From nobody Thu Dec 2 04:37:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF0A83A0772 for ; Thu, 2 Dec 2021 04:37:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=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, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 90AGnRu0i3_F for ; Thu, 2 Dec 2021 04:37:50 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 8005C3A00AF for ; Thu, 2 Dec 2021 04:37:49 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B2CbjDL1405119 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 2 Dec 2021 13:37:46 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638448666; bh=5DOmcikGCbqlo84bcB2ZNiU0OtPtB5XNNpMa43jwCGU=; h=Date:To:From:Subject:From; b=Wzk2RJ4Lw0mZowV3+EJ1+jvibhgMH4/RICBGhXFGEuGahdLAPHR2oNnIPcDpPYkkz NSjR+hgKnx3KTusB5Po6TIGpk1KcrhWnaF02EVT8tBdLcJlCf1j0NKSNNg1IB6T6dz Dl6ivZOlJw89++W2/XVJUYWXDydcozQWDpS+QRiU= Message-ID: Date: Thu, 2 Dec 2021 13:37:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------laz5APdoDNNtT62HTS9qBDrR" Archived-At: Subject: [Rfced-future] reminder: today's interim X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Dec 2021 12:37:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------laz5APdoDNNtT62HTS9qBDrR Content-Type: multipart/mixed; boundary="------------f0t8DS30Gyw2SXclQWoS3jtm"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: reminder: today's interim --------------f0t8DS30Gyw2SXclQWoS3jtm Content-Type: multipart/mixed; boundary="------------e4LqKG6FlDGNVdcog0aDkpTP" --------------e4LqKG6FlDGNVdcog0aDkpTP Content-Type: multipart/alternative; boundary="------------rMydJyDyPSUPFd17RPxGBMuL" --------------rMydJyDyPSUPFd17RPxGBMuL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Li4uIGJlZ2lucyBhdCA5OjAwcG0gR01ULg0KDQpMaW5rIGlzIA0KaHR0cHM6Ly9jaXNjby53 ZWJleC5jb20vY2lzY28vai5waHA/TVRJRD1tNzYwZGFlYjQzNWVlYmIyYWIyYjAxYjc0NDJi MDFiMjkuDQoNCkFnZW5kYSBpcyBhcyBmb2xsb3dzOg0KDQogMS4gTm90ZSBXZWxsDQogMi4g QWdlbmRhIEJhc2hpbmcgKDIgbWlucykNCiAzLiBDaGFpcnPigJkgY29tbWVudHMgKDUgbWlu cykNCiA0LiBEaXNjdXNzaW9uIG9mIOKAnFByaW5jaXBsZXPigJ3CoCAoNDAgbWlucykNCiA1 LiBOZXh0IHN0ZXBzICgxMCBtaW5zKQ0KIDYuIEFPQg0KDQpFbGlvdA0KDQoNCg== --------------rMydJyDyPSUPFd17RPxGBMuL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

... begins at 9:00pm GMT.

Link is https://cisco.webex.com/c= isco/j.php?MTID=3Dm760daeb435eebb2ab2b01b7442b01b29.

Agenda is as follows:

  1. Note Well
  2. Agenda Bashing (2 mins)
  3. Chairs=E2=80=99 comments (5 mins)
  4. Discussion of =E2=80=9CPrinciples=E2=80=9D=C2=A0 (40 mins)
    5. =
  5. Next steps (10 mins)
  6. AOB

Eliot


--------------rMydJyDyPSUPFd17RPxGBMuL-- --------------e4LqKG6FlDGNVdcog0aDkpTP Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------e4LqKG6FlDGNVdcog0aDkpTP-- --------------f0t8DS30Gyw2SXclQWoS3jtm-- --------------laz5APdoDNNtT62HTS9qBDrR Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGovhYFAwAAAAAACgkQh7ZrRtnSejOg VwgAszAy8iq6ZwpMHLZFA83D+4GxEs+uLgxoSSkDnqE+j2AsrsOMEUFPclkCqBvrgfshiWXsAQcq brzloPu8HZ3uZEAqNNb2cCTaeVZ6CsY/Vy0Bry6FOtLX68IMPGIyBHX7Npgohy5O1HZX96pKIXfk qtAqffRFe4hANyxMhoKtsrbRwPEs94YZOG3fPfGrvv0GyUCb5TTXTVfix4WEG3hv5ThpyoQHrGFq JLMoACu56NpgaCtfLslCVJVRitJI9Z7UczMIdluVqw5vLc+tf33zFcpPTs552pi1SWJDCE+gUM1W YkreTTunicKc8YGQVrETWms1NZTBqdsDiQXJVtICAQ== =sdyi -----END PGP SIGNATURE----- --------------laz5APdoDNNtT62HTS9qBDrR-- From nobody Thu Dec 2 11:26:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B46E3A0486 for ; Thu, 2 Dec 2021 11:26:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 0EOP4xcFNy6t for ; Thu, 2 Dec 2021 11:26:06 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9AC3A0485 for ; Thu, 2 Dec 2021 11:26:06 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1msriV-0003cm-AH for rfced-future@iab.org; Thu, 02 Dec 2021 14:26:03 -0500 Date: Thu, 02 Dec 2021 14:25:57 -0500 From: John C Klensin To: rfced-future@iab.org Message-ID: <5CCB7820E7B9E563371ED687@PSB> In-Reply-To: References: <7cec5108-bd80-cf68-106a-579ebff0b555@joelhalpern.com> <5F2A684C-716D-4465-ACC1-6855E4FE4835@ietf.org> <67745f0b-d5b5-4eeb-5218-6d33eca9b6cc@nostrum.com> <288E8939-43B9-413F-9237-D030C5F4EA12@ietf.org> <6efd25e0-7699-9e72-3a05-36f5d4e6604a@nostrum.com> <8833698e-7473-deca-2798-215418047236@nostrum.com> <8a2134d5-ad4e-43a2-585b-49309639ffef@joelhalpern.com> <1d090383-29a3-e61d-7357-eba9e423cf91@joelhalpern.com> <261c38f0-69e2-51d3-2aae-2e9ef27dec8e@joelhalpern.com> <84ED132E-39E5-4B11-9680-39179887016C@ietf.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Where, if not there? [was What, if not these] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:26:09 -0000 Hi. I have been trying, with little success, to follow this long and rapid-turnaround thread. If what I'm about to say has already been said by others, +1 to them. If not, perhaps this will be helpful to have down before the call because it _might_ point a path to a middle ground. In part because I believe it is possible, even likely, that the RSWG will be even less representation of that ill-defined extended community of people who depend on the RFC Series than this Program is (see below), I think the process we document and hand off to them must recognize that: * While it is probably adequately designed for making fairly routine decisions that should still involve community participation and oversight, there are issues of sufficient impact for which additional input is needed, including making efforts to reach out to people and groups who normally might not pay attention to what we are doing. In addition to the "principles" and/or types of "policies" people have been discussing, I would include any decision that, once implemented, would be impossible to reverse if experience (aka "running code") made it clear that it had not been a good idea. And "reaching out" does not mean just a generic invitation to participate in the RSWG or join a mailing list. * It is vital to give the RSWG very clear guidance about things that belong in that "more problematic" category, e.g., those things that require extraordinary outreach and review. I think we need at least a partial list of principles but maybe requiring that the RSWG carefully explore how a possible decision would be reversed if it turned out to be a bad idea (and report on that to the RSAG and IETF community) would substitute for many of them. Put differently, small adjustments of direction to stay on the same path to the same goals are ok; major changes of path, direction, or destination/goals require an extraordinary process. If the principles we can agree on are not more than example of things that require that treatment, maybe that is good enough. Maybe. * I'm also ok with leaving most of the definition of "extraordinary process" to the RSWG as long as we can make it clear that a serious attempt at outreach to user communicates for the RFC Series -- and listening to what they have to say-- is critical. While I'd hope to see some examples of such communities, including those who use RFCs in research work and for procurement, I don't think we need to try to enumerate that group. We just need to be clear that RSWG participants asking each other (or even the IAB, IESG, etc.) may be desirable but is not sufficient. Context for some of the above in addition to whatever I've learned from the list: First, if keeping up with this effort and being part of an informed, even if rough, consensus, requires reading and understanding over 200 messages on essentially the same cluster of topics in under three weeks, claims that our opinions or conclusions are generally held in the IETF community (even with a narrow definition of that term) are dubious. Judging from that and a count of the number of people who are posting (especially multiple times), the group seems to be sliding toward participation only from those who are very dedicated to getting things right as they see it, those who are being paid to do this specific work, and/or, as a colleague from another area of work would put it, who have too much time on their hands. None of those categories includes most IETF participants. Second, after thinking about Jay's "de facto" list and the recent discussions about principles, I don't think it would be appropriate or sufficient to hire an RSCE on the basis of that list. I've hinted at part of the problem before: in a situation like this, with a newly defined position, candidates should be judged partially of the questions they ask about things that don't go into the job description (RFP, whatever). Evaluation of those questions and the answers they are given is not going to be adequate to distinguish between likely good candidates and likely hacks unless they are strongly rooted in either clear principles or equivalent oral tradition. I am mentioning the above in this note and context, first because I see the discussion of principles to be at least as important to the qualifications for an RSCE as they are to the workings of the RSWG/RSAB. And second, because I think a RSCE with the right qualifications and experience would be a good source of advice both on which communities to reach out to but on how best to do that outreach if we really want input and advice. See many of you soon. best, john From nobody Thu Dec 2 14:09:58 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E35D03A07D3 for ; Thu, 2 Dec 2021 14:09:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=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, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VZOZ2REGIVP7 for ; Thu, 2 Dec 2021 14:09:48 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 410B23A07DD for ; Thu, 2 Dec 2021 14:09:47 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::2] ([IPv6:2001:420:c0c0:1011:0:0:0:2]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B2M9h861683486 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 2 Dec 2021 23:09:45 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638482985; bh=Or/lmTzGjjgxCyE7ipkaEOIT5NnDUnTJPxxUJHLdtrQ=; h=Date:To:From:Subject:From; b=HMiXY1ASgylRbGrnbWAoso2NJoHrBQxNGee1kW1igA2817wdpz0Bv22W3BKEUB5FU yqEMren36fzct9PlLh75c707+CDTk7E4EYtpuq9KaY0eNykYKd+65ufOo9z3aaqBjV /cLFf984/yqe+9mcwLAnqmzf1U5fddzd830c5R78= Message-ID: Date: Thu, 2 Dec 2021 23:09:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FaLd2kUafQ6jxKkTnubs3fkN" Archived-At: Subject: [Rfced-future] WebEx recording X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 22:09:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FaLd2kUafQ6jxKkTnubs3fkN Content-Type: multipart/mixed; boundary="------------wrvMsKcXn024eXJuptgc7PCb"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: WebEx recording --------------wrvMsKcXn024eXJuptgc7PCb Content-Type: multipart/mixed; boundary="------------tNFb1lOCHpYRY2udmZumBrh7" --------------tNFb1lOCHpYRY2udmZumBrh7 Content-Type: multipart/alternative; boundary="------------zHXv4DXLibeCS9GR7UoDcxj2" --------------zHXv4DXLibeCS9GR7UoDcxj2 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VGhhbmtzIHRvIHRob3NlIHdobyBhdHRlbmRlZCB0b2RheSdzIGludGVyaW0uwqAgRm9yIHRo b3NlIHdobyBjb3VsZG4ndCANCm1ha2UgaXQsIGFuZCBmb3IgdGhvc2Ugd2hvIGRpZCBidXQg bGlrZSBsaXN0ZW5pbmcgdG8gcmVjb3JkaW5ncywgeW91IGNhbiANCmZpbmQgdGhlIFdlYmV4 IHJlY29yZGluZyBoZXJlIA0KPGh0dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2NvL2xkci5w aHA/UkNJRD00NGZiYTc3ZjNlZWY0YzVmODVjMzdlYTViOTk4M2FkNj4uIA0KVGhlIHBhc3N3 b3JkIGlzICJLcDdTandwTiIuDQoNCkVsaW90DQoNCg0K --------------zHXv4DXLibeCS9GR7UoDcxj2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks to those who attended today's interim.=C2=A0 For those who couldn't make it, and for those who did but like listening to recordings, you can find the Webex recording here.=C2=A0 The password is "Kp7SjwpN".

Eliot


--------------zHXv4DXLibeCS9GR7UoDcxj2-- --------------tNFb1lOCHpYRY2udmZumBrh7 Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------tNFb1lOCHpYRY2udmZumBrh7-- --------------wrvMsKcXn024eXJuptgc7PCb-- --------------FaLd2kUafQ6jxKkTnubs3fkN Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGpRCUFAwAAAAAACgkQh7ZrRtnSejPo kAgAlSZW4ykbUUbOmzw26rt2oySAutEoZhOElxFPXnDrLepeiGAOclWYCBnsOZX59SwD5Ugp3+CX tDmZUZ9L6l/GbBA3T85OnKMBuKowTSu+zZP1ihOo10de84CSz6WeOcoCp/oGE/Pg0/kZIr+U5cDW kopUb3WY/Mm5AstAQ7YfSvOtJGiD/tyjuo0o1PGd12GcDfBscF/fAsSMxmEJRL66Yttjy+Smw3+I aMhR5FbX1AsMqu/BVIJORfXeWo1Gc7WrwIPLZnmpyv2750pFSmQpmi1FIPgk/0GO+eWri7Tsj1Jl jjPubwLXHTdIheufUmyG7fcjpt+IYnjfKmmDtsBCcQ== =ed7R -----END PGP SIGNATURE----- --------------FaLd2kUafQ6jxKkTnubs3fkN-- From nobody Thu Dec 2 15:36:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D28C3A07B6 for ; Thu, 2 Dec 2021 15:36:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Pi1l7mfo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nExTVdUd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-qHtg0iiNrk for ; Thu, 2 Dec 2021 15:36:50 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F25C43A07B0 for ; Thu, 2 Dec 2021 15:36:49 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EF8C15C0257 for ; Thu, 2 Dec 2021 18:36:48 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Thu, 02 Dec 2021 18:36:48 -0500 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= fm3; bh=sMtkRg8J1EE33c7E3hz4GNqICOLMuuGK6U8S9VN4B38=; b=Pi1l7mfo jN3IE/CtkX5G7qB7VNfQ2IL8hi1cr30Tax9ilY6yoXHkrSkGCIZlhi6JcQnpoC14 rbJc10VBeUhq4zXG0KXblAPk5PBbtftkj4BChTZ8ejaY7YldeyKqWq/TJPlEsF57 v/AMb0GTO1+rpe8IVun6Kh1mPWWVBCRUy+9AP9ZzHT4TDuS5MTiss6tatx6HwrOF 1JS6NPnoz6/wm6EjBCysjcbd/G9sz0CwnBN3fxNY15GbGebK1IuT61fvxy12xwNt AQIEMwgzdhKCbfq6sIWmy5iuLL50nyV8BuCNwHtszaUMX+eo5/nJxKgdK+XXcVJT IxSGqa2pJI7gnw== 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=fm1; bh=sMtkRg8J1EE33c7E3hz4GNqICOLMu uGK6U8S9VN4B38=; b=nExTVdUdXEDtm7gbB7UXHL7g6fCE78WmXx/TizSH6TQtJ W2WoMTXIe12jb+nwHrsBZ2eFMz9pBhS4CUE7ByQfE6WXQG07d2Stvjv+OG2/b+q6 oUjNuMDiFgIxSlA2pu/n+6sPgGlSGZgIJmDUAM0l5OZ1EmBsS5AX33XkL3PEGmKA DSW4nmQbIRSIBjd2gaZ1jcXROT8LCQ7g2NSOs99Ua7HipzTIixJXf4mBorb37i/m sgeoa3MBxr+falpCFzrXN2lbO3o54/DvvX8tJPy0Z9Y1IKG1n8/jUSK1ba2lN6IP 9aPzHuvq6yAdEyaQgiWPzPXThFLeJAWFjMONOV5Cg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrieeigdduvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkfffhvffutgesthdtredtre ertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghn thhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepvefguddtgfejfeduueehkeehke duueegheefgeevkeekgeelveevffeuudffheehnecuvehluhhsthgvrhfuihiivgeptden ucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D1BFB3C0F83; Thu, 2 Dec 2021 18:36:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4458-g51a91c06b2-fm-20211130.004-g51a91c06 Mime-Version: 1.0 Message-Id: Date: Fri, 03 Dec 2021 10:35:49 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:36:55 -0000 The text below attempts to capture a few things that I believe were the result of our discussions earlier today. First, that the RSAB has the responsibility and authority to decide how much review is appropriate. They are expected to exercise judgment in how they manage the public comment and review period, this just strengthens that requirement. Second, that the RSAB judgment on this matter would benefit from a few guidelines so that things that have been put in place deliberately over the years are not removed without equal care, deliberation, and consultation. Third, that this does not fundamentally change the process we apply. We still follow the same basic processes that we've agreed to. However, we highlight the need for additional care so that changes to important things are, as discussed, "very deliberate" and that the consequences of those changes are given due consideration. For this, I took Brian's text and tweaked it. The introductory piece here is mostly new, to capture the above points. The detailed points are largely the same, concentrating as they did in Brian's formulation on being factual rather than prescriptive. I have only edited some of these points down slightly to sharpen the focus. --- # Historical Properties of the RFC Series The RSAB has a duty to ensure that proposals from the RSWG receive appropriate levels of review. Proposals that, in the opinion of the RSAB, have significant impact on the series require additional outreach and review from a wider community. Additional time should be allowed for collecting feedback for such proposals. This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. However, the RSAB should seek broader review for proposals that might have a detrimental affect on these properties. The purpose of review is to ensure that all changes are deliberate and that all of the consequences of a proposal have been carefully considered. ## Availability Documents in the RFC Series have been available for more than 35 years, with no fee for access. ## Accessibility RFC Series documents have been published in a format that was intended to be as accessible as possible to those with special needs, e.g., for those with impaired sight. ## Publication Language All existing RFC Series documents have been published in English. Documents have been licensed to explicitly permit translation into other languages. ## Content Diversity In addition to Internet standards, the RFC series has published procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies. ## Document Quality RFC Series documents have been edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322]. From nobody Thu Dec 2 16:12:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8913A3A0912 for ; Thu, 2 Dec 2021 16:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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=stpeter.im header.b=O2r/XcHz; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Pd/npqTm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOOunldStBR4 for ; Thu, 2 Dec 2021 16:12:14 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A0C53A090F for ; Thu, 2 Dec 2021 16:12:14 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 5783C5C034D; Thu, 2 Dec 2021 19:12:13 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Thu, 02 Dec 2021 19:12:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=F EwgjK8WO53DsG1G3g0UFY+SlmJvl3tVrO5pdf4n4eM=; b=O2r/XcHzhanjFq5Sw tt5L2aI7t6Wk1i9BCngj8qveLaUHb3HP1hFDWDgyjWLuxnxJMfw5JmPGH8jMBeqi sMhrfmUGdi1jxDdMj93ujPqdBvQbvOvn4z+l7aYRe7E0jAwWsScpJU6Ly0wvioVt 3wGrShxz+l5huNlyf/qjADsRRFbLRCqlNh+xdJFvtiotibya6rnWvIR9VDG0SaDk w9cdRYMRSV1tm3EVmzzRWMjDFvK0B1SSc32zapZ8l5yitgVBeR4Gp3+kJk162TNz 3yH22ZtO0qBUPoV0WpEoL7sGrQTeq3SdvxZ8Lv6fV/Mk5ARXZ51bmZdG/5j9d5EY 7LlbA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=FEwgjK8WO53DsG1G3g0UFY+SlmJvl3tVrO5pdf4n4 eM=; b=Pd/npqTm5IEzeLqdI5K6Uu1w30ZUvYF2LrtIEfEQYbr2oSVdsrcg8uBCa cTajXRwCG6GvHaAFO3jGJdEs7t4lDxDkTeUGskR5SzR4WTxGkTVu39OjsIDeQztx iNd0IcsEDl8WyGrPu6nAjbr0S3lIFWI1LL41kRNBVZnxh02w676gxrNXR1n/60SS qJUunPiC0D5t2V/yI2UPx6VqPfQKHFyPnHhQmwogo8yynohsyps8O6NrbLGh8b/N UJbxCvhJRrDmACUBm3l0NuxYFkU2deDUrjMM+KM5jdFNsXm6eVkyirBucQIkgDuz Pkq20zxRajMMm8hoG6D+K/tCfSU4g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrieeigddulecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvghtvghr ucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqeenuc ggtffrrghtthgvrhhnpeehtefhvdejvdfhgeetgefhfeeuudefkeetvdfhkeelleeuheef leekkeekieffudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehsthhpvghtvghrsehsthhpvghtvghrrdhimh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 2 Dec 2021 19:12:12 -0500 (EST) Message-ID: <710ca179-3e9d-0501-d68c-c030ff9cc058@stpeter.im> Date: Thu, 2 Dec 2021 17:12:12 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Martin Thomson , rfced-future@iab.org References: From: Peter Saint-Andre In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:12:20 -0000 This is looking good. When I work on my part of the text, I'll likely place your first paragraph somewhere else in the document. On 12/2/21 4:35 PM, Martin Thomson wrote: > The text below attempts to capture a few things that I believe were the result of our discussions earlier today. > > First, that the RSAB has the responsibility and authority to decide how much review is appropriate. They are expected to exercise judgment in how they manage the public comment and review period, this just strengthens that requirement. > > Second, that the RSAB judgment on this matter would benefit from a few guidelines so that things that have been put in place deliberately over the years are not removed without equal care, deliberation, and consultation. > > Third, that this does not fundamentally change the process we apply. We still follow the same basic processes that we've agreed to. However, we highlight the need for additional care so that changes to important things are, as discussed, "very deliberate" and that the consequences of those changes are given due consideration. > > For this, I took Brian's text and tweaked it. The introductory piece here is mostly new, to capture the above points. The detailed points are largely the same, concentrating as they did in Brian's formulation on being factual rather than prescriptive. I have only edited some of these points down slightly to sharpen the focus. > > --- > # Historical Properties of the RFC Series > > The RSAB has a duty to ensure that proposals from the RSWG receive appropriate levels of review. Proposals that, in the opinion of the RSAB, have significant impact on the series require additional outreach and review from a wider community. Additional time should be allowed for collecting feedback for such proposals. > > This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. However, the RSAB should seek broader review for proposals that might have a detrimental affect on these properties. The purpose of review is to ensure that all changes are deliberate and that all of the consequences of a proposal have been carefully considered. > > ## Availability > > Documents in the RFC Series have been available for more than 35 years, with no fee for access. > > ## Accessibility > > RFC Series documents have been published in a format that was intended to be as accessible as possible to those with special needs, e.g., for those with impaired sight. > > ## Publication Language > > All existing RFC Series documents have been published in English. Documents have been licensed to explicitly permit translation into other languages. > > ## Content Diversity > > In addition to Internet standards, the RFC series has published procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies. > > ## Document Quality > > RFC Series documents have been edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322]. > From nobody Thu Dec 2 16:41:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0648F3A09D6 for ; Thu, 2 Dec 2021 16:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 ihlbw8MDYdkY for ; Thu, 2 Dec 2021 16:41:50 -0800 (PST) Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8BF3A09D2 for ; Thu, 2 Dec 2021 16:41:50 -0800 (PST) Received: by mail-pg1-x529.google.com with SMTP id f125so1453098pgc.0 for ; Thu, 02 Dec 2021 16:41:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=NC7Nl322QvBA4tA/HcrFopZ+jH1nSnt6z4I8VwCnBW0=; b=GJwus8bkl1Eg8RbWqBkVh2IQfx5jAbzCUAP4u0GTg7M5kUrLa+rZyaULUIXxCP8JD6 Xoq7qfmmGJVj0ToOMska82v2WoAB2/ZauJcTA7T1AJmHcSjrRuFtpYJiTvus8wl2tzlp An6Dq+3NMwMdiH9+NSIe6dL4ues1+lS9PvuyBVllho+F47c83xGuDkb+KOwgtUEdUBxZ 5yXSAtj+NbBe1bXz9tiVCMT1SX1X5tqSFwYFfdV4czdl97jam4bkH3U4eguN1AcBxkpN plh+KsW6bkJzLRbgc9KrcFcRWfYoK3EnrcLPA/FqIPP08nwXGhAUTRQjr734JoM+fcrf TFLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=NC7Nl322QvBA4tA/HcrFopZ+jH1nSnt6z4I8VwCnBW0=; b=3O/Iw61HGd3b9Pn1Fr6tpFpghUWl16fWzDZpDLrIJDp0cNOLM65BbTxcjzmWeMqC/Q SFMlD3AXKeOhRVEISrk/Uk/UHCWsT3lLLREQQj8oDYph8H2alHO2YbgDDzdjJe1s/9LC oDUexgUzGTSqlqE3vKA8jWJCVguvapQ9hhYs5qjQ4lplPDfkpZtD2ZjEfHuMziDHbdFk 6MCcy7VhuCwq//hnQwXE3cy4fOvDgGGMmGrBM2FLTtvAQ5yFf3YSazaLRnoKXC61Y3f/ XsBzx2LGLi41ToqHISzse5K0RG/WDQWVfDhAlqiPOvX4YIFysRpecrwb8vPQSyc3Ak/D k0UQ== X-Gm-Message-State: AOAM532Jq4PIR8Gn8Ox9rRMuHsQoSuglkTsZS5/xHdZ8ApiJ9Owo24is yu/4IvKU5LOykph8cgKEp5WiO4nA1vjPlw== X-Google-Smtp-Source: ABdhPJwK8GEnV7YC8NVgLmENvFOUuMNWJvw7h/seiaZOYJhxCK8nW6+ZCA4EXlBEVVMazb97HZhmVg== X-Received: by 2002:a63:9042:: with SMTP id a63mr2079220pge.75.1638492109113; Thu, 02 Dec 2021 16:41:49 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id rm1sm3712622pjb.3.2021.12.02.16.41.47 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Dec 2021 16:41:48 -0800 (PST) To: Martin Thomson , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: Date: Fri, 3 Dec 2021 13:41:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:41:52 -0000 This definitely works for me. Regards Brian Carpenter On 03-Dec-21 12:35, Martin Thomson wrote: > The text below attempts to capture a few things that I believe were the result of our discussions earlier today. > > First, that the RSAB has the responsibility and authority to decide how much review is appropriate. They are expected to exercise judgment in how they manage the public comment and review period, this just strengthens that requirement. > > Second, that the RSAB judgment on this matter would benefit from a few guidelines so that things that have been put in place deliberately over the years are not removed without equal care, deliberation, and consultation. > > Third, that this does not fundamentally change the process we apply. We still follow the same basic processes that we've agreed to. However, we highlight the need for additional care so that changes to important things are, as discussed, "very deliberate" and that the consequences of those changes are given due consideration. > > For this, I took Brian's text and tweaked it. The introductory piece here is mostly new, to capture the above points. The detailed points are largely the same, concentrating as they did in Brian's formulation on being factual rather than prescriptive. I have only edited some of these points down slightly to sharpen the focus. > > --- > # Historical Properties of the RFC Series > > The RSAB has a duty to ensure that proposals from the RSWG receive appropriate levels of review. Proposals that, in the opinion of the RSAB, have significant impact on the series require additional outreach and review from a wider community. Additional time should be allowed for collecting feedback for such proposals. > > This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. However, the RSAB should seek broader review for proposals that might have a detrimental affect on these properties. The purpose of review is to ensure that all changes are deliberate and that all of the consequences of a proposal have been carefully considered. > > ## Availability > > Documents in the RFC Series have been available for more than 35 years, with no fee for access. > > ## Accessibility > > RFC Series documents have been published in a format that was intended to be as accessible as possible to those with special needs, e.g., for those with impaired sight. > > ## Publication Language > > All existing RFC Series documents have been published in English. Documents have been licensed to explicitly permit translation into other languages. > > ## Content Diversity > > In addition to Internet standards, the RFC series has published procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies. > > ## Document Quality > > RFC Series documents have been edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322]. > From nobody Thu Dec 2 17:06:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2C903A0D33 for ; Thu, 2 Dec 2021 17:06:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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 6CdqGilpiuBj for ; Thu, 2 Dec 2021 17:06:43 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50AA83A0D32 for ; Thu, 2 Dec 2021 17:06:43 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4J4vmL6s8xz6G9sQ; Thu, 2 Dec 2021 17:06:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1638493602; bh=RAEb2dOnIvK5zlu+r8PQ9aWuyEnvt4wdK8lhrMDRWps=; h=Date:Subject:To:References:From:In-Reply-To:From; b=bIJ3h7ouRG3YSPIqcozBn1qy9gI75uDXAuMpfhR4sjYIYzSxYYDb7d2AxnXT7yFJU EwSXpTdBae8ZKNFZkeicbww4tFNZNxXOXjqw696TgyXmQNT1WDeiPLrN8m+p6CbqDi nVKGjW4uq3a6LMMuusaorYJzJAkOwx9DwrRP5qJ8= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4J4vmL2Nb0z6G9Vm; Thu, 2 Dec 2021 17:06:41 -0800 (PST) Message-ID: Date: Thu, 2 Dec 2021 20:06:40 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Martin Thomson , rfced-future@iab.org References: From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:06:48 -0000 Thank you. My first reaction is that I can live with this. In particular, I can live with the formulation of the introductory material. The details seem a good start, although i want to think about whether there is more we need. (I hope not. There is benefit in keeping this short.) Yours, Joel On 12/2/2021 6:35 PM, Martin Thomson wrote: > The text below attempts to capture a few things that I believe were the result of our discussions earlier today. > > First, that the RSAB has the responsibility and authority to decide how much review is appropriate. They are expected to exercise judgment in how they manage the public comment and review period, this just strengthens that requirement. > > Second, that the RSAB judgment on this matter would benefit from a few guidelines so that things that have been put in place deliberately over the years are not removed without equal care, deliberation, and consultation. > > Third, that this does not fundamentally change the process we apply. We still follow the same basic processes that we've agreed to. However, we highlight the need for additional care so that changes to important things are, as discussed, "very deliberate" and that the consequences of those changes are given due consideration. > > For this, I took Brian's text and tweaked it. The introductory piece here is mostly new, to capture the above points. The detailed points are largely the same, concentrating as they did in Brian's formulation on being factual rather than prescriptive. I have only edited some of these points down slightly to sharpen the focus. > > --- > # Historical Properties of the RFC Series > > The RSAB has a duty to ensure that proposals from the RSWG receive appropriate levels of review. Proposals that, in the opinion of the RSAB, have significant impact on the series require additional outreach and review from a wider community. Additional time should be allowed for collecting feedback for such proposals. > > This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. However, the RSAB should seek broader review for proposals that might have a detrimental affect on these properties. The purpose of review is to ensure that all changes are deliberate and that all of the consequences of a proposal have been carefully considered. > > ## Availability > > Documents in the RFC Series have been available for more than 35 years, with no fee for access. > > ## Accessibility > > RFC Series documents have been published in a format that was intended to be as accessible as possible to those with special needs, e.g., for those with impaired sight. > > ## Publication Language > > All existing RFC Series documents have been published in English. Documents have been licensed to explicitly permit translation into other languages. > > ## Content Diversity > > In addition to Internet standards, the RFC series has published procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies. > > ## Document Quality > > RFC Series documents have been edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322]. > From nobody Thu Dec 2 17:12:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1173A0D41 for ; Thu, 2 Dec 2021 17:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.741 X-Spam-Level: X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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 QsYyxaKx5-rd for ; Thu, 2 Dec 2021 17:12:50 -0800 (PST) Received: from mx36-out21.antispamcloud.com (mx36-out21.antispamcloud.com [209.126.121.69]) (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 8F3483A0D3E for ; Thu, 2 Dec 2021 17:12:50 -0800 (PST) Received: from xse91.mail2web.com ([66.113.196.91] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1msx7z-000Cjf-Sl for rfced-future@iab.org; Fri, 03 Dec 2021 02:12:46 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4J4vvF06Cwz9cS for ; Thu, 2 Dec 2021 17:12:41 -0800 (PST) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1msx7w-0004w0-SY for rfced-future@iab.org; Thu, 02 Dec 2021 17:12:40 -0800 Received: (qmail 8568 invoked from network); 3 Dec 2021 01:12:40 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.46.129]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 Dec 2021 01:12:39 -0000 Message-ID: Date: Thu, 2 Dec 2021 17:12:38 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Brian E Carpenter , Martin Thomson , rfced-future@iab.org References: From: Christian Huitema In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: 66.113.196.91 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KmiN Jlbp35LDv6neYIU3V6OyXsfpoA8yRVY+nIJ7kGZoSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVNeJTN7DFlYFLtIwbcoJsupotTbzF8bFslzcWfB/84WUhy/LP m2rFgOGYwKKX1POmkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dgjI4WE+pjPnfrWRF8b8VMfY s4VVx2OseivC2LxUp6eXb3UQT3xbkHqpqmyCe4PiKWIgJ2XxgK7Je5b0uU+cZFhDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAlp/ocjByv7EVGpOjPvPwdUsOtp+q3yU+z72+fnpodgpDIzNi k21rJduSLMQHg9ex5JgNcSDGdJql6+v1ck8qbYNmMRr+w2X69ygMahiTQMBdXNaLjwRWNZtndPBz yzhMETheMPxghFsjIwINNqkbXC8q7fBXfwiTkcwbv0dB5b3yNR3oW5YiBYO7UVjw0gdRPrII++x6 YSSQfv2n7TJ4De1knRDjH7QY7Fm+gQ0M40rBtaly/uPaPGs4IuAYIIDnnmIMx2SsJMcYcfaTa1Z5 siYOS4qqjKkTvrhEiORgsEtrMS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:12:53 -0000 +1 On 12/2/2021 4:41 PM, Brian E Carpenter wrote: > This definitely works for me. > > Regards >    Brian Carpenter > > On 03-Dec-21 12:35, Martin Thomson wrote: >> The text below attempts to capture a few things that I believe were >> the result of our discussions earlier today. >> >> First, that the RSAB has the responsibility and authority to decide >> how much review is appropriate.  They are expected to exercise >> judgment in how they manage the public comment and review period, >> this just strengthens that requirement. >> >> Second, that the RSAB judgment on this matter would benefit from a >> few guidelines so that things that have been put in place >> deliberately over the years are not removed without equal care, >> deliberation, and consultation. >> >> Third, that this does not fundamentally change the process we apply.  >> We still follow the same basic processes that we've agreed to.  >> However, we highlight the need for additional care so that changes to >> important things are, as discussed, "very deliberate" and that the >> consequences of those changes are given due consideration. >> >> For this, I took Brian's text and tweaked it.  The introductory piece >> here is mostly new, to capture the above points.  The detailed points >> are largely the same, concentrating as they did in Brian's >> formulation on being factual rather than prescriptive.  I have only >> edited some of these points down slightly to sharpen the focus. >> >> --- >> # Historical Properties of the RFC Series >> >> The RSAB has a duty to ensure that proposals from the RSWG receive >> appropriate levels of review. Proposals that, in the opinion of the >> RSAB, have significant impact on the series require additional >> outreach and review from a wider community. Additional time should be >> allowed for collecting feedback for such proposals. >> >> This section lists some of the properties that have been historically >> regarded as important to the RFC Series. Proposals that affect these >> properties are possible within the processes defined in this >> document. However, the RSAB should seek broader review for proposals >> that might have a detrimental affect on these properties. The purpose >> of review is to ensure that all changes are deliberate and that all >> of the consequences of a proposal have been carefully considered. >> >> ## Availability >> >> Documents in the RFC Series have been available for more than 35 >> years, with no fee for access. >> >> ## Accessibility >> >> RFC Series documents have been published in a format that was >> intended to be as accessible as possible to those with special needs, >> e.g., for those with impaired sight. >> >> ## Publication Language >> >> All existing RFC Series documents have been published in English. >> Documents have been licensed to explicitly permit translation into >> other languages. >> >> ## Content Diversity >> >> In addition to Internet standards, the RFC series has published >> procedural and informational documents, thought experiments, >> speculative ideas, research papers, histories, humor, and even eulogies. >> >> ## Document Quality >> >> RFC Series documents have been edited by professionals with a goal of >> ensuring that documents are clear, consistent, and readable [RFC7322]. >> > From nobody Fri Dec 3 01:18:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC913A1534 for ; Fri, 3 Dec 2021 01:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvkt2iLZSuSo for ; Fri, 3 Dec 2021 01:18:16 -0800 (PST) Received: from JPN01-OS0-obe.outbound.protection.outlook.com (mail-os0jpn01on2072f.outbound.protection.outlook.com [IPv6:2a01:111:f403:700c::72f]) (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 555A23A1532 for ; Fri, 3 Dec 2021 01:18:15 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H2rrLEHYJLxTsbqW+Rra9kouLjMeKb4mJl5rHyXXFnqn68okm0Jer1l21RkREA9vFOCujESDZ37zzzVWAxCTtOHqadThj4njb0vqLjtiuXANrPnAu+EpGfTcX8Fdd8C7JD+1LaNyhvpF+iyzDsRPXz9PEn2g4Ksm7XU0nLDcZe/IbdzU5HgsRUzdfZnhaJqctoWgEIVFZRIE32lSnUdTk5y7UD8Koygacgx97rirVmU/KE3M+0MFVByuD33dWDo6qS8wMpbrJ9eE4oVrYAzAN84H9nXgiKcnSHEKxGADv1xDg/ROlX3fL4MwME2YEBOJS3dEPOJHHsAUtbenkDzL6g== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S6A8r2i+ZzDdlgHii1+GXWnvBTRyW1YIN7AetG7T3SQ=; b=Gbm4S2nOEQEHxV9Ar2f4QJ/xND85CYGuMKrlcPXLzJ7jCuuB8S+vNm7V+gS29bQHaugkRjf3aVHNB3NjQrnlcByMOoougWBpJ01iQCm+XeHfUEDtEFuBfTWSuctbhhLyqwRLGSAYCHgnBS42P23UPzGkXOsIqSPcDJ5A/jdLeWfhx0X/LmyYZApxm3nGAFrnjc4tbD6vaHicidDvnobjT5OxrwJ0xPGbinLxV7hUmzMG5Fz9g4m83hQgvuf7IqNA7WPL2838BIsqBaThTjq2ejmh6FFzDk0tddZt5aSpC+rE7bIxEn2g5cd9f1+jewqLfppUsrWXtqXvaVbG/YPXfg== 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=S6A8r2i+ZzDdlgHii1+GXWnvBTRyW1YIN7AetG7T3SQ=; b=sVVLEsyPbgK22aH24zYapxQat650L1bAvgCtpKo3EqdKnidXYaRKDTKnAq+7vgEhk1Vy3Ap4fIZ0VS9OP+LYm/Cu7dPSc/FTmKFCT0VsptXKhL6qjlCQz4OZ78Etfp1EAoLwYkbNSOfvR9I5CiVMHelg4j7nV6HERdMPBIA/Ylc= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB4270.jpnprd01.prod.outlook.com (2603:1096:404:c6::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.20; Fri, 3 Dec 2021 09:18:05 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::348d:f2c7:d58f:35f3]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::348d:f2c7:d58f:35f3%7]) with mapi id 15.20.4734.028; Fri, 3 Dec 2021 09:18:06 +0000 Message-ID: <32294a20-86f7-9198-c4d0-653a0ef92439@it.aoyama.ac.jp> Date: Fri, 3 Dec 2021 18:18:04 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Martin Thomson , rfced-future@iab.org References: From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYAPR04CA0024.apcprd04.prod.outlook.com (2603:1096:404:15::36) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 Received: from [133.2.210.39] (133.2.210.39) by TYAPR04CA0024.apcprd04.prod.outlook.com (2603:1096:404:15::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.17 via Frontend Transport; Fri, 3 Dec 2021 09:18:05 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1155df6f-5b9a-46cc-b1af-08d9b63dd07b X-MS-TrafficTypeDiagnostic: TYAPR01MB4270: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3BQiFYRNmZf4Pkf9xRsMG/6kjbEt8LprPEqayFw/Sr7cZkdUYIHyrnDSGoO2fm2fDaxOFyv+Wyq7gSy2T3qmsj2wWj+BLaF59W4SbLsDCn4pIW1sPqID9xkSd9V9BfuUS40LpGwCRyXmk2KCgWyI7Ko+t4fvaQAUHls5+3gyYFWbdOmErDgDF1laRk+OSyQUaZQjsNecRoNv8BQnc10rcWuxuD7fK3U68F5D6/NtPdtX8yt0iF0wbqDu0BnVogIIdI3vD454ac7fh3AjmO0nMxsLTyr0lRj6Opy4rPusDVCJOIhlL0nP0JcUWRqz9uFsEzdYtVB52Q6hASbNv/xtFwc/3aJv8CFcEgaUruNJP+18Y7QoxNfTwf4zow2klYMBUl1g3/XOwknOuxxf4ZL0tTpoM7B2IcYZNx7pEmBs3iSoniGsjMo8+r/G/GNfIXo2dnPnA2cvuoM5WteMzD3Om94fiC5ZPB1/XDTmD/r+qux2AHnmWbgdd4cy5bbvJAwBrBOIefKjld57SVlWg8QsSsBTHRdpih8m3DjsAkmuY93d3ypyUYG/1XVtULys8Hs80vq06n9YUsHOfl/nnaKQn9rUC4FdSeRHLZWo2LpHSWiiw7x14AAHyagrtjyDR50OEweNMwCup2GWIoClYjyVSnhpkhaoJpGBDYRcgOFlVpkeVtrs01IH7dALTQI/jdLe7VqC5KFHJeQ5+g2uXNq7UBurROw7yf82z32cScMgI+A9WZvrx2RUdaSNxZXBFkuhdLSSoeF9ONIvR9mvoXsXPVspLUb+cFum5ELM1V+4WPA= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(346002)(136003)(39850400004)(366004)(396003)(786003)(83380400001)(66574015)(16576012)(316002)(86362001)(508600001)(6486002)(8936002)(66476007)(6706004)(66556008)(8676002)(66946007)(36916002)(38350700002)(2616005)(53546011)(31696002)(2906002)(5660300002)(956004)(31686004)(52116002)(186003)(26005)(38100700002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Yk03TnVtQ3JwMTFMTVJWcHg3dXhLQnY3TjVNdmVuTGZWaS83SWhkcFhES0Vx?= =?utf-8?B?TFlQYzJmcFcrTGNCVFoyd1o0VUFWQTRETHY1bzBuVHRyeXMzL0trYmtBWVlC?= =?utf-8?B?SmpWSDJGcmdQUDdjem9GMEtvNUlQQUJXL0U5WVBFMXFZMDdobFVoQitkWlFS?= =?utf-8?B?c21tSi9QK3R3WTk3WjBvVE5KVkZISXRPOU00dS85K1JHSVRYU3VwZkhmTmV2?= =?utf-8?B?YzdXa2tiQk5Hai9MdTFlS1lySVFJY2ovMGVSK2xrYWdHenVyVHBzdytNUzFr?= =?utf-8?B?OWRqd0ZPNnJTVEQ2bk9aUkkvTEFXTmtEeEt2VG5UTVZqUFpqSGR1MUtQTDI1?= =?utf-8?B?akFXaFVLNGs2eWszZ2M5bnVwZ1FHbThOOC9xV3Z2SUNld1pHZ1docTBOekVF?= =?utf-8?B?c1ZPenNrSDVqTnp0MjREMFRWRG05YkUyZ2hMYms5UnlvTTNZV2NpaWdrOFpF?= =?utf-8?B?Skh1b21CN2I4Z3ROMG56c2RHZzN4dXpYSGpSL2dPZk9hd2pLa2NPZ0RZZXE2?= =?utf-8?B?WndDaXFaQjhRNkdBM2lVMURMeDJ1MHZRcjVnUS9JTFdrOFZhSWtxNG9zSENV?= =?utf-8?B?T29jTitBOUtCUWxkdm95d2hQMjJmd1J2ZnBxY1pxOWFmbVBOSFZBRHcwMFhs?= =?utf-8?B?REN0Uk10dVZmUVZ4cDZSb1U4QTY1bW9WQjA5UHFZclhrOGMrVVRzUDE4M3E1?= =?utf-8?B?N205Mk1rWUpVWFNYOFRuTTFyNGlDSXNmWmd4OFU0OTVUWUdkV0p6R1pMSXNG?= =?utf-8?B?YkZxTitNZWRPQ2FJVnJwdjZQL1NFZitCZnlzK3ZXaGt0OW1pV2h0WnJ0NWhk?= =?utf-8?B?bmJub3V3c2dSd2E1bXdBU2xvVTk3YlpaNEpwWG5WY0lRNWpNdG5nNEpVTHlW?= =?utf-8?B?K3UyT1JBWmxwOS9sSy82aHhqZSt3RHpNYTIzTnlMTjRpMHFDM2xPNXdqVnRz?= =?utf-8?B?T3d2TXhjQTNEWk4ycEJPWEtiZE5tdSttdTlVR3VtWVk4TGV0Z0lxeVpKMEds?= =?utf-8?B?Zm51N3dhVUprc1hadWkyWDhkbkFNRklXMldrUEVFT3hGemRMaExIZnNrQVV3?= =?utf-8?B?R2RSbWRFeTVCcW9GcWlROUVHWTlFU2ZVeHhUeFFvLzVUVy9VVlV1dFJhNy9W?= =?utf-8?B?MlpJZHRxbkxZUFl2ZHJaZkR3OThxeS9WRmJGcnR2Tllla2x3MXpFN0RLbnBX?= =?utf-8?B?M3FYUUtJMldCVmVjQWpXeUxoVFArbTdmT1lMd3VtNllnWllReFU3ZEw2TjhI?= =?utf-8?B?YzJGelhSWmpHak1iWnZOMi9aRzhzbWRQRWt1cWw0RERuak9KMDJEKzNZRURS?= =?utf-8?B?OUhpRzIxSXdNSmtRSXFUMDVhVjhDRG1sbldJcjRmc3I5Sm9TSnJ3cjQySStv?= =?utf-8?B?TmV5SklBbG03VmhSb0E5Um5UQTRWZUxoZUhqYUNjQnBmbEVDWldUd09sbEI3?= =?utf-8?B?c3NXbnJjaTlEeGFUYm9zRnQ4TFY4dStxaWtDQWsyQXJlQXhmaUxqRng3MVMy?= =?utf-8?B?UXFnekd5NDhYYVBzU1JISHhRVXljN0VrMytmd0txUXlCY0VqZWx2amxtVmpO?= =?utf-8?B?Z01iWnBIRFVZUFU4UXRZRUZEbEZLNVZKQVVVYTVjblI5U3lVSWQ4RHVXV05P?= =?utf-8?B?R1JsZmp1WjJxN1lFRWROSjZPTHFOSWEvR0loRkhCVnRub3ZRWFdVVmhHNHJw?= =?utf-8?B?aUJDNGxzSFpwQ0xZQi9US0pYK2Z2Q0hnaDFPRGV4ZU5yUmNOVm9UT2RZWE9Y?= =?utf-8?B?UzdSZ0paSW9scnEyYytlbHpnVEJQakN4MFFWTUJMMFUrTUp5bHdaczBMSnM3?= =?utf-8?B?N09CN3Z5MUpjRytqcHh3M1BlSXZHVmNWUUxyRlpuNEFMbzJOZ0xma0RTOUMx?= =?utf-8?B?dzJlSjhiMzVyR05INVgvSzVIbFBqbU1NT1FBd044cGlWalZmRXhqdGxCbk9J?= =?utf-8?B?VXB1NWhaMHhvbFF4TXhPL1RJYm1QS3Y5ZmlmUHE3SFpEVW1HdDdWUEJXdHZ3?= =?utf-8?B?Um0vVUtJVVFGTTRpQVVURTgxWkZKcGZnWU5ZOXd6a0NyOGhINTEyVVcyeWNE?= =?utf-8?B?RlloOXV2em1uZk9uUlc2KzAvTnN5amxJWFBWcGNQYy9ZK0JXTHFvVlBwcjFx?= =?utf-8?B?bDIzVnh4WUxBaEZlUy9nK2xaOGRBRjMvTFU2U1kzc1JNUUM1RnkyeElDUkZI?= =?utf-8?Q?tUEZFw1tffkGXkgz2EXqx+8=3D?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 1155df6f-5b9a-46cc-b1af-08d9b63dd07b X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2021 09:18:06.2306 (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: 0HZtY90CMlymgl17gCof2GourxGkx1G6KP4+JHw5nOqb67i7IvKnjVoU/PMnUxm6Z4SAe604Sgv+TAd6F3LyeQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4270 Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 09:18:21 -0000 Many thanks to those who attended the meeting (sorry, way too early for me), and to Martin for the proposal below. I could definitely live with this direction, but I have a minor comment below. On 2021-12-03 08:35, Martin Thomson wrote: > The text below attempts to capture a few things that I believe were the result of our discussions earlier today. > > First, that the RSAB has the responsibility and authority to decide how much review is appropriate. They are expected to exercise judgment in how they manage the public comment and review period, this just strengthens that requirement. > > Second, that the RSAB judgment on this matter would benefit from a few guidelines so that things that have been put in place deliberately over the years are not removed without equal care, deliberation, and consultation. > > Third, that this does not fundamentally change the process we apply. We still follow the same basic processes that we've agreed to. However, we highlight the need for additional care so that changes to important things are, as discussed, "very deliberate" and that the consequences of those changes are given due consideration. > > For this, I took Brian's text and tweaked it. The introductory piece here is mostly new, to capture the above points. The detailed points are largely the same, concentrating as they did in Brian's formulation on being factual rather than prescriptive. I have only edited some of these points down slightly to sharpen the focus. > > --- > # Historical Properties of the RFC Series > > The RSAB has a duty to ensure that proposals from the RSWG receive appropriate levels of review. Proposals that, in the opinion of the RSAB, have significant impact on the series require additional outreach and review from a wider community. Additional time should be allowed for collecting feedback for such proposals. > > This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. However, the RSAB should seek broader review for proposals that might have a detrimental affect on these properties. The purpose of review is to ensure that all changes are deliberate and that all of the consequences of a proposal have been carefully considered. I'm a bit wary of "all", in particular in "and that all of the consequences of a proposal have been carefully considered". I think the intent is very clear, but unfortunately, we never can be sure we really are aware of all the possible consequences. So what about something like "and that the consequences of a proposal, as far as they are identifiable, have been carefully considered" or so. > ## Availability > > Documents in the RFC Series have been available for more than 35 years, with no fee for access. > > ## Accessibility > > RFC Series documents have been published in a format that was intended to be as accessible as possible to those with special needs, e.g., for those with impaired sight. > > ## Publication Language > > All existing RFC Series documents have been published in English. Documents have been licensed to explicitly permit translation into other languages. > > ## Content Diversity > > In addition to Internet standards, the RFC series has published procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies. > > ## Document Quality > > RFC Series documents have been edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322]. > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Fri Dec 3 01:41:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 873A93A155C for ; Fri, 3 Dec 2021 01:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=c7cbDUHn; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ej7whu+R Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3L_nyDEJmu6 for ; Fri, 3 Dec 2021 01:40:46 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B1F3A1570 for ; Fri, 3 Dec 2021 01:40:46 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 933AE5C0374; Fri, 3 Dec 2021 04:40:45 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Fri, 03 Dec 2021 04:40:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm3; bh=tKr4k F7PzQETbMHg7nSowMdrtZXSHnA+J6J82azwG5g=; b=c7cbDUHncoWwZZ+PtyXtd mQivI9D41zi8r1n2ilQ7yMXzG8VIf1t8Jjzek12fy3vY6NJTzA/V4aXxbnQHB8gE VYWpSxakF9uPpbJUGfZKV0NVsUBdS1Kt31XyN4ICtaUHOFilKaAHDSwtpsdZmGzY 4FZNYh0Tu4q9VgEhEndU4wZChIIkH708ZIt7oX9HKQBAIUyIOVkyHqA4Q2aRBzgf /gNm8RvNYxobq92F4UVM2JyBDfoaSoy3JMr4FjqgZHSqF709AkklggWu+awvsKlO WneeN3It2Q/2FqBEujA6LEVAA3QQgIo48kU51ogQTetlz6du3WeYyTT977E1YydI A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=tKr4kF7PzQETbMHg7nSowMdrtZXSHnA+J6J82azwG 5g=; b=Ej7whu+RxwbkOPpGnW3sDrOak7U194rM0jmznTcJ7UrWpbzcsrQ0FWh2X 3l7TtTGirhwCuLPFR2C4GWZxLtg9n4n1OCwAZQN1PqAgPSHLptRvlQJoB9DcEQk7 vi2ARtkNHWw7h3pZgPg45F5BwkvgOd/ezr7qNxNmAkbmsL/srsDRM7kCRP69ztif gYcLPvjKDiWzMZZuuYJO5okaVuFJUXZf2TiqgG46Cwz6dKa+I3A8SqvF3wjb7Mmx VId8Iim0kp/EyytS92ckDzQWRp9x26OjHCG9waMTOjSkIbEq55Ek1LUkZEfp46yV 1h9BVXBdCEi4UvQaPb87ypWvnfuhw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrieejgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefftefgvedvhfdtffehje dufefhhfevhedufefhgfelleetieefgeefgffgleehgfenucffohhmrghinhepihgvthhf rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CBB4A3C0C77; Fri, 3 Dec 2021 04:40:44 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4458-g51a91c06b2-fm-20211130.004-g51a91c06 Mime-Version: 1.0 Message-Id: <1f290d0f-198b-4056-82f7-062eb5fd6a9b@www.fastmail.com> In-Reply-To: <32294a20-86f7-9198-c4d0-653a0ef92439@it.aoyama.ac.jp> References: <32294a20-86f7-9198-c4d0-653a0ef92439@it.aoyama.ac.jp> Date: Fri, 03 Dec 2021 20:40:25 +1100 From: "Martin Thomson" To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 09:40:59 -0000 On Fri, Dec 3, 2021, at 20:18, Martin J. D=C3=BCrst wrote: > So what about something like > "and that the consequences of a=20 > proposal,=C2=A0as=C2=A0far=C2=A0as=C2=A0they=C2=A0are=C2=A0identifiabl= e, have been carefully=20 > considered" or so. That's a reasonable amendment. Thanks. I'm maintaining the text here: https://notes.ietf.org/BrrKxlvGRrOKVdNFjC= Uung?view in case you want to follow along. From nobody Fri Dec 3 01:52:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728EA3A0D71 for ; Fri, 3 Dec 2021 01:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqh6RMiOALFj for ; Fri, 3 Dec 2021 01:52:09 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 C2F6A3A0D74 for ; Fri, 3 Dec 2021 01:52:08 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B39q4Vs026549 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 3 Dec 2021 10:52:05 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638525125; bh=flbmBeLD0qpCGUQ1BpGIQk4wD0jpwNfxLxxXFeWEJ8o=; h=Date:Subject:To:References:From:In-Reply-To:From; b=uC7VEWR+bLQQ8J6kvZuo/jPyWM/K/s/7m7dwoO69wLG8d87Ebs74LuVN2p5uOkFYO H4qRcVjmltrTd3hSbxbYzvlbnjjXzJJR9Vz2EHdHHCd6Ql/dgR5VGm5Rm/KDwtmGi5 +hO8lFydW2jVevz0jct2ahOiNJGoJ908jbuEWAjM= Message-ID: Date: Fri, 3 Dec 2021 10:52:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Martin Thomson , rfced-future@iab.org References: <32294a20-86f7-9198-c4d0-653a0ef92439@it.aoyama.ac.jp> <1f290d0f-198b-4056-82f7-062eb5fd6a9b@www.fastmail.com> From: Eliot Lear In-Reply-To: <1f290d0f-198b-4056-82f7-062eb5fd6a9b@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------G0p0scgs57DL6hpm5zdes0bX" Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 09:52:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------G0p0scgs57DL6hpm5zdes0bX Content-Type: multipart/mixed; boundary="------------0D3zylr5QIKTtAOId1q9Pa3O"; protected-headers="v1" From: Eliot Lear To: Martin Thomson , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Proposed "Historical Properties" References: <32294a20-86f7-9198-c4d0-653a0ef92439@it.aoyama.ac.jp> <1f290d0f-198b-4056-82f7-062eb5fd6a9b@www.fastmail.com> In-Reply-To: <1f290d0f-198b-4056-82f7-062eb5fd6a9b@www.fastmail.com> --------------0D3zylr5QIKTtAOId1q9Pa3O Content-Type: multipart/mixed; boundary="------------q0oSBj72gCog2F7UySswz7QJ" --------------q0oSBj72gCog2F7UySswz7QJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgTWFydGluIFQsIGFuZCB0aGFua3MgZm9yIHRoaXMsIGFuZCB0aGFua3MgTWFydGluIEQg Zm9yIHlvdXIgY29tbWVudHMuDQoNCkNhbiBldmVyeW9uZSBjb21tZW50IG9uIE1hcnRpbidz IHRleHQ/DQoNCkVsaW90DQoNCk9uIDAzLjEyLjIxIDEwOjQwLCBNYXJ0aW4gVGhvbXNvbiB3 cm90ZToNCj4gT24gRnJpLCBEZWMgMywgMjAyMSwgYXQgMjA6MTgsIE1hcnRpbiBKLiBEw7xy c3Qgd3JvdGU6DQo+PiBTbyB3aGF0IGFib3V0IHNvbWV0aGluZyBsaWtlDQo+PiAiYW5kIHRo YXQgdGhlIGNvbnNlcXVlbmNlcyBvZiBhDQo+PiBwcm9wb3NhbCzCoGFzwqBmYXLCoGFzwqB0 aGV5wqBhcmXCoGlkZW50aWZpYWJsZSwgaGF2ZSBiZWVuIGNhcmVmdWxseQ0KPj4gY29uc2lk ZXJlZCIgb3Igc28uDQo+IFRoYXQncyBhIHJlYXNvbmFibGUgYW1lbmRtZW50LiAgVGhhbmtz Lg0KPg0KPiBJJ20gbWFpbnRhaW5pbmcgdGhlIHRleHQgaGVyZTogaHR0cHM6Ly9ub3Rlcy5p ZXRmLm9yZy9CcnJLeGx2R1JyT0tWZE5GakNVdW5nP3ZpZXcgaW4gY2FzZSB5b3Ugd2FudCB0 byBmb2xsb3cgYWxvbmcuDQo+DQo= --------------q0oSBj72gCog2F7UySswz7QJ Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------q0oSBj72gCog2F7UySswz7QJ-- --------------0D3zylr5QIKTtAOId1q9Pa3O-- --------------G0p0scgs57DL6hpm5zdes0bX Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGp6MEFAwAAAAAACgkQh7ZrRtnSejM8 rAgAjqF80FN+dMngjvgc3WPbwO4xcyDnliWW1uuV2eTwBDE2I63PPrI0M3MbOvwJ0Lr8v+BypMeE BLw7sidGutWati/J4C7GCgd8PR9NxBx5WD/nYjfsyQ0z5WrGes/nHdrgwrJ2q/qG/Dx0puX1FyKz 6XA+/oOgkq5rOFIffG9kHuoF0XMac5L/RCei2xmAu8KPFR0LVdUtlJIygunjCTqr504yz2PWIKBk Rz7kfMG5D4KRiUtIRxL8zM2E4sJ4Ai2XEe/PuIKx7cpiGDqPCZ+Qprc2FG7kBUVMkMvyKzKuSjMG 2zotN+KHQBpl7qFBWiREFMw4GTdn2G+e6Vg2EiF5Eg== =dzKq -----END PGP SIGNATURE----- --------------G0p0scgs57DL6hpm5zdes0bX-- From nobody Fri Dec 3 03:06:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351203A0787 for ; Fri, 3 Dec 2021 03:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XeL1N0zqzu29 for ; Fri, 3 Dec 2021 03:06:35 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [IPv6:2001:638:708:32::15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82FED3A078D for ; Fri, 3 Dec 2021 03:06:35 -0800 (PST) Received: from [192.168.217.118] (p5089a436.dip0.t-ipconnect.de [80.137.164.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4J594Q4hfXzDCgJ; Fri, 3 Dec 2021 12:06:30 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Fri, 3 Dec 2021 12:06:30 +0100 Cc: rfced-future@iab.org X-Mao-Original-Outgoing-Id: 660222390.337342-bae2cf87a2d53b71303dccbbcca0b568 Content-Transfer-Encoding: quoted-printable Message-Id: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> References: To: Martin Thomson X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 11:06:40 -0000 On 2021-12-03, at 00:35, Martin Thomson wrote: >=20 > ## Document Quality >=20 > RFC Series documents have been edited by professionals with a goal of = ensuring that documents are clear, consistent, and readable [RFC7322]. I don=E2=80=99t have a chance to follow the stream of comments here. I believe I have attempted to point out that the objectives for this and = other aspects of professionalism in handling the RFC series went = significantly beyond that. = https://mailarchive.ietf.org/arch/msg/rfced-future/rE0swA9xR6FZ9Th9X8J8Uap= uLJo/ = https://mailarchive.ietf.org/arch/msg/rfced-future/3EmXWQwKufE2MM5hFY4k-ID= LoHw/ Gr=C3=BC=C3=9Fe, Carsten From nobody Fri Dec 3 04:16:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04003A08A1 for ; Fri, 3 Dec 2021 04:16:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7X3uvQJ9jSLo for ; Fri, 3 Dec 2021 04:16:31 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 791CA3A089F for ; Fri, 3 Dec 2021 04:16:31 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::1] ([IPv6:2001:420:c0c0:1011:0:0:0:1]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B3CGRgr097383 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 3 Dec 2021 13:16:28 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638533788; bh=+CKf43RwDhfAYExuSSxB/cQjhx95Ofa4EawQ7/NyOJE=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=I3Iv4dSAgpSMg8c4d2OLYnq+QoAikpWM3oEJc6hndOm2q0KRBogyQ1K7o6oriS+Xj FqHbLFWPA6SlQmGSyjv3rJ2bcFLiQKS1EJI46R4o2TOB19oZeW180mXK/67JZc0cTR 8eDRG0lnog0afj4SbOX/vGYtkuh1UqpODN+3UP5g= Message-ID: Date: Fri, 3 Dec 2021 13:16:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Carsten Bormann , Martin Thomson Cc: rfced-future@iab.org References: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> From: Eliot Lear In-Reply-To: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------OYpniYYof8rDCPal9FXnKcWI" Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 12:16:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------OYpniYYof8rDCPal9FXnKcWI Content-Type: multipart/mixed; boundary="------------XUwGAcFOxBqMy9j46U0DH91e"; protected-headers="v1" From: Eliot Lear To: Carsten Bormann , Martin Thomson Cc: rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Proposed "Historical Properties" References: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> In-Reply-To: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> --------------XUwGAcFOxBqMy9j46U0DH91e Content-Type: multipart/mixed; boundary="------------3tJ2dg9lsCG0kRK8zMUsJXYP" --------------3tJ2dg9lsCG0kRK8zMUsJXYP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Q2Fyc3RlbiwNCg0KSSBjb3VsZCBpbnRlcnByZXQgeW91ciBwb2ludCB0byBiZSBvbmUgY2hh bmdlIGFuZCBvbmUgYWRkOg0KDQojIyBEb2N1bWVudCBRdWFsaXR5DQoNClJGQyBTZXJpZXMg ZG9jdW1lbnRzIGhhdmUgdW5kZXJnb25lIHJldmlldyBmb3Igc3ViamVjdCBtYXR0ZXIgcXVh bGl0eSBhbmQgaGF2ZSBiZWVuIGVkaXRlZCBieSBwcm9mZXNzaW9uYWxzIHdpdGggYSBnb2Fs IG9mIGVuc3VyaW5nIHRoYXQgZG9jdW1lbnRzIGFyZSBjbGVhciwgY29uc2lzdGVudCwgYW5k IHJlYWRhYmxlIFtSRkM3MzIyXS4NCg0KIyMgU3RhYmxlIFJlZmVyZW5jZXMNCg0KT25jZSBp c3N1ZWQsIGFuIHRoZSB0ZXh0IG9mIGFuIFJGQyB3b3VsZCByZW1haW4gdW5jaGFuZ2VkLCBz byB0aGF0IGFueW9uZSBpbXBsZW1lbnRpbmcgYSBwYXJ0aWN1bGFyIFJGQyBjb3JyZWN0bHkg Y291bGQgZW5qb3kgY29uc2lzdGVudCBhbmQgaW50ZXJvcGVyYWJsZSBiZWhhdmlvciwgYW5k IHRoYXQgdGhlIFJGQyBjb3VsZCBiZSBwcm9wZXJseSByZWZlcmVuY2VkIGluIGxpdGVyYXR1 cmUuDQoNCj8/DQoNCkVsaW90DQoNCk9uIDAzLjEyLjIxIDEyOjA2LCBDYXJzdGVuIEJvcm1h bm4gd3JvdGU6DQoNCj4NCj4gSSBkb27igJl0IGhhdmUgYSBjaGFuY2UgdG8gZm9sbG93IHRo ZSBzdHJlYW0gb2YgY29tbWVudHMgaGVyZS4NCj4NCj4gSSBiZWxpZXZlIEkgaGF2ZSBhdHRl bXB0ZWQgdG8gcG9pbnQgb3V0IHRoYXQgdGhlIG9iamVjdGl2ZXMgZm9yIHRoaXMgYW5kIG90 aGVyIGFzcGVjdHMgb2YgcHJvZmVzc2lvbmFsaXNtIGluIGhhbmRsaW5nIHRoZSBSRkMgc2Vy aWVzIHdlbnQgc2lnbmlmaWNhbnRseSBiZXlvbmQgdGhhdC4NCj4NCj4gaHR0cHM6Ly9tYWls YXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9yZmNlZC1mdXR1cmUvckUwc3dBOXhSNkZaOVRo OVg4SjhVYXB1TEpvLw0KPiBodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3JmY2VkLWZ1dHVyZS8zRW1YV1F3S3VmRTJNTTVoRlk0ay1JRExvSHcvDQo+DQo+IEdyw7zD n2UsIENhcnN0ZW4NCj4NCg== --------------3tJ2dg9lsCG0kRK8zMUsJXYP Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------3tJ2dg9lsCG0kRK8zMUsJXYP-- --------------XUwGAcFOxBqMy9j46U0DH91e-- --------------OYpniYYof8rDCPal9FXnKcWI Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGqCpoFAwAAAAAACgkQh7ZrRtnSejNK YggAyxTVfukZMu/xJDA1aKenbxrw2zXsQyqjJbJ1koiXW/wmzgjOxDzGd9P616t9vuxfdzjpww1E iAyI1/fVeWDshbBFyo6TKtk2XR03KLYIY4ucKjmn3l0daN+iMWjvn5os4sZQALHz99wYmUE5R5mx nbrhNDEozqGw3i1KAgvoTCmGQl1aGuaS+BZVAzRUYs/tlC+nc4UsuABtKOxO4ED79kaqKS0YRYav YQUPreakn3cuGRGccVD3ZCidzcbcXdQyTA6/SU5q0SGQzEBeXoB6hvI5XFWCGFmUiIKCdoTUnxFR GWnhf4rjwkV8cCW7/PzNG6wDrmooUhUJssxXmspqkA== =tQ1t -----END PGP SIGNATURE----- --------------OYpniYYof8rDCPal9FXnKcWI-- From nobody Fri Dec 3 06:06:11 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7BA3A09EC for ; Fri, 3 Dec 2021 06:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CZzO2vp987nc for ; Fri, 3 Dec 2021 06:06:04 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05C5A3A09EE for ; Fri, 3 Dec 2021 06:06:03 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 1B3ChW1u021192; Fri, 3 Dec 2021 14:06:01 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ZcYC5xNby2/hK4Eh+bFYBdZ7y86YssFkDtvKB7Sh+cU=; b=jF93P8oXl/pKglbsvSv0fKVmKH0SHPjkeRI6UGGRTP19gDghN+K/ZigQpIwO51vX6WkW b9JNPchEURDSTRwb39KHiVMGVj6sjnWEIFTwuc+IP/YuMqwzSKxGvDQPzkXn8htNwjiy NUeO9CkjGy4a8qcvvsVEARjgxE0yfUp+MBVYq430R64YAmJdE3nBPAfI0Ir7JXlrSmO+ vCLcFqmXymF+o6CDxaG3ZJgWmhWTMfyJI7K7k8hk9+6QZRGE51+cTPlAsnKa/XMhSZKQ icXP7I7GTyvibQTf8GUIB6GplNKv0n8KnuXQki6eaEdVzEa40EKUI0ry5BgEQAh2PJeV XQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com (PPS) with ESMTPS id 3cq4smgf9x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 Dec 2021 14:06:01 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 1B3Dq1nx032542; Fri, 3 Dec 2021 09:05:59 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 3cp56audxr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 03 Dec 2021 09:05:59 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Fri, 3 Dec 2021 09:05:59 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.026; Fri, 3 Dec 2021 09:05:59 -0500 From: "Salz, Rich" To: Martin Thomson , "rfced-future@iab.org" Thread-Topic: [Rfced-future] Proposed "Historical Properties" Thread-Index: AQHX59WB+MSZZagLaECdQkFR+n3QVqwg0YAAgAAGP4D///ZfgA== Date: Fri, 3 Dec 2021 14:05:58 +0000 Message-ID: <37FEE953-4960-4140-A9D5-FA11F6C67A91@akamai.com> References: <32294a20-86f7-9198-c4d0-653a0ef92439@it.aoyama.ac.jp> <1f290d0f-198b-4056-82f7-062eb5fd6a9b@www.fastmail.com> In-Reply-To: <1f290d0f-198b-4056-82f7-062eb5fd6a9b@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.55.21111400 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-03_07:2021-12-02, 2021-12-03 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 spamscore=0 phishscore=0 mlxlogscore=999 adultscore=0 mlxscore=0 malwarescore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112030084 X-Proofpoint-GUID: mfl_OBkmr5l_YxRjs4Pe-SA_jOliV3sV X-Proofpoint-ORIG-GUID: mfl_OBkmr5l_YxRjs4Pe-SA_jOliV3sV X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-03_07,2021-12-02_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 impostorscore=0 suspectscore=0 phishscore=0 mlxlogscore=999 mlxscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112030088 Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 14:06:10 -0000 Q2FuIHlvdSBtYWtlIEF2YWlsYWJpbGl0eSwgQWNjZXNzaWJpbGl0eSwgZXRjLiwgYXMgYnVsbGV0 cz8gIEEgc2VyaWVzIG9mIG9uZS1zZW50ZW5jZSBzZWN0aW9ucyBpcyBqYXJyaW5nLCBhbmQgSSB0 aGluayB0aGUgKnNsaWdodCogZGUtZW1waGFzaXMgYnkgbW92aW5nIHRvIGJ1bGxldHMgaXMgZ29v ZC4gQW5kIGNoYW5nZSB0aGUgaW50cm8gb2YgdGhlIHNlY29uZCBwYXJhZ3JhcGggdG8NCg0KCVRo ZSBsaXN0IGJlbG93IGlkZW50aWZpZXMsIGluIG5vIHBhcnRpY3VsYXIgb3JkZXIsIHNvbWUgb2Yg dGhlIHByb3BlcnRpZXMgLi4uDQoNCkZvciBwYXJhbGxlbCBzdHJ1Y3R1cmUsIEknZCBhbHNvIGxp a2UgdG8gc2VlICJMYW5ndWFnZSIgYW5kICJEaXZlcnNpdHkiIGFzIG9uZS13b3JkIGl0ZW1zLiBB bmQgdW5kZXIgTGFuZ3VhZ2UsIHMvaGF2ZSBiZWVuIGxpY2Vuc2VkL2FyZSBsaWNlbnNlZC8NCg0K VGhlc2UgYXJlIG5pdHMNCg0KDQoNCg== From nobody Fri Dec 3 10:58:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE3C3A0115 for ; Fri, 3 Dec 2021 10:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.741 X-Spam-Level: X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=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 Q03NnX8GXB9N for ; Fri, 3 Dec 2021 10:58:10 -0800 (PST) Received: from mx36-out20.antispamcloud.com (mx36-out20.antispamcloud.com [209.126.121.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2C273A00E1 for ; Fri, 3 Dec 2021 10:58:10 -0800 (PST) Received: from xse437.mail2web.com ([66.113.197.183] helo=xse.mail2web.com) by mx135.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1mtDl2-000Bnn-08 for rfced-future@iab.org; Fri, 03 Dec 2021 19:58:08 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4J5MXY62cQz9cj for ; Fri, 3 Dec 2021 10:58:05 -0800 (PST) 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 1mtDkz-0004a7-OS for rfced-future@iab.org; Fri, 03 Dec 2021 10:58:05 -0800 Received: (qmail 16734 invoked from network); 3 Dec 2021 18:58:05 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.58.46.129]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 3 Dec 2021 18:58:04 -0000 Message-ID: Date: Fri, 3 Dec 2021 10:58:03 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , Carsten Bormann , Martin Thomson Cc: rfced-future@iab.org References: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> From: Christian Huitema In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: 66.113.197.183 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KuJ4 rsjpbAhLNOVgSkZNngmCn3oZFShGuGVczvnnMQuySxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVNeJTN7DFlYFLtIwbcoJsupotTbzF8bFslzcWfB/84WVsvCwp YJpdb4B2L4Z5wQyKkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dgGI409Uexq5zP1TE60A1w6w IXCZNotm9naBveb6UalYb3UQT3xbkHqpqmyCe4PiKVv0wNAmy0z4NCWU5AbBg6tDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAllhE9tpzISNSoFwkFXAfXCK3h1ESmlc3/lS5x7qxkdla3rc/ 2CkWu7w7mVMnIIqHqgZbR4w0YnkkrhpfcUsmX99RXxKF5tPxTxfD0dMN+t5ZNLyX4ibBeuNtAq18 NcAsFxxHx5OlXOwSpUqAHfd6HCyN9/YGRrhMRGhIOTxMW00yF8F1u0YDQf8cLP9taeSLFY0fPBnF 89BphpBNlUg+TzHwBTL1+6vDOMemz/4I88NDcmnEJ4r7C+SwLRamrhQTd3PrpJpP5ewAjeqkzRNl ucyd+NO2McmveAr4ch9F7rE89jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:58:16 -0000 On 12/3/2021 4:16 AM, Eliot Lear wrote: > Carsten, > > I could interpret your point to be one change and one add: > > ## Document Quality > > RFC Series documents have undergone review for subject matter quality > and have been edited by professionals with a goal of ensuring that > documents are clear, consistent, and readable [RFC7322]. > > ## Stable References > > Once issued, an the text of an RFC would remain unchanged, so that > anyone implementing a particular RFC correctly could enjoy consistent > and interoperable behavior, and that the RFC could be properly > referenced in literature. That particular sentence is mixing a fact and a hope. The fact, indeed the historical property, is that once issued the text of an RFC remains unchanged and the RFC could be properly referenced in literature. The hope is that this leads to compatible implementations, but I would certainly not call that a historical property. For many of our most popular protocols, including TCP or DNS, implementing the nominal RFC does not result in implementations compatible with current deployments. -- Christian Huitema From nobody Fri Dec 3 11:52:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC32F3A07F3 for ; Fri, 3 Dec 2021 11:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 U-OWHDZayD5h for ; Fri, 3 Dec 2021 11:52:35 -0800 (PST) Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B4CF3A07F2 for ; Fri, 3 Dec 2021 11:52:35 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id b187so5140810iof.11 for ; Fri, 03 Dec 2021 11:52:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4i+kkVgFu0Rcn9vJ0BlvwbHXRKm6MWlB0rQhDd1ubLE=; b=eVnamPJNpjtU74YizuYKIw9oTkpEhHjQukkA39q7vU07zcBNpIFum+q0OzNZem4NgW EhrtByAbBUTaDdtoFUjgJUodtQUDk20XESt66KPKH78J/dUIcgG3scBeVgwn2txKUSJy e0q+9IE4esF6XeA5cCjdGJrhK/XuvJ+rGqpWYOV61DZVxBZPi4BxlXeyoNzuzSaQrlAw vOTU3pTyTbWIuVtP5TlKn2cAYn/sboLAUcsaEsDXDwD62oWBobetQrgig2Rn8YNmi3v+ beKBvzfjOWdWni93hObZbuTt0YHFg1uxPcepzf2u8MLPhmz4uKH/Rn2SwdXYf2xeGZHJ NV4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4i+kkVgFu0Rcn9vJ0BlvwbHXRKm6MWlB0rQhDd1ubLE=; b=oWN5M6+d8wYjKmXIUc9/1K2O/Wx/n9J4wOM+ZGl4kx4AQ11QGErZMvxptnWsPSUyI7 eBuwjHeKnVNqkWR4YbuULlrdDFLfp7/uVSWsvKnObd/9OAcmrLdZ6RYLnjdJ0Ureqxu6 LDzednjhg/nTMEa1zhIn6DMfBoVD9OJ71bUTUxKa53TjyeHlZJ4xMp7FqyNUO2Jj5SUs kgBiqgcVZCa4c3rLeSzzkv7p3/ntObqZ14wixMtVgKhI7Dgdq37WxhvV/SO4QDDKwYV9 bPHAObu8YpDDEnklINH36kJofv7oVTNFNlcjsnvzWmOQhsreAD5oKiRfouJ+5BglWWpV jRXA== X-Gm-Message-State: AOAM533XNveh8KROXIyH3bzxcwiq/OqzbiLnb61uQCYtwtpAU3bTDUAo Dz9uVe2SRaeju5Q/1NVspFZ7qxu7rVfrIePehGvCmA== X-Google-Smtp-Source: ABdhPJyXIo5vP7UTGsCAUE+kp1QHJsi5zE5ttoBB2Z7UnBQc2/j8eQtpFEvJEITjYt8m8fdlQH5xsC6f/gFpwCVIFP0= X-Received: by 2002:a6b:b4cc:: with SMTP id d195mr21487167iof.0.1638561153643; Fri, 03 Dec 2021 11:52:33 -0800 (PST) MIME-Version: 1.0 References: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> In-Reply-To: From: Eric Rescorla Date: Fri, 3 Dec 2021 11:51:57 -0800 Message-ID: To: Christian Huitema Cc: Eliot Lear , Carsten Bormann , Martin Thomson , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000818e6205d2433fab" Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:52:40 -0000 --000000000000818e6205d2433fab Content-Type: text/plain; charset="UTF-8" Perhaps just stop after "unchanged"? That seems factual. On Fri, Dec 3, 2021 at 10:58 AM Christian Huitema wrote: > > On 12/3/2021 4:16 AM, Eliot Lear wrote: > > Carsten, > > > > I could interpret your point to be one change and one add: > > > > ## Document Quality > > > > RFC Series documents have undergone review for subject matter quality > > and have been edited by professionals with a goal of ensuring that > > documents are clear, consistent, and readable [RFC7322]. > > > > ## Stable References > > > > Once issued, an the text of an RFC would remain unchanged, so that > > anyone implementing a particular RFC correctly could enjoy consistent > > and interoperable behavior, and that the RFC could be properly > > referenced in literature. > > > That particular sentence is mixing a fact and a hope. The fact, indeed > the historical property, is that once issued the text of an RFC remains > unchanged and the RFC could be properly referenced in literature. The > hope is that this leads to compatible implementations, but I would > certainly not call that a historical property. For many of our most > popular protocols, including TCP or DNS, implementing the nominal RFC > does not result in implementations compatible with current deployments. > > -- Christian Huitema > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000818e6205d2433fab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Perhaps just stop after "unchanged"? That seems = factual.

On Fri, Dec 3, 2021 at 10:58 AM Christian Huitema <huitema@huitema.net> wrote:

On 12/3/2021 4:16 AM, Eliot Lear wrote:
> Carsten,
>
> I could interpret your point to be one change and one add:
>
> ## Document Quality
>
> RFC Series documents have undergone review for subject matter quality =
> and have been edited by professionals with a goal of ensuring that > documents are clear, consistent, and readable [RFC7322].
>
> ## Stable References
>
> Once issued, an the text of an RFC would remain unchanged, so that > anyone implementing a particular RFC correctly could enjoy consistent =
> and interoperable behavior, and that the RFC could be properly
> referenced in literature.


That particular sentence is mixing a fact and a hope. The fact, indeed
the historical property, is that once issued the text of an RFC remains unchanged and the RFC could be properly referenced in literature. The
hope is that this leads to compatible implementations, but I would
certainly not call that a historical property. For many of our most
popular protocols, including TCP or DNS, implementing the nominal RFC
does not result in implementations compatible with current deployments.

-- Christian Huitema

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000818e6205d2433fab-- From nobody Fri Dec 3 13:03:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083243A0966 for ; Fri, 3 Dec 2021 13:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MF_PyxouZuLN for ; Fri, 3 Dec 2021 13:03:30 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 1B8463A0965 for ; Fri, 3 Dec 2021 13:03:29 -0800 (PST) Received: from [192.168.0.132] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B3L3I0h353699 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 3 Dec 2021 22:03:19 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638565400; bh=j3Nj8DbxJdXdgx8T27IwZDgZVkGC2eKsVGd/125k4o8=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=JFoZMe2Zf/4+oJyB4VflFJM4Y23vnsnXkgRSFFGFqe0l8GA5JuKOeVDlmbdboYCfL 1CwJYMzt5tXDyoXSJWgDLVn7uESwt2blADwjQeqEeLd+VHZ1TROk9Wmsx8F85HkzCh yehhOVrG6wpUcpcPWCAg3MOivqnSHJS0C9yR9peg= Message-ID: <98fc39ce-b947-f0fb-9a54-05400603decc@lear.ch> Date: Fri, 3 Dec 2021 22:03:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Eric Rescorla , Christian Huitema Cc: Carsten Bormann , Martin Thomson , rfced-future@iab.org References: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> From: Eliot Lear In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6h9Z0AV3qwblO0bodFfbElHb" Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:03:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6h9Z0AV3qwblO0bodFfbElHb Content-Type: multipart/mixed; boundary="------------Ci1y0VF03z1A7IaHLHCC10Be"; protected-headers="v1" From: Eliot Lear To: Eric Rescorla , Christian Huitema Cc: Carsten Bormann , Martin Thomson , rfced-future@iab.org Message-ID: <98fc39ce-b947-f0fb-9a54-05400603decc@lear.ch> Subject: Re: [Rfced-future] Proposed "Historical Properties" References: <4B179B56-D3B3-4E3A-9C45-93C993FCF9FD@tzi.org> In-Reply-To: --------------Ci1y0VF03z1A7IaHLHCC10Be Content-Type: multipart/mixed; boundary="------------TLstRSNGbTrL1A02lK7eSKJt" --------------TLstRSNGbTrL1A02lK7eSKJt Content-Type: multipart/alternative; boundary="------------XOrsRR00A6aJVUcyB3xiK2wI" --------------XOrsRR00A6aJVUcyB3xiK2wI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QW55dGhpbmcgaXMgb2sgd2l0aCBtZS4gQ2hyaXN0aWFuJ3MgcmlnaHQtIGl0J3MuLi4gYXNw aXJhdGlvbmFsIGF0IGJlc3QuDQoNCk9uIDAzLjEyLjIxIDIwOjUxLCBFcmljIFJlc2Nvcmxh IHdyb3RlOg0KPiBQZXJoYXBzIGp1c3Qgc3RvcCBhZnRlciAidW5jaGFuZ2VkIj8gVGhhdCBz ZWVtcyBmYWN0dWFsLg0KPg0KPiBPbiBGcmksIERlYyAzLCAyMDIxIGF0IDEwOjU4IEFNIENo cmlzdGlhbiBIdWl0ZW1hIA0KPiA8aHVpdGVtYUBodWl0ZW1hLm5ldD4gd3JvdGU6DQo+DQo+ DQo+ICAgICBPbiAxMi8zLzIwMjEgNDoxNiBBTSwgRWxpb3QgTGVhciB3cm90ZToNCj4gICAg ID4gQ2Fyc3RlbiwNCj4gICAgID4NCj4gICAgID4gSSBjb3VsZCBpbnRlcnByZXQgeW91ciBw b2ludCB0byBiZSBvbmUgY2hhbmdlIGFuZCBvbmUgYWRkOg0KPiAgICAgPg0KPiAgICAgPiAj IyBEb2N1bWVudCBRdWFsaXR5DQo+ICAgICA+DQo+ICAgICA+IFJGQyBTZXJpZXMgZG9jdW1l bnRzIGhhdmUgdW5kZXJnb25lIHJldmlldyBmb3Igc3ViamVjdCBtYXR0ZXINCj4gICAgIHF1 YWxpdHkNCj4gICAgID4gYW5kIGhhdmUgYmVlbiBlZGl0ZWQgYnkgcHJvZmVzc2lvbmFscyB3 aXRoIGEgZ29hbCBvZiBlbnN1cmluZyB0aGF0DQo+ICAgICA+IGRvY3VtZW50cyBhcmUgY2xl YXIsIGNvbnNpc3RlbnQsIGFuZCByZWFkYWJsZSBbUkZDNzMyMl0uDQo+ICAgICA+DQo+ICAg ICA+ICMjIFN0YWJsZSBSZWZlcmVuY2VzDQo+ICAgICA+DQo+ICAgICA+IE9uY2UgaXNzdWVk LCBhbiB0aGUgdGV4dCBvZiBhbiBSRkMgd291bGQgcmVtYWluIHVuY2hhbmdlZCwgc28gdGhh dA0KPiAgICAgPiBhbnlvbmUgaW1wbGVtZW50aW5nIGEgcGFydGljdWxhciBSRkMgY29ycmVj dGx5IGNvdWxkIGVuam95DQo+ICAgICBjb25zaXN0ZW50DQo+ICAgICA+IGFuZCBpbnRlcm9w ZXJhYmxlIGJlaGF2aW9yLCBhbmQgdGhhdCB0aGUgUkZDIGNvdWxkIGJlIHByb3Blcmx5DQo+ ICAgICA+IHJlZmVyZW5jZWQgaW4gbGl0ZXJhdHVyZS4NCj4NCj4NCj4gICAgIFRoYXQgcGFy dGljdWxhciBzZW50ZW5jZSBpcyBtaXhpbmcgYSBmYWN0IGFuZCBhIGhvcGUuIFRoZSBmYWN0 LA0KPiAgICAgaW5kZWVkDQo+ICAgICB0aGUgaGlzdG9yaWNhbCBwcm9wZXJ0eSwgaXMgdGhh dCBvbmNlIGlzc3VlZCB0aGUgdGV4dCBvZiBhbiBSRkMNCj4gICAgIHJlbWFpbnMNCj4gICAg IHVuY2hhbmdlZCBhbmQgdGhlIFJGQyBjb3VsZCBiZSBwcm9wZXJseSByZWZlcmVuY2VkIGlu IGxpdGVyYXR1cmUuIFRoZQ0KPiAgICAgaG9wZSBpcyB0aGF0IHRoaXMgbGVhZHMgdG8gY29t cGF0aWJsZSBpbXBsZW1lbnRhdGlvbnMsIGJ1dCBJIHdvdWxkDQo+ICAgICBjZXJ0YWlubHkg bm90IGNhbGwgdGhhdCBhIGhpc3RvcmljYWwgcHJvcGVydHkuIEZvciBtYW55IG9mIG91ciBt b3N0DQo+ICAgICBwb3B1bGFyIHByb3RvY29scywgaW5jbHVkaW5nIFRDUCBvciBETlMsIGlt cGxlbWVudGluZyB0aGUgbm9taW5hbCBSRkMNCj4gICAgIGRvZXMgbm90IHJlc3VsdCBpbiBp bXBsZW1lbnRhdGlvbnMgY29tcGF0aWJsZSB3aXRoIGN1cnJlbnQNCj4gICAgIGRlcGxveW1l bnRzLg0KPg0KPiAgICAgLS0gQ2hyaXN0aWFuIEh1aXRlbWENCj4NCj4gICAgIC0tIA0KPiAg ICAgUmZjZWQtZnV0dXJlIG1haWxpbmcgbGlzdA0KPiAgICAgUmZjZWQtZnV0dXJlQGlhYi5v cmcNCj4gICAgIGh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmNlZC1m dXR1cmUNCj4NCg== --------------XOrsRR00A6aJVUcyB3xiK2wI Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Anything is ok with me. Christian's right- it's... aspirational at best.

On 03.12.21 20:51, Eric Rescorla wrote= :
Perhaps just stop after "unchanged"? That seems factual.

On Fri, Dec 3, 2021 at 10:5= 8 AM Christian Huitema <huit= ema@huitema.net> wrote:
=
On 12/3/2021 4:16 AM, Eliot Lear wrote:
> Carsten,
>
> I could interpret your point to be one change and one add:
>
> ## Document Quality
>
> RFC Series documents have undergone review for subject matter quality
> and have been edited by professionals with a goal of ensuring that
> documents are clear, consistent, and readable [RFC7322]. >
> ## Stable References
>
> Once issued, an the text of an RFC would remain unchanged, so that
> anyone implementing a particular RFC correctly could enjoy consistent
> and interoperable behavior, and that the RFC could be properly
> referenced in literature.


That particular sentence is mixing a fact and a hope. The fact, indeed
the historical property, is that once issued the text of an RFC remains
unchanged and the RFC could be properly referenced in literature. The
hope is that this leads to compatible implementations, but I would
certainly not call that a historical property. For many of our most
popular protocols, including TCP or DNS, implementing the nominal RFC
does not result in implementations compatible with current deployments.

-- Christian Huitema

--
Rfced-future mailing list
Rfce= d-future@iab.org
https://www.iab.org/mailman/l= istinfo/rfced-future
--------------XOrsRR00A6aJVUcyB3xiK2wI-- --------------TLstRSNGbTrL1A02lK7eSKJt Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------TLstRSNGbTrL1A02lK7eSKJt-- --------------Ci1y0VF03z1A7IaHLHCC10Be-- --------------6h9Z0AV3qwblO0bodFfbElHb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGqhhUFAwAAAAAACgkQh7ZrRtnSejMk Qgf/aL+YU2zAT/kR5ojZCgS1qLlhiXnSDZtlfRvT7xcZQ5J2wPs4k76oIU2yyeAD41LbDO9VYBwe x8UcG7r5Dkrf14Jj+Fm9DJQph8T8oVvojI2hrJfO7chMHlLZzVfCRKpnc9lARYKKjlcCiYT9ocSX CqGW2ecgj0XwBGGKVVrpOCZUA/NYKTSJsy6EjkxYIhl5remrrrRG8rtMc5X19xnPf1/En3/AK1OX m6oyoK/z1v+R3LecppkHFWCXKGD/G1+q+yhpi7upcaQUXBSkYo9JfJLxijRQyO8H2zNH1B8wtFoL SbiwByVEPbsTQe/6xZBTi3/qEIKuBRHcZj1LNwvPRA== =UYcf -----END PGP SIGNATURE----- --------------6h9Z0AV3qwblO0bodFfbElHb-- From nobody Fri Dec 3 13:09:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4633A0988 for ; Fri, 3 Dec 2021 13:09:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 b85ix3v7zw_0 for ; Fri, 3 Dec 2021 13:09:08 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2117.outbound.protection.outlook.com [40.107.20.117]) (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 3C2733A0975 for ; Fri, 3 Dec 2021 13:09:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SVuj4BHfiPEBkRYP2sK5PnkuJG5gVAjjzEfFKlhKLjKkKGNLAxlfQ7bA7NTWQN+TMLQPyAoYgK8T1Eca1rBpWzWIJkU4s2axC6xF+uMiJbSC7AVs7Yw7JiTww3Liv6bbrNf2lK4YZHu+UFiC0ysOlASQgcLiXgcIaIfQ8kf7uNYFszIGcDHCEu3891CnbSsfyHSve/O97yk3ChdLGDWY4D6rQgqy6/FyrEvUbvs1rKNni5ATUHTPaaPG3KN7SMG3qmdlo5z8Lkw9fCuENOfKtRgGDWFECzxH3cUqVEzdAHuI4FiYANwfnt4VMMZ+IPTiQwRNYvZJIqlor9QgeE6szw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Rhzozee7XHZCzAs3s4JJGxho2W56KMTpCyY/hreKW+I=; b=aHKBzOpoqT0id/I+Zr+lcKxtoFIBdTSq6VeD1dhEuhm9jP1sEa7RFcyD5aCmAmFch1FCwK74BB85OcoBrVESYDHnBqK7tfpQYakC86XIdFygpoxL5tONc9yuOvaqm+JDojoLkOiIWqJY6lIFLKhQkJILVPddOMWEK86J41ifVqAQ5eImmUNH8caRQgv1vqwc5iJBvHsqSE1VA4EOTEFj4AY17SWQsloDcCQsyn4RaoCUtMWsN/MMfN9FCEXPB7cUHlWIH+BIVHuCi99nh/4C6JRsRbjV1JNJDZF5RVaXkyiILBKlP6hezcRmC/m8wq3G2F9W/IZ2UMwUhmSCibdMdQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Rhzozee7XHZCzAs3s4JJGxho2W56KMTpCyY/hreKW+I=; b=f5+CtzVMTFEVNjG6sgHoYk6xjDz7+Kg0aPmwoJmz+Hh4qBpGx+FzYqx5kEEaHcgGQuQWbcvz4vOB2h1Iu833kCG2fOSmtYxVm6Qgk2mT3E7TBL1PrW56KAOmxt1B+iE0ppQkHH5bya0E+CeNrD94md280ysSlpMXPjca8CHnpB4zzb1gQuZdZ+16Z22piuDN+V6onlBnGEqGPWHALmc4WZGO/lfJK69VhCkG7vuUesn9ODR9gdJrLIAlx7h+31QONsH4r3jxMKRGQ5CoeGQCyp6YcC2YIZ+zKpPV3RhSiD0kOZt9N0+Tfpd4ftilvgoSqXqaa4MqM6iBpNOTmjZYnA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB7PR02MB4969.eurprd02.prod.outlook.com (2603:10a6:10:7e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.23; Fri, 3 Dec 2021 21:09:04 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea%4]) with mapi id 15.20.4755.019; Fri, 3 Dec 2021 21:09:04 +0000 Message-ID: <14a08d9c-a911-a671-1770-2b748674397c@cs.tcd.ie> Date: Fri, 3 Dec 2021 21:04:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Martin Thomson , rfced-future@iab.org References: From: Stephen Farrell In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------veUFYCelurVs8wHltOJW00ac" X-ClientProxiedBy: DB6P18901CA0017.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::27) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.244.2.119] (95.45.153.252) by DB6P18901CA0017.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.16 via Frontend Transport; Fri, 3 Dec 2021 21:09:03 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ddd7a252-1359-422f-b613-08d9b6a122dc X-MS-TrafficTypeDiagnostic: DB7PR02MB4969: X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:4714; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: JYkHaeGAiJllvvy9J3o+ES5a0Qzz+6jYOYgfoVYxGxbA9ddMBzPuYDHsqTG09o+yqSuxMRdS7Do9s9qs3NhbnnTHbu9iGTdvOffsiJzfuOxvOhEaD7B5fD4HFKtGMePQvCBjA43x4yjPFAIoJytymQcIqx/JqqjveYa7Zqisgh5q1tFdAFxQaG3fzb3Kv5DJ9iSb8XwpIjAld5VgeY3/lBUXZj9h4oMQOyURYmfeUqhxZsYRxH70+oFJQRzgc5djus6hJxCUvdMO/JYoG1/9YDPSE0WyK48hWLsxm7RJ20nplPp2fmpDRf0hNSjBTGTj4odos9iH6vckg0F2xy7t30177lTCGTt+IoBPTWai2c/wqwBT7OYxOw4Ji07szKj3xW88sA/m9ez/X1JEqaKrLoscu6lMQUSFg/drMwWifkmadZPUG41IGRong7mDP7pdyyvbtuCOzSYoCnRe6W+eNNMd0+9Yq6gwgyw9xrfXDtZYoL27eYHzCbXSSdR8thxYD/LmFFasQRbzqR64WyEuH25CKW5yx5IOjxecyMJWtBoUSCvlguEF9o0Z81vv+2ehyG5Flf7CaKRDX3p/7T87J8QwvdsqIK73QSTBI5GQiuH3EhYkI4156kNBn5chO/w7MnFNgSUVJJtq1ccQdVvxuJ+3V6BlmBvNQvw/21/tkjKA6TePVRMgLE2ejJADWRCJmffLfQvvxv6yeoVepwwlQt/Em+c98OD9mFwORyAQI6SHP+NHQkq5kZQRnSTSMjsE X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(5660300002)(2906002)(83380400001)(38100700002)(508600001)(66556008)(6486002)(66476007)(26005)(31696002)(86362001)(66946007)(956004)(36756003)(21480400003)(66574015)(2616005)(53546011)(186003)(8936002)(44832011)(16576012)(316002)(786003)(31686004)(6666004)(8676002)(33964004)(235185007)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?bjc5RHkrcTdPcktnS1RObndrNnZjOHRFK2NtbThiS0J5Y2ZXUGFzdHJSNE9w?= =?utf-8?B?MWNkNXprRjNMRTZQMnAzOFN6RTV2bE11ZTd5WFpNWHQySFE4MXkrYUZXckNx?= =?utf-8?B?TDRVRnlxVjFOT3lwYm03ZVRCcDFSbW9pbUszYUg1UGx3YS8wT0pZQ1MyV1gr?= =?utf-8?B?UVNwdnUyclA0UW52K2dwZHN4WW92d0N1eHhRUjZXaURpdHM3cGxwZHE4dmQ5?= =?utf-8?B?aGFZKzZzLzU2ek5HWHRHb3ZMLzEzRHpKTFhDVVVCbS9ZL1h1bUdpRmc2eDdu?= =?utf-8?B?VVZqRDB1MHRMVEJGRVVZY3FNb3ZYQzFkdS83S0RKQ3lyMmdDdVNnWkExTTQ5?= =?utf-8?B?azB3ZlJMbnhiSDZJbFkzTnViK1VlcG5mZEp3c01OQ2pVOWFndDZRa0xCU3BT?= =?utf-8?B?NHc0UThrcDE0NmRRc1ljN2tyMGJzaU1DYkltT2ttRlJQamxtV0dIVE5vWGFI?= =?utf-8?B?L1hzWkkzcmdSNHRRc1NRd1ZHUHdZOVJmWVdLcnpNNDJUNmRzcmIycklGWllk?= =?utf-8?B?c2xZYUpETUZnTXcrbVNkbFhjUWR1S1EyWmlwYzExRXVVYkxrcWk0V2NiQ0hC?= =?utf-8?B?QjNlR1R4SnhMcldzbWdxS0dSTEsyVmxjQmlYM1VzRmFaTUphSk9vTGcyODFl?= =?utf-8?B?NG5TK0NHd1RXSkROWlBDbVVTaUdZZVNjbHdsY09XVVlqZWJKbDlxQ3UrRlA0?= =?utf-8?B?QVNUNVl6MnhDeGNObGJpMDBoK0g0VnQvMFpnTm4ydFlPUk9lblJhTDFlSHFl?= =?utf-8?B?R1A3QTBFMXRsMWFycWUzc0NyRURrUk9jdG0zbmRVN2VCemdSczJzRDAwK1NS?= =?utf-8?B?ZzVmRkZncVhQRVlPdlhhMzZWTHlFUHdoSzYvZDhYankraU9xeGpkQlVMeHRG?= =?utf-8?B?ZmdLNm5zcVUvVTVHdXFjYlNKOWE3T2EvK25BaGJTNDZ4U2JEU0p4ZHJQYVcx?= =?utf-8?B?bUI4YkdsTURpTzFTbjlHcU1wYU1oTkp4Q0V4SHE4SFVSYWxiS0RlMXdRTzlv?= =?utf-8?B?cTg4ajl0Vy91TU5rMVFHdFRRaGYzYWdsUndWZlVVOTZkWXZIR3g0Y0tUWElo?= =?utf-8?B?WEY5TmFmckkwMklrU2lSTnBpUkpwSm1uMzlMUzFKK09FSTk2WjlSU1NpTkpP?= =?utf-8?B?QjFuRjFFT3FVVVV0NDYrVEJQbjQ2WGhVQnhaQWhIL0lMcFZtZUQ2WUpPazVX?= =?utf-8?B?ckpKN2pmVTVyV2M1cmJjWk1LS3NpTlQ1TGQ2MGhxVlJIRUhQVnVNWVA2WjJU?= =?utf-8?B?NnZGL3ZDdnRjYkQvQnFKMXdzT3hRMzE2TzJqbTcrVWdYdzM5eUROclBrc0lk?= =?utf-8?B?ZE0vVGpqcDF2RVI4d1RUTHZBaU5VOXBzU0h0U1dSK3l1aThqQ3IveklPcEg2?= =?utf-8?B?QVIvNU5yUkxpamlQVjh6MGNVK3BMQjhpbnYrTGZnL1JZSjNxRy9wZ0NQM09T?= =?utf-8?B?VWlNbXhOdmdHeVd1emxaL1FYQlI1VlhBdThzZWN1c3N1VloweHY1QVVqd0FZ?= =?utf-8?B?cEVtR1JHZFpwODlOYnk5SkJLU2IwWEdlU0o3dVM5VFdtMU91UXo3SWRjSFVO?= =?utf-8?B?SGhNUUUyZFBZd3VTaWlBKzRTZ1JGOC9jSndiRmRDSFFwUmEzZDRLeEN6R1Np?= =?utf-8?B?dk1WUXNhQmFmeGpTRWwvTFRwY1IwUVdUaFlyRXhHbWZyZjZOcVNEL2Nsb2Rw?= =?utf-8?B?eTd1eU1vRFJxQWsxT1hhTVJnNHJUb0hOb0F5NzFVMkJpcUV3ZlVQazhYeXhP?= =?utf-8?B?VDVldjIvaElyMjUxNVIrSjdhK2ViczdoS25DV3ZvWXNnS3JHcDZ2Z0xhbFRp?= =?utf-8?B?aDlpRGdrN3F4ZkI0VDJJekR1UkVGZnVzLzV5K1lYRy81V0JZdHhjRHlmYUFN?= =?utf-8?B?RUdIb0ZiMGtiMVlGZ3Zkc0V3RStnZHU4dExyR09OQStRNW8zUzJESW5SalBE?= =?utf-8?B?WWNnYjA3VGVDbGgzWDIyekMxaXdya1hUbFFRQ0RsRmtVaHV5bStxeEVyRnFp?= =?utf-8?B?My8vcU5tQWlNY0dyQ0FqVm90dTBCcXJ1czZiWDRoaFpLMld3SlY3M2JZMkU4?= =?utf-8?B?cmpMU2dTWkNMNThScjVDTDB2b096b3ZWMFhOR3FIUy9LS0o2WjhTYjNya2RG?= =?utf-8?Q?1ayQ=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: ddd7a252-1359-422f-b613-08d9b6a122dc X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Dec 2021 21:09:04.1734 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: +SFcJ/kDhNFMpWIbcarmmU20AGZubCCUDUqPzmuDIemmCcUyDN4YgW4Mb7p47n2B X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR02MB4969 Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:09:14 -0000 --------------veUFYCelurVs8wHltOJW00ac Content-Type: multipart/mixed; boundary="------------i26937H1OTonPrvzVNlauaNz"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson , rfced-future@iab.org Message-ID: <14a08d9c-a911-a671-1770-2b748674397c@cs.tcd.ie> Subject: Re: [Rfced-future] Proposed "Historical Properties" References: In-Reply-To: --------------i26937H1OTonPrvzVNlauaNz Content-Type: multipart/mixed; boundary="------------FI305TjtPCOyowjQXzOWMIQ8" --------------FI305TjtPCOyowjQXzOWMIQ8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpJIGhhZCBwbGFubmVkIHRvIGxpc3RlbiB0byB0aGUgcmVjb3JkaW5nIGJlZm9yZSBwb3N0 aW5nIHRoaXMNCihhbmQgZGlkbid0IG1hbmFnZSB0aGF0KSBidXQgaW4gYW55IGNhc2UuLi4N Cg0KSSB0aGluayBNYXJ0aW4ncyBkb25lIGEgZ3JlYXQgam9iIHdpdGggdGhhdCB0ZXh0LiBG cm9tIG15IFBPVg0KaXQgb25seSBsYWNrcyBvbmUgaW1wb3J0YW50IHRoaW5nOiB0aGF0IFJG Q3MgYXJlLCBieSBkZXNpZ24sDQppbnRlbmRlZCB0byBoYXZlIGxvbmdldml0eSBpbiB0aGUg c2Vuc2Ugb2YgYmVpbmcgZWFzaWx5DQpyZW5kZXJlZCBmb3IgYSBodW1hbiBiZWluZyBmb3Ig ZXh0ZW5kZWQgcGVyaW9kcy4gSU1PIHRoYXQncw0KYSBkaWZmZXJlbnQgcHJvcGVydHkgYW5k IHdvcnRoIHN0YXRpbmcuIFNvIEknZCBzdWdnZXN0DQphZGRpbmc6DQoNCiIjIExvbmdldml0 eQ0KDQpSRkNzIGhhdmUgYWx3YXlzIGJlZW4gaW50ZW5kZWQgdG8gYmUgZWFzaWx5IGxlZ2li bGUgdG8gaHVtYW5zDQpldmVuIGRlY2FkZXMgYWZ0ZXIgaGF2aW5nIGJlZW4gd3JpdHRlbi4i DQoNClRvIGJlIGNsZWFyOiB3aXRoIHRoYXQgKG9yIHNpbWlsYXIpIGluY2x1ZGVkLCBJJ2Qg YmUgZmluZQ0Kd2l0aCB0aGUgZG9jdW1lbnQgb3ZlcmFsbC4NCg0KQ2hlZXJzLA0KUy4NCg0K DQpPbiAwMi8xMi8yMDIxIDIzOjM1LCBNYXJ0aW4gVGhvbXNvbiB3cm90ZToNCj4gVGhlIHRl eHQgYmVsb3cgYXR0ZW1wdHMgdG8gY2FwdHVyZSBhIGZldyB0aGluZ3MgdGhhdCBJIGJlbGll dmUgd2VyZQ0KPiB0aGUgcmVzdWx0IG9mIG91ciBkaXNjdXNzaW9ucyBlYXJsaWVyIHRvZGF5 Lg0KPiANCj4gRmlyc3QsIHRoYXQgdGhlIFJTQUIgaGFzIHRoZSByZXNwb25zaWJpbGl0eSBh bmQgYXV0aG9yaXR5IHRvIGRlY2lkZQ0KPiBob3cgbXVjaCByZXZpZXcgaXMgYXBwcm9wcmlh dGUuICBUaGV5IGFyZSBleHBlY3RlZCB0byBleGVyY2lzZQ0KPiBqdWRnbWVudCBpbiBob3cg dGhleSBtYW5hZ2UgdGhlIHB1YmxpYyBjb21tZW50IGFuZCByZXZpZXcgcGVyaW9kLA0KPiB0 aGlzIGp1c3Qgc3RyZW5ndGhlbnMgdGhhdCByZXF1aXJlbWVudC4NCj4gDQo+IFNlY29uZCwg dGhhdCB0aGUgUlNBQiBqdWRnbWVudCBvbiB0aGlzIG1hdHRlciB3b3VsZCBiZW5lZml0IGZy b20gYQ0KPiBmZXcgZ3VpZGVsaW5lcyBzbyB0aGF0IHRoaW5ncyB0aGF0IGhhdmUgYmVlbiBw dXQgaW4gcGxhY2UNCj4gZGVsaWJlcmF0ZWx5IG92ZXIgdGhlIHllYXJzIGFyZSBub3QgcmVt b3ZlZCB3aXRob3V0IGVxdWFsIGNhcmUsDQo+IGRlbGliZXJhdGlvbiwgYW5kIGNvbnN1bHRh dGlvbi4NCj4gDQo+IFRoaXJkLCB0aGF0IHRoaXMgZG9lcyBub3QgZnVuZGFtZW50YWxseSBj aGFuZ2UgdGhlIHByb2Nlc3Mgd2UgYXBwbHkuDQo+IFdlIHN0aWxsIGZvbGxvdyB0aGUgc2Ft ZSBiYXNpYyBwcm9jZXNzZXMgdGhhdCB3ZSd2ZSBhZ3JlZWQgdG8uDQo+IEhvd2V2ZXIsIHdl IGhpZ2hsaWdodCB0aGUgbmVlZCBmb3IgYWRkaXRpb25hbCBjYXJlIHNvIHRoYXQgY2hhbmdl cyB0bw0KPiBpbXBvcnRhbnQgdGhpbmdzIGFyZSwgYXMgZGlzY3Vzc2VkLCAidmVyeSBkZWxp YmVyYXRlIiBhbmQgdGhhdCB0aGUNCj4gY29uc2VxdWVuY2VzIG9mIHRob3NlIGNoYW5nZXMg YXJlIGdpdmVuIGR1ZSBjb25zaWRlcmF0aW9uLg0KPiANCj4gRm9yIHRoaXMsIEkgdG9vayBC cmlhbidzIHRleHQgYW5kIHR3ZWFrZWQgaXQuICBUaGUgaW50cm9kdWN0b3J5IHBpZWNlDQo+ IGhlcmUgaXMgbW9zdGx5IG5ldywgdG8gY2FwdHVyZSB0aGUgYWJvdmUgcG9pbnRzLiAgVGhl IGRldGFpbGVkIHBvaW50cw0KPiBhcmUgbGFyZ2VseSB0aGUgc2FtZSwgY29uY2VudHJhdGlu ZyBhcyB0aGV5IGRpZCBpbiBCcmlhbidzDQo+IGZvcm11bGF0aW9uIG9uIGJlaW5nIGZhY3R1 YWwgcmF0aGVyIHRoYW4gcHJlc2NyaXB0aXZlLiAgSSBoYXZlIG9ubHkNCj4gZWRpdGVkIHNv bWUgb2YgdGhlc2UgcG9pbnRzIGRvd24gc2xpZ2h0bHkgdG8gc2hhcnBlbiB0aGUgZm9jdXMu DQo+IA0KPiAtLS0gIyBIaXN0b3JpY2FsIFByb3BlcnRpZXMgb2YgdGhlIFJGQyBTZXJpZXMN Cj4gDQo+IFRoZSBSU0FCIGhhcyBhIGR1dHkgdG8gZW5zdXJlIHRoYXQgcHJvcG9zYWxzIGZy b20gdGhlIFJTV0cgcmVjZWl2ZQ0KPiBhcHByb3ByaWF0ZSBsZXZlbHMgb2YgcmV2aWV3LiBQ cm9wb3NhbHMgdGhhdCwgaW4gdGhlIG9waW5pb24gb2YgdGhlDQo+IFJTQUIsIGhhdmUgc2ln bmlmaWNhbnQgaW1wYWN0IG9uIHRoZSBzZXJpZXMgcmVxdWlyZSBhZGRpdGlvbmFsDQo+IG91 dHJlYWNoIGFuZCByZXZpZXcgZnJvbSBhIHdpZGVyIGNvbW11bml0eS4gQWRkaXRpb25hbCB0 aW1lIHNob3VsZCBiZQ0KPiBhbGxvd2VkIGZvciBjb2xsZWN0aW5nIGZlZWRiYWNrIGZvciBz dWNoIHByb3Bvc2Fscy48IS0tIFRoaXMNCj4gcGFyYWdyYXBoIG1pZ2h0IGdvIGVsc2V3aGVy ZSwgd2l0aCBhIHJlZmVyZW5jZSB0aGlzIHNlY3Rpb247IGF0DQo+IFBldGVyJ3MgZGlzY3Jl dGlvbi4gLS0+DQo+IA0KPiBUaGlzIHNlY3Rpb24gbGlzdHMgc29tZSBvZiB0aGUgcHJvcGVy dGllcyB0aGF0IGhhdmUgYmVlbiBoaXN0b3JpY2FsbHkNCj4gcmVnYXJkZWQgYXMgaW1wb3J0 YW50IHRvIHRoZSBSRkMgU2VyaWVzLiBQcm9wb3NhbHMgdGhhdCBhZmZlY3QgdGhlc2UNCj4g cHJvcGVydGllcyBhcmUgcG9zc2libGUgd2l0aGluIHRoZSBwcm9jZXNzZXMgZGVmaW5lZCBp biB0aGlzDQo+IGRvY3VtZW50LiBIb3dldmVyLCB0aGUgUlNBQiBzaG91bGQgc2VlayBicm9h ZGVyIHJldmlldyBmb3IgcHJvcG9zYWxzDQo+IHRoYXQgbWlnaHQgaGF2ZSBhIGRldHJpbWVu dGFsIGFmZmVjdCBvbiB0aGVzZSBwcm9wZXJ0aWVzLiBUaGUgcHVycG9zZQ0KPiBvZiByZXZp ZXcgaXMgdG8gZW5zdXJlIHRoYXQgYWxsIGNoYW5nZXMgYXJlIGRlbGliZXJhdGUgYW5kIHRo YXQgYWxsDQo+IG9mIHRoZSBjb25zZXF1ZW5jZXMgb2YgYSBwcm9wb3NhbCBoYXZlIGJlZW4g Y2FyZWZ1bGx5IGNvbnNpZGVyZWQuDQo+IA0KPiAjIyBBdmFpbGFiaWxpdHkNCj4gDQo+IERv Y3VtZW50cyBpbiB0aGUgUkZDIFNlcmllcyBoYXZlIGJlZW4gYXZhaWxhYmxlIGZvciBtb3Jl IHRoYW4gMzUNCj4geWVhcnMsIHdpdGggbm8gZmVlIGZvciBhY2Nlc3MuDQo+IA0KPiAjIyBB Y2Nlc3NpYmlsaXR5DQo+IA0KPiBSRkMgU2VyaWVzIGRvY3VtZW50cyBoYXZlIGJlZW4gcHVi bGlzaGVkIGluIGEgZm9ybWF0IHRoYXQgd2FzDQo+IGludGVuZGVkIHRvIGJlIGFzIGFjY2Vz c2libGUgYXMgcG9zc2libGUgdG8gdGhvc2Ugd2l0aCBzcGVjaWFsIG5lZWRzLA0KPiBlLmcu LCBmb3IgdGhvc2Ugd2l0aCBpbXBhaXJlZCBzaWdodC4NCj4gDQo+ICMjIFB1YmxpY2F0aW9u IExhbmd1YWdlDQo+IA0KPiBBbGwgZXhpc3RpbmcgUkZDIFNlcmllcyBkb2N1bWVudHMgaGF2 ZSBiZWVuIHB1Ymxpc2hlZCBpbiBFbmdsaXNoLg0KPiBEb2N1bWVudHMgaGF2ZSBiZWVuIGxp Y2Vuc2VkIHRvIGV4cGxpY2l0bHkgcGVybWl0IHRyYW5zbGF0aW9uIGludG8NCj4gb3RoZXIg bGFuZ3VhZ2VzLg0KPiANCj4gIyMgQ29udGVudCBEaXZlcnNpdHkNCj4gDQo+IEluIGFkZGl0 aW9uIHRvIEludGVybmV0IHN0YW5kYXJkcywgdGhlIFJGQyBzZXJpZXMgaGFzIHB1Ymxpc2hl ZA0KPiBwcm9jZWR1cmFsIGFuZCBpbmZvcm1hdGlvbmFsIGRvY3VtZW50cywgdGhvdWdodCBl eHBlcmltZW50cywNCj4gc3BlY3VsYXRpdmUgaWRlYXMsIHJlc2VhcmNoIHBhcGVycywgaGlz dG9yaWVzLCBodW1vciwgYW5kIGV2ZW4NCj4gZXVsb2dpZXMuDQo+IA0KPiAjIyBEb2N1bWVu dCBRdWFsaXR5DQo+IA0KPiBSRkMgU2VyaWVzIGRvY3VtZW50cyBoYXZlIGJlZW4gZWRpdGVk IGJ5IHByb2Zlc3Npb25hbHMgd2l0aCBhIGdvYWwgb2YNCj4gZW5zdXJpbmcgdGhhdCBkb2N1 bWVudHMgYXJlIGNsZWFyLCBjb25zaXN0ZW50LCBhbmQgcmVhZGFibGUNCj4gW1JGQzczMjJd Lg0KPiANCg== --------------FI305TjtPCOyowjQXzOWMIQ8 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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 zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 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+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC 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 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK 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+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb 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 Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R 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/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK 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+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB 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 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+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 =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------FI305TjtPCOyowjQXzOWMIQ8-- --------------i26937H1OTonPrvzVNlauaNz-- --------------veUFYCelurVs8wHltOJW00ac Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmGqhmYFAwAAAAAACgkQWrL68XsXK+ob PBAAq0n3VP46mNG/CFRcCE9DknsJiSDdtQiX4sbJx/cGhf4HSIAwGm/PjOT0I95+sT+If94XkrJ2 d3zsWJI531Yd+ip2tbhQdmwJa8isyD5cgBVG5TSJkARnhV3y/y/7y8iltmV09dM0Zu8SU39lk1Bd cGfRCpp2E5IupMqSAr643Us1fAfl736vt6/t0l1GLhYtosZ48jyqIWYgOoUsJ3Sd9xl0xw7xUri2 Hxe38X8oZJFOJFnI03JDzNp1YVKo6CBxQ2IgqR0ya4D4kL2i8IzquxUouy5QMx7ZeUxppHG2MC7U BL2zxD+olAWZfZoDek/7BtgkZplJ0l7m43skn1ybVjSpMLe+YZnqXjBPyoXJpmIDpmswThkn1LyJ X+J1fGZsMM8WrR6LQQnBWb7/PaMLfE3gzQCyHKngzXIoSRo1RiPvZlzWSsBGQsWgEV+gbMMQzplS XQmqbJUxYIIiLMfpwmWMzeW/BVrJTknpv3PumyKTIN9se/mGiQiWVB+slaCwKkUvALO5QV0DeWFY c8Ez9MLTq7Hfmwqyd1K/6dvBxW+VLZU6KBHOkzKSOv3cK2u+GjrHh3k0kagBq1axQPA6S0WsCyd7 O0dMwcUspzNTqa7JOy7yO85AXnI5sR95aI8yRoxb+XzW+VdJFALcNm8yPxCndPA3GXmZ704/nJzR 4lA= =dHAu -----END PGP SIGNATURE----- --------------veUFYCelurVs8wHltOJW00ac-- From nobody Fri Dec 3 13:22:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BD803A09BE for ; Fri, 3 Dec 2021 13:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 mdKfUZYb4PuV for ; Fri, 3 Dec 2021 13:22:13 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D113A09BC for ; Fri, 3 Dec 2021 13:22:13 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id e8so4016747ilu.9 for ; Fri, 03 Dec 2021 13:22:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+q09l4MSIwUbS/3hxedJFAcAHB+t9WRANk7ENpnRs5k=; b=qgD7a4IBk+5a9lrehCYhz99Oq3K9Wl+gXtXTL1E7G6PBxGaSWtjIc1eMOrwDdo9sF8 gPgnSLWlj+umzKxVnQf2w8ZAeCyh2ucKXX9lh66Gc2wUC9FRZpl5Q4MSKJYXykV8kD/+ gUFY8JiUHNZH43VHOZgAlel8Hyf6HiYldoruZhwjLBgXEXcmzb8rLbwwM6aP7dw/UHyI BlprZQWgB7OZvWgpiAZ9U51IIw3MRm78yGQMHYv0a5rbbwRc6Tc07ml0oRTtB3KWwyRc 0ne/MGWQW9qKTfucrHDp69VLIZKajqJf/GQC6KiUIhxqMXC4KvWpn1MrNFSVrWVay/mc KASw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+q09l4MSIwUbS/3hxedJFAcAHB+t9WRANk7ENpnRs5k=; b=nuojeZiWDen3LRcRK67ooFL5OGUAZLLeAzyuQb1jigwOKQlIDxz1sqy6ptKfD1aKEv Ml6g7Z9GrlqoW8eU8oqaBr9IsnU1sKt/9rIgNWCxooi0ehXWIuGk27LGhzYdmNsPTtXq kRAlVTN6k2HVl4lH17NzEgtstxPzFoxH8DD5V6n82++xSHCfS2du6MJL6g9a39iNCepb k98ovssSI3tMGNYa2ATdsPvXS+TOPD92DF7j+8LuhYgK88DlHPrN7kPb6k7kE6clXz63 R1aA9G3l6rMa7denQxXF4qiTKXX8gzR1mZRHmUgOragfrjqfVz/tA1v83oqDOD2zIEBA OabQ== X-Gm-Message-State: AOAM533CoLzxHu0Hf7VlpSp+TQShhc5Fp45s7SlFMQmaMEUowCn0YJ9N 3ba6g07XzJMLU4XSEgLhkzr4mpEQ+bE5QGAmc7Jl0Q== X-Google-Smtp-Source: ABdhPJwpaGiScI8K4ILfRaCmbuQrsgpKsDD1jpTKbipoiV1UYlaj8rEG8b1jCKlxH3v2reHmt7fWeh5mfp8WeyuLrd0= X-Received: by 2002:a05:6e02:152a:: with SMTP id i10mr19382209ilu.10.1638566532195; Fri, 03 Dec 2021 13:22:12 -0800 (PST) MIME-Version: 1.0 References: <14a08d9c-a911-a671-1770-2b748674397c@cs.tcd.ie> In-Reply-To: <14a08d9c-a911-a671-1770-2b748674397c@cs.tcd.ie> From: Eric Rescorla Date: Fri, 3 Dec 2021 13:21:36 -0800 Message-ID: To: Stephen Farrell Cc: Martin Thomson , rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000017ba2605d244803c" Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:22:18 -0000 --00000000000017ba2605d244803c Content-Type: text/plain; charset="UTF-8" This seems like a reasonable addition to me. On Fri, Dec 3, 2021 at 1:09 PM Stephen Farrell wrote: > > I had planned to listen to the recording before posting this > (and didn't manage that) but in any case... > > I think Martin's done a great job with that text. From my POV > it only lacks one important thing: that RFCs are, by design, > intended to have longevity in the sense of being easily > rendered for a human being for extended periods. IMO that's > a different property and worth stating. So I'd suggest > adding: > > "# Longevity > > RFCs have always been intended to be easily legible to humans > even decades after having been written." > > To be clear: with that (or similar) included, I'd be fine > with the document overall. > > Cheers, > S. > > > On 02/12/2021 23:35, Martin Thomson wrote: > > The text below attempts to capture a few things that I believe were > > the result of our discussions earlier today. > > > > First, that the RSAB has the responsibility and authority to decide > > how much review is appropriate. They are expected to exercise > > judgment in how they manage the public comment and review period, > > this just strengthens that requirement. > > > > Second, that the RSAB judgment on this matter would benefit from a > > few guidelines so that things that have been put in place > > deliberately over the years are not removed without equal care, > > deliberation, and consultation. > > > > Third, that this does not fundamentally change the process we apply. > > We still follow the same basic processes that we've agreed to. > > However, we highlight the need for additional care so that changes to > > important things are, as discussed, "very deliberate" and that the > > consequences of those changes are given due consideration. > > > > For this, I took Brian's text and tweaked it. The introductory piece > > here is mostly new, to capture the above points. The detailed points > > are largely the same, concentrating as they did in Brian's > > formulation on being factual rather than prescriptive. I have only > > edited some of these points down slightly to sharpen the focus. > > > > --- # Historical Properties of the RFC Series > > > > The RSAB has a duty to ensure that proposals from the RSWG receive > > appropriate levels of review. Proposals that, in the opinion of the > > RSAB, have significant impact on the series require additional > > outreach and review from a wider community. Additional time should be > > allowed for collecting feedback for such proposals. > > > > This section lists some of the properties that have been historically > > regarded as important to the RFC Series. Proposals that affect these > > properties are possible within the processes defined in this > > document. However, the RSAB should seek broader review for proposals > > that might have a detrimental affect on these properties. The purpose > > of review is to ensure that all changes are deliberate and that all > > of the consequences of a proposal have been carefully considered. > > > > ## Availability > > > > Documents in the RFC Series have been available for more than 35 > > years, with no fee for access. > > > > ## Accessibility > > > > RFC Series documents have been published in a format that was > > intended to be as accessible as possible to those with special needs, > > e.g., for those with impaired sight. > > > > ## Publication Language > > > > All existing RFC Series documents have been published in English. > > Documents have been licensed to explicitly permit translation into > > other languages. > > > > ## Content Diversity > > > > In addition to Internet standards, the RFC series has published > > procedural and informational documents, thought experiments, > > speculative ideas, research papers, histories, humor, and even > > eulogies. > > > > ## Document Quality > > > > RFC Series documents have been edited by professionals with a goal of > > ensuring that documents are clear, consistent, and readable > > [RFC7322]. > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --00000000000017ba2605d244803c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This seems like a reasonable addition to me.

=
On Fri, De= c 3, 2021 at 1:09 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

I had planned to listen to the recording before posting this
(and didn't manage that) but in any case...

I think Martin's done a great job with that text. From my POV
it only lacks one important thing: that RFCs are, by design,
intended to have longevity in the sense of being easily
rendered for a human being for extended periods. IMO that's
a different property and worth stating. So I'd suggest
adding:

"# Longevity

RFCs have always been intended to be easily legible to humans
even decades after having been written."

To be clear: with that (or similar) included, I'd be fine
with the document overall.

Cheers,
S.


On 02/12/2021 23:35, Martin Thomson wrote:
> The text below attempts to capture a few things that I believe were > the result of our discussions earlier today.
>
> First, that the RSAB has the responsibility and authority to decide > how much review is appropriate.=C2=A0 They are expected to exercise > judgment in how they manage the public comment and review period,
> this just strengthens that requirement.
>
> Second, that the RSAB judgment on this matter would benefit from a
> few guidelines so that things that have been put in place
> deliberately over the years are not removed without equal care,
> deliberation, and consultation.
>
> Third, that this does not fundamentally change the process we apply. > We still follow the same basic processes that we've agreed to.
> However, we highlight the need for additional care so that changes to<= br> > important things are, as discussed, "very deliberate" and th= at the
> consequences of those changes are given due consideration.
>
> For this, I took Brian's text and tweaked it.=C2=A0 The introducto= ry piece
> here is mostly new, to capture the above points.=C2=A0 The detailed po= ints
> are largely the same, concentrating as they did in Brian's
> formulation on being factual rather than prescriptive.=C2=A0 I have on= ly
> edited some of these points down slightly to sharpen the focus.
>
> --- # Historical Properties of the RFC Series
>
> The RSAB has a duty to ensure that proposals from the RSWG receive
> appropriate levels of review. Proposals that, in the opinion of the > RSAB, have significant impact on the series require additional
> outreach and review from a wider community. Additional time should be<= br> > allowed for collecting feedback for such proposals.<!-- This
> paragraph might go elsewhere, with a reference this section; at
> Peter's discretion. -->
>
> This section lists some of the properties that have been historically<= br> > regarded as important to the RFC Series. Proposals that affect these > properties are possible within the processes defined in this
> document. However, the RSAB should seek broader review for proposals > that might have a detrimental affect on these properties. The purpose<= br> > of review is to ensure that all changes are deliberate and that all > of the consequences of a proposal have been carefully considered.
>
> ## Availability
>
> Documents in the RFC Series have been available for more than 35
> years, with no fee for access.
>
> ## Accessibility
>
> RFC Series documents have been published in a format that was
> intended to be as accessible as possible to those with special needs,<= br> > e.g., for those with impaired sight.
>
> ## Publication Language
>
> All existing RFC Series documents have been published in English.
> Documents have been licensed to explicitly permit translation into
> other languages.
>
> ## Content Diversity
>
> In addition to Internet standards, the RFC series has published
> procedural and informational documents, thought experiments,
> speculative ideas, research papers, histories, humor, and even
> eulogies.
>
> ## Document Quality
>
> RFC Series documents have been edited by professionals with a goal of<= br> > ensuring that documents are clear, consistent, and readable
> [RFC7322].
>
--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--00000000000017ba2605d244803c-- From nobody Fri Dec 3 14:26:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACFEA3A0A73 for ; Fri, 3 Dec 2021 14:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.131 X-Spam-Level: X-Spam-Status: No, score=-3.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-1.852, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZ3l_0OMUpvx for ; Fri, 3 Dec 2021 14:26:49 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326623A0A74 for ; Fri, 3 Dec 2021 14:26:48 -0800 (PST) Received: from Zephyrus.local (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.17.1/8.16.1) with ESMTPSA id 1B3MQg6X003026 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 3 Dec 2021 16:26:44 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1638570405; bh=nkk8Ieg/qA3Yo10rVGHd56iNQRR/iz/elFz1NLAhZAY=; h=Subject:To:References:From:Date:In-Reply-To; b=eJFkCNWyX6qjjgH2iKIkInu9PL//FvVSC5Sa6mkcoM6DEgikUD5TA0qK6F/1qOtty v8+SoBKOpBL4Weq9jt5/K/4R/5Y3HmDYYosv2tMV2JOUGh4FtS5630ecL+mh4PoRd4 NlmukEaWZFGkkrB77AJ/GnhrSXVP+jaBaR0GqYbI= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be Zephyrus.local To: Eliot Lear , Martin Thomson , rfced-future@iab.org References: <32294a20-86f7-9198-c4d0-653a0ef92439@it.aoyama.ac.jp> <1f290d0f-198b-4056-82f7-062eb5fd6a9b@www.fastmail.com> From: Adam Roach Message-ID: <86455d7f-85ab-67db-97fa-6d97466a4557@nostrum.com> Date: Fri, 3 Dec 2021 16:26:36 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F7DF65982B97DFC46D81F3FA" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 22:26:54 -0000 This is a multi-part message in MIME format. --------------F7DF65982B97DFC46D81F3FA Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit As a general comment, I am okay with the direction the text has taken. I have no objections to Stephen's text about format longevity, nor to the (shortened version of the) "Stable References" text that you propose. /a On 12/3/21 03:52, Eliot Lear wrote: > Hi Martin T, and thanks for this, and thanks Martin D for your comments. > > Can everyone comment on Martin's text? > > Eliot > > On 03.12.21 10:40, Martin Thomson wrote: >> On Fri, Dec 3, 2021, at 20:18, Martin J. Dürst wrote: >>> So what about something like >>> "and that the consequences of a >>> proposal, as far as they are identifiable, have been carefully >>> considered" or so. >> That's a reasonable amendment.  Thanks. >> >> I'm maintaining the text here: >> https://notes.ietf.org/BrrKxlvGRrOKVdNFjCUung?view in case you want >> to follow along. >> > --------------F7DF65982B97DFC46D81F3FA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
As a general comment, I am okay with the direction the text has taken. I have no objections to Stephen's text about format longevity, nor to the (shortened version of the) "Stable References" text that you propose.

/a

On 12/3/21 03:52, Eliot Lear wrote:
Hi Martin T, and thanks for this, and thanks Martin D for your comments.

Can everyone comment on Martin's text?

Eliot

On 03.12.21 10:40, Martin Thomson wrote:
On Fri, Dec 3, 2021, at 20:18, Martin J. Dürst wrote:
So what about something like
"and that the consequences of a
proposal, as far as they are identifiable, have been carefully
considered" or so.
That's a reasonable amendment.  Thanks.

I'm maintaining the text here: https://notes.ietf.org/BrrKxlvGRrOKVdNFjCUung?view in case you want to follow along.



--------------F7DF65982B97DFC46D81F3FA-- From nobody Sat Dec 4 00:44:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3E843A0CF0 for ; Sat, 4 Dec 2021 00:44:20 -0800 (PST) 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_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPQ4yxSSUHkZ for ; Sat, 4 Dec 2021 00:44:15 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 8AF193A0CF2 for ; Sat, 4 Dec 2021 00:44:14 -0800 (PST) Received: from [192.168.0.132] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B48iBYQ696960 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 4 Dec 2021 09:44:11 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638607451; bh=zT+O3aFm7AzEoOsHkMvflQOfoDCOQDREn7sxeVZBIK8=; h=Date:To:From:Subject:From; b=spf7KzswaZwhiG61FDBZ9cP4LupHt2dqCadQtiUkajwbOof0VdgS+EKxRpewmdG9u 6CqlT55Nx1NwjL0+5zj26tgfWzwm2aj1D/3Lz1rOzf6lgKfniFIxJ6b6sVufjA7PIF LgDdGQi956AZZCgKqTd3jdzbE7V4OTobwXTl9Ht4= Message-ID: Date: Sat, 4 Dec 2021 09:44:10 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6yhjP049jU3h0v7X7BTuql0P" Archived-At: Subject: [Rfced-future] cleaning up remaining issues: CONSENSUS CALL, Issue 93 comment please by December 18th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:44:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6yhjP049jU3h0v7X7BTuql0P Content-Type: multipart/mixed; boundary="------------YLXd9LCM5Wr2S2VCzwHFSLed"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: cleaning up remaining issues: CONSENSUS CALL, Issue 93 comment please by December 18th --------------YLXd9LCM5Wr2S2VCzwHFSLed Content-Type: multipart/mixed; boundary="------------cCxxJ78yK9g6jLyx4xuaY8yg" --------------cCxxJ78yK9g6jLyx4xuaY8yg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UGxlYXNlIGNvbW1lbnQgYnkgRGVjZW1iZXIgMTh0aCBhYm91dCB3aGV0aGVyIHlvdSBzdXBw b3J0IHRoZSBmb2xsb3dpbmcgDQpjaGFuZ2U6DQoNCk9MRA0KDQo+IERlY2lzaW9ucyBvZiB0 aGUgUlNBQiBjYW4gYmUgYXBwZWFsZWQgb24gZ3JvdW5kcyBvZiBmYWlsdXJlIHRvIGZvbGxv dyANCj4gdGhlIGNvcnJlY3QgcHJvY2Vzcy4gV2hlcmUgdGhlIFJTQUIgbWFrZXMgYSBkZWNp c2lvbiBpbiBvcmRlciB0byANCj4gcmVzb2x2ZSBhIGRpc3B1dGUsIGFwcGVhbHMgY2FuIGJl IGZpbGVkIG9uIHRoZSBiYXNpcyB0aGF0IHRoZSBSU0FCIA0KPiBtaXNpbnRlcnByZXRlZCBh biBhcHByb3ZlZCBwb2xpY3kuIEluIG90aGVyIGNhc2VzLCBkaXNhZ3JlZW1lbnRzIGFib3V0 IA0KPiB0aGUgY29uZHVjdCBvZiB0aGUgUlNBQiBhcmUgbm90IHN1YmplY3QgdG8gYXBwZWFs Lg0KDQpORVcNCg0KPiBEZWNpc2lvbnMgb2YgdGhlIFJTQUIgY2FuIGJlIGFwcGVhbGVkIG9u IGdyb3VuZHMgb2YgZmFpbHVyZSB0byBmb2xsb3cgDQo+IHRoZSBjb3JyZWN0IHByb2Nlc3Mu IFdoZXJlIHRoZSBSU0FCIG1ha2VzIGEgZGVjaXNpb24gaW4gb3JkZXIgdG8gDQo+IHJlc29s dmUgYSBkaXNwdXRlLCBhcHBlYWxzIGNhbiBiZSBmaWxlZCBvbiB0aGUgYmFzaXMgdGhhdCB0 aGUgUlNBQiANCj4gbWlzaW50ZXJwcmV0ZWQgYW4gYXBwcm92ZWQgcG9saWN5LiBJbiBvdGhl ciBjYXNlcywgZGlzYWdyZWVtZW50cyBhYm91dCANCj4gdGhlIGNvbmR1Y3Qgb2YgdGhlIFJT QUIgYXJlIG5vdCBzdWJqZWN0IHRvIGFwcGVhbC4NCg0K --------------cCxxJ78yK9g6jLyx4xuaY8yg Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------cCxxJ78yK9g6jLyx4xuaY8yg-- --------------YLXd9LCM5Wr2S2VCzwHFSLed-- --------------6yhjP049jU3h0v7X7BTuql0P Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGrKloFAwAAAAAACgkQh7ZrRtnSejOT Fgf/b4QizZkL76aPxVlB7QKNTjm2l/K6hltvb/3BQaidVT6iaxY77cwusM06R/UhfX8sElS51VPS 4yg7/uREUsXYAjZkMRrveX/aEJ01Nh9Ppp2r8FQMZVT7ncVlDO7zckPO3epgl9DDBy9VYvqpvUIA sq7DC4WO6d891rs7YPzU+stC8WcBAlwaYmbuMagbu7C1S7NqfsmnmjBMlRpw8gy6Vs+rsTJ1PRke VwxfOX8+4O4EjEhby+1dLG/NfXBjvh5arzeDXDY97oLulXfmc6kVfqlKbICslREh+HVDa0A1zt6A UOesStuhGFTaIYC6Unbs2frU2gPVCky6s/PfYbc/kQ== =wMTi -----END PGP SIGNATURE----- --------------6yhjP049jU3h0v7X7BTuql0P-- From nobody Sat Dec 4 00:47:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3B63A0CF6 for ; Sat, 4 Dec 2021 00:47:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f1brGhR8xL_a for ; Sat, 4 Dec 2021 00:47:46 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 1DD823A0CF3 for ; Sat, 4 Dec 2021 00:47:45 -0800 (PST) Received: from [192.168.0.132] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B48lhFn698486 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 4 Dec 2021 09:47:43 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638607663; bh=GUcmAKwDAj7qxD+Nw3jUGzmiD3uJlyAq7kx6QCqKEj8=; h=Date:Subject:From:To:References:In-Reply-To:From; b=TpBRi9K2iY642MmI+aBReHs+hdLgFeu8i7FUFss+vTCBKsAqRGs9tFQ1t7dqI3pZe vNmudtfWat8KNHPuRxuk438mfx+sUfICZIY2LQeePucrWNGbdLOsT2DAFNuqrWBwOF /NxK4JwgY53j5yQ9DuHiJBTog5rIWirqf4bqUGNE= Message-ID: Date: Sat, 4 Dec 2021 09:47:42 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US From: Eliot Lear To: "rfced-future@iab.org" References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------W0hPXn3w4W5jSFKmTHEcefaD" Archived-At: Subject: Re: [Rfced-future] cleaning up remaining issues: CONSENSUS CALL, Issue 93 comment please by December 18th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:47:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------W0hPXn3w4W5jSFKmTHEcefaD Content-Type: multipart/mixed; boundary="------------Wzu9VjdXAQZhrukIK4qXomBI"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: Subject: Re: cleaning up remaining issues: CONSENSUS CALL, Issue 93 comment please by December 18th References: In-Reply-To: --------------Wzu9VjdXAQZhrukIK4qXomBI Content-Type: multipart/mixed; boundary="------------8jdJSkMNM07ExotW2dCXcNdQ" --------------8jdJSkMNM07ExotW2dCXcNdQ Content-Type: multipart/alternative; boundary="------------FkZf6nlYBwbH0tszC00HvIEg" --------------FkZf6nlYBwbH0tszC00HvIEg Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T2ssIHRoYXQgd2FzIGJhZC7CoCBXZSBzdGlsbCBuZWVkIHRvIHJlc29sdmUgSXNzdWUgOTMg YnV0IGl0IHNlZW1zIHRoZSANCnRleHQgd2FzIGFscmVhZHkgaW5jb3Jwb3JhdGVkLiBJJ2xs IGNvbWUgYmFjayB3aXRoIGEgZGlmZmVyZW50IG1lc3NhZ2UgDQpzaG9ydGx5Lg0KDQpFbGlv dA0KDQoNCk9uIDA0LjEyLjIxIDA5OjQ0LCBFbGlvdCBMZWFyIHdyb3RlOg0KPiBQbGVhc2Ug Y29tbWVudCBieSBEZWNlbWJlciAxOHRoIGFib3V0IHdoZXRoZXIgeW91IHN1cHBvcnQgdGhl IA0KPiBmb2xsb3dpbmcgY2hhbmdlOg0KPg0KPiBPTEQNCj4NCj4+IERlY2lzaW9ucyBvZiB0 aGUgUlNBQiBjYW4gYmUgYXBwZWFsZWQgb24gZ3JvdW5kcyBvZiBmYWlsdXJlIHRvIGZvbGxv dyANCj4+IHRoZSBjb3JyZWN0IHByb2Nlc3MuIFdoZXJlIHRoZSBSU0FCIG1ha2VzIGEgZGVj aXNpb24gaW4gb3JkZXIgdG8gDQo+PiByZXNvbHZlIGEgZGlzcHV0ZSwgYXBwZWFscyBjYW4g YmUgZmlsZWQgb24gdGhlIGJhc2lzIHRoYXQgdGhlIFJTQUIgDQo+PiBtaXNpbnRlcnByZXRl ZCBhbiBhcHByb3ZlZCBwb2xpY3kuIEluIG90aGVyIGNhc2VzLCBkaXNhZ3JlZW1lbnRzIA0K Pj4gYWJvdXQgdGhlIGNvbmR1Y3Qgb2YgdGhlIFJTQUIgYXJlIG5vdCBzdWJqZWN0IHRvIGFw cGVhbC4NCj4NCj4gTkVXDQo+DQo+PiBEZWNpc2lvbnMgb2YgdGhlIFJTQUIgY2FuIGJlIGFw cGVhbGVkIG9uIGdyb3VuZHMgb2YgZmFpbHVyZSB0byBmb2xsb3cgDQo+PiB0aGUgY29ycmVj dCBwcm9jZXNzLiBXaGVyZSB0aGUgUlNBQiBtYWtlcyBhIGRlY2lzaW9uIGluIG9yZGVyIHRv IA0KPj4gcmVzb2x2ZSBhIGRpc3B1dGUsIGFwcGVhbHMgY2FuIGJlIGZpbGVkIG9uIHRoZSBi YXNpcyB0aGF0IHRoZSBSU0FCIA0KPj4gbWlzaW50ZXJwcmV0ZWQgYW4gYXBwcm92ZWQgcG9s aWN5LiBJbiBvdGhlciBjYXNlcywgZGlzYWdyZWVtZW50cyANCj4+IGFib3V0IHRoZSBjb25k dWN0IG9mIHRoZSBSU0FCIGFyZSBub3Qgc3ViamVjdCB0byBhcHBlYWwuDQo+DQo+DQo= --------------FkZf6nlYBwbH0tszC00HvIEg Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ok, that was bad.=C2=A0 We still need = to resolve Issue 93 but it seems the text was already incorporated.=C2= =A0 I'll come back with a different message shortly.

Eliot


On 04.12.21 09:44, Eliot Lear wrote:
Please comment by December 18th about whether you support the following change:

OLD

Decisions of the RSAB can be appealed on grounds of failure to follow the correct process. Where the RSAB makes a decision in order to resolve a dispute, appeals can be filed on the basis that the RSAB misinterpreted an approved policy. In other cases, disagreements about the conduct of the RSAB are not subject to appeal.

NEW

Decisions of the RSAB can be appealed on grounds of failure to follow the correct process. Where the RSAB makes a decision in order to resolve a dispute, appeals can be filed on the basis that the RSAB misinterpreted an approved policy. In other cases, disagreements about the conduct of the RSAB are not subject to appeal.


--------------FkZf6nlYBwbH0tszC00HvIEg-- --------------8jdJSkMNM07ExotW2dCXcNdQ Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------8jdJSkMNM07ExotW2dCXcNdQ-- --------------Wzu9VjdXAQZhrukIK4qXomBI-- --------------W0hPXn3w4W5jSFKmTHEcefaD Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGrKy4FAwAAAAAACgkQh7ZrRtnSejNO Gwf/ftezrO9D8HeyIezdJ1wgr/v0yK5Ji5nuOeseXnDk0jyMGU3A08ONgWBzKJWAhvHkrpqsEbIh zUThFDE8ypnijtjn6dY4nTd1FLE8dZRNF1qZkQkN7yxAzkO7AMlZ9f0eJcmkjD6dYYfA4K8iDorL iKwx5qByHAc+n+Rx0gA5SJA6gTna/jQJPXuXeOfZRlPqAJdYV2honCZXJNZsuhg9Y/tHHXdiX48p Ao/l80Mro5pYEf4GIeyJdPJuRTWz2G5v2oLzN3wZSgwX9DmqFHfexgLS7/jKuSnrjVT5jhk290xt CZvoAGPyGy8rc4KXZHPNm40/1WqajJcYJg9+i1ZpEQ== =Nq1H -----END PGP SIGNATURE----- --------------W0hPXn3w4W5jSFKmTHEcefaD-- From nobody Sat Dec 4 00:51:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EB8F3A0D0B for ; Sat, 4 Dec 2021 00:51:38 -0800 (PST) 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_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2skUCCp1qY1 for ; Sat, 4 Dec 2021 00:51:33 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 910973A0D15 for ; Sat, 4 Dec 2021 00:51:33 -0800 (PST) Received: from [192.168.0.132] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B48pV9R700534 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 4 Dec 2021 09:51:31 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638607891; bh=5LumsdOIgTg4bweiwgXsspR6MuxtIYbaDKZUiQ45iVM=; h=Date:To:From:Subject:From; b=DuTXG5H1f6TKf/EPx4Vko8A8hbxSmV0z+VabqOP6dPrVTP596tBeI8BIt39s8uFhR ktAbEWHO7mPomTDDZL9tEj2H/6nNTf2SjBU3j3SXGnyL9nhDWFs+Rw4aQ4Ls+oYlhF wBN5SEN4GGiH8Wd45S5+09EepO1kIQaPv/agfj3A= Message-ID: <80bcb751-c46f-9cba-ef0f-83ccd9e153ce@lear.ch> Date: Sat, 4 Dec 2021 09:51:30 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------VXGcDDN9vJQ5Q7y6x74bwaKB" Archived-At: Subject: [Rfced-future] Corrected. CONSENSUS CHECK on Issue 93 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:51:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------VXGcDDN9vJQ5Q7y6x74bwaKB Content-Type: multipart/mixed; boundary="------------8006KrWo0w8B0giNWU09ijWP"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: <80bcb751-c46f-9cba-ef0f-83ccd9e153ce@lear.ch> Subject: Corrected. CONSENSUS CHECK on Issue 93 --------------8006KrWo0w8B0giNWU09ijWP Content-Type: multipart/mixed; boundary="------------MK5WTyCobmnKaq5tFclAIvOV" --------------MK5WTyCobmnKaq5tFclAIvOV Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VGhlIGZvbGxvd2luZyBpcyBuZXcgdGV4dCBhYm91dCBSU0FCIGFwcGVhbHM6DQoNCiDCoMKg IERlY2lzaW9ucyBvZiB0aGUgUlNBQiBjYW4gYmUgYXBwZWFsZWQgb24gZ3JvdW5kcyBvZiBm YWlsdXJlIHRvIGZvbGxvdw0KIMKgwqAgdGhlIGNvcnJlY3QgcHJvY2Vzcy7CoCBXaGVyZSB0 aGUgUlNBQiBtYWtlcyBhIGRlY2lzaW9uIGluIG9yZGVyIHRvDQogwqDCoCByZXNvbHZlIGEg ZGlzYWdyZWVtZW50IGJldHdlZW4gYXV0aG9ycyBhbmQgdGhlIFJQQyAoYXMgZGVzY3JpYmVk DQogwqDCoCB1bmRlciBTZWN0aW9uIDQuNCksIGFwcGVhbHMgY2FuIGJlIGZpbGVkIG9uIHRo ZSBiYXNpcyB0aGF0IHRoZSBSU0FCDQogwqDCoCBtaXNpbnRlcnByZXRlZCBhbiBhcHByb3Zl ZCBwb2xpY3kuwqAgSW4gb3RoZXIgY2FzZXMsIGRpc2FncmVlbWVudHMNCiDCoMKgIGFib3V0 IHRoZSBjb25kdWN0IG9mIHRoZSBSU0FCIGFyZSBub3Qgc3ViamVjdCB0byBhcHBlYWwuDQoN ClRoaXMgdGV4dCB3YXMgaW5jb3Jwb3JhdGVkIGluIHRoZSBkcmFmdCwgYnV0IHdlIG5lZWQg dG8gY2hlY2sgY29uc2Vuc3VzIA0Kb24gaXQuwqAgUGxlYXNlIGNvbW1lbnQgYnkgdGhlIDE4 dGggb2bCoCBEZWNlbWJlci4NCg0KRWxpb3QNCg0K --------------MK5WTyCobmnKaq5tFclAIvOV Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------MK5WTyCobmnKaq5tFclAIvOV-- --------------8006KrWo0w8B0giNWU09ijWP-- --------------VXGcDDN9vJQ5Q7y6x74bwaKB Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGrLBIFAwAAAAAACgkQh7ZrRtnSejP2 twgAhCcSi39N3VS7N/GsL0NwRFMkSiK9Y0Uo66p6HocS18vetLgCI52fP123Hiws6gqmoM1q5Tk1 wTwXSWLRBxBYLi2EsLXqB3nBsxS+uKBALHHcW7Us1TSKK3U1bc0SNC1447DogcwtJQ/Dt89Zkopg 0gLfGc7Uwe9ChdF/Eyt834lCRnJtp5jszeI5hiuvih1Md6BGC7DVe9L2Merj7XS/Asx+MeaXQiMs dqIn1DMSSWevlJvP2bLNBDIQkmhTAZ/czM/vgceVM0q8vSIDk0O99uCq1MCIOUQXZyGxnyv5wFqz z7gxEwV7OUb56BhZWhi5Ip4QiDjUiN/kas0jY4z/ZA== =2OnQ -----END PGP SIGNATURE----- --------------VXGcDDN9vJQ5Q7y6x74bwaKB-- From nobody Sat Dec 4 00:58:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECB2B3A0D34 for ; Sat, 4 Dec 2021 00:58:27 -0800 (PST) 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_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KPxLEJFAeKBC for ; Sat, 4 Dec 2021 00:58:23 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 47C923A0D35 for ; Sat, 4 Dec 2021 00:58:23 -0800 (PST) Received: from [192.168.0.132] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B48wKsY703602 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Sat, 4 Dec 2021 09:58:20 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638608300; bh=MUsIiLlVgxk6Utn9UA6Xq2XbLO6pPvDG75qnmO5Gwwk=; h=Date:To:From:Subject:From; b=hJGDGxlOdYu2mQYzbAAQeF1zzKLXYJEx6qd5Ajro6IxNVBTWJnAp5+KHNPm56OMNj HSSPBd/+NKiteuMinsGsnal7aCi58Is8eeJCwHF190+qsjmx3O+bO4TC5rnGaehop3 U8kl8/sRf2aqHtZ6knho/zLhkPwTrqRwuWnP6VPs= Message-ID: <7ed658ef-c6e5-4295-76e4-aeeb7d3248a7@lear.ch> Date: Sat, 4 Dec 2021 09:58:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------pqxui6bxhRrblQEN3iGpxgdy" Archived-At: Subject: [Rfced-future] Consensus check: Issue 94 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:58:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------pqxui6bxhRrblQEN3iGpxgdy Content-Type: multipart/mixed; boundary="------------HCRterGXCvAbvnFs1v6uJJ6l"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: <7ed658ef-c6e5-4295-76e4-aeeb7d3248a7@lear.ch> Subject: Consensus check: Issue 94 --------------HCRterGXCvAbvnFs1v6uJJ6l Content-Type: multipart/mixed; boundary="------------nuZ5pAIE6YlknVsvIvNSV00a" --------------nuZ5pAIE6YlknVsvIvNSV00a Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VGhpcyByZWxhdGVzIHRvIFNlY3Rpb24gNC40DQoNCk9MRDoNCg0KPiBJZiB0aGUgZGlzYWdy ZWVtZW50IHJhaXNlcyBhIG5ldyBpc3N1ZSB0aGF0IGlzIG5vdCBjb3ZlcmVkIGJ5IGFuDQo+ IGV4aXN0aW5nIHBvbGljeSBvciB0aGF0IGNhbm5vdCBiZSByZXNvbHZlZCB0aHJvdWdoIGNv bnN1bHRhdGlvbg0KPiBiZXR3ZWVuIHRoZSBSUEMgYW5kIG90aGVyIHJlbGV2YW50IGluZGl2 aWR1YWxzIGFuZCBib2RpZXMgKGFzDQo+IGRlc2NyaWJlZCBhYm92ZSksIHRoZSBpc3N1ZSBz aG91bGQgYmUgYnJvdWdodCB0byB0aGUgUlNXRyBpbiBvcmRlcg0KPiB0byBmb3JtdWxhdGUg YSBuZXcgcG9saWN5LsKgIEhvd2V2ZXIsIGluIHRoZSBpbnRlcmVzdCBvZiB0aW1lIHRoZQ0K PiBkaXNhZ3JlZW1lbnQgbWF5IGJlIHJlc29sdmVkIGFzIHRoZSBwYXJ0aWVzIGJlc3Qgc2Vl IGZpdCB3aGlsZSB0aGUNCj4gUlNXRyBmb3JtdWxhdGVzIGEgbW9yZSBnZW5lcmFsIHBvbGlj eS4NCj4NCk5FVw0KDQo+IElmIHRoZSBkaXNhZ3JlZW1lbnQgcmFpc2VzIGEgbmV3IGlzc3Vl IHRoYXQgaXMgbm90IGNvdmVyZWQgYnkgYW4NCj4gZXhpc3RpbmcgcG9saWN5IG9yIHRoYXQg Y2Fubm90IGJlIHJlc29sdmVkIHRocm91Z2ggY29uc3VsdGF0aW9uDQo+IGJldHdlZW4gdGhl IFJQQyBhbmQgb3RoZXIgcmVsZXZhbnQgaW5kaXZpZHVhbHMgYW5kIGJvZGllcyAoYXMNCj4g ZGVzY3JpYmVkIGFib3ZlKSwgdGhlIFJTQUIgc2hvdWxkIGJyaW5nIHRvIHRoZSBSU1dHIGlu IG9yZGVyDQo+IHRvIGZvcm11bGF0ZSBhIG5ldyBwb2xpY3kuIEhvd2V2ZXIsIGlmIG5lZWRl ZCwgaW4gdGhlIGludGVyZXN0IG9mDQo+IHRpbWUgdGhlIFJTQUIgaXMgcmVzcG9uc2libGUg Zm9yIHJlc29sdmluZyB0aGUgZGlzYWdyZWVtZW50IGJlZm9yZQ0KPiBhIG5ldyBwb2xpY3kg aXMgZGVmaW5lZC4NCg0KUGxlYXNlIGNvbW1lbnQgYnkgRGVjZW1iZXIgMTh0aC4NCg0KRWxp b3QNCg0K --------------nuZ5pAIE6YlknVsvIvNSV00a Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------nuZ5pAIE6YlknVsvIvNSV00a-- --------------HCRterGXCvAbvnFs1v6uJJ6l-- --------------pqxui6bxhRrblQEN3iGpxgdy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGrLawFAwAAAAAACgkQh7ZrRtnSejNp cQgAiIsejr4ZsvzOrz31kMkvgjqudos5MbXIXEmI3WCQSVb9laRus8Kl24PpVFtc97ppXMxDv9vs JUCKj7y6zRQTcJ/1k+3E6nERYF/OLJ9q+j++JZPtdqMJP4aSl74F72Mdp6/y1byjejhCsojrQ4oJ w+HINHxNy51lGDeb9OqZG6+20YwlRJtZyy33/O0oTY/I4Vghp49zqJVV54t9faX7euIlWsNmc0h3 Q8vuQEwGYKXcWxkahQpP+AztBZMDqGTS5qm8RF2jNJdVvED/s7d0KE0YIw8ZNK57Ie18Tg2DL8Rc WynOC4GA3LsbyErxUL5DW19xNoPG5xTZvFwDtsCDYQ== =C+RH -----END PGP SIGNATURE----- --------------pqxui6bxhRrblQEN3iGpxgdy-- From nobody Sat Dec 4 01:07:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91AE43A003E for ; Sat, 4 Dec 2021 01:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_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 Xvc4I5Rsm1qc for ; Sat, 4 Dec 2021 01:07:51 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A9DD3A003B for ; Sat, 4 Dec 2021 01:07:50 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1B497lQC017020; Sat, 4 Dec 2021 09:07:47 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 7C4764604F; Sat, 4 Dec 2021 09:07:47 +0000 (GMT) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6FB844604D; Sat, 4 Dec 2021 09:07:47 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs1.iomartmail.com (Postfix) with ESMTPS; Sat, 4 Dec 2021 09:07:47 +0000 (GMT) Received: from LAPTOPK7AS653V ([84.93.2.155]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1B497k4Y020633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 4 Dec 2021 09:07:47 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <7ed658ef-c6e5-4295-76e4-aeeb7d3248a7@lear.ch> In-Reply-To: <7ed658ef-c6e5-4295-76e4-aeeb7d3248a7@lear.ch> Date: Sat, 4 Dec 2021 09:07:45 -0000 Organization: Old Dog Consulting Message-ID: <01f301d7e8ee$67b514a0$371f3de0$@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: AQMxwt8N3TpUEjNX2m/KR5jL2g+BrqluVdvQ X-Originating-IP: 84.93.2.155 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26568.006 X-TM-AS-Result: No--8.882-10.0-31-10 X-imss-scan-details: No--8.882-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26568.006 X-TMASE-Result: 10--8.881800-10.000000 X-TMASE-MatchedRID: y/2oPz6gbvi8rRvefcjeTb7u5vMMMVTtaMmm586o4gAFd/lI0BeWVs8O alpDJEQlQ3fcoyc9qnBib/WzqZVChN2zNEXBxNvnLIrMljt3adtK0YCCYqpa5X9m2VdNqkg/+/K qneiC8jalPtLdOasotOizsiQoq4e/6yZu0IoqsWkK3Ma88LL+bvZfafJjZZIJY0OqNc47Rh6MTI HTD4MCVsKj1B/kFXP70/NbBMSkGddYv9JmZ/s9sMzWN98iBBeG5bMmdOYs/G8PnmQH7HRKM4o5B SI6pnHYGtPsII7bpSH1fsx0fFEH/oZKkFFIbQIAngIgpj8eDcDaf1N18C+ZArDszp3K5gqDjocz muoPCq0nDhaossYyQXZI68ZGIaGXWkhKMO4UmazCEzuaeGgHQRFrGBau9Z58DOvXZQGB4C/5tiH I3EW+8LWzl/CZOgTrzFXf45yUG1GvY4BboIs67rHhMA9aDpuh/WyINg5Mqdqespy8+E36a0PhZp 6NP5kf X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 94 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 09:07:57 -0000 I think there are errors of English in this. I also think that "should" is loose. The intention is probably that the = "However" sentence is the only let-out from the "should", but the text = doesn't read like that. The RSAB is unlikely to resolve the disagreement, but they could resolve = the issue. How about... > If the disagreement raises a new issue that is not covered by an > existing policy or that cannot be resolved through consultation > between the RPC and other relevant individuals and bodies (as > described above), the RSAB shall bring the issue to the RSWG in > order to formulate a new policy. However, if needed, in the > interest of time the RSAB may resolve the issue before the RSWG > has defined a new policy. Cheers, Adrian -----Original Message----- From: Rfced-future On Behalf Of Eliot = Lear Sent: 04 December 2021 08:58 To: rfced-future@iab.org Subject: [Rfced-future] Consensus check: Issue 94 This relates to Section 4.4 OLD: > If the disagreement raises a new issue that is not covered by an > existing policy or that cannot be resolved through consultation > between the RPC and other relevant individuals and bodies (as > described above), the issue should be brought to the RSWG in order > to formulate a new policy. However, in the interest of time the > disagreement may be resolved as the parties best see fit while the > RSWG formulates a more general policy. > NEW > If the disagreement raises a new issue that is not covered by an > existing policy or that cannot be resolved through consultation > between the RPC and other relevant individuals and bodies (as > described above), the RSAB should bring to the RSWG in order > to formulate a new policy. However, if needed, in the interest of > time the RSAB is responsible for resolving the disagreement before > a new policy is defined. Please comment by December 18th. Eliot From nobody Sat Dec 4 03:39:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A673A0786 for ; Sat, 4 Dec 2021 03:39:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=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, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4RrreWwkLGGE for ; Sat, 4 Dec 2021 03:39:31 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 83D7E3A0781 for ; Sat, 4 Dec 2021 03:39:29 -0800 (PST) Received: from [192.168.0.132] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B4BdRpr782193 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 4 Dec 2021 12:39:27 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638617967; bh=P3jCmwR0MPfL6EyLqaCLwRT/h8IMAdS4GMbVjYTuYRY=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=G6qxuiefB9AA0r+KdKpLp+BC0TlbFhrO3hhX1+t+FCXnxK+UkfSs5u9gkkadLvYxP /KhjD4SIrWfRSBp5yOjRo4UeCaNe+GcTWgHNDBjVW01Xjy830t4FWgkaePghwAV6Xb YY7gOBmxrosKxqSEme9QAhu/yqaWkVU3VI81I/j0= Message-ID: <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> Date: Sat, 4 Dec 2021 12:39:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Mark Nottingham Cc: Mirja Kuehlewind , rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> From: Eliot Lear In-Reply-To: <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------pygW0UquOxSMvfJRb0a9Yp4V" Archived-At: Subject: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 11:39:37 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------pygW0UquOxSMvfJRb0a9Yp4V Content-Type: multipart/mixed; boundary="------------KMhFjda80emnUfhfkNxo12X4"; protected-headers="v1" From: Eliot Lear To: Mark Nottingham Cc: Mirja Kuehlewind , rfced-future@iab.org Message-ID: <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> Subject: Issue 134: Re: [Rfced-future] How can this process be changed? References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> In-Reply-To: <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> --------------KMhFjda80emnUfhfkNxo12X4 Content-Type: multipart/mixed; boundary="------------cQhxxcCXyiU0XtW8sKt2JM8N" --------------cQhxxcCXyiU0XtW8sKt2JM8N Content-Type: multipart/alternative; boundary="------------ZQTKw6ivYBfQAFlg0JFtNhWx" --------------ZQTKw6ivYBfQAFlg0JFtNhWx Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 UmV0dXJuaW5nIHRvIHRoaXM6DQoNCk9uIDEyLjExLjIxIDAzOjM5LCBNYXJrIE5vdHRpbmdo YW0gd3JvdGU6DQo+IEkgdGhpbmsgZXhwbGljaXRseSBzYXlpbmcgdGhhdCBzdWNoIGNoYW5n ZXMgYXJlIGluIHNjb3BlIGZvciBkaXNjdXNzaW9uIGluIHRoZSBSU1dHIGlzIHdvcnRod2hp bGUsIGdpdmVuIHRoZSB1bmNlcnRhaW50eSB0aGF0IHdlJ3ZlIHNlZW4gc28gZmFyLg0KDQpU aGUgcHJvcG9zZWQgdGV4dDoNCg0KPiBVcGRhdGVzLCBhbWVuZG1lbnRzIGFuZCByZWZpbmVt ZW50cyBvZiB0aGlzIGRvY3VtZW50IGNhbiBiZSBwcm9kdWNlZCANCj4gdXNpbmcgdGhlIHBy b2Nlc3MgZG9jdW1lbnRlZCBoZXJlLCBidXQgYXJlIG9ubHkgb3BlcmF0aXZlIHVwb24gDQo+ IGFncmVlbWVudCBvZiB0aGUgSUFCLCB0aGUgSUVTRywgYW5kIHRoZSBJRVRGIExMQy4gTm90 ZSB0aGF0IHRoaXMgZG9lcyANCj4gbm90IHByZWNsdWRlIHN1Y2ggY2hhbmdlcyBmcm9tIGJl aW5nIGRlZmluZWQgb3V0c2lkZSB0aGlzIHByb2Nlc3MsIHNvIA0KPiBsb25nIGFzIHRoZSBz YW1lIGFncmVlbWVudCBpcyBmb3VuZC4NCg0KQmFzZWQgb24geW91ciBlbGFib3JhdGlvbiBh bmQgdGhlIHRleHQsIEkgdW5kZXJzdGFuZCB0aGUgaW50ZW50IHRvIGJlOg0KDQogICogVGhl IElBQiwgSUVTRywgYW5kIExMQyBtdXN0IGFwcHJvdmUgY2hhbmdlcyB0byB0aGUgcHJvY2Vz cyBkZWZpbmVkDQogICAgaW4gdGhpcyBkb2N1bWVudC4NCiAgKiBQcm9wb3NhbHMgZm9yIGNo YW5nZSBtYXkgY29tZSBmcm9tIG91dHNpZGUgdGhlIFJTV0cgYW5kIFJTQUIgaW4gY2FzZQ0K ICAgIHRoZXJlIGlzIHNvbWUgcHJvY2VzcyBmYWlsdXJlIHdpdGhpbiB0aGUgUlNXRyBhbmQg UlNBQi4NCiAgKiBJdCBpcyB3aXRoaW4gc2NvcGUgZm9yIHRoZSBSU1dHIGFuZCBSU0FCIHRv IGRpc2N1c3MgcHJvcG9zZWQgY2hhbmdlcy4NCg0KQW5kIHNvIG15IHF1ZXN0aW9uIGlzIHRo aXM6DQoNCiAgKiBXaHkgd291bGQgYW55b25lIHVzZSB0aGUgcHJvY2VzcyBkZWZpbmVkIGlu IHRoaXMgZG9jdW1lbnQgd2hlbiB0aGV5DQogICAgY2FuIGJ5cGFzcyBpdD/CoCBUaGF0IGp1 c3QgYWRkcyBhZGRpdGlvbmFsIGFwcHJvdmFscy4NCg0KRG8geW91IG1lYW4sIHJhdGhlcjoN Cg0KPiBVcGRhdGVzLCBhbWVuZG1lbnRzIGFuZCByZWZpbmVtZW50cyBvZiB0aGlzIGRvY3Vt ZW50IHJlcXVpcmUgYWdyZWVtZW50IA0KPiBvZiB0aGUgSUFCLCB0aGUgSUVTRywgYW5kIHRo ZSBJRVRGIExMQy7CoCBUaGUgUlNXRyBhbmQgUlNBQiBtYXkgZGlzY3VzcyANCj4gcHJvcG9z ZWQgY2hhbmdlcy4NCg0KPw0KDQpBbHNvLCBJIHJlY2FsbCB0aGF0IHRoZXJlIHdhcyBhIHF1 ZXN0aW9uIGFzIHRvIHdoZXRoZXIgdGhlIExMQyBzaG91bGQgYmUgDQppbiB0aGUgYXBwcm92 YWwgY2hhaW4uwqAgV2hhdCBkbyBwZW9wbGUgdGhpbms/DQoNCkVsaW90DQoNCg== --------------ZQTKw6ivYBfQAFlg0JFtNhWx Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Returning to this:

On 12.11.21 03:39, Mark Nottingham wrote:
I think explicitly saying th=
at such changes are in scope for discussion in the RSWG is worthwhile, gi=
ven the uncertainty that we've seen so far.

The proposed text:

Updates, amendments and refinements of this document can be produced using the process documented here, but are only operative upon agreement of the IAB, the IESG, and the IETF LLC. Note that this does not preclude such changes from being defined outside this process, so long as the same agreement is found.

Based on your elaboration and the text, I understand the intent to be:

  • The IAB, IESG, and LLC must approve changes to the process defined in this document.
  • Proposals for change may come from outside the RSWG and RSAB in case there is some process failure within the RSWG and RSAB.
  • It is within scope for the RSWG and RSAB to discuss proposed changes.

And so my question is this:

  • Why would anyone use the process defined in this document when they can bypass it?=C2=A0 That just adds additional approvals.

Do you mean, rather:

Updates, amendments and refinements of this document require agreement of the IAB, the IESG, and the IETF LLC.=C2=A0 The RSWG and RSAB may discuss proposed changes.

?

Also, I recall that there was a question as to whether the LLC should be in the approval chain.=C2=A0 What do people think?

Eliot

--------------ZQTKw6ivYBfQAFlg0JFtNhWx-- --------------cQhxxcCXyiU0XtW8sKt2JM8N Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------cQhxxcCXyiU0XtW8sKt2JM8N-- --------------KMhFjda80emnUfhfkNxo12X4-- --------------pygW0UquOxSMvfJRb0a9Yp4V Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGrU2oFAwAAAAAACgkQh7ZrRtnSejPZ Xwf+Kq0sht7w/qkUwXKVbKo8QJ0h625W4cK3cTWp054N0B4mWBRkt+1Y8AxW65Iz8R2QfQdomryY Mo14fcSfo11dLxHlV6jcm9/RWWS+Bv2QCrxcpDX/HGOZQl+AUo0q0G9AJSqA9QV2weSt8CaGINVH qSnA0yzNKtqTobpwnQey+RgVr6ygG+NymTcZHyYbALKoMoO0BROfBpQtL0s0VRLuzyWlUzB0kAke SW0/nOuKb+6foymVAW+q4i4zeRcVgmAxs2PPn49bMK8VkBYVQzyA+77PAiVKGfcY/nejm2Q/uVxI zvqbWiZAcyz/Kqr1T2xENTqLkhaZj2TxzJU1TKhkkw== =DhP5 -----END PGP SIGNATURE----- --------------pygW0UquOxSMvfJRb0a9Yp4V-- From nobody Sat Dec 4 11:58:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAA83A082A for ; Sat, 4 Dec 2021 11:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 5fzDVoQt5bLX for ; Sat, 4 Dec 2021 11:58:04 -0800 (PST) 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 B410C3A0821 for ; Sat, 4 Dec 2021 11:58:04 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id 137so6491650pgg.3 for ; Sat, 04 Dec 2021 11:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PdyDy9sCID553nl6wgWTbgclwRT0OMupzQttS523FOk=; b=NGqMgSVtOWrO11jLOwVBHu3MiN2bY74esr0UWCb6gHzjc8oZrRt+JU/kUe/ab+D1Zn 8sHkvquEefPxzbSyFLtkJIVdkelwENn2oycrOxEH3iNEWEicrT6MRnexp/VkjXeP07Ml XDcJbvZ8crwBuwNOao72fdwwV6YQIg65KFMibzY7C9ukELs9Pf91yITkWnlC3qsZTuXr +3IQFnonqnshHDnPLhQsmrgwsDy7xlEk+q0J2L5Ds4/UbHuYcayQwvagQekr7gNIfV6P ugwS76KoiO/hTr2iTARZ9XTM3eOd/DM2NJuW21XKrp7xAIwTnXnre5JlaA+ElIOxSzjl U95A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=PdyDy9sCID553nl6wgWTbgclwRT0OMupzQttS523FOk=; b=kdfmXzm1WjUbDMNr0hvgpuAnWbcjAFHpFzdigiA/EDILmjxJiLhIVT5PD8uCgN8biz 01xwIpASkIUmfwWl+6auJDdSTOPRWa1SjNgWbSPF7SbKD7oTeM1ThTaUxM5dK4w8iFMy E5HwxW2MwPN8DX6WBYQ9262GrCvJvtCSmDOmQOHLc7yrr3rol2Erf03pP3aAKFZpCPFa /Az+g/6wQiOK8pnlzFpOwJO7HYxSsAR623J8bFHoRvXtSpoBs0se7utQ7CZdTa8ym3rh 3NP8+g4xe6joF7x1IqW32MYP8yeyJpFEvc56oW6wIfQhP6h30msjoKp/1L2e3Z4mdv1e jicw== X-Gm-Message-State: AOAM533HN1zdxsFy2qcwRxCro4gNQKHEQz6xTOj4KnE0z0mE/tn13R/M cW2zR8d9PcWCkueCuw4Z/mZh8Z4FTFmiMw== X-Google-Smtp-Source: ABdhPJzWMliMew4tJ42IxkFk7Y4lNMpo5vHSkWav4eV12doC9u+AIqYP73GdJyBPvbqchtMzS+I+YA== X-Received: by 2002:aa7:9416:0:b0:4a8:3012:80b6 with SMTP id x22-20020aa79416000000b004a8301280b6mr27214040pfo.6.1638647882980; Sat, 04 Dec 2021 11:58:02 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id on6sm10382998pjb.47.2021.12.04.11.58.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Dec 2021 11:58:02 -0800 (PST) To: Eliot Lear , "rfced-future@iab.org" References: <80bcb751-c46f-9cba-ef0f-83ccd9e153ce@lear.ch> From: Brian E Carpenter Message-ID: <9d89d65b-dc14-01b1-e7a7-71f7631211c5@gmail.com> Date: Sun, 5 Dec 2021 08:57:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <80bcb751-c46f-9cba-ef0f-83ccd9e153ce@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Corrected. CONSENSUS CHECK on Issue 93 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:58:07 -0000 On 04-Dec-21 21:51, Eliot Lear wrote: > The following is new text about RSAB appeals: >=20 > =C2=A0=C2=A0 Decisions of the RSAB can be appealed on grounds of fail= ure to follow > =C2=A0=C2=A0 the correct process.=C2=A0 Where the RSAB makes a decisi= on in order to > =C2=A0=C2=A0 resolve a disagreement between authors and the RPC (as d= escribed > =C2=A0=C2=A0 under Section 4.4), appeals can be filed on the basis th= at the RSAB > =C2=A0=C2=A0 misinterpreted an approved policy.=C2=A0 In other cases,=20 disagreements > =C2=A0=C2=A0 about the conduct of the RSAB are not subject to appeal.= >=20 > This text was incorporated in the draft, but we need to check consensus= > on it.=C2=A0 Please comment by the 18th of=C2=A0 December. I'm not sure I understand the last sentence. It isn't completely obvious what "In other cases" is referring to. If the intention is to say "There are no other grounds for appeal against decisions of the RSAB." then could we say that? Also, what redress exists against an RSAB that takes decisions outside its competence? Would that be "failure to follow the correct process"? Brian C From nobody Sat Dec 4 12:04:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9114E3A083D for ; Sat, 4 Dec 2021 12:04:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 ETt6obUZ1hsD for ; Sat, 4 Dec 2021 12:04:29 -0800 (PST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5873A083C for ; Sat, 4 Dec 2021 12:04:29 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id np6-20020a17090b4c4600b001a90b011e06so5245826pjb.5 for ; Sat, 04 Dec 2021 12:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=AVyepuL51UcE0AuLnMkRcgXUoi+sCO6wQbcT7fXjlY4=; b=Ive2LZnTOjNWDmTH390yEzBhINylqHGoRl2xI3Sp9PKqwS0yrMWre+s/iRWKYnQxoo a2z8Znin1DBK0iiWlqM3H7P63cFlFZOxE5aDhtv4VAwHLol6yhsCf19Yo/TqxODDYQru PU9keYOtFq18dsEX+ZFZb9CsvNIu46sb5JT02sSb462MNSmryxkM4E9lmlGIZleT/MKb w2yamSDwbXL82e+FLW2wQX08jmrwu2rk+biD+PhmtvB+9qfhntxnKPdFIBcQ3Hr1W9qo SN+f1elkvVbkIXnHNgENilQjMo1bt2y/hKCy81huxSsNNQp5aOrIdyRz9EIKp580hjiS l/zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=AVyepuL51UcE0AuLnMkRcgXUoi+sCO6wQbcT7fXjlY4=; b=OEAUapmjDkSs0NlrW/vythYS/yMzLt7hY2hiJu9i46rxF+YqZHtEtNUVm11oqIoAax y2yUCE6yqrZQc8CoOKIlJqDEk84ipVGAjITtdvejdMWs7hZS7UcLYGgq4Uwrm7YKaYaF kzQ4QPGum4sSDsnN3GgbXgn4uXymdr4pt5VJ+5U/CyjQBPCAVmAzvtzH8oYaR93vNbTI c0F2SO+2TVtg5DObQ5Aj3ScGz+dyMytNfDZogyPROPZ9nI2Fuox/xw/CTqmrE+eLCG3p qvI/W0zvoSAryPJpuuucx2GKS/FFB6YUIHPiTT6PiEid256AhPW7/B1jVltS7Qa/ihhT jVZg== X-Gm-Message-State: AOAM531GOYWOfp02TSscQ+SAVf6Na/RbnWrXGX7O1QBHgBKcLmuURjtN R/rSOBeWjyEuSUIxeHlKatgUYxhRzZnxnA== X-Google-Smtp-Source: ABdhPJw4Hi7sypBAj0WOtf5fJ2mLhlk6rMwIKoHIeOSE2xdmmp0NbyjfKJH8pgeV5M2GeBBnkevIyQ== X-Received: by 2002:a17:902:e8d8:b0:142:5622:f9e5 with SMTP id v24-20020a170902e8d800b001425622f9e5mr32442416plg.42.1638648266428; Sat, 04 Dec 2021 12:04:26 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 199sm5604717pgb.22.2021.12.04.12.04.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Dec 2021 12:04:25 -0800 (PST) To: adrian@olddog.co.uk, 'Eliot Lear' , rfced-future@iab.org References: <7ed658ef-c6e5-4295-76e4-aeeb7d3248a7@lear.ch> <01f301d7e8ee$67b514a0$371f3de0$@olddog.co.uk> From: Brian E Carpenter Message-ID: <99bb99f1-f7fd-d605-cfbc-f2da04d14fa0@gmail.com> Date: Sun, 5 Dec 2021 09:04:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <01f301d7e8ee$67b514a0$371f3de0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Consensus check: Issue 94 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:04:34 -0000 I agree with Adrian, but one more bit of wordsmithing: On 04-Dec-21 22:07, Adrian Farrel wrote: > I think there are errors of English in this. > I also think that "should" is loose. The intention is probably that the "However" sentence is the only let-out from the "should", but the text doesn't read like that. > The RSAB is unlikely to resolve the disagreement, but they could resolve the issue. > How about... > >> If the disagreement raises a new issue that is not covered by an >> existing policy or that cannot be resolved through consultation >> between the RPC and other relevant individuals and bodies (as >> described above), the RSAB shall bring the issue to the RSWG in >> order to formulate a new policy. However, if needed, in the >> interest of time the RSAB may resolve the issue before the RSWG >> has defined a new policy. I'd make the last sentence more explicit: However, if needed due to urgency, the RSAB may resolve the issue before the RSWG has defined a new policy. (Do we need to clarify that this is a decision subject to appeal?) Regards Brian C > > Cheers, > Adrian > > -----Original Message----- > From: Rfced-future On Behalf Of Eliot Lear > Sent: 04 December 2021 08:58 > To: rfced-future@iab.org > Subject: [Rfced-future] Consensus check: Issue 94 > > This relates to Section 4.4 > > OLD: > >> If the disagreement raises a new issue that is not covered by an >> existing policy or that cannot be resolved through consultation >> between the RPC and other relevant individuals and bodies (as >> described above), the issue should be brought to the RSWG in order >> to formulate a new policy. However, in the interest of time the >> disagreement may be resolved as the parties best see fit while the >> RSWG formulates a more general policy. >> > NEW > >> If the disagreement raises a new issue that is not covered by an >> existing policy or that cannot be resolved through consultation >> between the RPC and other relevant individuals and bodies (as >> described above), the RSAB should bring to the RSWG in order >> to formulate a new policy. However, if needed, in the interest of >> time the RSAB is responsible for resolving the disagreement before >> a new policy is defined. > > Please comment by December 18th. > > Eliot > > From nobody Sat Dec 4 12:09:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A61533A085D for ; Sat, 4 Dec 2021 12:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 P5JM6P8r1SXD for ; Sat, 4 Dec 2021 12:09:49 -0800 (PST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 59B123A0854 for ; Sat, 4 Dec 2021 12:09:49 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id v23so4842351pjr.5 for ; Sat, 04 Dec 2021 12:09:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=l4w4ffIbV+bUgh2sSdlrl4J7fU5fs6urzA/rVfmcwP4=; b=kTbupyKoCanJeBJGsFNsMThoGgqvfVlEQUVNFK9XB75LeoteUNsgl6LzF8dHWbLHnz A3Jvyca17R9q3KLIeYmrgdDyTc5Cb65wqzf/6QcKeDFvTq+LusdDVICODATfPLBo4yZ2 ujmMWcfnu87N2QEcoUqDRkjGiPIgWpJDTwuRh9Alox/Ksn7GvAQEZhy+lMGk6Nti21Uc xaQDlLIg+fchLmFRYW8qi+hcNTvbWwbXqaqYM68aFoPbejgqNadPipJ8/xt/IFdttHqE nGuZ57ah/IgCnXM0DKu33kr0V1I+83y5e4jifo2CMwn9UX1W2gm2c30IhqYcw221MgaS chTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=l4w4ffIbV+bUgh2sSdlrl4J7fU5fs6urzA/rVfmcwP4=; b=y1zsiVNawYGTojLkSbNymGCoWeIbmwcjLYwOROBVMCY8D75xKDu2B37g+CAvhtt4S3 P8QiQIUDZ5uoGgy43fcYRUoeSInuW00NyHDCQsM0dcNpHfahOVudMsoLDx6Qnn1EPyKX tx4RJLyLDCCpvPWUAoMfI5+M7Wz2zrV1qjdJDjfR7a7NJIUDeAlTTdNlNgNI+e+5D85G vnO3D7MddwqIciZ1/Q5lzJZCto6engVkgida4yvdP3nyTu/jeBi29wkOSLbWUZdHT1d4 ughR4RjBe2zXCUjacZ6MET2QWFI6fPWFSHDGrhXOR+3GmnUjs1w3JDWAwXfIvDM9z/4/ LaYg== X-Gm-Message-State: AOAM533XZ7byuigtqRp/h5aSdWO0MFhosqzYdNNAHgGy8Oke0hrFjMIX DVf0N4sZC2qZJfeQCxI8Pr8G7Mzh9TZg6g== X-Google-Smtp-Source: ABdhPJw7YtUazdOb74w0WI4dS70ytqg3JiTH9OeWvBanTd1KrjkD5CmdS2QnHfP67buCgc5fasRJtQ== X-Received: by 2002:a17:90b:3149:: with SMTP id ip9mr24418546pjb.77.1638648585816; Sat, 04 Dec 2021 12:09:45 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j10sm7126730pfj.106.2021.12.04.12.09.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Dec 2021 12:09:45 -0800 (PST) To: Eliot Lear , Mark Nottingham Cc: rfced-future@iab.org, Mirja Kuehlewind References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> From: Brian E Carpenter Message-ID: Date: Sun, 5 Dec 2021 09:09:40 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:09:51 -0000 On 05-Dec-21 00:39, Eliot Lear wrote: > Returning to this: >=20 > On 12.11.21 03:39, Mark Nottingham wrote: >> I think explicitly saying that such changes are in scope for discussio= n in the RSWG is worthwhile, given the uncertainty that we've seen so far= =2E >=20 > The proposed text: >=20 >> Updates, amendments and refinements of this document can be produced u= sing the process documented here, but are only operative upon agreement o= f the IAB, the IESG, and the IETF LLC. Note that this does not preclude s= uch changes from being defined outside this process, so long as the same = agreement is found. >=20 > Based on your elaboration and the text, I understand the intent to be: >=20 > * The IAB, IESG, and LLC must approve changes to the process defined = in this document. > * Proposals for change may come from outside the RSWG and RSAB in cas= e there is some process failure within the RSWG and RSAB. > * It is within scope for the RSWG and RSAB to discuss proposed change= s. >=20 > And so my question is this: >=20 > * Why would anyone use the process defined in this document when they=20 can bypass it?=C2=A0 That just adds additional approvals. >=20 > Do you mean, rather: >=20 >> Updates, amendments and refinements of this document require agreement=20 of the IAB, the IESG, and the IETF LLC.=C2=A0 The RSWG and RSAB may discu= ss proposed changes. >=20 > ? That seems sufficient to me, but... =20 > Also, I recall that there was a question as to whether the LLC should b= e in the approval chain.=C2=A0 What do people think? The LLC exists to serve the community, so the LLC cannot have a veto, but=20 their opinion about feasibility must be heard. I'm not quite sure how bes= t to word that. Brian C From nobody Sat Dec 4 15:33:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384503A0C45 for ; Sat, 4 Dec 2021 15:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 ZohJr858WMXj for ; Sat, 4 Dec 2021 15:32:57 -0800 (PST) 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 40D1A3A0C44 for ; Sat, 4 Dec 2021 15:32:57 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id jo22so6439959qvb.13 for ; Sat, 04 Dec 2021 15:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=Oa9eWY4ag17TuxyTSddIF/Dgx2DUX4n4lLHBZz47EQ8=; b=H9vHjnX+L24OXLDDur51/DH0HcMV9qLTR9mFb+EgUdthMX3mOJgiqwsUJwKP2d9/IU 6rAf5wnHWhTRiNv9FzY1d2ag74pvuFLlYEpGKVsgoRGyUmGFi92pLCIPQupWQfUclp45 pId4CLmN7Z6XNtsDWTx7dz7NuTwjoaIHCqACf07JXDVJ3laemGWZ151emhbM/cSWrsyx x4MH5NWn9y/4utFOLWXfVh37nX5kikLmdOYIu5ZJoCitWX6JslZeqq55vlIAYtaoJMX6 nfdkgZkBNqVFVWrvY89cBKo9AbeNiSZ4S+eMKo1vq4x17x6Td2iuOh2IzA1UJ84VInIh u7ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=Oa9eWY4ag17TuxyTSddIF/Dgx2DUX4n4lLHBZz47EQ8=; b=1pnIw5d8j9+acNrK0hHrjqmnDVqCSx0GxnfpA0cr5Nlu/LacDp/+fqncBPwdXmQqfg SJsW7rzpRFL9irlEB98n3MDZzTJwcU4g6WCFbiZjNEuNW8QW8TouXINWTfgVt9MCpV16 0wXBgC39RvHrpj0s+LiMY2Lx1Pld6d7Xt8IBaXi4FgAEPhzAHzIWdx7+73ohLu7QosNy WFxRYhjaXWAgE4RlAci68ZrnSYi5mGvhTYAqyYiD+YO6DcsS1Ka9jRjuUgTXJ+JsXQRw Gx0HZhfHp1Op8E6qcHX4BPhDKlztaaie8E0c0W1BrzPNuj2muMAYTr1P6VvFSssdALWr ruyw== X-Gm-Message-State: AOAM533Lsho/rXKT2jY5oqXu7c/D4LxH08r+CDxUh0xQI/VxUeIdNHOn FjaLJ9lYNQ7XHBzBhO8azx256wU4OKhUCPEl X-Google-Smtp-Source: ABdhPJwR65IpP/R0VqoqayBtFWBr46QKPjJrRdXSSTcnaU/ULm3mk93OYYpLf1czhLactrTeHF4QRw== X-Received: by 2002:a05:6214:27e1:: with SMTP id jt1mr28738886qvb.34.1638660773783; Sat, 04 Dec 2021 15:32:53 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id f11sm4648938qko.84.2021.12.04.15.32.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Dec 2021 15:32:52 -0800 (PST) Content-Type: multipart/alternative; boundary="------------RdsJ7hN1i0Fce7SCUGFntPHk" Message-ID: Date: Sat, 4 Dec 2021 18:32:50 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:33:00 -0000 This is a multi-part message in MIME format. --------------RdsJ7hN1i0Fce7SCUGFntPHk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/4/2021 3:09 PM, Brian E Carpenter wrote: >> Also, I recall that there was a question as to whether the LLC should >> be in the approval chain.  What do people think? > > The LLC exists to serve the community, so the LLC cannot have a veto, > but their opinion about feasibility must be heard. I'm not quite sure > how best to word that. I've been off doing other things for a bit but.. This is a nonsense statement.  It is semantically equivalent to "The IAB exists to serve the community, so the IAB cannot have a veto."  Substitute in IESG and you get similar nonsense.  I apologize in advance if I offend with calling this nonsense, but it truly does not make any sense nor can it be made to make sense. The IAB, IESG and LLC board are selected by the community through the Nomcom process to represent the community and by doing so, to serve the community.  The LLC does get a veto for good and sufficient reasons - e.g. it's a brilliant idea that every one loves, but it will start breaking the bank in just about 2 years.   Or we've decided to stand up a second LLC to deal with the specifics of the RFC process as a subsidiary of the IETF LLC and the money and lawyers and external support must be gained. Or we want to move a task that's been contracted for and for which a contract modification may or may not be possible.  Or any of a number of other items that fall specifically in the LLC's purview of keeping things legal and affordable and sustainable. Neither the RSWG nor the RSAB are selected by the community, and so they can't be said to either represent the community or for that matter serve anything except a specific set of interests which may not necessarily align with the IAB/IESG/LLCs own view of the good of the community or for that matter the communities own view (for some definition of community).    So why are they veto-proof? Later, Mike --------------RdsJ7hN1i0Fce7SCUGFntPHk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/4/2021 3:09 PM, Brian E Carpenter wrote:
Also, I recall that there was a question as to whether the LLC should be in the approval chain.  What do people think?

The LLC exists to serve the community, so the LLC cannot have a veto, but their opinion about feasibility must be heard. I'm not quite sure how best to word that.

I've been off doing other things for a bit but..

This is a nonsense statement.  It is semantically equivalent to "The IAB exists to serve the community, so the IAB cannot have a veto."  Substitute in IESG and you get similar nonsense.  I apologize in advance if I offend with calling this nonsense, but it truly does not make any sense nor can it be made to make sense.

The IAB, IESG and LLC board are selected by the community through the Nomcom process to represent the community and by doing so, to serve the community.  The LLC does get a veto for good and sufficient reasons - e.g. it's a brilliant idea that every one loves, but it will start breaking the bank in just about 2 years.   Or we've decided to stand up a second LLC to deal with the specifics of the RFC process as a subsidiary of the IETF LLC and the money and lawyers and external support must be gained. Or we want to move a task that's been contracted for and for which a contract modification may or may not be possible.  Or any of a number of other items that fall specifically in the LLC's purview of keeping things legal and affordable and sustainable.

Neither the RSWG nor the RSAB are selected by the community, and so they can't be said to either represent the community or for that matter serve anything except a specific set of interests which may not necessarily align with the IAB/IESG/LLCs own view of the good of the community or for that matter the communities own view (for some definition of community).    So why are they veto-proof?

Later, Mike


--------------RdsJ7hN1i0Fce7SCUGFntPHk-- From nobody Sat Dec 4 16:25:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172773A0CDC for ; Sat, 4 Dec 2021 16:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=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, GB_AFFORDABLE=1, NICE_REPLY_A=-1.852, 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 moRwIFI5fGvt for ; Sat, 4 Dec 2021 16:25:29 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C362E3A0CDB for ; Sat, 4 Dec 2021 16:25:29 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id o4so6553359pfp.13 for ; Sat, 04 Dec 2021 16:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=chS1eRUZKtS0ZfaqqQgrn8kVS33/7YACAPN+zUz7ZFQ=; b=celKxJzNQaOF7wvKIF5zJkvwo0lX3LEx5Ge3Zw4KPfpmrxSSLwl0nTMOqjpuUBkQiV dPyDY7vSJrOgfVWavgP6DV/QPNCFSguKdp225MuI/A+R9SBuxL9CoynUtV448/16SmM+ vL/VYZFMxJtiuyoveK6DlkfcEBO84ZnpOvFRpeeTwqxeVGniOAqIUGWbdT/Tj1saNFPT X0OgIq8R3ZSdHuVKA0XE+dLqA9gmuo8+GKtxbqhWDh8kEKEA15sLoBZf64fcUQwv0oy8 jQtvSMRtHqSFvipbojx1yNx6gRZlSG9g4/EXfEj3h1DkmZpGoKqUiQt9i3+iGuInZCKp 1AaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=chS1eRUZKtS0ZfaqqQgrn8kVS33/7YACAPN+zUz7ZFQ=; b=TGNoutQy05SnJfqYEyPiZYyDqG6znh4A0pGCgWTdV4J824Q+4VXxVEo4XfF40EvJwb ET/ylzzd9Dsk9xaIrA7VUskeGSQU0Rcl5+oCm9jlfLPWYU1hIqh3MKuO6OmntX3P0Cz4 RjGC1D1gG0JWfrQF6vJiMJMqJlk9fA82zwKmOIJAYtHJJO5B+zawS6eEQ1ZmehH8kPKI +zwUcqGJxuBmfrYlojNy/Us4e8RYhHgFRsrNNcZyP9xgeii+v5p7FCKx5zeoWT+vSPEC YI4+ykRkg5cHJ/N2M/Haq/0lvPaRQO/+uh4Yt0QqSrCzOU+cjpU/i9PRcmoX3uzZjSqs vBSQ== X-Gm-Message-State: AOAM530DKYmh8vl6yVsp/DshuTgVhfp+FQGGzLae/USJ0DD4Rj13oR3o EnBiF8pj8IeqL5oK/9XWZrED1imlhaZp2g== X-Google-Smtp-Source: ABdhPJyKrpcqpFHqaUZSlDxrzLHSSmmPfH1ali01TOa6jLpacHp9OVQvQ6wtLMwehpV9iwy5Z4uZag== X-Received: by 2002:a63:350e:: with SMTP id c14mr11525646pga.543.1638663927768; Sat, 04 Dec 2021 16:25:27 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id f21sm8637117pfc.191.2021.12.04.16.25.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Dec 2021 16:25:27 -0800 (PST) To: Michael StJohns , rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> From: Brian E Carpenter Message-ID: Date: Sun, 5 Dec 2021 13:25:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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 Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:25:31 -0000 On 05-Dec-21 12:32, Michael StJohns wrote: > On 12/4/2021 3:09 PM, Brian E Carpenter wrote: >>> Also, I recall that there was a question as to whether the LLC should=20 be in the approval chain.=C2=A0 What do people think? >> >> The LLC exists to serve the community, so the LLC cannot have a veto, = but their opinion about feasibility must be heard. I'm not quite sure how=20 best to word that. >=20 > I've been off doing other things for a bit but.. >=20 > This is a nonsense statement.=C2=A0 It is semantically equivalent to "T= he IAB exists to serve the community, so the IAB cannot have a veto."=C2=A0=20 Substitute in IESG and you get similar nonsense.=C2=A0 I apologize in adv= ance if I offend with calling this nonsense, but it truly does not make a= ny sense nor can it be made to make sense. No offence, but clearly I expressed it poorly. What I'm getting at is th= at the LLC exists to provide support for the community (as specified in s= ection 4.3 of RFC8711), so it is out of order for the LLC to object to co= mmunity decisions *except as they affect administrative and technical sup= port*. The proposed text doesn't capture that limitation. (And no, I don'= t see that the IAB and IESG are limited in a similar way.) Regards, Brian =20 > The IAB, IESG and LLC board are selected by the community through the N= omcom process to represent the community and by doing so, to serve the co= mmunity.=C2=A0 The LLC does get a veto for good and sufficient reasons - = e.g. it's a brilliant idea that every one loves, but it will start breaki= ng the bank in just about 2 years.=C2=A0=C2=A0 Or we've decided to stand = up a second LLC to deal with the specifics of the RFC process as a subsid= iary of the IETF LLC and the money and lawyers and external support must = be gained. Or we want to move a task that's been contracted for and for w= hich a contract modification may or may not be possible.=C2=A0 Or any of = a number of other items that fall specifically in the LLC's purview of ke= eping things legal and affordable and sustainable. >=20 > Neither the RSWG nor the RSAB are selected by the community, and so the= y can't be said to either represent the community or for that matter serv= e anything except a specific set of interests which may not necessarily a= lign with the IAB/IESG/LLCs own view of the good of the community or for = that matter the communities own view (for some definition of community).=C2= =A0=C2=A0=C2=A0 So why are they veto-proof? >=20 > Later, Mike >=20 >=20 >=20 From nobody Sat Dec 4 16:57:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2957C3A0D22 for ; Sat, 4 Dec 2021 16:57:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 ZaTm4BPjSqXp for ; Sat, 4 Dec 2021 16:57:06 -0800 (PST) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA323A0C23 for ; Sat, 4 Dec 2021 16:57:06 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id y16so8601197ioc.8 for ; Sat, 04 Dec 2021 16:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pAhcivyhyYxntvs9XEA7lisDDUiQTMrcpsexkyVX/gw=; b=ZYsvZyZFJWFSQP3CH68tdTdcieMpR1idAq9O1cFj/bLi3wo4H8XFGrNPFrm4tobSUv x7VmNSIcv2MhxTNJm2GIpcGN/iKTEIGwj2xyPb7+6ot9U/Au6WngKGRxA3UJksLohKPE 2qG3v8J4x1OtgtN5SxTHR9m31NLaVaCXawmA13ASnJ4wxY+IWkyp1YWrnyp4XzgAL+8A G0ci4dQX8z1StvOiUgZRaShrxisQ2wpNI07Fwos5o6DPlD5Mzn5twwoZv4PwX7Twu9mZ CkbfqlsanClAqiUqt9wyTAvgjZkHYO1abPdeL2B4/u7UlbELVr9LtGfdIQ2ODCDkrSmL 7LJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pAhcivyhyYxntvs9XEA7lisDDUiQTMrcpsexkyVX/gw=; b=biEUXOZT8ciNCjfaU6Hv8ZoztE21TgdR9KrEIfcbDyBta+rvl9WN4qnUcTZTEJXpyL rFsntipmYQSjC8aSGOwMRa60tT9HxSQC2MerXbR5uyKd0gF2EhfzxoTw5M1otwiA1qnX yDkTHeeXlaLOf8ZJN0mtNvkuwFbfNySx2qGdY8c0SUwfP44SaTH00g3fl8BJ4qu/207F IDQe24I47EBxf4WDMBkX1sj8nXohCmiNg4VCYWqD5h9k1vgK7tHFthS+FViy4UNPFlbx 3z4YYSFWQRFPo28x3J4aUZTs1yf3h+FsAyKN0LaqPzDw/z71xAJogu02X+E4mwqQ5sGq Djaw== X-Gm-Message-State: AOAM533YJcwVFWq42uN4rsE4m6Jz5kMfRRiwk+LHoXJ2tpnhhwSb79rA EZZPR3b3iofh4Iy2tnaBa/NmGkH9W8w73K/i9X5R5FjavaK20g== X-Google-Smtp-Source: ABdhPJxCII+uUIVGzqcLRUNhI0llMZmQjcOt/RVtEh71a4fearAdgUBehqNYmvR40TqEvB+05MVHA8gKvU1w/tT+icA= X-Received: by 2002:a05:6638:1696:: with SMTP id f22mr33562705jat.113.1638665823737; Sat, 04 Dec 2021 16:57:03 -0800 (PST) MIME-Version: 1.0 References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> In-Reply-To: From: Eric Rescorla Date: Sat, 4 Dec 2021 16:56:27 -0800 Message-ID: To: Brian E Carpenter Cc: Michael StJohns , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000546ad705d25b9e7f" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:57:11 -0000 --000000000000546ad705d25b9e7f Content-Type: text/plain; charset="UTF-8" I agree with Brian here. One of the major themes when the LLC was formed was how people wanted it to be subordinate to the community, and so any say it has should be strictly limited. I can see a case to be made for the LLC having a say in whether some substantive change proposed by the RSWG (e.g., RFCs must be printed on gold plates) was practical. However, even then I think it would be better if the LLC gave advice and the RSWG and RSAB set policy. I don't see any reason why the LLC should be allowed to veto process changes instituted by the RSWG/RSAB. -Ekr On Sat, Dec 4, 2021 at 4:25 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 05-Dec-21 12:32, Michael StJohns wrote: > > On 12/4/2021 3:09 PM, Brian E Carpenter wrote: > >>> Also, I recall that there was a question as to whether the LLC should > be in the approval chain. What do people think? > >> > >> The LLC exists to serve the community, so the LLC cannot have a veto, > but their opinion about feasibility must be heard. I'm not quite sure how > best to word that. > > > > I've been off doing other things for a bit but.. > > > > This is a nonsense statement. It is semantically equivalent to "The IAB > exists to serve the community, so the IAB cannot have a veto." > Substitute in IESG and you get similar nonsense. I apologize in advance > if I offend with calling this nonsense, but it truly does not make any > sense nor can it be made to make sense. > > > No offence, but clearly I expressed it poorly. What I'm getting at is > that the LLC exists to provide support for the community (as specified in > section 4.3 of RFC8711), so it is out of order for the LLC to object to > community decisions *except as they affect administrative and technical > support*. The proposed text doesn't capture that limitation. (And no, I > don't see that the IAB and IESG are limited in a similar way.) > > Regards, > Brian > > > > The IAB, IESG and LLC board are selected by the community through the > Nomcom process to represent the community and by doing so, to serve the > community. The LLC does get a veto for good and sufficient reasons - e.g. > it's a brilliant idea that every one loves, but it will start breaking the > bank in just about 2 years. Or we've decided to stand up a second LLC to > deal with the specifics of the RFC process as a subsidiary of the IETF LLC > and the money and lawyers and external support must be gained. Or we want > to move a task that's been contracted for and for which a contract > modification may or may not be possible. Or any of a number of other items > that fall specifically in the LLC's purview of keeping things legal and > affordable and sustainable. > > > > Neither the RSWG nor the RSAB are selected by the community, and so they > can't be said to either represent the community or for that matter serve > anything except a specific set of interests which may not necessarily align > with the IAB/IESG/LLCs own view of the good of the community or for that > matter the communities own view (for some definition of community). So > why are they veto-proof? > > > > Later, Mike > > > > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000546ad705d25b9e7f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with Brian here. One of the major themes when the = LLC was
formed was how people wanted it to be subordinate to the communi= ty,
and so any say it has should be strictly limited.

I can see a= case to be made for the LLC having a say in whether some
substantive ch= ange proposed by the RSWG (e.g., RFCs must be printed on
gold plates) wa= s practical. However, even then I think it would be
better if the LLC ga= ve advice and the RSWG and RSAB set policy.

I don't see any reas= on why the LLC should be allowed to veto process
changes instituted by t= he RSWG/RSAB.

-Ekr

On Sat, Dec 4, 2021 at 4:25 PM Brian E Carpen= ter <brian.e.carpenter@gm= ail.com> wrote:
On 05-Dec-21 12:32, Michael StJohns wrote:
> On 12/4/2021 3:09 PM, Brian E Carpenter wrote:
>>> Also, I recall that there was a question as to whether the LLC= should
be in the approval chain.=C2=A0 What do people think?
>>
>> The LLC exists to serve the community, so the LLC cannot have a ve= to, but their opinion about feasibility must be heard. I'm not quite su= re how
best to word that.
>
> I've been off doing other things for a bit but..
>
> This is a nonsense statement.=C2=A0 It is semantically equivalent to &= quot;The IAB exists to serve the community, so the IAB cannot have a veto.&= quot;=C2=A0
Substitute in IESG and you get similar nonsense.=C2=A0 I apologize in advan= ce if I offend with calling this nonsense, but it truly does not make any s= ense nor can it be made to make sense.


No offence, but clearly I expressed it poorly.=C2=A0 What I'm getting a= t is that the LLC exists to provide support for the community (as specified= in section 4.3 of RFC8711), so it is out of order for the LLC to object to= community decisions *except as they affect administrative and technical su= pport*. The proposed text doesn't capture that limitation. (And no, I d= on't see that the IAB and IESG are limited in a similar way.)

Regards,
=C2=A0 =C2=A0Brian


> The IAB, IESG and LLC board are selected by the community through the = Nomcom process to represent the community and by doing so, to serve the com= munity.=C2=A0 The LLC does get a veto for good and sufficient reasons - e.g= . it's a brilliant idea that every one loves, but it will start breakin= g the bank in just about 2 years.=C2=A0=C2=A0 Or we've decided to stand= up a second LLC to deal with the specifics of the RFC process as a subsidi= ary of the IETF LLC and the money and lawyers and external support must be = gained. Or we want to move a task that's been contracted for and for wh= ich a contract modification may or may not be possible.=C2=A0 Or any of a n= umber of other items that fall specifically in the LLC's purview of kee= ping things legal and affordable and sustainable.
>
> Neither the RSWG nor the RSAB are selected by the community, and so th= ey can't be said to either represent the community or for that matter s= erve anything except a specific set of interests which may not necessarily = align with the IAB/IESG/LLCs own view of the good of the community or for t= hat matter the communities own view (for some definition of community).=C2= =A0=C2=A0=C2=A0 So why are they veto-proof?
>
> Later, Mike
>
>
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000546ad705d25b9e7f-- From nobody Sat Dec 4 17:01:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E58633A0C14 for ; Sat, 4 Dec 2021 17:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.749 X-Spam-Level: X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 WfIKNBvjgBuR for ; Sat, 4 Dec 2021 17:01:20 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EE2F3A0D22 for ; Sat, 4 Dec 2021 17:01:20 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id m25so7305917qtq.13 for ; Sat, 04 Dec 2021 17:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=51Xieb6B2WbbTKoaF8J2TQ3y776Rxy91t6ctcIpS6PQ=; b=WnNe7Ay5YqPAeyC/hgBGz01J91B4nn8Z5A7/JLQhADBAVriFAhVJhW+6xiMFRja3xx uhEyZhXYaTqktlm+WnccTPmk1omrOfs6qDFtwDN0DkLbn33Amb8JKSOGW1KPzsxFFb+G gyCOcKLE13moh9N2ygo14YGYKyARdqGzlgcGH2oxlKL75rREDuooAc/dRDt50h+bxHox IG/mRaFDELkluGGMZ1IQRBrumY4rgLtat0oXHiAh09wmleEmGUIptg8eLYmH/cU9nvmi V3vqVvrbzdivYw3/Ysis1dN7n0R6feh/Fqmt5NWlOM/9RqP9ENImOPmOoR5zl0LSadeb sRNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=51Xieb6B2WbbTKoaF8J2TQ3y776Rxy91t6ctcIpS6PQ=; b=GtJq7ZpEyB8KumJ0qd13pPcl7207YHts0sgqCgYuGIA9FLajGQS9XI6sfbsou+go76 /VcDvr9TI459g8WxR5c6OB4LV5GjQYkPlHt2b03yedbLGD+471mFYeRoHkK5CcfjXrgE d8lyPKy/tC3+Hv36ltdvX7UZt6H5Umh8aNbbIIKOayiib1QelVzqnaISN+IHTrtURX4T BKp4hc07gkeCzB1I0foh/uTKxSllW5QOe4YHXFkg+67jWYLItaSY/BnhGPdXnSZerzNl wvLhlxgjDyuVJjYsPqEg14t9sbGUFqeZd7T3tSutxp1uCFfWi60+VbDXp68yMusFh8Ca WluQ== X-Gm-Message-State: AOAM531BPi+lxJTIShH2IuUSdRTC1neOL26ERdr+tedr/zETNMdCkXMI IiB+wYvKxETkD3p3z898LOlIv8Wax9sA0kQE X-Google-Smtp-Source: ABdhPJyJhfs7BYlrE/nUCC/cVcWKz+9ANz9kJWbVoCZ5c4AIpw2PE5KDEDZ8S5a7mUszgplP39+k6g== X-Received: by 2002:a05:622a:1014:: with SMTP id d20mr31183184qte.399.1638666077281; Sat, 04 Dec 2021 17:01:17 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id v5sm5369650qtc.60.2021.12.04.17.01.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Dec 2021 17:01:16 -0800 (PST) Content-Type: multipart/alternative; boundary="------------ivzACIwqCm2qq0Afzwrs7XQF" Message-ID: <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> Date: Sat, 4 Dec 2021 20:01:14 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Brian E Carpenter , rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:01:23 -0000 This is a multi-part message in MIME format. --------------ivzACIwqCm2qq0Afzwrs7XQF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/4/2021 7:25 PM, Brian E Carpenter wrote: > On 05-Dec-21 12:32, Michael StJohns wrote: >> On 12/4/2021 3:09 PM, Brian E Carpenter wrote: >>>> Also, I recall that there was a question as to whether the LLC should > be in the approval chain.  What do people think? >>> >>> The LLC exists to serve the community, so the LLC cannot have a >>> veto, but their opinion about feasibility must be heard. I'm not >>> quite sure how > best to word that. >> >> I've been off doing other things for a bit but.. >> >> This is a nonsense statement.  It is semantically equivalent to "The >> IAB exists to serve the community, so the IAB cannot have a veto." > Substitute in IESG and you get similar nonsense.  I apologize in > advance if I offend with calling this nonsense, but it truly does not > make any sense nor can it be made to make sense. > > > No offence, but clearly I expressed it poorly.  What I'm getting at is > that the LLC exists to provide support for the community (as specified > in section 4.3 of RFC8711), so it is out of order for the LLC to > object to community decisions *except as they affect administrative > and technical support*. The proposed text doesn't capture that > limitation. (And no, I don't see that the IAB and IESG are limited in > a similar way.) > RFC8711 is interesting but not controlling.  What is controlling are the articles of incorporation, specifically 4(b): > Specific purpose. The purpose of the Company is to provide a corporate > legal framework > for facilitating current and futureactivities related to the Internet > Engineering Task > Force, the Internet Architecture Board (IAB), and the Internet > Research Task Force > (IRTF). The intent is that legal responsibility for all IETF-related > activities under the > corporate umbrella of the Member as of the Effective Date will > transfer to the Company. > Except as minimally necessary to provide appropriate administrative > and legal support > (consistent with that historically provided by the Member and the IETF > Administrative > Support Activity (IASA)), formation of the Company is not intended to > change anything > related to the oversight or steering of the standards process as > currently conducted by > the Internet Engineering Steering Group (IESG) and the IAB, the > appeals chain, the > process for making and organizations involved in confirming IETF and > IAB appointments, > the IETF Nominations Committee (NomCom), the IRTF, or Member's > memberships in or > support of other organizations The RFC process is not "oversight or steering of the standards process" by any measure.   "...corporate legal framework for facilitating current and future activities.." covers what we're intending for the RFC process.  The LLC is not and was not intended to be a rubber stamp for things that need to get paid for or managed.  E.g. the RFC process. And then there's section 4.4 of the RFC8711 - > * Diligence. The IETF LLC is expected to act responsibly so as to > minimize risks to IETF participants and to the future of the IETF > as a whole, such as financial risks. (And yes, there is also the Responsiveness to the Community item in the same section - both apply or neither). So, yes, the LLC gets a veto. Later, Mike > Regards, >   Brian > >> The IAB, IESG and LLC board are selected by the community through the >> Nomcom process to represent the community and by doing so, to serve >> the community.  The LLC does get a veto for good and sufficient >> reasons - e.g. it's a brilliant idea that every one loves, but it >> will start breaking the bank in just about 2 years.   Or we've >> decided to stand up a second LLC to deal with the specifics of the >> RFC process as a subsidiary of the IETF LLC and the money and lawyers >> and external support must be gained. Or we want to move a task that's >> been contracted for and for which a contract modification may or may >> not be possible.  Or any of a number of other items that fall >> specifically in the LLC's purview of keeping things legal and >> affordable and sustainable. >> >> Neither the RSWG nor the RSAB are selected by the community, and so >> they can't be said to either represent the community or for that >> matter serve anything except a specific set of interests which may >> not necessarily align with the IAB/IESG/LLCs own view of the good of >> the community or for that matter the communities own view (for some >> definition of community).    So why are they veto-proof? >> >> Later, Mike >> >> >> > --------------ivzACIwqCm2qq0Afzwrs7XQF Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/4/2021 7:25 PM, Brian E Carpenter wrote:
On 05-Dec-21 12:32, Michael StJohns wrote:
On 12/4/2021 3:09 PM, Brian E Carpenter wrote:
Also, I recall that there was a question as to whether the LLC should
be in the approval chain.  What do people think?

The LLC exists to serve the community, so the LLC cannot have a veto, but their opinion about feasibility must be heard. I'm not quite sure how
best to word that.

I've been off doing other things for a bit but..

This is a nonsense statement.  It is semantically equivalent to "The IAB exists to serve the community, so the IAB cannot have a veto." 
Substitute in IESG and you get similar nonsense.  I apologize in advance if I offend with calling this nonsense, but it truly does not make any sense nor can it be made to make sense.


No offence, but clearly I expressed it poorly.  What I'm getting at is that the LLC exists to provide support for the community (as specified in section 4.3 of RFC8711), so it is out of order for the LLC to object to community decisions *except as they affect administrative and technical support*. The proposed text doesn't capture that limitation. (And no, I don't see that the IAB and IESG are limited in a similar way.)

RFC8711 is interesting but not controlling.  What is controlling are the articles of incorporation, specifically 4(b):

Specific purpose. The purpose of the Company is to provide a corporate legal framework
for facilitating current and future activities related to the Internet Engineering Task
Force, the Internet Architecture Board (IAB), and the Internet Research Task Force
(IRTF). The intent is that legal responsibility for all IETF-related activities under the
corporate umbrella of the Member as of the Effective Date will transfer to the Company.
Except as minimally necessary to provide appropriate administrative and legal support
(consistent with that historically provided by the Member and the IETF Administrative
Support Activity (IASA)), formation of the Company is not intended to change anything
related to the oversight or steering of the standards process as currently conducted by
the Internet Engineering Steering Group (IESG) and the IAB, the appeals chain, the
process for making and organizations involved in confirming IETF and IAB appointments,
the IETF Nominations Committee (NomCom), the IRTF, or Member's memberships in or
support of other organizations

The RFC process is not "oversight or steering of the standards process" by any measure.   "...corporate legal framework for facilitating current and future activities.." covers what we're intending for the RFC process.  The LLC is not and was not intended to be a rubber stamp for things that need to get paid for or managed.  E.g. the RFC process.


And then there's section 4.4 of the RFC8711 - 

   *  Diligence.  The IETF LLC is expected to act responsibly so as to
      minimize risks to IETF participants and to the future of the IETF
      as a whole, such as financial risks.
(And yes, there is also the Responsiveness to the Community item in the same section - both apply or neither).

So, yes, the LLC gets a veto.

Later, Mike




Regards,
  Brian
 
The IAB, IESG and LLC board are selected by the community through the Nomcom process to represent the community and by doing so, to serve the community.  The LLC does get a veto for good and sufficient reasons - e.g. it's a brilliant idea that every one loves, but it will start breaking the bank in just about 2 years.   Or we've decided to stand up a second LLC to deal with the specifics of the RFC process as a subsidiary of the IETF LLC and the money and lawyers and external support must be gained. Or we want to move a task that's been contracted for and for which a contract modification may or may not be possible.  Or any of a number of other items that fall specifically in the LLC's purview of keeping things legal and affordable and sustainable.

Neither the RSWG nor the RSAB are selected by the community, and so they can't be said to either represent the community or for that matter serve anything except a specific set of interests which may not necessarily align with the IAB/IESG/LLCs own view of the good of the community or for that matter the communities own view (for some definition of community).    So why are they veto-proof?

Later, Mike





--------------ivzACIwqCm2qq0Afzwrs7XQF-- From nobody Sat Dec 4 17:05:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5493A0D2D for ; Sat, 4 Dec 2021 17:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_AFFORDABLE=1, NICE_REPLY_A=-1.852, 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 axWjCim4difg for ; Sat, 4 Dec 2021 17:05:38 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5404B3A0D29 for ; Sat, 4 Dec 2021 17:05:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4J67f96lvMz6GBRx; Sat, 4 Dec 2021 17:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1638666337; bh=BJgWDWdhvpULM81UVktDChx//IF1cB5Z9ts+Ffhn3Uo=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VdaGOKK72m2CGX9bnlp5W6GITK9BUR15utKf6eygs3toxkgpcQbvEECxXbmilU/M6 8QNZcBsrn1eerfU0OJzD1FPbZq3nRjGskSMuAbzlATc4XO2QwAy+5meKQHFrEig3En PZT2JHArdzww2XODnHLQif/KSriJEKY4ozAdzA/c= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4J67f92QYwz6GB66; Sat, 4 Dec 2021 17:05:37 -0800 (PST) Message-ID: Date: Sat, 4 Dec 2021 20:05:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eric Rescorla , Brian E Carpenter Cc: rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:05:43 -0000 I certainly wouldn't expect us to give the LLC an unlimited veto. But they clearly have the right to say "no, that would be illegal", or "no, that would break the bank". So they have a limited veto. I look forward to Brian's rephrasing. Yours, Joel On 12/4/2021 7:56 PM, Eric Rescorla wrote: > I agree with Brian here. One of the major themes when the LLC was > formed was how people wanted it to be subordinate to the community, > and so any say it has should be strictly limited. > > I can see a case to be made for the LLC having a say in whether some > substantive change proposed by the RSWG (e.g., RFCs must be printed on > gold plates) was practical. However, even then I think it would be > better if the LLC gave advice and the RSWG and RSAB set policy. > > I don't see any reason why the LLC should be allowed to veto process > changes instituted by the RSWG/RSAB. > > -Ekr > > On Sat, Dec 4, 2021 at 4:25 PM Brian E Carpenter > > wrote: > > On 05-Dec-21 12:32, Michael StJohns wrote: > > On 12/4/2021 3:09 PM, Brian E Carpenter wrote: > >>> Also, I recall that there was a question as to whether the LLC > should > be in the approval chain.  What do people think? > >> > >> The LLC exists to serve the community, so the LLC cannot have a > veto, but their opinion about feasibility must be heard. I'm not > quite sure how > best to word that. > > > > I've been off doing other things for a bit but.. > > > > This is a nonsense statement.  It is semantically equivalent to > "The IAB exists to serve the community, so the IAB cannot have a veto." > Substitute in IESG and you get similar nonsense.  I apologize in > advance if I offend with calling this nonsense, but it truly does > not make any sense nor can it be made to make sense. > > > No offence, but clearly I expressed it poorly.  What I'm getting at > is that the LLC exists to provide support for the community (as > specified in section 4.3 of RFC8711), so it is out of order for the > LLC to object to community decisions *except as they affect > administrative and technical support*. The proposed text doesn't > capture that limitation. (And no, I don't see that the IAB and IESG > are limited in a similar way.) > > Regards, >    Brian > > > > The IAB, IESG and LLC board are selected by the community through > the Nomcom process to represent the community and by doing so, to > serve the community.  The LLC does get a veto for good and > sufficient reasons - e.g. it's a brilliant idea that every one > loves, but it will start breaking the bank in just about 2 years. > Or we've decided to stand up a second LLC to deal with the specifics > of the RFC process as a subsidiary of the IETF LLC and the money and > lawyers and external support must be gained. Or we want to move a > task that's been contracted for and for which a contract > modification may or may not be possible.  Or any of a number of > other items that fall specifically in the LLC's purview of keeping > things legal and affordable and sustainable. > > > > Neither the RSWG nor the RSAB are selected by the community, and > so they can't be said to either represent the community or for that > matter serve anything except a specific set of interests which may > not necessarily align with the IAB/IESG/LLCs own view of the good of > the community or for that matter the communities own view (for some > definition of community).    So why are they veto-proof? > > > > Later, Mike > > > > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > > > From nobody Sat Dec 4 17:07:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 999CF3A0D2E for ; Sat, 4 Dec 2021 17:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 VS2RUkSJUlG9 for ; Sat, 4 Dec 2021 17:06:54 -0800 (PST) Received: from mail-il1-x135.google.com (mail-il1-x135.google.com [IPv6:2607:f8b0:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 304133A0C39 for ; Sat, 4 Dec 2021 17:06:54 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id z8so6614728ilu.7 for ; Sat, 04 Dec 2021 17:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BrA34t8UzUSvK7L75QDGKCPKjchm3i/OjxXKhpFWea4=; b=gyBuOPoW30Uj0SMLAmrvMIJcBiuxhrAqP5y+qgp3A0+TNadAJ3BB64b9myW0VDqXtP laWPAhBWjU1C4k7qOLSfxKYPVg61maRUh+yPoxjStkXgs3/sTvCSeTBydB1NJSETy9zz d1evKP6wJKrRmmSLKFnKXrAn0s6YS4Dfj3L1PFxmH37K45gqIcy19FxLxN4p5SmSO/+x L94Wdh62aD1wY+BNzCqBC1J8xCBMQBdcGS6r9YlDtGYXCaKecC0RucFwKCKK4k8z6uvu JgRfyVdQW+n2SmmmjIHp5LhUXQp0iUQFXw6mW2PjKQb3YPF/qwDRVBfVuNcwK9HyHXQM bhrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BrA34t8UzUSvK7L75QDGKCPKjchm3i/OjxXKhpFWea4=; b=0as9k9KvE3wePI9QQgCTndPOodC6CuO4yD6Xl0FwFne41uwZHcyh6utEKyHf7wnidZ bDqMSxbXD0MECMY/hXamPtpsoXiGUj39Uo/ZrtB3+zU8gOXxvxz0TfGOyHV3hW8Y+ghh uYv5B0Mx6YIq3CvoVYwE4aX7COgOk+arJ0/i9gdPiA5dJvzVSzPsKu9HVA1rhr6i52bN n7xEguDPHPzwOv189aatYPgMrcMiAX1iioLGvzNeJdqmcKZS0ajFHSqa8Zmf9CCFR4ni N/wDDlyP/28Uw3DKdJ/5NRJ8hEUiC61CwAOKkACRyoSMCdoC2o1cZ7aYLfUiL3/ezbnu uChA== X-Gm-Message-State: AOAM531/7cMYXxx9f/MVkPbblRoGgfBUb/T3JXkTqqalPY2zfFw7MalI aM2ZXHmQPygl+4XTPAXKYqJkwRHRT1wSutxPjcSuWA== X-Google-Smtp-Source: ABdhPJwjYwG0Akqr2Vt9vSnbVXXbKZh1kRFV83dio7hYCxwPTP382cMX/FZMomASKKPMqjBpAebPam4BAvFU2mfuAMs= X-Received: by 2002:a05:6e02:1be9:: with SMTP id y9mr27319516ilv.219.1638666411615; Sat, 04 Dec 2021 17:06:51 -0800 (PST) MIME-Version: 1.0 References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> In-Reply-To: <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> From: Eric Rescorla Date: Sat, 4 Dec 2021 17:06:15 -0800 Message-ID: To: Michael StJohns Cc: Brian E Carpenter , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000005ec29505d25bc11a" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:06:59 -0000 --0000000000005ec29505d25bc11a Content-Type: text/plain; charset="UTF-8" On Sat, Dec 4, 2021 at 5:01 PM Michael StJohns wrote: > On 12/4/2021 7:25 PM, Brian E Carpenter wrote: > > On 05-Dec-21 12:32, Michael StJohns wrote: > > On 12/4/2021 3:09 PM, Brian E Carpenter wrote: > > Also, I recall that there was a question as to whether the LLC should > > be in the approval chain. What do people think? > > > The LLC exists to serve the community, so the LLC cannot have a veto, but > their opinion about feasibility must be heard. I'm not quite sure how > > best to word that. > > > I've been off doing other things for a bit but.. > > This is a nonsense statement. It is semantically equivalent to "The IAB > exists to serve the community, so the IAB cannot have a veto." > > Substitute in IESG and you get similar nonsense. I apologize in advance > if I offend with calling this nonsense, but it truly does not make any > sense nor can it be made to make sense. > > > No offence, but clearly I expressed it poorly. What I'm getting at is > that the LLC exists to provide support for the community (as specified in > section 4.3 of RFC8711), so it is out of order for the LLC to object to > community decisions *except as they affect administrative and technical > support*. The proposed text doesn't capture that limitation. (And no, I > don't see that the IAB and IESG are limited in a similar way.) > > RFC8711 is interesting but not controlling. What is controlling are the > articles of incorporation, specifically 4(b): > > Specific purpose. The purpose of the Company is to provide a corporate > legal framework > for facilitating current and future activities related to the Internet > Engineering Task > Force, the Internet Architecture Board (IAB), and the Internet Research > Task Force > (IRTF). The intent is that legal responsibility for all IETF-related > activities under the > corporate umbrella of the Member as of the Effective Date will transfer to > the Company. > Except as minimally necessary to provide appropriate administrative and > legal support > (consistent with that historically provided by the Member and the IETF > Administrative > Support Activity (IASA)), formation of the Company is not intended to > change anything > related to the oversight or steering of the standards process as > currently conducted by > the Internet Engineering Steering Group (IESG) and the IAB, the appeals chain, > the > process for making and organizations involved in confirming IETF and IAB > appointments, > the IETF Nominations Committee (NomCom), the IRTF, or Member's memberships > in or > support of other organizations > > > The RFC process is not "oversight or steering of the standards process" by > any measure. "...corporate legal framework for facilitating current and > future activities.." covers what we're intending for the RFC process. The > LLC is not and was not intended to be a rubber stamp for things that need > to get paid for or managed. E.g. the RFC process. > I don't see how the articles of incorporation for the LLC are controlling on us. I could create EKR RFC Inc. whose articles said it was responsible for the health of the RFC series but that wouldn't compel anyone to listen to me. More concretely, it's within the remit of the community to take the RFC Series away from the LLC, whatever the articles say. And then there's section 4.4 of the RFC8711 - > > * Diligence. The IETF LLC is expected to act responsibly so as to > minimize risks to IETF participants and to the future of the IETF > as a whole, such as financial risks. > > (And yes, there is also the Responsiveness to the Community item in the > same section - both apply or neither). > > So, yes, the LLC gets a veto. > I don't see that this follows, either. The LLC can act responsibly within its limits. This doesn't give it extra powers. -Ekr Later, Mike > > > > > Regards, > Brian > > > The IAB, IESG and LLC board are selected by the community through the > Nomcom process to represent the community and by doing so, to serve the > community. The LLC does get a veto for good and sufficient reasons - e.g. > it's a brilliant idea that every one loves, but it will start breaking the > bank in just about 2 years. Or we've decided to stand up a second LLC to > deal with the specifics of the RFC process as a subsidiary of the IETF LLC > and the money and lawyers and external support must be gained. Or we want > to move a task that's been contracted for and for which a contract > modification may or may not be possible. Or any of a number of other items > that fall specifically in the LLC's purview of keeping things legal and > affordable and sustainable. > > Neither the RSWG nor the RSAB are selected by the community, and so they > can't be said to either represent the community or for that matter serve > anything except a specific set of interests which may not necessarily align > with the IAB/IESG/LLCs own view of the good of the community or for that > matter the communities own view (for some definition of community). So > why are they veto-proof? > > Later, Mike > > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000005ec29505d25bc11a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 4, 2021 at 5:01 PM Michae= l StJohns <msj@nthpermutation.= com> wrote:
=20 =20 =20
On 12/4/2021 7:25 PM, Brian E Carpenter wrote:
On 05-Dec-21 12:32, Michael StJohns wrote:
On 12/4/2021 3:09 PM, Brian E Carpenter wrote:
Also, I recall that there was a question as to whether the LLC should
be in the approval chain.=C2=A0 What do people think?

The LLC exists to serve the community, so the LLC cannot have a veto, but their opinion about feasibility must be heard. I'= m not quite sure how
best to word that.

I've been off doing other things for a bit but..

This is a nonsense statement.=C2=A0 It is semantically equivalent t= o "The IAB exists to serve the community, so the IAB cannot have= a veto."=C2=A0
Substitute in IESG and you get similar nonsense.=C2=A0 I apologize in advance if I offend with calling this nonsense, but it truly does not make any sense nor can it be made to make sense.


No offence, but clearly I expressed it poorly.=C2=A0 What I'm get= ting at is that the LLC exists to provide support for the community (as specified in section 4.3 of RFC8711), so it is out of order for the LLC to object to community decisions *except as they affect administrative and technical support*. The proposed text doesn't capture that limitation. (And no, I don't see that the IAB and IESG are limited in a similar way.)

RFC8711 is interesting but not controlling.=C2=A0 What is controllin= g are the articles of incorporation, specifically 4(b):

Specific purpose. The purpose of the Company is to provide a corporate legal framework <= br role=3D"presentation"> for facilitati= ng current and future activities re= lated to the Internet Engineering Task
Force, the Internet Architecture B= oard (IAB), and the Internet Research Task Force
(IRTF). The intent is that legal r= esponsibility for all IETF-related activities under the
corporate umbrella of the Member as of the Effective Date will transfer to the Company. Except as minimally necessary to provide appropriate administrative and legal support
(consistent with that historically provided by the Member and the IETF Administrative
Support Activity (IASA)), formation of the Company is not intended to change anything
related to the oversight or steeri= ng of the standards process as currently conducted by
the Internet Engineering Steering Group (IESG) and the IAB, the appeals chain, the
process for making and organizations involved in confirming IETF and IAB appointments,
the IETF Nominations Committee (NomCom), the IRTF, or Member's memberships in or
support of other organizations

The RFC process is not "oversight or steering of the standards process" by any measure.=C2=A0=C2=A0 "...corporate legal fr= amework for facilitating current and future activities.." covers what we'= ;re intending for the RFC process.=C2=A0 The LLC is not and was not intended to be a rubber stamp for things that need to get paid for or managed.=C2=A0 E.g. the RFC process.

I don't see how the articles of incorporation for the LLC = are controlling on us.

I could create EKR RFC Inc.= whose articles said it was responsible for the health of the
RF= C series but that wouldn't compel anyone to listen to me. More concrete= ly, it's within
the remit of the community to take the RFC Se= ries away from the LLC, whatever the
articles say.

=

=20

And then there's section 4.4 of the RFC8711 - 

   *  Diligence.  The IETF LLC is expected to act responsibly =
so as to
      minimize risks to IETF participants and to the future of the IETF
      as a whole, such as financial risks.
(And yes, there is also the Responsiveness to the Community item in the same section - both apply or neither).

So, yes, the LLC gets a veto.

I don't= see that this follows, either. The LLC can act responsibly within its limi= ts. This doesn't
give it extra powers.

-Ekr

Later, Mike




Regards,
=C2=A0 Brian
=C2=A0
The IAB, IESG and LLC board are selected by the community through the Nomcom process to represent the community and by doing so, to serve the community.=C2=A0 The LLC do= es get a veto for good and sufficient reasons - e.g. it's a brilliant idea that every one loves, but it will start breaking the bank in just about 2 years.=C2=A0=C2=A0 Or we've decided to= stand up a second LLC to deal with the specifics of the RFC process as a subsidiary of the IETF LLC and the money and lawyers and external support must be gained. Or we want to move a task that's been contracted for and for which a contract modificatio= n may or may not be possible.=C2=A0 Or any of a number of other items that fall specifically in the LLC's purview of keeping things legal and affordable and sustainable.

Neither the RSWG nor the RSAB are selected by the community, and so they can't be said to either represent the community or for that matter serve anything except a specific set of interests which may not necessarily align with the IAB/IESG/LLCs own view of the good of the community or for that matter the communities own view (for some definition of community).=C2=A0=C2=A0=C2=A0 So w= hy are they veto-proof?

Later, Mike





--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000005ec29505d25bc11a-- From nobody Sat Dec 4 18:21:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDBAF3A0D7C for ; Sat, 4 Dec 2021 18:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.951 X-Spam-Level: X-Spam-Status: No, score=-2.951 tagged_above=-999 required=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, GB_AFFORDABLE=1, NICE_REPLY_A=-1.852, 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 UJvl6KHJYwar for ; Sat, 4 Dec 2021 18:21:31 -0800 (PST) Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5126E3A0D79 for ; Sat, 4 Dec 2021 18:21:31 -0800 (PST) Received: by mail-pj1-x102f.google.com with SMTP id gt5so5177507pjb.1 for ; Sat, 04 Dec 2021 18:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ZWPZQlsIdRA/1fVTCieMmR8BlsObsVaFaTeWOof2vwA=; b=bBf2URHcwWClBUZDpNnHNumyILLy5isYAV5zEyEs4VIJDGbOk5u576Q8JkaTzVlxlV jxx/P7QdD9hEGNuTaNOVgHv0XFfuE6rQ9pUFpfWk9mQoqmW9UjGq1WWA0wQjt2SjRSIG F4qeHpfbE/JZxlsXrvLXtXCthHFYyKIP2Kb7B/AficyfUQXvluchl1TemhTXLRS4FpiZ 1uRf7yPXHuWmrd0U2nAkXiGqc4ZcZ4fJHh+A9b3tRE1XI2wbdpWLPHHOonRLp4tdmOBl l5ENTNaC6r88LeCD/fgc5Pqp3Y7HLUyMjVD30Lt1wzxZTQLP9xuolu5eRHu2Co5kuxus VpRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=ZWPZQlsIdRA/1fVTCieMmR8BlsObsVaFaTeWOof2vwA=; b=juAjKCBA10RAkq2BhKs4AjH2EiOkw2yG6pyfEuH6VlhCComl2z9NaTwKfCpty0+GjM D8h8PjixtwbK/OMAtvuD5xVduXgvVXwrkJ1xy0cw9+VTvHzF77AsxeYGw8njmw36PIwq nzhYW8mfb272Nu7/cJjS+91EHZxSnAuVL/3uU+5IRDEpsSaXp1iPyV9sja0bgEC8u7hL l7ppqhu+yA3fsE96we/Xdq1V3/enK2EzUX9NnsX+ssXTT/U2djb6XnFRupsGJuyveaJy CI7EkxPVZGr9tLQlQqMq37KzsbkhN+046RJnkaUzMW4WrLE9qGopuzSycyRtbhG+GE55 6aig== X-Gm-Message-State: AOAM532V6MOSdfuw+nPrEzGPysNiBeagA+puQcFGv0YyPWP5L3n85j4O ehwve4dZEJa6H+EE3DC4hdcAm1E/8Q6ahQ== X-Google-Smtp-Source: ABdhPJw+RJOM5FGxqllpPeiCjDLf2UEmkPufQK589y8JljntZNgQV2nlAdZLvB0HpN2Ugobnju4MhQ== X-Received: by 2002:a17:902:e2c3:b0:143:9b60:d16d with SMTP id l3-20020a170902e2c300b001439b60d16dmr33625808plc.42.1638670887843; Sat, 04 Dec 2021 18:21:27 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id p21sm1507185pfh.193.2021.12.04.18.21.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Dec 2021 18:21:27 -0800 (PST) To: Michael StJohns , rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> From: Brian E Carpenter Message-ID: <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> Date: Sun, 5 Dec 2021 15:21:23 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 02:21:34 -0000 Mike, Maybe my keyboard wasn't working. I thought I typed "it is out of order f= or the LLC to object to community decisions *except as they affect admini= strative and technical support*." That seems entirely consistent with wha= t you are saying. My proposed rewrite of the sentence in question after seeing other commen= ts is: OLD: Updates, amendments and refinements of this document can be produced usin= g the process documented here, but are only operative upon agreement of t= he IAB, the IESG, and the IETF LLC. NEW: Updates, amendments and refinements of this document can be produced usin= g the process documented here, but are only operative upon agreement of t= he IAB, the IESG, and the IETF LLC with regard to matters falling under their respective remits. Thus, if the RSWG and RSAB deem that RFCs shall be published in Esperanto=20 instead of English, the LLC could object on grounds of the expense and di= fficulty in hiring translators and copy-editors, but not on the grounds t= hat it's a stupid idea. Brian On 05-Dec-21 14:01, Michael StJohns wrote: > On 12/4/2021 7:25 PM, Brian E Carpenter wrote: >> On 05-Dec-21 12:32, Michael StJohns wrote: >>> On 12/4/2021 3:09 PM, Brian E Carpenter wrote: >>>>> Also, I recall that there was a question as to whether the LLC shou= ld=20 >> be in the approval chain.=C2=A0 What do people think? >>>> >>>> The LLC exists to serve the community, so the LLC cannot have a veto= , but their opinion about feasibility must be heard. I'm not quite sure h= ow=20 >> best to word that. >>> >>> I've been off doing other things for a bit but.. >>> >>> This is a nonsense statement.=C2=A0 It is semantically equivalent to = "The IAB exists to serve the community, so the IAB cannot have a veto."=20 >> Substitute in IESG and you get similar nonsense.=C2=A0 I apologize in = advance if I offend with calling this nonsense, but it truly does not mak= e any sense nor can it be made to make sense. >> >> >> No offence, but clearly I expressed it poorly.=C2=A0 What I'm getting = at is that the LLC exists to provide support for the community (as specif= ied in section 4.3 of RFC8711), so it is out of order for the LLC to obje= ct to community decisions *except as they affect administrative and techn= ical support*. The proposed text doesn't capture that limitation. (And no= , I don't see that the IAB and IESG are limited in a similar way.) >> > RFC8711 is interesting but not controlling.=C2=A0 What is controlling a= re the articles of incorporation, specifically 4(b): >=20 >> Specific purpose. The purpose of the Company is to provide a corporate=20 legal framework >> for facilitating current and futureactivities related to the Internet = Engineering Task >> Force, the Internet Architecture Board (IAB), and the Internet Researc= h Task Force >> (IRTF). The intent is that legal responsibility for all IETF-related a= ctivities under the >> corporate umbrella of the Member as of the Effective Date will transfe= r to the Company. >> Except as minimally necessary to provide appropriate administrative an= d legal support >> (consistent with that historically provided by the Member and the IETF=20 Administrative >> Support Activity (IASA)), formation of the Company is not intended to = change anything >> related to the oversight or steering of the standards process as curre= ntly conducted by >> the Internet Engineering Steering Group (IESG) and the IAB, the appeal= s chain, the >> process for making and organizations involved in confirming IETF and I= AB appointments, >> the IETF Nominations Committee (NomCom), the IRTF, or Member's members= hips in or >> support of other organizations >=20 > The RFC process is not "oversight or steering of the standards process"=20 by any measure.=C2=A0=C2=A0 "...corporate legal framework for facilitatin= g current and future activities.." covers what we're intending for the RF= C process.=C2=A0 The LLC is not and was not intended to be a rubber stamp=20 for things that need to get paid for or managed.=C2=A0 E.g. the RFC proce= ss. >=20 >=20 > And then there's section 4.4 of the RFC8711 - >=20 >> * Diligence. The IETF LLC is expected to act responsibly so as t= o >> minimize risks to IETF participants and to the future of the IE= TF >> as a whole, such as financial risks. > (And yes, there is also the Responsiveness to the Community item in the=20 same section - both apply or neither). >=20 > So, yes, the LLC gets a veto. >=20 > Later, Mike >=20 >=20 >=20 >=20 >> Regards, >> =C2=A0 Brian >> >>> The IAB, IESG and LLC board are selected by the community through the=20 Nomcom process to represent the community and by doing so, to serve the c= ommunity.=C2=A0 The LLC does get a veto for good and sufficient reasons -=20 e.g. it's a brilliant idea that every one loves, but it will start breaki= ng the bank in just about 2 years.=C2=A0=C2=A0 Or we've decided to stand = up a second LLC to deal with the specifics of the RFC process as a subsid= iary of the IETF LLC and the money and lawyers and external support must = be gained. Or we want to move a task that's been contracted for and for w= hich a contract modification may or may not be possible.=C2=A0 Or any of = a number of other items that fall specifically in the LLC's purview of ke= eping things legal and affordable and sustainable. >>> >>> Neither the RSWG nor the RSAB are selected by the community, and so t= hey can't be said to either represent the community or for that matter se= rve anything except a specific set of interests which may not necessarily=20 align with the IAB/IESG/LLCs own view of the good of the community or for=20 that matter the communities own view (for some definition of community).=C2= =A0=C2=A0=C2=A0 So why are they veto-proof? >>> >>> Later, Mike >>> >>> >>> >> >=20 From nobody Sat Dec 4 18:36:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D9F63A0FB3 for ; Sat, 4 Dec 2021 18:36:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 yF6FDai8ZOP0 for ; Sat, 4 Dec 2021 18:36:36 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E987C3A0FB0 for ; Sat, 4 Dec 2021 18:36:35 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id x6so8646278iol.13 for ; Sat, 04 Dec 2021 18:36:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zu0GBUQHV3a61m8BUm2X0nlAn5ihJqVud5Rhgb0kGQs=; b=3u3UiQHlsmBSpwoEOSm69g79ccoeC05sAixMqQvmRAK1cuut9XhodCKfmTV4S1ViXf xUZbSXEQnF8UOKqjdYKaJ1l/H6qKk/toWDNoJk9qAZBVuhijGzU0qeBCWaEMwpGZm2yU WIHiDp/MCJi4RNLHUuDl4be4SM0k+9Ma+ExJMES0NsgWNHYoAXteS+x1evDjdlhWaRxr /4dxGmK3uz7XTAipyEal82hWUaXn129Abpq3vsgD+G0mFiyfJaN1IDsiSiq8r7A/fMUf q++NypCap0GjRMtIrPCRYGI96aZuGHtAFtSU9lzdVLtE//CFKnWbcWihIepDHgECS+D6 WtFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zu0GBUQHV3a61m8BUm2X0nlAn5ihJqVud5Rhgb0kGQs=; b=kcVdQ/9Tn5MIOdEZcIUvCMqhEfOsUhMvMwRvq6bjCIZtV+ZqjWUb/YFjebnvoLju8G Hit4lBs2hltyxDT5ZY4tLwTBFrI/as3CzsaY5qvGqFh846yEOCpxGGf6mf57/aq/nGpT HU8RYC0++cnUQZp+uCa4++lAiChFhm3mYEHk7DYp06b5GIQ9u/tDVlGay2KKRfZLFmlE PkOJKALkbCkMX9QvJQsBwZ0SjCh0Pld65FP0qY/VRPlI8QHupJ8L+W8AWyBAdDCOFetB toLlRSBMG9Yj0kom83XBvxqkiAbCYQM+afHE9WusRudQyQFxzGcj+addlr6XH97BR2bI 69Ug== X-Gm-Message-State: AOAM530/MNFYXyyYijdYcxJIquhEILGQ261JmVGkcFEnE82tizIJjf3f dzOW2JtkRlC/BTZIMQOKDEutVD8txDCx07yVOT5IqA== X-Google-Smtp-Source: ABdhPJzIPmG5mUws6fkePVLv4BVhwEE+ZmDyY/RRh+aOV5LdiE+WGy4bOTg8d0eE1A/+i1fFn0K5ydOIR2eWdQyYOlQ= X-Received: by 2002:a05:6638:1696:: with SMTP id f22mr33901246jat.113.1638671793770; Sat, 04 Dec 2021 18:36:33 -0800 (PST) MIME-Version: 1.0 References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> In-Reply-To: <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> From: Eric Rescorla Date: Sat, 4 Dec 2021 18:35:57 -0800 Message-ID: To: Brian E Carpenter Cc: Michael StJohns , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000002be7d905d25d0270" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 02:36:40 -0000 --0000000000002be7d905d25d0270 Content-Type: text/plain; charset="UTF-8" On Sat, Dec 4, 2021 at 6:21 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Mike, > > Maybe my keyboard wasn't working. I thought I typed "it is out of order > for the LLC to object to community decisions *except as they affect > administrative and technical support*." That seems entirely consistent with > what you are saying. > > My proposed rewrite of the sentence in question after seeing other > comments is: > > OLD: > Updates, amendments and refinements of this document can be produced using > the process documented here, but are only operative upon agreement of the > IAB, the IESG, and the IETF LLC. > > NEW: > Updates, amendments and refinements of this document can be produced using > the process documented here, but are only operative upon agreement of the > IAB, the IESG, and the IETF LLC > with regard to matters falling under their respective remits. > > Thus, if the RSWG and RSAB deem that RFCs shall be published in Esperanto > instead of English, the LLC could object on grounds of the expense and > difficulty in hiring translators and copy-editors, but not on the grounds > that it's a stupid idea. > Brian, I agree with your sentiments, but I don't think that this text does it, because this document is about the process *not* about the RFC Series proper. So, it seems to me that under this text, the RSWG could mandate translation into Klingon without changing the process and only the RSAB could object. Can you give me an example of a change to this document that the LLC could have standing to object to? -Ekr > Brian > > On 05-Dec-21 14:01, Michael StJohns wrote: > > On 12/4/2021 7:25 PM, Brian E Carpenter wrote: > >> On 05-Dec-21 12:32, Michael StJohns wrote: > >>> On 12/4/2021 3:09 PM, Brian E Carpenter wrote: > >>>>> Also, I recall that there was a question as to whether the LLC > should > >> be in the approval chain. What do people think? > >>>> > >>>> The LLC exists to serve the community, so the LLC cannot have a veto, > but their opinion about feasibility must be heard. I'm not quite sure how > >> best to word that. > >>> > >>> I've been off doing other things for a bit but.. > >>> > >>> This is a nonsense statement. It is semantically equivalent to "The > IAB exists to serve the community, so the IAB cannot have a veto." > >> Substitute in IESG and you get similar nonsense. I apologize in > advance if I offend with calling this nonsense, but it truly does not make > any sense nor can it be made to make sense. > >> > >> > >> No offence, but clearly I expressed it poorly. What I'm getting at is > that the LLC exists to provide support for the community (as specified in > section 4.3 of RFC8711), so it is out of order for the LLC to object to > community decisions *except as they affect administrative and technical > support*. The proposed text doesn't capture that limitation. (And no, I > don't see that the IAB and IESG are limited in a similar way.) > >> > > RFC8711 is interesting but not controlling. What is controlling are the > articles of incorporation, specifically 4(b): > > > >> Specific purpose. The purpose of the Company is to provide a corporate > legal framework > >> for facilitating current and futureactivities related to the Internet > Engineering Task > >> Force, the Internet Architecture Board (IAB), and the Internet Research > Task Force > >> (IRTF). The intent is that legal responsibility for all IETF-related > activities under the > >> corporate umbrella of the Member as of the Effective Date will transfer > to the Company. > >> Except as minimally necessary to provide appropriate administrative and > legal support > >> (consistent with that historically provided by the Member and the IETF > Administrative > >> Support Activity (IASA)), formation of the Company is not intended to > change anything > >> related to the oversight or steering of the standards process as > currently conducted by > >> the Internet Engineering Steering Group (IESG) and the IAB, the appeals > chain, the > >> process for making and organizations involved in confirming IETF and > IAB appointments, > >> the IETF Nominations Committee (NomCom), the IRTF, or Member's > memberships in or > >> support of other organizations > > > > The RFC process is not "oversight or steering of the standards process" > by any measure. "...corporate legal framework for facilitating current > and future activities.." covers what we're intending for the RFC process. > The LLC is not and was not intended to be a rubber stamp > for things that need to get paid for or managed. E.g. the RFC process. > > > > > > And then there's section 4.4 of the RFC8711 - > > > >> * Diligence. The IETF LLC is expected to act responsibly so as to > >> minimize risks to IETF participants and to the future of the IETF > >> as a whole, such as financial risks. > > (And yes, there is also the Responsiveness to the Community item in the > same section - both apply or neither). > > > > So, yes, the LLC gets a veto. > > > > Later, Mike > > > > > > > > > >> Regards, > >> Brian > >> > >>> The IAB, IESG and LLC board are selected by the community through the > Nomcom process to represent the community and by doing so, to serve the > community. The LLC does get a veto for good and sufficient reasons - > e.g. it's a brilliant idea that every one loves, but it will start > breaking the bank in just about 2 years. Or we've decided to stand up a > second LLC to deal with the specifics of the RFC process as a subsidiary of > the IETF LLC and the money and lawyers and external support must be gained. > Or we want to move a task that's been contracted for and for which a > contract modification may or may not be possible. Or any of a number of > other items that fall specifically in the LLC's purview of keeping things > legal and affordable and sustainable. > >>> > >>> Neither the RSWG nor the RSAB are selected by the community, and so > they can't be said to either represent the community or for that matter > serve anything except a specific set of interests which may not necessarily > align with the IAB/IESG/LLCs own view of the good of the community or for > that matter the communities own view (for some definition of > community). So why are they veto-proof? > >>> > >>> Later, Mike > >>> > >>> > >>> > >> > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000002be7d905d25d0270 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Dec 4, 2021 at 6:21 PM Brian = E Carpenter <brian.e.carp= enter@gmail.com> wrote:
Mike,

Maybe my keyboard wasn't working. I thought I typed "it is out of = order for the LLC to object to community decisions *except as they affect a= dministrative and technical support*." That seems entirely consistent = with what you are saying.

My proposed rewrite of the sentence in question after seeing other comments= is:

OLD:
Updates, amendments and refinements of this document can be produced using = the process documented here, but are only operative upon agreement of the I= AB, the IESG, and the IETF LLC.

NEW:
Updates, amendments and refinements of this document can be produced using = the process documented here, but are only operative upon agreement of the I= AB, the IESG, and the IETF LLC
with regard to matters falling under their respective remits.

Thus, if the RSWG and RSAB deem that RFCs shall be published in Esperanto <= br> instead of English, the LLC could object on grounds of the expense and diff= iculty in hiring translators and copy-editors, but not on the grounds that = it's a stupid idea.

Brian, I agree = with your sentiments, but I don't think that this text does it, because= this document is about the process *not* about the RFC Series proper.
<= /div>

So, it seems to me that under this text, the RSWG = could mandate translation into Klingon without changing the process and onl= y the RSAB could object.

Can you give me an exampl= e of a change to this document that the LLC could have standing to object t= o?

-Ekr


= =C2=A0
=C2=A0 =C2=A0 Brian

On 05-Dec-21 14:01, Michael StJohns wrote:
> On 12/4/2021 7:25 PM, Brian E Carpenter wrote:
>> On 05-Dec-21 12:32, Michael StJohns wrote:
>>> On 12/4/2021 3:09 PM, Brian E Carpenter wrote:
>>>>> Also, I recall that there was a question as to whether= the LLC should
>> be in the approval chain.=C2=A0 What do people think?
>>>>
>>>> The LLC exists to serve the community, so the LLC cannot h= ave a veto, but their opinion about feasibility must be heard. I'm not = quite sure how
>> best to word that.
>>>
>>> I've been off doing other things for a bit but..
>>>
>>> This is a nonsense statement.=C2=A0 It is semantically equival= ent to "The IAB exists to serve the community, so the IAB cannot have = a veto."
>> Substitute in IESG and you get similar nonsense.=C2=A0 I apologize= in advance if I offend with calling this nonsense, but it truly does not m= ake any sense nor can it be made to make sense.
>>
>>
>> No offence, but clearly I expressed it poorly.=C2=A0 What I'm = getting at is that the LLC exists to provide support for the community (as = specified in section 4.3 of RFC8711), so it is out of order for the LLC to = object to community decisions *except as they affect administrative and tec= hnical support*. The proposed text doesn't capture that limitation. (An= d no, I don't see that the IAB and IESG are limited in a similar way.)<= br> >>
> RFC8711 is interesting but not controlling.=C2=A0 What is controlling = are the articles of incorporation, specifically 4(b):
>
>> Specific purpose. The purpose of the Company is to provide a corpo= rate
legal framework
>> for facilitating current and futureactivities related to the Inter= net Engineering Task
>> Force, the Internet Architecture Board (IAB), and the Internet Res= earch Task Force
>> (IRTF). The intent is that legal responsibility for all IETF-relat= ed activities under the
>> corporate umbrella of the Member as of the Effective Date will tra= nsfer to the Company.
>> Except as minimally necessary to provide appropriate administrativ= e and legal support
>> (consistent with that historically provided by the Member and the = IETF
Administrative
>> Support Activity (IASA)), formation of the Company is not intended= to change anything
>> related to the oversight or steering of the standards process as c= urrently conducted by
>> the Internet Engineering Steering Group (IESG) and the IAB, the ap= peals chain, the
>> process for making and organizations involved in confirming IETF a= nd IAB appointments,
>> the IETF Nominations Committee (NomCom), the IRTF, or Member's= memberships in or
>> support of other organizations
>
> The RFC process is not "oversight or steering of the standards pr= ocess"
by any measure.=C2=A0=C2=A0 "...corporate legal framework for facilita= ting current and future activities.." covers what we're intending = for the RFC process.=C2=A0 The LLC is not and was not intended to be a rubb= er stamp
for things that need to get paid for or managed.=C2=A0 E.g. the RFC process= .
>
>
> And then there's section 4.4 of the RFC8711 -
>
>>=C2=A0 =C2=A0 =C2=A0*=C2=A0 Diligence.=C2=A0 The IETF LLC is expect= ed to act responsibly so as to
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 minimize risks to IETF participants and= to the future of the IETF
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a whole, such as financial risks. > (And yes, there is also the Responsiveness to the Community item in th= e
same section - both apply or neither).
>
> So, yes, the LLC gets a veto.
>
> Later, Mike
>
>
>
>
>> Regards,
>> =C2=A0 Brian
>>
>>> The IAB, IESG and LLC board are selected by the community thro= ugh the
Nomcom process to represent the community and by doing so, to serve the com= munity.=C2=A0 The LLC does get a veto for good and sufficient reasons - e.g. it's a brilliant idea that every one loves, but it will start brea= king the bank in just about 2 years.=C2=A0=C2=A0 Or we've decided to st= and up a second LLC to deal with the specifics of the RFC process as a subs= idiary of the IETF LLC and the money and lawyers and external support must = be gained. Or we want to move a task that's been contracted for and for= which a contract modification may or may not be possible.=C2=A0 Or any of = a number of other items that fall specifically in the LLC's purview of = keeping things legal and affordable and sustainable.
>>>
>>> Neither the RSWG nor the RSAB are selected by the community, a= nd so they can't be said to either represent the community or for that = matter serve anything except a specific set of interests which may not nece= ssarily
align with the IAB/IESG/LLCs own view of the good of the community or for <= br> that matter the communities own view (for some definition of community).=C2= =A0=C2=A0=C2=A0 So why are they veto-proof?
>>>
>>> Later, Mike
>>>
>>>
>>>
>>
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000002be7d905d25d0270-- From nobody Sat Dec 4 18:52:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714053A0FD2 for ; Sat, 4 Dec 2021 18:52:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.952 X-Spam-Level: X-Spam-Status: No, score=-2.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, GB_AFFORDABLE=1, NICE_REPLY_A=-1.852, 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 prHCfhQiUya5 for ; Sat, 4 Dec 2021 18:52:45 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFCA53A0FD1 for ; Sat, 4 Dec 2021 18:52:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4J6B1n2NzQz6G9vv; Sat, 4 Dec 2021 18:52:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1638672765; bh=eKhFh3u2L/jzivrMZQLZpSR9sB0e6KkHtZKbl/1r4MQ=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=RW8S7G8i63uSaOicfec4zozk5fEPV1ZnUnCckDjueOvfi9Wh+savJ3IptIxpTDH6A S7yBRiNHTNAC2KhXITJ0gz9CBkP6+we63t0/M04xnrICL+8A0dimiMk/TF+d1k58iz oEky8mdaupWC6+rgxN5RQ3Iox8X0BNJdvcQhevMc= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4J6B1m5BjFz6G9tB; Sat, 4 Dec 2021 18:52:44 -0800 (PST) Message-ID: Date: Sat, 4 Dec 2021 21:52:43 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eric Rescorla Cc: rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 02:52:51 -0000 It is a bit of a strecth of course, but, as an example of change that the LLC would probably be obliged to object to, imagine a change to the procedure that declared that the LLC had to fund, without question, whatever the RSWG / RSAB approved. That would be a change to this document. And, as I understand it, the LLC Board would be violating their legal obligations if they accepted it. Yours, Joel On 12/4/2021 9:35 PM, Eric Rescorla wrote: > > > On Sat, Dec 4, 2021 at 6:21 PM Brian E Carpenter > > wrote: > > Mike, > > Maybe my keyboard wasn't working. I thought I typed "it is out of > order for the LLC to object to community decisions *except as they > affect administrative and technical support*." That seems entirely > consistent with what you are saying. > > My proposed rewrite of the sentence in question after seeing other > comments is: > > OLD: > Updates, amendments and refinements of this document can be produced > using the process documented here, but are only operative upon > agreement of the IAB, the IESG, and the IETF LLC. > > NEW: > Updates, amendments and refinements of this document can be produced > using the process documented here, but are only operative upon > agreement of the IAB, the IESG, and the IETF LLC > with regard to matters falling under their respective remits. > > Thus, if the RSWG and RSAB deem that RFCs shall be published in > Esperanto > instead of English, the LLC could object on grounds of the expense > and difficulty in hiring translators and copy-editors, but not on > the grounds that it's a stupid idea. > > > Brian, I agree with your sentiments, but I don't think that this text > does it, because this document is about the process *not* about the RFC > Series proper. > > So, it seems to me that under this text, the RSWG could mandate > translation into Klingon without changing the process and only the RSAB > could object. > > Can you give me an example of a change to this document that the LLC > could have standing to object to? > > -Ekr > > >     Brian > > On 05-Dec-21 14:01, Michael StJohns wrote: > > On 12/4/2021 7:25 PM, Brian E Carpenter wrote: > >> On 05-Dec-21 12:32, Michael StJohns wrote: > >>> On 12/4/2021 3:09 PM, Brian E Carpenter wrote: > >>>>> Also, I recall that there was a question as to whether the > LLC should > >> be in the approval chain.  What do people think? > >>>> > >>>> The LLC exists to serve the community, so the LLC cannot have > a veto, but their opinion about feasibility must be heard. I'm not > quite sure how > >> best to word that. > >>> > >>> I've been off doing other things for a bit but.. > >>> > >>> This is a nonsense statement.  It is semantically equivalent to > "The IAB exists to serve the community, so the IAB cannot have a veto." > >> Substitute in IESG and you get similar nonsense.  I apologize in > advance if I offend with calling this nonsense, but it truly does > not make any sense nor can it be made to make sense. > >> > >> > >> No offence, but clearly I expressed it poorly.  What I'm getting > at is that the LLC exists to provide support for the community (as > specified in section 4.3 of RFC8711), so it is out of order for the > LLC to object to community decisions *except as they affect > administrative and technical support*. The proposed text doesn't > capture that limitation. (And no, I don't see that the IAB and IESG > are limited in a similar way.) > >> > > RFC8711 is interesting but not controlling.  What is controlling > are the articles of incorporation, specifically 4(b): > > > >> Specific purpose. The purpose of the Company is to provide a > corporate > legal framework > >> for facilitating current and futureactivities related to the > Internet Engineering Task > >> Force, the Internet Architecture Board (IAB), and the Internet > Research Task Force > >> (IRTF). The intent is that legal responsibility for all > IETF-related activities under the > >> corporate umbrella of the Member as of the Effective Date will > transfer to the Company. > >> Except as minimally necessary to provide appropriate > administrative and legal support > >> (consistent with that historically provided by the Member and > the IETF > Administrative > >> Support Activity (IASA)), formation of the Company is not > intended to change anything > >> related to the oversight or steering of the standards process as > currently conducted by > >> the Internet Engineering Steering Group (IESG) and the IAB, the > appeals chain, the > >> process for making and organizations involved in confirming IETF > and IAB appointments, > >> the IETF Nominations Committee (NomCom), the IRTF, or Member's > memberships in or > >> support of other organizations > > > > The RFC process is not "oversight or steering of the standards > process" > by any measure.   "...corporate legal framework for facilitating > current and future activities.." covers what we're intending for the > RFC process.  The LLC is not and was not intended to be a rubber stamp > for things that need to get paid for or managed.  E.g. the RFC process. > > > > > > And then there's section 4.4 of the RFC8711 - > > > >>     *  Diligence.  The IETF LLC is expected to act responsibly > so as to > >>        minimize risks to IETF participants and to the future of > the IETF > >>        as a whole, such as financial risks. > > (And yes, there is also the Responsiveness to the Community item > in the > same section - both apply or neither). > > > > So, yes, the LLC gets a veto. > > > > Later, Mike > > > > > > > > > >> Regards, > >>   Brian > >> > >>> The IAB, IESG and LLC board are selected by the community > through the > Nomcom process to represent the community and by doing so, to serve > the community.  The LLC does get a veto for good and sufficient > reasons - > e.g. it's a brilliant idea that every one loves, but it will start > breaking the bank in just about 2 years.   Or we've decided to stand > up a second LLC to deal with the specifics of the RFC process as a > subsidiary of the IETF LLC and the money and lawyers and external > support must be gained. Or we want to move a task that's been > contracted for and for which a contract modification may or may not > be possible.  Or any of a number of other items that fall > specifically in the LLC's purview of keeping things legal and > affordable and sustainable. > >>> > >>> Neither the RSWG nor the RSAB are selected by the community, > and so they can't be said to either represent the community or for > that matter serve anything except a specific set of interests which > may not necessarily > align with the IAB/IESG/LLCs own view of the good of the community > or for > that matter the communities own view (for some definition of > community).    So why are they veto-proof? > >>> > >>> Later, Mike > >>> > >>> > >>> > >> > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > > > From nobody Sat Dec 4 19:26:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9513A100B for ; Sat, 4 Dec 2021 19:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_AFFORDABLE=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 CWDbTuxDAKPO for ; Sat, 4 Dec 2021 19:26:35 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A5F13A1008 for ; Sat, 4 Dec 2021 19:26:35 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id y16so8816433ioc.8 for ; Sat, 04 Dec 2021 19:26:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hN8nIagE+iYM1+mTXxhuZDS/CCKMreHNKGC4+7tpaZw=; b=WyhVPA3EKNvE+Qc1ZCfD+PtzSNHzMZMB1TWQVS+xxYxqUFWadTYxLj4X94huVGKHMu V6qcpubamfS3K+jTo+mBEKiJW8/fntVO/k09zL6fQW0vL/2mmX9RKS8k0MzU1FFSKxgp RcC0IN7ExNUHuClSWcMFA5WnrdxWHCuiNlNc2cOkJipJNO3Kgg4RKU5VqettJcPfUxZ2 asqRE1hhnw8mG9T6wzITET6JpraaL3H/cnnmykNABFF+HPr+Pzgr1S80ku8AiM3qipit YHWNQs32KuvCllg5AzLui1QmxhNxFfjhq5Iyvt4eCjFT9AejiF13dzH9e5IKdGenfG0I DDXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=hN8nIagE+iYM1+mTXxhuZDS/CCKMreHNKGC4+7tpaZw=; b=SpTJdpGH2Af16K0ZOzj49A24GLER1MXp8lrJYg6LgdwRNU1T8L8moPs+7X3RL39AJe q63ha2T1K1hd9IgtWHgTEeFiPTJjB0r47+BtNWtB/sEiDBfZ2HxTG5crwPEQQgzB3V2X RhhQm2Om+J8myj60fxsBcMoDwa316Z0NrrXRBUVyZ4oK/tnr6UtRf9DEfPRsyyACOlKV QPsHpD+x3g/PHMFiO/dEYc0wqJlyoTqmyvaXuWdDZ3JW+TwzOWNJ8sNNmMzX2PJQ86BD EEMYhLSg/Yk0PchrMXRiDVrg5rwOt2IQaCmrE1xh0KDfV8WgeranpaoBZKgKvP3kpeGX Z0eA== X-Gm-Message-State: AOAM530y5jfOBSvioiz81oFcHldcnItoypmobnPN3WjCMvL7IKXURZss NI+KO7hiNosvOHPqeAxKUnat1TFhIiektFWQ88TeWaikc2o= X-Google-Smtp-Source: ABdhPJxZJb1JidylpjL7M2ksW6EdL97cLR94Gw1Rc/+6G85t07tHnm/KYogyTMeGDNosXXOKVOYXZZIZfmE23+5dosU= X-Received: by 2002:a05:6638:1696:: with SMTP id f22mr34070183jat.113.1638674793157; Sat, 04 Dec 2021 19:26:33 -0800 (PST) MIME-Version: 1.0 References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> In-Reply-To: From: Eric Rescorla Date: Sat, 4 Dec 2021 19:25:57 -0800 Message-ID: To: "Joel M. Halpern" Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000f2e62805d25db49f" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 03:26:40 -0000 --000000000000f2e62805d25db49f Content-Type: text/plain; charset="UTF-8" That's a good point. I guess the text should stay. Perhaps we also need to add some kind of similar text to the approval phase for ordinary documents? -Ekr On Sat, Dec 4, 2021 at 6:52 PM Joel M. Halpern wrote: > It is a bit of a strecth of course, but, as an example of change that > the LLC would probably be obliged to object to, imagine a change to the > procedure that declared that the LLC had to fund, without question, > whatever the RSWG / RSAB approved. That would be a change to this > document. And, as I understand it, the LLC Board would be violating > their legal obligations if they accepted it. > > Yours, > Joel > > On 12/4/2021 9:35 PM, Eric Rescorla wrote: > > > > > > On Sat, Dec 4, 2021 at 6:21 PM Brian E Carpenter > > > > wrote: > > > > Mike, > > > > Maybe my keyboard wasn't working. I thought I typed "it is out of > > order for the LLC to object to community decisions *except as they > > affect administrative and technical support*." That seems entirely > > consistent with what you are saying. > > > > My proposed rewrite of the sentence in question after seeing other > > comments is: > > > > OLD: > > Updates, amendments and refinements of this document can be produced > > using the process documented here, but are only operative upon > > agreement of the IAB, the IESG, and the IETF LLC. > > > > NEW: > > Updates, amendments and refinements of this document can be produced > > using the process documented here, but are only operative upon > > agreement of the IAB, the IESG, and the IETF LLC > > with regard to matters falling under their respective remits. > > > > Thus, if the RSWG and RSAB deem that RFCs shall be published in > > Esperanto > > instead of English, the LLC could object on grounds of the expense > > and difficulty in hiring translators and copy-editors, but not on > > the grounds that it's a stupid idea. > > > > > > Brian, I agree with your sentiments, but I don't think that this text > > does it, because this document is about the process *not* about the RFC > > Series proper. > > > > So, it seems to me that under this text, the RSWG could mandate > > translation into Klingon without changing the process and only the RSAB > > could object. > > > > Can you give me an example of a change to this document that the LLC > > could have standing to object to? > > > > -Ekr > > > > > > Brian > > > > On 05-Dec-21 14:01, Michael StJohns wrote: > > > On 12/4/2021 7:25 PM, Brian E Carpenter wrote: > > >> On 05-Dec-21 12:32, Michael StJohns wrote: > > >>> On 12/4/2021 3:09 PM, Brian E Carpenter wrote: > > >>>>> Also, I recall that there was a question as to whether the > > LLC should > > >> be in the approval chain. What do people think? > > >>>> > > >>>> The LLC exists to serve the community, so the LLC cannot have > > a veto, but their opinion about feasibility must be heard. I'm not > > quite sure how > > >> best to word that. > > >>> > > >>> I've been off doing other things for a bit but.. > > >>> > > >>> This is a nonsense statement. It is semantically equivalent to > > "The IAB exists to serve the community, so the IAB cannot have a > veto." > > >> Substitute in IESG and you get similar nonsense. I apologize in > > advance if I offend with calling this nonsense, but it truly does > > not make any sense nor can it be made to make sense. > > >> > > >> > > >> No offence, but clearly I expressed it poorly. What I'm getting > > at is that the LLC exists to provide support for the community (as > > specified in section 4.3 of RFC8711), so it is out of order for the > > LLC to object to community decisions *except as they affect > > administrative and technical support*. The proposed text doesn't > > capture that limitation. (And no, I don't see that the IAB and IESG > > are limited in a similar way.) > > >> > > > RFC8711 is interesting but not controlling. What is controlling > > are the articles of incorporation, specifically 4(b): > > > > > >> Specific purpose. The purpose of the Company is to provide a > > corporate > > legal framework > > >> for facilitating current and futureactivities related to the > > Internet Engineering Task > > >> Force, the Internet Architecture Board (IAB), and the Internet > > Research Task Force > > >> (IRTF). The intent is that legal responsibility for all > > IETF-related activities under the > > >> corporate umbrella of the Member as of the Effective Date will > > transfer to the Company. > > >> Except as minimally necessary to provide appropriate > > administrative and legal support > > >> (consistent with that historically provided by the Member and > > the IETF > > Administrative > > >> Support Activity (IASA)), formation of the Company is not > > intended to change anything > > >> related to the oversight or steering of the standards process as > > currently conducted by > > >> the Internet Engineering Steering Group (IESG) and the IAB, the > > appeals chain, the > > >> process for making and organizations involved in confirming IETF > > and IAB appointments, > > >> the IETF Nominations Committee (NomCom), the IRTF, or Member's > > memberships in or > > >> support of other organizations > > > > > > The RFC process is not "oversight or steering of the standards > > process" > > by any measure. "...corporate legal framework for facilitating > > current and future activities.." covers what we're intending for the > > RFC process. The LLC is not and was not intended to be a rubber > stamp > > for things that need to get paid for or managed. E.g. the RFC > process. > > > > > > > > > And then there's section 4.4 of the RFC8711 - > > > > > >> * Diligence. The IETF LLC is expected to act responsibly > > so as to > > >> minimize risks to IETF participants and to the future of > > the IETF > > >> as a whole, such as financial risks. > > > (And yes, there is also the Responsiveness to the Community item > > in the > > same section - both apply or neither). > > > > > > So, yes, the LLC gets a veto. > > > > > > Later, Mike > > > > > > > > > > > > > > >> Regards, > > >> Brian > > >> > > >>> The IAB, IESG and LLC board are selected by the community > > through the > > Nomcom process to represent the community and by doing so, to serve > > the community. The LLC does get a veto for good and sufficient > > reasons - > > e.g. it's a brilliant idea that every one loves, but it will start > > breaking the bank in just about 2 years. Or we've decided to stand > > up a second LLC to deal with the specifics of the RFC process as a > > subsidiary of the IETF LLC and the money and lawyers and external > > support must be gained. Or we want to move a task that's been > > contracted for and for which a contract modification may or may not > > be possible. Or any of a number of other items that fall > > specifically in the LLC's purview of keeping things legal and > > affordable and sustainable. > > >>> > > >>> Neither the RSWG nor the RSAB are selected by the community, > > and so they can't be said to either represent the community or for > > that matter serve anything except a specific set of interests which > > may not necessarily > > align with the IAB/IESG/LLCs own view of the good of the community > > or for > > that matter the communities own view (for some definition of > > community). So why are they veto-proof? > > >>> > > >>> Later, Mike > > >>> > > >>> > > >>> > > >> > > > > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > > > > > > --000000000000f2e62805d25db49f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That's a good point. I guess the text should stay= . Perhaps we also need to add some kind of similar text to the approval pha= se for ordinary documents?

-Ekr

=
On Sat, Dec 4, 2021 at 6:52 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
It is a bit of a strecth of course, but,= as an example of change that
the LLC would probably be obliged to object to, imagine a change to the procedure that declared that the LLC had to fund, without question,
whatever the RSWG / RSAB approved.=C2=A0 That would be a change to this document.=C2=A0 And, as I understand it, the LLC Board would be violating <= br> their legal obligations if they accepted it.

Yours,
Joel

On 12/4/2021 9:35 PM, Eric Rescorla wrote:
>
>
> On Sat, Dec 4, 2021 at 6:21 PM Brian E Carpenter
> <b= rian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wro= te:
>
>=C2=A0 =C2=A0 =C2=A0Mike,
>
>=C2=A0 =C2=A0 =C2=A0Maybe my keyboard wasn't working. I thought I t= yped "it is out of
>=C2=A0 =C2=A0 =C2=A0order for the LLC to object to community decisions = *except as they
>=C2=A0 =C2=A0 =C2=A0affect administrative and technical support*."= That seems entirely
>=C2=A0 =C2=A0 =C2=A0consistent with what you are saying.
>
>=C2=A0 =C2=A0 =C2=A0My proposed rewrite of the sentence in question aft= er seeing other
>=C2=A0 =C2=A0 =C2=A0comments is:
>
>=C2=A0 =C2=A0 =C2=A0OLD:
>=C2=A0 =C2=A0 =C2=A0Updates, amendments and refinements of this documen= t can be produced
>=C2=A0 =C2=A0 =C2=A0using the process documented here, but are only ope= rative upon
>=C2=A0 =C2=A0 =C2=A0agreement of the IAB, the IESG, and the IETF LLC. >
>=C2=A0 =C2=A0 =C2=A0NEW:
>=C2=A0 =C2=A0 =C2=A0Updates, amendments and refinements of this documen= t can be produced
>=C2=A0 =C2=A0 =C2=A0using the process documented here, but are only ope= rative upon
>=C2=A0 =C2=A0 =C2=A0agreement of the IAB, the IESG, and the IETF LLC >=C2=A0 =C2=A0 =C2=A0with regard to matters falling under their respecti= ve remits.
>
>=C2=A0 =C2=A0 =C2=A0Thus, if the RSWG and RSAB deem that RFCs shall be = published in
>=C2=A0 =C2=A0 =C2=A0Esperanto
>=C2=A0 =C2=A0 =C2=A0instead of English, the LLC could object on grounds= of the expense
>=C2=A0 =C2=A0 =C2=A0and difficulty in hiring translators and copy-edito= rs, but not on
>=C2=A0 =C2=A0 =C2=A0the grounds that it's a stupid idea.
>
>
> Brian, I agree with your sentiments, but I don't think that this t= ext
> does it, because this document is about the process *not* about the RF= C
> Series proper.
>
> So, it seems to me that under this text, the RSWG could mandate
> translation into Klingon without changing the process and only the RSA= B
> could object.
>
> Can you give me an example of a change to this document that the LLC <= br> > could have standing to object to?
>
> -Ekr
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Brian
>
>=C2=A0 =C2=A0 =C2=A0On 05-Dec-21 14:01, Michael StJohns wrote:
>=C2=A0 =C2=A0 =C2=A0 > On 12/4/2021 7:25 PM, Brian E Carpenter wrote= :
>=C2=A0 =C2=A0 =C2=A0 >> On 05-Dec-21 12:32, Michael StJohns wrote= :
>=C2=A0 =C2=A0 =C2=A0 >>> On 12/4/2021 3:09 PM, Brian E Carpent= er wrote:
>=C2=A0 =C2=A0 =C2=A0 >>>>> Also, I recall that there was= a question as to whether the
>=C2=A0 =C2=A0 =C2=A0LLC should
>=C2=A0 =C2=A0 =C2=A0 >> be in the approval chain.=C2=A0 What do p= eople think?
>=C2=A0 =C2=A0 =C2=A0 >>>>
>=C2=A0 =C2=A0 =C2=A0 >>>> The LLC exists to serve the commu= nity, so the LLC cannot have
>=C2=A0 =C2=A0 =C2=A0a veto, but their opinion about feasibility must be= heard. I'm not
>=C2=A0 =C2=A0 =C2=A0quite sure how
>=C2=A0 =C2=A0 =C2=A0 >> best to word that.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> I've been off doing other things = for a bit but..
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> This is a nonsense statement.=C2=A0 I= t is semantically equivalent to
>=C2=A0 =C2=A0 =C2=A0"The IAB exists to serve the community, so the= IAB cannot have a veto."
>=C2=A0 =C2=A0 =C2=A0 >> Substitute in IESG and you get similar no= nsense.=C2=A0 I apologize in
>=C2=A0 =C2=A0 =C2=A0advance if I offend with calling this nonsense, but= it truly does
>=C2=A0 =C2=A0 =C2=A0not make any sense nor can it be made to make sense= .
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> No offence, but clearly I expressed it po= orly.=C2=A0 What I'm getting
>=C2=A0 =C2=A0 =C2=A0at is that the LLC exists to provide support for th= e community (as
>=C2=A0 =C2=A0 =C2=A0specified in section 4.3 of RFC8711), so it is out = of order for the
>=C2=A0 =C2=A0 =C2=A0LLC to object to community decisions *except as the= y affect
>=C2=A0 =C2=A0 =C2=A0administrative and technical support*. The proposed= text doesn't
>=C2=A0 =C2=A0 =C2=A0capture that limitation. (And no, I don't see t= hat the IAB and IESG
>=C2=A0 =C2=A0 =C2=A0are limited in a similar way.)
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 > RFC8711 is interesting but not controlling.= =C2=A0 What is controlling
>=C2=A0 =C2=A0 =C2=A0are the articles of incorporation, specifically 4(b= ):
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >> Specific purpose. The purpose of the Comp= any is to provide a
>=C2=A0 =C2=A0 =C2=A0corporate
>=C2=A0 =C2=A0 =C2=A0legal framework
>=C2=A0 =C2=A0 =C2=A0 >> for facilitating current and futureactivi= ties related to the
>=C2=A0 =C2=A0 =C2=A0Internet Engineering Task
>=C2=A0 =C2=A0 =C2=A0 >> Force, the Internet Architecture Board (I= AB), and the Internet
>=C2=A0 =C2=A0 =C2=A0Research Task Force
>=C2=A0 =C2=A0 =C2=A0 >> (IRTF). The intent is that legal responsi= bility for all
>=C2=A0 =C2=A0 =C2=A0IETF-related activities under the
>=C2=A0 =C2=A0 =C2=A0 >> corporate umbrella of the Member as of th= e Effective Date will
>=C2=A0 =C2=A0 =C2=A0transfer to the Company.
>=C2=A0 =C2=A0 =C2=A0 >> Except as minimally necessary to provide = appropriate
>=C2=A0 =C2=A0 =C2=A0administrative and legal support
>=C2=A0 =C2=A0 =C2=A0 >> (consistent with that historically provid= ed by the Member and
>=C2=A0 =C2=A0 =C2=A0the IETF
>=C2=A0 =C2=A0 =C2=A0Administrative
>=C2=A0 =C2=A0 =C2=A0 >> Support Activity (IASA)), formation of th= e Company is not
>=C2=A0 =C2=A0 =C2=A0intended to change anything
>=C2=A0 =C2=A0 =C2=A0 >> related to the oversight or steering of t= he standards process as
>=C2=A0 =C2=A0 =C2=A0currently conducted by
>=C2=A0 =C2=A0 =C2=A0 >> the Internet Engineering Steering Group (= IESG) and the IAB, the
>=C2=A0 =C2=A0 =C2=A0appeals chain, the
>=C2=A0 =C2=A0 =C2=A0 >> process for making and organizations invo= lved in confirming IETF
>=C2=A0 =C2=A0 =C2=A0and IAB appointments,
>=C2=A0 =C2=A0 =C2=A0 >> the IETF Nominations Committee (NomCom), = the IRTF, or Member's
>=C2=A0 =C2=A0 =C2=A0memberships in or
>=C2=A0 =C2=A0 =C2=A0 >> support of other organizations
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > The RFC process is not "oversight or ste= ering of the standards
>=C2=A0 =C2=A0 =C2=A0process"
>=C2=A0 =C2=A0 =C2=A0by any measure.=C2=A0=C2=A0 "...corporate lega= l framework for facilitating
>=C2=A0 =C2=A0 =C2=A0current and future activities.." covers what w= e're intending for the
>=C2=A0 =C2=A0 =C2=A0RFC process.=C2=A0 The LLC is not and was not inten= ded to be a rubber stamp
>=C2=A0 =C2=A0 =C2=A0for things that need to get paid for or managed.=C2= =A0 E.g. the RFC process.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > And then there's section 4.4 of the RFC87= 11 -
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0*=C2=A0 Diligence.=C2= =A0 The IETF LLC is expected to act responsibly
>=C2=A0 =C2=A0 =C2=A0so as to
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 minimize risks= to IETF participants and to the future of
>=C2=A0 =C2=A0 =C2=A0the IETF
>=C2=A0 =C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a whole, su= ch as financial risks.
>=C2=A0 =C2=A0 =C2=A0 > (And yes, there is also the Responsiveness to= the Community item
>=C2=A0 =C2=A0 =C2=A0in the
>=C2=A0 =C2=A0 =C2=A0same section - both apply or neither).
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > So, yes, the LLC gets a veto.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Later, Mike
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >> Regards,
>=C2=A0 =C2=A0 =C2=A0 >> =C2=A0 Brian
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >>> The IAB, IESG and LLC board are selec= ted by the community
>=C2=A0 =C2=A0 =C2=A0through the
>=C2=A0 =C2=A0 =C2=A0Nomcom process to represent the community and by do= ing so, to serve
>=C2=A0 =C2=A0 =C2=A0the community.=C2=A0 The LLC does get a veto for go= od and sufficient
>=C2=A0 =C2=A0 =C2=A0reasons -
>=C2=A0 =C2=A0 =C2=A0e.g. it's a brilliant idea that every one loves= , but it will start
>=C2=A0 =C2=A0 =C2=A0breaking the bank in just about 2 years.=C2=A0=C2= =A0 Or we've decided to stand
>=C2=A0 =C2=A0 =C2=A0up a second LLC to deal with the specifics of the R= FC process as a
>=C2=A0 =C2=A0 =C2=A0subsidiary of the IETF LLC and the money and lawyer= s and external
>=C2=A0 =C2=A0 =C2=A0support must be gained. Or we want to move a task t= hat's been
>=C2=A0 =C2=A0 =C2=A0contracted for and for which a contract modificatio= n may or may not
>=C2=A0 =C2=A0 =C2=A0be possible.=C2=A0 Or any of a number of other item= s that fall
>=C2=A0 =C2=A0 =C2=A0specifically in the LLC's purview of keeping th= ings legal and
>=C2=A0 =C2=A0 =C2=A0affordable and sustainable.
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> Neither the RSWG nor the RSAB are sel= ected by the community,
>=C2=A0 =C2=A0 =C2=A0and so they can't be said to either represent t= he community or for
>=C2=A0 =C2=A0 =C2=A0that matter serve anything except a specific set of= interests which
>=C2=A0 =C2=A0 =C2=A0may not necessarily
>=C2=A0 =C2=A0 =C2=A0align with the IAB/IESG/LLCs own view of the good o= f the community
>=C2=A0 =C2=A0 =C2=A0or for
>=C2=A0 =C2=A0 =C2=A0that matter the communities own view (for some defi= nition of
>=C2=A0 =C2=A0 =C2=A0community).=C2=A0=C2=A0=C2=A0 So why are they veto-= proof?
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>> Later, Mike
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>>
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Rfced-future mailing list
>=C2=A0 =C2=A0 =C2=A0Rfced-future@iab.org <mailto:Rfced-future@iab.org>
>=C2=A0 =C2=A0 =C2=A0https://www.iab.org/mailman= /listinfo/rfced-future
>=C2=A0 =C2=A0 =C2=A0<https://www.iab.org/mai= lman/listinfo/rfced-future>
>
>
--000000000000f2e62805d25db49f-- From nobody Sat Dec 4 19:27:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C38173A100E for ; Sat, 4 Dec 2021 19:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.95 X-Spam-Level: X-Spam-Status: No, score=-2.95 tagged_above=-999 required=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, GB_AFFORDABLE=1, NICE_REPLY_A=-1.852, 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 UMeLZHLr63Ek for ; Sat, 4 Dec 2021 19:27:37 -0800 (PST) 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 80D743A100D for ; Sat, 4 Dec 2021 19:27:37 -0800 (PST) Received: by mail-pj1-x102c.google.com with SMTP id fv9-20020a17090b0e8900b001a6a5ab1392so5668902pjb.1 for ; Sat, 04 Dec 2021 19:27:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=A1ORSd4LBcg25vItbG0U/kA5to+ZKrIOeKXkHxGCTGE=; b=GCu62jNeQMRA65TXuDaNoc+3JNdgYcCiYCwhds2qprp+0PgYvvc2YhPoBeXON/Q5vx nOFeJBzKxbuGzZ3chz0nmcIs7nikThOROYIm3oVjTZdY3GvfGr0DLBY7pMIk2c2/CHnq 13FSzcBPuMSYWsdZUM6x8zkwGckm0vX2ley05XJUzYiI7Y8kjrUaHAPykqedvXYGGI4B 0vciEpRNZawGBpVsOBEVJQq2JFdOCbDPS4d/KrsV9rEfMfsHvGNzupkInDJyj4U3+jo1 ntU31XrEDdoQqaGGaIXt8mntoSBnboTJEnj0o4bBPBIMphhmX9CJzOrnsclk38Zp0MVB J/TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=A1ORSd4LBcg25vItbG0U/kA5to+ZKrIOeKXkHxGCTGE=; b=7n4MB9m4L+uOIrCTAJdA4y5k339+h/VzCc09NYsyLmUI/KtS+vJMdo0boIUBZ0wRNg 45Yq0oHPWDebkrr0zlDgYwP3/KdN1FHMdpIth2sbRD+VWdF6OZLmd8y9CJO3EUyycqp/ YyS/cwcbQo6LWDMLPkM+4E4jy7tCAHPE+5FH0VzGQm6Rr+RG/94HkDpFCeMyZB47x4ZK /4UFROSGpJrorHZPa2Bl71qq+iqX1ObJ6EiFh+3XvtZOL9PgPSN5JGcYG+c6VCfV5sQ3 yyuV2wfAe5idsI2DmW37+uiUgxv1yOrPVuxKknzyGDGddXtJoJOfu5TmSKsawdHIr/7r pmIg== X-Gm-Message-State: AOAM531kWfQflvFg3ExgwNlRtkC6lO42WpwMey1PgNAgkdTWJbvhaDLQ JWzRy+cwWL2sfqcS984acdUiZJvXcHUYDA== X-Google-Smtp-Source: ABdhPJweGZWtAU96HPWVVZWCbTFJqAxcqBnlnzKn9EpeNXuLYXG+ONvifIXNVy4ius648bHTT57cng== X-Received: by 2002:a17:90b:1293:: with SMTP id fw19mr26740260pjb.155.1638674855438; Sat, 04 Dec 2021 19:27:35 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:db7:d041:a2d:ce65? ([2406:e003:102d:e801:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id 130sm7627361pfu.13.2021.12.04.19.27.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 04 Dec 2021 19:27:35 -0800 (PST) To: "Joel M. Halpern" , Eric Rescorla Cc: rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> From: Brian E Carpenter Message-ID: <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> Date: Sun, 5 Dec 2021 16:27:31 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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 Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 03:27:42 -0000 Yes, or any change that the LLC's lawyers advised would expose the LLC to serious legal risk. I'm not a lawyer so I won't invent an example. Really, my phrase "with regard to matters falling under their respective remits" was intended to be non-specific, so maybe it was a mistake to invent an example. Regards Brian On 05-Dec-21 15:52, Joel M. Halpern wrote: > It is a bit of a strecth of course, but, as an example of change that > the LLC would probably be obliged to object to, imagine a change to the= > procedure that declared that the LLC had to fund, without question, > whatever the RSWG / RSAB approved. That would be a change to this > document. And, as I understand it, the LLC Board would be violating > their legal obligations if they accepted it. >=20 > Yours, > Joel >=20 > On 12/4/2021 9:35 PM, Eric Rescorla wrote: >> >> >> On Sat, Dec 4, 2021 at 6:21 PM Brian E Carpenter >> > wro= te: >> >> Mike, >> >> Maybe my keyboard wasn't working. I thought I typed "it is out of= >> order for the LLC to object to community decisions *except as the= y >> affect administrative and technical support*." That seems entirel= y >> consistent with what you are saying. >> >> My proposed rewrite of the sentence in question after seeing othe= r >> comments is: >> >> OLD: >> Updates, amendments and refinements of this document can be produ= ced >> using the process documented here, but are only operative upon >> agreement of the IAB, the IESG, and the IETF LLC. >> >> NEW: >> Updates, amendments and refinements of this document can be produ= ced >> using the process documented here, but are only operative upon >> agreement of the IAB, the IESG, and the IETF LLC >> with regard to matters falling under their respective remits. >> >> Thus, if the RSWG and RSAB deem that RFCs shall be published in >> Esperanto >> instead of English, the LLC could object on grounds of the expens= e >> and difficulty in hiring translators and copy-editors, but not on= >> the grounds that it's a stupid idea. >> >> >> Brian, I agree with your sentiments, but I don't think that this text >> does it, because this document is about the process *not* about the RF= C >> Series proper. >> >> So, it seems to me that under this text, the RSWG could mandate >> translation into Klingon without changing the process and only the RSA= B >> could object. >> >> Can you give me an example of a change to this document that the LLC >> could have standing to object to? >> >> -Ekr >> >> >> =C2=A0 =C2=A0 Brian >> >> On 05-Dec-21 14:01, Michael StJohns wrote: >> > On 12/4/2021 7:25 PM, Brian E Carpenter wrote: >> >> On 05-Dec-21 12:32, Michael StJohns wrote: >> >>> On 12/4/2021 3:09 PM, Brian E Carpenter wrote: >> >>>>> Also, I recall that there was a question as to whether the= >> LLC should >> >> be in the approval chain.=C2=A0 What do people think? >> >>>> >> >>>> The LLC exists to serve the community, so the LLC cannot ha= ve >> a veto, but their opinion about feasibility must be heard. I'm no= t >> quite sure how >> >> best to word that. >> >>> >> >>> I've been off doing other things for a bit but.. >> >>> >> >>> This is a nonsense statement.=C2=A0 It is semantically equiv= alent to >> "The IAB exists to serve the community, so the IAB cannot have a = veto." >> >> Substitute in IESG and you get similar nonsense.=C2=A0 I apol= ogize in >> advance if I offend with calling this nonsense, but it truly does= >> not make any sense nor can it be made to make sense. >> >> >> >> >> >> No offence, but clearly I expressed it poorly.=C2=A0 What I'm=20 getting >> at is that the LLC exists to provide support for the community (a= s >> specified in section 4.3 of RFC8711), so it is out of order for t= he >> LLC to object to community decisions *except as they affect >> administrative and technical support*. The proposed text doesn't >> capture that limitation. (And no, I don't see that the IAB and IE= SG >> are limited in a similar way.) >> >> >> > RFC8711 is interesting but not controlling.=C2=A0 What is cont= rolling >> are the articles of incorporation, specifically 4(b): >> > >> >> Specific purpose. The purpose of the Company is to provide a >> corporate >> legal framework >> >> for facilitating current and futureactivities related to the >> Internet Engineering Task >> >> Force, the Internet Architecture Board (IAB), and the Interne= t >> Research Task Force >> >> (IRTF). The intent is that legal responsibility for all >> IETF-related activities under the >> >> corporate umbrella of the Member as of the Effective Date wil= l >> transfer to the Company. >> >> Except as minimally necessary to provide appropriate >> administrative and legal support >> >> (consistent with that historically provided by the Member and= >> the IETF >> Administrative >> >> Support Activity (IASA)), formation of the Company is not >> intended to change anything >> >> related to the oversight or steering of the standards process=20 as >> currently conducted by >> >> the Internet Engineering Steering Group (IESG) and the IAB, t= he >> appeals chain, the >> >> process for making and organizations involved in confirming I= ETF >> and IAB appointments, >> >> the IETF Nominations Committee (NomCom), the IRTF, or Member'= s >> memberships in or >> >> support of other organizations >> > >> > The RFC process is not "oversight or steering of the standards= >> process" >> by any measure.=C2=A0=C2=A0 "...corporate legal framework for fac= ilitating >> current and future activities.." covers what we're intending for = the >> RFC process.=C2=A0 The LLC is not and was not intended to be a ru= bber stamp >> for things that need to get paid for or managed.=C2=A0 E.g. the R= FC process. >> > >> > >> > And then there's section 4.4 of the RFC8711 - >> > >> >>=C2=A0 =C2=A0 =C2=A0*=C2=A0 Diligence.=C2=A0 The IETF LLC is e= xpected to act responsibly >> so as to >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 minimize risks to IETF participant= s and to the future of >> the IETF >> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 as a whole, such as financial risk= s. >> > (And yes, there is also the Responsiveness to the Community it= em >> in the >> same section - both apply or neither). >> > >> > So, yes, the LLC gets a veto. >> > >> > Later, Mike >> > >> > >> > >> > >> >> Regards, >> >> =C2=A0 Brian >> >> >> >>> The IAB, IESG and LLC board are selected by the community >> through the >> Nomcom process to represent the community and by doing so, to ser= ve >> the community.=C2=A0 The LLC does get a veto for good and suffici= ent >> reasons - >> e.g. it's a brilliant idea that every one loves, but it will star= t >> breaking the bank in just about 2 years.=C2=A0=C2=A0 Or we've dec= ided to stand >> up a second LLC to deal with the specifics of the RFC process as = a >> subsidiary of the IETF LLC and the money and lawyers and external= >> support must be gained. Or we want to move a task that's been >> contracted for and for which a contract modification may or may n= ot >> be possible.=C2=A0 Or any of a number of other items that fall >> specifically in the LLC's purview of keeping things legal and >> affordable and sustainable. >> >>> >> >>> Neither the RSWG nor the RSAB are selected by the community,= >> and so they can't be said to either represent the community or fo= r >> that matter serve anything except a specific set of interests whi= ch >> may not necessarily >> align with the IAB/IESG/LLCs own view of the good of the communit= y >> or for >> that matter the communities own view (for some definition of >> community).=C2=A0=C2=A0=C2=A0 So why are they veto-proof? >> >>> >> >>> Later, Mike >> >>> >> >>> >> >>> >> >> >> > >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> >> >> >=20 From nobody Sun Dec 5 00:05:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80BE03A0AB5 for ; Sun, 5 Dec 2021 00:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbkvXG6f2Ykq for ; Sun, 5 Dec 2021 00:05:33 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 3521C3A0AB0 for ; Sun, 5 Dec 2021 00:05:32 -0800 (PST) Received: from [192.168.0.132] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B584meG1377395 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sun, 5 Dec 2021 09:04:48 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638691492; bh=ZgQ9b0jqwQgd+PVzMtKrxUa71WYiMAxxKVSFVMvp8DY=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=fh+u+Aiuv8Hodlix+AIK+lbw1PV4cdBDG1E34yIPgYSwbBtqG0D7q6BVeACtaXJd4 IjOeeAljVjifJY+CH0PXKlVIR+eRB8UuQYtoBf4XOci0Sc0eDzVFBKL/OwaGmVsnT8 szBG0j+Nyq2fvyk2o2EAJdeahzN8qtW/Flgym2uo= Message-ID: <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> Date: Sun, 5 Dec 2021 09:04:47 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Brian E Carpenter , "Joel M. Halpern" , Eric Rescorla Cc: rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> From: Eliot Lear In-Reply-To: <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------LLoTcma2L0YsQNnwlAxt4F7i" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:05:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------LLoTcma2L0YsQNnwlAxt4F7i Content-Type: multipart/mixed; boundary="------------SshHu6svzx1ZJ4A7hsk0jcy5"; protected-headers="v1" From: Eliot Lear To: Brian E Carpenter , "Joel M. Halpern" , Eric Rescorla Cc: rfced-future@iab.org Message-ID: <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> In-Reply-To: <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> --------------SshHu6svzx1ZJ4A7hsk0jcy5 Content-Type: multipart/mixed; boundary="------------bbTBl8aMLpuGg87oDPmWolwu" --------------bbTBl8aMLpuGg87oDPmWolwu Content-Type: multipart/alternative; boundary="------------00MS4V2L072PWTXcQpA1xLCs" --------------00MS4V2L072PWTXcQpA1xLCs Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 WWVzLCBJIHRoaW5rIHdlIG1peGVkIHR3byB0aGluZ3MgdXA6DQoNCiAgKiBUaGUgcHJvY2Vz cyBmb3IgY2hhbmdpbmcgdGhlIGdvdmVybmluZyBkb2N1bWVudCB3ZSBhcmUgZGV2ZWxvcGlu ZywgYW5kDQogICogVGhlIGdlbmVyYWwgYXBwcm92YWwgcHJvY2VzcyBmb3IgZG9jdW1lbnRz IGZyb20gdGhlIFJTV0cNCg0KV2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGZvcm1lci7CoCBG b3IgdGhlIGxhdHRlciwgd2UgZGlzY3Vzc2VkIHRoaXMgYW5kIA0KdGhlcmUgaXMgdGV4dCBp biB0aGUgZHJhZnQgdGhhdCBzdGF0ZXMgdGhhdDoNCg0KPiDCoMKgIHRoZSBSU0FCIHNoYWxs DQo+IMKgwqAgaW5jbHVkZSB0aGUgSUVURiBFeGVjdXRpdmUgRGlyZWN0b3Igb3IgdGhlaXIg ZGVsZWdhdGUgYXMgYSBub24tdm90aW5nDQo+IMKgwqAgbWVtYmVyIHNpbmNlIHRoZSBJRVRG IExMQyBpcyByZXNwb25zaWJsZSBmb3IgaW1wbGVtZW50YXRpb24gb2YNCj4gwqDCoCBwb2xp Y2llcyBnb3Zlcm5pbmcgdGhlIFJGQyBTZXJpZXMuDQoNClRoYXQncyBiZWNhdXNlIG9uZSBj b3VsZCBlbnZpc2lvbiBhIGdvb2QgbWFueSBjaGFuZ2VzIHRoYXQgd291bGQgcmVxdWlyZSAN CnF1aXRlIGEgbnVtYmVyIG9mIGFkanVzdG1lbnRzLCBpbmNsdWRpbmcgY29udHJhY3R1YWwg b25lcy4NCg0KRWxpb3QNCg0K --------------00MS4V2L072PWTXcQpA1xLCs Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Yes, I think we mixed two things up:

  • The process for changing the governing document we are developing, and
  • The general approval process for documents from the RSWG

We are talking about the former.=C2=A0 For the latter, we discusse= d this and there is text in the draft that states that:

=C2=A0=C2=A0 the RSAB shall
=C2=A0=C2=A0 include the IETF Executive Director or their delegat= e as a non-voting
=C2=A0=C2=A0 member since the IETF LLC is responsible for impleme= ntation of
=C2=A0=C2=A0 policies governing the RFC Series.

That's because one could envision a good many changes that would require quite a number of adjustments, including contractual ones.<= /p>

Eliot

--------------00MS4V2L072PWTXcQpA1xLCs-- --------------bbTBl8aMLpuGg87oDPmWolwu Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------bbTBl8aMLpuGg87oDPmWolwu-- --------------SshHu6svzx1ZJ4A7hsk0jcy5-- --------------LLoTcma2L0YsQNnwlAxt4F7i Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGscp8FAwAAAAAACgkQh7ZrRtnSejO8 fQf8CipdkX/O9fUbLSaX0uS87Q5db5DsL2FNE5DGRo7WrJrje4321XiAwXuJ2wVBgAnCJ81WiTje Ve/1Hwu/nsp+iKlSzInj/aXAcWWnu6R82arQrTprJMe1N7+t9AV1fZ8vmvtsMsHSo83X7Yl5+9J9 BJRz7czt8wbAI4/TxrdN0EiVDzVX2P3QQUXT2Z62YV9qBuxt26BmBAjcLW8rRfBitWo09fitsEfX OdQzkeBLiTOraleqSs4YUQd0oBEJewqz/N6qtEQ4QYKMsyWa1yVEbZ6hwLx04EcMQeC4bWK1uwIM YStmuJhcBNrrVzDcJm7RRIGrHmrwYqj2mikbbzrTOA== =mptr -----END PGP SIGNATURE----- --------------LLoTcma2L0YsQNnwlAxt4F7i-- From nobody Sun Dec 5 00:36:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1114F3A126C for ; Sun, 5 Dec 2021 00:35:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=EDj5HKGD; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=J2dviGVR Received: 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_XhAtWfFO3N for ; Sun, 5 Dec 2021 00:35:54 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4833F3A126D for ; Sun, 5 Dec 2021 00:35:54 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 776CB3200AB0 for ; Sun, 5 Dec 2021 02:39:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Sun, 05 Dec 2021 02:39:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=NlEPpyAOPfh kNuw2hCeOa7ZogaYo2seX1VFxtY3Wqqs=; b=EDj5HKGDxmQ1qFvVEmM8HMbddyq vow7Gs6XitlYiYnqsklSd2CglwDALzD40oWePFb4VFg9wMgAjRlyzXp0qZBmW1Um d8DkzEnaT9VgJ0PuVeAjNm9HAV1fs1M696jQrUx42oK7YdLEfHsE3VR4KIhVE/gh eiZA9MwiTvOG7nwc+OPjXRpfiphYUa+FvTSA0weoUVhs32b+rhcIxOr32QlXog9N aAlztWXgLBlD19y1P94owCCa1rOM2B+OABdenUxMCSnmHSNcJNByvSifxTa9RuOf mhtJD73sOvoORuDnSNgsasHkjOCzUIsvfIzMBAKARIoZQ1Hp106z04Egi6A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=NlEPpyAOPfhkNuw2hCeOa7ZogaYo2seX1VFxtY3Wqqs=; b=J2dviGVR LcVwmjY3ueDlYtZ628tqQho/nJC6JLNt8JEONmhudv6sEo9fbJ9HEHbrJ0wn2l8u r8z4uwocVd1o7TMo7HO1EBEbZLCRMlg5T5vkN3P3pKtQfkq/7ZQbIgNMgj79N9Lo g2BjajNWiHnnRwBUAfkxWVjrIiD6uN/wNef87eACGGi7mwk2/jky1tfjAv/s0Iwo Os0xpcHDOAIDk//QL7WkXOdIAIKgWnC0KeTbWvSYuaZU5gAsSJtYuDPxpIsoJzFe SgkKDkYFt8flJUYqzrqW+95hwdqS7Rv0lpmWxtGomOWczWND8h7ZWWCD4LWVesgK /2gbJgdoqxoA1w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjedtgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 5 Dec 2021 02:39:39 -0500 (EST) Content-Type: multipart/alternative; boundary="===============2092877803909737247==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: rfced-future@iab.org Message-Id: <20211205083554.4833F3A126D@ietfa.amsl.com> Date: Sun, 5 Dec 2021 00:35:54 -0800 (PST) Archived-At: Subject: [Rfced-future] Weekly github digest (RFC Editor Future Development Program Activity Summary) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:35:59 -0000 --===============2092877803909737247== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events=20 Issues ------ * intarchboard/program-rfced-future (+0/-1/=F0=9F=92=AC3) 2 issues received 3 new comments: - #134 How do we update This document? (2 by elear) https://github.com/intarchboard/program-rfced-future/issues/134=20 - #129 RSWG chairs issue community call, not RSAB (1 by elear) https://github.com/intarchboard/program-rfced-future/issues/129=20 1 issues closed: - RSWG chairs issue community call, not RSAB https://github.com/intarchbo= ard/program-rfced-future/issues/129=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/program-rfced-future --===============2092877803909737247== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (RFC Editor Future Development Program Activity= Summary)

Sunday December 05, 2021

Events

Issues

intarchboard/program-rfced-future (+0/-1/=F0=9F=92=AC3)

2 issues received 3 new comments:

1 issues closed:

Repositories tracked by this digest:
--===============2092877803909737247==-- From nobody Sun Dec 5 01:02:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DA13A12B1 for ; Sun, 5 Dec 2021 01:02:02 -0800 (PST) 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 eYUh7kvcseSP for ; Sun, 5 Dec 2021 01:01:57 -0800 (PST) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B1273A12B0 for ; Sun, 5 Dec 2021 01:01:57 -0800 (PST) Received: by mail-lj1-x231.google.com with SMTP id 13so14906830ljj.11 for ; Sun, 05 Dec 2021 01:01:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=r8NRie9ahzESxLjou0J0DFtAHVgGEl9IOuThOlP4nl0=; b=NdSUrvwHOxZmhHNd/Me4B5/dn289A8MK5a0W4BSnskcKh+kOdRanM6ODd3IoOEYb3T l5mOSpjw+cdGLxmttrX2OZIOYcTSYzdR2HJQUXrBFkFjMpPNpSE4WFb/fq8BGZKdDvNa Y5kaeBr+E63apQr62zk2zO6iJFIWRrTqOjQTk+7Qo97V7Hl2Je6kGYUr96afhvyuawYF w/E3O8UdxULkBjY0FXQsJd8cckg29YPGJ1E/JAnN39nKfS9dSW536eufCluee+5K+xFr hzov89pRZiLFvmA4WRk6ki45mu16xB4BbpXkSTKYLxhs1GvBLhs+KGs0Q26takgKCQZr 2osQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=r8NRie9ahzESxLjou0J0DFtAHVgGEl9IOuThOlP4nl0=; b=Wjztl6OY8XA1J2f9qhbqd2aDMaM2NibiW6Op2h/AYYN2Fl8LgT/4s5+KDDJtIlDJUI +8YLMWRp/Bgan7NUOUJ8eG1h+FYV46TmyAZjp86NWNgR/8c0KGjBJ6DPn0lpG8tlCFmn UnOKwySI6ytsHahcTP+7mVoSDhM8e85r+DJ1LhSHQWtzJcu0x6fGpLOVShhonVJMBdtN hP9Kjfffa/mzXZEm1Cf5pdg/6Ro9bvbxjkcTwcfTlhyR2IlncmNtb4NKJBNeHxoQuehd +RYo3zOec1IpLNVZa287hqnk/NLWu7y7yFl7zYnpnudqKwCQxGwJxGbKNac4ll/td85P JS3g== X-Gm-Message-State: AOAM531SUo4t0GDqAhsnf/tBvJB/VJjofC/XXuRFWU+3nY+2SDApsZPF BHAqjq7oShEFxmJirCnOFj3LZ8qFr0dRvUjxq7TP26Y2tTo= X-Google-Smtp-Source: ABdhPJwYvmLgSkhZQyMg3XXn7KA/Q5qvYGVp7FF3ynbHxTCZUpj9dG9ekkTVyeNYu3FX/vTspzwBLktx61aAxz+5id0= X-Received: by 2002:a2e:9641:: with SMTP id z1mr31182087ljh.66.1638694912815; Sun, 05 Dec 2021 01:01:52 -0800 (PST) MIME-Version: 1.0 References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> In-Reply-To: <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> From: Brian Carpenter Date: Sun, 5 Dec 2021 22:01:41 +1300 Message-ID: To: Eliot Lear Cc: "Joel M. Halpern" , Eric Rescorla , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000002c764105d262641c" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 09:02:02 -0000 --0000000000002c764105d262641c Content-Type: text/plain; charset="UTF-8" Exactly, and there is no problem with the second point. For the first point, my concern is that the LLC should stay in its lane when changes to the model are in discussion. Regards, Brian Carpenter (via tiny screen & keyboard) On Sun, 5 Dec 2021, 21:04 Eliot Lear, wrote: > Yes, I think we mixed two things up: > > - The process for changing the governing document we are developing, > and > - The general approval process for documents from the RSWG > > We are talking about the former. For the latter, we discussed this and > there is text in the draft that states that: > > the RSAB shall > include the IETF Executive Director or their delegate as a non-voting > member since the IETF LLC is responsible for implementation of > policies governing the RFC Series. > > That's because one could envision a good many changes that would require > quite a number of adjustments, including contractual ones. > > Eliot > --0000000000002c764105d262641c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Exactly, and there is no problem with the second poi= nt. For the first point, my concern is that the LLC should stay in its lane= when changes to the model are in discussion.

Regards,
=C2=A0=C2=A0=C2=A0 Brian Carpenter
=C2=A0= =C2=A0=C2=A0 (via tiny screen & keyboard)

On Sun, 5 Dec 2021, 21:04 Elio= t Lear, <lear@lear.ch> wrote:
=
=20 =20 =20

Yes, I think we mixed two things up:

  • The process for changing the governing document we are developing, and
  • The general approval process for documents from the RSWG

We are talking about the former.=C2=A0 For the latter, we discussed this and there is text in the draft that states that:

=C2=A0=C2=A0 the RSAB shall
=C2=A0=C2=A0 include the IETF Executive Director or their delegate = as a non-voting
=C2=A0=C2=A0 member since the IETF LLC is responsible for implement= ation of
=C2=A0=C2=A0 policies governing the RFC Series.

That's because one could envision a good many changes that would require quite a number of adjustments, including contractual ones.

Eliot

--0000000000002c764105d262641c-- From nobody Sun Dec 5 05:26:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 493D63A0989 for ; Sun, 5 Dec 2021 05:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 hQ5hoRV3vrGx for ; Sun, 5 Dec 2021 05:26:06 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15BEA3A1466 for ; Sun, 5 Dec 2021 05:26:06 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id x6so9674687iol.13 for ; Sun, 05 Dec 2021 05:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aA/YdisdpPpLuLKBemqKzBV5vxGEEDbI0KMxYAvsKlM=; b=tpVHt0PYaHtmkIJ+gillCEw8Zj71+l0yeeRljtXTwUkH8x5sRLi8a89NThch9qGyov +fbb3oO8/qXnA7L4Al/RXvNNzT7/Av9WeZMaDXhVUnOI8+PYvxI2WP5ngKInHCEcyamo CMMLqAuxafkv6rDIja2b/sJIO1pjNA6u7x7e9nbImW+VuTa/s9oFeuBax+LiX2s0QV9T 9wYzQnh67Ep7PKusncFubDeZHUkBY6/Kuq0TMXsFlv3Q7qi9IQyxzIrOk1CPgvKf3Ugp RmZCRvJRT0dHv97Hq8q+u3cZLk1Aoa3E0OdDlstaYl0TsIDiAuL70jEf+iFK1l4mo8bR 3l7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aA/YdisdpPpLuLKBemqKzBV5vxGEEDbI0KMxYAvsKlM=; b=fz+B9OuZ22W2l0RhG0EHIci9YODgUgaO+QMYKkJMkdf8DQn+5IU/xVzaH063u3TRe2 D7W/HJikL3m6SN0513BK25T9AgXkJ/jwu0jzkNAKvUlcDGOJ7V+Rfv/yx1EAL7OA9g3g 9s68o8sJIBt7AkLb+zIknEWanQ2QNP2YYVYFUHjUN6aBJjnQd9ws+fh9EolK2en/9MND vPe/wgjoL4d+39JLof0F9Vn7UlNmitid5oBvvpsnNd8sJPU9OZdzKQrFgVPDZ6kHgXJE qq7koZryO6CfxZaoNePBCKA5E4gfbUqSU6CRI2B4pPdxw4zbRGVOEigsMNiCHwE+BRqP f8eg== X-Gm-Message-State: AOAM533RtfrQGH05uo1pM6GVr3HxNf8uAfsJU8QqeJhTTXtSKJGqCoT2 88wuWDO62j6o7FoylNcoCTw0hv9dy+Y5SUp0dCxejQ== X-Google-Smtp-Source: ABdhPJz/7n6k7WbvXolNQIX3CVmsJc7JjaQfy3//2+OQf9vArooOYAtElaJ6UKu45RflU4frWufQXdY/opC9C1PX32I= X-Received: by 2002:a05:6638:190f:: with SMTP id p15mr35497904jal.82.1638710764131; Sun, 05 Dec 2021 05:26:04 -0800 (PST) MIME-Version: 1.0 References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> In-Reply-To: From: Eric Rescorla Date: Sun, 5 Dec 2021 05:25:28 -0800 Message-ID: To: Brian Carpenter Cc: Eliot Lear , "Joel M. Halpern" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000fc6fa605d2661417" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 13:26:13 -0000 --000000000000fc6fa605d2661417 Content-Type: text/plain; charset="UTF-8" I agree with this. My thesis is just that the LLC should have no more authority in changes to the model than for changes to its implementation, and requiring them to sign off on the model -- even with restrictions -- seems to do that. Do I have the wrong end of things? -Ekr On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter wrote: > Exactly, and there is no problem with the second point. For the first > point, my concern is that the LLC should stay in its lane when changes to > the model are in discussion. > > Regards, > Brian Carpenter > (via tiny screen & keyboard) > > On Sun, 5 Dec 2021, 21:04 Eliot Lear, wrote: > >> Yes, I think we mixed two things up: >> >> - The process for changing the governing document we are developing, >> and >> - The general approval process for documents from the RSWG >> >> We are talking about the former. For the latter, we discussed this and >> there is text in the draft that states that: >> >> the RSAB shall >> include the IETF Executive Director or their delegate as a non-voting >> member since the IETF LLC is responsible for implementation of >> policies governing the RFC Series. >> >> That's because one could envision a good many changes that would require >> quite a number of adjustments, including contractual ones. >> >> Eliot >> > --000000000000fc6fa605d2661417 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I agree with this. My thesis is just that the LLC sho= uld have no more authority in changes to the model than for changes to its = implementation, and requiring them to sign off on the model -- even with re= strictions -- seems to do that. Do I have the wrong end of things?

-Ekr


On Sun, Dec 5, 2021 at 1:01 A= M Brian Carpenter <brian.= e.carpenter@gmail.com> wrote:
Exactly, and there is no proble= m with the second point. For the first point, my concern is that the LLC sh= ould stay in its lane when changes to the model are in discussion.

<= div>Regards,
=C2=A0=C2=A0=C2=A0 Brian Carpenter
=C2=A0=C2=A0=C2=A0 (v= ia tiny screen & keyboard)

On Sun, 5 Dec 2021, 21:04 Eliot Lear, <lear@lear.ch> wrote:<= br>
=20 =20 =20

Yes, I think we mixed two things up:

  • The process for changing the governing document we are developing, and
  • The general approval process for documents from the RSWG

We are talking about the former.=C2=A0 For the latter, we discussed this and there is text in the draft that states that:

=C2=A0=C2=A0 the RSAB shall
=C2=A0=C2=A0 include the IETF Executive Director or their delegate = as a non-voting
=C2=A0=C2=A0 member since the IETF LLC is responsible for implement= ation of
=C2=A0=C2=A0 policies governing the RFC Series.

That's because one could envision a good many changes that would require quite a number of adjustments, including contractual ones.

Eliot

--000000000000fc6fa605d2661417-- From nobody Sun Dec 5 12:41:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AACC73A093D for ; Sun, 5 Dec 2021 12:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 IUz04buE0UM6 for ; Sun, 5 Dec 2021 12:41:31 -0800 (PST) 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 DFFAC3A083D for ; Sun, 5 Dec 2021 12:41:30 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id g19so8268406pfb.8 for ; Sun, 05 Dec 2021 12:41:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=EKcPbXAU/7iPPb03UUvsPTiL3IDg1D87R0+jvqOfyO0=; b=BpLNitrLZHGZmkt4KYSC/1FFJKuPbJNtxUcObz5Xmw6oxKDRh9zUfNI7lTsdi9F+Di qM9wBKXlIo70T5dvPPsK4M8L1ZJoa5K4JvPCAorjxrUSzlYdcE+GPfbmcKWBz9G1SRSJ 10SnMh8HPH8ui1noQ1d+V1U0dstW8oBPA7rxmu/s0LWYlTIUrbqM8p5AbMf8nj/Tp/mp F94Nf/ak11HO28oSzogtrFlBSZ9aklWl/o5m+e3Afekj1aoOySRnq99ChNeDCRlGAsru MoFHKT/Si7qziTtfpa7QDLjSL1gZPdBF1i4V2/D/HqWBaPvx1+cmfpVLcxJiXAffo986 QkwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=EKcPbXAU/7iPPb03UUvsPTiL3IDg1D87R0+jvqOfyO0=; b=DysDwsPv5J6jTyr+U2l3NbsC1m0mvv9kMojXYBWlvaXDiBJ7KIaSWlzrXZCu8H2Q4f kvbM8ZsRPunEN/n8w9mntX94s3mMuZCyIHtieqb+0Cwh8+nfe3lJ+miqzE/+zUra5H9x f9Vs4tmmSevAf9Vg7gsqMABvg0U+uPre32WrDdJP4qRujNJQOH4fb33mI6aK4y8uwiYe AeuCtr33/amLQcv6R0wNfjJq28KybBI9knPlgHpa6D1vgd0egKgeSBuot/RxW6U5NNhV 0c4DmTLbsvZwrhRYqoVz+4ZqwA25jiCInEVXTWCIqJrX33O/D1NA2Zek6lPblJr8kuUy tItw== X-Gm-Message-State: AOAM531okniXudGw8eH5mU4gXSeTFDDwQe8RrGX2TayIW1h/fQaTIsSW 1ATZfnwraUXv89CYOPvTg1nszFXw74TKZg== X-Google-Smtp-Source: ABdhPJyanvp5bZMbBbnLnH2h4kGtDfamjtMPBR8iwZdFIdFDPycmnA+cwmhbqi10XwPRtEyeHHs6uw== X-Received: by 2002:a63:1018:: with SMTP id f24mr2703364pgl.20.1638736888712; Sun, 05 Dec 2021 12:41:28 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id mm22sm7864096pjb.28.2021.12.05.12.41.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Dec 2021 12:41:28 -0800 (PST) To: Eric Rescorla Cc: Eliot Lear , "Joel M. Halpern" , rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> From: Brian E Carpenter Message-ID: <532ade3b-7b44-4d4d-50b5-a0b6cf880275@gmail.com> Date: Mon, 6 Dec 2021 09:41:22 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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 Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:41:36 -0000 To be clear, I think that Jay (and others under the LLC umbrella) have st= ayed entirely within their remit in the discussions on this list. But tha= t isn't the same thing as giving the LLC an *unconditional* veto over fut= ure changes to the model. Regards Brian On 06-Dec-21 02:25, Eric Rescorla wrote: > I agree with this. My thesis is just that the LLC should have no more a= uthority in changes to the model than for changes to its implementation, = and requiring them to sign off on the model -- even with restrictions -- = seems to do that. Do I have the wrong end of things? >=20 > -Ekr >=20 >=20 > On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter > wrote: >=20 > Exactly, and there is no problem with the second point. For the fir= st point, my concern is that the LLC should stay in its lane when changes=20 to the model are in discussion. >=20 > Regards, > =C2=A0=C2=A0=C2=A0 Brian Carpenter > =C2=A0=C2=A0=C2=A0 (via tiny screen & keyboard) >=20 > On Sun, 5 Dec 2021, 21:04 Eliot Lear, > wrote: >=20 > Yes, I think we mixed two things up: >=20 > * The process for changing the governing document we are deve= loping, and > * The general approval process for documents from the RSWG >=20 > We are talking about the former.=C2=A0 For the latter, we discu= ssed this and there is text in the draft that states that: >=20 >> =C2=A0=C2=A0 the RSAB shall >> =C2=A0=C2=A0 include the IETF Executive Director or their dele= gate as a non-voting >> =C2=A0=C2=A0 member since the IETF LLC is responsible for impl= ementation of >> =C2=A0=C2=A0 policies governing the RFC Series. >=20 > That's because one could envision a good many changes that woul= d require quite a number of adjustments, including contractual ones. >=20 > Eliot >=20 From nobody Sun Dec 5 12:52:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830573A0893 for ; Sun, 5 Dec 2021 12:52:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=TWSAQ+VT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PydHZGK1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LHuxKG7-TKoG for ; Sun, 5 Dec 2021 12:52:23 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4EA03A0878 for ; Sun, 5 Dec 2021 12:52:22 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 314245C008F; Sun, 5 Dec 2021 15:52:22 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Sun, 05 Dec 2021 15:52:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:to:from:subject:content-type :content-transfer-encoding; s=fm1; bh=NmdwRUqeiKDGszPPyualBwXh/K JogA6zQHPn6Z1SbQk=; b=TWSAQ+VTe1OWa5Ut0FYQOL9dpkLNUUVsyVUaBc7LhY i/DsmhTyxsyaxz4YXuL6gdr4oJEKWzLjaOfKX9W3Js/2+LdlwxBrmnmQtSem/1yh 312ikmTG2etT4EOrsDvCgxXINrMrFC3tq4vENePByJOu1ZdfExqwz8AYvPd73Wn1 hKRryck+9Y7XSsKGPWRuD8glrSUicl+THsE2RAoTFhPZZDCSGYsc+jC/tdLYviAO Gn8WszeWtcI9kTGm8pmh6Q6EXOjGlhFNkXKCWKDzyYn4IYDfw0eRHPDL06zliY1o KB86fmn3jvE/i/LaV4btHb3I1R10Vz6BWIjeu11N4LKw== 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=fm1; bh=NmdwRU qeiKDGszPPyualBwXh/KJogA6zQHPn6Z1SbQk=; b=PydHZGK1OPouL/3cEzotw1 J17XXttZ/5zEHvenBVl93b4ML4g70lPJaAmXCHiYtTVYWnJmmIY2sH1FMGuEGhEm YUc6vlF+3RVAzRPbeRe7v7xMwGfGSCyVHHsx8GsO4Y2FfJxO13KRIE0zfUlmwprs QNFgYgdD0HzYjFwXbe19zipQCa2CF8LGiH1VuMCh6NN6QwatXSiCTKzwGxhLeU6V Ov0IM4LFsDoqiqti2tnwPtDo+ot5Y68kvlbRRQBjaEYbiaONSa8881Tm/c3s8uQB jBWZtwQvxIW7woEwRPB7UtZuV+eL7c2zOT/tWGkoJAv5zqWdX+hQ9VwyKR9qiuxg == X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjedugddugeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefkffggfgfvhffutgfgsehtjeertd dtfeejnecuhfhrohhmpefrvghtvghrucfurghinhhtqdetnhgurhgvuceoshhtphgvthgv rhesshhtphgvthgvrhdrihhmqeenucggtffrrghtthgvrhhnpedugffhjeeludefveehvd dtheelkeehveeludeiiefgvddtgfffueeiffekvdfhueenucffohhmrghinhepghhithhh uhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 5 Dec 2021 15:52:21 -0500 (EST) Message-ID: <1b84a90e-0a99-e4dd-42cf-a9159f39e17f@stpeter.im> Date: Sun, 5 Dec 2021 13:52:17 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: "rfced-future@iab.org" From: Peter Saint-Andre Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Issue #138: Requests of the IETF Trust X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:52:29 -0000 Sandy Ginoza mentioned to me offlist that this document should request assistance from the IETF Trust in meeting its goals and procedures, very similar to what was requested in Section 5 and Section 6 of RFC 5744. I've created an issue for this: https://github.com/intarchboard/program-rfced-future/issues/138 Peter From nobody Sun Dec 5 13:00:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7B53A0990 for ; Sun, 5 Dec 2021 12:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 nMSvtk1DRfHd for ; Sun, 5 Dec 2021 12:59:53 -0800 (PST) Received: from mail-il1-x12a.google.com (mail-il1-x12a.google.com [IPv6:2607:f8b0:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 971B73A098F for ; Sun, 5 Dec 2021 12:59:53 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id i6so8387577ila.0 for ; Sun, 05 Dec 2021 12:59:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=74tvlmDCKyFUnqpi05/C6gt26PJgvglvQZnjqqCxFp0=; b=DvIvv52Fj3ZzZSrLuqcWxBftkMnrHVjCE/mbmcX2gFJB/8bCa6Fowiwq2JPHUMiaSE XKvHhFnyiW54hhAO89Jfveixy5ovxP3nKZp53mSajWjnw2LuKrAX+WRJX2IfuYzZAAoG VlINAnjjbH76NS+dTmCyN729TOfedmadDI49iXvoi/JDBqBwpo08mP0jHM3JQ7hDh04q doqRYiaZZomTQ8fi703zNJLQ9sv1hnJOGAQ4w26JK/ntxzXo8CZJcs2iWxhTMxXsZD37 AZ0FVENfUlWYx8w1vMrXqhJLkYcwU03SmyhxVwNpBcSRx7SXvlvn1JVdd2YUFgl8jtrf iGRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=74tvlmDCKyFUnqpi05/C6gt26PJgvglvQZnjqqCxFp0=; b=LzCRuQuj3wN6qHjfBzNCISBHuofnN0EFpFZ5opCfFzgqub5rx2sv1kTn4fTv/FoV9N mLNDrxiaRJs68Fbs4vmML59MAeI/S1Aqbz73CEX5zyq9KV9rOH1BAqHXQ3Tc6w3Nsxx5 R6Y8ULe+/a24vYISeNVcH4n7rdnfNVewGI6emncGt49Ks6mKytp+Kyn8kxeInnz0enLM G5WwNJai63AKlcIcazFbgBLt5ntb1+qM5fEOReIVlVADSnsjBZijbH2Ojmm3Xkxi1ZQ7 pTA/fk2wrlCN/cb87bjU+3HFaAkO98GRPg3kmoOoSlpC+kQ9Uyg7lL0y8RLVdeuew0DW wPbg== X-Gm-Message-State: AOAM530qzqmzFs0CIEMU2SPxbVK2sgV/+USH1wLo7zxKNI13cxT15M+5 Zd/ezjdma2sP1OcRIIcZJsP5CX3j04XlmQohbK4uE+fcOIw= X-Google-Smtp-Source: ABdhPJzwvaVZkGoT56gDbvuRPkCqFga4q9QZo6PvDy4ECBIpKf59gFzjtVJV1aPE2Y/vfxCx5pehE9//+P3HWiECXso= X-Received: by 2002:a92:db04:: with SMTP id b4mr29761871iln.276.1638737991885; Sun, 05 Dec 2021 12:59:51 -0800 (PST) MIME-Version: 1.0 References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> <532ade3b-7b44-4d4d-50b5-a0b6cf880275@gmail.com> In-Reply-To: <532ade3b-7b44-4d4d-50b5-a0b6cf880275@gmail.com> From: Eric Rescorla Date: Sun, 5 Dec 2021 12:59:15 -0800 Message-ID: To: Brian E Carpenter Cc: Eliot Lear , "Joel M. Halpern" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000e2fc4a05d26c6bcc" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:59:59 -0000 --000000000000e2fc4a05d26c6bcc Content-Type: text/plain; charset="UTF-8" No disagreement there. On Sun, Dec 5, 2021 at 12:41 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > To be clear, I think that Jay (and others under the LLC umbrella) have > stayed entirely within their remit in the discussions on this list. But > that isn't the same thing as giving the LLC an *unconditional* veto over > future changes to the model. > > Regards > Brian > > On 06-Dec-21 02:25, Eric Rescorla wrote: > > I agree with this. My thesis is just that the LLC should have no more > authority in changes to the model than for changes to its implementation, > and requiring them to sign off on the model -- even with restrictions -- > seems to do that. Do I have the wrong end of things? > > > > -Ekr > > > > > > On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > Exactly, and there is no problem with the second point. For the > first point, my concern is that the LLC should stay in its lane when > changes > to the model are in discussion. > > > > Regards, > > Brian Carpenter > > (via tiny screen & keyboard) > > > > On Sun, 5 Dec 2021, 21:04 Eliot Lear, lear@lear.ch>> wrote: > > > > Yes, I think we mixed two things up: > > > > * The process for changing the governing document we are > developing, and > > * The general approval process for documents from the RSWG > > > > We are talking about the former. For the latter, we discussed > this and there is text in the draft that states that: > > > >> the RSAB shall > >> include the IETF Executive Director or their delegate as a > non-voting > >> member since the IETF LLC is responsible for implementation > of > >> policies governing the RFC Series. > > > > That's because one could envision a good many changes that would > require quite a number of adjustments, including contractual ones. > > > > Eliot > > > > --000000000000e2fc4a05d26c6bcc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No disagreement there.

On Sun, Dec 5, 2021 at 12:41 PM = Brian E Carpenter <brian.= e.carpenter@gmail.com> wrote:
To be clear, I think that Jay (and others under the LL= C umbrella) have stayed entirely within their remit in the discussions on t= his list. But that isn't the same thing as giving the LLC an *unconditi= onal* veto over future changes to the model.

Regards
=C2=A0 =C2=A0 Brian

On 06-Dec-21 02:25, Eric Rescorla wrote:
> I agree with this. My thesis is just that the LLC should have no more = authority in changes to the model than for changes to its implementation, a= nd requiring them to sign off on the model -- even with restrictions -- see= ms to do that. Do I have the wrong end of things?
>
> -Ekr
>
>
> On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Exactly, and there is no problem with the second po= int. For the first point, my concern is that the LLC should stay in its lan= e when changes
to the model are in discussion.
>
>=C2=A0 =C2=A0 =C2=A0Regards,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 Brian Carpenter
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 (via tiny screen & keyboard= )
>
>=C2=A0 =C2=A0 =C2=A0On Sun, 5 Dec 2021, 21:04 Eliot Lear, <lear@lear.ch <mailto:lear@lear.ch>> wrot= e:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Yes, I think we mixed two things up:<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* The process for changing the= governing document we are developing, and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0* The general approval process= for documents from the RSWG
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0We are talking about the former.=C2= =A0 For the latter, we discussed this and there is text in the draft that s= tates that:
>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 the RSAB shall
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 include the IETF Exe= cutive Director or their delegate as a non-voting
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 member since the IET= F LLC is responsible for implementation of
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0 policies governing t= he RFC Series.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0That's because one could envision= a good many changes that would require quite a number of adjustments, incl= uding contractual ones.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Eliot
>

--000000000000e2fc4a05d26c6bcc-- From nobody Sun Dec 5 13:45:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B2073A09F4 for ; Sun, 5 Dec 2021 13:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, 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.20210112.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 Gb6Uk9liA7dX for ; Sun, 5 Dec 2021 13:45:33 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE0D3A09F7 for ; Sun, 5 Dec 2021 13:45:32 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id b11so8257566qvm.7 for ; Sun, 05 Dec 2021 13:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=zOshcY+KLAmBVBXP0Pp3LTk8FtQmt0hQSf0+BffcViM=; b=5mb19mtfj29MVxwI6xIRhFIpdXw1HpYySEMlZKmjVNeASy1+7IP2zrvezMJV8frSsj UgbMM1ygA2m7LIhfXH0Md5wRq7gt6N2ZSWh9iSMEG3N/E59bd5OEwyxjg6tA10xniWwO 29nu/oLYoVcia1DU0QD/SsnJWD4LQoinDHRe31/AYB4JXsZolNFSQ77PWQ5h9+jyMe/o Bz1YmFMuS/INGAyGymvWrwdWZNtfkOt1+sa1JdSyapYMTP+Jsla7d05s5DQUIPvJeCjJ cwVCc/u5if3TI7lJgeo494zpJi+G+9GLTtX9Fv2a8USgnvHQdLKGNMiGhqPrdDyi97g6 bn8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=zOshcY+KLAmBVBXP0Pp3LTk8FtQmt0hQSf0+BffcViM=; b=2ulIuhUR+zZyRaiQk4kI/DCuT8vAgmKTCNAILrfQXn7s5W4CyJKxHueiocCvXkgYgo p+iIQk1PDuXZ5eiroHG7zHjS+aKZryCOrn5WsPb3PTYug8RmEH078ZqSSwQsoEJ3Tc1a u4MGsEAjVF8datRJBuxvFXt6L7LiwDyTbPrlD3Ag23m2VgS8v+BqFdgUwkMZw2VRDAGI Ga8Z90e9ZQEEtDA3oY2iC7q/Rm5dA2a3malGzzjTrMpYFLJmXGIP5Ie0iN7KixR5xInG aPICocd37OJl/uKHTy6rlYHZRDOpa7emLqI0IImxPVA+mBBPY5nyft1Fqba0nWAacjNf HDlg== X-Gm-Message-State: AOAM530glN/dm6/zayx1+fw+PahjssHJLPSUf8PVw4XeNNt+0qnFIWKf jGiAT1gADB7kofJDBu0lAGOhEJPXFUk7Xc+d X-Google-Smtp-Source: ABdhPJwvSRY6paxM+EWTA0VNy18VX233hTuuTvffaqAc9Vo+c/QjQgnTc1yd/Qd6XVf1QaQgLlRACg== X-Received: by 2002:a05:6214:c42:: with SMTP id r2mr32897418qvj.69.1638740730139; Sun, 05 Dec 2021 13:45:30 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id a15sm6422409qtb.5.2021.12.05.13.45.29 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 05 Dec 2021 13:45:29 -0800 (PST) Message-ID: <7b735662-02ee-5619-e551-1d29200a7ce2@nthpermutation.com> Date: Sun, 5 Dec 2021 16:45:28 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: rfced-future@iab.org References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> <532ade3b-7b44-4d4d-50b5-a0b6cf880275@gmail.com> From: Michael StJohns In-Reply-To: <532ade3b-7b44-4d4d-50b5-a0b6cf880275@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:45:38 -0000 On 12/5/2021 3:41 PM, Brian E Carpenter wrote: > To be clear, I think that Jay (and others under the LLC umbrella) have > stayed entirely within their remit in the discussions on this list. > But that isn't the same thing as giving the LLC an *unconditional* > veto over future changes to the model. > To be clear, I'm not talking about giving the LLC a veto, I'm explaining that they have one regardless of what we believe or specify.   If the LLC board collectively decides not to approve the *implementation* of a set of changes, those changes will not happen as the contract is held by the LLC.  That is effectively a veto which cannot be overridden unless and until the LLC board composition changes and they take up the question again.  (Or in EKRs dream vision - where some other organization takes over the contracting and management of the RFC Series and is controlled by the RSWG). I'm happy with Mirja's original text and I think it is both appropriate and correct and not overspecified.  To wit: > "Updates, amendments and refinements of this document require > agreement of the IAB, the IESG, and the IETF LLC." Again, you, EKR and others have been arguing with me about my pushback on trusting the RSAB and RSWG (neither of which is a community/Nomcom selected body) to "do the right thing".  Why are you so dead set on trying to legislate and constrain the behavior of a set of a community selected members in a manner that may ultimately conflict with their fiduciary duties? You appear to be unwilling to trust them to "do the right thing" without over specific text and I'm beginning to get hints of a "you're not the boss of me" argument here rather than something based in ensuring the system continues to work. Later, Mike > Regards >    Brian > > On 06-Dec-21 02:25, Eric Rescorla wrote: >> I agree with this. My thesis is just that the LLC should have no more >> authority in changes to the model than for changes to its >> implementation, and requiring them to sign off on the model -- even >> with restrictions -- seems to do that. Do I have the wrong end of >> things? >> >> -Ekr >> >> >> On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter >> > >> wrote: >> >>     Exactly, and there is no problem with the second point. For the >> first point, my concern is that the LLC should stay in its lane when >> changes > to the model are in discussion. >> >>     Regards, >>          Brian Carpenter >>          (via tiny screen & keyboard) >> >>     On Sun, 5 Dec 2021, 21:04 Eliot Lear, > > wrote: >> >>         Yes, I think we mixed two things up: >> >>           * The process for changing the governing document we are >> developing, and >>           * The general approval process for documents from the RSWG >> >>         We are talking about the former.  For the latter, we >> discussed this and there is text in the draft that states that: >> >>>            the RSAB shall >>>            include the IETF Executive Director or their delegate as >>> a non-voting >>>            member since the IETF LLC is responsible for >>> implementation of >>>            policies governing the RFC Series. >> >>         That's because one could envision a good many changes that >> would require quite a number of adjustments, including contractual ones. >> >>         Eliot >> > From nobody Sun Dec 5 14:20:11 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC5AB3A02BD for ; Sun, 5 Dec 2021 14:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 eUhTlvuVzpSP for ; Sun, 5 Dec 2021 14:19:50 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B1B3A00F7 for ; Sun, 5 Dec 2021 14:19:50 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id j7so8385008ilk.13 for ; Sun, 05 Dec 2021 14:19:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=avSjnpL9VUrfuK+00IIynM9qOcfcqIxiyf5k6KnsrPI=; b=JDRnCvJisQ0ZgDK088GACF6eBh5ryA3IEXyVhHK+Gok7ew83lY6mNLttoUGDQpMS45 Ht/3zxQP2w8zJfm8VI9XzALEvQRvnZ8p49272Tmdx8uK5oE/ViNssT7TxbR46L8ctbk0 I0P/PVr+ghqQ3towHoTAJu2kpgbT1LGWoUdkJq7jqbLR8QEfSFfXsgQ6Ek04A/th1taT OzTLe1I8bBdRKZKoW/0V3z9x7Gfh2alPqk4VvhsURJGxP1+EVVPXpR/W2F7TBSJj6e8F v1eyEK2KbN9RY3esEQ6A3bYZ9bO4xFf6hGxTk26NDQXXeFuNa1NBiAbvYgHaDBoy35ly RRnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=avSjnpL9VUrfuK+00IIynM9qOcfcqIxiyf5k6KnsrPI=; b=i1dmPkizKtCjNq6TgAEqqmw+DNi3vrlQ6B5qtTrI8fZZsDG9hrI5ZHyFPyzP+NbHRF ScvPmyKPTptcx30UmwDSm8zfZzRGsCYeg5N5J2oSsoGqLnDaX6B0bn8KTbxP7vPNCCKm VqTnqUDAUqwkOYqKFBA//XNgM3z2spwAFKu39sq5FnDF1G75HNHhle1sqenKfcj4pkYA 0fk2PgVPqtaO2+/dbOOud95bgy6RPKkr+JcFBWqpJECw2Hlp9FA7oHbl4nO9GE6T4aRX VfUe9Gf0ppW9REpf2W/mTLrTmiNL8FMy2RP3nbUZmQbhB4mxQiDjxdXXU4BDhTa3UU7b DBBw== X-Gm-Message-State: AOAM5323UAEnhwwaCkWb1QWbGZiHir8tfNSNaInWRBHPwgFh1Fdi0gXD wteMgPuNgz7hfX9LofOvvCPWt94g6Q+fbYbtHuUgZow1QH0= X-Google-Smtp-Source: ABdhPJxdNAI9C265as/R0Tp4g41aVKFeKIJnMkA5HHzIxxw2a+gmEdZ4WNdetTzb6SzCPqqvRjzDhWkmH9Jof6U0vm0= X-Received: by 2002:a92:db04:: with SMTP id b4mr29961347iln.276.1638742789238; Sun, 05 Dec 2021 14:19:49 -0800 (PST) MIME-Version: 1.0 References: <61B6976D-14FA-4CD5-A49F-432FABE40533@ietf.org> <0586FE1B-18F1-41C1-9F8E-D4BD42D3814B@mnot.net> <0ea56594-2a74-4dc2-ff42-bf73acca00be@lear.ch> <650d784a-a7e8-e27b-e8ea-1f4cf610cd8a@nthpermutation.com> <18340aca-5c46-477c-d6da-f764a9033a6a@gmail.com> <3a2cdf37-e132-5475-4f00-50e87054a3e1@gmail.com> <4d52eed2-09eb-09d3-70fd-5f05baa40d26@lear.ch> <532ade3b-7b44-4d4d-50b5-a0b6cf880275@gmail.com> <7b735662-02ee-5619-e551-1d29200a7ce2@nthpermutation.com> In-Reply-To: <7b735662-02ee-5619-e551-1d29200a7ce2@nthpermutation.com> From: Eric Rescorla Date: Sun, 5 Dec 2021 14:19:13 -0800 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000d4c1fe05d26d8991" Archived-At: Subject: Re: [Rfced-future] Issue 134: Re: How can this process be changed? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 22:20:00 -0000 --000000000000d4c1fe05d26d8991 Content-Type: text/plain; charset="UTF-8" On Sun, Dec 5, 2021 at 1:45 PM Michael StJohns wrote: > On 12/5/2021 3:41 PM, Brian E Carpenter wrote: > > To be clear, I think that Jay (and others under the LLC umbrella) have > > stayed entirely within their remit in the discussions on this list. > > But that isn't the same thing as giving the LLC an *unconditional* > > veto over future changes to the model. > > > To be clear, I'm not talking about giving the LLC a veto, I'm explaining > that they have one regardless of what we believe or specify. If the > LLC board collectively decides not to approve the *implementation* of a > set of changes, those changes will not happen as the contract is held by > the LLC. That is effectively a veto which cannot be overridden unless > and until the LLC board composition changes and they take up the > question again. (Or in EKRs dream vision - where some other > organization takes over the contracting and management of the RFC Series > and is controlled by the RSWG). > Two points: 1. They have an effective veto over some points and not others. For instance, the LLC could not plausibly just refuse to implement a change in which the ISE member of the RSAB got 25 votes. 2. Yes, it's certainly true that the LLC can just refuse to do certain things, but there is a difference between "The LLC is just refusing to execute the will of the community" and "The LLC is part of the process of deciding what is supposed to happen." For example, the LLC could refuse to seat a new AD by not giving them a datatracker login, refusing to process their actions, etc., but I think we would all agree that this is acting outside the rules. The text you propose below is different: it gives the LLC a say in what the rules are and so if they apply their veto they would be acting inside the ruls. I'm happy with Mirja's original text and I think it is both appropriate > and correct and not overspecified. To wit: > > > "Updates, amendments and refinements of this document require > > agreement of the IAB, the IESG, and the IETF LLC." > I can live with this with the text proposed by Brian limiting the requirement by the LLC to agreement within their area. Otherwise, this seems overbroad. > Again, you, EKR and others have been arguing with me about my pushback > on trusting the RSAB and RSWG (neither of which is a community/Nomcom > selected body) to "do the right thing". Why are you so dead set on > trying to legislate and constrain the behavior of a set of a community > selected members in a manner that may ultimately conflict with their > fiduciary duties? You appear to be unwilling to trust them to "do the > right thing" without over specific text and I'm beginning to get hints > of a "you're not the boss of me" argument here rather than something > based in ensuring the system continues to work. > It will probably make this conversation a lot smoother if you avoid attributing motivations to others. In any case, I would appreciate it if you did so. -Ekr > Later, Mike > > > > > Regards > > Brian > > > > On 06-Dec-21 02:25, Eric Rescorla wrote: > >> I agree with this. My thesis is just that the LLC should have no more > >> authority in changes to the model than for changes to its > >> implementation, and requiring them to sign off on the model -- even > >> with restrictions -- seems to do that. Do I have the wrong end of > >> things? > >> > >> -Ekr > >> > >> > >> On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter > >> > > >> wrote: > >> > >> Exactly, and there is no problem with the second point. For the > >> first point, my concern is that the LLC should stay in its lane when > >> changes > > to the model are in discussion. > >> > >> Regards, > >> Brian Carpenter > >> (via tiny screen & keyboard) > >> > >> On Sun, 5 Dec 2021, 21:04 Eliot Lear, >> > wrote: > >> > >> Yes, I think we mixed two things up: > >> > >> * The process for changing the governing document we are > >> developing, and > >> * The general approval process for documents from the RSWG > >> > >> We are talking about the former. For the latter, we > >> discussed this and there is text in the draft that states that: > >> > >>> the RSAB shall > >>> include the IETF Executive Director or their delegate as > >>> a non-voting > >>> member since the IETF LLC is responsible for > >>> implementation of > >>> policies governing the RFC Series. > >> > >> That's because one could envision a good many changes that > >> would require quite a number of adjustments, including contractual ones. > >> > >> Eliot > >> > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000d4c1fe05d26d8991 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Dec 5, 2021 at 1:45 PM Michae= l StJohns <msj@nthpermutation.= com> wrote:
On 12/5/2021 3:41 PM, Brian E Carpenter wrote:
> To be clear, I think that Jay (and others under the LLC umbrella) have=
> stayed entirely within their remit in the discussions on this list. > But that isn't the same thing as giving the LLC an *unconditional*=
> veto over future changes to the model.
>
To be clear, I'm not talking about giving the LLC a veto, I'm expla= ining
that they have one regardless of what we believe or specify.=C2=A0=C2=A0 If= the
LLC board collectively decides not to approve the *implementation* of a set of changes, those changes will not happen as the contract is held by the LLC.=C2=A0 That is effectively a veto which cannot be overridden unless=
and until the LLC board composition changes and they take up the
question again.=C2=A0 (Or in EKRs dream vision - where some other
organization takes over the contracting and management of the RFC Series and is controlled by the RSWG).

Two poi= nts:

1. They have an effective veto over some poin= ts and not others. For
instance, the LLC could not plausibly just= refuse to implement a change
in which the ISE member of the RSAB= got 25 votes.

2. Yes, it's certainly true tha= t the LLC can just refuse to do certain
things, but there is a di= fference between "The LLC is just refusing
to execute the wi= ll of the community" and "The LLC is part of the
proces= s of deciding what is supposed to happen." For example,
the = LLC could refuse to seat a new AD by not giving them a datatracker
login, refusing to process their actions, etc., but I think we would
all agree that this is acting outside the rules. The text you propose=
below is different: it gives the LLC a say in what the rules are=
and so if they apply their veto they would be acting inside the = ruls.


I'm happy with Mirja's original text and I think it is both appropr= iate
and correct and not overspecified.=C2=A0 To wit:

> "Updates, amendments and refinements of this document require > agreement of the IAB, the IESG, and the IETF LLC."

I can live with this with the text proposed by Brian = limiting the requirement
by the LLC to agreement within their are= a. Otherwise, this seems overbroad.


Again, you, EKR and others have been arguing with me about my pushback
on trusting the RSAB and RSWG (neither of which is a community/Nomcom
selected body) to "do the right thing".=C2=A0 Why are you so dead= set on
trying to legislate and constrain the behavior of a set of a community
selected members in a manner that may ultimately conflict with their
fiduciary duties? You appear to be unwilling to trust them to "do the =
right thing" without over specific text and I'm beginning to get h= ints
of a "you're not the boss of me" argument here rather than so= mething
based in ensuring the system continues to work.

It will probably make this conversation a lot smoother if you avoi= d
attributing motivations to others. In any case, I would appreci= ate it
if you did so.

-Ekr


Later, Mike



> Regards
> =C2=A0=C2=A0 Brian
>
> On 06-Dec-21 02:25, Eric Rescorla wrote:
>> I agree with this. My thesis is just that the LLC should have no m= ore
>> authority in changes to the model than for changes to its
>> implementation, and requiring them to sign off on the model -- eve= n
>> with restrictions -- seems to do that. Do I have the wrong end of =
>> things?
>>
>> -Ekr
>>
>>
>> On Sun, Dec 5, 2021 at 1:01 AM Brian Carpenter
>> <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>>=
>> wrote:
>>
>> =C2=A0=C2=A0=C2=A0 Exactly, and there is no problem with the secon= d point. For the
>> first point, my concern is that the LLC should stay in its lane wh= en
>> changes
> to the model are in discussion.
>>
>> =C2=A0=C2=A0=C2=A0 Regards,
>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Brian Carpenter
>> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 (via tiny screen &= keyboard)
>>
>> =C2=A0=C2=A0=C2=A0 On Sun, 5 Dec 2021, 21:04 Eliot Lear, <lear@lear.ch
>> <mailto:lear@= lear.ch>> wrote:
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Yes, I think we mixed t= wo things up:
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * The proce= ss for changing the governing document we are
>> developing, and
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * The gener= al approval process for documents from the RSWG
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 We are talking about th= e former.=C2=A0 For the latter, we
>> discussed this and there is text in the draft that states that: >>
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 the RS= AB shall
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 includ= e the IETF Executive Director or their delegate as
>>> a non-voting
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 member= since the IETF LLC is responsible for
>>> implementation of
>>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0 polici= es governing the RFC Series.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 That's because one = could envision a good many changes that
>> would require quite a number of adjustments, including contractual= ones.
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Eliot
>>
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000d4c1fe05d26d8991-- From nobody Sun Dec 5 15:12:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DB6E3A0062 for ; Sun, 5 Dec 2021 15:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=kaKq1bZU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RFxYZGF0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id st_enhRSx3V2 for ; Sun, 5 Dec 2021 15:12:08 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8103E3A005B for ; Sun, 5 Dec 2021 15:12:08 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id BE5583200993 for ; Sun, 5 Dec 2021 18:12:04 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Sun, 05 Dec 2021 18:12:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=KiVdZ5WJgVF+ewIWYuprDygfvFLii0P eH1aStg8aiFc=; b=kaKq1bZUpaLuilU/PpYMuLL0mklov7EL8kef0tC6NPkHKIh XisvPYpOZPH6+J501MfqS+m1QtCtf4vt/otcr17NB7CA2JGh8ZYy/0t9kuJA1IrX QzIpXqTSmltHw8TS+loF2Oju3OJUt2D7+q2PJ38FdO6bPUyU2Dy/aBBJa6/7Th99 zC3lHo3C6WKw86VSw2/vKzzXAD20YMLdw7S45RGz+qMkRbbs1ChurmJd+Y9TYuNk kpu5w12xPBwmW2z3MpQ8WDhvyWjJNFAbjSwuFfHOTJlTK3DL3hP+Tf/I6rJWE2SI weMQKdpY9jC+5vtvXZGAI7Sfk7wfvP+n7V12rmw== 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=fm1; bh=KiVdZ5 WJgVF+ewIWYuprDygfvFLii0PeH1aStg8aiFc=; b=RFxYZGF09gcrMHO18tr6jk 6GzU2DUlCvebs84CyCCRBw8QbPsksHgyNrwYFqGfv6VCVAHfvvbzwg+CfUo/BsHS Sn1KJorIA+THORnDaRzFadJ09aBQ2QT/MRccFUGXXciHzE7Vy2o6z+DR1Uwqqk5J LRyaANzSCoYcVkT8p3Jo5Aw5tNj5y4fzrARrkr0mrTWDgJpoGyuEqj14YGn0I/tS XMy1t4b3KfOZFqBWLVwmtE0UCoCB519mZWNvxJx95UA7hKp532zMwls6tx9C4U8v jhmlWB0wh7phwcd9c/lItVT4gWHsvg0QzWV+76QQbKx5SgQhHJ+btUz1sCv6P5bw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjedvgddtjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 0A46B3C0246; Sun, 5 Dec 2021 18:12:04 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4458-g51a91c06b2-fm-20211130.004-g51a91c06 Mime-Version: 1.0 Message-Id: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> In-Reply-To: References: Date: Mon, 06 Dec 2021 10:11:44 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:12:14 -0000 Thanks to everyone contributing friendly amendments. I now have: # Historical Properties of the RFC Series The RSAB has a duty to ensure that proposals from the RSWG receive appropriate levels of review. Proposals that, in the opinion of the RSAB, have significant impact on the series require additional outreach and review from a wider community. Additional time should be allowed for collecting feedback for such proposals. This section lists some of the properties that have been historically regarded as important to the RFC Series. Proposals that affect these properties are possible within the processes defined in this document. However, the RSAB should seek broader review for proposals that might have a detrimental affect on these properties. The purpose of review is to ensure that all changes are deliberate and and that the consequences of a proposal, as far as they are identifiable, have been carefully considered. ## Availability Documents in the RFC Series have been available for more than 35 years, with no fee for access. ## Accessibility RFC Series documents have been published in a format that was intended to be as accessible as possible to those with special needs, e.g., for those with impaired sight. ## Language All existing RFC Series documents have been published in English. Documents have been licensed to explicitly permit translation into other languages. ## Diversity In addition to Internet standards, the RFC series has published procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies. ## Quality RFC Series documents have been reviewed for subject matter quality and edited by professionals with a goal of ensuring that documents are clear, consistent, and readable [RFC7322]. ## Stability Once published, RFC Series documents have not changed. ## Longevity RFC Series documents have been published in a form intended to be easily legible to humans for decades or longer. From nobody Sun Dec 5 15:48:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EAFE3A0688 for ; Sun, 5 Dec 2021 15:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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 hSSepPsdq4Qa for ; Sun, 5 Dec 2021 15:48:24 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06DD73A067A for ; Sun, 5 Dec 2021 15:48:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4J6jtb450Jz1pKqg; Sun, 5 Dec 2021 15:48:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1638748103; bh=mKFNUaXQpiS4DxElGhyMFaSvaw0eBiqxonec12TiUpk=; h=Date:Subject:To:References:From:In-Reply-To:From; b=GOJY19e+1e8QLiZgqYYxWdpsEh2hkOQDyM3pX5hikrjN3AiJ3Iwg3iuniysW0ymdo Gx67AO93YRPh7VXTtF/u8iAM68lKunxu3ZzGD42Xb3Z/nuBf67nGHN1/8F173d2pCT uGghSVJjpaj5U7pJN5LGfmhnpgGVXCb9NoZ0NZFY= X-Quarantine-ID: <7OeqvNKofwng> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4J6jtZ752dz1ntly; Sun, 5 Dec 2021 15:48:22 -0800 (PST) Message-ID: <0515e2cf-97db-5c5c-fa3c-26ac918e2323@joelhalpern.com> Date: Sun, 5 Dec 2021 18:48:21 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Peter Saint-Andre , "rfced-future@iab.org" References: <1b84a90e-0a99-e4dd-42cf-a9159f39e17f@stpeter.im> From: "Joel M. Halpern" In-Reply-To: <1b84a90e-0a99-e4dd-42cf-a9159f39e17f@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Issue #138: Requests of the IETF Trust X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:48:28 -0000 Why would this document need to do anything to the procedures in 5744? Or, for that matter 5378. Both would still apply. Also no reason to mess with 8179. They have nothing to do with the RFC Editor or the RPC. If there is a reason to mess with those, we will need to proceed very carefully. Yours, Joel On 12/5/2021 3:52 PM, Peter Saint-Andre wrote: > Sandy Ginoza mentioned to me offlist that this document should request > assistance from the IETF Trust in meeting its goals and procedures, very > similar to what was requested in Section 5 and Section 6 of RFC 5744. > I've created an issue for this: > > https://github.com/intarchboard/program-rfced-future/issues/138 > > Peter > From nobody Sun Dec 5 16:28:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A54713A0045 for ; Sun, 5 Dec 2021 16:28:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=eLN5ZKKL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Or8s6LzN Received: 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_EisN_47k2W for ; Sun, 5 Dec 2021 16:27:55 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4C603A003F for ; Sun, 5 Dec 2021 16:27:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 4BF903200D25; Sun, 5 Dec 2021 19:27:54 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 05 Dec 2021 19:27:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=x u5sCXf+AvM0H/ksGci+FQP4acEPzSvOntMmLMlvrxM=; b=eLN5ZKKL6pLqhh6Jy rayoONhIOUgHR+twQZNCW0CeFAlFyBd4etToTBeo8YhYkBgkw9+OfO0jG6RV7hSl h6tEwZQqRi0cY8Xov9LmaZOFoAyCQgmiiVqd/0qPahG8EGQjDiiW44YzsvFGn9Gc OH4IOJ67Wos09YWmU9USlRToTAGm6PTRe6GuNj4NQVySRavSqST2IM5rHGiJvTvL 7yw9wmbZJq5L+bhFM44hBWBaxeoh1VajEXC4Kh7kB+xIxgejqXqkI93SO3E93sLK G65qSoLQX3iJfyS/hu3vcst8iSjUOx4f1Bd/ic0qbXOqFHjn6XOVKWi0lhVtz8Ch rjXtw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=xu5sCXf+AvM0H/ksGci+FQP4acEPzSvOntMmLMlvr xM=; b=Or8s6LzNpmO11lY1AApTukEmVlEQ2mYKtsgVaGCpP2+otoFjFIOi8Rq/Q /ScEQmP2YldU4lXjeAvBumCgMx5Bnq7ejR9kLDhhVgtEt8FCY5dPUCwzuS07grWn BJeDZA/rMvYzjQC0vVgQ97406WJ14JVWGj/5mK7Ca4IfEvAFJTVIuU28OLEoNwVU 23Ce3mPQ6y0sjbDhzabY9AMVXeysMtLEOsin+r6tfG8l1z3kp9OGicStb8GMUdep oyXYD90xL+8Zx4U99IIpfIm0utzlnO4WHUvet3By72td9fen30bP1/JnVuvT1fOz cLbPAHGLY5X7AotWpBjepylIgi7Aw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjedvgddvvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthekre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepjeegueffuefhtedugf evhfekueefteegtdeuudelheffgffggeduueevtdfffefgnecuffhomhgrihhnpehrfhgt qdgvughithhorhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehsthhpvghtvghrsehsthhpvghtvghrrdhimh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 5 Dec 2021 19:27:53 -0500 (EST) Message-ID: Date: Sun, 5 Dec 2021 17:27:52 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: "Joel M. Halpern" , "rfced-future@iab.org" References: <1b84a90e-0a99-e4dd-42cf-a9159f39e17f@stpeter.im> <0515e2cf-97db-5c5c-fa3c-26ac918e2323@joelhalpern.com> From: Peter Saint-Andre In-Reply-To: <0515e2cf-97db-5c5c-fa3c-26ac918e2323@joelhalpern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue #138: Requests of the IETF Trust X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:28:01 -0000 On 12/5/21 4:48 PM, Joel M. Halpern wrote: > Why would this document need to do anything to the procedures in 5744? > Or, for that matter 5378.  Both would still apply. Also no reason to > mess with 8179. They have nothing to do with the RFC Editor or the RPC. > If there is a reason to mess with those, we will need to proceed very > carefully. Because the existing non-IETF streams have text requesting assistance from the IETF Trust, we should do so for the Editorial Stream, too: IRTF: https://www.rfc-editor.org/rfc/rfc5743.html#section-3.1 IAB: https://www.rfc-editor.org/rfc/rfc5745.html#section-5 ISE: https://www.rfc-editor.org/rfc/rfc5744.html#section-5 Peter From nobody Sun Dec 5 16:31:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE55E3A0047 for ; Sun, 5 Dec 2021 16:31:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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 ZwaLRH_zzWgW for ; Sun, 5 Dec 2021 16:31:26 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9AB3A003F for ; Sun, 5 Dec 2021 16:31:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4J6krG0wqQz1pKqh; Sun, 5 Dec 2021 16:31:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1638750686; bh=Aywu6PcpmGNnuzdSeZulkSCdkRwIhCSEil2qzB+WOzk=; h=Date:Subject:To:References:From:In-Reply-To:From; b=C04gP4zk5hNFa9H2hd5DIS/hQMEE44Y6+NO/Rfp8AZNkbWU+hLUdFSFUX3fVLHPKr 1bqqHeB813XFCg0EwsxfDZuuNPV88tIZxnL313oRFnkxXePvRUaRfmNG80kQN1KLfA C9zjtnHC89fwWBuGX3S1nhs2kuWNCFfDwkPPjprY= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4J6krF4QMqz1pKWP; Sun, 5 Dec 2021 16:31:25 -0800 (PST) Message-ID: <4f6af912-7a7b-8a12-a040-240c0444d694@joelhalpern.com> Date: Sun, 5 Dec 2021 19:31:24 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Peter Saint-Andre , "rfced-future@iab.org" References: <1b84a90e-0a99-e4dd-42cf-a9159f39e17f@stpeter.im> <0515e2cf-97db-5c5c-fa3c-26ac918e2323@joelhalpern.com> From: "Joel M. Halpern" In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue #138: Requests of the IETF Trust X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:31:31 -0000 Thanks. I misunderstood what you were suggesting adding. That makes sense. Happy to see the text added, and work with my fellow trustees to make sure we confirm at the relevant point in the process. Yours, Joel On 12/5/2021 7:27 PM, Peter Saint-Andre wrote: > On 12/5/21 4:48 PM, Joel M. Halpern wrote: >> Why would this document need to do anything to the procedures in 5744? >> Or, for that matter 5378.  Both would still apply. Also no reason to >> mess with 8179. They have nothing to do with the RFC Editor or the RPC. >> If there is a reason to mess with those, we will need to proceed very >> carefully. > > Because the existing non-IETF streams have text requesting assistance > from the IETF Trust, we should do so for the Editorial Stream, too: > > IRTF: https://www.rfc-editor.org/rfc/rfc5743.html#section-3.1 > IAB: https://www.rfc-editor.org/rfc/rfc5745.html#section-5 > ISE: https://www.rfc-editor.org/rfc/rfc5744.html#section-5 > > Peter From nobody Sun Dec 5 16:47:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D5683A012A for ; Sun, 5 Dec 2021 16:47:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=poDc0btr; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UAIJPEv+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwKqo7bOAu7V for ; Sun, 5 Dec 2021 16:47:10 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46263A0139 for ; Sun, 5 Dec 2021 16:47:10 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 979613200A2E; Sun, 5 Dec 2021 19:47:09 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Sun, 05 Dec 2021 19:47:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=h 5R9SVRHJUYkhpUPlcIA75e1KbNA4ueJf871hH/dUKs=; b=poDc0btr60yTPjm93 ThFJLYXLhtKz3qkN4U+Ef0sdM75cIMOd+7ZAMq2xRP7OTv+71NZepjxNbML/SydM gzVnQsHn9udmWw74wG/vLA4fWnabMRm9QEs8i8oGWtszc1xi/LMekqvEkunBW7q8 Fqk9BJPoxvW224TCKdZDZwpEKYGyu3WfIm52b+dyuaJ5ZYUUXeGyeMCzcBEF5pJN 6C04qjW4tZXTz+j/71nQ5jTGLtqZJgIz0BxyH7nmfhiXBtsZyL+S/tpfSth8t9lA oK0u85T5bCdgeAkgyLi8JWSdKXmMYI8lE9z4i7wXC5tDmIwXajtkpy2kHakk3MNJ 6FFnQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=h5R9SVRHJUYkhpUPlcIA75e1KbNA4ueJf871hH/dU Ks=; b=UAIJPEv+OlgEHb1ibt884GglzsFF2GNMMH7uuBYZqH4/H4ozZ2BYoRzjX ypZu/WhIFFZFYE4XTFuhKRKvxXxf13680B66b7PVH9FHixP92c3rjwiNCeeDNKY6 nF37GSrXFjC8SPl0kbHqa5zWQSyRWgAXgzeQNdau7tSGvF9qlsgzdw/WyiPDRQ/C 0SDi6V0LubDXb7AdxsfJJmWvpcNPFAy5BVoEId55azMzezJpjP7zaLO4EUD3S9uV a+s1lQtuULEKEasyuDJOB2M8zsiysqCdHgz8q3XHyWJLPPmK17rjTMIfsjml4YC7 +DZGqCIggzPwH78D51FgrNHloy10w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjedvgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthekre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepjeegueffuefhtedugf evhfekueefteegtdeuudelheffgffggeduueevtdfffefgnecuffhomhgrihhnpehrfhgt qdgvughithhorhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmh grihhlfhhrohhmpehsthhpvghtvghrsehsthhpvghtvghrrdhimh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 5 Dec 2021 19:47:08 -0500 (EST) Message-ID: <60b9c321-57e3-8ecf-2611-ff642a7fc75e@stpeter.im> Date: Sun, 5 Dec 2021 17:47:07 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: "Joel M. Halpern" , "rfced-future@iab.org" References: <1b84a90e-0a99-e4dd-42cf-a9159f39e17f@stpeter.im> <0515e2cf-97db-5c5c-fa3c-26ac918e2323@joelhalpern.com> <4f6af912-7a7b-8a12-a040-240c0444d694@joelhalpern.com> From: Peter Saint-Andre In-Reply-To: <4f6af912-7a7b-8a12-a040-240c0444d694@joelhalpern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue #138: Requests of the IETF Trust X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:47:16 -0000 Thanks, Joel. I didn't explain it very well. On 12/5/21 5:31 PM, Joel M. Halpern wrote: > Thanks.  I misunderstood what you were suggesting adding. > That makes sense. > Happy to see the text added, and work with my fellow trustees to make > sure we confirm at the relevant point in the process. > > Yours, > Joel > > On 12/5/2021 7:27 PM, Peter Saint-Andre wrote: >> On 12/5/21 4:48 PM, Joel M. Halpern wrote: >>> Why would this document need to do anything to the procedures in >>> 5744? Or, for that matter 5378.  Both would still apply. Also no >>> reason to mess with 8179. They have nothing to do with the RFC Editor >>> or the RPC. >>> If there is a reason to mess with those, we will need to proceed very >>> carefully. >> >> Because the existing non-IETF streams have text requesting assistance >> from the IETF Trust, we should do so for the Editorial Stream, too: >> >> IRTF: https://www.rfc-editor.org/rfc/rfc5743.html#section-3.1 >> IAB: https://www.rfc-editor.org/rfc/rfc5745.html#section-5 >> ISE: https://www.rfc-editor.org/rfc/rfc5744.html#section-5 >> >> Peter From nobody Sun Dec 5 22:26:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50DE3A05F8 for ; Sun, 5 Dec 2021 22:26:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwa6TyuOPbkt for ; Sun, 5 Dec 2021 22:26:01 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 3732A3A05E2 for ; Sun, 5 Dec 2021 22:26:00 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::4] ([IPv6:2001:420:c0c0:1011:0:0:0:4]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B66PtHm2028050 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 6 Dec 2021 07:25:56 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638771957; bh=3iznIGtasPoBo7itGSlCit/Rc/JbH66Lhb1yd1xM5/s=; h=Date:To:References:From:Cc:Subject:In-Reply-To:From; b=onEFsxs6stgeLD4ocOuob5sAVSn19FJfMPLfoXI2g4Cbc6sIK3idC/L9mCokU6RDD XU02AWnOrjodnMC77w4haErivX7EIGJ6MVHCgwiY9/0jJb4LVugXAQ2ESC289ZfKiM Ngh6ygF/7Xseq1twb2QRFZz5lK/2QuJfbljCXaeo= Message-ID: <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> Date: Mon, 6 Dec 2021 07:25:51 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Martin Thomson References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> From: Eliot Lear Cc: "rfced-future@iab.org" , Peter Saint-Andre In-Reply-To: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------5ukuU41evCb95ctrvePyiWQy" Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 06:26:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------5ukuU41evCb95ctrvePyiWQy Content-Type: multipart/mixed; boundary="------------xi0anF4XT00JiDm0qN8IxLUq"; protected-headers="v1" From: Eliot Lear To: Martin Thomson Cc: "rfced-future@iab.org" , Peter Saint-Andre Message-ID: <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> Subject: Re: [Rfced-future] Proposed "Historical Properties" References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> In-Reply-To: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> --------------xi0anF4XT00JiDm0qN8IxLUq Content-Type: multipart/mixed; boundary="------------p6pO4eyeUpbv7Qw001SGniLZ" --------------p6pO4eyeUpbv7Qw001SGniLZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VGhhbmtzLCBNYXJ0aW4uwqAgQSByZW1pbmRlcjogd2UgYXNrZWQgUGV0ZXIgdG8gd29yayB0 byBwdXQgdG9nZXRoZXIgYSANCnByb3Bvc2FsIG9uIHRoZSBwcm9jZWR1cmFsIGFzcGVjdHMs IHdoaWNoIHdpbGwgbmVlZCB0byBjaGFuZ2UgYSBiaXQuwqAgSGUgDQppcyB3b3JraW5nIHRv IGRldmVsb3AgdGhhdCB0ZXh0LCB3aGljaCBpcyByZWxhdGVkIHRvIHlvdXIgZmlyc3QgcGFy YWdyYXBoLg0KDQpJbiB0aGUgbWVhbnRpbWUsIEknZCBhc2sgUGV0ZXIgdG8gY3JlYXRlIGEg UFIgZm9yIHRoaXMgdGV4dCBpbiBhIHNlY3Rpb24gDQp0aGF0IGhlIGRlZW1zIGFwcHJvcHJp YXRlLsKgIFRoYXQgZG9lc24ndCBtZWFuIHRoYXQgdGhpbmdzIGNhbid0IGJlIA0KdHdlYWtl ZCBiYXNlZCBvbiBmdXJ0aGVyIGRpc2N1c3Npb24sIGJ1dCBJJ2QgbGlrZSB0aGUgZ3JvdXAg dG8gc2VlIG9uZSANCm1vcmUgdmVyc2lvbiBvZiB0aGUgZG9jIGJlZm9yZSB3ZSBhbGwgYnJl YWsgZm9yIGhvbGlkYXlzLg0KDQpFbGlvdA0KDQpPbiAwNi4xMi4yMSAwMDoxMSwgTWFydGlu IFRob21zb24gd3JvdGU6DQo+IFRoYW5rcyB0byBldmVyeW9uZSBjb250cmlidXRpbmcgZnJp ZW5kbHkgYW1lbmRtZW50cy4gSSBub3cgaGF2ZToNCj4NCj4NCj4gIyBIaXN0b3JpY2FsIFBy b3BlcnRpZXMgb2YgdGhlIFJGQyBTZXJpZXMNCj4NCj4gVGhlIFJTQUIgaGFzIGEgZHV0eSB0 byBlbnN1cmUgdGhhdCBwcm9wb3NhbHMgZnJvbSB0aGUgUlNXRyByZWNlaXZlIGFwcHJvcHJp YXRlIGxldmVscyBvZiByZXZpZXcuIFByb3Bvc2FscyB0aGF0LCBpbiB0aGUgb3BpbmlvbiBv ZiB0aGUgUlNBQiwgaGF2ZSBzaWduaWZpY2FudCBpbXBhY3Qgb24gdGhlIHNlcmllcyByZXF1 aXJlIGFkZGl0aW9uYWwgb3V0cmVhY2ggYW5kIHJldmlldyBmcm9tIGEgd2lkZXIgY29tbXVu aXR5LiBBZGRpdGlvbmFsIHRpbWUgc2hvdWxkIGJlIGFsbG93ZWQgZm9yIGNvbGxlY3Rpbmcg ZmVlZGJhY2sgZm9yIHN1Y2ggcHJvcG9zYWxzLjwhLS0gVGhpcyBwYXJhZ3JhcGggbWlnaHQg Z28gZWxzZXdoZXJlLCB3aXRoIGEgcmVmZXJlbmNlIHRoaXMgc2VjdGlvbi4gLS0+DQo+DQo+ IFRoaXMgc2VjdGlvbiBsaXN0cyBzb21lIG9mIHRoZSBwcm9wZXJ0aWVzIHRoYXQgaGF2ZSBi ZWVuIGhpc3RvcmljYWxseSByZWdhcmRlZCBhcyBpbXBvcnRhbnQgdG8gdGhlIFJGQyBTZXJp ZXMuIFByb3Bvc2FscyB0aGF0IGFmZmVjdCB0aGVzZSBwcm9wZXJ0aWVzIGFyZSBwb3NzaWJs ZSB3aXRoaW4gdGhlIHByb2Nlc3NlcyBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuIEhvd2V2 ZXIsIHRoZSBSU0FCIHNob3VsZCBzZWVrIGJyb2FkZXIgcmV2aWV3IGZvciBwcm9wb3NhbHMg dGhhdCBtaWdodCBoYXZlIGEgZGV0cmltZW50YWwgYWZmZWN0IG9uIHRoZXNlIHByb3BlcnRp ZXMuIFRoZSBwdXJwb3NlIG9mIHJldmlldyBpcyB0byBlbnN1cmUgdGhhdCBhbGwgY2hhbmdl cyBhcmUgZGVsaWJlcmF0ZSBhbmQgYW5kIHRoYXQgdGhlIGNvbnNlcXVlbmNlcyBvZiBhIHBy b3Bvc2FsLCBhcyBmYXIgYXMgdGhleSBhcmUgaWRlbnRpZmlhYmxlLCBoYXZlIGJlZW4gY2Fy ZWZ1bGx5IGNvbnNpZGVyZWQuDQo+DQo+ICMjIEF2YWlsYWJpbGl0eQ0KPg0KPiBEb2N1bWVu dHMgaW4gdGhlIFJGQyBTZXJpZXMgaGF2ZSBiZWVuIGF2YWlsYWJsZSBmb3IgbW9yZSB0aGFu IDM1IHllYXJzLCB3aXRoIG5vIGZlZSBmb3IgYWNjZXNzLg0KPg0KPiAjIyBBY2Nlc3NpYmls aXR5DQo+DQo+IFJGQyBTZXJpZXMgZG9jdW1lbnRzIGhhdmUgYmVlbiBwdWJsaXNoZWQgaW4g YSBmb3JtYXQgdGhhdCB3YXMgaW50ZW5kZWQgdG8gYmUgYXMgYWNjZXNzaWJsZSBhcyBwb3Nz aWJsZSB0byB0aG9zZSB3aXRoIHNwZWNpYWwgbmVlZHMsIGUuZy4sIGZvciB0aG9zZSB3aXRo IGltcGFpcmVkIHNpZ2h0Lg0KPg0KPiAjIyBMYW5ndWFnZQ0KPg0KPiBBbGwgZXhpc3Rpbmcg UkZDIFNlcmllcyBkb2N1bWVudHMgaGF2ZSBiZWVuIHB1Ymxpc2hlZCBpbiBFbmdsaXNoLiBE b2N1bWVudHMgaGF2ZSBiZWVuIGxpY2Vuc2VkIHRvIGV4cGxpY2l0bHkgcGVybWl0IHRyYW5z bGF0aW9uIGludG8gb3RoZXIgbGFuZ3VhZ2VzLg0KPg0KPiAjIyBEaXZlcnNpdHkNCj4NCj4g SW4gYWRkaXRpb24gdG8gSW50ZXJuZXQgc3RhbmRhcmRzLCB0aGUgUkZDIHNlcmllcyBoYXMg cHVibGlzaGVkIHByb2NlZHVyYWwgYW5kIGluZm9ybWF0aW9uYWwgZG9jdW1lbnRzLCB0aG91 Z2h0IGV4cGVyaW1lbnRzLCBzcGVjdWxhdGl2ZSBpZGVhcywgcmVzZWFyY2ggcGFwZXJzLCBo aXN0b3JpZXMsIGh1bW9yLCBhbmQgZXZlbiBldWxvZ2llcy4NCj4NCj4gIyMgUXVhbGl0eQ0K Pg0KPiBSRkMgU2VyaWVzIGRvY3VtZW50cyBoYXZlIGJlZW4gcmV2aWV3ZWQgZm9yIHN1Ympl Y3QgbWF0dGVyIHF1YWxpdHkgYW5kIGVkaXRlZCBieSBwcm9mZXNzaW9uYWxzIHdpdGggYSBn b2FsIG9mIGVuc3VyaW5nIHRoYXQgZG9jdW1lbnRzIGFyZSBjbGVhciwgY29uc2lzdGVudCwg YW5kIHJlYWRhYmxlIFtSRkM3MzIyXS4NCj4NCj4gIyMgU3RhYmlsaXR5DQo+DQo+IE9uY2Ug cHVibGlzaGVkLCBSRkMgU2VyaWVzIGRvY3VtZW50cyBoYXZlIG5vdCBjaGFuZ2VkLg0KPg0K PiAjIyBMb25nZXZpdHkNCj4NCj4gUkZDIFNlcmllcyBkb2N1bWVudHMgaGF2ZSBiZWVuIHB1 Ymxpc2hlZCBpbiBhIGZvcm0gaW50ZW5kZWQgdG8gYmUgZWFzaWx5IGxlZ2libGUgdG8gaHVt YW5zIGZvciBkZWNhZGVzIG9yIGxvbmdlci4NCj4NCg== --------------p6pO4eyeUpbv7Qw001SGniLZ Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------p6pO4eyeUpbv7Qw001SGniLZ-- --------------xi0anF4XT00JiDm0qN8IxLUq-- --------------5ukuU41evCb95ctrvePyiWQy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGtrO8FAwAAAAAACgkQh7ZrRtnSejMR +AgAy812fJretMyyP0+raaVY37rR2KJHta50L0TZxhoLP5M30OXlBrD/goIsOG5C7vRMBW0c0V1L KDZZHMZbU1wfKnY7hwxU9R9X1iJNPHsxbQxlUrosdJWkoCObakQCMKotEqqierNrO7YFpqIn9+kw FDavYh49ri0wlEy8N/lHLlE5NohelZnPXTI2550Bj2SNZQpaqFT1Y/8qoRuo8auySJkTZ1pgZoIK 0n0Fyr4EK/pkwS9AbRcbxrAanZcLdVQfodwzChVOGbl9sTPPupyEsSITJT9a0GX7GclVqXfQyFXA LKYurdhRLBxez/lAQEUhT7qeKV94+xCVSHLUmAsHDw== =G5Di -----END PGP SIGNATURE----- --------------5ukuU41evCb95ctrvePyiWQy-- From nobody Mon Dec 6 15:47:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79FD3A0B68 for ; Mon, 6 Dec 2021 15:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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=stpeter.im header.b=ZQ153yeu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=M7wEv/+h Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSqQzRPk6OuJ for ; Mon, 6 Dec 2021 15:46:53 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AF5D3A0B67 for ; Mon, 6 Dec 2021 15:46:53 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A551A5C021E; Mon, 6 Dec 2021 18:46:52 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 06 Dec 2021 18:46:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=W D7/wsjs9Oac/31+8s88O7kZf7Hc4bPl9ovV5C6Jysg=; b=ZQ153yeuP18LzKfk8 LVcNcXGl2AKL28CoXhayhhYwWzX+BkOYbQ6D5Lgt6BQZ8SChUO0RyUo5PFxo6Oze MmZTZKlSym/3uZNfy2hPi0nqPPrBuqxBDm05JFEDIejYSqVruMBMl/sQhVRCf4yM PwPApaefSDeqHLmGIHaKZ0LuEWgqL5oT30Cgo9ha8lwdwu2QwIuCJ6ebUyU8KNVo Q4VZ+v/uqeIv8Gnz7WCZDrcz3UNRvzZC8W6rYd1Rq4eKoSlhsnr8vO4V3UFeVqRD 7mSwPiPFSrux1WMoGtG2UvX0XYp03q8DaSpQICaYvu9A0SUAVZpj1jdHtH6wJVfH obA2A== 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=fm1; bh=WD7/wsjs9Oac/31+8s88O7kZf7Hc4bPl9ovV5C6Jy sg=; b=M7wEv/+hV22gyCa0R4chg8oQTBwD1A+WQ4hGJ02KKUJeUFvzxGN0q+Enr JcW9SvtUDh1z0aXGaLdMb+NjMD6VkrblOoRaFMYAEqwM3B0YMk16z+vIclMfaQxy 1b0FKYHVAF6c1zDT1XPerxMUqxEVp0ZuZWesmHM6FS7zl7gIXva648PrhDkVBgVQ 4PTHTPl7SB0LnSc8f0sHttfuRgFOe18qnSYI1MSqqVk1S4hcb9iN5Byl+or6KSrB PxBAvdnCdyRjrFPeH2DtB0Sf2pehT7FK0ryNgS5GBbP9wFeTzSx0QU3ep2cMzaH+ JZw2B4taP8WLR702T2dw0Cl4A+szA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeeggddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefrvghtvghr ucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqeenuc ggtffrrghtthgvrhhnpeevfedvgeeuueehueetfefhhfduhfevheejudfhleeiudffueek leetjefgteelgeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgv thgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 6 Dec 2021 18:46:51 -0500 (EST) Message-ID: Date: Mon, 6 Dec 2021 16:46:51 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , Martin Thomson Cc: "rfced-future@iab.org" References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> From: Peter Saint-Andre In-Reply-To: <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:46:59 -0000 Martin's text is now in a pull request: https://github.com/intarchboard/program-rfced-future/pull/140 The related text about community calls for comment and RSWG/RSAB review is in a separate PR: https://github.com/intarchboard/program-rfced-future/pull/141 On 12/5/21 11:25 PM, Eliot Lear wrote: > Thanks, Martin.  A reminder: we asked Peter to work to put together a > proposal on the procedural aspects, which will need to change a bit.  He > is working to develop that text, which is related to your first paragraph. > > In the meantime, I'd ask Peter to create a PR for this text in a section > that he deems appropriate.  That doesn't mean that things can't be > tweaked based on further discussion, but I'd like the group to see one > more version of the doc before we all break for holidays. > > Eliot > > On 06.12.21 00:11, Martin Thomson wrote: >> Thanks to everyone contributing friendly amendments. I now have: >> >> >> # Historical Properties of the RFC Series >> >> The RSAB has a duty to ensure that proposals from the RSWG receive >> appropriate levels of review. Proposals that, in the opinion of the >> RSAB, have significant impact on the series require additional >> outreach and review from a wider community. Additional time should be >> allowed for collecting feedback for such proposals. >> >> This section lists some of the properties that have been historically >> regarded as important to the RFC Series. Proposals that affect these >> properties are possible within the processes defined in this document. >> However, the RSAB should seek broader review for proposals that might >> have a detrimental affect on these properties. The purpose of review >> is to ensure that all changes are deliberate and and that the >> consequences of a proposal, as far as they are identifiable, have been >> carefully considered. >> >> ## Availability >> >> Documents in the RFC Series have been available for more than 35 >> years, with no fee for access. >> >> ## Accessibility >> >> RFC Series documents have been published in a format that was intended >> to be as accessible as possible to those with special needs, e.g., for >> those with impaired sight. >> >> ## Language >> >> All existing RFC Series documents have been published in English. >> Documents have been licensed to explicitly permit translation into >> other languages. >> >> ## Diversity >> >> In addition to Internet standards, the RFC series has published >> procedural and informational documents, thought experiments, >> speculative ideas, research papers, histories, humor, and even eulogies. >> >> ## Quality >> >> RFC Series documents have been reviewed for subject matter quality and >> edited by professionals with a goal of ensuring that documents are >> clear, consistent, and readable [RFC7322]. >> >> ## Stability >> >> Once published, RFC Series documents have not changed. >> >> ## Longevity >> >> RFC Series documents have been published in a form intended to be >> easily legible to humans for decades or longer. >> From nobody Mon Dec 6 15:47:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B041F3A0B6A for ; Mon, 6 Dec 2021 15:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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=stpeter.im header.b=lJHe/77F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ODztqeV4 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jJKk-7sgCgD for ; Mon, 6 Dec 2021 15:47:49 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD803A0B68 for ; Mon, 6 Dec 2021 15:47:49 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id F3E8E5C01E2; Mon, 6 Dec 2021 18:47:48 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 06 Dec 2021 18:47:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:from:to:references :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=p NO7XaPm0ZWXobnnUVOZ3AkKn0YSFRQ4pcj/t/LBo5s=; b=lJHe/77FkWbGtpMTa 3HdobyQYHc8fAq+ZqZyzMfAlcffTMkN+yLOQ7oVVfoo1F9AvfOBL2YIa9HmlEQlj OYTdeG3UDTTkNxt5qqaWc79GLAdMyUlnNGItWIp9eafMYJKj0+vM7sH4CMoNlu3n Rd2DdHLeDCWtVtoEX96slf4wFMIQWhjzxENsFQuyw4OxMe9SuYlqFP/A6Pg4yISC nrcz0KWnKUc2jG1H6TlhIHuwy5His873Wu1vnBXCVSLo0so+URsd5PR6GKchgf/w O/8wecDRcGQJy8zGlYD3Y6rC+FD2zk6023k7T2IpsdGZXkxCK9QGJ2/oIDM+qV5Y JKoJg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=pNO7XaPm0ZWXobnnUVOZ3AkKn0YSFRQ4pcj/t/LBo 5s=; b=ODztqeV4QnVYuSV/6Q33Xp6S06Y6JIWH/a9HLLEaitW303SQyxKHhof/t Oaim1hGquo+QxTLsCFkcyb2frGTwbvFNLJwZ29wp7ISQvpuUX2GnR3zLcaMSVup3 8H0wSAkWSn6a9xWXGSCXj4MgOPROYtyFEMki17nDu195EAY0dbjBZBCnndn9Hliv XvnNTN8RgBwdbiv820gn315zJSzZwiN3YbmsR9PbPflWjPxFndkNLghRCbndlGNV w7s9LcX5JMTgM4PvUxdSyzDC+QAs5tk51KobYwt+BooOB8OQW0srtzIRjc2z1fpo ldmLbp5iCAZSCoEnFskF6xjfmUHBQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeeggddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffhvfhfjggtgfesthekre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepveekgfehtdehkeegve etueetudeftdeivdetgedtheevieegkeetjeduheekudeinecuffhomhgrihhnpehgihht hhhusgdrtghomhdprhhftgdqvgguihhtohhrrdhorhhgnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgvthgvrhdr ihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 6 Dec 2021 18:47:48 -0500 (EST) Message-ID: Date: Mon, 6 Dec 2021 16:47:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US From: Peter Saint-Andre To: "Joel M. Halpern" , "rfced-future@iab.org" References: <1b84a90e-0a99-e4dd-42cf-a9159f39e17f@stpeter.im> <0515e2cf-97db-5c5c-fa3c-26ac918e2323@joelhalpern.com> <4f6af912-7a7b-8a12-a040-240c0444d694@joelhalpern.com> <60b9c321-57e3-8ecf-2611-ff642a7fc75e@stpeter.im> In-Reply-To: <60b9c321-57e3-8ecf-2611-ff642a7fc75e@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue #138: Requests of the IETF Trust X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:47:54 -0000 I've submitted a pull request for this issue: https://github.com/intarchboard/program-rfced-future/pull/142 On 12/5/21 5:47 PM, Peter Saint-Andre wrote: > Thanks, Joel. I didn't explain it very well. > > On 12/5/21 5:31 PM, Joel M. Halpern wrote: >> Thanks.  I misunderstood what you were suggesting adding. >> That makes sense. >> Happy to see the text added, and work with my fellow trustees to make >> sure we confirm at the relevant point in the process. >> >> Yours, >> Joel >> >> On 12/5/2021 7:27 PM, Peter Saint-Andre wrote: >>> On 12/5/21 4:48 PM, Joel M. Halpern wrote: >>>> Why would this document need to do anything to the procedures in >>>> 5744? Or, for that matter 5378.  Both would still apply. Also no >>>> reason to mess with 8179. They have nothing to do with the RFC >>>> Editor or the RPC. >>>> If there is a reason to mess with those, we will need to proceed >>>> very carefully. >>> >>> Because the existing non-IETF streams have text requesting assistance >>> from the IETF Trust, we should do so for the Editorial Stream, too: >>> >>> IRTF: https://www.rfc-editor.org/rfc/rfc5743.html#section-3.1 >>> IAB: https://www.rfc-editor.org/rfc/rfc5745.html#section-5 >>> ISE: https://www.rfc-editor.org/rfc/rfc5744.html#section-5 >>> >>> Peter > From nobody Mon Dec 6 20:23:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50173A1043 for ; Mon, 6 Dec 2021 20:23:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRXFSXBrl8ji for ; Mon, 6 Dec 2021 20:23:03 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614EB3A103D for ; Mon, 6 Dec 2021 20:23:03 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1muS0H-000CH3-9T; Mon, 06 Dec 2021 23:22:57 -0500 Date: Mon, 06 Dec 2021 23:22:52 -0500 From: John C Klensin To: Peter Saint-Andre , Eliot Lear , Martin Thomson cc: rfced-future@iab.org Message-ID: <04FA6448C084AE9C3A72F76E@PSB> In-Reply-To: References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> 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] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 04:23:08 -0000 Peter, Martin, Some (I hope small) suggestions / changes: --On Monday, December 6, 2021 16:46 -0700 Peter Saint-Andre wrote: > Martin's text is now in a pull request: > > https://github.com/intarchboard/program-rfced-future/pull/140 ------ Current: proposals that might have a detrimental effect Comment: "detrimental" would be appropriate if we were talking about principles, but I gather that is what people are trying to avoid ("principles" would still be my personal preference). In this context, it implies a judgment call by the RSAG, with no guidance other than whatever they are thinking at the moment as to whether a particular change meets that bar and hence should get the more extensive review. Example, deliberately chosen as probably the least likely of the list to become an issue or generate a proposed change. Suppose the RSWG/RSAG concluded that the Series would be considerably improved with more intense technical editing and that the only way to get there would be to charge a fee for at least some of the documents in the series. If the goal were to improve quality, nothing "detrimental" there. But we'd certainly want very wide and careful review. ----- Current: "heightened scrutiny" (and the new calls for comment, etc., text) Comment: I actually like this term as an alternate to "enhanced review" or similar phrases. But my intent, as discussed during the call and in earlier messages, was an expanded review, not just extra care in the discussions among the usual group of RSWG participants and RSAB members. The current text seems to imply the latter. What I, at least, was after was additional outreach to, e.g., the academic research and historical communities of readers and to those who use RFCs in procurement and/or regulatory specifications. I continue to believe that we do not need to specify how that outreach is done or to spend energy on what to do if it fails to produce any input. But I do expect the RSAG to make a good-faith effort, using the best advice they can get, to get reviews and input from people in those communities that are unlikely to be well-represented in the RSWG and unlikely to follow the mailing lists or social media venues called out in the current text and to pay careful attention to what they have to say. That seems to have been entirely lost from the current formulation, I hope not intentionally. ----- Current: more than 35 years, Comment: RFC 8700 says "50" and that was two years ago. Those who are especially concerned about privacy might also want it noted that, for most of that period, no identification of the person obtaining the document has been necessary. Also, under "Accessibility", "Availability", "Longevity", or some other topic, we have paid careful attention to the issue of making documents available without the need to use software to interpret documents that might fall out of use or require unusual tools or processing in the future. That has been mentioned, in different forms, several times on the list, only sometimes as part of the "archival" topic. ----- Current: licensed to explicitly permit translation Comment: I'll defer to others on this if they have better information, but my impression is that, at least for the first 30 or so years of the series, translations were explicitly permitted without any requirement for specific licensing. The above, in context, seems to imply that licenses are required and, at least unless they are guaranteed or blanket licenses exist, that would contradict the history we are trying to record. That is important in part because, unlike other SDOs, we have never tried to have, or designated, official translators or translations, much less guaranteed their accuracy. Any moves in those directions would also be inconsistent with the history. ----- Current: to Internet standards, the RFC series has Comment: Historically, we should not lose track of the facts that it was many years before the term "standard" was used for RFCs. Among the earliest documents identified as "standard for the Internet community" were documents that we would identify as procedural, rather than standard track, today. And this goes to the historical observation that the RFC Series predates the IETF and that the IETF came into being without the notion of "standards body". Suggestion: Can we just drop that bit, which implies that Internet standards (also a term of art, especially if "Standards" is used rather than "standards", that means something rather different. We should also try to avoid statements that get tangled up with "who is the publisher of the series". Instead, try, e.g., "The RFC series has included many types of documents including standards for the Internet, procedural and informational documents, thought experiments, speculative ideas, research papers, histories, humor, and even eulogies." ----- Current: easily legible to humans Comment: And least where I come from "legible" means that the text is not presented in a form that people have trouble reading, e.g., my handwriting or a highly decorated, neo-calligraphic, type style. I think something more like "accessible and usable" is intended. See above. ----- best, john From nobody Mon Dec 6 20:58:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 138A23A1073 for ; Mon, 6 Dec 2021 20:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.93 X-Spam-Level: X-Spam-Status: No, score=-3.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LOTS_OF_MONEY=0.001, NICE_REPLY_A=-1.852, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBswmuhyl0T7 for ; Mon, 6 Dec 2021 20:58:22 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6B13A1079 for ; Mon, 6 Dec 2021 20:58:21 -0800 (PST) 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.17.1/8.16.1) with ESMTPSA id 1B74wHMu079301 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 6 Dec 2021 22:58:19 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1638853099; bh=EFr2AEQXDbiFmRTfdTmahXpjqHaVMDUJt+a+7oY9994=; h=Subject:To:References:From:Date:In-Reply-To; b=ci4v31fXXQCZcJnQbn1qe3BZOvW4F/gDir3wmwCBRHij4Rsl9X8vOruIDaG8sPZct hneUnlAd2ltmkZmbz/Ux/9xu7iKkUKWVdFNx/pJFTJ+vURuyUKIfsMo+CeNsACFImi /uY5atzJQNO0Rnh9vQiGYIOUkQBFDuqQDxqGESk4= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> From: Adam Roach Message-ID: <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> Date: Mon, 6 Dec 2021 22:58:13 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <04FA6448C084AE9C3A72F76E@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 04:58:27 -0000 On 12/6/2021 10:22 PM, John C Klensin wrote: > > Current: > proposals that might have a detrimental effect > > Comment: > "detrimental" would be appropriate if we were talking about > principles, but I gather that is what people are trying to avoid > ("principles" would still be my personal preference). In this > context, it implies a judgment call by the RSAG, with no > guidance other than whatever they are thinking at the moment as > to whether a particular change meets that bar and hence should > get the more extensive review. No matter how we slice this, it's going to rely on the RSAG exhibiting good judgement. I think the point here is that, e.g., deciding that we want to add some kind of accessibility markup to the HTML output format has a positive effect on Accessibility, while deciding that we want to replace all HTML elements with styled elements would have a detrimental effect. So while it would be incumbent on the RSAG to cast a wider net for the latter change, I don't think we want to require the same level of scrutiny for the former. > Example, deliberately chosen as > probably the least likely of the list to become an issue or > generate a proposed change. Suppose the RSWG/RSAG concluded > that the Series would be considerably improved with more intense > technical editing and that the only way to get there would be to > charge a fee for at least some of the documents in the series. That would have a clearly detrimental effect on the properties described under "Availability," thereby resulting in wider consultation. On the other hand, if some deep-pocketed nonprofit stood up and offered US$2.5M worth of editorial assistance per year, no strings attached, it wouldn't have the clear detrimental effect that you hypothesize; and I think we agree that it wouldn't require the wider community review as a consequence. So I'm pretty sure your triggering condition here isn't to the attempt to improve Quality, as much as it is the detrimental impact on Availability. I think we also need to have a baseline assumption that the RSWG and RSAG will not, en masse, go batdung bonkers. > ----- > > Current: > "heightened scrutiny" (and the new calls for comment, etc., > text) > > Comment: > I actually like this term as an alternate to "enhanced > review" or similar phrases. But my intent, as discussed during > the call and in earlier messages, was an expanded review, not > just extra care in the discussions among the usual group of RSWG > participants and RSAB members. The current text seems to imply > the latter. That's because you're looking at the wrong section. The key phrase in *this* section is "As described under... {{cfc}}..." The key phrase in {{cfc}} is: "In cases where a proposal has the potential to significantly modify   policies of long standing or historical characteristics of the   Series, the RSAB should take extra care to reach out to even broader   communities that make use of RFCs, such as scholarly researchers,   procurement managers, and standards development organizations." > That seems to have been entirely lost from the current > formulation, I hope not intentionally. John. > ----- > > Current: > licensed to explicitly permit translation > > Comment: > I'll defer to others on this if they have better information, > but my impression is that, at least for the first 30 or so years > of the series, translations were explicitly permitted without > any requirement for specific licensing. The above, in context, > seems to imply that licenses are required and, at least unless > they are guaranteed or blanket licenses exist, that would > contradict the history we are trying to record. Ah, I think you're onto something here. Perhaps: "Documents have been made available under terms that explicitly allow anyone to translate them into other languages without asking for permission to do so." Your other comments have concrete suggestions, and I have no issue with those suggestions. /a From nobody Mon Dec 6 21:50:23 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC043A1123 for ; Mon, 6 Dec 2021 21:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=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 5hV60JU7z_F2 for ; Mon, 6 Dec 2021 21:50:17 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57A7D3A1122 for ; Mon, 6 Dec 2021 21:50:16 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1muTMj-000COi-Tr; Tue, 07 Dec 2021 00:50:13 -0500 Date: Tue, 07 Dec 2021 00:50:08 -0500 From: John C Klensin To: Adam Roach , rfced-future@iab.org Message-ID: <5C645FC1866F8E37156908F4@PSB> In-Reply-To: <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 05:50:22 -0000 --On Monday, December 6, 2021 22:58 -0600 Adam Roach wrote: > On 12/6/2021 10:22 PM, John C Klensin wrote: >> >> Current: >> proposals that might have a detrimental effect >> >> Comment: >> "detrimental" would be appropriate if we were talking about >> principles, but I gather that is what people are trying to >> avoid ("principles" would still be my personal preference). >> In this context, it implies a judgment call by the RSAG, with >> no guidance other than whatever they are thinking at the >> moment as to whether a particular change meets that bar and >> hence should get the more extensive review. > No matter how we slice this, it's going to rely on the RSAG > exhibiting good judgement. I think the point here is that, > e.g., deciding that we want to add some kind of accessibility > markup to the HTML output format has a positive effect on > Accessibility, while deciding that we want to replace all HTML > elements with styled elements would have a detrimental > effect. So while it would be incumbent on the RSAG to cast a > wider net for the latter change, I don't think we want to > require the same level of scrutiny for the former. Agreed, I think. Just having a bit of a problem with terminology and wanting to provide some meaningful guidance, guidance that should probably include, at least implicitly, something equivalent to "if in doubt, do the wider review". >> Example, deliberately chosen as >> probably the least likely of the list to become an issue or >> generate a proposed change. Suppose the RSWG/RSAG concluded >> that the Series would be considerably improved with more >> intense technical editing and that the only way to get there >> would be to charge a fee for at least some of the documents >> in the series. > > > That would have a clearly detrimental effect on the properties > described under "Availability," thereby resulting in wider > consultation. > > On the other hand, if some deep-pocketed nonprofit stood up > and offered US$2.5M worth of editorial assistance per year, no > strings attached, it wouldn't have the clear detrimental > effect that you hypothesize; and I think we agree that it > wouldn't require the wider community review as a consequence. I'm actually not sure about that. Example: The idea of shifting to a pre-Last Call editing pass so that the community would be reviewing a document very close to what would be published has been raised/proposed several times. It would largely eliminate the problem of post-Last Call negotiations among the the RPC, IESG, ADs, and authors that has occasionally resulted in documents being published that are barely recognizable to the WGs that produced them. That idea has always been rejected because we simply do not have the resources to edit a given document multiple times and because such editing (given the available resources) would introduce unacceptable delays. A big injection of money could presumably eliminate both of those obstacles. So, completely positive, right? But it would also reduce the ability of the RPC to work as a small team in close intra-team communications, possibly change the role of the RSCE somewhat (in practice if not in theory), and create different risks about technical errors being introduced in the editorial process that a WG would then need to sort out. I'd suggest that, at the risk of looking gift horses in the mouth, such an offer would deserve exceptional scrutiny. > So I'm pretty sure your triggering condition here isn't to the > attempt to improve Quality, as much as it is the detrimental > impact on Availability. > > I think we also need to have a baseline assumption that the > RSWG and RSAG will not, en masse, go batdung bonkers. I am making that assumption. I am also making an assumption, having only watched the IETF community on and off for nearly 35 years and the ARPANET/Internet development community for a decade and a half longer, that people who have discovered a whizbang new idea and agreed on it will sometimes get impatient to see it deployed, sometimes being inclined to take shortcuts because their solution or approach seems too obvious to question. I am not too concerned about "bonkers", batdung or otherwise. I am concerned with impatience and wanting to get on with things and therefore seeing heightened scrutiny and outreach --a process that could easily add a month or two to the "normal" methods-- as an unattractive impediment to be avoided if that is plausible. Examples where it is clearly and unambiguously not plausible are easy to find and we have both identified them. It is the "well, maybe, this does not _really_, _absolutely_, need wider review" cases I'm concerned about. I need to stop there for tonight; will try to get back to your other comments tomorrow. john From nobody Mon Dec 6 22:16:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E723A1157 for ; Mon, 6 Dec 2021 22:16:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8W7hC2w779L for ; Mon, 6 Dec 2021 22:16:20 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 203893A1156 for ; Mon, 6 Dec 2021 22:16:19 -0800 (PST) Received: from [192.168.0.230] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B76GGeI2723278 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 7 Dec 2021 07:16:16 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638857776; bh=mmUWpojRxClUySgU32Oi5UQivpVKJ5nENaWmjSXg1tU=; h=Date:To:References:From:Subject:In-Reply-To:From; b=qgSSoiKVy9ZwRHWIXTZMBnyqUSAIAqnbu/UJkGZwRGWvHsKoviIsFPD2/ZNgdsZee RE6JCu8rWXcFKYdDq7FSFUthDN6OQcOVEvYr4SNfzYQMFkpqsiCXh3WL1Omy35DaKn l63lYVKnASQJv28cIZoEtcCcUgSZ0ct4YprWzC38= Message-ID: <81d0646f-f4d5-dea6-3e82-afb6c68c6a99@lear.ch> Date: Tue, 7 Dec 2021 07:16:16 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Adam Roach , rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> From: Eliot Lear In-Reply-To: <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------mC9EXm4Xt9x0JhOLVyR2kpRh" Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 06:16:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------mC9EXm4Xt9x0JhOLVyR2kpRh Content-Type: multipart/mixed; boundary="------------dfkSTZadQuyK92pu0RTHw3o7"; protected-headers="v1" From: Eliot Lear To: Adam Roach , rfced-future@iab.org Message-ID: <81d0646f-f4d5-dea6-3e82-afb6c68c6a99@lear.ch> Subject: Re: [Rfced-future] Proposed "Historical Properties" References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> In-Reply-To: <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> --------------dfkSTZadQuyK92pu0RTHw3o7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkhDQoNCk9uIDA3LjEyLjIxIDA1OjU4LCBBZGFtIFJvYWNoIHdyb3RlOg0KPg0KPj4gQ29t bWVudDoNCj4+IMKgwqDCoMKgwqAgSSBhY3R1YWxseSBsaWtlIHRoaXMgdGVybSBhcyBhbiBh bHRlcm5hdGUgdG8gImVuaGFuY2VkDQo+PiByZXZpZXciIG9yIHNpbWlsYXIgcGhyYXNlcy7C oCBCdXQgbXkgaW50ZW50LCBhcyBkaXNjdXNzZWQgZHVyaW5nDQo+PiB0aGUgY2FsbCBhbmQg aW4gZWFybGllciBtZXNzYWdlcywgd2FzIGFuIGV4cGFuZGVkIHJldmlldywgbm90DQo+PiBq dXN0IGV4dHJhIGNhcmUgaW4gdGhlIGRpc2N1c3Npb25zIGFtb25nIHRoZSB1c3VhbCBncm91 cCBvZiBSU1dHDQo+PiBwYXJ0aWNpcGFudHMgYW5kIFJTQUIgbWVtYmVycy7CoMKgIFRoZSBj dXJyZW50IHRleHQgc2VlbXMgdG8gaW1wbHkNCj4+IHRoZSBsYXR0ZXIuDQo+DQo+DQo+IFRo YXQncyBiZWNhdXNlIHlvdSdyZSBsb29raW5nIGF0IHRoZSB3cm9uZyBzZWN0aW9uLiBUaGUg a2V5IHBocmFzZSBpbiANCj4gKnRoaXMqIHNlY3Rpb24gaXMgIkFzIGRlc2NyaWJlZCB1bmRl ci4uLiB7e2NmY319Li4uIiBUaGUga2V5IHBocmFzZSBpbiANCj4ge3tjZmN9fSBpczoNCj4N Cj4gIkluIGNhc2VzIHdoZXJlIGEgcHJvcG9zYWwgaGFzIHRoZSBwb3RlbnRpYWwgdG8gc2ln bmlmaWNhbnRseSBtb2RpZnkNCj4gwqAgcG9saWNpZXMgb2YgbG9uZyBzdGFuZGluZyBvciBo aXN0b3JpY2FsIGNoYXJhY3RlcmlzdGljcyBvZiB0aGUNCj4gwqAgU2VyaWVzLCB0aGUgUlNB QiBzaG91bGQgdGFrZSBleHRyYSBjYXJlIHRvIHJlYWNoIG91dCB0byBldmVuIGJyb2FkZXIN Cj4gwqAgY29tbXVuaXRpZXMgdGhhdCBtYWtlIHVzZSBvZiBSRkNzLCBzdWNoIGFzIHNjaG9s YXJseSByZXNlYXJjaGVycywNCj4gwqAgcHJvY3VyZW1lbnQgbWFuYWdlcnMsIGFuZCBzdGFu ZGFyZHMgZGV2ZWxvcG1lbnQgb3JnYW5pemF0aW9ucy4iDQo+DQoNClllcy7CoCBUaGUgcmVz b2x1dGlvbiB3ZSBjYW1lIHRvIGxhc3Qgd2VlayByZXF1aXJlcyBjaGFuZ2VzIGluIG11bHRp cGxlIA0KcGxhY2VzIGluIHRoZSBkb2N1bWVudC7CoCBXZSB3aWxsIG5lZWQgb25lIG9yIHR3 byBtb3JlIHR3ZWFrcyBoZXJlIG9yIA0KdGhlcmUgdG8gYnJpbmcgdGhlIHByb2NlZHVyZSBp biBsaW5lIHdpdGggYWxsIG9mIHRoYXQuwqAgRm9yIGV4YW1wbGUsIHdlIA0Kc2hvdWxkIHJl aXRlcmF0ZSB0aGUgdGV4dCBQZXRlciBhZGRlZCBpbiBncm91bmRzIGZvciBjb25jZXJuIChh cyBpdCANCnN0YW5kcyB0aGF0IG9sZCB0ZXh0IGNvbmZsaWN0IHdpdGggd2hhdCBQZXRlciBh ZGRlZCBlbHNld2hlcmUpLg0KDQpJbiBwYXJ0aWN1bGFyLCB3ZSBzaG91bGQgcHJvYmFibHkg cmVpdGVyYXRlIHRoZSBjcml0ZXJpYSBmb3IgQ09OQ0VSTnMgaW4gDQp0aGUgcHJvY2VkdXJh bCBzZWN0aW9uIChncm91bmRzIGZvciByYWlzaW5nIGEgY29uY2Vybik7IGFzIGl0IHN0YW5k cyANCnRoZXJlIGlzIGEgY29uZmxpY3QgYmV0d2VlbiBvbGQgYW5kIG5ldyB0ZXh0Lg0KDQpF bGlvdA0KDQo= --------------dfkSTZadQuyK92pu0RTHw3o7-- --------------mC9EXm4Xt9x0JhOLVyR2kpRh Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGu/DAFAwAAAAAACgkQh7ZrRtnSejOy IggA0xegBMT43kklVZFUkKoNB4PeEJZcjCRTo05O3Zsx0QPAPcSBuQhYDgQErMO8CvySjBcbsCab 47tUd3WbjSrx4wkpdnNDbj58Ho4GbQiUW1WP9ZDYZ6rcBiVirB87Q1arO4XN9dAdmoVOF2muSk+i 6bxG4r+a3Rph8Mr73V6dhND3cdLWPfvBqskls5r9Bxb4tOhBZCgW8U+TIpy9aTmBxro7nCtqM1Y0 OC90hkCsP/QPNCZkSDELvVkzKOUmBwfTi6kKRpaBuEXzUnNgzYzunQxvGZeBsmHdwTk8uep8Xdzt uk3Arn89H01KsSbt+pWKzmO15wlfXJ/pd/Vg62/QcA== =YJQM -----END PGP SIGNATURE----- --------------mC9EXm4Xt9x0JhOLVyR2kpRh-- From nobody Mon Dec 6 22:29:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D2853A1188 for ; Mon, 6 Dec 2021 22:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=VAzu39zJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=VEk2Qsys Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdHVqXnbG_8g for ; Mon, 6 Dec 2021 22:29:05 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3E3B3A1186 for ; Mon, 6 Dec 2021 22:29:04 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3C8505C01DE; Tue, 7 Dec 2021 01:29:04 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 07 Dec 2021 01:29:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=idC3id717YuAcLhilGl+1y4wUOqf ejuitfRaK/AoK9s=; b=VAzu39zJh60cOBKXxcz8JJfJtebTQJlvG/SbR5piQMEZ S6t84m3Op86FSH1pDu3LpLOHZN5PtxblWxgtZ0P7q1gF6ZQPmrG9I9vyB2Rxq1cU bXVLtihDSGwkaH5pFnu7nDQz1J9tdOx7kFqtNAaXSYI8WA4VPW2HB96fb2kaQivL cdPSmUGz0YKl+2XgmbxjZBApTsC4KxnALuUThBKZPaNEduwGyoyBXepsscebm3uf ylZM2YINamyzkwhMQppLEd9iCF1AyjNLxCa2xFSXI3txgBrx/Gdag8/A70gj2jyO VS1NFmg26DvtO7RaLaTKbbHY3yNwFl2R+9IC4FBgTA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=idC3id 717YuAcLhilGl+1y4wUOqfejuitfRaK/AoK9s=; b=VEk2QsysqZceqzqrhH0qlb FMtRUxMFmGewGsQR3SDkJlx0RGGd23JWl85P+mezr6E1ST2CKtHy8WifEulgUiS7 L5PwZb5jdGVPMWXBY34NJM+hV3dT3tFV/OD/roPLJ1NtxAZp1ctok+FpiQv33iLf myBx8ZFxfb5AKuir193WnPK+8gHLEaAA0M2RnBxQii0ybJbAySH4QQ0EQ+LvM+Y9 weMReqUaPciFQWx+C+cwlspZJuqjJD/Odp0gGt6bP8PxlNYxizMjqshH45xO/Syf tZVy60YLdR0K6Vx8DaNF/SciRivxoXblB6BEkxBmIiofVnAasCps5nualyWNIdyA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeeggdeliecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfofgrrhht ihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigvnhhtrhhophihrdhnvghtqeenucggtf frrghtthgvrhhnpedtgefhkeegfffhteefjeekveefteehheelgeehheevleefteefieek fefgjedvgeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidr nhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C720A3C0246; Tue, 7 Dec 2021 01:29:03 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4492-g121c2470aa-fm-20211206.001-g121c2470 Mime-Version: 1.0 Message-Id: In-Reply-To: <04FA6448C084AE9C3A72F76E@PSB> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> Date: Tue, 07 Dec 2021 17:28:42 +1100 From: "Martin Thomson" To: "John C Klensin" , "Peter Saint-Andre" , "Eliot Lear" Cc: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 06:29:11 -0000 Hi John, Thanks for this input; the changes do seem small and constructive. I've taken those suggestions from you and those from Adam's response - all of those seem reasonable to me - and made suggestions against Peter's text. I think that the only things we might be missing is the connection between the two sets of changes Peter has shared (where the "wider review" piece moved from this section to the other) and your point about the "archival" topic. Personally, I'm happy to accept any of the changes as proposed. I will defer to Peter on the document organization piece. As for the the "archival" topic, my view is that we've captured the points on which we will agree to already, so I'd prefer to leave that matter undisturbed. On Tue, Dec 7, 2021, at 15:22, John C Klensin wrote: > Peter, Martin, > > Some (I hope small) suggestions / changes: > > > > --On Monday, December 6, 2021 16:46 -0700 Peter Saint-Andre > wrote: > >> Martin's text is now in a pull request: >> >> https://github.com/intarchboard/program-rfced-future/pull/140 > > ------ > > Current: > proposals that might have a detrimental effect > > Comment: > "detrimental" would be appropriate if we were talking about > principles, but I gather that is what people are trying to avoid > ("principles" would still be my personal preference). In this > context, it implies a judgment call by the RSAG, with no > guidance other than whatever they are thinking at the moment as > to whether a particular change meets that bar and hence should > get the more extensive review. Example, deliberately chosen as > probably the least likely of the list to become an issue or > generate a proposed change. Suppose the RSWG/RSAG concluded > that the Series would be considerably improved with more intense > technical editing and that the only way to get there would be to > charge a fee for at least some of the documents in the series. > If the goal were to improve quality, nothing "detrimental" > there. But we'd certainly want very wide and careful review. > > ----- > > Current: > "heightened scrutiny" (and the new calls for comment, etc., > text) > > Comment: > I actually like this term as an alternate to "enhanced > review" or similar phrases. But my intent, as discussed during > the call and in earlier messages, was an expanded review, not > just extra care in the discussions among the usual group of RSWG > participants and RSAB members. The current text seems to imply > the latter. What I, at least, was after was additional outreach > to, e.g., the academic research and historical communities of > readers and to those who use RFCs in procurement and/or > regulatory specifications. I continue to believe that we do not > need to specify how that outreach is done or to spend energy on > what to do if it fails to produce any input. But I do expect > the RSAG to make a good-faith effort, using the best advice they > can get, to get reviews and input from people in those > communities that are unlikely to be well-represented in the RSWG > and unlikely to follow the mailing lists or social media venues > called out in the current text and to pay careful attention to > what they have to say. > > That seems to have been entirely lost from the current > formulation, I hope not intentionally. > > ----- > > Current: > more than 35 years, > > Comment: > RFC 8700 says "50" and that was two years ago. Those who > are especially concerned about privacy might also want it noted > that, for most of that period, no identification of the person > obtaining the document has been necessary. > > Also, under "Accessibility", "Availability", "Longevity", > or some other topic, we have paid careful attention to the issue > of making documents available without the need to use software > to interpret documents that might fall out of use or require > unusual tools or processing in the future. That has been > mentioned, in different forms, several times on the list, only > sometimes as part of the "archival" topic. > > ----- > > Current: > licensed to explicitly permit translation > > Comment: > I'll defer to others on this if they have better information, > but my impression is that, at least for the first 30 or so years > of the series, translations were explicitly permitted without > any requirement for specific licensing. The above, in context, > seems to imply that licenses are required and, at least unless > they are guaranteed or blanket licenses exist, that would > contradict the history we are trying to record. That is > important in part because, unlike other SDOs, we have never > tried to have, or designated, official translators or > translations, much less guaranteed their accuracy. Any moves in > those directions would also be inconsistent with the history. > > ----- > > Current: > to Internet standards, the RFC series has > > Comment: > Historically, we should not lose track of the facts that it > was many years before the term "standard" was used for RFCs. > Among the earliest documents identified as "standard for the > Internet community" were documents that we would identify as > procedural, rather than standard track, today. And this goes to > the historical observation that the RFC Series predates the IETF > and that the IETF came into being without the notion of > "standards body". > > Suggestion: > Can we just drop that bit, which implies that Internet > standards (also a term of art, especially if "Standards" is used > rather than "standards", that means something rather different. > We should also try to avoid statements that get tangled up with > "who is the publisher of the series". Instead, try, e.g., > > "The RFC series has included many types of documents > including standards for the Internet, procedural and > informational documents, thought experiments, > speculative ideas, research papers, histories, humor, > and even eulogies." > > ----- > > Current: > easily legible to humans > > Comment: > And least where I come from "legible" means that the text > is not presented in a form that people have trouble reading, > e.g., my handwriting or a highly decorated, neo-calligraphic, > type style. I think something more like "accessible and usable" > is intended. See above. > > ----- > > best, > john From nobody Mon Dec 6 22:29:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6B83A118B for ; Mon, 6 Dec 2021 22:29:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.931 X-Spam-Level: X-Spam-Status: No, score=-3.931 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YCAh-wQbfbnZ for ; Mon, 6 Dec 2021 22:29:33 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3CB3A1189 for ; Mon, 6 Dec 2021 22:29:33 -0800 (PST) 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.17.1/8.16.1) with ESMTPSA id 1B76TTbu094839 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 7 Dec 2021 00:29:30 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1638858571; bh=4k5oWAaWNNzzy2Kava+NrudqiDHA3oGzr38S5+inEg0=; h=Subject:To:References:From:Date:In-Reply-To; b=E7WzNsY7+JcnIOyjeoDcZFVrXBvFbT8ez/DTFQ7b8IWvnt0Zmhh2QtsyIan21gHZV tAbOC7YDQZc1ImP2fAmnzPqqJHwV7Q5rDeVpgO3pIRZH+cx8RWjoIjBqPYV8kGk/Al +4Qbc2s9rUiQOXb+5hCBdzw7NySRL2JKQ17wUGSM= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> <5C645FC1866F8E37156908F4@PSB> From: Adam Roach Message-ID: <5c43e4db-667f-871c-4205-08d9b329d658@nostrum.com> Date: Tue, 7 Dec 2021 00:29:25 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <5C645FC1866F8E37156908F4@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 06:29:38 -0000 On 12/6/2021 11:50 PM, John C Klensin wrote: > Just having a bit of a problem with > terminology and wanting to provide some meaningful guidance, > guidance that should probably include, at least implicitly, > something equivalent to "if in doubt, do the wider review". Sure. More formally, one might phrase this in the document as "When in doubt about whether a proposal qualifies, the RSAG should err on the side of wider consultation." That's more for the text in PR 141 than PR 140, though. /a From nobody Mon Dec 6 22:56:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0B373A11DF for ; Mon, 6 Dec 2021 22:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.741 X-Spam-Level: X-Spam-Status: No, score=-3.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, 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 (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 avYuElHPAAdB for ; Mon, 6 Dec 2021 22:56:49 -0800 (PST) Received: from JPN01-OS0-obe.outbound.protection.outlook.com (mail-os0jpn01on2071e.outbound.protection.outlook.com [IPv6:2a01:111:f403:700c::71e]) (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 8E42B3A11DC for ; Mon, 6 Dec 2021 22:56:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ezC3J3jC4RpD0hp4n9YONFraCdRGKMtXxKgB2Z9LIqu9j9sOmJures2d4sRvRaD1goGTAtabnJ2wDkHEWWChIqsmAiUTPxCCTUjJVJ9VQayFFcNwnYRCZO0OXMkoPlc6nXZrNBVtXu2wXUklsWTV8MH8y6M8OyJpnBO8SO/8Fyb2ypKTNiFgAisiKdRz6Mejuu4naCCflYqroVL1FQNSLiqlCmUmb3laNZYz/j463bKQwwe4bxXMuBFVX/g7vkH1TcRn5vtHoPqwnpLDGJZjVblpPwmxeid6T5qABvCrKdec0HQONh/Vto1NnlNnsNfXN4aFOIwDCTQns22BFZkIfg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=S/pp2QbTlNZeY2ruaYG5XThs5NVxpOrL1qCG9leG2oI=; b=F1QPqYYA1jsFc1zb878h46QbsMKVmgE/70aIodcPO6l/fve0wwJGFPMzieSuPfS/XN8g6Q/L4ER4fkKcBIFjyg8ZVJcfIg5rLC3VfRpmODKaidvt27VZ7cqn2+FWZgqb7hQsAl4peOpmyAi6fVYy7gpi3Y/JiJQrqd6sHubE2w8SW3ryfqYBSKACrVKhtCJ/n4ppJP/g4zqLOjEztbV46wu1zOX1tlOFLjVqIVN2+1w1v8SEdaey9JZpM8jWkfT46GDLiOl6QWSiqnkyLhSYo2REeqKni2tveICKHJimTdHiwg8siAF5tbsu+HqCf66yHWK1cAdgfpqjEwLYKEzwWg== 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=S/pp2QbTlNZeY2ruaYG5XThs5NVxpOrL1qCG9leG2oI=; b=vmnyNBRQFyT9s7Vw55WbUbK+fOERPm7KOfAddqH55bwogEO02cz8Glvurxt1D2UgRXgUfo+pGeTEyR36ZGQqzgbS85WlsZPqE1R9mavCIT7tEmf2TzNakSBNwm7cFvXf4fLYe3Q1fzfqx+mc10+q4APppeY5owWZCqzMpjoxEcU= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB3532.jpnprd01.prod.outlook.com (2603:1096:404:d1::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.19; Tue, 7 Dec 2021 06:56:43 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085%6]) with mapi id 15.20.4755.022; Tue, 7 Dec 2021 06:56:43 +0000 Message-ID: <701a29bd-25c2-be15-aeaf-979b9f41e0b9@it.aoyama.ac.jp> Date: Tue, 7 Dec 2021 15:56:41 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: John C Klensin , Peter Saint-Andre , Eliot Lear , Martin Thomson Cc: rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: <04FA6448C084AE9C3A72F76E@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYCPR01CA0064.jpnprd01.prod.outlook.com (2603:1096:405:2::28) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 Received: from [133.2.210.39] (133.2.210.39) by TYCPR01CA0064.jpnprd01.prod.outlook.com (2603:1096:405:2::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.19 via Frontend Transport; Tue, 7 Dec 2021 06:56:42 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 49fde9ea-db03-480b-ee92-08d9b94eba17 X-MS-TrafficTypeDiagnostic: TY2PR01MB3532:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 3dLtjK3xk0sYi2lvAi4f5UhyZzQ6H/VTpvAWKq4NT/4FaCKA/GdAdk9puiopiPLvHoRhtp//en2rcfp7Pm53anqzUuxuiGC9h4EsGWarKOawAA6yir86dnydTX47oMTKUpRSI049S9XNUjg5kaGpSYvLWgXRRt7pkpEGAZPEcUamsL8iq3kbSOLKO2KuKYUds4dawu1Cw3eK085vrLbgXVIxlQb5iH2v0Vi6CrAUIEQnTpYAJNlHHx3QEm+fHi6/H7DR9Kgk3v9GeaXWyG7mbtcFP09u+Nh180MBUvJHCB150juUCG5iAoRQ8bPdZeE/brkLW58/OuoyrV/foSkQupqOk3+2fio/fQ62O9wtgKEOQPqeyeHvnM2BIbcyXo/xzKnJm1mEK4mcGF/4KNp/pnCGRoip9rRyejCy1rQgaK0LkDey7IQCztXJoDPr5++mggZ7kgYjdC9FIVTYu+zi2nzpZ0zyH+F944VGfeuJqmNE0B1BLiqkwDg6Ptz/K59Q6M/cJf0AzJqz8fpJliHAUlALu802TXM85eFYS7kLIJnGyNCa0fWYZ4N2uPq9tITCAkObKRw3Sf7KIR8mg5MnwuCPe5KnCLtjx8ULrIQu26HaPga3kNRAHa6eoxzR19AV/8LNUmKkyxKYTtaH7sOB0b38PZytHGn0DeXe6Yh00gXuRqjU44urPpW3HBh5N9GrIww3Cg0T7RdGPAYKMtyBX7V0nyWUinmVm4FMCUwJ+8u82lnu0mZOBOnsZPBzAOyXhPGyQxyghfYPxBTJeRahGn0yHwWcji1DObxwCoZCBG9XsXycJ75SX1OgbvmK9FSfaDv4Q1iNGvNXIJrQst2hqWgXrimC7726222v75N/bADPDLQKLeSAnWWwRMaToTCP X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(396003)(136003)(39840400004)(366004)(376002)(8676002)(53546011)(8936002)(6706004)(86362001)(26005)(2616005)(956004)(6486002)(316002)(16576012)(786003)(52116002)(31686004)(36916002)(66476007)(66556008)(966005)(186003)(508600001)(5660300002)(110136005)(66946007)(38100700002)(38350700002)(31696002)(4326008)(2906002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K08zRUR6NzN0OFk2Q2UwTlkyTzBOZTc3Y21CMHR4dEhOVTB1Ym9OaVpDdVJ0?= =?utf-8?B?d0JybW9LekpJTVBLLy84ZGR0QlJTZnpuSGJmR0tXc2F3U1FSR2dOcytIY3h3?= =?utf-8?B?NkpsWDJkd3FTWkY0Q1ZpMkdkTno2TEdtRzlCcmw5NDMvVlY3d1V6QnRGVDFy?= =?utf-8?B?cjFsQkt3WURxZHNVM2UyN2pZa25UWHVPbm4vanAyOEhLOUpveHk0UTV4bmxZ?= =?utf-8?B?amVwWG5HeU9Mb0h4aHM5bFJwOXlIRTZwQzFFUUJIRlVMYUgwdHQwellLYWt2?= =?utf-8?B?SjRtYU9KdytMVXBUL1FLRHZVSmFKQTdRamdJTmR6dkpzWm01NTBVeHgyeFhU?= =?utf-8?B?L2QwR05OSXpsQUFUVGpqcFJXVlRPMXVXajVBYmkxb3FUSlEvRm1ESFRvZWlY?= =?utf-8?B?OFhITzNDb0FxVTJMOFFIL1h2eG1mSDBZd1VjK3h0dElLdEIvZVJpckVPb0FH?= =?utf-8?B?SVVPVzE1STcvaUZNbHF6UHhZZHJ3d3dhTi9OR0dJSFJDUmVYbDlEcmx2c2t6?= =?utf-8?B?d1NHN2xqMER5Yjh5cThkclNOMmtLZmFua3JLMXFCZ2lXbFJEOXU2aGJBK3lO?= =?utf-8?B?WEtTaGJkT0RESHZpeEZJeitMRmoxRSt2MjY2UmFyemdZQ1FyM2FRYWhadnM5?= =?utf-8?B?S0JXdWVaUFp2QjloL1ZyRXJTUzR4OHJjODRiSXUzZVhhSHUrMnVJK1psTS9S?= =?utf-8?B?VkR0bDZxVW04VThPMzJEREY2aFFlWEtJV2lvZDdGUGJWdHlHbWsvZTE3dnBE?= =?utf-8?B?N0lKUEF2Y3QvVC9iOC8zenhBYXBlV2o5Z2VuVmdtYWdIQnJDWFRNTEtONit3?= =?utf-8?B?WWFKdU9TS3E4bkR6S0FlaGFsNUhLamFXb3h1QUtsQzFOeW5nMFdJVGM2QTF6?= =?utf-8?B?WTVlWkxxTFE5L3JJYU0vOEViT1poZFVkaTl5L0lhdjZsNUZVeW84RkpvemhD?= =?utf-8?B?aDVhekU1eGc5T3czTWNydjkzY3ZOTmFxUDF4WHFMS01xNnQrRHh4YkFKdnBa?= =?utf-8?B?SWpOd3ZRT1hoakIybjh6ZERvaDRGY0M4aGpvdzFFd2JMKzYxK1Bwb2xoR1ZX?= =?utf-8?B?MlhSNE1qS2VhNmVpNHZjNUVTNjkzZ2p1Q1hHdkdOQ040SGd0RW9XSDBVbzND?= =?utf-8?B?eXNOM3MzZ1JONTUzbTI4OUF6QUZIMEljT09ZN1R2WFBPTG90eTdlN2JHeTI2?= =?utf-8?B?bWxJSTVnd3JUU3hxMVliYU02K3d6SFk0WXk1YjZZajF0aGlmMC9zMkJuVWEx?= =?utf-8?B?Y1RCS0c3aVlONUNiNGlDM0RiaDFWME41Sk5LZkdBdGRBVC9CZ0ZDUFVQZVpl?= =?utf-8?B?UUQ1NmZkNUp1Vm1SbXVQVkJCQzBwMThaWkpWMEJaYnQ5Z0I0NmhEZnhONHQv?= =?utf-8?B?MStrMGV4NjNwWERjQ294YWExZGVaUjRwRlhTTEhhM2dPcFJDWnhOVEIrMWph?= =?utf-8?B?eEoxR0tWSlNyTmVrSHMrZzNWSS9zbFNQV21xRmNUYlJhOVZHd0VKRlVCWDJD?= =?utf-8?B?U1BKeTI4OWJBdzZnRjFhUUtndGsrSmMza0xkS091ZGJPY245cGIwWkl1K091?= =?utf-8?B?SWJxemdpZENQTlp6anRhOGNybXE3ZmVQdmJnNHN5eGhvTmJBNnlYbGtUMmpE?= =?utf-8?B?ZEVpbkYxakxCMTVLQW9IN1BSTStRNEpNeGF2YTAxRFBtYzVIU3NnL3A2Mkk5?= =?utf-8?B?ZzhKNkhRK2Q0MnA0ZExacE9yOTBESWlpZzNteG9nMU51NC8rc2x6QlJzbmpk?= =?utf-8?B?d2VsZ1pSTjJ1ZHk3N2ZzcjhoWjVRM25yU1UzS0lFdlUzcFZFVDNrL2FPOGdY?= =?utf-8?B?T09qVFhGdWxDRUdiV1VhaWIyY3ZoR3ZIQUduTGMyUSsyWHpRbmU0RXZCVm1l?= =?utf-8?B?NVZvZzFtWmFrdTBZZUxJNnBHSWdRdHdEaTlRUEZwSHdHNE5oQ2Y1ZDFEY1lX?= =?utf-8?B?YU1iRmJQdGRvV0IyZGUwMGx3NHFEZzBOa2NLWkhsak9ZRnVtT3VmRVAvblVR?= =?utf-8?B?SVlJZ3ZwdytpVzF1UGRERzBhVklkeGs1YzZWL0p4aFhmNk9qa3Bad1ZIL0xN?= =?utf-8?B?TVBvYWRpY2x1ZzZkWHZTNWJFeWNGUlVZdGpnVm1iSkdNMmhYK21QdnYvMzUy?= =?utf-8?B?VFd0N0ZOU0dJdkZyTkxWb0VaWlpLL1BVcGs4RWVTQ2s0alQ0Y0FZSDRPWk5w?= =?utf-8?Q?euFWwEg+Gh+JzyuXREPGJhA=3D?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 49fde9ea-db03-480b-ee92-08d9b94eba17 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2021 06:56:43.1435 (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: Zzm8IKNjRqKajQyToh0tnti6Isi7WGmWTkWv1+bGoRhsfgthYLzxI9IcIh+lHA/8bpUi+YbURdPxbX2K/u0ZhQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB3532 Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 06:56:56 -0000 Hello John, others On 2021-12-07 13:22, John C Klensin wrote: > Peter, Martin, > > Some (I hope small) suggestions / changes: > Current: > licensed to explicitly permit translation > > Comment: > I'll defer to others on this if they have better information, > but my impression is that, at least for the first 30 or so years > of the series, translations were explicitly permitted without > any requirement for specific licensing. The above, in context, > seems to imply that licenses are required and, at least unless > they are guaranteed or blanket licenses exist, that would > contradict the history we are trying to record. That is > important in part because, unlike other SDOs, we have never > tried to have, or designated, official translators or > translations, much less guaranteed their accuracy. Any moves in > those directions would also be inconsistent with the history. IANAL, and what I'm writing here is mostly based on my experience with 'handling' translations at the W3C over 15 years ago. Translations are derivative works, and so unless they are done for personal use, a license *is* needed under most if not all copyright regimes. Whether this license is given explicitly (as is the case now, and as you mention was the case earlier) or implicitly (as may have been the case in the very early parts of RFC history) is a secondary issue. A 'license' doesn't mean there has to be a written contract between licensee and licensor. If you say they "were *explicitly* permitted without any requirement for specific licensing", that would mean that there was something somewhere in a relevant location that in some form said that they were permitted. This would be enough for a license, and would be essentially the same as now, where this is, with a lot of legalese, written down in the IETF Trust Legal Provisions (see https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/). Or did you mean to write 'implicitly'? And we don't know how often e.g. Jon Postel was asked by somebody whether it was okay to translate an RFC, and just said something like "sure, go ahead". That would have been an oral license, which in the general case should be fine. I'd still expect that e.g. a publisher wanting to publish a translation of (parts of) an RFC in a book would have tried to get something in writing, e.g. by sending Jon a release form with the necessary details. Regards, Martin. From nobody Tue Dec 7 05:50:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3D513A1640 for ; Tue, 7 Dec 2021 05:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.852 X-Spam-Level: X-Spam-Status: No, score=-3.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 O0x8N8EkRIbs for ; Tue, 7 Dec 2021 05:50:41 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2139.outbound.protection.outlook.com [40.107.20.139]) (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 9A9753A163F for ; Tue, 7 Dec 2021 05:50:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BJWm6A99j/lDbWFXNN4mYE0cuWr3kpiTg6IFi80nZEmM00brFFht//BXtjOiyZQjnG2+hx4FwMUB5MRo2DaU1Su7IBubo3FnahHoG7+C+HJyf0jiSaaNSsHEMJhSjuWCgpD/QHXeJN9awDxoffbZOTAnJrOE0V5ZoKR5OBYWJtffY6VyGlV1IjxBE1UblOoR7OjtJSsvPKM8L1vzqLa9cT4z9BFWiISgVb4ptlVuLzUcB9xYYlRIhwvCrlLXSl9gYlbLD4nyVJxt6+gIb/+vlbxkp5lsyGmZXMrm6WepfIUF7tgWwajc+GlizujsNoZ821QbeTZ+uSnk8RXvnLXzNQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=exA3X0CvXZrtz4U0UN13IO1cPunwxvMDivJEaCwqMz8=; b=FpTOJPFFoJUGdA8YGgG2N699K6vEMO4T7TXDrC1S71ybOe5SHMLqIJXt3PsZl6y+0EjJ6DWhPNdZWR8mtfoPfclooBz0zl7C7s0TS6uTw3BybE39m30OeXaYUtzJjQyo0PgVg/hrUJSJ/nlAnJOQoEAshD0cCPGSAUfWRNRPkdHnHv4NhyxG8B5CsCdZAQsuTFpZFpUrTOvTmu0vNIjKclxqQRgIjRzpkOjxOeJO3kKG0kkvH2K+V4nq9fXXlpYR6d3nN47An9F8WuasgideOkuhejGM8sAcrb7ejKcUFtXIV7fqQD87Qyun+jfu3Xr49ZP9LXotCviImUgsxzhBPg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=exA3X0CvXZrtz4U0UN13IO1cPunwxvMDivJEaCwqMz8=; b=VM3+r9Kln+2g421YATJMervak50H5+N4WUFm3oJn2mLmOTnUCbovijo4Ueulz5HGoJhR0bO17xJMEL5BqpfQOUlyLfdS4ktVcZ76N0iQfaHD1+ymYY9HNZFOpr8PaBg07YpqR4WzKaxjeq9lnFjaLzYypKQ0/xe6+8/KZR4mEUk4oY4xgOtuA8/eJrN0xrhMWE6VO+LPDlG6z6YLPcZIi9kjBSGxZoxmkql4QA6gOsCij3Ehf3H7as5Re8MNHoIATK6gcSg+KskkoVWj4GZ0BFp2pOMjb3bnOseM/ZYWEEYMapwVjRgEJxvJdzaMHht4NH5lD/Ev5ZnKW7rTVM2yEw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB9PR02MB7049.eurprd02.prod.outlook.com (2603:10a6:10:1fd::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Tue, 7 Dec 2021 13:50:37 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea%4]) with mapi id 15.20.4755.022; Tue, 7 Dec 2021 13:50:37 +0000 Message-ID: <662f244d-22c2-480e-453f-fef13c768f9b@cs.tcd.ie> Date: Tue, 7 Dec 2021 13:50:34 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: John C Klensin , Peter Saint-Andre , Eliot Lear , Martin Thomson Cc: rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> From: Stephen Farrell In-Reply-To: <04FA6448C084AE9C3A72F76E@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------byNiQHX9VxrRFWBxWZooyaUi" X-ClientProxiedBy: DB8PR09CA0022.eurprd09.prod.outlook.com (2603:10a6:10:a0::35) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [IPV6:2001:bb6:5e5e:b458:a354:7e12:ebb9:4a5f] (2001:bb6:5e5e:b458:a354:7e12:ebb9:4a5f) by DB8PR09CA0022.eurprd09.prod.outlook.com (2603:10a6:10:a0::35) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.17 via Frontend Transport; Tue, 7 Dec 2021 13:50:36 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: ffb8b87c-297a-4645-2c9a-08d9b9888bde X-MS-TrafficTypeDiagnostic: DB9PR02MB7049:EE_ X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:1751; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: aKK5u5JcGOvaQMoacyOvaOaUXxPQjxBRsiWXBpJZo74zvXGtdQ2sK+AbFXxBABRi4EjKyGnEpeujlhDDpQ21MM0SpDJDwKIgkR13bnXEmjQeoAtbOl1+ew3dJs2AikXdzLF4ps8WVbiLyke615OrlZOrzeINzJXbq+BdUcPRcflVkyOPgP0Cr8BNdk/TBtJsNNyEtn9eESx0h7RSrE+Sk1AW9dwXgDS2+kPE1+L6FXOdlcd9bzHC1Vqt/Zxr0jrQNn7zY9HWS/cajT48UJ5crlRRouZGMIt58CTsSOJeakfJalEJqcc8L9H8UKOKB4iDYQbKgfpLPaTbxx3wwa1gEyQH9arAycbUvn8e586VH5+dDg3RmWetw7bU4aUQ3tCLxPaSiUX/NSFrGHcdL/YcM8Cv8GkhFHYFPBPaQs4QpuhUg4d2TKsvLlvFFNMdqaDFcTIX9xUiTYgTBJYy0sZjdZjhBY5FQMqD9KCLz1BVIMSvj8XacXhmNnudvi6bWUZV2Z14m9YjsztqA/kDOTUVwtxXmX+ekPD8q3bcKH6SJOL1bdhFakKJwXGFyM2fV2VsgvxnIkXvwf3MbPhZBnUKSPkExoQ+QIzVTqit4+22g4N/4qab0ckDV4fKn8tnrVqo2S1iKU4IbmIppK6MRRS/T8VT//VohwWFu7cS1VCZTG8XhNLUkgvSbDO27zbi/U16tjggzOHNViXANiuR6Y9mLKZoainUk0BfZ77GELL2FF1WWJkWBe7X6ng+EG/y0BHk X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(33964004)(110136005)(86362001)(53546011)(21480400003)(5660300002)(235185007)(8676002)(31696002)(36756003)(6486002)(38100700002)(2906002)(786003)(316002)(66476007)(66556008)(66946007)(44832011)(2616005)(4326008)(186003)(31686004)(8936002)(508600001)(83380400001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MVBsQWdUVG1VWXdncDBLUXFpa3V0RkNvRUJNNWE4cGg0eHBOY2czbHV4bS85?= =?utf-8?B?M3NMTlVWQUxucXlyMDg5L0xmRXF3Q0s1QlQybWFZcHB1bXhsODN0RStvT2d4?= =?utf-8?B?cUx0SDBkMlBrTDNrQW1kSUF4Sm5CT09PeDBnOE5kN2ZTUVMwalFlWWpRVTJx?= =?utf-8?B?REp2bGxBNW8xRjg1TkZTVnlKbjE0aUVSdDludVJJVlFaZWd1MzN0NWQ5MkdL?= =?utf-8?B?Y1U0VTFzREQ4b1hVQVV1WmhuYSt4NXVLWkxscFdGVjhqQU9GUUU0TlNmWHJm?= =?utf-8?B?aGxBclZ1Rm9CQmNvcnIyQzVYVW42bzFjR2d4M21tc2NWaEc2M2lFL3IzRGpT?= =?utf-8?B?ZVVuZVNhK0hpQ1NBVXRrRjF1Q1FUVk1HeHo5Mm5FWmlhUnlNaDhpSkc3Uml5?= =?utf-8?B?YXAwMFJBV3phNDJwcSt2MDE3dStUTThRQUpOVUgvRjF1bFI2emxXTUpiUExR?= =?utf-8?B?dytUMUI5czlrQ2I2aGRFUmFHNVJiZ2RBRDl3dVdkbENJUW1WK3VKelJOa2dv?= =?utf-8?B?VlYyaW1BV3E1VTJWNzFSK0Z2c2M3enQ5NDZ0OVhRSk5HVmZQeFhSYm1jMVpE?= =?utf-8?B?SytNakJYZ1NpMnpleUM3RldBVjVtWkp6WTA4dFF3aWxvb1lHazBXb0UvTnBa?= =?utf-8?B?RnVwYnFieG1XVGs1V2tacCtOU3VCL28xZXVRM1JwMElGd3ZOdDJqVURVdUpx?= =?utf-8?B?UVZpUldTWTN0c2RjdWhtWTRSUVFBWVVxeEVPdUxEQThiMlRSaGdQUGRnT1hu?= =?utf-8?B?VVkxVDQvdGFOZW5wVWIyeVpIREY4c2ZlTjVyZ3VCVmtKTmJXTkpadDYvQTVM?= =?utf-8?B?RTQ1d2kvcURYc1p1RHhZeEZvQit5NXVaWjNqNHJrbHRBRmFabTM3dWtPZE50?= =?utf-8?B?NFJLWVdkVkFxWGkyWmZJYUVKVkVLYnhzZ3RvcVFzbW1qRy9Ba0Mxd3MrUzRq?= =?utf-8?B?U3hJUFVLNWd6NWphM0FnVG0vMWZ0Y0hFM3Z4eldkLzVQSEdnRUp2L21reUUr?= =?utf-8?B?azVpL0FpZ1VXdlpIS2FJWElkVUMxRTg5emk5SHBWWGVOVjVPdzhEdFNSV3pB?= =?utf-8?B?TzdZK1VvOWcrNkpmUkZTdThoVktERVFWMTJDcjVUYmh0KzY0M3hKR2hWeWU3?= =?utf-8?B?citBRUp5ZzQzdnZTRHFHUEhQMnNkRzRmV2lZMkx6UGdlSWx0QlpIdGM3NnJ2?= =?utf-8?B?bWd1OXMwbWhLT1FGZjR5LzdjMEVUMVo5bHFBNjc2NzRrNDdkUW5WWFhVd3ZM?= =?utf-8?B?SVJnVmY2YU54N2FvZUV1Vy9qQVB1QU4ySmVmYU5haDdkM1BtWVpMWkRVY00z?= =?utf-8?B?TWUrbHlUcllQcFZCTUxUN2d2S2lwUG1sYkN5elpObnlnWmYrRGdaZ1N3MjRQ?= =?utf-8?B?Z0krUElCQ1grVG9sVFNpWkJCbW5mUE11NlhMd0N3NjJOdjhsdWRSZnRPQWd2?= =?utf-8?B?YnBtc01Wc0UvZHRDc1ErVkVNZFlWWUVaK0dmZXBPWUUxWk85cmpaK0UvKzdV?= =?utf-8?B?enVmcGZ2UDlCSkRINlU1RExFdUtocjYxYS9OSEgrVkxweTVLS014Umg4TlBK?= =?utf-8?B?Nk4wcjd4cUdUdmpBcmduR21EbHBjYVJXUnk1MmJBak9MZXNWLzladFpNTFpq?= =?utf-8?B?amo5bkpmTlhiSGZvZUpNcjJLRUJkVERxS0ZtWmM3Y1hGdHY0S3E4aWhZelhh?= =?utf-8?B?LzhBM0owSUd2SXNUMS9xYzc3cnBYaXNmbVFBYXJ2SlVqRWpEODhSb25CM1dI?= =?utf-8?B?YjFTQ0Jhdzk0QW5ndncwb1haQnpKUGh2VWdvQUhrVENhOElvMm5ESlZlc3pj?= =?utf-8?B?Z1ZDaVBjYmpBMC9JUUpZSmtpRGpNYzVnN1ZVUEw2aVV1NnNoejY5cy9FNGZ0?= =?utf-8?B?Z05YcmhXdUVFYnkyYzVXZzFrdkNpa0hmOWc5WndYRnpuTEJmY09UM0JkSndl?= =?utf-8?B?V2dqM3NPeWJNL3BSQTFENFpicXpnTm0rUmVHcVozNUVPbEFqREN0bDNnY3hQ?= =?utf-8?B?R1FLdnN5eFJJRThNM3BpbllUMlBsWE4vYkxjSTY1VDltMmZuVW5kajRHRGZy?= =?utf-8?B?QkVkUUJsSnkzNHZYOW1MdC9OMDRTOC85MVJ3dEYvUWd1dlFCTDdSb1grRW9n?= =?utf-8?B?ZVQzNlByOE5iVEFYMUNiTHR1bElXMXdHVEUvK0xTRlRwaXV4U2Q1NGczSjA3?= =?utf-8?Q?nxxHx6nQFeHgO4B5rLnyqEo=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: ffb8b87c-297a-4645-2c9a-08d9b9888bde X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2021 13:50:36.9916 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: QfgT1AW+kWFkGQzWNzcL0I82xVpGEZsNs8Ze1V0fAgpGfked+9ji8SMVJsVr+9SG X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR02MB7049 Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 13:50:47 -0000 --------------byNiQHX9VxrRFWBxWZooyaUi Content-Type: multipart/mixed; boundary="------------NcT9RrLlQVpHVP8UkStQIcI1"; protected-headers="v1" From: Stephen Farrell To: John C Klensin , Peter Saint-Andre , Eliot Lear , Martin Thomson Cc: rfced-future@iab.org Message-ID: <662f244d-22c2-480e-453f-fef13c768f9b@cs.tcd.ie> Subject: Re: [Rfced-future] Proposed "Historical Properties" References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> In-Reply-To: <04FA6448C084AE9C3A72F76E@PSB> --------------NcT9RrLlQVpHVP8UkStQIcI1 Content-Type: multipart/mixed; boundary="------------ivFfKacLBD9BqQJgQMLEjs90" --------------ivFfKacLBD9BqQJgQMLEjs90 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpIaXlhLA0KDQpKdXN0IG9uIHRoaXMgYml0Li4uDQoNCk9uIDA3LzEyLzIwMjEgMDQ6MjIs IEpvaG4gQyBLbGVuc2luIHdyb3RlOg0KPiANCj4gQ3VycmVudDoNCj4gICAgICAgZWFzaWx5 IGxlZ2libGUgdG8gaHVtYW5zDQo+IA0KPiBDb21tZW50Og0KPiAgICAgICBBbmQgbGVhc3Qg d2hlcmUgSSBjb21lIGZyb20gImxlZ2libGUiIG1lYW5zIHRoYXQgdGhlIHRleHQNCj4gaXMg bm90IHByZXNlbnRlZCBpbiBhIGZvcm0gdGhhdCBwZW9wbGUgaGF2ZSB0cm91YmxlIHJlYWRp bmcsDQo+IGUuZy4sIG15IGhhbmR3cml0aW5nIG9yIGEgaGlnaGx5IGRlY29yYXRlZCwgbmVv LWNhbGxpZ3JhcGhpYywNCj4gdHlwZSBzdHlsZS4gIEkgdGhpbmsgc29tZXRoaW5nIG1vcmUg bGlrZSAiYWNjZXNzaWJsZSBhbmQgdXNhYmxlIg0KPiBpcyBpbnRlbmRlZC4gIFNlZSBhYm92 ZS4NCg0KSSdtIGZpbmUgaWYgc29tZSBzeW5vbnltIG9mIGxlZ2libGUgaXMgdXNlZCBidXQg ZGlkIHBpY2sNCnRoYXQgZGVsaWJlcmF0ZWx5IGFuZCBkb24ndCB0aGluayAiYWNjZXNzaWJs ZSBhbmQgdXNhYmxlIg0KaXMgYSBncmVhdCByZXBsYWNlbWVudCBiZWNhdXNlICJhY2Nlc3Np YmxlIiBpcyBjb3ZlcmVkDQplbHNld2hlcmUsIGFuZCAidXNhYmxlIiBpbXBsaWVzIHVuZGVy c3RhbmRpbmcgb2YgdGhlIGNvbnRlbnQNCndoaWNoIHdhc24ndCB3aGF0IEkgd2FudGVkIHRv IHNheS4gQXMgaXQncyB0aGUgImRlY2FkZXMNCmxhdGVyIiB0aGF0J3MgdGhlIG1lYXQgb2Yg dGhpcyBwb2ludCB0aG91Z2gsIGl0IHdvdWxkbid0DQpiZSB0aGUgZW5kIG9mIHRoZSB3b3Js ZCB0byBtYWtlIHRoYXQgY2hhbmdlLg0KDQpDaGVlcnMsDQpTLg0KDQoNCg== --------------ivFfKacLBD9BqQJgQMLEjs90 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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 zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 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+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC 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 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK 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+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb 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 Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R 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/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK 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+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB 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 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+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 =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------ivFfKacLBD9BqQJgQMLEjs90-- --------------NcT9RrLlQVpHVP8UkStQIcI1-- --------------byNiQHX9VxrRFWBxWZooyaUi Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmGvZqoFAwAAAAAACgkQWrL68XsXK+ry Rw/9GmuqcxTRhlWI6S0R+jDEGXx7/Q7roKTbo1Y34esHu7JnR/WnZuPjzAgd7S4R9p8vt9jMVzO9 I0d59YHwsaoojwfNFpDj8h1F0HfAR4zNnd9Q1+4C39K/tiSHaJXd8OQUSDrmWiiSIvDz0sgQydcC GIXB47/Spx4Zv8pT9Cqd3+hhk/ANVLavOHHsACVO3n0ztTf+0hqxejYzqefkPmDJcB2W570EuzzU DNFeKC+KJLX1DUkMLrcsLcbHaOGGXYpiYjwSwfLz5jMMGIARLQVkRMaB4kcLXrlknn17+xr96Xzx B05Y6c5swcxXce5QNKvwkE8ERpXRi3ix9at+jQOHapD8rTknj3/An+vS5Aeicu3KYY5Dqc+5wmL5 sQ0D9EOWJVRed61lmsKXuM6TFIdZoG6k44Q8BYipq7uCt4TElfxw6CkcKOP98zALOr+Otrb0yJjj I/J7sMAEuOz5VpovlOBmiYS9nG95460nLy6y/kE5gxBSdIFJfgl0wUCJMn9RabaeFUR2dJN4BLTw JuFLcNlJTI8Ii/V1W4cbq4CLiTfQVenz6ZFIoyWbvd0TWVVOxbFqij3Ywivs7sg9rOVBWDPE5cZ9 RKt77/BLzlZpgRDMCt01WKU3hBfuMV1zVzBaUEqPjr/TNTl9yCQ8H8bA/kWRX2xIx53p5VbZIC/B mGo= =QS/b -----END PGP SIGNATURE----- --------------byNiQHX9VxrRFWBxWZooyaUi-- From nobody Tue Dec 7 06:04:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0300A3A1649 for ; Tue, 7 Dec 2021 06:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lnylKmdm8vCM for ; Tue, 7 Dec 2021 06:04:02 -0800 (PST) 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 4917C3A0A3A for ; Tue, 7 Dec 2021 06:04:02 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mub4W-000D1p-CV; Tue, 07 Dec 2021 09:03:56 -0500 Date: Tue, 07 Dec 2021 09:03:50 -0500 From: John C Klensin To: Stephen Farrell , Peter Saint-Andre , Eliot Lear , Martin Thomson cc: rfced-future@iab.org Message-ID: <25D478BB44D300A93B9155F0@PSB> In-Reply-To: <662f244d-22c2-480e-453f-fef13c768f9b@cs.tcd.ie> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <662f244d-22c2-480e-453f-fef13c768f9b@cs.tcd.ie> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 14:04:07 -0000 --On Tuesday, December 7, 2021 13:50 +0000 Stephen Farrell wrote: > > Hiya, > > Just on this bit... > > On 07/12/2021 04:22, John C Klensin wrote: >> >> Current: >> easily legible to humans >> >> Comment: >> And least where I come from "legible" means that the >> text is not presented in a form that people have >> trouble reading, e.g., my handwriting or a highly decorated, >> neo-calligraphic, type style. I think something more like >> "accessible and usable" is intended. See above. > > I'm fine if some synonym of legible is used but did pick > that deliberately and don't think "accessible and usable" > is a great replacement because "accessible" is covered > elsewhere, and "usable" implies understanding of the content > which wasn't what I wanted to say. As it's the "decades > later" that's the meat of this point though, it wouldn't > be the end of the world to make that change. As you say "decades later" (I'd actually prefer "a century or more later") is the point and I agree that my proposed substitution is not ideal. So, if someone else cannot come up with a better replacement for "legible", let's treat this is "editor discretion" or, if Peter cannot do better, maybe call the RPC's attention to this in the hope that they can find better vocabulary. Not important enough, IMO, to justifying a wordsmithing thread on the list. best, john From nobody Tue Dec 7 06:18:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEF0E3A1662 for ; Tue, 7 Dec 2021 06:18:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.615 X-Spam-Level: X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YaZM_Etl0rzJ for ; Tue, 7 Dec 2021 06:18:33 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C9973A165D for ; Tue, 7 Dec 2021 06:18:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4J7j890jKBz1pKqk; Tue, 7 Dec 2021 06:18:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1638886713; bh=9O0KxISSQrgPWDYKlUQpTx2N4eTAQAd4UtsJe6z1n40=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=AIzzFop+oCeHDvX0J6mPO4ALdYrhxTy4XvHaP8rZ63TzlvharSKd89u6PLIdAFOy2 dnER1cmTTy9iW3wg8jc6DV6BkRivfAU36H4fKG/Q5NNwZ1BYP1ayHyOKtrrkKFi+RB xVbF1WoIlXXMmrhqTIb+miBMkPmPqrRXTYUaXbAE= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4J7j884G1fz1pKHX; Tue, 7 Dec 2021 06:18:32 -0800 (PST) Message-ID: Date: Tue, 7 Dec 2021 09:18:30 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Cc: rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <701a29bd-25c2-be15-aeaf-979b9f41e0b9@it.aoyama.ac.jp> From: "Joel M. Halpern" In-Reply-To: <701a29bd-25c2-be15-aeaf-979b9f41e0b9@it.aoyama.ac.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 14:18:38 -0000 For purposes of clarifying what the historical practice on translation of RFCs is, the FAQ page for the IETF Trust says: Since the beginning of the RFC series, reproduction of whole RFCs (including translation into a language other than English) has been allowed and encouraged. The IETF Trust and the RFC Editor place no restrictions on this. Most RFCs include the standard phrase “Distribution of this memo is unlimited” to indicate this. Yours, Joel On 12/7/2021 1:56 AM, Martin J. Dürst wrote: > Hello John, others > > On 2021-12-07 13:22, John C Klensin wrote: >> Peter, Martin, >> >> Some (I hope small) suggestions / changes: > >> Current: >>         licensed to explicitly permit translation >> >> Comment: >>         I'll defer to others on this if they have better information, >> but my impression is that, at least for the first 30 or so years >> of the series, translations were explicitly permitted without >> any requirement for specific licensing.  The above, in context, >> seems to imply that licenses are required and, at least unless >> they are guaranteed or blanket licenses exist, that would >> contradict the history we are trying to record.  That is >> important in part because, unlike other SDOs, we have never >> tried to have, or designated, official translators or >> translations, much less guaranteed their accuracy.  Any moves in >> those directions would also be inconsistent with the history. > > IANAL, and what I'm writing here is mostly based on my experience with > 'handling' translations at the W3C over 15 years ago. > > Translations are derivative works, and so unless they are done for > personal use, a license *is* needed under most if not all copyright > regimes. Whether this license is given explicitly (as is the case now, > and as you mention was the case earlier) or implicitly (as may have been > the case in the very early parts of RFC history) is a secondary issue. > > A 'license' doesn't mean there has to be a written contract between > licensee and licensor. If you say they "were *explicitly* permitted > without any requirement for specific licensing", that would mean that > there was something somewhere in a relevant location that in some form > said that they were permitted. This would be enough for a license, and > would be essentially the same as now, where this is, with a lot of > legalese, written down in the IETF Trust Legal Provisions (see > https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/). Or > did you mean to write 'implicitly'? > > And we don't know how often e.g. Jon Postel was asked by somebody > whether it was okay to translate an RFC, and just said something like > "sure, go ahead". That would have been an oral license, which in the > general case should be fine. I'd still expect that e.g. a publisher > wanting to publish a translation of (parts of) an RFC in a book would > have tried to get something in writing, e.g. by sending Jon a release > form with the necessary details. > > Regards,   Martin. > From nobody Tue Dec 7 06:27:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 848C53A1667 for ; Tue, 7 Dec 2021 06:27:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFvrTgYvQu0O for ; Tue, 7 Dec 2021 06:27:17 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB2D3A1666 for ; Tue, 7 Dec 2021 06:27:17 -0800 (PST) Received: from p200300dee7024600f8f09a5b836f56d4.dip0.t-ipconnect.de ([2003:de:e702:4600:f8f0:9a5b:836f:56d4]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mubR1-0003BT-DI; Tue, 07 Dec 2021 15:27:11 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Tue, 7 Dec 2021 15:27:10 +0100 Cc: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <91289E13-ED07-456E-BC6E-CB6758A097A7@kuehlewind.net> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <701a29bd-25c2-be15-aeaf-979b9f41e0b9@it.aoyama.ac.jp> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1638887237;e8476d6b; X-HE-SMSGID: 1mubR1-0003BT-DI Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 14:27:23 -0000 Let just steal this text (or is there a copyright issue? ;-) ) > On 7. Dec 2021, at 15:18, Joel M. Halpern wrote: >=20 > For purposes of clarifying what the historical practice on translation = of RFCs is, the FAQ page for the IETF Trust says: > Since the beginning of the RFC series, reproduction of whole > RFCs (including translation into a language other than English) > has been allowed and encouraged. The IETF Trust and the RFC Editor > place no restrictions on this. Most RFCs include the standard = phrase > =E2=80=9CDistribution of this memo is unlimited=E2=80=9D to = indicate this. >=20 > Yours, > Joel >=20 > On 12/7/2021 1:56 AM, Martin J. D=C3=BCrst wrote: >> Hello John, others >> On 2021-12-07 13:22, John C Klensin wrote: >>> Peter, Martin, >>>=20 >>> Some (I hope small) suggestions / changes: >>> Current: >>> licensed to explicitly permit translation >>>=20 >>> Comment: >>> I'll defer to others on this if they have better = information, >>> but my impression is that, at least for the first 30 or so years >>> of the series, translations were explicitly permitted without >>> any requirement for specific licensing. The above, in context, >>> seems to imply that licenses are required and, at least unless >>> they are guaranteed or blanket licenses exist, that would >>> contradict the history we are trying to record. That is >>> important in part because, unlike other SDOs, we have never >>> tried to have, or designated, official translators or >>> translations, much less guaranteed their accuracy. Any moves in >>> those directions would also be inconsistent with the history. >> IANAL, and what I'm writing here is mostly based on my experience = with 'handling' translations at the W3C over 15 years ago. >> Translations are derivative works, and so unless they are done for = personal use, a license *is* needed under most if not all copyright = regimes. Whether this license is given explicitly (as is the case now, = and as you mention was the case earlier) or implicitly (as may have been = the case in the very early parts of RFC history) is a secondary issue. >> A 'license' doesn't mean there has to be a written contract between = licensee and licensor. If you say they "were *explicitly* permitted = without any requirement for specific licensing", that would mean that = there was something somewhere in a relevant location that in some form = said that they were permitted. This would be enough for a license, and = would be essentially the same as now, where this is, with a lot of = legalese, written down in the IETF Trust Legal Provisions (see = https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/). Or = did you mean to write 'implicitly'? >> And we don't know how often e.g. Jon Postel was asked by somebody = whether it was okay to translate an RFC, and just said something like = "sure, go ahead". That would have been an oral license, which in the = general case should be fine. I'd still expect that e.g. a publisher = wanting to publish a translation of (parts of) an RFC in a book would = have tried to get something in writing, e.g. by sending Jon a release = form with the necessary details. >> Regards, Martin. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Dec 7 06:39:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5EE713A16EB for ; Tue, 7 Dec 2021 06:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.615 X-Spam-Level: X-Spam-Status: No, score=-0.615 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_SBL_CSS=3.335, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaos4G3sGETO for ; Tue, 7 Dec 2021 06:39:11 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452AF3A16AA for ; Tue, 7 Dec 2021 06:39:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4J7jbx60cPz1pKqk; Tue, 7 Dec 2021 06:39:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1638887949; bh=l2zCZD4WqNFSdleBHeGFjMnG1HRFSD65CYPK2vb5/Xg=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=U4HxaSMBty1QhZPa75/8I8EhLPyuqMT+YKZN/Sc40T3HllPUSqXmS/Bt4Y16jyOMJ hasWQGgJXnvSG/ABoLF9/sR7AAaLUGSfM5dch+Z00MmlqVrK9p8QawaXLCXa+VWoNc voQ4OjHFq0WUAhDnTGzA4mlnx5hFuw59ynYXZpUc= X-Quarantine-ID: <4bFQVYR-WSsV> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4J7jbx2dGfz1pKqg; Tue, 7 Dec 2021 06:39:09 -0800 (PST) Message-ID: <97a572da-db7b-c250-4b0c-14e09b4f1cb5@joelhalpern.com> Date: Tue, 7 Dec 2021 09:39:08 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Mirja Kuehlewind Cc: rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <701a29bd-25c2-be15-aeaf-979b9f41e0b9@it.aoyama.ac.jp> <91289E13-ED07-456E-BC6E-CB6758A097A7@kuehlewind.net> From: "Joel M. Halpern" In-Reply-To: <91289E13-ED07-456E-BC6E-CB6758A097A7@kuehlewind.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 14:39:20 -0000 :-) For IETF purposes, we can steal it with no trouble. Yours, Joel On 12/7/2021 9:27 AM, Mirja Kuehlewind wrote: > Let just steal this text (or is there a copyright issue? ;-) ) > >> On 7. Dec 2021, at 15:18, Joel M. Halpern wrote: >> >> For purposes of clarifying what the historical practice on translation of RFCs is, the FAQ page for the IETF Trust says: >> Since the beginning of the RFC series, reproduction of whole >> RFCs (including translation into a language other than English) >> has been allowed and encouraged. The IETF Trust and the RFC Editor >> place no restrictions on this. Most RFCs include the standard phrase >> “Distribution of this memo is unlimited” to indicate this. >> >> Yours, >> Joel >> >> On 12/7/2021 1:56 AM, Martin J. Dürst wrote: >>> Hello John, others >>> On 2021-12-07 13:22, John C Klensin wrote: >>>> Peter, Martin, >>>> >>>> Some (I hope small) suggestions / changes: >>>> Current: >>>> licensed to explicitly permit translation >>>> >>>> Comment: >>>> I'll defer to others on this if they have better information, >>>> but my impression is that, at least for the first 30 or so years >>>> of the series, translations were explicitly permitted without >>>> any requirement for specific licensing. The above, in context, >>>> seems to imply that licenses are required and, at least unless >>>> they are guaranteed or blanket licenses exist, that would >>>> contradict the history we are trying to record. That is >>>> important in part because, unlike other SDOs, we have never >>>> tried to have, or designated, official translators or >>>> translations, much less guaranteed their accuracy. Any moves in >>>> those directions would also be inconsistent with the history. >>> IANAL, and what I'm writing here is mostly based on my experience with 'handling' translations at the W3C over 15 years ago. >>> Translations are derivative works, and so unless they are done for personal use, a license *is* needed under most if not all copyright regimes. Whether this license is given explicitly (as is the case now, and as you mention was the case earlier) or implicitly (as may have been the case in the very early parts of RFC history) is a secondary issue. >>> A 'license' doesn't mean there has to be a written contract between licensee and licensor. If you say they "were *explicitly* permitted without any requirement for specific licensing", that would mean that there was something somewhere in a relevant location that in some form said that they were permitted. This would be enough for a license, and would be essentially the same as now, where this is, with a lot of legalese, written down in the IETF Trust Legal Provisions (see https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/). Or did you mean to write 'implicitly'? >>> And we don't know how often e.g. Jon Postel was asked by somebody whether it was okay to translate an RFC, and just said something like "sure, go ahead". That would have been an oral license, which in the general case should be fine. I'd still expect that e.g. a publisher wanting to publish a translation of (parts of) an RFC in a book would have tried to get something in writing, e.g. by sending Jon a release form with the necessary details. >>> Regards, Martin. >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > From nobody Tue Dec 7 06:42:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5ED3A168C for ; Tue, 7 Dec 2021 06:42:19 -0800 (PST) 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_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCBMASaSqLY7 for ; Tue, 7 Dec 2021 06:42:15 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 33E183A168B for ; Tue, 7 Dec 2021 06:42:12 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::9] ([IPv6:2001:420:c0c0:1011:0:0:0:9]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B7Eg9Nh2968254 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Tue, 7 Dec 2021 15:42:10 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638888130; bh=iZfdtsCFjvZ8CKcvX5/1HM5PV10Y/u6rMRshhl+trn8=; h=Date:To:From:Subject:From; b=sactSHGy/K0XGQbiH8TKCTC/f6E8HTVPcDIv/lrKYT9EXcVgOj3m+S6CmG2bIB8mj jDMCUkb9CY+Cqr6HOYXyMziuDJnSb9ORI3ZjwBcpsgVT51+NTzW21fMTltmRk32LDa ijzpHQbHvK25v/omY5FEtyOqJi5PL0xqpMg6uZl8= Message-ID: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> Date: Tue, 7 Dec 2021 15:42:08 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------NCevXG5HEWzq0I14FgOEcpMg" Archived-At: Subject: [Rfced-future] next steps X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 14:42:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------NCevXG5HEWzq0I14FgOEcpMg Content-Type: multipart/mixed; boundary="------------HHC851orzzuigeA1eAIbLh03"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> Subject: next steps --------------HHC851orzzuigeA1eAIbLh03 Content-Type: multipart/mixed; boundary="------------SrROHzzRd45tT3Eb1jMvP4ZF" --------------SrROHzzRd45tT3Eb1jMvP4ZF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 QWxsLA0KDQpCYXJyaW5nIGxvdHMgbW9yZSBjb21tZW50cywgSSBhbSBhc2tpbmcgUGV0ZXIg dG8gZ2V0IGEgbmV3IHZlcnNpb24gb3V0IA0KYXJvdW5kIHRoZSBlbmQgb2YgdGhlIHdlZWsu wqAgSWYgdGhlcmUgaXMgYSBsb3Qgb2YgY29udmVyc2F0aW9uLCBoZSANCnNob3VsZCB3YWl0 LsKgIFRoZSBjaGFpcnMgaGF2ZW4ndCBoYWQgYSBjaGFuY2UgdG8gdGFsaywgYnV0IEkgYW0g dGhpbmtpbmcgDQp3ZSB3aWxsIHdhbnQgYW5vdGhlciAyIHdlZWsgTEMsIGJ1dCBwbGVhc2Ug T05MWSBvbiB0aGUgY2hhbmdlcy7CoCBEb2VzIA0KdGhhdCBzb3VuZCByZWFzb25hYmxlPw0K DQpFbGlvdA0KDQo= --------------SrROHzzRd45tT3Eb1jMvP4ZF Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------SrROHzzRd45tT3Eb1jMvP4ZF-- --------------HHC851orzzuigeA1eAIbLh03-- --------------NCevXG5HEWzq0I14FgOEcpMg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGvcsAFAwAAAAAACgkQh7ZrRtnSejNX QwgAgVxFWLExpLIlQNQrXRPxtHEwX3qCWD5hQyGqQbUKK+KAUnGrRpsT7KEoXZ9fJlloGTq8DNgp amy0/NGirwsFUgrO/aoBJHyFihCS8ivQJM9VT3j14XIoPogNilVCLInL/WtqitEizBbBg/lEtePZ PR9rTq08RPspJhY0eOuwWkjmmmrLb2ypGJQVW3zsQi5O5fFNJ88uAGDHqFV8vv/ba2THqMiDuKkq faxgxzkH2Ty50tBpLg+As8Jrgv75B14Nj0nJ3BNX/x6xE8ijYVLs29L7+UhSENhqgF7bhXBKx/Sr r1j1wNz4m49ejymAObi3XAPYfbuRA1D8ggX2H/TW4Q== =kBlI -----END PGP SIGNATURE----- --------------NCevXG5HEWzq0I14FgOEcpMg-- From nobody Tue Dec 7 07:04:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 343F13A16B6 for ; Tue, 7 Dec 2021 07:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6rYwqUemwmE for ; Tue, 7 Dec 2021 07:03:56 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 341763A16B1 for ; Tue, 7 Dec 2021 07:03:55 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1muc0Q-000D7d-31; Tue, 07 Dec 2021 10:03:46 -0500 Date: Tue, 07 Dec 2021 10:03:40 -0500 From: John C Klensin To: Mirja Kuehlewind , "Joel M. Halpern" cc: rfced-future@iab.org, =?UTF-8?Q?=22Martin_J=2E_D=C3=BCrst=22?= Message-ID: <28F7BCC622EA4D684390455B@PSB> In-Reply-To: <91289E13-ED07-456E-BC6E-CB6758A097A7@kuehlewind.net> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <701a29bd-25c2-be15-aeaf-979b9f41e0b9@it.aoyama.ac.jp> <91289E13-ED07-456E-BC6E-CB6758A097A7@kuehlewind.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 15:04:01 -0000 +1 (and shared amusement) --On Tuesday, December 7, 2021 15:27 +0100 Mirja Kuehlewind wrote: > Let just steal this text (or is there a copyright issue? ;-) ) >=20 >> On 7. Dec 2021, at 15:18, Joel M. Halpern >> wrote: >>=20 >> For purposes of clarifying what the historical practice on >> translation of RFCs is, the FAQ page for the IETF Trust says: >> Since the beginning of the RFC series, reproduction of >> whole RFCs (including translation into a language other >> than English) has been allowed and encouraged. The IETF >> Trust and the RFC Editor place no restrictions on this. >> Most RFCs include the standard phrase "Distribution of >> this memo is unlimited" to indicate this. >>=20 >> Yours, >> Joel >>=20 >> On 12/7/2021 1:56 AM, Martin J. D=C3=BCrst wrote: >>> Hello John, others >>> On 2021-12-07 13:22, John C Klensin wrote: >>>> Peter, Martin, >>>>=20 >>>> Some (I hope small) suggestions / changes: >>>> Current: >>>> licensed to explicitly permit translation >>>>=20 >>>> Comment: >>>> I'll defer to others on this if they have better >>>> information, but my impression is that, at least >>>> for the first 30 or so years of the series, translations >>>> were explicitly permitted without any requirement for >>>> specific licensing. The above, in context, seems to imply >>>> that licenses are required and, at least unless they are >>>> guaranteed or blanket licenses exist, that would contradict >>>> the history we are trying to record. That is important in >>>> part because, unlike other SDOs, we have never tried to >>>> have, or designated, official translators or translations, >>>> much less guaranteed their accuracy. Any moves in those >>>> directions would also be inconsistent with the history. >>> IANAL, and what I'm writing here is mostly based on my >>> experience with 'handling' translations at the W3C over 15 >>> years ago. Translations are derivative works, and so unless >>> they are done for personal use, a license *is* needed under >>> most if not all copyright regimes. Whether this license is >>> given explicitly (as is the case now, and as you mention was >>> the case earlier) or implicitly (as may have been the case >>> in the very early parts of RFC history) is a secondary = issue. >>> A 'license' doesn't mean there has to be a written contract >>> between licensee and licensor. If you say they "were >>> *explicitly* permitted without any requirement for specific >>> licensing", that would mean that there was something >>> somewhere in a relevant location that in some form said that >>> they were permitted. This would be enough for a license, and >>> would be essentially the same as now, where this is, with a >>> lot of legalese, written down in the IETF Trust Legal >>> Provisions (see >>> https://trustee.ietf.org/documents/trust-legal-provisions/tl >>> p-5/). Or did you mean to write 'implicitly'? And we don't >>> know how often e.g. Jon Postel was asked by somebody whether >>> it was okay to translate an RFC, and just said something >>> like "sure, go ahead". That would have been an oral license, >>> which in the general case should be fine. I'd still expect >>> that e.g. a publisher wanting to publish a translation of >>> (parts of) an RFC in a book would have tried to get >>> something in writing, e.g. by sending Jon a release form >>> with the necessary details. Regards, Martin. >>=20 >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Dec 7 07:15:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797033A16CA for ; Tue, 7 Dec 2021 07:15:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHgksCPzeESH for ; Tue, 7 Dec 2021 07:15:31 -0800 (PST) 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 149333A0834 for ; Tue, 7 Dec 2021 07:15:30 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mucBl-000D8m-8L; Tue, 07 Dec 2021 10:15:29 -0500 Date: Tue, 07 Dec 2021 10:15:23 -0500 From: John C Klensin To: Eliot Lear , rfced-future@iab.org Message-ID: <937D289CD1D4CC64E2A66C65@PSB> In-Reply-To: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> References: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> 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] next steps X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 15:15:36 -0000 --On Tuesday, December 7, 2021 15:42 +0100 Eliot Lear wrote: > All, >=20 > Barring lots more comments, I am asking Peter to get a new > version out around the end of the week.=C2=A0 If there is a = lot of > conversation, he should wait.=C2=A0 The chairs haven't had a > chance to talk, but I am thinking we will want another 2 week > LC, but please ONLY on the changes.=C2=A0 Does that sound > reasonable? Eliot, I think it does/should but only with the understanding that "only changes" is to be interpreted liberally. My concern is that sometimes new text accidentally exposes issues in other parts of the document and I would not want to have discussions of those barred. best, john From nobody Tue Dec 7 13:34:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC9683A0E63 for ; Tue, 7 Dec 2021 13:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=cyOctxSE; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=EamojCUn Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9nlJneB7j9_F for ; Tue, 7 Dec 2021 13:34:19 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345453A18E6 for ; Tue, 7 Dec 2021 13:34:06 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 302C3320249D; Tue, 7 Dec 2021 16:34:03 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 07 Dec 2021 16:34:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=4 lfmBt3/mRSgZ87X1UGEvetL0v2jx1CycUBKgVjAz3U=; b=cyOctxSEG8nXUlBCR iPtDeUSV7peubOe2JhYhpGYJD7EvLbkzYsfXe0G3JjKPhVRpVoJDCO2TEuv4OQh3 EGbcZ1XvbpBIQjcLT9yZOYOIhzuaPhJP7iaR0GM0nI6V9vREGon9I1tk1QQCxQZH /heFTsXv4rmi/2GjSkofHNSj7vUPn1QuEH3ZT4aadSwjokeib2VZ2n9Z+LL3InEX 3ah8Q31O0G+CQw+ZktaKxzHg+XolNud6mD+tHFA/xr8wvJxk83YwVEriowGK5t/5 CLa5dAv8L4fHW2FYEyPo5ARBsDc/rM8+S50dUVN56yA64ylEhGDaRcizOEWG6dEh 8mgFw== 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=fm1; bh=4lfmBt3/mRSgZ87X1UGEvetL0v2jx1CycUBKgVjAz 3U=; b=EamojCUnKI32eP6h+yAIZRQ+lIgav7PI79fEFYy6Lot4X3fodH35nnRM6 MO802QL4J13YzXl73dObFgSxlpeanEhS1jPrfJ8B2cGNSQqEfQz4+q2aSJSQgK2X MoH3uoAwIVmZAPibz+adf8mHxLGBH93CuZNX8Kj+A3g1qSuzFiS3ZpDTgwnIWtSd mjZVci8wo6wN7tDf84a9OI9oZxLkiUU1czIKA8t/cyA2CTBGa1CJr6SjTs+yEWrW QF7U3SypNayPg3NoZ2XDAUkXzSRUvcnX3KIC6X0e0Jcmxv+22rgYYpHNKdW+S+WN 6zoEUs+4+j/oc1T5/p1HWugjVP//Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeehgdduhedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqne cuggftrfgrthhtvghrnhepkeeliedtvdfgudeugfffvdejvdfghffhuedvjeelgefggedu tdeivdehueevheefnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsthhpvghtvghrsehsthhp vghtvghrrdhimh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Dec 2021 16:34:01 -0500 (EST) Message-ID: <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> Date: Tue, 7 Dec 2021 14:33:57 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Martin Thomson , John C Klensin , Eliot Lear Cc: rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> From: Peter Saint-Andre In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 21:34:24 -0000 Thanks, Martin. After we merge in the open pull requests, I'll take a closer look at the document organization. On 12/6/21 11:28 PM, Martin Thomson wrote: > Hi John, > > Thanks for this input; the changes do seem small and constructive. > > I've taken those suggestions from you and those from Adam's response - all of those seem reasonable to me - and made suggestions against Peter's text. I think that the only things we might be missing is the connection between the two sets of changes Peter has shared (where the "wider review" piece moved from this section to the other) and your point about the "archival" topic. > > Personally, I'm happy to accept any of the changes as proposed. I will defer to Peter on the document organization piece. As for the the "archival" topic, my view is that we've captured the points on which we will agree to already, so I'd prefer to leave that matter undisturbed. > > On Tue, Dec 7, 2021, at 15:22, John C Klensin wrote: >> Peter, Martin, >> >> Some (I hope small) suggestions / changes: >> >> >> >> --On Monday, December 6, 2021 16:46 -0700 Peter Saint-Andre >> wrote: >> >>> Martin's text is now in a pull request: >>> >>> https://github.com/intarchboard/program-rfced-future/pull/140 >> >> ------ >> >> Current: >> proposals that might have a detrimental effect >> >> Comment: >> "detrimental" would be appropriate if we were talking about >> principles, but I gather that is what people are trying to avoid >> ("principles" would still be my personal preference). In this >> context, it implies a judgment call by the RSAG, with no >> guidance other than whatever they are thinking at the moment as >> to whether a particular change meets that bar and hence should >> get the more extensive review. Example, deliberately chosen as >> probably the least likely of the list to become an issue or >> generate a proposed change. Suppose the RSWG/RSAG concluded >> that the Series would be considerably improved with more intense >> technical editing and that the only way to get there would be to >> charge a fee for at least some of the documents in the series. >> If the goal were to improve quality, nothing "detrimental" >> there. But we'd certainly want very wide and careful review. >> >> ----- >> >> Current: >> "heightened scrutiny" (and the new calls for comment, etc., >> text) >> >> Comment: >> I actually like this term as an alternate to "enhanced >> review" or similar phrases. But my intent, as discussed during >> the call and in earlier messages, was an expanded review, not >> just extra care in the discussions among the usual group of RSWG >> participants and RSAB members. The current text seems to imply >> the latter. What I, at least, was after was additional outreach >> to, e.g., the academic research and historical communities of >> readers and to those who use RFCs in procurement and/or >> regulatory specifications. I continue to believe that we do not >> need to specify how that outreach is done or to spend energy on >> what to do if it fails to produce any input. But I do expect >> the RSAG to make a good-faith effort, using the best advice they >> can get, to get reviews and input from people in those >> communities that are unlikely to be well-represented in the RSWG >> and unlikely to follow the mailing lists or social media venues >> called out in the current text and to pay careful attention to >> what they have to say. >> >> That seems to have been entirely lost from the current >> formulation, I hope not intentionally. >> >> ----- >> >> Current: >> more than 35 years, >> >> Comment: >> RFC 8700 says "50" and that was two years ago. Those who >> are especially concerned about privacy might also want it noted >> that, for most of that period, no identification of the person >> obtaining the document has been necessary. >> >> Also, under "Accessibility", "Availability", "Longevity", >> or some other topic, we have paid careful attention to the issue >> of making documents available without the need to use software >> to interpret documents that might fall out of use or require >> unusual tools or processing in the future. That has been >> mentioned, in different forms, several times on the list, only >> sometimes as part of the "archival" topic. >> >> ----- >> >> Current: >> licensed to explicitly permit translation >> >> Comment: >> I'll defer to others on this if they have better information, >> but my impression is that, at least for the first 30 or so years >> of the series, translations were explicitly permitted without >> any requirement for specific licensing. The above, in context, >> seems to imply that licenses are required and, at least unless >> they are guaranteed or blanket licenses exist, that would >> contradict the history we are trying to record. That is >> important in part because, unlike other SDOs, we have never >> tried to have, or designated, official translators or >> translations, much less guaranteed their accuracy. Any moves in >> those directions would also be inconsistent with the history. >> >> ----- >> >> Current: >> to Internet standards, the RFC series has >> >> Comment: >> Historically, we should not lose track of the facts that it >> was many years before the term "standard" was used for RFCs. >> Among the earliest documents identified as "standard for the >> Internet community" were documents that we would identify as >> procedural, rather than standard track, today. And this goes to >> the historical observation that the RFC Series predates the IETF >> and that the IETF came into being without the notion of >> "standards body". >> >> Suggestion: >> Can we just drop that bit, which implies that Internet >> standards (also a term of art, especially if "Standards" is used >> rather than "standards", that means something rather different. >> We should also try to avoid statements that get tangled up with >> "who is the publisher of the series". Instead, try, e.g., >> >> "The RFC series has included many types of documents >> including standards for the Internet, procedural and >> informational documents, thought experiments, >> speculative ideas, research papers, histories, humor, >> and even eulogies." >> >> ----- >> >> Current: >> easily legible to humans >> >> Comment: >> And least where I come from "legible" means that the text >> is not presented in a form that people have trouble reading, >> e.g., my handwriting or a highly decorated, neo-calligraphic, >> type style. I think something more like "accessible and usable" >> is intended. See above. >> >> ----- >> >> best, >> john From nobody Tue Dec 7 14:08:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE083A0E75 for ; Tue, 7 Dec 2021 14:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=GCpUx4k/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KGNoZ8pN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QVOmAkdzE3vB for ; Tue, 7 Dec 2021 14:08:02 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2AA53A0639 for ; Tue, 7 Dec 2021 14:08:02 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id D7C253201F90; Tue, 7 Dec 2021 17:08:01 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 07 Dec 2021 17:08:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=w ZMcKyoWfOXK34gVkO7rdznLCnFCpN2BZFUCykQdL4Y=; b=GCpUx4k/aETIFfRKt eE/xASMwBdX6ItyIF7yyayG+cwnaWzPDybOgmIUkdw2S5K0cAQPy7qaVMg667p8k GWb7bqkyOAo9imkXasEUS/Su0A99F2omzRZYo/UI0epwnIO2Nbv24Jxwe8tbIsdx GffZ6pIsVx3NNB10Rkb6rmWksloxf4ai2iAe/xIGocFx713XyJDbT2F2M57gOCmz /+5C4GJ8nWJXZAsOSd6S1ZYaMJq6JHntSU33f+ETiJDxafpgwmhfDhfvtVjtMIjH D+60hHYt+/rIcWLuqpv2grQATSx/aw8rMv14G1DFM2n5k/Os/ezDr2m9z2PVPly+ yyzgA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=wZMcKyoWfOXK34gVkO7rdznLCnFCpN2BZFUCykQdL 4Y=; b=KGNoZ8pNDv+evxmRnKkf+rB2s2zs2SCsj/sYLIfmukpjYs6x0IwcTFmXm FjYMIrJ/LAZInw1qPVjqCgbHqE0r3p4zbMFJmwYmF9IphzHlQES6LbSfDof4Sm+F ccYdbtfXG8ke4aC8044DrpkQJ8WrV20Rst8+qG3y2tA3ocXZsK3HT3o9tuj2kObc x3S7Zl8gdz5kOMzutjQLcv31P01Bm4ytUYq5S6Ud98np8wglyb/pC7ZTT6VAQsBW JIYUoSCcV8E2OQQPhR9lcIxXtbMfhV078Bvh1fjCUO++n29YmrJoycrb26gvc4xt HjcGmMtVP6+/NRe2yZY/ZHGn/g7ug== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeehgdduheekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomheprfgvthgv rhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqne cuggftrfgrthhtvghrnhepheethfdvjedvhfegteeghfefuedufeektedvhfekleelueeh feelkeekkeeiffdunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Dec 2021 17:08:00 -0500 (EST) Message-ID: Date: Tue, 7 Dec 2021 15:08:00 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , "rfced-future@iab.org" References: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> From: Peter Saint-Andre In-Reply-To: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] next steps X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 22:08:07 -0000 On 12/7/21 7:42 AM, Eliot Lear wrote: > Barring lots more comments, I am asking Peter to get a new version out > around the end of the week. Because of personal commitments, it's more likely that I'll submit version -07 on Monday. Peter From nobody Tue Dec 7 14:46:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C75F33A1981 for ; Tue, 7 Dec 2021 14:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ughQxOeM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ph+j9IAV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YfjrW7lJjEVB for ; Tue, 7 Dec 2021 14:46:31 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B46ED3A09BE for ; Tue, 7 Dec 2021 14:46:31 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id B12D33201C29 for ; Tue, 7 Dec 2021 17:46:26 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 07 Dec 2021 17:46:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=/hpGbX8wl2fV5UUDK8wa6E3cWhRKciT WB+9kgRZzgDU=; b=ughQxOeMR0RDcbPkGgthKutpsrBhgCUl5144/CEdbuQXN9b NpMWS0qfivwt6o+aYjOukytVRJX3uA1MdygsHOZ7jdLybSd4qR/ockz2pdBgT/Hx lyNNNi51jbOfKDr4qgQqzoLrX64frKH98QtlrIDw3KhRDA/sTMhnIlXa7l5a2eO/ R5c4AHPGF/tXL1Q4lafdbYdyEUu6SI8plJ9EfLJDNzgYuwtmJPEldLop1r+NQyK7 RewriW3c4dKM6/C1DiJqz4+Gmg5g//d9rrxP2JOAqhjUUpXCphOcLb5RAu3ltv3K My7XjLB8S+JeCYkrXqix9MLpso6rARkzYmcJI8g== 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=fm1; bh=/hpGbX 8wl2fV5UUDK8wa6E3cWhRKciTWB+9kgRZzgDU=; b=Ph+j9IAVrVFRZq68AH7wVs hsJRm4anGh0khGE8VU5NHFRa0wyJAY7xDpZsBld1SZfv6EJgI9OQ0vz+KjinNNIJ Wn4HZA7jHT/KvOOW+sqLE//I5VsQwTnh39U999/Kktbcw/KTjqPxD42LbtK8WzcM 6zR+9KszcYK8Gs2E3zOZ6boKodz2ccCFegQwTnIuCeWDxoY8OaeVQgMM8fw0i1dF XUsuTCYIKm7tOHeNYtHNq2sGqvOek1zbbLpt1hg+51Tv31TNRMgv+BUhoXuxYLFf AVO/wwm4qTvs4qn7UYOTexaFQ2eoQ1wj4CUJias2tJgffrfQfwEN3FjHpKzcOSQw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeeigddtudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepueeifefhkefhhfduudegvd evleelheeikeffffejiedvffevkeefhefhtefhgfdunecuffhomhgrihhnpehgihhthhhu sgdrtghomhdpihgrsgdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmh epmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E29B63C04A3; Tue, 7 Dec 2021 17:46:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4492-g121c2470aa-fm-20211206.001-g121c2470 Mime-Version: 1.0 Message-Id: In-Reply-To: <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> Date: Wed, 08 Dec 2021 09:46:05 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 22:46:37 -0000 I took another look and have some tiny suggestions, informed by the discussion: On accessible and usable vs. legible, another word choice: - accessible and usable to humans for decades or longer. + comprehensible to humans for decades or longer. On translation, I don't think that we need this: - The IETF Trust and the RFC Editor place no restrictions on this. Joel's text mentioned redistribution, which might be worth considering: - with no fee for access. + with no constraints on access or (re)distribution. All of these are offered as suggestions on the pull request, to be taken or left as you see fit. On Wed, Dec 8, 2021, at 08:33, Peter Saint-Andre wrote: > Thanks, Martin. After we merge in the open pull requests, I'll take a > closer look at the document organization. > > On 12/6/21 11:28 PM, Martin Thomson wrote: >> Hi John, >> >> Thanks for this input; the changes do seem small and constructive. >> >> I've taken those suggestions from you and those from Adam's response - all of those seem reasonable to me - and made suggestions against Peter's text. I think that the only things we might be missing is the connection between the two sets of changes Peter has shared (where the "wider review" piece moved from this section to the other) and your point about the "archival" topic. >> >> Personally, I'm happy to accept any of the changes as proposed. I will defer to Peter on the document organization piece. As for the the "archival" topic, my view is that we've captured the points on which we will agree to already, so I'd prefer to leave that matter undisturbed. >> >> On Tue, Dec 7, 2021, at 15:22, John C Klensin wrote: >>> Peter, Martin, >>> >>> Some (I hope small) suggestions / changes: >>> >>> >>> >>> --On Monday, December 6, 2021 16:46 -0700 Peter Saint-Andre >>> wrote: >>> >>>> Martin's text is now in a pull request: >>>> >>>> https://github.com/intarchboard/program-rfced-future/pull/140 >>> >>> ------ >>> >>> Current: >>> proposals that might have a detrimental effect >>> >>> Comment: >>> "detrimental" would be appropriate if we were talking about >>> principles, but I gather that is what people are trying to avoid >>> ("principles" would still be my personal preference). In this >>> context, it implies a judgment call by the RSAG, with no >>> guidance other than whatever they are thinking at the moment as >>> to whether a particular change meets that bar and hence should >>> get the more extensive review. Example, deliberately chosen as >>> probably the least likely of the list to become an issue or >>> generate a proposed change. Suppose the RSWG/RSAG concluded >>> that the Series would be considerably improved with more intense >>> technical editing and that the only way to get there would be to >>> charge a fee for at least some of the documents in the series. >>> If the goal were to improve quality, nothing "detrimental" >>> there. But we'd certainly want very wide and careful review. >>> >>> ----- >>> >>> Current: >>> "heightened scrutiny" (and the new calls for comment, etc., >>> text) >>> >>> Comment: >>> I actually like this term as an alternate to "enhanced >>> review" or similar phrases. But my intent, as discussed during >>> the call and in earlier messages, was an expanded review, not >>> just extra care in the discussions among the usual group of RSWG >>> participants and RSAB members. The current text seems to imply >>> the latter. What I, at least, was after was additional outreach >>> to, e.g., the academic research and historical communities of >>> readers and to those who use RFCs in procurement and/or >>> regulatory specifications. I continue to believe that we do not >>> need to specify how that outreach is done or to spend energy on >>> what to do if it fails to produce any input. But I do expect >>> the RSAG to make a good-faith effort, using the best advice they >>> can get, to get reviews and input from people in those >>> communities that are unlikely to be well-represented in the RSWG >>> and unlikely to follow the mailing lists or social media venues >>> called out in the current text and to pay careful attention to >>> what they have to say. >>> >>> That seems to have been entirely lost from the current >>> formulation, I hope not intentionally. >>> >>> ----- >>> >>> Current: >>> more than 35 years, >>> >>> Comment: >>> RFC 8700 says "50" and that was two years ago. Those who >>> are especially concerned about privacy might also want it noted >>> that, for most of that period, no identification of the person >>> obtaining the document has been necessary. >>> >>> Also, under "Accessibility", "Availability", "Longevity", >>> or some other topic, we have paid careful attention to the issue >>> of making documents available without the need to use software >>> to interpret documents that might fall out of use or require >>> unusual tools or processing in the future. That has been >>> mentioned, in different forms, several times on the list, only >>> sometimes as part of the "archival" topic. >>> >>> ----- >>> >>> Current: >>> licensed to explicitly permit translation >>> >>> Comment: >>> I'll defer to others on this if they have better information, >>> but my impression is that, at least for the first 30 or so years >>> of the series, translations were explicitly permitted without >>> any requirement for specific licensing. The above, in context, >>> seems to imply that licenses are required and, at least unless >>> they are guaranteed or blanket licenses exist, that would >>> contradict the history we are trying to record. That is >>> important in part because, unlike other SDOs, we have never >>> tried to have, or designated, official translators or >>> translations, much less guaranteed their accuracy. Any moves in >>> those directions would also be inconsistent with the history. >>> >>> ----- >>> >>> Current: >>> to Internet standards, the RFC series has >>> >>> Comment: >>> Historically, we should not lose track of the facts that it >>> was many years before the term "standard" was used for RFCs. >>> Among the earliest documents identified as "standard for the >>> Internet community" were documents that we would identify as >>> procedural, rather than standard track, today. And this goes to >>> the historical observation that the RFC Series predates the IETF >>> and that the IETF came into being without the notion of >>> "standards body". >>> >>> Suggestion: >>> Can we just drop that bit, which implies that Internet >>> standards (also a term of art, especially if "Standards" is used >>> rather than "standards", that means something rather different. >>> We should also try to avoid statements that get tangled up with >>> "who is the publisher of the series". Instead, try, e.g., >>> >>> "The RFC series has included many types of documents >>> including standards for the Internet, procedural and >>> informational documents, thought experiments, >>> speculative ideas, research papers, histories, humor, >>> and even eulogies." >>> >>> ----- >>> >>> Current: >>> easily legible to humans >>> >>> Comment: >>> And least where I come from "legible" means that the text >>> is not presented in a form that people have trouble reading, >>> e.g., my handwriting or a highly decorated, neo-calligraphic, >>> type style. I think something more like "accessible and usable" >>> is intended. See above. >>> >>> ----- >>> >>> best, >>> john > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Dec 7 14:58:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CDB3A1993 for ; Tue, 7 Dec 2021 14:58:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.851 X-Spam-Level: X-Spam-Status: No, score=-3.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, 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=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 g_fZXeMppuhr for ; Tue, 7 Dec 2021 14:58:19 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-ve1eur03on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe09::716]) (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 B38863A1991 for ; Tue, 7 Dec 2021 14:58:18 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JyC+5UspCgREvRDLr8hb7CL0393vMVhwka3BBh6JnmmOfHo65vVgXsMcYztMN+j+7vcItbAGuQmqVOrZNAjFYSms3ZxDFjp+0VSzeH6oCWZfN/8ctK8bEc3fn19PCouc6Rg3ggqFk8drKieNqrNxFBtRKbV1wYa7atFsq0cjtYYChkOYJJaRbmj8EekVyq8BAeNp4j84sM8DcI4gkZ8Yvl1L8Q4pbidlU7PW8lph/L//91IXud0hPcqPlXld7Rh68ZDBBJPjJQi7PRoSLOdSC6qiCKK92owN1xb6fO+TAtTAvdP5DzMk5ibY7qWR7f1hvlFZX25zKP5x0ny6oLCjAw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=y3LtZ525b1EI1f97PvGJQs+ULrJrPWOuuj0lzeMnpEY=; b=RavqcdRPu8rsUYcQu0abFHK+jo6JBESZqDBUEcohDgNcBXltG51ib40aaItxTacTGBFgo3wSuSmGD/InPy7GEwtZV1t2SPep6aJcGZk7MaKblrWqVZ04WjjEmWEJeEDNZGY3ChwiMBzjWgwqvJ29coaBVHCJI2j8eTZ050dL5ohYj3hAXFwZcjDJzFR/crUl9HI8VZluP512DylZ9QzUyKhCM3/JOze0PT/xK87CChfwtin9FVnozk7Vg4YQzyrp7NWfuFwZHXS9y+iQngDfoKAmab4CktCgCwdMFmNJgd6+pxqYbhKIA5CcHE3BK5DQQZ/BxucxZNZ6+DplXzgA8Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y3LtZ525b1EI1f97PvGJQs+ULrJrPWOuuj0lzeMnpEY=; b=RubokG4Nzo9kjtGQE62WHyAYQn4P+pvCyv5ZiqwstJRDJIA7Xk9Ecz8OiDXLuBBd9Hc/+3U14Qeatmy4qWckg93JGZtf7UXdIQ6VhjYcDPMY7jiqdvkLjpDOUssW1t9xTjqwvdrFxV29LsBTCHfOl57PllKZRMvfZstjRmlp7KjJrdqmSggM497P15bWMbfkMs4XFRhOHVTo62wSJQC/3+IKN6UmzW8Q2b0RjeRr2iztnt5WjnuT7OscBU7zksgndZnwH/xY5BoKM7H6tZFZTNg2QhS8ceD4uoS0Y0c6q9SUBIgwgm8uWny7jXrSzxkm0OH5Z+SLxpdlIh/zUMdwhA== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB9PR02MB6635.eurprd02.prod.outlook.com (2603:10a6:10:1fa::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.22; Tue, 7 Dec 2021 22:58:11 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea%4]) with mapi id 15.20.4755.022; Tue, 7 Dec 2021 22:58:11 +0000 Message-ID: <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> Date: Tue, 7 Dec 2021 22:58:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Martin Thomson , rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> From: Stephen Farrell In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------lhUfMMmDw5Q6Rh7Xpm3XHsCQ" X-ClientProxiedBy: DU2PR04CA0184.eurprd04.prod.outlook.com (2603:10a6:10:28d::9) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.244.2.119] (95.45.153.252) by DU2PR04CA0184.eurprd04.prod.outlook.com (2603:10a6:10:28d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.16 via Frontend Transport; Tue, 7 Dec 2021 22:58:10 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9e8006a2-cc05-4491-2901-08d9b9d50a86 X-MS-TrafficTypeDiagnostic: DB9PR02MB6635:EE_ X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:605; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: lsFl1RnGEInYyUlPLkygFVUIli5eOjMzeMSIcb55e8xPOXM1PUmQRuIu6GUe1p66wBRtolpx+BzN4GcxRsRTbWDgKowlV9z9btIF3jgmxdYDZ82FaWbqrAevFX3fvpW94B78gHRetvjO6HQlUPwJ9kTuiJjzv4mHlpM5OjtSi8XGMENI1gpFJsFVRuHuhPYMF3afCFpEvdyyFBTqyT/k5fmX6d/hbhs4QUFMymFAHBzHpi4UTi99zItkeOkxZQ+t6A+cow+oeLqhuAs8fYS6okgnpRmWZak4S7HRnyk/fJYSzug3ojf1qIG+Zyh5VSVuc5UfeXcWRJkfrFWvmc13DftJkfv3Mjh5ljE9XYmQpoYh3D9Ub7rNpqd/0pqpAbOcDMUbx3ZPYIpxYjJP1Ybgk1XNZyILkAef7bBtpDd4bG0Kg7V04F702xMYojIOvcVKGiWMrOtZjLHxrWVGnipMIC1Q4Jl4DM7wjZmE+pm/7N5YTj+oSjklRu6mXYf+6IPQM98xSNNwkrVxPIljdd3MIcmtLcV2TTxyMd96vl3RQ651FARLCGXyV4ll408f2UTlffyS0rJVEU8w31+clK3e9R8Cez5TmNs1DutKhNSkZfEcclT6IFh7CnhZkTGrn8DvUbkq2L4pBTt4kufNwMClqROIS1gR7OCUcMbnybYDQbla1ONoeInqniw4QgpdDWKq2kCXfOAVeDlzcVQI6uHne9mDgUUI98RdL7M3DrPqn24ro7tLW2jsdL6qiWpX6xgy X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(235185007)(186003)(786003)(6486002)(26005)(956004)(508600001)(8936002)(5660300002)(2616005)(21480400003)(83380400001)(38100700002)(31696002)(53546011)(2906002)(31686004)(8676002)(66946007)(564344004)(66556008)(36756003)(66476007)(86362001)(316002)(44832011)(33964004)(16576012)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?Vmo4SEh5UU9vNnB6NUhjdkNlMmJmbm9iS2ZVQUVwQXJPM2pKbFZONExna1Js?= =?utf-8?B?NHN0V1U3M3dDOUJTaHhsd3JuVkxhRFBDS1ZINWYyVnN6ekVSSCtjVUtaTkoz?= =?utf-8?B?WjcxYlNvTjUwN0dIZ3YyOG9tRDBGc3VlcGN1V2hBYTlac0JOQlZhaUdKZDlQ?= =?utf-8?B?OS83SS8rWFJJem5KUWFZaXVXNWVic0lRMUpGaFZFUDdpUkIrM0JoWFhlSEo1?= =?utf-8?B?ZTBnQUlUcWlWZU9IeXUyT2xvRUduZjFKYm45dWJZMU1DYW56VitkL1JQeUpw?= =?utf-8?B?TSt2cGdoWkNDOTZlREN1TXBRZzNVREorUjNkWE1GeWY1WFpZaUt1eTRVQVNF?= =?utf-8?B?b3pXcFFIWXp6ekdNdnRwZ2cvU3hyNm5FUlIyNFNTS21aNG1hN1NOalZQOUM0?= =?utf-8?B?T3VldW1OWW9IVzRrQy8xMkFzZERxVkxLK1BQZWx6NmFDdVU3bDh6b0MrM3Z1?= =?utf-8?B?Um5lU1dTQ2p3TzlDRElETVIvQnlzWTQzUkNuWis2SnlVK05wbnRNVU54Qngr?= =?utf-8?B?aENYMTl2S0QwczM4TVA0eDd4VGVKQ0JVcWxsa2RGQVU3WkhoRmNFYVV4SDJj?= =?utf-8?B?Y1lsN2pUZUV5UWFjVU9xbUhhUjlQTGVJMkZFZUZ2em9uc3RDRUNQVGhMMHJC?= =?utf-8?B?dmdZRm5ZMzVzeWY2RXZDQ3dWYll2VnNOa29HdFVVYXlzY2JnT0lGdkhsMno4?= =?utf-8?B?VnM3eklnemV2bjM5Qng1dEhnbU9YYWU1aVQ5eFNsYi9HMExqeUVFRlpWc29S?= =?utf-8?B?ZWU0Z3BIVXcwRWhRaytPSHg5dzdrelBrUUtDWVBLUU1telFUUmc2SWF4aTBX?= =?utf-8?B?UzhCWUtLQVpvVWRWRXNCNytQTkpqcmJCemQ5Rzd0ejY1VnNhcjdzeWNmRHYv?= =?utf-8?B?MVpxWXpaL1l5Z3VTYTZHS0pYbks3cFlGQkV4OHJLNCtidjBRall4STFZUTJF?= =?utf-8?B?QkZqUkE1M3F4WTVFSDkzRW45UWl0MVc4dWlTWFllWkZmbytuQzJYUTB4MU9S?= =?utf-8?B?MDFhOFJISTRUT3hpZDZSR3Jta1FGZ0RES3ZIRGExbzcwS0x1VWJBS2t2MXVZ?= =?utf-8?B?UlR1QXZOV2UwRnFFQUVScUlPekljZnZyZUdYSTNxTGpEM0N6dzJIejN1WTAy?= =?utf-8?B?UHk0SjA1ZTBBSFd3RmhaeGxkWC9JYldra3JjMVcveFNaWnQ1SHlKRWZiVzhM?= =?utf-8?B?U2xNY3JnbVhOSDk4WHZkK0NzTVY2R1BGeFRRSm5ZWlY5NkFGYVNjdUNvcDZN?= =?utf-8?B?aCtHUkEwT3ZkOC93dlBkQ0o4cWxZK0VGMmthNDNHVy8xb1BWc1lzQVZmVFBI?= =?utf-8?B?OVQvWVYvaERrSGZHNjdVVWNLd1lpV3BwaDBMQjh4cjcrLzNQcUF6L29qNitx?= =?utf-8?B?cG1PdSttUG9aOENjVGMrTlFyaFVlYW1zbU5henFtZHFjMnpsNW9BSFBnb2ln?= =?utf-8?B?NFRXczNhS1hqTmtMcjRWQTBTbnpVRGVDYnM3aUNaODdtL0VVZkMxRkR1dDhp?= =?utf-8?B?bkZDR21EaGNtamU3Y1cxSEZmNWN6cHhkN2NFeEYzQ2p6WlhCTXo1cHlvWWp6?= =?utf-8?B?c0FkV2pMQm82V3BiMlBvRUVqYjd3SlltNnFFbld1SkNVM3BHdDUrMVFWR3c5?= =?utf-8?B?cHJsdDAzQUdrY0NwdjdOMTZxM0ZUaTZoV0FDUWZGSHZUSnVFd09HZ1puSld3?= =?utf-8?B?UTRmbG95YVdjalhJOWRGUDVkSk1sVFZCZVZPSHZhR0Q4Um9aa25iOG0xYjlL?= =?utf-8?B?SGxIMnZJL2NXN2JLRlJyRmoybGpHcDZIa3dCdDh0NWFxMEpNUGdTQ1BEQ0NI?= =?utf-8?B?Y0x5cEc4enoyY0JQMitRcW5lQldRTlVWdlpHM3MxUzFRMUhUSG82bklYbDZo?= =?utf-8?B?ZXIzYUE5WHEzejlpenkzWlg2ajVhcUU3NzJuM1dxL1V2T2ZGVnRRbVZMNlA3?= =?utf-8?B?ZE13NExnakF4ZHM2RkhwTXRQM3FJK2gvTVhuZWQzNE9WaGFob3E2RXVJYlk2?= =?utf-8?B?cldYR05oVnNCNkMrNDlJZDF1aDZVZDhUMnRLSHZvd0dJaEZ1MysvRUJOZFBz?= =?utf-8?B?MWJhU1R3eEM2TlZ1MTUxYW9RRUlSOUh3dk15dHR3Y0hzOU9LNkJtRHFya0xu?= =?utf-8?Q?2Fwk=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: 9e8006a2-cc05-4491-2901-08d9b9d50a86 X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Dec 2021 22:58:11.0739 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: 4ZZ2iJLVkb+8rFklgaXE6DG3gYtwTtkPj4qdDot/VT+qfREVPO7G6PI4C9Hq1wcH X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB9PR02MB6635 Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 22:58:26 -0000 --------------lhUfMMmDw5Q6Rh7Xpm3XHsCQ Content-Type: multipart/mixed; boundary="------------5tji8wWBBVnP4Z0lggAn4VUt"; protected-headers="v1" From: Stephen Farrell To: Martin Thomson , rfced-future@iab.org Message-ID: <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> Subject: Re: [Rfced-future] Proposed "Historical Properties" References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> In-Reply-To: --------------5tji8wWBBVnP4Z0lggAn4VUt Content-Type: multipart/mixed; boundary="------------MKIqukCZN3oRS2hf7uJiWEFd" --------------MKIqukCZN3oRS2hf7uJiWEFd Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQoNCk9uIDA3LzEyLzIwMjEgMjI6NDYsIE1hcnRpbiBUaG9tc29uIHdyb3RlOg0KPiArIGNv bXByZWhlbnNpYmxlIHRvIGh1bWFucyBmb3IgZGVjYWRlcyBvciBsb25nZXIuDQoNCmhlaDot KSBJIHRob3VnaHQgb2YgdGhhdCBvbmUgdG9vIChhbmQgaXQgY291bGQgYmUgb2spDQpidXQg dGhlbiBJIGNvbnNpZGVyIHdoZXRoZXIgb3Igbm90IEkgY29tcHJlaGVuZCBORlN2NC4uLg0K DQpDaGVlcnMsDQpTLg0K --------------MKIqukCZN3oRS2hf7uJiWEFd Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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 zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 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+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC 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 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK 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+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb 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 Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R 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/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK 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+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB 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 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+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 =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------MKIqukCZN3oRS2hf7uJiWEFd-- --------------5tji8wWBBVnP4Z0lggAn4VUt-- --------------lhUfMMmDw5Q6Rh7Xpm3XHsCQ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmGv5wEFAwAAAAAACgkQWrL68XsXK+qg TQ/8D+h16BZARecRGkVakhjPo00px3dINdzpbvUXlqpNr6bTtoY0Ag/w14nUh8chy2oHOk4jZbMX Tl2RGOgsTXUgo3TQPyuEIsDSY1VWRd62s1od0WjuOlBnmhe1+IBSPsTu09g07Up/+6hConYpZLkn iFTQcbvORNXKaeIPN5pjX0JYAjNul3jbJ73ht+aSin/n5IGAcOYLAkGnDDHWpuviASijPhu147i0 xwvOa6VscimO/7bQ1MvhJ7W36H/7m4rp9SMYXAWeszhz1CAWchuJf7oU0jxd1cvIr/bOSl1lmiWa D8mgVluBdJCdQpqQSktmyG7PLNq0TAOj5LjKRjM5P5h0SmKvlQuXm3/KifrztaADU1G41j9YGkIQ fWr+VpKtcYGfG8xFg6Kyeh22x+arsfi0/4PGRI3lrZ9Y5e0dI76vbmH73PP0UDcd1EZv/bd2yFzh JOE3DdtBbv+eUGiTEmmjWID/RHnlKqqZcz2ZRFGZ0fZF83fxiUR4G1p66FZmV81gBlcNoCmU/xqH dtpMcvywo7o6QdcDEPHik97d2sr9VgqAe2pLKIoRACLSll7MKNqMwc1fv7cAWw6nnLK7gf9rLp+3 WUj3UKKWMuGUVT7qCpqIJaIea6Ci4f7PFWtkgUlcXHwUC9iAjLmIdNne2P3aJmhlsMxk3N1Ix87b vJ0= =cTTU -----END PGP SIGNATURE----- --------------lhUfMMmDw5Q6Rh7Xpm3XHsCQ-- From nobody Tue Dec 7 15:08:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFDA3A0AA1 for ; Tue, 7 Dec 2021 15:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=Iv1eU22i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fnEUzhkK Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lx-pgr34v_p9 for ; Tue, 7 Dec 2021 15:08:02 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 946DB3A060A for ; Tue, 7 Dec 2021 15:08:02 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 09DA53201C28 for ; Tue, 7 Dec 2021 18:08:01 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 07 Dec 2021 18:08:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=GBLqNDFiD0hKohkfbMD+bSXbna84Na1 M8dVHQnfiwgk=; b=Iv1eU22iEpndSrV4iwduiqccU6Qdxex/klJj05W5Qog+WSZ Ax0XTMHKBb20Lxt3HY6HOYAEKSngvCjYTHWeWH1PeqJLktPhED5KCIsGdFlWiXvu 16zloeW/UkqG+LfRO1ISxKvKLdjXiZEo/mQfaTvMFkKu5yQvFsT5ARDpRwV90aOK MsY7hovg3N4hFaqi2QOZ8KTw2PYv/UHOHLSVRCmT23BaNNP750gsSNKXLIc8wPZC 9ulWlfX4QWxIWicWE4/PxKRPARE8o9F7sCdPbsuflUvr+aAefTl7p47IRSGOAXDt kYyduOAbrLMm79UMYXJn8g+qbnbmya2CyGZB9JA== 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=fm1; bh=GBLqND FiD0hKohkfbMD+bSXbna84Na1M8dVHQnfiwgk=; b=fnEUzhkKJeZQFQMtkAj3i/ T62sO4xROV/frmqSPLYtqsO4WBWz1OC/dx1iHPHPIP3cJcv3dWG8NC0CSBrUDMJo uY8m5P07OTX1lrdJK7VMy2Y1thleZ8QJINRqrO3sgI/YVJdq6bvrvH4dGjjZGn0b FoqgRByHDJA5IVg3um5Bw2utuvc1pzKKiATWyvQRMzPSohyy9aN7xiNM/6/KTD9s qNEuCd8maf1qDfbdHAa0/uXowvUAYPv46V/TVLr5rpNSD+3ZMFkcHA0Dx5fh8xvJ CTeT61F/JG2qtfLULo1ghmsdJovhGoCRjkJRSOfRgjdyDwA/lyzFDlHisu35Le4w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeeigddthecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfeekve fhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 467433C04A3; Tue, 7 Dec 2021 18:08:01 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4492-g121c2470aa-fm-20211206.001-g121c2470 Mime-Version: 1.0 Message-Id: <8032f77f-5ecf-427a-b9b3-f8a47f933700@www.fastmail.com> In-Reply-To: <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> Date: Wed, 08 Dec 2021 10:07:43 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 23:08:08 -0000 On Wed, Dec 8, 2021, at 09:58, Stephen Farrell wrote: > On 07/12/2021 22:46, Martin Thomson wrote: >> + comprehensible to humans for decades or longer. > > heh:-) I thought of that one too (and it could be ok) > but then I consider whether or not I comprehend NFSv4... Strike "easily" then and I think we're good. From nobody Tue Dec 7 15:28:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB8473A0039 for ; Tue, 7 Dec 2021 15:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=T0MEsI47; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d6uTt/es Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEXj4jTbbbeo for ; Tue, 7 Dec 2021 15:28:08 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28B893A0038 for ; Tue, 7 Dec 2021 15:28:08 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 4AE5C3201C3C; Tue, 7 Dec 2021 18:28:07 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Tue, 07 Dec 2021 18:28:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=w xFIhRdDzfJ36kC2Vg97TdLoXbK7ufZdZdvHK3WaEOM=; b=T0MEsI47AVWL27d4m NO9RKD7Nir2zzCv2EhqkOjbRKz3M31eDDS1hv7yNo7uIhO3wsf42rsfDi96uPYJj kB21qv6NoujCNgLq6X9/im9ZoOsFhW7/nAvBi0j3jkWsEPfao/myFTN3xoEiL91r 6Ye7D6RKccBuRMAtYv9y9DFu4sxYh2nhXmOqFEs46E8rz/xtOdVPU9tb9zdHujGP 1iUZMtbiaTnaHCf0cn0zlBUftPvu2fR1yB4ojLZZJeifSmj8QPIxFPYGyhaiGLJz zTU8Ml7ckSM0T0ufwdTLnil8iTDD9EM7YcWm4pg4uKxU51NVC9FtQq8VeIqjnazg 6VDog== 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=fm1; bh=wxFIhRdDzfJ36kC2Vg97TdLoXbK7ufZdZdvHK3WaE OM=; b=d6uTt/eseneTIcJRAcgZGaSsk2qCz/NeNEOOD8wh5FtKxYOjQ8wLTYtoI DDXy0dQ0yuV+U9gpdqOdOjcSPyNsXbKSjbwILfKQqcDx3iMD4DsmS6nd9DE1pTFe 3rarfzxzAPsIhW0PPFF32z+FNd13LWpPjxRear0yC4NZm6BL8Rkoa4zSjJG7984N Acs7zL/0V8NYd5b1EuW9QHTbGHBbrmkpIHml79yjgGqEd/mUcsvKQiMm/HFwkZwc YfDZwlsm2BnAijF5tfDH1d90U7KxGRuqxE029LQFcv3Z2pWGvPiN6OXK19n6ZA2k sgAeIU06/8oAR5Y1Oz8cp2GiTyiTQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrjeeigddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepvefffffhudetveevhfeuffeigedtuedtheffleetffeftddtgeegjeehieeuteet necuffhomhgrihhnpehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 7 Dec 2021 18:28:05 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Mark Nottingham In-Reply-To: <937D289CD1D4CC64E2A66C65@PSB> Date: Wed, 8 Dec 2021 10:28:02 +1100 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> References: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> <937D289CD1D4CC64E2A66C65@PSB> To: John C Klensin X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Rfced-future] next steps X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 Dec 2021 23:28:13 -0000 +1. It's important to look at the final state of the text as a whole -- = particularly since (AIUI) there isn't an equivalent of an IETF LC here. > On 8 Dec 2021, at 2:15 am, John C Klensin wrote: >=20 > I think it does/should but only with the understanding that > "only changes" is to be interpreted liberally. My concern is > that sometimes new text accidentally exposes issues in other > parts of the document and I would not want to have discussions > of those barred. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Dec 7 16:33:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA743A05DC for ; Tue, 7 Dec 2021 16:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ruLT4tToKlhj for ; Tue, 7 Dec 2021 16:33:52 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2963A05DF for ; Tue, 7 Dec 2021 16:33:50 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1muku0-000DuW-Ur; Tue, 07 Dec 2021 19:33:44 -0500 Date: Tue, 07 Dec 2021 19:33:38 -0500 From: John C Klensin To: Peter Saint-Andre , Martin Thomson , Eliot Lear cc: rfced-future@iab.org Message-ID: In-Reply-To: <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> 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] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:33:57 -0000 --On Tuesday, December 7, 2021 14:33 -0700 Peter Saint-Andre wrote: > Thanks, Martin. After we merge in the open pull requests, I'll > take a closer look at the document organization. Peter, thanks. Please pick up the suggestion that you just pick up the translation text Joel supplied from the official Trust statement and review the exchange between Stephen and myself about "legible". For the latter, as I said there and having raised the issue, I'm personally happy to trust your discretion about the term and maybe suggest that, if you leave it, you call the attention of the RPC to the term when the document goes over the wall and see what (if anything) they want to do on final editing. A bit more below. > On 12/6/21 11:28 PM, Martin Thomson wrote: >> Hi John, >> >> Thanks for this input; the changes do seem small and >> constructive. >> >> I've taken those suggestions from you and those from Adam's >> response - all of those seem reasonable to me - and made >> suggestions against Peter's text. I think that the only >> things we might be missing is the connection between the two >> sets of changes Peter has shared (where the "wider review" >> piece moved from this section to the other) and your point >> about the "archival" topic. Yes. However you organize things, the two seem to me closely enough connected that explicit explanatory cross-references are probably in order. >> Personally, I'm happy to accept any of the changes as >> proposed. I will defer to Peter on the document organization >> piece. As for the the "archival" topic, my view is that >> we've captured the points on which we will agree to already, >> so I'd prefer to leave that matter undisturbed. I will probably try to periodically and gently push on that, as well as on "expertise", but I do not see it as catastrophic if the final result is not much different from what we have today... at least as long as text does not creep in the deprecates the principle. Put differently, I'm ok with "archival" and little or no explanation or even a statement that it seems impossible to get a definition that is at once clear and comprehensive and that will get consensus. I would have serious problems with anything that implies that, because we cannot agree on a comprehensive definition, the term and whatever it might imply is meaningless and should therefore not be considered relevant. best, john From nobody Tue Dec 7 16:58:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7632A3A074B for ; Tue, 7 Dec 2021 16:58:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zaa9oVEp-bK4 for ; Tue, 7 Dec 2021 16:58:06 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F4293A06E7 for ; Tue, 7 Dec 2021 16:58:05 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mulHU-000DxG-Dw; Tue, 07 Dec 2021 19:58:00 -0500 Date: Tue, 07 Dec 2021 19:57:54 -0500 From: John C Klensin To: Stephen Farrell , Martin Thomson , rfced-future@iab.org Message-ID: <4BA70DE21D06AB0FB03F7101@PSB> In-Reply-To: <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:58:12 -0000 --On Tuesday, December 7, 2021 22:58 +0000 Stephen Farrell wrote: > On 07/12/2021 22:46, Martin Thomson wrote: >> + comprehensible to humans for decades or longer. > > heh:-) I thought of that one too (and it could be ok) > but then I consider whether or not I comprehend NFSv4... Yeah. "Comprehensible" implies that one can actually understand the text. One could say "readable": that does not necessarily imply comprehension but might not be much better. That not only interacts with Stephen's comprehension of NFSv4 and my ability to comprehend a detailed description of some encryption algorithm (I assume either of us could, but it would involve a level of work that we'd find hard to get sufficiently motivated about) but, adding in what I've learned from a recent (and unrelated) discussion about our standards for review of technical documents that are heavily dependent on information in other, earlier, ones for comprehension, maybe we cannot easily get much further. "Legible" at least implies the ability to physically read the characters without implying the ability to understand their meaning. If we were translating RFCs into the Chinese of many centuries ago and then chiseling the results into the proverbial stone tablets, they would be legible but comprehensible (or even readable) only to specialists. If we used the wrong sort of stone and left it exposed to the elements for long enough, the characters might not even be legible. This is, at least for me, a really interesting side-discussion because I'm now fascinated by what the right word might be (sadly, it is a bit tied up with one of the meanings of "archival") but maybe we need to resist it and, having raised the issue and probed it a bit, delegate the problem to Peter. best, john From nobody Tue Dec 7 17:28:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6BC63A07A7 for ; Tue, 7 Dec 2021 17:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.842 X-Spam-Level: X-Spam-Status: No, score=-3.842 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, 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 (2048-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 BLbRXnPi5g5s for ; Tue, 7 Dec 2021 17:28:18 -0800 (PST) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2124.outbound.protection.outlook.com [40.107.20.124]) (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 2BFFD3A07A4 for ; Tue, 7 Dec 2021 17:28:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aMSPIEYdvFh2/2q/t9Xk0stXuYI36diOATjmmT5SnYM647ZempKpaY0uwlQ1LqPT6kAKEMN/Dmjua/YA+850RiGuAnC1JKbGkpOggII8SGqRnD9KHr1uE4vdhx4I+25G8izPmZulBR76UtR7m52MNz1goSuB3i97T+3XEV8pdFOM/uYtmVEDFA1rVNPKlCYTJCOBO63vzN4qhM1W0SL6giWWwzJp1bHc2IX7RKATPUsyFmCb45xHTtv+rnWZF0EB93gdVuRKatd99XN2Lwq+acTvno+bJUjbPjp9EepMTZJTL60bHuWHqxRiiCXeiSId5onyNuXa3mkUpmUcBxwVpQ== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KxxhaTwQlt2QNeK6jLcKsxm2cjm3RXJYSSeLBpLNrCg=; b=kIJxmesarawqpkclh3G25bmPP/T/qJJpdkIYZGZJdCptJpM0Hwu3aV1L3nFc4SLgkHOz2KGytbGXWbdyN9d3auK4b7VJQ/1mdakda32b5ZC8VrCl31dKTFlK2Q+cy88c7fxTlmt8l7wfg1mmzf9knNzTQWjXdhg97u7+yNilFZeD3oYPeC8THyvjfG5wBx4nJGkPeCJ+0qiRiZsOAnPeDfx4Ok/VPS85dKHH5ypKFKl8zMv4RQqWaLQJST52qVDHoLyt4Lpu8d4tztN+xFBy8BjxRqGcpmLJJve+++goeFomDkgMee2HWzHp23o42CQyA7fsyAfSw5V9h6cArKMN8w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KxxhaTwQlt2QNeK6jLcKsxm2cjm3RXJYSSeLBpLNrCg=; b=SUiAU7TweCP69dd7Db8rRVN2lqyd2pmqRMAZOMoxjxUri5x67AwyFxIeqrtEWkLa1fFzPUo4KOdWMD+TBXS0P1+Tn4YGsPvA0/ItC0pbpU6HU79DulATUxFTo74BbEw4/4ItLIV2ijFnpNsaTKK4jCtlboLB7/3+Y6mb4IWuRdeKaIjSVCArv1hoTFvUdMzlh5CEO4DsooJrsPvLIhFTTvGsfppzpwWS+10kf3cF2LzDCsgCSE25aT0FoxWFU4+qZNkKzNjEQjS6034aHixlpk3OFZhNHmdDiYJNNyiRs/kig20UN8yMFn/j4xyeEC9t/tnKTjFljKJ5KkbE6cesMw== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from AM6PR02MB5112.eurprd02.prod.outlook.com (2603:10a6:20b:90::21) by AM6PR02MB4836.eurprd02.prod.outlook.com (2603:10a6:20b:5f::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.19; Wed, 8 Dec 2021 01:28:08 +0000 Received: from AM6PR02MB5112.eurprd02.prod.outlook.com ([fe80::ccdd:8682:b20b:a2d1]) by AM6PR02MB5112.eurprd02.prod.outlook.com ([fe80::ccdd:8682:b20b:a2d1%7]) with mapi id 15.20.4755.021; Wed, 8 Dec 2021 01:28:08 +0000 Message-ID: <82394d7e-59fe-7178-727e-9524f8fa05be@cs.tcd.ie> Date: Wed, 8 Dec 2021 01:28:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: John C Klensin , Martin Thomson , rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> <4BA70DE21D06AB0FB03F7101@PSB> From: Stephen Farrell In-Reply-To: <4BA70DE21D06AB0FB03F7101@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------Zo6ZGQm0vn0wBldO6zPuRhnL" X-ClientProxiedBy: DB7PR02CA0006.eurprd02.prod.outlook.com (2603:10a6:10:52::19) To AM6PR02MB5112.eurprd02.prod.outlook.com (2603:10a6:20b:90::21) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.244.2.119] (95.45.153.252) by DB7PR02CA0006.eurprd02.prod.outlook.com (2603:10a6:10:52::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.17 via Frontend Transport; Wed, 8 Dec 2021 01:28:08 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5705ffaa-5626-4fcd-81a6-08d9b9e9fd99 X-MS-TrafficTypeDiagnostic: AM6PR02MB4836:EE_ X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:2449; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: hSPo/0sBiFIbnQhkP6PYxU63Tu6UdtsnI7WyF3q1Dz/GQ5CmLe5o/M/lA3h/HXQqgM2u+TLbfgRnNr9IoVxrCYdN/nO0fQpwjv9JNEP/XXHiqQfjwBRWxRWSmRLswqZLK+IA9JvFtoImqlXPznb7nRaR5CRmn/JO/43oKmpqjJUPqkaK3JC3AMk+03ig6nzsxpt9nma0Tftf3n4buVTVnO9gSTH1EGeQpzgnQauOhUa3y+EyQHM7kDhJ32I9OvcQQBLR3jonJoBfeMxDwkwlltPIEjQICd2dH0zHkLZsu1u4E2EjjdQzEDKho1UAMJjX/YePTU3Q/piwZD3Vle15RXRYkk4oJs2EV/hUKXype7Es52Jx6YWx03t56CQY9fmHreIlQylf+ATDm/KbzfOy1lzqoYOhtTryrLBS6vrKteH2xUC2DoDPgmWgYbIRO/zNAyUjAk0oYM7tOH5GM5QOiFgn2QpeBE7PloaanJ+iI5hfb9S6FdYp/lkL6FEg9rfGznpkQ5fJX1yeN8ved5ow7bjMhDSTO2veU2x1OriKUv0yprybzB75s107m2e1F+8vb52ITBzbVrhTtUZmI5v/v9144Du7ooiaeZ8aI8wxttfENGiruz/aRPlpKyYg/ss2NPaMjmyXv+UFy9GyKrGDAg3oer5VRIl4jqj/C7//pWe/RO1z81/sZab8/NnCE2jPGrDmIaD8uY9Pi+o7O2bD+0wTn3axF6bxJliNFj9VHHEck0eus1OMfkp+totLCBjL X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR02MB5112.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(66946007)(38100700002)(6486002)(956004)(2616005)(21480400003)(66476007)(31686004)(8936002)(44832011)(31696002)(83380400001)(33964004)(26005)(786003)(110136005)(186003)(86362001)(5660300002)(2906002)(235185007)(16576012)(8676002)(508600001)(316002)(36756003)(53546011)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?NEhzM09Xank1eGFWcDhhZk1OQWZmWG5VWW5mSFMwdWx6UElTNXJDc3lUYWlZ?= =?utf-8?B?Y0s0d3lPRWZQSkhWWXFjYkdpWDNURFUrMTdmV3ZwQ2g4YUIzaXJmZEdwUlA1?= =?utf-8?B?eTZuNXQ1alBsdWVWMTZkbnJicjA1M0srMlRWV0c2Q0tCcGFxTC8zSG9SYS9E?= =?utf-8?B?dXdoVHpGNi9QNktkQThVU1cwSy83bGVwUUF0M0xTakJLQUFOR2dxODZGbDIx?= =?utf-8?B?V0tuL1h2RTd4QXUvTzlwb1RMZFZQOTI4Ujd1enNPMUY3Y3Nqem42bG0rY0hL?= =?utf-8?B?dC9yaUdSZGJ2SEY0VEZlU2lpd3ZjdDkzTFdBcnVRTWRxN0h2WXpmNmV4Y1VP?= =?utf-8?B?YjBkdzJ3QXA5S0RDTmRXNW5CR3ovcFI3TXFYZDZUZEVIOStiQ1ZVZSttT0Mz?= =?utf-8?B?L3hxZjZkRVY5emVqYm1DYVVsdWdXdTJSWnh0VXdabjlWanY1QTNxcDBsWHRy?= =?utf-8?B?Uk5yS1BGbFFSL3hyRHg3MDZub3UrL29malFkTmhqYU5jSkNPR2NhWXlxL3Nx?= =?utf-8?B?bzJDSC9KUW4wSENrNDViVThSOGhtZ3NOaDYxcnVzOWtNM0VYWFVBcUI5Y1V3?= =?utf-8?B?SVk5YmxQeThkR3FQSlNSSEt3SnVsQUVpSVY2dnB0Ky95V2hhdTA2a2dGTTQ1?= =?utf-8?B?eDNUWEJWdHFabGtIT1FmYWViQS9YVEEzU1NGRmVDM3puOWRNaDhST3ZmV0l5?= =?utf-8?B?U3JacEdZOEl1TWoyMGtlS3pRdStzOHRyOVZoVlREVmNlVlRhQmRmYXp6cFl3?= =?utf-8?B?bU9kalJrdG1YOGtpdGJSc2hKczNBb29UMGEzWHVMMnJ0OTV0V1RDZytUeE9B?= =?utf-8?B?bUIxWk4vYTJWcWtZWUlYSmpJWHZBdExtdmpNcnlwVXB5SWdyMHlvTU93eWlR?= =?utf-8?B?WTRCa2tuM3VPOThUSDBqb0JYbkFmaHlDcE1ub1ZvaWZJd0VlYUk1dnU5TWpz?= =?utf-8?B?Y2o4SUxoZExtVjVxVXNOcU03ZHA1MFVJOUU2bThuZHFGNkpFUEYrMzdBamZw?= =?utf-8?B?WFVEaHM2YmgzNEtHSlhudkd5WENrOVlhUE1UbXZmNE1EWTNSczJqNG5hODhX?= =?utf-8?B?VDdlaStua2huWkpWZ2JRa2JXRGluOUpRbkJNMnlybDYxQXBhZUhxWHZPa1NR?= =?utf-8?B?K3Zpa1drOWEva2RCMDdFNnREYW5kRmVFNFQ3Um5ZK1hpU3hiZm1RbG9YUHRN?= =?utf-8?B?UzBDLzN4S2Fwa3YyQ0FVQ1E2Y3N0V0xlbHk2TDdFWktMSU1VYWs5RGZkbmIr?= =?utf-8?B?UjdEZFVUamhKU0tzR0JIV2ZIbDFPcHhHMks4Z1JjV0VKVmtNSmRPRnVCK1Ns?= =?utf-8?B?cjhlN2lDbGwyMkowWG1SQ0l4bUNUcVZFV2tNSkxSMTliZFZxcVpwNzRhbmhO?= =?utf-8?B?RXlMTzZ6VlYwcE5rSk0ydlhBdFJ0Ri9MVDJpaTJQMUpNNENYallrQzVUNnFy?= =?utf-8?B?MlpwWThXZGczQjE2bUdicWtYUi9SeUVXaFgwSDcxT1M2Vk0rRElxY3pRRkd2?= =?utf-8?B?bHFRa25Qa0Q2WHlTV3NrN1pVZzMxemRXT0NQeEFnREpQTWg4TEhmUkZYcldu?= =?utf-8?B?TGpmK09sR0FXNWlrN2JyNjArSEZGRjY5ZFhndFlMY0I5QTE5VU5ESVlDNVZZ?= =?utf-8?B?T3E3bS9wU2xUZEpkY2NFVDV5cmdxS21ZYUVVRFpLczQ5ZXpyYldOd3Vad0Ex?= =?utf-8?B?V0IzSVkvN3BEYmhET3N5QjloYjFtZDFPN2U4VDE1TUJHS0QyYlRjbHFCZllQ?= =?utf-8?B?QzJXMXRmdEpkU1E2b29CSWpQRUNEc29MK3VFRDJCOW9mRVRwYVlKemh5NzZK?= =?utf-8?B?MkV0RVl2UDRBOWFDNW14MnltWm9uM0E4TDJGbmRPSGE3MGFFNnQ2dWFjd1pq?= =?utf-8?B?Y3BodXltVkl2L21HOGNORlhXTjNNNkhYVE5VeDZIRFNJN1R5WGpqaFNEUngx?= =?utf-8?B?SkdseE04eUJ3QU5mYlVCeStwcElIaEhnYXNRSllQc2UxeGFUV3V5YW92RU1F?= =?utf-8?B?MzJQQTAzNFRWRWJFb2RWZ2VCcmNkeTh6alRhZm03b2doblBuTzNMYjBkWkZy?= =?utf-8?B?RlZUSUxPc2YyZUVyallzNDlyeEprK0dLL3JJNlF2RFNmYkNtaE04T25Sby9u?= =?utf-8?Q?dcqc=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: 5705ffaa-5626-4fcd-81a6-08d9b9e9fd99 X-MS-Exchange-CrossTenant-AuthSource: AM6PR02MB5112.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2021 01:28:08.7693 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: f/d9sHtbs0/I/hMPnlxqOQ1mlpcHEkznSXL+6p2PB9MqxiY8bt7uLseqDSSEEL/v X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR02MB4836 Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:28:24 -0000 --------------Zo6ZGQm0vn0wBldO6zPuRhnL Content-Type: multipart/mixed; boundary="------------CAso0zi1GI6syympyLat1UrY"; protected-headers="v1" From: Stephen Farrell To: John C Klensin , Martin Thomson , rfced-future@iab.org Message-ID: <82394d7e-59fe-7178-727e-9524f8fa05be@cs.tcd.ie> Subject: Re: [Rfced-future] Proposed "Historical Properties" References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> <4BA70DE21D06AB0FB03F7101@PSB> In-Reply-To: <4BA70DE21D06AB0FB03F7101@PSB> --------------CAso0zi1GI6syympyLat1UrY Content-Type: multipart/mixed; boundary="------------khRwfoYTYG8RMANfB0orq2sS" --------------khRwfoYTYG8RMANfB0orq2sS Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpXZSdyZSBhcHByb2FjaGluZyBhbmdlbHMgb24gaGVhZHMgb2YgcGlucyBidXQgYW55d2F5 Li4uDQoNCk9uIDA4LzEyLzIwMjEgMDA6NTcsIEpvaG4gQyBLbGVuc2luIHdyb3RlOg0KPiBZ ZWFoLiAgIkNvbXByZWhlbnNpYmxlIiBpbXBsaWVzIHRoYXQgb25lIGNhbiBhY3R1YWxseSB1 bmRlcnN0YW5kDQo+IHRoZSB0ZXh0LiBPbmUgY291bGQgc2F5ICJyZWFkYWJsZSI6IHRoYXQg ZG9lcyBub3QgbmVjZXNzYXJpbHkNCj4gaW1wbHkgY29tcHJlaGVuc2lvbiBidXQgbWlnaHQg bm90IGJlIG11Y2ggYmV0dGVyLg0KDQpJIHByZWZlcnJlZCBsZWdpYmxlIHRvIHJlYWRhYmxl IGFzIChmb3IgbWUpIHRoZSBmb3JtZXINCmlzIG1vcmUgaHVtYW4tb3JpZW50ZWQgd2hlcmVh cyBvbmUgY291bGQgYXJndWUgdGhhdCBhDQp3b3Jkc3RhciBmaWxlIGlzIHN0aWxsIGVudGly ZWx5IHJlYWRhYmxlIHZpYSBmZ2V0YygpDQpldmVuIGlmIG5vdCBwb3NzZXNzaW5nIHRoZSBw cm9wZXJ0eSB3ZSdyZSB0cnlpbmcgdG8NCmRlc2NyaWJlLg0KDQpDaGVlcnMsDQpTLg0K --------------khRwfoYTYG8RMANfB0orq2sS Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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 zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 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+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC 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 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK 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+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb 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 Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R 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/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK 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+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB 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 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+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 =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------khRwfoYTYG8RMANfB0orq2sS-- --------------CAso0zi1GI6syympyLat1UrY-- --------------Zo6ZGQm0vn0wBldO6zPuRhnL Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmGwCiYFAwAAAAAACgkQWrL68XsXK+qR LhAAlQ3F5HZRjxbs1G/2knTt0etbC1hI/M344eZdQUeJlAqeJOtDsh7fDqUB2bJWOxVW9HvWwtcO aSWGlNmVOIScFKHlaM7dRmmq9M5p6GcSn8PI1kbiM28uLjocRuXasY/9q6USmrrSQONSyfacpHKU Mt9nvoNo2uB+XAHKAAdmWmqldbCQXq9ZUxTBPWIqi8eMIpCtcq90XvPvaFNNP948/maqcWOkbuWv Fg6zY4xRe34aG+TqfcgqpRC3VSdcJ2clCZRTVaguukYOaDcRInGFQyodKawR2RU5wlBWrGH4H+fg LD0hafbn9CwXJA0nQrfMlnolbKaax1sVnD7YJfP135izxi2+s3yPrsjDAmgHPoKOzY254YGAjSPO ANXD0wKHeIiLFuyxUYaWV5GEakcffYVGm82cH/6iV4go9F6iPVQBBBKYvUkQwzaO2n/Zu/9g21M7 UyKj0yRcd6DV95JbtHYkaCK/oxBiyRSZGbu74WbIB6qI9U5O1ddlC5zYGwRKWxO9mOSposQ9M8T3 SB2C6PNXPAg4q7ktVERaE5zykW50ea4NXx9t0BqnWj9ey8lJL3pd/If+xJQZLKDk6zGP810e0AqB TVjm8QxZgdXOpZuPkfZ3462G3Xit6XJTrT2lLnIvzi7RkGZQV7AW8VgO+7l9UZQIZ6jvQOIrutVk p3o= =0Pkt -----END PGP SIGNATURE----- --------------Zo6ZGQm0vn0wBldO6zPuRhnL-- From nobody Tue Dec 7 17:56:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 998C03A07E2 for ; Tue, 7 Dec 2021 17:56:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58YuoaGRk3iA for ; Tue, 7 Dec 2021 17:56:45 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB94E3A07DC for ; Tue, 7 Dec 2021 17:56:44 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mumCF-000E1t-UP; Tue, 07 Dec 2021 20:56:39 -0500 Date: Tue, 07 Dec 2021 20:56:33 -0500 From: John C Klensin To: Stephen Farrell , Martin Thomson , rfced-future@iab.org Message-ID: <35D4CF880C533BEA9E78159C@PSB> In-Reply-To: <82394d7e-59fe-7178-727e-9524f8fa05be@cs.tcd.ie> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <967121a8-5c79-4a7d-215e-6c06e4f8885d@stpeter.im> <247bc663-87bf-1ce9-fd73-9c4ccf543633@cs.tcd.ie> <4BA70DE21D06AB0FB03F7101@PSB> <82394d7e-59fe-7178-727e-9524f8fa05be@cs.tcd.ie> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:56:50 -0000 --On Wednesday, December 8, 2021 01:28 +0000 Stephen Farrell wrote: > > We're approaching angels on heads of pins but anyway... > > On 08/12/2021 00:57, John C Klensin wrote: >> Yeah. "Comprehensible" implies that one can actually >> understand the text. One could say "readable": that does not >> necessarily imply comprehension but might not be much better. > > I preferred legible to readable as (for me) the former > is more human-oriented whereas one could argue that a > wordstar file is still entirely readable via fgetc() > even if not possessing the property we're trying to > describe. At the risk of increasing the angel count, the same comment about "readable" could be made about an XML2RFC v3 source file. Without studying the vocabulary, a typical one is not much more comprehensible than, e.g., one of those NSFv4 specs and, without the interpreter, not much better for "readable" than that WordStar file (maybe worse). So, yes, "legible" has much more to do with human visual perception and that is sort of the minimum condition, but it is not quite enough, just as knowing that an 8" floppy or a LaserDisc is "readable" (for a different definition of that term than you are using) but not easily by most of us. Methinks that the aforementioned angel-populated pin may occupy the bottom of a rathole. At the risk of encouraging an extended tour of such a rathole, I note that there are a series of ISO Standards about the archival (sic) properties of assorted media, including storage conditions, etc. Equally important at least in the context of some of my recent obsessions, if I present a well-formatted, carefully printed, document to you in, e.g,. Vedic period Sanskrit or Song Dynasty Chinese, would you consider it "legible" and/or "readable" and why. I am guessing to the answer to "comprehensible", but, either way, it wouldn't have much to do with the sort of technical issues that cause your comments about NSFv4 or mine about some crypto algorithms. I think we know, and are more or less in agreement, about what we are trying to say here. It is somewhat difficult to believe that there is no word in English that describes it fairly precisely, but I think that may be the conclusion we are reaching. I'd encourage Peter to explain rather than trying to summarize in a single term but am nervous that we might then discover that we don't agree about the boundary cases after all. best, john From nobody Tue Dec 7 19:23:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAF23A0902 for ; Tue, 7 Dec 2021 19:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 b5AT1GF57-A0 for ; Tue, 7 Dec 2021 19:23:16 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBDCE3A08B9 for ; Tue, 7 Dec 2021 19:23:16 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id y14-20020a17090a2b4e00b001a5824f4918so3375806pjc.4 for ; Tue, 07 Dec 2021 19:23:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kvIzMkn4ovBCR9Ju2GBSJ8QiUy8v4/NPu1b1GXid2a0=; b=Y+MWAKslagdYqqAxyySLCF5o4NPwk+MfnRLuOXGiqevNNEiIshIY6Pf2ia1CjShiun z6k+95nuCkItpsb6I3y4TV5dT3V8X+kT3xHoGWl78JZV2l1dXgoKi/R63OXmY9O7YTkI smVjA3LjkAv/tWA7lHOos2+VDvyinqH4qcwe3xLeFOcnFgW+ANfeo57lQBaHX036xx1c DXtaF/ZB6IM+kW7M2ef4KKAcU8yj3jvbncUiFQmkvvvB8fR4F0YGofc7lGKsnvCG2WG+ 9XRhHLZ2KzIs/qCdw+NRzJxtc/0KKzXReN6O/hLCDqeDXO5AvpJeB7cCaABDP6/Din9G GuEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=kvIzMkn4ovBCR9Ju2GBSJ8QiUy8v4/NPu1b1GXid2a0=; b=2hH01/QoUZ9Yfcu6IQTAoPLn0oURhIsAKvOoIVjED+04UhsPGDxVA4aPOsFayo80i9 4wWCZdj7nUiNXC6gYl8P6cTNHjjIN29JB9pkl9DAeBy+f1cBUZA3TDVf0wbVQVMp/vRu ihdZtxlNJq4xdYGQeKhg8mCD8JFlSewIFQmFrSH4xs4VcwXisnUrixNjFJ2+gUvmStLP pnOQJ6KGh3waPUw+QsIZdiUzjTGhdTiWI8CWuTHefkvoKg5AnbYEeEYLWk04l8CSA5uO ZLniNYJgxyOVaHeqUbiZ8G9HWM4ORFIlF7pK5wXtdeDeHgMqhFl4IrckAyHvNwidqNgr hfzQ== X-Gm-Message-State: AOAM531fXX+rSfxkDeg8KHmaBPEWL4w4do4M5srxOJjSO8HjCQ7mR87a mX2Pt9UnvTRb4O4f0HIlX5E= X-Google-Smtp-Source: ABdhPJy8iY3Uuu+h4j8z3wL4p3OzBTHCyPGyl9mh9vi8ssU6IbtyNuIkVFK5sSWe/qifMlfoaIbvYg== X-Received: by 2002:a17:90a:ea09:: with SMTP id w9mr4003516pjy.46.1638933794604; Tue, 07 Dec 2021 19:23:14 -0800 (PST) Received: from ?IPv6:2406:e003:102d:e801:80b2:5c79:2266:e431? ([2406:e003:102d:e801:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id z4sm1285279pfh.15.2021.12.07.19.23.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Dec 2021 19:23:13 -0800 (PST) To: John C Klensin , Mirja Kuehlewind , "Joel M. Halpern" Cc: rfced-future@iab.org, =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <701a29bd-25c2-be15-aeaf-979b9f41e0b9@it.aoyama.ac.jp> <91289E13-ED07-456E-BC6E-CB6758A097A7@kuehlewind.net> <28F7BCC622EA4D684390455B@PSB> From: Brian E Carpenter Message-ID: Date: Wed, 8 Dec 2021 16:23:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <28F7BCC622EA4D684390455B@PSB> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 03:23:28 -0000 For your further amusement, Alexa (the person, not the robot) informed me this morning that my name is still on the NZ trademark registration for "IETF". Not because I live in NZ, but because I was one of the IETF Trustees when the registration was made. Sadly, I've now signed away my rights to the current Trustees, but at least for the next few days anybody who uses the mark "IETF" in New Zealand owes me. Jay, I'm looking at you :-). Regards Brian Carpenter On 08-Dec-21 04:03, John C Klensin wrote: > +1 (and shared amusement) >=20 > --On Tuesday, December 7, 2021 15:27 +0100 Mirja Kuehlewind > wrote: >=20 >> Let just steal this text (or is there a copyright issue? ;-) ) >> >>> On 7. Dec 2021, at 15:18, Joel M. Halpern >>> wrote: >>> >>> For purposes of clarifying what the historical practice on >>> translation of RFCs is, the FAQ page for the IETF Trust says: >>> Since the beginning of the RFC series, reproduction of >>> whole RFCs (including translation into a language other >>> than English) has been allowed and encouraged. The IETF >>> Trust and the RFC Editor place no restrictions on this. >>> Most RFCs include the standard phrase "Distribution of >>> this memo is unlimited" to indicate this. >>> >>> Yours, >>> Joel >>> >>> On 12/7/2021 1:56 AM, Martin J. D=C3=BCrst wrote: >>>> Hello John, others >>>> On 2021-12-07 13:22, John C Klensin wrote: >>>>> Peter, Martin, >>>>> >>>>> Some (I hope small) suggestions / changes: >>>>> Current: >>>>> licensed to explicitly permit translation >>>>> >>>>> Comment: >>>>> I'll defer to others on this if they have better >>>>> information, but my impression is that, at least >>>>> for the first 30 or so years of the series, translations >>>>> were explicitly permitted without any requirement for >>>>> specific licensing. The above, in context, seems to imply >>>>> that licenses are required and, at least unless they are >>>>> guaranteed or blanket licenses exist, that would contradict >>>>> the history we are trying to record. That is important in >>>>> part because, unlike other SDOs, we have never tried to >>>>> have, or designated, official translators or translations, >>>>> much less guaranteed their accuracy. Any moves in those >>>>> directions would also be inconsistent with the history. >>>> IANAL, and what I'm writing here is mostly based on my >>>> experience with 'handling' translations at the W3C over 15 >>>> years ago. Translations are derivative works, and so unless >>>> they are done for personal use, a license *is* needed under >>>> most if not all copyright regimes. Whether this license is >>>> given explicitly (as is the case now, and as you mention was >>>> the case earlier) or implicitly (as may have been the case >>>> in the very early parts of RFC history) is a secondary issue. >>>> A 'license' doesn't mean there has to be a written contract >>>> between licensee and licensor. If you say they "were >>>> *explicitly* permitted without any requirement for specific >>>> licensing", that would mean that there was something >>>> somewhere in a relevant location that in some form said that >>>> they were permitted. This would be enough for a license, and >>>> would be essentially the same as now, where this is, with a >>>> lot of legalese, written down in the IETF Trust Legal >>>> Provisions (see >>>> https://trustee.ietf.org/documents/trust-legal-provisions/tl >>>> p-5/). Or did you mean to write 'implicitly'? And we don't >>>> know how often e.g. Jon Postel was asked by somebody whether >>>> it was okay to translate an RFC, and just said something >>>> like "sure, go ahead". That would have been an oral license, >>>> which in the general case should be fine. I'd still expect >>>> that e.g. a publisher wanting to publish a translation of >>>> (parts of) an RFC in a book would have tried to get >>>> something in writing, e.g. by sending Jon a release form >>>> with the necessary details. Regards, Martin. >>> >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Tue Dec 7 21:26:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C593A09FB for ; Tue, 7 Dec 2021 21:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggc1bqIY904N for ; Tue, 7 Dec 2021 21:25:58 -0800 (PST) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01on20730.outbound.protection.outlook.com [IPv6:2a01:111:f403:7010::730]) (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 807C33A09F1 for ; Tue, 7 Dec 2021 21:25:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DiqqOePNf2Ig16d9So7ANMKrn7BM/0f2z8ewuw3J4e4Fy2XPSXP5afqWcfejwy3L/I36gTDZhy8h5VDofY8RwvePHVm6xRkZMaUBKgyo7EhlgaVwOxezyawiEu1de/dOeasupHTJ80Z+/H3q4vNCPzdB/Vx76DcPuNvgDuhv10Ldx40/BLyUgMEVHX8S/fzAmTY94phKV/ZHxk6HvsxEZMY3PNdnAccpg6+CozF60DEfVJXAdC4Dbz2hm/8MOXZuZvxYhKM6a7qVKFwkuW3w+IgwOkaF45urHURQHCyuXyXn7M4FeHndeeKHlUSf1v2UDDCXN8OnZI9fZOtHQx5r6w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=vQy7orcylL0Vrs8xU0x6PWgnW2Aa1rxylrFkLzsrsuc=; b=Y2ULQr7wfcsnqGM9MbkUqxqeuU1PVQXk/FsW3iGXdayWsn5eNtd6SUjCd0n7kD2nATUOxN2IKlOTAnoV1lCUXTbjInamVArvDxTonPbOzlj4bxFUDRXje+mcLotP+t4zjOL1kvEzyqkHk2G3tRcqeTajdwk6Bzo8TmPrLUA28Zd4OVFp6WD9DIEYW9h6X2O3pvUy7qShw+aF2nnWE2WHMyuEyra/PEcWbUpw31ON/1SZcR1gUIZSLUw49ZZjZZXxxKo5kD/RUy9FFh7bqet6zZJNy9faHMcJA/mcuNideRlo1v6jUd4z4GQ88t1D5c8HVXKmgkdOQU4KMvvYB6epFw== 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=vQy7orcylL0Vrs8xU0x6PWgnW2Aa1rxylrFkLzsrsuc=; b=DSRLfV6RV+uoUegFkhOY+fhxoRln5ueDsYmDtlO5A1NdO9q0i9QO818omhDqwSm6AWXzNqLBcolfErknAIThtEp4REwQKKhHjLJVosR2LceRacUnFYNjHJI15kam9qyIS71oAJ+oW4WH5BPg3/rk+NnEpmxV/ggl4Pi8gsxq5OE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB4266.jpnprd01.prod.outlook.com (2603:1096:404:d5::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Wed, 8 Dec 2021 05:25:52 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085%6]) with mapi id 15.20.4755.022; Wed, 8 Dec 2021 05:25:52 +0000 Message-ID: <8e2201f8-3748-e02c-bf16-d329c06a5412@it.aoyama.ac.jp> Date: Wed, 8 Dec 2021 14:25:49 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Mirja Kuehlewind , "Joel M. Halpern" Cc: rfced-future@iab.org References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <701a29bd-25c2-be15-aeaf-979b9f41e0b9@it.aoyama.ac.jp> <91289E13-ED07-456E-BC6E-CB6758A097A7@kuehlewind.net> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: <91289E13-ED07-456E-BC6E-CB6758A097A7@kuehlewind.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYCPR01CA0051.jpnprd01.prod.outlook.com (2603:1096:405:2::15) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 Received: from [100.70.10.6] (133.2.0.86) by TYCPR01CA0051.jpnprd01.prod.outlook.com (2603:1096:405:2::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.20 via Frontend Transport; Wed, 8 Dec 2021 05:25:51 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9a1a1bf4-08bd-4a2d-bf18-08d9ba0b336d X-MS-TrafficTypeDiagnostic: TY2PR01MB4266:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: cXVR7ruYe5FHBh2D7R+5EJBF8PO+8oDE23vhuNWL7hH2wIbBcRpsKyoZBbZ3R+9lXZKUTliUQoTQi4AJ676XevcyVMxxwi4sUBCrFPZrlIdvbfl5ctDaoWS7Nns8rBd0+ODYCmsWkn0OWb9w8ur8wKx4KC8VWjPRNC6l4YU6UtuEG8UQ2dKcGVM4w4iXUzE7PaN5cIhFSK42UyaNQRqdkGZTJdvFSkU7j9cCw/pJM5AiaH1jxgZA9GT93FrNR/yk5Tks+xwCR9n67Al6FZpQzjHyEmEvG/L13mck6epVfBXn3me/LSFHHRkMaP/RpbpkXZFn3nz80UDQnm/y5M7lVHVN7FHxtduk9kZ28+604BGJT5ImK9a13TS+7OTqlX9IGazKNmIU26EWDzEWC+s7PKrsAwVLM8nsLWoQtAvc4r7nxc0pN4uUCuDr8yXg7enxg+/P6lHv/zU/5li1hHnFd3lnwyj2GTkvd3q9l9rxF2a2eDnY9g/W7LYNaIol4T3D3XNQdo+V02y5mW3u64LcGXhZ/7II7RhNzVaaLOgMw1Nu96vGQuEOGqN8G0HJtqoRVtlIuNzmYYlzExEjGULedpjpxM8FlBI6drhhfU5P++Zwp8KpMQZGaJTEB3Lt5QIDtJQqockxprHgk97FkV87rsl/+XxBzeSSqxIXnVntokGEjV3LaJDy1cowKHHpFf6tVENExKJYAT5fYDT41Q66ff7vSzpArgZpuef4BOyee8ulF/pGwQJC0LwCRPz2jLXqGQXMl+9mIGKlSRQ2KLEsnmCZ5SCI72wK3+FJEXso3iKA7tVUR83BoGpuXP63ruHe7LQyzGMN4SW5srdXQodNbMqpbK0qfu8afleqa6Qu5Z43EaEWxCG3FAUAQDG5WEkR X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(396003)(136003)(346002)(39850400004)(66476007)(83380400001)(966005)(2906002)(66574015)(26005)(36916002)(6706004)(956004)(66946007)(4326008)(66556008)(8676002)(6486002)(8936002)(52116002)(508600001)(86362001)(5660300002)(53546011)(186003)(31686004)(38350700002)(2616005)(31696002)(110136005)(316002)(16576012)(786003)(38100700002)(78286007)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?MlhFRlRyZ2ZIOURDZUgra3hUQ1ZzSHo0anNGY21SNDdoZ3JXbVFlYi80NDRz?= =?utf-8?B?MHJHTnZ6eGVmRCtsT3hxVmZIMUE4VU0rdm9LeHNJb3pLTEF6NTg2c2VnNCtV?= =?utf-8?B?MVMwK2pTOElmR0I5YXNSWityTnVRYS9ISXphcUVEb2QzNGxuZjZLN1N5bW9T?= =?utf-8?B?eUxnemhLQ1JBRGVZMTBvY0FSTHdBQ0J6YmhVUzZhdktGV2FSWHUwUFIyVkgx?= =?utf-8?B?dGJOeUt0YVN0MGY0NHpEa3h0OUd3eXZDcWdqNnd5T2IxSElNUStMMmtJK0Zl?= =?utf-8?B?YUI0RjFTZzkwTDlnQnF1UExzeGxMam9IRDd3NzZ0SHFpWUlXMGI5Z3RYNklJ?= =?utf-8?B?bzcrcDVISTgwV1dhY0FRTFVUWUllMWk0YXIyZGIvbi94TXBLSUJRZE8vb09u?= =?utf-8?B?MFphQmdDK0J4dm8wSFM3dnhtVXZPZGE1dlJWdC9FNXJxMGxFcFRVMUFicHcy?= =?utf-8?B?bUFFVG5wMUYrcDRLRHJ0L3N5QW13UzZqOU80VHltaUo0Q2tCaDVlTUVpL2Yw?= =?utf-8?B?dTByeWdleDZ2WElvcUgwN3VlVXlwekVLVVROdStxN3pQRlBnTUJGMGlTbDFI?= =?utf-8?B?MFl1eWFiTzJjV2ovdExwR0dtdWhFNVI0WGNUS2xTRnZvcldyaWlDeTlaY3M5?= =?utf-8?B?OERLbzhhZGpXTkJpamw4UVRCVDZCTk9WT3FwUHU1RVFXZjBHcmZMc2ZmYkJW?= =?utf-8?B?WWluQ1RVR3JGZmhETTAyQlFaeVdobFJaZ3Z2MEZON2QwWjdpVkw1bExaYXdL?= =?utf-8?B?MlpKdXk1Y0xEamllRUgvMjBNNTMwYzkzSjZQcWlhRmpOc1BGbWxkcWltQy9x?= =?utf-8?B?ZnR4VlFScmxMTnlESk9zQk15YmxQTytFd3RLTS9NVkgvMXJLL1Y5NEV1akZ3?= =?utf-8?B?ZnhPYitNb0JQMUNVZkhBa0xoQ3ZnRGplaml4UXIrQkM0RmRTUThBTUFyQjRC?= =?utf-8?B?MmFncUdhU0d5bURtc0o4UytpVVR4Nkd4YmRjaXdnbnhndVFndHNmS1Z1NTBv?= =?utf-8?B?Nnl5Z1RUTEtaY21nRFA0Zm5jOS9aU1pCVmJPa1ZsR2VDcm1oUFJqV2oxZngy?= =?utf-8?B?Ynlva00vS3poMXcwSkwvT1FEa25jY0JOU3lJZENva1pCQWFSZ1gzRXdNVDVZ?= =?utf-8?B?cHhlK2piaGt6aW1Kazdpa3BjSVg2OUl4L2FwSG5Ra0pUWjhueDA1YkFoaDB3?= =?utf-8?B?SlVyRVY5TDJneWh2eDBkRXlyQys5NjN4ZExnV0hvbVBDNHZjb0UxaU4wTmJn?= =?utf-8?B?K0NWMDN0UkVGZVdYRjhRQ2FKWC92NERCTjNOOUgvbThNQmxTN2VDVE1FcjIx?= =?utf-8?B?andqRXNFUDh3MjR1cWFFN20xbExIaHVVQ2VrM3JOdDBYeGlCWWZGVlkxWWY0?= =?utf-8?B?eTQwcm4vbWRmM2c0UmJuSTNWZkpBN2NGWllOREJ6WTJGRDljOUJySFN1R2NK?= =?utf-8?B?UXplS1hObWNIS3NpSjB1eDFXSjgvc3NFdldkRzVGa244bXl2Q1l5R1hZUUY1?= =?utf-8?B?S3F0VjFhdHNIcW9PRTVpdVl1d2hGVGJXc2lBTURIeFhtbHlDUmNBZDlUUEFS?= =?utf-8?B?SThKR3oxTXl0blF6TnlCQjRNRjlFdUNic0xLWWRVREpNWUdvS2Fod3pqSkkx?= =?utf-8?B?dDh3M0o1YkplS3I2MERaNkVsY2FSU2piaDBDRTdJdmxwbzEzc05IejRHTHJR?= =?utf-8?B?b0NGUEdNTmtSNWF1SlBoSkdLakc0M2I3OG44Rms4VGRVSlFhckppb1FnQTF3?= =?utf-8?B?VzhJK1BNdmpheVpVdHBrNTBCVjZjZHo1Z1prMjlYUld2cldkOU14V3BqeVhl?= =?utf-8?B?MmV0V1QzVEVYaEFhUld1dC90alJ5Y1NFeFZEclJCMUdnYVV1KzI1NlhQb0xN?= =?utf-8?B?UlZWN0tZSlBSRWhoRjJ5UmhyckYyTFcyUWRmZ014L3dlai9nQlFSeEg2TXM3?= =?utf-8?B?T0ZuT1pUdkM1SkhIUmNSOWFuaFJ2ank1TW4rbjhMUkZhU01VOEh5VGVPMk1D?= =?utf-8?B?RVZPcmZBdTRIY3NYblI5RTRkNlZiU01sRnNRcTd4ZUw4bUpMaS9FTmhKZURR?= =?utf-8?B?bkJUVm5WVkVxa254RVRkYTFjVThVQncvVUhGa0VPRVE3dHh0ZEVoNThXTmsz?= =?utf-8?B?dnVFRTRJL2ZYRGV4bVF1NGp3ckNWOHdtTURTRS9adUVrdDlRb2dLSmV6K0Jh?= =?utf-8?B?YlE9PQ==?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 9a1a1bf4-08bd-4a2d-bf18-08d9ba0b336d X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Dec 2021 05:25:52.1435 (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: /oQsOed+yy/1tSBMhcTC9hKSzriaHIJDYGcAy0x7EbOruoi5fq0L70ZCO1/b/j5cKcUI3CUq0OzqMvVnIbl8aQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB4266 Archived-At: Subject: Re: [Rfced-future] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 05:26:05 -0000 On 2021-12-07 23:27, Mirja Kuehlewind wrote: > Let just steal this text (or is there a copyright issue? ;-) ) Well, if there's a copyright issue, then it's stealing. But if there's no copyright issue, then we don't have to steal it, we can just copy it. :-) >> On 7. Dec 2021, at 15:18, Joel M. Halpern wrote: >> >> For purposes of clarifying what the historical practice on translation of RFCs is, the FAQ page for the IETF Trust says: >> Since the beginning of the RFC series, reproduction of whole >> RFCs (including translation into a language other than English) >> has been allowed and encouraged. The IETF Trust and the RFC Editor >> place no restrictions on this. Most RFCs include the standard phrase >> “Distribution of this memo is unlimited” to indicate this. >> >> Yours, >> Joel >> >> On 12/7/2021 1:56 AM, Martin J. Dürst wrote: >>> Hello John, others >>> On 2021-12-07 13:22, John C Klensin wrote: >>>> Peter, Martin, >>>> >>>> Some (I hope small) suggestions / changes: >>>> Current: >>>> licensed to explicitly permit translation >>>> >>>> Comment: >>>> I'll defer to others on this if they have better information, >>>> but my impression is that, at least for the first 30 or so years >>>> of the series, translations were explicitly permitted without >>>> any requirement for specific licensing. The above, in context, >>>> seems to imply that licenses are required and, at least unless >>>> they are guaranteed or blanket licenses exist, that would >>>> contradict the history we are trying to record. That is >>>> important in part because, unlike other SDOs, we have never >>>> tried to have, or designated, official translators or >>>> translations, much less guaranteed their accuracy. Any moves in >>>> those directions would also be inconsistent with the history. >>> IANAL, and what I'm writing here is mostly based on my experience with 'handling' translations at the W3C over 15 years ago. >>> Translations are derivative works, and so unless they are done for personal use, a license *is* needed under most if not all copyright regimes. Whether this license is given explicitly (as is the case now, and as you mention was the case earlier) or implicitly (as may have been the case in the very early parts of RFC history) is a secondary issue. >>> A 'license' doesn't mean there has to be a written contract between licensee and licensor. If you say they "were *explicitly* permitted without any requirement for specific licensing", that would mean that there was something somewhere in a relevant location that in some form said that they were permitted. This would be enough for a license, and would be essentially the same as now, where this is, with a lot of legalese, written down in the IETF Trust Legal Provisions (see https://trustee.ietf.org/documents/trust-legal-provisions/tlp-5/). Or did you mean to write 'implicitly'? >>> And we don't know how often e.g. Jon Postel was asked by somebody whether it was okay to translate an RFC, and just said something like "sure, go ahead". That would have been an oral license, which in the general case should be fine. I'd still expect that e.g. a publisher wanting to publish a translation of (parts of) an RFC in a book would have tried to get something in writing, e.g. by sending Jon a release form with the necessary details. >>> Regards, Martin. >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > . > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Tue Dec 7 21:30:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214593A0A05 for ; Tue, 7 Dec 2021 21:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPm9xv1LAsHN for ; Tue, 7 Dec 2021 21:30:36 -0800 (PST) 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 B61DE3A0A0B for ; Tue, 7 Dec 2021 21:30:35 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mupXF-000EGI-Lg; Wed, 08 Dec 2021 00:30:33 -0500 Date: Wed, 08 Dec 2021 00:30:28 -0500 From: John C Klensin To: Adam Roach , rfced-future@iab.org Message-ID: <149B08C2B6DA1F5DD8841708@PSB> In-Reply-To: <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.com> References: <262efdcd-8215-4e8c-a141-7258e7e5bcce@www.fastmail.com> <069b20c0-96d3-bd86-5b6e-a0232959b29c@lear.ch> <04FA6448C084AE9C3A72F76E@PSB> <90593bc4-cb13-70fb-963c-4a1ba7d1f6c8@nostrum.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] Proposed "Historical Properties" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 05:30:41 -0000 Picking up where I left off... --On Monday, December 6, 2021 22:58 -0600 Adam Roach wrote: > On 12/6/2021 10:22 PM, John C Klensin wrote: >... >> ----- >>=20 >> Current: >> "heightened scrutiny" (and the new calls for comment, >> etc., text) >>=20 >> Comment: >> I actually like this term as an alternate to "enhanced >> review" or similar phrases. But my intent, as discussed >> during the call and in earlier messages, was an expanded >> review, not just extra care in the discussions among the >> usual group of RSWG participants and RSAB members. The >> current text seems to imply the latter. >=20 >=20 > That's because you're looking at the wrong section. The key > phrase in *this* section is "As described under... {{cfc}}..." > The key phrase in {{cfc}} is: >=20 > "In cases where a proposal has the potential to significantly > modify > =C2=A0 policies of long standing or historical = characteristics of > the > =C2=A0 Series, the RSAB should take extra care to reach out = to > even broader > =C2=A0 communities that make use of RFCs, such as scholarly > researchers, > =C2=A0 procurement managers, and standards development > organizations." I did indeed miss that. I was trying to work from the GitHub posting and, perhaps because I was tired, found it a bit hard to navigate. >... >> ----- >>=20 >> Current: >> licensed to explicitly permit translation >>=20 >> Comment: >> I'll defer to others on this if they have better >> information, but my impression is that, at least for the >> first 30 or so years of the series, translations were >> explicitly permitted without any requirement for specific >> licensing. The above, in context, seems to imply that >> licenses are required and, at least unless they are >> guaranteed or blanket licenses exist, that would contradict >> the history we are trying to record. > Ah, I think you're onto something here. Perhaps: "Documents > have been made available under terms that explicitly allow > anyone to translate them into other languages without asking > for permission to do so." That would make me much happier. Thanks. > Your other comments have concrete suggestions, and I have no > issue with those suggestions. Again, thanks. john From nobody Tue Dec 7 21:43:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6982A3A0A1E for ; Tue, 7 Dec 2021 21:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w6YSSQW5RNZg for ; Tue, 7 Dec 2021 21:43:06 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 F01403A0A1D for ; Tue, 7 Dec 2021 21:43:04 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::5] ([IPv6:2001:420:c0c0:1011:0:0:0:5]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B85h1K23416701 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 8 Dec 2021 06:43:02 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638942182; bh=LJ3LlOQOqFdF1dvzmt/+57oX3eBL34GcwOMmk6frY1Q=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=qR0QEqE+MidR5B/Q38i/qxzLlgW9anbOyEvDyLQDszSFA6SSnUYMfGqzCMGmC1PW5 5g52NuUnFxRTIWb0tREbHKstBWo9o87hLqmDdaRzzuw/7zsJFmuZhAkWkn7y242uVC +5niPcIyG3BeJB+AofmWmGnbPpX21zgkY0v7+hMw= Message-ID: <8740e3b3-9f2c-dbc0-1cc9-07b178ccb1b8@lear.ch> Date: Wed, 8 Dec 2021 06:42:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Mark Nottingham Cc: rfced-future@iab.org References: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> <937D289CD1D4CC64E2A66C65@PSB> <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> From: Eliot Lear In-Reply-To: <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------3fCty0SbQ3kp8OB0RZhwiuvm" Archived-At: Subject: Re: [Rfced-future] next steps X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 05:43:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------3fCty0SbQ3kp8OB0RZhwiuvm Content-Type: multipart/mixed; boundary="------------9vuumxXsfCzSuatr0ddubMkc"; protected-headers="v1" From: Eliot Lear To: Mark Nottingham Cc: rfced-future@iab.org Message-ID: <8740e3b3-9f2c-dbc0-1cc9-07b178ccb1b8@lear.ch> Subject: Re: [Rfced-future] next steps References: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> <937D289CD1D4CC64E2A66C65@PSB> <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> In-Reply-To: <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> --------------9vuumxXsfCzSuatr0ddubMkc Content-Type: multipart/mixed; boundary="------------U8jLc4rbbcvTMiA3Dgv0zzI7" --------------U8jLc4rbbcvTMiA3Dgv0zzI7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAwOC4xMi4yMSAwMDoyOCwgTWFyayBOb3R0aW5naGFtIHdyb3RlOg0KPiArMS4gSXQn cyBpbXBvcnRhbnQgdG8gbG9vayBhdCB0aGUgZmluYWwgc3RhdGUgb2YgdGhlIHRleHQgYXMg YSB3aG9sZSAtLSBwYXJ0aWN1bGFybHkgc2luY2UgKEFJVUkpIHRoZXJlIGlzbid0IGFuIGVx dWl2YWxlbnQgb2YgYW4gSUVURiBMQyBoZXJlLg0KPg0KVGhlcmUgaXMgYSByZXF1aXJlZCBj b21tdW5pdHkgcmV2aWV3LCBhcyBpcyB0aGUgY2FzZSB3aXRoIGFsbCBJQUIgdHJhY2sgDQpk b2N1bWVudHMuwqAgSG93IHRoZSBJQUIgaGFuZGxlcyB0aG9zZSBjb21tZW50cyBpcywgb2Yg Y291cnNlLCB1cCB0byB0aGVtLg0KDQpFbGlvdA0KDQoNCg== --------------U8jLc4rbbcvTMiA3Dgv0zzI7 Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------U8jLc4rbbcvTMiA3Dgv0zzI7-- --------------9vuumxXsfCzSuatr0ddubMkc-- --------------3fCty0SbQ3kp8OB0RZhwiuvm Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGwReMFAwAAAAAACgkQh7ZrRtnSejNv cggAvNJeQ7ktWdxWKbt8Gpd7cvjZz8ipjoT05++SlUyKrsypZc78vAD2u23k7W9viyM3AAIifkSW R9MZBbnUaBfEvIr0B+9UczK5Iz5JK3eTHvlT2f6mb+DVVB/BNGIMEJhqLHyOMkjQiWZdDFDumJpV vGk9FGesJ60Ef1FSGetz2+oYFf33jBArq8T1mm7ml2s/Y2HtqOREys3hjZ+St7LaZWAEV4oXvlGf 31bvUseguEDnseoG2oJahl5797j36pi2E4MIt58rBPn8+Wqshw9NjG+cuYbfUFIC8yBNnd+XRDVC 5VgheilT/vMkOZIKSSL05Nr6mWs3lZSVK/Xgggbwsg== =2C2S -----END PGP SIGNATURE----- --------------3fCty0SbQ3kp8OB0RZhwiuvm-- From nobody Wed Dec 8 05:04:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CA283A07D0 for ; Wed, 8 Dec 2021 05:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_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 of5Eq9EsPzSr for ; Wed, 8 Dec 2021 05:04:41 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FBC53A07CF for ; Wed, 8 Dec 2021 05:04:40 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1B8D4btL024396; Wed, 8 Dec 2021 13:04:37 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B770146052; Wed, 8 Dec 2021 13:04:36 +0000 (GMT) Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id A9B2646050; Wed, 8 Dec 2021 13:04:36 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS; Wed, 8 Dec 2021 13:04:36 +0000 (GMT) Received: from LAPTOPK7AS653V ([84.93.2.155]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1B8D4ZKK019348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 8 Dec 2021 13:04:36 GMT Reply-To: From: "Adrian Farrel" To: "'Mark Nottingham'" , "'John C Klensin'" Cc: , "'Eliot Lear'" References: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> <937D289CD1D4CC64E2A66C65@PSB> <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> In-Reply-To: <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> Date: Wed, 8 Dec 2021 13:04:35 -0000 Organization: Old Dog Consulting Message-ID: <053501d7ec34$2708c660$751a5320$@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: AQIz/6/ZS07O8m6U1xdBVPjUEh6hPAFINjKvAZVWbnOrWXvfAA== X-Originating-IP: 84.93.2.155 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2034-8.6.0.1018-26576.007 X-TM-AS-Result: No--1.586-10.0-31-10 X-imss-scan-details: No--1.586-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2034-8.6.1018-26576.007 X-TMASE-Result: 10--1.585700-10.000000 X-TMASE-MatchedRID: oTBA/+sdKabxIbpQ8BhdbJFL3OZgJTJB98OeHA9B9EeCfqmp4B6gPagF 8LHYfOYGen08PYUeHYlByfmsLMURTyVWe//c8jkZc3NMj892q4pPnKxAOPp4WU7zDnANQrNS3aC KrnFF0wvZEhrS7mh5pvLnart8kfb3hnBMPbxjCXQK3Ma88LL+bq15LjjfKZ5RsendljuCrd2OuD 30M4BEVGUVI5FRUThegAIcTCLsUSWmnax2ll+5MrU+IyHhkXf1ktBHfvLK/Jqh6+nkvTUDSrDsz p3K5gqDjoczmuoPCq29yXmsEVLCNjqIVNrn32MkFAUL5KBLpaexIMXihHo2504H4ZoHRWGHv5vV 1Cab4yHj3zZ2GAUEzsohvxQZdNwfZSD1NvrjPpMl4nVYwIRGQa1+3JijYrAOMqmhG/M0o4/0MHw zu2JowBZt/2+KOWzz X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] next steps X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 13:04:47 -0000 At the risk of piling on =F0=9F=98=8A You're not saying, Eliot, that if someone discovers a defect or = significant fault in the text we should bury it. Sure, you don't want to reopen discussions that have already reached = consensus, but bugs are bugs. A -----Original Message----- From: Rfced-future On Behalf Of Mark = Nottingham Sent: 07 December 2021 23:28 To: John C Klensin Cc: rfced-future@iab.org; Eliot Lear Subject: Re: [Rfced-future] next steps +1. It's important to look at the final state of the text as a whole -- = particularly since (AIUI) there isn't an equivalent of an IETF LC here. > On 8 Dec 2021, at 2:15 am, John C Klensin wrote: >=20 > I think it does/should but only with the understanding that > "only changes" is to be interpreted liberally. My concern is > that sometimes new text accidentally exposes issues in other > parts of the document and I would not want to have discussions > of those barred. -- Mark Nottingham https://www.mnot.net/ --=20 Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Dec 8 06:22:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609A83A0932 for ; Wed, 8 Dec 2021 06:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecQPEwBuWkJq for ; Wed, 8 Dec 2021 06:22:37 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 1671B3A0921 for ; Wed, 8 Dec 2021 06:22:35 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::9] ([IPv6:2001:420:c0c0:1011:0:0:0:9]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1B8EMRBK3668015 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 8 Dec 2021 15:22:28 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1638973348; bh=mG6rPn6wZBpjfd/hpMDgBEJIpaSe5NwE8ur7560ve7w=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=vmFlaYW75QwBZuwoVJZ6NeIq67WPt7+DGV/n4l+XRHVZK3KDr6WeHu/t6Ph+3B3A+ VGtCG6DwdtGfSi7CRUbIXQrXqTW45ILxNZqaj0XaxHdQkvcMJZ4PPljs0eSGdR0tyN BZi9QTIHSSgg6+ls/QHNJa9amiNooJpVYvUoxZYQ= Message-ID: <562cb5c1-25e2-a8be-cbd1-faf17a66f8fe@lear.ch> Date: Wed, 8 Dec 2021 15:22:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: adrian@olddog.co.uk, "'Mark Nottingham'" , "'John C Klensin'" Cc: rfced-future@iab.org References: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> <937D289CD1D4CC64E2A66C65@PSB> <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> <053501d7ec34$2708c660$751a5320$@olddog.co.uk> From: Eliot Lear In-Reply-To: <053501d7ec34$2708c660$751a5320$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------GviG2ASFeMvx0Ks2FylwJzjS" Archived-At: Subject: Re: [Rfced-future] next steps X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 14:22:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------GviG2ASFeMvx0Ks2FylwJzjS Content-Type: multipart/mixed; boundary="------------G03tePQ8IRptPXs1DrPy7RxZ"; protected-headers="v1" From: Eliot Lear To: adrian@olddog.co.uk, 'Mark Nottingham' , 'John C Klensin' Cc: rfced-future@iab.org Message-ID: <562cb5c1-25e2-a8be-cbd1-faf17a66f8fe@lear.ch> Subject: Re: [Rfced-future] next steps References: <32bbc689-169b-5c2a-00b9-3b66289a9ead@lear.ch> <937D289CD1D4CC64E2A66C65@PSB> <5A7E468D-CAF0-4583-AC6A-A898A6430EC0@mnot.net> <053501d7ec34$2708c660$751a5320$@olddog.co.uk> In-Reply-To: <053501d7ec34$2708c660$751a5320$@olddog.co.uk> --------------G03tePQ8IRptPXs1DrPy7RxZ Content-Type: multipart/mixed; boundary="------------OgoEBtvmjfbqsAyde07TgUK3" --------------OgoEBtvmjfbqsAyde07TgUK3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAwOC4xMi4yMSAxNDowNCwgQWRyaWFuIEZhcnJlbCB3cm90ZToNCj4gQXQgdGhlIHJp c2sgb2YgcGlsaW5nIG9uIPCfmIoNCj4NCj4gWW91J3JlIG5vdCBzYXlpbmcsIEVsaW90LCB0 aGF0IGlmIHNvbWVvbmUgZGlzY292ZXJzIGEgZGVmZWN0IG9yIHNpZ25pZmljYW50IGZhdWx0 IGluIHRoZSB0ZXh0IHdlIHNob3VsZCBidXJ5IGl0Lg0KPg0KPiBTdXJlLCB5b3UgZG9uJ3Qg d2FudCB0byByZW9wZW4gZGlzY3Vzc2lvbnMgdGhhdCBoYXZlIGFscmVhZHkgcmVhY2hlZCBj b25zZW5zdXMsIGJ1dCBidWdzIGFyZSBidWdzLg0KDQpPZiBjb3Vyc2UuwqAgcmUtbGl0aWdh dGluZyBkZWNpc2lvbnMsIGhvd2V2ZXIsIHNob3VsZCBiZSBhdm9pZGVkLg0KDQpFbGlvdA0K DQo+IEENCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUmZjZWQt ZnV0dXJlIDxyZmNlZC1mdXR1cmUtYm91bmNlc0BpYWIub3JnPiBPbiBCZWhhbGYgT2YgTWFy ayBOb3R0aW5naGFtDQo+IFNlbnQ6IDA3IERlY2VtYmVyIDIwMjEgMjM6MjgNCj4gVG86IEpv aG4gQyBLbGVuc2luIDxqb2huLWlldGZAamNrLmNvbT4NCj4gQ2M6IHJmY2VkLWZ1dHVyZUBp YWIub3JnOyBFbGlvdCBMZWFyIDxsZWFyQGxlYXIuY2g+DQo+IFN1YmplY3Q6IFJlOiBbUmZj ZWQtZnV0dXJlXSBuZXh0IHN0ZXBzDQo+DQo+ICsxLiBJdCdzIGltcG9ydGFudCB0byBsb29r IGF0IHRoZSBmaW5hbCBzdGF0ZSBvZiB0aGUgdGV4dCBhcyBhIHdob2xlIC0tIHBhcnRpY3Vs YXJseSBzaW5jZSAoQUlVSSkgdGhlcmUgaXNuJ3QgYW4gZXF1aXZhbGVudCBvZiBhbiBJRVRG IExDIGhlcmUuDQo+DQo+DQo+PiBPbiA4IERlYyAyMDIxLCBhdCAyOjE1IGFtLCBKb2huIEMg S2xlbnNpbiA8am9obi1pZXRmQGpjay5jb20+IHdyb3RlOg0KPj4NCj4+IEkgdGhpbmsgaXQg ZG9lcy9zaG91bGQgYnV0IG9ubHkgd2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0DQo+PiAi b25seSBjaGFuZ2VzIiBpcyB0byBiZSBpbnRlcnByZXRlZCBsaWJlcmFsbHkuICBNeSBjb25j ZXJuIGlzDQo+PiB0aGF0IHNvbWV0aW1lcyBuZXcgdGV4dCBhY2NpZGVudGFsbHkgZXhwb3Nl cyBpc3N1ZXMgaW4gb3RoZXINCj4+IHBhcnRzIG9mIHRoZSBkb2N1bWVudCBhbmQgSSB3b3Vs ZCBub3Qgd2FudCB0byBoYXZlIGRpc2N1c3Npb25zDQo+PiBvZiB0aG9zZSBiYXJyZWQuDQo+ IC0tDQo+IE1hcmsgTm90dGluZ2hhbSAgIGh0dHBzOi8vd3d3Lm1ub3QubmV0Lw0KPg0K --------------OgoEBtvmjfbqsAyde07TgUK3 Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------OgoEBtvmjfbqsAyde07TgUK3-- --------------G03tePQ8IRptPXs1DrPy7RxZ-- --------------GviG2ASFeMvx0Ks2FylwJzjS Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGwv6EFAwAAAAAACgkQh7ZrRtnSejMi CQf/d2IOQ9p0YaX2Gs8gvlPL7RWNIz4uSlplYfK/YJ/RhOpPORCvsr3NuL0+m1mfoPKlPyTaYDY6 2nVt+xBmaAYNSPEaG7H6boz/1ngBs6lF8t3v3KCFfwNSTrPNzUQXh+U3jGuyDdAXaMZRVIDeVgQZ NENf1YTU6RxanDqsV66X8rV7lNlndjDc1uel/O50qEJ7lWwi6sHq9ycCg6Tv9kdDyfH/TNHKfCxF RKKtFu5gdWNtHdWsoIKIktwI5UjViXoyLDZGPo+ykR6wpqX2RERNliwBvfNkzt8YciCBaqq4aw3p +uLA9Gq3Z9q8pm/kovh6wO2MWAzJHx+bQYN5c3WTAw== =4hOH -----END PGP SIGNATURE----- --------------GviG2ASFeMvx0Ks2FylwJzjS-- From nobody Fri Dec 10 05:31:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145C63A0D88 for ; Fri, 10 Dec 2021 05:31:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 F3-BlhJUuLOe for ; Fri, 10 Dec 2021 05:31:39 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92FD23A0D82 for ; Fri, 10 Dec 2021 05:31:39 -0800 (PST) Received: from p200300dee702460081280280a09c2034.dip0.t-ipconnect.de ([2003:de:e702:4600:8128:280:a09c:2034]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mvfzq-0007Bl-QG; Fri, 10 Dec 2021 14:31:34 +0100 From: Mirja Kuehlewind Content-Type: multipart/alternative; boundary="Apple-Mail=_FC8B236F-D687-48C2-836A-90570CA5F31B" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> Date: Fri, 10 Dec 2021 14:31:34 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1639143099;486eabeb; X-HE-SMSGID: 1mvfzq-0007Bl-QG Archived-At: Subject: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Dec 2021 13:31:41 -0000 --Apple-Mail=_FC8B236F-D687-48C2-836A-90570CA5F31B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi al, I just recently noted this text and wanted to double-check it with the = group: =E2=80=9DTo ensure the smooth operation of the RFC Series, the RSAB = shall include the IETF Executive Director or their delegate as a = non-voting member since the IETF LLC is responsible for implementation = of policies governing the RFC Series. The RSAB may at its discretion = include additional non-voting members, for instance a liaison from the = RPC." This has a shall for the ED but only a may for the RPC. However, in many = places we say that the RSAB is also an advisory body for the RPC and = therefore I think it would actually be important to have an RPC liaison.=20= Currently in our stream manager meetings with the RPC (which happen = about 3 times a year), we usually have 2-3 people from the RPC and the = RPC is organising the meeting and mostly sets the agenda. These meetings = are seen as very valuable by the RPC and my current assumption was that = those meetings would in future be part of the RSAB meetings. Therefore I = believe it would be important to ensure that a) someone from the RPC is = presented, b) multiple people from the RPC are be allowed to join and c) = that the RPC is able to add item to the agenda.=20 We don=E2=80=99t necessarily need to specify those details about the = operation of the RSAB in this or any RFC, however, the =E2=80=9Cmay=E2=80=9D= in the text above seems wrong or at least irritating to me. Should we = change that? Mirja --Apple-Mail=_FC8B236F-D687-48C2-836A-90570CA5F31B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = al,

I just recently = noted this text and wanted to double-check it with the group:

=E2=80=9DTo ensure the smooth operation of the RFC Series, = the RSAB shall include the = IETF Executive Director or their delegate as a = non-voting member since the IETF = LLC is responsible for implementation of policies governing the RFC Series. The RSAB may at = its discretion include = additional non-voting members, for instance a liaison = from the = RPC."

This has a shall for the ED but only a may for the RPC. = However, in many places we say that the RSAB is also an advisory body = for the RPC and therefore I think it would actually be important to have = an RPC liaison. 

Currently in our stream manager meetings with the RPC (which = happen about 3 times a year), we usually have 2-3 people from the RPC = and the RPC is organising the meeting and mostly sets the agenda. These = meetings are seen as very valuable by the RPC and my current assumption = was that those meetings would in future be part of the RSAB meetings. = Therefore I believe it would be important to ensure that a) someone from = the RPC is presented, b) multiple people from the RPC are be allowed to = join and c) that the RPC is able to add item to the = agenda. 

We= don=E2=80=99t necessarily need to specify those details about the = operation of the RSAB in this or any RFC, however, the =E2=80=9Cmay=E2=80=9D= in the text above seems wrong or at least irritating to me. Should we = change that?

Mirja

= --Apple-Mail=_FC8B236F-D687-48C2-836A-90570CA5F31B-- From nobody Fri Dec 10 07:07:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 299853A0780 for ; Fri, 10 Dec 2021 07:07:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5OBfOQoaTjr for ; Fri, 10 Dec 2021 07:06:59 -0800 (PST) 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 569B13A077E for ; Fri, 10 Dec 2021 07:06:57 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mvhU7-000JQr-W2; Fri, 10 Dec 2021 10:06:56 -0500 Date: Fri, 10 Dec 2021 10:06:50 -0500 From: John C Klensin To: Mirja Kuehlewind , rfced-future@iab.org Message-ID: <613FF68257493B3A165C6868@PSB> In-Reply-To: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Dec 2021 15:07:04 -0000 --On Friday, December 10, 2021 14:31 +0100 Mirja Kuehlewind wrote: > Hi al, > > I just recently noted this text and wanted to double-check it > with the group: > > "To ensure the smooth operation of the RFC Series, the RSAB > shall include the IETF Executive Director or their delegate as > a non-voting member since the IETF LLC is responsible for > implementation of policies governing the RFC Series. The RSAB > may at its discretion include additional non-voting members, > for instance a liaison from the RPC." > > This has a shall for the ED but only a may for the RPC. > However, in many places we say that the RSAB is also an > advisory body for the RPC and therefore I think it would > actually be important to have an RPC liaison. > > Currently in our stream manager meetings with the RPC (which > happen about 3 times a year), we usually have 2-3 people from > the RPC and the RPC is organising the meeting and mostly sets > the agenda. These meetings are seen as very valuable by the > RPC and my current assumption was that those meetings would in > future be part of the RSAB meetings. Therefore I believe it > would be important to ensure that a) someone from the RPC is > presented, b) multiple people from the RPC are be allowed to > join and c) that the RPC is able to add item to the agenda. > > We don't necessarily need to specify those details about the > operation of the RSAB in this or any RFC, however, the > "may" in the text above seems wrong or at least irritating > to me. Should we change that? FWIW, I agree with the analysis and believe the answer is "yes", Not having the RPC present and represented by one of its senior people, but rather relying on the ExecDir to represent them and decide when and if they should be present might be reasonable but would, IMO, turn the RSAB into more of an executive oversight board than an advisory one charged with making more detailed reviews of substantive matters about the Series. I don't think that is what we have been looking for. john From nobody Fri Dec 10 08:41:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64B943A07E8 for ; Fri, 10 Dec 2021 08:41:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wl9At5LskYTO for ; Fri, 10 Dec 2021 08:41:10 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 059473A07E9 for ; Fri, 10 Dec 2021 08:41:08 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BAGer5C043690 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 10 Dec 2021 17:41:02 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639154462; bh=N/qJVYr8IMAwxauV3mQS+UHrwJzz5KsSQiv05DSSiYQ=; h=Date:To:References:From:Subject:In-Reply-To:From; b=XwtSo5SKndPa4uytWbzjq8IVwZ1Tw5V36cu8h1+ragzC/x72SdvseQuST9AXKAMX4 2DyLxGLx1RnG9HPbDdAlx2fT0ua1fZwqvlaqFOySzwMVxIhJKUnDmokrn3YL2Q/1Rf sdM/Yi+Cv+gNomG4fVDtz48sbTbHvPGcN9YiuXYU= Message-ID: <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> Date: Fri, 10 Dec 2021 17:40:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Mirja Kuehlewind , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> From: Eliot Lear In-Reply-To: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------iHjEGgNGlnJ3Q9KBhFPDZ008" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Dec 2021 16:41:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------iHjEGgNGlnJ3Q9KBhFPDZ008 Content-Type: multipart/mixed; boundary="------------JXX5xsvnCSC0h9AcEUJU3YFQ"; protected-headers="v1" From: Eliot Lear To: Mirja Kuehlewind , rfced-future@iab.org Message-ID: <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> Subject: Re: [Rfced-future] RPC liaison to the RSAB References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> In-Reply-To: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> --------------JXX5xsvnCSC0h9AcEUJU3YFQ Content-Type: multipart/alternative; boundary="------------Nmf06k5hThoTdqWECkivzBMR" --------------Nmf06k5hThoTdqWECkivzBMR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpPbiAxMC4xMi4yMSAxNDozMSwgTWlyamEgS3VlaGxld2luZCB3cm90ZToNCj4NCj4gV2Ug ZG9u4oCZdCBuZWNlc3NhcmlseSBuZWVkIHRvIHNwZWNpZnkgdGhvc2UgZGV0YWlscyBhYm91 dCB0aGUgb3BlcmF0aW9uIA0KPiBvZiB0aGUgUlNBQiBpbiB0aGlzIG9yIGFueSBSRkMsIGhv d2V2ZXIsIHRoZSDigJxtYXnigJ0gaW4gdGhlIHRleHQgYWJvdmUgDQo+IHNlZW1zIHdyb25n IG9yIGF0IGxlYXN0IGlycml0YXRpbmcgdG8gbWUuIFNob3VsZCB3ZSBjaGFuZ2UgdGhhdD8N Cg0KVGhlIHJlYXNvbiBpdCdzIGEgIm1heSIgaXMgdG8gYWxsb3cgdGhlIFJTQUIgdG8gZGVj aWRlIHdobyB0aGV5IG5lZWQgYXMgDQpsaWFpc29ucy7CoCBUaGUgUlBDIGlzIGxpc3RlZCBh cyBhbiBleGFtcGxlLsKgIFRoZSBSU0FCIG1heSB3aXNoIHRvIA0KZXN0YWJsaXNoICpvdGhl ciogbGlhaXNvbnMgYmFzZWQgb24gdGhlaXIgbmVlZHMuIFRoaXMgd2FzIGJhc2VkIG9uIA0K ZGlzY3Vzc2lvbiB0aGF0IEx1Y3kgaW5pdGlhdGVkIHNvbWUgdGltZSBhZ28uDQoNCkJ1dCBJ IHdvdWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBpZiB5b3UgdGhpbmsgdGhlIFJTQUIgYW5kIG1l bWJlcnMgb2YgdGhlIA0KUlBDIGNhbm5vdCBtZWV0IHdoZW4gdGhleSBmZWVsIHRoZXkgbmVl ZCB0by7CoCBJIGRvbid0IHRoaW5rIHRoYXQgd2FzIHRoZSANCmludGVudCBvZiB0aGUgdGV4 dCBvciB0aGUgZ3JvdXAuDQoNCkVsaW90DQoNCg== --------------Nmf06k5hThoTdqWECkivzBMR Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 10.12.21 14:31, Mirja Kuehlewind wrote:

We don=E2=80=99t necessarily need to specify those = details about the operation of the RSAB in this or any RFC, however, the =E2=80=9Cmay=E2=80=9D in the text above seems wrong or at least i= rritating to me. Should we change that?

The reason it's a "may" is to allow the RSAB to decide who they need as liaisons.=C2=A0 The RPC is listed as an example.=C2=A0 The = RSAB may wish to establish other liaisons based on their needs.=C2=A0= This was based on discussion that Lucy initiated some time ago.

=

But I would like to understand if you think the RSAB and members of the RPC cannot meet when they feel they need to.=C2=A0 I don't t= hink that was the intent of the text or the group.

Eliot

--------------Nmf06k5hThoTdqWECkivzBMR-- --------------JXX5xsvnCSC0h9AcEUJU3YFQ-- --------------iHjEGgNGlnJ3Q9KBhFPDZ008 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmGzgxQFAwAAAAAACgkQh7ZrRtnSejOS nwgAt0lGTnWWeg5KwAvjnpiQeKr/ODTGtHGN64y3WNJUjzXGqRLp4lcA446x6w8OazGlbY9tpUVH 72LX47LCmGVZVx+qHUFxmhg2mxyUfXIl5uREhVUYXiw5olpXCueez7OV8ZUdQqsS//zPCXSlHXb5 hx4vJ1TIKgzez8tZJuwCi6dH7ZiLGVinfIqGSDDkHZlRuqUbCK/5x99sRdqYBMygJ/1aI979Q455 pfT5lHyV4qzv8yQbOANECLUniAnftU7+lFhgCdx0pIVIYnQtsPUiavPM4oMzfnWK5jslW+IWmFlz z8fSAII5Y0l6ISqQWpdvutR30b8piZ+UPPrNYSb8OA== =ZiT+ -----END PGP SIGNATURE----- --------------iHjEGgNGlnJ3Q9KBhFPDZ008-- From nobody Fri Dec 10 09:09:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78E7D3A0812 for ; Fri, 10 Dec 2021 09:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7EnPyQb8Ubi for ; Fri, 10 Dec 2021 09:09:04 -0800 (PST) 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 11C323A07DB for ; Fri, 10 Dec 2021 09:09:02 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mvjOC-000JYd-7a; Fri, 10 Dec 2021 12:08:56 -0500 Date: Fri, 10 Dec 2021 12:08:50 -0500 From: John C Klensin To: Eliot Lear , Mirja Kuehlewind , rfced-future@iab.org Message-ID: <0F551C75039D59C39BC6734B@PSB> In-Reply-To: <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> 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] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Dec 2021 17:09:09 -0000 --On Friday, December 10, 2021 17:40 +0100 Eliot Lear wrote: >=20 > On 10.12.21 14:31, Mirja Kuehlewind wrote: >>=20 >> We don't necessarily need to specify those details about >> the operation of the RSAB in this or any RFC, however, the >> "may" in the text above seems wrong or at least >> irritating to me. Should we change that? >=20 > The reason it's a "may" is to allow the RSAB to decide who > they need as liaisons.=C2=A0 The RPC is listed as an = example.=C2=A0 > The RSAB may wish to establish *other* liaisons based on their > needs. This was based on discussion that Lucy initiated some > time ago. >=20 > But I would like to understand if you think the RSAB and > members of the RPC cannot meet when they feel they need = to.=C2=A0 > I don't think that was the intent of the text or the group. Eliot, Speaking only for myself... I think there are two separate questions: One is whether the RSAB should be able to decide who they need or want as liaisons, whether they can invite the RPC (or, in the appropriate season, Santa Claus) to meetings, etc. I think the answer to those questions is clearly "yes" and I'd be very concerned if either (i) we needed to make a time-wasting formal ritual a requirement for such interactions or (ii) anything prevented RPC staff from reaching out informally and directly to RSAB members or vice versa at any time and for any reason they felt was appropriate. To be clear, that should include not barring someone saying "time for coffee" at someone's table if and when we resume f2f meetings. The other is whether the RSAB should be meeting without some presence/ representation of the people who are actually doing the day-to-day, down-in-the-trenches work. In this new structure, that means the RPC and, probably with the usual exception for personnel matters, I think the answer is "no -- the RPC needs to be present". If the reasons for that are not clear, I remind people that the IAB (not just the RSOC) excluding Heather from discussions and planning that clearly involved the Series was a reason she cited as leading to her decision to not seek contract renewal and hence leading us into these discussions. Perhaps more important, if we really want a process of informed decision making by the community, leaving the RPC out of RSAB discussions that might turn out to be relevant puts us back on the path toward decisions being made top-down and then perhaps allowing people to protest. john From nobody Fri Dec 10 10:27:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C08513A0A7E for ; Fri, 10 Dec 2021 10:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 9OxJVHqrYSRs for ; Fri, 10 Dec 2021 10:27:46 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D93D3A0A73 for ; Fri, 10 Dec 2021 10:27:46 -0800 (PST) Received: from p200300dee702460081280280a09c2034.dip0.t-ipconnect.de ([2003:de:e702:4600:8128:280:a09c:2034]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mvkcQ-0004MU-3y; Fri, 10 Dec 2021 19:27:42 +0100 From: Mirja Kuehlewind Message-Id: <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_7727E858-AD3C-46AF-B20C-1D6DA944DAE5" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Fri, 10 Dec 2021 19:27:41 +0100 In-Reply-To: <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> Cc: rfced-future@iab.org To: Eliot Lear References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1639160866;a6559d21; X-HE-SMSGID: 1mvkcQ-0004MU-3y Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Dec 2021 18:27:52 -0000 --Apple-Mail=_7727E858-AD3C-46AF-B20C-1D6DA944DAE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Eliot Sorry I should have been clearer about what kind of change I had in = mind. Current the text says: shall have the ED as liaison, and my have others = e.g. RPC I think it should rather say: shall have ED and RPC and may have others As you say below I also think the RSAB and RPC can meet how often they = want and there is noting in the doc that would stop them. But having the = shall there for the ED and only naming the RPC as an example of others = seem to give the impressing that having a liaison to the RPC is less = important. I don=E2=80=99t think that maps the relation between the RSAB = and RPC as described in the rest of the document. Mirja > On 10. Dec 2021, at 17:40, Eliot Lear wrote: >=20 >=20 >=20 > On 10.12.21 14:31, Mirja Kuehlewind wrote: >>=20 >> We don=E2=80=99t necessarily need to specify those details about the = operation of the RSAB in this or any RFC, however, the =E2=80=9Cmay=E2=80=9D= in the text above seems wrong or at least irritating to me. Should we = change that? > The reason it's a "may" is to allow the RSAB to decide who they need = as liaisons. The RPC is listed as an example. The RSAB may wish to = establish other liaisons based on their needs. This was based on = discussion that Lucy initiated some time ago. >=20 > But I would like to understand if you think the RSAB and members of = the RPC cannot meet when they feel they need to. I don't think that was = the intent of the text or the group. >=20 > Eliot >=20 --Apple-Mail=_7727E858-AD3C-46AF-B20C-1D6DA944DAE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Eliot

Sorry I should = have been clearer about what kind of change I had in mind.

Current the text says: = shall have the ED as liaison, and my have others e.g. RPC

I think it should rather = say: shall have ED and RPC and may have others

As you say below I also think the RSAB = and RPC can meet how often they want and there is noting in the doc that = would stop them. But having the shall there for the ED and only naming = the RPC as an example of others seem to give the impressing that having = a liaison to the RPC is less important. I don=E2=80=99t think that maps = the relation between the RSAB and RPC as described in the rest of the = document.

Mirja


On 10. = Dec 2021, at 17:40, Eliot Lear <lear@lear.ch> wrote:

=20 =20


On 10.12.21 14:31, Mirja Kuehlewind wrote:

We don=E2=80=99t necessarily need to specify those = details about the operation of the RSAB in this or any RFC, however, the =E2=80=9Cmay=E2=80=9D in the text above seems wrong or at least = irritating to me. Should we change that?

The reason it's a "may" is to allow the = RSAB to decide who they need as liaisons.  The RPC is listed as an example.  The = RSAB may wish to establish other liaisons based on their = needs.  This was based on discussion that Lucy initiated some time = ago.

But I would like to understand if you think the = RSAB and members of the RPC cannot meet when they feel they need to.  I don't = think that was the intent of the text or the group.

Eliot


= --Apple-Mail=_7727E858-AD3C-46AF-B20C-1D6DA944DAE5-- From nobody Fri Dec 10 11:06:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0433A00DF for ; Fri, 10 Dec 2021 11:05:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 89bpQy9vNviZ for ; Fri, 10 Dec 2021 11:05:52 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17A483A00D3 for ; Fri, 10 Dec 2021 11:05:51 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id 8so9328345qtx.5 for ; Fri, 10 Dec 2021 11:05:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=AadT0A/xHy+pJ0sakFx+gDLa9WPHQE5U56DT3jawBy4=; b=iAv5fT6qRoEA2INbWOEeCl/jQcxOb0V6C5CLhfGtl+BtQptm8uDMxHUS4GCOlnCIbS FtqSPUtfL6SztvEo+aJX3kCZyp9WwH2qbR+LnyKjXMwqFw4W7eOriRvq0nSp18rJ9K3N uzySOstasdbgV+/JSIWG8M4HYCSU48zjM68qctdMp7RNdpVMnKu1J1BHpl8QLhBPhbV1 lv+7ndbl2QgHC2y+yuZYJTVpL5uxksbDKotKAq8oWDo7LykvKKgQGoegsTuS4crraoo8 9kE/iADFdLIS98xbwHf1YVQttHRU6ldGlqcKfYoaQ9rGrp8M6TzYhHCjQa5IJBiN7Xhs O0RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=AadT0A/xHy+pJ0sakFx+gDLa9WPHQE5U56DT3jawBy4=; b=IvF+ebQ2i7CVXaseC5ptBHzuXvfxO+vA4UPJe1WyGL0NLomE89ozzRz+UULX2wn9WZ 0S5auT5LvG6S9e1BhYLBi+UfNCyZFbC0mhfQhunhqJkawMxv+8Eu81hJle22uAKnrSA9 XThl/5On1p4jcrWQ2wMdRVcYTIszRQuKiQnRBvtUBtgx4gInUxL71au4O1zQbYQo+mdA bRnotBTzPLnN/AUbH9S1eFWL5/bt/i2HMI90IGoybdbuBC7bV5RkhnCcXVU0DBoOsRWR MhVWejYHFSB2GwkfneHA8WOlJ07NQUDtIFhSPAX+Jm/Zb6bnt60bzgIjcoxoRYaQUUlR 0b8w== X-Gm-Message-State: AOAM53069N/zlN8QnK+NKyp3S3U6MVJKGu7Ef7fq0waTLxS6+k0+TQaF wl5sw3EJue3oLtKJHWc9AkCpMDOe7ds1igvt X-Google-Smtp-Source: ABdhPJz0UjYskKAsEwPhvhH5Ce+wRgkJ/96GPQXAAcZzvKLSD8CdY6CL8Ohj7adpHyvtJM3tGhAdaA== X-Received: by 2002:a05:622a:7:: with SMTP id x7mr28833433qtw.68.1639163149464; Fri, 10 Dec 2021 11:05:49 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id t6sm1753323qkj.33.2021.12.10.11.05.48 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Dec 2021 11:05:48 -0800 (PST) Content-Type: multipart/alternative; boundary="------------PsQlJCYr33ECkqvP9IhdRFkG" Message-ID: Date: Fri, 10 Dec 2021 14:05:47 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> From: Michael StJohns In-Reply-To: <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Dec 2021 19:05:57 -0000 This is a multi-part message in MIME format. --------------PsQlJCYr33ECkqvP9IhdRFkG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: > Hi Eliot > > Sorry I should have been clearer about what kind of change I had in mind. > > Current the text says: shall have the ED as liaison, and my have > others e.g. RPC > > I think it should rather say: shall have ED and RPC and may have others > > As you say below I also think the RSAB and RPC can meet how often they > want and there is noting in the doc that would stop them. But having > the shall there for the ED and only naming the RPC as an example of > others seem to give the impressing that having a liaison to the RPC is > less important. I don’t think that maps the relation between the RSAB > and RPC as described in the rest of the document. > > Mirja Hi Mirja - I agree with you that the RPC should be represented.  It probably can't be done directively here because of contracts. So "The ED shall be a liaison member of the RSAB.  The entity performing the tasks of the RPC may also appoint a liaison member to the RSAB. Liaisions may participate in all activities of the RSAB as non-voting members."  E.g. the choice is the RPC's not the RSAB's in this case. Mike > > >> On 10. Dec 2021, at 17:40, Eliot Lear wrote: >> >> >> On 10.12.21 14:31, Mirja Kuehlewind wrote: >>> >>> We don’t necessarily need to specify those details about the >>> operation of the RSAB in this or any RFC, however, the “may” in the >>> text above seems wrong or at least irritating to me. Should we >>> change that? >> >> The reason it's a "may" is to allow the RSAB to decide who they need >> as liaisons.  The RPC is listed as an example.  The RSAB may wish to >> establish *other* liaisons based on their needs. This was based on >> discussion that Lucy initiated some time ago. >> >> But I would like to understand if you think the RSAB and members of >> the RPC cannot meet when they feel they need to.  I don't think that >> was the intent of the text or the group. >> >> Eliot >> > > --------------PsQlJCYr33ECkqvP9IhdRFkG Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote:
Hi Eliot

Sorry I should have been clearer about what kind of change I had in mind.

Current the text says: shall have the ED as liaison, and my have others e.g. RPC

I think it should rather say: shall have ED and RPC and may have others

As you say below I also think the RSAB and RPC can meet how often they want and there is noting in the doc that would stop them. But having the shall there for the ED and only naming the RPC as an example of others seem to give the impressing that having a liaison to the RPC is less important. I don’t think that maps the relation between the RSAB and RPC as described in the rest of the document.

Mirja


Hi Mirja -

I agree with you that the RPC should be represented.  It probably can't be done directively here because of contracts. So "The ED shall be a liaison member of the RSAB.  The entity performing the tasks of the RPC may also appoint a liaison member to the RSAB.  Liaisions may participate in all activities of the RSAB as non-voting members."  E.g. the choice is the RPC's not the RSAB's in this case.

Mike





On 10. Dec 2021, at 17:40, Eliot Lear <lear@lear.ch> wrote:


On 10.12.21 14:31, Mirja Kuehlewind wrote:

We don’t necessarily need to specify those details about the operation of the RSAB in this or any RFC, however, the “may” in the text above seems wrong or at least irritating to me. Should we change that?

The reason it's a "may" is to allow the RSAB to decide who they need as liaisons.  The RPC is listed as an example.  The RSAB may wish to establish other liaisons based on their needs.  This was based on discussion that Lucy initiated some time ago.

But I would like to understand if you think the RSAB and members of the RPC cannot meet when they feel they need to.  I don't think that was the intent of the text or the group.

Eliot




--------------PsQlJCYr33ECkqvP9IhdRFkG-- From nobody Fri Dec 10 12:05:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE1B3A074E for ; Fri, 10 Dec 2021 12:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 Na3lsOLYwamm for ; Fri, 10 Dec 2021 12:05:17 -0800 (PST) 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 41D0D3A0788 for ; Fri, 10 Dec 2021 12:05:17 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id m24so6951342pls.10 for ; Fri, 10 Dec 2021 12:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=tXSJIdQD16+ZAWoYmtMI5+y/6Q+5VYi7gizQsLquUHI=; b=YoA8d8tG2+UE3PTJLoI933Y148q83Qxun3CnVKMX9LK+Q38dBDDoFI6tDOond5E9Su VlG80THJ1WlYHo0OUIN4WBxdoStfNytC2GdavfSV3+hZVNakxy+oZP18PP2luFhpxCjO aR0YtvNkp+/03jbgERaFLDoEIQkrBfk00C81e+FSNTRamwGm6grNPtM68Ck7l4vcq5MU VhHaJioaycUHGwo6Ku/GCJEB4SjYj3hEX6nVA3rDVmdGk+wWxqonKxlbmkoqrvfdlCNf P6SP2eRMdk8fGcKXIZ5lTVxi5pRk6PxjW8DDepUx5ZTmyFzlO8DMd4v8YkAA08sKHXPO RYng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=tXSJIdQD16+ZAWoYmtMI5+y/6Q+5VYi7gizQsLquUHI=; b=CYKCg1eAMpxC/LehYcTkHdZh7iljlMO3D9jC3AQE9RLo8DJO8kr7lmNSfZJgEUNu/k zPPyAMP/9eK68SmCtwsMKvpKWNbJt2rNQsMyvKzM34ICpmy6aeH/kEqgcoZ1Axm1wfch cs+wTFJDAznsAM+qQco3buXqmUJWcqy+cqP8rrTyMUUfTB1vFGafYh9nwT/5EUB0+wTI KlMKORO6ktZaNa1b9wWFadzbZA9I0Af42Z+D8wi7z1OM3IFywGTqS0Kgp6o4i0pbF5EP gq4NazwqgBZbdtFIx6ziuhyd6vhowE+aetd11GA4dXoCXVMK5yPNkMuAUBZIhCzTzIG/ o9Pw== X-Gm-Message-State: AOAM530fQWGbljyszlmwOBs1wIwoitwOhkhqg1GYUTRLS09WqxTbBbkl IWhJsz5iqSKQJN+NDnSzmOEIqta8M3g= X-Google-Smtp-Source: ABdhPJxsEsicXYOo75t2Tz/2Qg8nI71IcPg/3vInJIxPlIP5xw/pwDvmisZ0a90w5MU3o7Dow0Qmlw== X-Received: by 2002:a17:90b:612:: with SMTP id gb18mr26383485pjb.0.1639166714799; Fri, 10 Dec 2021 12:05:14 -0800 (PST) Received: from ?IPv6:2406:e003:1071:1701:80b2:5c79:2266:e431? ([2406:e003:1071:1701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id kk7sm15523134pjb.19.2021.12.10.12.05.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 10 Dec 2021 12:05:14 -0800 (PST) To: Michael StJohns , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> From: Brian E Carpenter Message-ID: <909ca446-9b10-c54b-0aa3-300784da97af@gmail.com> Date: Sat, 11 Dec 2021 09:05:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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 Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 Dec 2021 20:05:23 -0000 On 11-Dec-21 08:05, Michael StJohns wrote: > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: >> Hi Eliot >> >> Sorry I should have been clearer about what kind of change I had in mi= nd. >> >> Current the text says: shall have the ED as liaison, and my have other= s e.g. RPC >> >> I think it should rather say: shall have ED and RPC and may have other= s >> >> As you say below I also think the RSAB and RPC can meet how often they=20 want and there is noting in the doc that would stop them. But having the = shall there for the ED and only naming the RPC as an example of others se= em to give the impressing that having a liaison to the RPC is less import= ant. I don=E2=80=99t think that maps the relation between the RSAB and RP= C as described in the rest of the document. >> >> Mirja >=20 >=20 > Hi Mirja - >=20 > I agree with you that the RPC should be represented.=C2=A0 It probably = can't be done directively here because of contracts. So "The ED shall be = a liaison member of the RSAB.=C2=A0 The entity performing the tasks of th= e RPC may also appoint a liaison member to the RSAB. Liaisions may partic= ipate in all activities of the RSAB as non-voting members."=C2=A0 E.g. th= e choice is the RPC's not the RSAB's in this case. Exactly right. The RSAB should be obliged to listen to what the RPC has t= o say, if they wish to say anything. Brian From nobody Sat Dec 11 01:00:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B58253A0A80 for ; Sat, 11 Dec 2021 01:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PolHlakMmuj for ; Sat, 11 Dec 2021 01:00:33 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 210723A0A81 for ; Sat, 11 Dec 2021 01:00:32 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BB90Shc519703 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 11 Dec 2021 10:00:29 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639213229; bh=PKQlUQIPjmBW7PlRMLAXKZG2dxOazP8wOsIOiK7B1sI=; h=Date:To:References:From:Subject:In-Reply-To:From; b=wpubr+fR51Nm46nR+IIf/13IFOZaifAJ1L20WPHdRu9HXmApg3jtB2CFoEephNJmf rkflsUGPl+6/QQ4O6/nw/Ilpeax7QwTVBxGhcggODkLJqfeWrIba26K3el8fsxiPIS EAdUM8HROZ35U7/p4KsK7ox1fxAvOVh6BpvymFGg= Message-ID: Date: Sat, 11 Dec 2021 10:00:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: John C Klensin , Mirja Kuehlewind , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> From: Eliot Lear In-Reply-To: <0F551C75039D59C39BC6734B@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ZtQfiN0HUs9dPP1UdIi4pjMv" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Dec 2021 09:00:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ZtQfiN0HUs9dPP1UdIi4pjMv Content-Type: multipart/mixed; boundary="------------dNd7cVn603NuaaXMn0QcRP4l"; protected-headers="v1" From: Eliot Lear To: John C Klensin , Mirja Kuehlewind , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] RPC liaison to the RSAB References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> In-Reply-To: <0F551C75039D59C39BC6734B@PSB> --------------dNd7cVn603NuaaXMn0QcRP4l Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgSm9obiwNCg0KT24gMTAuMTIuMjEgMTg6MDgsIEpvaG4gQyBLbGVuc2luIHdyb3RlOg0K Pg0KPiAtLU9uIEZyaWRheSwgRGVjZW1iZXIgMTAsIDIwMjEgMTc6NDAgKzAxMDAgRWxpb3Qg TGVhcg0KPiA8bGVhckBsZWFyLmNoPiB3cm90ZToNCj4NCj4+IE9uIDEwLjEyLjIxIDE0OjMx LCBNaXJqYSBLdWVobGV3aW5kIHdyb3RlOg0KPj4+IFdlIGRvbid0IG5lY2Vzc2FyaWx5IG5l ZWQgdG8gc3BlY2lmeSB0aG9zZSBkZXRhaWxzIGFib3V0DQo+Pj4gdGhlIG9wZXJhdGlvbiAg b2YgdGhlIFJTQUIgaW4gdGhpcyBvciBhbnkgUkZDLCBob3dldmVyLCB0aGUNCj4+PiAibWF5 IiBpbiB0aGUgdGV4dCBhYm92ZSAgc2VlbXMgd3Jvbmcgb3IgYXQgbGVhc3QNCj4+PiBpcnJp dGF0aW5nIHRvIG1lLiBTaG91bGQgd2UgY2hhbmdlIHRoYXQ/DQo+PiBUaGUgcmVhc29uIGl0 J3MgYSAibWF5IiBpcyB0byBhbGxvdyB0aGUgUlNBQiB0byBkZWNpZGUgd2hvDQo+PiB0aGV5 IG5lZWQgYXMgbGlhaXNvbnMuwqAgVGhlIFJQQyBpcyBsaXN0ZWQgYXMgYW4gZXhhbXBsZS4N Cj4+IFRoZSBSU0FCIG1heSB3aXNoIHRvIGVzdGFibGlzaCAqb3RoZXIqIGxpYWlzb25zIGJh c2VkIG9uIHRoZWlyDQo+PiBuZWVkcy4gVGhpcyB3YXMgYmFzZWQgb24gZGlzY3Vzc2lvbiB0 aGF0IEx1Y3kgaW5pdGlhdGVkIHNvbWUNCj4+IHRpbWUgYWdvLg0KPj4NCj4+IEJ1dCBJIHdv dWxkIGxpa2UgdG8gdW5kZXJzdGFuZCBpZiB5b3UgdGhpbmsgdGhlIFJTQUIgYW5kDQo+PiBt ZW1iZXJzIG9mIHRoZSBSUEMgY2Fubm90IG1lZXQgd2hlbiB0aGV5IGZlZWwgdGhleSBuZWVk IHRvLg0KPj4gSSBkb24ndCB0aGluayB0aGF0IHdhcyB0aGUgaW50ZW50IG9mIHRoZSB0ZXh0 IG9yIHRoZSBncm91cC4NCj4gRWxpb3QsDQo+DQo+IFNwZWFraW5nIG9ubHkgZm9yIG15c2Vs Zi4uLg0KPg0KPiBJIHRoaW5rIHRoZXJlIGFyZSB0d28gc2VwYXJhdGUgcXVlc3Rpb25zOg0K Pg0KPiBPbmUgaXMgd2hldGhlciB0aGUgUlNBQiBzaG91bGQgYmUgYWJsZSB0byBkZWNpZGUg d2hvIHRoZXkgbmVlZA0KPiBvciB3YW50IGFzIGxpYWlzb25zLCB3aGV0aGVyIHRoZXkgY2Fu IGludml0ZSB0aGUgUlBDIChvciwgaW4gdGhlDQo+IGFwcHJvcHJpYXRlIHNlYXNvbiwgU2Fu dGEgQ2xhdXMpIHRvIG1lZXRpbmdzLCBldGMuICBJIHRoaW5rIHRoZQ0KPiBhbnN3ZXIgdG8g dGhvc2UgcXVlc3Rpb25zIGlzIGNsZWFybHkgInllcyIgYW5kIEknZCBiZSB2ZXJ5DQo+IGNv bmNlcm5lZCBpZiBlaXRoZXIgKGkpIHdlIG5lZWRlZCB0byBtYWtlIGEgdGltZS13YXN0aW5n IGZvcm1hbA0KPiByaXR1YWwgYSByZXF1aXJlbWVudCBmb3Igc3VjaCBpbnRlcmFjdGlvbnMg b3IgKGlpKSBhbnl0aGluZw0KPiBwcmV2ZW50ZWQgUlBDIHN0YWZmIGZyb20gcmVhY2hpbmcg b3V0IGluZm9ybWFsbHkgYW5kIGRpcmVjdGx5IHRvDQo+IFJTQUIgbWVtYmVycyBvciB2aWNl IHZlcnNhIGF0IGFueSB0aW1lIGFuZCBmb3IgYW55IHJlYXNvbiB0aGV5DQo+IGZlbHQgd2Fz IGFwcHJvcHJpYXRlLiAgIFRvIGJlIGNsZWFyLCB0aGF0IHNob3VsZCBpbmNsdWRlIG5vdA0K PiBiYXJyaW5nIHNvbWVvbmUgc2F5aW5nICJ0aW1lIGZvciBjb2ZmZWUiIGF0IHNvbWVvbmUn cyB0YWJsZSBpZg0KPiBhbmQgd2hlbiB3ZSByZXN1bWUgZjJmIG1lZXRpbmdzLg0KDQpSaWdo dC7CoCBEbyB5b3UgYmVsaWV2ZSB0aGUgY3VycmVudCBkb2N1bWVudCBzYXlzIHRoYXQ/DQoN Cg0KPg0KPiBUaGUgb3RoZXIgaXMgd2hldGhlciB0aGUgUlNBQiBzaG91bGQgYmUgbWVldGlu ZyB3aXRob3V0IHNvbWUNCj4gcHJlc2VuY2UvIHJlcHJlc2VudGF0aW9uIG9mIHRoZSBwZW9w bGUgd2hvIGFyZSBhY3R1YWxseSBkb2luZw0KPiB0aGUgZGF5LXRvLWRheSwgZG93bi1pbi10 aGUtdHJlbmNoZXMgd29yay4gIEluIHRoaXMgbmV3DQo+IHN0cnVjdHVyZSwgdGhhdCBtZWFu cyB0aGUgUlBDIGFuZCwgcHJvYmFibHkgd2l0aCB0aGUgdXN1YWwNCj4gZXhjZXB0aW9uIGZv ciBwZXJzb25uZWwgbWF0dGVycywgSSB0aGluayB0aGUgYW5zd2VyIGlzICJubyAtLQ0KPiB0 aGUgUlBDIG5lZWRzIHRvIGJlIHByZXNlbnQiLiAgSWYgdGhlIHJlYXNvbnMgZm9yIHRoYXQg YXJlIG5vdA0KPiBjbGVhciwgSSByZW1pbmQgcGVvcGxlIHRoYXQgdGhlIElBQiAobm90IGp1 c3QgdGhlIFJTT0MpDQo+IGV4Y2x1ZGluZyBIZWF0aGVyIGZyb20gZGlzY3Vzc2lvbnMgYW5k IHBsYW5uaW5nIHRoYXQgY2xlYXJseQ0KPiBpbnZvbHZlZCB0aGUgU2VyaWVzIHdhcyBhIHJl YXNvbiBzaGUgY2l0ZWQgYXMgbGVhZGluZyB0byBoZXINCj4gZGVjaXNpb24gdG8gbm90IHNl ZWsgY29udHJhY3QgcmVuZXdhbCBhbmQgaGVuY2UgbGVhZGluZyB1cyBpbnRvDQo+IHRoZXNl IGRpc2N1c3Npb25zLg0KDQpZb3UgYXJlIHVzaW5nIHR3byB3cm9uZyBhbmFsb2dpZXMuwqAg Rmlyc3QsIHRoZSBSU0NFIGlzIHByZXNlbnQgb24gdGhlIA0KUlNBQiBhcyBhIHZvdGluZyBt ZW1iZXIuwqAgU2Vjb25kLCB0aGUgZnVuZGFtZW50YWwgY2hhbmdlIG9mIHRoaXMgDQpkb2N1 bWVudCBzaGlmdHMgYW4gb3BhcXVlIHByb2Nlc3MgbWFuYWdlZCBieSB0aGUgUlNPQyBhbmQg SUFCIHRvIGEgDQpjb21tdW5pdHktZHJpdmVuIHByb2Nlc3MgaW4gdGhlIFJTV0csIGluIHdo aWNoIGFueW9uZSDigJMgYW55b25lIOKAkyBjYW4gDQpwYXJ0aWNpcGF0ZS7CoCBUaGF0IGlu Y2x1ZGVzIHRoZSBSUEMsIHRvIHRoZSBsaW1pdHMgb2YgcG9saWNpZXMgc2V0IGJ5IA0KdGhl IExMQy7CoCBJbiBmYWN0LCBpdCB3b3VsZCBiZSB2ZXJ5IGJhZCBpZiB0aGUgUlBDIGRpZG4n dCBwYXJ0aWNpcGF0ZSBpbiANCnRoZSB0aGUgUlNXRywgYmVjYXVzZSB0aGV5IGFyZSB0aGUg b25lcyB3aXRoIHRoZSB2ZXJ5IGV4cGVydGlzZSB0aGF0IHlvdSANCndvcnJ5IHRoZSBjb21t dW5pdHkgbWlnaHQgbGFjay4NCg0KRnVydGhlcm1vcmUsIGlmIHRoZXJlIGlzIGEgZm9ybWFs IGxpYWlzb24gZnJvbSB0aGUgUlBDLCB0aGUgRUQgaW4gdGhlIA0KZW5kIHdpbGwgaGF2ZSB0 byBkZWNpZGUgd2hvIGZyb20gdGhlIFJQQyBzaG91bGQgYmUgdGhhdCByZXByZXNlbnRhdGl2 ZSANCnRvIHRoZSBSU0FCLsKgIEhlIGFscmVhZHkgaGFzIHRoZSBjYXBhYmlsaXR5IHVuZGVy IHRoZSBjdXJyZW50IHRleHQgdG8gDQpicmluZyB0aGUgUlBDIGluLCBhbmQgc28gZG9lcyB0 aGUgUlNBQi4NCg0KQW5kIHRoaXMgd2FzIGxpdGlnYXRlZCwgYW5kIG5vdyB3ZSBhcmUgcmVs aXRpZ2F0aW5nLg0KDQpFbGlvdA0KDQo= --------------dNd7cVn603NuaaXMn0QcRP4l-- --------------ZtQfiN0HUs9dPP1UdIi4pjMv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG0aKoFAwAAAAAACgkQh7ZrRtnSejPa 4wf/W3u+VzT9EJZLauUx1nP8dNJPyKnP455s3PQMum6J6fFBPZGQbfgNlAz8HATFlUDo3ltiIbeo //LjRSJdCnyWNH4Ju4YIdwIXcpt8WJCy5Qatwx5bEliPkqUMOc/qWuX7E5yagRYl2tDVBuPhvf4f OTdRFb6aVG7T6ppXyxdqJfdzfHleQiGil2J74MTPe5mhZM3E8opQm6f15tCeZgBUZgwoEDCRju/z +t9vM236CJkuiZXGk2XryG8jpTGMR5XE8dlcFi5+NhWkeIuOwj/xWo2el1j2VsWpRBt72jOvXbBV THFdxF54HoO7rNT5Q0+nSzEtBsa+bzwJtAfInfZFuA== =Xqj5 -----END PGP SIGNATURE----- --------------ZtQfiN0HUs9dPP1UdIi4pjMv-- From nobody Sat Dec 11 03:52:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8B23A0128 for ; Sat, 11 Dec 2021 03:52:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Lkpl80BF3jqh for ; Sat, 11 Dec 2021 03:52:32 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 318923A012A for ; Sat, 11 Dec 2021 03:52:32 -0800 (PST) Received: from p200300dee7299200d0dd22c3f0369953.dip0.t-ipconnect.de ([2003:de:e729:9200:d0dd:22c3:f036:9953]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mw0vS-000401-4E; Sat, 11 Dec 2021 12:52:26 +0100 From: Mirja Kuehlewind Message-Id: <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> Content-Type: multipart/alternative; boundary="Apple-Mail=_975E6ACC-D606-44B5-912F-2CD0E83377BB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Sat, 11 Dec 2021 12:52:25 +0100 In-Reply-To: Cc: John C Klensin , rfced-future@iab.org To: Eliot Lear References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1639223552;1c90fe2b; X-HE-SMSGID: 1mw0vS-000401-4E Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Dec 2021 11:52:36 -0000 --Apple-Mail=_975E6ACC-D606-44B5-912F-2CD0E83377BB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please see below. > On 11. Dec 2021, at 10:00, Eliot Lear wrote: >=20 > Hi John, >=20 > On 10.12.21 18:08, John C Klensin wrote: >>=20 >> --On Friday, December 10, 2021 17:40 +0100 Eliot Lear >> wrote: >>=20 >>> On 10.12.21 14:31, Mirja Kuehlewind wrote: >>>> We don't necessarily need to specify those details about >>>> the operation of the RSAB in this or any RFC, however, the >>>> "may" in the text above seems wrong or at least >>>> irritating to me. Should we change that? >>> The reason it's a "may" is to allow the RSAB to decide who >>> they need as liaisons. The RPC is listed as an example. >>> The RSAB may wish to establish *other* liaisons based on their >>> needs. This was based on discussion that Lucy initiated some >>> time ago. >>>=20 >>> But I would like to understand if you think the RSAB and >>> members of the RPC cannot meet when they feel they need to. >>> I don't think that was the intent of the text or the group. >> Eliot, >>=20 >> Speaking only for myself... >>=20 >> I think there are two separate questions: >>=20 >> One is whether the RSAB should be able to decide who they need >> or want as liaisons, whether they can invite the RPC (or, in the >> appropriate season, Santa Claus) to meetings, etc. I think the >> answer to those questions is clearly "yes" and I'd be very >> concerned if either (i) we needed to make a time-wasting formal >> ritual a requirement for such interactions or (ii) anything >> prevented RPC staff from reaching out informally and directly to >> RSAB members or vice versa at any time and for any reason they >> felt was appropriate. To be clear, that should include not >> barring someone saying "time for coffee" at someone's table if >> and when we resume f2f meetings. >=20 > Right. Do you believe the current document says that? >=20 >=20 >>=20 >> The other is whether the RSAB should be meeting without some >> presence/ representation of the people who are actually doing >> the day-to-day, down-in-the-trenches work. In this new >> structure, that means the RPC and, probably with the usual >> exception for personnel matters, I think the answer is "no -- >> the RPC needs to be present". If the reasons for that are not >> clear, I remind people that the IAB (not just the RSOC) >> excluding Heather from discussions and planning that clearly >> involved the Series was a reason she cited as leading to her >> decision to not seek contract renewal and hence leading us into >> these discussions. >=20 > You are using two wrong analogies. First, the RSCE is present on the = RSAB as a voting member. Second, the fundamental change of this = document shifts an opaque process managed by the RSOC and IAB to a = community-driven process in the RSWG, in which anyone =E2=80=93 anyone = =E2=80=93 can participate. That includes the RPC, to the limits of = policies set by the LLC. In fact, it would be very bad if the RPC = didn't participate in the the RSWG, because they are the ones with the = very expertise that you worry the community might lack. The RSE was present in RSOC and in the IAB (also the wording is a = liaison from the RFC Editor function, so the RSE could probably also = have named someone else), however, the RSCE is not a replace for the = RSE. The RSE was kind of providing a bride between the RPC and the = IAB/RSOC, however, as you also say I thought that one point of this is = also to have the RPC more directly involved rather than taking this = indirect route. Yes, they can participate in the RSWG of course but the = discussion is about the role of the RPC in the RSAB and we also have = this text in the draft: =E2=80=9DIf issues arise with the implementation of particular policies, = the RPC brings those issues to the RSAB, which interprets the policies = and provides interim guidance to the RPC, informing the RSWG of those = interpretations.=E2=80=9D and=20 The RPC is advised by the RSCE and RSAB, and has a duty to consult with = them under specific circumstances, such as those relating to = disagreements between authors and the RPC. I was assuming that this consultation is best done by having a = representative of the RPC in the RSAB meeting and on the RSAB mailing = list. However, the text about liaison I cited in my initial email gives = a different impression.=20 If my assumption is wrong I think it would be helpful to clarify in the = document how this consultation should work otherwise. However, if other = people in this program also assume that the RPC would be present at = meetings and the mailing list we should write that down. This part has = cause uncertainty in the RPC about how the future process is supposed to = work and that=E2=80=99s to me a sign that we are currently not clear = enough about this in the document. As a reference, the IESG charter has the follow sentence: In addition, members of the IETF Secretariat are subscribed to the mailing list and present in the IESG meetings as needed in order to serve as a support function. Actually maybe this is also something we should add regarding the = secretariat. And a similar sentence about the RPC would do it for me as = well, e.g. Further, members of the RPC are subscribed to the mailing list and present in the IESG meetings as needed in order to facilitate expedited consultation. Mirja >=20 > Furthermore, if there is a formal liaison from the RPC, the ED in the = end will have to decide who from the RPC should be that representative = to the RSAB. He already has the capability under the current text to = bring the RPC in, and so does the RSAB. >=20 > And this was litigated, and now we are relitigating. >=20 > Eliot >=20 --Apple-Mail=_975E6ACC-D606-44B5-912F-2CD0E83377BB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Please see below.

On 11. Dec 2021, at 10:00, = Eliot Lear <lear@lear.ch> wrote:

Hi = John,

On 10.12.21 18:08, John C Klensin = wrote:

--On Friday, December 10, 2021 17:40 +0100 Eliot Lear
<lear@lear.ch> wrote:

On 10.12.21 14:31, Mirja = Kuehlewind wrote:
We = don't necessarily need to specify those details about
the = operation  of the RSAB in this or any RFC, however, the
"may" in the text above  seems wrong or at least
irritating to me. Should we change that?
The reason it's a "may" is to allow the RSAB to = decide who
they need as liaisons.  The RPC is listed = as an example.
The RSAB may wish to establish *other* = liaisons based on their
needs. This was based on = discussion that Lucy initiated some
time ago.

But I would like to understand if you think = the RSAB and
members of the RPC cannot meet when they feel = they need to.
I don't think that was the intent of the = text or the group.
Eliot,

Speaking only for myself...

I = think there are two separate questions:

One = is whether the RSAB should be able to decide who they need
or want as liaisons, whether they can invite the RPC (or, in = the
appropriate season, Santa Claus) to meetings, etc. =  I think the
answer to those questions is clearly = "yes" and I'd be very
concerned if either (i) we needed to = make a time-wasting formal
ritual a requirement for such = interactions or (ii) anything
prevented RPC staff from = reaching out informally and directly to
RSAB members or = vice versa at any time and for any reason they
felt was = appropriate.   To be clear, that should include not
barring someone saying "time for coffee" at someone's table = if
and when we resume f2f meetings.

Right.  Do you believe the = current document says that?



The other = is whether the RSAB should be meeting without some
presence/= representation of the people who are actually doing
the = day-to-day, down-in-the-trenches work.  In this new
structure, that means the RPC and, probably with the usual
exception for personnel matters, I think the answer is "no = --
the RPC needs to be present".  If the reasons for = that are not
clear, I remind people that the IAB (not just = the RSOC)
excluding Heather from discussions and planning = that clearly
involved the Series was a reason she cited as = leading to her
decision to not seek contract renewal and = hence leading us into
these discussions.

You are using two wrong = analogies.  First, the RSCE is present on the RSAB as a voting = member.  Second, the fundamental change of this document shifts an = opaque process managed by the RSOC and IAB to a community-driven process = in the RSWG, in which anyone =E2=80=93 anyone =E2=80=93 can = participate.  That includes the RPC, to the limits of policies set = by the LLC.  In fact, it would be very bad if the RPC didn't = participate in the the RSWG, because they are the ones with the very = expertise that you worry the community might lack.

The = RSE was present in RSOC and in the IAB (also the wording is a liaison = from the RFC Editor function, so the RSE could probably also have named = someone else), however, the RSCE is not a replace for the RSE. The RSE = was kind of providing a bride between the RPC and the IAB/RSOC, however, = as you also say I thought that one point of this is also to have the RPC = more directly involved rather than taking this indirect route. Yes, they = can participate in the RSWG of course but the discussion is about the = role of the RPC in the RSAB and we also have this text in the = draft:

=E2=80=9DIf issues arise with the implementation of = particular policies, the = RPC brings those issues to the RSAB, which interprets = the policies and provides interim = guidance to the RPC, informing the RSWG= of those interpretations.=E2=80=9D

and 

The = RPC is advised by the RSCE and RSAB, and has a duty to = consult with them under specific = circumstances, such as those relating to disagreements between authors and the = RPC.

I was assuming that this = consultation is best done by having a representative of the RPC in the = RSAB meeting and on the RSAB mailing list. However, the text about = liaison I cited in my initial email gives a different = impression. 

If my assumption is wrong I think it would be helpful to = clarify in the document how this consultation should work otherwise. = However, if other people in this program also assume that the RPC would = be present at meetings and the mailing list we should write that down. = This part has cause uncertainty in the RPC about how the future process = is supposed to work and that=E2=80=99s to me a sign that we are = currently not clear enough about this in the document.

As a reference, the IESG = charter has the follow sentence:

In addition, members of the =
IETF Secretariat are subscribed to the
   mailing list and present in the IESG meetings as needed in order to
   serve as a support function.

Actually maybe this is also = something we should add regarding the secretariat. And a similar = sentence about the RPC would do it for me as well, e.g.

Further, members of the RPC are =
subscribed to the
   mailing list and present in the IESG meetings as needed in order to
   facilitate expedited consultation.


Mirja




Furthermore, if there is a = formal liaison from the RPC, the ED in the end will have to decide who = from the RPC should be that representative to the RSAB.  He already = has the capability under the current text to bring the RPC in, and so = does the RSAB.

And this was litigated, and = now we are relitigating.

Eliot


= --Apple-Mail=_975E6ACC-D606-44B5-912F-2CD0E83377BB-- From nobody Sat Dec 11 12:06:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FB13A003C for ; Sat, 11 Dec 2021 12:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 0anbqcDS8ZZM for ; Sat, 11 Dec 2021 12:06:46 -0800 (PST) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94AE3A003B for ; Sat, 11 Dec 2021 12:06:45 -0800 (PST) Received: by mail-pg1-x530.google.com with SMTP id m15so10925684pgu.11 for ; Sat, 11 Dec 2021 12:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=UcEQP70Tt1E7NQdj80W/IMCOP4iuZ/am8pO+gtuFkZM=; b=botZFPDOo5Wjebi6rLBwLEcx/W9n2NrBTJNAqakLelrRZDDPrKn677YzZhTP/+nWpi 4qqX5/SONL2DMkvLFbv/NA5dzGhRBC8uQCHkY23y/D7sR0FxM1nhIdBOg9yzHTTyZ80O e29XTotTtZQyu/6lI7jtHC+H0oOGPAp3lUmKU3dRiuwa0KIzUilXrSrTJTMC74uOiZwk ftbyl+ZWYN3M0vuMMzyPCr90Oz8IF+7Sd+GOY4fJ4d/ialpIRIay2lviAyTVlr5E4fKZ 3HueOJ6DVMQAAtumlNDlGlL3XeYZmzRMeUFVfaRzn3Jyg4RRpDm5XDN7Am/oQoNOlA/d fQzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=UcEQP70Tt1E7NQdj80W/IMCOP4iuZ/am8pO+gtuFkZM=; b=5Nl2hHj5jzM14/L8AxQ9j2YmfcaZbnbucaLI8viEYFeyxsBnHks8sXF/vzCOUE6Tnn 4TGHF/2LRcPrUL5R4sqdMpbamsLKk57exXYM39gQlE0fL0iXPyTsBdr/m0ZgyyyHTfr3 AuhcQgKif2s4ns+QpMUd07PbOSHy7JglnA5q4nboS+vCBv/uHYeF4Zp2/RYRsPAtcQR1 pJa3izrDuUXHdR5AUg7ynHNVH6sSDLa2VsNXpD+HviaRFpvS1zAQ/eefRC+8rBYd1OHc GVX9pWjiKqSNtAdAmcz+Q+9XKAHO6kyvlUyL830L0nUP75nB6wOGiTR3cUirBakFNo56 r0+w== X-Gm-Message-State: AOAM533a5Jz/CgygtGbYYJ29DQl3PVrUxlanVHFLNi+4wBJkeAztDgxU Zjqm59ux2n3HPJZD0cxiBJ8fzz9fekAP3g== X-Google-Smtp-Source: ABdhPJxB/v0xZGRQ8/+dgWBl2/+J702hBDiU7/7NsVQKHAecJASo43JwEpi+lj9Ln/jbFXBlnWkhfQ== X-Received: by 2002:a63:87c7:: with SMTP id i190mr1411074pge.93.1639253204167; Sat, 11 Dec 2021 12:06:44 -0800 (PST) Received: from ?IPv6:2406:e003:1071:1701:80b2:5c79:2266:e431? ([2406:e003:1071:1701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id n71sm7561172pfd.50.2021.12.11.12.06.42 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 11 Dec 2021 12:06:43 -0800 (PST) To: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> From: Brian E Carpenter Message-ID: <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> Date: Sun, 12 Dec 2021 09:06:39 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 Dec 2021 20:06:51 -0000 Comment below (and a possible new issue...) On 12-Dec-21 00:52, Mirja Kuehlewind wrote: > Please see below. >=20 >> On 11. Dec 2021, at 10:00, Eliot Lear > wrote: >> >> Hi John, >> >> On 10.12.21 18:08, John C Klensin wrote: >>> >>> --On Friday, December 10, 2021 17:40 +0100 Eliot Lear >>> > wrote: >>> >>>> On 10.12.21 14:31, Mirja Kuehlewind wrote: >>>>> We don't necessarily need to specify those details about >>>>> the operation =C2=A0of the RSAB in this or any RFC, however, the >>>>> "may" in the text above =C2=A0seems wrong or at least >>>>> irritating to me. Should we change that? >>>> The reason it's a "may" is to allow the RSAB to decide who >>>> they need as liaisons.=C2=A0 The RPC is listed as an example. >>>> The RSAB may wish to establish *other* liaisons based on their >>>> needs. This was based on discussion that Lucy initiated some >>>> time ago. >>>> >>>> But I would like to understand if you think the RSAB and >>>> members of the RPC cannot meet when they feel they need to. >>>> I don't think that was the intent of the text or the group. >>> Eliot, >>> >>> Speaking only for myself... >>> >>> I think there are two separate questions: >>> >>> One is whether the RSAB should be able to decide who they need >>> or want as liaisons, whether they can invite the RPC (or, in the >>> appropriate season, Santa Claus) to meetings, etc. =C2=A0I think the >>> answer to those questions is clearly "yes" and I'd be very >>> concerned if either (i) we needed to make a time-wasting formal >>> ritual a requirement for such interactions or (ii) anything >>> prevented RPC staff from reaching out informally and directly to >>> RSAB members or vice versa at any time and for any reason they >>> felt was appropriate. =C2=A0=C2=A0To be clear, that should include no= t >>> barring someone saying "time for coffee" at someone's table if >>> and when we resume f2f meetings. >> >> Right.=C2=A0 Do you believe the current document says that? >> >> >>> >>> The other is whether the RSAB should be meeting without some >>> presence/ representation of the people who are actually doing >>> the day-to-day, down-in-the-trenches work. =C2=A0In this new >>> structure, that means the RPC and, probably with the usual >>> exception for personnel matters, I think the answer is "no -- >>> the RPC needs to be present". =C2=A0If the reasons for that are not >>> clear, I remind people that the IAB (not just the RSOC) >>> excluding Heather from discussions and planning that clearly >>> involved the Series was a reason she cited as leading to her >>> decision to not seek contract renewal and hence leading us into >>> these discussions. >> >> You are using two wrong analogies.=C2=A0 First, the RSCE is present on=20 the RSAB as a voting member.=C2=A0 Second, the fundamental change of this=20 document shifts an opaque process managed by the RSOC and IAB to a commun= ity-driven process in the RSWG, in which anyone =E2=80=93 anyone =E2=80=93=20 can participate.=C2=A0 That includes the RPC, to the limits of policies s= et by the LLC.=C2=A0 In fact, it would be very bad if the RPC didn't part= icipate in the the RSWG, because they are the ones with the very expertis= e that you worry the community might lack. >=20 > The RSE was present in RSOC and in the IAB (also the wording is a liais= on from the RFC Editor function, so the RSE could probably also have name= d someone else), however, the RSCE is not a replace for the RSE. The RSE = was kind of providing a bride between the RPC and the IAB/RSOC, however, = as you also say I thought that one point of this is also to have the RPC = more directly involved rather than taking this indirect route. Yes, they = can participate in the RSWG of course but the discussion is about the rol= e of the RPC in the RSAB and we also have this text in the draft: >=20 > =E2=80=9DIf issues arise with the implementation of particular policies= , the RPC brings those issues to the RSAB, which interprets the policies = and provides interim guidance to the RPC, informing the RSWG of those int= erpretations.=E2=80=9D >=20 > and >=20 > The RPC is advised by the RSCE and RSAB, and has a duty to consult with=20 them under specific circumstances, such as those relating to disagreement= s between authors and the RPC. >=20 > I was assuming that this consultation is best done by having a represen= tative of the RPC in the RSAB meeting and on the RSAB mailing list. Howev= er, the text about liaison I cited in my initial email gives a different = impression. >=20 > If my assumption is wrong I think it would be helpful to clarify in the=20 document how this consultation should work otherwise. However, if other p= eople in this program also assume that the RPC would be present at meetin= gs and the mailing list we should write that down. This part has cause un= certainty in the RPC about how the future process is supposed to work and=20 that=E2=80=99s to me a sign that we are currently not clear enough about = this in the document. >=20 > As a reference, the IESG charter has the follow sentence: >=20 > In addition, members of the IETF Secretariat are subscribed to the > mailing list and present in the IESG meetings as needed in order to= > serve as a support function. >=20 >=20 > Actually maybe this is also something we should add regarding the secre= tariat. And a similar sentence about the RPC would do it for me as well, = e.g. >=20 > Further, members of the RPC are subscribed to the > mailing list and present in the IESG meetings as needed in order to= > =C2=A0facilitate expedited consultation. I think you mean "RSAB meetings". I don't like the word "meetings" anyway= , because it's still my hope that the RSAB needs very few meetings and in=20 general has very little work. (The work gets done in the working group.) Also, I don't think the analogy with the Secretariat is correct. The Secr= etariat staff do what used to be called secretarial work for the IESG. (T= hese days, for reasons that baffle me, it's considered more dignified to = call it "admin".) The RPC staff don't work *for* the RSAB in any such way= =2E There's no reason that all of them need to read RSAB email. So I prefer yesterday's formulation of a direct RPC liaison to the RSAB. = But then when I look at draft-iab-rfcefdp-rfced-model-06, I see that it's=20 already covered, at the RSAB's discretion. If you really want a new issue, here's one: As far as I can see, we don't=20 specify whether the RSAB's mailing list does, or doesn't, have a public a= rchive. Brian > Mirja >=20 >=20 >=20 >> >> Furthermore, if there is a formal liaison from the RPC, the ED in the = end will have to decide who from the RPC should be that representative to=20 the RSAB.=C2=A0 He already has the capability under the current text to b= ring the RPC in, and so does the RSAB. >> >> And this was litigated, and now we are relitigating. >> >> Eliot From nobody Sun Dec 12 00:36:02 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA933A08A4 for ; Sun, 12 Dec 2021 00:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=jjTcR29K; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BgnhfcXa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ay_6RxnriHJG for ; Sun, 12 Dec 2021 00:35:50 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50363A08A0 for ; Sun, 12 Dec 2021 00:35:50 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EF9E55C0156 for ; Sun, 12 Dec 2021 02:39:27 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Sun, 12 Dec 2021 02:39:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=sQ+Ti5P5R3g i3PMXwqq1z3jBkg8AN24AWL/jAznvyTc=; b=jjTcR29K7QwZqmrbh2FNwzd/z+H qp0VvDZrxvQK/V9TzxebT0EiIgFnoePExJQNs7Ir19RKcgiKl44HXF95IfStgief VyZR3P3PTFiZ8nMy8lNHUMwQlyKsTZq+1Ekq2/ZwyNqwdXRpHYImmw1vLrEc/VOq Js9Wbzfin6XJyBmDty8Ul6fhdn3MyDcgNQ/mUUv+lX0ops44eIOvwCl79x1tr643 pEmmOf6gDw0Z9Qv5XY0LK89+1B6lrjdUc2selxceJTmyoZPY+gZrBLXXuC6gnKKg V7V9NcgmjRk6BE6fF4WheojsQ3MaNNacGCmJXv00s9iCpoDCWrqMaXQFfng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=sQ+Ti5P5R3gi3PMXwqq1z3jBkg8AN24AWL/jAznvyTc=; b=BgnhfcXa JmCiIepcGgvM4lkmL94LVbnT3vd4JD96wj1SHF1VRJ5tEYFVYttqHJDFxBqPdvJv kl+y+l8NWLNEiNSHG8BhDYil1HYP63zKsf8ZBkz7hzHhzilwX+yB8q8BB24hTrbE kMsNDeMgPYR6MxzLMzdhZAxtcoRP7ozF0b9slbGZTVtYhLu90pBWLlwm72k+RmvR qoojN/i451lMptXGSBDDk+SjqPvm/slQAvBMlf5aYRALg0XKz00e0CmoYKIxw0TD r/Rh4iV98b8fZOsWT6ItmqCBytACGS5BGNV3viR2ZfBS86SRsK+gGxqLeqLEZ7gK 8kR3EDA+7hVXjg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrkeehgddutdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 12 Dec 2021 02:39:27 -0500 (EST) Content-Type: multipart/alternative; boundary="===============2150733070457415949==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: rfced-future@iab.org Message-Id: <20211212083550.A50363A08A0@ietfa.amsl.com> Date: Sun, 12 Dec 2021 00:35:50 -0800 (PST) Archived-At: Subject: [Rfced-future] Weekly github digest (RFC Editor Future Development Program Activity Summary) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 Dec 2021 08:35:56 -0000 --===============2150733070457415949== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events=20 Issues ------ * intarchboard/program-rfced-future (+2/-0/=F0=9F=92=AC0) 2 issues created: - Improve Community Calls for Comment (by stpeter) https://github.com/intarchboard/program-rfced-future/issues/139=20 - Requests of the IETF Trust (by stpeter) https://github.com/intarchboard/program-rfced-future/issues/138=20 Pull requests ------------- * intarchboard/program-rfced-future (+3/-0/=F0=9F=92=AC8) 3 pull requests submitted: - address #138 (by stpeter) https://github.com/intarchboard/program-rfced-future/pull/142=20 - address #119 (by stpeter) https://github.com/intarchboard/program-rfced-future/pull/141=20 - address #139 (by stpeter) https://github.com/intarchboard/program-rfced-future/pull/140=20 3 pull requests received 8 new comments: - #142 add requests for IETF Trust (1 by stpeter) https://github.com/intarchboard/program-rfced-future/pull/142=20 - #141 improve text about Community Calls for Comment etc. (3 by becarpen= ter, martinthomson, stpeter) https://github.com/intarchboard/program-rfced-future/pull/141=20 - #140 add Historical Properties text (4 by adamroach, becarpenter, stpet= er) https://github.com/intarchboard/program-rfced-future/pull/140=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/program-rfced-future --===============2150733070457415949== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (RFC Editor Future Development Program Activity= Summary)

Sunday December 12, 2021

Events

Issues

intarchboard/program-rfced-future (+2/-0/=F0=9F=92=AC0)

2 issues created:

Pull requests

intarchboard/program-rfced-future (+3/-0/=F0=9F=92=AC8)

3 pull requests submitted:

3 pull requests received 8 new comments:

Repositories tracked by this digest:
--===============2150733070457415949==-- From nobody Mon Dec 13 15:16:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6573A0C0E for ; Mon, 13 Dec 2021 15:16:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=uXIbjFM8; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PbKbuoHT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vs_xAuga7ZBs for ; Mon, 13 Dec 2021 15:16:29 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 309623A0C35 for ; Mon, 13 Dec 2021 15:16:29 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 1A0493200A2F; Mon, 13 Dec 2021 18:16:28 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 13 Dec 2021 18:16:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:references:to:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=g XZTlMY6Wemo512Tj7BuMCRpWzaE5ufdOzAVfIFAjhE=; b=uXIbjFM8xhAoQn2FI bh5QexCV5DlQumlBaYGmll8D9N/BOT/zFHTlcmWrToUCt8V5t67HMX6Iqz4UmCcm 6ETRfdIFn557PjECzcZH+Mga07XE6TU3RJ09CD+9YugbxaxbkIUKU83HlreFw9lA RjsoMOjRJQZIiTAVSqe4je+dtR8uK5lteWVhtfg3L7rC4InTduSfdSMQn9+vO6qL jC6jrwNmg1fJARmHZKPttkh0XPs8vMRcUdPmemyZDNyA+iGRAQf1fPpeVZ2kCZX7 0nX79dUFtnlVJ1Ui1Mx4UDAUg5oJ1L2FHH6dl8WCUoOCxURqwbr55LWHxihRNJ8C tbyEg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=gXZTlMY6Wemo512Tj7BuMCRpWzaE5ufdOzAVfIFAj hE=; b=PbKbuoHTI18tlW6q7QvuNWM7+2/ftGpWuNZ5DKifgOGybt54hogubKSfD FqXxsUfpTX3I+0xqUMlbt95Wdz6UecPIAdaQi5ymErW8WOlh19vLTXKJL0ebbtz4 Euv5DFCeNHnHy0FnKQo/vZIqDrkw6PlcTjJA3Ow2wH+7+rHugahTBgPUt2psivja H8+et5OtC7UibhOAZt4LV3GcT6WwC0Irp17tV27jwKjvWUzMMYxhg0dVSnp+hTJc TbnX64qMQyvJW7ADt9oJIT3VYMnS2/bljt3em4xp6AkOD94AZMuc4IBb3fkX0IQz Hq1E4wpjGVlJrBg9hw5QFxwRRpLxw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrkeelgddtlecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfufhfvffhjggtgfesthejre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepteegtdfgfeehleetie ehveeltdeiteevfefftdehkefhhfeltdelfeeltdfgieegnecuffhomhgrihhnpehivght fhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehsthhpvghtvghrsehsthhpvghtvghrrdhimh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Dec 2021 18:16:27 -0500 (EST) Message-ID: <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> Date: Mon, 13 Dec 2021 16:16:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> Content-Language: en-US To: "rfced-future@iab.org" From: Peter Saint-Andre In-Reply-To: <163943716470.11925.12473737358937211066@ietfa.amsl.com> X-Forwarded-Message-Id: <163943716470.11925.12473737358937211066@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 23:16:34 -0000 Hi all, I've just now submitted version -07 of our document, which I think addresses all of the feedback received on version -06. If I have missed anything, please let me know by posting on the list or by filing a GitHub issue. Thanks! Peter -------- Forwarded Message -------- Subject: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt Date: Mon, 13 Dec 2021 15:12:44 -0800 From: internet-drafts@ietf.org To: Peter Saint-Andre A new version of I-D, draft-iab-rfcefdp-rfced-model-07.txt has been successfully submitted by Peter Saint-Andre and posted to the IETF repository. Name: draft-iab-rfcefdp-rfced-model Revision: 07 Title: RFC Editor Model (Version 3) Document date: 2021-12-13 Group: iab Pages: 29 URL: https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07.txt Status: https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-model/ Html: https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07.html Htmlized: https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model Diff: https://www.ietf.org/rfcdiff?url2=draft-iab-rfcefdp-rfced-model-07 Abstract: This document specifies version 3 of the RFC Editor Model. The model defines two high-level tasks related to the RFC Series. First, policy definition is the joint responsibility of the RFC Series Working Group (RSWG), which produces policy proposals, and the RFC Series Approval Board (RSAB), which approves such proposals. Second, policy implementation is primarily the responsibility of the RFC Production Center (RPC) as contractually overseen by the IETF Administration Limited Liability Company (IETF LLC). This document obsoletes RFC 8728. This document updates RFC 7841, RFC 8729, and RFC 8730. The IETF Secretariat From nobody Mon Dec 13 15:38:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61B2E3A0C69 for ; Mon, 13 Dec 2021 15:38:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.853 X-Spam-Level: X-Spam-Status: No, score=-3.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 EGsvqF6Rb2Ae for ; Mon, 13 Dec 2021 15:38:05 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130093.outbound.protection.outlook.com [40.107.13.93]) (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 55CC33A0EDA for ; Mon, 13 Dec 2021 15:37:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LDC1hSBXJlr3CT7vzWSDc0IsvhpiAkQYHQQ2vxxTlZ/bbEhmOl5g0HmTGCSOOmNcFZIIEdRCvZdA+WzMf/DdHdFIJB+rqKULaZAwaNEKHDOSULRS29zg3Id2amEtLjCPpb/XMilA538eP2DGFdexqBySnBoH/CKpsm6PfyKdIs+4ryV6oYA0iYaNHabiBY8C2SuVkL7VxpCwvVZ4iWSneSlVirE5IakWAHD8fX6d/Y6HKXpz1Ye+0jTM+L3M7XZ6PWi7mx5qClxRX97KSwOobEjM+qaWw7oW6tqjn1FNGNTxsu0U8hvDGyHWSkEXXOfKxcY+40CARPQO6j3yyfGWew== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=GoSs23GnKhyj5rk7PCtJ412IvXQZ6PGh/k6Rg0+RaDc=; b=HrMhrnN6zmLwK3OPu2+USLmiphDT54JgvdebjnpLqpgAVafWIkTSp5MWD9E5o02MJRyUyOPpbDZMgo3QkMFB4tOdEBOyWXEJ/Uga5lLAxXuRp8GgMrrv2mHS2z6EB8u+i7NTzCh8uAto6RPDp+qNkBfPapBrQy6UMjt/GTCGOD+joiI9kkwPWSKVEY7Bgs5w/D0l++O8ztYk5ps5EgdapvA/DIKidl2mcBtCkvWt19MG6VpCjTvzzTZxoZrYLJUuGtGhbUkNSoK9c3+IAeABSl6t76LzrwEjO383r9dFhWwp62PoHCVT++HDS/+IJ88G1Y8i/o28spUN9QCcdKyeHA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GoSs23GnKhyj5rk7PCtJ412IvXQZ6PGh/k6Rg0+RaDc=; b=jFsFA0muQpcOX+cxyl4JRkA6RfEECcwp1N0a8Hsf3N7iS9jhevFEdJEPj5zbP+a9AxsaRiFQPLqpASUnY202hFC101uKospGKkfiBDVydYdPfewowx5tib3Zz+ckjJSm0wPTCcpY6ahmnYROvD3jR/eARiWygd6xpyEXcYRFPhV45eNGBSlk5omPJgGE7/a/mYXx7N5SFy1b6asULx/iulh1P2x0d2OmYFKVo0D+zE5PDp975RliSUz0761h0eq2R0n+g5rII/NI/x5PFEzTvwTmPVwl5dqhYIwaUa8j7OUK6Kf2H+qQcT8IelnMJCVMpxgcwwxTF6X+RKGL48EcjQ== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB6PR0202MB2741.eurprd02.prod.outlook.com (2603:10a6:4:aa::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.22; Mon, 13 Dec 2021 23:37:18 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea%4]) with mapi id 15.20.4778.018; Mon, 13 Dec 2021 23:37:18 +0000 Message-ID: <7e2b6366-ae9a-9c5c-5573-db73ade513e3@cs.tcd.ie> Date: Mon, 13 Dec 2021 23:37:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Peter Saint-Andre , "rfced-future@iab.org" References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> From: Stephen Farrell In-Reply-To: <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------JKJLX0BbzoAz0GQfav01ohLE" X-ClientProxiedBy: DU2PR04CA0178.eurprd04.prod.outlook.com (2603:10a6:10:2b0::33) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 9c7c4333-4cc1-4712-00ea-08d9be91809a X-MS-TrafficTypeDiagnostic: DB6PR0202MB2741:EE_ X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:2089; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: kOhJkZegkib5onzDAC5ihOYSblGBucaFTy/92V7n3TRko/UbwTEK/SH5lyvtwdXpy4IgQricP+EP8r85MWdVhzqtgLuH0pahGQLM37KqtoDOVximTOHOm6f9icmaKeO9LPhtn//GZT/abBue9x0GjOJDskCnyht6zw5vZM1VI2x3xz5RiKEQK18iMxIrRPX99fZNMLfskeSyzWhLtBL5+RNVkJx4ReYKg/wE/gJ0th25zrT+JZe5byf9Z5SbB7FDBZIOPZTKaY4Je5Eyd9iBlSgQRxPedxPspMXWhGWUXGpvPRy8JRb4E54PfUyIfvE2PapNOZP4tSfse780CNlkUfa46amOyJB4PBdaOMD9Tq5WyIivfhPXvDDU5E2wWeH06Hq6rIB6C3FhOsreoVbNh+W40hYf5KEoQeL1NdJsEeMuGF0B3bttDRvMGQjO2VqlqcdYyPTaBjG/939UBUxgwmG1GtpPGwSl0LLMyGcEZm4aVmnp9F3pn2KjXnoaVcLPE078z5O1p7sh4TBOAzkSAMk7HJ8oTG6Ut92IgNjY1Q6tHpRo5OSRCB7WjXa+IKB7gWPQjWMgKgaiu8J6E4ZBQPgsHQwmZSZ8Xgd/9NkUy4y81+pXbLpVAl442kJCge0DkYHIvy1oHni7sCj+uhBcfscSO6EDpFnkrlHmgxsgMJknO8l439lJJfyco7/J1dKQs6IYT+DfkC8j1o6OPtB5MXwXzjQs3SkAjUUsmPoQ2hmiknKYDnBDgNp5Fa8kA3e+r3Q48DsGiLDrCTG9YHGj6gE9NnFgX+5nIRJZLBqgg02fBvEGKrMJm1DgjZxTIMqBdpz+jTqUuLL5ABtt1mahBbDgnhhWvYKdWtODq/MRcUM= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(66556008)(53546011)(66476007)(31696002)(2906002)(508600001)(6512007)(86362001)(83380400001)(15650500001)(36756003)(66574015)(966005)(2616005)(21480400003)(66946007)(6506007)(8936002)(235185007)(786003)(8676002)(44832011)(5660300002)(31686004)(4001150100001)(316002)(38100700002)(110136005)(6486002)(33964004)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dStGc0dadUtlWW1DSHRrcUozUHJVMEJQWVdQTUZuak5RcGVUYW1VM21kV2ZX?= =?utf-8?B?dXBPeng5MUpqZDZXZEIrT2krU00rdVZ6eFdkLytFdjhOUmpCYitTakh1K05m?= =?utf-8?B?ZjEzcFd1RDg3R3hwdWZNOFh1dGFiN3pteTZzMGZDUW4rK05FTWJvQkV5ZUxr?= =?utf-8?B?aG54dkxWeEI1VFA0RlZKdnlQcHk3UzE4L0NLVnVUYUpTQTFPdGxuaUp6TCs1?= =?utf-8?B?dG5XM0psRnZWUWY2TndidmR3SWZLZ2kvZ0R5U0VmWXJOMnVzaGpyN1V2ektj?= =?utf-8?B?NlI2d0szaXZCUjVxUW9iazUrRGk5cEtnaDlyemY4RU5SNGpaQ2hOSFhBY2lL?= =?utf-8?B?eXNuTFRQWDhkTkpEY1JCVnY1S0VZWmZzSERrZGtIajJqMGtCZk5FWGN4YlRY?= =?utf-8?B?UnFHZ2xpQ1Y5TVkzVEtibCtLU0VvbXU2WHNuQUJ0R1pJQm5xU0xLc3ViS1Bh?= =?utf-8?B?NzlOMHBRRHNYZG8yUlZURkdJaDQ1QmRGd0IzUUxFVk5RM3R1RHhQZHlEdVdm?= =?utf-8?B?NXhDYyt4TzR6U1pkMVdObXR0N1g1NmFvK3pDbTJCSlROVE1yWEs4NXBoS3Z4?= =?utf-8?B?Y0RxM1ZhVTMxUWdGUHJFeEMycm4reVNWUGptR3NxZGo1MjdOejFYdzdSc1RE?= =?utf-8?B?MHhoMDU1QzhQYzB0SnpCMFc1dm8zUXdQVUxsSTRxOUt4ZXVTT1J5OW1heC82?= =?utf-8?B?L0Rpckpua05ldXowUG1hV3ZObE8rTzZiNWxCY3grY09NaE1TV1NPQTJlbDZa?= =?utf-8?B?bC9Hamh0L2VBMHVqcEVLUVA4TUR0cEdZRWpEZ1RMZlltMmE5QlVLUDNJNG52?= =?utf-8?B?cVlPYWE0YjJiUmFENEFCb2dWMUp2QnJUbVNHNm9sdExJL3ZkTWNXMExUdTd5?= =?utf-8?B?YW16TXJtSU5hL3Q1YmI5MHYycVpKVmpHb0pBNlZza3k4Z09hQ2s1SU1KMzdT?= =?utf-8?B?UWFqdmNhUmF5Um1kMVUwQlZPMUdTRHhEOU1lamZyTnNIOXZvbGpaTXNWdVph?= =?utf-8?B?b2xDMjRpUi8waWhZeU84TTlmenhiWndEdDQ2ZklKaXY3cWJmOSsrMXNXK0Za?= =?utf-8?B?T0I2UVFyellVZWxoL05CVmRtZEFHYnhWK0p4NlU0MWhYRnFBM1Z0UmlvNmZI?= =?utf-8?B?S1NLWjI0bEJGb2FYanFyUEw3a05BenBibEZjRG1QL3ZmU29UcUVyS3ZmRE1J?= =?utf-8?B?SWwvc0N0S0ozZ2dxMDB1bXBXbkx6dit4alRNRDRrb3dzR1NUaWUxMXRzN0J1?= =?utf-8?B?WTdJSmgzeVlnK3ZLTkI2Q1hXbmNQOEpWQkZFWnJEL1l1aFdJczAwckd0K1o5?= =?utf-8?B?cmJ0K0VXNVZKYStPTTI1aVhnMmEwbk5KQ0c1ZERNTW5jL2diMnRmaFhzMkFJ?= =?utf-8?B?RGZuYlVydTVzNGJtanBvSTZ4QkErUXExemc0aVF4TVJ6d1ZsdlZPR0N1MWpi?= =?utf-8?B?TldPSDJ3VEhDeG03T3lHTkc1aWNwaTk4V2RwejdPZ0Jib0M0SS9aRUlETG94?= =?utf-8?B?SVR0OUFEOUlTQlBTZCtaQ0lnV3RvVmp3L0R1QUY5ekZXRXJWNUdiVzVyRzQ3?= =?utf-8?B?QmZxM3RKR0xlQVZ0a3NyVERhOXFtSk9XUVR5bmhLVU52T25WVHQyb3l4NDlV?= =?utf-8?B?Z2ZhNFFjVERYWkdZdUNGNmVzU2wva2xyQVVKWElTa3loa3BtbGtXZk81YjNX?= =?utf-8?B?bC9sSy9FSy9sMk1QVVN4eDJTQlk4MFYwd0RmYmZPWHFidk54ZXZyeTQzSEcy?= =?utf-8?B?Vm5oRWZtNzRIY0IrTEJFeEd6QUhCZ3FycFpNOXUyZzROeFZ5bWJxK2RpTUJ6?= =?utf-8?B?S3BYR2ZUaSt3MjdxM2VDUFBzTE5QZ2sxTjA0RHdWQURhY0dnQWZIQllsMjd5?= =?utf-8?B?VEpxcGVtblJ2SFJ5MC9PQmNJbzQ5bUZsL2Vma1BNN0pGRXBXWHNQbUxueW5p?= =?utf-8?B?U2lHMS9pV2Y3NmZXK0orakUvRlp4OEpCVVBEenp1cW4yQlVpWmZvanplUno5?= =?utf-8?B?LzdkTFQxMllpS082ZVNQQUJyY3ZNdUkwa21mbWZ4cm91Z1ZDMytwODZpOStB?= =?utf-8?B?U0J2aTE4bFI1bW5lZGZ6bTd6Z0pDdStOZ0RRMm1yV0FFbVQ4NnJtYXU1WGFN?= =?utf-8?B?bGNWNXBXbFpBNm5admRGeDlxRTlPUFZYM0ZRd29DUUowMzM3T0ZpNktTWjY5?= =?utf-8?Q?4/g2f5+N3i0eiSGNMf/JxzM=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: 9c7c4333-4cc1-4712-00ea-08d9be91809a X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2021 23:37:18.8226 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: VQVe37htDpg87WOk6EN6TcCWdkTE5lcDYzpJ+BEVC7Do22JpzwBXqFUoY9j75eG9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0202MB2741 Archived-At: Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 23:38:11 -0000 --------------JKJLX0BbzoAz0GQfav01ohLE Content-Type: multipart/mixed; boundary="------------wsHgT4l1Fai6fUdWmWP0IShR"; protected-headers="v1" From: Stephen Farrell To: Peter Saint-Andre , "rfced-future@iab.org" Message-ID: <7e2b6366-ae9a-9c5c-5573-db73ade513e3@cs.tcd.ie> Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> In-Reply-To: <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> --------------wsHgT4l1Fai6fUdWmWP0IShR Content-Type: multipart/mixed; boundary="------------KnrPzjZNRcqKdboMqMjDn1g0" --------------KnrPzjZNRcqKdboMqMjDn1g0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpIaXlhLA0KDQpPbiAxMy8xMi8yMDIxIDIzOjE2LCBQZXRlciBTYWludC1BbmRyZSB3cm90 ZToNCj4gSGkgYWxsLCBJJ3ZlIGp1c3Qgbm93IHN1Ym1pdHRlZCB2ZXJzaW9uIC0wNyBvZiBv dXIgZG9jdW1lbnQsIHdoaWNoIEkgDQo+IHRoaW5rIGFkZHJlc3NlcyBhbGwgb2YgdGhlIGZl ZWRiYWNrIHJlY2VpdmVkIG9uIHZlcnNpb24gLTA2LiBJZiBJIGhhdmUgDQo+IG1pc3NlZCBh bnl0aGluZywgcGxlYXNlIGxldCBtZSBrbm93IGJ5IHBvc3Rpbmcgb24gdGhlIGxpc3Qgb3Ig YnkgZmlsaW5nIA0KPiBhIEdpdEh1YiBpc3N1ZS4NCg0KSSBqdXN0IGNoZWNrZWQgdGhlIGRp ZmYgYW5kIGl0IGxvb2tzIGdvb2QgdG8gbWUuDQoNClRoYW5rcywNClMuDQoNCj4gDQo+IFRo YW5rcyENCj4gDQo+IFBldGVyDQo+IA0KPiAtLS0tLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAt LS0tLS0tLQ0KPiBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LWlhYi1yZmNlZmRwLXJmY2VkLW1vZGVsLTA3LnR4dA0KPiBEYXRlOiBNb24sIDEzIERlYyAy MDIxIDE1OjEyOjQ0IC0wODAwDQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0K PiBUbzogUGV0ZXIgU2FpbnQtQW5kcmUgPHN0cGV0ZXJAc3RwZXRlci5pbT4NCj4gDQo+IA0K PiBBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtaWFiLXJmY2VmZHAtcmZjZWQtbW9kZWwt MDcudHh0DQo+IGhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGV0ZXIgU2Fp bnQtQW5kcmUgYW5kIHBvc3RlZCB0byB0aGUNCj4gSUVURiByZXBvc2l0b3J5Lg0KPiANCj4g TmFtZTrCoMKgwqDCoMKgwqDCoCBkcmFmdC1pYWItcmZjZWZkcC1yZmNlZC1tb2RlbA0KPiBS ZXZpc2lvbjrCoMKgwqAgMDcNCj4gVGl0bGU6wqDCoMKgwqDCoMKgwqAgUkZDIEVkaXRvciBN b2RlbCAoVmVyc2lvbiAzKQ0KPiBEb2N1bWVudCBkYXRlOsKgwqDCoCAyMDIxLTEyLTEzDQo+ IEdyb3VwOsKgwqDCoMKgwqDCoMKgIGlhYg0KPiBQYWdlczrCoMKgwqDCoMKgwqDCoCAyOQ0K PiBVUkw6IGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWFiLXJmY2Vm ZHAtcmZjZWQtbW9kZWwtMDcudHh0DQo+IFN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWFiLXJmY2VmZHAtcmZjZWQtbW9kZWwvDQo+IEh0bWw6IGh0 dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWFiLXJmY2VmZHAtcmZjZWQt bW9kZWwtMDcuaHRtbA0KPiBIdG1saXplZDogDQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWFiLXJmY2VmZHAtcmZjZWQtbW9kZWwNCj4gRGlmZjog aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlhYi1yZmNlZmRwLXJm Y2VkLW1vZGVsLTA3DQo+IA0KPiBBYnN0cmFjdDoNCj4gIMKgwqAgVGhpcyBkb2N1bWVudCBz cGVjaWZpZXMgdmVyc2lvbiAzIG9mIHRoZSBSRkMgRWRpdG9yIE1vZGVsLsKgIFRoZSBtb2Rl bA0KPiAgwqDCoCBkZWZpbmVzIHR3byBoaWdoLWxldmVsIHRhc2tzIHJlbGF0ZWQgdG8gdGhl IFJGQyBTZXJpZXMuwqAgRmlyc3QsDQo+ICDCoMKgIHBvbGljeSBkZWZpbml0aW9uIGlzIHRo ZSBqb2ludCByZXNwb25zaWJpbGl0eSBvZiB0aGUgUkZDIFNlcmllcw0KPiAgwqDCoCBXb3Jr aW5nIEdyb3VwIChSU1dHKSwgd2hpY2ggcHJvZHVjZXMgcG9saWN5IHByb3Bvc2FscywgYW5k IHRoZSBSRkMNCj4gIMKgwqAgU2VyaWVzIEFwcHJvdmFsIEJvYXJkIChSU0FCKSwgd2hpY2gg YXBwcm92ZXMgc3VjaCBwcm9wb3NhbHMuwqAgU2Vjb25kLA0KPiAgwqDCoCBwb2xpY3kgaW1w bGVtZW50YXRpb24gaXMgcHJpbWFyaWx5IHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgUkZD DQo+ICDCoMKgIFByb2R1Y3Rpb24gQ2VudGVyIChSUEMpIGFzIGNvbnRyYWN0dWFsbHkgb3Zl cnNlZW4gYnkgdGhlIElFVEYNCj4gIMKgwqAgQWRtaW5pc3RyYXRpb24gTGltaXRlZCBMaWFi aWxpdHkgQ29tcGFueSAoSUVURiBMTEMpLg0KPiANCj4gIMKgwqAgVGhpcyBkb2N1bWVudCBv YnNvbGV0ZXMgUkZDIDg3MjguwqAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIFJGQyA3ODQxLA0K PiAgwqDCoCBSRkMgODcyOSwgYW5kIFJGQyA4NzMwLg0KPiANCj4gDQo+IA0KPiANCj4gVGhl IElFVEYgU2VjcmV0YXJpYXQNCj4gDQo+IA0K --------------KnrPzjZNRcqKdboMqMjDn1g0 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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 zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 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+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC 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 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK 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+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb 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 Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R 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/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK 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+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB 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 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+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 =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------KnrPzjZNRcqKdboMqMjDn1g0-- --------------wsHgT4l1Fai6fUdWmWP0IShR-- --------------JKJLX0BbzoAz0GQfav01ohLE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmG32S0FAwAAAAAACgkQWrL68XsXK+o/ vg//Y5WeF223hYDzy37j+KU5V+O/MJ4RiRNrssWsS0Um8l20yxIye/UoMJodnQCO/SX9Fs3ZAXmU j375J3FHclB+9PZOu2Aw+x9PYBvD1AyNYVWrOhSVmfpRlDL9kdHmFYqsq7z7tHGHBLAIcTdWlRbj +5xk0t1HDUFIJRCoRACr2CO4GQqAd4YgL83RsF/br0B1IutiTbpI37k0d3uK759mRZ2+hv6ZUtjP nkZsgihNyODhvBpylk/o1lZ9Z1VII6IXcgc2sxU8ld4olYGH97T+tOszyluySSm0Yo6lVTToG2K9 7SjCrNrlN2JxKKmnIQTndoe1zGmr8jf4BnumnYP8pRi0tmhnf49eiORXzEjdKpNL53Nn9ai7KutS WWkTjbLuftHSLnx5vklE6n1kEC/Du1pMXUPfbSWANmBjQhXcnbtR6sU1V87wEvJyqIF9vdQp2l/M 4jzZzq/Z2pxZpqfvYjgmsFQ95pNm+ZWMmy9D4uaS2BpL8nzNEVnM65mupB30Kda5GdloX+HulEV2 +JQfql21nvyHrFgK/GyFHJraMgGDYzHOJzZSAWaXTuJCXGIqqRw/7juffSo/G7CQ2woOPBZBXnHm +7tyea/wJ7kj/U9BwDgKc+ZEWz3Auj0o1cuA1mVtBcBf1OZMq+Y6+0EGvRb0lTnHadM9olADK59j UZQ= =tEYH -----END PGP SIGNATURE----- --------------JKJLX0BbzoAz0GQfav01ohLE-- From nobody Mon Dec 13 15:56:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC51E3A0C94 for ; Mon, 13 Dec 2021 15:56:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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 YJ_QGkRwIkR5 for ; Mon, 13 Dec 2021 15:56:19 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A5DF3A0C40 for ; Mon, 13 Dec 2021 15:56:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4JCdh266hDz6GZFJ; Mon, 13 Dec 2021 15:56:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1639439778; bh=NN6ugiXr5zVwLgG7UbGxURuJyS+hpHU+SL9XgwzPIpo=; h=Date:Subject:To:References:From:In-Reply-To:From; b=CrJlr2szCjU2+9EdFiRlW4I8jTenm0rvg6Cl2l4HES8IzxjjD2YqsDJxIxjt4kxQV c70Aucr80U7Iu5nWtWWYPumJBQwGY6GjpPfiQ3jPhuhs/x+I/gJowDc+b9MngI7xjI n/73eRwvAQJGrTvltMsY94t0j6bF5L0TlLjxxKMw= X-Quarantine-ID: <1bayZLvJAEpR> X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4JCdh21gHtz6GZDt; Mon, 13 Dec 2021 15:56:17 -0800 (PST) Message-ID: Date: Mon, 13 Dec 2021 18:56:15 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Peter Saint-Andre , "rfced-future@iab.org" References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> From: "Joel M. Halpern" In-Reply-To: <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Dec 2021 23:56:24 -0000 Thank you. I looked at the diffs and this does even better than I had hoped. Yours, Joel On 12/13/2021 6:16 PM, Peter Saint-Andre wrote: > Hi all, I've just now submitted version -07 of our document, which I > think addresses all of the feedback received on version -06. If I have > missed anything, please let me know by posting on the list or by filing > a GitHub issue. > > Thanks! > > Peter > > -------- Forwarded Message -------- > Subject: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt > Date: Mon, 13 Dec 2021 15:12:44 -0800 > From: internet-drafts@ietf.org > To: Peter Saint-Andre > > > A new version of I-D, draft-iab-rfcefdp-rfced-model-07.txt > has been successfully submitted by Peter Saint-Andre and posted to the > IETF repository. > > Name:        draft-iab-rfcefdp-rfced-model > Revision:    07 > Title:        RFC Editor Model (Version 3) > Document date:    2021-12-13 > Group:        iab > Pages:        29 > URL: https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07.txt > Status: https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-model/ > Html: https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07.html > Htmlized: > https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model > Diff: https://www.ietf.org/rfcdiff?url2=draft-iab-rfcefdp-rfced-model-07 > > Abstract: >    This document specifies version 3 of the RFC Editor Model.  The model >    defines two high-level tasks related to the RFC Series.  First, >    policy definition is the joint responsibility of the RFC Series >    Working Group (RSWG), which produces policy proposals, and the RFC >    Series Approval Board (RSAB), which approves such proposals.  Second, >    policy implementation is primarily the responsibility of the RFC >    Production Center (RPC) as contractually overseen by the IETF >    Administration Limited Liability Company (IETF LLC). > >    This document obsoletes RFC 8728.  This document updates RFC 7841, >    RFC 8729, and RFC 8730. > > > > > The IETF Secretariat > > From nobody Mon Dec 13 16:28:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F91B3A0CC5 for ; Mon, 13 Dec 2021 16:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=DbTAQodJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=cAHowHF0 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kEnSfcrhhR66 for ; Mon, 13 Dec 2021 16:28:50 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C18BD3A0CC6 for ; Mon, 13 Dec 2021 16:28:50 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 564353200F3F; Mon, 13 Dec 2021 19:28:44 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 13 Dec 2021 19:28:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=D No1r2oKfkctztIs94b/8v9hhqru2CwTaMyLCXDICsM=; b=DbTAQodJ6r+uhC6Jo Qq5eDANc8Si+nIlHNrd+c/05JWd2L0NkCAtb40ca7cepg1Sbsnu/S5rSYLeCURUU b+X3XJiSyBYrC7Ov2aSZmI1qiUA8DBBSlhv9vL7krYnZnglXgZu2TdVmkTF03igG lsd+FNzghDZXc/5qx+RKuo+q/Ic/57bLbhY9Ik9zKmHBAgIyjZHh1a14p7sqNYMC uZ/h2gXIrMZmobaFTnVzyLK6Ky5oA3ojdKPoyRwEB6z0XYNjr/L54bFuj3kUX+Wu 89b8wqV8gtl0p+eqOLHUve5pb2v3yU1sreKWaydz1TMOLcK8YpfH5iHkHVgTix+a 6qA6w== 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=fm1; bh=DNo1r2oKfkctztIs94b/8v9hhqru2CwTaMyLCXDIC sM=; b=cAHowHF0zbqOfbHTSgxxEMekA5qCB2YBvJNG/aox9/dy+dipJHOvIRZQQ aXL5B9MSyCFtrWuUNtDGoXI/KVGw49kr189KVoa28NVJZh5tiP1QQOlP35k5nNwB 9i200caWPQEoJFt4yfs/2vhFhlOiRtFbYPJoiMuWJqpnuQpscpIc7u1K1aKrlnny wPKp3EfgXIoZGB1CSdNCLuksmboBv7zfFYB/wvX9EFdbZ2Oi3AtZfIqMNcvzPjLe CXtU3J6qxk2kMSX1hqYhoI81pJjdHKCo/FCbewzrKnuo+Ze8A40J5EdfeJmj3S7F smzUBAeF70U4MURnS+yMXP8I4A+/Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrkeelgddvfecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeforghrkhcu pfhothhtihhnghhhrghmuceomhhnohhtsehmnhhothdrnhgvtheqnecuggftrfgrthhtvg hrnhepieetudduvdduffettdduvdeghedtueehheejgeeltdelkeevgfffheefffeffffg necuffhomhgrihhnpehivghtfhdrohhrghdpihgrsgdrohhrghdpmhhnohhtrdhnvghtne cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohht sehmnhhothdrnhgvth X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Dec 2021 19:28:41 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Mark Nottingham In-Reply-To: <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> Date: Tue, 14 Dec 2021 11:28:39 +1100 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4A893774-2CA2-450E-AC10-2A67DD77EAC0@mnot.net> References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Rfced-future] New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 00:28:55 -0000 Hi Peter,=20 Thanks. Reading through, I found some potential ambiguities: * This text in 3.1.2: """ Voting on approval of policy documents produced by the RSWG shall be = delayed until the vacancy or vacancies have been filled, up to a maximum = of 3 months; this clause does not apply to a vacancy of the RSCE role, = only of the stream representatives enumerated above. If during this = 3-month period a further vacancy arises, the delay should be extended by = up to another 3 months. """ is slightly ambiguous. Does 'this clause' refer to the entire sentence = preceding it, or the phrase 'up to a maximum of 3 months'? My assumption = is that it's the former (the entire sentence). * In 3.2.4: """ Decisions of the RSAB can be appealed on grounds of failure to follow = the correct process. Where the RSAB makes a decision in order to resolve = a disagreement between authors and the RPC (as described under Section = 4.4), appeals can be filed on the basis that the RSAB misinterpreted an = approved policy. In other cases, disagreements about the conduct of the = RSAB are not subject to appeal. """ The 'in other cases' clause is ambiguous here -- does it apply to just = the precedent sentence, or the two preceding sentences? Cheers, > On 14 Dec 2021, at 10:16 am, Peter Saint-Andre = wrote: >=20 > Hi all, I've just now submitted version -07 of our document, which I = think addresses all of the feedback received on version -06. If I have = missed anything, please let me know by posting on the list or by filing = a GitHub issue. >=20 > Thanks! >=20 > Peter >=20 > -------- Forwarded Message -------- > Subject: New Version Notification for = draft-iab-rfcefdp-rfced-model-07.txt > Date: Mon, 13 Dec 2021 15:12:44 -0800 > From: internet-drafts@ietf.org > To: Peter Saint-Andre >=20 >=20 > A new version of I-D, draft-iab-rfcefdp-rfced-model-07.txt > has been successfully submitted by Peter Saint-Andre and posted to the > IETF repository. >=20 > Name: draft-iab-rfcefdp-rfced-model > Revision: 07 > Title: RFC Editor Model (Version 3) > Document date: 2021-12-13 > Group: iab > Pages: 29 > URL: = https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07.txt > Status: = https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-model/ > Html: = https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07.html > Htmlized: = https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfced-model > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-rfcefdp-rfced-model-07 >=20 > Abstract: > This document specifies version 3 of the RFC Editor Model. The = model > defines two high-level tasks related to the RFC Series. First, > policy definition is the joint responsibility of the RFC Series > Working Group (RSWG), which produces policy proposals, and the RFC > Series Approval Board (RSAB), which approves such proposals. = Second, > policy implementation is primarily the responsibility of the RFC > Production Center (RPC) as contractually overseen by the IETF > Administration Limited Liability Company (IETF LLC). >=20 > This document obsoletes RFC 8728. This document updates RFC 7841, > RFC 8729, and RFC 8730. >=20 >=20 >=20 > The IETF Secretariat >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Mon Dec 13 16:43:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73C13A0CDB for ; Mon, 13 Dec 2021 16:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=IsUPvMkY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MQlLf7uB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tcrc0CcwuGWO for ; Mon, 13 Dec 2021 16:43:07 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DA513A0CDA for ; Mon, 13 Dec 2021 16:43:06 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id ECF543200E5D; Mon, 13 Dec 2021 19:43:03 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 13 Dec 2021 19:43:04 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:to:cc:references:from:subject :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=k C73aifqNzGwQj1qvDey/Cu0RWghG3Z2sUy8zmJfNGE=; b=IsUPvMkY8SMYuHvZU TlLGYFZw4ivLBlACf11E8Tp54o1OE7f2ZPRPn3Id2ivsinUAGIWYhc7XGcjY4mjX RJeng0WmTG+HGsyYIEZUsCIVZlT5o/FLX9dbG1YKKw59jTS5y3ytlunv17KF5g6T fbyGWnUHjHEcBWKgE3It31C0Rw/yFLZI9Gp+xF618nxq1MjZLTrEsKtu0WwlPp9D SGxtsZwmqU8oR0BNpis8U/2St5qmIkGwmhGtYoEqpLvsr1riWd4dlIcD+DKgVRFO s1R3pm+CXy97U+XirOmAHVnAMXHe8t01RALB60kkSXlXYG8boKkEY2J4MmzDCXbx eT82A== 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=fm1; bh=kC73aifqNzGwQj1qvDey/Cu0RWghG3Z2sUy8zmJfN GE=; b=MQlLf7uBWqt9Hjz54GWa3D5UD1rj8nf7x9/+kWgQs8tK+++8K+qcSabnI qcySYP+5nqqYz47G4m1bt4VspiUxjab+hGIDQDzB9GFspuu5u31Hj4ULfTWaOC4w sK4QLBTtZNMkibdD3eqlBwEIETf7Rw+9jNmhixbrMAi/B2sG4I5hxNZYoHW+zNkY C+DoIjCq4/xU+MY24bUCuzSnem9N59no3bYB3TRkwH9mE4a2YwaJ3IZxCP3VYWTm ok3gagVWX1I/BqIeia2FhBA5tD3safN3yd3/nLmIxMwhL10Pgbuyy+4pphKTB+W1 a8mqUdQ1JhSMqxxSvtybBrnb25U6g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrkeelgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfvfhfhufgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvghtvghr ucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqeenuc ggtffrrghtthgvrhhnpefgleekveevlefgheejuefhheeuhfekfedtfffggefhgeetvdeg iefgvdekledtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehsthhpvghtvghrsehsthhpvghtvghrrdhimh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 13 Dec 2021 19:43:02 -0500 (EST) Message-ID: Date: Mon, 13 Dec 2021 17:42:58 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Mark Nottingham Cc: "rfced-future@iab.org" References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> <4A893774-2CA2-450E-AC10-2A67DD77EAC0@mnot.net> From: Peter Saint-Andre In-Reply-To: <4A893774-2CA2-450E-AC10-2A67DD77EAC0@mnot.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 00:43:13 -0000 Hi Mark, Thanks for your review. On 12/13/21 5:28 PM, Mark Nottingham wrote: > Hi Peter, > > Thanks. Reading through, I found some potential ambiguities: > > * This text in 3.1.2: > > """ > Voting on approval of policy documents produced by the RSWG shall be delayed until the vacancy or vacancies have been filled, up to a maximum of 3 months; this clause does not apply to a vacancy of the RSCE role, only of the stream representatives enumerated above. If during this 3-month period a further vacancy arises, the delay should be extended by up to another 3 months. > """ > > is slightly ambiguous. Does 'this clause' refer to the entire sentence preceding it, or the phrase 'up to a maximum of 3 months'? My assumption is that it's the former (the entire sentence). Yes, we should perhaps say "this rule". > * In 3.2.4: > > """ > Decisions of the RSAB can be appealed on grounds of failure to follow the correct process. Where the RSAB makes a decision in order to resolve a disagreement between authors and the RPC (as described under Section 4.4), appeals can be filed on the basis that the RSAB misinterpreted an approved policy. In other cases, disagreements about the conduct of the RSAB are not subject to appeal. > """ > > The 'in other cases' clause is ambiguous here -- does it apply to just the precedent sentence, or the two preceding sentences? I'll work to clear this up, but I've understood it to be the two preceding sentences. Peter From nobody Mon Dec 13 19:24:11 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65AF3A0E30 for ; Mon, 13 Dec 2021 19:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 MJVsPiM_lFaB for ; Mon, 13 Dec 2021 19:24:05 -0800 (PST) Received: from mail-pl1-x636.google.com (mail-pl1-x636.google.com [IPv6:2607:f8b0:4864:20::636]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF99D3A0E2F for ; Mon, 13 Dec 2021 19:24:05 -0800 (PST) Received: by mail-pl1-x636.google.com with SMTP id v19so12614279plo.7 for ; Mon, 13 Dec 2021 19:24:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=0BaPUOEtDpqXrB9utqcSDogRHcoE5t1WttCzUMLbz44=; b=Atqb/J075rMlSGt4hthF2kzWrgx6J4W/u5gO5301+pvGzh+6vL/TSFbs7XKxFcT47f brcWUwVtSEhHAb+Yv4JNQwn5cKvidoxNG8KE/chdiKzU/LKBS53FlCvRIk3z7CEWEbMh +AZ8N+CNcCqpbkof+yyr/N0pF4O14cOWYwsvSP24kypXlZVRXcssO/BLcHFGjZDnZyTW 7lvPvRCNst9TEhaq0SGpMIYS7ZrjmY1RuXWYFm06AdphfSxpr0WvzdXSLLW0dB5R0AxD HN3/JzuejF9BmJWMBrIuDOQ7Docjjpu8deoy5cYQ4AOzX+/ZQGb3XNcgCPV62hkMX4V/ rPKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=0BaPUOEtDpqXrB9utqcSDogRHcoE5t1WttCzUMLbz44=; b=JdJ29GN4pEHNvV8mEzcACgwUIDKqXf4nlDqq0ShHpTIf2N+ZHUKH37h9oIWb0ZLRld eZDEuebNrE+Rx/AZrt8MlIz9bggBHR8tMQL2aolFamn8zTPbUwGRAc7CzUWUHqkfzDUT 0WizKZ0QsS44sUBJT2u85+2ygVqgzZnNsTbz9xqfE2Xbfk8eA6WidJ25Mci3V4TbsOMD DXepmHkyWuRfTWMZy1+lElJD25oPtTFK7NxeWFphIRp0F50IehDAShz5iBnzY0RduCK0 Do7ehmvb+RX1VgoS1egcqRKDgKBvVfDSy6G0fj7xsRbO6CsjRlY1ZouoG5OBq2Tb0/Wt TAwA== X-Gm-Message-State: AOAM531t4ssPSlt3o0CGnOF4lnEg+wQn8UpZvi8FIsvHRy7XPQxw73aI Pc+Pek7PDrAbTDBYzaJPok5Zjm/GLFyvdw== X-Google-Smtp-Source: ABdhPJwmKckVqOqb9osHHMzUQYI4gKDlEW0q/rKQtUH8kO0GCQBsPG/Lk2gYw0lqLRaniPxgfTN7/A== X-Received: by 2002:a17:90a:6a82:: with SMTP id u2mr2712324pjj.105.1639452244428; Mon, 13 Dec 2021 19:24:04 -0800 (PST) Received: from ?IPv6:2406:e003:1071:1701:80b2:5c79:2266:e431? ([2406:e003:1071:1701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id om8sm505958pjb.12.2021.12.13.19.24.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 13 Dec 2021 19:24:03 -0800 (PST) To: Peter Saint-Andre , Mark Nottingham Cc: "rfced-future@iab.org" References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> <4A893774-2CA2-450E-AC10-2A67DD77EAC0@mnot.net> From: Brian E Carpenter Message-ID: <24aefb9c-f0bd-6ee7-a54b-563d55ad7954@gmail.com> Date: Tue, 14 Dec 2021 16:24:00 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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] New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 03:24:10 -0000 I'm happy with the new draft, and also with Peter's interpretations below. Regards Brian On 14-Dec-21 13:42, Peter Saint-Andre wrote: > Hi Mark, > > Thanks for your review. > > On 12/13/21 5:28 PM, Mark Nottingham wrote: >> Hi Peter, >> >> Thanks. Reading through, I found some potential ambiguities: >> >> * This text in 3.1.2: >> >> """ >> Voting on approval of policy documents produced by the RSWG shall be delayed until the vacancy or vacancies have been filled, up to a maximum of 3 months; this clause does not apply to a vacancy of the RSCE role, only of the stream representatives enumerated above. If during this 3-month period a further vacancy arises, the delay should be extended by up to another 3 months. >> """ >> >> is slightly ambiguous. Does 'this clause' refer to the entire sentence preceding it, or the phrase 'up to a maximum of 3 months'? My assumption is that it's the former (the entire sentence). > > Yes, we should perhaps say "this rule". > >> * In 3.2.4: >> >> """ >> Decisions of the RSAB can be appealed on grounds of failure to follow the correct process. Where the RSAB makes a decision in order to resolve a disagreement between authors and the RPC (as described under Section 4.4), appeals can be filed on the basis that the RSAB misinterpreted an approved policy. In other cases, disagreements about the conduct of the RSAB are not subject to appeal. >> """ >> >> The 'in other cases' clause is ambiguous here -- does it apply to just the precedent sentence, or the two preceding sentences? > > I'll work to clear this up, but I've understood it to be the two > preceding sentences. > > Peter > From nobody Tue Dec 14 02:21:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 452333A0A4F for ; Tue, 14 Dec 2021 02:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z3mpSsAZfgTQ for ; Tue, 14 Dec 2021 02:21:12 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 A57843A0A4C for ; Tue, 14 Dec 2021 02:21:09 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BEAKuak2656873 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 14 Dec 2021 11:21:06 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639477267; bh=m6Hc53Yg6a7Ht/19l5UIkWpTDPX1VaEr8orZKSeyCso=; h=Date:Subject:To:References:Cc:From:In-Reply-To:From; b=DT17A7w8/TvEEpKJCzD7s5+67pPfO3Wwi+Hz3V/dIjA5u1/z6H94stK4etrH1LQqP oHEqvYa1CMo1S1tmiHnwU/H/Jy2ZJQ2CRE1iOXuhw27jGRe33+T1tESnTikbh842lV aZSZ5DRvaGvttC0wU51CGDwpsMJuMPPyeW9MIQQY= Message-ID: <25569886-3caf-786b-16f5-0db0cd2627df@lear.ch> Date: Tue, 14 Dec 2021 11:20:46 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Peter Saint-Andre References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> Cc: "rfced-future@iab.org" From: Eliot Lear In-Reply-To: <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ejGxeuwagB30jJPF9FJ2UM4r" Archived-At: Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 10:21:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ejGxeuwagB30jJPF9FJ2UM4r Content-Type: multipart/mixed; boundary="------------gjmXlcZP0nOCODG62cOtZYR6"; protected-headers="v1" From: Eliot Lear To: Peter Saint-Andre Cc: "rfced-future@iab.org" Message-ID: <25569886-3caf-786b-16f5-0db0cd2627df@lear.ch> Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> In-Reply-To: <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> --------------gjmXlcZP0nOCODG62cOtZYR6 Content-Type: multipart/mixed; boundary="------------JEl1Bgie0BKwDM0RhXtFgEx0" --------------JEl1Bgie0BKwDM0RhXtFgEx0 Content-Type: multipart/alternative; boundary="------------Nd2CvvLqfpnmomqUd0pghrum" --------------Nd2CvvLqfpnmomqUd0pghrum Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VGhhbmsgeW91IFBldGVyIGZvciB0aGlzIGxhdGVzdCBkcmFmdC7CoCBJIGhhdmUgYXNrZWQg UGV0ZXIgdG8gd2FpdCBqdXN0IA0KYSBmZXcgZGF5cyBiZWZvcmUgcG9zdGluZyBhbiB1cGRh dGUgdG8gYWRkcmVzcyBNYXJrJ3MgY29tbWVudHMuwqAgSSB0aGluayANCml0J3MgYmVzdCB0 byBob2xkIG9mZiBvbiB0aGUgMiB3ZWVrIGxhc3QgY2FsbCB1bnRpbCAqYWZ0ZXIqIHRoZSAx c3Qgb2YgDQp0aGUgeWVhciBhdCB0aGlzIHBvaW50Lg0KDQpJIGFtIHRlbXB0ZWQgdG8gcHV0 IGEgcGxhY2Vob2xkZXIgaW4gdGhlIHNjaGVkdWxlIGZvciBhbiBpbnRlcmltIGluIA0KSmFu dWFyeSDigJPigJMgSlVTVCBJTiBDQVNFLsKgIEkgZG8gbm90IHRoaW5rIHdlIHdpbGwgbmVl ZCBpdCwgYnV0IEkgaGF2ZSANCmJlZW4gd3JvbmcgYmVmb3JlLg0KDQpUaG91Z2h0cz8NCg0K RWxpb3QNCg0KT24gMTQuMTIuMjEgMDA6MTYsIFBldGVyIFNhaW50LUFuZHJlIHdyb3RlOg0K PiBIaSBhbGwsIEkndmUganVzdCBub3cgc3VibWl0dGVkIHZlcnNpb24gLTA3IG9mIG91ciBk b2N1bWVudCwgd2hpY2ggSSANCj4gdGhpbmsgYWRkcmVzc2VzIGFsbCBvZiB0aGUgZmVlZGJh Y2sgcmVjZWl2ZWQgb24gdmVyc2lvbiAtMDYuIElmIEkgaGF2ZSANCj4gbWlzc2VkIGFueXRo aW5nLCBwbGVhc2UgbGV0IG1lIGtub3cgYnkgcG9zdGluZyBvbiB0aGUgbGlzdCBvciBieSAN Cj4gZmlsaW5nIGEgR2l0SHViIGlzc3VlLg0KPg0KPiBUaGFua3MhDQo+DQo+IFBldGVyDQo+ DQo+IC0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQo+IFN1YmplY3Q6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgDQo+IGRyYWZ0LWlhYi1yZmNlZmRwLXJmY2Vk LW1vZGVsLTA3LnR4dA0KPiBEYXRlOiBNb24sIDEzIERlYyAyMDIxIDE1OjEyOjQ0IC0wODAw DQo+IEZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZw0KPiBUbzogUGV0ZXIgU2FpbnQt QW5kcmUgPHN0cGV0ZXJAc3RwZXRlci5pbT4NCj4NCj4NCj4gQSBuZXcgdmVyc2lvbiBvZiBJ LUQsIGRyYWZ0LWlhYi1yZmNlZmRwLXJmY2VkLW1vZGVsLTA3LnR4dA0KPiBoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBldGVyIFNhaW50LUFuZHJlIGFuZCBwb3N0ZWQg dG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4NCj4gTmFtZTrCoMKgwqDCoMKgwqDCoCBk cmFmdC1pYWItcmZjZWZkcC1yZmNlZC1tb2RlbA0KPiBSZXZpc2lvbjrCoMKgwqAgMDcNCj4g VGl0bGU6wqDCoMKgwqDCoMKgwqAgUkZDIEVkaXRvciBNb2RlbCAoVmVyc2lvbiAzKQ0KPiBE b2N1bWVudCBkYXRlOsKgwqDCoCAyMDIxLTEyLTEzDQo+IEdyb3VwOsKgwqDCoMKgwqDCoMKg IGlhYg0KPiBQYWdlczrCoMKgwqDCoMKgwqDCoCAyOQ0KPiBVUkw6IGh0dHBzOi8vd3d3Lmll dGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtaWFiLXJmY2VmZHAtcmZjZWQtbW9kZWwtMDcudHh0 DQo+IFN0YXR1czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWFi LXJmY2VmZHAtcmZjZWQtbW9kZWwvDQo+IEh0bWw6IA0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9hcmNoaXZlL2lkL2RyYWZ0LWlhYi1yZmNlZmRwLXJmY2VkLW1vZGVsLTA3Lmh0bWwNCj4g SHRtbGl6ZWQ6IA0KPiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWlhYi1yZmNlZmRwLXJmY2VkLW1vZGVsDQo+IERpZmY6IGh0dHBzOi8vd3d3LmlldGYu b3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pYWItcmZjZWZkcC1yZmNlZC1tb2RlbC0wNw0KPg0K PiBBYnN0cmFjdDoNCj4gwqDCoCBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyB2ZXJzaW9uIDMg b2YgdGhlIFJGQyBFZGl0b3IgTW9kZWwuwqAgVGhlIG1vZGVsDQo+IMKgwqAgZGVmaW5lcyB0 d28gaGlnaC1sZXZlbCB0YXNrcyByZWxhdGVkIHRvIHRoZSBSRkMgU2VyaWVzLsKgIEZpcnN0 LA0KPiDCoMKgIHBvbGljeSBkZWZpbml0aW9uIGlzIHRoZSBqb2ludCByZXNwb25zaWJpbGl0 eSBvZiB0aGUgUkZDIFNlcmllcw0KPiDCoMKgIFdvcmtpbmcgR3JvdXAgKFJTV0cpLCB3aGlj aCBwcm9kdWNlcyBwb2xpY3kgcHJvcG9zYWxzLCBhbmQgdGhlIFJGQw0KPiDCoMKgIFNlcmll cyBBcHByb3ZhbCBCb2FyZCAoUlNBQiksIHdoaWNoIGFwcHJvdmVzIHN1Y2ggcHJvcG9zYWxz LiBTZWNvbmQsDQo+IMKgwqAgcG9saWN5IGltcGxlbWVudGF0aW9uIGlzIHByaW1hcmlseSB0 aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhlIFJGQw0KPiDCoMKgIFByb2R1Y3Rpb24gQ2VudGVy IChSUEMpIGFzIGNvbnRyYWN0dWFsbHkgb3ZlcnNlZW4gYnkgdGhlIElFVEYNCj4gwqDCoCBB ZG1pbmlzdHJhdGlvbiBMaW1pdGVkIExpYWJpbGl0eSBDb21wYW55IChJRVRGIExMQykuDQo+ DQo+IMKgwqAgVGhpcyBkb2N1bWVudCBvYnNvbGV0ZXMgUkZDIDg3MjguwqAgVGhpcyBkb2N1 bWVudCB1cGRhdGVzIFJGQyA3ODQxLA0KPiDCoMKgIFJGQyA4NzI5LCBhbmQgUkZDIDg3MzAu DQo+DQo+DQo+DQo+DQo+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+DQo+DQo= --------------Nd2CvvLqfpnmomqUd0pghrum Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thank you Peter for this latest draft.=C2=A0 I have asked Peter to= wait just a few days before posting an update to address Mark's comments.=C2=A0 I think it's best to hold off on the 2 week last ca= ll until after the 1st of the year at this point.

I am tempted to put a placeholder in the schedule for an interim in January =E2=80=93=E2=80=93 JUST IN CASE.=C2=A0 I do not think we= will need it, but I have been wrong before.

Thoughts?

Eliot

On 14.12.21 00:16, Peter Saint-Andre wrote:
Hi all= , I've just now submitted version -07 of our document, which I think addresses all of the feedback received on version -06. If I have missed anything, please let me know by posting on the list or by filing a GitHub issue.

Thanks!

Peter

-------- Forwarded Message --------
Subject: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt
Date: Mon, 13 Dec 2021 15:12:44 -0800
From: internet-drafts@ietf.org
To: Peter Saint-Andre <stpeter@stpeter.im>


A new version of I-D, draft-iab-rfcefdp-rfced-model-07.txt
has been successfully submitted by Peter Saint-Andre and posted to the
IETF repository.

Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-iab-rfcefdp-r= fced-model
Revision:=C2=A0=C2=A0=C2=A0 07
Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC Editor Model (= Version 3)
Document date:=C2=A0=C2=A0=C2=A0 2021-12-13
Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iab
Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 29
URL: https://www.ietf.org/archiv= e/id/draft-iab-rfcefdp-rfced-model-07.txt
Status: https://datatracker.ietf.org/d= oc/draft-iab-rfcefdp-rfced-model/
Html: https://www.ietf.org/archi= ve/id/draft-iab-rfcefdp-rfced-model-07.html
Htmlized: https://datatracker.ietf.o= rg/doc/html/draft-iab-rfcefdp-rfced-model
Diff: https://www.ietf.org/rfcdif= f?url2=3Ddraft-iab-rfcefdp-rfced-model-07

Abstract:
=C2=A0=C2=A0 This document specifies version 3 of the RFC Editor Mo= del.=C2=A0 The model
=C2=A0=C2=A0 defines two high-level tasks related to the RFC Series= =2E=C2=A0 First,
=C2=A0=C2=A0 policy definition is the joint responsibility of the R= FC Series
=C2=A0=C2=A0 Working Group (RSWG), which produces policy proposals,= and the RFC
=C2=A0=C2=A0 Series Approval Board (RSAB), which approves such prop= osals.=C2=A0 Second,
=C2=A0=C2=A0 policy implementation is primarily the responsibility = of the RFC
=C2=A0=C2=A0 Production Center (RPC) as contractually overseen by t= he IETF
=C2=A0=C2=A0 Administration Limited Liability Company (IETF LLC).

=C2=A0=C2=A0 This document obsoletes RFC 8728.=C2=A0 This document = updates RFC 7841,
=C2=A0=C2=A0 RFC 8729, and RFC 8730.




The IETF Secretariat


--------------Nd2CvvLqfpnmomqUd0pghrum-- --------------JEl1Bgie0BKwDM0RhXtFgEx0 Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------JEl1Bgie0BKwDM0RhXtFgEx0-- --------------gjmXlcZP0nOCODG62cOtZYR6-- --------------ejGxeuwagB30jJPF9FJ2UM4r Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG4b/4FAwAAAAAACgkQh7ZrRtnSejNz vAgAuYE4SQenLVb+1g2kNZOyp+gAKf9291CUxKIDTtsofINtwAuvqgZbLhX6t+XwOY320IFzEIHo yV273b6pjFUt84KYz5ZZIZ+3K3mmtcHubdE2DO0PSQ1E7iQvqPMnKZAHLz6vW9VcU27uQRHJ2TpF 80e47apue04R5TbtQduWUZc4gyjp9QHmeMXnmaLyHjKgKOjwbb3Vb52lJJ6NjRGXEapzKv+C/aYE EhuhxXwN8gi0P78TPYi6j1GH6Zn0tsoX9ye78ndERgaKudOiQ6OWIs2NidPt0mN9r9UHvKU0N48n yXUES1asnKgplgS7Low11fx/DiEeDA8ddAI+R71yLQ== =aIs/ -----END PGP SIGNATURE----- --------------ejGxeuwagB30jJPF9FJ2UM4r-- From nobody Tue Dec 14 12:04:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE4DC3A089C for ; Tue, 14 Dec 2021 12:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 9LO2TAP0UMwW for ; Tue, 14 Dec 2021 12:04:07 -0800 (PST) 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 386313A088A for ; Tue, 14 Dec 2021 12:03:12 -0800 (PST) Received: by mail-pl1-x62b.google.com with SMTP id z6so14443022plk.6 for ; Tue, 14 Dec 2021 12:03:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2mdP2JvJC/TSCpR/AZaMxCEpfM1ZSFpI7DhlA9efUZY=; b=fM1L2ekG6EhdpLBZ6VTWzEhT9MdZ9WaTZTqYrP6pduPiAYMpOqZcPSkogliirRIIwi XqJ8Q3cckMw+NZ7Pv0LmYhPxMDpFVVoAkMaNr1+xECuTdU76f9qiflWHOhR5Wd8q3qIh +p1lk1BDfZglNliEIfoxILcjDCcQFOqroD12s51pNbBwtr870U/8GjfUua7tWOaTO77t gbTCGIY8F9A92tbPUjZfBPkXBsCYPdSpp/hTepRr2r0HoWYMaERn5FczD669kVtoHgtk PQtnsOTUdYQwNb26fMMOZQlF2+pC+bQB3zX8AUKZ8UXBi4HSHIbBfUsPpii8NLmre8dO GBBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=2mdP2JvJC/TSCpR/AZaMxCEpfM1ZSFpI7DhlA9efUZY=; b=T2qFlz2x2OS/fT0fFgTiA8QHQ3LakKdODGvKCXTCQ39SSmtz+QuDSeVkzR1+LbqQ61 YHpMKhtRXYLBUpSaUM2IKe0NWu2erM6a3ai9kcPOZw6bvsZ+RooBBZQURv5bMvHA5rqd nTEyEOfzVNsHdN1zdzFakcFim97v6ewt7ksH2foEHG4oKI34Su1gnqjMc34v9GopvnJU Jjck3AdZxIcJotPJK9KlKR5p7YFizkcDSdWV0OI4TMHjp9jNMKytPki64+kn80eymgny tPsMQfkMA/YniE7oLZmZzTrYr8RhX/LCmccRTFxea8tvNmIsnhcq04Ta468L3VEt+rmS 2ljA== X-Gm-Message-State: AOAM531GgS/WZgK9agO70sLqzyrepIVVHY7fmVqlURZhmG0Piq3tPj+n FAGZCdB6AHYJQ/OuYAeOlbYnBORn064PpQ== X-Google-Smtp-Source: ABdhPJz5O1hBh6LiJMSKQo96LsTMGvf0ZaABH/rZ/eQpw6vkzx5BiZ4rgd9kthtJ39D/abBEFyS3Ag== X-Received: by 2002:a17:90a:1f85:: with SMTP id x5mr2079725pja.211.1639512191176; Tue, 14 Dec 2021 12:03:11 -0800 (PST) Received: from ?IPv6:2406:e003:1071:1701:80b2:5c79:2266:e431? ([2406:e003:1071:1701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 63sm620137pfz.119.2021.12.14.12.03.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 14 Dec 2021 12:03:10 -0800 (PST) To: Eliot Lear , Peter Saint-Andre Cc: "rfced-future@iab.org" References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> <25569886-3caf-786b-16f5-0db0cd2627df@lear.ch> From: Brian E Carpenter Message-ID: Date: Wed, 15 Dec 2021 09:03:05 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <25569886-3caf-786b-16f5-0db0cd2627df@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 20:04:12 -0000 On 14-Dec-21 23:20, Eliot Lear wrote: > Thank you Peter for this latest draft.=C2=A0 I have asked Peter to wait=20 just a few days before posting an update to address Mark's comments.=C2=A0=20 I think it's best to hold off on the 2 week last call until *after* the 1= st of the year at this point. Please don't lose the small issue I noted a couple of days ago: "As far as I can see, we don't specify whether the RSAB's mailing list do= es, or doesn't, have a public archive." > I am tempted to put a placeholder in the schedule for an interim in Jan= uary =E2=80=93=E2=80=93 JUST IN CASE.=C2=A0 I do not think we will need i= t, but I have been wrong before. >=20 > Thoughts? I'm really hoping the remaining issues are minor enough to avoid that. Wh= at we get back as IAB comments or wider community comments is quite unpr= edictable and might need a discussion, but more likely in February. Brian C >=20 > Eliot >=20 > On 14.12.21 00:16, Peter Saint-Andre wrote: >> Hi all, I've just now submitted version -07 of our document, which I t= hink addresses all of the feedback received on version -06. If I have mis= sed anything, please let me know by posting on the list or by filing a Gi= tHub issue. >> >> Thanks! >> >> Peter >> >> -------- Forwarded Message -------- >> Subject: New Version Notification for draft-iab-rfcefdp-rfced-model-07= =2Etxt >> Date: Mon, 13 Dec 2021 15:12:44 -0800 >> From: internet-drafts@ietf.org >> To: Peter Saint-Andre >> >> >> A new version of I-D, draft-iab-rfcefdp-rfced-model-07.txt >> has been successfully submitted by Peter Saint-Andre and posted to the= >> IETF repository. >> >> Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draft-iab-rfcefdp-rfce= d-model >> Revision:=C2=A0=C2=A0=C2=A0 07 >> Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 RFC Editor Model (Ver= sion 3) >> Document date:=C2=A0=C2=A0=C2=A0 2021-12-13 >> Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 iab >> Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 29 >> URL: https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07.= txt >> Status: https://datatracker.ietf.org/doc/draft-iab-rfcefdp-rfced-model= / >> Html: https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07= =2Ehtml >> Htmlized: https://datatracker.ietf.org/doc/html/draft-iab-rfcefdp-rfce= d-model >> Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-iab-rfcefdp-rfced-mode= l-07 >> >> Abstract: >> =C2=A0=C2=A0 This document specifies version 3 of the RFC Editor Model= =2E=C2=A0 The model >> =C2=A0=C2=A0 defines two high-level tasks related to the RFC Series.=C2= =A0 First, >> =C2=A0=C2=A0 policy definition is the joint responsibility of the RFC = Series >> =C2=A0=C2=A0 Working Group (RSWG), which produces policy proposals, an= d the RFC >> =C2=A0=C2=A0 Series Approval Board (RSAB), which approves such proposa= ls. Second, >> =C2=A0=C2=A0 policy implementation is primarily the responsibility of = the RFC >> =C2=A0=C2=A0 Production Center (RPC) as contractually overseen by the = IETF >> =C2=A0=C2=A0 Administration Limited Liability Company (IETF LLC). >> >> =C2=A0=C2=A0 This document obsoletes RFC 8728.=C2=A0 This document upd= ates RFC 7841, >> =C2=A0=C2=A0 RFC 8729, and RFC 8730. >> >> >> >> >> The IETF Secretariat >> >> >=20 From nobody Tue Dec 14 12:27:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 144AB3A08D6 for ; Tue, 14 Dec 2021 12:26:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=PGKjU9B9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k/Q9YXOE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1X0DkDlM5jDH for ; Tue, 14 Dec 2021 12:26:54 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90613A08D7 for ; Tue, 14 Dec 2021 12:26:53 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1BFE95C02C4; Tue, 14 Dec 2021 15:26:53 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 14 Dec 2021 15:26:53 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=/ ammkMNIGIvRG1c2goqOOHezhz/H7SnSi/jXwgIqpU4=; b=PGKjU9B9vqeDs6u5d 2UgFjjL5ZgnA8A2s7NlLScIoGnDt623PVkls2Hld+OQbpflj5cwJpvLKkMX4svXn q7Xu6xxLw/qrslKYOYrR1kGm0WtwcqP7ZuTcOD+IrAuUvq8ZH30rT0Ge+QrxHFKe T4sgNLmHlorrFib2f5xff1cuwYD93f6jWlmAB1TiD79+O8oq7zYgzRzj5iG28KN4 Ws/DPV5k1PSdUt98aam9GyhwmHEAntUt9b1xz9zUhspeobAMvvUWHMOlO8gV9sSN nRwkUD80G1hLZf8Df0Yd/eEkoCZTFLf7qWOY5n6FAUwFWmM8Xpsk8IEfdi+Ll/Pc gSJBg== 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=fm1; bh=/ammkMNIGIvRG1c2goqOOHezhz/H7SnSi/jXwgIqp U4=; b=k/Q9YXOEX9RlTlGJJzhjKenh1M3UGmAzeq7JMYChi8jGrYxVVp0F9bvMg bjccbfYe+Ds9r8Ap/fpm2juFlpj+1W47t+56Y0lcuGqwyhFaINBmMNaQgz4FVUrw sbnp+l+tH9d21yp8yq1RUVSKdGeo5W/r2C7PCoYvEXfBqKDtqnPJdjqUMp8pr6/w Ej7Kv7yr2dnEcmCSdoipH5ihcuRUPJn5PFRYvV1d+guUBGob+cP+aMbeipWyRyKU B71kpv8R5dwuSa94rwAPOsOKOOESvdD2eR4XjVxdfzumHurSMy+Sjj9hrRd4cliv lEczwssSvF1wxE8Y3t6ZkyDCDSe0w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrledtgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqne cuggftrfgrthhtvghrnhepvedtgfettefgffevheetvddugedugfelveeftdelveetgfef gefggfefledukeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Dec 2021 15:26:51 -0500 (EST) Message-ID: <456ef460-573e-d0cf-921f-9e0ebbc1431a@stpeter.im> Date: Tue, 14 Dec 2021 13:26:47 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Brian E Carpenter , Eliot Lear Cc: "rfced-future@iab.org" References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> <25569886-3caf-786b-16f5-0db0cd2627df@lear.ch> From: Peter Saint-Andre In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 20:26:59 -0000 On 12/14/21 1:03 PM, Brian E Carpenter wrote: > On 14-Dec-21 23:20, Eliot Lear wrote: >> Thank you Peter for this latest draft.  I have asked Peter to wait > just a few days before posting an update to address Mark's comments. I > think it's best to hold off on the 2 week last call until *after* the > 1st of the year at this point. > > Please don't lose the small issue I noted a couple of days ago: > "As far as I can see, we don't specify whether the RSAB's mailing list > does, or doesn't, have a public archive." Do note that in -07 I made it explicit that the RSWG list is to be publicly archived. We should make a decision about that regarding RSAB. It strikes me as a good idea. Peter From nobody Tue Dec 14 12:28:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BBA83A08D9 for ; Tue, 14 Dec 2021 12:28:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=tEP0XOdp; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gMqtWBZd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78QE_zAlnKKH for ; Tue, 14 Dec 2021 12:28:20 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 397853A08DC for ; Tue, 14 Dec 2021 12:28:20 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 75B7F5C02C4; Tue, 14 Dec 2021 15:28:19 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Tue, 14 Dec 2021 15:28:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=R vNXEV4cLjrmYU2SL32481dl6s68HqJCtqkF7V9U0Vk=; b=tEP0XOdp8+5cnhhZe lIvTbVPkPzSwwdvjgdtFgyMgKqwnEPpOw0cTHDm9lGEhz4rE4tCscdqHs9aOE3wi G8WKorgcLyjFIi4QvBN8D+SVHZTBHyQ4OWzEjlQMfI6Wa8dHA1QdtbTpfWwFYbKz X/0ZjyXRJcRu+m7azWHrTFTGG/D5atsVTcHzKWCuXNG7scy76K72oacyqjMHn8/7 k+JaayM4VK5jjEKT5GVFAy2IE4ZAnKslIqespkKlvrqkPfuCio998ONzIWPCkgvD ttVyh/GWbuNq1OqmXJsHWP3zxUWi/jo9TSsd/oBnrzzLb08190sEtIZBjptah6qp +KxmA== 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=fm1; bh=RvNXEV4cLjrmYU2SL32481dl6s68HqJCtqkF7V9U0 Vk=; b=gMqtWBZdttLbIfGc20Z4L6GDXVCzaemIL4TQAHfEXIOOpZdOXKBt4b8Nr l7hzrpZSfnMhqBwzUDx8wx6RJh5o2WoQpRl7FmITZj2kddb/SHKwDZPqD7wnfCTA GazVnkQR15VntZ+ffubf63bAQeGDEz9b0lUuyFg73j1PW1Ut2CFLnPFFdG7NytBi 3/qzZbOZHDu6TiWD6mgG4wOI11OJ8aHSc1LtZ4UIyDG7HmbSCaEPnSh20zIvtVwc GH9LtjuFU8+blsze/YoASCSmpBWAej2YsLlmRQ2TAM19dHMv1BX3bU8HnlWXLYfj VouPYm/Wlx2jpyG3FyLR9xDgWT4yQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrledtgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqne cuggftrfgrthhtvghrnhepvedtgfettefgffevheetvddugedugfelveeftdelveetgfef gefggfefledukeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 14 Dec 2021 15:28:18 -0500 (EST) Message-ID: <2225c287-1fbb-6d5f-c4b2-da746d514c7d@stpeter.im> Date: Tue, 14 Dec 2021 13:28:18 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear Cc: "rfced-future@iab.org" References: <163943716470.11925.12473737358937211066@ietfa.amsl.com> <571a52d5-719c-a679-16bd-4f2b3385f058@stpeter.im> <25569886-3caf-786b-16f5-0db0cd2627df@lear.ch> From: Peter Saint-Andre In-Reply-To: <25569886-3caf-786b-16f5-0db0cd2627df@lear.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Fwd: New Version Notification for draft-iab-rfcefdp-rfced-model-07.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Dec 2021 20:28:26 -0000 On 12/14/21 3:20 AM, Eliot Lear wrote: > Thank you Peter for this latest draft.  I have asked Peter to wait just > a few days before posting an update to address Mark's comments.  I think > it's best to hold off on the 2 week last call until *after* the 1st of > the year at this point. In that case I'll likely wait until January 3rd to post a new version so as to address any further comments that come in before the end of the year. Peter From nobody Wed Dec 15 02:39:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9B643A0E50 for ; Wed, 15 Dec 2021 02:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zlO9zCtDa1I for ; Wed, 15 Dec 2021 02:39:08 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 198CF3A0E53 for ; Wed, 15 Dec 2021 02:39:06 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BFAcufZ3364181 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 15 Dec 2021 11:38:57 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639564739; bh=/2NFXBw3Dw6WHjlGGDyr+jLnlkXcJ6p8ak/ugTMwfzs=; h=Date:To:References:From:Subject:In-Reply-To:From; b=opY3Xvtj+s79hP9jSDbgs4m5ftlnXKFMlt/ZJS1H6fpibamTSKWfEyJAQFerchZ1z cW0CAbHEOaAJGtYAWp/5826ABmVIefDpOK5uCDvDMHdOYTZzKWd2PMn8vmj19uX5Hs gzz3CwPGpvUeYFBN7/vNUD/csTM36LZySzdOPHXA= Message-ID: Date: Wed, 15 Dec 2021 11:38:55 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Michael StJohns , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> From: Eliot Lear In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8QFw49s9hr0l30WFYwX7y2c0" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 10:39:14 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8QFw49s9hr0l30WFYwX7y2c0 Content-Type: multipart/mixed; boundary="------------Bg9RYIpODzisSmt7fO8rgfSO"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] RPC liaison to the RSAB References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> In-Reply-To: --------------Bg9RYIpODzisSmt7fO8rgfSO Content-Type: multipart/mixed; boundary="------------NNNq1pbL0zfqKf7M6ZvlcLmG" --------------NNNq1pbL0zfqKf7M6ZvlcLmG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 V2UgbmVlZCB0byBkZWNpZGUgd2hhdCB0byBkbyB3aXRoIHRoaXMgaXNzdWUgYmVmb3JlIHdl IGNsb3NlIHRoZSANCmRvY3VtZW50LsKgIEFzIEkndmUgd3JpdHRlbiwgSSBkb24ndCB0aGlu ayB0aGUgdGV4dCBiZWxvdyBpcyBuZWNlc3Nhcnkgb3IgDQphcHByb3ByaWF0ZS7CoCBIb3dl dmVyLCBpZiB3ZSBhcmUgdG8gaW5jbHVkZSBpdCwgdGhlcmUgaXMgYW5vdGhlciBjb25jZXJu Og0KDQpPbiAxMC4xMi4yMSAyMDowNSwgTWljaGFlbCBTdEpvaG5zIHdyb3RlOg0KPg0KPiBI aSBNaXJqYSAtDQo+DQo+IEkgYWdyZWUgd2l0aCB5b3UgdGhhdCB0aGUgUlBDIHNob3VsZCBi ZSByZXByZXNlbnRlZC7CoCBJdCBwcm9iYWJseSANCj4gY2FuJ3QgYmUgZG9uZSBkaXJlY3Rp dmVseSBoZXJlIGJlY2F1c2Ugb2YgY29udHJhY3RzLiBTbyAiVGhlIEVEIHNoYWxsIA0KPiBi ZSBhIGxpYWlzb24gbWVtYmVyIG9mIHRoZSBSU0FCLsKgIFRoZSBlbnRpdHkgcGVyZm9ybWlu ZyB0aGUgdGFza3Mgb2YgDQo+IHRoZSBSUEMgbWF5IGFsc28gYXBwb2ludCBhIGxpYWlzb24g bWVtYmVyIHRvIHRoZSBSU0FCLsKgIExpYWlzaW9ucyBtYXkgDQo+IHBhcnRpY2lwYXRlIGlu IGFsbCBhY3Rpdml0aWVzIG9mIHRoZSBSU0FCIGFzIG5vbi12b3RpbmcgbWVtYmVycy4iwqAg DQo+IEUuZy4gdGhlIGNob2ljZSBpcyB0aGUgUlBDJ3Mgbm90IHRoZSBSU0FCJ3MgaW4gdGhp cyBjYXNlLg0KPg0KSXQgaXMgcXVpdGUgcG9zc2libGUgdGhhdCB0aGUgUlNBQiB3aWxsIGJl IGNhbGxlZCB1cG9uIHRvIHByb3ZpZGUgaW5wdXQgDQpvbiB0aGUgcGVyZm9ybWFuY2Ugb2Yg dGhlIFJQQywgdGhlIEVELCBhL28gdGhlIExMQy7CoCBUaGUgcGVudWx0aW1hdGUgDQpzZW50 ZW5jZSB3b3VsZCBtYWtlIHRoYXQgaW5wdXQgdmVyeSBkaWZmaWN1bHQsIGFuZCBpdCBtYXkg ZnVydGhlciANCmNvbmZsaWN0IHdpdGggY29uZmxpY3Qtb2YtaW50ZXJlc3QgcG9saWNpZXMg b2YgdGhlIExMQy7CoCBKYXkgbWF5IHdpc2ggdG8gDQpjb3JyZWN0IG1lLg0KDQpFbGlvdA0K DQoNCg== --------------NNNq1pbL0zfqKf7M6ZvlcLmG Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------NNNq1pbL0zfqKf7M6ZvlcLmG-- --------------Bg9RYIpODzisSmt7fO8rgfSO-- --------------8QFw49s9hr0l30WFYwX7y2c0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG5xb8FAwAAAAAACgkQh7ZrRtnSejMx aAgA1FjpthDuzlZtJ8B3GQY//xTSccZfo2cbeWujxlNXg/Kq5yqa7PilrKnBs28nXwvqR7nAzDqI lB9RwlhDW/XWBYvpl/4qPCanJEZDlSDXCZxx0/6WOQJe6U9KneBDWDTZy0P7YgApEnCreA9Wp07k 9K/eK7vJa0sprW6raXXHcYzKHZqLhot7cJUg0K+4pSBUN+pc/95TzyiIcPCjXaITaJV8blzvLOH5 VULp/vvS+6U+QK8gbja40OlBJaxSMMqnpmnf1WgJFEfeKKv6dLGGHv/FsvijsaKOB3MCZg320aKx FfVv5xHiD2i1caf/KRoIN9ZBPpI+jn2fNKEqaXH/Xw== =5gxY -----END PGP SIGNATURE----- --------------8QFw49s9hr0l30WFYwX7y2c0-- From nobody Wed Dec 15 02:58:04 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53D03A0E88 for ; Wed, 15 Dec 2021 02:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 u_I2U_EG7vmK for ; Wed, 15 Dec 2021 02:57:57 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5406E3A0E84 for ; Wed, 15 Dec 2021 02:57:57 -0800 (PST) Received: from p200300dee7299200f95bf20eb1879d32.dip0.t-ipconnect.de ([2003:de:e729:9200:f95b:f20e:b187:9d32]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1mxRyr-0004pz-RF; Wed, 15 Dec 2021 11:57:53 +0100 From: Mirja Kuehlewind Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C94F085C-2F14-48A0-A8CB-9A8856A82595" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 15 Dec 2021 11:57:52 +0100 In-Reply-To: <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> Cc: rfced-future@iab.org To: Brian E Carpenter References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1639565877;84111a58; X-HE-SMSGID: 1mxRyr-0004pz-RF Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 10:58:03 -0000 --Apple-Mail=_C94F085C-2F14-48A0-A8CB-9A8856A82595 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, hi all, Please see below (cutting down to the important parts only) > On 11. Dec 2021, at 21:06, Brian E Carpenter = wrote: >=20 >> Actually maybe this is also something we should add regarding the = secretariat. And a similar sentence about the RPC would do it for me as = well, e.g. >> Further, members of the RPC are subscribed to the >> mailing list and present in the IESG meetings as needed in order = to >> facilitate expedited consultation. >=20 >=20 > I think you mean "RSAB meetings". Yes, sorry, copy and paste error. > I don't like the word "meetings" anyway, because it's still my hope = that the RSAB needs very few meetings and in general has very little = work. (The work gets done in the working group.) Agreed. >=20 > Also, I don't think the analogy with the Secretariat is correct. The = Secretariat staff do what used to be called secretarial work for the = IESG. (These days, for reasons that baffle me, it's considered more = dignified to call it "admin".) The RPC staff don't work *for* the RSAB = in any such way. There's no reason that all of them need to read RSAB = email. I agree. I didn=E2=80=99t imply by using this reference that the RPC = would work for the RSAB (and I don=E2=80=99t think that=E2=80=99s what = the text says). I was only assuming that having them present and be able = to access the mailing list would make life easy for everybody - both the = RPC and the RSAB. But more importantly my intention was that there is no = ambiguity for the RPC about what the RPC is allowed or not allowed to do = when interacting with the RSAB but just exposing them to everything. >=20 > So I prefer yesterday's formulation of a direct RPC liaison to the = RSAB. But then when I look at draft-iab-rfcefdp-rfced-model-06, I see = that it's already covered, at the RSAB's discretion. No sure what you refer to because the text from Mike only said that the = RPC selects the liaison person but does not really say anything if there = should be a liaison or not. I believe Mike's intention was to always = have a liaison from the RPC. While currently the text says that the RSAB = decides if there is one or not. Having the RSAB decide if they need any liaisons seems generally right = to me and this is also what we say for other boards (like the IESG or = IAB). However then we also say that the ED =E2=80=9Cshall=E2=80=9D be a = liaison. I think making a stronger recommendation (namely shall) to have = the ED as liaison seems correct to me. So I only wonder why we don=E2=80=99= t have an equally strong recommendation for the RPC. That gives the = impression that having a liaison to the RPC is less important. If that = is what we actually want to say (even so I personally would disagree) = that's fine. But if that=E2=80=99s not the message we want to give we = should change that. In your reply to Mike you said: "Exactly right. The RSAB should be obliged to listen to what the RPC has = to say, if they wish to say anything.=E2=80=9D That=E2=80=99s exactly the point I would like to clarify. Maybe my text = proposal doesn=E2=80=99t capture that appropriately. However, actually I = think Mike=E2=80=99s doesn=E2=80=99t do that either (given it=E2=80=99s = still optional o have a liaison from the RPC). Mirja --Apple-Mail=_C94F085C-2F14-48A0-A8CB-9A8856A82595 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Brian, hi all,

Please = see below (cutting down to the important parts only)

On 11. Dec 2021, at 21:06, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Actually maybe this is also something we should add regarding = the secretariat. And a similar sentence about the RPC would do it for me = as well, e.g.
Further, members of the RPC are subscribed = to the
   mailing list and present in the = IESG meetings as needed in order to
   facilitate expedited consultation.


I think you mean "RSAB = meetings".

Yes, sorry, copy and paste error.

I don't like the word "meetings" anyway, because it's still = my hope that the RSAB needs very few meetings and in general has very = little work. (The work gets done in the working group.)

Agreed.


Also, I don't think the analogy = with the Secretariat is correct. The Secretariat staff do what used to = be called secretarial work for the IESG. (These days, for reasons that = baffle me, it's considered more dignified to call it "admin".) The RPC = staff don't work *for* the RSAB in any such way. There's no reason that = all of them need to read RSAB email.

I agree. I didn=E2=80=99t imply by using this = reference that the RPC would work for the RSAB (and I don=E2=80=99t = think that=E2=80=99s what the text says). I was only assuming that = having them present and be able to access the mailing list would make = life easy for everybody - both the RPC and the RSAB. But more = importantly my intention was that there is no ambiguity for the RPC = about what the RPC is allowed or not allowed to do when interacting with = the RSAB but just exposing them to everything.


So I prefer = yesterday's formulation of a direct RPC liaison to the RSAB. But then = when I look at draft-iab-rfcefdp-rfced-model-06, I see that it's already = covered, at the RSAB's discretion.

No sure what you refer to because the text from = Mike only said that the RPC selects the liaison person but does not = really say anything if there should be a liaison or not. I believe = Mike's intention was to always have a liaison from the RPC. While = currently the text says that the RSAB decides if there is one or = not.

Having the RSAB decide if they = need any liaisons seems generally right to me and this is also what we = say for other boards (like the IESG or IAB). However then we also say = that the ED =E2=80=9Cshall=E2=80=9D be a liaison. I think making a = stronger recommendation (namely shall) to have the ED as liaison seems = correct to me. So I only wonder why we don=E2=80=99t have an equally = strong recommendation for the RPC. That gives the impression that having = a liaison to the RPC is less important. If that is what we actually want = to say (even so I personally would disagree) that's fine. But if = that=E2=80=99s not the message we want to give we should change = that.

In your reply to Mike you = said:

"Exactly right. The RSAB = should be obliged to listen to what the RPC has to say, if they wish to = say anything.=E2=80=9D

That=E2=80=99s = exactly the point I would like to clarify. Maybe my text proposal = doesn=E2=80=99t capture that appropriately. However, actually I think = Mike=E2=80=99s doesn=E2=80=99t do that either (given it=E2=80=99s still = optional o have a liaison from the RPC).

Mirja





= --Apple-Mail=_C94F085C-2F14-48A0-A8CB-9A8856A82595-- From nobody Wed Dec 15 10:32:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A193F3A0B57 for ; Wed, 15 Dec 2021 10:32:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, 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.20210112.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 NLX2ijTfb5DQ for ; Wed, 15 Dec 2021 10:32:04 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 333BC3A0B41 for ; Wed, 15 Dec 2021 10:32:03 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id o10so645140qvc.5 for ; Wed, 15 Dec 2021 10:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=oLk7z7igVtcR061aVujA5QQwk9MaYZyG3EXqlVylFP8=; b=laOTx4luzHoOexXg3PAcPIlcm/4+P7wRoYHDKxdICdKILdfppdnp3r8ffLReH76iWM bYvPhgU0UHl8MiRtyNg7ZzJoTS368f0NxY28omrzYfITSGHFcbnaV1oxrVHPJPOQZekC hIYnPO4e8wxF5lfH32RU50KgifWtWdBNszQ/oWyKDCdpJ0Huena4mzMISDZRzSDDK2Fy mTVe4x5RH5V7j3gIoySuADfKrJSJOG+6c5j9ONKIAckt7kJTiQMHM8YGSe7w9i1bSSNo KDUFEVrj2faYE0WpEFeDqns2CLsoFtv9lEv227fSaXF4wAgGnNR4fYG2cE44FZNRvVQg N1Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=oLk7z7igVtcR061aVujA5QQwk9MaYZyG3EXqlVylFP8=; b=v7aykFcKe17uuFCbKIIpoy9YzkdnGXi/aMmFJ4/AKWfoesqU5tdAmuweiPpQOoFZ9k Ek6IrE2NLG3rCC0nzpe5ACRNYTwOYCKdZt8rn2SLJd1VPdOTcLPOyjPa6gcNV2DGA/gK jpKtDkt7M8j1Qqg7qKZaWDbmSt8/vikXlqYQ3hvdJMkxsa99DEKuWgRX6uZmkfnkJwm5 AgJzNnylf0z/mFeP6e0/mi4nqhj2MIIhrl48wB9tZDaUn0AQAl3t5ImzspsURyfkPn5k BhL9MnWBw3T7XzmzIvcyLgCAjwLXe0Nn4WW9lme9MeGY539b/V7qPk6P15sufjQA6PJS jmJg== X-Gm-Message-State: AOAM533pP63b/AXwNlhgyBt6EbH95QryXmnPm+WJlXBkC1w0IReBeJzM Av70IOjPRnXya1rnfmk0fjWXQw== X-Google-Smtp-Source: ABdhPJyKX5jI4LkE/+JiOU/8TykTt6zMXTyGEGes56y0cD6M2RgpnzlMZo5KNvOOQL4ic0ozam4vsQ== X-Received: by 2002:a0c:e5d1:: with SMTP id u17mr12418544qvm.120.1639593120983; Wed, 15 Dec 2021 10:32:00 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id y16sm892754qkj.69.2021.12.15.10.31.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Dec 2021 10:32:00 -0800 (PST) Message-ID: Date: Wed, 15 Dec 2021 13:31:58 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> From: Michael StJohns In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:32:11 -0000 On 12/15/2021 5:38 AM, Eliot Lear wrote: > We need to decide what to do with this issue before we close the > document. As I've written, I don't think the text below is necessary > or appropriate.  However, if we are to include it, there is another > concern: > > On 10.12.21 20:05, Michael StJohns wrote: >> >> Hi Mirja - >> >> I agree with you that the RPC should be represented.  It probably >> can't be done directively here because of contracts. So "The ED shall >> be a liaison member of the RSAB.  The entity performing the tasks of >> the RPC may also appoint a liaison member to the RSAB.  Liaisions may >> participate in all activities of the RSAB as non-voting members."  >> E.g. the choice is the RPC's not the RSAB's in this case. >> > It is quite possible that the RSAB will be called upon to provide > input on the performance of the RPC, the ED, a/o the LLC.  The > penultimate sentence would make that input very difficult, and it may > further conflict with conflict-of-interest policies of the LLC.  Jay > may wish to correct me. > > Eliot No.  Individual members of the RSAB/RSWG may be asked for their input on how the various contractors perform and may reply, as with any member of the community in good standing.  Neither the RSAB nor the RSWG shall give or offer to give a coordinated statement or evaluation.  I'm pretty sure we've already indicated that the RSAB has no personnel responsibilities.  With the exception of the initial appointment of the RSCE, there should be no personnel actions of any interest to the RSAB and even those can  be handled as individual queries.  E.g., there should be no reason for the RSAB to have any '"Executive Sessions". With respect to Mirja and Peter's comments - for clarity then: "The ED shall be a liaison member of the RSAB.  The entity performing the tasks of the RPC may also appoint a liaison member to the RSAB.  Liaisions may participate in all activities of the RSAB as non-voting members.   The RSAB may approve additional liaison positions as it deems fit." Subnote:  "While the RSAB meetings shall be open to any and all observers, the actual discussions shall be limited to the RSAB members and the liaisons except during designated public discussions times which shall be held at the discretion of the RSAB".   - To clarify the difference between a liaison and a random person listening in. Use the above and eliminate any other text about the RSAB approving liaison's. Mirja/Peter - "shall be a liaison" is directive here and requires the ED to participate.  "RPC may appoint..." is permissive and allows the RPC to appoint whoever they want as a liaison including no one.  It may conflict with other text, but the normal rules of construction are that the specific (e.g. applying to the RPC) override the general (the RSAB selects liaisons).  Having the ED select a liaison from the RPC isn't normally in keeping with the way contracts work.    The RPC will be the best judge of who should represent them in RSAB matters. Mike From nobody Wed Dec 15 10:52:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA323A0E23 for ; Wed, 15 Dec 2021 10:52:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W5DfXeB_4-L for ; Wed, 15 Dec 2021 10:52:29 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 502AF3A0E1F for ; Wed, 15 Dec 2021 10:52:28 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BFIqPKa3602941 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 15 Dec 2021 19:52:25 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639594346; bh=m7ArKrv74oMqxhGn7x58/LjjFF2pgJY+OfbZ6ivgCFk=; h=Date:To:References:From:Subject:In-Reply-To:From; b=tQGJjrv6jvxUh0/X70BCM0j78zWzBwUY3MleemEAcGm6IRgzKzSFBCGHh1JOLhGBN RHK7TwDiQ0u16pDoltRfN6/CRkmmb5GYQ/X3/dxhZNyz+EIFWtofusR4vlRIFql4wP XHpYAn4YUUU8kORkxQO8zD/OB6LXfqVnWqywlX8M= Message-ID: <8a4f2402-33d8-200b-e362-91eba6b1189a@lear.ch> Date: Wed, 15 Dec 2021 19:52:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Michael StJohns , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> From: Eliot Lear In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------FlqPt74TwHsBdrmpVEWOFkSx" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:52:35 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------FlqPt74TwHsBdrmpVEWOFkSx Content-Type: multipart/mixed; boundary="------------UR4mTqFXbopMs4sD0mbOJFgI"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , rfced-future@iab.org Message-ID: <8a4f2402-33d8-200b-e362-91eba6b1189a@lear.ch> Subject: Re: [Rfced-future] RPC liaison to the RSAB References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> In-Reply-To: --------------UR4mTqFXbopMs4sD0mbOJFgI Content-Type: multipart/alternative; boundary="------------TV8ZpBHsD0gOV4xFFeizdfY7" --------------TV8ZpBHsD0gOV4xFFeizdfY7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TWlrZToNCg0KT24gMTUuMTIuMjEgMTk6MzEsIE1pY2hhZWwgU3RKb2hucyB3cm90ZToNCj4g Tm8uIEluZGl2aWR1YWwgbWVtYmVycyBvZiB0aGUgUlNBQi9SU1dHIG1heSBiZSBhc2tlZCBm b3IgdGhlaXIgaW5wdXQgDQo+IG9uIGhvdyB0aGUgdmFyaW91cyBjb250cmFjdG9ycyBwZXJm b3JtIGFuZCBtYXkgcmVwbHksIGFzIHdpdGggYW55IA0KPiBtZW1iZXIgb2YgdGhlIGNvbW11 bml0eSBpbiBnb29kIHN0YW5kaW5nLsKgIE5laXRoZXIgdGhlIFJTQUIgbm9yIHRoZSANCj4g UlNXRyBzaGFsbCBnaXZlIG9yIG9mZmVyIHRvIGdpdmUgYSBjb29yZGluYXRlZCBzdGF0ZW1l bnQgb3IgDQo+IGV2YWx1YXRpb24uwqAgSSdtIHByZXR0eSBzdXJlIHdlJ3ZlIGFscmVhZHkg aW5kaWNhdGVkIHRoYXQgdGhlIFJTQUIgaGFzIA0KPiBubyBwZXJzb25uZWwgcmVzcG9uc2li aWxpdGllcy4NCg0KVGhhdCdzIGluY29ycmVjdDoNCg0KICAgIFBlcmlvZGljYWxseSwgdGhl IElFVEYgTExDIHdpbGwgZXZhbHVhdGUgdGhlIHBlcmZvcm1hbmNlIG9mIHRoZSBSU0NFLA0K ICAgIGluY2x1ZGluZyBhIGNhbGwgZm9yIGNvbmZpZGVudGlhbCBpbnB1dCBmcm9tIHRoZSBj b21tdW5pdHkuICBUaGUgSUVURg0KICAgIExMQyB3aWxsIHByb2R1Y2UgYSBkcmFmdCBldmFs dWF0aW9uIG9mIHRoZSBSU0NFJ3MgcGVyZm9ybWFuY2UgZm9yDQogICAgcmV2aWV3IGJ5IFJT QUIgbWVtYmVycyBvdGhlciB0aGFuIHRoZSBSU0NFLCB3aG8gd2lsbCBwcm92aWRlIGZlZWRi YWNrDQogICAgdG8gdGhlIElFVEYgTExDLg0KDQpBbmQgdGhlIGdyb3VwIGRpZCBuZWdvdGlh dGUgYXQgc29tZSBsZW5ndGggb24gdGhhdCB0ZXh0LsKgIFdlIGRvbid0IGhhdmUgDQpzdWNo IHRleHQgZm9yIHRoZSBSUEMsIGJ1dCB0aGF0J3MgYmVjYXVzZSB0aGUgTExDIGhhcyBhbiBl eGlzdGluZyANCnByb2Nlc3MgZm9yIHRoZSBSUEMuwqAgTm93IHdlIG1heSBoYXZlIGFuIGlu Y29uc2lzdGVuY3kgaW4gdGhlIHRleHQgYWJvdXQgDQpvcGVuIG1lZXRpbmcgbWF0dGVycy4N Cg0KRWxpb3QNCg0K --------------TV8ZpBHsD0gOV4xFFeizdfY7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Mike:

On 15.12.21 19:31, Michael StJohns wrote:
No.=C2=A0 Individual members of the RSAB/RSWG may be asked for their input on how the various contractors perform and may reply, as with any member of the community in good standing.=C2=A0 Neither the RSAB no= r the RSWG shall give or offer to give a coordinated statement or evaluation.=C2=A0 I'm pretty sure we've already indicated that the = RSAB has no personnel responsibilities.

That's incorrect:

   Periodically, the IETF LLC will evaluate th=
e performance of the RSCE,
   including a call for confidential input from the community.  The IETF
   LLC will produce a draft evaluation of the RSCE's performance for
   review by RSAB members other than the RSCE, who will provide feedback
   to the IETF LLC.

And the group did negotiate at some length on that text.=C2=A0 We don't have such text for the RPC, but that's because the LLC has an existing process for the RPC.=C2=A0 Now we may have an inconsist= ency in the text about open meeting matters.

Eliot

--------------TV8ZpBHsD0gOV4xFFeizdfY7-- --------------UR4mTqFXbopMs4sD0mbOJFgI-- --------------FlqPt74TwHsBdrmpVEWOFkSx Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG6OWYFAwAAAAAACgkQh7ZrRtnSejOB gQgAoB07UhWEogFO1cwDzugicrSiD5TDglxhsbJZ0/n3q5DGvlhkTRjA4Dc8WJP1BnVir23ExUw0 U4Tr91t5CYEH2cJBaxWHezsBiq603vEv4uMnreMSiFDcUAoMBmnaelJLAkhTSkU9GaqT1IjEcAJ4 OytsnDRrRaH4RSvtzc5AtlcPybngmGG8MWnaIVr23rpVC6FfT/rwTDn3CPoawXSRSGiTVWV6YkgH 8cHeMfqv3fXKDsrUJUbvPROMJI8fZTmitHhgy2+kTL/R7Ga3qMp1EHu3rZ2cJrCJwNVSFVhFhq+z xKJZXrd0D2l/PWkELRvwWzQcWpwQI/8SD15jTHuk+w== =Hjj+ -----END PGP SIGNATURE----- --------------FlqPt74TwHsBdrmpVEWOFkSx-- From nobody Wed Dec 15 11:15:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 253AF3A07B5 for ; Wed, 15 Dec 2021 11:15:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 eI9Ppv7d2Tgd for ; Wed, 15 Dec 2021 11:15:05 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 765543A077C for ; Wed, 15 Dec 2021 11:15:05 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id h16so20206977ila.4 for ; Wed, 15 Dec 2021 11:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kZo6X9EwRtPlze8VrH2VwjjtqmrOY4WgyRa57ycJ1+c=; b=EMADSiIiF/Ff0V8PDjntYHk/BupqVQuILBdxMZNl++35dNLDqgWp+U2TLri1x08C0o ZdNYZZxbkHNmoUsZ6V2lpONAWVn5h/w+ganUxwbMWZ8Qn5S39IojK9zd8HtaeumMsgCt Zj2ik/wHRNtf9raZUcYVx9+sSY3SRpm1akTy+xVwE39Ry7l05TSs67o9ixQtyBR+d/xv jyq/A1/Ts64nd+jnfwq1FYw06QJBD11+QGjQBi0+lgNmvkeVLz2LysxspS90dgzuM5nr OPq9KwNKKoEfwhuz/1rThrOuAXWYUSFZ+1YyjyMHC4o5rukWnr4A+H+UpjgU2nyUWgNX w3WQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kZo6X9EwRtPlze8VrH2VwjjtqmrOY4WgyRa57ycJ1+c=; b=cMtDkOsoIcPvCW2siIT9XChxULnoNzf3Oxc2Aq1LXzSEfNGKmW9a5xMaeI5cqQM3jF UsdarOFdXodU8iGLyJ2LPP91619sdMBAXTimXDWlvsBiRbek6jDWA5C4DmkBA0iPihb9 ep+0RGrLl5jMdnPApT5HQLMsFo/YUwLOf5N3CbPzDp0jZngSqMEq1KB/HMz/vPm4i7Yz yxXaR6WHvd3HRzIHsC2ch4Ma2qWTp7Bp3wpb6Q3XBzTAPQKxFoL9VGyI2nsR0c1eE4nP EIP19EjEFAgawWQ7WXbVnltYrdWFD7YewYBCB+A4B1XfpHxk4xqmpzaR2choApohshYo w/Ng== X-Gm-Message-State: AOAM532bD2qOL9IGJrqLCOx5AZZHsmLBAf7YMO50T67S4cSC1LrGZviv rHom8DTV8MzaWVcTwodyGWHpL7XCsgeBL6gqhPnhKlVnbng= X-Google-Smtp-Source: ABdhPJxwq+VYO3Wn9H6gmoOGmXzcxKEEuJplVYUKNV8qyEFR7FOlb0SGX4rhji9uLuSZlbZfgbwRUQ61GSA6aCvd+94= X-Received: by 2002:a05:6e02:2147:: with SMTP id d7mr7538186ilv.219.1639595703342; Wed, 15 Dec 2021 11:15:03 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> In-Reply-To: From: Eric Rescorla Date: Wed, 15 Dec 2021 11:14:27 -0800 Message-ID: To: Michael StJohns Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000792e9d05d3341f00" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:15:17 -0000 --000000000000792e9d05d3341f00 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 15, 2021 at 10:32 AM Michael StJohns wrote: > On 12/15/2021 5:38 AM, Eliot Lear wrote: > > We need to decide what to do with this issue before we close the > > document. As I've written, I don't think the text below is necessary > > or appropriate. However, if we are to include it, there is another > > concern: > > > > On 10.12.21 20:05, Michael StJohns wrote: > >> > >> Hi Mirja - > >> > >> I agree with you that the RPC should be represented. It probably > >> can't be done directively here because of contracts. So "The ED shall > >> be a liaison member of the RSAB. The entity performing the tasks of > >> the RPC may also appoint a liaison member to the RSAB. Liaisions may > >> participate in all activities of the RSAB as non-voting members." > >> E.g. the choice is the RPC's not the RSAB's in this case. > >> > > It is quite possible that the RSAB will be called upon to provide > > input on the performance of the RPC, the ED, a/o the LLC. The > > penultimate sentence would make that input very difficult, and it may > > further conflict with conflict-of-interest policies of the LLC. Jay > > may wish to correct me. > > > > Eliot > > No. Individual members of the RSAB/RSWG may be asked for their input on > how the various contractors perform and may reply, as with any member of > the community in good standing. Neither the RSAB nor the RSWG shall > give or offer to give a coordinated statement or evaluation. I'm pretty > sure we've already indicated that the RSAB has no personnel > responsibilities. With the exception of the initial appointment of the > RSCE, there should be no personnel actions of any interest to the RSAB > and even those can be handled as individual queries. E.g., there > should be no reason for the RSAB to have any '"Executive Sessions". > I don't agree with this. It seems entirely appropriate for the RSAB to give input as a group (perhaps minus the RSCE if the input is on the RSCE). I would note that the draft has had text allowing RSAB executive sessions for some time, so changing that seems like it would require some consensus to change. > With respect to Mirja and Peter's comments - for clarity then: > > "The ED shall be a liaison member of the RSAB. The entity performing > the tasks of the RPC may also appoint a liaison member to the RSAB. > See below. > Liaisions may participate in all activities of the RSAB as non-voting > members. I don't in fact think this is the right text and it's not usually how we handle liaisons. Rather the, RSAB should (without the liaison) determine the nature of the liaison's participation. > The RSAB may approve additional liaison positions as it deems > fit." > This seems fine. > Subnote: "While the RSAB meetings shall be open to any and all > observers, the actual discussions shall be limited to the RSAB members > and the liaisons except during designated public discussions times which > shall be held at the discretion of the RSAB". - To clarify the > difference between a liaison and a random person listening in. > This also seems fine. > Mirja/Peter - "shall be a liaison" is directive here and requires the ED > to participate. I don't think we should require that. "RPC may appoint..." is permissive and allows the RPC > to appoint whoever they want as a liaison including no one. It may > conflict with other text, but the normal rules of construction are that > the specific (e.g. applying to the RPC) override the general (the RSAB > selects liaisons). Having the ED select a liaison from the RPC isn't > normally in keeping with the way contracts work. The RPC will be the > best judge of who should represent them in RSAB matters. > Given the ED's overall responsibilities here, I think having the ED formally approve the liaison -- on the recommendation of the RPC perhaps -- makes more sense. -Ekr > Mike > > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000792e9d05d3341f00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 15, 2021 at 10:32 AM Mich= ael StJohns <msj@nthpermutatio= n.com> wrote:
On 12/15/2021 5:38 AM, Eliot Lear wrote:
> We need to decide what to do with this issue before we close the
> document. As I've written, I don't think the text below is nec= essary
> or appropriate.=C2=A0 However, if we are to include it, there is anoth= er
> concern:
>
> On 10.12.21 20:05, Michael StJohns wrote:
>>
>> Hi Mirja -
>>
>> I agree with you that the RPC should be represented.=C2=A0 It prob= ably
>> can't be done directively here because of contracts. So "= The ED shall
>> be a liaison member of the RSAB.=C2=A0 The entity performing the t= asks of
>> the RPC may also appoint a liaison member to the RSAB.=C2=A0 Liais= ions may
>> participate in all activities of the RSAB as non-voting members.&q= uot;=C2=A0
>> E.g. the choice is the RPC's not the RSAB's in this case.<= br> >>
> It is quite possible that the RSAB will be called upon to provide
> input on the performance of the RPC, the ED, a/o the LLC.=C2=A0 The > penultimate sentence would make that input very difficult, and it may =
> further conflict with conflict-of-interest policies of the LLC.=C2=A0 = Jay
> may wish to correct me.
>
> Eliot

No.=C2=A0 Individual members of the RSAB/RSWG may be asked for their input = on
how the various contractors perform and may reply, as with any member of the community in good standing.=C2=A0 Neither the RSAB nor the RSWG shall <= br> give or offer to give a coordinated statement or evaluation.=C2=A0 I'm = pretty
sure we've already indicated that the RSAB has no personnel
responsibilities.=C2=A0 With the exception of the initial appointment of th= e
RSCE, there should be no personnel actions of any interest to the RSAB
and even those can=C2=A0 be handled as individual queries.=C2=A0 E.g., ther= e
should be no reason for the RSAB to have any '"Executive Sessions&= quot;.

I don't agree with this. It = seems entirely appropriate for the RSAB to give
input as a group = (perhaps minus the RSCE if the input is on the RSCE).

<= div>I would note that the draft has had text allowing RSAB executive sessio= ns
for some time, so changing that seems like it would require so= me consensus
to change.


= =C2=A0
With respect to Mirja and Peter's comments - for clarity then:

"The ED shall be a liaison member of the RSAB.=C2=A0 The entity perfor= ming
the tasks of the RPC may also appoint a liaison member to the RSAB.=C2=A0 <= br>

See below.

=C2= =A0
Liaisions may participate in all activities of the RSAB as non-voting
members.=C2=A0

I don't in fact think th= is is the right text and it's not usually how we
handle liais= ons. Rather the, RSAB should (without the liaison)
determine the = nature of the liaison's participation.

=C2= =A0
=C2=A0 The RSAB = may approve additional liaison positions as it deems
fit."

This seems fine.
<= br>
=C2=A0
=C2=A0
Subnote:=C2=A0 "While the RSAB meetings shall be open to any and all <= br> observers, the actual discussions shall be limited to the RSAB members
and the liaisons except during designated public discussions times which shall be held at the discretion of the RSAB".=C2=A0=C2=A0 - To clarify= the
difference between a liaison and a random person listening in.

This also seems fine.
=C2=A0
=C2=A0
Mirja/Peter - "shall be a liaison" is directive here and requires= the ED
to participate.=C2=A0

I don't think we = should require that.


"RPC may appoint..." is permiss= ive and allows the RPC
to appoint whoever they want as a liaison including no one.=C2=A0 It may conflict with other text, but the normal rules of construction are that the specific (e.g. applying to the RPC) override the general (the RSAB
selects liaisons).=C2=A0 Having the ED select a liaison from the RPC isn= 9;t
normally in keeping with the way contracts work.=C2=A0=C2=A0=C2=A0 The RPC = will be the
best judge of who should represent them in RSAB matters.

Given the ED's overall responsibilities here, I think= having the ED formally
approve the liaison -- on the recommendat= ion of the RPC perhaps -- makes
more sense.
--000000000000792e9d05d3341f00-- From nobody Wed Dec 15 11:21:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E81F3A076C for ; Wed, 15 Dec 2021 11:21:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id izdWEgqkCR9O for ; Wed, 15 Dec 2021 11:21:02 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350613A0768 for ; Wed, 15 Dec 2021 11:21:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 0D27341274E6; Wed, 15 Dec 2021 11:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bADUs-fvO1bz; Wed, 15 Dec 2021 11:21:02 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id 5A2E941274D7; Wed, 15 Dec 2021 11:21:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Jay Daley In-Reply-To: Date: Thu, 16 Dec 2021 08:20:56 +1300 Cc: Brian E Carpenter , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> To: Mirja Kuehlewind X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:21:08 -0000 > On 15/12/2021, at 11:57 PM, Mirja Kuehlewind = wrote: >=20 > Hi Brian, hi all, >=20 > Please see below (cutting down to the important parts only) >=20 >> On 11. Dec 2021, at 21:06, Brian E Carpenter = wrote: >>=20 >>> Actually maybe this is also something we should add regarding the = secretariat. And a similar sentence about the RPC would do it for me as = well, e.g. >>> Further, members of the RPC are subscribed to the >>> mailing list and present in the IESG meetings as needed in order = to >>> facilitate expedited consultation. >>=20 >>=20 >> I think you mean "RSAB meetings". >=20 > Yes, sorry, copy and paste error. >=20 >> I don't like the word "meetings" anyway, because it's still my hope = that the RSAB needs very few meetings and in general has very little = work. (The work gets done in the working group.) >=20 > Agreed. >=20 >>=20 >> Also, I don't think the analogy with the Secretariat is correct. The = Secretariat staff do what used to be called secretarial work for the = IESG. (These days, for reasons that baffle me, it's considered more = dignified to call it "admin".) The RPC staff don't work *for* the RSAB = in any such way. There's no reason that all of them need to read RSAB = email. >=20 > I agree. I didn=E2=80=99t imply by using this reference that the RPC = would work for the RSAB (and I don=E2=80=99t think that=E2=80=99s what = the text says). I was only assuming that having them present and be able = to access the mailing list would make life easy for everybody - both the = RPC and the RSAB. But more importantly my intention was that there is no = ambiguity for the RPC about what the RPC is allowed or not allowed to do = when interacting with the RSAB but just exposing them to everything. >=20 >>=20 >> So I prefer yesterday's formulation of a direct RPC liaison to the = RSAB. But then when I look at draft-iab-rfcefdp-rfced-model-06, I see = that it's already covered, at the RSAB's discretion. >=20 > No sure what you refer to because the text from Mike only said that = the RPC selects the liaison person but does not really say anything if = there should be a liaison or not. I believe Mike's intention was to = always have a liaison from the RPC. While currently the text says that = the RSAB decides if there is one or not. >=20 > Having the RSAB decide if they need any liaisons seems generally right = to me and this is also what we say for other boards (like the IESG or = IAB). However then we also say that the ED =E2=80=9Cshall=E2=80=9D be a = liaison. I think making a stronger recommendation (namely shall) to have = the ED as liaison seems correct to me. So I only wonder why we don=E2=80=99= t have an equally strong recommendation for the RPC. That gives the = impression that having a liaison to the RPC is less important. If that = is what we actually want to say (even so I personally would disagree) = that's fine. But if that=E2=80=99s not the message we want to give we = should change that. This is not about importance, it is about the different roles, and = trying to find an equivalence between different liaisons where none = exists is the wrong way to design a group. The reasons for the RPC = being a mandatory liaison should standalone. The reason for the ED being a mandatory liaison are well documented - = In July in response to community comments, Peter originally proposed = text that allowed the RSAB to optionally appoint both the ED and an RPC = [1] and different text that mandated the ED but not the RPC [2]. I had = previously made the case [3] for a mandatory LLC liaison - "necessary = for the LLC in its role of setting the performance targets for the RPC = and negotiating the work plan budget/timetables", which was generally = accepted. When it comes to the RPC being a liaison to RSAB, then the situation is = much more complex than it is for the ED. In particular the RSAB needs = to reconcile the following: - how to manage the RPC input/engagement when discussing the priorities = and performance of the RPC - how to manage responding to RPC requests for advice - how to manage any conflicting advice from the RSCE and the RPC None of these are insurmountable, but I would hope that any proposal for = the RPC being a mandatory liaison addresses those issues as not doing = that puts the RSAB on a difficult footing from the start. Jay [1] = https://mailarchive.ietf.org/arch/msg/rfced-future/0dzrlliAktfbWZro1HKscIA= ekOo/ [2] = https://mailarchive.ietf.org/arch/msg/rfced-future/tf9lkn4bdt1uPPns-1OgeUw= xWpE/ [3] = https://mailarchive.ietf.org/arch/msg/rfced-future/Ld6eMPFj29KlA5AR4bRRY6z= AjKI/ >=20 > In your reply to Mike you said: >=20 > "Exactly right. The RSAB should be obliged to listen to what the RPC = has to say, if they wish to say anything.=E2=80=9D >=20 > That=E2=80=99s exactly the point I would like to clarify. Maybe my = text proposal doesn=E2=80=99t capture that appropriately. However, = actually I think Mike=E2=80=99s doesn=E2=80=99t do that either (given = it=E2=80=99s still optional o have a liaison from the RPC). >=20 > Mirja >=20 >=20 >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director exec-director@ietf.org From nobody Wed Dec 15 12:24:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8F3A0DBE for ; Wed, 15 Dec 2021 12:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 et3af2DuvlpD for ; Wed, 15 Dec 2021 12:23:59 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1713A0D9F for ; Wed, 15 Dec 2021 12:23:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id B8723300C56 for ; Wed, 15 Dec 2021 15:24:01 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id dSz2kQvOF0BH for ; Wed, 15 Dec 2021 15:23:59 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 49E97300B02; Wed, 15 Dec 2021 15:23:59 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_E9FF963E-CA87-40AB-841B-56BE53FCDCCF" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Wed, 15 Dec 2021 15:23:55 -0500 In-Reply-To: Cc: rfced-future@iab.org To: Eric Rescorla , Mike StJohns , Eliot Lear References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:24:04 -0000 --Apple-Mail=_E9FF963E-CA87-40AB-841B-56BE53FCDCCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Dec 15, 2021, at 2:14 PM, Eric Rescorla wrote: >=20 > =20 > Liaisions may participate in all activities of the RSAB as non-voting=20= > members.=20 >=20 > I don't in fact think this is the right text and it's not usually how = we > handle liaisons. Rather the, RSAB should (without the liaison) > determine the nature of the liaison's participation. We have many situations where liaisons are full participants in the = discussion, but then cannot vote. Further, some groups may want to give = their liaison instructions that limit the ways that the liaison can = participate. Russ --Apple-Mail=_E9FF963E-CA87-40AB-841B-56BE53FCDCCF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Dec 15, 2021, at 2:14 PM, Eric Rescorla <ekr@rtfm.com> = wrote:

 
Liaisions may = participate in all activities of the RSAB as non-voting 
members. 

I = don't in fact think this is the right text and it's not usually how = we
handle liaisons. Rather the, RSAB should (without the = liaison)
determine the nature of the liaison's = participation.

We have many situations where liaisons are full participants = in the discussion, but then cannot vote.  Further, some groups may = want to give their liaison instructions that limit the ways that the = liaison can participate.

Russ

= --Apple-Mail=_E9FF963E-CA87-40AB-841B-56BE53FCDCCF-- From nobody Wed Dec 15 12:29:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9843A0E25 for ; Wed, 15 Dec 2021 12:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 AYkX5zbunmpV for ; Wed, 15 Dec 2021 12:29:29 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01583A0DE7 for ; Wed, 15 Dec 2021 12:29:28 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id b187so32023992iof.11 for ; Wed, 15 Dec 2021 12:29:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0SH4ri+vdIULQeYAYocxYJVPEJsi7AosNhWA+ul9GJg=; b=WZMFvmAOWtke235epe7TvMdluCb0N/KlC8/LV+42yOiAK5RwqzmRL8hPk9Ny/RBGcV LwMEuQf/vLyW6BM5nP9AzEQUnaGkge0Bfct0xoIeux4Ao/fH+k450/3DharLFz/60blH ZVafB6A+bGdn/2ndgc1/vinA8kBCrAourIQIJDDAK8COiASG8UuTuRUSD8YEljZ1vp49 iMI54ib21C7bdJ/jP7dXdF0Pkf/u66XVCma9St+DLJDYxgZQBy0YG3lPaCMBWpGVyh2L cmES0JPNzQUFu3VVU0c2tgLFPakt6d14Jgi//iWuXf8aieWssaIbhW2DjYuRttfJb9RI hyIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0SH4ri+vdIULQeYAYocxYJVPEJsi7AosNhWA+ul9GJg=; b=Ld9+8w17i/n7VpGXrLGOwPw1nyAOGy7e8hFykZPq0v7M5uaMW4s4NohyDXiC0ZynW0 tpaoyIzbUY6PKF1lAXiienUR2Jx4L3kgfLWVoEDl3nF0tgW/ctyE7TXhb/p2mDAPBiNn d8HQM/tUt6K+q3yC2ruIAxD17lM8SLXWfiygubcp4cDwqbfuNdpAYNuUS9ashNg0Hjtq 6pDRuT8240I80vs0giTGvvwo3wYsYCDER6IHYuGFpkVUKeX9pf7mR60a9wcanIHLjG9a TW7iajz24hkEVrOAEz21UtAzBECyLMKz3vh6F1gCPHulM3HVOVXBskZkUGkyqGb1nKT3 qOww== X-Gm-Message-State: AOAM531DQsEayw0r9ebYqHHt8yT9xexQm8aYG2ehgp81tucOQkUtYZRU 72qAn9TsbgXe5tJ7sQzctqAczsIlSW0g39j2EAUmVw== X-Google-Smtp-Source: ABdhPJx7Icrn5jULNFFfKzCIOhDnRinamk92F4NLL6cQx2BWrCKZ5evNH4+zgbJmknJjZzSJYsSBS05t2Xeiu/TjgNw= X-Received: by 2002:a05:6638:2727:: with SMTP id m39mr7132655jav.75.1639600165915; Wed, 15 Dec 2021 12:29:25 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> In-Reply-To: From: Eric Rescorla Date: Wed, 15 Dec 2021 12:28:50 -0800 Message-ID: To: Russ Housley Cc: Mike StJohns , Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000076a21805d33529a8" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:29:39 -0000 --00000000000076a21805d33529a8 Content-Type: text/plain; charset="UTF-8" On Wed, Dec 15, 2021 at 12:23 PM Russ Housley wrote: > > > On Dec 15, 2021, at 2:14 PM, Eric Rescorla wrote: > > > >> Liaisions may participate in all activities of the RSAB as non-voting >> members. > > > I don't in fact think this is the right text and it's not usually how we > handle liaisons. Rather the, RSAB should (without the liaison) > determine the nature of the liaison's participation. > > > We have many situations where liaisons are full participants in the > discussion, but then cannot vote. > Correct, but it's at the discretion of the receiving organization. > Further, some groups may want to give their liaison instructions that > limit the ways that the liaison can participate. > Sure. And if they want less participation, that's their right. But I think the outer limits should be set by the RSAB. -Ekr > > Russ > > --00000000000076a21805d33529a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 15, 2021 at 12:23 PM Russ= Housley <housley@vigilsec.com> wrote:



=C2=A0
Liaisions may participate in all activities of the RSAB as= non-voting=C2=A0
members.=C2=A0

I don't in fact think this is the= right text and it's not usually how we
handl= e liaisons. Rather the, RSAB should (without the liaison)
determine the nature of the liaison's participation.

We have many situations where liaisons are = full participants in the discussion, but then cannot vote.

Correct, but it's at the discretion of the= receiving organization.

=C2=A0
=C2=A0Further, some groups may want to give their liaison = instructions that limit the ways that the liaison can participate.

Sure. And if they want less participati= on, that's their right. But I think the outer limits should be set by t= he RSAB.

-Ekr
=C2=A0

Russ

=
--00000000000076a21805d33529a8-- From nobody Wed Dec 15 13:49:04 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3A763A0775 for ; Wed, 15 Dec 2021 13:48:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 pHRXPwixsm2s for ; Wed, 15 Dec 2021 13:48:49 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BADA3A0657 for ; Wed, 15 Dec 2021 13:48:48 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id kj6so6296783qvb.2 for ; Wed, 15 Dec 2021 13:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=SaxXE5Nm3dseZH7LS7DuBWKkAB3U6l8hcUUB5ZO22pk=; b=29mj6YkAQ07OgMvMdvf+GvXCK7N6ff9qfRvmYlcZkwvEW3YPWIgQyTlR9L9Q2foUmz NSSg50mY+ojIR9PcgV6pW5eP8dOvQW76NS+JXvoB7U/eRKoQsJL2ySrMXWOS8VcF+6cx i2RxwXmqp7sHpV/XCvWi9fkJOiDpeUw7nDbuQLrlHFc7vEq9qJ7Dm5OjWm7rt05YDczK 7MXT7bj/VJ4P/502nwToi05N/tdUZMhYPtkEwuxYUQLxByxxhLpyVfHGxE8JUgorJDhx LgazhjA0d0MpXvLHR7DJN2repOBatPq/WhZh/yxa8AIGCjcu8clJYiTLNObWjeHc6ROO TkRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=SaxXE5Nm3dseZH7LS7DuBWKkAB3U6l8hcUUB5ZO22pk=; b=2LpSmEVxNnPj5zSUdIo2JSmNKzupRTQhrjRcjlMY1Z+ZdjcT3WGs7KA6S2VLC1xl/c NBnLR0XrtUhlEFoMAeIjtersjF1k90dWWzkr9NsnGGhz+k4NHqyoPQvncru5nqryj7lU Vhyr826bwbAkTtrRtXJRYP6Ucb1yFFszKTGdBo0o/sOIy/OX+hQ9gsqe5Dm6Hn7bmBXs Mno3X+rCQAt7GUxdVLD1P9C1IJqtROZTI1lGzne9aoje5CIyHG5Zu0JfboV2shZugF0y MkXM/yPgnsc+/WztcNaRIW5b5DulPvukHejeW/1h5DQlAGRKOW2XaFe7DptGHoOYoq0q Xcbw== X-Gm-Message-State: AOAM532wEBlhdmVcNcFqiqlXRkZloLgD+zKqnBahJ+V/HZxu4U+6UmqZ ICfuW5Bz3kYjdoK2pizq3Y4rge65O981B6SB X-Google-Smtp-Source: ABdhPJxkSf/gK9vdvGo6b2DHYxiJ71KAwaYTjYMj5jxYdjKW+Jd7loPOUbkqP1ywj/cN49M7LZFpJA== X-Received: by 2002:a0c:ef03:: with SMTP id t3mr13309200qvr.32.1639604926835; Wed, 15 Dec 2021 13:48:46 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id 8sm2539206qtz.28.2021.12.15.13.48.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Dec 2021 13:48:46 -0800 (PST) Content-Type: multipart/alternative; boundary="------------quqO9liZER1PhMKwpK10e0gz" Message-ID: <639a8abd-1adb-dc1a-9a53-9af5c2574092@nthpermutation.com> Date: Wed, 15 Dec 2021 16:48:44 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <8a4f2402-33d8-200b-e362-91eba6b1189a@lear.ch> From: Michael StJohns In-Reply-To: <8a4f2402-33d8-200b-e362-91eba6b1189a@lear.ch> Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:49:02 -0000 This is a multi-part message in MIME format. --------------quqO9liZER1PhMKwpK10e0gz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/15/2021 1:52 PM, Eliot Lear wrote: > > Mike: > > On 15.12.21 19:31, Michael StJohns wrote: >> No. Individual members of the RSAB/RSWG may be asked for their input >> on how the various contractors perform and may reply, as with any >> member of the community in good standing.  Neither the RSAB nor the >> RSWG shall give or offer to give a coordinated statement or >> evaluation.  I'm pretty sure we've already indicated that the RSAB >> has no personnel responsibilities. > > That's incorrect: > > Periodically, the IETF LLC will evaluate the performance of the RSCE, > including a call for confidential input from the community. The IETF > LLC will produce a draft evaluation of the RSCE's performance for > review by RSAB members other than the RSCE, who will provide feedback > to the IETF LLC. > > And the group did negotiate at some length on that text.  We don't > have such text for the RPC, but that's because the LLC has an existing > process for the RPC.  Now we may have an inconsistency in the text > about open meeting matters. > > Eliot > Hi Eliot - That text predates this text AFAICT: > The appointing bodies, i.e., the stream approval bodies (IESG, IAB, > IRTF chair, ISE), shall determine their own processes for appointing > RSAB members (note that processes related to the RSCE are described > under Section 5). Each appointing body shall have the power to > remove its appointed RSAB member at its discretion at any time. > Appointing bodies should ensure that voting members are seated at all > times and should fill any vacancies with all due speed, if necessary > on a temporary basis. The gist of that second text is that a) the member appointed to the RSAB does not have to originate from the appointing organization, and b) a member on the RSAB at the time of the request for review is not necessarily the one that has been working with the RSCE over the last few years or so and may have little if anything useful to say, and c) this still  has the potential for having the RSAB think they are managing the RSCE. In this read through I've been looking at synergistic implications of how the various clauses interact.     While I agree that the text you cited exists, I suggest it is the wrong text given the text I cited.  Basically, the LLC should feel free to reach out to the actual individuals that have experience with the RSCE  for a personal evaluation rather than giving the RSAB more pseudo-authority with respect to the RSCE. I can see no real reason for the RSAB to meet in executive session with the sole exception of discussing with the ED various candidates for the RSCE job and even then I'm not sure that's a good idea.  Instead, the LLC could adopt the current members of the RSAB onto the selection board and set their own processes that way. Finally, if there is a possibility of executive sessions, how broadly can information from an executive session be shared?  Can the non-IESG member appointed by the IESG share discussions with the IESG?  On what topics?  If a member is replaced mid-executive-discussion, what happens?  Can the RSAB emit a response to the LLC's queries if it is incomplete?  Does the LLC have to wait until the RSAB is reconstituted (member replaced) to get a response to its queries?  E.g. is the evaluation document a "policy document"?  Etc, etc, etc.  Let's simplify this and just keep all of the RSAB stuff in the light. And rather than reply to EKR's notes let me say here that letting the RSAB have the choice of ignoring the RPC or only sometime have them as a liaison based on how 3 of the RSAB are feeling that day seems to be shooting ourselves in the foot.   The RPC should be able to have a liaison on the RSAB for some of the same reasons that we've specified that the ED is a liaison.  To paraphrase: To ensure the smooth operation of the RFC Series, the RSAB shall include the s/IETF Executive Director or their delegate/a person appointed by the RPC/ as a non-voting member, because the s/IETF LLC/RPC/ is responsible for s/implementation of policies governing the RFC Series/publication of the RFC series and implementation of processes specified under the scheme defined herein/ Later, Mike --------------quqO9liZER1PhMKwpK10e0gz Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/15/2021 1:52 PM, Eliot Lear wrote:

Mike:

On 15.12.21 19:31, Michael StJohns wrote:
No.  Individual members of the RSAB/RSWG may be asked for their input on how the various contractors perform and may reply, as with any member of the community in good standing.  Neither the RSAB nor the RSWG shall give or offer to give a coordinated statement or evaluation.  I'm pretty sure we've already indicated that the RSAB has no personnel responsibilities.

That's incorrect:

   Periodically, the IETF LLC will evaluate the performance of the RSCE,
   including a call for confidential input from the community.  The IETF
   LLC will produce a draft evaluation of the RSCE's performance for
   review by RSAB members other than the RSCE, who will provide feedback
   to the IETF LLC.

And the group did negotiate at some length on that text.  We don't have such text for the RPC, but that's because the LLC has an existing process for the RPC.  Now we may have an inconsistency in the text about open meeting matters.

Eliot

Hi Eliot -

That text predates this text AFAICT:

   The appointing bodies, i.e., the stream approval bodies (IESG, IAB,
   IRTF chair, ISE), shall determine their own processes for appointing
   RSAB members (note that processes related to the RSCE are described
   under Section 5).  Each appointing body shall have the power to
   remove its appointed RSAB member at its discretion at any time.
   Appointing bodies should ensure that voting members are seated at all
   times and should fill any vacancies with all due speed, if necessary
   on a temporary basis.

The gist of that second text is that a) the member appointed to the RSAB does not have to originate from the appointing organization, and b) a member on the RSAB at the time of the request for review is not necessarily the one that has been working with the RSCE over the last few years or so and may have little if anything useful to say, and c) this still  has the potential for having the RSAB think they are managing the RSCE.

In this read through I've been looking at synergistic implications of how the various clauses interact.     While I agree that the text you cited exists, I suggest it is the wrong text given the text I cited.  Basically, the LLC should feel free to reach out to the actual individuals that have experience with the RSCE  for a personal evaluation rather than giving the RSAB more pseudo-authority with respect to the RSCE. 

I can see no real reason for the RSAB to meet in executive session with the sole exception of discussing with the ED various candidates for the RSCE job and even then I'm not sure that's a good idea.  Instead, the LLC could adopt the current members of the RSAB onto the selection board and set their own processes that way.

Finally, if there is a possibility of executive sessions, how broadly can information from an executive session be shared?  Can the non-IESG member appointed by the IESG share discussions with the IESG?  On what topics?  If a member is replaced mid-executive-discussion, what happens?  Can the RSAB emit a response to the LLC's queries if it is incomplete?  Does the LLC have to wait until the RSAB is reconstituted (member replaced) to get a response to its queries?  E.g. is the evaluation document a "policy document"?  Etc, etc, etc.  Let's simplify this and just keep all of the RSAB stuff in the light.

And rather than reply to EKR's notes let me say here that letting the RSAB have the choice of ignoring the RPC or only sometime have them as a liaison based on how 3 of the RSAB are feeling that day seems to be shooting ourselves in the foot.   The RPC should be able to have a liaison on the RSAB for some of the same reasons that we've specified that the ED is a liaison.  To paraphrase:

To ensure the smooth operation of the RFC Series, the RSAB shall
   include the s/IETF Executive Director or their delegate/a person appointed by the RPC/ as a non-voting
   member, because the s/IETF LLC/RPC/ is responsible for s/implementation of
   policies governing the RFC Series/publication of the RFC series and implementation of processes specified under the scheme defined herein/

Later, Mike


--------------quqO9liZER1PhMKwpK10e0gz-- From nobody Wed Dec 15 15:37:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B73613A07F5 for ; Wed, 15 Dec 2021 15:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=lBs+JkrA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=anQS1DyP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcPMp4X2uGMv for ; Wed, 15 Dec 2021 15:37:41 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA6EE3A07F1 for ; Wed, 15 Dec 2021 15:37:41 -0800 (PST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 38C5D3200A60; Wed, 15 Dec 2021 18:37:37 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 15 Dec 2021 18:37:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=S NlA0pzaVRByQ4zJZIKO8Jg5iUDDGetoHRAOC4Czkww=; b=lBs+JkrA/g4amvQx3 atA/8WjOOxsrE52tf6B4VSAssiEBhsor4Wfp6un7edeE17mVLLUxKS0M8TVywn1P 6zqiMx+sNrPer/rCcZzeJxIarFv4RJWx0B1QPJ0mkdNBP3qesyKTaACr2vpQd3zf dAHGwczN3u3scOh1ThBKFgCSeH4I71teoQtRtvw5vaIUWQxRYoOR7wu/tXFY24/r FfLMt0FmG6fm6CRWtLlcDejY8DN9ptKFUqbRmFEim9rrtbj+gixYngxJNh3M+4k7 Diz/EwT8wcHvrnvuAK05w7NcOkPIQ8UPvsiCxy+HIgU/aU4Mocg4JULGHO6ulHHe SCQKQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=SNlA0pzaVRByQ4zJZIKO8Jg5iUDDGetoHRAOC4Czk ww=; b=anQS1DyPiOIEtKreVU+hEL+Qf9XNBPH1MSGht818pzMUUa/rIjsPz2Gmi zagSaF9FYpbmCOsAIPaLibtVmlzMe883elF2sDq1t3SSy3xllO7Elb5uMQ/L1m0C NAAL8wbOugwqAyk7piHxx2sGySXS+sWi77Hk0ccBQSfPJc4qAJBz0PGcHnHHMxAX FTXvAxMPYQUudSr0jpNnkqFCRXeoopiXCYyvNOm/eT4aSnGmgzrD7COy/aJz9irQ g+rJk+tNIDKioyFI1oIDmbFUj8TfBTvumNu9E+QBTt/Gi9Me2I4igZYMPCCFtyqo WPfDR364lF3YXyY/s/FGzVRJdr+kw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleefgddtkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfhfhfgjtgfgsehtjeertddtfeejnecuhfhrohhmpefrvghtvghr ucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqeenuc ggtffrrghtthgvrhhnpeekleeitddvgfduuefgffdvjedvgffhhfeuvdejleeggfeguddt iedvheeuveehfeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrh fuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgv thgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Dec 2021 18:37:36 -0500 (EST) Message-ID: Date: Wed, 15 Dec 2021 16:37:32 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Brian E Carpenter , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> From: Peter Saint-Andre In-Reply-To: <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:37:47 -0000 On 12/11/21 1:06 PM, Brian E Carpenter wrote: > If you really want a new issue, here's one: As far as I can see, we > don't specify whether the RSAB's mailing list does, or doesn't, have a > public archive. Filed as #143: https://github.com/intarchboard/program-rfced-future/issues/143 Peter From nobody Wed Dec 15 15:48:40 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 175FD3A0B09 for ; Wed, 15 Dec 2021 15:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=bSy4YN88; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jv1SjXsN Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jV7avHusTu8g for ; Wed, 15 Dec 2021 15:48:34 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B073E3A0AFB for ; Wed, 15 Dec 2021 15:48:34 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C46223200A2F; Wed, 15 Dec 2021 18:48:32 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 15 Dec 2021 18:48:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=d TDTu11viczc2VsxkNcNf+TLFkeUHvHCji7dlow8k+4=; b=bSy4YN88vf5DmNh8n +N0dlWQKIKmDttYDc92hH4hxmVxAYNu0S75bgoiivnZVb3rOkPTT2ccOx42q8sMz 6A2nkJPeaXvtiLIQZy62jxm+dFCT98jWFJRv4RYbROWWxjGv739Ra9bW3meNLm1m GfzoR7uDfg+mDz6t9qL5RoPzEuKAEeRemW/34yUcGp3wV6wxwguobfdpZKrOZO/a KRUd9CndV4kraFF/3hQ1MJr53FGHrMx+HpGzDbyvSiSPtyA26UhCJdczwOYqvnlK kPgdUvCa4newFwtBLnXS1R4iURhEmBOCwarCb0yBWCA4Opg0QXqA4fnxbOrsC5IV 8M0qg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=dTDTu11viczc2VsxkNcNf+TLFkeUHvHCji7dlow8k +4=; b=jv1SjXsNP8y7f09VLEKW95KnDUD6NCU7U+C524I/0BsklUJ9gIKWAmPq6 AShI0Y5/N5wizS3guJGZUUgvgpalpK4s/ccEiZr0yQy9RIrraOU1t4UFDwkeE+jb bHpZlYVNp1gGVr4//mbL6Ajct06mTPFb/VF4aOg7cLhmgacEEHJyPzMFcGIMAL88 PeQMVSpryJXdFUisw7YMQ9GGWmuP04/9rGU0M+86mz3l2xmgCkLfq1D7I2Rse59j HGwdWow8DFGOsrkohQLjInL09L1CliJRDG3c+v92iJU+K2MCrHk+LB64ZLa6LFmd Fxc7JlQ2cbOWX90RCIs4DhclzO7Tw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleefgddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthekre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepvedtgfettefgffevhe etvddugedugfelveeftdelveetgfefgefggfefledukeehnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgvthgvrh drihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Dec 2021 18:48:31 -0500 (EST) Message-ID: Date: Wed, 15 Dec 2021 16:48:30 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Michael StJohns , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> From: Peter Saint-Andre In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:48:39 -0000 On 12/10/21 12:05 PM, Michael StJohns wrote: > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: >> Hi Eliot >> >> Sorry I should have been clearer about what kind of change I had in mind. >> >> Current the text says: shall have the ED as liaison, and my have >> others e.g. RPC >> >> I think it should rather say: shall have ED and RPC and may have others >> >> As you say below I also think the RSAB and RPC can meet how often they >> want and there is noting in the doc that would stop them. But having >> the shall there for the ED and only naming the RPC as an example of >> others seem to give the impressing that having a liaison to the RPC is >> less important. I don’t think that maps the relation between the RSAB >> and RPC as described in the rest of the document. >> >> Mirja > > > Hi Mirja - > > I agree with you that the RPC should be represented.  It probably can't > be done directively here because of contracts. So "The ED shall be a > liaison member of the RSAB.  The entity performing the tasks of the RPC > may also appoint a liaison member to the RSAB. Liaisions may participate > in all activities of the RSAB as non-voting members."  E.g. the choice > is the RPC's not the RSAB's in this case. Although as the document editor I'll add whatever text we agree on, this seems backward: RSAB should be the entity that initiates liaison arrangements, and we've had text to that effect for a long time now. Peter From nobody Wed Dec 15 16:01:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D0AB3A0CCD for ; Wed, 15 Dec 2021 16:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20210112.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 8CSfte1t4ghF for ; Wed, 15 Dec 2021 16:00:56 -0800 (PST) Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 862323A0CAA for ; Wed, 15 Dec 2021 16:00:56 -0800 (PST) Received: by mail-lf1-x12a.google.com with SMTP id c32so46303858lfv.4 for ; Wed, 15 Dec 2021 16:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VwXH0LPVGtbow3VxTjvIgHtQitzBu887XSK0a55g8vI=; b=4dIRDxjicWg7++uP7hG+G12wxvuV65yseNEWfWm/4CXHzx25numD14jiWe7QWtV/gp hM31zynyBC47Y5Ng47rnlepLZwqO4WcQePGzWhhZNxmpxzErNqXZkP8A/gvrrBuBxpXK oZvuq2cbs1+yjP3ao4vAHVtdk4cEeNNEwG77aN+Vz/25w45kJPKv89pI7zun2KzwaApF lsAtwlD21h09uDWqnpOY/WRfa3Ss6pUsBKQArziTRZpKGQ5xs6WcRTSgIVv6EAL3pK2k Q2e6vMjE0npzG4hF4dkPViTbvyewOa/sAZbqetf6sjYU30zURzJcUUVBChLHzRtTHo3M OU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VwXH0LPVGtbow3VxTjvIgHtQitzBu887XSK0a55g8vI=; b=El6lkalB6JVC0JyeFmfDfWwjRhsP64U53whM67D535GAkW7qCuthI1NpP0DRyrbL2O Ybl9Oaci/0ABm0bdGb3Sb/UwksR6SiAj97DD4px+rND6LnCBTnREgvgPqVl3TgENhrjx emuLFz0KhnJijFHkeKoyYhAOph6hO1D8QlXSImlKREq6gs4u66SWfvozO5gwvvQWBclW y+wrM6F3jliyxahzyH+iBo8AX5jjUBRqjAyPjyzdy4u/1SNanwU6A0fT7z7ynvCtL+Xv on1idwrBrBLGIE3iQCV1/sX02gX8QopIvGW9lpT0F/sQ1t/3tVHc/cpmfSMSZrPMoqjh kxSA== X-Gm-Message-State: AOAM533Mxf7JA3QVQ+1vjtlsXfGPaop1qZCLq6sRvPvkh2LI/73LT+Cz PP6ivyVrBCw6nrRPYsCbS220qvnOGwgPe+2jJkVPudFnhH1ZuA== X-Google-Smtp-Source: ABdhPJy1JCypTW9sgTMNXCKrYW9juaYR3in5w83lnjGV2Tl6iY5HkUAJFZ/hKV5svWDiOS8ing0bAb21QcsVrAXaa1A= X-Received: by 2002:a05:6512:33bc:: with SMTP id i28mr12602004lfg.33.1639612852673; Wed, 15 Dec 2021 16:00:52 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> In-Reply-To: From: "StJohns, Michael" Date: Wed, 15 Dec 2021 19:00:41 -0500 Message-ID: To: Peter Saint-Andre Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000a732df05d3381d29" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:01:04 -0000 --000000000000a732df05d3381d29 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre wrote: > On 12/10/21 12:05 PM, Michael StJohns wrote: > > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: > >> Hi Eliot > >> > >> Sorry I should have been clearer about what kind of change I had in > mind. > >> > >> Current the text says: shall have the ED as liaison, and my have > >> others e.g. RPC > >> > >> I think it should rather say: shall have ED and RPC and may have other= s > >> > >> As you say below I also think the RSAB and RPC can meet how often they > >> want and there is noting in the doc that would stop them. But having > >> the shall there for the ED and only naming the RPC as an example of > >> others seem to give the impressing that having a liaison to the RPC is > >> less important. I don=E2=80=99t think that maps the relation between t= he RSAB > >> and RPC as described in the rest of the document. > >> > >> Mirja > > > > > > Hi Mirja - > > > > I agree with you that the RPC should be represented. It probably can't > > be done directively here because of contracts. So "The ED shall be a > > liaison member of the RSAB. The entity performing the tasks of the RPC > > may also appoint a liaison member to the RSAB. Liaisions may participat= e > > in all activities of the RSAB as non-voting members." E.g. the choice > > is the RPC's not the RSAB's in this case. > > Although as the document editor I'll add whatever text we agree on, this > seems backward: RSAB should be the entity that initiates liaison > arrangements, and we've had text to that effect for a long time now. > > Peter Hi Peter - your argument seems to reduce to =E2=80=9Cbecause we call this a= liaison then we should let the RSAB decide. =E2=80=9C Instead maybe fill in: There exist specific situations where not having the RPC participate on the RSAB makes sense for the success of the system, so we should let the RSAB decide when and when not to let the RPC participate. Those situations are: ??? I=E2=80=99ve been unable to think of any such situations. Maybe you=E2=80= =99ve got another perception? Mike > --000000000000a732df05d3381d29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre <stpeter@stpeter.im> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On 12/10/21 12:05 PM, Michael StJohns wrote:<= br> > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote:
>> Hi Eliot
>>
>> Sorry I should have been clearer about what kind of change I had i= n mind.
>>
>> Current the text says: shall have the ED as liaison, and my have <= br> >> others e.g. RPC
>>
>> I think it should rather say: shall have ED and RPC and may have o= thers
>>
>> As you say below I also think the RSAB and RPC can meet how often = they
>> want and there is noting in the doc that would stop them. But havi= ng
>> the shall there for the ED and only naming the RPC as an example o= f
>> others seem to give the impressing that having a liaison to the RP= C is
>> less important. I don=E2=80=99t think that maps the relation betwe= en the RSAB
>> and RPC as described in the rest of the document.
>>
>> Mirja
>
>
> Hi Mirja -
>
> I agree with you that the RPC should be represented.=C2=A0 It probably= can't
> be done directively here because of contracts. So "The ED shall b= e a
> liaison member of the RSAB.=C2=A0 The entity performing the tasks of t= he RPC
> may also appoint a liaison member to the RSAB. Liaisions may participa= te
> in all activities of the RSAB as non-voting members."=C2=A0 E.g. = the choice
> is the RPC's not the RSAB's in this case.

Although as the document editor I'll add whatever text we agree on, thi= s
seems backward: RSAB should be the entity that initiates liaison
arrangements, and we've had text to that effect for a long time now.
Peter

Hi Peter - = your argument seems to reduce to =E2=80=9Cbecause we call this a liaison th= en we should let the RSAB decide. =E2=80=9C

Instead maybe fill in: There exist specific situations = where not having the RPC participate on the RSAB makes sense for the succes= s of the system, so we should let the RSAB decide when and when not to let = the RPC participate.=C2=A0 Those situations are: ???

I=E2=80=99ve been unable to think of any such = situations.=C2=A0 Maybe you=E2=80=99ve got another perception?


Mike



--000000000000a732df05d3381d29-- From nobody Wed Dec 15 16:08:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADB303A0D26 for ; Wed, 15 Dec 2021 16:08:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=cpLE+iAf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nx6FkiiM Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8W0mbzaEwvN for ; Wed, 15 Dec 2021 16:08:31 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48AF03A0D25 for ; Wed, 15 Dec 2021 16:08:31 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id A5F7D3200AB0; Wed, 15 Dec 2021 19:08:27 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 15 Dec 2021 19:08:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:to:cc:references:from:subject :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=X TE7wH2OMHKo28wu9BhIg3+ibBwB5rarKg6n2qhaypU=; b=cpLE+iAf1N8CGq+Um 5e96HeEUMhFDsuFegLaAHoRaJHLzVn4XEQGQEtalbLkZ/m3esmm3ycXn1ayz2FLy WIOIthh8Yapyqwos7tphuNU3TP09dgzM+HJ65d62bND6r02efDztuyjQFo6spSW7 kk26Lf2Xuf31gQrZlPMAuHZGcH5H5OwgbPPr7RjrjE8b94Z/z9TyETUe4hk7Uw0W zw8ruhHOOWCnjMCy2pqvWyHJ4DSvHRmBsPY4Ma31aImXr9kN7D7fUkYZ4b1/jlQC hxmrp2Bny92RkxxMIPXkQV4j7vDM7uOBv0cYD0udbG7iCrFy7N3K+O8CrV4Z8OzB g36Dg== 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=fm1; bh=XTE7wH2OMHKo28wu9BhIg3+ibBwB5rarKg6n2qhay pU=; b=nx6FkiiM2dsXedeUkMtpB707hH98a8mcL/BkQq8DRQ9yIx9gWjJaqedw9 lGodFwoWp64eP4IuD0jQO8JRPDhS/NgqvOlRqspSCfBjG6xSZGEmLParIX7cmNwT 7gkEqMklMONBnoxLgSJOiWXKaPVYhc2/noZrwfJiOnEmVNdoiVKPpL3nmrDNhMDt iy373ryCwlPwb5SzTbtOwqNXCzvqnkeaBrdP5RAV7dAtKD2U3dx6l9Ujrc4jbyPF 9w7vl4IOtFt1+4vdBSY9Ic5C+rlIJ/oIh9eiaF926C8ELxvj34ePBLPSqTQSHFQW TfAM59q+bN+sdJmxyzb2W38RZnX8Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleefgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfvfhfhffujggtgfesthekre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepfedvhffhfeefudethf elhffhgffhudeigfdvgeefieeikeduhfeigeeluddtieehnecuffhomhgrihhnpehifhhp shhmrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Dec 2021 19:08:26 -0500 (EST) Message-ID: <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> Date: Wed, 15 Dec 2021 17:08:22 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: "StJohns, Michael" Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> From: Peter Saint-Andre In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:08:37 -0000 On 12/15/21 5:00 PM, StJohns, Michael wrote: > > > On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre > wrote: > > On 12/10/21 12:05 PM, Michael StJohns wrote: > > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: > >> Hi Eliot > >> > >> Sorry I should have been clearer about what kind of change I had > in mind. > >> > >> Current the text says: shall have the ED as liaison, and my have > >> others e.g. RPC > >> > >> I think it should rather say: shall have ED and RPC and may have > others > >> > >> As you say below I also think the RSAB and RPC can meet how > often they > >> want and there is noting in the doc that would stop them. But > having > >> the shall there for the ED and only naming the RPC as an example of > >> others seem to give the impressing that having a liaison to the > RPC is > >> less important. I don’t think that maps the relation between the > RSAB > >> and RPC as described in the rest of the document. > >> > >> Mirja > > > > > > Hi Mirja - > > > > I agree with you that the RPC should be represented.  It probably > can't > > be done directively here because of contracts. So "The ED shall be a > > liaison member of the RSAB.  The entity performing the tasks of > the RPC > > may also appoint a liaison member to the RSAB. Liaisions may > participate > > in all activities of the RSAB as non-voting members."  E.g. the > choice > > is the RPC's not the RSAB's in this case. > > Although as the document editor I'll add whatever text we agree on, > this > seems backward: RSAB should be the entity that initiates liaison > arrangements, and we've had text to that effect for a long time now. > > Peter > > > Hi Peter - your argument seems to reduce to “because we call this a > liaison then we should let the RSAB decide. “ > > Instead maybe fill in: There exist specific situations where not having > the RPC participate on the RSAB makes sense for the success of the > system, so we should let the RSAB decide when and when not to let the > RPC participate.  Those situations are: ??? > > I’ve been unable to think of any such situations.  Maybe you’ve got > another perception? It just seems strange to me that any arbitrary entity can proactively appoint a liaison to the RSAB and expect to have a seat at the table. Can, say, ISOC or ICANN or ISO or W3C or NIST or 3GPP or IFPSM [1] do that, too? (After all, one could argue that they and many others all have a "stake" in the RFC Series.) Peter [1] https://www.ifpsm.org/ifpsm From nobody Wed Dec 15 16:16:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1083A0DA0 for ; Wed, 15 Dec 2021 16:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=KRUxBV8H; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k01/gZRv Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pt6ds3oj4HOo for ; Wed, 15 Dec 2021 16:16:49 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D2B53A0D9D for ; Wed, 15 Dec 2021 16:16:48 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 9067432009CC; Wed, 15 Dec 2021 19:16:47 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Wed, 15 Dec 2021 19:16:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:to:cc:references:from:subject :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=9 lGaIfkfzKRpuE6gXnibum6BS/r0PDADaAo3VGv8T8s=; b=KRUxBV8HEXFrh3vAJ VllDPsGhuRxOPWdO/isKbPnHU6KqCQnF2OtOYBVSaBWd/vBfEZuFArcE+XF+2fSm jidKNfzyKBwYktY0h3C7vyd8J3lu7r9IVmGEwyX/A+DTixLq71r2ANI5XjuAYJn2 HHFPMrkJEuXnw0eq0wEHZnTouQbl4rccFhMu/dKimeMzIGlTFVeJ22kJeb4xOnLe BwuPJJPxOY8iggQEwFGu+zm73fUOoW+iURU7N6aPqLVuU/l6dWwFIenC9BQlJL8U MhF4I6gqgVCkrrLtD37yairpiQBbITPVwm6Ohyh3m79pTWS2IcCMGrBNn/r7rNxb 4tCjg== 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=fm1; bh=9lGaIfkfzKRpuE6gXnibum6BS/r0PDADaAo3VGv8T 8s=; b=k01/gZRvajuBQ2xE/UzOnzLVUww97YAxRkKjg4sCbhcK2pG34/WQ9DiCy JdF+IC8bKE262yk0MFpAPXw2jlPtoZtg65imBL4o/0r3JgZvrm/bxIDywbKomXe+ uvDF8NLZbGOMu/TxfHmoSiE5y6NeSvS7uXy/HKNBLV+KupIPSLHLZJLhBIebLMaq /wXNozMy4/DgXmr/AA5VpchrNFs3SEgzmk5brSMOZl95zj9H98bsUbt0X1+rTOcR cumrXKiNmy0DwXeINHYwzPOJhNh6VFabFLu8lGnhMB2Gudd9MIxNs0A55GgUvvm2 9C9vJcmZMGKmdFcG/oVNywoFB53Ew== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleefgdduiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfvfhfhffujggtgfesthejre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepgfelkeevveelgfehje euhfehuefhkeeftdffgfeghfegtedvgeeigfdvkeeltdfgnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgvthgvrh drihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Dec 2021 19:16:46 -0500 (EST) Message-ID: <3872ff33-0aa4-b6dc-c2ea-9feb94f838a4@stpeter.im> Date: Wed, 15 Dec 2021 17:16:41 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Jay Daley , Mirja Kuehlewind Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> From: Peter Saint-Andre In-Reply-To: <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:16:55 -0000 Thanks, Jay, this is helpful. Although I don't have position on this matter, see below for a few observations. On 12/15/21 12:20 PM, Jay Daley wrote: > This is not about importance, it is about the different roles, and trying to find an equivalence between different liaisons where none exists is the wrong way to design a group. The reasons for the RPC being a mandatory liaison should standalone. > > The reason for the ED being a mandatory liaison are well documented - In July in response to community comments, Peter originally proposed text that allowed the RSAB to optionally appoint both the ED and an RPC [1] and different text that mandated the ED but not the RPC [2]. I had previously made the case [3] for a mandatory LLC liaison - "necessary for the LLC in its role of setting the performance targets for the RPC and negotiating the work plan budget/timetables", which was generally accepted. > > When it comes to the RPC being a liaison to RSAB, then the situation is much more complex than it is for the ED. In particular the RSAB needs to reconcile the following: > > - how to manage the RPC input/engagement when discussing the priorities and performance of the RPC > - how to manage responding to RPC requests for advice > - how to manage any conflicting advice from the RSCE and the RPC > > None of these are insurmountable, but I would hope that any proposal for the RPC being a mandatory liaison addresses those issues as not doing that puts the RSAB on a difficult footing from the start. It strikes me that there are several aspects here. 1. Direct conversation between RSAB members and a representative from the RPC could be helpful in working through the topics you've enumerated. 2. The fact that such conversations could be helpful doesn't require us to legislate an RPC liaison in this document, since RSAB would be free to establish it on their own. 3. If there is a liaison from RPC to the RSAB (whether we legislate it now or the RSAB establishes it on its own initiative), the RSAB could discuss any matters it deems sensitive in executive session or the equivalent. 4. Reading between the lines, I hear a concern that RSAB as a body might need to formulate an RSAB "position" before engaging with the RPC on some of these topics. That feels like a more formal interaction model than might be necessary. Peter From nobody Wed Dec 15 16:18:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE683A0DB7 for ; Wed, 15 Dec 2021 16:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 9WRvRN1qzH1R for ; Wed, 15 Dec 2021 16:18:03 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0733A3A0DC2 for ; Wed, 15 Dec 2021 16:18:03 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id r2so20694117ilb.10 for ; Wed, 15 Dec 2021 16:18:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zMIq4mbdTzmcDfvClH2reSIt1e1jqk6wEFtN0IIcAx0=; b=Mi+y+Py2Rua4OmY5mvkSAWfNxtUnf1qb1VQ3lfuGTmAaiBG+EohqJDTfCSDx4o06gh Xvlaz2iEGdbmtdnvivtnbSPCW9sYwt+fS74Y5uj8dkMLtmSWiEQeWoj1dY6jQchlY70P 9iPypC6LoCqGDx57rON3cJMAFJeY/q5c1qQp3Gz83oKdXrbhAoR/IMCCyd8UIQvDuHrU WtlSMKTwOm8CZ0+MznGNCpf8p1dHC+LOsJ1jHrlvCfrgvbY8SQnoTaMF4oq50FcMt1SU mRC+E3D7OssotZtzgXEOZZnu8NMhSO/arHDadDecnFzltVdrspQLBQJ+d+QV4LCpJlAn Su7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zMIq4mbdTzmcDfvClH2reSIt1e1jqk6wEFtN0IIcAx0=; b=Dgvr/6QMTjvCBy8Cpl654nxU/zahWeAE1+lfRnCNO/SPQNe2pDmqIiHNyaQiq4fB7V KxCIKxowLxAEObQ/IkSCTiTxaL4/kadPdD8syMnBarg6BTbY6NB85vnp9C4cFEBLdM2z WtzVRvVi93v9ZWHELvo9AItV8BkFX+rf4aYgqyMCOPDo7vbNZ49y5cu6rATCmg0iZwXD yP6VnepAIc4O54L9x9XakbdP8L6Im6piSKSEStCUokjdoW4pZk4c1aEj1If4X6QjREiJ qRIlKX6F7uXToT2GSP3xTt7BEYKZXOiHDnVZqzMJXgTvnFcqg2Guw3UYdhmEnwfvnOkZ rYBg== X-Gm-Message-State: AOAM533UfsUvKx9WtRyyTQIkvA+y0YF4v3yD02jkL9EVkVt/i+PtJjyE MkVO7X00ZpIW89b3+EIuPNc3J7KTvyz/UjVNzmxEqUlc6Uw= X-Google-Smtp-Source: ABdhPJyeo8tFG5SM+bUb0JsRka1gR4bLJZx2fshrkj0/uXGwKDtFI9aFZkWv5Yz6t2Oq72kFKwVpV0+hxH1RgsRfz0E= X-Received: by 2002:a92:cd8b:: with SMTP id r11mr7989298ilb.39.1639613879958; Wed, 15 Dec 2021 16:17:59 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> In-Reply-To: <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> From: Eric Rescorla Date: Wed, 15 Dec 2021 16:17:23 -0800 Message-ID: To: Peter Saint-Andre Cc: "StJohns, Michael" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000e255b905d3385a26" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:18:09 -0000 --000000000000e255b905d3385a26 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I said earlier, it seems to me that there is quite a bit of daylight between "org X can appoint a liaison to org Y" and "that liaison is part of org Y", so I think the default ought to be quite the opposite of what Mike suggests, namely: - The LLC ED is a non-voting member of the RSAB - The RSAB can allow other non-voting members at its discretion (This is what it currently says) If we must say anything about the RPC beyond the example, it ought to say that the RPC shall appoint a liaison but that the manner of the liaison's participation is up to the RSAB. -Ekr On Wed, Dec 15, 2021 at 4:08 PM Peter Saint-Andre wrote: > On 12/15/21 5:00 PM, StJohns, Michael wrote: > > > > > > On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre > > wrote: > > > > On 12/10/21 12:05 PM, Michael StJohns wrote: > > > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: > > >> Hi Eliot > > >> > > >> Sorry I should have been clearer about what kind of change I ha= d > > in mind. > > >> > > >> Current the text says: shall have the ED as liaison, and my hav= e > > >> others e.g. RPC > > >> > > >> I think it should rather say: shall have ED and RPC and may hav= e > > others > > >> > > >> As you say below I also think the RSAB and RPC can meet how > > often they > > >> want and there is noting in the doc that would stop them. But > > having > > >> the shall there for the ED and only naming the RPC as an exampl= e > of > > >> others seem to give the impressing that having a liaison to the > > RPC is > > >> less important. I don=E2=80=99t think that maps the relation be= tween the > > RSAB > > >> and RPC as described in the rest of the document. > > >> > > >> Mirja > > > > > > > > > Hi Mirja - > > > > > > I agree with you that the RPC should be represented. It probabl= y > > can't > > > be done directively here because of contracts. So "The ED shall > be a > > > liaison member of the RSAB. The entity performing the tasks of > > the RPC > > > may also appoint a liaison member to the RSAB. Liaisions may > > participate > > > in all activities of the RSAB as non-voting members." E.g. the > > choice > > > is the RPC's not the RSAB's in this case. > > > > Although as the document editor I'll add whatever text we agree on, > > this > > seems backward: RSAB should be the entity that initiates liaison > > arrangements, and we've had text to that effect for a long time now= . > > > > Peter > > > > > > Hi Peter - your argument seems to reduce to =E2=80=9Cbecause we call th= is a > > liaison then we should let the RSAB decide. =E2=80=9C > > > > Instead maybe fill in: There exist specific situations where not having > > the RPC participate on the RSAB makes sense for the success of the > > system, so we should let the RSAB decide when and when not to let the > > RPC participate. Those situations are: ??? > > > > I=E2=80=99ve been unable to think of any such situations. Maybe you=E2= =80=99ve got > > another perception? > > It just seems strange to me that any arbitrary entity can proactively > appoint a liaison to the RSAB and expect to have a seat at the table. > Can, say, ISOC or ICANN or ISO or W3C or NIST or 3GPP or IFPSM [1] do > that, too? (After all, one could argue that they and many others all > have a "stake" in the RFC Series.) > > Peter > > [1] https://www.ifpsm.org/ifpsm > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000e255b905d3385a26 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I said earlier, it seems to me that there is quite= a bit of daylight between "org X can appoint a liaison to org Y"= and "that liaison
is part of org Y", so I think t= he default ought to be quite the opposite of what Mike suggests, namely:

- The LLC ED is a non-voting member of the RSAB
- The RSAB can allow other non-voting members at its discretion
=
(This is what it currently says)

If we must s= ay anything about the RPC beyond the example, it ought to say that the RPC = shall appoint a liaison but that the manner of the liaison's participat= ion is up to the RSAB.

-Ekr






On Wed, Dec 15, 2= 021 at 4:08 PM Peter Saint-Andre <= stpeter@stpeter.im> wrote:
On 12/15/21 5:00 PM, StJohns, Michael wrote:
>
>
> On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stp= eter@stpeter.im>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 12/10/21 12:05 PM, Michael StJohns wrote:
>=C2=A0 =C2=A0 =C2=A0 > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote= :
>=C2=A0 =C2=A0 =C2=A0 >> Hi Eliot
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Sorry I should have been clearer about wh= at kind of change I had
>=C2=A0 =C2=A0 =C2=A0in mind.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Current the text says: shall have the ED = as liaison, and my have
>=C2=A0 =C2=A0 =C2=A0 >> others e.g. RPC
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> I think it should rather say: shall have = ED and RPC and may have
>=C2=A0 =C2=A0 =C2=A0others
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> As you say below I also think the RSAB an= d RPC can meet how
>=C2=A0 =C2=A0 =C2=A0often they
>=C2=A0 =C2=A0 =C2=A0 >> want and there is noting in the doc that = would stop them. But
>=C2=A0 =C2=A0 =C2=A0having
>=C2=A0 =C2=A0 =C2=A0 >> the shall there for the ED and only namin= g the RPC as an example of
>=C2=A0 =C2=A0 =C2=A0 >> others seem to give the impressing that h= aving a liaison to the
>=C2=A0 =C2=A0 =C2=A0RPC is
>=C2=A0 =C2=A0 =C2=A0 >> less important. I don=E2=80=99t think tha= t maps the relation between the
>=C2=A0 =C2=A0 =C2=A0RSAB
>=C2=A0 =C2=A0 =C2=A0 >> and RPC as described in the rest of the d= ocument.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Mirja
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Hi Mirja -
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I agree with you that the RPC should be repre= sented.=C2=A0 It probably
>=C2=A0 =C2=A0 =C2=A0can't
>=C2=A0 =C2=A0 =C2=A0 > be done directively here because of contracts= . So "The ED shall be a
>=C2=A0 =C2=A0 =C2=A0 > liaison member of the RSAB.=C2=A0 The entity = performing the tasks of
>=C2=A0 =C2=A0 =C2=A0the RPC
>=C2=A0 =C2=A0 =C2=A0 > may also appoint a liaison member to the RSAB= . Liaisions may
>=C2=A0 =C2=A0 =C2=A0participate
>=C2=A0 =C2=A0 =C2=A0 > in all activities of the RSAB as non-voting m= embers."=C2=A0 E.g. the
>=C2=A0 =C2=A0 =C2=A0choice
>=C2=A0 =C2=A0 =C2=A0 > is the RPC's not the RSAB's in this c= ase.
>
>=C2=A0 =C2=A0 =C2=A0Although as the document editor I'll add whatev= er text we agree on,
>=C2=A0 =C2=A0 =C2=A0this
>=C2=A0 =C2=A0 =C2=A0seems backward: RSAB should be the entity that init= iates liaison
>=C2=A0 =C2=A0 =C2=A0arrangements, and we've had text to that effect= for a long time now.
>
>=C2=A0 =C2=A0 =C2=A0Peter
>
>
> Hi Peter - your argument seems to reduce to =E2=80=9Cbecause we call t= his a
> liaison then we should let the RSAB decide. =E2=80=9C
>
> Instead maybe fill in: There exist specific situations where not havin= g
> the RPC participate on the RSAB makes sense for the success of the > system, so we should let the RSAB decide when and when not to let the =
> RPC participate.=C2=A0 Those situations are: ???
>
> I=E2=80=99ve been unable to think of any such situations.=C2=A0 Maybe = you=E2=80=99ve got
> another perception?

It just seems strange to me that any arbitrary entity can proactively
appoint a liaison to the RSAB and expect to have a seat at the table.
Can, say, ISOC or ICANN or ISO or W3C or NIST or 3GPP or IFPSM [1] do
that, too? (After all, one could argue that they and many others all
have a "stake" in the RFC Series.)

Peter

[1] https://www.ifpsm.org/ifpsm

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000e255b905d3385a26-- From nobody Wed Dec 15 17:25:48 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1302D3A105A for ; Wed, 15 Dec 2021 17:25:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20210112.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 YlDBMlE2EUsR for ; Wed, 15 Dec 2021 17:25:41 -0800 (PST) Received: from mail-lf1-x12e.google.com (mail-lf1-x12e.google.com [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A6093A1059 for ; Wed, 15 Dec 2021 17:25:40 -0800 (PST) Received: by mail-lf1-x12e.google.com with SMTP id t3so105918lfe.12 for ; Wed, 15 Dec 2021 17:25:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CLMrlO81jPtjNt++1McB7mwkhwonWlOlcLQNWroCPjw=; b=jla9s3B/ZNXGX25mpt7IuHaMjNbEFzpvg7iPbD8PUBPW5L9ttFFcXVesWFITN22DDX pP5TMErnj23FNxYmkTWaqEb4QShTDJT04Y/1RcVEVXpMcAQEnGNt4kc6gr+4dBwm4YNU E4KNzAQ8CFJBYwb8R9gQPy87HUAuyqtol3VK8RFvmW43qX0EqHUJ1cptL9pMVsRp6zEr wG5eyYsSmkTer47T1XPk05LvgSg3RviU0xYqiaSqyANNgW88PZc/y21cfZ+I3p/ZH0Xv Ii9gRHUaO2Cjd6cMqvDqGPCZLprBvtt4usPJZHaQK/qCkDhjxDxBh5YWAI33lYh7crN2 H3mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CLMrlO81jPtjNt++1McB7mwkhwonWlOlcLQNWroCPjw=; b=udk6cbaaclsimmh4wmlJBRkyE1/mX0k2U4Em/Aro9x02D93tDkwy5ke1MEfLyNVfYK m7lTTFQLmIe4VshORverZjDEc9b2oVFbHTFcPilXaP9fIW785ehZjDc7WaQPavGdG+yC XNnZ/9b91ympzrUDxgwYHYtta3MmMwFkHz1p5svTaGAawYLfpFQNWbEAU7tjDYF9dJJF x5eMiPOu6n6VHNx4Zh+0Npaypn79FQkWn8+oMBW03y3EJFep2yl6IPTXX3QUZPrcLJSU 6ouDye6u4V0UydAbFGwZ87yx0Jhn+X8zp6s75eGnlUYyaRwl4JfQA3fY0I3m4/UXNtR/ JyMQ== X-Gm-Message-State: AOAM533PUQvXWlD18X62s4yKeLPrMDdywBew7PXoIQmPrAkgIXFiiZp6 McqvZ2TgnSeo168VgqFk36LhenRpDVDYkQvo6L1AzA== X-Google-Smtp-Source: ABdhPJwoPSH9lYKSI5XtwmXth3ixLq28H+y+mnxfFOvt7TtNJGP9MK3O7Jc/ymWl9fdK5oMhPaiPJ5RHNANW6S+6JW8= X-Received: by 2002:a05:6512:1113:: with SMTP id l19mr12441870lfg.247.1639617938273; Wed, 15 Dec 2021 17:25:38 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> In-Reply-To: <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> From: "StJohns, Michael" Date: Wed, 15 Dec 2021 20:25:26 -0500 Message-ID: To: Peter Saint-Andre Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000c7487905d3394c7e" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:25:46 -0000 --000000000000c7487905d3394c7e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 15, 2021 at 19:08 Peter Saint-Andre wrote: > On 12/15/21 5:00 PM, StJohns, Michael wrote: > > > > > > On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre > > wrote: > > > > On 12/10/21 12:05 PM, Michael StJohns wrote: > > > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: > > >> Hi Eliot > > >> > > >> Sorry I should have been clearer about what kind of change I ha= d > > in mind. > > >> > > >> Current the text says: shall have the ED as liaison, and my hav= e > > >> others e.g. RPC > > >> > > >> I think it should rather say: shall have ED and RPC and may hav= e > > others > > >> > > >> As you say below I also think the RSAB and RPC can meet how > > often they > > >> want and there is noting in the doc that would stop them. But > > having > > >> the shall there for the ED and only naming the RPC as an exampl= e > of > > >> others seem to give the impressing that having a liaison to the > > RPC is > > >> less important. I don=E2=80=99t think that maps the relation be= tween the > > RSAB > > >> and RPC as described in the rest of the document. > > >> > > >> Mirja > > > > > > > > > Hi Mirja - > > > > > > I agree with you that the RPC should be represented. It probabl= y > > can't > > > be done directively here because of contracts. So "The ED shall > be a > > > liaison member of the RSAB. The entity performing the tasks of > > the RPC > > > may also appoint a liaison member to the RSAB. Liaisions may > > participate > > > in all activities of the RSAB as non-voting members." E.g. the > > choice > > > is the RPC's not the RSAB's in this case. > > > > Although as the document editor I'll add whatever text we agree on, > > this > > seems backward: RSAB should be the entity that initiates liaison > > arrangements, and we've had text to that effect for a long time now= . > > > > Peter > > > > > > Hi Peter - your argument seems to reduce to =E2=80=9Cbecause we call th= is a > > liaison then we should let the RSAB decide. =E2=80=9C > > > > Instead maybe fill in: There exist specific situations where not having > > the RPC participate on the RSAB makes sense for the success of the > > system, so we should let the RSAB decide when and when not to let the > > RPC participate. Those situations are: ??? > > > > I=E2=80=99ve been unable to think of any such situations. Maybe you=E2= =80=99ve got > > another perception? > > It just seems strange to me that any arbitrary entity can proactively > appoint a liaison to the RSAB and expect to have a seat at the table. > Can, say, ISOC or ICANN or ISO or W3C or NIST or 3GPP or IFPSM [1] do > that, too? (After all, one could argue that they and many others all > have a "stake" in the RFC Series.) > > Peter > > [1] https://www.ifpsm.org/ifpsm How the heck did you get from my =E2=80=9Chave the RPC participate as a mat= ter of course=E2=80=9D to your =E2=80=9Cany TD&H may become a liaison without the= RSAB signing off=E2=80=9D? Mike > --000000000000c7487905d3394c7e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Dec 15, 2021 at 19:08 Peter Saint-Andre <stpeter@stpeter.im> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">On 12/15/21 5:00 PM, StJohns, Michael wrote:<= br> >
>
> On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stp= eter@stpeter.im>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 12/10/21 12:05 PM, Michael StJohns wrote:
>=C2=A0 =C2=A0 =C2=A0 > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote= :
>=C2=A0 =C2=A0 =C2=A0 >> Hi Eliot
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Sorry I should have been clearer about wh= at kind of change I had
>=C2=A0 =C2=A0 =C2=A0in mind.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Current the text says: shall have the ED = as liaison, and my have
>=C2=A0 =C2=A0 =C2=A0 >> others e.g. RPC
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> I think it should rather say: shall have = ED and RPC and may have
>=C2=A0 =C2=A0 =C2=A0others
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> As you say below I also think the RSAB an= d RPC can meet how
>=C2=A0 =C2=A0 =C2=A0often they
>=C2=A0 =C2=A0 =C2=A0 >> want and there is noting in the doc that = would stop them. But
>=C2=A0 =C2=A0 =C2=A0having
>=C2=A0 =C2=A0 =C2=A0 >> the shall there for the ED and only namin= g the RPC as an example of
>=C2=A0 =C2=A0 =C2=A0 >> others seem to give the impressing that h= aving a liaison to the
>=C2=A0 =C2=A0 =C2=A0RPC is
>=C2=A0 =C2=A0 =C2=A0 >> less important. I don=E2=80=99t think tha= t maps the relation between the
>=C2=A0 =C2=A0 =C2=A0RSAB
>=C2=A0 =C2=A0 =C2=A0 >> and RPC as described in the rest of the d= ocument.
>=C2=A0 =C2=A0 =C2=A0 >>
>=C2=A0 =C2=A0 =C2=A0 >> Mirja
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Hi Mirja -
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I agree with you that the RPC should be repre= sented.=C2=A0 It probably
>=C2=A0 =C2=A0 =C2=A0can't
>=C2=A0 =C2=A0 =C2=A0 > be done directively here because of contracts= . So "The ED shall be a
>=C2=A0 =C2=A0 =C2=A0 > liaison member of the RSAB.=C2=A0 The entity = performing the tasks of
>=C2=A0 =C2=A0 =C2=A0the RPC
>=C2=A0 =C2=A0 =C2=A0 > may also appoint a liaison member to the RSAB= . Liaisions may
>=C2=A0 =C2=A0 =C2=A0participate
>=C2=A0 =C2=A0 =C2=A0 > in all activities of the RSAB as non-voting m= embers."=C2=A0 E.g. the
>=C2=A0 =C2=A0 =C2=A0choice
>=C2=A0 =C2=A0 =C2=A0 > is the RPC's not the RSAB's in this c= ase.
>
>=C2=A0 =C2=A0 =C2=A0Although as the document editor I'll add whatev= er text we agree on,
>=C2=A0 =C2=A0 =C2=A0this
>=C2=A0 =C2=A0 =C2=A0seems backward: RSAB should be the entity that init= iates liaison
>=C2=A0 =C2=A0 =C2=A0arrangements, and we've had text to that effect= for a long time now.
>
>=C2=A0 =C2=A0 =C2=A0Peter
>
>
> Hi Peter - your argument seems to reduce to =E2=80=9Cbecause we call t= his a
> liaison then we should let the RSAB decide. =E2=80=9C
>
> Instead maybe fill in: There exist specific situations where not havin= g
> the RPC participate on the RSAB makes sense for the success of the > system, so we should let the RSAB decide when and when not to let the =
> RPC participate.=C2=A0 Those situations are: ???
>
> I=E2=80=99ve been unable to think of any such situations.=C2=A0 Maybe = you=E2=80=99ve got
> another perception?

It just seems strange to me that any arbitrary entity can proactively
appoint a liaison to the RSAB and expect to have a seat at the table.
Can, say, ISOC or ICANN or ISO or W3C or NIST or 3GPP or IFPSM [1] do
that, too? (After all, one could argue that they and many others all
have a "stake" in the RFC Series.)

Peter

[1] https://www.ifpsm.org/ifpsm

How the heck did you get from my =E2=80=9Chave the RPC= participate as a matter of course=E2=80=9D to =C2=A0your =E2=80=9Cany TD&a= mp;H may become a liaison without the RSAB signing off=E2=80=9D?

Mike


--000000000000c7487905d3394c7e-- From nobody Wed Dec 15 17:32:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEDEE3A07BA for ; Wed, 15 Dec 2021 17:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=o8Kl5/kx; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SGUiTKpA Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oPM7XqAopDeq for ; Wed, 15 Dec 2021 17:32:31 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF7433A079F for ; Wed, 15 Dec 2021 17:32:28 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 9C9093200A1E; Wed, 15 Dec 2021 20:32:27 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 15 Dec 2021 20:32:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=6 zqSrMVt40j2CD+ivLb/rXvOPCjfT6P0hrGiFZf6xgw=; b=o8Kl5/kxSD7DYoEaH UHWokK0xgcQbkACFhCs05lTYzXXQdUr9uvGMcZSX9cG/4t/LRZbw07vjRlt7X1sy 3681t7FqoCDUVMLIhg6iw9PIpGuL1c29R/DGhL8beAxT1iHVSslc/RE+RCmDQQ0Y RzVOXeiNvGm0lk/9DihCwcVyLThqmKOXuFjh8CrkkR4fyCuW0ebfeioZxY1scaGS vYpOWGrAXAMcZyJRcLGWITHw6R1NwmKU8MY1i0rLOzE1ClChhEmg66CkFN+j3Ddy 6T4X4xIWHAPaJrkH2A0859vBvoIr6esmcZf0ZcyvLj4p6Sg1PC9gSI/4Yse246cw sxPmw== 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=fm1; bh=6zqSrMVt40j2CD+ivLb/rXvOPCjfT6P0hrGiFZf6x gw=; b=SGUiTKpAXhW9xcvQU0feEHwETMVTLvdRrQHkpfBRxBVaDgyl0ysk8ORUk /sSAkA1m15iuNke2cYcnVWB0IbyGiCSfxqRHnv7uUwq+HEGzT3BaqxAiupaA6Rk9 CzCCxPOdRiyKObZMdUxcRI0iWGNIrJuk1zbTlyRovMDEK//HaVj65UD5g1Ph8zP3 60vk8CGGs20mWzLHrhYvfFEMrFa3Qe+8ka4sTxO0WzqNKxrdM1gp2zVXKrOjUuXF HJgYya/6t0t+UcvsDqu+4/vwHQjfgsy6bfN+5Jvp0njGXVWV6xVes96x9nkv89Br WCND5ho9uOaEzngFzb6Ou5Fd58sSw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleefgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthekre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnheptdetffehteegteduie eikeekiedutdeugeejleevheegvdfhjedujeetieeikedvnecuffhomhgrihhnpehifhhp shhmrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Dec 2021 20:32:26 -0500 (EST) Message-ID: <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> Date: Wed, 15 Dec 2021 18:32:21 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: "StJohns, Michael" Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> From: Peter Saint-Andre In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:32:44 -0000 On 12/15/21 6:25 PM, StJohns, Michael wrote: > > > On Wed, Dec 15, 2021 at 19:08 Peter Saint-Andre > wrote: > > On 12/15/21 5:00 PM, StJohns, Michael wrote: > > > > > > On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre > > > >> wrote: > > > >     On 12/10/21 12:05 PM, Michael StJohns wrote: > >      > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: > >      >> Hi Eliot > >      >> > >      >> Sorry I should have been clearer about what kind of > change I had > >     in mind. > >      >> > >      >> Current the text says: shall have the ED as liaison, and > my have > >      >> others e.g. RPC > >      >> > >      >> I think it should rather say: shall have ED and RPC and > may have > >     others > >      >> > >      >> As you say below I also think the RSAB and RPC can meet how > >     often they > >      >> want and there is noting in the doc that would stop them. But > >     having > >      >> the shall there for the ED and only naming the RPC as an > example of > >      >> others seem to give the impressing that having a liaison > to the > >     RPC is > >      >> less important. I don’t think that maps the relation > between the > >     RSAB > >      >> and RPC as described in the rest of the document. > >      >> > >      >> Mirja > >      > > >      > > >      > Hi Mirja - > >      > > >      > I agree with you that the RPC should be represented.  It > probably > >     can't > >      > be done directively here because of contracts. So "The ED > shall be a > >      > liaison member of the RSAB.  The entity performing the > tasks of > >     the RPC > >      > may also appoint a liaison member to the RSAB. Liaisions may > >     participate > >      > in all activities of the RSAB as non-voting members." > E.g. the > >     choice > >      > is the RPC's not the RSAB's in this case. > > > >     Although as the document editor I'll add whatever text we > agree on, > >     this > >     seems backward: RSAB should be the entity that initiates liaison > >     arrangements, and we've had text to that effect for a long > time now. > > > >     Peter > > > > > > Hi Peter - your argument seems to reduce to “because we call this a > > liaison then we should let the RSAB decide. “ > > > > Instead maybe fill in: There exist specific situations where not > having > > the RPC participate on the RSAB makes sense for the success of the > > system, so we should let the RSAB decide when and when not to let > the > > RPC participate.  Those situations are: ??? > > > > I’ve been unable to think of any such situations.  Maybe you’ve got > > another perception? > > It just seems strange to me that any arbitrary entity can proactively > appoint a liaison to the RSAB and expect to have a seat at the table. > Can, say, ISOC or ICANN or ISO or W3C or NIST or 3GPP or IFPSM [1] do > that, too? (After all, one could argue that they and many others all > have a "stake" in the RFC Series.) > > Peter > > [1] https://www.ifpsm.org/ifpsm > > > How the heck did you get from my “have the RPC participate as a matter > of course” to  your “any TD&H may become a liaison without the RSAB > signing off”? Perhaps I misunderstood this statement of yours: "The entity performing the tasks of the RPC may also appoint a liaison member to the RSAB." What exactly does it mean to appoint a liaison member to the RSAB (or any other group)? Such a liaison relationship needs to be mutual, which means it needs to be accepted by the group to which the liaison is named, in this case the RSAB. The RPC can't just appoint a liaison on its own. Peter From nobody Wed Dec 15 18:20:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE893A09FF for ; Wed, 15 Dec 2021 18:20:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20210112.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 qRV6wF2hNeio for ; Wed, 15 Dec 2021 18:20:08 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C6B23A09FD for ; Wed, 15 Dec 2021 18:20:08 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id k23so36190382lje.1 for ; Wed, 15 Dec 2021 18:20:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BGQbCyrpT78wMCQNO5h8gaxRrqdf7fbijrfODYaXWYg=; b=GfDEQ5AWG8p6gjZj7Us1/2ydW/QI6CP7jAjjLt92rZdh2ja9+6JhY5Q0iNWKaXr/yW VNRhe7HXKLHiJRQJLDhVrjekIrVgfl7Q+Y/IH0J9a8z4qbwEjcptI9G7d673/rfAtLCA RBVtfeCfiJfV1yA68jzlz8Rs+596jYrX4RlP9CC7Sg6Exu611BN01o+xZ6ke6/20/q1W hag+HsephvP25ypGlak4uwoyoVI1F3g+nuXh69VwexgscLtIylQ/V8gsEdOLkPa55qEQ mXVs+Ib1anqxJwRSK7YDBRP12P8XdfAzli16L+N82VWOsuRFMlZFJVnQGPG7NecWiz+e gOwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BGQbCyrpT78wMCQNO5h8gaxRrqdf7fbijrfODYaXWYg=; b=NUhqctkz4Dxm+tcxkjU+PeKXwB7FX+tOYJubyRvrckgqfrBrJj/iVX4MIFUj/1yo0K enxAgzapoLeK1nGMfT6c0T8Yxo/3gU2mGTsqJ3EDC0oitYau59hVKkr9p/Mg7uY1Wjn9 W5T201sgxrMK572x6nQcwBkrmhY8vmOPzKOdrpu3v8/COxxBM1vUR6wwqHW0N56orIfu AQgNLnp79uQm0R4QMguyEScylZWqzZOzKm0o83OEg936g3dY+Ulj5tEEqoTxJsOLUr1D o1sSKqs6sk9jyjs6t31r+LqJOJ/cqbMgsMGaCfIPe6WaB8lJQ7+i0wwfNw+J3nYtxnWn q92Q== X-Gm-Message-State: AOAM533Xx7b9Rscw5R0I54F74QExfmOBusrP1ZaudF4Ifq5sfWidZInY H14+AnospDlMw3TBwMPKexXEOpUgRCS5GYK6xT3Z222klJluZA== X-Google-Smtp-Source: ABdhPJyR8i4rgAUCohG98MV+61ppO7uPmojro+uMmIsW1I8iIjz4qVVmX8uu5WUdc9Y5g77NQjgaOZB6AMyXKTPtGGM= X-Received: by 2002:a2e:a4a5:: with SMTP id g5mr13620706ljm.176.1639621205188; Wed, 15 Dec 2021 18:20:05 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> In-Reply-To: <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> From: "StJohns, Michael" Date: Wed, 15 Dec 2021 21:19:54 -0500 Message-ID: To: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000080780c05d33a0fbf" Archived-At: Subject: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 02:20:14 -0000 --00000000000080780c05d33a0fbf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes I did. Oops. ---------- Forwarded message --------- From: Peter Saint-Andre Date: Wed, Dec 15, 2021 at 21:10 Subject: Re: [Rfced-future] RPC liaison to the RSAB To: StJohns, Michael Thanks for clarifying! (Not sure if you meant to send this to the list.) On 12/15/21 7:02 PM, StJohns, Michael wrote: > > > On Wed, Dec 15, 2021 at 20:32 Peter Saint-Andre > wrote: > > On 12/15/21 6:25 PM, StJohns, Michael wrote: > > > > > > On Wed, Dec 15, 2021 at 19:08 Peter Saint-Andre > > > >> wrote: > > > > On 12/15/21 5:00 PM, StJohns, Michael wrote: > > > > > > > > > On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre > > > > > > > > >>> wrote: > > > > > > On 12/10/21 12:05 PM, Michael StJohns wrote: > > > > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: > > > >> Hi Eliot > > > >> > > > >> Sorry I should have been clearer about what kind of > > change I had > > > in mind. > > > >> > > > >> Current the text says: shall have the ED as > liaison, and > > my have > > > >> others e.g. RPC > > > >> > > > >> I think it should rather say: shall have ED and > RPC and > > may have > > > others > > > >> > > > >> As you say below I also think the RSAB and RPC can > meet how > > > often they > > > >> want and there is noting in the doc that would > stop them. But > > > having > > > >> the shall there for the ED and only naming the RPC > as an > > example of > > > >> others seem to give the impressing that having a > liaison > > to the > > > RPC is > > > >> less important. I don=E2=80=99t think that maps the= relation > > between the > > > RSAB > > > >> and RPC as described in the rest of the document. > > > >> > > > >> Mirja > > > > > > > > > > > > Hi Mirja - > > > > > > > > I agree with you that the RPC should be > represented. It > > probably > > > can't > > > > be done directively here because of contracts. So > "The ED > > shall be a > > > > liaison member of the RSAB. The entity performing the > > tasks of > > > the RPC > > > > may also appoint a liaison member to the RSAB. > Liaisions may > > > participate > > > > in all activities of the RSAB as non-voting members.= " > > E.g. the > > > choice > > > > is the RPC's not the RSAB's in this case. > > > > > > Although as the document editor I'll add whatever text we > > agree on, > > > this > > > seems backward: RSAB should be the entity that > initiates liaison > > > arrangements, and we've had text to that effect for a long > > time now. > > > > > > Peter > > > > > > > > > Hi Peter - your argument seems to reduce to =E2=80=9Cbecaus= e we > call this a > > > liaison then we should let the RSAB decide. =E2=80=9C > > > > > > Instead maybe fill in: There exist specific situations > where not > > having > > > the RPC participate on the RSAB makes sense for the > success of the > > > system, so we should let the RSAB decide when and when not > to let > > the > > > RPC participate. Those situations are: ??? > > > > > > I=E2=80=99ve been unable to think of any such situations. = Maybe > you=E2=80=99ve got > > > another perception? > > > > It just seems strange to me that any arbitrary entity can > proactively > > appoint a liaison to the RSAB and expect to have a seat at > the table. > > Can, say, ISOC or ICANN or ISO or W3C or NIST or 3GPP or > IFPSM [1] do > > that, too? (After all, one could argue that they and many > others all > > have a "stake" in the RFC Series.) > > > > Peter > > > > [1] https://www.ifpsm.org/ifpsm > > > > > > > > How the heck did you get from my =E2=80=9Chave the RPC participate= as a > matter > > of course=E2=80=9D to your =E2=80=9Cany TD&H may become a liaison= without the RSAB > > signing off=E2=80=9D? > > Perhaps I misunderstood this statement of yours: > > "The entity performing the tasks of the RPC may also appoint a liaiso= n > member to the RSAB." > > What exactly does it mean to appoint a liaison member to the RSAB (or > any other group)? Such a liaison relationship needs to be mutual, which > means it needs to be accepted by the group to which the liaison is > named, in this case the RSAB. The RPC can't just appoint a liaison on > its own. > > > I=E2=80=99ve explained this like 4 times but let=E2=80=99s try it again. > > Liaison appears to be the trigger word, but what I mean - whatever word > you want to use - basically the same type of position that the ED would > have in the RSAB - a non-voting but speaking position (e.g not an > observer role, but a participant). As I explained before, the RPC gets > to choose who represents them, this is not a person selected by the ED. > > And organizations appoint liaisons all the time. In fact I=E2=80=99ll be= t you > could find dozens of messages where the IAB appoints someone as liaison > to another organization. The fact that there will be a =E2=80=9Cliaison= =E2=80=9D is > either subject to negotiation after the organization is created, or is > specified in the documents that create the organization - e.g. like the > host of liaisons that are part of the population of the Nomcom for example. > > The final point is that the sending organization selects their > representative, not the gaining organization. > > So all we=E2=80=99re arguing about here is whether or not the RPC always = gets a > seat at the table, or whether that=E2=80=99s subject to the whims of the = then > current RSAB. There=E2=80=99s precedence ( e.g. Nomcom) in specifying a > requirement here rather than deferring to an ever changing group of > people with their own set of biases. > > Later, Mike > > > > > Peter > --00000000000080780c05d33a0fbf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes I did.=C2=A0 Oops.=C2=A0

---------- Forwarded mes= sage ---------
From: Pet= er Saint-Andre <stpeter@stpeter.im>
Date: Wed, Dec 15, 2021 at 2= 1:10
Subject: Re: [Rfced-future] RPC liaison to the RSAB
To: StJohns,= Michael <msj@nthpermutation.c= om>


Thanks for clarifying! (Not sure if you meant t= o send this to the list.)

On 12/15/21 7:02 PM, StJohns, Michael wrote:
>
>
> On Wed, Dec 15, 2021 at 20:32 Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stp= eter@stpeter.im>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 12/15/21 6:25 PM, StJohns, Michael wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Wed, Dec 15, 2021 at 19:08 Peter Saint-And= re
>=C2=A0 =C2=A0 =C2=A0<stpeter@stpeter.im <mailto:stpeter@stpeter.im>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:stpeter@stpeter.im <mailto:stpeter@stpeter.im>>> wro= te:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 12/15/21 5:00 PM, StJoh= ns, Michael wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Wed, Dec 15, 2021= at 18:48 Peter Saint-Andre
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<stpeter@stpeter.im <mailto:stpeter@stpeter.im>=
>=C2=A0 =C2=A0 =C2=A0<mailto:stpeter@stpeter.im <mailto:stpeter@stpeter.im>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:stpeter@stpeter.im <= ;mailto:stpeter@stp= eter.im>
>=C2=A0 =C2=A0 =C2=A0<mailto:stpeter@stpeter.im <mailto:stpeter@stpeter.im>>>> wrote= :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0O= n 12/10/21 12:05 PM, Michael StJohns wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> Hi Eliot
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> Sorry I should have been clearer about what kind of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0change I had
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0i= n mind.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> Current the text says: shall have the ED as
>=C2=A0 =C2=A0 =C2=A0liaison, and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0my have
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> others e.g. RPC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> I think it should rather say: shall have ED and
>=C2=A0 =C2=A0 =C2=A0RPC and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0may have
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0o= thers
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> As you say below I also think the RSAB and RPC can
>=C2=A0 =C2=A0 =C2=A0meet how
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0o= ften they
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> want and there is noting in the doc that would
>=C2=A0 =C2=A0 =C2=A0stop them. But
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0h= aving
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> the shall there for the ED and only naming the RPC
>=C2=A0 =C2=A0 =C2=A0as an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0example of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> others seem to give the impressing that having a
>=C2=A0 =C2=A0 =C2=A0liaison
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= PC is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> less important. I don=E2=80=99t think that maps the relation
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0between the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= SAB
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> and RPC as described in the rest of the document.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> Mirja
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > Hi Mirja -
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > I agree with you that the RPC should be
>=C2=A0 =C2=A0 =C2=A0represented.=C2=A0 It
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0probably
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= an't
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > be done directively here because of contracts. So
>=C2=A0 =C2=A0 =C2=A0"The ED
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0shall be a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > liaison member of the RSAB.=C2=A0 The entity performing the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0tasks of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= he RPC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > may also appoint a liaison member to the RSAB.
>=C2=A0 =C2=A0 =C2=A0Liaisions may
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0p= articipate
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > in all activities of the RSAB as non-voting members."
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0E.g. the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= hoice
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > is the RPC's not the RSAB's in this case.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A= lthough as the document editor I'll add whatever text we
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0agree on,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= his
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0s= eems backward: RSAB should be the entity that
>=C2=A0 =C2=A0 =C2=A0initiates liaison
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0a= rrangements, and we've had text to that effect for a long
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0time now.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P= eter
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Hi Peter - your argu= ment seems to reduce to =E2=80=9Cbecause we
>=C2=A0 =C2=A0 =C2=A0call this a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > liaison then we shou= ld let the RSAB decide. =E2=80=9C
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Instead maybe fill i= n: There exist specific situations
>=C2=A0 =C2=A0 =C2=A0where not
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0having
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > the RPC participate = on the RSAB makes sense for the
>=C2=A0 =C2=A0 =C2=A0success of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > system, so we should= let the RSAB decide when and when not
>=C2=A0 =C2=A0 =C2=A0to let
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > RPC participate.=C2= =A0 Those situations are: ???
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > I=E2=80=99ve been un= able to think of any such situations.=C2=A0 Maybe
>=C2=A0 =C2=A0 =C2=A0you=E2=80=99ve got
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > another perception?<= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0It just seems strange to m= e that any arbitrary entity can
>=C2=A0 =C2=A0 =C2=A0proactively
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0appoint a liaison to the R= SAB and expect to have a seat at
>=C2=A0 =C2=A0 =C2=A0the table.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Can, say, ISOC or ICANN or= ISO or W3C or NIST or 3GPP or
>=C2=A0 =C2=A0 =C2=A0IFPSM [1] do
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that, too? (After all, one= could argue that they and many
>=C2=A0 =C2=A0 =C2=A0others all
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0have a "stake" i= n the RFC Series.)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Peter
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[1] https://www.ifpsm.or= g/ifpsm <https://www.ifpsm.org/ifpsm>
>=C2=A0 =C2=A0 =C2=A0<https://www.ifpsm.org/ifpsm <https= ://www.ifpsm.org/ifpsm>>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > How the heck did you get from my =E2=80=9Chav= e the RPC participate as a
>=C2=A0 =C2=A0 =C2=A0matter
>=C2=A0 =C2=A0 =C2=A0 > of course=E2=80=9D to =C2=A0your =E2=80=9Cany= TD&H may become a liaison without the RSAB
>=C2=A0 =C2=A0 =C2=A0 > signing off=E2=80=9D?
>
>=C2=A0 =C2=A0 =C2=A0Perhaps I misunderstood this statement of yours: >
>=C2=A0 =C2=A0 =C2=A0"The entity performing the tasks of the RPC ma= y also appoint a liaison
>=C2=A0 =C2=A0 =C2=A0member to the RSAB."
>
>=C2=A0 =C2=A0 =C2=A0What exactly does it mean to appoint a liaison memb= er to the RSAB (or
>=C2=A0 =C2=A0 =C2=A0any other group)? Such a liaison relationship needs= to be mutual, which
>=C2=A0 =C2=A0 =C2=A0means it needs to be accepted by the group to which= the liaison is
>=C2=A0 =C2=A0 =C2=A0named, in this case the RSAB. The RPC can't jus= t appoint a liaison on
>=C2=A0 =C2=A0 =C2=A0its own.
>
>
> I=E2=80=99ve explained this like 4 times but let=E2=80=99s try it agai= n.
>
> Liaison appears to be the trigger word, but what I mean - whatever wor= d
> you want to use - basically the same type of position that the ED woul= d
> have in the RSAB - a non-voting but speaking position (e.g not an
> observer role, but a participant). As I explained before, the RPC gets=
> to choose who represents them, this is not a person selected by the ED= .
>
> And organizations appoint liaisons all the time.=C2=A0 In fact I=E2=80= =99ll bet you
> could find dozens of messages where the IAB appoints someone as liaiso= n
> to another organization.=C2=A0 The fact that there will be a =E2=80=9C= liaison=E2=80=9D is
> either subject to negotiation after the organization is created, or is=
> specified in the documents that create the organization - e.g. like th= e
> host of liaisons that are part of the population of the Nomcom for exa= mple.
>
> The final point is that the sending organization selects their
> representative, not the gaining organization.
>
> So all we=E2=80=99re arguing about here is whether or not the RPC alwa= ys gets a
> seat at the table, or whether that=E2=80=99s subject to the whims of t= he then
> current RSAB.=C2=A0 There=E2=80=99s precedence ( e.g. Nomcom) in speci= fying a
> requirement here rather than deferring to an ever changing group of > people with their own set of biases.
>
> Later, Mike
>
>
>
>
>=C2=A0 =C2=A0 =C2=A0Peter
>

--00000000000080780c05d33a0fbf-- From nobody Wed Dec 15 18:36:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F340A3A0B7B for ; Wed, 15 Dec 2021 18:36:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 Z_Kr9y_0ZsTD for ; Wed, 15 Dec 2021 18:36:07 -0800 (PST) Received: from mail-io1-xd2e.google.com (mail-io1-xd2e.google.com [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48E9D3A0B8F for ; Wed, 15 Dec 2021 18:36:07 -0800 (PST) Received: by mail-io1-xd2e.google.com with SMTP id p23so33182109iod.7 for ; Wed, 15 Dec 2021 18:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BA3EoKtzXNH0y3kM6TRtqkpKxzMbCpA7ZKYzBCotUDY=; b=GbW7E1if81y9xaDrRwN30rkW8IScoNIYIxGRJlDa5kB4g35Jz3hB7HKd0g4LBpbP6O PIc/hCLGMg0SuUuEGMqgeNDfL4pjTBcK4cConIkz4GU7yiDu0XE0hm97rNF6MZyUd4ys kQzLXCNp21aYf8QcFoUB6/eFMrhB344yIr06ivgbB8HJIQK4EzlqNzneyv+30wcx7SwX UvU+PR7ElP89yPJVZupLgmCPSXudUVNxh39WDseFyLYkscY74xG9KRalec/7nsyt/Eno 3qvEeSqj7pq3z9z0YnEWfJBLkxlxtXcWjhRQfzy9PCcz6+soBFBgaoX7PUV8wAGz9mGj HLMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=BA3EoKtzXNH0y3kM6TRtqkpKxzMbCpA7ZKYzBCotUDY=; b=3oJU8rkB7z4Kle2bKX5solcQtWn04nf9mxqXXVwm91C13oS7PGjd5zQD0OnTKZ438l m1QFqzaZx3whUxjLw8So0PURPSfxIIz938B+D0mvKfaTEUkyZMqbmVo7teWk5kP0x/uz FvujfWwsbySWU26rLdMkr3x5VgItxaLFbpQ6HMuJjdoOgbDjW6i4kPB4b/DXsVNJriSo 4gd4OMK+F5wVyid0NnKUfpnwyWWPgGYw2NbCznealMsl2hsaDsGLYK7s11tGi+SVzMsz b0f45j1LW496/dp+UntltGmRE4HqsIbBDuV72MKxNlWQgRA2bH+o2WghJqEFap4bM05h eKtw== X-Gm-Message-State: AOAM532LC/0XQAZjUDwgDY254m/WuT4c4ObFkxpuKpn1fDRR64c2KqSh 5ErkVOGocRNBxISeHJPUxE8qOt+iVxntEkhRa4DxsfwUpHM= X-Google-Smtp-Source: ABdhPJxyHmmxanZeaqUAuEHO5G/z//HtdQCkvFqn7eMGFpXj9cy3OWpSIu/+V+8UcTAOVl6cCdFovBl4IIzS/T0Ko40= X-Received: by 2002:a05:6638:d56:: with SMTP id d22mr8013481jak.20.1639622165815; Wed, 15 Dec 2021 18:36:05 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> In-Reply-To: From: Eric Rescorla Date: Wed, 15 Dec 2021 18:35:28 -0800 Message-ID: To: "StJohns, Michael" Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000c2743605d33a48ce" Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 02:36:12 -0000 --000000000000c2743605d33a48ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Dec 15, 2021 at 6:20 PM StJohns, Michael wrote: > Yes I did. Oops. > > ---------- Forwarded message --------- > From: Peter Saint-Andre > Date: Wed, Dec 15, 2021 at 21:10 > Subject: Re: [Rfced-future] RPC liaison to the RSAB > To: StJohns, Michael > > > Thanks for clarifying! (Not sure if you meant to send this to the list.) > > On 12/15/21 7:02 PM, StJohns, Michael wrote: > > > > > > On Wed, Dec 15, 2021 at 20:32 Peter Saint-Andre > > wrote: > > > > On 12/15/21 6:25 PM, StJohns, Michael wrote: > > > > > > > > > On Wed, Dec 15, 2021 at 19:08 Peter Saint-Andre > > > > > >> wrote: > > > > > > On 12/15/21 5:00 PM, StJohns, Michael wrote: > > > > > > > > > > > > On Wed, Dec 15, 2021 at 18:48 Peter Saint-Andre > > > > > > > > > > > > >>> wrote: > > > > > > > > On 12/10/21 12:05 PM, Michael StJohns wrote: > > > > > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote: > > > > >> Hi Eliot > > > > >> > > > > >> Sorry I should have been clearer about what kind = of > > > change I had > > > > in mind. > > > > >> > > > > >> Current the text says: shall have the ED as > > liaison, and > > > my have > > > > >> others e.g. RPC > > > > >> > > > > >> I think it should rather say: shall have ED and > > RPC and > > > may have > > > > others > > > > >> > > > > >> As you say below I also think the RSAB and RPC ca= n > > meet how > > > > often they > > > > >> want and there is noting in the doc that would > > stop them. But > > > > having > > > > >> the shall there for the ED and only naming the RP= C > > as an > > > example of > > > > >> others seem to give the impressing that having a > > liaison > > > to the > > > > RPC is > > > > >> less important. I don=E2=80=99t think that maps t= he > relation > > > between the > > > > RSAB > > > > >> and RPC as described in the rest of the document. > > > > >> > > > > >> Mirja > > > > > > > > > > > > > > > Hi Mirja - > > > > > > > > > > I agree with you that the RPC should be > > represented. It > > > probably > > > > can't > > > > > be done directively here because of contracts. So > > "The ED > > > shall be a > > > > > liaison member of the RSAB. The entity performing > the > > > tasks of > > > > the RPC > > > > > may also appoint a liaison member to the RSAB. > > Liaisions may > > > > participate > > > > > in all activities of the RSAB as non-voting > members." > > > E.g. the > > > > choice > > > > > is the RPC's not the RSAB's in this case. > > > > > > > > Although as the document editor I'll add whatever tex= t > we > > > agree on, > > > > this > > > > seems backward: RSAB should be the entity that > > initiates liaison > > > > arrangements, and we've had text to that effect for a > long > > > time now. > > > > > > > > Peter > > > > > > > > > > > > Hi Peter - your argument seems to reduce to =E2=80=9Cbeca= use we > > call this a > > > > liaison then we should let the RSAB decide. =E2=80=9C > > > > > > > > Instead maybe fill in: There exist specific situations > > where not > > > having > > > > the RPC participate on the RSAB makes sense for the > > success of the > > > > system, so we should let the RSAB decide when and when no= t > > to let > > > the > > > > RPC participate. Those situations are: ??? > > > > > > > > I=E2=80=99ve been unable to think of any such situations.= Maybe > > you=E2=80=99ve got > > > > another perception? > > > > > > It just seems strange to me that any arbitrary entity can > > proactively > > > appoint a liaison to the RSAB and expect to have a seat at > > the table. > > > Can, say, ISOC or ICANN or ISO or W3C or NIST or 3GPP or > > IFPSM [1] do > > > that, too? (After all, one could argue that they and many > > others all > > > have a "stake" in the RFC Series.) > > > > > > Peter > > > > > > [1] https://www.ifpsm.org/ifpsm > > > > > > > > > > > > How the heck did you get from my =E2=80=9Chave the RPC participa= te as a > > matter > > > of course=E2=80=9D to your =E2=80=9Cany TD&H may become a liais= on without the > RSAB > > > signing off=E2=80=9D? > > > > Perhaps I misunderstood this statement of yours: > > > > "The entity performing the tasks of the RPC may also appoint a > liaison > > member to the RSAB." > > > > What exactly does it mean to appoint a liaison member to the RSAB (= or > > any other group)? Such a liaison relationship needs to be mutual, > which > > means it needs to be accepted by the group to which the liaison is > > named, in this case the RSAB. The RPC can't just appoint a liaison = on > > its own. > > > > > > I=E2=80=99ve explained this like 4 times but let=E2=80=99s try it again= . > > > > Liaison appears to be the trigger word, but what I mean - whatever word > > you want to use - basically the same type of position that the ED would > > have in the RSAB - a non-voting but speaking position (e.g not an > > observer role, but a participant). As I explained before, the RPC gets > > to choose who represents them, this is not a person selected by the ED. > > > > And organizations appoint liaisons all the time. In fact I=E2=80=99ll = bet you > > could find dozens of messages where the IAB appoints someone as liaison > > to another organization. The fact that there will be a =E2=80=9Cliaiso= n=E2=80=9D is > > either subject to negotiation after the organization is created, or is > > specified in the documents that create the organization - e.g. like the > > host of liaisons that are part of the population of the Nomcom for > example. > > > > The final point is that the sending organization selects their > > representative, not the gaining organization. > > > > So all we=E2=80=99re arguing about here is whether or not the RPC alway= s gets a > > seat at the table, or whether that=E2=80=99s subject to the whims of th= e then > > current RSAB. There=E2=80=99s precedence ( e.g. Nomcom) in specifying = a > > requirement here rather than deferring to an ever changing group of > > people with their own set of biases. > > I'm not sure that this precedent cuts the way you seem to believe. As I understand it, nomcoms have varied quite a bit in the level of participation. -Ekr --000000000000c2743605d33a48ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Dec 15, 2021 at 6:20 PM StJoh= ns, Michael <msj@nthpermutatio= n.com> wrote:
Yes I did.=C2=A0 Oops.=C2=A0

---------- Forwarded message ---------From: Peter Saint-Andre <stpeter@stpeter.im>
Date: Wed, Dec 15, 2021 at 21:10
S= ubject: Re: [Rfced-future] RPC liaison to the RSAB
To: StJohns, Michael = <msj@nthperm= utation.com>


Thanks for clarifying! (Not sure if yo= u meant to send this to the list.)

On 12/15/21 7:02 PM, StJohns, Michael wrote:
>
>
> On Wed, Dec 15, 2021 at 20:32 Peter Saint-Andre <stpeter@stpeter.im
> <mailto:stp= eter@stpeter.im>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 12/15/21 6:25 PM, StJohns, Michael wrote:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > On Wed, Dec 15, 2021 at 19:08 Peter Saint-And= re
>=C2=A0 =C2=A0 =C2=A0<stpeter@stpeter.im <mailto:stpeter@stpeter.im>
>=C2=A0 =C2=A0 =C2=A0 > <mailto:stpeter@stpeter.im <mailto:stpeter@stpeter.im>>> wro= te:
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0On 12/15/21 5:00 PM, StJoh= ns, Michael wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > On Wed, Dec 15, 2021= at 18:48 Peter Saint-Andre
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0<stpeter@stpeter.im <mailto:stpeter@stpeter.im>=
>=C2=A0 =C2=A0 =C2=A0<mailto:stpeter@stpeter.im <mailto:stpeter@stpeter.im>>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > <mailto:stpeter@stpeter.im <= ;mailto:stpeter@stp= eter.im>
>=C2=A0 =C2=A0 =C2=A0<mailto:stpeter@stpeter.im <mailto:stpeter@stpeter.im>>>> wrote= :
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0O= n 12/10/21 12:05 PM, Michael StJohns wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > On 12/10/2021 1:27 PM, Mirja Kuehlewind wrote:
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> Hi Eliot
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> Sorry I should have been clearer about what kind of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0change I had
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0i= n mind.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> Current the text says: shall have the ED as
>=C2=A0 =C2=A0 =C2=A0liaison, and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0my have
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> others e.g. RPC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> I think it should rather say: shall have ED and
>=C2=A0 =C2=A0 =C2=A0RPC and
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0may have
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0o= thers
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> As you say below I also think the RSAB and RPC can
>=C2=A0 =C2=A0 =C2=A0meet how
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0o= ften they
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> want and there is noting in the doc that would
>=C2=A0 =C2=A0 =C2=A0stop them. But
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0h= aving
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> the shall there for the ED and only naming the RPC
>=C2=A0 =C2=A0 =C2=A0as an
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0example of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> others seem to give the impressing that having a
>=C2=A0 =C2=A0 =C2=A0liaison
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0to the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= PC is
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> less important. I don=E2=80=99t think that maps the relation
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0between the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0R= SAB
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> and RPC as described in the rest of the document.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >>
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >> Mirja
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > Hi Mirja -
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > I agree with you that the RPC should be
>=C2=A0 =C2=A0 =C2=A0represented.=C2=A0 It
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0probably
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= an't
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > be done directively here because of contracts. So
>=C2=A0 =C2=A0 =C2=A0"The ED
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0shall be a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > liaison member of the RSAB.=C2=A0 The entity performing the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0tasks of
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= he RPC
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > may also appoint a liaison member to the RSAB.
>=C2=A0 =C2=A0 =C2=A0Liaisions may
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0p= articipate
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > in all activities of the RSAB as non-voting members."
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0E.g. the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0c= hoice
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 = > is the RPC's not the RSAB's in this case.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0A= lthough as the document editor I'll add whatever text we
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0agree on,
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0t= his
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0s= eems backward: RSAB should be the entity that
>=C2=A0 =C2=A0 =C2=A0initiates liaison
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0a= rrangements, and we've had text to that effect for a long
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0time now.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0P= eter
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Hi Peter - your argu= ment seems to reduce to =E2=80=9Cbecause we
>=C2=A0 =C2=A0 =C2=A0call this a
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > liaison then we shou= ld let the RSAB decide. =E2=80=9C
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > Instead maybe fill i= n: There exist specific situations
>=C2=A0 =C2=A0 =C2=A0where not
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0having
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > the RPC participate = on the RSAB makes sense for the
>=C2=A0 =C2=A0 =C2=A0success of the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > system, so we should= let the RSAB decide when and when not
>=C2=A0 =C2=A0 =C2=A0to let
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0the
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > RPC participate.=C2= =A0 Those situations are: ???
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > I=E2=80=99ve been un= able to think of any such situations.=C2=A0 Maybe
>=C2=A0 =C2=A0 =C2=A0you=E2=80=99ve got
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0 > another perception?<= br> >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0It just seems strange to m= e that any arbitrary entity can
>=C2=A0 =C2=A0 =C2=A0proactively
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0appoint a liaison to the R= SAB and expect to have a seat at
>=C2=A0 =C2=A0 =C2=A0the table.
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Can, say, ISOC or ICANN or= ISO or W3C or NIST or 3GPP or
>=C2=A0 =C2=A0 =C2=A0IFPSM [1] do
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0that, too? (After all, one= could argue that they and many
>=C2=A0 =C2=A0 =C2=A0others all
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0have a "stake" i= n the RFC Series.)
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0Peter
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >=C2=A0 =C2=A0 =C2=A0[1] https://www.ifpsm.or= g/ifpsm <https://www.ifpsm.org/ifpsm>
>=C2=A0 =C2=A0 =C2=A0<https://www.ifpsm.org/ifpsm <https= ://www.ifpsm.org/ifpsm>>
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > How the heck did you get from my =E2=80=9Chav= e the RPC participate as a
>=C2=A0 =C2=A0 =C2=A0matter
>=C2=A0 =C2=A0 =C2=A0 > of course=E2=80=9D to =C2=A0your =E2=80=9Cany= TD&H may become a liaison without the RSAB
>=C2=A0 =C2=A0 =C2=A0 > signing off=E2=80=9D?
>
>=C2=A0 =C2=A0 =C2=A0Perhaps I misunderstood this statement of yours: >
>=C2=A0 =C2=A0 =C2=A0"The entity performing the tasks of the RPC ma= y also appoint a liaison
>=C2=A0 =C2=A0 =C2=A0member to the RSAB."
>
>=C2=A0 =C2=A0 =C2=A0What exactly does it mean to appoint a liaison memb= er to the RSAB (or
>=C2=A0 =C2=A0 =C2=A0any other group)? Such a liaison relationship needs= to be mutual, which
>=C2=A0 =C2=A0 =C2=A0means it needs to be accepted by the group to which= the liaison is
>=C2=A0 =C2=A0 =C2=A0named, in this case the RSAB. The RPC can't jus= t appoint a liaison on
>=C2=A0 =C2=A0 =C2=A0its own.
>
>
> I=E2=80=99ve explained this like 4 times but let=E2=80=99s try it agai= n.
>
> Liaison appears to be the trigger word, but what I mean - whatever wor= d
> you want to use - basically the same type of position that the ED woul= d
> have in the RSAB - a non-voting but speaking position (e.g not an
> observer role, but a participant). As I explained before, the RPC gets=
> to choose who represents them, this is not a person selected by the ED= .
>
> And organizations appoint liaisons all the time.=C2=A0 In fact I=E2=80= =99ll bet you
> could find dozens of messages where the IAB appoints someone as liaiso= n
> to another organization.=C2=A0 The fact that there will be a =E2=80=9C= liaison=E2=80=9D is
> either subject to negotiation after the organization is created, or is=
> specified in the documents that create the organization - e.g. like th= e
> host of liaisons that are part of the population of the Nomcom for exa= mple.
>
> The final point is that the sending organization selects their
> representative, not the gaining organization.
>
> So all we=E2=80=99re arguing about here is whether or not the RPC alwa= ys gets a
> seat at the table, or whether that=E2=80=99s subject to the whims of t= he then
> current RSAB.=C2=A0 There=E2=80=99s precedence ( e.g. Nomcom) in speci= fying a
> requirement here rather than deferring to an ever changing group of > people with their own set of biases.

<= div>
I'm not sure that this precedent cuts the way you se= em to believe. As I understand
it, nomcoms have varied quite a bi= t in the level of participation.

-Ekr
--000000000000c2743605d33a48ce-- From nobody Wed Dec 15 18:57:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E63F3A0772 for ; Wed, 15 Dec 2021 18:57:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 Kkp3oaywzWkr for ; Wed, 15 Dec 2021 18:57:27 -0800 (PST) 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 4C9383A0770 for ; Wed, 15 Dec 2021 18:57:27 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id mj19so4286142pjb.3 for ; Wed, 15 Dec 2021 18:57:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=myQTuOJ9Z/XROMvRaJbEGBl1mKFJIZsZrVUG9mjyvRU=; b=Ozd6t2yduwQbwQx7AJkJlcgyCkmlXEcXUbTLlC/bXC0lgZf6X03nwpwh3j3M/yv/9K /YFxKSt7ow9dVYy8MeSGsR93oEAg8jBkkcTKR5hBEUhjYpi2cPIShe89Wl2G3HCsQyOX jt1f09jDxH3zJUkqdmN0UVOcxqLRWtoe2dFK3e6x7vmdmu1SILhIAgRWx+gNYKhJXDNJ OC3ZepHqgLok3S5t6Id/pwf/cqOOtHoALnRyDqFSc3ECAAEGIct+qfsm+HkDYTgqKkcJ c8IEcDSBAFQuPapbV9cNdZU9oTDG6gPmoLPL8+VA6ZeI0RsN+3WspbHOabsXfpItzrgK Fm+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=myQTuOJ9Z/XROMvRaJbEGBl1mKFJIZsZrVUG9mjyvRU=; b=kq1NXi5jenhzUE4wNpSFuHCQ2bW5LXSyR5TdlqQ7ctKmY187qKN4UDTHMza8/01djb Nc4o5j9oKSuqfvOKhwc5eDhrAvLP0nAz3bHSPrxW/zczE4+uA17686qo2IQ2QTDnmeX/ niwABP8uACAhNF6XHXWx6NIOxaSalMzkBYWL0lvIorqVqYnFlYUFkYTEYo9/3GBXca9T d6d7McRw/U1ztxvkY1jIIC8mddzKZI91XUH65IXZllLIfbOeV9OZConBVhehbG3xZKo7 flDU81LtSmz/c7aBJARjf1IWsQSVva79rGxuz7UzuAJvu3ditZsrPiWiafW6ff/InEer NeyA== X-Gm-Message-State: AOAM530jAkaQYm71pMfh5SPCbavHDF2+FI+OsEFHhVeWJoOU2SruyWcR yKwlfmFdLnrYS86SarBoTnYaZUvpE3GX6Q== X-Google-Smtp-Source: ABdhPJx6l0FjPfm1NHpvMNaAjGSZvLIUOXe1cIAgMoMhWChFO2MFdchI9GAqXqCFrc6oIQJcQqoYLQ== X-Received: by 2002:a17:902:b489:b0:148:b385:b2af with SMTP id y9-20020a170902b48900b00148b385b2afmr3907867plr.166.1639623445514; Wed, 15 Dec 2021 18:57:25 -0800 (PST) Received: from ?IPv6:2406:e003:1071:1701:80b2:5c79:2266:e431? ([2406:e003:1071:1701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c17sm4095451pfc.163.2021.12.15.18.57.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 15 Dec 2021 18:57:25 -0800 (PST) To: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> From: Brian E Carpenter Message-ID: <938370c4-eefd-8105-cd98-89e81d6140a7@gmail.com> Date: Thu, 16 Dec 2021 15:57:20 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 02:57:32 -0000 The draft says: The RSAB may at its discretion include additional non-voting members, for instance a liaison from the RPC. Ain't broken, don't fix. Regards Brian C From nobody Wed Dec 15 19:20:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBAA3A08CD for ; Wed, 15 Dec 2021 19:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTViHHPrDwez for ; Wed, 15 Dec 2021 19:20:39 -0800 (PST) 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 804A23A08CE for ; Wed, 15 Dec 2021 19:20:31 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mxhJk-000CYL-8y; Wed, 15 Dec 2021 22:20:28 -0500 Date: Wed, 15 Dec 2021 22:20:22 -0500 From: John C Klensin To: Peter Saint-Andre , "StJohns, Michael" cc: rfced-future@iab.org Message-ID: <37B079C1B661437AA93F47C7@PSB> In-Reply-To: <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> 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] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 03:20:45 -0000 --On Wednesday, December 15, 2021 18:32 -0700 Peter Saint-Andre wrote: >... >> It just seems strange to me that any arbitrary entity can >> proactively appoint a liaison to the RSAB and expect to >> have a seat at the table. Can, say, ISOC or ICANN or ISO >> or W3C or NIST or 3GPP or IFPSM [1] do that, too? (After >> all, one could argue that they and many others all have a >> "stake" in the RFC Series.) >>=20 >> Peter >>=20 >> [1] https://www.ifpsm.org/ifpsm >> >>=20 >>=20 >> How the heck did you get from my "have the RPC participate >> as a matter of course" to =C2=A0your "any TD&H may become a >> liaison without the RSAB signing off"? >=20 > Perhaps I misunderstood this statement of yours: >=20 > "The entity performing the tasks of the RPC may also appoint a > liaison member to the RSAB." >=20 > What exactly does it mean to appoint a liaison member to the > RSAB (or any other group)? Such a liaison relationship needs > to be mutual, which means it needs to be accepted by the group > to which the liaison is named, in this case the RSAB. The RPC > can't just appoint a liaison on its own. Peter, I've been trying to sit this one out since my initial comments, but I guess I'm failing. Not speaking for Mike or anyone = else... The difficulty with roles we have traditionally called "liaison" is not only the kind of two-way situation you describe but that the body to which they are appointed or designated can, traditionally, decide that they should be excluded from discussions. Sometimes we restrict that exclusion by requiring that a reason be given and that the fall into some specific category, sometimes we don't. Independent of what it is called, I think the RPC needs to have a seat at the RSAB table and have it as part of the model. That seat should not be discretionary. I suspect that a mechanism will be needed to allow some or all of the RSAB members to decide the RPC should be locked out of a discussion, but the mechanism should be constrained and the information that is being done and the reasons should be public. In particular, I am not talking about (and don't believe Mike, Mirja, or others are talking about) a role that "needs to be accepted by the group to which the liaison is named, in this case the RSAB" for the RPC any more than I think that definition would be appropriate for the LLC ED. Probably "liaison" is, as you, Mike, and others have sort of suggested, the wrong term for what is intended by this. If I correctly understand what at least some of us have intended, "ex-officio" would be closer to the usual usage for both the LLC ED and RPC representations. Apparently that term has not been used in the document so might be used (with "non-voting" if appropriate) for these two positions, thereby distinguishing them from "liaisons" who the RSAB would need to invite and/or accept. And that brings me to... --On Thursday, December 16, 2021 08:20 +1300 Jay Daley wrote: >... > When it comes to the RPC being a liaison to RSAB, then the > situation is much more complex than it is for the ED. In > particular the RSAB needs to reconcile the following: >=20 > - how to manage the RPC input/engagement when discussing the > priorities and performance of the RPC > - how to manage responding to RPC requests for advice > - how to manage any conflicting advice from the RSCE=20 > and the RPC >=20 > None of these are insurmountable, but I would hope that any > proposal for the RPC being a mandatory liaison addresses those > issues as not doing that puts the RSAB on a difficult footing > from the start. Agreed. But I don't think that any of the above are hard. I still believe that the model we are specifying will work to produce the RFC Series we want only if things can proceed collegially, with people having open discussions, sharing perspectives and opinions openly. If the RSAB needs to go into some type of executive session to make certain decisions with some or all the ex-officio members (and/or liaisons) excluded, then so be it, but I would hope that: -- The RPC would participate in discussions about their priorities and performance. If needed, that would be far more likely to result in incremental adjustments or corrections rather than discussions about the detailed provisions of contracts or something needing to assert authority. -- The RPC should be present for discussions about their requests for advice. Perhaps they would have nothing to say, but that is not an issue. If the requests or associated issues are not correctly interpreted, then having them present to clarify would save time and improve results. Maybe I'm missing something, but I can see no scenario in which excluding them from such discussions would make the quality of RSAB decisions, the Series, or the Internet better. -- If the RPC and RSCE have conflicting advice, I believe that having them discuss their different advice and perspectives with each other and with the RSAB would be in the best interests of all concerned. Certainly, I'd hope nothing would bar them from having private discussions to clarify (even if not resolve) conflicting positions. That would almost certainly be in everyone's interest, but I see no reason for the document to need to say that unless there are provisions that someone could interpret as getting in the way (I haven't found any). Where I (very slightly) might disagree with Jay is that I don't see that situation as being much more complex than the one with the ED. For example, if the ED has advice about funding limits or the LLC Board were to ask the RSAB (either as a separate entity or as part of a more general query to the community) for an evaluation of the performance of the ED, the same issues would arise. I'd hope the RSAB would be able to turn such advice or requests into discussions of tradeoffs or of strengths and weaknesses. If a final decision required an executive session with the ED excluded, so be it. So no so different from the above. best, john From nobody Wed Dec 15 19:40:27 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF24F3A0C49 for ; Wed, 15 Dec 2021 19:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 1MbMShavrHWf for ; Wed, 15 Dec 2021 19:40:21 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9F943A0C43 for ; Wed, 15 Dec 2021 19:40:20 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mxhcw-000CZZ-19; Wed, 15 Dec 2021 22:40:18 -0500 Date: Wed, 15 Dec 2021 22:40:11 -0500 From: John C Klensin To: Brian E Carpenter , rfced-future@iab.org Message-ID: <2EE72EEFBC9AA5A4CE181D54@PSB> In-Reply-To: <938370c4-eefd-8105-cd98-89e81d6140a7@gmail.com> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <938370c4-eefd-8105-cd98-89e81d6140a7@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] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 03:40:25 -0000 --On Thursday, December 16, 2021 15:57 +1300 Brian E Carpenter wrote: > The draft says: > > The RSAB may at its discretion include additional non-voting > members, for instance a liaison from the RPC. > > Ain't broken, don't fix. Is broken. Allows the RSAB to exclude a critical perspective and voice with expertise that might otherwise not be available. For the RPC case, I don't think that is wise or appropriate. See note sent a few minutes ago. john From nobody Wed Dec 15 19:51:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F22EB3A0060 for ; Wed, 15 Dec 2021 19:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yPJ2-gprHiZG for ; Wed, 15 Dec 2021 19:51:07 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 063283A003F for ; Wed, 15 Dec 2021 19:51:06 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BG3p2Yn3863333 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 16 Dec 2021 04:51:02 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639626662; bh=4ki/hkaZwf55Oe712fTOIds/yEfoAVCNicgZCMvrt4E=; h=Date:To:References:From:Subject:In-Reply-To:From; b=ShXz3ZPEGxMuKa3QAC5T6B9M7P95idI2ku/KMIGtxAW0U+lgfEAsYzw12P1kpxGJP m1EOwNai5RB9de1rbF6pR278tr1q6Irk1LcLMNHkatOJw5JSOSkavVvI+phfCe5RXj M59fxXbSuDRDuwe6mkEr7q0HJZ4EVJkOaNTf6TaA= Message-ID: <9d0eeb6f-6cbd-3d0b-94af-ef603d1b2dd5@lear.ch> Date: Thu, 16 Dec 2021 04:51:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Michael StJohns , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <8a4f2402-33d8-200b-e362-91eba6b1189a@lear.ch> <639a8abd-1adb-dc1a-9a53-9af5c2574092@nthpermutation.com> From: Eliot Lear In-Reply-To: <639a8abd-1adb-dc1a-9a53-9af5c2574092@nthpermutation.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------HbgUoETedaq3YlJAhPPEvhgE" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 03:51:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------HbgUoETedaq3YlJAhPPEvhgE Content-Type: multipart/mixed; boundary="------------9n7tSsG5Draldxq1Y2wiZNfw"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , rfced-future@iab.org Message-ID: <9d0eeb6f-6cbd-3d0b-94af-ef603d1b2dd5@lear.ch> Subject: Re: [Rfced-future] RPC liaison to the RSAB References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <8a4f2402-33d8-200b-e362-91eba6b1189a@lear.ch> <639a8abd-1adb-dc1a-9a53-9af5c2574092@nthpermutation.com> In-Reply-To: <639a8abd-1adb-dc1a-9a53-9af5c2574092@nthpermutation.com> --------------9n7tSsG5Draldxq1Y2wiZNfw Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TWlrZToNCg0KT24gMTUuMTIuMjEgMjI6NDgsIE1pY2hhZWwgU3RKb2hucyB3cm90ZToNCj4N Cj4gSSBjYW4gc2VlIG5vIHJlYWwgcmVhc29uIGZvciB0aGUgUlNBQiB0byBtZWV0IGluIGV4 ZWN1dGl2ZSBzZXNzaW9uIA0KPiB3aXRoIHRoZSBzb2xlIGV4Y2VwdGlvbiBvZiBkaXNjdXNz aW5nIHdpdGggdGhlIEVEIHZhcmlvdXMgY2FuZGlkYXRlcyANCj4gZm9yIHRoZSBSU0NFIGpv YiBhbmQgZXZlbiB0aGVuIEknbSBub3Qgc3VyZSB0aGF0J3MgYSBnb29kIGlkZWEuwqAgDQo+ IEluc3RlYWQsIHRoZSBMTEMgY291bGQgYWRvcHQgdGhlIGN1cnJlbnQgbWVtYmVycyBvZiB0 aGUgUlNBQiBvbnRvIHRoZSANCj4gc2VsZWN0aW9uIGJvYXJkIGFuZCBzZXQgdGhlaXIgb3du IHByb2Nlc3NlcyB0aGF0IHdheS4NCj4NCldlIGFyZSBub3cgcmVsaXRpZ2F0aW5nIHRleHQg dGhhdCB3YXMgY2FyZWZ1bGx5IGFncmVlZC7CoCBJIG1lbnRpb25lZCB0aGUgDQp0ZXh0IGFz IGFuIGV4YW1wbGUsIGFuZCBub3QgdG8gb3BlbiBpdCB1cCBmb3IgcmV2aXNpb24uwqAgSXRz IGFncmVlZCANCnB1cnBvc2UgdG8gbW9kZXJhdGUgY29tbWVudHMgdG8gcHJvdGVjdCB0aGUg UlNDRSwgYmFzZWQgb24gYW4gaXNzdWUgeW91IA0Kb3BlbmVkLsKgIEl0IGlzIG5vdCBhdCBh bGwgcmVsYXRlZCB0byB0aGUgc2VsZWN0aW9uIG1ldGhvZCBvZiB0aGUgUlNBQiwgDQphbmQg aXQgaXMgbm90IGZlYXNpYmxlIGZvciBpbmRpdmlkdWFscyB0byBkbyB0aGUgdmV0dGluZy4N Cg0KUmF0aGVyIHRoYW4gcmVsaXRpZ2F0ZSB0aGF0IGlzc3VlLCB3aGljaCBJIHVyZ2UgdXMg bm90IHVzIG5vdCB0byBkbywgaWYgDQp0aGVyZSBpcyB0byBiZSBhIGxpYWlzb24gZnJvbSB0 aGUgUlBDLCBpdCBzaG91bGQgc2ltcGx5IG5vdCBwYXJ0aWNpcGF0ZSANCmluIG1hdHRlcnMg aW52b2x2aW5nIHRoZSBldmFsdWF0aW9uIG9mIGl0cyBwZXJmb3JtYW5jZS7CoCBLZWVwIHRo aXMgaW4gDQptaW5kOiBuZWFybHkgYWxsIGRlY2lzaW9ucyBvZiB0aGUgUlNBQiBhcmUgcmF0 aWZpY2F0aW9ucyBvciByZWplY3Rpb25zIA0Kb2YgdGhlIHdvcmsgb2YgdGhlIFJTV0cuwqAg QXMgSSB3cm90ZSBlYXJsaWVyLCB0aGUgUlBDIHNob3VsZCBiZSANCmluZm9ybWluZyB0aGF0 IGVmZm9ydC4NCg0KRWxpb3QNCg0K --------------9n7tSsG5Draldxq1Y2wiZNfw-- --------------HbgUoETedaq3YlJAhPPEvhgE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG6t6UFAwAAAAAACgkQh7ZrRtnSejNN VAf/UtmLa7VE0bOCAl1oczjkXYOmkM8gKjry49fVz3nPiLgTlI9BhatL4r6R9noA2994jbHx0QMj CM92k8gTvJ8nDuN1kmC5G2F5+rFpXq6nJ1Cegp/ObUCaQHvBdnKkSM59KrAk5xSnLU1rgZdXkELT EFB6OaLmDndQQOmmkp2ZZchAQ1jbGbrqbrXlggwQ4WdPnanqS5eP+4XSzhdIeWg2kATnkZIgQqvz I4xFxQ2hudMp7VJtUdCu2cxIqFjvH+MzeTt8gITbM5Yox/JpmZx3YfoJ1fJn7fPeH+tgh5P7dcQP JlLtAi7Uq/K3teYlsE78zDocjtBagMB8zRrMY+nuZQ== =1akK -----END PGP SIGNATURE----- --------------HbgUoETedaq3YlJAhPPEvhgE-- From nobody Wed Dec 15 19:52:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EC673A0063 for ; Wed, 15 Dec 2021 19:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=stpeter.im header.b=WE0jA9jt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=lp7HegCV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1V845eNgAJTp for ; Wed, 15 Dec 2021 19:52:01 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB9F3A00E0 for ; Wed, 15 Dec 2021 19:52:01 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 10FD832005C1; Wed, 15 Dec 2021 22:51:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 15 Dec 2021 22:52:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=5 VNaZTmnMXYJ8ElX7RGdQ4UdpvKbMRfbyLpo2x1I85U=; b=WE0jA9jtv6akucjU/ ZNq1okVbJbdjYrlhpD32G+ODTkFxZ/NAQWVcQi9p4xcIICukH1byPSf4jFohKpiG JDiepyJN2xLe90BaG0FDdAuxvzuHW/DMB+wDC9yVpqsRBE6LVo1VjIAYspAKThG7 JQAoB9mo6sp+ofvvOC+loIQ9EZVRsNHSjINVeIOjbFGLl/OHTe1tMLE1c0CzEC/T HapL7/WwSyu4Hpl/Y6mlsswy15b3XozvsNqC3mnq8pnkJ93gHvGkgcB0tEA/PCsY VcHRyY0m3iJJ6yk+KHs20DhT1SbLlRPzLig+6dD69wR2KrHWk/3OeYXPoycXNHIL wnBqg== 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=fm1; bh=5VNaZTmnMXYJ8ElX7RGdQ4UdpvKbMRfbyLpo2x1I8 5U=; b=lp7HegCVYtr2gWG9O0CV1CkOhHe8tsONM6HvVKqLp5mkccq8GA0vWmla0 CsfhHCl93zbq5fbTd1y5qvtMeX3W4L8zu9/3iRx1YnckhR2tGyJo5hUFlO3VgOvz HpfrKd/ur7iLQFmj0jUkWhv0suIOAjhjjFONTZonJlve38JUlgHNA12zj0fCgY7/ wy9xTSTiFhldv68fDAlOrFPDIKsFFApIzsAE/DaOsw6F218DyHGJ0GfTouQiJhoX Gk+50jweK//lLn67uh3nX1+Ihyu0sbAdKaR6d8KF76Bnnt3yDXsdvccJVaLaIfNQ bCWwPxKC0tKvomATAQt0ETHRWBa5Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleefgdeiudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfuffvfhfhjggtgfesthekre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnheptdetffehteegteduie eikeekiedutdeugeejleevheegvdfhjedujeetieeikedvnecuffhomhgrihhnpehifhhp shhmrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 15 Dec 2021 22:51:58 -0500 (EST) Message-ID: Date: Wed, 15 Dec 2021 20:51:54 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: John C Klensin , "StJohns, Michael" Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> From: Peter Saint-Andre In-Reply-To: <37B079C1B661437AA93F47C7@PSB> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 03:52:07 -0000 Thanks, John. I think you're on the right track but I need to think about it properly before replying (which I didn't do in my recent responses to Mike - sorry about that). Peter On 12/15/21 8:20 PM, John C Klensin wrote: > > > --On Wednesday, December 15, 2021 18:32 -0700 Peter Saint-Andre > wrote: > >> ... >>> It just seems strange to me that any arbitrary entity can >>> proactively appoint a liaison to the RSAB and expect to >>> have a seat at the table. Can, say, ISOC or ICANN or ISO >>> or W3C or NIST or 3GPP or IFPSM [1] do that, too? (After >>> all, one could argue that they and many others all have a >>> "stake" in the RFC Series.) >>> >>> Peter >>> >>> [1] https://www.ifpsm.org/ifpsm >>> >>> >>> >>> How the heck did you get from my "have the RPC participate >>> as a matter of course" to  your "any TD&H may become a >>> liaison without the RSAB signing off"? >> >> Perhaps I misunderstood this statement of yours: >> >> "The entity performing the tasks of the RPC may also appoint a >> liaison member to the RSAB." >> >> What exactly does it mean to appoint a liaison member to the >> RSAB (or any other group)? Such a liaison relationship needs >> to be mutual, which means it needs to be accepted by the group >> to which the liaison is named, in this case the RSAB. The RPC >> can't just appoint a liaison on its own. > > Peter, > > I've been trying to sit this one out since my initial comments, > but I guess I'm failing. Not speaking for Mike or anyone else... > > The difficulty with roles we have traditionally called "liaison" > is not only the kind of two-way situation you describe but that > the body to which they are appointed or designated can, > traditionally, decide that they should be excluded from > discussions. Sometimes we restrict that exclusion by requiring > that a reason be given and that the fall into some specific > category, sometimes we don't. > > Independent of what it is called, I think the RPC needs to have > a seat at the RSAB table and have it as part of the model. That > seat should not be discretionary. I suspect that a mechanism > will be needed to allow some or all of the RSAB members to > decide the RPC should be locked out of a discussion, but the > mechanism should be constrained and the information that is > being done and the reasons should be public. > > In particular, I am not talking about (and don't believe Mike, > Mirja, or others are talking about) a role that "needs to be > accepted by the group to which the liaison is named, in this > case the RSAB" for the RPC any more than I think that definition > would be appropriate for the LLC ED. > > Probably "liaison" is, as you, Mike, and others have sort of > suggested, the wrong term for what is intended by this. If I > correctly understand what at least some of us have intended, > "ex-officio" would be closer to the usual usage for both the LLC > ED and RPC representations. Apparently that term has not been > used in the document so might be used (with "non-voting" if > appropriate) for these two positions, thereby distinguishing > them from "liaisons" who the RSAB would need to invite and/or > accept. > > And that brings me to... > > --On Thursday, December 16, 2021 08:20 +1300 Jay Daley > wrote: > >> ... >> When it comes to the RPC being a liaison to RSAB, then the >> situation is much more complex than it is for the ED. In >> particular the RSAB needs to reconcile the following: >> >> - how to manage the RPC input/engagement when discussing the >> priorities and performance of the RPC >> - how to manage responding to RPC requests for advice >> - how to manage any conflicting advice from the RSCE >> and the RPC >> >> None of these are insurmountable, but I would hope that any >> proposal for the RPC being a mandatory liaison addresses those >> issues as not doing that puts the RSAB on a difficult footing >> from the start. > > Agreed. But I don't think that any of the above are hard. I > still believe that the model we are specifying will work to > produce the RFC Series we want only if things can proceed > collegially, with people having open discussions, sharing > perspectives and opinions openly. If the RSAB needs to go into > some type of executive session to make certain decisions with > some or all the ex-officio members (and/or liaisons) excluded, > then so be it, but I would hope that: > > -- The RPC would participate in discussions about their > priorities and performance. If needed, that would be far more > likely to result in incremental adjustments or corrections > rather than discussions about the detailed provisions of > contracts or something needing to assert authority. > -- The RPC should be present for discussions about their > requests for advice. Perhaps they would have nothing to say, > but that is not an issue. If the requests or associated issues > are not correctly interpreted, then having them present to > clarify would save time and improve results. Maybe I'm missing > something, but I can see no scenario in which excluding them > from such discussions would make the quality of RSAB decisions, > the Series, or the Internet better. > -- If the RPC and RSCE have conflicting advice, I believe that > having them discuss their different advice and perspectives with > each other and with the RSAB would be in the best interests of > all concerned. Certainly, I'd hope nothing would bar them from > having private discussions to clarify (even if not resolve) > conflicting positions. That would almost certainly be in > everyone's interest, but I see no reason for the document to > need to say that unless there are provisions that someone could > interpret as getting in the way (I haven't found any). > > Where I (very slightly) might disagree with Jay is that I don't > see that situation as being much more complex than the one with > the ED. For example, if the ED has advice about funding limits > or the LLC Board were to ask the RSAB (either as a separate > entity or as part of a more general query to the community) for > an evaluation of the performance of the ED, the same issues > would arise. I'd hope the RSAB would be able to turn such > advice or requests into discussions of tradeoffs or of strengths > and weaknesses. If a final decision required an executive > session with the ED excluded, so be it. So no so different from > the above. > > best, > john > > > From nobody Thu Dec 16 00:15:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DB593A1016 for ; Thu, 16 Dec 2021 00:15:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soIgUTuPg8wv for ; Thu, 16 Dec 2021 00:15:10 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 9720D3A1015 for ; Thu, 16 Dec 2021 00:15:08 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BG8F34l3993345 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 16 Dec 2021 09:15:03 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639642505; bh=aAfoU8R/NJuVfcB7dvIdv2xVtfQOxlj8tBEi4n0pqQw=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=Uny5jUpVJ0PTgdVGu2pbImefw2g1qrxmk88CblzjPtPKwM3EhH6Fle8QQJnsqLBrr QV/S65wS9koCGcnIepjCQYSrW9Zyc0AvNGWEL34QH0u6OZXtmzh8KhXp5q9iZU4Q+x bnuLB4ZySf0GyIS95y1a79zGldOSQ7vlM09fQFtA= Message-ID: Date: Thu, 16 Dec 2021 09:15:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: John C Klensin , Peter Saint-Andre , "StJohns, Michael" Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> From: Eliot Lear In-Reply-To: <37B079C1B661437AA93F47C7@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8Q0SNX2tptTAszw30si0HfdS" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:15:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8Q0SNX2tptTAszw30si0HfdS Content-Type: multipart/mixed; boundary="------------sLyP63YfQ54AemC2KyrTmYtr"; protected-headers="v1" From: Eliot Lear To: John C Klensin , Peter Saint-Andre , "StJohns, Michael" Cc: rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] RPC liaison to the RSAB References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> In-Reply-To: <37B079C1B661437AA93F47C7@PSB> --------------sLyP63YfQ54AemC2KyrTmYtr Content-Type: multipart/mixed; boundary="------------wX42YbFZc8oZq6QPALMuDYH9" --------------wX42YbFZc8oZq6QPALMuDYH9 Content-Type: multipart/alternative; boundary="------------BiZ9l9ikRNYE0nEV7rMXNYOG" --------------BiZ9l9ikRNYE0nEV7rMXNYOG Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SSB0aGluayBwZW9wbGUgYXJlIG1pc3VuZGVyc3RhbmRpbmcgdGhlIG5hdHVyZSBvZiB0aGUg UlNBQiBhbmQgdGhlIHZlcnkgDQptb2RlbCB3ZSBhcmUgY3JlYXRpbmcuDQoNClRoZSBSU0FC IGhhcyBwcmVjaXNlbHkgZm91ciBqb2JzOg0KDQogMS4gQXBwcm92ZSBvciBkaXNhcHByb3Zl IFJTV0cgd29yaywNCiAyLiBQcm92aWRlIGd1aWRhbmNlIHRvIHRoZSBSUEMgcmVnYXJkaW5n IGNlcnRhaW4gaW50ZXItc3RyZWFtIGNvbmZsaWN0cywNCiAzLiBQcm92aWRlIGFuIG9waW5p b24gcmVnYXJkaW5nIGZlZWRiYWNrIG9uIHRoZSBSU0NFIHRvIHRoZSBMTEMsIGFuZA0KIDQu IEFkZHJlc3MgY2VydGFpbiBhcHBlYWxzLg0KDQpUaGF0J3MgaXQuDQoNCkluIGVhY2ggY2Fz ZSwgb25lIHNob3VsZCBhc2sgd2hhdCBiZW5lZml0IGEgZm9ybWFsIGxpYWlzb24gYnJpbmdz LCBvciANCndoYXQgcmlzayB0aGUgZm9ybWFsIGxpYWlzb24gbWl0aWdhdGVzLCBhbmQgd2hh dCBjb21wbGljYXRpb25zIGEgZm9ybWFsIA0KbGlhaXNvbiBicmluZ3MuDQoNCkl0J3MgaW1w b3J0YW50IHRvIG5vdGUgdGhhdCBkaXNwdXRlcyBhbmQgYXBwZWFscyBhcmUgZXhwZWN0ZWQg dG8gYmUgDQpjb3JuZXIgY2FzZXMuwqAgV2Ugc2hvdWxkIGJlIGNhcmVmdWwgYWJvdXQgaG93 IHdlIGxlZ2lzbGF0ZSB0aGVtLsKgIA0KUHJpbmNpcGFsbHksIHRoZSB3b3JrIHRoYXQgbmVl ZHMgdG8gZ2V0IGRvbmUgb24gcG9saWN5IGRldmVsb3BtZW50IGlzIA0KbWVhbnQgdG8gaGFw cGVuIGluIHRoZSBSU1dHLsKgIFRoYXQgaXMgd2hlcmUgdGhlIGZvY3VzIG9mIGludGVyYWN0 aW9uIA0Kc2hvdWxkIGJlLg0KDQpTby7CoCBJIHdpbGwgYXNrIGFkdm9jYXRlcyBvZiBhbiBS UEMgbGlhaXNvbiByb2xlIHRvIHN0YXRlIGNsZWFybHkgd2hhdCANCnJpc2sgdGhleSBhcmUg aW50ZW5kaW5nIHRvIG1pdGlnYXRlLg0KDQpBIHJpc2sgdGhhdCB3ZSBjYW5ub3QgbWl0aWdh dGUgYXJlIGFueSBsaW1pdGF0aW9ucyB0aGUgRUQgb3IgTExDIG1heSANCnBsYWNlIG9uIHBh cnRpY2lwYXRpb24gYXMgYSBtYXR0ZXIgb2YgTExDIHBvbGljeSBvciBjb250cmFjdC4gUGxl YXNlIA0KZG9uJ3QgYXJndWUgdGhhdCBwb2ludCBoZXJlIHNpbmNlIHRoZXJlJ3Mgbm90aGlu ZyB0aGlzIGdyb3VwIGNhbiBvciANCnNob3VsZCBkbyBhYm91dCB0aGF0IChhbnkgaXNzdWVz IHdpdGggdGhhdCBuZWVkIHRvIGJlIGJyb3VnaHQgdG8gdGhlIExMQykuDQoNCkVsaW90DQoN Ck9uIDE2LjEyLjIxIDA0OjIwLCBKb2huIEMgS2xlbnNpbiB3cm90ZToNCj4gSW5kZXBlbmRl bnQgb2Ygd2hhdCBpdCBpcyBjYWxsZWQsIEkgdGhpbmsgdGhlIFJQQyBuZWVkcyB0byBoYXZl DQo+IGEgc2VhdCBhdCB0aGUgUlNBQiB0YWJsZSBhbmQgaGF2ZSBpdCBhcyBwYXJ0IG9mIHRo ZSBtb2RlbC4gIFRoYXQNCj4gc2VhdCBzaG91bGQgbm90IGJlIGRpc2NyZXRpb25hcnkuICBJ IHN1c3BlY3QgdGhhdCBhIG1lY2hhbmlzbQ0KPiB3aWxsIGJlIG5lZWRlZCB0byBhbGxvdyBz b21lIG9yIGFsbCBvZiB0aGUgUlNBQiBtZW1iZXJzIHRvDQo+IGRlY2lkZSB0aGUgUlBDIHNo b3VsZCBiZSBsb2NrZWQgb3V0IG9mIGEgZGlzY3Vzc2lvbiwgYnV0IHRoZQ0KPiBtZWNoYW5p c20gc2hvdWxkIGJlIGNvbnN0cmFpbmVkIGFuZCB0aGUgaW5mb3JtYXRpb24gdGhhdCBpcw0K PiBiZWluZyBkb25lIGFuZCB0aGUgcmVhc29ucyBzaG91bGQgYmUgcHVibGljLg0KPg0KPiBJ biBwYXJ0aWN1bGFyLCBJIGFtIG5vdCB0YWxraW5nIGFib3V0IChhbmQgZG9uJ3QgYmVsaWV2 ZSBNaWtlLA0KPiBNaXJqYSwgb3Igb3RoZXJzIGFyZSB0YWxraW5nIGFib3V0KSBhIHJvbGUg dGhhdCAibmVlZHMgdG8gYmUNCj4gYWNjZXB0ZWQgYnkgdGhlIGdyb3VwIHRvIHdoaWNoIHRo ZSBsaWFpc29uIGlzIG5hbWVkLCBpbiB0aGlzDQo+IGNhc2UgdGhlIFJTQUIiIGZvciB0aGUg UlBDIGFueSBtb3JlIHRoYW4gSSB0aGluayB0aGF0IGRlZmluaXRpb24NCj4gd291bGQgYmUg YXBwcm9wcmlhdGUgZm9yIHRoZSBMTEMgRUQuDQo+DQo+IFByb2JhYmx5ICJsaWFpc29uIiBp cywgYXMgeW91LCBNaWtlLCBhbmQgb3RoZXJzIGhhdmUgc29ydCBvZg0KPiBzdWdnZXN0ZWQs IHRoZSB3cm9uZyB0ZXJtIGZvciB3aGF0IGlzIGludGVuZGVkIGJ5IHRoaXMuICBJZiBJDQo+ IGNvcnJlY3RseSB1bmRlcnN0YW5kIHdoYXQgYXQgbGVhc3Qgc29tZSBvZiB1cyBoYXZlIGlu dGVuZGVkLA0KPiAiZXgtb2ZmaWNpbyIgd291bGQgYmUgY2xvc2VyIHRvIHRoZSB1c3VhbCB1 c2FnZSBmb3IgYm90aCB0aGUgTExDDQo+IEVEIGFuZCBSUEMgcmVwcmVzZW50YXRpb25zLiAg IEFwcGFyZW50bHkgdGhhdCB0ZXJtIGhhcyBub3QgYmVlbg0KPiB1c2VkIGluIHRoZSBkb2N1 bWVudCBzbyBtaWdodCBiZSB1c2VkICh3aXRoICJub24tdm90aW5nIiBpZg0KPiBhcHByb3By aWF0ZSkgZm9yIHRoZXNlIHR3byBwb3NpdGlvbnMsIHRoZXJlYnkgZGlzdGluZ3Vpc2hpbmcN Cj4gdGhlbSBmcm9tICJsaWFpc29ucyIgd2hvIHRoZSBSU0FCIHdvdWxkIG5lZWQgdG8gaW52 aXRlIGFuZC9vcg0KPiBhY2NlcHQuDQo+DQo+IEFuZCB0aGF0IGJyaW5ncyBtZSB0by4uLg0K Pg0KPiAtLU9uIFRodXJzZGF5LCBEZWNlbWJlciAxNiwgMjAyMSAwODoyMCArMTMwMCBKYXkg RGFsZXkNCj4gPGV4ZWMtZGlyZWN0b3JAaWV0Zi5vcmc+ICB3cm90ZToNCj4NCj4+IC4uLg0K Pj4gV2hlbiBpdCBjb21lcyB0byB0aGUgUlBDIGJlaW5nIGEgbGlhaXNvbiB0byBSU0FCLCB0 aGVuIHRoZQ0KPj4gc2l0dWF0aW9uIGlzIG11Y2ggbW9yZSBjb21wbGV4IHRoYW4gaXQgaXMg Zm9yIHRoZSBFRC4gIEluDQo+PiBwYXJ0aWN1bGFyIHRoZSBSU0FCIG5lZWRzIHRvIHJlY29u Y2lsZSB0aGUgZm9sbG93aW5nOg0KPj4NCj4+IC0gaG93IHRvIG1hbmFnZSB0aGUgUlBDIGlu cHV0L2VuZ2FnZW1lbnQgd2hlbiBkaXNjdXNzaW5nIHRoZQ0KPj4gcHJpb3JpdGllcyBhbmQg cGVyZm9ybWFuY2Ugb2YgdGhlIFJQQw0KPj4gLSBob3cgdG8gbWFuYWdlIHJlc3BvbmRpbmcg dG8gUlBDIHJlcXVlc3RzIGZvciBhZHZpY2UNCj4+IC0gaG93IHRvIG1hbmFnZSBhbnkgY29u ZmxpY3RpbmcgYWR2aWNlIGZyb20gdGhlIFJTQ0UNCj4+IGFuZCB0aGUgUlBDDQo+Pg0KPj4g Tm9uZSBvZiB0aGVzZSBhcmUgaW5zdXJtb3VudGFibGUsIGJ1dCBJIHdvdWxkIGhvcGUgdGhh dCBhbnkNCj4+IHByb3Bvc2FsIGZvciB0aGUgUlBDIGJlaW5nIGEgbWFuZGF0b3J5IGxpYWlz b24gYWRkcmVzc2VzIHRob3NlDQo+PiBpc3N1ZXMgYXMgbm90IGRvaW5nIHRoYXQgcHV0cyB0 aGUgUlNBQiBvbiBhIGRpZmZpY3VsdCBmb290aW5nDQo+PiBmcm9tIHRoZSBzdGFydC4NCj4g QWdyZWVkLiAgQnV0IEkgZG9uJ3QgdGhpbmsgdGhhdCBhbnkgb2YgdGhlIGFib3ZlIGFyZSBo YXJkLiAgSQ0KPiBzdGlsbCBiZWxpZXZlIHRoYXQgdGhlIG1vZGVsIHdlIGFyZSBzcGVjaWZ5 aW5nIHdpbGwgd29yayB0bw0KPiBwcm9kdWNlIHRoZSBSRkMgU2VyaWVzIHdlIHdhbnQgb25s eSBpZiB0aGluZ3MgY2FuIHByb2NlZWQNCj4gY29sbGVnaWFsbHksIHdpdGggcGVvcGxlIGhh dmluZyBvcGVuIGRpc2N1c3Npb25zLCBzaGFyaW5nDQo+IHBlcnNwZWN0aXZlcyBhbmQgb3Bp bmlvbnMgb3Blbmx5LiAgSWYgdGhlIFJTQUIgbmVlZHMgdG8gZ28gaW50bw0KPiBzb21lIHR5 cGUgb2YgIGV4ZWN1dGl2ZSBzZXNzaW9uIHRvIG1ha2UgY2VydGFpbiBkZWNpc2lvbnMgd2l0 aA0KPiBzb21lIG9yIGFsbCB0aGUgZXgtb2ZmaWNpbyBtZW1iZXJzIChhbmQvb3IgbGlhaXNv bnMpIGV4Y2x1ZGVkLA0KPiB0aGVuIHNvIGJlIGl0LCBidXQgSSB3b3VsZCBob3BlIHRoYXQ6 DQo+DQo+ICAgLS0gVGhlIFJQQyB3b3VsZCBwYXJ0aWNpcGF0ZSBpbiBkaXNjdXNzaW9ucyBh Ym91dCB0aGVpcg0KPiBwcmlvcml0aWVzIGFuZCBwZXJmb3JtYW5jZS4gIElmIG5lZWRlZCwg dGhhdCB3b3VsZCBiZSBmYXIgbW9yZQ0KPiBsaWtlbHkgdG8gcmVzdWx0IGluIGluY3JlbWVu dGFsIGFkanVzdG1lbnRzIG9yIGNvcnJlY3Rpb25zDQo+IHJhdGhlciB0aGFuIGRpc2N1c3Np b25zIGFib3V0IHRoZSBkZXRhaWxlZCBwcm92aXNpb25zIG9mDQo+IGNvbnRyYWN0cyBvciBz b21ldGhpbmcgbmVlZGluZyB0byBhc3NlcnQgYXV0aG9yaXR5Lg0KPiAgIC0tIFRoZSBSUEMg c2hvdWxkIGJlIHByZXNlbnQgZm9yIGRpc2N1c3Npb25zIGFib3V0IHRoZWlyDQo+IHJlcXVl c3RzIGZvciBhZHZpY2UuICBQZXJoYXBzIHRoZXkgd291bGQgaGF2ZSBub3RoaW5nIHRvIHNh eSwNCj4gYnV0IHRoYXQgaXMgbm90IGFuIGlzc3VlLiAgSWYgdGhlIHJlcXVlc3RzIG9yIGFz c29jaWF0ZWQgaXNzdWVzDQo+IGFyZSBub3QgY29ycmVjdGx5IGludGVycHJldGVkLCB0aGVu IGhhdmluZyB0aGVtIHByZXNlbnQgdG8NCj4gY2xhcmlmeSB3b3VsZCBzYXZlIHRpbWUgYW5k IGltcHJvdmUgcmVzdWx0cy4gIE1heWJlIEknbSBtaXNzaW5nDQo+IHNvbWV0aGluZywgYnV0 IEkgY2FuIHNlZSBubyBzY2VuYXJpbyBpbiB3aGljaCBleGNsdWRpbmcgdGhlbQ0KPiBmcm9t IHN1Y2ggZGlzY3Vzc2lvbnMgd291bGQgbWFrZSB0aGUgcXVhbGl0eSBvZiBSU0FCIGRlY2lz aW9ucywNCj4gdGhlIFNlcmllcywgb3IgdGhlIEludGVybmV0IGJldHRlci4NCj4gICAgLS0g SWYgdGhlIFJQQyBhbmQgUlNDRSBoYXZlIGNvbmZsaWN0aW5nIGFkdmljZSwgSSBiZWxpZXZl IHRoYXQNCj4gaGF2aW5nIHRoZW0gZGlzY3VzcyB0aGVpciBkaWZmZXJlbnQgYWR2aWNlIGFu ZCBwZXJzcGVjdGl2ZXMgd2l0aA0KPiBlYWNoIG90aGVyIGFuZCB3aXRoIHRoZSBSU0FCIHdv dWxkIGJlIGluIHRoZSBiZXN0IGludGVyZXN0cyBvZg0KPiBhbGwgY29uY2VybmVkLiAgQ2Vy dGFpbmx5LCBJJ2QgaG9wZSBub3RoaW5nIHdvdWxkIGJhciB0aGVtIGZyb20NCj4gaGF2aW5n IHByaXZhdGUgZGlzY3Vzc2lvbnMgdG8gY2xhcmlmeSAoZXZlbiBpZiBub3QgcmVzb2x2ZSkN Cj4gY29uZmxpY3RpbmcgcG9zaXRpb25zLiAgVGhhdCB3b3VsZCBhbG1vc3QgY2VydGFpbmx5 IGJlIGluDQo+IGV2ZXJ5b25lJ3MgaW50ZXJlc3QsIGJ1dCBJIHNlZSBubyByZWFzb24gZm9y IHRoZSBkb2N1bWVudCB0bw0KPiBuZWVkIHRvIHNheSB0aGF0IHVubGVzcyB0aGVyZSBhcmUg cHJvdmlzaW9ucyB0aGF0IHNvbWVvbmUgY291bGQNCj4gaW50ZXJwcmV0IGFzIGdldHRpbmcg aW4gdGhlIHdheSAoSSBoYXZlbid0IGZvdW5kIGFueSkuDQo+DQo+IFdoZXJlIEkgKHZlcnkg c2xpZ2h0bHkpIG1pZ2h0IGRpc2FncmVlIHdpdGggSmF5IGlzIHRoYXQgSSBkb24ndA0KPiBz ZWUgdGhhdCBzaXR1YXRpb24gYXMgYmVpbmcgbXVjaCBtb3JlIGNvbXBsZXggdGhhbiB0aGUg b25lIHdpdGgNCj4gdGhlIEVELiAgRm9yIGV4YW1wbGUsIGlmIHRoZSBFRCBoYXMgYWR2aWNl IGFib3V0IGZ1bmRpbmcgbGltaXRzDQo+IG9yIHRoZSBMTEMgQm9hcmQgd2VyZSB0byBhc2sg dGhlIFJTQUIgKGVpdGhlciBhcyBhIHNlcGFyYXRlDQo+IGVudGl0eSBvciBhcyBwYXJ0IG9m IGEgbW9yZSBnZW5lcmFsIHF1ZXJ5IHRvIHRoZSBjb21tdW5pdHkpIGZvcg0KPiBhbiBldmFs dWF0aW9uIG9mIHRoZSBwZXJmb3JtYW5jZSBvZiB0aGUgRUQsIHRoZSBzYW1lIGlzc3Vlcw0K PiB3b3VsZCBhcmlzZS4gIEknZCBob3BlIHRoZSBSU0FCIHdvdWxkIGJlIGFibGUgdG8gdHVy biBzdWNoDQo+IGFkdmljZSBvciByZXF1ZXN0cyBpbnRvIGRpc2N1c3Npb25zIG9mIHRyYWRl b2ZmcyBvciBvZiBzdHJlbmd0aHMNCj4gYW5kIHdlYWtuZXNzZXMuICBJZiBhIGZpbmFsIGRl Y2lzaW9uIHJlcXVpcmVkIGFuIGV4ZWN1dGl2ZQ0KPiBzZXNzaW9uIHdpdGggdGhlIEVEIGV4 Y2x1ZGVkLCBzbyBiZSBpdC4gIFNvIG5vIHNvIGRpZmZlcmVudCBmcm9tDQo+IHRoZSBhYm92 ZS4NCj4NCj4gYmVzdCwNCj4gICAgIGpvaG4NCj4NCj4gICANCj4NCg== --------------BiZ9l9ikRNYE0nEV7rMXNYOG Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think people are misunderstanding the nature of the RSAB and the very model we are creating.

The RSAB has precisely four jobs:

  1. Approve or disapprove RSWG work,
  2. Provide guidance to the RPC regarding certain inter-stream conflicts,
  3. Provide an opinion regarding feedback on the RSCE to the LLC, and
  4. Address certain appeals.
That's it.

In each case, one should ask what benefit a formal liaison brings, or what risk the formal liaison mitigates, and what complications a formal liaison brings.

It's important to note that disputes and appeals are expected to be corner cases.=C2=A0 We should be careful about how we legislate them.=C2=A0 Principally, the work that needs to get done on policy development is meant to happen in the RSWG.=C2=A0 That is where the= focus of interaction should be.

So.=C2=A0 I will ask advocates of an RPC liaison role to state cle= arly what risk they are intending to mitigate.=C2=A0

A risk that we cannot mitigate are any limitations the ED or LLC may place on participation as a matter of LLC policy or contract.=C2= =A0 Please don't argue that point here since there's nothing this group can or should do about that (any issues with that need to be brought to the LLC).

Eliot

On 16.12.21 04:20, John C Klensin wrote:
Independent of what it is ca=
lled, I think the RPC needs to have
a seat at the RSAB table and have it as part of the model.  That
seat should not be discretionary.  I suspect that a mechanism
will be needed to allow some or all of the RSAB members to
decide the RPC should be locked out of a discussion, but the
mechanism should be constrained and the information that is
being done and the reasons should be public.

In particular, I am not talking about (and don't believe Mike,
Mirja, or others are talking about) a role that "needs to be
accepted by the group to which the liaison is named, in this
case the RSAB" for the RPC any more than I think that definition
would be appropriate for the LLC ED.

Probably "liaison" is, as you, Mike, and others have sort of
suggested, the wrong term for what is intended by this.  If I
correctly understand what at least some of us have intended,
"ex-officio" would be closer to the usual usage for both the LLC
ED and RPC representations.   Apparently that term has not been
used in the document so might be used (with "non-voting" if
appropriate) for these two positions, thereby distinguishing
them from "liaisons" who the RSAB would need to invite and/or
accept.

And that brings me to...

--On Thursday, December 16, 2021 08:20 +1300 Jay Daley
<exec-director@ietf.org> wrote:


...
When it comes to the RPC being a liaison to RSAB, then the
situation is much more complex than it is for the ED.  In
particular the RSAB needs to reconcile the following:

- how to manage the RPC input/engagement when discussing the
priorities and performance of the RPC
- how to manage responding to RPC requests for advice
- how to manage any conflicting advice from the RSCE=20
and the RPC

None of these are insurmountable, but I would hope that any
proposal for the RPC being a mandatory liaison addresses those
issues as not doing that puts the RSAB on a difficult footing
from the start.

Agreed.  But I don't think that any of the above are hard.  I
still believe that the model we are specifying will work to
produce the RFC Series we want only if things can proceed
collegially, with people having open discussions, sharing
perspectives and opinions openly.  If the RSAB needs to go into
some type of  executive session to make certain decisions with
some or all the ex-officio members (and/or liaisons) excluded,
then so be it, but I would hope that:

 -- The RPC would participate in discussions about their
priorities and performance.  If needed, that would be far more
likely to result in incremental adjustments or corrections
rather than discussions about the detailed provisions of
contracts or something needing to assert authority.
 -- The RPC should be present for discussions about their
requests for advice.  Perhaps they would have nothing to say,
but that is not an issue.  If the requests or associated issues
are not correctly interpreted, then having them present to
clarify would save time and improve results.  Maybe I'm missing
something, but I can see no scenario in which excluding them
from such discussions would make the quality of RSAB decisions,
the Series, or the Internet better.
  -- If the RPC and RSCE have conflicting advice, I believe that
having them discuss their different advice and perspectives with
each other and with the RSAB would be in the best interests of
all concerned.  Certainly, I'd hope nothing would bar them from
having private discussions to clarify (even if not resolve)
conflicting positions.  That would almost certainly be in
everyone's interest, but I see no reason for the document to
need to say that unless there are provisions that someone could
interpret as getting in the way (I haven't found any).

Where I (very slightly) might disagree with Jay is that I don't
see that situation as being much more complex than the one with
the ED.  For example, if the ED has advice about funding limits
or the LLC Board were to ask the RSAB (either as a separate
entity or as part of a more general query to the community) for
an evaluation of the performance of the ED, the same issues
would arise.  I'd hope the RSAB would be able to turn such
advice or requests into discussions of tradeoffs or of strengths
and weaknesses.  If a final decision required an executive
session with the ED excluded, so be it.  So no so different from
the above.

best,
   john

=20
--------------BiZ9l9ikRNYE0nEV7rMXNYOG-- --------------wX42YbFZc8oZq6QPALMuDYH9 Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------wX42YbFZc8oZq6QPALMuDYH9-- --------------sLyP63YfQ54AemC2KyrTmYtr-- --------------8Q0SNX2tptTAszw30si0HfdS Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG69YQFAwAAAAAACgkQh7ZrRtnSejOe uQf9E5FvPwhSK6yB34KZkWBdp75RDbNHzGxkUTY1YuArrqCKTtXEEzQYmHX+41lMI8dYyV2PJvkx LO5Os8Y9okF+fvE5g6FlnxhF/cysqEiEENzuKVEGdUesS9bBlj0AakIegTNjE14wyzU0VUrydYV7 DKXG1VKXboRn4PRq+UdwsJeKJyPgCuUODbVim26wu5doX+DJbsjFhHTIeOs8tu1u8OMsmpNHCxQb zVaSnRbTE80yezMYFhkzSqWm/WavmrdZEfKb62Wix+Y431xzOW6ItxRaSBIVbrkD7iyBRrNi+LeK SKNmjnPqUdPGLFe59SeuC+DWqw0sMFfTQY5stN+u0w== =HJu8 -----END PGP SIGNATURE----- --------------8Q0SNX2tptTAszw30si0HfdS-- From nobody Thu Dec 16 11:23:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1EC73A103D for ; Thu, 16 Dec 2021 11:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 0bB5pjVvIwVi for ; Thu, 16 Dec 2021 11:23:21 -0800 (PST) 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 EA1293A105B for ; Thu, 16 Dec 2021 11:23:20 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id 8so275990qtx.5 for ; Thu, 16 Dec 2021 11:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=t+9hPrVJSIYPYqZAZ0MzbfjcE3xx7NjuueMIxKY7nTU=; b=sYNxFuZGlJYRfSMbrbnPocvsIBbBQrJuk470oekaLnzsbkCYB4mqMBrFvF/UNvpBSB I+HwblyTFlVjYQk2NR5rle9j9FsKSBTi2UZjta+p9Sel5IAKmI4QwXjrMH97bEp9cjg2 /RUwUhq+FwJlWCQHqG/BIWAPSfhOKtN0IeEL5gruxnLEYLRI83yf3zXV+YCWFybxegzB xzytS4al547vXWY1ST2Ukwxvha93YFIyB+8mHoZtqRzXgyImYEfaF1byPwz3jqcMWoDG 1OUQAFSCnz9zLKryhv4f+cDyn2Hvx+j+gdsqfBmaMaxrxcdzQWE8WykFPIJQb7qfyZDD IzTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=t+9hPrVJSIYPYqZAZ0MzbfjcE3xx7NjuueMIxKY7nTU=; b=GV8KpK+pCB8GGe4Jt9Py36tXVtO0LejR/O4cts6ithgpyhUL0JyvlcuVYQqKqwCbYO AQNitPWC86OSeqw1qoNX9DXrWN/tru/F5uqanX3WYo25ZmWwy9LgRUXPGzyIcM4nuLdX DJkASbzx0DsLix78ijVOhovgPM2m3+MVqJj6w8dq77XwbAFYADHKSSK5ngAYAAhNC/Ct OA5Bhcdsryam9xLG2tqgY1qudWWJJOyiWE5yAMbN0EEpdOfs1J8e7jW/ysgMHH88IhTb dNhcWcyRdf7jWU2QrNlNSuGubsfkIFRHvBjNWagZx9wNxp9pybtqE5U1DbZvAAJ6jrAG g5PA== X-Gm-Message-State: AOAM533+VPZxN8dQlmOQ+YJcwGKgscsOB4i4rNOENNVEo4A7OS9JdOBy Q3S1R2qm5hdDzxYv4pvI33hm0g== X-Google-Smtp-Source: ABdhPJyQVKCx00P9y7rDEoIOBiOQn6kKDUgFa9IxILwf0fMm1OGWczcpMxrGZ/9BTvn5aTioQ8cXwA== X-Received: by 2002:ac8:5792:: with SMTP id v18mr6354396qta.610.1639682598881; Thu, 16 Dec 2021 11:23:18 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id d23sm3276520qkl.70.2021.12.16.11.23.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 11:23:18 -0800 (PST) Content-Type: multipart/alternative; boundary="------------Gq0YVidwZMS0N3fkuNBC6haz" Message-ID: Date: Thu, 16 Dec 2021 14:23:16 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eric Rescorla Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:23:27 -0000 This is a multi-part message in MIME format. --------------Gq0YVidwZMS0N3fkuNBC6haz Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/15/2021 9:35 PM, Eric Rescorla wrote: > > > > > So all we’re arguing about here is whether or not the RPC always > gets a > > seat at the table, or whether that’s subject to the whims of the > then > > current RSAB.  There’s precedence ( e.g. Nomcom) in specifying a > > requirement here rather than deferring to an ever changing group of > > people with their own set of biases. > > > I'm not sure that this precedent cuts the way you seem to believe. As > I understand > it, nomcoms have varied quite a bit in the level of participation. > > -Ekr I'm not sure of the point you're trying to make here.   If you're saying that sometimes some of the organizations permitted liaisons failed to send them, then sure, but that's the choice of the sending organization and doesn't undercut what I'm saying and in fact exactly mirrors what I said about the RPC choosing its representative or none at all.  If you're saying that a given Nomcom declined to seat a liaison from an organization that was allowed one by the current Nomcom procedures RFC - it never happened AFAICT. Or something else?  And exactly how does it undercut what I've said? Later, Mike --------------Gq0YVidwZMS0N3fkuNBC6haz Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/15/2021 9:35 PM, Eric Rescorla wrote:



> So all we’re arguing about here is whether or not the RPC always gets a
> seat at the table, or whether that’s subject to the whims of the then
> current RSAB.  There’s precedence ( e.g. Nomcom) in specifying a
> requirement here rather than deferring to an ever changing group of
> people with their own set of biases.


I'm not sure that this precedent cuts the way you seem to believe. As I understand
it, nomcoms have varied quite a bit in the level of participation.

-Ekr

I'm not sure of the point you're trying to make here.   If you're saying that sometimes some of the organizations permitted liaisons failed to send them, then sure, but that's the choice of the sending organization and doesn't undercut what I'm saying and in fact exactly mirrors what I said about the RPC choosing its representative or none at all.  If you're saying that a given Nomcom declined to seat a liaison from an organization that was allowed one by the current Nomcom procedures RFC - it never happened AFAICT.

Or something else?  And exactly how does it undercut what I've said?

Later, Mike



--------------Gq0YVidwZMS0N3fkuNBC6haz-- From nobody Thu Dec 16 11:50:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E47A3A115B for ; Thu, 16 Dec 2021 11:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 Gp4Nf5g-TBHd for ; Thu, 16 Dec 2021 11:50:11 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B15473A1158 for ; Thu, 16 Dec 2021 11:50:10 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id d21so40869qkl.3 for ; Thu, 16 Dec 2021 11:50:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=viI+22RAtop6Btvi76jNKGQKAMGYFetI83BwAaFQBrs=; b=zgoC4EexVgRU/mCAXYzt1QYDR6o68tqqQAKKJXvD8fUhVZgV1x9K0aOXplLZv92MMB LlXD6kYGrr3T4uPCATnX/aioWjS43OMF1lZNJt+mccYtpHAWZGwr9CiD+EdV3epi4oh6 +DwFn0CQgtiqoV8XT4GxBTj7QUgN429zhW9h6HgR15gtR7QCnrL6d7HnwOGkbzO5DQVW dz6wS+xwQVmRsxo17FtJ+ujR1wZ3Py5J5CJq8DALjAXnMi2/izkyPGDTZqDeJjmKVFmj Ujc+qy+ouThfnpBZhm5C1IIukboO+E3m/Dq1abv/yMSFKs3ofgxuadsFHgGVnRJOYTnt 1hUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=viI+22RAtop6Btvi76jNKGQKAMGYFetI83BwAaFQBrs=; b=Rhlp67qi8kiK4M9RPuXC4NpcgM6xdlawma3PFWmHBm6vqpJuOddwQdriyQyl1IDFdA lzjp+26eoLIYQ2Nr/8UrRaCTXbp2CgKbs1pFUjHSKUy8sQGX1RkLEj57ohSU7gt+pQmn aZ4R9nxsjLULfxEgJMiOPFRpVy52mTRLGqUYslA4H58DIJBG0V3H5Un3RH/6qRVWaaBM rFnr4PB20rsOYAwOJc655OqW4P9+SHbbQf6kgMiO0tcBnro7SzqRQAEt5Z2GYLqPeBTm tquECnZuZkuo1+PlXqpqV61ZA4cbdLB9udQtC2ds22+dQ7mx497edG1R33mfFfYBxPJI VLcQ== X-Gm-Message-State: AOAM531XfO5Fm8Ni6zTTA2FtieRupxtb4WA2jwkqx/gtCstxgj0phkq4 m8U0kvJRRqT5OawCPgkg09/y+Q== X-Google-Smtp-Source: ABdhPJyLbLiplBj99seib06yh2QYvNuJghEKMLXIEA0roba26p20mC03q/78H3BAmHkTwUJdxKcUrA== X-Received: by 2002:a05:620a:1aa5:: with SMTP id bl37mr13593668qkb.175.1639684208369; Thu, 16 Dec 2021 11:50:08 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id h13sm5118587qtk.25.2021.12.16.11.50.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 11:50:07 -0800 (PST) Content-Type: multipart/alternative; boundary="------------CVpdJxtR9E0WnNlkdu5u4OCV" Message-ID: Date: Thu, 16 Dec 2021 14:50:05 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , John C Klensin , Peter Saint-Andre Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:50:16 -0000 This is a multi-part message in MIME format. --------------CVpdJxtR9E0WnNlkdu5u4OCV Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Top posting because. Eliot - Generally the role of the chair is to elicit both points and rationales and engender a discussion, not to pick one point as the true answer and require the other side to attack it. In this case, I think there's substantial commentary on why the RPC should have a seat at the table.  And little commentary on not beside "let the RSAB decide". For your points below: 1) If the RSWG is proposing something that will impact the RPC's work, work flow, LOE, costs, SLA etc, having the RPC be able to explain exactly what will need to change to support the proposal, and explaining what could be moved around to make things work seems to be a useful input into whether the RSAB approves a document or returns it with comments to the RSWG.   Given that pretty much any document that describes functional albeit strategic changes will involve the RPC and that I would be surprised if there are many non-functional (changes not affecting function) proposed by the RSWG, it just makes sense that the RPC be included.  Filtering all that through the ED is not a) scalable (how much more gets piled on to Jay or his successor?), b) efficient (e.g. a pre-meeting with the ED and the RPC to prepare the ED for the RSAB meeting), c) error-free (think the game of "Telephone").  In fact having both the ED and the RPC there may mean that small tweaks can be approved quickly as both sides of the contract would be represented. 2) This one seems obvious - the RPC brings things to the RSAB for discussion.  Having a seat at the table to add things to the agenda vs being summoned at the whim of the RSAB - the equities argue for the former. I actually expect that most meetings (based on the RSOC's minutes) will involve RPC discussions of some sort under this heading. 3) I need to get back to your other email on this point, but I'm becoming more and more convinced that the RSAB as a group should not be holding executive sessions for any reason.  This task for the RSAB only really makes sense if all of the RSAB members excluding the RSCE were from their appointing organizations and were long-lived in the job - and neither of these appear to be guaranteed to be true.  In any event the presence of this task neither argues for or against non-voting ex-officio members. 4) The ED doesn't have a role in the appeals process, but is still included as ex-officio so the presence of this task neither argues for or against having the RPC having an ex-officio member.  It's possible that both the ED and the RPC might have useful input into a given appeal which might be missed if either is excluded from the discussions. I look forward to the opponents of the RPC being ex-officio providing related commentary - e.g.  a) why should a random membership of the RSAB decide whether the RPC relationship is ex-officio or something else? b) how often should they decide this (e.g. everytime a member changes out?  each meeting? each year? never?), c) what is the difference between an ex-officio member and one that gets invited to every meeting (e.g. is the difference that the RPC by rule sits mute until asked about something?  Should that rule apply to the ED as well? If not, why not?) Mike On 12/16/2021 3:15 AM, Eliot Lear wrote: > > I think people are misunderstanding the nature of the RSAB and the > very model we are creating. > > The RSAB has precisely four jobs: > > 1. Approve or disapprove RSWG work, > 2. Provide guidance to the RPC regarding certain inter-stream conflicts, > 3. Provide an opinion regarding feedback on the RSCE to the LLC, and > 4. Address certain appeals. > > That's it. > > In each case, one should ask what benefit a formal liaison brings, or > what risk the formal liaison mitigates, and what complications a > formal liaison brings. > > It's important to note that disputes and appeals are expected to be > corner cases.  We should be careful about how we legislate them.  > Principally, the work that needs to get done on policy development is > meant to happen in the RSWG.  That is where the focus of interaction > should be. > > So.  I will ask advocates of an RPC liaison role to state clearly what > risk they are intending to mitigate. > > A risk that we cannot mitigate are any limitations the ED or LLC may > place on participation as a matter of LLC policy or contract.  Please > don't argue that point here since there's nothing this group can or > should do about that (any issues with that need to be brought to the LLC). > > Eliot > > On 16.12.21 04:20, John C Klensin wrote: >> Independent of what it is called, I think the RPC needs to have >> a seat at the RSAB table and have it as part of the model. That >> seat should not be discretionary. I suspect that a mechanism >> will be needed to allow some or all of the RSAB members to >> decide the RPC should be locked out of a discussion, but the >> mechanism should be constrained and the information that is >> being done and the reasons should be public. >> >> In particular, I am not talking about (and don't believe Mike, >> Mirja, or others are talking about) a role that "needs to be >> accepted by the group to which the liaison is named, in this >> case the RSAB" for the RPC any more than I think that definition >> would be appropriate for the LLC ED. >> >> Probably "liaison" is, as you, Mike, and others have sort of >> suggested, the wrong term for what is intended by this. If I >> correctly understand what at least some of us have intended, >> "ex-officio" would be closer to the usual usage for both the LLC >> ED and RPC representations. Apparently that term has not been >> used in the document so might be used (with "non-voting" if >> appropriate) for these two positions, thereby distinguishing >> them from "liaisons" who the RSAB would need to invite and/or >> accept. >> >> And that brings me to... >> >> --On Thursday, December 16, 2021 08:20 +1300 Jay Daley >> wrote: >> >>> ... >>> When it comes to the RPC being a liaison to RSAB, then the >>> situation is much more complex than it is for the ED. In >>> particular the RSAB needs to reconcile the following: >>> >>> - how to manage the RPC input/engagement when discussing the >>> priorities and performance of the RPC >>> - how to manage responding to RPC requests for advice >>> - how to manage any conflicting advice from the RSCE >>> and the RPC >>> >>> None of these are insurmountable, but I would hope that any >>> proposal for the RPC being a mandatory liaison addresses those >>> issues as not doing that puts the RSAB on a difficult footing >>> from the start. >> Agreed. But I don't think that any of the above are hard. I >> still believe that the model we are specifying will work to >> produce the RFC Series we want only if things can proceed >> collegially, with people having open discussions, sharing >> perspectives and opinions openly. If the RSAB needs to go into >> some type of executive session to make certain decisions with >> some or all the ex-officio members (and/or liaisons) excluded, >> then so be it, but I would hope that: >> >> -- The RPC would participate in discussions about their >> priorities and performance. If needed, that would be far more >> likely to result in incremental adjustments or corrections >> rather than discussions about the detailed provisions of >> contracts or something needing to assert authority. >> -- The RPC should be present for discussions about their >> requests for advice. Perhaps they would have nothing to say, >> but that is not an issue. If the requests or associated issues >> are not correctly interpreted, then having them present to >> clarify would save time and improve results. Maybe I'm missing >> something, but I can see no scenario in which excluding them >> from such discussions would make the quality of RSAB decisions, >> the Series, or the Internet better. >> -- If the RPC and RSCE have conflicting advice, I believe that >> having them discuss their different advice and perspectives with >> each other and with the RSAB would be in the best interests of >> all concerned. Certainly, I'd hope nothing would bar them from >> having private discussions to clarify (even if not resolve) >> conflicting positions. That would almost certainly be in >> everyone's interest, but I see no reason for the document to >> need to say that unless there are provisions that someone could >> interpret as getting in the way (I haven't found any). >> >> Where I (very slightly) might disagree with Jay is that I don't >> see that situation as being much more complex than the one with >> the ED. For example, if the ED has advice about funding limits >> or the LLC Board were to ask the RSAB (either as a separate >> entity or as part of a more general query to the community) for >> an evaluation of the performance of the ED, the same issues >> would arise. I'd hope the RSAB would be able to turn such >> advice or requests into discussions of tradeoffs or of strengths >> and weaknesses. If a final decision required an executive >> session with the ED excluded, so be it. So no so different from >> the above. >> >> best, >> john >> >> >> --------------CVpdJxtR9E0WnNlkdu5u4OCV Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Top posting because.

Eliot - Generally the role of the chair is to elicit both points and rationales and engender a discussion, not to pick one point as the true answer and require the other side to attack it.

In this case, I think there's substantial commentary on why the RPC should have a seat at the table.  And little commentary on not beside "let the RSAB decide".

For your points below:

1) If the RSWG is proposing something that will impact the RPC's work, work flow, LOE, costs, SLA etc, having the RPC be able to explain exactly what will need to change to support the proposal, and explaining what could be moved around to make things work seems to be a useful input into whether the RSAB approves a document or returns it with comments to the RSWG.   Given that pretty much any document that describes functional albeit strategic changes will involve the RPC and that I would be surprised if there are many non-functional (changes not affecting function) proposed by the RSWG, it just makes sense that the RPC be included.  Filtering all that through the ED is not a) scalable (how much more gets piled on to Jay or his successor?), b) efficient (e.g. a pre-meeting with the ED and the RPC to prepare the ED for the RSAB meeting), c) error-free (think the game of "Telephone").  In fact having both the ED and the RPC there may mean that small tweaks can be approved quickly as both sides of the contract would be represented.

2) This one seems obvious - the RPC brings things to the RSAB for discussion.  Having a seat at the table to add things to the agenda vs being summoned at the whim of the RSAB - the equities argue for the former. I actually expect that most meetings (based on the RSOC's minutes) will involve RPC discussions of some sort under this heading.

3) I need to get back to your other email on this point, but I'm becoming more and more convinced that the RSAB as a group should not be holding executive sessions for any reason.  This task for the RSAB only really makes sense if all of the RSAB members excluding the RSCE were from their appointing organizations and were long-lived in the job - and neither of these appear to be guaranteed to be true.  In any event the presence of this task neither argues for or against non-voting ex-officio members.

4) The ED doesn't have a role in the appeals process, but is still included as ex-officio so the presence of this task neither argues for or against having the RPC having an ex-officio member.  It's possible that both the ED and the RPC might have useful input into a given appeal which might be missed if either is excluded from the discussions.

I look forward to the opponents of the RPC being ex-officio providing related commentary - e.g.  a) why should a random membership of the RSAB decide whether the RPC relationship is ex-officio or something else? b) how often should they decide this (e.g. everytime a member changes out?  each meeting? each year? never?), c) what is the difference between an ex-officio member and one that gets invited to every meeting (e.g. is the difference that the RPC by rule sits mute until asked about something?  Should that rule apply to the ED as well? If not, why not?)

Mike




On 12/16/2021 3:15 AM, Eliot Lear wrote:

I think people are misunderstanding the nature of the RSAB and the very model we are creating.

The RSAB has precisely four jobs:

  1. Approve or disapprove RSWG work,
  2. Provide guidance to the RPC regarding certain inter-stream conflicts,
  3. Provide an opinion regarding feedback on the RSCE to the LLC, and
  4. Address certain appeals.
That's it.

In each case, one should ask what benefit a formal liaison brings, or what risk the formal liaison mitigates, and what complications a formal liaison brings.

It's important to note that disputes and appeals are expected to be corner cases.  We should be careful about how we legislate them.  Principally, the work that needs to get done on policy development is meant to happen in the RSWG.  That is where the focus of interaction should be.

So.  I will ask advocates of an RPC liaison role to state clearly what risk they are intending to mitigate. 

A risk that we cannot mitigate are any limitations the ED or LLC may place on participation as a matter of LLC policy or contract.  Please don't argue that point here since there's nothing this group can or should do about that (any issues with that need to be brought to the LLC).

Eliot

On 16.12.21 04:20, John C Klensin wrote:
Independent of what it is called, I think the RPC needs to have
a seat at the RSAB table and have it as part of the model.  That
seat should not be discretionary.  I suspect that a mechanism
will be needed to allow some or all of the RSAB members to
decide the RPC should be locked out of a discussion, but the
mechanism should be constrained and the information that is
being done and the reasons should be public.

In particular, I am not talking about (and don't believe Mike,
Mirja, or others are talking about) a role that "needs to be
accepted by the group to which the liaison is named, in this
case the RSAB" for the RPC any more than I think that definition
would be appropriate for the LLC ED.

Probably "liaison" is, as you, Mike, and others have sort of
suggested, the wrong term for what is intended by this.  If I
correctly understand what at least some of us have intended,
"ex-officio" would be closer to the usual usage for both the LLC
ED and RPC representations.   Apparently that term has not been
used in the document so might be used (with "non-voting" if
appropriate) for these two positions, thereby distinguishing
them from "liaisons" who the RSAB would need to invite and/or
accept.

And that brings me to...

--On Thursday, December 16, 2021 08:20 +1300 Jay Daley
<exec-director@ietf.org> wrote:


...
When it comes to the RPC being a liaison to RSAB, then the
situation is much more complex than it is for the ED.  In
particular the RSAB needs to reconcile the following:

- how to manage the RPC input/engagement when discussing the
priorities and performance of the RPC
- how to manage responding to RPC requests for advice
- how to manage any conflicting advice from the RSCE 
and the RPC

None of these are insurmountable, but I would hope that any
proposal for the RPC being a mandatory liaison addresses those
issues as not doing that puts the RSAB on a difficult footing
from the start.

Agreed.  But I don't think that any of the above are hard.  I
still believe that the model we are specifying will work to
produce the RFC Series we want only if things can proceed
collegially, with people having open discussions, sharing
perspectives and opinions openly.  If the RSAB needs to go into
some type of  executive session to make certain decisions with
some or all the ex-officio members (and/or liaisons) excluded,
then so be it, but I would hope that:

 -- The RPC would participate in discussions about their
priorities and performance.  If needed, that would be far more
likely to result in incremental adjustments or corrections
rather than discussions about the detailed provisions of
contracts or something needing to assert authority.
 -- The RPC should be present for discussions about their
requests for advice.  Perhaps they would have nothing to say,
but that is not an issue.  If the requests or associated issues
are not correctly interpreted, then having them present to
clarify would save time and improve results.  Maybe I'm missing
something, but I can see no scenario in which excluding them
from such discussions would make the quality of RSAB decisions,
the Series, or the Internet better.
  -- If the RPC and RSCE have conflicting advice, I believe that
having them discuss their different advice and perspectives with
each other and with the RSAB would be in the best interests of
all concerned.  Certainly, I'd hope nothing would bar them from
having private discussions to clarify (even if not resolve)
conflicting positions.  That would almost certainly be in
everyone's interest, but I see no reason for the document to
need to say that unless there are provisions that someone could
interpret as getting in the way (I haven't found any).

Where I (very slightly) might disagree with Jay is that I don't
see that situation as being much more complex than the one with
the ED.  For example, if the ED has advice about funding limits
or the LLC Board were to ask the RSAB (either as a separate
entity or as part of a more general query to the community) for
an evaluation of the performance of the ED, the same issues
would arise.  I'd hope the RSAB would be able to turn such
advice or requests into discussions of tradeoffs or of strengths
and weaknesses.  If a final decision required an executive
session with the ED excluded, so be it.  So no so different from
the above.

best,
   john


--------------CVpdJxtR9E0WnNlkdu5u4OCV-- From nobody Thu Dec 16 12:02:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A556E3A11DB for ; Thu, 16 Dec 2021 12:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 4RaYATj8hKAD for ; Thu, 16 Dec 2021 12:01:51 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2F933A12B0 for ; Thu, 16 Dec 2021 12:01:45 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id x6so36497515iol.13 for ; Thu, 16 Dec 2021 12:01:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dOWU0FI51Jz4p0jdgfUNC2c6xz7+pqjesgJlcE4Kphw=; b=yWoEvC9f2d9DG+Jm/cM+Qh7njUq+MN2unxCT9/d6ytF91iI0f68FUvzpJYQZ1fK3Bk hwHs/DB66erDXYDH4eDjC7hVEBLDjq4Q/sqyNyPcTQnMQ4JMGASENYNkHyUVG9ildp29 7/kE/1PCj8ULLpYIErB5Wk8qziQbDzfvaAY8KUxtfpYrlinuOpNpGNf5A5zZ07cUVgSk fn0r2N50rNj/DpVtyhSbZ9V+ooO8SsmUBtE0b47C1PmAC+PNDX9E1+P8nDxXteHWiFQy mD0Z9DzZ4M3sGWafNBGuVMWFZ8hSRwSGeBmyWXZV13yWxSBFLcDP2Jk6xsF1p9KWT5+J SG1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dOWU0FI51Jz4p0jdgfUNC2c6xz7+pqjesgJlcE4Kphw=; b=yx7SAYlAsrfhzjRou6LYguCO34nV2XQTUEKWyIbJvmdGmwK4ut1ydAueX7NEGSkrdQ IEBEVSYriKobyUpZ+fzdQfClvFz6Df3NmxoRG4mSayvRSyREvEyXOmHhycO2Ztn9IGNS 3DbXLrRgjp6FUu0eIEqqHMTEfZti+dXjbMhslqsGK+lGxEFJbQdUYcFtYu4Useb+ORIC vAjrp04Tkxo8gL58wXH88ylNterfDMChBFm6OF9m0KKoLx50KZ16GgQfO1Lgi5It6TH2 SCAcBdpr5i40X770gaD4SFaRE9HZycXE9XHxc9+mZ5K3N85L2zFwCj1XFYmnLKGMvIbX 5jug== X-Gm-Message-State: AOAM5314/hUUsbD/IOIDY8gEiRHzTdMiXr8NarXqfSR+IbDe/USUxMpL f4HxM9TGW4x7sqNTXA08VjxYNa1jSQXYwadin0j5heLBGjs= X-Google-Smtp-Source: ABdhPJyGpok3pZvEs0EWv2UP1DF2sXQ8c/+8q+HXiHNOKgciGjB2DHPsuhCUzoISfHS0bx6dxH2AIbMqA0GeJkAmMuw= X-Received: by 2002:a05:6638:d56:: with SMTP id d22mr10681891jak.20.1639684903332; Thu, 16 Dec 2021 12:01:43 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> In-Reply-To: From: Eric Rescorla Date: Thu, 16 Dec 2021 12:01:07 -0800 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000034ff6b05d348e440" Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:02:05 -0000 --00000000000034ff6b05d348e440 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns wrote: > On 12/15/2021 9:35 PM, Eric Rescorla wrote: > > > > > > So all we=E2=80=99re arguing about here is whether or not the RPC alway= s gets a >> > seat at the table, or whether that=E2=80=99s subject to the whims of t= he then >> > current RSAB. There=E2=80=99s precedence ( e.g. Nomcom) in specifying= a >> > requirement here rather than deferring to an ever changing group of >> > people with their own set of biases. >> >> > I'm not sure that this precedent cuts the way you seem to believe. As I > understand > it, nomcoms have varied quite a bit in the level of participation. > > -Ekr > > I'm not sure of the point you're trying to make here. If you're saying > that sometimes some of the organizations permitted liaisons failed to sen= d > them, then sure, but that's the choice of the sending organization and > doesn't undercut what I'm saying and in fact exactly mirrors what I said > about the RPC choosing its representative or none at all. If you're sayi= ng > that a given Nomcom declined to seat a liaison from an organization that > was allowed one by the current Nomcom procedures RFC - it never happened > AFAICT. > > Or something else? And exactly how does it undercut what I've said? > I'm saying that the nomcom sets the terms under which the liaisons participate, and that in some cases it's a lot and in some cases it's much less. Which is precisely what I'm advocating for here, rather than prescribing the manner in which the liaison engages. -Ekr Later, Mike > > > > --00000000000034ff6b05d348e440 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 16, 2021 at 11:23 AM Mich= ael StJohns <msj@nthpermutatio= n.com> wrote:
=20 =20 =20
On 12/15/2021 9:35 PM, Eric Rescorla wrote:
=20



> So all we=E2=80=99re arguing about here is whether or = not the RPC always gets a
> seat at the table, or whether that=E2=80=99s subject t= o the whims of the then
> current RSAB.=C2=A0 There=E2=80=99s precedence ( e.g. = Nomcom) in specifying a
> requirement here rather than deferring to an ever changing group of
> people with their own set of biases.


I'm not sure that this precedent cuts the way you seem t= o believe. As I understand
it, nomcoms have varied quite a bit in the level of participation.

-Ekr

I'm not sure of the point you're trying to make here.=C2=A0= =C2=A0 If you're saying that sometimes some of the organizations permitted liaisons failed to send them, then sure, but that's the choice of the sending organization and doesn't undercut what I'm saying and= in fact exactly mirrors what I said about the RPC choosing its representative or none at all.=C2=A0 If you're saying that a give= n Nomcom declined to seat a liaison from an organization that was allowed one by the current Nomcom procedures RFC - it never happened AFAICT.

Or something else?=C2=A0 And exactly how does it undercut what I'= ;ve said?

I'm saying that the nomcom sets = the terms under which the liaisons participate, and that in some cases it&#= 39;s a lot and in some cases it's much less. Which is precisely what I&= #39;m advocating for here, rather than prescribing the manner in which the = liaison engages.

-Ekr



Later, Mike



--00000000000034ff6b05d348e440-- From nobody Thu Dec 16 12:14:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 974B63A1360 for ; Thu, 16 Dec 2021 12:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 dE9jgBargJtE for ; Thu, 16 Dec 2021 12:14:15 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26C033A1331 for ; Thu, 16 Dec 2021 12:14:10 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id 132so56129qkj.11 for ; Thu, 16 Dec 2021 12:14:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=l5i/lpf+Tp/aKKnfMIDiSZMhWeBN+7qIXJ7MFDbI1so=; b=F3/cwCswVy3rniRvViTUyU+LqBt70dhqg9PWTW/ywX5vXekfPZo71hmSH7tMpvFRDy Hy4ffrxhlx/2ppRLJGQRHvesjIaG5bMsKvuNLSawHyrB/b5AkDv4WdIMNxanXTsS+kT1 /u+dXAXUpEKKgV9GNR6qRZGy/Qs8/c2NteQBAsdl+p6hIs3TE6E9+Vg8g2xH5KSruUiT 9GbgKiK0z/fzWQHOhdiOlQXar/mtGWImnucnajdz+xoVOqjWRrOiEAHVbTU9x4H3HIdU 0ICOL0yuFGUhTqApeDV/VYL0gTa9PeQF4uH5gw8eNzMMhBUTUNYV4OkkxfOnQEY+AruY /RAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=l5i/lpf+Tp/aKKnfMIDiSZMhWeBN+7qIXJ7MFDbI1so=; b=1hccGAY3HiAQLw3x1BE/fE4Rh43ALiIA5dVRPLMfxTM+pkSTG+TFDhdXwAjUqDjwNx 2LuD3QwjD6H3N4FfOFaqJinRXnFW8/j/NczxO2jlS7GYx7hXfVXvzwhJNH515h3tHgTJ YNk4ds3oQipY0kaZaV4J2Rlxtv90FHhbzrXYEAUUzsaj0h1rPDPlZOrWi4DJCIijYree sgXB1ErP+hRPyfokqaEFMcAEnWkVjyECS0kwHqb32cgBFcTvNPShNOCN1AF3THjt7DE4 VHqTmXhWhHaF4x5w8zcV87xe4lE5niROWUytplBckRECtvw8geOpPZQU74idEwRQFhay eJcA== X-Gm-Message-State: AOAM530VvVAR8lLdmnhEAXQIueCbRRw5o0m/uRXjUiHnA7LF5O8q6+aS OnZjtG8drS2TnxSMVXGtlVRcda5D/kwzyb0P X-Google-Smtp-Source: ABdhPJzEIqBHBUficQTMd9UT6OFUYmUbPDI80RXeTMO+luj49Ka7mazqGW0rAAejqvTOF0hSdJtm1Q== X-Received: by 2002:a05:620a:f02:: with SMTP id v2mr13629720qkl.65.1639685648208; Thu, 16 Dec 2021 12:14:08 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id 14sm5102370qtx.84.2021.12.16.12.14.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 12:14:07 -0800 (PST) Content-Type: multipart/alternative; boundary="------------maJgVCIYVHvC0AyPf5FuiQfB" Message-ID: <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> Date: Thu, 16 Dec 2021 15:14:06 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eric Rescorla Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:14:28 -0000 This is a multi-part message in MIME format. --------------maJgVCIYVHvC0AyPf5FuiQfB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/16/2021 3:01 PM, Eric Rescorla wrote: > > > On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns > wrote: > > On 12/15/2021 9:35 PM, Eric Rescorla wrote: >> >> >> >> > So all we’re arguing about here is whether or not the RPC >> always gets a >> > seat at the table, or whether that’s subject to the whims >> of the then >> > current RSAB.  There’s precedence ( e.g. Nomcom) in >> specifying a >> > requirement here rather than deferring to an ever changing >> group of >> > people with their own set of biases. >> >> >> I'm not sure that this precedent cuts the way you seem to >> believe. As I understand >> it, nomcoms have varied quite a bit in the level of participation. >> >> -Ekr > > I'm not sure of the point you're trying to make here. If you're > saying that sometimes some of the organizations permitted liaisons > failed to send them, then sure, but that's the choice of the > sending organization and doesn't undercut what I'm saying and in > fact exactly mirrors what I said about the RPC choosing its > representative or none at all.  If you're saying that a given > Nomcom declined to seat a liaison from an organization that was > allowed one by the current Nomcom procedures RFC - it never > happened AFAICT. > > Or something else?  And exactly how does it undercut what I've said? > > I'm saying that the nomcom sets the terms under which the liaisons > participate, and that in some cases it's a lot and in some cases it's > much less. Which is precisely what I'm advocating for here, rather > than prescribing the manner in which the liaison engages. > > -Ekr > Um.   See https://datatracker.ietf.org/doc/html/rfc8713 section 4.7 which specifies the roles and responsibilities of a Nomcom liaison and those are not subject to constraint by the Nomcom on which they serve. > Liaisons may have other nominating committee responsibilities as > required by their respective organizations or requested by the > nominating committee, except that such responsibilities may not > conflict with any other provisions of this document. It's possible you're referring to the above paragraph, but that's "other duties as assigned" rather than "you can't participate in the discussions".  AFAICT section 4.7 was last updated in 2015 and before that was mostly the same but scattered throughout the document.  The main operative change here was to make the appointment of the ISOC liaison optional in both reality and as written. And there's section 4.3 which has: The Chair, liaisons, and advisors do not vote on the selection of candidates. They do vote on all other issues before the committee unless otherwise specified in this document. So I believe you are incorrect in all aspects here. Mike > > > Later, Mike > > > --------------maJgVCIYVHvC0AyPf5FuiQfB Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/16/2021 3:01 PM, Eric Rescorla wrote:


On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns <msj@nthpermutation.com> wrote:
On 12/15/2021 9:35 PM, Eric Rescorla wrote:



> So all we’re arguing about here is whether or not the RPC always gets a
> seat at the table, or whether that’s subject to the whims of the then
> current RSAB.  There’s precedence ( e.g. Nomcom) in specifying a
> requirement here rather than deferring to an ever changing group of
> people with their own set of biases.


I'm not sure that this precedent cuts the way you seem to believe. As I understand
it, nomcoms have varied quite a bit in the level of participation.

-Ekr

I'm not sure of the point you're trying to make here.   If you're saying that sometimes some of the organizations permitted liaisons failed to send them, then sure, but that's the choice of the sending organization and doesn't undercut what I'm saying and in fact exactly mirrors what I said about the RPC choosing its representative or none at all.  If you're saying that a given Nomcom declined to seat a liaison from an organization that was allowed one by the current Nomcom procedures RFC - it never happened AFAICT.

Or something else?  And exactly how does it undercut what I've said?

I'm saying that the nomcom sets the terms under which the liaisons participate, and that in some cases it's a lot and in some cases it's much less. Which is precisely what I'm advocating for here, rather than prescribing the manner in which the liaison engages.

-Ekr


Um.   See  https://datatracker.ietf.org/doc/html/rfc8713 section 4.7 which specifies the roles and responsibilities of a Nomcom liaison and those are not subject to constraint by the Nomcom on which they serve.

Liaisons may have other nominating committee responsibilities as
   required by their respective organizations or requested by the
   nominating committee, except that such responsibilities may not
   conflict with any other provisions of this document.

It's possible you're referring to the above paragraph, but that's "other duties as assigned" rather than "you can't participate in the discussions".  AFAICT section 4.7 was last updated in 2015 and before that was mostly the same but scattered throughout the document.  The main operative change here was to make the appointment of the ISOC liaison optional in both reality and as written. 

And there's section 4.3 which has:

The Chair, liaisons, and advisors do not vote on the selection of
   candidates.  They do vote on all other issues before the committee
   unless otherwise specified in this document.

So I believe you are incorrect in all aspects here.

Mike




Later, Mike




--------------maJgVCIYVHvC0AyPf5FuiQfB-- From nobody Thu Dec 16 12:24:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 663683A12F5 for ; Thu, 16 Dec 2021 12:24:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 fZIagXgvn7aJ for ; Thu, 16 Dec 2021 12:24:47 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7960E3A12F6 for ; Thu, 16 Dec 2021 12:24:47 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id z18so33409iof.5 for ; Thu, 16 Dec 2021 12:24:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5YW0DA6APSTv8+E+QcLgHHHoUoC6PQnEuuFcnNI2P/A=; b=pg5eOoXWYxYrhT5h3mJKtHmf2p2wtWnmvGSHrujMYToMUl+gbheXm3m114RfkfKold 70m2m5SS9ufv8Y9zNqCjRMl+pTPz2deJacCwKOdskToEnfmCuxt1gZkzul39XtZHY7Ed G2QUwNMmAHy6bxmnyaZltP8F0Ygd+t1euZ9ZvxlzoRmZAwAr0v9tvMKEbz+LHXwvY8w8 IE5Ye7WP77ZOriCKldDeJr6+L5vdg8uzytiTFdRp02Fyzmib4x9hlJDTw0xns6PpAJEg aRTsh1B6OhhTE6vxpKd4Fu7XExTCjHG+tZpQoRP383bmYOMFJhuy2T/3o+M3qYzi8FKE Lysg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5YW0DA6APSTv8+E+QcLgHHHoUoC6PQnEuuFcnNI2P/A=; b=RyzMuegQRXriqjIBrp18pxvr3UkNciO9/XegrXWihYyQ3ramubHf0YXTxb/xk1G7Tr leMdYHaGhesZJPJ+nHz+7RdpuD6bHg8HPapcftlhvKPS4T3Pw5dkxFLIpckduF56wKPk Ju7i0f44H8PFjBPdeqfZF6Hy+F3GROi+dN8W6sHFc/8rY4UOr12BA/1b94Zq1kWdw/Ws 0L0s9s8lP9mjm9gPjG7zxircJJsm0EZJjYtzM+sLd3Vc70N92+CZzHRIYdntzFmZaFTD hRq2cDiMuHKJh8bXovWSsXJJqTPw/5lVKb2KJEX2RKc7wUUhEAhRfK28l2yzIf+dXrTj RfrA== X-Gm-Message-State: AOAM532GhZmEkHygV3yQJIyfHhbZ7bHl8qchFwRtL5b1Wl4uDHnESzew M7L01yp2Cf0ocnQU2uM+P2q4FD56KEozVbguefqUzpWTp8mo9g== X-Google-Smtp-Source: ABdhPJzSw5GJtv0Kg+RSFHfPGAPNe874Y5dz6QPDf5dDrTmTe9k1KPK+T/P+4Wdq6a+TcX6yDmnc04WgmnvMj0bOyO0= X-Received: by 2002:a05:6602:3409:: with SMTP id n9mr10491338ioz.148.1639686285338; Thu, 16 Dec 2021 12:24:45 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> In-Reply-To: <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> From: Eric Rescorla Date: Thu, 16 Dec 2021 12:24:09 -0800 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000094c60e05d349360d" Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:24:53 -0000 --00000000000094c60e05d349360d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 16, 2021 at 12:14 PM Michael StJohns wrote: > On 12/16/2021 3:01 PM, Eric Rescorla wrote: > > > > On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns > wrote: > >> On 12/15/2021 9:35 PM, Eric Rescorla wrote: >> >> >> >> >> > So all we=E2=80=99re arguing about here is whether or not the RPC alwa= ys gets a >>> > seat at the table, or whether that=E2=80=99s subject to the whims of = the then >>> > current RSAB. There=E2=80=99s precedence ( e.g. Nomcom) in specifyin= g a >>> > requirement here rather than deferring to an ever changing group of >>> > people with their own set of biases. >>> >>> >> I'm not sure that this precedent cuts the way you seem to believe. As I >> understand >> it, nomcoms have varied quite a bit in the level of participation. >> >> -Ekr >> >> I'm not sure of the point you're trying to make here. If you're saying >> that sometimes some of the organizations permitted liaisons failed to se= nd >> them, then sure, but that's the choice of the sending organization and >> doesn't undercut what I'm saying and in fact exactly mirrors what I said >> about the RPC choosing its representative or none at all. If you're say= ing >> that a given Nomcom declined to seat a liaison from an organization that >> was allowed one by the current Nomcom procedures RFC - it never happened >> AFAICT. >> >> Or something else? And exactly how does it undercut what I've said? >> > I'm saying that the nomcom sets the terms under which the liaisons > participate, and that in some cases it's a lot and in some cases it's muc= h > less. Which is precisely what I'm advocating for here, rather than > prescribing the manner in which the liaison engages. > > -Ekr > > > Um. See https://datatracker.ietf.org/doc/html/rfc8713 section 4.7 > which specifies the roles and responsibilities of a Nomcom liaison and > those are not subject to constraint by the Nomcom on which they serve. > > Liaisons may have other nominating committee responsibilities as > required by their respective organizations or requested by the > nominating committee, except that such responsibilities may not > conflict with any other provisions of this document. > > It's possible you're referring to the above paragraph, but that's "other > duties as assigned" rather than "you can't participate in the > discussions". AFAICT section 4.7 was last updated in 2015 and before tha= t > was mostly the same but scattered throughout the document. The main > operative change here was to make the appointment of the ISOC liaison > optional in both reality and as written. > I don't see anything here that says that the liaisons are allowed to participate fully in the discussion. Do you have some more on point text? > And there's section 4.3 which has: > > The Chair, liaisons, and advisors do not vote on the selection of > candidates. They do vote on all other issues before the committee > unless otherwise specified in this document. > > Voting on all other issues is not the same as participating fully in the discussion. -Ekr > Mike > > > > > Later, Mike >> >> >> >> > --00000000000094c60e05d349360d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 16, 2021 at 12:14 PM Mich= ael StJohns <msj@nthpermutatio= n.com> wrote:
=20 =20 =20
On 12/16/2021 3:01 PM, Eric Rescorla wrote:
=20


On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns <msj@nthpermutation.com> wrote:
On 12/15/2021 9:35 PM, Eric Rescorla wrote:



> So all we=E2=80=99re arguing about here = is whether or not the RPC always gets a
> seat at the table, or whether that=E2=80=99s subject to the whims of the then
> current RSAB.=C2=A0 There=E2=80=99s preceden= ce ( e.g. Nomcom) in specifying a
> requirement here rather than deferring to an ever changing group of
> people with their own set of biases.


I'm not sure that this precedent cuts the way you seem to believe. As I understand
it, nomcoms have varied quite a bit in the level of participation.

-Ekr

I'm not sure of the point you're trying to make he= re.=C2=A0=C2=A0 If you're saying that sometimes some of the organizations permitted liaisons failed to send them, then sure, but that's the choice of the sending organization and doesn't undercut what I'm saying a= nd in fact exactly mirrors what I said about the RPC choosing its representative or none at all.=C2=A0 If you're sayi= ng that a given Nomcom declined to seat a liaison from an organization that was allowed one by the current Nomcom procedures RFC - it never happened AFAICT.

Or something else?=C2=A0 And exactly how does it undercut what I've said?

I'm saying that the nomcom sets the terms under which th= e liaisons participate, and that in some cases it's a lot and in some cases it's much less. Which is precisely what I'= ;m advocating for here, rather than prescribing the manner in which the liaison engages.

-Ekr


Um.=C2=A0=C2=A0 See=C2=A0 https://datatracker.ietf.org/doc/html/rfc= 8713 section 4.7 which specifies the roles and responsibilities of a Nomcom liaison and those are not subject to constraint by the Nomcom on which they serve.

Liaisons may have other nominating committee responsibilities =
as
   required by their respective organizations or requested by the
   nominating committee, except that such responsibilities may not
   conflict with any other provisions of this document.

It's possible you're referring to the above paragraph, but t= hat's "other duties as assigned" rather than "you can't = participate in the discussions".=C2=A0 AFAICT section 4.7 was last updated in 2= 015 and before that was mostly the same but scattered throughout the document.=C2=A0 The main operative change here was to make the appointment of the ISOC liaison optional in both reality and as written.=C2=A0


I don&#= 39;t see anything here that says that the liaisons are allowed to participa= te fully in the discussion. Do you have some more on point text?
<= div>=C2=A0
=

And there's section 4.3 which has:

The Chair, liaisons, and advisors do not vote on the selection of
   candidates.  They do vote on all other issues before the committee
   unless otherwise specified in this document.
=C2=A0
Voting on all other issues is not the same as parti= cipating fully in the discussion.
=C2=A0

-Ekr=

=C2=A0

Mike




Later, Mike




--00000000000094c60e05d349360d-- From nobody Thu Dec 16 12:30:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12FA33A1332 for ; Thu, 16 Dec 2021 12:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CjlVIPmOrvz for ; Thu, 16 Dec 2021 12:30:42 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F2A23A1330 for ; Thu, 16 Dec 2021 12:30:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id D45864901112; Thu, 16 Dec 2021 12:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZsCMJszdYYE; Thu, 16 Dec 2021 12:30:41 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id CAC2441274D0; Thu, 16 Dec 2021 12:30:40 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) From: Jay Daley In-Reply-To: Date: Fri, 17 Dec 2021 09:30:37 +1300 Cc: Eliot Lear , John C Klensin , Peter Saint-Andre , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> To: Michael StJohns X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:30:46 -0000 > On 17/12/2021, at 8:50 AM, Michael StJohns = wrote: >=20 > Top posting because. >=20 > Eliot - Generally the role of the chair is to elicit both points and = rationales and engender a discussion, not to pick one point as the true = answer and require the other side to attack it. >=20 > In this case, I think there's substantial commentary on why the RPC = should have a seat at the table. And little commentary on not beside = "let the RSAB decide". >=20 > For your points below: >=20 > 1) If the RSWG is proposing something that will impact the RPC's work, = work flow, LOE, costs, SLA etc, having the RPC be able to explain = exactly what will need to change to support the proposal, and explaining = what could be moved around to make things work seems to be a useful = input into whether the RSAB approves a document or returns it with = comments to the RSWG. Given that pretty much any document that = describes functional albeit strategic changes will involve the RPC and = that I would be surprised if there are many non-functional (changes not = affecting function) proposed by the RSWG, it just makes sense that the = RPC be included. Filtering all that through the ED is not a) scalable = (how much more gets piled on to Jay or his successor?), b) efficient = (e.g. a pre-meeting with the ED and the RPC to prepare the ED for the = RSAB meeting), c) error-free (think the game of "Telephone"). In fact = having both the ED and the RPC there may mean that small tweaks can be = approved quickly as both sides of the contract would be represented. The ED cannot represent the RPC on the RSAB, act an intermediary or = otherwise replace direct contact between the RPC and the RSAB. >=20 > 2) This one seems obvious - the RPC brings things to the RSAB for = discussion. Having a seat at the table to add things to the agenda vs = being summoned at the whim of the RSAB - the equities argue for the = former. I actually expect that most meetings (based on the RSOC's = minutes) will involve RPC discussions of some sort under this heading. >=20 > 3) I need to get back to your other email on this point, but I'm = becoming more and more convinced that the RSAB as a group should not be = holding executive sessions for any reason. The problem with that is the "RSCE Performance Evaluation" [1]. If you = recall, we had a long conversation about this process requiring both = community input and community review of the ED=E2=80=99s = recommendations. > This task for the RSAB only really makes sense if all of the RSAB = members excluding the RSCE were from their appointing organizations and = were long-lived in the job - and neither of these appear to be = guaranteed to be true. In any event the presence of this task neither = argues for or against non-voting ex-officio members. >=20 > 4) The ED doesn't have a role in the appeals process, but is still = included as ex-officio so the presence of this task neither argues for = or against having the RPC having an ex-officio member. It's possible = that both the ED and the RPC might have useful input into a given appeal = which might be missed if either is excluded from the discussions. >=20 > I look forward to the opponents of the RPC being ex-officio providing = related commentary - e.g. a) why should a random membership of the RSAB = decide whether the RPC relationship is ex-officio or something else? b) = how often should they decide this (e.g. everytime a member changes out? = each meeting? each year? never?), c) what is the difference between an = ex-officio member and one that gets invited to every meeting (e.g. is = the difference that the RPC by rule sits mute until asked about = something? Should that rule apply to the ED as well? If not, why not?) I=E2=80=99m not against the RPC being an ex-officio member, but I do = think that if that is to be part of the model then the model should = address any conflicts of interest from that ex-officio role. I got the = impression that John and Peter were close to text on that. I don=E2=80=99= t btw see any similar conflicts of interest with the ED despite John=E2=80= =99s attempt to construct one. Jay [1] = https://www.ietf.org/archive/id/draft-iab-rfcefdp-rfced-model-07.html#sect= ion-5.2-1 >=20 > Mike >=20 >=20 >=20 >=20 > On 12/16/2021 3:15 AM, Eliot Lear wrote: >> I think people are misunderstanding the nature of the RSAB and the = very model we are creating. >>=20 >> The RSAB has precisely four jobs: >>=20 >> =E2=80=A2 Approve or disapprove RSWG work, >> =E2=80=A2 Provide guidance to the RPC regarding certain = inter-stream conflicts, >> =E2=80=A2 Provide an opinion regarding feedback on the RSCE to = the LLC, and=20 >> =E2=80=A2 Address certain appeals. >> That's it. >>=20 >> In each case, one should ask what benefit a formal liaison brings, or = what risk the formal liaison mitigates, and what complications a formal = liaison brings. >> It's important to note that disputes and appeals are expected to be = corner cases. We should be careful about how we legislate them. = Principally, the work that needs to get done on policy development is = meant to happen in the RSWG. That is where the focus of interaction = should be. >>=20 >> So. I will ask advocates of an RPC liaison role to state clearly = what risk they are intending to mitigate. =20 >>=20 >> A risk that we cannot mitigate are any limitations the ED or LLC may = place on participation as a matter of LLC policy or contract. Please = don't argue that point here since there's nothing this group can or = should do about that (any issues with that need to be brought to the = LLC). >>=20 >> Eliot >>=20 >> On 16.12.21 04:20, John C Klensin wrote: >>> Independent of what it is called, I think the RPC needs to have >>> a seat at the RSAB table and have it as part of the model. That >>> seat should not be discretionary. I suspect that a mechanism >>> will be needed to allow some or all of the RSAB members to >>> decide the RPC should be locked out of a discussion, but the >>> mechanism should be constrained and the information that is >>> being done and the reasons should be public. >>>=20 >>> In particular, I am not talking about (and don't believe Mike, >>> Mirja, or others are talking about) a role that "needs to be >>> accepted by the group to which the liaison is named, in this >>> case the RSAB" for the RPC any more than I think that definition >>> would be appropriate for the LLC ED. >>>=20 >>> Probably "liaison" is, as you, Mike, and others have sort of >>> suggested, the wrong term for what is intended by this. If I >>> correctly understand what at least some of us have intended, >>> "ex-officio" would be closer to the usual usage for both the LLC >>> ED and RPC representations. Apparently that term has not been >>> used in the document so might be used (with "non-voting" if >>> appropriate) for these two positions, thereby distinguishing >>> them from "liaisons" who the RSAB would need to invite and/or >>> accept. >>>=20 >>> And that brings me to... >>>=20 >>> --On Thursday, December 16, 2021 08:20 +1300 Jay Daley >>>=20 >>> >>> wrote: >>>=20 >>>=20 >>>> ... >>>> When it comes to the RPC being a liaison to RSAB, then the >>>> situation is much more complex than it is for the ED. In >>>> particular the RSAB needs to reconcile the following: >>>>=20 >>>> - how to manage the RPC input/engagement when discussing the >>>> priorities and performance of the RPC >>>> - how to manage responding to RPC requests for advice >>>> - how to manage any conflicting advice from the RSCE=20 >>>> and the RPC >>>>=20 >>>> None of these are insurmountable, but I would hope that any >>>> proposal for the RPC being a mandatory liaison addresses those >>>> issues as not doing that puts the RSAB on a difficult footing >>>> from the start. >>>>=20 >>> Agreed. But I don't think that any of the above are hard. I >>> still believe that the model we are specifying will work to >>> produce the RFC Series we want only if things can proceed >>> collegially, with people having open discussions, sharing >>> perspectives and opinions openly. If the RSAB needs to go into >>> some type of executive session to make certain decisions with >>> some or all the ex-officio members (and/or liaisons) excluded, >>> then so be it, but I would hope that: >>>=20 >>> -- The RPC would participate in discussions about their >>> priorities and performance. If needed, that would be far more >>> likely to result in incremental adjustments or corrections >>> rather than discussions about the detailed provisions of >>> contracts or something needing to assert authority. >>> -- The RPC should be present for discussions about their >>> requests for advice. Perhaps they would have nothing to say, >>> but that is not an issue. If the requests or associated issues >>> are not correctly interpreted, then having them present to >>> clarify would save time and improve results. Maybe I'm missing >>> something, but I can see no scenario in which excluding them >>> from such discussions would make the quality of RSAB decisions, >>> the Series, or the Internet better. >>> -- If the RPC and RSCE have conflicting advice, I believe that >>> having them discuss their different advice and perspectives with >>> each other and with the RSAB would be in the best interests of >>> all concerned. Certainly, I'd hope nothing would bar them from >>> having private discussions to clarify (even if not resolve) >>> conflicting positions. That would almost certainly be in >>> everyone's interest, but I see no reason for the document to >>> need to say that unless there are provisions that someone could >>> interpret as getting in the way (I haven't found any). >>>=20 >>> Where I (very slightly) might disagree with Jay is that I don't >>> see that situation as being much more complex than the one with >>> the ED. For example, if the ED has advice about funding limits >>> or the LLC Board were to ask the RSAB (either as a separate >>> entity or as part of a more general query to the community) for >>> an evaluation of the performance of the ED, the same issues >>> would arise. I'd hope the RSAB would be able to turn such >>> advice or requests into discussions of tradeoffs or of strengths >>> and weaknesses. If a final decision required an executive >>> session with the ED excluded, so be it. So no so different from >>> the above. >>>=20 >>> best, >>> john >>>=20 >>> =20 >>>=20 >>>=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director exec-director@ietf.org From nobody Thu Dec 16 12:56:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 152DA3A03F3 for ; Thu, 16 Dec 2021 12:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 FmKiqB6cqANC for ; Thu, 16 Dec 2021 12:55:57 -0800 (PST) Received: from mail-qv1-xf35.google.com (mail-qv1-xf35.google.com [IPv6:2607:f8b0:4864:20::f35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484A53A0332 for ; Thu, 16 Dec 2021 12:55:57 -0800 (PST) Received: by mail-qv1-xf35.google.com with SMTP id kk22so528488qvb.0 for ; Thu, 16 Dec 2021 12:55:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=n8671q2Ysdr3srMTzy9Zeev6/Ggm2788k5jcwKid0rU=; b=Heb6IoBroBG7r4OavMwhxQsDENak/gKw6rr8PpU73Yl4zBV1X8aWVv/bXRuAlsb8ny hd9XGYT+nwtDOoQXnT6FMftMtZx4RW1qJSS2SqVZJVaaB7/ykurgRX8GbPRGCCe+Xf1N HJZ9tfSVzi/y7AthOeU1jYmR/5OtDkofSjSJ47Z4d7uQf9Z2JAnXrJZ3CcixRY/Rcbsx LFa4li0JF5GhRo9cv8h7UWcLKZ1B6e/FfoZu82RLXSZsJb3nlNzJWNG+xst2UdPJbcqs K3odZ07VPPFbIJJwM6sTvexTHYjWNg4WosR0DldwrvGUGRbRpc/r5TxGlt6aRGL2A9g8 2bxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=n8671q2Ysdr3srMTzy9Zeev6/Ggm2788k5jcwKid0rU=; b=uU2GssXYkmLLjrt3vxAp5oB1X/CDxL4ZiLe+lOLiSX+rjkT2elmQKEq++SiAaNh91x vxcLipkbHGKsgSrYnMNS/90LuKU8JBMEaiB8zUAVNUSsCkfG83skY88qB4K7ffkncynE 4YtGRRyzEKUi96udKqWlviGSb8Ep6n4tfWsRKZNtDXZmCeo0OqM9fDnaJGRfqTiIBIUv 5vB0JCn1AIz/zxDJt1TebgelD5HJqqInpopbxtzxHAmYgAwP0m+B+7phUK/gNeiIwNKx 0739PNvcd7U/3a0e3yovd298uf5jmSyQeTQ45f+scDk9x2SsLATrsIIAcOuHtK2Ltwzx /gKw== X-Gm-Message-State: AOAM531Nk9l43QBhcvpKUFPwQZA/YczJz2xE4+iTHFZQERRgJbp4BUrE gDC2kdV6HokcVrNViG1yc+7W4qZ4qXNp+eEe X-Google-Smtp-Source: ABdhPJzvMZQx6XjAw0//21736nOH+5vZ0lc3yef+MoXJeverQ41+URRXjoIkUqw4lPX19UwdYCF6Mw== X-Received: by 2002:ad4:5f06:: with SMTP id fo6mr17692045qvb.91.1639688154633; Thu, 16 Dec 2021 12:55:54 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id x1sm4904689qtj.9.2021.12.16.12.55.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 12:55:53 -0800 (PST) Content-Type: multipart/alternative; boundary="------------oRWVbxmfG4BcxR0GDDGSB4Qk" Message-ID: <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> Date: Thu, 16 Dec 2021 15:55:51 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Jay Daley Cc: Eliot Lear , John C Klensin , Peter Saint-Andre , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> From: Michael StJohns In-Reply-To: <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:55:59 -0000 This is a multi-part message in MIME format. --------------oRWVbxmfG4BcxR0GDDGSB4Qk Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/16/2021 3:30 PM, Jay Daley wrote: >> 3) I need to get back to your other email on this point, but I'm becoming more and more convinced that the RSAB as a group should not be holding executive sessions for any reason. > The problem with that is the "RSCE Performance Evaluation" [1]. If you recall, we had a long conversation about this process requiring both community input and community review of the ED’s recommendations. > >> This task for the RSAB only really makes sense if all of the RSAB members excluding the RSCE were from their appointing organizations and were long-lived in the job - and neither of these appear to be guaranteed to be true. In any event the presence of this task neither argues for or against non-voting ex-officio members. Hi Jay - As I noted in another, the discussion on [1]  happened at a time where I understood the RSAB to be composed of long-term (e.g. 2 years) delegates FROM the IESG, IAB and IRTF for those slots NOT appointees from the general population by those organizations to the RSAB who could be swapped out by whim at random intervals including right before the review process.  It's possible I'm confused about the result of that discussion, but I see nothing in the current document that requires the organizations to actually send members to the RSAB. Under the model I believed we were originally working under, having the RSAB review an RSCE evaluation made some sense - not a lot, but some -  as they could bring the views of the members of the organizations to which they belonged to the review of the RSCE performance.  That is not guaranteed for the newer model and thus makes evaluation of the RSCE by the RSAB no better than an evaluation/personal opinion by a random selection of people working with the RFC system. Personally, I think you'd be better off creating an adhoc group as necessary from the IESG/IAB/IRTF/ISE to  do your review with the understanding they bring forward the views of their organizations - feel free to select members of the RSAB if they meet that criteria at the time you need to do the review. Looking at the bidding, I'm no longer sure why this is included here or needs to be specified here as it's a contract issue and the LLC Board is/will be responsible for the performance review process. Mike --------------oRWVbxmfG4BcxR0GDDGSB4Qk Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/16/2021 3:30 PM, Jay Daley wrote:
3) I need to get back to your other email on this point, but I'm becoming more and more convinced that the RSAB as a group should not be holding executive sessions for any reason.

The problem with that is the "RSCE Performance Evaluation" [1].  If you recall, we had a long conversation about this process requiring both community input and community review of the ED’s recommendations.


  This task for the RSAB only really makes sense if all of the RSAB members excluding the RSCE were from their appointing organizations and were long-lived in the job - and neither of these appear to be guaranteed to be true.  In any event the presence of this task neither argues for or against non-voting ex-officio members.

Hi Jay -

As I noted in another, the discussion on [1]  happened at a time where I understood the RSAB to be composed of long-term (e.g. 2 years) delegates FROM the IESG, IAB and IRTF for those slots NOT appointees from the general population by those organizations to the RSAB who could be swapped out by whim at random intervals including right before the review process.  It's possible I'm confused about the result of that discussion, but I see nothing in the current document that requires the organizations to actually send members to the RSAB.

Under the model I believed we were originally working under, having the RSAB review an RSCE evaluation made some sense - not a lot, but some -  as they could bring the views of the members of the organizations to which they belonged to the review of the RSCE performance.  That is not guaranteed for the newer model and thus makes evaluation of the RSCE by the RSAB no better than an evaluation/personal opinion by a random selection of people working with the RFC system.

Personally, I think you'd be better off creating an adhoc group as necessary from the IESG/IAB/IRTF/ISE to  do your review with the understanding they bring forward the views of their organizations - feel free to select members of the RSAB if they meet that criteria at the time you need to do the review.   Looking at the bidding, I'm no longer sure why this is included here or needs to be specified here as it's a contract issue and the LLC Board is/will be responsible for the performance review process.

Mike


--------------oRWVbxmfG4BcxR0GDDGSB4Qk-- From nobody Thu Dec 16 13:06:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 000F73A0780; Thu, 16 Dec 2021 13:06:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJM9tYoXP0NS; Thu, 16 Dec 2021 13:06:00 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 557553A077D; Thu, 16 Dec 2021 13:06:00 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BGL5qxX172599 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 16 Dec 2021 22:05:53 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639688753; bh=JI+A6mqZHz4Efd/+FMV9OMy2fzoNaJfMC3pP2mXtKRI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=lGrZxYPjQrE13VhAg3+pFZp0WbxXeXVuH2H7B6zPUTbPS7wL/CLPJdsV37MCoU/PJ xJhXRxrM5YGCFkYVd0ESLXLoyX4XrlFUqm4dgJ9qs6+uBWBBYKsOtuRLlsvaI4XbFd d2+31X5VJYXEiHpq4eeDFxCqRdXc/5BaISq9RIh0= Message-ID: <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> Date: Thu, 16 Dec 2021 22:05:49 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Michael StJohns , Jay Daley Cc: John C Klensin , Peter Saint-Andre , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> From: Eliot Lear In-Reply-To: <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------g3RKe8ZmN6ca8Xj6aW9YYrtF" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:06:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------g3RKe8ZmN6ca8Xj6aW9YYrtF Content-Type: multipart/mixed; boundary="------------lqZ2BjEDXgpxAOJfPKZLmUJs"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , Jay Daley Cc: John C Klensin , Peter Saint-Andre , rfced-future@iab.org Message-ID: <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> Subject: Re: [Rfced-future] RPC liaison to the RSAB References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> In-Reply-To: <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> --------------lqZ2BjEDXgpxAOJfPKZLmUJs Content-Type: multipart/mixed; boundary="------------fF2MGeSGH2X5gbGSuJ70H0pZ" --------------fF2MGeSGH2X5gbGSuJ70H0pZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TWlrZSB3ZSB3aWxsIG5vdCByZWxpdGlnYXRlIGNoYW5nZXMgcmVnYXJkaW5nIFJTQ0UgZmVl ZGJhY2suIFRoYXQgbWF0dGVyIA0KaXMgc2V0dGxlZCBhbmQgY2xvc2VkIHdpdGggY29uc2Vu c3VzIG9mIHRoaXMgZ3JvdXAuDQoNCkVsaW90DQoNCg0K --------------fF2MGeSGH2X5gbGSuJ70H0pZ Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------fF2MGeSGH2X5gbGSuJ70H0pZ-- --------------lqZ2BjEDXgpxAOJfPKZLmUJs-- --------------g3RKe8ZmN6ca8Xj6aW9YYrtF Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG7qi4FAwAAAAAACgkQh7ZrRtnSejOI nwgA0YEWq6izkrpE51gu0eqUfC9BXQCHzzWy1Xng204KT2Dp7sTjcK9YVwGBb0DpEFJSYlCxGNb8 hP9dM42DIc6t/+Zn0Kt+uZ8PPPQND5GxwgFKwQSbn17lBaIO7cRw/Z2dUqrdmdhMQubX7DejJDtJ LlJPAZJWgKpcBQ8uVGuKrevILCoiVQrkyK5sVWiaLsGBG8U/CqQEhiK9PgYZMwoAGUattGgfcsL7 XWWFZS6b2KDEp/YAwSZ1sE/gK81LYA+ZnWLsVzGYK8Q6BB3DuOnuLG/H/vihqsppEGyrsfhST4az xgSgOn5CHilp9YexaoiiF0/gOrrUErLpmtu3b7wA1g== =0xwH -----END PGP SIGNATURE----- --------------g3RKe8ZmN6ca8Xj6aW9YYrtF-- From nobody Thu Dec 16 13:06:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E633A076F for ; Thu, 16 Dec 2021 13:06:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 cmdW2c7HPn10 for ; Thu, 16 Dec 2021 13:06:25 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A95DD3A077D for ; Thu, 16 Dec 2021 13:06:25 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id m25so538607qtq.13 for ; Thu, 16 Dec 2021 13:06:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=wS8WOSCWIyJytTbxBwO41JGTt7oTpQMp2jdrBTje2pM=; b=LZdszQ9Jan6IUvPE9kL9O1YzZUBqAzKnh2OXBvgMy8IdtKSVuzuyt8MMiFCszkkA1/ DrichadsU0nKjeHCP5i8eMWbXJej5PA975JFDctF4uj5ux1l1woYQzOtjB9MioFeiYs0 S3itWW3IyMyVYJykf0cYKBnOiRFXnCydE95jnVVwPt0JIEcoa9KeG4vGN4jWxldk6xYx 6COLSaaLTcSBaRQ4oryMMt/J+27e73dddzuNUtCxTfZZ4MLDwpDSFJoPw53wK5eF1d55 66zkEQT5bL0lEObnia7lDk4tQ0mjeP46SDNaALtACVd/4zGlU/Duk9QfiRWiW9nyTkJn Gkyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=wS8WOSCWIyJytTbxBwO41JGTt7oTpQMp2jdrBTje2pM=; b=xYu2W2Uwp/42YN9DGnf+RrXQrJ+BQvoQtReJ3fsVDBZv1NYfAx57TCCH+71lucfmFi HUqUkzfi8opZcHAxCKhWGKD9gXvgT6lT9l9DFazaqfzS+LzFkY7Zuc41hegeCF8IL4qB ajYC7On7gP6h3v4IJFYQ5BAq8t+Hk1VnO0w3x8l3JksoATCC5Kz1OaHuUEMDmzsbe/K8 Lkddd6KbbXZf4X5L0vF04Tp8TY+tSBRvUhs8cF5bnQFRqjY89e9d/6JWAysjrQXIlo64 K3GgHDa23Zw1dA4J22MJ/R/ssyHxyRtrxXd9vauZpA1y3ro+X6ZZKEozQ6pg3MKME4hv DeMg== X-Gm-Message-State: AOAM5325t3VwlsgV7vnxiPINvXZuS5WTF5gIeUQYvJqx1i0BerhYvwZJ VvOJpAUQ0d3RWxt6Olh0ICXCMBH9UXA7Gznb X-Google-Smtp-Source: ABdhPJzOg4gzmjnDJGj730P1VcT4lbU0gtUAxDMCvqkvNQk5JWOkGyib8P+4id7YWzJyb/ZsZJ7g1g== X-Received: by 2002:ac8:5743:: with SMTP id 3mr18717818qtx.277.1639688781575; Thu, 16 Dec 2021 13:06:21 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id r16sm5061442qta.46.2021.12.16.13.06.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 13:06:20 -0800 (PST) Content-Type: multipart/alternative; boundary="------------k984L5ojIQK63HCUcWp3uiXP" Message-ID: <5e2b5b72-26ab-f5fe-a6ec-badc8721fdd0@nthpermutation.com> Date: Thu, 16 Dec 2021 16:06:19 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eric Rescorla Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:06:31 -0000 This is a multi-part message in MIME format. --------------k984L5ojIQK63HCUcWp3uiXP Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/16/2021 3:24 PM, Eric Rescorla wrote: > > > On Thu, Dec 16, 2021 at 12:14 PM Michael StJohns > wrote: > > On 12/16/2021 3:01 PM, Eric Rescorla wrote: >> >> >> On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns >> wrote: >> >> On 12/15/2021 9:35 PM, Eric Rescorla wrote: >>> >>> >>> >>> > So all we’re arguing about here is whether or not the >>> RPC always gets a >>> > seat at the table, or whether that’s subject to the >>> whims of the then >>> > current RSAB.  There’s precedence ( e.g. Nomcom) in >>> specifying a >>> > requirement here rather than deferring to an ever >>> changing group of >>> > people with their own set of biases. >>> >>> >>> I'm not sure that this precedent cuts the way you seem to >>> believe. As I understand >>> it, nomcoms have varied quite a bit in the level of >>> participation. >>> >>> -Ekr >> >> I'm not sure of the point you're trying to make here.   If >> you're saying that sometimes some of the organizations >> permitted liaisons failed to send them, then sure, but that's >> the choice of the sending organization and doesn't undercut >> what I'm saying and in fact exactly mirrors what I said about >> the RPC choosing its representative or none at all.  If >> you're saying that a given Nomcom declined to seat a liaison >> from an organization that was allowed one by the current >> Nomcom procedures RFC - it never happened AFAICT. >> >> Or something else?  And exactly how does it undercut what >> I've said? >> >> I'm saying that the nomcom sets the terms under which the >> liaisons participate, and that in some cases it's a lot and in >> some cases it's much less. Which is precisely what I'm advocating >> for here, rather than prescribing the manner in which the liaison >> engages. >> >> -Ekr >> > > Um.   See https://datatracker.ietf.org/doc/html/rfc8713 section > 4.7 which specifies the roles and responsibilities of a Nomcom > liaison and those are not subject to constraint by the Nomcom on > which they serve. > >> Liaisons may have other nominating committee responsibilities as >> required by their respective organizations or requested by the >> nominating committee, except that such responsibilities may not >> conflict with any other provisions of this document. > > It's possible you're referring to the above paragraph, but that's > "other duties as assigned" rather than "you can't participate in > the discussions".  AFAICT section 4.7 was last updated in 2015 and > before that was mostly the same but scattered throughout the > document.  The main operative change here was to make the > appointment of the ISOC liaison optional in both reality and as > written. > > > I don't see anything here that says that the liaisons are allowed to > participate fully in the discussion. Do you have some more on point text? Section 5.9: > Deliberations > > All members of the NomCom may participate in all deliberations. > > The emphasis of this rule is that no member can be explicitly > excluded from any deliberation. However, a member may individually > choose not to participate in a deliberation. which IMHO is definitive. AFAICT, the only way the liaisons would not be allowed to fully participate - if they wanted to - is if the whole nomcom including the liaisons and advisors voted to restrict them in some manner. Sure that could happen legally, but that would require a majority vote of all of the participants, not just a majority vote of the voting members.  If everyone who can appoints a liaison, that's a total membership of 10 + 2 (chair and past chair) + 5 liaisons => 17.  Which means 9 people would have to vote for the restriction for it to pass. > > And there's section 4.3 which has: > > The Chair, liaisons, and advisors do not vote on the selection of > candidates. They do vote on all other issues before the committee > unless otherwise specified in this document. > > Voting on all other issues is not the same as participating fully in > the discussion. Never said it was - but never thought you'd think that voting on something without participating in the discussion was a thing. Any other arguments on this point? Later, Mike > > -Ekr > > Mike > > >> >> >> Later, Mike >> >> >> > --------------k984L5ojIQK63HCUcWp3uiXP Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/16/2021 3:24 PM, Eric Rescorla wrote:


On Thu, Dec 16, 2021 at 12:14 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 12/16/2021 3:01 PM, Eric Rescorla wrote:


On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns <msj@nthpermutation.com> wrote:
On 12/15/2021 9:35 PM, Eric Rescorla wrote:



> So all we’re arguing about here is whether or not the RPC always gets a
> seat at the table, or whether that’s subject to the whims of the then
> current RSAB.  There’s precedence ( e.g. Nomcom) in specifying a
> requirement here rather than deferring to an ever changing group of
> people with their own set of biases.


I'm not sure that this precedent cuts the way you seem to believe. As I understand
it, nomcoms have varied quite a bit in the level of participation.

-Ekr

I'm not sure of the point you're trying to make here.   If you're saying that sometimes some of the organizations permitted liaisons failed to send them, then sure, but that's the choice of the sending organization and doesn't undercut what I'm saying and in fact exactly mirrors what I said about the RPC choosing its representative or none at all.  If you're saying that a given Nomcom declined to seat a liaison from an organization that was allowed one by the current Nomcom procedures RFC - it never happened AFAICT.

Or something else?  And exactly how does it undercut what I've said?

I'm saying that the nomcom sets the terms under which the liaisons participate, and that in some cases it's a lot and in some cases it's much less. Which is precisely what I'm advocating for here, rather than prescribing the manner in which the liaison engages.

-Ekr


Um.   See  https://datatracker.ietf.org/doc/html/rfc8713 section 4.7 which specifies the roles and responsibilities of a Nomcom liaison and those are not subject to constraint by the Nomcom on which they serve.

Liaisons may have other nominating committee responsibilities as
   required by their respective organizations or requested by the
   nominating committee, except that such responsibilities may not
   conflict with any other provisions of this document.

It's possible you're referring to the above paragraph, but that's "other duties as assigned" rather than "you can't participate in the discussions".  AFAICT section 4.7 was last updated in 2015 and before that was mostly the same but scattered throughout the document.  The main operative change here was to make the appointment of the ISOC liaison optional in both reality and as written. 


I don't see anything here that says that the liaisons are allowed to participate fully in the discussion. Do you have some more on point text?


Section 5.9:

 Deliberations

   All members of the NomCom may participate in all deliberations.

   The emphasis of this rule is that no member can be explicitly
   excluded from any deliberation.  However, a member may individually
   choose not to participate in a deliberation.
which IMHO is definitive.

AFAICT, the only way the liaisons would not be allowed to fully participate - if they wanted to - is if the whole nomcom including the liaisons and advisors voted to restrict them in some manner.  Sure that could happen legally, but that would require a majority vote of all of the participants, not just a majority vote of the voting members.  If everyone who can appoints a liaison, that's a total membership of 10 + 2 (chair and past chair) + 5 liaisons => 17.  Which means 9 people would have to vote for the restriction for it to pass.

 

And there's section 4.3 which has:

The Chair, liaisons, and advisors do not vote on the selection of
   candidates.  They do vote on all other issues before the committee
   unless otherwise specified in this document.
 
Voting on all other issues is not the same as participating fully in the discussion.

Never said it was - but never thought you'd think that voting on something without participating in the discussion was a thing.

Any other arguments on this point?

Later, Mike


 

-Ekr

 

Mike




Later, Mike





--------------k984L5ojIQK63HCUcWp3uiXP-- From nobody Thu Dec 16 13:14:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D6B93A081B for ; Thu, 16 Dec 2021 13:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20210112.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 vkzvHqA1msp7 for ; Thu, 16 Dec 2021 13:14:04 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 890193A0812 for ; Thu, 16 Dec 2021 13:14:04 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id m25so559252qtq.13 for ; Thu, 16 Dec 2021 13:14:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=+nFKSxD+TJ5qKIn/BiNPGJ9hXD8ucLIIMKPGxRm7MfA=; b=QnW74YVo+VQDfOrrzBevY1HlY5CQMTjA33pgMUAUe8DO8b8NfNjtg1OYBUip1h810h cY+VGsoAcTZuWP7o3T68MlZSEsN1rCl7341t9dj0mUkSiw7NW/ZX/jIX89bjmw8So/BA su0lJQWX20FrAKXYDelQUg+CHgKhKmJk1prfZxx26lPNQAOGzAngqSb1VHP9OmRFoem7 SQGeluRHX8rXDdPDKowqUOBw5a7sc8jhuUbbq2Q6YONpDTps+JebcLECJg0ghdgCg6GO PyqVjHulswCSfmR4Knkh7Q9b5wu1lnNSERJmr5Soafvw0yAkADHEEq4zrOgsnE0FZcuQ QFYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=+nFKSxD+TJ5qKIn/BiNPGJ9hXD8ucLIIMKPGxRm7MfA=; b=yKbU2vvyWgkHTiDXB6icj/0XsPe7vRoqbe0PlFQx+YOhOqD5UO9gkhB6wTQGxHNQgi mtWflQlN+NcgeeG4zi56RadPVFxmwbLcjrQdB42LGwC83nD+AXofiRiiI5A231Sn6KLl 0QELRCm5WXOPZm7IYp5HtAiNwT2yz7af0zUlgJZxLFkhPAXb1hjq6N3/fO2lH4nHIpMf 74mMfivWpZ6+N23PQDaM+VLVK+mw2X4Lthb3psd3isqDlKU0PzkbveVd1RN6B93g/Jyw PZy3vS/vZ9RT0LWj5j20mlcrMpk3wuMSh00yHH8VWoJEhVSgGbTDmcKQoz/SKntTtduq NvuA== X-Gm-Message-State: AOAM530qnxOxW3VNgtzegR5PUzXKzUnzD6xUD1Q6AWlZ76KdQHbwi9My 6U85JIHz8TlvJ3PbULlbCfXt3a55VtRD2lBm X-Google-Smtp-Source: ABdhPJwmkeJwvAKpyNDTRUPzZtsYZE9BaMku/O/N/ImtvJcLj1U149H+14dD5yHdYbJDNfyv84gNBw== X-Received: by 2002:a05:622a:1c7:: with SMTP id t7mr18534557qtw.441.1639689242096; Thu, 16 Dec 2021 13:14:02 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id x4sm5394941qtw.44.2021.12.16.13.14.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 13:14:01 -0800 (PST) Message-ID: Date: Thu, 16 Dec 2021 16:13:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Jay Daley Cc: Eliot Lear , John C Klensin , Peter Saint-Andre , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> From: Michael StJohns In-Reply-To: <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:14:10 -0000 On 12/16/2021 3:30 PM, Jay Daley wrote: > The ED cannot represent the RPC on the RSAB, act an intermediary or otherwise replace direct contact between the RPC and the RSAB. What Jay said! Mike From nobody Thu Dec 16 13:46:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6101A3A09DB for ; Thu, 16 Dec 2021 13:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 PqoYLoQDuxfB for ; Thu, 16 Dec 2021 13:46:39 -0800 (PST) Received: from mail-il1-x12b.google.com (mail-il1-x12b.google.com [IPv6:2607:f8b0:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38A433A09D6 for ; Thu, 16 Dec 2021 13:46:39 -0800 (PST) Received: by mail-il1-x12b.google.com with SMTP id 15so168555ilq.2 for ; Thu, 16 Dec 2021 13:46:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=77DdMttP5JriVs4mlXBXkBXxWEkhwAD3HVvhVNWkiuk=; b=SE0gTShq78EOgnVrghZf6JOd2c/QwNbCR7OaO8kpOOTDkxvdpS2Bomb8/+XyvBp5wX 3yuhTO8xaOJl7QzQpFI85MHDUs/Gido9YUmU6C4DKnkaI1G2Ou2qfWVRoF8XkTEJs+5Y PtCPjOfrPR+pbbqp6BPDC13XcmaaLBZ/LFPjFFth3m5tGuB9whyLVIAt6UnT/KgqXZjq GCQvkD9x43yfO8LcDQ4nYKYncvGa1fuFA+lNKM7zWRPIvDj/ZLTqmUn7K21Cj5lnn7Dk 5NgSbNZWYXdUoaaHi7kiP99TitfI6tYVsDLV383w+OK9fjXPOpa54u66WTZpttOcA3gy qa3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=77DdMttP5JriVs4mlXBXkBXxWEkhwAD3HVvhVNWkiuk=; b=05TJS61JH8eu3wBYtNNQ2sPpib6V17tjsrmOv6zRw5iRX0j97Jntzi2BVQkAVpBl/d zLs2Bz+Y/mUP4oxvOF2McgpZ+/UJbIKr0WaRGFNCsH30L/dlb455GGdOvwPitUb25M30 q2Wrj5EMnvJz7gZBEPyew+vSNmjwqjJOPGssklc13W8x9d2LiwyQLquAVt0syoiDohWK /IFTmTYv4MaRZF+Ycxmz8xaqoFP6eglDpZguml16tzY2eO5+5SLsP8epNqeA8/i2q9iy qCgL5cDnvPC1MBBFv5hYMbVbHgeUhiGBN3wXT52Z/E7xvbOYu/e23HpwoPC1xlkNYmg8 2mSA== X-Gm-Message-State: AOAM533X/5FewH58Xp0VAdQTQw+dD/UotJMGm8yQnarrnHVlIQi1RP3J L6j3oHgOS+hUe5Ycq1ZghtLuya3qn1M5jNlbU05wauZJYck= X-Google-Smtp-Source: ABdhPJzSCQlWxRAdsuO3fQNdvIN+MGFX1eD1w4tP3J70+vxjcIHuRBjebr2a/Jb+srynhYocuDZlVNqN2lQiUa2mxKw= X-Received: by 2002:a05:6e02:1789:: with SMTP id y9mr10151349ilu.276.1639691196903; Thu, 16 Dec 2021 13:46:36 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> <5e2b5b72-26ab-f5fe-a6ec-badc8721fdd0@nthpermutation.com> In-Reply-To: <5e2b5b72-26ab-f5fe-a6ec-badc8721fdd0@nthpermutation.com> From: Eric Rescorla Date: Thu, 16 Dec 2021 13:46:00 -0800 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000055451105d34a5b76" Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:46:45 -0000 --00000000000055451105d34a5b76 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 16, 2021 at 1:06 PM Michael StJohns wrote: > On 12/16/2021 3:24 PM, Eric Rescorla wrote: > > > > On Thu, Dec 16, 2021 at 12:14 PM Michael StJohns > wrote: > >> On 12/16/2021 3:01 PM, Eric Rescorla wrote: >> >> >> >> On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns >> wrote: >> >>> On 12/15/2021 9:35 PM, Eric Rescorla wrote: >>> >>> >>> >>> >>> > So all we=E2=80=99re arguing about here is whether or not the RPC alw= ays gets >>>> a >>>> > seat at the table, or whether that=E2=80=99s subject to the whims of= the then >>>> > current RSAB. There=E2=80=99s precedence ( e.g. Nomcom) in specifyi= ng a >>>> > requirement here rather than deferring to an ever changing group of >>>> > people with their own set of biases. >>>> >>>> >>> I'm not sure that this precedent cuts the way you seem to believe. As I >>> understand >>> it, nomcoms have varied quite a bit in the level of participation. >>> >>> -Ekr >>> >>> I'm not sure of the point you're trying to make here. If you're sayin= g >>> that sometimes some of the organizations permitted liaisons failed to s= end >>> them, then sure, but that's the choice of the sending organization and >>> doesn't undercut what I'm saying and in fact exactly mirrors what I sai= d >>> about the RPC choosing its representative or none at all. If you're sa= ying >>> that a given Nomcom declined to seat a liaison from an organization tha= t >>> was allowed one by the current Nomcom procedures RFC - it never happene= d >>> AFAICT. >>> >>> Or something else? And exactly how does it undercut what I've said? >>> >> I'm saying that the nomcom sets the terms under which the liaisons >> participate, and that in some cases it's a lot and in some cases it's mu= ch >> less. Which is precisely what I'm advocating for here, rather than >> prescribing the manner in which the liaison engages. >> >> -Ekr >> >> >> Um. See https://datatracker.ietf.org/doc/html/rfc8713 section 4.7 >> which specifies the roles and responsibilities of a Nomcom liaison and >> those are not subject to constraint by the Nomcom on which they serve. >> >> Liaisons may have other nominating committee responsibilities as >> required by their respective organizations or requested by the >> nominating committee, except that such responsibilities may not >> conflict with any other provisions of this document. >> >> It's possible you're referring to the above paragraph, but that's "other >> duties as assigned" rather than "you can't participate in the >> discussions". AFAICT section 4.7 was last updated in 2015 and before th= at >> was mostly the same but scattered throughout the document. The main >> operative change here was to make the appointment of the ISOC liaison >> optional in both reality and as written. >> > > I don't see anything here that says that the liaisons are allowed to > participate fully in the discussion. Do you have some more on point text? > > > Section 5.9: > > Deliberations > > All members of the NomCom may participate in all deliberations. > > The emphasis of this rule is that no member can be explicitly > excluded from any deliberation. However, a member may individually > choose not to participate in a deliberation. > > which IMHO is definitive. > Thanks. As I said, I believe that in some nomcoms, this has not been the practice and it is good to have something to point to. Just in the interest of clarity: this does not alter my view that we do not need to require an RPC member (liaison or otherwise) on the RSAB. This is not to say that they should not be able to provide input, but they can do so in the way that others do -- or, if the RSAB asks them to, directly. I do not think that special participation rights not available to the general community should be provided to them in this document. -Ekr --00000000000055451105d34a5b76 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 16, 2021 at 1:06 PM Micha= el StJohns <msj@nthpermutation= .com> wrote:
=20 =20 =20
On 12/16/2021 3:24 PM, Eric Rescorla wrote:
=20


On Thu, Dec 16, 2021 at 12:14 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 12/16/2021 3:01 PM, Eric Rescorla wrote:


On Thu, Dec 16, 2021 at 11:23 AM Michael StJohns <msj@nthpermutation.com> wrote:
On 12/15/2021 9:35 PM, Eric Rescorla wrote:



> So all we=E2=80=99re arguing a= bout here is whether or not the RPC always gets a
> seat at the table, or whether that=E2=80=99s subject to the whims of = the then
> current RSAB.=C2=A0 There=E2=80=99= s precedence ( e.g. Nomcom) in specifying a
> requirement here rather than deferring to an ever changing group of
> people with their own set of biases.


I'm not sure that this precedent cut= s the way you seem to believe. As I understand
it, nomcoms have varied quite a bit in the level of participation.

-Ekr

I'm not sure of the point you're trying = to make here.=C2=A0=C2=A0 If you're saying that = sometimes some of the organizations permitted liaisons failed to send them, then sure, but that's th= e choice of the sending organization and doesn'= t undercut what I'm saying and in fact exactly mirrors what I said about the RPC choosing its representative or none at all.=C2=A0 If you'r= e saying that a given Nomcom declined to seat a liaison from an organization that was allowed one by the current Nomcom procedures RFC - it never happened AFAICT.

Or something else?=C2=A0 And exactly how does it undercut what I've said?

I'm saying that the nomcom sets the terms unde= r which the liaisons participate, and that in some cases it's a lot and in some cases it's much = less. Which is precisely what I'm advocating for here, rather than prescribing the manner in which the liaison engages.

-Ekr


Um.=C2=A0=C2=A0 See=C2=A0 https://datatracker.ietf.org/do= c/html/rfc8713 section 4.7 which specifies the roles and responsibilities of a Nomcom liaison and those are not subject to constraint by the Nomcom on which they serve. 

Liaisons may have other nominating committee responsib=
ilities as
   required by their respective organizations or requested by the
   nominating committee, except that such responsibilities may not
   conflict with any other provisions of this document.

It's possible you're referring to the above paragr= aph, but that's "other duties as assigned" rather = than "you can't participate in the discussions".=C2=A0 AFAIC= T section 4.7 was last updated in 2015 and before that was mostly the same but scattered throughout the document.=C2=A0 The main operative change here was to make the appointment of the ISOC liaison optional in both reality and as written.=C2=A0


I don't see anything here that says that the liaisons ar= e allowed to participate fully in the discussion. Do you have some more on point text?


Section 5.9:

 Deliberations

   All members of the NomCom may participate in all deliberations.

   The emphasis of this rule is that no member can be explicitly
   excluded from any deliberation.  However, a member may individually
   choose not to participate in a deliberation.
which IMHO is definitive.

T= hanks. As I said, I believe that in some nomcoms, this has not been the pra= ctice and it is good to have something to point to.

Just in the interest of clarity: this does not alter my view that we do n= ot need to require an RPC member (liaison or otherwise) on the RSAB.

This is not to say that they should not be able to = provide input, but they can do so in the way that others do -- or, if the R= SAB asks them to, directly. I do not think that special participation right= s not available to the general community should be provided to them in this= document.

-Ekr

=C2= =A0


--00000000000055451105d34a5b76-- From nobody Thu Dec 16 13:54:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7173A0AB6 for ; Thu, 16 Dec 2021 13:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 8vL4u2ZgH5Bv for ; Thu, 16 Dec 2021 13:54:53 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF8203A0AB1 for ; Thu, 16 Dec 2021 13:54:52 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id g28so309306qkk.9 for ; Thu, 16 Dec 2021 13:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=wWrqgidR9lrRjC1Y2ktuLLQ0bIrhkUwR0e4jCBdvFgM=; b=sWUz8ZlWwxENocnZ79gir+mudYR52vG3O2QUatMyTC+0VxBYV3e0ch/x+Tn7V9fCB7 o6LUYWOqgbtRYWDAi6om8Nm71pr7uOpVjPBxi62ANfgXnPjUV8g0ZGI6BvcZabm/Wvn1 OYOqqLMKw18geOOhss3XnE/sCOmSfyqVot5RRBl9ld0qKXvijzlB7BvdeMK3ZQHrxEH2 RjEV0xoQP5J3QN3UMgqLCN1DYDZ2dcISF3IhLWJSUy+EH4bPFK8Ehy0zZqepmqKPDcq+ qMOeaVNNrmgkt3eoMD1tjHjpdFQ3Hl4XePjrmPSUV6SU6Ar/brfbgznzjzsoVUOyKZu4 5XrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=wWrqgidR9lrRjC1Y2ktuLLQ0bIrhkUwR0e4jCBdvFgM=; b=nggqeAzXQC6rAYVJASq6Irgm28AZ3LKMpxWgaKvbn+AaNcXKiROxFtDXx8LcWHiqWs hNa/NPoeRRGF9+KSGVvEG2fra62aqChwgsRKPKZqK5XstyaKSPTQ05DrPHza2TZLVbUg h0kURAsOoY8H6xZmfTAzX13IsI4pSQnBb0cCiUjQMxhvp7+7Lm7tJDE61kJhyd/mQOI6 2UVkINugvPmkN5w6IEPBtqutzHtpQ5dV40YhXVPHtayM1flDTSLfwKvTHQjzuNURMTBw RJvm+CcemcXM50egdn/DvkNYyI5C+BghNrBszJgNCsrerjzXU9mFWNyhEo+34kVyS6Yd V8sg== X-Gm-Message-State: AOAM533Dayp/3SfhG4aoamiX4ACOixv8iRYYGFOVKxQ3Ziw6WooqEgzm Ttn4JLq9hQaWHFkhcljj8MHz2A== X-Google-Smtp-Source: ABdhPJxBfIH4URRc1MG5dC/X1UP7EyYc+xVbT+c4GTkwXmzRF2aUMt+LCs6Xy19WjvMt39kx0xhGkA== X-Received: by 2002:a05:620a:4507:: with SMTP id t7mr47848qkp.652.1639691690630; Thu, 16 Dec 2021 13:54:50 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id a16sm5254397qta.94.2021.12.16.13.54.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 13:54:49 -0800 (PST) Content-Type: multipart/alternative; boundary="------------6xY53lhjTOWQ5EfnaIGvpQii" Message-ID: <5607f34c-1b06-e05f-8d20-1f80c1b4a27b@nthpermutation.com> Date: Thu, 16 Dec 2021 16:54:48 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eric Rescorla Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> <5e2b5b72-26ab-f5fe-a6ec-badc8721fdd0@nthpermutation.com> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:54:56 -0000 This is a multi-part message in MIME format. --------------6xY53lhjTOWQ5EfnaIGvpQii Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/16/2021 4:46 PM, Eric Rescorla wrote: > > Section 5.9: > >> Deliberations >> >> All members of the NomCom may participate in all deliberations. >> >> The emphasis of this rule is that no member can be explicitly >> excluded from any deliberation. However, a member may individually >> choose not to participate in a deliberation. > which IMHO is definitive. > > > Thanks. As I said, I believe that in some nomcoms, this has not been > the practice and it is good to have something to point to. > > Just in the interest of clarity: this does not alter my view that we > do not need to require an RPC member (liaison or otherwise) on the RSAB. > > This is not to say that they should not be able to provide input, but > they can do so in the way that others do -- or, if the RSAB asks them > to, directly. I do not think that special participation rights not > available to the general community should be provided to them in this > document. Hi Ekr - Let me point out that what you've done is stated an opinion, not given any reasons for that opinion.   Perhaps you might state a few reasons for your opinion? Later, Mike --------------6xY53lhjTOWQ5EfnaIGvpQii Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/16/2021 4:46 PM, Eric Rescorla wrote:

Section 5.9:

 Deliberations

   All members of the NomCom may participate in all deliberations.

   The emphasis of this rule is that no member can be explicitly
   excluded from any deliberation.  However, a member may individually
   choose not to participate in a deliberation.
which IMHO is definitive.

Thanks. As I said, I believe that in some nomcoms, this has not been the practice and it is good to have something to point to.

Just in the interest of clarity: this does not alter my view that we do not need to require an RPC member (liaison or otherwise) on the RSAB.

This is not to say that they should not be able to provide input, but they can do so in the way that others do -- or, if the RSAB asks them to, directly. I do not think that special participation rights not available to the general community should be provided to them in this document.


Hi Ekr -

Let me point out that what you've done is stated an opinion, not given any reasons for that opinion.   Perhaps you might state a few reasons for your opinion?

Later, Mike

--------------6xY53lhjTOWQ5EfnaIGvpQii-- From nobody Thu Dec 16 14:02:04 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2C093A0B18 for ; Thu, 16 Dec 2021 14:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 QPEy8VPCdN5O for ; Thu, 16 Dec 2021 14:01:58 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232BC3A0AFB for ; Thu, 16 Dec 2021 14:01:58 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id y16so355418ioc.8 for ; Thu, 16 Dec 2021 14:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CtYCPqGUUXBpNzKe9nULzN6gcg+dR2Y0J0ttNXnmUpE=; b=7z/avNLSmiHBpYDk4sPtGyz03/+BaQcSwxztchJsVcu8Qhxfgh0I+HTkdTRqRIBOi5 IXL2CDIa1RAGbwKTGAoDX5b8VJLoU+dvBaDDXNlQ/r2mKAz+Oa7JPjSGio+dbcBNxFLM YuGDk4RvdpbMhrSwGhiREaItLgIVV1BFMVD8Sg5pJyym185O5Asj7QGW1HzA7rzxcNAD a0EB5wJZjQ+pcMjCmoemPExXMzclb1T1+TPbw/BwW9xt36PEyHb17GOUMj3UNFRg+h2k 8l5QoFoIVNEIdTTOf81WCjvYKXsFuzDkYxLzTac/sJwmR+Ow9FRSjYG2f/egTMF8e9kC 82ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CtYCPqGUUXBpNzKe9nULzN6gcg+dR2Y0J0ttNXnmUpE=; b=CCslitik2xGwANiBwSr+KcxqhUkACC+AFRVb72PeEMD1ZUD0mYP1NSYZBB7/mE2GzC CuPe5aNx+vD95U8SFLuvmd0CxQMogpEgz6Wouqr+HWawNrKUGHRqvaCeZoipTtNC2ynt N7/19CbnWpMf77Yv2jC9yEbBCBRIoI8PI0mGXn6EqGy8U82rf+k6108M8TG7d7g5Lrox 9RkAp3fOAeYJ5Rai2OHMOr2IECa0OdptFGnIF91y0KndC9Hnt+2kmh09jVO6tkpgyKBu KKmcbLH7BzJ1hcToiEaxvksJneGQBeWmodX8BDzhradouiT2uLURLiUjzy8ZHTkj7ZZU ozrw== X-Gm-Message-State: AOAM530JLt+dSIIMJGwFGsGNSfNCDk0knstj7IVuKEJ4eTy6TKiG0wLu 0BTeMdHzDTMtDLsIMHUw2RJ/lSgLuq5HkW23+nsAow== X-Google-Smtp-Source: ABdhPJzqUgUCTsHuA2pB3YiMtanT1dRQ31pvu7WmoN0i0WMayFpnp3RmfvOMj54IVi1K7+YtwOQXANhbPhp3aAVBB+Y= X-Received: by 2002:a05:6638:2487:: with SMTP id x7mr11739358jat.94.1639692114720; Thu, 16 Dec 2021 14:01:54 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> <5e2b5b72-26ab-f5fe-a6ec-badc8721fdd0@nthpermutation.com> <5607f34c-1b06-e05f-8d20-1f80c1b4a27b@nthpermutation.com> In-Reply-To: <5607f34c-1b06-e05f-8d20-1f80c1b4a27b@nthpermutation.com> From: Eric Rescorla Date: Thu, 16 Dec 2021 14:01:18 -0800 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000000a0d7405d34a928b" Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 22:02:03 -0000 --0000000000000a0d7405d34a928b Content-Type: text/plain; charset="UTF-8" On Thu, Dec 16, 2021 at 1:54 PM Michael StJohns wrote: > On 12/16/2021 4:46 PM, Eric Rescorla wrote: > > Section 5.9: >> >> Deliberations >> >> All members of the NomCom may participate in all deliberations. >> >> The emphasis of this rule is that no member can be explicitly >> excluded from any deliberation. However, a member may individually >> choose not to participate in a deliberation. >> >> which IMHO is definitive. >> > > Thanks. As I said, I believe that in some nomcoms, this has not been the > practice and it is good to have something to point to. > > Just in the interest of clarity: this does not alter my view that we do > not need to require an RPC member (liaison or otherwise) on the RSAB. > > This is not to say that they should not be able to provide input, but they > can do so in the way that others do -- or, if the RSAB asks them to, > directly. I do not think that special participation rights not available to > the general community should be provided to them in this document. > > > Hi Ekr - > > Let me point out that what you've done is stated an opinion, not given any > reasons for that opinion. Perhaps you might state a few reasons for your > opinion? > I just did. They can provide input the way that others do so and I haven't seen any persuasive argument that they should have special participation rights. The underlying theme of this work is that the *community* decides. We have constructed the RSAB as a limited check on that and it reflects certain equities, but I don't believe that applies to the RPC. -Ekr --0000000000000a0d7405d34a928b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 16, 2021 at 1:54 PM Micha= el StJohns <msj@nthpermutation= .com> wrote:
=20 =20 =20
On 12/16/2021 4:46 PM, Eric Rescorla wrote:

Section 5.9:

 Deliberations

   All members of the NomCom may participate in all deliberations.

   The emphasis of this rule is that no member can be explicitly
   excluded from any deliberation.  However, a member may individually
   choose not to participate in a deliberation.
which IMHO is definitive.

Thanks. As I said, I believe that in some nomcoms, this has not been the practice and it is good to have something to point to.

Just in the interest of clarity: this does not alter my view that we do not need to require an RPC member (liaison or otherwise) on the RSAB.

This is not to say that they should not be able to provide input, but they can do so in the way that others do -- or, if the RSAB asks them to, directly. I do not think that special participation rights not available to the general community should be provided to them in this document.


Hi Ekr -

Let me point out that what you've done is stated an opinion, not given any reasons for that opinion.=C2=A0=C2=A0 Perhaps you might sta= te a few reasons for your opinion?

I just did. = They can provide input the way that others do so and I haven't seen any= persuasive argument that they should have special participation rights.

The underlying theme of this work is that the *commu= nity* decides. We have constructed the RSAB as a limited check on that and = it reflects certain equities, but I don't believe that applies to the R= PC.

-Ekr
=C2=A0
--0000000000000a0d7405d34a928b-- From nobody Thu Dec 16 14:03:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 550C43A0B1C for ; Thu, 16 Dec 2021 14:03:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20210112.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 Ttux1NV2CweW for ; Thu, 16 Dec 2021 14:03:32 -0800 (PST) Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EDF13A0AFB for ; Thu, 16 Dec 2021 14:03:32 -0800 (PST) Received: by mail-qk1-x729.google.com with SMTP id l25so360412qkl.5 for ; Thu, 16 Dec 2021 14:03:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=fewpmUmWtamKonvwrO4PnJCk+99vrbZOwMUZaTJlvRo=; b=oQAhRO0YGChG3VH9M8xOkTEeJUQvXUF6ITvZzjUxuqob6TTgymF89BvnV+xNmIXDu8 jnlwDsdzGu0W08LRflQN/l7x7wvMSWFllDhGxweMIEmyUb8IkamxUEzOSWKHHjpbuoQQ itsg1b5m2YfF+p2qbOWtmND70UtRRHT2N2b98VOwpzaEga1dauKdZsgH+Lfsu+VosxSA 7BwYtorcwM21nzlTx6toJF3rmbXlD5D8otgHta7+m1+ufPtxDzL0ndFBSkvvGMQ8gHK4 UtozO9kq8vpq2bfGyf5BvdT5CNIZEn1zsKKKNdcYtQR7uGu3lUd8lNcEHTNSf8JQ7Z34 b4Vg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=fewpmUmWtamKonvwrO4PnJCk+99vrbZOwMUZaTJlvRo=; b=foIU4PUBX9gMNod1QCVx0j418TGX9iBM3RYdP++zmGx2JMCYUk56ucKho1+Cb1tLdU diYv8lY6hiCzOdmOqbTk1XJukQCT5beghU+vD3DkS20Bnm+TyRhrBl3u2xWDJbdVBxhU 6oJJU6vAZy7U9dJJLeZlkKevEuFLpit5ai8Fvru5tBWsUGjWrXAn8UowPGlR8DU0Gp4L Q/lRa6XmgYgUNChfsos2BG0krlhz+4IluQTC+SywyyYqSFcnubA4sSv7/D7VF6qpiIaV JYApPKjePWfYVcvWd1oLHsN8g9+mjrP8fUHAbzgsP64EjNbXxmaxBn6MFWkovV9Va0My mrLw== X-Gm-Message-State: AOAM532rqwCyrPUMGNkT3h/2KN9k9c18v2DcTGt5/kmdW7TXYHryubK1 SvIYE/xzND87jlwFnF/v29mfKA== X-Google-Smtp-Source: ABdhPJzQaBA8OgAxlTQLpRp56aKYA/MJT8pYyACT8tBvUn+m1CkZd+YtppEbcYLnEjfcPER3TzbCMg== X-Received: by 2002:a37:4250:: with SMTP id p77mr78231qka.430.1639692208504; Thu, 16 Dec 2021 14:03:28 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id i7sm3539965qkn.0.2021.12.16.14.03.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 14:03:28 -0800 (PST) Message-ID: Date: Thu, 16 Dec 2021 17:03:26 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , Jay Daley Cc: John C Klensin , Peter Saint-Andre , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> From: Michael StJohns In-Reply-To: <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 22:03:37 -0000 On 12/16/2021 4:05 PM, Eliot Lear wrote: > Mike we will not relitigate changes regarding RSCE feedback. That > matter is settled and closed with consensus of this group. > > Eliot > > Hi Eliot - If you offer to give me an ox in exchange for a mule and I agree, but then you say that the ox died, but you have this nice goat that gives milk instead, I get to reconsider whether or not you get the mule. In this case, the source of the cast of characters doing the review potentially changed, which synergistically may result in a decrease of the merit of the "closed" text you're defending.  If nothing comes from the discussion, I'm happy to close it out after a bit. Later, Mike From nobody Thu Dec 16 14:16:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 627013A0CB1 for ; Thu, 16 Dec 2021 14:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 KUx2X5giaxkR for ; Thu, 16 Dec 2021 14:16:37 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAD663A0CAB for ; Thu, 16 Dec 2021 14:16:36 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id v22so743385qtx.8 for ; Thu, 16 Dec 2021 14:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=l98NdynNf09iDhjFqXL12EcZFjUGv34KWmOzcnL3iEY=; b=NAu1KfD+dHUjabM2wxHpqKAensNDN4R3Hqi7viyXurUZloiXEJh60L6IkjnQX1z3Ta cYlcAP4UFQas0Z44LM4lx5cJ9F5xyMwHSnJjs/0bvUYdD3Mp8dcmkXX1oMSixRbHwv26 +4I8lCwTy5M4qeu/iCvjl0UT3kJj+2kC4oulUvLdJATG9en4O2F3El81kZZiUcnfVGFC diMshaWFlltXqNIlNcG7z90YX7hRgLFQwGqX1D0PdYeyH5IsmXWNIQmBHeRgQp+ypPDd +71eZ4+nO1Fciy18xNWV5U88a5MlyPZQmkZ1waPlWXKyr7N/++uYR7rPAXUkU8+e3ThA Jlxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=l98NdynNf09iDhjFqXL12EcZFjUGv34KWmOzcnL3iEY=; b=SPCZP6SpZf18NrKMURu6x3OJLZBoX4aBHTiH2Nw4eLaeAZXE7PQ+Jb+G8tJPZPpEjj 2MkxIVWNrmoJhc69u6l8f7OQ4wzMGW37KXT1PAEVCB0HQqo2+vnXSwUkBVs0AMUJIb+W wdg2c/9xTrMEsq0f+lq0wzsOJ/p+pz6W2wqouA1hesKlyUzGyefrT6EcQut2KJ0ArXqV 3G/LtJGP5NI8dLd1lJNI25xx/SGiazR7fob7R0jeEepQlnB/tBAN1bQub6WEj/ZvoDxe Qjqx9Gc46/KiXENAAF4z619z8EqdOYL7zJNtt0IciWL9VooMMsF5HnJg+mJaHK4YfI/G LK7g== X-Gm-Message-State: AOAM533fFfIEjcwiF3VicFVf8drt/07MrDzf88j7Ss7cxprLorbWHhPM ludNxWwOSX2AXYgGefVg6OObWZ3EOwvAIv+n X-Google-Smtp-Source: ABdhPJzuKNdfCh2Kt1Cf/rCmuW7O8Ea7GdOow2eie02vBpTsC1nS7qNcGPQDkwmrLYdIFGvW1UZJAQ== X-Received: by 2002:a05:622a:3cc:: with SMTP id k12mr79226qtx.412.1639692995346; Thu, 16 Dec 2021 14:16:35 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id y10sm3586786qkp.128.2021.12.16.14.16.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 14:16:34 -0800 (PST) Content-Type: multipart/alternative; boundary="------------eHH8St7shn09zG4eTtFPyQk9" Message-ID: Date: Thu, 16 Dec 2021 17:16:33 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eric Rescorla Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> <5e2b5b72-26ab-f5fe-a6ec-badc8721fdd0@nthpermutation.com> <5607f34c-1b06-e05f-8d20-1f80c1b4a27b@nthpermutation.com> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 22:16:42 -0000 This is a multi-part message in MIME format. --------------eHH8St7shn09zG4eTtFPyQk9 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/16/2021 5:01 PM, Eric Rescorla wrote: > > > On Thu, Dec 16, 2021 at 1:54 PM Michael StJohns > wrote: > > On 12/16/2021 4:46 PM, Eric Rescorla wrote: >> >> Section 5.9: >> >>> Deliberations >>> >>> All members of the NomCom may participate in all deliberations. >>> >>> The emphasis of this rule is that no member can be explicitly >>> excluded from any deliberation. However, a member may individually >>> choose not to participate in a deliberation. >> which IMHO is definitive. >> >> >> Thanks. As I said, I believe that in some nomcoms, this has not >> been the practice and it is good to have something to point to. >> >> Just in the interest of clarity: this does not alter my view that >> we do not need to require an RPC member (liaison or otherwise) on >> the RSAB. >> >> This is not to say that they should not be able to provide input, >> but they can do so in the way that others do -- or, if the RSAB >> asks them to, directly. I do not think that special participation >> rights not available to the general community should be provided >> to them in this document. > > > Hi Ekr - > > Let me point out that what you've done is stated an opinion, not > given any reasons for that opinion. Perhaps you might state a few > reasons for your opinion? > > I just did. They can provide input the way that others do so and I > haven't seen any persuasive argument that they should have special > participation rights. > > The underlying theme of this work is that the *community* decides. We > have constructed the RSAB as a limited check on that and it reflects > certain equities, but I don't believe that applies to the RPC. > > -Ekr I'm still seeing mostly opinion.  Nothing about how giving the RPC a seat might be bad for example.  Or why my arguments don't hold water? When you say community, what I think you really mean are the people that show up to the RSWG will get to decide.  That is a community based decision process - it is not the community deciding in any way shape or form.  The community may ultimately decide to approve this process we're drafting.  The community will mostly not be deciding on individual documents and AIRC you've been a big opponent of requiring broader community review for some documents - so the definition of community you're laboring under feels a bit flexible. AFAICT giving the RPC a seat at the table to be able to talk does not prevent the RSWG from proposing anything, nor does it necessarily prevent the RSAB from approving it.  What it does do is give the RSAB a consistently available source of ground truth that it can't easily ignore in its decision process.   Generally, more information is better.  Or do you disagree? For the appeals process, if one occurs, having the RPC on record as to how they view the appealed proposal can only make the appeals process less error prone and the decisions less subjective. So how does this prevent the "community" from deciding? Later, Mike --------------eHH8St7shn09zG4eTtFPyQk9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/16/2021 5:01 PM, Eric Rescorla wrote:


On Thu, Dec 16, 2021 at 1:54 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 12/16/2021 4:46 PM, Eric Rescorla wrote:

Section 5.9:

 Deliberations

   All members of the NomCom may participate in all deliberations.

   The emphasis of this rule is that no member can be explicitly
   excluded from any deliberation.  However, a member may individually
   choose not to participate in a deliberation.
which IMHO is definitive.

Thanks. As I said, I believe that in some nomcoms, this has not been the practice and it is good to have something to point to.

Just in the interest of clarity: this does not alter my view that we do not need to require an RPC member (liaison or otherwise) on the RSAB.

This is not to say that they should not be able to provide input, but they can do so in the way that others do -- or, if the RSAB asks them to, directly. I do not think that special participation rights not available to the general community should be provided to them in this document.


Hi Ekr -

Let me point out that what you've done is stated an opinion, not given any reasons for that opinion.   Perhaps you might state a few reasons for your opinion?

I just did. They can provide input the way that others do so and I haven't seen any persuasive argument that they should have special participation rights.

The underlying theme of this work is that the *community* decides. We have constructed the RSAB as a limited check on that and it reflects certain equities, but I don't believe that applies to the RPC.

-Ekr
 

I'm still seeing mostly opinion.  Nothing about how giving the RPC a seat might be bad for example.  Or why my arguments don't hold water?

When you say community, what I think you really mean are the people that show up to the RSWG will get to decide.  That is a community based decision process - it is not the community deciding in any way shape or form.  The community may ultimately decide to approve this process we're drafting.  The community will mostly not be deciding on individual documents and AIRC you've been a big opponent of requiring broader community review for some documents - so the definition of community you're laboring under feels a bit flexible.

AFAICT giving the RPC a seat at the table to be able to talk does not prevent the RSWG from proposing anything, nor does it necessarily prevent the RSAB from approving it.  What it does do is give the RSAB a consistently available source of ground truth that it can't easily ignore in its decision process.   Generally, more information is better.  Or do you disagree? 

For the appeals process, if one occurs, having the RPC on record as to how they view the appealed proposal can only make the appeals process less error prone and the decisions less subjective.

So how does this prevent the "community" from deciding? 

Later, Mike




--------------eHH8St7shn09zG4eTtFPyQk9-- From nobody Thu Dec 16 16:43:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF6333A0910 for ; Thu, 16 Dec 2021 16:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 SXUW7nT99OZN for ; Thu, 16 Dec 2021 16:43:49 -0800 (PST) Received: from mail-pg1-x534.google.com (mail-pg1-x534.google.com [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401073A090D for ; Thu, 16 Dec 2021 16:43:49 -0800 (PST) Received: by mail-pg1-x534.google.com with SMTP id r5so565651pgi.6 for ; Thu, 16 Dec 2021 16:43:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=k7DlWViW/HYYKBk6rNPK46pqJO85c6k7A0Ls9caPh5Q=; b=i9xQPR6ALYr0axnTQlHLCln9U438iJsAXo2EM21s4GhMDtFGJxnRHNT4AiZ7I1MnBY ZBdXJcJ1n+0S/Y+HQjPWA4RasX+5VstQ8YFolHmh4hmWuYqzuaYFNYWWVJhe7QiS5yFs 0GzDb0HEYj+tOdZ6nClCM7yC1oAoma91GXXpL25MtdnFM80c7vYdNtNT4cJV6Tma8vGy uHJuMnUxiNcZ/GfTMtA3Km0XXVqOx8M05sd41USuv9OvimPcYj85wL1r+JX2jd5OllZ4 WnmLhHnokaZ2oEoCvholYIWpgx2NPpIlyFp/DJeIXprn/bZ/qh6PTU2unYDXUhi+9KO8 J1IA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=k7DlWViW/HYYKBk6rNPK46pqJO85c6k7A0Ls9caPh5Q=; b=1t++aGn4PCYha9sIdUB75/+bJaBFpMwDI2yJUbdnJu1d8fLLjmBqwXRt+3jWx6Zzc0 tHlhkwfG/ILMhI45wItDgIPWBhtGaElkf5q4jYFSgxjs3s5CX+OA0FRTOk2dYLdCFbiT UyrklUHsrj5xSRSz0dTDhwvERLUQ6Le90a0K8Vjgoyg4fhATj/9VR8tUXj01DTi6WxsE oKv+gvLNZi43U9JG/Ua7omLIXI5p69IINJot/jUHSBA9cjySt8jRe94HMnAa5hIpTxNv dmcMosXJ3OFZVtuA5XJrrS9qpWIiVrlcvBOHiVbO/FUrh4xsi+UMTx0N+luLrPFTg3jR P1Iw== X-Gm-Message-State: AOAM531rK2NLKPHpimqU2sCa5CgsRgmukUEtmXriWNlOeLg4TWHbncrY Vi0X5rYiIQc4Eo6ZMR+6P66f8zQgddxpuA== X-Google-Smtp-Source: ABdhPJwQ7S8tmNU7dBexY+g4Ov7Fmm3Qxzdj8WuXv5GfojVOcORGMwGqaysg1+7ehsO7xUYUvZaVfQ== X-Received: by 2002:a05:6a00:986:b0:4a2:c1fa:8899 with SMTP id u6-20020a056a00098600b004a2c1fa8899mr491413pfg.61.1639701827323; Thu, 16 Dec 2021 16:43:47 -0800 (PST) Received: from ?IPv6:2406:e003:1071:1701:80b2:5c79:2266:e431? ([2406:e003:1071:1701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w19sm6445735pga.80.2021.12.16.16.43.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 16:43:46 -0800 (PST) To: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> <5e2b5b72-26ab-f5fe-a6ec-badc8721fdd0@nthpermutation.com> <5607f34c-1b06-e05f-8d20-1f80c1b4a27b@nthpermutation.com> From: Brian E Carpenter Message-ID: <3ce60640-c942-cd1c-2bb4-96e2bcb79d6c@gmail.com> Date: Fri, 17 Dec 2021 13:43:43 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:43:51 -0000 Eric, On 17-Dec-21 11:01, Eric Rescorla wrote: ... > The underlying theme of this work is that the *community* decides. We have constructed the RSAB as a limited check on that and it reflects certain equities, but I don't believe that applies to the RPC. I would expect that if the RSWG reaches consensus on a policy that the RPC considers unworkable (and RPC people have made this clear during the RSWG discussion), the RPC would anyway raise the issue with the ED, who is a non-voting RSAB member, as well as with the RSCE. Brian C From nobody Thu Dec 16 16:44:53 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C0F3A0917; Thu, 16 Dec 2021 16:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMcYZHQy_Iqe; Thu, 16 Dec 2021 16:44:46 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1428D3A0915; Thu, 16 Dec 2021 16:44:41 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1my1MU-000Ec4-1b; Thu, 16 Dec 2021 19:44:38 -0500 Date: Thu, 16 Dec 2021 19:44:32 -0500 From: John C Klensin To: Eliot Lear , Michael StJohns , Jay Daley cc: Peter Saint-Andre , rfced-future@iab.org Message-ID: <8DD8DC80C6CD5605BDD0E07B@PSB> In-Reply-To: <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> 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] Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:44:51 -0000 --On Thursday, December 16, 2021 22:05 +0100 Eliot Lear wrote: > Mike we will not relitigate changes regarding RSCE feedback. > That matter is settled and closed with consensus of this group. Eliot, I think there are two separate issues here and wonder if we might be able to keep them separate: (1) I agree that this should not be reopened, not necessarily because I disagree with Mike's reasoning but because, if we forbid the RSAG from having an executive session when sensitive matters come up, we basic encourage such sessions being held in secret and out of public view due to one loophole or the other when didn't think to close. For that reason, I'd rather see the document allow such sessions but be sure their existence and the justification for them are public. I'll need to make another pass through it with that question in mind before having an opinion as to whether the document is adequate on that dimension. (2) While I sympathize with and share your desire to keep moving forward and to not revisit settled issues, one thing we have observed before is that many of the issues facing us are ultimately related to each other in complex ways. While trying separate them and address them separately and in some sequence is obviously tempting and desirable, it inevitably raises the risk of later decisions changing things (in this case and as Mike points out, the definition of the RSCE role and the composition of the RSAB) that undermine the assumptions that underlay the earlier conclusions. If those conclusions cannot be reopened to evaluate whether subsequent changes might undermine them and how, then I think we are in serious trouble to the point that claims of rough consensus within the effort become dubious. best, john From nobody Thu Dec 16 16:58:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB65D3A099E for ; Thu, 16 Dec 2021 16:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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=stpeter.im header.b=GUuYYcts; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YzKiCkR/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7NiJjdfASDXv for ; Thu, 16 Dec 2021 16:58:19 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68D493A09A6 for ; Thu, 16 Dec 2021 16:58:19 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 76D7D5C01B6; Thu, 16 Dec 2021 19:58:18 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 16 Dec 2021 19:58:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:to:cc:references:from:subject :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=L WY4IYd3UaQxmtcuLP3gpUfRymIPjTRZU3kA2Cf7SV4=; b=GUuYYctscrZ2BUplT WtWjOtUSnQoWstpOmnrDM8hV8SPzZrrQb5gkdtwd1OXpcHTjyuFCcO+QBFv0y77G SOHFto7sENkLMw7Ivy+7OWOrE8hWp31arvAcE3Isp2d33HeIKk5ou+MWZvyPnv97 AZ9BGoF7g4Tz1e1VCv9y25yNchfO/YRE2+TI6Xo5r4/AAtyDolnAofFCKWVtp4pN xeTFKw8SEnfTh1lt7aR00NEIYljurH7kdL3MQMv8NWg/aWE0tdjCwraQwyBPdD/C cxZ1aJQ+M8k+XACdZKXmgPrQ1G138FspVMRMXQnNTjyVOxAV0Qz684DnuUmWZXce T8pNA== 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=fm1; bh=LWY4IYd3UaQxmtcuLP3gpUfRymIPjTRZU3kA2Cf7S V4=; b=YzKiCkR/JmBOmJgKy4wwcEo20CWxsR8g/PjCAXr+uORtQ8HlWP5VLmajJ BpzCcRfaHam/U84jQSON/hvtQOt0CTIMFj/o3DTjcVFv17IVPJ2dZhA9skBCnbQw 7QWCZsHVHksdzPeE9Jo5fEfkORCpk7yFXwscr8OCjz1Wuas0hYmmwuCqCDIIr5tS Z+BKW2F4aE+1ZoO1ldmOj/eDbyflzSEYNDTKbX2eHt/5q1flZJRtOlkfe+rDiN2x WYaRG3XoJz0Tz6jAT4r6QTvByuxXfhsXG9BKkfvdtXuOh2T9MHU/fAi19BJOb7nC B4PPrzS1lXH2bVKgCuSmmMW+5creg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleehgddviecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepkfffgggfvfhfhffujggtgfesthgsre dttdefjeenucfhrhhomheprfgvthgvrhcuufgrihhnthdqtehnughrvgcuoehsthhpvght vghrsehsthhpvghtvghrrdhimheqnecuggftrfgrthhtvghrnhepleevudelvdegheeije dvfedvheeuteffvefhtedtteejieegueetfeekieeuffejnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgvthgvrh drihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 16 Dec 2021 19:58:17 -0500 (EST) Message-ID: Date: Thu, 16 Dec 2021 17:58:13 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Jay Daley , Michael StJohns Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> From: Peter Saint-Andre In-Reply-To: <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:58:25 -0000 T24gMTIvMTYvMjEgMTozMCBQTSwgSmF5IERhbGV5IHdyb3RlOg0KPiANCj4gDQo+PiBPbiAx Ny8xMi8yMDIxLCBhdCA4OjUwIEFNLCBNaWNoYWVsIFN0Sm9obnMgPG1zakBudGhwZXJtdXRh dGlvbi5jb20+IHdyb3RlOg0KPj4NCj4+IFRvcCBwb3N0aW5nIGJlY2F1c2UuDQoNCk1pa2Us IEkgc3VyZSB3aXNoIHlvdSdkIHRha2UgdXAgaW50ZXJsZWF2ZWQgcmVwbGllcyAtIHRoZXkn cmUgbXVjaCANCmVhc2llciB0byBmb2xsb3cuIDotKQ0KDQo+PiBFbGlvdCAtIEdlbmVyYWxs eSB0aGUgcm9sZSBvZiB0aGUgY2hhaXIgaXMgdG8gZWxpY2l0IGJvdGggcG9pbnRzIGFuZCBy YXRpb25hbGVzIGFuZCBlbmdlbmRlciBhIGRpc2N1c3Npb24sIG5vdCB0byBwaWNrIG9uZSBw b2ludCBhcyB0aGUgdHJ1ZSBhbnN3ZXIgYW5kIHJlcXVpcmUgdGhlIG90aGVyIHNpZGUgdG8g YXR0YWNrIGl0Lg0KPj4NCj4+IEluIHRoaXMgY2FzZSwgSSB0aGluayB0aGVyZSdzIHN1YnN0 YW50aWFsIGNvbW1lbnRhcnkgb24gd2h5IHRoZSBSUEMgc2hvdWxkIGhhdmUgYSBzZWF0IGF0 IHRoZSB0YWJsZS4gIEFuZCBsaXR0bGUgY29tbWVudGFyeSBvbiBub3QgYmVzaWRlICJsZXQg dGhlIFJTQUIgZGVjaWRlIi4NCj4+DQo+PiBGb3IgeW91ciBwb2ludHMgYmVsb3c6ID4+DQo+ PiAxKSANCg0KVGhhdCBpcyAoZnJvbSBFbGlvdCdzIGVtYWlsKTogIkFwcHJvdmUgb3IgZGlz YXBwcm92ZSBSU1dHIHdvcmssIg0KDQo+IElmIHRoZSBSU1dHIGlzIHByb3Bvc2luZyBzb21l dGhpbmcgdGhhdCB3aWxsIGltcGFjdCB0aGUgUlBDJ3Mgd29yaywgd29yayBmbG93LCBMT0Us IGNvc3RzLCBTTEEgZXRjLCBoYXZpbmcgdGhlIFJQQyBiZSBhYmxlIHRvIGV4cGxhaW4gZXhh Y3RseSB3aGF0IHdpbGwgbmVlZCB0byBjaGFuZ2UgdG8gc3VwcG9ydCB0aGUgcHJvcG9zYWws IGFuZCBleHBsYWluaW5nIHdoYXQgY291bGQgYmUgbW92ZWQgYXJvdW5kIHRvIG1ha2UgdGhp bmdzIHdvcmsgc2VlbXMgdG8gYmUgYSB1c2VmdWwgaW5wdXQgaW50byB3aGV0aGVyIHRoZSBS U0FCIGFwcHJvdmVzIGEgZG9jdW1lbnQgb3IgcmV0dXJucyBpdCB3aXRoIGNvbW1lbnRzIHRv IHRoZSBSU1dHLiAgIEdpdmVuIHRoYXQgcHJldHR5IG11Y2ggYW55IGRvY3VtZW50IHRoYXQg ZGVzY3JpYmVzIGZ1bmN0aW9uYWwgYWxiZWl0IHN0cmF0ZWdpYyBjaGFuZ2VzIHdpbGwgaW52 b2x2ZSB0aGUgUlBDIGFuZCB0aGF0IEkgd291bGQgYmUgc3VycHJpc2VkIGlmIHRoZXJlIGFy ZSBtYW55IG5vbi1mdW5jdGlvbmFsIChjaGFuZ2VzIG5vdCBhZmZlY3RpbmcgZnVuY3Rpb24p IHByb3Bvc2VkIGJ5IHRoZSBSU1dHLCBpdCBqdXN0IG1ha2VzIHNlbnNlIHRoYXQgdGhlIFJQ QyBiZSBpbmNsdWRlZC4gIEZpbHRlcmluZyBhbGwgdGhhdCB0aHJvdWdoIHRoZSBFRCBpcyBu b3QgYSkgc2NhbGFibGUgKGhvdyBtdWNoIG1vcmUgZ2V0cyBwaWxlZCBvbiB0byBKYXkgb3Ig aGlzIHN1Y2Nlc3Nvcj8pLCBiKSBlZmZpY2llbnQgKGUuZy4gYSBwcmUtbWVldGluZyB3aXRo IHRoZSBFRCBhbmQgdGhlIFJQQyB0byBwcmVwYXJlIHRoZSBFRCBmb3IgdGhlIFJTQUIgbWVl dGluZyksIGMpIGVycm9yLWZyZWUgKHRoaW5rIHRoZSBnYW1lIG9mICJUZWxlcGhvbmUiKS4g IEluIGZhY3QgaGF2aW5nIGJvdGggdGhlIEVEIGFuZCB0aGUgUlBDIHRoZXJlIG1heSBtZWFu IHRoYXQgc21hbGwgdHdlYWtzIGNhbiBiZSBhcHByb3ZlZCBxdWlja2x5IGFzIGJvdGggc2lk ZXMgb2YgdGhlIGNvbnRyYWN0IHdvdWxkIGJlIHJlcHJlc2VudGVkLg0KPiANCj4gVGhlIEVE IGNhbm5vdCByZXByZXNlbnQgdGhlIFJQQyBvbiB0aGUgUlNBQiwgYWN0IGFuIGludGVybWVk aWFyeSBvciBvdGhlcndpc2UgcmVwbGFjZSBkaXJlY3QgY29udGFjdCBiZXR3ZWVuIHRoZSBS UEMgYW5kIHRoZSBSU0FCLg0KDQpJIGRvIHRoaW5rIEpheSBtYWtlcyBhbiBpbXBvcnRhbnQg cG9pbnQgaGVyZS4NCg0KSG93ZXZlciwgZ29pbmcgYmFjayB0byBFbGlvdCdzIG5vdGUsIGV2 ZXJ5dGhpbmcgdGhhdCBNaWtlIHNheXMgYWJvdXQgDQppbXBhY3RzIG9uIHRoZSBSUEMgc2hv dWxkIGhhdmUgYmVlbiBjb3ZlcmVkIGluIHRoZSBSU1dHIGxvbmcgYmVmb3JlIHRoZSANClJT QUIgZ2V0cyBhcm91bmQgdG8gdm90aW5nLiBBcyBFa3Igc2F5cywgdGhpcyBpcyBzdXBwb3Nl ZCB0byBiZSBhIA0KY29tbXVuaXR5LWRyaXZlbiBwcm9jZXNzIGFuZCBSUEMgZm9sa3Mgc2hv dWxkIG1ha2Ugc3VyZSB0aGVpciB2b2ljZXMgYXJlIA0KaGVhcmQgdmVyeSBlYXJseSBvbiwg bm90IGxhdGUgaW4gdGhlIHByb2Nlc3MuIEluIGZhY3QsIHdlIG1pZ2h0IHdhbnQgdG8gDQph bHRlciBvdXIgdGV4dCBpbiB0aGUgd29ya2Zsb3cgc2VjdGlvbiBhbG9uZyB0aGVzZSBsaW5l czoNCg0KT0xEDQoNCiAgICAzLiAgVGhlIFJTV0cgc2hhbGwgdGhlbiBmdXJ0aGVyIGRpc2N1 c3MgYW5kIGRldmVsb3AgdGhlIHByb3Bvc2FsLg0KICAgICAgICBNZW1iZXJzIG9mIHRoZSBS U0FCIGFyZSBleHBlY3RlZCB0byBwYXJ0aWNpcGF0ZSBhcyBpbmRpdmlkdWFscyBpbg0KICAg ICAgICBhbGwgZGlzY3Vzc2lvbnMgcmVsYXRpbmcgdG8gUlNXRyBwcm9wb3NhbHMgc28gdGhh dCB0aGV5IGFyZSBmdWxseQ0KICAgICAgICBhd2FyZSBvZiBwcm9wb3NhbHMgZWFybHkgaW4g dGhlIHBvbGljeSBkZWZpbml0aW9uIHByb2Nlc3MsIGFuZCBzbw0KICAgICAgICB0aGF0IGFu eSBpc3N1ZXMgb3IgY29uY2VybnMgdGhhdCB0aGV5IGhhdmUgd2lsbCBiZSByYWlzZWQgZHVy aW5nDQogICAgICAgIHRoZSBkZXZlbG9wbWVudCBvZiB0aGUgcHJvcG9zYWwsIG5vdCBsZWZ0 IHVudGlsIHRoZSBSU0FCIHJldmlldw0KICAgICAgICBwZXJpb2QuICBUaGUgUlNXRyBjaGFp cnMgYXJlIGFsc28gZXhwZWN0ZWQgdG8gcGFydGljaXBhdGUgYXMNCiAgICAgICAgaW5kaXZp ZHVhbHMuDQoNCk5FVw0KDQogICAgMy4gIFRoZSBSU1dHIHNoYWxsIHRoZW4gZnVydGhlciBk aXNjdXNzIGFuZCBkZXZlbG9wIHRoZSBwcm9wb3NhbC4NCiAgICAgICAgTWVtYmVycyBvZiB0 aGUgUlNBQiBhcmUgZXhwZWN0ZWQgdG8gcGFydGljaXBhdGUgYXMgaW5kaXZpZHVhbHMgaW4N CiAgICAgICAgYWxsIGRpc2N1c3Npb25zIHJlbGF0aW5nIHRvIFJTV0cgcHJvcG9zYWxzIHNv IHRoYXQgdGhleSBhcmUgZnVsbHkNCiAgICAgICAgYXdhcmUgb2YgcHJvcG9zYWxzIGVhcmx5 IGluIHRoZSBwb2xpY3kgZGVmaW5pdGlvbiBwcm9jZXNzLCBhbmQgc28NCiAgICAgICAgdGhh dCBhbnkgaXNzdWVzIG9yIGNvbmNlcm5zIHRoYXQgdGhleSBoYXZlIHdpbGwgYmUgcmFpc2Vk IGR1cmluZw0KICAgICAgICB0aGUgZGV2ZWxvcG1lbnQgb2YgdGhlIHByb3Bvc2FsLCBub3Qg bGVmdCB1bnRpbCB0aGUgUlNBQiByZXZpZXcNCiAgICAgICAgcGVyaW9kLiAgUmVwcmVzZW50 YXRpdmVzIG9mIHRoZSBSUEMgc2hvdWxkIGFsc28gcGFydGljaXBhdGUgc28NCiAgICAgICAg dGhhdCBhbnkgaW1wYWN0cyBvbiBpbXBsZW1lbnRhdGlvbiBvZiBwcm9wb3NlZCBwb2xpY2ll cyBhcmUNCiAgICAgICAgcmFpc2VkIGFuZCBhZGRyZXNzZWQgZWFybHkgaW4gdGhlIHByb2Nl c3MuICBUaGUgUlNXRyBjaGFpcnMgYXJlDQogICAgICAgIGFsc28gZXhwZWN0ZWQgdG8gcGFy dGljaXBhdGUgYXMgaW5kaXZpZHVhbHMuDQoNCj4+IDIpIA0KDQpUaGF0IGlzIChmcm9tIEVs aW90J3MgZW1haWwpOiAiUHJvdmlkZSBndWlkYW5jZSB0byB0aGUgUlBDIHJlZ2FyZGluZyAN CmNlcnRhaW4gaW50ZXItc3RyZWFtIGNvbmZsaWN0cywiDQoNCj4gVGhpcyBvbmUgc2VlbXMg b2J2aW91cyAtIHRoZSBSUEMgYnJpbmdzIHRoaW5ncyB0byB0aGUgUlNBQiBmb3IgZGlzY3Vz c2lvbi4gIEhhdmluZyBhIHNlYXQgYXQgdGhlIHRhYmxlIHRvIGFkZCB0aGluZ3MgdG8gdGhl IGFnZW5kYSB2cyBiZWluZyBzdW1tb25lZCBhdCB0aGUgd2hpbSBvZiB0aGUgUlNBQiANCg0K U3RlcGhlbiBtYWRlIGEgZ29vZCBwb2ludCBzb21lIHRocmVhZHMgYWdvIGFib3V0IGluZmxh bW1hdG9yeSBsYW5ndWFnZS4gDQpDb3VsZCB3ZSBwbGVhc2UgYXZvaWQgdGhhdD8gV2h5IHNo b3VsZCB3ZSB0aGluayB0aGF0IFJTQUIsIHBlb3BsZWQgYnkgDQpwZW9wbGUgd2hvIHByZXN1 bWFibHkgY2FyZSBhIGdyZWF0IGRlYWwgYWJvdXQgdGhlIFNlcmllcyBhbmQgaGF2ZSANCnNp Z25pZmljYW50IGtub3dsZWRnZSBvZiB0aGUgU2VyaWVzIChhbmQgaGF2ZSBiZWVuIGFwcG9p bnRlZCBieSB0aGUgDQpsaWtlcyBvZiB0aGUgSUVTRyBvciBJQUIpLCB3aWxsIGFjdCBvbiB3 aGltPw0KDQo+IC0gdGhlIGVxdWl0aWVzIGFyZ3VlIGZvciB0aGUgZm9ybWVyLiBJIGFjdHVh bGx5IGV4cGVjdCB0aGF0IG1vc3QgbWVldGluZ3MgKGJhc2VkIG9uIHRoZSBSU09DJ3MgbWlu dXRlcykgd2lsbCBpbnZvbHZlIFJQQyBkaXNjdXNzaW9ucyBvZiBzb21lIHNvcnQgdW5kZXIg dGhpcyBoZWFkaW5nLg0KDQpJdCdzIHRydWUgdGhhdCB3aXRoaW4gUlNPQyB0aGVyZSdzIG9m dGVuIHZlcnkgcHJvZHVjdGl2ZSBkaXNjdXNzaW9uIHdpdGggDQphIHJlcHJlc2VudGF0aXZl IG9mIHRoZSBSUEMuIEhvd2V2ZXIsIHZlcnNpb24gMyBvZiB0aGUgbW9kZWwgZ2V0cyByaWQg b2YgDQp0aGUgUlNPQyBhbmQgcmVwbGFjZXMgaXQgd2l0aCwgZm9yIHRoZSBtb3N0IHBhcnQs IGNvbW11bml0eSBkaXNjdXNzaW9uIA0Kd2l0aGluIHRoZSBSU1dHLg0KDQpXaXRoIHJlZ2Fy ZCB0byB0aGUgUlBDIGJyaW5naW5nIHRoaW5ncyB0byB0aGUgUlNBQiBmb3IgZGlzY3Vzc2lv biwgdGhlIA0KY29udGV4dCBoZXJlIGlzIHJlYWxseSBTZWN0aW9uIDQuNCwgIlJlc29sdXRp b24gb2YgRGlzYWdyZWVtZW50cyBiZXR3ZWVuIA0KQXV0aG9ycyBhbmQgdGhlIFJQQyIgKElN SE8gRWxpb3QncyBwaHJhc2luZyAiUHJvdmlkZSBndWlkYW5jZSB0byB0aGUgUlBDIA0KcmVn YXJkaW5nIGNlcnRhaW4gaW50ZXItc3RyZWFtIGNvbmZsaWN0cyIgaXNuJ3QgcXVpdGUgYWNj dXJhdGUpLiBJbiB0aGlzIA0KY2FzZSB0aGUgUlBDIGlzIGFscmVhZHkgZnVsbHkgZW5nYWdl ZCBiZWNhdXNlIHRoZXJlJ3MgYSBkaXNhZ3JlZW1lbnQgDQp3aXRoIGFuIGF1dGhvciBvciBz ZXQgb2YgYXV0aG9ycyBvbiBhbiBSRkMtdG8tYmUuIFNvIHRoZXJlJ3Mgbm8gbmVlZCBmb3Ig DQoic3VtbW9uaW5nIiBiYXNlZCBvbiB3aGltIG9yIHJlYXNvbi4NCg0KPj4gMykgDQoNClRo YXQgaXMgKGZyb20gRWxpb3QncyBlbWFpbCk6ICJQcm92aWRlIGFuIG9waW5pb24gcmVnYXJk aW5nIGZlZWRiYWNrIG9uIA0KdGhlIFJTQ0UgdG8gdGhlIExMQywgYW5kIg0KDQo+IEkgbmVl ZCB0byBnZXQgYmFjayB0byB5b3VyIG90aGVyIGVtYWlsIG9uIHRoaXMgcG9pbnQsIGJ1dCBJ J20gYmVjb21pbmcgbW9yZSBhbmQgbW9yZSBjb252aW5jZWQgdGhhdCB0aGUgUlNBQiBhcyBh IGdyb3VwIHNob3VsZCBub3QgYmUgaG9sZGluZyBleGVjdXRpdmUgc2Vzc2lvbnMgZm9yIGFu eSByZWFzb24uDQo+IA0KPiBUaGUgcHJvYmxlbSB3aXRoIHRoYXQgaXMgdGhlICJSU0NFIFBl cmZvcm1hbmNlIEV2YWx1YXRpb24iIFsxXS4gIElmIHlvdSByZWNhbGwsIHdlIGhhZCBhIGxv bmcgY29udmVyc2F0aW9uIGFib3V0IHRoaXMgcHJvY2VzcyByZXF1aXJpbmcgYm90aCBjb21t dW5pdHkgaW5wdXQgYW5kIGNvbW11bml0eSByZXZpZXcgb2YgdGhlIEVE4oCZcyByZWNvbW1l bmRhdGlvbnMuDQo+IA0KPj4gICAgVGhpcyB0YXNrIGZvciB0aGUgUlNBQiBvbmx5IHJlYWxs eSBtYWtlcyBzZW5zZSBpZiBhbGwgb2YgdGhlIFJTQUIgbWVtYmVycyBleGNsdWRpbmcgdGhl IFJTQ0Ugd2VyZSBmcm9tIHRoZWlyIGFwcG9pbnRpbmcgb3JnYW5pemF0aW9ucyBhbmQgd2Vy ZSBsb25nLWxpdmVkIGluIHRoZSBqb2IgLSBhbmQgbmVpdGhlciBvZiB0aGVzZSBhcHBlYXIg dG8gYmUgZ3VhcmFudGVlZCB0byBiZSB0cnVlLiAgSW4gYW55IGV2ZW50IHRoZSBwcmVzZW5j ZSBvZiB0aGlzIHRhc2sgbmVpdGhlciBhcmd1ZXMgZm9yIG9yIGFnYWluc3Qgbm9uLXZvdGlu ZyBleC1vZmZpY2lvIG1lbWJlcnMuDQoNCk1pa2UsIGRvIHlvdSBzZWUgYSBzcGVjaWFsIHJv bGUgZm9yIHRoZSBSUEMgb24gcG9pbnQgIzMgb3IgY2FuIHRoZWlyIA0KZmVlZGJhY2sgYmUg Z2F0aGVyZWQgYXMgYW55IG90aGVyIGNvbW11bml0eSBmZWVkYmFjayB3b3VsZCBiZT8gQXMg ZmFyIGFzIA0KSSBjYW4gc2VlLCBhbiBSUEMgcmVwcmVzZW50YXRpdmUgd291bGQgbm90IG5l ZWQgdG8gYmUgYW4gZXgtb2ZmaWNpbyBvZiANClJTQUIgaW4gb3JkZXIgdG8gcHJvdmlkZSB0 aGlzIGtpbmQgb2YgZmVlZGJhY2suDQoNCj4+IDQpIA0KDQpUaGF0IGlzIChmcm9tIEVsaW90 J3MgZW1haWwpOiAiQWRkcmVzcyBjZXJ0YWluIGFwcGVhbHMuIg0KDQo+IFRoZSBFRCBkb2Vz bid0IGhhdmUgYSByb2xlIGluIHRoZSBhcHBlYWxzIHByb2Nlc3MsIGJ1dCBpcyBzdGlsbCBp bmNsdWRlZCBhcyBleC1vZmZpY2lvIHNvIHRoZSBwcmVzZW5jZSBvZiB0aGlzIHRhc2sgbmVp dGhlciBhcmd1ZXMgZm9yIG9yIGFnYWluc3QgaGF2aW5nIHRoZSBSUEMgaGF2aW5nIGFuIGV4 LW9mZmljaW8gbWVtYmVyLiAgSXQncyBwb3NzaWJsZSB0aGF0IGJvdGggdGhlIEVEIGFuZCB0 aGUgUlBDIG1pZ2h0IGhhdmUgdXNlZnVsIGlucHV0IGludG8gYSBnaXZlbiBhcHBlYWwgd2hp Y2ggbWlnaHQgYmUgbWlzc2VkIGlmIGVpdGhlciBpcyBleGNsdWRlZCBmcm9tIHRoZSBkaXNj dXNzaW9ucy4NCg0KSGVyZSBhZ2FpbiBJIGRvbid0IHNlZSBhIHNwZWNpYWwgcm9sZSBmb3Ig dGhlIFJQQyByZWdhcmRpbmcgYXBwZWFscyB0byANCnRoZSBSU0FCIG9mIGJlaGF2aW9yIGJ5 IHRoZSBSU1dHIG9yIFJTV0cgY2hhaXJzLg0KDQo+PiBJIGxvb2sgZm9yd2FyZCB0byB0aGUg b3Bwb25lbnRzIG9mIHRoZSBSUEMgYmVpbmcgZXgtb2ZmaWNpbyBwcm92aWRpbmcgcmVsYXRl ZCBjb21tZW50YXJ5IC0gZS5nLiAgYSkgd2h5IHNob3VsZCBhIHJhbmRvbSBtZW1iZXJzaGlw IG9mIHRoZSBSU0FCIGRlY2lkZSB3aGV0aGVyIHRoZSBSUEMgcmVsYXRpb25zaGlwIGlzIGV4 LW9mZmljaW8gb3Igc29tZXRoaW5nIGVsc2U/IGIpIGhvdyBvZnRlbiBzaG91bGQgdGhleSBk ZWNpZGUgdGhpcyAoZS5nLiBldmVyeXRpbWUgYSBtZW1iZXIgY2hhbmdlcyBvdXQ/ICBlYWNo IG1lZXRpbmc/IGVhY2ggeWVhcj8gbmV2ZXI/KSwgYykgd2hhdCBpcyB0aGUgZGlmZmVyZW5j ZSBiZXR3ZWVuIGFuIGV4LW9mZmljaW8gbWVtYmVyIGFuZCBvbmUgdGhhdCBnZXRzIGludml0 ZWQgdG8gZXZlcnkgbWVldGluZyAoZS5nLiBpcyB0aGUgZGlmZmVyZW5jZSB0aGF0IHRoZSBS UEMgYnkgcnVsZSBzaXRzIG11dGUgdW50aWwgYXNrZWQgYWJvdXQgc29tZXRoaW5nPyAgU2hv dWxkIHRoYXQgcnVsZSBhcHBseSB0byB0aGUgRUQgYXMgd2VsbD8gSWYgbm90LCB3aHkgbm90 PykNCj4gDQo+IEnigJltIG5vdCBhZ2FpbnN0IHRoZSBSUEMgYmVpbmcgYW4gZXgtb2ZmaWNp byBtZW1iZXIsIGJ1dCBJIGRvIHRoaW5rIHRoYXQgaWYgdGhhdCBpcyB0byBiZSBwYXJ0IG9m IHRoZSBtb2RlbCB0aGVuIHRoZSBtb2RlbCBzaG91bGQgYWRkcmVzcyBhbnkgY29uZmxpY3Rz IG9mIGludGVyZXN0IGZyb20gdGhhdCBleC1vZmZpY2lvIHJvbGUuICBJIGdvdCB0aGUgaW1w cmVzc2lvbiB0aGF0IEpvaG4gYW5kIFBldGVyIHdlcmUgY2xvc2UgdG8gdGV4dCBvbiB0aGF0 LiAgSSBkb27igJl0IGJ0dyBzZWUgYW55IHNpbWlsYXIgY29uZmxpY3RzIG9mIGludGVyZXN0 IHdpdGggdGhlIEVEIGRlc3BpdGUgSm9obuKAmXMgYXR0ZW1wdCB0byBjb25zdHJ1Y3Qgb25l Lg0KDQpOb3R3aXRoc3RhbmRpbmcgZXZlcnl0aGluZyBJJ3ZlIHNhaWQgYWJvdmUsIEknbSBu b3QgYWdhaW5zdCBhbiBSUEMgDQpyZXByZXNlbnRhdGl2ZSBiZWluZyBhbiBleC1vZmZpY2lv IG1lbWJlciBvZiB0aGUgUlNBQiwgZm9yIHNldmVyYWwgcmVhc29uczoNCg0KKGEpIGl0IG1p Z2h0IGJlIG1vcmUgZWZmaWNpZW50LCBlc3BlY2lhbGx5IHdpdGggcmVzcGVjdCB0byDCpzQu NCBhcyANCmRlc2NyaWJlZCBhYm92ZSBidXQgYWxzbyB3aXRoIHJlc3BlY3QgdG8gdW5jb3Zl cmluZyBhbnkgaW1wYWN0cyBvbiANCmltcGxlbWVudGF0aW9uIG9mIHBvbGljeSBwcm9wb3Nh bHMNCg0KKGIpIGFuIFJQQyByZXByZXNlbnRhdGl2ZSBjb3VsZCBiZSBtb3JlIGxpa2VseSB0 byByYWlzZSBjb25jZXJucyBpbiB0aGUgDQpzbWFsbGVyIHZlbnVlIG9mIFJTQUIgZGlzY3Vz c2lvbnMgdGhhbiBpbiB0aGUgcm91Z2gtYW5kLXR1bWJsZSBvZiB0aGUgDQpSU1dHIChJIG5v dGUgdGhhdCBSUEMgZm9sa3MgaGF2ZW4ndCBiZWVuIGFsbCB0aGF0IGFjdGl2ZSB3aXRoaW4g dGhpcyANClByb2dyYW0pDQoNCihjKSB0aGUgUlNBQidzIHJlbWl0IGlzIHF1aXRlIGxpbWl0 ZWQgc28gaXQgc2VlbXMgdW5saWtlbHkgdGhhdCANCmluY2x1ZGluZyBhbiBSUEMgcmVwcmVz ZW50YXRpdmUgaW4gUlNBQiBkaXNjdXNzaW9ucyB3b3VsZCBiZSBoYXJtZnVsLCANCmFuZCBj b3VsZCBiZSBiZW5lZmljaWFsIGJlY2F1c2Ugb2YgcmVhc29ucyAoYSkgYW5kIChiKQ0KDQpC eSB0aGUgd2F5LCB0aGVzZSBjb25zaWRlcmF0aW9ucyBhbmQgb3RoZXJzIG1ha2UgbWUgbW9y ZSBpbmNsaW5lZCB0byANCnNwZWNpZnlpbmcgdGhhdCBSU0FCIGRpc2N1c3Npb25zIHNob3Vs ZCBiZSBwdWJsaWNseSBhcmNoaXZlZCBhbmQgd2VsbCANCm1pbnV0ZWQuIFRyYW5zcGFyZW5j eSBpcyBpbXBvcnRhbnQgaGVyZS4NCg0KUGV0ZXINCg== From nobody Thu Dec 16 16:59:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF0613A09AC for ; Thu, 16 Dec 2021 16:59:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 YF2jSu-v3157 for ; Thu, 16 Dec 2021 16:59:18 -0800 (PST) Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 693683A09A8 for ; Thu, 16 Dec 2021 16:59:18 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id z18so837212iof.5 for ; Thu, 16 Dec 2021 16:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=K2xE1tIspru9wwWVeSOWqUdbuYdR1P2/DQl/dqo7XtM=; b=LBBLRr/hMcayyRa0KMAz1xhBG9qYoHIZRg4O5Gzi7TU4Z94h8uP0FK2/Rh60FyDx+m C0ba0+5oO6TmQS9N+e7WHBUBBsgY44rUJj25hZPn+kv2Uc5LadtJxRywFlM5du8Vh8Vy KF6YZeA3z/xs1VCBKjG0jqtfUfyxdBdnYDkM6ezInYxoRjn99lsQ7aunyBpvHMELG16U wg+5RFsrQPrZAZKNpTiMo0u74dRiCwoliTLG9KM8SevARBNZ6rLvtYYiyfzXrJ5TgLea 73LyhNHIK1R6AZ4vASB9wX3pWnwt/5y+HEpbIwWATyXZbFVrdf4HMiphwjw6+76d2Hxr fYxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=K2xE1tIspru9wwWVeSOWqUdbuYdR1P2/DQl/dqo7XtM=; b=7LPOjL1edd5dojnNw+9hrvwoT6MmeTbo599PxjTqhrYM6RLetVUSr2OHPtQLegm/X5 j1QAP7zj2UldxePFcNBSm+y1On+gu2LQ91S9UhUIQQl6zh4CQH1JUaDTfNmzdBK+sKbB ENpbR4kXOFvoo5SIx7EVN4gfSrg/iQ5+5ComxXm8Vy6NIsDk23KzAkD6eQ2Sja77reMl efJIpuN9uv4zgkMmqgEpwrO+feV6owmcISR1dAbKYcUFUfts9b4weahMDU9MNC//QXVP TqwpZ6j8CjzZeDc5dJanfQFAyIqriQDzCp4mYoks8o6e3+U0JhrqXTQSm5bOEmymcOjM TgkA== X-Gm-Message-State: AOAM5338pRQXKX8dBU7U59bYbWZ9sU/03S/uqMmwAakCbu9un4r8qu+s UnOOv7JtDUti1+m4BSEl9M6U9L67v16h+xiA7gM9iQ== X-Google-Smtp-Source: ABdhPJy7eHIQLuyWVLlzjvb6wvMks6+i467ZqJHXe2N8xqheLjvjav/g5XWGr8ZQ2+PRuHeC8k6KL/I+4xWPz6XY3Y4= X-Received: by 2002:a05:6638:2727:: with SMTP id m39mr339736jav.75.1639702757104; Thu, 16 Dec 2021 16:59:17 -0800 (PST) MIME-Version: 1.0 References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <075d00fe-a1b5-5ae4-7f23-239b634e979c@stpeter.im> <279b36f7-fbaf-1b9c-4bda-bcf36a8eef51@nthpermutation.com> <5e2b5b72-26ab-f5fe-a6ec-badc8721fdd0@nthpermutation.com> <5607f34c-1b06-e05f-8d20-1f80c1b4a27b@nthpermutation.com> <3ce60640-c942-cd1c-2bb4-96e2bcb79d6c@gmail.com> In-Reply-To: <3ce60640-c942-cd1c-2bb4-96e2bcb79d6c@gmail.com> From: Eric Rescorla Date: Thu, 16 Dec 2021 16:58:40 -0800 Message-ID: To: Brian E Carpenter Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000005fefaa05d34d0c9f" Archived-At: Subject: Re: [Rfced-future] Fwd: RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:59:23 -0000 --0000000000005fefaa05d34d0c9f Content-Type: text/plain; charset="UTF-8" On Thu, Dec 16, 2021 at 4:43 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > Eric, > > On 17-Dec-21 11:01, Eric Rescorla wrote: > ... > > > The underlying theme of this work is that the *community* decides. We > have constructed the RSAB as a limited check on that and it reflects > certain equities, but I don't believe that applies to the RPC. > > > I would expect that if the RSWG reaches consensus on a policy that the RPC > considers unworkable (and RPC people have made this clear during the RSWG > discussion), the RPC would anyway raise the issue with the ED, who is a > non-voting RSAB member, as well as with the RSCE. > Yes this is what I would expect as well, which is part of why I don't believe that we need a separate RPC liaison. -Ekr > Brian C > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000005fefaa05d34d0c9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Dec 16, 2021 at 4:43 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
Eric,

On 17-Dec-21 11:01, Eric Rescorla wrote:
...

> The underlying theme of this work is that the *community* decides. We = have constructed the RSAB as a limited check on that and it reflects certai= n equities, but I don't believe that applies to the RPC.


I would expect that if the RSWG reaches consensus on a policy that the RPC = considers unworkable (and RPC people have made this clear during the RSWG d= iscussion), the RPC would anyway raise the issue with the ED, who is a non-= voting RSAB member, as well as with the RSCE.

Yes this is what I would expect as well, which is part of why I don&= #39;t believe that we need a separate RPC liaison.

=
-Ekr


=C2=A0 =C2=A0 =C2=A0Brian C

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000005fefaa05d34d0c9f-- From nobody Thu Dec 16 17:31:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C04173A0C53 for ; Thu, 16 Dec 2021 17:31:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, 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.20210112.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 Qim1K-UDDOt7 for ; Thu, 16 Dec 2021 17:31:48 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08B243A0C50 for ; Thu, 16 Dec 2021 17:31:47 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id f20so1146417qtb.4 for ; Thu, 16 Dec 2021 17:31:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=VO1B/uMk0Jw2Ca+jGcq1jLj4YgZiJlontJkVc+c15aA=; b=56NBNA7FBvJ73NXs5iuKAICDGnOCHbMk6Qwdh4zAI5J4LxtoGIRNntFB1eR9Fu0MSy mOOfs9645peM8MJgwhE5ppYGJRz3xG+xNwmuawtuIpCz0SqYU/cPm+eGOm5/YM9SY5tU YSqAVovbRd5oDFzrEZNHtoSM1TmwYYJO0DzamKwjyh7j61UDtId5wgCzBCFqQjsQ6yYb 78Fo91Rm1LPAVnJG+r5RA0B8mAetVuS74YPCo5V0zZqXWfSjVU06fhU30ZEAXmzwY3+y tkvqxwo6PyxWITx+W6x9NO0BcXtwCL7Ra39nJPTUGEMnaEcGrJqf+gj09X1v7toPJQLv FLag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=VO1B/uMk0Jw2Ca+jGcq1jLj4YgZiJlontJkVc+c15aA=; b=bq/ZkGTOnSYBFeLk3I4cBa3ODoy5fQiS+9r6U7WI2if3UaRSTi5k4zsbfRDomBAYMb mxC9YQdn7ceBfAw3t42moc7/2x+nhPjFHHLjkd6pd/x6Csfjw3uc8HRHmkogOTQ7BrXC PDSQ1c5tsyrtYo/DmJcmhCD1+py7N9XczEgbp40InEtjyeplU4EL0nQh+IoiX5L9VbwK 4MvIFraBcpaFV/99n/XQKZEEye/JK8HNC4NNtrXiExFhn8T7bYgfCmKQKrrD0ZUUL1mk kxXT1fgvMUM7KptT7ZOcJZfOshJkjatEaqhi/xDL7PqeDUWAR9fvdGZ/EQrj4AqvEi3C GvMA== X-Gm-Message-State: AOAM530ohupBMz6e56g+oBL3KygvZk0/l6C3Ni1xaqzVNS8LlSPjLEVs +7kB6YI/HT89K6Nd+Na/f492Rf3lAp99bpeI X-Google-Smtp-Source: ABdhPJxLv5MpzTfgbXHQaEBz9+50mtoIoTuejbo4vwSlPJQAH/iSJQnHvc34m9FqFtVEf2mSseABwQ== X-Received: by 2002:a05:622a:118b:: with SMTP id m11mr616830qtk.165.1639704705661; Thu, 16 Dec 2021 17:31:45 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id j9sm3863035qkp.111.2021.12.16.17.31.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 16 Dec 2021 17:31:45 -0800 (PST) Message-ID: Date: Thu, 16 Dec 2021 20:31:43 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Peter Saint-Andre , Jay Daley Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> From: Michael StJohns In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 01:31:50 -0000 On 12/16/2021 7:58 PM, Peter Saint-Andre wrote: For context only > NEW > >    3.  The RSWG shall then further discuss and develop the proposal. >        Members of the RSAB are expected to participate as individuals in >        all discussions relating to RSWG proposals so that they are fully >        aware of proposals early in the policy definition process, and so >        that any issues or concerns that they have will be raised during >        the development of the proposal, not left until the RSAB review >        period. This: > Representatives of the RPC should also participate so >        that any impacts on implementation of proposed policies are >        raised and addressed early in the process. Hi Peter - I think this needs to be broken out as a separate issue. I believe that the RPC is not currently resourced to follow and participate in discussions of the intensity and type that are probable for the RSWG.  There also at least some difference in the necessary skills for reviewing a final proposal for input to the RSAB vs participating, analyzing, and injecting input in all stages of the proposal process in the RSWG.  That suggests the LLC would need to fund additional staffing (hours or person) for the RPC which may or may not be able to be made up from the current skill sets or personnel of the RPC provider.   I haven't a clue what the scale factor would be but maybe at least 3-6x?  E.g. if the RPC participating in the RSAB requires 10 hours per month,  participating in the RSWG might be require 30-60 hours?  (Both of these numbers guesses - I have no idea how much dedicated time either the RSAB or RSWG tasking to the the RPC would require, I just expect that it would be somewhat more for the RSWG than the RSAB given the relative duty cycles of each organization). That's a change in the scope of the RPC that I don't think we've contemplated before and one that I'm not entirely comfortable with. Later, Mike ps - I'll get back to the rest of your note later - its well thought out, but I need a break from typing. From nobody Thu Dec 16 22:32:45 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D027E3A15FF; Thu, 16 Dec 2021 22:32:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpOThYcl3MWS; Thu, 16 Dec 2021 22:32:36 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 E5E253A15FC; Thu, 16 Dec 2021 22:32:34 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BH6WRmM447726 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 17 Dec 2021 07:32:29 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639722750; bh=2mUPUWtgX2uspY4x+XY1nGh6og4TkAivypepERD5FO4=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=FUsOOV7i4AOP07SQyxn0eqrWGRWo+BaHszuGzfsr58T9g/BGmDxIqZYsDhw1n8eie dRLnQ4S05kftc2DmKlbVzGNT7gGQc/Bh+NxUv2e/0i+sChq0UqqYvymOVv5UGm6WwY 6f4BTEnQC71NfjQq4hpRHTqZOL2odIzCXX2OiQMg= Message-ID: Date: Fri, 17 Dec 2021 07:32:27 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: John C Klensin , Michael StJohns , Jay Daley Cc: Peter Saint-Andre , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> From: Eliot Lear In-Reply-To: <8DD8DC80C6CD5605BDD0E07B@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------COUBpk6IRSegGgyj0r0N30Oe" Archived-At: Subject: Re: [Rfced-future] Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 06:32:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------COUBpk6IRSegGgyj0r0N30Oe Content-Type: multipart/mixed; boundary="------------e6G05QOaDexbGSJoPu6Dt1Tm"; protected-headers="v1" From: Eliot Lear To: John C Klensin , Michael StJohns , Jay Daley Cc: Peter Saint-Andre , rfced-future@iab.org Message-ID: Subject: Re: Relitigating (was: Re: [Rfced-future] RPC liaison to the RSAB) References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> In-Reply-To: <8DD8DC80C6CD5605BDD0E07B@PSB> --------------e6G05QOaDexbGSJoPu6Dt1Tm Content-Type: multipart/mixed; boundary="------------BzMj5E0kXpyotujKrK15iUVh" --------------BzMj5E0kXpyotujKrK15iUVh Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 Sm9obiwNCg0KT24gMTcuMTIuMjEgMDE6NDQsIEpvaG4gQyBLbGVuc2luIHdyb3RlOg0KPiAo MikgV2hpbGUgSSBzeW1wYXRoaXplIHdpdGggYW5kIHNoYXJlIHlvdXIgZGVzaXJlIHRvIGtl ZXAgbW92aW5nDQo+IGZvcndhcmQgYW5kIHRvIG5vdCByZXZpc2l0IHNldHRsZWQgaXNzdWVz LCBvbmUgdGhpbmcgd2UgaGF2ZQ0KPiBvYnNlcnZlZCBiZWZvcmUgaXMgdGhhdCBtYW55IG9m IHRoZSBpc3N1ZXMgZmFjaW5nIHVzIGFyZQ0KPiB1bHRpbWF0ZWx5IHJlbGF0ZWQgdG8gZWFj aCBvdGhlciBpbiBjb21wbGV4IHdheXMuDQoNCkkgd291bGQgYWdyZWUgaWYgdGhlIG1hdHRl ciB3YXMgZ2l2ZW4gb25seSBsaWdodCBjb25zaWRlcmF0aW9uLiBUaGF0IHdhcyANCk5PVCB0 aGUgY2FzZSBoZXJlLsKgIFJlbGl0aWdhdGluZyBpcyBkaXNyZXNwZWN0ZnVsIHRvIHRoZSBw ZW9wbGUgd2hvIGhhdmUgDQpuZWdvdGlhdGVkIGluIGdvb2QgZmFpdGggdG8gY29tZSB0byBh biBhZ3JlZW1lbnQsIHBhcnRpY3VsYXJseSB3aGVuIHRoZSANCnVuZGVybHlpbmcgZmFjdHMg b24gdGhlIGdyb3VuZCBoYXZlbid0IGNoYW5nZWQsIGFzIGlzIHRoZSBjYXNlIGhlcmUuwqAg DQpUaGF0IGxlYWRzIHRvIHBlb3BsZSBkZXBhcnRpbmcgdGhlIHByb2Nlc3MgYW5kIFRIQVQg d2Vha2VucyBjb25zZW5zdXMsIA0KYW5kIHRoYXQgbm9uZSBvZiB1cyBzaG91bGQgdG9sZXJh dGUuDQoNCkVsaW90DQoNCg0K --------------BzMj5E0kXpyotujKrK15iUVh Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------BzMj5E0kXpyotujKrK15iUVh-- --------------e6G05QOaDexbGSJoPu6Dt1Tm-- --------------COUBpk6IRSegGgyj0r0N30Oe Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG8LvsFAwAAAAAACgkQh7ZrRtnSejNg 4wgAlRob/DIWo5nsYA4ez8suctekP+g+RBaOuwXuZ6SBRpoCFCN9u2tgF/RI1ou81ITqH6EAreZs OMzw7OrgqswiXhtuneHOlU0Kw3u8b6i9PhAoFnnU3axKAKlpOXuCtI5Wojgr1XSkvhsx06jAsFXy dG0dL21VsWGZnsaKsnKEKwNi2ydWl9lm2lVW7FE0YC7zoDe0SzZ+CyAvfAWr+M0cGqYO5hKowcYA zoIl1W0TILvdM5dThGfq2s6XDHILHoMkHkl8578OrER+5H2TawTIGoA1iH8DxoYGYjkxBcqJby9V W9tZSZ44nSk/kU75RrF4l3l+VCd6pV51+xZFjxBPfg== =97+d -----END PGP SIGNATURE----- --------------COUBpk6IRSegGgyj0r0N30Oe-- From nobody Thu Dec 16 23:03:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3815A3A1681 for ; Thu, 16 Dec 2021 23:03:04 -0800 (PST) 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_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mWm3wfnaiweu for ; Thu, 16 Dec 2021 23:02:58 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 993C93A1680 for ; Thu, 16 Dec 2021 23:02:58 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BH72sro462668 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Fri, 17 Dec 2021 08:02:55 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639724575; bh=EKQrj1fqukj9eus773g4Mk8dZokJH3J6RKFAd0/NcZc=; h=Date:To:From:Subject:From; b=XuuvfX4wjQFB0Ai69A7KqOA70pC8papPvMuDnm5foLqQBRQEkUQNMrvYdzAzlB+uh RQ+QkRWuNwuZYpJ+i6B8iKuPCrZbM9UWbmkHzb1Qq5vgwcBoiDjjw9lWJaYUgXCjet /8h8Mo7/mbLhSxyYqA2hf7SAUFHgJrYBalS1Vnx4= Message-ID: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> Date: Fri, 17 Dec 2021 08:02:50 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------He8z7TZOKK8lTARr9UhEg9UM" Archived-At: Subject: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 07:03:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------He8z7TZOKK8lTARr9UhEg9UM Content-Type: multipart/mixed; boundary="------------B01DaC0r0fltYgL0QE1mPZQK"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> Subject: RPC liaison role --------------B01DaC0r0fltYgL0QE1mPZQK Content-Type: multipart/mixed; boundary="------------0t7KB1YOf0aGXXTz0WXDSmU7" --------------0t7KB1YOf0aGXXTz0WXDSmU7 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 V2UgaGF2ZSBoZWFyZCBmcm9tIHNldmVyYWwgcGVvcGxlIG9uIHRoaXMgdG9waWMuwqAgQ291 bGQgb3RoZXJzIHBsZWFzZSANCmNoaW1lIGluPw0KDQpFbGlvdA0KDQo= --------------0t7KB1YOf0aGXXTz0WXDSmU7 Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------0t7KB1YOf0aGXXTz0WXDSmU7-- --------------B01DaC0r0fltYgL0QE1mPZQK-- --------------He8z7TZOKK8lTARr9UhEg9UM Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG8NhoFAwAAAAAACgkQh7ZrRtnSejNa 8Qf/Sh0aMhQ3YbxrMlWrJ7fSehILAuXWeozg0dt4doSsV7sZh0QB3mDv/Jood6CZ6uRsT267KH0r h7bCvMVXXptkQomavUIJxXfLPd+5OizCqDx2qszOo+jCIM4m5lnqzYEasyMcT2E7opqX+1U76S+S ZGV1uPFg8uJ6N5Kptl1huYqqBN+rDTkIxIE/QId5sZzRFR2bN76n+4syvZ6bI9Ayuys+wLDfOMAW 3syQjGdgU+/yU+XW/pSALOMr/t4D3CoRFvuKKFAsO3J9BSRKy7yYhcvJuuVKMnLjL6LDZhRPIxZv /L3kcI20GreuN6pokuiVak8kjBcOMfZ0dQb3QTFaJA== =lEGI -----END PGP SIGNATURE----- --------------He8z7TZOKK8lTARr9UhEg9UM-- From nobody Fri Dec 17 01:13:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B69A3A1908 for ; Fri, 17 Dec 2021 01:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxOJYeLftfQz for ; Fri, 17 Dec 2021 01:13:35 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A53AF3A1907 for ; Fri, 17 Dec 2021 01:13:33 -0800 (PST) Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1BH9DUGX031048; Fri, 17 Dec 2021 09:13:30 GMT Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 656614604A; Fri, 17 Dec 2021 09:13:30 +0000 (GMT) Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5958446043; Fri, 17 Dec 2021 09:13:30 +0000 (GMT) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs4.iomartmail.com (Postfix) with ESMTPS; Fri, 17 Dec 2021 09:13:30 +0000 (GMT) Received: from LAPTOPK7AS653V ([85.255.232.196]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1BH9DSWq029803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Dec 2021 09:13:29 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> In-Reply-To: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> Date: Fri, 17 Dec 2021 09:13:28 -0000 Organization: Old Dog Consulting Message-ID: <038c01d7f326$5b9afdf0$12d0f9d0$@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: AQMPzwcfgN7zu8Z35RTJ0BvhJHy/yKnGq+5g Content-Language: en-gb X-Originating-IP: 85.255.232.196 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26594.006 X-TM-AS-Result: No--3.232-10.0-31-10 X-imss-scan-details: No--3.232-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26594.006 X-TMASE-Result: 10--3.232400-10.000000 X-TMASE-MatchedRID: 8+bhjh9TQnHxIbpQ8BhdbG7IMYi+/BbSnAOerUWXenfkMnUVL5d0E5yx oZK5UFNtOHYRQK//zyOTDZltu0btiBLmJd2F/yFu8KQMqZXaCznsmqgTaEBAI3crTFGcc+2Ylte ai6D7W36xVJeFbI50PL+vUQI/PUlYVsECnj5Uz60dZEkR8Y/meYIXoaQH2H4PP4H+2nyK0FMWM2 zIMiL0FlVg7HKukpOi6zh0Vj1AUxuZxQ0LLmG+fzkNh772QidMnuTZkvYnorQINpIFnbd6mrwua nGfW+XuFRlxiF1eFJv14SsYBsN7CRQ3/xoDO/IlNTNaqE9xDZarDPxf3LbqpCAry4BuXO87+F2Q r5gL+CrnzlXMYw4XMOYv5V7WeGfs0C1sQRfQzEHEQdG7H66TyH4gKq42LRYkYC4MKGdqMQUKvYw BlSsR3HQlnVtcVgfGCFX7wnu/gUd+3BndfXUhXQ== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 09:13:40 -0000 I can't recall whether I commented before, and I am no longer reading = the seemingly endless email exchanges on this list. At the risk of relitigating... Of course the RPC should be invited to send someone to RSAB meetings to = see things before they come down the track to them, to provide input = when needed (and a lot of what the RSAB discusses will have direct = influence on the work of the RPC), and to make observations when it = seems that the RSAB is unaware of how the RPC works. Yes, if there are executive sessions, liaisons would be excluded, but = the issue of executive sessions is not related to the question of = liaisons. Cheers, Adrian -----Original Message----- From: Rfced-future On Behalf Of Eliot = Lear Sent: 17 December 2021 07:03 To: rfced-future@iab.org Subject: [Rfced-future] RPC liaison role We have heard from several people on this topic. Could others please=20 chime in? Eliot From nobody Fri Dec 17 01:18:17 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60ED83A1929 for ; Fri, 17 Dec 2021 01:18:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWHejefEjaci for ; Fri, 17 Dec 2021 01:18:10 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791063A1928 for ; Fri, 17 Dec 2021 01:18:10 -0800 (PST) Received: from smtpclient.apple (unknown [IPv6:2a00:ac00:4000:400:c4eb:1479:77a2:3087]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 7C2B8606CF7; Fri, 17 Dec 2021 11:17:59 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1639732679; bh=H0CxaWY1H185zI4e8uIlAMe/QaojypYy1AedMdW35gA=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=EBV+9/m0/IusJooxhLsIZK2QcIPqR2Yqzyet5Lhiwvu2kpAqrs6PNV3CO4lpWaLF8 LmWDF5HMrCZ+9lcg/9Mm1tCvr8GjAC6fuHmCeJLyAp4EvDJTULW/2ROZ97pOhuYtcP q8C70j4Qm4qHiQ8FaB77QHgCToYawU1F5MeBf6r8= Content-Type: multipart/signed; boundary="Apple-Mail=_C07EB2DB-C743-4983-92F8-783E66D83117"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.40.0.1.81\)) From: Lars Eggert In-Reply-To: <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> Date: Fri, 17 Dec 2021 11:17:58 +0200 Cc: Eliot Lear , rfced-future@iab.org Message-Id: References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> To: Adrian Farrel X-MailScanner-ID: 7C2B8606CF7.A4A32 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 09:18:16 -0000 --Apple-Mail=_C07EB2DB-C743-4983-92F8-783E66D83117 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2021-12-17, at 11:13, Adrian Farrel wrote: > Of course the RPC should be invited to send someone to RSAB meetings = to see things before they come down the track to them, to provide input = when needed (and a lot of what the RSAB discusses will have direct = influence on the work of the RPC), and to make observations when it = seems that the RSAB is unaware of how the RPC works. +1 Lars --Apple-Mail=_C07EB2DB-C743-4983-92F8-783E66D83117 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmG8VcYACgkQVLXDCb9w wVchXxAAjQa0PzqJkCTDN4qzKed+vRWjvL4dR+Fsc0EC9yIpl8heenhvSe2kFX3W 0xuDVIGf6MOmeVbE1dbKwl4ktPFUSxYlFg7XYll5BR6E2MDAdSftVfrSIbwMgTm8 wJ9YYW4D2zrItJyduUbMH3TZ+dAgxXzOREHacOKpkp5DLEkmz0POQUI86e0ZzgjY g9OypiLUomV9O4B+wVbhcYb6alzMLSqS/CUc9cSbcMJHl9LN9eYsCEpbtfV5wYzB OvP5iHzEx+cpIeptJCmVbCSkbKlKFNSnJ4jc9NzSC+iyOBxDZw1uuMYJYnLoKVLg c6gYkK4Qx3ffeK5Q+Fmqx7upPMI4QqLGjTzK1cz/gnkZwFhhR2FCjECMrXnNim/z pb3rkOcEE0oG2GvIO3VIubSfOv65kGkBhICA8KNlR4mfqkQLxWhzivD5Qi4GqUb2 6YB69aXRP6Hip6FA8rKI6Rg2Ef2GV07AJIoLA7AOGdSIWxuNAj/pnN9YDqHnmtHb B8cTAXJajQEOfGjWoyt2L8IJiEKSkLi1V7bX0IM6kne/tXsOBt+tOQXa+bNT3qnw MdXba+q1q/MSt07wLdTZRhd0cURKnZw+9ioqMC93t3fp4DCAHFbP30rADvBEENLD u2tpTuv69ofKzNHADCmtW0lFiiVBy11XIe45Ai4mUFaC5otn33I= =K+ev -----END PGP SIGNATURE----- --Apple-Mail=_C07EB2DB-C743-4983-92F8-783E66D83117-- From nobody Fri Dec 17 01:31:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B4F3A1976 for ; Fri, 17 Dec 2021 01:31:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.751 X-Spam-Level: X-Spam-Status: No, score=-3.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cH2PE4DrDTdR for ; Fri, 17 Dec 2021 01:31:14 -0800 (PST) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01on20717.outbound.protection.outlook.com [IPv6:2a01:111:f403:7010::717]) (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 05DB23A1972 for ; Fri, 17 Dec 2021 01:31:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YfL3KFRNgja4M1/82b+T63aF+hRnKI9Q8CKuvonpyinjIJD21wcLXy66GHpqOV/79I1CW66pQAEJIfgjV3oUQ7vowXE1txILoSwdXUQFt0g1QRhR5AoQzpUe9Opeff92qoEP9WVLghwmmzk8V2uwjgcKX2nxhgi0SIVWq1v07JhpeJL0w5rhO9JN/a7/ejNYphE2mp4/Bp7VUJFzArQxw3ZNwj0xjR3w/+Ue+eqyqIKjY4NdtPGs/AG2hhGWhsy73uLETaKws1LKYoccJrxTYlCDrn0t5aWt0NlVdd+cT4kAE9V64EoGpgMW4RYkFY9/1mz+Qr8AH28k0WrtDOdk0A== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=tE7303aNHuOAGCLDkqfC6O2AH+bnSwgA6pYsDWb21eM=; b=QSM4rU3J21I7Df7xj99f6P1VettrxVEv9BDnG5sc0/f14d/w/cRyVlnRvozEIHplJWC8jh7gEeeeNHcdONGqPuA30E+lBodYpF4qgyAZzFmLjPpvV7fbEuD2smzmNhWaSI+sJoSzFS2G5aaB7zdvWhdXUTxkpyrg+2RpjrbpGk+9zjc4coqmvlN8q0hap30h5HhQb6MeOdMQPFk9lExBEEwhxCEsYMFePfK+aEkUBSo25mGU6tcBAoi8hxlyH1eg/dqNVGWYUpKQROuEd/qD6RrwCWIZMZlOmnfqK3OaztFAmHZQqJvwVXG2EsB+6Dj6G57kxhZ6CG4SfvAEpmh2Eg== 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=tE7303aNHuOAGCLDkqfC6O2AH+bnSwgA6pYsDWb21eM=; b=Old4AK2k4BNV5mKF5gQM9gzCc+3XDYcL5DIMFSOBnozxrqchvcZQCmkJBcQIuBH+RU/CwkSPqkjig4+LW9P+xrc5DFc6ZMJg83hF8h/GJTErHbkk9xDJ/FRoVF4H5ZMS+/2BvoCUQ7KuSvKeumyM9W5dCLFQtvBTS/Z45dpsglE= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB2316.jpnprd01.prod.outlook.com (2603:1096:404:d::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.17; Fri, 17 Dec 2021 09:31:03 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085%6]) with mapi id 15.20.4755.022; Fri, 17 Dec 2021 09:31:03 +0000 Message-ID: Date: Fri, 17 Dec 2021 18:31:03 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Peter Saint-Andre , Jay Daley , Michael StJohns Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYXPR01CA0052.jpnprd01.prod.outlook.com (2603:1096:403:a::22) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 Received: from [133.2.210.39] (133.2.210.39) by TYXPR01CA0052.jpnprd01.prod.outlook.com (2603:1096:403:a::22) with Microsoft SMTP Server (version=TLS1_2, cipher=) via Frontend Transport; Fri, 17 Dec 2021 09:31:03 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bfd004b6-6996-4804-09ad-08d9c13ff1ee X-MS-TrafficTypeDiagnostic: TY2PR01MB2316:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QKQjq5plHDlk9Ci3oRxTVg2jVxpO8PUzMGOesjJkqwyX1oOigHKZYU/n9AI/45AWDOKuGj2m2Gk6U+Tt3mYZNZuOeq7uReND+pWURURb3Bzy36NeIOYho5I4iGnUFJ8rDUQA+1c68hC1Y5LSWiZYUG2O0AEfeP6GhpGin2CJSrmWA8QKFlbiWRVMkyS/pfKgg27L7RDYHmlDMIScg7BfiL4QRZRyz+1EL2FOHnYJdpS2ZDZBVsmfy8H6aFr3iOPZkEGOYlqJT1E0cCdNsFIFC3VXS8WOUpfqsWSku5mywAR46lKGVSA8rJC4ETI3wzcwXkZQMg03xtMYCOQGwz1rACzWz7etEmjebbN1/MH0uzRTS9x0YthCtmCvYPao8/NIHdWhJnC9TgZDbOnDzD8/O7/LkEi3pBCcjZDmLv7ABBuutBtpm6fPf3YyiVeXlG9/dpfEtfHz5Rp9MxblLZVedpLIQ6NTGSr66sgFwqNK2Xio0+WWx32EiM1Ud71Ok/6wJeHO1yhaCEi5MTqHI6dJyNQCn5IBgo4fmxMEhzVPOEJFHKtnv2PY0aE8bJ8j1e5V73DNZOCTb4MBxLCSuLQ6SXYff+DXrfzPo53stJz0SmJRqkd94rCdXNTFOJcPIq1GC2vhfImw0sATUgx+UgG49+hVWXcKsAhk8tqR5LeMgjvQFSVZDVfSdJjUYkB9DUJzf2sALMtY5RWqSIoSM0A+b+8uST2op3dxO1+6UIxi/LzN+mC9wxFwuAVeP8gZaTquvnywpdgAyN3fcYx40cOEcTONMQTZhnLqaLYYeS9HI7ni7XCUAipUJ5LvmNSVjzrQxCwzB0Y9B1G0YqXCg+IYqHnNkWR+YTVUc4EaP8mAeFxIc906/JQYy2+RCFoyfB/0 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(39850400004)(346002)(366004)(376002)(396003)(136003)(5660300002)(53546011)(956004)(8936002)(2616005)(4001150100001)(966005)(83380400001)(8676002)(508600001)(26005)(6706004)(110136005)(31696002)(2906002)(86362001)(6486002)(31686004)(786003)(316002)(16576012)(38350700002)(38100700002)(4326008)(52116002)(66476007)(66946007)(66556008)(36916002)(186003)(3940600001)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?UExLRnF2QzJyZXBvU1ZvRGl2bng2Nys5amY4SFY2VEVZb2UvNTQrKzhLRnlK?= =?utf-8?B?LzNCM1p6dFV6Njd3akh2S0FEZnBQUGxSOVNtanRYWnJ2K0NOSFFubnNLL2Za?= =?utf-8?B?K0pCeWR3dy9pVUg5MDZITmt3V2xxQ3N1TEVCZ3pMaE00c0tNakM3TzFnU20w?= =?utf-8?B?QjlWaEZZcmliZ0VZZ2tZSjEzeW5TSDJEczVJRGZIa3JaQmpscUl2b3haSEJO?= =?utf-8?B?YjJ3SHJXYmhNaVNiYmtrUDd0Tkd5S2xVMUtxMHdlT1BKVE85S25yTmN3YlZT?= =?utf-8?B?YTJ1bVBKUEdCK1lwWThydFZoTG1OdSt2cmdxRld1RVpaOWM0MS9TSWxjUy9S?= =?utf-8?B?OGZONm5iY1gvaXFrT1VUQTFwT0tmMVFGVnQvQjdkb3FrMXFjMVJiQlFzYm1D?= =?utf-8?B?WXcvbFlqdVhGaWhRTTZiZDQ5elBYY1B0WlhTVTVWSTZ3UEhRcXVyRksvM0p4?= =?utf-8?B?RTBzWmpiQmdQbHhUeEQ5Q1hOY0FnZ2V1Y1FXb2RscU9VUVBlUC82QUJLbEZ0?= =?utf-8?B?ZWVJY3N6dFprV0E0d2VGYk1YL1FxODNSQVFydUZKUTNTUTJBaE5yZFArZkZx?= =?utf-8?B?eERjdm9nWEwzNkpDdVlreXBRakUyT2hVbHE0bERkVzM0RkdNYmZBNy9uVjN3?= =?utf-8?B?Mk1Tcmp0MWZWeXFzbDYvZGx6UnlSM1pvZ01IYzVLWXNDL2hadjF4c2hQNGRp?= =?utf-8?B?YzJGTklRYk1YL3RXenlxV3laaG80R0lselBiWFNEWURLendBUXdGS2RHZGdx?= =?utf-8?B?U2dSUzFHUFB5Ylp2ZzRwbzRJa1pvMGYwQS9jbEQ5cEdudU9hQk1XYk1SeWFI?= =?utf-8?B?MmtnUmpTYVpQNHJZVXlHazlIb05VRWJpOXJjelhWSkxlY1NYck1xRGg5MVRu?= =?utf-8?B?YVc3ckVQVmp5UnNiU2pXQlFoVmIxOXNZbGRvbUV4TVBTTVFYc0NxYno3SmJT?= =?utf-8?B?MG1DV2ZhZVR0Vk8xaW13aTVsb0Y1Y2c2WVZEQ1JOUnQyUzM5YmFmUExPck5h?= =?utf-8?B?UDNtQ2FhRXB6bTZ4bHl6VEtSaFJ1ZXBrbHdPS3FVTzhTdENjbURJVjV2VytP?= =?utf-8?B?ajVYOTIwajA4bm53YmxSdTM4dktQUG0yZVZOczBaWTJhd0pWVVhJZVYrSHQy?= =?utf-8?B?TytNS2U3bHRXVUUwbnpMYnQzUElkNnVkVXg5VmJXSXVpWFBEaWhFbWlhT2NX?= =?utf-8?B?N1hFbmsyODBwMmdCRlYzQVhjM2FlSDhGSENpWEd0T2JNWVV4a3BrQUtKdjF2?= =?utf-8?B?VWZsNGxyWHdJblJWYUpPYWhIYkJ0NjZCUFEzejNhSmd4RnVpc2tBVTBxT2h1?= =?utf-8?B?K0JMWjI0SGVCSUFKSzl6VUwrTU5KckpNeVNFRWwvWUpSVlBkZE5aU0t1NGdp?= =?utf-8?B?b0dXWHF5a0Fwa1Z6MmNSRDdWcWYxb3J3ZHNVQk5ERVUvTHlFRnp0YW95Q3dR?= =?utf-8?B?QVNHVkZ1Vy9Ed3pYRXEwVXlmbFBEak54TmpCWDcrcWJoMWlIY3pJOGFEM25X?= =?utf-8?B?WDZ6ZWdSQWlDL3AvZktGaXgwbWVpN1Q4WEtCeUV2U3FhYXBRMHQxUUJKTjdi?= =?utf-8?B?c0oyLzBYOWY5YUZhNmV3RDZqTllmQ1dFaVJTUk1BOWdIZ0JBMTRXYTJjWG5m?= =?utf-8?B?MUxHUFNKc2M3ZXRndGdma3kvSTdBR2dWU3F3RlA0SFFPWkdQcHlzenhDbnZT?= =?utf-8?B?aGVTbDVIMVBhSzJXQ01XNXgzVEIyUktOd1V5Wi9xT3dlVm1nRXJydGhLZDZ6?= =?utf-8?B?alhzVGtiOWJFejVyYSt2aldpM0JJTVZVbTFjOTZhSDlUbm9ybWZCWExZb25I?= =?utf-8?B?VW1yaU5VS1hveUxPc3JhU3BlYTVJQWJZaXRuNFp5c0hucVhXbmRuTU5VYmxC?= =?utf-8?B?V1RHMjhiWWU3Tk9UZ05kMzVBcW5GdFpYN01DSTRhWjFZV3ZVWWFHOU9KTk5t?= =?utf-8?B?eGVXMEQ5WkpvS2FFVmpodVFxTXYyNkUzeXoxNkJXM0d2aWp6amQrajdpNUxM?= =?utf-8?B?ZDFtZkRicjVZNHhESjdFNi9LMlFQUWdwY3NpNnRxOHhjUnJkS29DWEtWckI5?= =?utf-8?B?SjJ4UVFwQVZRMzM3eDVUS1luOSt3SXZzbjRHOGlqbENqdmtVNXZvUzZHK3hL?= =?utf-8?B?ME1GdTJqUnE1SzJVajhoYVJEQXNLVTcxNXdLZ016S2k0QjYvTzRmOG15MGVi?= =?utf-8?Q?+zI8ls3tZEPWMZocBJhreTE=3D?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: bfd004b6-6996-4804-09ad-08d9c13ff1ee X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2021 09:31:03.8157 (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: yKG9SFRio69I/3Jw1kODK5WSz4T+f4hoXk8tochVGDo3RjNVEUlDnAolM/eU7A6nVR3IJ3Qw6d6vxHTDxCX+MQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2316 Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 09:31:19 -0000 Eliot has asked for others to chime in to this discussion, so I'm trying to do that. I think it would be best to give the RPC an ex officio (of course non-voting) position on the RSAB. The reasons for this have been given by Michael, mainly in https://mailarchive.ietf.org/arch/msg/rfced-future/1qAC9KXjE2vHQC5WfHvnpMT97x8 (the mail that starts with "Top posting because"), Jay, and by Peter below at the very end. To summarize, if it's beneficial to have somebody from the RPC around anyway, then we should make that so. Details (executive session of the RSAB yes/no,...) can be worked out. One more minor point way below. Regards, Martin. On 2021-12-17 09:58, Peter Saint-Andre wrote: > On 12/16/21 1:30 PM, Jay Daley wrote: >> >> >>> On 17/12/2021, at 8:50 AM, Michael StJohns >>> wrote: >>> >>> Top posting because. > > Mike, I sure wish you'd take up interleaved replies - they're much > easier to follow. :-) > >>> Eliot - Generally the role of the chair is to elicit both points and >>> rationales and engender a discussion, not to pick one point as the >>> true answer and require the other side to attack it. >>> >>> In this case, I think there's substantial commentary on why the RPC >>> should have a seat at the table.  And little commentary on not beside >>> "let the RSAB decide". >>> >>> For your points below: >> >>> 1) > > That is (from Eliot's email): "Approve or disapprove RSWG work," > >> If the RSWG is proposing something that will impact the RPC's work, >> work flow, LOE, costs, SLA etc, having the RPC be able to explain >> exactly what will need to change to support the proposal, and >> explaining what could be moved around to make things work seems to be >> a useful input into whether the RSAB approves a document or returns it >> with comments to the RSWG.   Given that pretty much any document that >> describes functional albeit strategic changes will involve the RPC and >> that I would be surprised if there are many non-functional (changes >> not affecting function) proposed by the RSWG, it just makes sense that >> the RPC be included.  Filtering all that through the ED is not a) >> scalable (how much more gets piled on to Jay or his successor?), b) >> efficient (e.g. a pre-meeting with the ED and the RPC to prepare the >> ED for the RSAB meeting), c) error-free (think the game of >> "Telephone").  In fact having both the ED and the RPC there may mean >> that small tweaks can be approved quickly as both sides of the >> contract would be represented. >> >> The ED cannot represent the RPC on the RSAB, act an intermediary or >> otherwise replace direct contact between the RPC and the RSAB. > > I do think Jay makes an important point here. > > However, going back to Eliot's note, everything that Mike says about > impacts on the RPC should have been covered in the RSWG long before the > RSAB gets around to voting. As Ekr says, this is supposed to be a > community-driven process and RPC folks should make sure their voices are > heard very early on, not late in the process. In fact, we might want to > alter our text in the workflow section along these lines: > > OLD > >    3.  The RSWG shall then further discuss and develop the proposal. >        Members of the RSAB are expected to participate as individuals in >        all discussions relating to RSWG proposals so that they are fully >        aware of proposals early in the policy definition process, and so >        that any issues or concerns that they have will be raised during >        the development of the proposal, not left until the RSAB review >        period.  The RSWG chairs are also expected to participate as >        individuals. > > NEW > >    3.  The RSWG shall then further discuss and develop the proposal. >        Members of the RSAB are expected to participate as individuals in >        all discussions relating to RSWG proposals so that they are fully >        aware of proposals early in the policy definition process, and so >        that any issues or concerns that they have will be raised during >        the development of the proposal, not left until the RSAB review >        period.  Representatives of the RPC should also participate so >        that any impacts on implementation of proposed policies are >        raised and addressed early in the process.  The RSWG chairs are >        also expected to participate as individuals. > >>> 2) > > That is (from Eliot's email): "Provide guidance to the RPC regarding > certain inter-stream conflicts," > >> This one seems obvious - the RPC brings things to the RSAB for >> discussion.  Having a seat at the table to add things to the agenda vs >> being summoned at the whim of the RSAB > > Stephen made a good point some threads ago about inflammatory language. > Could we please avoid that? Why should we think that RSAB, peopled by > people who presumably care a great deal about the Series and have > significant knowledge of the Series (and have been appointed by the > likes of the IESG or IAB), will act on whim? > >> - the equities argue for the former. I actually expect that most >> meetings (based on the RSOC's minutes) will involve RPC discussions of >> some sort under this heading. > > It's true that within RSOC there's often very productive discussion with > a representative of the RPC. However, version 3 of the model gets rid of > the RSOC and replaces it with, for the most part, community discussion > within the RSWG. > > With regard to the RPC bringing things to the RSAB for discussion, the > context here is really Section 4.4, "Resolution of Disagreements between > Authors and the RPC" (IMHO Eliot's phrasing "Provide guidance to the RPC > regarding certain inter-stream conflicts" isn't quite accurate). I noticed that too. > In this > case the RPC is already fully engaged because there's a disagreement > with an author or set of authors on an RFC-to-be. So there's no need for > "summoning" based on whim or reason. > >>> 3) > > That is (from Eliot's email): "Provide an opinion regarding feedback on > the RSCE to the LLC, and" > >> I need to get back to your other email on this point, but I'm becoming >> more and more convinced that the RSAB as a group should not be holding >> executive sessions for any reason. >> >> The problem with that is the "RSCE Performance Evaluation" [1].  If >> you recall, we had a long conversation about this process requiring >> both community input and community review of the ED’s recommendations. >> >>>    This task for the RSAB only really makes sense if all of the RSAB >>> members excluding the RSCE were from their appointing organizations >>> and were long-lived in the job - and neither of these appear to be >>> guaranteed to be true.  In any event the presence of this task >>> neither argues for or against non-voting ex-officio members. > > Mike, do you see a special role for the RPC on point #3 or can their > feedback be gathered as any other community feedback would be? As far as > I can see, an RPC representative would not need to be an ex-officio of > RSAB in order to provide this kind of feedback. > >>> 4) > > That is (from Eliot's email): "Address certain appeals." > >> The ED doesn't have a role in the appeals process, but is still >> included as ex-officio so the presence of this task neither argues for >> or against having the RPC having an ex-officio member.  It's possible >> that both the ED and the RPC might have useful input into a given >> appeal which might be missed if either is excluded from the discussions. > > Here again I don't see a special role for the RPC regarding appeals to > the RSAB of behavior by the RSWG or RSWG chairs. > >>> I look forward to the opponents of the RPC being ex-officio providing >>> related commentary - e.g.  a) why should a random membership of the >>> RSAB decide whether the RPC relationship is ex-officio or something >>> else? b) how often should they decide this (e.g. everytime a member >>> changes out?  each meeting? each year? never?), c) what is the >>> difference between an ex-officio member and one that gets invited to >>> every meeting (e.g. is the difference that the RPC by rule sits mute >>> until asked about something?  Should that rule apply to the ED as >>> well? If not, why not?) >> >> I’m not against the RPC being an ex-officio member, but I do think >> that if that is to be part of the model then the model should address >> any conflicts of interest from that ex-officio role.  I got the >> impression that John and Peter were close to text on that.  I don’t >> btw see any similar conflicts of interest with the ED despite John’s >> attempt to construct one. > > Notwithstanding everything I've said above, I'm not against an RPC > representative being an ex-officio member of the RSAB, for several reasons: > > (a) it might be more efficient, especially with respect to §4.4 as > described above but also with respect to uncovering any impacts on > implementation of policy proposals > > (b) an RPC representative could be more likely to raise concerns in the > smaller venue of RSAB discussions than in the rough-and-tumble of the > RSWG (I note that RPC folks haven't been all that active within this > Program) > > (c) the RSAB's remit is quite limited so it seems unlikely that > including an RPC representative in RSAB discussions would be harmful, > and could be beneficial because of reasons (a) and (b) > > By the way, these considerations and others make me more inclined to > specifying that RSAB discussions should be publicly archived and well > minuted. Transparency is important here. > > Peter From nobody Fri Dec 17 04:27:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D267D3A0B64 for ; Fri, 17 Dec 2021 04:27:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.943 X-Spam-Level: X-Spam-Status: No, score=-3.943 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BafNUx_y36Nn for ; Fri, 17 Dec 2021 04:27:40 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 394853A0B66 for ; Fri, 17 Dec 2021 04:27:39 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BHCRZMU619363 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 17 Dec 2021 13:27:36 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639744057; bh=kAVH/X3cf7RmADwg28wjuS4xPzOLNcmQpdM3+0WxICM=; h=Date:Subject:To:References:From:In-Reply-To:From; b=A31v+p+vZL14faisUQODkLaO48Aioty3azf5Df9YbVvYiCp96+S4rxi2Bb++djo8o TG0bZHPHJeu+PcsdIzfWHwBssae5kKugjmRrypd7kQC8zMdfOUdC4NM58CAtjUeFuH smcF2G+zama6DyvsmJqp4IoJoAjG67KyWBEQpCsE= Message-ID: <716dc6ae-28a7-4474-2085-6e2b3f283c8c@lear.ch> Date: Fri, 17 Dec 2021 13:27:34 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: adrian@olddog.co.uk, rfced-future@iab.org References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> From: Eliot Lear In-Reply-To: <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------LSxQ4Aq8HIjbx68DyfhziRXb" Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 12:27:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------LSxQ4Aq8HIjbx68DyfhziRXb Content-Type: multipart/mixed; boundary="------------Y1wrFuO9d6ojQkGQv5thu2hA"; protected-headers="v1" From: Eliot Lear To: adrian@olddog.co.uk, rfced-future@iab.org Message-ID: <716dc6ae-28a7-4474-2085-6e2b3f283c8c@lear.ch> Subject: Re: [Rfced-future] RPC liaison role References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> In-Reply-To: <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> --------------Y1wrFuO9d6ojQkGQv5thu2hA Content-Type: multipart/mixed; boundary="------------8JgjD9XN5ugUQv39Z5w7C0Zo" --------------8JgjD9XN5ugUQv39Z5w7C0Zo Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VGhhbmtzIEFkcmlhbi7CoCBKdXN0IG9uZSBwb2ludDoNCg0KT24gMTcuMTIuMjEgMTA6MTMs IEFkcmlhbiBGYXJyZWwgd3JvdGU6DQo+IE9mIGNvdXJzZSB0aGUgUlBDIHNob3VsZCBiZSBp bnZpdGVkIHRvIHNlbmQgc29tZW9uZSB0byBSU0FCIG1lZXRpbmdzIHRvIHNlZSB0aGluZ3Mg YmVmb3JlIHRoZXkgY29tZSBkb3duIHRoZSB0cmFjayB0byB0aGVtLCB0byBwcm92aWRlIGlu cHV0IHdoZW4gbmVlZGVkIChhbmQgYSBsb3Qgb2Ygd2hhdCB0aGUgUlNBQiBkaXNjdXNzZXMg d2lsbCBoYXZlIGRpcmVjdCBpbmZsdWVuY2Ugb24gdGhlIHdvcmsgb2YgdGhlIFJQQyksIGFu ZCB0byBtYWtlIG9ic2VydmF0aW9ucyB3aGVuIGl0IHNlZW1zIHRoYXQgdGhlIFJTQUIgaXMg dW5hd2FyZSBvZiBob3cgdGhlIFJQQyB3b3Jrcy4NCg0KVW5kZXIgdGhlIG1vZGVsIHdlIGFk b3B0ZWQgZnJvbSB5b3VyIHByb3Bvc2FsLCBpdCBpcyBzdGlsbCBpbXBvcnRhbnQgDQp0aGF0 IHNvbWVvbmUgZnJvbSB0aGUgUlBDIHBhcnRpY2lwYXRlIGluIHRoZSBSU1dHLCByZWdhcmRs ZXNzIG9mIGhvdyB0aGUgDQpsaWFpc29uIGlzc3VlIGdldHMgYWRkcmVzc2VkLsKgIE90aGVy d2lzZSwgdGhlIFJTQUIgY291bGQgYmUgZm9yY2VkIHRvIA0Kc3VycHJpc2UgdGhlIFJTV0cs IHdoaWNoIGlzIHNvbWV0aGluZyB3ZSBoYXZlIHNhaWQgd2UgZG9uJ3Qgd2FudCB0byBzZWUg DQpoYXBwZW4uDQoNCkVsaW90DQoNCg== --------------8JgjD9XN5ugUQv39Z5w7C0Zo Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------8JgjD9XN5ugUQv39Z5w7C0Zo-- --------------Y1wrFuO9d6ojQkGQv5thu2hA-- --------------LSxQ4Aq8HIjbx68DyfhziRXb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG8gjYFAwAAAAAACgkQh7ZrRtnSejNH aAgAr1QRkCXZ29KnUNVT32A3U9UKRWc75NPpOZH9/jQ1gZJb1I3D8IVa2pj1b/QU/7oPXwGwNbMQ i9d+Bt2L8HItcv3i2VfIIOoEkk2FJPUVb/RHXXstk1303U5xT9CrUhDworfEaEgHhnIITxNTO98A dEVI1LaiI6676/puA//wEz/vIngynUYUUgYZKSvsiWjY52R0NQSTbzyYFhy3TONHIffXtmqfiFWC JR66qCY8mdaz+oSDneJbrxl9WXtSCw1KlfsQFCv34xJqBo+NJRW2Hd1KqpRu8rcd2d8DdaOEBegS c9MVKmAqNfjhau69fl8AsSDzGDQ284cn3na3e+QEWQ== =RWD6 -----END PGP SIGNATURE----- --------------LSxQ4Aq8HIjbx68DyfhziRXb-- From nobody Fri Dec 17 06:59:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728CB3A116D; Fri, 17 Dec 2021 06:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jfAprbuQB5o; Fri, 17 Dec 2021 06:59:47 -0800 (PST) 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 8523D3A116A; Fri, 17 Dec 2021 06:59:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1myEhx-000FwE-T0; Fri, 17 Dec 2021 09:59:41 -0500 Date: Fri, 17 Dec 2021 09:59:35 -0500 From: John C Klensin To: Eliot Lear , Michael StJohns , Jay Daley cc: Peter Saint-Andre , rfced-future@iab.org Message-ID: In-Reply-To: References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> 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] Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 14:59:53 -0000 --On Friday, December 17, 2021 07:32 +0100 Eliot Lear wrote: > John, >=20 > On 17.12.21 01:44, John C Klensin wrote: >> (2) While I sympathize with and share your desire to keep >> moving forward and to not revisit settled issues, one thing >> we have observed before is that many of the issues facing us >> are ultimately related to each other in complex ways. >=20 > I would agree if the matter was given only light > consideration. That was NOT the case here.=C2=A0 Relitigating = is > disrespectful to the people who have negotiated in good faith > to come to an agreement, particularly when the underlying > facts on the ground haven't changed, as is the case = here.=C2=A0 > That leads to people departing the process and THAT weakens > consensus, and that none of us should tolerate. Eliot, Procedurally, I'm disappointed by this response. The assertion was that key assumptions and decisions (whether characterized as "facts on the ground" or not) had changed since the time of the careful discussions to which you refer. _If_ they have, then reviewing that earlier discussion would seem to be entirely in order. Indeed, I suggest that if "we spent a lot of time on that and people reached their conclusions after good-faith negotiations, so the topic cannot be reopened", we'd still be running NCP on the network. Sometimes externalities change or, if you want to pursue the legal analogies, new evidence is discovered. Now, it would have been, IMO, entirely reasonable had you said something more like "we've been there and made a decision, we (the co-chairs) believe that nothing substantive has changed, and so, unless someone can provide clear evidence that the assumptions that went into that decision are no longer correct, do not bring it up again". =20 But what you did say sounds more like something others have suggested you are doing: making a decision and then telling those who might disagree that the burden of proof is on them and that you get to determine the rules for discussion. Even the perception of that is bad for the discussion and bad for claims that the ultimate conclusions of this group represent broad, or even rough, consensus of an informed and representative subset of "the community". =20 I, too, am concerned about people leaving the process and my concerns/ complaints about very high mail volumes and repeated arguments are very much part of that. But I don't think moving things along by chair assertion helps with that either. I do not need a response to the above. I believe the discussion has moved on and that we should concentrate on the subject matter rather than procedural discussions. But please think about it. best, john From nobody Fri Dec 17 08:11:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4FD3A0657 for ; Fri, 17 Dec 2021 08:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_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 Dw2fcLqPQ54x for ; Fri, 17 Dec 2021 08:10:55 -0800 (PST) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D13BA3A0644 for ; Fri, 17 Dec 2021 08:10:54 -0800 (PST) Received: from vs4.iomartmail.com (vs4.iomartmail.com [10.12.10.122]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1BHGApmH011229; Fri, 17 Dec 2021 16:10:51 GMT Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 624044604B; Fri, 17 Dec 2021 16:10:51 +0000 (GMT) Received: from vs4.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5632F4604A; Fri, 17 Dec 2021 16:10:51 +0000 (GMT) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs4.iomartmail.com (Postfix) with ESMTPS; Fri, 17 Dec 2021 16:10:51 +0000 (GMT) Received: from LAPTOPK7AS653V ([185.69.145.233]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 1BHGAo5l009853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 17 Dec 2021 16:10:50 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <716dc6ae-28a7-4474-2085-6e2b3f283c8c@lear.ch> In-Reply-To: <716dc6ae-28a7-4474-2085-6e2b3f283c8c@lear.ch> Date: Fri, 17 Dec 2021 16:10:49 -0000 Organization: Old Dog Consulting Message-ID: <041701d7f360$a8eeef00$facccd00$@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: AQMPzwcfgN7zu8Z35RTJ0BvhJHy/yAHdzDG0ASC4602pry4gcA== Content-Language: en-gb X-Originating-IP: 185.69.145.233 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.1.0.2090-8.6.0.1018-26596.000 X-TM-AS-Result: No--0.108-10.0-31-10 X-imss-scan-details: No--0.108-10.0-31-10 X-TMASE-Version: IMSVA-9.1.0.2090-8.6.1018-26596.000 X-TMASE-Result: 10--0.108200-10.000000 X-TMASE-MatchedRID: eVEkOcJu0F7xIbpQ8BhdbPHkpkyUphL9IiTd2l7lf6H++ePvgqdIKs8O alpDJEQlz64ST/B/U0W2GKPMGwRl3edv6cWcdrc0u6cTLrgJBGpm8qF4pBsxH7V5fSMRD1zq9El XcKz9Jn/wLZ7E63MdDwcL3CEbaGO3PWKLA6/g//vwpAypldoLOeyaqBNoQEAjdytMUZxz7ZiW15 qLoPtbfrFUl4VsjnQ8v69RAj89SVhWwQKePlTPrR1kSRHxj+Z5ghehpAfYfg8/gf7afIrQUxYzb MgyIvQWVWDscq6Sk6LrOHRWPUBTG/iJY1qaWXugiH95tLFH8ee3ABLlp51F6Ag2kgWdt3qafFY4 JDdrKX/nzlXMYw4XMDzvSj1BF/M7U6baA36eiazEQdG7H66TyKsQd9qPXhnJkePCGbfh193pjkq +lIKGJbCS4x5xUaXFFu8IucAlGhajE0jwhNWlSw== X-TMASE-SNAP-Result: 1.821001.0001-0-1-22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 16:11:01 -0000 > it is still important that someone from the RPC participate in the = RSWG=20 Which is fine (although I don't think I said anything about = participating in the RSWG). If there is a desire to have the RPC participate in the RSWG, this will = need to be factored into their costings as it could be a heavy load = (judging by the cost of simply keeping up with the emails on this list). A -----Original Message----- From: Eliot Lear =20 Sent: 17 December 2021 12:28 To: adrian@olddog.co.uk; rfced-future@iab.org Subject: Re: [Rfced-future] RPC liaison role Thanks Adrian. Just one point: On 17.12.21 10:13, Adrian Farrel wrote: > Of course the RPC should be invited to send someone to RSAB meetings = to see things before they come down the track to them, to provide input = when needed (and a lot of what the RSAB discusses will have direct = influence on the work of the RPC), and to make observations when it = seems that the RSAB is unaware of how the RPC works. Under the model we adopted from your proposal, it is still important=20 that someone from the RPC participate in the RSWG, regardless of how the = liaison issue gets addressed. Otherwise, the RSAB could be forced to=20 surprise the RSWG, which is something we have said we don't want to see=20 happen. Eliot From nobody Fri Dec 17 09:04:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97DFF3A081B for ; Fri, 17 Dec 2021 09:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BFWp7zTwJX63 for ; Fri, 17 Dec 2021 09:04:07 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FF313A0812 for ; Fri, 17 Dec 2021 09:04:07 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 477C3300C57 for ; Fri, 17 Dec 2021 12:04:09 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jv4DMY7KWNK0 for ; Fri, 17 Dec 2021 12:04:07 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 7D904300B02; Fri, 17 Dec 2021 12:04:07 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Russ Housley In-Reply-To: <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> Date: Fri, 17 Dec 2021 12:04:03 -0500 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <7E37302A-7AA4-445B-A1EC-A2ADFD54FF16@vigilsec.com> References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 17:04:12 -0000 +1 > On Dec 17, 2021, at 4:13 AM, Adrian Farrel = wrote: >=20 > I can't recall whether I commented before, and I am no longer reading = the seemingly endless email exchanges on this list. >=20 > At the risk of relitigating... >=20 > Of course the RPC should be invited to send someone to RSAB meetings = to see things before they come down the track to them, to provide input = when needed (and a lot of what the RSAB discusses will have direct = influence on the work of the RPC), and to make observations when it = seems that the RSAB is unaware of how the RPC works. >=20 > Yes, if there are executive sessions, liaisons would be excluded, but = the issue of executive sessions is not related to the question of = liaisons. >=20 > Cheers, > Adrian > -----Original Message----- > From: Rfced-future On Behalf Of Eliot = Lear > Sent: 17 December 2021 07:03 > To: rfced-future@iab.org > Subject: [Rfced-future] RPC liaison role >=20 > We have heard from several people on this topic. Could others please=20= > chime in? >=20 > Eliot >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Fri Dec 17 09:05:08 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CB73A082F for ; Fri, 17 Dec 2021 09:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.853 X-Spam-Level: X-Spam-Status: No, score=-3.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ml8JXL5d2jdE for ; Fri, 17 Dec 2021 09:05:00 -0800 (PST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10131.outbound.protection.outlook.com [40.107.1.131]) (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 9C24D3A0826 for ; Fri, 17 Dec 2021 09:04:59 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SVsnPg8B1Xe4Vozkv1LXSL6gqUQflVbRhfKfUrFgXkW1dF4Cv+6KQcEccFVymeqiiJfmK92LP9Elx+uwiLWmHOj6hmvlysYazuMhVgdOtNmU5vpI88+abYd/coM8MjuwPWPOGlFz0phaJSIaVldCmx9ySeSctTmIMneUQop8Gii4rvwCD2HWbTgB66ocBHSz72qZs6OOAv8G114gG2N02uJGDU+py6O+YPdCdck2XMNpfw7n1OoGmQ4nId0InigB8QJ6RzLNdqIYCVFUCILpHETzKpHRaLFGqv+YYUgdD7qYgU9CbdzoivP1r8msj8l15xNAh7fasGCyTLU1aY7bmg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=u9sOaQlVjGLxSGf9f4hyM6TfW/JN91vmD0cvjCFzl4Q=; b=XlcHj2ck0Fcxh53T0lPdB3t9jygvz+m4BLhAmopzkNr5FbXZuOjj6hh2HYpqGQsJS4+u3kW/TiWXTVz7WHg1EU1V8rebBDzAvxF29fWgEFK+z5UfC7SDGbb3aXkGo2o4mf413rSUJm19GCvZy1Nhho3mn+6hrEeWSwPSHAbqzqzCAUZpd8+xpZy4E19ZS+qQ0lfqabw1E5G7qOBQEVdudSFndbFDqVGbmm/SJrSYrc8QrjMY4kd6ZSonhBGANdBx62mcrMcAxDuLS1DiTj+QZAP23koOp9qV8zsifJHphlHgPZbuY8qsTpAgYsDXtFwNC2sTolI9/bD5pDVtfuuPCQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=u9sOaQlVjGLxSGf9f4hyM6TfW/JN91vmD0cvjCFzl4Q=; b=LKOJyAuoCCacLSuQxys1Ni/NiT6wMfnarKkDCVOpFAX+numMRICoWX9dWE+ThkcvuVHDUfO9Z3OpjRTAfr0xBV4Wf/jilqmUGgjuuI0+BHayXND+iwth8KGKqtihZAy16FygHsweg0gfb3Nptxnvr/0GzZaub8xBfB1G7hJMiUZmnVMOJv1KB0qbySlCEHIY6zNYt02I9wsZtYLbgN9f7VxTaMb+h782Qpv8NG/DolX7MaBScn5XdPQUx6zf4cqRXIys7HR05l5fgqA1Ui5Bt7TtBMFID43d0Nfl1tHq26l/PaQ6vOhTqngG6rUaCXCaa7SGtgJzuQ5XYIbN2N4Q0A== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB6PR0201MB2087.eurprd02.prod.outlook.com (2603:10a6:4:43::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.17; Fri, 17 Dec 2021 17:04:53 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea%4]) with mapi id 15.20.4801.015; Fri, 17 Dec 2021 17:04:53 +0000 Message-ID: Date: Fri, 17 Dec 2021 17:04:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Russ Housley , Adrian Farrel Cc: rfced-future@iab.org, Eliot Lear References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <7E37302A-7AA4-445B-A1EC-A2ADFD54FF16@vigilsec.com> From: Stephen Farrell In-Reply-To: <7E37302A-7AA4-445B-A1EC-A2ADFD54FF16@vigilsec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ISQVIdb3IrWyjB5Pcobvzrzw" X-ClientProxiedBy: DB6PR07CA0068.eurprd07.prod.outlook.com (2603:10a6:6:2a::30) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6f340d06-0bbf-4d2d-b7d3-08d9c17f57cc X-MS-TrafficTypeDiagnostic: DB6PR0201MB2087:EE_ X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:1148; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: g6p5eWFGLxsjbUQWvMGU3J0Dme4bY8qOVB2Zt+LwLZ0ss68Q3xsNc98KuSPzvW3mfOY6BK+f/QowA7n7s4OX0lLQGwZp9+IMaBwndfYzUWhhJlHSYRBMbAzAOEYlSaOmH0UxYLjBa5qydYAypW20u0qDHFuqzDNPw5X/bQjW3qTgpXrrEWg2DY5YuoTh75dHINtenWHNFwpJ5vgUbVDGgJrA744poxE3pX9p+BGUb2JVhYkTzo8yT9EVqYg0K08tXGMYGgive+NiFEO1fDVAQ1ihrcz5GrNFSFLldHCpSS4Nm9fnpPrpsQIwe2At5SDacU+/kVlx5/L68qPEX09d8D6DUw8evYrNlt4gIPOGev0/3ykeaLKsSqpmDfpgVS6KMM38F8W9UXgP0BDIGV56/wNW9HkwtvEV976Ub1ayotmxApEgduEs7ZCo3MN7o4pZtBGCIIh4NucUxTxpEn2aUN55rl+IO34/avzwLTXFpM05tFC1fSYsTneaAFVuUjFGJB6ZKAE+9+hGlWXCTgbMOYDgZpIrZjOpmnkLcX8VYJk/hrwiwYgLOxSuTlNqtaegeqAU+SGuFOQkKnXTw1DfcRd84b8rKvAPahl8Zg4E7Z4uNWr63Ld0dJ/vshu36hkGDQbBJP87NC7JIv1rIyFVdpJiCWAZnyvMMqHn/hXvWLz05JTOesO73+9q/zwcTp5o+mqYeMB7iwT//iWJG9HRtf1dNbjfIhnTgaKHvC81tpMEj164pxTypklNEnNMYhCRDwNfj64IVcbiCuok+4leIIq2AHJFhHqiym3x7ka7yekJCyCRhr82a5EtGBMQuO/1 X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(36756003)(33964004)(6506007)(5660300002)(53546011)(235185007)(66946007)(4326008)(66476007)(186003)(66556008)(508600001)(966005)(86362001)(21480400003)(2906002)(2616005)(44832011)(316002)(8676002)(110136005)(38100700002)(6512007)(786003)(6486002)(31696002)(31686004)(8936002)(83380400001)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ejNheDc3MC93YW95WGR0SVZFc1JuR3U0eHZxSmRBNEsvY0N3bmhPYUxadVYv?= =?utf-8?B?ZmJ4b0NqQm9BZGV0bG9sbm9Sc1l1Qkh2T2dCUndpYnVKcWFhYWNqaUZOcXp4?= =?utf-8?B?ejYvRDk0YWpBWThUeTI4d0l6dXNRNzNHL2RJdmYyNWdzL0ZZYUhTZHFibE1u?= =?utf-8?B?R1JaV2k5SHZta2lCNWZReWRncFNxTHFBemRPOXpuc1IraE9FYTRYUFBQYWtp?= =?utf-8?B?S21IRmVKdUhhUEROQlN4Z0hrZW9aUGp4bWkyU0poMU9lZHBXRnFCTDQyN1E5?= =?utf-8?B?eGkzY3hwNWp6cEdBM1ZPb1VjUUx6U25XeDZ3NFk0S2xra0ZkRy84OCt6NFUv?= =?utf-8?B?VXZtVGhwcVh3a20vSGVraVM1eERhdVdMR0pmMUlkS21kdnpQcGM5L0ZHQ0lB?= =?utf-8?B?R2dobEtyVk1pYVUxWkxqNG82a1Q0blZGS3hNKzBlS01CM0lFYS9PVHd4UERF?= =?utf-8?B?ajJvS2QyTmpxbTRYc0ZFcVU2RlhhSjVpek1iVkpsS2wzUzRURzMyeUk2Q2kz?= =?utf-8?B?eG5POWJlYk1sSHJaWWNMcGYzUzRKREI1SVNsVXdqUlhQQlYwNFgvOWttYVVz?= =?utf-8?B?ZGV0MWZZMDVsWnBQVEo2VlZUbTlnR0xjRlMrdlJwTEJ2N1RRcGpVN3lGVVRJ?= =?utf-8?B?NWNublh4UC9oODMxM2pxZlYyWjRrVGJ5eUp3Q09STHVmeUFtdWNQZWh0WVhJ?= =?utf-8?B?V1pyZTFDb1l0Qmg1dU92QytPNGxia2FUenNTQUp6ZEZ6UkNuRmZOdkhkWG0v?= =?utf-8?B?bnY2Ynh1bHFxUHRSY3QxQXJ4bVlTS3hvZGN3VFVieWpZTnI5MFB5RlRYNDdF?= =?utf-8?B?TWdDM0ZUM1FCak1mblBTZDg4WUJMbVdlMlY5TXU1cVVGL3V1dXFhcGtlZElE?= =?utf-8?B?a3FrejRCRGNLWXFkQ0NkZ2Jrc3dpemtjV3d6MGIzRVQ2Q2RLTW1wNDJibW93?= =?utf-8?B?VHR5WjBSWnVEN2F2WTU5bFZRRHZCUS9EYkxGckRxTFU4WFlLVDZKMVhHcjgx?= =?utf-8?B?Qy9MRlZHQjMvaVZ2MXMrc1ZxbWR2SnJQRnMwc1FBN1lWQmMweVdrU0dYc2Ix?= =?utf-8?B?SUxLTStqRk5sS0YwRjZ0cGJXSjJ6eHlsNjIraFZzRDVIbHNhK3huS05vaXFS?= =?utf-8?B?QlFVWjA0d1J5Rkt2c1IwSUthQlhhamVGa2pQMmJMNFBURE9lazRvSkdPRWd3?= =?utf-8?B?K3QyZDljUjVtbkFBYnlxdklvdEQzUm8yZXI4NXEweXlZVzlDai9QbDllc3JR?= =?utf-8?B?V1FYdmorcmZ6bkxVYWRjaXZMY0RWclZGV0lxVU5pcEhsYk14M0ZqS212dUJo?= =?utf-8?B?ZFRSa3BwdEF4ZVAvRmVIZnZ5NGgyYTB3Vi9WSjdrdTlpaGpoS1RQZnkvdits?= =?utf-8?B?aDRVblhaR0tXZzNZbE1SeDZUbi9kUHI4S1MvcXJPcVlzQWtpemxBeXE3N3NW?= =?utf-8?B?VnFURkNSTkV5TE4wRlZFNkVEei9qQ2hlalo5UFByKzNQcWx2WjRPU3dPRlpK?= =?utf-8?B?RUNoc2lOc3M0TXhKQWR1Y3h2WWwvWU5oclc1b3FNdWNCQlRlU2pMeVcrZEd2?= =?utf-8?B?bnpGaHJDOHMyaHNLY1FoK3p2RDY2WE4rY08veXplT0lFOE9KR3BQc0c3MDcw?= =?utf-8?B?YXZHdENPVEdQZndXZ1JIMjZaWU9nQ0xEQmZSb2xwNkhpUTFWc2UrRUV1aHAx?= =?utf-8?B?VGRCOVJoU29qUlpSaHZjb3ZGTXRjOENHV201R3FBOXVRL285b3lHNkFUVkVk?= =?utf-8?B?L3pMemdESU1PKzdjcHZjbTMrQnlncTRneXFwTVU2R3hIbEVlNktSOXA2S2Jh?= =?utf-8?B?YXMzcG9laSt2cnUyVkwxT0lRMk43VVlaRFk0dmNlU01uMVRmV2J2UzJZZzhU?= =?utf-8?B?U2JIeUJZLzdUZDh3MUpwS242ZWo1M0IrTXl3UUtEKytOS1pFVW5kamFjQ2dZ?= =?utf-8?B?KzJsQk1OTWVkdUN3c2tDM0tEdk0vTmRjZnVhNGpKeU9lcWFSMVhJR2JhNkxQ?= =?utf-8?B?YytYdnJHQlp1RFphdlpXbkg1emJZMTg5R2U1dks3V1Y5YjNHTUorMlYxdytu?= =?utf-8?B?RUtSSXMySWlMQnVkWXM0bFRqTkdXQStGc2NJZHZad3Q5dktFOUlZWm1GNnVB?= =?utf-8?B?SlVVaE1Bdy8vM0R0WUM0cE5EYll6RjVQWjdDcmFYZk93ZkRCVmluM09pdzFG?= =?utf-8?Q?Ob+e1fMAc0+Hm7EcEkutJAI=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: 6f340d06-0bbf-4d2d-b7d3-08d9c17f57cc X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Dec 2021 17:04:53.0155 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: Y99z6vW6nQF+Fifx2CiqNQN4EFkvHOzdclcVX/+YzlA4xmrCTHDY+5LSYds4PTLt X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0201MB2087 Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 17:05:05 -0000 --------------ISQVIdb3IrWyjB5Pcobvzrzw Content-Type: multipart/mixed; boundary="------------1VKYd0nZyG7Z6KvCjXbVw0sJ"; protected-headers="v1" From: Stephen Farrell To: Russ Housley , Adrian Farrel Cc: rfced-future@iab.org, Eliot Lear Message-ID: Subject: Re: [Rfced-future] RPC liaison role References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <7E37302A-7AA4-445B-A1EC-A2ADFD54FF16@vigilsec.com> In-Reply-To: <7E37302A-7AA4-445B-A1EC-A2ADFD54FF16@vigilsec.com> --------------1VKYd0nZyG7Z6KvCjXbVw0sJ Content-Type: multipart/mixed; boundary="------------oc0RLqCiPnbbS1ok2h156I4B" --------------oc0RLqCiPnbbS1ok2h156I4B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQoNCk9uIDE3LzEyLzIwMjEgMTc6MDQsIFJ1c3MgSG91c2xleSB3cm90ZToNCj4gKzENCg0K U2FtZSBoZXJlIGZ3aXcsDQpDaGVlcnMsDQpTLg0KDQo+IA0KPj4gT24gRGVjIDE3LCAyMDIx LCBhdCA0OjEzIEFNLCBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9nLmNvLnVrPiB3cm90 ZToNCj4+DQo+PiBJIGNhbid0IHJlY2FsbCB3aGV0aGVyIEkgY29tbWVudGVkIGJlZm9yZSwg YW5kIEkgYW0gbm8gbG9uZ2VyIHJlYWRpbmcgdGhlIHNlZW1pbmdseSBlbmRsZXNzIGVtYWls IGV4Y2hhbmdlcyBvbiB0aGlzIGxpc3QuDQo+Pg0KPj4gQXQgdGhlIHJpc2sgb2YgcmVsaXRp Z2F0aW5nLi4uDQo+Pg0KPj4gT2YgY291cnNlIHRoZSBSUEMgc2hvdWxkIGJlIGludml0ZWQg dG8gc2VuZCBzb21lb25lIHRvIFJTQUIgbWVldGluZ3MgdG8gc2VlIHRoaW5ncyBiZWZvcmUg dGhleSBjb21lIGRvd24gdGhlIHRyYWNrIHRvIHRoZW0sIHRvIHByb3ZpZGUgaW5wdXQgd2hl biBuZWVkZWQgKGFuZCBhIGxvdCBvZiB3aGF0IHRoZSBSU0FCIGRpc2N1c3NlcyB3aWxsIGhh dmUgZGlyZWN0IGluZmx1ZW5jZSBvbiB0aGUgd29yayBvZiB0aGUgUlBDKSwgYW5kIHRvIG1h a2Ugb2JzZXJ2YXRpb25zIHdoZW4gaXQgc2VlbXMgdGhhdCB0aGUgUlNBQiBpcyB1bmF3YXJl IG9mIGhvdyB0aGUgUlBDIHdvcmtzLg0KPj4NCj4+IFllcywgaWYgdGhlcmUgYXJlIGV4ZWN1 dGl2ZSBzZXNzaW9ucywgbGlhaXNvbnMgd291bGQgYmUgZXhjbHVkZWQsIGJ1dCB0aGUgaXNz dWUgb2YgZXhlY3V0aXZlIHNlc3Npb25zIGlzIG5vdCByZWxhdGVkIHRvIHRoZSBxdWVzdGlv biBvZiBsaWFpc29ucy4NCj4+DQo+PiBDaGVlcnMsDQo+PiBBZHJpYW4NCj4+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBSZmNlZC1mdXR1cmUgPHJmY2VkLWZ1dHVy ZS1ib3VuY2VzQGlhYi5vcmc+IE9uIEJlaGFsZiBPZiBFbGlvdCBMZWFyDQo+PiBTZW50OiAx NyBEZWNlbWJlciAyMDIxIDA3OjAzDQo+PiBUbzogcmZjZWQtZnV0dXJlQGlhYi5vcmcNCj4+ IFN1YmplY3Q6IFtSZmNlZC1mdXR1cmVdIFJQQyBsaWFpc29uIHJvbGUNCj4+DQo+PiBXZSBo YXZlIGhlYXJkIGZyb20gc2V2ZXJhbCBwZW9wbGUgb24gdGhpcyB0b3BpYy4gIENvdWxkIG90 aGVycyBwbGVhc2UNCj4+IGNoaW1lIGluPw0KPj4NCj4+IEVsaW90DQo+Pg0KPj4NCj4+IC0t IA0KPj4gUmZjZWQtZnV0dXJlIG1haWxpbmcgbGlzdA0KPj4gUmZjZWQtZnV0dXJlQGlhYi5v cmcNCj4+IGh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5mby9yZmNlZC1mdXR1 cmUNCj4gDQo= --------------oc0RLqCiPnbbS1ok2h156I4B Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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 zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 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+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC 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 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK 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+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb 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 Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R 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/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK 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+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB 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 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+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 =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------oc0RLqCiPnbbS1ok2h156I4B-- --------------1VKYd0nZyG7Z6KvCjXbVw0sJ-- --------------ISQVIdb3IrWyjB5Pcobvzrzw Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmG8wzMFAwAAAAAACgkQWrL68XsXK+ro 9Q/7BA6RZN6inYaWRprQsZZS2MsiYZ/CEoVHCrTOJdhCvMeyVDR/KS+31Z2LgG77KGwaN2LzRAz2 ZrkCR4fFVSYY6/7MXwQoHvK7Yh8BGYMHJnmba1y5fptSrdmAxd/uWUu02hka+OGURC2zRQ5n/260 4iRRyT7OvB0caif57M2svOk0idY/9pbSDUZ76xa1g6N2DWZvZnzqJphkAJxUMgmiXruWadndAIRg 869jwAC03O+XKieGDWbnGg+4xw0pBNbHrGmnvLOwXg2jw0r//zFs+fRm9rpXQL2ABrmWuXcDSi6w rxXIpSZ384aTDu76d411+OPHIE8zriN5WW91otM5o4FmnBr8hL20qg0m2qJHKe61v/0Tbuu3Zx6O dn/p+IYvhFceFmmcN8z7RCc2UNy1Xwnij0jndFz6+FR8mouDkz+Luuy1sjZhETL3A4Wun60OtpsU HNXOqHDKdQKgwIXvFV5EMQmhZN0DhDPzz6kirbt65muWaHAfWuUao7gYMGpf1I02mBFZRDYjOvOS IheJN+W+pPdPixHIsSLY5PATXkOhmRa9yjb5cu5aTP1BkSK/TShHqcJKSuwUu1LtMFT1uGvlnRZu PghnPiPGem6By8FgJZPkGjV7NNERIx4RBfaPbnJmid2q4kwBF+XDaz2rv3xVIAGcX5cBXY6617MM Ypg= =8yS/ -----END PGP SIGNATURE----- --------------ISQVIdb3IrWyjB5Pcobvzrzw-- From nobody Fri Dec 17 10:06:05 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E23B43A044D for ; Fri, 17 Dec 2021 10:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blrIt3jTQGbt for ; Fri, 17 Dec 2021 10:05:58 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E8263A043F for ; Fri, 17 Dec 2021 10:05:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:From:Subject; bh=ISDuA8OxWln9Dgkc7NCI3KYdTVu3tbrBnuqzbOMA/D8=; b=J7CWsnZ7MHLf7EvgI2zTzg/T+s 6syQZe8eju8TZRKL1ITph4l4Wx+9kFeVosL/f0MxpZNlMvmEhkS2C1AhGlm3nptLxlD+xoDP9svER syfdNXYlXu/lADDUAzG+NxyVrPfTm7c5e1OxWab7Aztip2rqLX1KcbX3Tjr/9OWTVaEWfJDgSPJ9f DXD1slxg6feQeVJqrH0XsTZeyrXqPnA8/3IXJWOFo9xauw3a9EScPQQdspHeq4PgJ9w1XfZWu9ITl STZ2ErLxSDfn6O8XyECgCL1fCH2Z/DECH1Nz/B9pmSUFTiJPTDCDcc8v88ZDht4h6D5ODZpX0M3VN EOQDDYMA==; Received: from [81.187.2.149] (port=34211 helo=[192.168.0.67]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1myHc9-0005Ej-3o; Fri, 17 Dec 2021 18:05:54 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) From: Colin Perkins In-Reply-To: <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> Date: Fri, 17 Dec 2021 18:05:48 +0000 Cc: Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <110D043B-EF99-4539-A5DF-95F517949E4B@csperkins.org> References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> To: Adrian Farrel X-Mailer: Apple Mail (2.3445.104.21) X-BlackCat-Spam-Score: 4 Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:06:04 -0000 I fully agree with Adrian here.=20 Colin > On 17 Dec 2021, at 09:13, Adrian Farrel wrote: >=20 > I can't recall whether I commented before, and I am no longer reading = the seemingly endless email exchanges on this list. >=20 > At the risk of relitigating... >=20 > Of course the RPC should be invited to send someone to RSAB meetings = to see things before they come down the track to them, to provide input = when needed (and a lot of what the RSAB discusses will have direct = influence on the work of the RPC), and to make observations when it = seems that the RSAB is unaware of how the RPC works. >=20 > Yes, if there are executive sessions, liaisons would be excluded, but = the issue of executive sessions is not related to the question of = liaisons. >=20 > Cheers, > Adrian > -----Original Message----- > From: Rfced-future On Behalf Of Eliot = Lear > Sent: 17 December 2021 07:03 > To: rfced-future@iab.org > Subject: [Rfced-future] RPC liaison role >=20 > We have heard from several people on this topic. Could others please=20= > chime in? >=20 > Eliot >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Colin Perkins https://csperkins.org/ From nobody Fri Dec 17 10:52:50 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF5D63A07EF for ; Fri, 17 Dec 2021 10:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97x_Rmg5wfwh for ; Fri, 17 Dec 2021 10:52:37 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 1DA503A0818 for ; Fri, 17 Dec 2021 10:52:36 -0800 (PST) Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BHIqRK2805983 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 17 Dec 2021 19:52:28 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639767148; bh=4h3FdSuwxUXWbmwEdAGTt7ppDYqEEgMLxap76A/LWnc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=VB42us2kASh+3KjFFWQzoxs320yvvoPUjkeqt06JQJziT0I6X5N9I3KntuxpOIwPr c29XTs9RD4yaB42OMU+G5J/K9r9yKRsjibmkBivz6smzSlj4u4PDzo20aqVic/fXrQ dEBQKWk+FTEmyWbtG9Re6qIRiCTFkwYc+3Qgw/cA= Message-ID: <9438939d-8166-9ce9-b2ad-ed76e9937ee0@lear.ch> Date: Fri, 17 Dec 2021 19:52:26 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Colin Perkins , Adrian Farrel Cc: rfced-future@iab.org References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <110D043B-EF99-4539-A5DF-95F517949E4B@csperkins.org> From: Eliot Lear In-Reply-To: <110D043B-EF99-4539-A5DF-95F517949E4B@csperkins.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------8PUGC3TnDQRka9n9hFO9kEZa" Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:52:49 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------8PUGC3TnDQRka9n9hFO9kEZa Content-Type: multipart/mixed; boundary="------------ja0WBWTgsRwFygiqpPYy7T0q"; protected-headers="v1" From: Eliot Lear To: Colin Perkins , Adrian Farrel Cc: rfced-future@iab.org Message-ID: <9438939d-8166-9ce9-b2ad-ed76e9937ee0@lear.ch> Subject: Re: [Rfced-future] RPC liaison role References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <110D043B-EF99-4539-A5DF-95F517949E4B@csperkins.org> In-Reply-To: <110D043B-EF99-4539-A5DF-95F517949E4B@csperkins.org> --------------ja0WBWTgsRwFygiqpPYy7T0q Content-Type: multipart/mixed; boundary="------------Ca17vgRwPG5rqaTiurMOl89B" --------------Ca17vgRwPG5rqaTiurMOl89B Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 VGhhbmsgeW91IENvbGluIGFuZCBvdGhlcnMuwqAgSWYgb3RoZXJzIGhhdmUgbm90IHNwb2tl biwgcGxlYXNlIGRvIHNvOyANCmJ1dCBJJ20gc2Vuc2luZyBhIHJvdWdoIGNvbnNlbnN1cyBm b3JtaW5nLg0KDQpPbiAxNy4xMi4yMSAxOTowNSwgQ29saW4gUGVya2lucyB3cm90ZToNCj4g SSBmdWxseSBhZ3JlZSB3aXRoIEFkcmlhbiBoZXJlLg0KPg0KPiBDb2xpbg0KPg0KPg0KPj4g T24gMTcgRGVjIDIwMjEsIGF0IDA5OjEzLCBBZHJpYW4gRmFycmVsIDxhZHJpYW5Ab2xkZG9n LmNvLnVrPiB3cm90ZToNCj4+DQo+PiBJIGNhbid0IHJlY2FsbCB3aGV0aGVyIEkgY29tbWVu dGVkIGJlZm9yZSwgYW5kIEkgYW0gbm8gbG9uZ2VyIHJlYWRpbmcgdGhlIHNlZW1pbmdseSBl bmRsZXNzIGVtYWlsIGV4Y2hhbmdlcyBvbiB0aGlzIGxpc3QuDQo+Pg0KPj4gQXQgdGhlIHJp c2sgb2YgcmVsaXRpZ2F0aW5nLi4uDQo+Pg0KPj4gT2YgY291cnNlIHRoZSBSUEMgc2hvdWxk IGJlIGludml0ZWQgdG8gc2VuZCBzb21lb25lIHRvIFJTQUIgbWVldGluZ3MgdG8gc2VlIHRo aW5ncyBiZWZvcmUgdGhleSBjb21lIGRvd24gdGhlIHRyYWNrIHRvIHRoZW0sIHRvIHByb3Zp ZGUgaW5wdXQgd2hlbiBuZWVkZWQgKGFuZCBhIGxvdCBvZiB3aGF0IHRoZSBSU0FCIGRpc2N1 c3NlcyB3aWxsIGhhdmUgZGlyZWN0IGluZmx1ZW5jZSBvbiB0aGUgd29yayBvZiB0aGUgUlBD KSwgYW5kIHRvIG1ha2Ugb2JzZXJ2YXRpb25zIHdoZW4gaXQgc2VlbXMgdGhhdCB0aGUgUlNB QiBpcyB1bmF3YXJlIG9mIGhvdyB0aGUgUlBDIHdvcmtzLg0KPj4NCj4+IFllcywgaWYgdGhl cmUgYXJlIGV4ZWN1dGl2ZSBzZXNzaW9ucywgbGlhaXNvbnMgd291bGQgYmUgZXhjbHVkZWQs IGJ1dCB0aGUgaXNzdWUgb2YgZXhlY3V0aXZlIHNlc3Npb25zIGlzIG5vdCByZWxhdGVkIHRv IHRoZSBxdWVzdGlvbiBvZiBsaWFpc29ucy4NCj4+DQo+PiBDaGVlcnMsDQo+PiBBZHJpYW4N Cj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PiBGcm9tOiBSZmNlZC1mdXR1cmUg PHJmY2VkLWZ1dHVyZS1ib3VuY2VzQGlhYi5vcmc+IE9uIEJlaGFsZiBPZiBFbGlvdCBMZWFy DQo+PiBTZW50OiAxNyBEZWNlbWJlciAyMDIxIDA3OjAzDQo+PiBUbzogcmZjZWQtZnV0dXJl QGlhYi5vcmcNCj4+IFN1YmplY3Q6IFtSZmNlZC1mdXR1cmVdIFJQQyBsaWFpc29uIHJvbGUN Cj4+DQo+PiBXZSBoYXZlIGhlYXJkIGZyb20gc2V2ZXJhbCBwZW9wbGUgb24gdGhpcyB0b3Bp Yy4gIENvdWxkIG90aGVycyBwbGVhc2UNCj4+IGNoaW1lIGluPw0KPj4NCj4+IEVsaW90DQo+ Pg0KPj4NCj4+IC0tIA0KPj4gUmZjZWQtZnV0dXJlIG1haWxpbmcgbGlzdA0KPj4gUmZjZWQt ZnV0dXJlQGlhYi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlhYi5vcmcvbWFpbG1hbi9saXN0aW5m by9yZmNlZC1mdXR1cmUNCj4NCj4NCg== --------------Ca17vgRwPG5rqaTiurMOl89B Content-Type: application/pgp-keys; name="OpenPGP_0x87B66B46D9D27A33.asc" Content-Disposition: attachment; filename="OpenPGP_0x87B66B46D9D27A33.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW 9H035clTlpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie 2GOnYxqmsw4v1yNZ9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+Iw upRSQ+vXEvFFGhERQ88zo5CaSa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+ 1y3I+An3AJeD3AA31fJZD3H8YRKOBgqeILPILbw1mM7gCtCjfvFCt6AFCwEsjITG x55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEBAAHNJUVsaW90IExlYXIgPGxl YXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMCHgECF4ACGQEWIQSY 0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgIDAQAKCRCH tmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZA ZOaRS+md+52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZD yrpivCxm8zHQwmB6AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7Fd wDgeKxuMYUOOoVVTTMWNWcMEUkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4p M+E5C5mhTbrdFUFLJC3Y5fLID7stK/ChaEaBwkYEEhECAAYFAlMfD60ACgkQrMab GguI183qWgCcDBjqDmK7cBrd5B8Lx1Hce3DoITAAoITHspuUZhEMClsQ2ruFruxq YVx7wkYEEhECAAYFAlMfD7kACgkQbSQVTUC9PaNvRQCePg8STHTpWqepHj7Qo5A4 2U0AtEAAnjmosjanQaJsp8bSsCzcBbD6vrp3wsBiBBMBCgAMBQJTIsh+BYMHhh+A AAoJEMQNkRdNmQgQBJMH/3IYT+as04P6G4XLtbCamz0Ca6MqfXAahQt8ES3b9hXN KDBBhCIMAAVXdq3xx3SUWSrIhTUfI6GqEfDoKbv3m86glT9OxjZzdZTdMuzaS5TT emG+e9cEEjJrjmAMZRXocbv3OX7P7PeILWW3qg9TlK5Jy5FxGYGh3KFsP+VGTGTc 9XvabUOhCBb5z1oocHuh4uVJbNMaKVkQTE1FrjBSgX2ofCza6sn8ht91aRSsoqvS sIH63pw7GN5jhtURktWpm/vXqNKoHKZ+9HaTrnQrxcbp3KT3zkhDDNI5AgaBIucj hC2j47FY7nvtEzs3rvB0EaLgEt2iPIPn4TTrOm5YWFbCRgQTEQIABgUCVxX/yAAK CRBugA9nE248uI7tAKCuv/d7rt4PpsN9CXNIu65JqvJMWQCgiVjlI3bzSuDrqtOO WMhLlLr4IFXNG0VsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPsLAjgQTAQIAOAIb AwIeAQIXgBYhBJjQvZBGHbCSp7JhHYe2a0bZ0nozBQJbEnAzBQsJCAcCBhUICQoL AgQWAgMBAAoJEIe2a0bZ0noz99sH/05ohkPD2proSE1OEMK7I8cJTOdf0Qo+zpVT t/GJX1CabzWSsAPO8VAy39fjk6n9/+C48Kg3SUaZwaOURUGSBhojQxDuSw9mOff1 MuU6AQBqepeAgieyaN5CMk5fyQj6TmHeUhOWi8F6dk5cz2HbU4tPxQaMu8fi/1nj RlqKusz85pZAsmCvOMHsDn2zz/zTwcoy5dGnikYSyUFhZ6Ic018VoddI0RZYNDBm fvOPTmpVM/1GVT+IgcIe50v5A3ucBmnbkyiK0lcgNrP4pEcaESX424Yi9jgbZYdE Eo58kj09uVtr1l7lpC87/p+6B9ljB1xWNC2cSSqk7KzHZ7CT0vrCRgQSEQIABgUC Ux8PrgAKCRCsxpsaC4jXzV41AJ97++0NnIjeQmmJHORfqUuHVBiCoACfZQlNGmN1 zmVoE9701OnCDbAfUOrCRgQSEQIABgUCUx8PugAKCRBtJBVNQL09o5sxAKDbY0bJ FO1KoP297EClcJRuMb2XIQCdGq6D9WBDN+ZyLtApHOS9DyKbV0nCRgQTEQIABgUC Ux7XlgAKCRB3+hotMPnpedfUAJ9VQai0umpSlBSTA9OAMkal7Qt4YgCdEzmwSiZO IahuTF6u/K/n2gnZqv7CwGIEEwEKAAwFAlMiyKMFgweGH4AACgkQxA2RF02ZCBD7 4ggAi/BaletObe+e/bo95Eovpfv1mWgwh1ZvWnM4nrdhwPY9QLyyflyMQFzlhOqp 4aMqeL8FSbt1QRcttOU4rXwnWniRWoDAK4dF+bLYZtL4dN+kVG6aqCbdRYfw/Fap cnAPZwKnabXozei5a5BCbPbSfvrmhfvWnXWesgp3JLMVfArFYLPrAjrb0c5Ic1BQ /R3AMQJYmEvCFdUw8Pntm65U+cHESWA7XD1lcfxNuFJ/7+4ITM3xXJNyHkRRxOoI rkxhmbK1rK9AU3wx34sEUGj+zMzcOOJ0Sc5imFHHmb/U6j/QEvkrjCwAWYAeavOj U+7dH4pvCHL9rv64DTnC8C2268JGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4Y0oA oJvlyBpcNcpV0dTh9NdoU0oFrq+cAKC/0cvn08pwmL5oL3aSdSMJ6jAUdsLBcwQQ AQgAHRYhBNJ0tiDZIMzm6Zz6qraoYY/DYONRBQJZd6pPAAoJELaoYY/DYONRgMEP /iaM1GyOgKTg5Fgc6BhWOiqkv4rIOCIzEgeepRicUhW0m55yVf/enGFodwKleLxw jgV4MGLTRCfkKoBh5vsFjCe+W7hB82Wns/yGrhCzVl/JzqThAzFezlCS/KoG0Ltk kJ/rjvAnMYNNs/q6H4deNNg+yNs4XeWXPxfGEZQxPdX58eGfY2P9OJPbxNqwX1pF kF1oDtdhf7qO8Kf2+zWAE7Tvk/gXSbTCXgcUxbtvYvntSiAC7T5Ucfe363Zp4/F1 BEo/GK7OAn1QPTiTcXZUM71ORaWZbO0dgc5rEmXSOTgA7Qx+asXJHkcNj3nKfqOR MUQBdxHmlolpn0rxbUR7pREJhhcwrtYJLtrdoy41QUqd1ei6dJl28YgnWNLm7XOt mZCsrf06r4iB8XTe0va6b8J/PDWY8KjiqLl4VM36YPTSSoYM4+83adaYzyFaJZWa mTY+Wx8lOcx8XWQQ0OWQHJtss+rMZ7sq7k2Z/PcLYLU/n0R54xUj6Bd7dg5Yxt5y a0h9aTtz9cMnfCLHfVL2ZimkSjsPo0lWqHIhCz/7FUT1quGXLZMrTiWGN8ep9rhd PCYuCInnC/HbeBFrghVUd0oHMrTiud925J2gUGUHAUhrFFdvM8gf9U/SbdS+BYzL +IEVdv2w1hP1zBYJMP4fftVbQj11u0FrWd2JKRciLMCKzRlFbGlvdCBMZWFyIDxs ZWFyQGxlYXIuY2g+wsCOBBMBAgA4AhsDAh4BAheAFiEEmNC9kEYdsJKnsmEdh7Zr RtnSejMFAlsScDMFCwkIBwIGFQgJCgsCBBYCAwEACgkQh7ZrRtnSejPCiAf+OqRa yV/uDnJJdnx0d9N2orPS8sfI7+plyijq/FkdFGHCdLMkK4WmmTRtVVffLWEBxyvR ecu4R+GArK696HWes6Gr58eV9V/9scPMu99n/4q1aDjpGC4nfSBj8Wtntp2FwmaX Xuf8r798Hl1ROJhuHRAA+U/IikuB8/93yhiUNeaO/Sb/dh4Au0aQrdFmokNG+mnD 9z7sIwycycyxWc2+4yIgd4s8UBEklhNRjUZqACv5NIFupJsdf/O7UBDayvtzZ+Ai UhUFhenp7S52O1HlZvecGzEJCXr8HXQ1lDtobg25mZ5sYClxs0kqbjau5/CAgDpW 7dB33SQGUH8tuW8L3sJGBBMRAgAGBQJXFf/MAAoJEG6AD2cTbjy4JScAn0VSzCt2 EkadyJJJF3I/oCasjO0eAJ9Zz3CRgJnJCfGy5npEaboA6xL6p87ATQRTHtVEAQgA tFle2HW7/ecWBj4bYU3QoQSKT7ZeyTwlf3Ov94hJr46XxrhTWiuDGnI/ZXttBAOQ NQR+z4CxqBzojzOuTcrEaWfekUVV90zXy5oRjBa+YTzhjXavsXBh1brZsD1fVO2y nlDUYjxcd2HRJBMXXaldhPBZbU9MdhUintsbMzzxweoFbTHJF+W7iPadSt321YV3 bxJHGGP4wdCRCRsoUuWhG3LeXB1LwwJE/Nf2BSuSX4PEUcLtatbdWLiCUjlgGUPS faFLIOg/UaQpVPrSBQaHt4k6dQFHyXMqbnBioC2Crabv2soHKUDjR2JGFudNN5j7 K2oxYUXlReb3snDGx7OLuQARAQABwsBfBBgBAgAJBQJTHtVEAhsMAAoJEIe2a0bZ 0nozkrkIANu6dq2AeyodtHcpulfHOtqVqQRx04Ma/99s3r8R0ol5esb1AoOU/FlM H1JPDr4A3ARKyv25QwDF0M0oN7KeOdCYUfEZ1x1xeWc9k9OF+x55SFSRsH9go58M hACQqjM2gpiPoNyJr4P/C+J8gRb4ZRRw7/pCLzIro8snIzwLu8cSqZQbNfyBMJg6 ADI53hZmsL33kJ8HTIUiivD4ykrsxlOblJsY9xgX0ar0zNKqZoTDxTpg4SUph+eR ywJMtjJZqiWFyT7f/RH0hIRYrmtTOoC4rjRLj5KfvI3Jx0Kiq9CHh7fFKnMC7dph nyMpdBVXRfYb1j4zUcxm4KqE9Q4tN0U=3D =3DjPt/ -----END PGP PUBLIC KEY BLOCK----- --------------Ca17vgRwPG5rqaTiurMOl89B-- --------------ja0WBWTgsRwFygiqpPYy7T0q-- --------------8PUGC3TnDQRka9n9hFO9kEZa Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG83GoFAwAAAAAACgkQh7ZrRtnSejMe jwf9F37pGsorU8QkS1a+K4SY5s2N4NNlrcMmFnQD67C0zOXFIzvW2BNmZylUhaNqEWGiDXC/8e/v n2er5qkMUqSE6zcd6BkYayd66KFzg3Gm1gIfe9aXAzGiyXLW1maPERDtYR4cGSzu/OT7ZgLwWB2q S3C25J7MLgl5wy27OLkzBCDFpGM2Iur+H8K+Rw+R+wVMqR0fDzXa/GuEiNo5i3PofUeGP4vxllSV +RBv2CwKolzkjtRZHReXJH0jwLZoFz3g3prYZiIRZSFmzJR6C0d9+1pokndR9K+tP5VeKM5NNsvo S1iWnO5M8LjsKB6rzlKRt96D1t+O5rtaoCtSfqp4Dw== =C1YS -----END PGP SIGNATURE----- --------------8PUGC3TnDQRka9n9hFO9kEZa-- From nobody Fri Dec 17 10:59:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9D23A08D2 for ; Fri, 17 Dec 2021 10:59:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.952 X-Spam-Level: X-Spam-Status: No, score=-3.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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 g9kGjTnh469s for ; Fri, 17 Dec 2021 10:59:04 -0800 (PST) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77C9D3A08AE for ; Fri, 17 Dec 2021 10:59:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4JFyvC5CKkz6GZDt; Fri, 17 Dec 2021 10:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1639767543; bh=o5voe7luffh9rMKliBpbkzaWgubWN8+fi4LsMlN1RYI=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=nPibIu11I1QBesspSK4EfMSenKw9ylY8Ust+KfgTVunVgHuEci5D8m/6RXXMl2cc7 wqnnA1PoIfS3o4fkm85vsJlO7Igthp8ceDXQmRDPYRIy2coD1V21ke31rMm6RL2ZtP M0DJuz9nTmcAnvvRJvAz6tLtwCF5KoEv8kKhZQMw= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.22.111] (50-233-136-230-static.hfc.comcastbusiness.net [50.233.136.230]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4JFyvC10jRz6GZDl; Fri, 17 Dec 2021 10:59:02 -0800 (PST) Message-ID: Date: Fri, 17 Dec 2021 13:59:01 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Eliot Lear Cc: rfced-future@iab.org References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <110D043B-EF99-4539-A5DF-95F517949E4B@csperkins.org> <9438939d-8166-9ce9-b2ad-ed76e9937ee0@lear.ch> From: "Joel M. Halpern" In-Reply-To: <9438939d-8166-9ce9-b2ad-ed76e9937ee0@lear.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:59:20 -0000 I agree with Adrian et. al. Yours, Joel On 12/17/2021 1:52 PM, Eliot Lear wrote: > Thank you Colin and others.  If others have not spoken, please do so; > but I'm sensing a rough consensus forming. > > On 17.12.21 19:05, Colin Perkins wrote: >> I fully agree with Adrian here. >> >> Colin >> >> >>> On 17 Dec 2021, at 09:13, Adrian Farrel wrote: >>> >>> I can't recall whether I commented before, and I am no longer reading >>> the seemingly endless email exchanges on this list. >>> >>> At the risk of relitigating... >>> >>> Of course the RPC should be invited to send someone to RSAB meetings >>> to see things before they come down the track to them, to provide >>> input when needed (and a lot of what the RSAB discusses will have >>> direct influence on the work of the RPC), and to make observations >>> when it seems that the RSAB is unaware of how the RPC works. >>> >>> Yes, if there are executive sessions, liaisons would be excluded, but >>> the issue of executive sessions is not related to the question of >>> liaisons. >>> >>> Cheers, >>> Adrian >>> -----Original Message----- >>> From: Rfced-future On Behalf Of Eliot >>> Lear >>> Sent: 17 December 2021 07:03 >>> To: rfced-future@iab.org >>> Subject: [Rfced-future] RPC liaison role >>> >>> We have heard from several people on this topic.  Could others please >>> chime in? >>> >>> Eliot >>> >>> >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> >> > From nobody Fri Dec 17 11:31:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 226BB3A08F9 for ; Fri, 17 Dec 2021 11:31:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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=stpeter.im header.b=gV3/M6wu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FT89znlU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3zx4KORBlPo for ; Fri, 17 Dec 2021 11:31:11 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A936B3A091E for ; Fri, 17 Dec 2021 11:31:11 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 0DBE85C00C4; Fri, 17 Dec 2021 14:31:11 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Fri, 17 Dec 2021 14:31:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=v 0dDm8EMqHDiI+no0OgSdYzql9uIst9E/wMpJafm6z0=; b=gV3/M6wucacKdNeUM klQYIXdsjlD7quk7DumQbK/svKoJMKj53NsxEiV29YUXa8nVWztcQ1BSWjfu7smy 15zCCqn+9DfvRq5kYPlOVrwisgJlM/SBkMwBieCufz65IZyBQGjZkjRysoSRY4Mz CwpK2DQbk9U9VmBtlB/K8PoQcuwaJAjZDZ1N36AgF/i2b+loVvJ3VP5XhiuWdaGx 3hWFzuwR/6EUA9jNkE6+K9xKND+qxaMVnB0c5la6B7yEEhYd53TeojaBEx1r5Idt Ltw3qSZRsucVqehHa8xPH3vfH1EM3Do2luJceJBpl4phsbLva3h9k9/grDMnUpDm VjcpQ== 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=fm1; bh=v0dDm8EMqHDiI+no0OgSdYzql9uIst9E/wMpJafm6 z0=; b=FT89znlUmBiAqNp5TRtVp8CHyWkQ0R/q46RvMrul4fk0gjSgKV/BLwbL0 i14fR2ZeQvFZshR5N+1bPi0ClPI6IM3KQWuxZ1oFoMDCY8AX3WwNqgcFsmrEb0U9 g+msGZPIsqNCuR/77gzWXlQRmEQNJVxdSbElI6zOhNcBUtKv/Apqc12cD+U1SNSb pHlyGG+c2YSlEmYwVh4/O4KfIGAUr4YCMrYNNBQh2HObM8UotR27NHw9LrqL9Tbw G/NLnV1ZCmCWtbWY69sPyQ9A0rRV3Xs5Dp4Br16kcNEhutlmDTviL8LpiSE4pW9S OyQsVxdKnaupOQgZjdq22AwTQMRuw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleeigdduvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqne cuggftrfgrthhtvghrnhephefhvedvteduueffgeeihefghfdtfeelieegkeevgeegueeh jedtgfeuvdevjedunecuffhomhgrihhnpehirggsrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshhtphgvthgv rhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 17 Dec 2021 14:31:10 -0500 (EST) Message-ID: Date: Fri, 17 Dec 2021 12:31:06 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Eliot Lear Cc: rfced-future@iab.org References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <110D043B-EF99-4539-A5DF-95F517949E4B@csperkins.org> <9438939d-8166-9ce9-b2ad-ed76e9937ee0@lear.ch> From: Peter Saint-Andre In-Reply-To: <9438939d-8166-9ce9-b2ad-ed76e9937ee0@lear.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:31:17 -0000 A clarifying note based on an offlist conversation that John Klensin and I had: it's important to distinguish between liaisons to the RSAB and ex-officio members of the RSAB. I think both the IETF LLC Executive Director and an RPC representative would be ex-officio members, not liaisons. Peter On 12/17/21 11:52 AM, Eliot Lear wrote: > Thank you Colin and others.  If others have not spoken, please do so; > but I'm sensing a rough consensus forming. > > On 17.12.21 19:05, Colin Perkins wrote: >> I fully agree with Adrian here. >> >> Colin >> >> >>> On 17 Dec 2021, at 09:13, Adrian Farrel wrote: >>> >>> I can't recall whether I commented before, and I am no longer reading >>> the seemingly endless email exchanges on this list. >>> >>> At the risk of relitigating... >>> >>> Of course the RPC should be invited to send someone to RSAB meetings >>> to see things before they come down the track to them, to provide >>> input when needed (and a lot of what the RSAB discusses will have >>> direct influence on the work of the RPC), and to make observations >>> when it seems that the RSAB is unaware of how the RPC works. >>> >>> Yes, if there are executive sessions, liaisons would be excluded, but >>> the issue of executive sessions is not related to the question of >>> liaisons. >>> >>> Cheers, >>> Adrian >>> -----Original Message----- >>> From: Rfced-future On Behalf Of Eliot >>> Lear >>> Sent: 17 December 2021 07:03 >>> To: rfced-future@iab.org >>> Subject: [Rfced-future] RPC liaison role >>> >>> We have heard from several people on this topic.  Could others please >>> chime in? >>> >>> Eliot >>> >>> >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> >> > From nobody Fri Dec 17 11:33:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDF03A08FA for ; Fri, 17 Dec 2021 11:33:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, 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 imXS9BaTPYUP for ; Fri, 17 Dec 2021 11:33:28 -0800 (PST) Received: from mail-oi1-x229.google.com (mail-oi1-x229.google.com [IPv6:2607:f8b0:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B68A3A0930 for ; Fri, 17 Dec 2021 11:33:28 -0800 (PST) Received: by mail-oi1-x229.google.com with SMTP id u74so5109028oie.8 for ; Fri, 17 Dec 2021 11:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3KU6Vf3DlK9yAW49w+SKYV8ScLlJ+KumUrRCSV8nSqY=; b=nQCui7b0ulTSfTquw6lllGETPy/zw9QG85tuc0bHFFw7adnt1WZbiL9JDsrRt75YWb tR9X5Xpd7ztOA5HSzE9KlsGF8oviYoNDs6gCgAqVW7MokYZwii5wE6O+WxR3HhHTEfVX zHyf9H96QTJDM3UqR/rhH1rd0ALFtg9dbfVF/oUx7acdY3+OaZvFLmH8B74ZuSl4YMW/ +NRTy3sW0ZXjbgmtsx0YmbhvUJfkADQgcCKQA8lYu9UNk1pM1D1Ed2GOsgsAe212IPVd 17JsLMQHdhDURy9x87zbIHWp/y2TAVQS+RI5bfdlVvtFmi7PWhssZRcin9wAwKNXIfrH 9uEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3KU6Vf3DlK9yAW49w+SKYV8ScLlJ+KumUrRCSV8nSqY=; b=x1qfCcfKs/HQ/4v4i/m9Rv8DZCdg9uREafCG7GoGsBYjqZidt6sizZwtVIDxin9o11 XadiTpRe7Yp1+loX63YsX74PVxOi/uQsBWIUcbPmB7yNFCen18qDGOj8Mk66CKE1e6pk Hl3kXCAK9/G+JoXn+YzTTtsBcOfdSrN4sTJv8sfHXzJe33F+Q7RuJBiX/ydGmJSmNJ8M jSrTvCosMhX5t2+RDqw+8svSGNV0FUoAOIvfMu9EBlOLiGQlY/SUInNxmEleGtpre7I4 B4YTGCZqS1gL5k38wUpjFeAcDsBtpZNnfb7Iixgkq3uK1rPc1skQAYXgJgPBg2IKA83W K+Jg== X-Gm-Message-State: AOAM530EMw41NC/dR4K+5QhLvewZh57S4Eemql3UJkyQzJSteGHa0V2B IrxXAVrjyW2lfv21EihEXZw= X-Google-Smtp-Source: ABdhPJzs7xenjQ5whp7rC/V/Yt8pLLGFWJPBGcbXQ5AFIYtJF0tMYHgBbnb8rEJV0C+gt63+3ITqlA== X-Received: by 2002:a05:6808:2187:: with SMTP id be7mr9335069oib.97.1639769606486; Fri, 17 Dec 2021 11:33:26 -0800 (PST) Received: from ?IPv6:2601:647:4c80:2eac:b0e7:a5bf:c58:9424? ([2601:647:4c80:2eac:b0e7:a5bf:c58:9424]) by smtp.gmail.com with ESMTPSA id d8sm1861041oiw.24.2021.12.17.11.33.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 17 Dec 2021 11:33:25 -0800 (PST) From: Bob Hinden Message-Id: <67BAD394-50C1-4B5A-8044-CB23DA940991@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A49AEBBE-5851-4368-8D65-CD2231CB20FC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Fri, 17 Dec 2021 11:33:23 -0800 In-Reply-To: <9438939d-8166-9ce9-b2ad-ed76e9937ee0@lear.ch> Cc: Bob Hinden , Colin Perkins , Adrian Farrel , rfced-future@iab.org To: Eliot Lear References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <110D043B-EF99-4539-A5DF-95F517949E4B@csperkins.org> <9438939d-8166-9ce9-b2ad-ed76e9937ee0@lear.ch> X-Mailer: Apple Mail (2.3445.104.21) Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:33:34 -0000 --Apple-Mail=_A49AEBBE-5851-4368-8D65-CD2231CB20FC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Yes, of course the RPC should be involved. To put it another way, the = best way to make this whole thing fail (again?) is to keep the people = doing the actual work away from the people making decisions. Bob > On Dec 17, 2021, at 10:52 AM, Eliot Lear wrote: >=20 > Signed PGP part > Thank you Colin and others. If others have not spoken, please do so; = but I'm sensing a rough consensus forming. >=20 > On 17.12.21 19:05, Colin Perkins wrote: >> I fully agree with Adrian here. >>=20 >> Colin >>=20 >>=20 >>> On 17 Dec 2021, at 09:13, Adrian Farrel wrote: >>>=20 >>> I can't recall whether I commented before, and I am no longer = reading the seemingly endless email exchanges on this list. >>>=20 >>> At the risk of relitigating... >>>=20 >>> Of course the RPC should be invited to send someone to RSAB meetings = to see things before they come down the track to them, to provide input = when needed (and a lot of what the RSAB discusses will have direct = influence on the work of the RPC), and to make observations when it = seems that the RSAB is unaware of how the RPC works. >>>=20 >>> Yes, if there are executive sessions, liaisons would be excluded, = but the issue of executive sessions is not related to the question of = liaisons. >>>=20 >>> Cheers, >>> Adrian >>> -----Original Message----- >>> From: Rfced-future On Behalf Of Eliot = Lear >>> Sent: 17 December 2021 07:03 >>> To: rfced-future@iab.org >>> Subject: [Rfced-future] RPC liaison role >>>=20 >>> We have heard from several people on this topic. Could others = please >>> chime in? >>>=20 >>> Eliot >>>=20 >>>=20 >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >>=20 > >=20 >=20 --Apple-Mail=_A49AEBBE-5851-4368-8D65-CD2231CB20FC 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmG85gMACgkQrut0EXfn u6htMAf/RmM+abfaAlAZ3P1t3XoRxCtAjtwJwV9qrAlgeyzqJijh16XKMZo56TkB YmefreZjOcpSe8LeInFdd/d5n3/l+QCZ8s73NzaKr+F8hITRHckurfgMWPRhYmps uKLg9+5JVfLEi8MLs8iE9iafVbtyy15rfb74yQvv6GNC9fMkAsbjeYxsVvLzU7/L QTZIFEzwrCbKz43SywUbCbIBYzK2vDyETDnrmYY8sMY+2NEFImKyT0OOf1GZ29M7 lecnuVzqtm12lIiIrKkX0RrUPHiuBshD2jufgiA9BF7W1u2jTRbfscc81BcIJ5dS h1l0S9Q/zuaA5QW79MUWJHYd8rfUAw== =rLW3 -----END PGP SIGNATURE----- --Apple-Mail=_A49AEBBE-5851-4368-8D65-CD2231CB20FC-- From nobody Fri Dec 17 12:49:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 772BF3A0483 for ; Fri, 17 Dec 2021 12:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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.20210112.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 9J2bDugaCAtz for ; Fri, 17 Dec 2021 12:49:12 -0800 (PST) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8C23A047F for ; Fri, 17 Dec 2021 12:49:12 -0800 (PST) Received: by mail-qv1-xf2b.google.com with SMTP id o10so3562635qvc.5 for ; Fri, 17 Dec 2021 12:49:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to:content-transfer-encoding; bh=LY/Bwz8rDT9nYtSIi9bx5wlNKGnXFaDQSX4w4I2Qerw=; b=ga6/qvHRPr/zJvVO8FcVnkUvNnPOn0mdQpmu/yu0lOrOet5ROtL93MBgYAxGemjvV0 TVzTBxmUEtG9s80kBQzu6NiSl09bgxJrNBoTsxr4Ch3eynQgMmEYkDHH+gOlqYb610qU phauacO/j/SyYIg8RiFrImRMOrqe1mUXRQLC4RArqlqLXekXkSCtK/nOtM5ukav7MnSK Jn1PqtJwHwo/gXRiQSpa0wrghJ9NYFlxpnJQC11861icmSQx9TgB/b66fyTz2itmdCsS 6q3DFAMsHKjSBUKupZ9lwwFRJt2+D79QHdSGlEAF+EUNwgGIdx3yQhY1Ndbz6iVx/r4I Rdsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=LY/Bwz8rDT9nYtSIi9bx5wlNKGnXFaDQSX4w4I2Qerw=; b=Rs4DVRBi8q3Ix17EFr4t7gP2ftPHpD0pxqd6khcu+zeO6oZ2FfgeACk4k4H2V65XwW 52eg6nSmTId+lQwgQAki0swEAJP7sxYv+QGelVsQzaUNXDyPUTtkh4veWVcE6QB1E0Sr Y8X0RBpJzcxdx5hGD+Hs32OSYAw5D0bAsxbsara1K4e2mNbvp8TOuvYFFpdB991eEkEx Tz9R24qggMyK9uDptbY5IfZeSyPibfG0ldizBdivVhzrryqYEdqyc/8Y0osN2iQEaCo0 qqrRwVHxMZSiEuXZXBdV7usZuE/9RHdxpo9HxoRHKDx2W9rrwIJSV4/ik8UbrfWvTVvk LLNw== X-Gm-Message-State: AOAM533XfL+WK+jK7xHcFmw7gPkB+fGxpIENyD1DwcvLDQPIVP/WC8VA icDu7lr23S+hb0gCt8FyZhCO/b4yheSoWkWf X-Google-Smtp-Source: ABdhPJyyvwBWx6/zk9mPlJYxbud6I/sPq6zSR6MlnEEd4KMnJRITP4Ql8WRZRxXdwG/SZfJdVN6r0Q== X-Received: by 2002:a05:6214:2585:: with SMTP id fq5mr3881334qvb.3.1639774149717; Fri, 17 Dec 2021 12:49:09 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id f8sm8055200qtk.1.2021.12.17.12.49.08 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Dec 2021 12:49:08 -0800 (PST) Message-ID: <08fb2387-cc08-80e8-b338-2ce8a62133ba@nthpermutation.com> Date: Fri, 17 Dec 2021 15:49:07 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: rfced-future@iab.org References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <716dc6ae-28a7-4474-2085-6e2b3f283c8c@lear.ch> <041701d7f360$a8eeef00$facccd00$@olddog.co.uk> From: Michael StJohns In-Reply-To: <041701d7f360$a8eeef00$facccd00$@olddog.co.uk> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: [Rfced-future] RPC RSWG Role - if any? was: Re: RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:49:16 -0000 On 12/17/2021 11:10 AM, Adrian Farrel wrote: >> it is still important that someone from the RPC participate in the RSWG > Which is fine (although I don't think I said anything about participating in the RSWG). > > If there is a desire to have the RPC participate in the RSWG, this will need to be factored into their costings as it could be a heavy load (judging by the cost of simply keeping up with the emails on this list). > > A > One of the reasons for having the RPC on the RSAB is so that the RSAB members (who are required to participate on the RSWG) can regularly say to the RPC member of the RSAB: "Hey - this came up in the RSWG and it may affect the RPC - could you take a quick look at these two emails please?"    That seems a better alternative (and less costly) than requiring the RPC to have a presence on the RSWG AND be willing to hold up a caution sign when the RSWG starts discussing how the RPC is the perfect place for X to be done and require it to read possibly 100s of emails that have nothing to do with the RPC. I see from the diff that the words "within the RSWG" were added to the 8th item under section 4.3 RPC responsibilities between -06 and -07.  I don't remember that popping up as a discussion item between -06 and -07, it may have been considered editorial?  A quick search of the emails I've received from the rfced-future mailing list with the search term body:"within the RSWG" doesn't bring up anything.  Nor does body:RSWG seem to give me anything on point It probably should have been considered substantive because of the implied or actual difference in costs and RPC scope. Mike From nobody Fri Dec 17 12:56:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 289033A076C for ; Fri, 17 Dec 2021 12:56:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 Zt6YuBnLO4wC for ; Fri, 17 Dec 2021 12:56:06 -0800 (PST) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7FF3A0768 for ; Fri, 17 Dec 2021 12:56:06 -0800 (PST) Received: by mail-pf1-x429.google.com with SMTP id t123so1857579pfc.13 for ; Fri, 17 Dec 2021 12:56:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=/CxNGk/KeBXOSHZUP+FnCuexWd/q1owTyvRcTKb85WI=; b=FccnmC3/fpItyzORgF6y1JPSkgzSRUX/kVHYhNb3JXICuiktgsmQE4rMvXQ1ZRN9SD LOJprGP4bJV57u30YvROqQLtAil7yg1Ptoz0NYsCRrYIxiXIxh9WOezylnguCDRqBE2f skBZHOXLyvEEqpJvvWu4foQz4gwIpBuQfjQ+58bDoIZAkC7q+DUvi5nIrAl4NSIcSRps zswVdi90KkjC6hixR4eOiVwSoJCyJv/WGsVweg273In2g/c+VfQEEdMuuW3CxqByVrGi Oqz9/ELcj+zhaQ90ZhWNPLLgdY9X9rpFPTntik9u7EVjOKzH+N+MNG6d1kKU4DgA3v8u kuCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=/CxNGk/KeBXOSHZUP+FnCuexWd/q1owTyvRcTKb85WI=; b=lwpitT42/prwvihdlfC/VHqyBXbmQ3QrQSIz4KJSXuVoPINS0lADprXyrz/6ospqbJ KEyc7dywMrtWvqFlujNkO6I8LIjooMl7ou1HktP31f6I6qoYHb74qbpmaYqU2QG5frz4 yCsmAaG/0LkK/u3MRwRABxOSRtV1DuNLwsuVd9ACrrKcS1WedhAF2gRTVvp7t4BILDR4 5wD0h4n5mAiP2ogyl2cVlkLjzclKSNMDYKNvXtD2jkgsdAASVv+TbSb5xOeRrlEB1xHM oYTB7Ow9yYVbvPZQuO/u7t/IF+9IctBGWtn03lnQeLeka8r90ZKA3XhUA9e267FMG6WB g31A== X-Gm-Message-State: AOAM531RXizw63cMlfLWoHU6ryusa2keeVPmD6X+cS3RZm9bUONlN1US lWnQ7olOQ3o01ptGpG6Jg+T59pzNk4gyFg== X-Google-Smtp-Source: ABdhPJz6dZbGY4k40tUrS2CT5VKVq86GfucqhWD6F61bQBYrFFzVNRbBGX/uTrzvx5T1W6T/w5mehA== X-Received: by 2002:a63:495a:: with SMTP id y26mr4413751pgk.264.1639774564655; Fri, 17 Dec 2021 12:56:04 -0800 (PST) Received: from ?IPv6:2406:e003:1071:1701:80b2:5c79:2266:e431? ([2406:e003:1071:1701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id b65sm4112951pfg.209.2021.12.17.12.56.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 17 Dec 2021 12:56:04 -0800 (PST) To: Eliot Lear , adrian@olddog.co.uk, rfced-future@iab.org References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <716dc6ae-28a7-4474-2085-6e2b3f283c8c@lear.ch> From: Brian E Carpenter Message-ID: Date: Sat, 18 Dec 2021 09:55:59 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <716dc6ae-28a7-4474-2085-6e2b3f283c8c@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:56:07 -0000 On 18-Dec-21 01:27, Eliot Lear wrote: > Thanks Adrian.=C2=A0 Just one point: >=20 > On 17.12.21 10:13, Adrian Farrel wrote: >> Of course the RPC should be invited to send someone to RSAB meetings t= o see things before they come down the track to them, to provide input wh= en needed (and a lot of what the RSAB discusses will have direct influenc= e on the work of the RPC), and to make observations when it seems that th= e RSAB is unaware of how the RPC works. >=20 > Under the model we adopted from your proposal, it is still important > that someone from the RPC participate in the RSWG, regardless of how th= e > liaison issue gets addressed.=C2=A0 Otherwise, the RSAB could be forced=20 to > surprise the RSWG, which is something we have said we don't want to see= > happen. To that point, I think there's a minor wording issue in this sentence fro= m section 3.1.1. "RFC Series Working Group (RSWG)": "The IETF LLC Board members, staff, and the IETF Executive Director are i= nvited to participate as community members in the RSWG to the extent perm= itted by any relevant IETF LLC policies." Probably this should also cover contractors: "The IETF LLC Board members, staff, contractors, and the IETF Executive D= irector are invited to participate as community members in the RSWG to th= e extent permitted by any relevant IETF LLC policies." Brian From nobody Sat Dec 18 12:24:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6EB3A116E for ; Sat, 18 Dec 2021 12:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 VwvOTvCj0Dny for ; Sat, 18 Dec 2021 12:24:41 -0800 (PST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3AB53A116D for ; Sat, 18 Dec 2021 12:24:40 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id kk22so5723076qvb.0 for ; Sat, 18 Dec 2021 12:24:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=J3VOriXQPlSGlyUxVySrZEpxFJpMFevetHpuMgQSpWQ=; b=IR3l3hQYCxXmCvLUWvGcgRpz2T8nd+ppPKEtljvastfJ9PF/FJoONy58MQCtoPSbak /ubvbj3zRiFN+mA56LV5v/CQpDHYypg3ndCpxgzKEGKVXzBXrSD3Y5rclwq1p69FJAri /KutcKVWw0IN38VbSkQMzY147GthUq0DYb8rKx98MjwGnwg7kTZG8YAHsL005eaOz+h2 Yv1JXHuE33ByyXt1vGcqHFmwamcIuWYFlP3ZzzR3zjYLQZc9BBNsUl2mepebqrYmM613 aJmCIutif0Zi6x7aIgmok5LdCFTQSjhYH5VckAn9ssyBZcfhjpxP2MixAEb+Z+cmI0sE EAww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=J3VOriXQPlSGlyUxVySrZEpxFJpMFevetHpuMgQSpWQ=; b=EEnnS0NmRct5nWA06oTDdlmf/DgEEn4FrGAYzEpuoDLIN79Riafmkdekktv9jfhPFK V6klSUBT7iWzVLqR3wJ8GFm8BvD2WmbnlqKskh9NU0C990b+B+wBD+HiTff8xMOLTm7z 9z+KU5EiUbXTHYmKojVymfF0gVEEbUKCXldLeMoOwCgJS7uH4Lk2rYGs9vJJEtSPwoBo 0wrOoTVLBO8sFry/C55DlR6c2x2F1LEb29BLDsRt9WHi6lUVOqRZiZNK5xiZTDWTpC05 3176HL9xEGFGid8ZotgmWrl52SJJNM2z95SqmW/XUF8uLYC81qw1LwsRWlU6llGPlTWZ opqw== X-Gm-Message-State: AOAM530KRM/bUrbfNNO9kjOcDvYVSKoiY4EcZ4aPVjRu6JwU+DD4zFaL V8slkWZOJ/RqFydFdLU7nx4g8A== X-Google-Smtp-Source: ABdhPJzABjfo0txwMWqvNRJLpmk0OP+wsaHUlt1fGq7TwY+gbOEMEDUceAIwGA9DdBt7hKF8eoQ0Fw== X-Received: by 2002:a05:6214:508d:: with SMTP id kk13mr1761271qvb.43.1639859078525; Sat, 18 Dec 2021 12:24:38 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id u17sm7807318qki.2.2021.12.18.12.24.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 18 Dec 2021 12:24:37 -0800 (PST) Content-Type: multipart/alternative; boundary="------------vEoujrTSotcCDpxknluLU7I0" Message-ID: <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> Date: Sat, 18 Dec 2021 15:24:36 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , John C Klensin , Jay Daley Cc: Peter Saint-Andre , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:24:46 -0000 This is a multi-part message in MIME format. --------------vEoujrTSotcCDpxknluLU7I0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/17/2021 1:32 AM, Eliot Lear wrote: > John, > > On 17.12.21 01:44, John C Klensin wrote: >> (2) While I sympathize with and share your desire to keep moving >> forward and to not revisit settled issues, one thing we have >> observed before is that many of the issues facing us are >> ultimately related to each other in complex ways. > > I would agree if the matter was given only light consideration. That > was NOT the case here.  Relitigating is disrespectful to the people > who have negotiated in good faith to come to an agreement, > particularly when the underlying facts on the ground haven't changed, > as is the case here.  That leads to people departing the process and > THAT weakens consensus, and that none of us should tolerate. > > Eliot > > Hi Eliot - Claiming the underlying facts haven't changed while they have is somewhat disingenuous. In the instant case, the text on who was doing the review of the RSCE evaluation changed from "stream managers" to RSAB minus the RSEA/RSCE between rev 00 and rev 01.  Discussions on the need for the evaluation happened way before this. Over the next 5 revs the concept of who was on the RSAB morphed a bit both in language and in fact.  While -00 had language such as "One delegate representing the IETF stream, appointed by the IESG" for the IESG and IAB, the IRTF chair was the stream representative for the IRTF and the ISE represented himself.   -01 allowed the IRTF chair to appoint a delegate instead of having the chair serve. Then we get to the discussion between -05 and -06 where it was made clear that there was a difference of understanding on who actually could be appointed to the role of RSAB (if you really want me to, I can point to the various emails on this point - but its time I don't currently have and I'm sure you could do the research as well as I could).  There was my understanding (as well I believe others held the same understanding) that of course the representative would be appointed from the sending body.   Others came to the conclusion that the IESG, IAB, IRTF and even the ISE might be too busy to be able to execute the role, so why not let them appoint who they want as a delegate? Discussion ensued along with the various discussions on term limits etc resulting in the current text (beginning in -06) of : "As the stream representative for the IETF stream, an IESG member or other person appointed by the IESG" with similar language for the IRTF, IAB and even the ISE. So we went from a situation where the worst case was two of the RSAB member were Nomcom selected, with two members selected by a Nomcom selected body (e.g. the IAB) to a possible worst case of 4 RSAB members selected from the community, with two of them selected by a Nomcom selected body and two selected by other appointees. During the -05-06 discussions I was focused on the principles document and thoughts about long term stability.  Had I had more time to consider, I would have brought this up in the above discussion, but at the time, while I thought it was a bad idea to devolve the responsibilities of the RSAB out of the IESG, IAB and IRTF, looking only at the two tasks of RSWG document approval and RPC interaction the only ones who might be hurt by that are the bodies themselves.  E.g. how does a random person A appointed by the IESG usefully represent the IESG if they are not participating in the IESG discussion.  But the various IAB/IESG/IRTF participants asked for a particular result and - considering only those two tasks - decided I could live with the changes (or clarifications as I would guess Eliot might call them).  I apologize for not speaking up about this earlier, but I was out of bandwidth. I didn't think about the third (RSCE review) and fourth (appeals) tasks in the context of an RSAB composed of 4 random people who volunteer for the job.  Sounds more like the RSOC with respect to its composition than I expected when we started this.   As we've discussed before, the RSOC model with respect to personnel management was not optimal  and there was nothing the community could do about it except possibly fire the IAB who had appointed them over a period of two Nomcoms. When I started my review of -07 (which is in pretty good shape and while I'm not happy with all of it I can live with it mostly), I wanted to take a look and see if anything popped where later changes changed how earlier changes were implemented - e.g were there any unintended consequences.   The other thing that was happening at the same time was the question of "transparency" for the RSAB.   That led to the RSAB membership model changes and to what Eliot calls a relitigation. At this point I'm concerned with the membership of the review team that reads and responds to the EDs proposed RSCE evaluation, and whether that should continue to be the RSAB given the changes.  Having it be the RSAB made a bit more sense when their nexus with respect to their sending organizations was a bit closer, and also (not arguing about the change, just the impact) when there was more of a fixed term for a given member.   It might make more sense for the ED to convene a team themselves taking from the IESG, IAB, IRTF and ISE for the specific purpose here and have them run under appropriate LLC rules rather than try and craft them here.  If not, perhaps the following things should be considered: * Can a delegate to the RSAB share the review with a member of the sending organization?  With the whole organization? * Who is responsible for the response to the review - the RSAB member or the organization that sent them? * If the RSAB member is not a member of the sending organization, how are organizational issues gathered and reflected to ED for this review? On the subject of transparency, if we remove the RSAB's personnel responsibilities, in what other situations would the RSAB need an executive session?  I agree we should provide for one, but the opportunities for such in camera proceedings should be very limited. That's it.  This is not a hill I'm willing to die on.  But it's one that I found hard to ignore and it would have been disrespectful to the process not to speak up. Later, Mike --------------vEoujrTSotcCDpxknluLU7I0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/17/2021 1:32 AM, Eliot Lear wrote:
John,

On 17.12.21 01:44, John C Klensin wrote:
(2) While I sympathize with and share your desire to keep moving
forward and to not revisit settled issues, one thing we have
observed before is that many of the issues facing us are
ultimately related to each other in complex ways.

I would agree if the matter was given only light consideration. That was NOT the case here.  Relitigating is disrespectful to the people who have negotiated in good faith to come to an agreement, particularly when the underlying facts on the ground haven't changed, as is the case here.  That leads to people departing the process and THAT weakens consensus, and that none of us should tolerate.

Eliot



Hi Eliot -

Claiming the underlying facts haven't changed while they have is somewhat disingenuous.  

In the instant case, the text on who was doing the review of the RSCE evaluation changed from "stream managers" to RSAB minus the RSEA/RSCE between rev 00 and rev 01.  Discussions on the need for the evaluation happened way before this.

Over the next 5 revs the concept of who was on the RSAB morphed a bit both in language and in fact.  While -00 had language such as "One delegate representing the IETF stream, appointed by the IESG" for the IESG and IAB, the IRTF chair was the stream representative for the IRTF and the ISE represented himself.   -01 allowed the IRTF chair to appoint a delegate instead of having the chair serve. 

Then we get to the discussion between -05 and -06 where it was made clear that there was a difference of understanding on who actually could be appointed to the role of RSAB (if you really want me to, I can point to the various emails on this point - but its time I don't currently have and I'm sure you could do the research as well as I could).  There was my understanding (as well I believe others held the same understanding) that of course the representative would be appointed from the sending body.   Others came to the conclusion that the IESG, IAB, IRTF and even the ISE might be too busy to be able to execute the role, so why not let them appoint who they want as a delegate?

Discussion ensued along with the various discussions on term limits etc resulting in the current text (beginning in -06) of :  "As the stream representative for the IETF stream, an IESG member or other person appointed by the IESG" with similar language for the IRTF, IAB and even the ISE.

So we went from a situation where the worst case was two of the RSAB member were Nomcom selected, with two members selected by a Nomcom selected body (e.g. the IAB) to a possible worst case of 4 RSAB members selected from the community, with two of them selected by a Nomcom selected body and two selected by other appointees.

During the -05-06 discussions I was focused on the principles document and thoughts about long term stability.  Had I had more time to consider, I would have brought this up in the above discussion, but at the time, while I thought it was a bad idea to devolve the responsibilities of the RSAB out of the IESG, IAB and IRTF, looking only at the two tasks of RSWG document approval and RPC interaction the only ones who might be hurt by that are the bodies themselves.  E.g. how does a random person A appointed by the IESG usefully represent the IESG if they are not participating in the IESG discussion.  But the various IAB/IESG/IRTF participants asked for a particular result and - considering only those two tasks - decided I could live with the changes (or clarifications as I would guess Eliot might call them).  I apologize for not speaking up about this earlier, but I was out of bandwidth.

I didn't think about the third (RSCE review) and fourth (appeals) tasks in the context of an RSAB composed of 4 random people who volunteer for the job.  Sounds more like the RSOC with respect to its composition than I expected when we started this.   As we've discussed before, the RSOC model with respect to personnel management was not optimal  and there was nothing the community could do about it except possibly fire the IAB who had appointed them over a period of two Nomcoms.  

When I started my review of -07 (which is in pretty good shape and while I'm not happy with all of it I can live with it mostly), I wanted to take a look and see if anything popped where later changes changed how earlier changes were implemented - e.g were there any unintended consequences.   The other thing that was happening at the same time was the question of "transparency" for the RSAB.   That led to the RSAB membership model changes and to what Eliot calls a relitigation.  

At this point I'm concerned with the membership of the review team that reads and responds to the EDs proposed RSCE evaluation, and whether that should continue to be the RSAB given the changes.  Having it be the RSAB made a bit more sense when their nexus with respect to their sending organizations was a bit closer, and also (not arguing about the change, just the impact) when there was more of a fixed term for a given member.   It might make more sense for the ED to convene a team themselves taking from the IESG, IAB, IRTF and ISE for the specific purpose here and have them run under appropriate LLC rules rather than try and craft them here.  If not, perhaps the following things should be considered:

  • Can a delegate to the RSAB share the review with a member of the sending organization?  With the whole organization?
  • Who is responsible for the response to the review - the RSAB member or the organization that sent them?
  • If the RSAB member is not a member of the sending organization, how are organizational issues gathered and reflected to ED for this review?

On the subject of transparency, if we remove the RSAB's personnel responsibilities, in what other situations would the RSAB need an executive session?  I agree we should provide for one, but the opportunities for such in camera proceedings should be very limited.

That's it.  This is not a hill I'm willing to die on.  But it's one that I found hard to ignore and it would have been disrespectful to the process not to speak up.

Later, Mike


--------------vEoujrTSotcCDpxknluLU7I0-- From nobody Sat Dec 18 13:34:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366943A1186 for ; Sat, 18 Dec 2021 13:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9MiBw_dzqFIS for ; Sat, 18 Dec 2021 13:34:48 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 6E1093A116E for ; Sat, 18 Dec 2021 13:34:47 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BILYh8E1618767 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Sat, 18 Dec 2021 22:34:44 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1639863285; bh=Ko8PAQzZHlF8yNS+NXpJfFoBYRHCHZMnsUqm+ikmfKo=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=YiEPUYyIItoVALKnTUZVdyjQxxEeQPw0/sXgNEXs0kCAf6JBWsj4UsLA6eFGRRFD4 40dBPxo6ceDbY+rjDKiFF/4vEFXH8SEy7ICHl7Pmj0G2KEcZ07JuV5H7X8M10UmDLc 8yuCT2Pz1rEOsod1v8cMcP2GgUR2HT9u9D8xcpDY= Message-ID: Date: Sat, 18 Dec 2021 22:34:41 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Michael StJohns Cc: Peter Saint-Andre , rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> From: Eliot Lear In-Reply-To: <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------LwdywLf7xqFm4SR4L4CMayPb" Archived-At: Subject: Re: [Rfced-future] Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:34:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------LwdywLf7xqFm4SR4L4CMayPb Content-Type: multipart/mixed; boundary="------------0Fc2G5faGWXYMdFxE3X957It"; protected-headers="v1" From: Eliot Lear To: Michael StJohns Cc: Peter Saint-Andre , rfced-future@iab.org Message-ID: Subject: Re: Relitigating (was: Re: [Rfced-future] RPC liaison to the RSAB) References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> In-Reply-To: <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> --------------0Fc2G5faGWXYMdFxE3X957It Content-Type: multipart/alternative; boundary="------------ggSeLdqxplgCVShg0HQ6Njrv" --------------ggSeLdqxplgCVShg0HQ6Njrv Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpIZXJlIGlzIDAwOg0KDQo+ICAgICBvICBPbmUgZGVsZWdhdGUgcmVwcmVzZW50aW5nIHRo ZSBJRVRGIHN0cmVhbSwgYXBwb2ludGVkIGJ5IHRoZSBJRVNHDQo+DQo+ICAgICBvICBPbmUg ZGVsZWdhdGUgcmVwcmVzZW50aW5nIHRoZSBJQUIgc3RyZWFtLCBhcHBvaW50ZWQgYnkgdGhl IElBQg0KPg0KPiAgICAgbyAgVGhlIElSVEYgQ2hhaXIsIHJlcHJlc2VudGluZyB0aGUgSVJU RiBzdHJlYW0NCj4NCj4gICAgIG8gIFRoZSBJbmRlcGVuZGVudCBTdWJtaXNzaW9ucyBFZGl0 b3IgW1JGQzg3MzAgIDxodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL3Jm Yzg3MzA+XQ0KPg0KPiAgICAgbyAgVGhlIFJGQyBTZXJpZXMgRWRpdG9yL0Fkdmlzbw0KDQpI ZXJlIGlzIC0wNzoNCg0KPiAgICAgKiAgQXMgdGhlIHN0cmVhbSByZXByZXNlbnRhdGl2ZSBm b3IgdGhlIElFVEYgc3RyZWFtLCBhbiBJRVNHIG1lbWJlcg0KPiAgICAgICAgb3Igb3RoZXIg cGVyc29uIGFwcG9pbnRlZCBieSB0aGUgSUVTRw0KPg0KPiAgICAgKiAgQXMgdGhlIHN0cmVh bSByZXByZXNlbnRhdGl2ZSBmb3IgdGhlIElBQiBzdHJlYW0sIGFuIElBQiBtZW1iZXIgb3IN Cj4gICAgICAgIG90aGVyIHBlcnNvbiBhcHBvaW50ZWQgYnkgdGhlIElBQg0KPg0KPiAgICAg KiAgQXMgdGhlIHN0cmVhbSByZXByZXNlbnRhdGl2ZSBmb3IgdGhlIElSVEYgc3RyZWFtLCB0 aGUgSVJURiBjaGFpcg0KPiAgICAgICAgb3Igb3RoZXIgcGVyc29uIGFwcG9pbnRlZCBieSB0 aGUgSVJURiBDaGFpcg0KPg0KPiAgICAgKiAgQXMgdGhlIHN0cmVhbSByZXByZXNlbnRhdGl2 ZSBmb3IgdGhlIEluZGVwZW5kZW50IHN0cmVhbSwgdGhlDQo+ICAgICAgICBJbmRlcGVuZGVu dCBTdWJtaXNzaW9ucyBFZGl0b3IgKElTRSkgW1JGQzg3MzAgIDxodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9odG1sL3JmYzg3MzA+XSBvciBvdGhlciBwZXJzb24NCj4gICAg ICAgIGFwcG9pbnRlZCBieSB0aGUgSVNFDQo+DQo+ICAgICAqICBUaGUgUkZDIFNlcmllcyBD b25zdWx0aW5nIEVkaXRvcg0KDQpJbiBzdW1tYXJ5Og0KDQogICogVGhlIHdvcmQgZGVsZWdh dGUgd2FzIHJlbW92ZWQsDQogICogVGhlIElSVEYgY2hhaXIgYW5kIElTRSBub3cgY2FuIGFw cG9pbnQgcmVwcmVzZW50YXRpdmVzLg0KICAqIFdlIGFkb3B0ZWQgdGhlIHRlcm0gUlNDRS4N Cg0KPiBTbyB3ZSB3ZW50IGZyb20gYSBzaXR1YXRpb24gd2hlcmUgdGhlIHdvcnN0IGNhc2Ug d2FzIHR3byBvZiB0aGUgUlNBQiANCj4gbWVtYmVyIHdlcmUgTm9tY29tIHNlbGVjdGVkLCB3 aXRoIHR3byBtZW1iZXJzIHNlbGVjdGVkIGJ5IGEgTm9tY29tIA0KPiBzZWxlY3RlZCBib2R5 IChlLmcuIHRoZSBJQUIpIHRvIGEgcG9zc2libGUgd29yc3QgY2FzZSBvZiA0IFJTQUIgDQo+ IG1lbWJlcnMgc2VsZWN0ZWQgZnJvbSB0aGUgY29tbXVuaXR5LCB3aXRoIHR3byBvZiB0aGVt IHNlbGVjdGVkIGJ5IGEgDQo+IE5vbWNvbSBzZWxlY3RlZCBib2R5IGFuZCB0d28gc2VsZWN0 ZWQgYnkgb3RoZXIgYXBwb2ludGVlcy4NCg0KQXMgeW91IGNhbiBzZWUsIGl0IHdhcyBhbHdh eXMgdGhlIGNhc2UgdGhhdCB0aGUgSUFCIGFuZCBJRVNHIGNvdWxkIA0Kc2VsZWN0IHBlb3Bs ZSBmcm9tIG91dHNpZGUgdGhlaXIgcmFua3MgaWYgdGhleSBzbyBjaG9zZS4gV2UgZGlkIGRp c2N1c3MgDQp3aGV0aGVyIHRob3NlIGRlbGVnYXRlcyBzaG91bGQgYmUgZnJvbSB0aG9zZSBi b2RpZXMuIFRoYXQgd2FzIElzc3VlIDM4LCANCnJhaXNlZCBieSBNYXJ0aW4gVGhvbXNvbiBp biBBcHJpbC7CoCBXZSBmb3VuZCBjb25zZW5zdXMgb24gdGhhdCBvbmUgaW4gDQpBdWd1c3Qu wqAgV2UgZWxpbWluYXRlZCB0aGUgd29yZCAiZGVsZWdhdGUiIGJlY2F1c2UgcGVvcGxlIGNv dWxkbid0IGFncmVlIA0Kb24gaXRzIGltcGxpY2F0aW9ucywgYW5kIHNvIHdlIGZvdW5kIGEg Y2xlYXJlciBwaHJhc2luZy7CoCBBbGxvd2luZyB0aGUgDQpJU0UgYW5kIElSVEYgY2hhaXIg dG8gYXBwb2ludCBhIHJlcHJlc2VudGF0aXZlIHdhcyBpbnRlbmRlZCB0byBhZGRyZXNzIA0K cmlza3Mgb2YgZXhjZXNzaXZlIHByb2Nlc3NpbmcgZGVsYXlzIGJ5IHRoZSBSU0FCIGR1ZSB0 byB2YWNhbmNpZXMuDQoNCkl0J3Mgb2theSB0byBnZXQgYnVzeS7CoCBUaGlzIG9yZ2FuaXph dGlvbiBoYXMgYSBoaXN0b3J5IG9mIHRvbGVyYXRpbmcgDQppc3N1ZXMgdGhhdCBhcmUgcmFp c2VkIGxhdGUgaW4gdGhlIHByb2Nlc3MuwqAgQnV0IGlmIGFuIGlzc3VlIGdvdCANCmFkZHJl c3NlZCB3aGlsZSB5b3Ugd2VyZSBkb2luZyBvdGhlciB0aGluZ3MsIHRoYXQncyBub3QgYSBy ZWFzb24gdG8gDQpyZXZpc2l0IGl0Lg0KDQpFbGlvdA0KDQoNCg== --------------ggSeLdqxplgCVShg0HQ6Njrv Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Here is 00:

   o  One delegate representing the IETF s=
tream, appointed by the IESG

   o  One delegate representing the IAB stream, appointed by the IAB

   o  The IRTF Chair, representing the IRTF stream

   o  The Independent Submissions Editor [RFC8730]

   o  The RFC Series Editor/Adviso

Here is -07:

   *  As the stream representative for the=
 IETF stream, an IESG member
      or other person appointed by the IESG

   *  As the stream representative for the IAB stream, an IAB member or
      other person appointed by the IAB

   *  As the stream representative for the IRTF stream, the IRTF chair
      or other person appointed by the IRTF Chair

   *  As the stream representative for the Independent stream, the
      Independent Submissions Editor (ISE) [RFC8730] or other person
      appointed by the ISE

   *  The RFC Series Consulting Editor

In summary:

  • The word delegate was removed,
  • The IRTF chair and ISE now can appoint representatives.=C2=A0 <= br>
  • We adopted the term RSCE.
So we went from a situation where the worst= case was two of the RSAB member were Nomcom selected, with two members selected by a Nomcom selected body (e.g. the IAB) to a possible worst case of 4 RSAB members selected from the community, with two of them selected by a Nomcom selected body and two selected by other appointees.

As you can see, it was always the case that the IAB and IESG could select people from outside their ranks if they so chose. We did discuss whether those delegates should be from those bodies.=C2= =A0 That was Issue 38, raised by Martin Thomson in April.=C2=A0 We foun= d consensus on that one in August.=C2=A0 We eliminated the word "delegate" because people couldn't agree on its implications, and so we found a clearer phrasing.=C2=A0 Allowing the ISE and IRTF cha= ir to appoint a representative was intended to address risks of excessive processing delays by the RSAB due to vacancies.

It's okay to get busy.=C2=A0 This organization has a history of tolerating issues that are raised late in the process.=C2=A0 But if= an issue got addressed while you were doing other things, that's not a reason to revisit it.

Eliot


--------------ggSeLdqxplgCVShg0HQ6Njrv-- --------------0Fc2G5faGWXYMdFxE3X957It-- --------------LwdywLf7xqFm4SR4L4CMayPb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmG+U/EFAwAAAAAACgkQh7ZrRtnSejNC 1wf8DcB2sgUG6xTHYYKJkdUcAYTa2+OLsSbdG7zi+y1r+SJEIdmDHnPS/8aDqXtpve6IyeEaBKkq XrBV88jO8mJZhUxBV+LW8oHY6OIZqdDaZTAh3fTV31wuxKD1LztUxVXw8WUltd20+xQCmmcirkQl /Tkb8g1KJiCilbMSYcRx5Jzl4uSp8IXBA6gaq8Hr01+C5aqOaFFuewM9DSaIrMVG3zzjy8izR+Lr pMmTlIFBCzxZFlwag9HifsgVbP+Ez2u/PvcC1wyKeWaZ+Ot0o3p7K1HhIe5wbXN7lbqUsU/Bfdtd z3mZaq5RbFUC7j8VZk4N8nFsurf7VFB5rKCuVjN+iQ== =l4Qn -----END PGP SIGNATURE----- --------------LwdywLf7xqFm4SR4L4CMayPb-- From nobody Sat Dec 18 23:46:01 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E50813A09DC for ; Sat, 18 Dec 2021 23:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=EyKf8zF/; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=iywrqcIi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oVAkllo5qz7r for ; Sat, 18 Dec 2021 23:45:55 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C35E3A09DD for ; Sat, 18 Dec 2021 23:45:55 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id ADAFF3200B58 for ; Sun, 19 Dec 2021 02:39:59 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Sun, 19 Dec 2021 02:39:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:from:to:subject; s=fm1; bh=huLL8/AwHnD SpmVV3/lSh90xQOe4quLd53ev1ZgAFM0=; b=EyKf8zF/JwF9MGt8vnbtie1lNtL AeUDDcn7+kx2osPs4HTLXKXU0tL0eiS1x+83QipqQk5L3wVZwmKRPq28UuV7sJaU p75IpL/Me7vcRL2kgTnyOG0UVexL/ufjXSG/JKqk5wZ7zLmRQf+yhko/3wB00Hh7 zdEBUZAFTWScyEI0NQ0mIlXjmdpqL+AOXI1eOj0yNB4ZX3qN62LXGqfvY7PM+FrN +W3NMg/cTtkVSlIfz80kIKZ0vRcj3fq2DF262rbjHK24xFGF1CP/fgQ460ZNLWl5 BZ/WlQNYrkNXCsb37TwESWiuxsH/h0fFlLFevzeNTPrvms/MqjVRG1Y0fjQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:from:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=huLL8/AwHnDSpmVV3/lSh90xQOe4quLd53ev1ZgAFM0=; b=iywrqcIi 4W1ngj6Yrhv7r0tfu8kQZYarXeESW+mrN67mPbzL7LaWACJIzVFotd9S1PUcTQuy Ik9Na8UwmNRztsWXPn5EFOhT2lrPboz1aD8PZbJ07wJTS8kSNLqrawsn38U6xkOA mdLKiB4JCnWZQFzuRbcAOdOdBHjSE6mlGAl7gewnrD8s7UpM5lU/9XET2duPAvSl AbsNWI9aBITKLXyJ1GuKrrH3tXB0ZxDC5hbo7h8CvksWdisJqMGIITSKT8sWrfIw y9aYy74d8Fm976t+aD12JGiRgagELn3TC1Ns7EfjICdTcV5REmfCaaf8ySg0IZ7i xIGVJ40jSHTdyA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrleelgddutdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucfpohcuuggrthgvuchfihgvlhguucdlgeelmdenuc fjughrpegtggfhvffusegrtddtredttdejnecuhfhrohhmpeftvghpohhsihhtohhrhicu tegtthhivhhithihucfuuhhmmhgrrhihuceuohhtuceoughopghnohhtpghrvghplhihse hmnhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepkeefvdduteejvdefkeehieevuefg fefhteetveegffekffefteffvdelheduieetnecuffhomhgrihhnpehgihhthhhusgdrtg homhenucevlhhushhtvghrufhiiigvpedunecurfgrrhgrmhepmhgrihhlfhhrohhmpegu ohgpnhhothgprhgvphhlhiesmhhnohhtrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Sun, 19 Dec 2021 02:39:58 -0500 (EST) Content-Type: multipart/alternative; boundary="===============8927207940421792738==" MIME-Version: 1.0 From: Repository Activity Summary Bot To: rfced-future@iab.org Message-Id: <20211219074555.3C35E3A09DD@ietfa.amsl.com> Date: Sat, 18 Dec 2021 23:45:55 -0800 (PST) Archived-At: Subject: [Rfced-future] Weekly github digest (RFC Editor Future Development Program Activity Summary) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 07:46:00 -0000 --===============8927207940421792738== MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8"; format="flowed" Events=20 Issues ------ * intarchboard/program-rfced-future (+1/-3/=F0=9F=92=AC1) 1 issues created: - Is there a public archive for the RSAB email list? (by stpeter) https://github.com/intarchboard/program-rfced-future/issues/143=20 1 issues received 1 new comments: - #143 Is there a public archive for the RSAB email list? (1 by becarpent= er) https://github.com/intarchboard/program-rfced-future/issues/143=20 3 issues closed: - Improve Community Calls for Comment https://github.com/intarchboard/pro= gram-rfced-future/issues/139=20 - "Heritage" https://github.com/intarchboard/program-rfced-future/issues/= 119=20 - Requests of the IETF Trust https://github.com/intarchboard/program-rfce= d-future/issues/138=20 Pull requests ------------- * intarchboard/program-rfced-future (+0/-3/=F0=9F=92=AC1) 1 pull requests received 1 new comments: - #141 improve text about Community Calls for Comment etc. (1 by elear) https://github.com/intarchboard/program-rfced-future/pull/141=20 3 pull requests merged: - improve text about Community Calls for Comment etc. https://github.com/intarchboard/program-rfced-future/pull/141=20 - add Historical Properties text https://github.com/intarchboard/program-rfced-future/pull/140=20 - add requests for IETF Trust https://github.com/intarchboard/program-rfced-future/pull/142=20 Repositories tracked by this digest: ----------------------------------- * https://github.com/intarchboard/program-rfced-future --===============8927207940421792738== Content-Type: text/html; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Weekly github digest (RFC Editor Future Development Program Activity= Summary)

Sunday December 19, 2021

Events

Issues

intarchboard/program-rfced-future (+1/-3/=F0=9F=92=AC1)

1 issues created:

1 issues received 1 new comments:

3 issues closed:

Pull requests

intarchboard/program-rfced-future (+0/-3/=F0=9F=92=AC1)

1 pull requests received 1 new comments:

3 pull requests merged:

Repositories tracked by this digest:
--===============8927207940421792738==-- From nobody Mon Dec 20 05:04:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8A733A0AF0; Mon, 20 Dec 2021 05:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.942 X-Spam-Level: X-Spam-Status: No, score=-3.942 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulltspeQuiq0; Mon, 20 Dec 2021 05:04:10 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 323223A0AF2; Mon, 20 Dec 2021 05:04:07 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BKD40qc2185158 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 20 Dec 2021 14:04:04 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1640005445; bh=uFQSYIftJcWli3WyoXg+I04zG1/h4HTTfliZSS2zceI=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=MEd05DK5Ab3DH1poTzdPNgsMdn58rRHCq36/DcCFx85aDpi4iwfw+lzgh7AhU38i5 5QuEbJkWceU7KZtIpJFDasX+/oYig+GmixOMaz+Bh1ybhHnz045jHR6gSMetZYbZfZ pJJWerSMYRJaNv0ijQtu8bry+j06YKbEdbhyBwZo= Message-ID: <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> Date: Mon, 20 Dec 2021 14:04:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Jay Daley , Mirja Kuehlewind Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> From: Eliot Lear In-Reply-To: <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------tvuLL0FNbMKMpsQj01Tcfz2y" Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 13:04:15 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------tvuLL0FNbMKMpsQj01Tcfz2y Content-Type: multipart/mixed; boundary="------------EcDU5jThTXYsfgETrJn0Dcio"; protected-headers="v1" From: Eliot Lear To: Jay Daley , Mirja Kuehlewind Cc: rfced-future@iab.org Message-ID: <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> Subject: Re: [Rfced-future] RPC liaison to the RSAB References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> In-Reply-To: <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> --------------EcDU5jThTXYsfgETrJn0Dcio Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 U2luY2UgaXQgc2VlbXMgdGhhdCB3ZSBhcmUgaGVhZGluZyBpbiB0aGUgZGlyZWN0aW9uIG9m IGFkZGluZyBhbiBSUEMgDQpsaWFpc29uIHRvIHRoZSBSU0FCLCBJIHdvdWxkIGxpa2UgdG8g cmV0dXJuIHRvIEpheSdzIGFkdmljZToNCg0KT24gMTUuMTIuMjEgMjA6MjAsIEpheSBEYWxl eSB3cm90ZToNCj4gaGVuIGl0IGNvbWVzIHRvIHRoZSBSUEMgYmVpbmcgYSBsaWFpc29uIHRv IFJTQUIsIHRoZW4gdGhlIHNpdHVhdGlvbiBpcyBtdWNoIG1vcmUgY29tcGxleCB0aGFuIGl0 IGlzIGZvciB0aGUgRUQuICBJbiBwYXJ0aWN1bGFyIHRoZSBSU0FCIG5lZWRzIHRvIHJlY29u Y2lsZSB0aGUgZm9sbG93aW5nOg0KPg0KPiAtIGhvdyB0byBtYW5hZ2UgdGhlIFJQQyBpbnB1 dC9lbmdhZ2VtZW50IHdoZW4gZGlzY3Vzc2luZyB0aGUgcHJpb3JpdGllcyBhbmQgcGVyZm9y bWFuY2Ugb2YgdGhlIFJQQw0KQW5kIEkgd2lsbCBhZGQgaGVyZSwgdGhhdCBvZiB0aGUgUlND RSBhcyB3ZWxsLg0KPiAtIGhvdyB0byBtYW5hZ2UgcmVzcG9uZGluZyB0byBSUEMgcmVxdWVz dHMgZm9yIGFkdmljZQ0KPiAtIGhvdyB0byBtYW5hZ2UgYW55IGNvbmZsaWN0aW5nIGFkdmlj ZSBmcm9tIHRoZSBSU0NFIGFuZCB0aGUgUlBDDQo+DQo+IE5vbmUgb2YgdGhlc2UgYXJlIGlu c3VybW91bnRhYmxlLCBidXQgSSB3b3VsZCBob3BlIHRoYXQgYW55IHByb3Bvc2FsIGZvciB0 aGUgUlBDIGJlaW5nIGEgbWFuZGF0b3J5IGxpYWlzb24gYWRkcmVzc2VzIHRob3NlIGlzc3Vl cyBhcyBub3QgZG9pbmcgdGhhdCBwdXRzIHRoZSBSU0FCIG9uIGEgZGlmZmljdWx0IGZvb3Rp bmcgZnJvbSB0aGUgc3RhcnQuLg0KDQpQbGVhc2UgY29tbWVudCBvbiBob3cgeW91IHdvdWxk IGxpa2UgdGhlc2UgcG9pbnRzIGFkZHJlc3NlZC4NCg0KUGV0ZXIgd3JvdGU6DQoNCj4gQSBj bGFyaWZ5aW5nIG5vdGUgYmFzZWQgb24gYW4gb2ZmbGlzdCBjb252ZXJzYXRpb24gdGhhdCBK b2huIEtsZW5zaW4gDQo+IGFuZCBJIGhhZDogaXQncyBpbXBvcnRhbnQgdG8gZGlzdGluZ3Vp c2ggYmV0d2VlbiBsaWFpc29ucyB0byB0aGUgUlNBQiANCj4gYW5kIGV4LW9mZmljaW8gbWVt YmVycyBvZiB0aGUgUlNBQi4NCg0KQSBsaWFpc29uIGlzIHNvbWVvbmUgd2hvIGlzIHNlbnQg dG8gcmVwcmVzZW50IGFuIG9yZ2FuaXphdGlvbi4gVGhpcyBpcyANCmluZGVlZCB3aGF0IHdl IGhhdmUgYmVlbiBkaXNjdXNzaW5nLsKgIFdoaWxlIHRoZSByb2xlIG1heSBpbmRlZWQgYmUg ZXggDQpvZmZpY2lvLCB0aGF0IGRvZXNuJ3QgaW1wbHkgZXggb2ZmaWNpbyBtZW1iZXJzaGlw LCBiZWNhdXNlIG1lbWJlcnNoaXAgDQpoYXMgaXRzIHByaXZpbGVnZXMgKGxpa2Ugdm90aW5n KS7CoCBJZiB3ZSBhcmUgdG8gdXNlIHRoZSB0ZXJtLCBpdCBzaG91bGQgDQpiZSBhcHByb3By aWF0ZWx5IGNvbnN0cmFpbmVkLg0KDQpFbGlvdA0KDQo= --------------EcDU5jThTXYsfgETrJn0Dcio-- --------------tvuLL0FNbMKMpsQj01Tcfz2y Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmHAf0AFAwAAAAAACgkQh7ZrRtnSejPc wwf+Ivrv8hyH1HBGWUhpHVK+Fy9ZKC25CBq8YtjuKqA8FDiIOGNG08PAMPuOZelJj97KK328eVl2 twSrOw41EDsrqb0dlDgwg8xX2O2UExpw76Wcjmubr8jogBNkpSlI15A8J7NbIfvFoRdRhDNtYZll 5Jb5OoDbFUpnVabdRerAy5Tskd82XKK7H0FVN11dTXtGQE60wl6lVmNxrXdmqrSXAuYQgaodrt1G oXIzH1afgE/jMKvAqbGoDq/fLhUgj+HXGedPXDvZ1gD+E0/+aixPiyPkQBLHBehWzyx4Hei0t9bk pB1gHCZJ3hMjJHkkIMsRQl30KgXyL+Y1QEP+6yw8sg== =Pnii -----END PGP SIGNATURE----- --------------tvuLL0FNbMKMpsQj01Tcfz2y-- From nobody Mon Dec 20 09:09:32 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD623A10CE; Mon, 20 Dec 2021 09:09:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImYUC9HA4h8x; Mon, 20 Dec 2021 09:09:25 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86EBF3A10CC; Mon, 20 Dec 2021 09:09:21 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mzMA0-000N2p-WA; Mon, 20 Dec 2021 12:09:17 -0500 Date: Mon, 20 Dec 2021 12:09:11 -0500 From: John C Klensin To: Eliot Lear , Jay Daley , Mirja Kuehlewind cc: rfced-future@iab.org Message-ID: <8BD1727D2222111F0DB19B49@PSB> In-Reply-To: <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> 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] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 17:09:30 -0000 Eliot, Since you asked, let me repeat and add a bit to some comments I made on the 15th and point back to the original. Some of this may have gotten lost or because it was in the bottom part of a response to Peter. Because of that and contrary to my usual practice, I'm going to write separate notes addressing very different parts of your comments. This one is addressed to the material you quoted from Jay's note. --On Monday, December 20, 2021 14:04 +0100 Eliot Lear wrote: > Since it seems that we are heading in the direction of adding > an RPC liaison to the RSAB, I would like to return to Jay's > advice: > > On 15.12.21 20:20, Jay Daley wrote: >> hen it comes to the RPC being a liaison to RSAB, then the >> situation is much more complex than it is for the ED. In >> particular the RSAB needs to reconcile the following: >> >> - how to manage the RPC input/engagement when discussing the >> priorities and performance of the RPC > And I will add here, that of the RSCE as well. >> - how to manage responding to RPC requests for advice >> - how to manage any conflicting advice from the RSCE and the >> RPC >> >> None of these are insurmountable, but I would hope that any >> proposal for the RPC being a mandatory liaison addresses >> those issues as not doing that puts the RSAB on a difficult >> footing from the start.. > > Please comment on how you would like these points addressed. Edited from the last half of (the first half was a response to Peter about the use of the term liaison). The comment at the end is completely new in this version: I don't think that any of the above are hard. I still believe that the model we are specifying will work to produce the RFC Series we want [[see below]] only if things can proceed collegially, with people having open discussions, sharing perspectives and opinions openly. If the RSAB needs to go into some type of executive session to make certain decisions with some or all the ex-officio members (and/or liaisons) excluded, then so be it, but I would hope that: -- The RPC would participate in discussions about their priorities and performance. If needed, that would be far more likely to result in incremental adjustments or corrections rather than discussions about the detailed provisions of contracts or something needing to assert authority. -- The RPC should be present for discussions about their requests for advice. Perhaps they would have nothing to say, but that is not an issue. If the requests or associated issues are not correctly interpreted, then having them present to clarify would save time and improve results. Maybe I'm missing something, but I can see no scenario in which excluding them from such discussions would make the quality of RSAB decisions, the Series, or the Internet better. -- If the RPC and RSCE have conflicting advice, I believe that having them discuss their different advice and perspectives with each other and with the RSAB would be in the best interests of all concerned. Certainly, I'd hope nothing would bar them from having private discussions to clarify (even if not resolve) conflicting positions. That would almost certainly be in everyone's interest, but I see no reason for the document to need to say that unless there are provisions that someone could interpret as getting in the way (I haven't found any). Where I (very slightly) might disagree with Jay is that I don't see that situation as being much more complex than the one with the ED. For example, if the ED has advice about funding limits or the LLC Board were to ask the RSAB (either as a separate entity or as part of a more general query to the community) for an evaluation of the performance of the ED, the same issues would arise. I'd hope the RSAB would be able to turn such advice or requests into discussions of tradeoffs or of strengths and weaknesses. If a final decision required an executive session with the ED excluded, so be it. So not so different from the above. [[New this time]] What I think is key here is that I think that, the more we can have open discussion, understand each other's perspectives, and reach agreement, the better off we are. By contrast, if, in order to make progress, anyone needs to assert individual authority to make a decision, that should be seen as a failure --perhaps a necessary and acceptable one-- but a failure of that open discussion process. We should be trying to guard against the need for such failures rather than doing things --including excluding people from discussions for which their perspectives might be helpful-- that enable or encourage them. That should not be controversial. We've turned the rather powerful RSE role into the advisory and consultative RSCE one. We've narrowed the conditions under which the RSAB can block something rather than forcing more discussion down to nearly zero. If those actions imply consensus, let's apply the corollaries. ----- "The RFC Series we want:" I continue to hope that, small details aside, there really is a shared vision for the future of the series and the criteria for success. I had some doubts about that early on and some recent discussions reinforce those doubts. The counter-hypothesis is that there are at least two, incompatible, visions in the community and on this mailing list. If so, neither side has done a good enough job of explaining their view to the other (or listening to such explanations) to the point that we have a shared understanding of what the disagreements about those high-level goals actually are. Or, more cynically, we have been deliberately not having those discussions because they would be paralyzing. Instead, we continue to fuss about small details of process and structure with those who adhere to one vision or the other trying to organize things to increase the likelihood of their vision prevailing in the long term. If that counter-hypothesis is correct, it probably also explains why an attempt to nail down principles stirs such passion and eventually turns into a discussion about how to water things down enough that everyone can say "nothing really offensive there" and move on and while particular changes look significant --significant enough to justify reviewing older decisions-- to some of us and trivial enough to others that looking again at those old decisions would constitute re-litigating them. And, if that counter-hypothesis is even nearly correct, I don't envy you and Brian your jobs because doing them fairly, without inadvertently biasing things one way or the other, is nearly impossible. best, john From nobody Mon Dec 20 10:41:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E48523A07DF; Mon, 20 Dec 2021 10:41:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOJKHkZB07sO; Mon, 20 Dec 2021 10:41:48 -0800 (PST) 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 5D5E03A07D6; Mon, 20 Dec 2021 10:41:44 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mzNbS-000NC9-39; Mon, 20 Dec 2021 13:41:42 -0500 Date: Mon, 20 Dec 2021 13:41:36 -0500 From: John C Klensin To: Eliot Lear , Jay Daley , Mirja Kuehlewind cc: rfced-future@iab.org Message-ID: <0598E1C336A4E02F484F85E8@PSB> In-Reply-To: <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> 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@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:41:53 -0000 (Part 2: What we call the relationships among various bodies who might designate someone to participate in another bodies) --On Monday, December 20, 2021 14:04 +0100 Eliot Lear wrote: >... > Peter wrote: >=20 >> A clarifying note based on an offlist conversation that John >> Klensin and I had: it's important to distinguish between >> liaisons to the RSAB and ex-officio members of the RSAB. >=20 > A liaison is someone who is sent to represent an organization. > This is indeed what we have been discussing.=C2=A0 While the = role > may indeed be ex officio, that doesn't imply ex officio > membership, because membership has its privileges (like > voting).=C2=A0 If we are to use the term, it should be > appropriately constrained. Eliot, Peter's comment leaves out part of that conversation, presumably because he didn't think it would be controversial (I didn't think it would be either). However... Neither of those terms have the sort of universal and precise meanings you attribute to them above. In many contexts, as Peter pointed out, "liaison" implies a two-way relationship, e.g., if there was going to be a liaison from the RPC or the LLC to the RSAB, then there would need to be liaisons from the RSAB to the RPC and LLC respectively -- something we are definitely not contemplating. "Liaison" usually, but not always, implies acceptance by the receiving organization, acceptance which might be of the relationship and/or the designated individual. Similarly, there are many contexts in which "ex-officio" implies voting, many where it does not, and some where, if there is voting to be done, "liaisons" vote. Things are further confused by "liaison" sometimes referring to a person, sometimes to the relationship (often, but not always, as two bodies being in liaison with each other), or correspondence associated with that relationship. The important point from that conversation was not the terms but that we seem to be heading toward three categories of participants (temporarily avoiding "member" and the specific meaning you attribute to it) in the RSAB: (i) Designees of the IETF stream, the IAB stream, the IRTF stream, and the Independent stream and the RSCE. The document currently uses the term "voting members" but also uses the term "stream representative" for the first four. The latter term, as others have pointed out, may be misleading if someone is designated who does not have regular access to discussions within that stream's decision-making apparatus. (ii) Designees of the Executive Director (the ED or delegate) and, if I correctly read the direction of the discussion, the RPC. (iii) Parties or groups invited to participate in the RSAB (possibly by delegating someone) with the invitations and their specificity being at the discretion of the RSAB. As I read the I-D, the RSAB might invite individual experts for some specific topic or duration, people who would not be "liaisons" in any of the usual senses of that term. I was arguing for clearly identifying those three categories as different from each other and, in particular, clearly separating the second and third. Although terminology is not clearly assigned, that is consistent with the current text, where "liaison" is used only as an example of part of the third category. So, while I/we proposed "member", "ex-officio", and "liaison", it might be equally reasonable -- and less likely to create confusion with definitions or conceptions already in people's heads -- to designate them "eagles", "geese", and "ducks". The point was to make them clearly separate categories and then, separately, sort out which ones vote (when voting is needed), which ones can be excluded from specific meetings, and, if there are other issues or privileges, how those are allocated. For example, I don't know whether it would be reasonable for the RSAB to be able to hold closed meetings with the geese as well as the ducks excluded, but I think we need to make separate decisions about the geese and ducks (or decide to delegate that decision to the RSAB on a case by case basis). And I don't know how much we should try to constrain the RSAB about holding those meetings and the conditions that would apply to them (I believe Mike has argued for "no such meetings", I've argued in my earlier note for a set of constraints, and others might suggest "leave it to the discretion of the RSAB eagles", so there are a wide range of options). However, let's avoid confusing the three categories --because they really are different-- or making up a term for a category and then start attributing properties like voting, reciprocity, or potential exclusion to it because of what some of us think the term means. If we cannot use terms like "ex-officio" and "liaison" without falling into that trap, then I recommend the next draft use "eagles, geese, and ducks" or some other triple of the editor's choice. best, john From nobody Mon Dec 20 10:54:52 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA7EA3A0824 for ; Mon, 20 Dec 2021 10:54:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20210112.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 sDsbk5Ga0DCe for ; Mon, 20 Dec 2021 10:54:42 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BCB3A0839 for ; Mon, 20 Dec 2021 10:54:42 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id p4so10284547qkm.7 for ; Mon, 20 Dec 2021 10:54:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=RiBcjwRKOr+XvIdZd/MNt0qonA7YxYPB2Q8AOzms4Dk=; b=Sz2Qxjv7uxm7SJw6RQEQQabXBqCqJJAiYKGp/i9TqNh2yHj3SCXygO9SkRDqSgJZ/g h1L4J3yRx81n55bEEs8PxCDOaM5T4CYjBUwLu10eic0DFUcqINQzPza0H8Myw+2ljzv+ jQBYVGwiQrLjcMkOy4aAjPHItzgaovsqjoAK50T2gliEvXwWE7xYCOx6tXuxN87Kkrbo QQ91R2NaMpdcde9yPM3H3C/rAgoWg0Ryi/JZAGzQLKKw/VKA9+HzlP/ctCO5w2yofu60 2QUM1jsaiH5OKrKc9a9dXFT+sLoCBKDsdI2zSlcSYOdOm8kHwinksXP1sxtBBVt6j/h3 8ZDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=RiBcjwRKOr+XvIdZd/MNt0qonA7YxYPB2Q8AOzms4Dk=; b=TG9IcDyVKn3O24LhFdhxhy3C86t/JdJRx+wXLq4bYJ/qzcatoRrg2c32hmzh6C/PDH ABNAi9+VZLCHtiWr/1KG8VZF6wWlR5de8ryYoHL77AOWFKscbAxmj4ualMd/Fz4ICUB6 kc0L/X2dFs50a8TqfrsyjORp0pFkcZCaI4RTEPuO5eDX3w/26teNzNaFsJ4tpPtxt/MV lKy5B//G5WHuNZgf3hY8ACWaGJv25IfejnFM43v5tWLK/hi0lMjvJUl+bnddWsmWLMD3 +Iu90PkGwhywYe8+DThQU1u94JOsBrxuysvUd5QOAKSm+H8EDOL5M1L/6dsumChVpZvd R6vA== X-Gm-Message-State: AOAM531TIkbLKFoooCBpqLQfwHpvq6m18kdqktR2Q8ZXckHFmQ46LiRq Yis6m4gWWy8g8Faxn7g14n/T1D3LYikkKT5c X-Google-Smtp-Source: ABdhPJzXs8aB+GOsiezrg0uBvEtgl75ddEKQT/mxBqPzRpN/up+QE07jbHQn9Y+Tj10B/lVqNA9Gaw== X-Received: by 2002:a05:620a:371e:: with SMTP id de30mr10719748qkb.136.1640026478859; Mon, 20 Dec 2021 10:54:38 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id j14sm12266396qkp.28.2021.12.20.10.54.36 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Dec 2021 10:54:37 -0800 (PST) Content-Type: multipart/alternative; boundary="------------ilkGgImRvXfLRMRimWCmSAcx" Message-ID: <72cdd59f-3473-b055-38eb-4f57bd204369@nthpermutation.com> Date: Mon, 20 Dec 2021 13:54:35 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> From: Michael StJohns In-Reply-To: Archived-At: Subject: [Rfced-future] RSAB membership; was Re: Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:54:49 -0000 This is a multi-part message in MIME format. --------------ilkGgImRvXfLRMRimWCmSAcx Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi - Most of you should ignore what follows.  I've made my comment about the possible need to revisit the role of the RSAB in reviewing the RSCE in light of the expansion of possible RSAB members outside the sending organizations.   As I said in my previous email, this is not a hill I am willing to die on, and I expected the discussion would have been short. Unfortunately, Eliot's last message needs a response to correct both facts and conclusions.  Most of this was in my previous email or implied from it. In any event, feel free to ignore this and I apologize in advance for using up space in your mailbox on this. Hi Eliot - I reached out to Heather to make sure I understood the history of the "stream managers".   According to her this was the ground truth: At the beginning of her tenure, the stream managers were the three chairs and the ISE.  Sometime after Andrew was selected as IAB chair he started devolving responsibilities to other IAB members - the IAB stream manager's job being one of them.  There appears to have been a brief discussion about this among that group, with the result that it was felt that any member of the IAB could represent the IAB, and likewise for the IESG.   But at no time was there even the hint of discussion that it would be appropriate for either of those groups to appoint a non-member. For the IRTF, the chair was the default and as of at least 2019 or before the IRTF chair also claimed the right to delegate (https://irtf.org/policies/cross-stream-updates.html). As far as I've been able to tell (and I'll ask Adrian and/or Nevil to chime in if I'm wrong), there was no discussion among the stream managers that the IRTF chair would go outside the IRTF community for such a member.  Remember that, unlike the IETF, IRTF RGs have (or are supposed to have) a defined membership and that would probably be considered the community. AFAICT, up to the time we started this program, only the IAB had taken advantage of the looser interpretation of the stream manager and appointed a non-chair. I may be wrong about that given that these positions were not generally announced to a public mailing list as they were primarily administrative. On 12/18/2021 4:34 PM, Eliot Lear wrote: > > > Here is 00: > >> o One delegate representing the IETF stream, appointed by the IESG >> >> o One delegate representing the IAB stream, appointed by the IAB >> >> o The IRTF Chair, representing the IRTF stream >> >> o The Independent Submissions Editor [RFC8730 ] >> >> o The RFC Series Editor/Adviso > > Here is -07: > >> * As the stream representative for the IETF stream, an IESG member >> or other person appointed by the IESG >> >> * As the stream representative for the IAB stream, an IAB member or >> other person appointed by the IAB >> >> * As the stream representative for the IRTF stream, the IRTF chair >> or other person appointed by the IRTF Chair >> >> * As the stream representative for the Independent stream, the >> Independent Submissions Editor (ISE) [RFC8730 ] or other person >> appointed by the ISE >> >> * The RFC Series Consulting Editor > > In summary: > > * The word delegate was removed, > * The IRTF chair and ISE now can appoint representatives. > * We adopted the term RSCE. > The above is correct, but ignores both the history of who had the stream manager role, and the reality of the changes between -05 and -06. -01 clarified the ability of the IRTF chair to appoint a delegate that historically existed but was missed in -01. >> So we went from a situation where the worst case was two of the RSAB >> member were Nomcom selected, with two members selected by a Nomcom >> selected body (e.g. the IAB) to a possible worst case of 4 RSAB >> members selected from the community, with two of them selected by a >> Nomcom selected body and two selected by other appointees. > > As you can see, it was always the case that the IAB and IESG could > select people from outside their ranks if they so chose. > This is incorrect. The discussion between -05 and -06 under the subject of "Who are the stream managers?" started by Lars at https://mailarchive.ietf.org/arch/msg/rfced-future/j0ulWNMMPzJsNTnIx0eLsazviFU/ made it clear that the question you thought was disposed of by issue 38 was still unresolved.  To whit: Lars: All this leaves me with a bunch of questions about whether stream managers and stream approving bodies are just two terms for the same role. If the roles are different, is there any RFC that I missed that would define who the stream managers are? John K: If we are doing something different, e.g., with named individuals as RSAB members, perhaps it would be helpful to drop the "manager" terminology and talk about "stream representative", "stream spokesperson", or "stream designee". NEW: The approval bodies for the RFC streams are the IAB, IESG, IRSG, and ISE. Each approval body designates, by a method of its choosing, a Stream Representative to act as an administrative point of contact on behalf of that stream and member of the RSAB. Colin: If we go that route, I’d suggest IAB and IESG select one of their members to be their stream manager, IRTF Chair and ISE are the managers for the respective streams but can delegate. Peter: https://mailarchive.ietf.org/arch/msg/rfced-future/KCZFN0nEFjFC92XafoG8s_2Pmt8/ > If we go that route, I’d suggest IAB and IESG select one of their members to be their stream manager, IRTF Chair and ISE are the managers for the respective streams but can delegate.  I think that's effectively what our current text says. John K: https://mailarchive.ietf.org/arch/msg/rfced-future/JJAfHcCn3OoxfF1AGps3oV1hwJM/ > I think that's effectively what our current text says. Yes, modulo another distinction. There is a significant distinction between our piling this on the Chairs and then saying "they can delegate" versus our saying "up to the body". "More duties, responsibilities, and power to the Chairs" is not necessarily a good idea and should be beyond the scope of this effort to decide anyway. So.. And so on.  The discussion makes clear that before October 12th, there was no consensus on whether the IAB or IESG could appoint non-(IAB/IESG)members to the RSAB and an assumption (at least according to Peter and others who replied to Peter's comment) was that the IAB and IESG were expected to select from their membership. Peter proposed the -06 language  in https://mailarchive.ietf.org/arch/msg/rfced-future/KCZFN0nEFjFC92XafoG8s_2Pmt8/ which removed any language about requiring the IAB/IESG to appoint from their membership and that's what ultimately made it in when the discussion petered (pun intended) out.  There wasn't a formal consensus call on the text, but there was on the document. > We did discuss whether those delegates should be from those bodies.  > That was Issue 38, raised by Martin Thomson in April. Issue #38 ended up getting revisited by the discussion between -05 and -06.  38 closed without any changes to the delegation process and AFAICT no text changes were attributed to that issue. Specifically your summary of On this issue 38, based on discussion on list and in the meeting, we think we have consensus that the appointing bodies should establish their own policies as to how their representatives are appointed. Ended up needing clarification which clarification was addressed in October and that resulted in an effective change from the status quo. Note that issue 38 was closed on August 27th, which means that changes from this issue should have shown up in -02 - none did. > We found consensus on that one in August.  We eliminated the word > "delegate" because people couldn't agree on its implications, and so > we found a clearer phrasing.  Allowing the ISE and IRTF chair to > appoint a representative was intended to address risks of excessive > processing delays by the RSAB due to vacancies. > Nope - this didn't happen until -05 to -06 - October, not August. > It's okay to get busy.  This organization has a history of tolerating > issues that are raised late in the process.  But if an issue got > addressed while you were doing other things, that's not a reason to > revisit it. > I was busy on the principles stuff during the run up to publishing -06 and was following the "What is a stream manager" discussion, but thought it was headed in the right direction.  I missed Peter's proposal of the text and its incorporation, but might have still missed the implications of letting the IESG and IAB select outside their membership even if I had seen it.  I saw it with my last review of -07 and here we are. This is a new issue, triggered by the changes between -05 and -06, not a revisitation of an old one (or as you've tried to cast it - a relitigation).   And as far as I can tell it is probably now moot. Later, Mike > Eliot > > > --------------ilkGgImRvXfLRMRimWCmSAcx Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi -

Most of you should ignore what follows.  I've made my comment about the possible need to revisit the role of the RSAB in reviewing the RSCE in light of the expansion of possible RSAB members outside the sending organizations.   As I said in my previous email, this is not a hill I am willing to die on, and I expected the discussion would have been short. 

Unfortunately, Eliot's last message needs a response to correct both facts and conclusions.  Most of this was in my previous email or implied from it.  

In any event, feel free to ignore this and I apologize in advance for using up space in your mailbox on this.



Hi Eliot -

I reached out to Heather to make sure I understood the history of the "stream managers".   According to her this was the ground truth:
At the beginning of her tenure, the stream managers were the three chairs and the ISE.  Sometime after Andrew was selected as IAB chair he started devolving responsibilities to other IAB members - the IAB stream manager's job being one of them.  There appears to have been a brief discussion about this among that group, with the result that it was felt that any member of the IAB could represent the IAB, and likewise for the IESG.   But at no time was there even the hint of discussion that it would be appropriate for either of those groups to appoint a non-member.  

For the IRTF, the chair was the default and as of at least 2019 or before the IRTF chair also claimed the right to delegate (https://irtf.org/policies/cross-stream-updates.html). 

As far as I've been able to tell (and I'll ask Adrian and/or Nevil to chime in if I'm wrong), there was no discussion among the stream managers that the IRTF chair would go outside the IRTF community for such a member.  Remember that, unlike the IETF, IRTF RGs have (or are supposed to have) a defined membership and that would probably be considered the community.

AFAICT, up to the time we started this program, only the IAB had taken advantage of the looser interpretation of the stream manager and appointed a non-chair.   I may be wrong about that given that these positions were not generally announced to a public mailing list as they were primarily administrative.



On 12/18/2021 4:34 PM, Eliot Lear wrote:


Here is 00:

   o  One delegate representing the IETF stream, appointed by the IESG

   o  One delegate representing the IAB stream, appointed by the IAB

   o  The IRTF Chair, representing the IRTF stream

   o  The Independent Submissions Editor [RFC8730]

   o  The RFC Series Editor/Adviso

Here is -07:

   *  As the stream representative for the IETF stream, an IESG member
      or other person appointed by the IESG

   *  As the stream representative for the IAB stream, an IAB member or
      other person appointed by the IAB

   *  As the stream representative for the IRTF stream, the IRTF chair
      or other person appointed by the IRTF Chair

   *  As the stream representative for the Independent stream, the
      Independent Submissions Editor (ISE) [RFC8730] or other person
      appointed by the ISE

   *  The RFC Series Consulting Editor

In summary:

  • The word delegate was removed,
  • The IRTF chair and ISE now can appoint representatives. 
  • We adopted the term RSCE.

The above is correct, but ignores both the history of who had the stream manager role, and the reality of the changes between -05 and -06.

-01 clarified the ability of the IRTF chair to appoint a delegate that historically existed but was missed in -01.


So we went from a situation where the worst case was two of the RSAB member were Nomcom selected, with two members selected by a Nomcom selected body (e.g. the IAB) to a possible worst case of 4 RSAB members selected from the community, with two of them selected by a Nomcom selected body and two selected by other appointees.

As you can see, it was always the case that the IAB and IESG could select people from outside their ranks if they so chose.

This is incorrect.

The discussion between -05 and -06 under the subject of "Who are the stream managers?" started by Lars at https://mailarchive.ietf.org/arch/msg/rfced-future/j0ulWNMMPzJsNTnIx0eLsazviFU/ made it clear that the question you thought was disposed of by issue 38 was still unresolved.  To whit: 

Lars:

All this leaves me with a bunch of questions about whether stream managers and stream approving bodies are just two terms for the same role. If the roles are different, is there any RFC that I missed that would define who the stream managers are?

John K:

If we are doing something different, e.g., with named individuals as RSAB members, perhaps it would be helpful to drop the "manager" terminology and talk about "stream representative", "stream spokesperson", or "stream designee".

NEW: The approval bodies for the RFC streams are the IAB, IESG, IRSG, and ISE. Each approval body designates, by a method of its choosing, a Stream Representative to act as an administrative point of contact on behalf of that stream and member of the RSAB.

Colin:

If we go that route, I’d suggest IAB and IESG select one of their members to be their stream manager, IRTF Chair and ISE are the managers for the respective streams but can delegate.

Peter:  https://mailarchive.ietf.org/arch/msg/rfced-future/KCZFN0nEFjFC92XafoG8s_2Pmt8/

> If we go that route, I’d suggest IAB and IESG select one of their members to be their stream manager, IRTF Chair and ISE are the managers for the respective streams but can delegate.

 I think that's effectively what our current text says.

John K: https://mailarchive.ietf.org/arch/msg/rfced-future/JJAfHcCn3OoxfF1AGps3oV1hwJM/
> I think that's effectively what our current text says.

Yes, modulo another distinction. There is a significant distinction between our piling this on the Chairs and then saying "they can delegate" versus our saying "up to the body". "More duties, responsibilities, and power to the Chairs" is not necessarily a good idea and should be beyond the scope of this effort to decide anyway. So..


And so on.  The discussion makes clear that before October 12th, there was no consensus on whether the IAB or IESG could appoint non-(IAB/IESG)members to the RSAB and an assumption (at least according to Peter and others who replied to Peter's comment) was that the IAB and IESG were expected to select from their membership.  

Peter proposed the -06 language  in https://mailarchive.ietf.org/arch/msg/rfced-future/KCZFN0nEFjFC92XafoG8s_2Pmt8/ which removed any language about requiring the IAB/IESG to appoint from their membership and that's what ultimately made it in when the discussion petered (pun intended) out.  There wasn't a formal consensus call on the text, but there was on the document.

We did discuss whether those delegates should be from those bodies.  That was Issue 38, raised by Martin Thomson in April. 

Issue #38 ended up getting revisited by the discussion between -05 and -06.  38 closed without any changes to the delegation process and AFAICT no text changes were attributed to that issue.  Specifically your summary of

On this issue 38, based on discussion on list and in the meeting, we think we have consensus that the appointing bodies should establish their own policies as to how their representatives are appointed.

Ended up needing clarification which clarification was addressed in October and that resulted in an effective change from the status quo. 

Note that issue 38 was closed on August 27th, which means that changes from this issue should have shown up in -02 - none did.


We found consensus on that one in August.  We eliminated the word "delegate" because people couldn't agree on its implications, and so we found a clearer phrasing.  Allowing the ISE and IRTF chair to appoint a representative was intended to address risks of excessive processing delays by the RSAB due to vacancies.

Nope - this didn't happen until -05 to -06 - October, not August.

It's okay to get busy.  This organization has a history of tolerating issues that are raised late in the process.  But if an issue got addressed while you were doing other things, that's not a reason to revisit it.

I was busy on the principles stuff during the run up to publishing -06 and was following the "What is a stream manager" discussion, but thought it was headed in the right direction.  I missed Peter's proposal of the text and its incorporation, but might have still missed the implications of letting the IESG and IAB select outside their membership even if I had seen it.  I saw it with my last review of -07 and here we are.

This is a new issue, triggered by the changes between -05 and -06, not a revisitation of an old one (or as you've tried to cast it - a relitigation).   And as far as I can tell it is probably now moot.

Later, Mike


Eliot




--------------ilkGgImRvXfLRMRimWCmSAcx-- From nobody Mon Dec 20 11:16:06 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EC73A08D6 for ; Mon, 20 Dec 2021 11:16:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 RfMPhnWbYk9o for ; Mon, 20 Dec 2021 11:16:00 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0824E3A08D5 for ; Mon, 20 Dec 2021 11:15:59 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id p19so10712017qtw.12 for ; Mon, 20 Dec 2021 11:15:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=QRK4OOSr3ehfVzEJi7Tj/BQ6gPDdnjmlosiZLriAiBY=; b=j+duz2ygOEKc7mblGClxo9UeSSYJGBMAtkIT9hPu7QAtw9YEK3UVgdY4wP5+LszSdL YailZKHJhjkK4k7bl7vRMZvd1S+L+qdIVkLhySNASqP3Il/GAcMw+3YROwqG4RtfYFb3 Vr96OwXXhGg7J+9W/BQtOZ5wPH+aNOKbIPqm2Dgkd2ofMzsCHsVGdbMclEzEEoA/N7eg kTuPphXhrvqHVNRsX3BV0yO8SByn/KoQZasrASd/8cVR07F1anLKv/QtUFavWFtZ0p60 wCJsS9O4o3bhb9Jk48H8ZZWd2x7HyrWXfRgakqUGms+IJOVqhlEY6HuyX62IL0Sz8FyZ 340w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=QRK4OOSr3ehfVzEJi7Tj/BQ6gPDdnjmlosiZLriAiBY=; b=05NAQ1zb3ansXm81bnS7QeP2Lk6y3OLxZ3bAVeP9JpErwhHHWyQXrNs1rEWsob6MvQ b+pGBNECkueh4h6XykPlZeAhHCfeHtcDcg5isoOXOWc39mOK1TAfXF7ICgNI/ck0E9sN qimPwI3z3QrKpwSE1NW+fn8Mahk9Q16AOVMLizrr6g+LR+jtpz49WdtX3Zu6PD+Xe0Fy JWBZHMjcGDi3E9Cv2vkL+J5xUe0r9pYXVhASxwNwJ8ZlXxe68pUbhIr7LgcxOmeFJ0NG Dw9iNSJ7uunEc10Lxlug0EbkiJMrubTViLH3tKcaRXzIYVApGdV4R25yjbOb29wXQURM WQQQ== X-Gm-Message-State: AOAM533v93EIGRh8p91kPnYzhI1RlH7xyThSHkvZMk5sEd9rz679OUbl Ak6BngkAjM64W4P8DO2A2mnC1P7HTi64MWN/ X-Google-Smtp-Source: ABdhPJyYNwmvCdmVfkHC8l8zGjf63O0n8n/vho8DXp8/N8OQ43+znjaKz4kwI28M89584xp1v3YoKA== X-Received: by 2002:ac8:7f8b:: with SMTP id z11mr8496981qtj.513.1640027757500; Mon, 20 Dec 2021 11:15:57 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id y10sm12261368qkp.128.2021.12.20.11.15.56 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Dec 2021 11:15:57 -0800 (PST) Content-Type: multipart/alternative; boundary="------------jrMg4AT8IgZiCdEIQlxxUyIK" Message-ID: <3550e0a1-58da-30f4-3867-14c7b99a3929@nthpermutation.com> Date: Mon, 20 Dec 2021 14:15:55 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> From: Michael StJohns In-Reply-To: <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:16:05 -0000 This is a multi-part message in MIME format. --------------jrMg4AT8IgZiCdEIQlxxUyIK Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/20/2021 8:04 AM, Eliot Lear wrote: > Since it seems that we are heading in the direction of adding an RPC > liaison to the RSAB, I would like to return to Jay's advice: A > clarifying note based on an offlist conversation that John Klensin and > I had: it's important to distinguish between liaisons to the RSAB and > ex-officio members of the RSAB. > > A liaison is someone who is sent to represent an organization. This is > indeed what we have been discussing.  While the role may indeed be ex > officio, that doesn't imply ex officio membership, because membership > has its privileges (like voting).  If we are to use the term, it > should be appropriately constrained. Ex officio means simply "by virtue of their position or status", it does not imply voting or non voting, but it does imply membership as a matter of right. The RFC Editor was a non-voting ex officio member of the IAB. The IETF Chair was a voting ex officio member of the IAB.  The chair of the IRTF is a non-voting ex officio member of the IAB. The IAB ED is an ex officio member of the IAB. A liaison may be a voting or non voting member, but generally falls in the latter category.   E.g. **a person who helps organizations or groups to work together and provide information to each other.  Those are generally not positions held by right but require mutual agreement. The ED is a non-voting ex officio member of the RSAB. The RPC may appoint a non-voting ex officio member of the RSAB. The RSAB may create additional non-voting ex officio positions through the normal RSWG process.  The RSAB may create non-voting liaison positions through mutual agreement with any organization it deems useful to the RFC Series process. > > Eliot > > --------------jrMg4AT8IgZiCdEIQlxxUyIK Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/20/2021 8:04 AM, Eliot Lear wrote:
Since it seems that we are heading in the direction of adding an RPC liaison to the RSAB, I would like to return to Jay's advice: A clarifying note based on an offlist conversation that John Klensin and I had: it's important to distinguish between liaisons to the RSAB and ex-officio members of the RSAB.

A liaison is someone who is sent to represent an organization. This is indeed what we have been discussing.  While the role may indeed be ex officio, that doesn't imply ex officio membership, because membership has its privileges (like voting).  If we are to use the term, it should be appropriately constrained.

Ex officio means simply "by virtue of their position or status", it does not imply voting or non voting, but it does imply membership as a matter of right.

The RFC Editor was a non-voting ex officio member of the IAB.  The IETF Chair was a voting ex officio member of the IAB.  The chair of the IRTF is a non-voting ex officio member of the IAB.  The IAB ED is an ex officio member of the IAB.

A liaison may be a voting or non voting member, but generally falls in the latter category.   E.g.  a person who helps organizations or groups to work together and provide information to each other.  Those are generally not positions held by right but require mutual agreement.

The ED is a non-voting ex officio member of the RSAB.

The RPC may appoint a non-voting ex officio member of the RSAB.

The RSAB may create additional non-voting ex officio positions through the normal RSWG process.  The RSAB may create non-voting liaison positions through mutual agreement with any organization it deems useful to the RFC Series process.


Eliot



--------------jrMg4AT8IgZiCdEIQlxxUyIK-- From nobody Mon Dec 20 13:13:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092EC3A08AE for ; Mon, 20 Dec 2021 13:13:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.951 X-Spam-Level: X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-1.852, 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 UDi1beWeS8St for ; Mon, 20 Dec 2021 13:13:04 -0800 (PST) Received: from mail-pl1-x62f.google.com (mail-pl1-x62f.google.com [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2684C3A08A8 for ; Mon, 20 Dec 2021 13:13:04 -0800 (PST) Received: by mail-pl1-x62f.google.com with SMTP id n16so8295094plc.2 for ; Mon, 20 Dec 2021 13:13:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=BAqegsCEJbcMUEN68En3yq0zRGu340piKYU3VtkW2ak=; b=UYGriOBxrGt4A/zjPoW0Dk4Bf+lQJN/5SBbVNPXBbWTd//UZof2+gc6DsWpY5ZJxbg g/BoCroBdCnl2QD3pWOhBn88M7JtBKfhrlRHjxEVE//QJJHomapEviSZ52HhnJefhnnV n5NMsAKIXTc19TLdrjce26xfzKqEIoHzLSJYfFZzPRnp1t7FulobtPzhvw9KRdZdvseo 2YGDZVUHDp0RwmEB0OBqClsTqee//eM0nCUX0Mu8Sa4VEBW12YpULWuC0+S746qE6rtR U51kaHRMSM50VKLC7j9dFc3Wyn6JWPg4K5jfd9BmHjbQAGh1w6QdwfcXBKaPVLn0gocX ey4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=BAqegsCEJbcMUEN68En3yq0zRGu340piKYU3VtkW2ak=; b=sQ+Bx5uPbdlTjmH/Fh8WoU62NH/w+VoiWK2+WKCfXxwL73UilHcOpwzck1z2IDAYjE EAbh2YPWhQwv6d/92LF3ATF5F0q61uqQlb6QZJ3Bt8UhtSDa+adlY/44x3Fqp0AdzAbJ jRCIBbObH4h40yhjX3yUAOJv9/h9qfng/2OjhtRqt61HNfYZkKngrXS/Ld77fiFDz8hQ BSnbEdR7qOtHti0sZovuB37np4g/WSKFu1C3Pa3LRn4//gO9n5sgad+jvQA3+VVj3+jF 8k2vdIQu9PrAxN70YAzKcTRk4aArdIAzhU1gbnQq1OkszDldqgRXZRaOzO5vWDk7HbLx s5+Q== X-Gm-Message-State: AOAM531LDEKEszhARivWAQtsqWdjrpTlTWZtKC/KBxkM9CWQ3x2b8cvt H6EGZMf4lA1sm+d9PlIWK2X8EHuJFtjzYg== X-Google-Smtp-Source: ABdhPJxhldP4sdropIYipeJnwq9IM4i/y8+QGAeQdey30NqMZHvxkcH0yVZBsBRFYNpgLWttwApuPA== X-Received: by 2002:a17:902:8a84:b0:148:a2f7:9d8d with SMTP id p4-20020a1709028a8400b00148a2f79d8dmr18503251plo.172.1640034783047; Mon, 20 Dec 2021 13:13:03 -0800 (PST) Received: from ?IPv6:2406:e003:1071:1701:80b2:5c79:2266:e431? ([2406:e003:1071:1701:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id z4sm20730029pfh.15.2021.12.20.13.13.00 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Dec 2021 13:13:02 -0800 (PST) To: Eliot Lear , Jay Daley , Mirja Kuehlewind Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> From: Brian E Carpenter Message-ID: <1b02a4cd-8302-0145-c626-05adf2bcaaf9@gmail.com> Date: Tue, 21 Dec 2021 10:12:58 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:13:08 -0000 I'd go with this (from Mike): "The RPC may appoint a non-voting ex officio member of the RSAB." but we probably need a note that the voting members of the RSAB may hold private discussions among themselves for good cause (which we can't stop them doing anyway). Regards Brian C On 21-Dec-21 02:04, Eliot Lear wrote: > Since it seems that we are heading in the direction of adding an RPC > liaison to the RSAB, I would like to return to Jay's advice: >=20 > On 15.12.21 20:20, Jay Daley wrote: >> hen it comes to the RPC being a liaison to RSAB, then the situation is=20 much more complex than it is for the ED. In particular the RSAB needs to=20 reconcile the following: >> >> - how to manage the RPC input/engagement when discussing the prioritie= s and performance of the RPC > And I will add here, that of the RSCE as well. >> - how to manage responding to RPC requests for advice >> - how to manage any conflicting advice from the RSCE and the RPC >> >> None of these are insurmountable, but I would hope that any proposal f= or the RPC being a mandatory liaison addresses those issues as not doing = that puts the RSAB on a difficult footing from the start.. >=20 > Please comment on how you would like these points addressed. >=20 > Peter wrote: >=20 >> A clarifying note based on an offlist conversation that John Klensin >> and I had: it's important to distinguish between liaisons to the RSAB >> and ex-officio members of the RSAB. >=20 > A liaison is someone who is sent to represent an organization. This is > indeed what we have been discussing.=C2=A0 While the role may indeed be=20 ex > officio, that doesn't imply ex officio membership, because membership > has its privileges (like voting).=C2=A0 If we are to use the term, it s= hould > be appropriately constrained. >=20 > Eliot >=20 >=20 From nobody Mon Dec 20 15:52:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24A953A0D9A; Mon, 20 Dec 2021 15:52:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 qJHhWAV41h1x; Mon, 20 Dec 2021 15:52:10 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7EA3A0D97; Mon, 20 Dec 2021 15:52:08 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1mzSRp-000NjH-2X; Mon, 20 Dec 2021 18:52:05 -0500 Date: Mon, 20 Dec 2021 18:51:59 -0500 From: John C Klensin To: Brian E Carpenter , Eliot Lear , Jay Daley , Mirja Kuehlewind cc: rfced-future@iab.org Message-ID: In-Reply-To: <1b02a4cd-8302-0145-c626-05adf2bcaaf9@gmail.com> References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <0F551C75039D59C39BC6734B@PSB> <4929ABE4-6078-49E0-A20F-9DAB28599B8B@kuehlewind.net> <5eabe076-b67d-3c91-9f22-423a33a58dff@gmail.com> <412B464C-FE18-45D2-BB14-20D42EF26747@ietf.org> <0c232134-d74b-f6dc-3590-39b5c4a74744@lear.ch> <1b02a4cd-8302-0145-c626-05adf2bcaaf9@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] RPC liaison to the RSAB X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:52:14 -0000 --On Tuesday, December 21, 2021 10:12 +1300 Brian E Carpenter wrote: > I'd go with this (from Mike): > > "The RPC may appoint a non-voting ex officio member of the > RSAB." WFM. > but we probably need a note that the voting members of the RSAB > may hold private discussions among themselves for good cause > (which we can't stop them doing anyway). As you imply, I'd rather regularize that than try to stop them. But, as I've suggested before, I think the community would be well served by insisting that the fact that such meetings are being held and an explanation of the cause be public. If circumstance prevent the light of openness from shining into the room in which such meetings are held, it should at least be able to illuminate the specific cause/ justification for such a meeting. A line or two in an agenda or minutes that says "the RSAB went into executive session to discuss ABC because..." should not be unreasonably burdensome and would provide the community at least a bit of accountability. john From nobody Mon Dec 20 15:53:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FAF43A0DC8 for ; Mon, 20 Dec 2021 15:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7QmvIj3kem5O for ; Mon, 20 Dec 2021 15:53:18 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDB53A0DA2 for ; Mon, 20 Dec 2021 15:53:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=LQflneo1IZZACRAIX2sX8eVY8inElrhZDFkQD/kHESw=; b=mB+4mI7sGdUnE1ksDwlKDWVkWi PmeofSxJvsyZdTu4vDwQNzC7KLLqfZyDMNmwwCAUi7TGsMcZhVf4GbwYMVizfOfVpYgut43Zl+W64 FGcvaweQhv8M/8Jai7tKBbqxzpwUqXS0YeNWN/rsoWjxP+ELxcMnfG43BnYwgq9bg0Yq2nUpCYsmo riYr/Dsm+qlevurrg2Bf1TEB4GRY/OdaeEwL+5ti7yjcChwaJewz8Hz85NFA4nhinZmvUxxjFjRRW 7rCwzuyJAyznYS8xWT7H0oLnryvgDWV2zCUZ+IYSn1vlla9SbNVTDLfvdKSTlxdLl8cxvPP0eoqcs x1Tb78rw==; Received: from [81.187.2.149] (port=32929 helo=[192.168.0.67]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mzSSo-0002X4-Pi; Mon, 20 Dec 2021 23:53:11 +0000 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9B62DB00-8AC2-4C6B-881C-670E39528347" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Mon, 20 Dec 2021 23:53:02 +0000 In-Reply-To: <72cdd59f-3473-b055-38eb-4f57bd204369@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <7f50ad00-95b4-7764-90c8-879bfd76f777@lear.ch> <256DE82E-E519-4DC5-BE61-DA6FBBCF4038@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> <72cdd59f-3473-b055-38eb-4f57bd204369@nthpermutation.com> X-Mailer: Apple Mail (2.3445.104.21) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Rfced-future] RSAB membership; was Re: Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:53:24 -0000 --Apple-Mail=_9B62DB00-8AC2-4C6B-881C-670E39528347 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 20 Dec 2021, at 18:54, Michael StJohns = wrote: >=20 > Hi -=20 >=20 > Most of you should ignore what follows. I've made my comment about = the possible need to revisit the role of the RSAB in reviewing the RSCE = in light of the expansion of possible RSAB members outside the sending = organizations. As I said in my previous email, this is not a hill I am = willing to die on, and I expected the discussion would have been short. =20= >=20 > Unfortunately, Eliot's last message needs a response to correct both = facts and conclusions. Most of this was in my previous email or implied = from it. =20 >=20 > In any event, feel free to ignore this and I apologize in advance for = using up space in your mailbox on this. >=20 >=20 >=20 > Hi Eliot -=20 >=20 > I reached out to Heather to make sure I understood the history of the = "stream managers". According to her this was the ground truth: > At the beginning of her tenure, the stream managers were the three = chairs and the ISE. Sometime after Andrew was selected as IAB chair he = started devolving responsibilities to other IAB members - the IAB stream = manager's job being one of them. There appears to have been a brief = discussion about this among that group, with the result that it was felt = that any member of the IAB could represent the IAB, and likewise for the = IESG. But at no time was there even the hint of discussion that it = would be appropriate for either of those groups to appoint a non-member. = =20 >=20 > For the IRTF, the chair was the default and as of at least 2019 or = before the IRTF chair also claimed the right to delegate = (https://irtf.org/policies/cross-stream-updates.html = ). =20 I wrote that page, after discussion about cross-stream updates with the = IRSG and IESG. It was published in October 2019. The phrasing "The IRTF = stream manager (i.e., the IRTF chair, or their delegate)=E2=80=9D was my = understanding of the status quo at that time, not a new claim.=20 RFC 2014 is silent on the topic. RFC 7827 states that some of the = administrative duties of the IRTF chair "may be permanently or = temporarily delegated to other IRSG members=E2=80=9D. I believe stream = manager is included in the set of responsibilities that could be = delegated. I=E2=80=99m not aware that it has been delegated. > As far as I've been able to tell (and I'll ask Adrian and/or Nevil to = chime in if I'm wrong), there was no discussion among the stream = managers that the IRTF chair would go outside the IRTF community for = such a member. It would be a matter for the IRTF Chair and IAB to discuss if there were = any such proposal.=20 > Remember that, unlike the IETF, IRTF RGs have (or are supposed to = have) a defined membership and that would probably be considered the = community. Research groups may have open or closed membership. All current RGs have = open membership, hence there is no defined set of members for any IRTF = RG. Colin > AFAICT, up to the time we started this program, only the IAB had taken = advantage of the looser interpretation of the stream manager and = appointed a non-chair. I may be wrong about that given that these = positions were not generally announced to a public mailing list as they = were primarily administrative. >=20 >=20 >=20 > On 12/18/2021 4:34 PM, Eliot Lear wrote: >>=20 >> Here is 00: >>=20 >>=20 >>> o One delegate representing the IETF stream, appointed by the = IESG >>>=20 >>> o One delegate representing the IAB stream, appointed by the IAB >>>=20 >>> o The IRTF Chair, representing the IRTF stream >>>=20 >>> o The Independent Submissions Editor [RFC8730 = ] >>>=20 >>> o The RFC Series Editor/Adviso >> Here is -07: >>=20 >>=20 >>> * As the stream representative for the IETF stream, an IESG = member >>> or other person appointed by the IESG >>>=20 >>> * As the stream representative for the IAB stream, an IAB member = or >>> other person appointed by the IAB >>>=20 >>> * As the stream representative for the IRTF stream, the IRTF = chair >>> or other person appointed by the IRTF Chair >>>=20 >>> * As the stream representative for the Independent stream, the >>> Independent Submissions Editor (ISE) [RFC8730 = ] or other person >>> appointed by the ISE >>>=20 >>> * The RFC Series Consulting Editor >> In summary: >>=20 >> The word delegate was removed,=20 >> The IRTF chair and ISE now can appoint representatives. =20 >> We adopted the term RSCE. > The above is correct, but ignores both the history of who had the = stream manager role, and the reality of the changes between -05 and -06. >=20 > -01 clarified the ability of the IRTF chair to appoint a delegate that = historically existed but was missed in -01. >=20 >=20 >>> So we went from a situation where the worst case was two of the RSAB = member were Nomcom selected, with two members selected by a Nomcom = selected body (e.g. the IAB) to a possible worst case of 4 RSAB members = selected from the community, with two of them selected by a Nomcom = selected body and two selected by other appointees. >> As you can see, it was always the case that the IAB and IESG could = select people from outside their ranks if they so chose. >>=20 > This is incorrect. >=20 > The discussion between -05 and -06 under the subject of "Who are the = stream managers?" started by Lars at = https://mailarchive.ietf.org/arch/msg/rfced-future/j0ulWNMMPzJsNTnIx0eLsaz= viFU/ = made it clear that the question you thought was disposed of by = issue 38 was still unresolved. To whit:=20 >=20 > Lars:=20 >=20 > All this leaves me with a bunch of questions about whether stream = managers and stream approving bodies are just two terms for the same = role. If the roles are different, is there any RFC that I missed that = would define who the stream managers are? >=20 > John K:=20 >=20 > If we are doing something different, e.g., with named individuals as = RSAB members, perhaps it would be helpful to drop the "manager" = terminology and talk about "stream representative", "stream = spokesperson", or "stream designee". >=20 > NEW: The approval bodies for the RFC streams are the IAB, IESG, IRSG, = and ISE. Each approval body designates, by a method of its choosing, a = Stream Representative to act as an administrative point of contact on = behalf of that stream and member of the RSAB.=20 >=20 > Colin:=20 >=20 > If we go that route, I=E2=80=99d suggest IAB and IESG select one of = their members to be their stream manager, IRTF Chair and ISE are the = managers for the respective streams but can delegate. > Peter: = https://mailarchive.ietf.org/arch/msg/rfced-future/KCZFN0nEFjFC92XafoG8s_2= Pmt8/ = > > If we go that route, I=E2=80=99d suggest IAB and IESG select one of = their members to be their stream manager, IRTF Chair and ISE are the = managers for the respective streams but can delegate. >=20 > I think that's effectively what our current text says. >=20 > John K: = https://mailarchive.ietf.org/arch/msg/rfced-future/JJAfHcCn3OoxfF1AGps3oV1= hwJM/ = > > I think that's effectively what our current text says.=20 >=20 > Yes, modulo another distinction. There is a significant distinction = between our piling this on the Chairs and then saying "they can = delegate" versus our saying "up to the body". "More duties, = responsibilities, and power to the Chairs" is not necessarily a good = idea and should be beyond the scope of this effort to decide anyway. = So.. >=20 >=20 > And so on. The discussion makes clear that before October 12th, there = was no consensus on whether the IAB or IESG could appoint = non-(IAB/IESG)members to the RSAB and an assumption (at least according = to Peter and others who replied to Peter's comment) was that the IAB and = IESG were expected to select from their membership. =20 >=20 > Peter proposed the -06 language in = https://mailarchive.ietf.org/arch/msg/rfced-future/KCZFN0nEFjFC92XafoG8s_2= Pmt8/ = which removed any language about requiring the IAB/IESG to = appoint from their membership and that's what ultimately made it in when = the discussion petered (pun intended) out. There wasn't a formal = consensus call on the text, but there was on the document. >=20 >> We did discuss whether those delegates should be from those bodies. = That was Issue 38, raised by Martin Thomson in April.=20 > Issue #38 ended up getting revisited by the discussion between -05 and = -06. 38 closed without any changes to the delegation process and AFAICT = no text changes were attributed to that issue. Specifically your = summary of=20 >=20 > On this issue 38, based on discussion on list and in the meeting, we = think we have consensus that the appointing bodies should establish = their own policies as to how their representatives are appointed. > Ended up needing clarification which clarification was addressed in = October and that resulted in an effective change from the status quo. =20= >=20 > Note that issue 38 was closed on August 27th, which means that changes = from this issue should have shown up in -02 - none did. >=20 >=20 >=20 >> We found consensus on that one in August. We eliminated the word = "delegate" because people couldn't agree on its implications, and so we = found a clearer phrasing. Allowing the ISE and IRTF chair to appoint a = representative was intended to address risks of excessive processing = delays by the RSAB due to vacancies. >>=20 > Nope - this didn't happen until -05 to -06 - October, not August. >=20 >> It's okay to get busy. This organization has a history of tolerating = issues that are raised late in the process. But if an issue got = addressed while you were doing other things, that's not a reason to = revisit it. >>=20 > I was busy on the principles stuff during the run up to publishing -06 = and was following the "What is a stream manager" discussion, but thought = it was headed in the right direction. I missed Peter's proposal of the = text and its incorporation, but might have still missed the implications = of letting the IESG and IAB select outside their membership even if I = had seen it. I saw it with my last review of -07 and here we are. >=20 > This is a new issue, triggered by the changes between -05 and -06, not = a revisitation of an old one (or as you've tried to cast it - a = relitigation). And as far as I can tell it is probably now moot. >=20 > Later, Mike >=20 >=20 >=20 >>=20 >> Eliot >>=20 >>=20 >>=20 >>=20 >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_9B62DB00-8AC2-4C6B-881C-670E39528347 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 20 Dec 2021, at 18:54, Michael StJohns <msj@nthpermutation.com> wrote:

=20 =20
Hi -

Most of you should ignore what follows.  I've made my comment about the possible need to = revisit the role of the RSAB in reviewing the RSCE in light of the expansion of possible RSAB members outside the sending organizations.   As I said in my previous email, this is = not a hill I am willing to die on, and I expected the discussion would have been short. 

Unfortunately, Eliot's last message needs a response to correct both facts and conclusions.  Most = of this was in my previous email or implied from it.  

In any event, feel free to ignore = this and I apologize in advance for using up space in your mailbox on this.



Hi Eliot -

I reached out to Heather to make sure = I understood the history of the "stream managers".   = According to her this was the ground truth:
At the beginning of her tenure, the stream managers were the three chairs and the ISE.  = Sometime after Andrew was selected as IAB chair he started devolving responsibilities to other IAB members - the IAB stream manager's job being one of them.  There appears to have been a brief discussion about this among that group, with the result that it was felt that any member of the IAB could represent the IAB, and likewise for the IESG.   But at no time was there even = the hint of discussion that it would be appropriate for either of those groups to appoint a non-member.  

For the IRTF, the chair was the default and as of at least 2019 or before the IRTF chair also claimed the right to delegate (https://irtf.= org/policies/cross-stream-updates.html). =  

I wrote that page, after discussion about cross-stream = updates with the IRSG and IESG. It was published in October 2019. The = phrasing "The IRTF stream manager (i.e., the IRTF chair, or = their delegate)=E2=80=9D was my understanding of the status quo at = that time, not a new claim. 

RFC = 2014 is silent on the topic. RFC 7827 states that some of the = administrative duties of the IRTF chair "may be permanently or = temporarily delegated to other IRSG members=E2=80=9D. I believe stream = manager is included in the set of responsibilities that could be delegated. I=E2=80=99m not aware that it has been delegated.
As far as I've been able to tell (and I'll ask Adrian and/or Nevil to chime in if I'm wrong), there was no discussion among the stream managers that the IRTF chair would go outside the IRTF community for such a member. =

It would = be a matter for the IRTF Chair and IAB to discuss if there were any such = proposal. 

Remember that, unlike the IETF, IRTF RGs have (or are supposed to have) a defined membership and that would probably be considered the = community.

Research groups may have open or closed = membership. All current RGs have open membership, hence there is no = defined set of members for any IRTF RG.

Colin




AFAICT, up to the time we started = this program, only the IAB had taken advantage of the looser interpretation of the stream manager and appointed a = non-chair.   I may be wrong about that given that these positions were not generally announced to a public mailing list as they were primarily administrative.



On 12/18/2021 4:34 PM, Eliot Lear wrote:


Here is 00:


   o  One delegate representing the IETF =
stream, appointed by the IESG

   o  One delegate representing the IAB stream, appointed by the IAB

   o  The IRTF Chair, representing the IRTF stream

   o  The Independent Submissions Editor [RFC8730]

   o  The RFC Series Editor/Adviso

Here is -07:


   *  As the stream representative for =
the IETF stream, an IESG member
      or other person appointed by the IESG

   *  As the stream representative for the IAB stream, an IAB member or
      other person appointed by the IAB

   *  As the stream representative for the IRTF stream, the IRTF chair
      or other person appointed by the IRTF Chair

   *  As the stream representative for the Independent stream, the
      Independent Submissions Editor (ISE) [RFC8730] or other person
      appointed by the ISE

   *  The RFC Series Consulting Editor

In summary:

  • The word delegate was removed,
  • The IRTF chair and ISE now can appoint = representatives. 
  • We adopted the term RSCE.

The above is correct, but ignores both = the history of who had the stream manager role, and the reality of the changes between -05 and -06.

-01 clarified the ability of the IRTF chair to = appoint a delegate that historically existed but was missed in -01.


So we went from a situation = where the worst case was two of the RSAB member were Nomcom selected, with two members selected by a Nomcom selected body (e.g. the IAB) to a possible worst case of 4 RSAB members selected from the community, with two of them selected by a Nomcom selected body and two selected by other appointees.

As= you can see, it was always the case that the IAB and IESG could select people from outside their ranks if they so = chose.

This is incorrect.

The discussion between -05 and -06 under the = subject of "Who are the stream managers?" started by Lars at https://mailarchive.ietf.org/arch/msg/rfced-future/j0ulWNMM= PzJsNTnIx0eLsazviFU/ made it clear that the question you thought was disposed of by issue 38 was still unresolved.  To whit: 

Lars:

All this leaves me with a bunch of questions = about whether stream managers and stream approving bodies are just two terms for the same role. If the roles are different, is there any RFC that I missed that would define who the stream managers = are?

John K:

If we are doing something different, e.g., with named individuals as RSAB members, perhaps it would be helpful to drop the "manager" terminology and talk about "stream representative", "stream spokesperson", or "stream designee".

NEW: The approval bodies for the RFC streams are the IAB, IESG, IRSG, and ISE. Each approval body designates, by a method of its choosing, a Stream Representative to act as an administrative point of contact on behalf of that stream and member of the RSAB.

Colin:

If we go that route, I=E2=80=99d suggest IAB = and IESG select one of their members to be their stream manager, IRTF Chair and ISE are the managers for the respective streams but can delegate.

Peter:  https://mailarchive.ietf.org/arch/msg/rfced-future/KCZFN0nE= FjFC92XafoG8s_2Pmt8/

> If we go that route, I=E2=80=99d suggest = IAB and IESG select one of their members to be their stream manager, IRTF Chair and ISE are the managers for the respective streams but can delegate.

 I think that's effectively what our current text says.

John K: https://mailarchive.ietf.org/arch/msg/rfced-future/JJAfHcCn= 3OoxfF1AGps3oV1hwJM/
> I think that's effectively what our = current text says.

Yes, modulo another distinction. There is a significant distinction between our piling this on the Chairs and then saying "they can delegate" versus our saying "up to the body". "More duties, responsibilities, and power to the Chairs" is not necessarily a good idea and should be beyond the scope of this effort to decide anyway. So..


And so on.  The discussion makes clear that = before October 12th, there was no consensus on whether the IAB or IESG could appoint non-(IAB/IESG)members to the RSAB and an assumption (at least according to Peter and others who replied to Peter's comment) was that the IAB and IESG were expected to select from their membership.  

Peter proposed the -06 language  in https://mailarchive.ietf.org/arch/msg/rfced-future/KCZFN0nE= FjFC92XafoG8s_2Pmt8/ which removed any language about requiring the IAB/IESG to appoint from their membership and that's what ultimately made it in when the discussion petered (pun intended) out.  There wasn't a = formal consensus call on the text, but there was on the document.

We = did discuss whether those delegates should be from those bodies.  = That was Issue 38, raised by Martin Thomson in April.  =

Issue #38 ended up getting revisited by the = discussion between -05 and -06.  38 closed without any changes to the delegation process and AFAICT no text changes were attributed to that = issue.  Specifically your summary of

On this issue 38, based on discussion on list = and in the meeting, we think we have consensus that the appointing bodies should establish their own policies as to how their representatives are appointed.

Ended up = needing clarification which clarification was addressed in October and that resulted in an effective change from the status quo. 

Note that issue 38 was closed on August 27th, = which means that changes from this issue should have shown up in -02 - none did.


We found consensus on that one in August.  We eliminated = the word "delegate" because people couldn't agree on its implications, and so we found a clearer phrasing.  Allowing = the ISE and IRTF chair to appoint a representative was intended to address risks of excessive processing delays by the RSAB due to vacancies.

Nope - this didn't happen until -05 to = -06 - October, not August.

It's okay to get busy.  This organization has a history = of tolerating issues that are raised late in the process.  But = if an issue got addressed while you were doing other things, that's not a reason to revisit it.

I was busy on the principles stuff during = the run up to publishing -06 and was following the "What is a stream manager" discussion, but thought it was headed in the right = direction.  I missed Peter's proposal of the text and its incorporation, but might have still missed the implications of letting the IESG and IAB select outside their membership even if I had seen it.  I = saw it with my last review of -07 and here we are.

This= is a new issue, triggered by the changes between -05 and -06, not a revisitation of an old one (or as you've tried to cast it - a relitigation).   And as far as I can tell it is = probably now moot.

Later, Mike



Eliot




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



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




= --Apple-Mail=_9B62DB00-8AC2-4C6B-881C-670E39528347-- From nobody Mon Dec 20 16:19:16 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF11E3A0E2C for ; Mon, 20 Dec 2021 16:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 BErkl35j_Sr1 for ; Mon, 20 Dec 2021 16:19:11 -0800 (PST) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F1A3A0E23 for ; Mon, 20 Dec 2021 16:19:11 -0800 (PST) Received: by mail-qk1-x72f.google.com with SMTP id l25so11027746qkl.5 for ; Mon, 20 Dec 2021 16:19:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=ZvV5qPS7yBbaW+XS2aZpFCyidyJzoHzSHJKFUctLSRs=; b=hCWMkDQBrK8cBjydtJptXcq/XYWBy3c/0+wMeFRJfklY/goONYqhaHwdeGjMohUf/b L6xOD3B+XpTrme/7s0BqPfeM+ILRMyf2KwMlnC7D5i/uwO76kX5OPTU2SFPdWBWFfwq6 XRpSDoiDyoCNfsua+x/T9ETM1Gdu+FYEa34Yufs54CvkZHpW7J+3qGiANior0aNJ1F13 Bkau1FmSkIQvsCn3DE0cejK3RgQMPF+QqPHgN3I9oh20uz3GozllM/xge+0FNnS2GCGB 7D7cqipgEF3cin5amlkOIgZFqE/7c4C2mLVeG3DVVm4WK2Egqsfxr15F0Kad9wz+tS88 UOCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=ZvV5qPS7yBbaW+XS2aZpFCyidyJzoHzSHJKFUctLSRs=; b=IQ8DrfjH+VR0eMLez529Y4OS7yId1sBIqV39bdXTW9aW9p1KFaO9JOwokdmoFbjnNH j5egfTqMAk5Zk6B37A7dzQAhq53rQcRMNrtKAgjsqC6MDPfn23PN/Pp9RxORaAqvXk4o xDFdwCkw2rS0EznpweYKpChjAS87r/04tXPOwuOf6agM6BdgMT+95Vl/gSLVAeUvKNBQ E5WztfR3KcAz9sShCNK9ZhSHdiilpGhAp40+UyXWm7G2qhnKHIGGpgKXIMZHfWCHCqEJ WEuCojyIk9aq6w5u8+RarXh44aHp9OOsu1hbfFDd4nqUaNgrWAcbiccBlQP9kzAHpUHH wMuQ== X-Gm-Message-State: AOAM5312JzufRscmzm1pR6I9ev1wLD02H7VWcxGBV9KVV/j3J5LM7ONj FKWGtNsQfb7N5ls+l8kKs5gOEEaZX4BIiCrF X-Google-Smtp-Source: ABdhPJx1lU0l0Kz/J+azapsQa26UvqsMGvEs8lEoiHhrgXGtUVqw29jbidLrGV3UlFviefK1xh6+Ow== X-Received: by 2002:a37:658:: with SMTP id 85mr522878qkg.668.1640045949419; Mon, 20 Dec 2021 16:19:09 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id m1sm15604581qtk.34.2021.12.20.16.19.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 20 Dec 2021 16:19:08 -0800 (PST) Content-Type: multipart/alternative; boundary="------------uBkDwbr0yNFkQ4F028JaDwsR" Message-ID: Date: Mon, 20 Dec 2021 19:19:07 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Colin Perkins Cc: rfced-future@iab.org References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> <72cdd59f-3473-b055-38eb-4f57bd204369@nthpermutation.com> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] RSAB membership; was Re: Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:19:15 -0000 This is a multi-part message in MIME format. --------------uBkDwbr0yNFkQ4F028JaDwsR Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 12/20/2021 6:53 PM, Colin Perkins wrote: >> Remember that, unlike the IETF, IRTF RGs have (or are supposed to >> have) a defined membership and that would probably be considered the >> community. > > Research groups may have open or closed membership. All current RGs > have open membership, hence there is no defined set of members for any > IRTF RG. > > Colin Hi Colin - I don't necessarily disagree with the above (or the parts I edited out), but even with open membership (RFC 2014): The IRTF is a composed of a number of focused, long-term, SMALL Research Groups. Research Groups are expected to have the STABLE long term MEMBERSHIP needed to promote the development of research collaboration and teamwork in exploring research issues. Emphasis mine. Open vs closed applies to how members are enrolled in the RG (e.g. does the existing membership get a vote on who joins - yes -> closed, no -> open), not so much on whether they're expected to be identifiable, long term and active participants. So while I believe your statement that no RG has a defined set of members, I'm wondering if that is consistent with the intent of 2014, whether it should be , and how long since there was a membership model? It's possible this is no longer the way the IRTF should be viewed, in which case it may be time for a complete update of RFC 2014. But that's obviously not an RFCED topic. Thanks - Mike --------------uBkDwbr0yNFkQ4F028JaDwsR Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/20/2021 6:53 PM, Colin Perkins wrote:
Remember that, unlike the IETF, IRTF RGs have (or are supposed to have) a defined membership and that would probably be considered the community.

Research groups may have open or closed membership. All current RGs have open membership, hence there is no defined set of members for any IRTF RG.

Colin


Hi Colin -

I don't necessarily disagree with the above (or the parts I edited out), but even with open membership (RFC 2014): 

   The IRTF is a composed of a number of focused, long-term, SMALL
   Research Groups.
   Research Groups
   are expected to have the STABLE long term MEMBERSHIP needed to
   promote the development of research collaboration and teamwork in
   exploring research issues.
Emphasis mine.

Open vs closed applies to how members are enrolled in the RG (e.g. does the existing membership get a vote on who joins - yes -> closed, no -> open), not so much on whether they're expected to be identifiable, long term and active participants.  So while I believe your statement that no RG has a defined set of members, I'm wondering if that is consistent with the intent of 2014, whether it should be , and how long since there was a membership model?

It's possible this is no longer the way the IRTF should be viewed, in which case it may be time for a complete update of RFC 2014.

But that's obviously not an RFCED topic.

Thanks - Mike


--------------uBkDwbr0yNFkQ4F028JaDwsR-- From nobody Mon Dec 20 16:36:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738FF3A0E51 for ; Mon, 20 Dec 2021 16:36:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=csperkins.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzrbh-ePfR_n for ; Mon, 20 Dec 2021 16:36:37 -0800 (PST) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0323A08B8 for ; Mon, 20 Dec 2021 16:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=csperkins.org; s=mythic-beasts-k1; h=To:Date:Subject:From; bh=TqGawZWCHtCdq5KqMPsclgH3OnvMYJ7XJbu5BNF/Mek=; b=W/fUk8TpBAQzXUE6JpA8zO2TXC UhrsRt0/c88FtzEaj/beCCyZ2G8r/jAOpT0aNB31EdtLG6hVpxazol2AceZRxWr91ua7ew0OZOw00 Kuar9paxYLJM4MvPViwSf065zzguXys4/lxlIiJhw+fmevViGDp+Ticp5lcf8/bquRmAi3+n2Xria 7GhwxxtA1xHVk1SmmR4jGFhRGMi+LcZMsukDqeA367D3EvjvbjUaqOjuiWCRP1XVfhcfVTJKqvs7M XT4PEhU9OraWhhtp41Uh4zLjqz55x3qdrKfZxvtZfbcRIM6K3NB8QuoAvIOJ+GQuAUWIPbQcnMZ9b s3Izgxeg==; Received: from [81.187.2.149] (port=36408 helo=[192.168.0.67]) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from ) id 1mzT8o-0008J6-PW; Tue, 21 Dec 2021 00:36:35 +0000 From: Colin Perkins Message-Id: <3C870B07-53F2-44EF-A4E1-3B9E0FEA910E@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_5A2B5120-ACF2-4299-839D-3EB4D98163CA" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Date: Tue, 21 Dec 2021 00:36:28 +0000 In-Reply-To: Cc: rfced-future@iab.org To: Michael StJohns References: <1685B8A4-F5DE-4A49-9CC3-94B9B719BA7E@kuehlewind.net> <1397ce86-40a8-6087-2842-769beb5b79cf@stpeter.im> <74c75ee2-7343-3e82-0742-6608f4968a54@stpeter.im> <37B079C1B661437AA93F47C7@PSB> <28B8EF84-DF9B-41A5-8A05-C4049DC52C1D@ietf.org> <64351ca7-c13f-a92c-8df9-7374148b6023@nthpermutation.com> <90e3d8fc-9621-7c98-df2d-290d5f30cb69@lear.ch> <8DD8DC80C6CD5605BDD0E07B@PSB> <8f44f403-6f30-8c4c-fd44-aa9ce85a4140@nthpermutation.com> <72cdd59f-3473-b055-38eb-4f57bd204369@nthpermutation.com> X-Mailer: Apple Mail (2.3445.104.21) X-BlackCat-Spam-Score: 14 Archived-At: Subject: Re: [Rfced-future] RSAB membership; was Re: Relitigating (was: Re: RPC liaison to the RSAB) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:36:44 -0000 --Apple-Mail=_5A2B5120-ACF2-4299-839D-3EB4D98163CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 21 Dec 2021, at 00:19, Michael StJohns = wrote: > On 12/20/2021 6:53 PM, Colin Perkins wrote: >>> Remember that, unlike the IETF, IRTF RGs have (or are supposed to = have) a defined membership and that would probably be considered the = community. >>=20 >> Research groups may have open or closed membership. All current RGs = have open membership, hence there is no defined set of members for any = IRTF RG. >>=20 >> Colin > Hi Colin - >=20 > I don't necessarily disagree with the above (or the parts I edited = out), but even with open membership (RFC 2014):=20 >=20 > The IRTF is a composed of a number of focused, long-term, SMALL > Research Groups. > Research Groups > are expected to have the STABLE long term MEMBERSHIP needed to > promote the development of research collaboration and teamwork in > exploring research issues.=20 >=20 > Emphasis mine. > Open vs closed applies to how members are enrolled in the RG (e.g. = does the existing membership get a vote on who joins - yes -> closed, no = -> open), not so much on whether they're expected to be identifiable, = long term and active participants. So while I believe your statement = that no RG has a defined set of members, I'm wondering if that is = consistent with the intent of 2014, whether it should be , and how long = since there was a membership model? >=20 I believe the current RGs operate in a manner that=E2=80=99s consistent = with RFC 2014.=20 > It's possible this is no longer the way the IRTF should be viewed, in = which case it may be time for a complete update of RFC 2014. >=20 > But that's obviously not an RFCED topic. >=20 As you say, this is off-topic for this list. --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_5A2B5120-ACF2-4299-839D-3EB4D98163CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = 21 Dec 2021, at 00:19, Michael StJohns <msj@nthpermutation.com> wrote:
=20 =20
On 12/20/2021 6:53 PM, Colin Perkins wrote:
Remember that, unlike the = IETF, IRTF RGs have (or are supposed to have) a defined membership and that would probably be considered the community.

Research groups may have open or closed = membership. All current RGs have open membership, hence there is no defined set of members for any IRTF RG.

Colin

Hi Colin -

I = don't necessarily disagree with the above (or the parts I edited out), but even with open membership (RFC 2014): 

   The IRTF is a composed of a number of =
focused, long-term, SMALL
   Research Groups.
   Research Groups
   are expected to have the STABLE long term MEMBERSHIP needed to
   promote the development of research collaboration and teamwork in
   exploring research issues.=20
Emphasis mine.

Open vs closed applies to = how members are enrolled in the RG (e.g. does the existing membership get a vote on who joins - yes -> closed, no -> open), not so much on whether they're expected to be identifiable, long term and active = participants.  So while I believe your statement that no RG has a defined set of members, I'm wondering if that is consistent with the intent of 2014, whether it should be , and how long since there was a membership model?

I = believe the current RGs operate in a manner that=E2=80=99s consistent = with RFC 2014. 

It's possible this is no longer the way the IRTF = should be viewed, in which case it may be time for a complete update of RFC 2014.

But that's obviously not an RFCED = topic.

As you say, = this is off-topic for this list.

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




= --Apple-Mail=_5A2B5120-ACF2-4299-839D-3EB4D98163CA-- From nobody Wed Dec 22 12:56:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E0E3A0C19 for ; Wed, 22 Dec 2021 12:56:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20210112.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 qYgj_UvaJyA3 for ; Wed, 22 Dec 2021 12:56:39 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5015B3A0C25 for ; Wed, 22 Dec 2021 12:56:39 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id 8so3101416qtx.5 for ; Wed, 22 Dec 2021 12:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:content-language:to:from :subject; bh=g4lJ1OAUTVOeFb+zr+6EiXdzDY0rJ2L0XIggE8I6kP0=; b=F0KH9eVJXdIJbnegA+xXKFfifdlqyteey/0JspDup/l3gqZHlsYaZOIBgwS3YzYZAI qky0VrjO1vJs/ga6WWOmp6jhwKUmn+PEhNRdcoi6UpaMbswp6eWU1DQr+v0HaOicC9a/ ZIPJcR+B7z2jDmC/wlNHlEqkVmsfmpoAihEeI+MBuJsb//WYhK3uq12EAR3+bG+J+PqV Go15srgLRr2/en++V9TuehFlO3dqONbFpSoqOsnHoLPEM/dlhZsyIMJ+Wjf8iSS8UZB1 OSMlqm361gasxhQm0xFQxPAv49jNwRvHtAsz2gkRLiZOb1DqXc0XWWW+MG+l9Sw7VKXt +Blw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent :content-language:to:from:subject; bh=g4lJ1OAUTVOeFb+zr+6EiXdzDY0rJ2L0XIggE8I6kP0=; b=nLxZ1QjjzvsN7Mj4cB3ojf7puk4+sC7ZxxE8/2rcvM+sFh6pWjAHAM6Lzuhwh5gxFw CoGgbIRqvStK9LT4ULErWGK1cr+tncSo5VqW1dOjmqzGA+OY+0uZBB6iB4RAj6QF3/i4 DCIT5+cusVwaj2ZFh9lCpBax27JrdtDNhfi8y4SNaboYqsuDWWrw8+1t8nEcWY0uZbX4 FFgvdvNBHaKi2Fbo5Y2Rq/ZLvLZOlWDBvxRHe+ntUS/RYfn37ftXbFnV9RxEdCugc9Tm Dly3eaGg40At4kVA/jcaYUNWdn6hj8cyh0mCi/CUxQSv0nhnMMiWRg9Ec8H6MTUmaId6 BatQ== X-Gm-Message-State: AOAM532siEARfBAGFKZ4f03aYKuQNs7o24GXPiSvUkbIUhptXLQxDN51 9OstJhVv2DjYgsHbLdkZjCiB5Z/CigMtBa+L X-Google-Smtp-Source: ABdhPJwfIIxkmBtKd3tS0xjoNJvTyHbUSSEaVaZPAl+KuDIim06zFeHhh1smX3POWEpd5ZgxY4iTEw== X-Received: by 2002:a05:622a:34c:: with SMTP id r12mr3547339qtw.403.1640206596424; Wed, 22 Dec 2021 12:56:36 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id f8sm2559550qtk.1.2021.12.22.12.56.35 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Dec 2021 12:56:35 -0800 (PST) Content-Type: multipart/alternative; boundary="------------dR8C10IK6DAPv8S00huOlWwa" Message-ID: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> Date: Wed, 22 Dec 2021 15:56:34 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: "rfced-future@iab.org" From: Michael StJohns Archived-At: Subject: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:56:45 -0000 This is a multi-part message in MIME format. --------------dR8C10IK6DAPv8S00huOlWwa Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit As I noted before, this is in pretty good shape excluding the RPC RSAB membership stuff and maybe a few more things. S 3.2.4 - "Appeals of RSWG decisions..." - The RSWG doesn't make decisions, it comes to consensus and that consensus is judged by the RSWG chairs.  So instead "Appeals of any decisions of the RSWG chairs, including declining to decide an open issue in their purview after a suitable period shall be made to the RSAB." Similarly in the next sentence.  "Decisions of the RSWG chairs..." and later "... notice having been given to the RSWG [mailing list | chairs]?" - I think this is editorial. S 4.3, bullet 8 - noted elsewhere, still haven't had an issue opened.  Question is whether this bullet is an "RPC MAY participate in the RSWG as it needs to" or "RPC MUST participate".   Since the bullets open with More specifically, the RPC's responsibilities at the time of writing include the following:  it currently reads as a "MUST", and I'm not sure they are resourced for it, nor whether this makes the most sense for their current skillsets and staffing.   I'd be happy with clarifying this is an optional (MAY) interaction, especially since we appear to have settled on the RPC being a non-voting ex officio member of the RSAB.  So text: 8. The RPC may, as it determines necessary, participate within the RSWG in the creation of new Editorial Stream RFCs, especially those that might impact the RPC. I explicitly left out "advisory" here - I think the RSWG open group model really should avoid restricting people to an advisory role.  That's left to the following proposed language: 8.1 The RPC may participate in the RSAB as a non-voting ex-officio member primarily as an advisor on RPC capabilities, schedules, staffing and resources. S 4.3 bullet 16 - Is this needed if the RPC is an ex officio member of the RSAB?  Shouldn't that be where this interaction mostly happens?  "Stream approving bodies" is different than "stream manager" and not having a single POC might be problematic.  (Sorry - I see this change was made -05 to -06, but there are a number of places in this document where telling the RPC to talk to an organization is just a bad idea - this comes under the heading of unintended consequences). S 4.6.2 - S/The/Most/ first word.   I think we're adding or changing some costs here, but claiming there are no new expenses is more probably wrong that right. - nit. S 5.3 - Reading this - is it possible for a temporary RSCE to be appointed as a volunteer?  (Was Olaf K an unpaid volunteer during his short term as RSE?).  If a volunteer steps in temporarily, does that change who gets to do the approvals?  Happy if the answer to "unpaid volunteer" is no, but if yes, not sure why the LLC would need to sign off. S 6 - 2nd para - "The Editorial Stream will be used...." to "The Editorial Stream shall be used..." - nit. S 6.1 "These procedures need to also allow authors to indicate either no rights to make derivative works, or preferentially, the right to make unlimited derivative works from the documents." is probably to specific.   I looked at this one and I think I see a land mine. We're trying to specify legal language here and if not careful could conflict with the language of 5378.  Instead: These procedures need to allow authors to indicate rights requests consistent with BCP78 (currently RFC5378) or it successor.   The publication of a successor document to RFC5378 and designation as BCP 78 shall be effective on the Editorial Stream process as of the BCP's publication date. Or get a lawyer to craft this. S 7 - I'm mostly happy with the list, but I'm still unhappy there is no language that the RSAB can use these items as part of their determination as "harm to the system".  I'm afraid that the RSWG will mostly ignore these as there really is no penalty for doing so, and the RSAB won't have a leg to stand on to push back.  I'll shut up now. Good work to Peter dealing with all of this. Mike --------------dR8C10IK6DAPv8S00huOlWwa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

As I noted before, this is in pretty good shape excluding the RPC RSAB membership stuff and maybe a few more things.

S 3.2.4 - "Appeals of RSWG decisions..." - The RSWG doesn't make decisions, it comes to consensus and that consensus is judged by the RSWG chairs.  So instead "Appeals of any decisions of the RSWG chairs, including declining to decide an open issue in their purview after a suitable period shall be made to the RSAB."   Similarly in the next sentence.  "Decisions of the RSWG chairs..." and later "... notice having been given to the RSWG [mailing list | chairs]?" - I think this is editorial.

S 4.3, bullet 8 - noted elsewhere, still haven't had an issue opened.  Question is whether this bullet is an "RPC MAY participate in the RSWG as it needs to" or "RPC MUST participate".   Since the bullets open with 

   More specifically, the RPC's responsibilities at the time of writing
   include the following:
 it currently reads as a "MUST", and I'm not sure they are resourced for it, nor whether this makes the most sense for their current skillsets and staffing.   I'd be happy with clarifying this is an optional (MAY) interaction, especially since we appear to have settled on the RPC being a non-voting ex officio member of the RSAB.  So text:
8. The RPC may, as it determines necessary, participate within the RSWG in the creation of new Editorial Stream RFCs, especially those that might impact the RPC.
I explicitly left out "advisory" here - I think the RSWG open group model really should avoid restricting people to an advisory role.  That's left to the following proposed language:
8.1 The RPC may participate in the RSAB as a non-voting ex-officio member primarily as an advisor on RPC capabilities, schedules, staffing and resources.

S 4.3 bullet 16 - Is this needed if the RPC is an ex officio member of the RSAB?  Shouldn't that be where this interaction mostly happens?  "Stream approving bodies" is different than "stream manager" and not having a single POC might be problematic.  (Sorry - I see this change was made -05 to -06, but there are a number of places in this document where telling the RPC to talk to an organization is just a bad idea - this comes under the heading of unintended consequences). 

S 4.6.2 - S/The/Most/ first word.   I think we're adding or changing some costs here, but claiming there are no new expenses is more probably wrong that right. - nit.

S 5.3 - Reading this - is it possible for a temporary RSCE to be appointed as a volunteer?  (Was Olaf K an unpaid volunteer during his short term as RSE?).  If a volunteer steps in temporarily, does that change who gets to do the approvals?  Happy if the answer to "unpaid volunteer" is no, but if yes, not sure why the LLC would need to sign off.  

S 6 - 2nd para - "The Editorial Stream will be used...." to "The Editorial Stream shall be used..." - nit.

S 6.1 "These procedures need to also allow authors to indicate either no rights to make derivative works, or preferentially, the right to make unlimited derivative works from the documents." is probably to specific.   I looked at this one and I think I see a land mine. We're trying to specify legal language here and if not careful could conflict with the language of 5378.  Instead:

These procedures need to allow authors to indicate rights requests consistent with BCP78 (currently RFC5378) or it successor.   The publication of a successor document to RFC5378 and designation as BCP 78 shall be effective on the Editorial Stream process as of the BCP's publication date.

Or get a lawyer to craft this.


S 7 - I'm mostly happy with the list, but I'm still unhappy there is no language that the RSAB can use these items as part of their determination as "harm to the system".  I'm afraid that the RSWG will mostly ignore these as there really is no penalty for doing so, and the RSAB won't have a leg to stand on to push back.  I'll shut up now.

Good work to Peter dealing with all of this.

Mike



--------------dR8C10IK6DAPv8S00huOlWwa-- From nobody Wed Dec 22 13:12:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FA03A0C43 for ; Wed, 22 Dec 2021 13:12:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.941 X-Spam-Level: X-Spam-Status: No, score=-3.941 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3vUmdSLdpTj for ; Wed, 22 Dec 2021 13:12:52 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 B4E9E3A0C41 for ; Wed, 22 Dec 2021 13:12:51 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BMLCmTn2231800 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 22 Dec 2021 22:12:49 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1640207569; bh=kp2ld93Y3zL7MNf1lsqRMzkZdSOz1bwZFoYsr2hGgHU=; h=Date:To:References:From:Cc:Subject:In-Reply-To:From; b=Gyq+AUsNwMLSgBXYC5eZOzVkqBJrcvVjumqXpN5JR7E3Yi+uKplnAtTPFmDht3gdn a1vUnaQ8QHJlRHx0OQeInBgYLUCp73yXJxFC7fBnvR9dq0gMTlOe+yE3WYqG0uzIcg F1e9NxuFaw6RraiIrakJvzQ/RqqPRVeohSFmq5XY= Message-ID: Date: Wed, 22 Dec 2021 22:12:48 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Michael StJohns References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> From: Eliot Lear Cc: "rfced-future@iab.org" In-Reply-To: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------61NtL0MZGjgH7Knqsfw0747O" Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:12:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------61NtL0MZGjgH7Knqsfw0747O Content-Type: multipart/mixed; boundary="------------u0T3YbmHCjwbm6XQfTNXgfpi"; protected-headers="v1" From: Eliot Lear To: Michael StJohns Cc: "rfced-future@iab.org" Message-ID: Subject: Re: [Rfced-future] Comments on -07 References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> In-Reply-To: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> --------------u0T3YbmHCjwbm6XQfTNXgfpi Content-Type: multipart/alternative; boundary="------------BUpi9MVE9y2fjAOMXg3VC9JJ" --------------BUpi9MVE9y2fjAOMXg3VC9JJ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgTWlrZSwNCg0KSnVzdCBvbiB0aGlzIG9uZSBmb3Igbm93Li4uDQoNCk9uIDIyLjEyLjIx IDIxOjU2LCBNaWNoYWVsIFN0Sm9obnMgd3JvdGU6DQo+DQo+IFMgNyAtIEknbSBtb3N0bHkg aGFwcHkgd2l0aCB0aGUgbGlzdCwgYnV0IEknbSBzdGlsbCB1bmhhcHB5IHRoZXJlIGlzIA0K PiBubyBsYW5ndWFnZSB0aGF0IHRoZSBSU0FCIGNhbiB1c2UgdGhlc2UgaXRlbXMgYXMgcGFy dCBvZiB0aGVpciANCj4gZGV0ZXJtaW5hdGlvbiBhcyAiaGFybSB0byB0aGUgc3lzdGVtIi7C oCBJJ20gYWZyYWlkIHRoYXQgdGhlIFJTV0cgd2lsbCANCj4gbW9zdGx5IGlnbm9yZSB0aGVz ZSBhcyB0aGVyZSByZWFsbHkgaXMgbm8gcGVuYWx0eSBmb3IgZG9pbmcgc28sIGFuZCANCj4g dGhlIFJTQUIgd29uJ3QgaGF2ZSBhIGxlZyB0byBzdGFuZCBvbiB0byBwdXNoIGJhY2suwqAg SSdsbCBzaHV0IHVwIG5vdy4NCj4NClRoZSB3YXkgUGV0ZXIgY29uc3RydWN0ZWQgdGhpcyB0 ZXh0LCB0aGUgZm9sbG93aW5nIGJ1bGxldCB3YXMgYWRkZWQ6DQoNCiAgICAqICBDb21tZW50 cyByZWNlaXZlZCBkdXJpbmcgYSBjb21tdW5pdHkgY2FsbCBmb3IgY29tbWVudCBuZWVkIHRv IGJlDQogICAgICAgYWRkcmVzc2VkLCBhcyBkZXNjcmliZWQgdW5kZXJTZWN0aW9uIDMuMi4z ICA8aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pYWItcmZj ZWZkcC1yZmNlZC1tb2RlbCNzZWN0aW9uLTMuMi4zPi4NCg0KQW5kIHRoZW4gaWYgeW91IGxv b2sgaW50byBTZWN0aW9uIDMuMi4zIHlvdSBzZWU6DQoNCj4gICAgIFRoZSBSU0FCIGlzIHJl c3BvbnNpYmxlIGZvciBjb25zaWRlcmluZyBjb21tZW50cyByZWNlaXZlZCBkdXJpbmcgYQ0K PiAgICAgY29tbXVuaXR5IGNhbGwgZm9yIGNvbW1lbnQuICBJZiBSU0FCIG1lbWJlcnMgY29u Y2x1ZGUgdGhhdCBzdWNoDQo+ICAgICBjb21tZW50cyByYWlzZSBpbXBvcnRhbnQgaXNzdWVz IHRoYXQgc2hvdWxkIGJlIGFkZHJlc3NlZCwgdGhleSBzaG91bGQNCj4gICAgIGRvIHNvIGJ5 IGRpc2N1c3NpbmcgdGhvc2UgaXNzdWVzIHdpdGhpbiB0aGUgUlNXRyBvciBsb2RnaW5nIGEN Cj4gICAgIHBvc2l0aW9uIG9mICJDT05DRVJOIiBkdXJpbmcgUlNBQiBiYWxsb3RpbmcuDQoN ClRoZXNlIHR3byB0ZXh0cyBhcmUgcmVmZXJlbmNlZCBpbiB0aGUgU2VjdGlvbiA3IGNoYXBl YXUuDQoNClNvIHRoZXJlIGlzIGEgYml0IG9mIGluZGlyZWN0aW9uIGluIHRoZSB0ZXh0LsKg IFRoaXMgc2F2ZXMgc3BhY2UgYW5kIA0KYXZvaWRzIGludHJvZHVjaW5nIGFtYmlndWl0aWVz LCBidXQgbWF5IHNlZW0gYSBiaXQgZGlzam9pbnQuIE9uIHRoZSANCnN1YnN0YW5jZSwgUlNB QiBtZW1iZXJzIG5vdyBoYXZlIGEgZmFpciBhbW91bnQgb2YgbGF0aXR1ZGUsIGFzIEkgcmVh ZCBpdC4NCg0KRG8geW91IGRpc2FncmVlP8KgIEl0IGNvdWxkIGJlIHRoYXQgdGhpcyBpcyBh biBlZGl0b3JpYWwgbWF0dGVyLiBJdCBtYXkgDQpoZWxwIHRvIGhhdmUgc29tZSBhZGRpdGlv bmFsIGZvcndhcmQgcmVmZXJlbmNlcy4NCg0KRWxpb3QNCg0KDQo= --------------BUpi9MVE9y2fjAOMXg3VC9JJ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Mike,

Just on this one for now...

On 22.12.21 21:56, Michael StJohns wrote:

S 7 - I'm mostly happy with the list, but I'm still unhappy there is no language that the RSAB can use these items as part of their determination as "harm to the system".=C2=A0 I'm afraid = that the RSWG will mostly ignore these as there really is no penalty for doing so, and the RSAB won't have a leg to stand on to push back.=C2=A0 I'll shut up now.

The way Peter constructed this text, the following bullet was added:

   *  Comments received during a community cal=
l for comment need to be
      addressed, as described under Section 3.2.3.

And then if you look into Section 3.2.3 you see:

   The RSAB is responsible for considering=
 comments received during a
   community call for comment.  If RSAB members conclude that such
   comments raise important issues that should be addressed, they should
   do so by discussing those issues within the RSWG or lodging a
   position of "CONCERN" during RSAB balloting.

These two texts are referenced in the Section 7 chapeau.

So there is a bit of indirection in the text.=C2=A0 This saves spa= ce and avoids introducing ambiguities, but may seem a bit disjoint.=C2= =A0 On the substance, RSAB members now have a fair amount of latitude, as I read it.

Do you disagree?=C2=A0 It could be that this is an editorial matte= r.=C2=A0 It may help to have some additional forward references.

Eliot


--------------BUpi9MVE9y2fjAOMXg3VC9JJ-- --------------u0T3YbmHCjwbm6XQfTNXgfpi-- --------------61NtL0MZGjgH7Knqsfw0747O Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmHDlNAFAwAAAAAACgkQh7ZrRtnSejPo qggAleayRibRnazGH3owhON3EOpqU5ZGAQ6mnb1ddkcjlYfpfamP6k7VAHaOCwknQTOrMV0re+TB z8sCsGp6uGCFFODqE3MqGVn6zUo428WdqXyt1PK9HvAM7fkewGvAdm+b44G67bj29qUYHqgMOOWI Fer2B3etnMdjPiVdA+mf/uJHUWTunEcwp8eYTrXEdQNKeoZ+yCfRCbviihjv+3q5JXXBhX3r9ipb tqc/FBEY8mFbCVlU8M1RFGU2zg6BqtEHB6BV0NBj3ak4qVeUx10Jbgaz08fC7NOOpcLCjnhEyouW Z4/GJiGy58XFLSHvNNwFt6azywOOjGRran3Y+ExQpQ== =5vD5 -----END PGP SIGNATURE----- --------------61NtL0MZGjgH7Knqsfw0747O-- From nobody Wed Dec 22 13:22:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F0B3A0C51 for ; Wed, 22 Dec 2021 13:22:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 WlTmx2QKJ9my for ; Wed, 22 Dec 2021 13:22:27 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1188D3A0C50 for ; Wed, 22 Dec 2021 13:22:27 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id a11so3567480qkh.13 for ; Wed, 22 Dec 2021 13:22:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=67+hVt2yAdC+qlkxjlH4yjZDNevySEvi3L/cpzqOfpU=; b=YVznmXSavk8y++eu2FPKmZ4/0Z+S0HTdoQoBnkKXp/21H6fJp+Dw5DtqUtCrAuxi4V Jr08mrbf8UzAfh93VHW+ahm3/J9Rm6EjUtUFGw83Jdo0O8Wt6LkZ+4mPvSUKmgzAym/J 0N+xhL88n6nqDCqNk7mAOrWuZUCy7b2KnPWGx7eEIQoAG6pb9NJHY1eQb0QJIVbcpSaV yCVBRJ34PaGKdxZ9DBd5RzELDq/1T18e7d/IK7HGuszd3m4DnsAzR0lvmS0OTaYOHW/t Jv6uE7gelVVKnmnDn07IxrvTDPK91spvfcw3fWVJQifDoYdQfd12hcgZl/0PzYSC2Qqu 9fNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=67+hVt2yAdC+qlkxjlH4yjZDNevySEvi3L/cpzqOfpU=; b=YWHcyS2bhxZ1hVM0RT/hjTHqu5nHjie+Mmn2au/zYVKKkrN+mpanp1WV9uxg5Swt+u 9snWeF+DJCphUKBKrI2ntciGV7sCehimLAAInSBe64J0o1B2hwu5cnDxbfiBu19H0w2+ jN5entVNTDYeIFJHQSmbCT25mVuokYs18L3F38TntMZVVFzw35Bk3QhGBlTgWmd9nKzl UAKjYk7DAVD8oQrddpj7+fMpGZnXSCXh4cuTj+ziAS5P8twiO9AJFoYLQSJ9QT3K92LM MZxK69EiUz9hROAZIS8lMnipIQmYtFTrKkl2C31q5OoSe42PxS4jq3RzWCnq7/5Yv2Ax SydA== X-Gm-Message-State: AOAM533xtQ+wC9RuHRtlaR16WrXGaY+077FKgcbb04wBGHwI9C3HoDW2 wMIt5TyvviDOOVJ/awNhBJoFfszu90ukkWQl X-Google-Smtp-Source: ABdhPJyWgoeiYiUS9Dz9gdSDCfDI594KJiAq8cFsKTJLHw7sXa8kR6WW+ODYT2bXpKEtIG5bZm7ejw== X-Received: by 2002:ae9:eb10:: with SMTP id b16mr3407163qkg.191.1640208144870; Wed, 22 Dec 2021 13:22:24 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id bi9sm2858747qkb.60.2021.12.22.13.22.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Dec 2021 13:22:24 -0800 (PST) Content-Type: multipart/alternative; boundary="------------c0K8Lz11f03cthT1Aamwbnq6" Message-ID: Date: Wed, 22 Dec 2021 16:22:22 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear Cc: "rfced-future@iab.org" References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> From: Michael StJohns In-Reply-To: Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:22:32 -0000 This is a multi-part message in MIME format. --------------c0K8Lz11f03cthT1Aamwbnq6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/22/2021 4:12 PM, Eliot Lear wrote: > > Hi Mike, > > Just on this one for now... > > On 22.12.21 21:56, Michael StJohns wrote: >> >> S 7 - I'm mostly happy with the list, but I'm still unhappy there is >> no language that the RSAB can use these items as part of their >> determination as "harm to the system".  I'm afraid that the RSWG will >> mostly ignore these as there really is no penalty for doing so, and >> the RSAB won't have a leg to stand on to push back.  I'll shut up now. >> > The way Peter constructed this text, the following bullet was added: > > * Comments received during a community call for comment need to be > addressed, as described underSection 3.2.3 . > > And then if you look into Section 3.2.3 you see: > >> The RSAB is responsible for considering comments received during a >> community call for comment. If RSAB members conclude that such >> comments raise important issues that should be addressed, they should >> do so by discussing those issues within the RSWG or lodging a >> position of "CONCERN" during RSAB balloting. > > These two texts are referenced in the Section 7 chapeau. > > So there is a bit of indirection in the text.  This saves space and > avoids introducing ambiguities, but may seem a bit disjoint.  On the > substance, RSAB members now have a fair amount of latitude, as I read it. > > Do you disagree?  It could be that this is an editorial matter.  It > may help to have some additional forward references. > > Eliot > > I think this meets my needs - thanks! Mike --------------c0K8Lz11f03cthT1Aamwbnq6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/22/2021 4:12 PM, Eliot Lear wrote:

Hi Mike,

Just on this one for now...

On 22.12.21 21:56, Michael StJohns wrote:

S 7 - I'm mostly happy with the list, but I'm still unhappy there is no language that the RSAB can use these items as part of their determination as "harm to the system".  I'm afraid that the RSWG will mostly ignore these as there really is no penalty for doing so, and the RSAB won't have a leg to stand on to push back.  I'll shut up now.

The way Peter constructed this text, the following bullet was added:

   *  Comments received during a community call for comment need to be
      addressed, as described under Section 3.2.3.

And then if you look into Section 3.2.3 you see:

   The RSAB is responsible for considering comments received during a
   community call for comment.  If RSAB members conclude that such
   comments raise important issues that should be addressed, they should
   do so by discussing those issues within the RSWG or lodging a
   position of "CONCERN" during RSAB balloting.

These two texts are referenced in the Section 7 chapeau.

So there is a bit of indirection in the text.  This saves space and avoids introducing ambiguities, but may seem a bit disjoint.  On the substance, RSAB members now have a fair amount of latitude, as I read it.

Do you disagree?  It could be that this is an editorial matter.  It may help to have some additional forward references.

Eliot


I think this meets my needs - thanks! 

Mike


--------------c0K8Lz11f03cthT1Aamwbnq6-- From nobody Wed Dec 22 13:54:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1C13A0CE0 for ; Wed, 22 Dec 2021 13:54:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_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 HT29zb9oU_hj for ; Wed, 22 Dec 2021 13:54:47 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC3B53A0CDF for ; Wed, 22 Dec 2021 13:54:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id D5B4D4971C56; Wed, 22 Dec 2021 13:54:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 74r23Iia4Gpp; Wed, 22 Dec 2021 13:54:47 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id 4D6144971C43; Wed, 22 Dec 2021 13:54:47 -0800 (PST) From: Jay Daley Message-Id: <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_AD0EA36C-C7CE-44DE-9AAA-8E4CB6AAD5B0" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Thu, 23 Dec 2021 10:54:42 +1300 In-Reply-To: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> Cc: "rfced-future@iab.org" To: Michael StJohns References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 21:54:53 -0000 --Apple-Mail=_AD0EA36C-C7CE-44DE-9AAA-8E4CB6AAD5B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23/12/2021, at 9:56 AM, Michael StJohns = wrote: >=20 > As I noted before, this is in pretty good shape excluding the RPC RSAB = membership stuff and maybe a few more things. >=20 > S 3.2.4 - "Appeals of RSWG decisions..." - The RSWG doesn't make = decisions, it comes to consensus and that consensus is judged by the = RSWG chairs. So instead "Appeals of any decisions of the RSWG chairs, = including declining to decide an open issue in their purview after a = suitable period shall be made to the RSAB." Similarly in the next = sentence. "Decisions of the RSWG chairs..." and later "... notice = having been given to the RSWG [mailing list | chairs]?" - I think this = is editorial. >=20 > S 4.3, bullet 8 - noted elsewhere, still haven't had an issue opened. = Question is whether this bullet is an "RPC MAY participate in the RSWG = as it needs to" or "RPC MUST participate". Since the bullets open with=20= >=20 > More specifically, the RPC's responsibilities at the time of = writing > include the following: > it currently reads as a "MUST", and I'm not sure they are resourced = for it, nor whether this makes the most sense for their current = skillsets and staffing. I'd be happy with clarifying this is an = optional (MAY) interaction, especially since we appear to have settled = on the RPC being a non-voting ex officio member of the RSAB. So text: > 8. The RPC may, as it determines necessary, participate within the = RSWG in the creation of new Editorial Stream RFCs, especially those that = might impact the RPC. > I explicitly left out "advisory" here - I think the RSWG open group = model really should avoid restricting people to an advisory role. = That's left to the following proposed language: > 8.1 The RPC may participate in the RSAB as a non-voting ex-officio = member primarily as an advisor on RPC capabilities, schedules, staffing = and resources. > S 4.3 bullet 16 - Is this needed if the RPC is an ex officio member of = the RSAB? Shouldn't that be where this interaction mostly happens? = "Stream approving bodies" is different than "stream manager" and not = having a single POC might be problematic. (Sorry - I see this change = was made -05 to -06, but there are a number of places in this document = where telling the RPC to talk to an organization is just a bad idea - = this comes under the heading of unintended consequences). =20 >=20 > S 4.6.2 - S/The/Most/ first word. I think we're adding or changing = some costs here, but claiming there are no new expenses is more probably = wrong that right. - nit. >=20 > S 5.3 - Reading this - is it possible for a temporary RSCE to be = appointed as a volunteer? (Was Olaf K an unpaid volunteer during his = short term as RSE?). If a volunteer steps in temporarily, does that = change who gets to do the approvals? Happy if the answer to "unpaid = volunteer" is no, but if yes, not sure why the LLC would need to sign = off. =20 >=20 Am I misreading this, or are you suggesting that someone could = self-appoint themselves as the temporary RSCE in the event that the RSCE = is unavailable and nobody else should have any say in the matter? The appointment text doesn=E2=80=99t require anyone to be paid and so I = don=E2=80=99t see anything stopping an unpaid volunteer from being the = RSCE or a temporary RSCE. Jay > S 6 - 2nd para - "The Editorial Stream will be used...." to "The = Editorial Stream shall be used..." - nit. >=20 > S 6.1 "These procedures need to also allow authors to indicate either = no rights to make derivative works, or preferentially, the right to make = unlimited derivative works from the documents." is probably to = specific. I looked at this one and I think I see a land mine. We're = trying to specify legal language here and if not careful could conflict = with the language of 5378. Instead:=20 >=20 > These procedures need to allow authors to indicate rights requests = consistent with BCP78 (currently RFC5378) or it successor. The = publication of a successor document to RFC5378 and designation as BCP 78 = shall be effective on the Editorial Stream process as of the BCP's = publication date.=20 >=20 > Or get a lawyer to craft this. >=20 >=20 >=20 > S 7 - I'm mostly happy with the list, but I'm still unhappy there is = no language that the RSAB can use these items as part of their = determination as "harm to the system". I'm afraid that the RSWG will = mostly ignore these as there really is no penalty for doing so, and the = RSAB won't have a leg to stand on to push back. I'll shut up now. >=20 > Good work to Peter dealing with all of this. >=20 > Mike >=20 >=20 >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director exec-director@ietf.org --Apple-Mail=_AD0EA36C-C7CE-44DE-9AAA-8E4CB6AAD5B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23/12/2021, at 9:56 AM, Michael StJohns <msj@nthpermutation.com> wrote:

=20 =20

As I noted before, this is in pretty = good shape excluding the RPC RSAB membership stuff and maybe a few more things.

S 3.2.4 - "Appeals of RSWG decisions..." - The RSWG doesn't = make decisions, it comes to consensus and that consensus is judged by the RSWG chairs.  So instead "Appeals of any decisions of the = RSWG chairs, including declining to decide an open issue in their purview after a suitable period shall be made to the = RSAB."   Similarly in the next sentence.  "Decisions of the RSWG = chairs..." and later "... notice having been given to the RSWG [mailing list | chairs]?" - I think this is editorial.

S 4.3, bullet 8 - noted elsewhere, still haven't = had an issue opened.  Question is whether this bullet is an "RPC MAY participate in the RSWG as it needs to" or "RPC MUST participate".   Since the bullets open with 

   More specifically, the RPC's =
responsibilities at the time of writing
   include the following:
 it currently reads as a "MUST", and I'm = not sure they are resourced for it, nor whether this makes the most sense for their current skillsets and staffing.   I'd be happy = with clarifying this is an optional (MAY) interaction, especially since we appear to have settled on the RPC being a non-voting ex officio member of the RSAB.  So text:
8. The RPC may, as it determines necessary, participate within the RSWG in the creation of new Editorial Stream RFCs, especially those that might impact the RPC.
I explicitly left out "advisory" here - I think the RSWG open group model really should avoid restricting people to an advisory role.  That's left to the following proposed language:
8.1 The RPC may participate in the RSAB as = a non-voting ex-officio member primarily as an advisor on RPC capabilities, schedules, staffing and resources.

S 4.3 bullet 16 - Is this needed if the = RPC is an ex officio member of the RSAB?  Shouldn't that be where this interaction mostly happens?  "Stream approving bodies" is different than "stream manager" and not having a single POC might be problematic.  (Sorry - I see this change was made -05 to -06, = but there are a number of places in this document where telling the RPC to talk to an organization is just a bad idea - this comes under the heading of unintended consequences). 
=

S 4.6.2 - S/The/Most/ first word.   I = think we're adding or changing some costs here, but claiming there are no new expenses is more probably wrong that right. - nit.

S 5.3 - Reading this - is it possible for a = temporary RSCE to be appointed as a volunteer?  (Was Olaf K an unpaid volunteer = during his short term as RSE?).  If a volunteer steps in = temporarily, does that change who gets to do the approvals?  Happy if the answer to "unpaid volunteer" is no, but if yes, not sure why the LLC would need to sign off.  


Am = I misreading this, or are you suggesting that someone could self-appoint = themselves as the temporary RSCE in the event that the RSCE is = unavailable and nobody else should have any say in the = matter?

The appointment text = doesn=E2=80=99t require anyone to be paid and so I don=E2=80=99t see = anything stopping an unpaid volunteer from being the RSCE or a temporary = RSCE.

Jay

S 6 - 2nd para - "The Editorial Stream will be = used...." to "The Editorial Stream shall be used..." - nit.

S 6.1 "These procedures need to also allow authors = to indicate either no rights to make derivative works, or preferentially, the right to make unlimited derivative works from the documents." is probably to specific.   I looked at this one and I think = I see a land mine. We're trying to specify legal language here and if not careful could conflict with the language of 5378.  Instead: =

These procedures need to allow = authors to indicate rights requests consistent with BCP78 (currently RFC5378) or it successor.   The publication of a successor document = to RFC5378 and designation as BCP 78 shall be effective on the Editorial Stream process as of the BCP's publication date.

Or get a lawyer to craft this.


S 7 - I'm mostly happy with the list, but I'm = still unhappy there is no language that the RSAB can use these items as part of their determination as "harm to the system".  I'm afraid that the = RSWG will mostly ignore these as there really is no penalty for doing so, and the RSAB won't have a leg to stand on to push back.  = I'll shut up now.

Good work to Peter dealing with all = of this.

Mike



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

-- 
Jay = Daley
IETF Executive Director
exec-director@ietf.org

= --Apple-Mail=_AD0EA36C-C7CE-44DE-9AAA-8E4CB6AAD5B0-- From nobody Wed Dec 22 14:01:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46C2F3A0CF1 for ; Wed, 22 Dec 2021 14:01:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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=stpeter.im header.b=n6f4e0ik; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Qke1TwX2 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHpXT1-W2jvG for ; Wed, 22 Dec 2021 14:01:18 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62D183A0CF0 for ; Wed, 22 Dec 2021 14:01:18 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8E9225C013F; Wed, 22 Dec 2021 17:01:17 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Wed, 22 Dec 2021 17:01:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=9 7kwiqvWIvzHw7RkDH59kLua+MsJRifI2+5gmogr+t4=; b=n6f4e0ikq+EC1I+od NtSOD+XzXpKll1U8MJ1va3KzS2d377QjpKMq4vlGOvd1VeC8mqbrMKBQHWngrsLN Zc+IAu4FUHRRE+k0SFJVz2oJvtXgIH15wFGfnuo9mMkXnY9QHf9mo1Qe+8aPm4/z w4RFxwLlT52tmS40w2r5FBeGDIqKmf1nJhSsDltdaJpR2zDpWO2m8avYvqD0S05o kbzivRjRgmfNSnV48/AQq8DStJZbmQgDW6aju1qasUDtATFzaqvgWPqKgFE7Y5+Q m+9XCcOTjtxw5YwzYNrqPXtyCelZaO42J/wy7eEyW5Jt4nEADKxxB0+59lf4Uuoc C2MGA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=97kwiqvWIvzHw7RkDH59kLua+MsJRifI2+5gmogr+ t4=; b=Qke1TwX2i7jvqDAUzCFLO24iiuStLZaTyz0eUsxXrAmai2f1tspUr9KHI nPtswz508r7/RGkqPuGUF7IFfRqfwY92K7eLKs/r3PbQUsXo/KB+i9wEHVYdxjo5 6if2fwEYfIv6mVuqtSDGyiyMAHeSo+2WyflRdj25EafLOFsu2JOX6fCfPCZ9F75u cllEEqLIIIGBSbJjjiS+yLp0TwSjkSbTmap848U1FFKEAtouuF2BnqP6KXblkuxp hMavQSjd0/NzVNAFcGsnHTYlhzaNrBmvGS+N3AjUpVupmmLLDDuDDEPTmRIcLDpA kcBQtNv1ZvZAAEv1rOssqYx7RtZZQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddtiedgudehtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefkffggfgfuvfhfhfgjtgfgsehtkeertddtfeejnecuhfhrohhmpefrvght vghrucfurghinhhtqdetnhgurhgvuceoshhtphgvthgvrhesshhtphgvthgvrhdrihhmqe enucggtffrrghtthgvrhhnpeevfedvgeeuueehueetfefhhfduhfevheejudfhleeiudff ueekleetjefgteelgeenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsth gvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepshhtphgvthgvrhesshht phgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 22 Dec 2021 17:01:16 -0500 (EST) Message-ID: <371ca787-272e-4995-7cbe-6dde21dfb692@stpeter.im> Date: Wed, 22 Dec 2021 15:01:14 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Brian E Carpenter , rfced-future@iab.org References: <88c553a0-d4b8-6685-e041-15a9440a0a5a@lear.ch> <038c01d7f326$5b9afdf0$12d0f9d0$@olddog.co.uk> <716dc6ae-28a7-4474-2085-6e2b3f283c8c@lear.ch> From: Peter Saint-Andre In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] RPC liaison role X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 22:01:24 -0000 ACK. https://github.com/intarchboard/program-rfced-future/commit/4c01fe35dbc170bb58dd350bd432f2385412ce3a On 12/17/21 1:55 PM, Brian E Carpenter wrote: > I think there's a minor wording issue in this sentence > from section  3.1.1. "RFC Series Working Group (RSWG)": > > "The IETF LLC Board members, staff, and the IETF Executive Director are > invited to participate as community members in the RSWG to the extent > permitted by any relevant IETF LLC policies." > > Probably this should also cover contractors: > > "The IETF LLC Board members, staff, contractors, and the IETF Executive > Director are invited to participate as community members in the RSWG to > the extent permitted by any relevant IETF LLC policies." > >    Brian > From nobody Wed Dec 22 15:10:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7B63A0D80 for ; Wed, 22 Dec 2021 15:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 tvSY5474DbtN for ; Wed, 22 Dec 2021 15:10:44 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1DE3A0D8A for ; Wed, 22 Dec 2021 15:10:43 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id a1so3326077qtx.11 for ; Wed, 22 Dec 2021 15:10:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=h3d20gYqjDkq5szOcljKdj1RA2/zbmpInqU46Ava9oI=; b=hPpnUs/HA0448wX53yY2MyP+cjT6vBkX+0YnkK1/5ISVDPKnAQ2pRFHupVwUaJ5llX B95iP93/DmllJVFb4uyLgDFGMpqBom1/sshjh7d7FsuR1y+2hXmxPmJR7FSArKQPeuVM y3LO6AG4oJw3ZT14UW+JYligBSF6NXnTceLseE9md4XneGs0H+SobiGYwwvYy4A5v0eC AKClf7d5pEKPU9XQDGM+pRYycLhqa/8tU10zfi+ls7fkW4fGNhilt6uOaOtF+U1E3Wnf hAmpXT1pl+WYeXczkBDoiQp+wvr7+4N2miukW9uhkOuf5EDuAJMjSjyJ+b/8pt+DNpOe Ww6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=h3d20gYqjDkq5szOcljKdj1RA2/zbmpInqU46Ava9oI=; b=x+9d16JTqrL6byXgoI+n0O8pAkiOYe3acFIS5ML+evhfbMDvfuatxe6Qey3kYHxvHP n3twbo/EJAhLPC392Y13VTuBX5c5zkYIa2KJil6Aa6pLUPPkVJanc/UNeO8S53WojzVo pi2tnHkZaxNtq5bAYpMSM3eWiDnThsymaCLTQ7EptcCrIn6niOzK3WY9TjxFFFDEbKnd 2nuviDMWg8dRDbWW0L9Ly33IW69hA1KS05KvWzsQrKy/f+Ud/BeGhO1bhs7Skep6YbSh jM4I3Uw0Gwn9rOYkaAkuXhldmvhFpTwWBzIbz0xbnx8FwpgalWQXKGXz+cJjjpx841rd Wa8A== X-Gm-Message-State: AOAM530XNgFsUbKz0VY7sTzUtvs10v/9Zb3rcwgO8hH1ZWKsiJw0GFIC uP8u3YX/35Z1/1Cl/DLg6hVRUg== X-Google-Smtp-Source: ABdhPJyb47DRirR0VP1yjiJxGU43CrIgsZ66svkN7VfkzzhjKeFYmm1Orlgyn7T8eH+kvnPHrJRA1w== X-Received: by 2002:ac8:7d07:: with SMTP id g7mr3974010qtb.364.1640214640816; Wed, 22 Dec 2021 15:10:40 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id q15sm2719708qkj.108.2021.12.22.15.10.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Dec 2021 15:10:40 -0800 (PST) Content-Type: multipart/alternative; boundary="------------1laJJ9h1tAtq6Knm5thECar3" Message-ID: Date: Wed, 22 Dec 2021 18:10:38 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Jay Daley Cc: "rfced-future@iab.org" References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> From: Michael StJohns In-Reply-To: <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:10:47 -0000 This is a multi-part message in MIME format. --------------1laJJ9h1tAtq6Knm5thECar3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/22/2021 4:54 PM, Jay Daley wrote: > > >> On 23/12/2021, at 9:56 AM, Michael StJohns >> wrote: >> >> S 4.6.2 - S/The/Most/ first word.   I think we're adding or changing >> some costs here, but claiming there are no new expenses is more >> probably wrong that right. - nit. >> >> S 5.3 - Reading this - is it possible for a temporary RSCE to be >> appointed as a volunteer?  (Was Olaf K an unpaid volunteer during his >> short term as RSE?).  If a volunteer steps in temporarily, does that >> change who gets to do the approvals?  Happy if the answer to "unpaid >> volunteer" is no, but if yes, not sure why the LLC would need to sign >> off. >> > > Am I misreading this, or are you suggesting that someone could > self-appoint themselves as the temporary RSCE in the event that the > RSCE is unavailable and nobody else should have any say in the matter? > > The appointment text doesn’t require anyone to be paid and so I don’t > see anything stopping an unpaid volunteer from being the RSCE or a > temporary RSCE. > > Jay You are misreading it, but I was less than clear. What I meant was, if the Temporary RSCE (s 5.3) is a paid position, then obviously the LLC is involved because of the contract and funding issues. If instead, we end up having an unpaid volunteer, I would think that the process for doing that would be closer to that of selecting an ISE and wouldn't necessarily include involvement of the LLC.  Selecting an unpaid volunteer via the LLC is possible, but not obviously the right thing. Something like: "The Temporary RSCE position is intended to be a funded position for a publications expert , however if necessary for operational reasons, the LLC, with the advice of the IAB and IESG, may select an unpaid volunteer to fill the role of Temp RSCE on a short-term basis." As I said, I'd be fine if the answer was "no unpaid volunteers", but it might be useful to review our assumptions and make sure that's what we want. Thanks - Mike --------------1laJJ9h1tAtq6Knm5thECar3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/22/2021 4:54 PM, Jay Daley wrote:


On 23/12/2021, at 9:56 AM, Michael StJohns <msj@nthpermutation.com> wrote:

S 4.6.2 - S/The/Most/ first word.   I think we're adding or changing some costs here, but claiming there are no new expenses is more probably wrong that right. - nit.

S 5.3 - Reading this - is it possible for a temporary RSCE to be appointed as a volunteer?  (Was Olaf K an unpaid volunteer during his short term as RSE?).  If a volunteer steps in temporarily, does that change who gets to do the approvals?  Happy if the answer to "unpaid volunteer" is no, but if yes, not sure why the LLC would need to sign off.  


Am I misreading this, or are you suggesting that someone could self-appoint themselves as the temporary RSCE in the event that the RSCE is unavailable and nobody else should have any say in the matter?

The appointment text doesn’t require anyone to be paid and so I don’t see anything stopping an unpaid volunteer from being the RSCE or a temporary RSCE.

Jay


You are misreading it, but I was less than clear.  

What I meant was, if the Temporary RSCE (s 5.3) is a paid position, then obviously the LLC is involved because of the contract and funding issues. If instead, we end up having an unpaid volunteer, I would think that the process for doing that would be closer to that of selecting an ISE and wouldn't necessarily include involvement of the LLC.  Selecting an unpaid volunteer via the LLC is possible, but not obviously the right thing.

Something like:

"The Temporary RSCE position is intended to be a funded position for a publications expert , however if necessary for operational reasons, the LLC, with the advice of the IAB and IESG, may select an unpaid volunteer to fill the role of Temp RSCE on a short-term basis."

As I said, I'd be fine if the answer was "no unpaid volunteers", but it might be useful to review our assumptions and make sure that's what we want.


Thanks - Mike



--------------1laJJ9h1tAtq6Knm5thECar3-- From nobody Wed Dec 22 15:33:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AAE3A0DFA for ; Wed, 22 Dec 2021 15:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 uxavKziBrPAq for ; Wed, 22 Dec 2021 15:33:11 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63CC93A0DFC for ; Wed, 22 Dec 2021 15:33:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 449B8436DDB8; Wed, 22 Dec 2021 15:33:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiqt66OxOJkN; Wed, 22 Dec 2021 15:33:11 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id B0F50436DD7E; Wed, 22 Dec 2021 15:33:10 -0800 (PST) From: Jay Daley Message-Id: <535448DE-B9B2-47AF-95A1-3D783D290777@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_6250DB0A-A1E6-4015-B06D-C6FA18BF5EC1" Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.20.0.1.32\)) Date: Thu, 23 Dec 2021 12:33:06 +1300 In-Reply-To: Cc: "rfced-future@iab.org" To: Michael StJohns References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> X-Mailer: Apple Mail (2.3693.20.0.1.32) Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 23:33:19 -0000 --Apple-Mail=_6250DB0A-A1E6-4015-B06D-C6FA18BF5EC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23/12/2021, at 12:10 PM, Michael StJohns = wrote: >=20 > On 12/22/2021 4:54 PM, Jay Daley wrote: >>=20 >>=20 >>> On 23/12/2021, at 9:56 AM, Michael StJohns > wrote: >>>=20 >>> S 4.6.2 - S/The/Most/ first word. I think we're adding or changing = some costs here, but claiming there are no new expenses is more probably = wrong that right. - nit. >>> S 5.3 - Reading this - is it possible for a temporary RSCE to be = appointed as a volunteer? (Was Olaf K an unpaid volunteer during his = short term as RSE?). If a volunteer steps in temporarily, does that = change who gets to do the approvals? Happy if the answer to "unpaid = volunteer" is no, but if yes, not sure why the LLC would need to sign = off. =20 >>>=20 >>=20 >> Am I misreading this, or are you suggesting that someone could = self-appoint themselves as the temporary RSCE in the event that the RSCE = is unavailable and nobody else should have any say in the matter? >>=20 >> The appointment text doesn=E2=80=99t require anyone to be paid and so = I don=E2=80=99t see anything stopping an unpaid volunteer from being the = RSCE or a temporary RSCE. >>=20 >> Jay >=20 > You are misreading it, but I was less than clear. =20 >=20 > What I meant was, if the Temporary RSCE (s 5.3) is a paid position, = then obviously the LLC is involved because of the contract and funding = issues. If instead, we end up having an unpaid volunteer, I would think = that the process for doing that would be closer to that of selecting an = ISE and wouldn't necessarily include involvement of the LLC. Selecting = an unpaid volunteer via the LLC is possible, but not obviously the right = thing. >=20 > Something like: >=20 > "The Temporary RSCE position is intended to be a funded position for a = publications expert , however if necessary for operational reasons, the = LLC, with the advice of the IAB and IESG, may select an unpaid volunteer = to fill the role of Temp RSCE on a short-term basis." >=20 I see. The problem with that is that in our current model the LLC is = the appointing body for the RSCE, so that would mean creating a = different appointing body for the specific instance where someone = volunteers to take on a temporary RSCE role on an unpaid basis. I = don=E2=80=99t think that is workable and I don=E2=80=99t see any benefit = in re-opening who the appointment body for the RSCE is. > As I said, I'd be fine if the answer was "no unpaid volunteers", but = it might be useful to review our assumptions and make sure that's what = we want. >=20 I would not want to say that, but rather that the model stays silent on = that, thereby implicitly allowing for it. Jay >=20 > Thanks - Mike >=20 >=20 >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director exec-director@ietf.org --Apple-Mail=_6250DB0A-A1E6-4015-B06D-C6FA18BF5EC1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 23/12/2021, at 12:10 PM, Michael StJohns <msj@nthpermutation.com> wrote:

=20 =20
On 12/22/2021 4:54 PM, Jay Daley = wrote:


On 23/12/2021, at 9:56 AM, Michael StJohns = <msj@nthpermutation.com> wrote:

S 4.6.2 - S/The/Most/ first = word.   I think we're adding or changing some costs here, but claiming there are no new expenses is more probably wrong that right. - nit.

S 5.3 - Reading = this - is it possible for a temporary RSCE to be appointed as a volunteer?  = (Was Olaf K an unpaid volunteer during his short term as RSE?).  If a volunteer steps in temporarily, does = that change who gets to do the approvals?  Happy if the answer to "unpaid volunteer" is no, but if yes, not sure why the LLC would need to sign off.  


Am I misreading this, or are you suggesting that = someone could self-appoint themselves as the temporary RSCE in the event that the RSCE is unavailable and nobody else should have any say in the matter?

The appointment text doesn=E2=80=99t require = anyone to be paid and so I don=E2=80=99t see anything stopping an unpaid = volunteer from being the RSCE or a temporary RSCE.

Jay


You are misreading it, but I was less than = clear.  

What I meant was, if the Temporary RSCE (s 5.3) is = a paid position, then obviously the LLC is involved because of the contract and funding issues. If instead, we end up having an unpaid volunteer, I would think that the process for doing that would be closer to that of selecting an ISE and wouldn't necessarily include involvement of the LLC.  Selecting an = unpaid volunteer via the LLC is possible, but not obviously the right thing.

Something like:

"The = Temporary RSCE position is intended to be a funded position for a publications expert , however if necessary for operational reasons, the LLC, with the advice of the IAB and IESG, may select an unpaid volunteer to fill the role of Temp RSCE on a short-term basis."

I see.  The problem = with that is that in our current model the LLC is the appointing body = for the RSCE, so that would mean creating a different appointing body = for the specific instance where someone volunteers to take on a = temporary RSCE role on an unpaid basis.  I don=E2=80=99t think that = is workable and I don=E2=80=99t see any benefit in re-opening who the = appointment body for the RSCE is.

As = I said, I'd be fine if the answer was "no unpaid volunteers", but it might be useful to review our assumptions and make sure that's what we want.

I would not want = to say that, but rather that the model stays silent on that, thereby = implicitly allowing for it.

Jay


Thanks - Mike



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

-- 
Jay = Daley
IETF Executive Director
exec-director@ietf.org

= --Apple-Mail=_6250DB0A-A1E6-4015-B06D-C6FA18BF5EC1-- From nobody Wed Dec 22 16:22:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BAE3A0E67 for ; Wed, 22 Dec 2021 16:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.748 X-Spam-Level: X-Spam-Status: No, score=-3.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 0x2yoqFDgmy8 for ; Wed, 22 Dec 2021 16:21:57 -0800 (PST) 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 D773A3A0E62 for ; Wed, 22 Dec 2021 16:21:56 -0800 (PST) Received: by mail-qv1-xf34.google.com with SMTP id o10so3763143qvc.5 for ; Wed, 22 Dec 2021 16:21:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to; bh=yshlJ0pBzwHHYOyDL1DdoM6e7YUnh/vSpkL6wyz1Rus=; b=u5m0+UsGM35d1htdLlwGik+aqlEUE1rndwoog0LnQqwbS+CrtJEgqlIl+C34xZZGHn JW2T1O1Ww+QP0hvIT1kH8aBy+EWnasllZ1OL7BNy3y7xkfsJg/LpbcV7buHhWxsX+IzJ fuSpBBHkocb/g+vrRKtHAaX9oiAp+qAQyjvlsnALjZFC7kR0Oe6J+fcCFgg4vbomKWMv Vh+0RHgKwPAg4SOx1hGmyG3lrX1THV8/INavShXVbHYH5pTGNAQXdAWRkNi2moJgBLIq YDehKo7GVPTJpclptW3VDFtNgh9O6DWKZFfew35x1nWpg8CSAVYHPlCA0eMYqPZEXY4D HqMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to; bh=yshlJ0pBzwHHYOyDL1DdoM6e7YUnh/vSpkL6wyz1Rus=; b=H6s2OlWoapPFzzYC6A1ayT7jEKHwZMtkE+uv7xzCTTl9tmAwySk2ULDm9bISCYMNRe l8MZtbtN7bLv6jySxi5aam90JvDNNi+t7gW5qzxlN1S/S6BQE/BN2GJsqry3+eNjihKg 4boIPhkvcqPsw1iR4/bADh0oWqWPLtoAK2vOp9USlqPmP1rCgXXfao/H04lYtCdQNBBL CDTRHkF/Fzj8qI7ZUaLWtnB2/kWgOd6NLlZaOtaVpEOMYLKknEOr9GWlK3yqFNhx7eOU LoUkOG3WxReFDCjfuyqXBgsIe0Ltb7ULtLEZsLeiFoEttUSJ7Y5qIUmfHr85Vfg4waL5 5nfQ== X-Gm-Message-State: AOAM5320nLTjHw+fOokyffiqJ8V4sOiVefkJDLN90QbepVOp2nQslulf /fj6UAMMAv574JYiDXOHMxzN0pELRc1jAq6I X-Google-Smtp-Source: ABdhPJxz5pdydwEPauKMZwums73t0c5tGZSXKC/8nB57Mu1nRZZ3nEkOLp4DNg8cRCxryCEQgK3vgQ== X-Received: by 2002:a0c:e5d1:: with SMTP id u17mr93225qvm.120.1640218915091; Wed, 22 Dec 2021 16:21:55 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id j20sm3498188qko.117.2021.12.22.16.21.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Dec 2021 16:21:54 -0800 (PST) Content-Type: multipart/alternative; boundary="------------xnqdcl80ktUhI2ec0Rc8w4Iq" Message-ID: Date: Wed, 22 Dec 2021 19:21:52 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Jay Daley Cc: "rfced-future@iab.org" References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <535448DE-B9B2-47AF-95A1-3D783D290777@ietf.org> From: Michael StJohns In-Reply-To: <535448DE-B9B2-47AF-95A1-3D783D290777@ietf.org> Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 00:22:02 -0000 This is a multi-part message in MIME format. --------------xnqdcl80ktUhI2ec0Rc8w4Iq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/22/2021 6:33 PM, Jay Daley wrote: > > >> On 23/12/2021, at 12:10 PM, Michael StJohns >> wrote: >> >> On 12/22/2021 4:54 PM, Jay Daley wrote: >>> >>> >>>> On 23/12/2021, at 9:56 AM, Michael StJohns >>>> wrote: >>>> >>>> S 4.6.2 - S/The/Most/ first word. I think we're adding or changing >>>> some costs here, but claiming there are no new expenses is more >>>> probably wrong that right. - nit. >>>> >>>> S 5.3 - Reading this - is it possible for a temporary RSCE to be >>>> appointed as a volunteer?  (Was Olaf K an unpaid volunteer during >>>> his short term as RSE?).  If a volunteer steps in temporarily, does >>>> that change who gets to do the approvals?  Happy if the answer to >>>> "unpaid volunteer" is no, but if yes, not sure why the LLC would >>>> need to sign off. >>>> >>> >>> Am I misreading this, or are you suggesting that someone could >>> self-appoint themselves as the temporary RSCE in the event that the >>> RSCE is unavailable and nobody else should have any say in the matter? >>> >>> The appointment text doesn’t require anyone to be paid and so I >>> don’t see anything stopping an unpaid volunteer from being the RSCE >>> or a temporary RSCE. >>> >>> Jay >> >> >> You are misreading it, but I was less than clear. >> >> What I meant was, if the Temporary RSCE (s 5.3) is a paid position, >> then obviously the LLC is involved because of the contract and >> funding issues. If instead, we end up having an unpaid volunteer, I >> would think that the process for doing that would be closer to that >> of selecting an ISE and wouldn't necessarily include involvement of >> the LLC.  Selecting an unpaid volunteer via the LLC is possible, but >> not obviously the right thing. >> >> Something like: >> >> "The Temporary RSCE position is intended to be a funded position for >> a publications expert , however if necessary for operational reasons, >> the LLC, with the advice of the IAB and IESG, may select an unpaid >> volunteer to fill the role of Temp RSCE on a short-term basis." >> > I see.  The problem with that is that in our current model the LLC is > the appointing body for the RSCE, so that would mean creating a > different appointing body for the specific instance where someone > volunteers to take on a temporary RSCE role on an unpaid basis.  I > don’t think that is workable and I don’t see any benefit in re-opening > who the appointment body for the RSCE is. I agree that creating a new appointing body would require reworking quite a lot of things.  But that mostly doesn't apply to the temporary appointments.  5.3 already has this: "the IETF LLC may appoint a Temporary RSCE through whatever recruitment process it considers appropriate".   What my text above is meant to suggest is that if the LLC isn't going to go off and do all of the search committee things for the temp RSCE (because of need and time for example), and they get an unpaid volunteer to fill in, that the LLC check in with the IAB and IESG to make sure that they agree that a non-paid temp volunteer is sufficient to fulfill the requirements.   E.g. advise, not consent - llc would still run the process. > >> As I said, I'd be fine if the answer was "no unpaid volunteers", but >> it might be useful to review our assumptions and make sure that's >> what we want. >> > I would not want to say that, but rather that the model stays silent > on that, thereby implicitly allowing for it. There are a lot of things the model stays silent on that none of us would want to think are implicitly allowed! :-)   My druthers are to make this clear rather than assume. Later, Mike > > Jay >> >> >> Thanks - Mike >> >> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > -- > Jay Daley > IETF Executive Director > exec-director@ietf.org > --------------xnqdcl80ktUhI2ec0Rc8w4Iq Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/22/2021 6:33 PM, Jay Daley wrote:


On 23/12/2021, at 12:10 PM, Michael StJohns <msj@nthpermutation.com> wrote:

On 12/22/2021 4:54 PM, Jay Daley wrote:


On 23/12/2021, at 9:56 AM, Michael StJohns <msj@nthpermutation.com> wrote:

S 4.6.2 - S/The/Most/ first word.   I think we're adding or changing some costs here, but claiming there are no new expenses is more probably wrong that right. - nit.

S 5.3 - Reading this - is it possible for a temporary RSCE to be appointed as a volunteer?  (Was Olaf K an unpaid volunteer during his short term as RSE?).  If a volunteer steps in temporarily, does that change who gets to do the approvals?  Happy if the answer to "unpaid volunteer" is no, but if yes, not sure why the LLC would need to sign off.  


Am I misreading this, or are you suggesting that someone could self-appoint themselves as the temporary RSCE in the event that the RSCE is unavailable and nobody else should have any say in the matter?

The appointment text doesn’t require anyone to be paid and so I don’t see anything stopping an unpaid volunteer from being the RSCE or a temporary RSCE.

Jay


You are misreading it, but I was less than clear.  

What I meant was, if the Temporary RSCE (s 5.3) is a paid position, then obviously the LLC is involved because of the contract and funding issues. If instead, we end up having an unpaid volunteer, I would think that the process for doing that would be closer to that of selecting an ISE and wouldn't necessarily include involvement of the LLC.  Selecting an unpaid volunteer via the LLC is possible, but not obviously the right thing.

Something like:

"The Temporary RSCE position is intended to be a funded position for a publications expert , however if necessary for operational reasons, the LLC, with the advice of the IAB and IESG, may select an unpaid volunteer to fill the role of Temp RSCE on a short-term basis."

I see.  The problem with that is that in our current model the LLC is the appointing body for the RSCE, so that would mean creating a different appointing body for the specific instance where someone volunteers to take on a temporary RSCE role on an unpaid basis.  I don’t think that is workable and I don’t see any benefit in re-opening who the appointment body for the RSCE is.

I agree that creating a new appointing body would require reworking quite a lot of things.  But that mostly doesn't apply to the temporary appointments.  5.3 already has this: "the IETF LLC may appoint a Temporary RSCE through whatever recruitment process it considers appropriate".   What my text above is meant to suggest is that if the LLC isn't going to go off and do all of the search committee things for the temp RSCE (because of need and time for example), and they get an unpaid volunteer to fill in, that the LLC check in with the IAB and IESG to make sure that they agree that a non-paid temp volunteer is sufficient to fulfill the requirements.   E.g. advise, not consent - llc would still run the process.



As I said, I'd be fine if the answer was "no unpaid volunteers", but it might be useful to review our assumptions and make sure that's what we want.

I would not want to say that, but rather that the model stays silent on that, thereby implicitly allowing for it.

There are a lot of things the model stays silent on that none of us would want to think are implicitly allowed! :-)   My druthers are to make this clear rather than assume.

Later, Mike




Jay


Thanks - Mike



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

-- 
Jay Daley
IETF Executive Director
exec-director@ietf.org


--------------xnqdcl80ktUhI2ec0Rc8w4Iq-- From nobody Wed Dec 22 22:48:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D2A3A1203; Wed, 22 Dec 2021 22:48:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XBbZuxiXNO7; Wed, 22 Dec 2021 22:48:25 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 702783A11FD; Wed, 22 Dec 2021 22:48:22 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BN6mIkF2239894 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 23 Dec 2021 07:48:18 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1640242099; bh=wwLmg3qHB29F18rFsUeYX1XnGKfBMUNi/z3ydhyUEfg=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=HHd2fvPOiBl0Nwy4XVkSC+1TWqEqyXHpSaoOB5XUoGXXpeUzU4+EOmne2fOT4czaU s070RGteHikaKN9+Qk0ZUR9HTrgMDQneugezZYv5hCY43oA1Ne680BbywKR6MRdi1b lLcC1OdlqShGth1RM/5//+o6b8YJRui+h8mfQ2GM= Message-ID: <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> Date: Thu, 23 Dec 2021 07:48:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Michael StJohns , Jay Daley Cc: "rfced-future@iab.org" References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> From: Eliot Lear In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------rVlUX2K5VsEj8FkgwPpEBYLg" Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 06:48:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rVlUX2K5VsEj8FkgwPpEBYLg Content-Type: multipart/mixed; boundary="------------YoTlgGNXdWuEY83jmxWbFdH0"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , Jay Daley Cc: "rfced-future@iab.org" Message-ID: <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> Subject: Re: [Rfced-future] Comments on -07 References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> In-Reply-To: --------------YoTlgGNXdWuEY83jmxWbFdH0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 TWlrZSwNCg0KRm9yIGJhY2tncm91bmQgZm9yIGFsbCwgdGhpcyB0ZXh0IHdhcyBpbnRyb2R1 Y2VkIGFzIHBhcnQgb2YgdGhlIA0KcmVzb2x1dGlvbiB0byBJc3N1ZSAxMDQuDQoNCk9uIDIz LjEyLjIxIDAwOjEwLCBNaWNoYWVsIFN0Sm9obnMgd3JvdGU6DQo+IFNlbGVjdGluZyBhbiB1 bnBhaWQgdm9sdW50ZWVyIHZpYSB0aGUgTExDwqAgaXMgcG9zc2libGUsIGJ1dCBub3QgDQo+ IG9idmlvdXNseSB0aGUgcmlnaHQgdGhpbmcuDQoNCkNhbiB5b3Ugc3RhdGUgd2h5IHdlIHNo b3VsZCByZXZpc2l0IHRoaXMgaXNzdWUsIHdoYXQgcHJvYmxlbSB5b3UgYXJlIA0KdHJ5aW5n IHRvIHNvbHZlIHdpdGggdGhlIGV4aXN0aW5nIHRleHQsIGFuZCB3aHkgdGhpcyByZXNwb25z aWJpbGl0eSANCnNob3VsZCBzaGlmdCBmcm9tIHRoZSBMTEM/DQoNCkVsaW90DQoNCg0K --------------YoTlgGNXdWuEY83jmxWbFdH0-- --------------rVlUX2K5VsEj8FkgwPpEBYLg Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmHEG7EFAwAAAAAACgkQh7ZrRtnSejOG sQgAn1pFpIiEEnXvQV77GUpzd6h4Dix36lstzu48W9yChz1x2NdgOgnQw3u6PXjDHpGW2b/pb4o1 Y6vVTC7MJWf+T29egP0QA7l0Fe9Ca7FLgPh0GSBh6tHXOBZ1UKRtXbCBv4vLDV0D/16O6/5gDTNr F5983OcL8NHXSvlhSCmc4Rs4fUcYKB/B7DWY7buQkdNyv5cmF93/Lsskn624liJnL8jwm6gMS8Pl AEzR4KHKFB36MI2mzXs7cJsW+Go+yvmwz36fxrxPiYlw5RLySDTqo6WM9WQc4ww/WQ+rKHWDCxTI utpdP2V/2Qdbx8ht6jmm/xnD36Sx4na83TjR4LMWLg== =gvXJ -----END PGP SIGNATURE----- --------------rVlUX2K5VsEj8FkgwPpEBYLg-- From nobody Wed Dec 22 23:33:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BB813A124F for ; Wed, 22 Dec 2021 23:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pKOV1UVHT7YR for ; Wed, 22 Dec 2021 23:33:37 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 B23C63A124E for ; Wed, 22 Dec 2021 23:33:35 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BN7XXtM2240340 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 23 Dec 2021 08:33:33 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1640244813; bh=hbsjHNSiJj3rZXAkvtBd87K6CIPivQW9yaSen0ll/Tk=; h=Date:To:References:From:Subject:In-Reply-To:From; b=RnWWEICUf9jnWDyeEwGcNIaeX4ZVAnTeIbrjgpAORZVJsYL4YarqH5fQtK2W834EY R2deKvQr4CxhK+EDl8o7GoCZ8L766Qj71XYqW0sgUqifRzfvAyAap0QUDheo86aSPL 0NKyk8+i/7SIaYDp2UEDxZO1/x0aRhDe/3tWwGgE= Message-ID: <211d997a-ea0d-f56c-7329-d0cbc73638a4@lear.ch> Date: Thu, 23 Dec 2021 08:33:32 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: Michael StJohns , "rfced-future@iab.org" References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> From: Eliot Lear In-Reply-To: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------tKW7vD2cxNqKBlAZLlR6zjIJ" Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 07:33:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------tKW7vD2cxNqKBlAZLlR6zjIJ Content-Type: multipart/mixed; boundary="------------HN3S3qTTcTuACQWiJtLjgbP0"; protected-headers="v1" From: Eliot Lear To: Michael StJohns , "rfced-future@iab.org" Message-ID: <211d997a-ea0d-f56c-7329-d0cbc73638a4@lear.ch> Subject: Re: [Rfced-future] Comments on -07 References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> In-Reply-To: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> --------------HN3S3qTTcTuACQWiJtLjgbP0 Content-Type: multipart/alternative; boundary="------------YAUKzmFJ1uWW81xaUPnaJxd1" --------------YAUKzmFJ1uWW81xaUPnaJxd1 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgTWlrZSwNCg0KT24gdGhpczoNCg0KT24gMjIuMTIuMjEgMjE6NTYsIE1pY2hhZWwgU3RK b2hucyB3cm90ZToNCj4gUyA0LjMgYnVsbGV0IDE2IC0gSXMgdGhpcyBuZWVkZWQgaWYgdGhl IFJQQyBpcyBhbiBleCBvZmZpY2lvIG1lbWJlciBvZiANCj4gdGhlIFJTQUI/IA0KDQpGb3Ig Y29udGV4dCB0aGUgYnVsbGV0IHNheXMgdGhlIGZvbGxvd2luZzoNCg0KICAgIDE2LiAgTGlh aXNpbmcgd2l0aCBzdHJlYW0gYXBwcm92aW5nIGJvZGllcyBhbmQgb3RoZXIgcmVwcmVzZW50 YXRpdmVzDQogICAgICAgICBvZiB0aGUgc3RyZWFtcyBhcyBuZWVkZWQuDQoNCk4uQi4sIOKA nGFzIG5lZWRlZC7igJ0NCg0KPiBTaG91bGRuJ3QgdGhhdCBiZSB3aGVyZSB0aGlzIGludGVy YWN0aW9uIG1vc3RseSBoYXBwZW5zP8KgICJTdHJlYW0gDQo+IGFwcHJvdmluZyBib2RpZXMi IGlzIGRpZmZlcmVudCB0aGFuICJzdHJlYW0gbWFuYWdlciIgYW5kIG5vdCBoYXZpbmcgYSAN Cj4gc2luZ2xlIFBPQyBtaWdodCBiZSBwcm9ibGVtYXRpYy7CoCAoU29ycnkgLSBJIHNlZSB0 aGlzIGNoYW5nZSB3YXMgbWFkZSANCj4gLTA1IHRvIC0wNiwgYnV0IHRoZXJlIGFyZSBhIG51 bWJlciBvZiBwbGFjZXMgaW4gdGhpcyBkb2N1bWVudCB3aGVyZSANCj4gdGVsbGluZyB0aGUg UlBDIHRvIHRhbGsgdG8gYW4gb3JnYW5pemF0aW9uIGlzIGp1c3QgYSBiYWQgaWRlYSAtIHRo aXMgDQo+IGNvbWVzIHVuZGVyIHRoZSBoZWFkaW5nIG9mIHVuaW50ZW5kZWQgY29uc2VxdWVu Y2VzKS4gDQoNCk9uZSBleGFtcGxlIG9mIHdoZW4gaXQgd291bGQgYmUgbmVjZXNzYXJ5IGZv ciB0aGUgUlBDIGFuZCBhIHN0cmVhbSB0byANCmNvbW11bmljYXRlIHdvdWxkIGJlIGluIHJl bGF0aW9uIHRvIGJvaWxlciBwbGF0ZSBxdWVzdGlvbnMgb3IgY2hhbmdlcy7CoCANCkFub3Ro ZXIgY2FzZSBtaWdodCBpbnZvbHZlIG1ldGEtaW5mb3JtYXRpb24gc3VjaCBhcyBvYnNvbGV0 aW5nL3VwZGF0aW5nIA0Kb2YgUkZDcy7CoCBBY2NvcmRpbmcgdG8gdGhlIGRyYWZ0LCB0aGVz ZSBzb3J0cyBvZiB0aGluZ3Mgd291bGQgbm90IGJlIA0KYXBwcm9wcmlhdGUgZm9yIHRoZSBS U0FCLCBidXQgZm9yIHRoZSBpbmRpdmlkdWFsIHN0cmVhbXMgdGhlbXNlbHZlcy4NCg0KRWxp b3QNCg0K --------------YAUKzmFJ1uWW81xaUPnaJxd1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Mike,

On this:

On 22.12.21 21:56, Michael StJohns wrote:
S 4.3 bullet 16 - Is this needed if the RPC is an ex officio member of the RSAB?=C2=A0

For context the bullet says the following:

   16.  Liaising with stream approving bodies =
and other representatives
        of the streams as needed.

N.B., =E2=80=9Cas needed.=E2=80=9D

Shouldn't that be where this interaction mostly happens?=C2=A0 "Stream approv= ing bodies" is different than "stream manager" and not having a single POC might be problematic.=C2=A0 (Sorry - I see this change was made= -05 to -06, but there are a number of places in this document where telling the RPC to talk to an organization is just a bad idea - this comes under the heading of unintended consequences).=C2=A0

One example of when it would be necessary for the RPC and a stream to communicate would be in relation to boiler plate questions or changes.=C2=A0 Another case might involve meta-informa= tion such as obsoleting/updating of RFCs.=C2=A0 According to the draft, these sorts of things would not be appropriate for the RSAB, but for the individual streams themselves.

Eliot

--------------YAUKzmFJ1uWW81xaUPnaJxd1-- --------------HN3S3qTTcTuACQWiJtLjgbP0-- --------------tKW7vD2cxNqKBlAZLlR6zjIJ Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmHEJkwFAwAAAAAACgkQh7ZrRtnSejP7 NAgAscnuKhFry7B6RaQJYugfuCrSNj0lBXZlXS09CMKUkPXZhPkCICoRR4a+LpMI8zT03l0/cVZz XNlTwwRZWaqagUvVrgMBCmiuZNpHYMJeZ1gFpbrcF9cG/SEQruX4MHrIslyEnqk9+a4a+fYz5cm7 B7dcYLbTrs8d3H+lV+IYREsxIPlgrHaMJtz+ljouDRycDx4v8MdDxTpmmbz30CRG2vvZJsPCvEna U9ic/4FtXTAUb0D89W/9UNxNFSo93YAtuPUQfeLYWeIQ7nt10Uqs/eVBp9ij97kqORBQ0VVUj1Jh j5VEWyIMAwwkjy9mQfAKz3xVl9L8T9hbqq2OIk/zjg== =CZuD -----END PGP SIGNATURE----- --------------tKW7vD2cxNqKBlAZLlR6zjIJ-- From nobody Thu Dec 23 07:19:11 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69E433A16F6 for ; Thu, 23 Dec 2021 07:19:09 -0800 (PST) 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_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty_MbCyv_MUM for ; Thu, 23 Dec 2021 07:19:04 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 7FF953A16F5 for ; Thu, 23 Dec 2021 07:19:02 -0800 (PST) Received: from [192.168.0.227] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BNFIx8k2246408 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO) for ; Thu, 23 Dec 2021 16:18:59 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1640272739; bh=9hH0mLaNj1EA2k8oO7j7QlMzLXrNki3n99K4Of5U30g=; h=Date:To:From:Subject:From; b=tYKj0ADQ3bEaN5/hLn4wZtdkSFjO0hLMPRp3ChuSoFHJ38mHa5jQh31WZqhSNktFM wPRrlp/Q4WLLg2gd0NaURqr2LYU6+di5Q/CTlG8AFkEOTB8843lMBisj+espuiG2Tu 13+pzL5pRTzwVk+tA/ENr1OzBC4g43jESt3OdVqg= Message-ID: <82e8068b-e311-330a-c2cb-6f55e88188cf@lear.ch> Date: Thu, 23 Dec 2021 16:18:59 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Content-Language: en-US To: "rfced-future@iab.org" From: Eliot Lear Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------6zjLQd50NVCnuYueRXh0ONRt" Archived-At: Subject: [Rfced-future] for those who haven't noticed... X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 15:19:10 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------6zjLQd50NVCnuYueRXh0ONRt Content-Type: multipart/mixed; boundary="------------LT9amxFIDLJVxPYnonfvzQ0R"; protected-headers="v1" From: Eliot Lear To: "rfced-future@iab.org" Message-ID: <82e8068b-e311-330a-c2cb-6f55e88188cf@lear.ch> Subject: for those who haven't noticed... --------------LT9amxFIDLJVxPYnonfvzQ0R Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SSBoYXZlIGFwcGxpZWQgZm9yIHRoZSBJU0UgcG9zaXRpb24uwqAgVGhpcyB3YXMgYSBkZWNp c2lvbiBJIG1hZGUgYWZ0ZXIgDQp0aGUgYW5ub3VuY2VtZW50IHNob3dlZCB1cCBpbiBPY3Rv YmVyLsKgIEkgYW0gb25lIG9mIGEgbnVtYmVyIG9mIGdvb2QgDQpjYW5kaWRhdGVzIGJlZm9y ZSB0aGUgSUFCLiBPdXQgb2YgYW4gYWJ1bmRhbmNlIG9mIGNhdXRpb24sIGluIHRoZSANCnVu bGlrZWx5IGV2ZW50IHRoYXQgYSBtYXR0ZXIgc3Vic3RhbnRpYWxseSBpbXBhY3RpbmcgdGhl IElTRSB3b3VsZCBiZSANCmJlZm9yZSB1cyBhZ2FpbiwgQnJpYW4gd2lsbCBjYWxsIGNvbnNl bnN1cyBvbiB0aG9zZSBwb2ludHMuKg0KDQpFbGlvdA0KDQoqIFRoaXMgZ3JvdXAgaGFzIGdl bmVyYWxseSwgdGhvdWdoIG5vdCBlbnRpcmVseSwgYXZvaWRlZCBkaXNjdXNzaW9ucyANCmFi b3V0IGluZGl2aWR1YWwgc3RyZWFtcy4NCg0KDQo= --------------LT9amxFIDLJVxPYnonfvzQ0R-- --------------6zjLQd50NVCnuYueRXh0ONRt Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmHEk2MFAwAAAAAACgkQh7ZrRtnSejNE WAf9HQSLw5en2yfWXbSQNfi7/J81YTqgmTBO5QgHS+9GH2T82fAz3JnwuydmGNRWC34YCAVKBrpU amkaQ/JYZEkrnOL6jdW2l6OfXA9cHC0fo94DV5uGWiaV3u69z6/i1T8guUpeUj2Of/suMvHM8fx6 WwV1kuWAUKFjLb2KlTH7Y5JQfIJ0SGBuJqzlzDwjy1D/1hFD7H3rHO3/UdLGAF/T3uOjQMWYVId9 +sD1ik14IqqfjsUoFeYabzvDx1g+lJ8hQ/Nu3Y8Ns2B+fk1yamON9BwJnidJQypNe9aM3dtZTEek 2JCAyJ6GgUVSu8PHBIcfvblAPwh9QDN7GN1UlPSbaQ== =zfR+ -----END PGP SIGNATURE----- --------------6zjLQd50NVCnuYueRXh0ONRt-- From nobody Thu Dec 23 09:27:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 891543A0317 for ; Thu, 23 Dec 2021 09:27:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, 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.20210112.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 r7gRacOPg4un for ; Thu, 23 Dec 2021 09:27:05 -0800 (PST) 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 85C283A0332 for ; Thu, 23 Dec 2021 09:27:05 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id j17so5530667qtx.2 for ; Thu, 23 Dec 2021 09:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :references:from:in-reply-to; bh=1PDiSBDJ5BUH/1wkYsnXnnqrL8xkwFnPh7jjHThVbqw=; b=QWCAIvPl/Xr4JQoDrL0Pcmj7k7iqPywfNVzuS+6K8nl/NRGz+Td9cJTnYlk4Me9ahI o1fLdgXwrocmD3levSdIonGgCYC6unsdJjK4eD88UTlADdpe5tqCWcRJpwK3GAQ+OHq/ OKFl+P8SBp78tPVReEXPijRZ3MFjv24VUKa78WVHxyFAzjf/muwkQawJjLyKQV23LfNd 3WdI/Lw4AcAOM9VSB6iPZkNLgi/77OU2E76xQLwK80I5ZZzlnkvn8pnD0WJfuYnJ/phe O4GmwQ/eo+WLWljdPJeEzkQ8vp1nMOjjIJD8v7uf2r14s3vTEpqIn1MFyco5u/c1VhH8 q5cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to; bh=1PDiSBDJ5BUH/1wkYsnXnnqrL8xkwFnPh7jjHThVbqw=; b=X+QYBPDNzb8lXlq/GFlB1aXcen6/6JynKft4Vkm8pEk8TohRrqGG7euFhl5rWQ7AEM DJ7A4ZkY0KRLgbSwT1ychbA6WoSVDKDlvY3hOCjWHU5qtW/nP4kDzgoYyXrZo5HoTfX3 Hyx6DQ1HlJay8cNjQ+/8UpsZU/jooJkNS5mUmjdrtEpshM6THh2Mo5cN/1Miibb/cZDD NIOBiv535aTFzYQ3G9UNYKredObuCTe4QEhuk+gxwZR0kRrxeRsysiMJ/psUzwk2UQAH jeAbAo4ZuXq8SHmMi7k0waltEGstRFHJZy5O/cfzPEwaFeFNQReYYubJiopt7FoDPTt1 uxLA== X-Gm-Message-State: AOAM533C2OAerkGRTlh5em+od4JXAxhSyYqoFP12cZ/Nb7Zyer+5f4EQ B7zZoWdhQMXrvhN7MHAJwMrbeQ== X-Google-Smtp-Source: ABdhPJyUvInf4QfNxrI/JLexYhJDGjK6xKrrJ6oRMqh4zzUYPZ1my03QJeC7NGTBuvtzOPnPS/E5WA== X-Received: by 2002:a05:622a:49:: with SMTP id y9mr2495601qtw.529.1640280423114; Thu, 23 Dec 2021 09:27:03 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id l15sm4757291qtx.77.2021.12.23.09.27.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Dec 2021 09:27:02 -0800 (PST) Content-Type: multipart/alternative; boundary="------------IGmsPu4pZfaPOynv75BT481M" Message-ID: Date: Thu, 23 Dec 2021 12:26:59 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Content-Language: en-US To: Eliot Lear , "rfced-future@iab.org" References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <211d997a-ea0d-f56c-7329-d0cbc73638a4@lear.ch> From: Michael StJohns In-Reply-To: <211d997a-ea0d-f56c-7329-d0cbc73638a4@lear.ch> Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 17:27:09 -0000 This is a multi-part message in MIME format. --------------IGmsPu4pZfaPOynv75BT481M Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 12/23/2021 2:33 AM, Eliot Lear wrote: > > Hi Mike, > > On this: > > On 22.12.21 21:56, Michael StJohns wrote: >> S 4.3 bullet 16 - Is this needed if the RPC is an ex officio member >> of the RSAB? > > For context the bullet says the following: > > 16. Liaising with stream approving bodies and other representatives > of the streams as needed. > > N.B., “as needed.” > >> Shouldn't that be where this interaction mostly happens?  "Stream >> approving bodies" is different than "stream manager" and not having a >> single POC might be problematic.  (Sorry - I see this change was made >> -05 to -06, but there are a number of places in this document where >> telling the RPC to talk to an organization is just a bad idea - this >> comes under the heading of unintended consequences). > > One example of when it would be necessary for the RPC and a stream to > communicate would be in relation to boiler plate questions or > changes.  Another case might involve meta-information such as > obsoleting/updating of RFCs.  According to the draft, these sorts of > things would not be appropriate for the RSAB, but for the individual > streams themselves. > > Eliot > I think that's a fair interpretation, but it used to be "stream managers" and AFAICT, that was changed to "stream approving bodies" primarily to eliminate the "stream manager" term, rather than to address the point you made and hence leading to the question. It also is weird when reading it for the ISE. How about "Liaising with other representatives of the streams as needed" which says that just not the RSAB member of a stream might be important? I don't have strong feelings here that it needs to be changed - more of a nit than anything. Mike --------------IGmsPu4pZfaPOynv75BT481M Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 12/23/2021 2:33 AM, Eliot Lear wrote:

Hi Mike,

On this:

On 22.12.21 21:56, Michael StJohns wrote:
S 4.3 bullet 16 - Is this needed if the RPC is an ex officio member of the RSAB? 

For context the bullet says the following:

   16.  Liaising with stream approving bodies and other representatives
        of the streams as needed.

N.B., “as needed.”

Shouldn't that be where this interaction mostly happens?  "Stream approving bodies" is different than "stream manager" and not having a single POC might be problematic.  (Sorry - I see this change was made -05 to -06, but there are a number of places in this document where telling the RPC to talk to an organization is just a bad idea - this comes under the heading of unintended consequences). 

One example of when it would be necessary for the RPC and a stream to communicate would be in relation to boiler plate questions or changes.  Another case might involve meta-information such as obsoleting/updating of RFCs.  According to the draft, these sorts of things would not be appropriate for the RSAB, but for the individual streams themselves.

Eliot

I think that's a fair interpretation, but it used to be "stream managers" and AFAICT, that was changed to "stream approving bodies" primarily to eliminate the "stream manager" term, rather than to address the point you made and hence leading to the question. It also is weird when reading it for the ISE.

How about "Liaising with other representatives of the streams as needed" which says that just not the RSAB member of a stream might be important?

I don't have strong feelings here that it needs to be changed - more of a nit than anything.

Mike



--------------IGmsPu4pZfaPOynv75BT481M-- From nobody Sun Dec 26 20:48:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0EF93A1766 for ; Sun, 26 Dec 2021 20:48:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.753 X-Spam-Level: X-Spam-Status: No, score=-3.753 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, 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 vBwxVuidZcgg for ; Sun, 26 Dec 2021 20:48:20 -0800 (PST) Received: from JPN01-TYC-obe.outbound.protection.outlook.com (mail-tycjpn01on20715.outbound.protection.outlook.com [IPv6:2a01:111:f403:7010::715]) (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 071993A1764 for ; Sun, 26 Dec 2021 20:48:19 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=b28NSdYC2zi14KKBknTIRG5mKFI1VSM1DewAr542E/DJmq1dzliIG9rsJVt/I50+mz8Q7QcYPbj1sqwlxxzEWt8G09nNHOD4lIkS/kH/UXkt6yqBUTZKHSVpYqsHI49Yo1x+QmQFH/cC/HjWHtQauqD0/ENaI9Nu/cubhUd+9bu4UOhwALVlY8Ys2o+yF2tXlda/oFekkOYis3/B0Ew907SBPhM/V2CSh2rUxUMoozKXdL7BEvIe76JK+ebLAZ6iBDvVOhx6p++Tvpn9SkjvoVzE8nIhfs2ApxFg4GXF5sjMn/x3LJu7dsbdoMRm0w2kjSE7rIfdHnEd7Q75GN07Dw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=u+/CLoYbFrHtoc63xYdFPtyX2GrKMcfeGYAVmfb9cRo=; b=BBYOfQUPzQFkbBArH+3MrwQhC3WUciCHQc45Tlo7jlFgsj0ZlQK7YvqptxIgTJT4TAxhwoRVQgNz6WJrLrurdu10rIQZbd7vcVAkJc3XjdIcs7q/Xhci78q0yRG0G8b74vp/SiRlVXWk9lnFDK6anWqm0iE2IydAtcCFU4JzlJQgnswTPe/4AiJh7A8u43FDuTsylyZPMXE0sqMDw2oCMLF3JTP7SbzI+FNcLel1LvGII9iopZMGcYaPSoEEW81xwEYuIgfzyzsTIy5YB9QSa/xfnLwjMOrEo3iRpQMfErv1Trfnbmsho//vfMGwVk6LoGHeJJ0BdeMSaO8Z7BqFuA== 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=u+/CLoYbFrHtoc63xYdFPtyX2GrKMcfeGYAVmfb9cRo=; b=D9NK4fqcHHAfiD7uSLWDcCvrshS/+PcqLRX3N23fuLstlRXQTKtKE4W36TFn3thoSNtYmtVeqOlqwQcScTrNHP/FpHOer9GLFigQH/whkBzvwA/hwmLEYuwYI0KYyrWlblepDw2PCuwvIzDtxJn/RO48yvVQcY1PyCEDCA4pvio= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYCPR01MB6964.jpnprd01.prod.outlook.com (2603:1096:400:bb::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.19; Mon, 27 Dec 2021 04:48:10 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085%9]) with mapi id 15.20.4823.022; Mon, 27 Dec 2021 04:48:10 +0000 Message-ID: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> Date: Mon, 27 Dec 2021 13:48:07 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Michael StJohns , "rfced-future@iab.org" References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYBP286CA0042.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:10a::30) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 817d3415-08a7-4cd3-546f-08d9c8f414f3 X-MS-TrafficTypeDiagnostic: TYCPR01MB6964:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: EHVHUx3gwr0/nqTe0kMy/SqU4URaaE/DD5Ktbc6L4Mg/5VZN74ZqFxBHOG2lJws5npFsdsiyNWRUpdbe+dRYUlJOy2zPgk2us/0H+jofY4qnbkJzEyXeIVry32iUoQCB4bqRZ0PI92QBU33uIvbic+NMT5Jv9ywY6OTxsJu4MGdG5QnnkHX+JHNdn3O6l+iVb4h03hlRkVqRUOrCmJfC0vlEDsJW0e4vMJ1sJVukq1PUwFfcXES46Qvbsa8iJtc9fRfI+tNgdRpl1XRrWVtG1EoUNjO4/Aikvmqdp2JQo6pI1gXlphAZla4yN8b50cdFXz2SCD2jQYUWRV1PeA/U38+/U3g5JyT9xXNxK0JwzPIeCy+uSdp8qiZCRLk6HRUEKKd8kSYJ5vaS4Qqq5EK/qlkMFyhHsQSCVLWehRzC/nSA8NUrdWtN9g75eENAWMNEYeldcs9gju+SV50VZxpPthYG23UpUlVO7hT2HQOdJZrsUJsbYcKMhK4tMSVBEwlC2bH7lj+i2BDCEn4ZAaBJuav/QkH87NBn4jxiMU/q3vuEKWHcZTPYWth7jL7Y1bj1A9it8tynGbK10WkEkjaHIIFQdUbgZ80b69rMnuoz/Qs7NXOOVtyIQkssIazZMFbbpzpfC8XDJHLDUepWL2+gEddBtnwOi0wrW/DMgIIJJBNCZTGmCSSii5Di0lAHiCEh6xJhqiQOnxkOCFU0dxqwwty7Ks7wEpHsY02ZoOJBc5GZKNnDG3n5e0npQY8QysKH+yvHOXsazeNuB1hA5tjXzA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39840400004)(396003)(346002)(366004)(376002)(66946007)(786003)(66476007)(316002)(36916002)(6666004)(6512007)(52116002)(8676002)(38100700002)(66556008)(38350700002)(83380400001)(5660300002)(110136005)(6506007)(8936002)(2906002)(53546011)(26005)(86362001)(4744005)(508600001)(2616005)(4001150100001)(186003)(31686004)(31696002)(6486002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?YkZKSUhSNkJxRkpMTENld0NCQUtIbUM0UVpncFZRSjVSdVV1WHBuTXpMT1Qx?= =?utf-8?B?QWZnVWJpK1dtOGQwOUlmM1ByOHhVT3owdis3WHBlU2hyOUdTOEV1ZXI3b3Ni?= =?utf-8?B?UTdjZXZ5a2lvWlYzOFpzd0IwNjN1WVlHdXRXL2FiR3dIaStHNkMxOTR6eVlO?= =?utf-8?B?K0xZeTNXRTVQWDFFbldNc2s0OWNnczVCWERmNVk4TW5YT1ZGU3ZXVDB6TmNX?= =?utf-8?B?RXVKSThQWlU2SDhHQ3dIUUFrV0JmdHVWVStoMjAycVZsTUtMTFYvQnJveE0x?= =?utf-8?B?WG95bU5rYWFGbzJVSlpFODhYYU9KZ2ZZWWhkZEhXK2hKQ0R3RnpTWkJLRXd0?= =?utf-8?B?RDlhNlZ3RURWc2ZJekdlUEUzaFpyRmUxYjlLeVFadlUvWUFkV3p0K2FsWXJT?= =?utf-8?B?ZW9PMUlxSWlmMlNDK1crNWNMSC9BOUhoMWlyMTFDVXBNSUNITWJDNDdRdXQv?= =?utf-8?B?dXJPUk9WYnYycGRHdTFXNXNHZ0N1aldIZlloc0RpZE5aSUhjNzlaVkVlSWFv?= =?utf-8?B?WDFhQnFMcUFyTTRxVnJYOSs4ZkJRdXcxZyt0Y0pPVlNyRnhLaUNKTjR1Nmow?= =?utf-8?B?RHVyK0Z4RDA0T2hMQ0h2R3E2NUQ2dGIzcUJqQUFiZ3NQQkUvSTBXelJGZFRs?= =?utf-8?B?N2daR01xM2JYRUtqd28vaWdGMXZiYUg0MXVrd2RUYmlob2tZNENHS0tGNytx?= =?utf-8?B?TDBwTERTRnRWN2NFNUVqcEFCYXFocHhrR2JienJrRUVUMnhwMHFETld4WG1E?= =?utf-8?B?dUR2ZHNVNXNnZFoyRk85SzRqQkZ5enhqNUpVWk5paEtxOThtYlBlTjhUZEkr?= =?utf-8?B?ZHB1cmo0b1FTVXNPcEgzWk9sSkN4U2FCTEh2YkpOcG1GOGF1UEcyMHZ0Z1N3?= =?utf-8?B?aWs4cllHYWhFSStFbFdpTGdYSWQrQTQvMmtQNUlEZHhSRTlGd2NjY3piVTVO?= =?utf-8?B?YTZBa05wdkdSRGhYU25zOTBlK2ppZ2VBR21BZ0N5UHBZdHpjZWdrRTNPaUZu?= =?utf-8?B?c2VwUWdLNTRKeWN1SDZDUEtTY3gyTFUxcUc0d2E4N1hXUGNOVDc1amlBRjlU?= =?utf-8?B?azI2NFk4clVwYjlTUVpkRjhUdkhNaW9zelBSTXNoTjlvbGtTMW1hMlhYY2ZN?= =?utf-8?B?eFp0bFp2Skp3dnFJeUJ0UXptS2tmZDJvZXdZeUlwdlUyRThaVk80eENzL2dr?= =?utf-8?B?cmo5eTJNbVo5UkdZUXpMSWxNbzgwNjEvU1hxUGhtZCsrcmxGaFFtalhUbUFi?= =?utf-8?B?Z2lvMVUyTkh1UjFtd3owZnkrUGsrLzhpM1FaVHZVRkZCSmtGZURUWUVZWTk5?= =?utf-8?B?UXIvVjVkbE1Ob21jdVJiOVRlZkRsRjZFRmQ3MExSZ3FZamRhYWJjS3h3blBS?= =?utf-8?B?bTROSnhnQ0haU0ZCeFo2b3dteWpMOHpjb1Flc1dUSXhqMEFtYmgxbDE0OTg5?= =?utf-8?B?dTYxRUdGT1pCK2Y4Wm9YOWhkeVhaTHkrYys2QUFNcndGMVpvNnBhWTVIWFVR?= =?utf-8?B?aWR3VkM0NGsrYjRSRzBULzVhN0pQQXVMWjQ5NVhHQUg0Z1JHYjF2V0JrZU9z?= =?utf-8?B?SHFMYXJ4V3R4RE1tZDVQYWo5UmovWWhnT01WS0R6WUp3OURTcndNMTJaYlN5?= =?utf-8?B?cjdiWWltZ1RLbGJzUm14RTFVdTdQWVZkaE92SFFHMnRVTDlNWXNwQzZVUTl0?= =?utf-8?B?eG5PeVFEQVFxZnZRQ0JHakt5Mm5CU3FrUHgzY3BueUc3MEtUN2d0c3E3VTNR?= =?utf-8?B?UnhOMlRLUmVodVpNSEJINGRRQS90NER0TXNqZUxIbnJWS1JOMkpoYmorNDNF?= =?utf-8?B?YTd5aEpJNndJL0tHQ1RCMFFzbitLMXIxNW4vU0FOODZPYXVBRWxnT0pzV2tW?= =?utf-8?B?bmh2TTJqNUNQdkVRb0xSU0phVmVSeWs5SzJTUld4eVFLeEhFcS9RL2NBamYr?= =?utf-8?B?R1hEajR4STIyZ1oyaG5wRHNyazVibGlocVIvTWVQK05RWmFvRjlOck5YQ1Yw?= =?utf-8?B?QTBuMkE5Q3hjQ2JwbksvTTBEd0lsbjY1b3g0ZzBqQWVsUWlBQXVGYmxRSm5B?= =?utf-8?B?VGVBYldlbXJWaFE4WWp6REtRb250RmxZV0hZQ0RPQ3BJcU9iNFlFYmJRL2tF?= =?utf-8?B?YlR0VUtiakZNOThHUkZSZzJwdmJoVVlJeDlucngzS3VzUWd2QlNMZzZjNitm?= =?utf-8?Q?4mccr4gt+t7/jt+ZQCrRT8o=3D?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 817d3415-08a7-4cd3-546f-08d9c8f414f3 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Dec 2021 04:48:10.0420 (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: wrNyE2WNlT6WYfQTOz6EH91NuRd9zbQ6rVih2d6hgeBY9OxMq3HboaAzTBY8a5j2I99ffi5MmOQ1QtH1BSoElw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYCPR01MB6964 Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 04:48:25 -0000 Just one nit below. On 2021-12-23 05:56, Michael StJohns wrote: > S 6.1 "These procedures need to also allow authors to indicate either no > rights to make derivative works, or preferentially, the right to make > unlimited derivative works from the documents." is probably to > specific.   I looked at this one and I think I see a land mine. We're > trying to specify legal language here and if not careful could conflict > with the language of 5378.  Instead: > >    These procedures need to allow authors to indicate rights requests >    consistent with BCP78 (currently RFC5378) or it successor.   The >    publication of a successor document to RFC5378 and designation as >    BCP 78 shall be effective on the Editorial Stream process as of the >    BCP's publication date. > > Or get a lawyer to craft this. "BCP78 (currently RFC5378) or it successor" -> "BCP78 (currently RFC5378, or it successor)" or some such. Happy holidays to everybody, Martin. From nobody Sun Dec 26 20:51:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7E63A176A for ; Sun, 26 Dec 2021 20:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=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, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=me.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bCkCvMI_X2q7 for ; Sun, 26 Dec 2021 20:51:18 -0800 (PST) Received: from mr85p00im-zteg06011601.me.com (mr85p00im-zteg06011601.me.com [17.58.23.186]) (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 46F493A1769 for ; Sun, 26 Dec 2021 20:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=me.com; s=1a1hai; t=1640580678; bh=w8/kOlZjbQsPrRrG6q+fZMkQNkIdbtC3rdfvcUY6IG0=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=TN9+5tmOsdKp4/rID6MFdSkxLhelOe/FQfzXH4SvhSly+cq8OJjr9ARrmUBIXm6ge ZpTt//+Fut15nTRpeasZ7nfgeDFUxyzVeNp17dCh5M8m7UIMtRCLHWvPfwlaTP143O xIC84qepQsh+jh7nDvHyyPkuLQc2ENc10RE212GTyulHm0OUnRwojAooKGlU3hHKM4 L9cPj3+W2sN9c1zoohsRVV6jeGV2a0fAgZlC6D0C7YRJHgtKvMiDyzIxaKPsdEQGUy 5vFcvFCmdnnTypCALjVfIGp9117q5LifPSQPVjOuay3LjP6rgwcQxrHgZw9wk3gin6 xoqRgAAbi10kw== Received: from smtpclient.apple (157-131-155-250.fiber.dynamic.sonic.net [157.131.155.250]) by mr85p00im-zteg06011601.me.com (Postfix) with ESMTPSA id AC6C51807CE; Mon, 27 Dec 2021 04:51:17 +0000 (UTC) Content-Type: multipart/alternative; boundary=Apple-Mail-6E784FDF-36C5-41C0-92F3-DDF6A73787A3 Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) From: Ole Jacobsen In-Reply-To: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> Date: Sun, 26 Dec 2021 20:51:16 -0800 Cc: Michael StJohns , rfced-future@iab.org Message-Id: <72B98B27-2B99-405A-8219-2C8BB5D5F164@me.com> References: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> To: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= X-Mailer: iPhone Mail (19C57) X-Proofpoint-Virus-Version: =?UTF-8?Q?vendor=3Dfsecure_engine=3D1.1.170-22c6f66c430a71ce266a39bfe25bc?= =?UTF-8?Q?2903e8d5c8f:6.0.425,18.0.790,17.0.607.475.0000000_definitions?= =?UTF-8?Q?=3D2021-12-27=5F01:2021-12-24=5F01,2021-12-27=5F01,2020-04-07?= =?UTF-8?Q?=5F01_signatures=3D0?= X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 malwarescore=0 clxscore=1011 phishscore=0 mlxscore=0 spamscore=0 bulkscore=0 mlxlogscore=724 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2112270026 Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 04:51:23 -0000 --Apple-Mail-6E784FDF-36C5-41C0-92F3-DDF6A73787A3 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think you mean: "BCP78 (currently RFC5378) or it successor" -> "BCP78 (currently RFC5378, or its successor)" its instead of it Ole J. Jacobsen Editor & Publisher The Internet Protocol Journal Office: +1 415 550-9433 Cell: +1 415 370-4628 T-Mobile: +1 415 889-9821 Docomo: +81 90 3337 9311=E2=80=AC http://protocoljournal.org Sent from my iPhone > On 26 Dec 2021, at 20:48, Martin J. D=C3=BCrst wr= ote: >=20 > =EF=BB=BFJust one nit below. --Apple-Mail-6E784FDF-36C5-41C0-92F3-DDF6A73787A3 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I think you mean:

"BCP78 (currently RFC5378) or it su= ccessor" ->
"BCP78 (currently RFC5378, or its suc= cessor)"

its instead of it


Ole J. Jacobsen
Editor & Publisher
The Internet Protocol Journal
Office: +1 415 550-9433
Cell: +1 415 3= 70-4628
T-Mobile: +1 415 889-9821
Docomo: +81 90 3337 9311=E2=80=AC
http://protocoljournal.org

Sent from my iPhone<= /div>

On 26 Dec 2021, at 20:48= , Martin J. D=C3=BCrst <duerst@it.aoyama.ac.jp> wrote:

=EF=BB=BFJust on= e nit below.
= --Apple-Mail-6E784FDF-36C5-41C0-92F3-DDF6A73787A3-- From nobody Sun Dec 26 21:05:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A373A1783 for ; Sun, 26 Dec 2021 21:05:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.752 X-Spam-Level: X-Spam-Status: No, score=-3.752 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcmlsSGZRk-F for ; Sun, 26 Dec 2021 21:05:17 -0800 (PST) Received: from JPN01-OS0-obe.outbound.protection.outlook.com (mail-os0jpn01on20725.outbound.protection.outlook.com [IPv6:2a01:111:f403:700c::725]) (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 C3C3F3A177E for ; Sun, 26 Dec 2021 21:05:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MbowhWwiN4RqUNNNwrVwRJVAVYafEEahwoJwuu8jD1Z4Y/CfEQqTnnGmdHcgjRe7PXDwO33A0RaVhelqMqA2SA4uRQycc/te5wJ97tEuv29O7RRqAJ5XtJQzHlZaKAGnjAijmGeX37HLGD8FLEvQnSyl3B0kalRMFCXTW6QTHj6sfN5HuysqFCwygWfIh0ePV8ThfmFB/z5aJwvJfDl4NsiammvE2Eff/alupiCrozckbv3IGb8DFkzlcuwtwj0TxfYpBWNvgC00IveZO397owWgleD3QVaYmH4RlpbIZSPAfPXnre4mIeLXd3MeJNbqsFcnFxM7SZmhYcajlBBs4g== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=uTfqEfUB2bgjc14MlI2dmEmhVyvQES5Wfs/NC8soKIQ=; b=GuA3BjSYsTJWtDxtqUcdPYT/NIvrXGoDrDbH4oNxiVsjnSEMIzCTxPp4uNFWS1tOEUVDHAIqu7Jn5QUNfW86NhmkuZbvplGEbzoWtUVJifhri9tQqpWtoDSoXmw2zWpBo7yhtplokvlG1DrXzd5TX5mYz/JpyK4+M2LI3GG0YjsLpZgLsDuzYxFTpF7Fctd2uN5vEuztk66dQHwwQWHk8hJKaoAs/iLgpT/lRkVlpJgyKvsRi5GKBaLLwd3PL8YxLCqWBJQb37Dknl7JeJsoEiuBN9tnwVSbV5ieETpFc929PVyrnJL6p4Tr79EwRArPb7VuFmqrcaxTI4Z+ss2adA== 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=uTfqEfUB2bgjc14MlI2dmEmhVyvQES5Wfs/NC8soKIQ=; b=fIwh7oQUzOIE5lGkYXYDNBxsPgghLyREF7C4Oh0gjC0y34Tc7pm3QVrgrNDYJgcs6h6oZTEcXxnGaoLAHks3f/2hE9CNuwnm8a24P7NZQOzhTg8Lm32fTHYa/O/OMTEopM6KvW4DFFS0D2nNydZpQFZafI+GH8+d+l80CsglNR8= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB2922.jpnprd01.prod.outlook.com (2603:1096:404:72::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.21; Mon, 27 Dec 2021 05:05:08 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::20af:5ba3:7059:f085%9]) with mapi id 15.20.4823.022; Mon, 27 Dec 2021 05:05:07 +0000 Message-ID: Date: Mon, 27 Dec 2021 14:05:04 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Ole Jacobsen Cc: Michael StJohns , rfced-future@iab.org References: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> <72B98B27-2B99-405A-8219-2C8BB5D5F164@me.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University In-Reply-To: <72B98B27-2B99-405A-8219-2C8BB5D5F164@me.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: TYAPR01CA0023.jpnprd01.prod.outlook.com (2603:1096:404::35) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e0e903d6-ae78-4390-1035-08d9c8f673aa X-MS-TrafficTypeDiagnostic: TY2PR01MB2922:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:3383; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LF98IZJ4GM6nOkgNQ94OwctvQRafVdLl4LXj8byXeqf/qOWgSeZE0qwOqpuEKzOhwQUa5gVQRJ809tTwICVMXEZNgvvBZsilam9zgzDF5yYjETLEI5H3cbmXqtt8gI04aXjVs2s8tVSwQxhIj9+r7ASL/o88qptanzMEnhcZLZI3U8MH8foepfNkPPCaZFftVKu8pLZjjDePUht0Pq+b0DzfYALtEtMmTxXCRd7Bl4bwdbH6nOur/yw7bDWz7rfA6iXh3q7n7z1eGYBr4EzAjgT2kuT3T7upaLoF56v4z6h2CHVU04Z/p18WxrB/ZRV2A1HbRN2VR2Bao+GoC1vNGoarI5eqvKS8Nodt7iLdcqPvWM7DX/saYrCdNNjInvP49qrnMI9BZy2DlfjHKdy5ougNojQRcThWh0k5BkvxrN9mtOlAyMeDImCxp8HzLnuxmNf4yzBDPjvLYFzKuGZZgtU05XD3QW23MmK6PHp0Rfl/DFDvAW5Nr4cFKRnybVU7ukxspsYm5tGn7iOe9doFJR+t7bJf8IBWToIFvvS5wOnp9mLlPWXHywKo5GvDM+QhC3EQkW66/G7a7sAOhWWdswENgAsEGJVHB6y35opp/m6HGKLEgRSTN41fpp8fwTw4f+u1orQgzsObtOwx+kYpgr+w4y6LQ9NiEVofwePFqjctMVLQmC8991YX6kThoRxkuynJ/pxcqjkB2pHiQ+9fzvzou5ImAEFu0juqCf3NVCrArUsLMkWwmVQcHW6MADLXLmmpcsV2wuxnVtb+JweV9zA9obOnB2FdaW9H4pR6l8fsKcWolfEK5BTZfiItM2WuEo0Jmv9uBibAXL6WhA8sQySgPvhces3xdnQ6OHYfjMA= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(39840400004)(376002)(346002)(136003)(396003)(366004)(66556008)(4326008)(26005)(2616005)(66476007)(186003)(66946007)(4001150100001)(38350700002)(5660300002)(31696002)(38100700002)(8936002)(6916009)(40140700001)(66574015)(53546011)(966005)(86362001)(6486002)(4744005)(6512007)(508600001)(316002)(8676002)(786003)(2906002)(6666004)(36916002)(6506007)(31686004)(52116002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZUtCNFdTaXRxdlpmWmYybzcvdGRsZjl6WkE1RVJERXU4dFpLLzNjSm5WUUJJ?= =?utf-8?B?QW9iOW8xcEsxUUxHWnVxRm9YK3dnN2xjSVQ5Y1JHd2dieHE1WUNDSUd3OWVX?= =?utf-8?B?cmVpYy85cGdtTTdpVHp5TXZCTEw5OGZLWjZraCs4bnVnMXJLVUNQcnF2dGEv?= =?utf-8?B?S1FpWkI4UnVjNFZJNkRSQmgvTUdvQ2V0ekJEaytabWpjQ2daUktodUovTGVX?= =?utf-8?B?SGN4TVh1N2wvQVJ0bEZqSGZJaWhLVXNkWlI4TVZ0V0xtbC9PRFN6R0hzYkQ4?= =?utf-8?B?Z1VvSzFnLzRZaW42eDJZMFR3QXdCTXd2THFrNUNMNytlbktxQmhzd3EralYw?= =?utf-8?B?VDhEWCtFdjNqdGh4dERIcStWU0ErMmRSdEwzam1OOTlNNU9JTnRCVDRLUk11?= =?utf-8?B?aGhvWWI4V1pCRFQxQkFLRWFmYWYrbSsrbTRYNWhaU2dpalNOcmdLSHp0UTJl?= =?utf-8?B?WXNEVm5pZnR5TGhMTXl1NlpVWEhhRVh1N2FIV1VidHB0V0hkdlIrYVJzazMx?= =?utf-8?B?MmxlNjVjcEdNTUZ3TjhXdGdFK0FBS3JBN2wzSE5YbStXS2tWY0VyYkhFdXR5?= =?utf-8?B?a1pWMnpENUZadmRKd2dXRDBTc3VBai9BcmpCVWQ1dW1BV21xR2pIbHF2OHcx?= =?utf-8?B?dkxaNjhNeXJvQXhNZlV6T3EyeUtRVXBnalZwRkNEZmF2Zzlpb0k0dDZ6Wml2?= =?utf-8?B?ZnVqS20vUHNFdzVKd1RjVkQvV2JKS2RnZ3FwaDhWK3Q5dzdKR0tHM3RJaUNI?= =?utf-8?B?ckhJdEwxTWpKZWQyTExuRXUyUkxVWU03d3RZZ21hVHVSRDRWQWw0dXZrZm16?= =?utf-8?B?N1p4VkNmaGdLWW5lZGtSbklVSnJqbURQQzl2TW1hWm4vM1lkVzRBTllXSkI0?= =?utf-8?B?SGZPM1pKSVRFVWk5TFgxdk8xcXNvNGdmVHFzNjFic01kNUFkU25ta2EvU2pq?= =?utf-8?B?WlgwU2xrOEhlU2ZZOXNqNjZ1VzFBQUJEVU0vQTlXMktycjBaSC9QUU5iMTJo?= =?utf-8?B?SDdEQVBIZ3o0eHVGVlREeDN4Wk5jOGloUDBhTTVyeHVKNlFsaWJFb1ZmQlBK?= =?utf-8?B?WDNrR2pSUTJPaURqdHdnS0xRQWs3ekVza2lMQmxGdFVQaHJvRUVuWDlvUG1W?= =?utf-8?B?QUsreG1TNy9jaWVRWVlSODY2MEV3MmVKdnk0blhFMlkrMDhNODg5RThKU2FG?= =?utf-8?B?SjcrY25ZZHdoZXNtanhFS3l1V3dmUjMzRFNyUTFMamlKekhSZjJpRGcrOVRI?= =?utf-8?B?VngwQWhxUGNXYmxkVWdYVlU5M0g0OVcvL0lRVVhiS1F6UHZ1UW9qdkZYWVEv?= =?utf-8?B?UVlSMVJ2YVJDRmxYMFhHOU1UaVJ3R01zck5MYTRiVDVwQmZNdC8rcDFBZERZ?= =?utf-8?B?cUVySHZuQVdFSUVtVnNnelI2eDZMWHdpVFlRcEI0RTlwU1hSZXByeUdUSDZC?= =?utf-8?B?Z1RzM0M0M3ZrYWQya1J1SEFXVHJ4OTdFaUdhT3FIcllZZGRZUFV3Tll5dUdh?= =?utf-8?B?Vk9seEM1bXZ5TmhLR3I3OVIwdkFwWXNrdW92WEhMaFJJTFJVTTNuRXhQZkY0?= =?utf-8?B?cTd3Tjk0TmFzM1FweTZwUytYV3VpSXM3anZXQ3p1dHlPQVFGSmQ2TVVRdHlU?= =?utf-8?B?RUo5THNDZUdidmhrNjNnZjhuZU8rbjhGZy85SlZxaXN3SGp2L05HZTVac2pk?= =?utf-8?B?UmtHMjJFM2xIU3Fxa1kxRENHc1VFa0dtczVRNHFUNHExeG1EMk93MzM4ZHoy?= =?utf-8?B?WmFMS2VGdEI0RHhUY1ZSOVZQNGdZWUExdG90Rlc2cEl3N21kY3ZGVUM5TFVt?= =?utf-8?B?YzBscHhXSmwyRGdOaXAvaE1GRGRyNHBsS2grZm9DcHh5M3VBUnhrdmJ1N21a?= =?utf-8?B?bXpsNEV1Q2Z0c3RaNWE0NlRZQnBSRm9IYmd3eTZ4MmVkRnpqeVIxOTVDVGRv?= =?utf-8?B?aTQzbXNsa3ZVbHh6MXd0R3JXa013aytzZnZqUHh5My9KcGc5eWszSHpvRUFs?= =?utf-8?B?cHNrQUxiVVVRbnhMNjhxOVY3b3BqRjNCZWRWN2hBdUYwUjBMSjlNRkFJNExN?= =?utf-8?B?eGJGbkNZYTdMTk9IUm8vZzRxcnVQUGh4dXdibEcrNDZlajBUc3doK0dHZlht?= =?utf-8?B?WEVVRkZyRHkxSFhSbWpka3FQNmViRlhKdHRkSHJoV3d2RXBjTlRIUElhenp5?= =?utf-8?Q?FvXycj2Ylk6MDQ0CMFaps+o=3D?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: e0e903d6-ae78-4390-1035-08d9c8f673aa X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Dec 2021 05:05:07.8764 (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: Yfh08dbcrFBMj6uah3SW+dJX5h0kCmOabUXs1TYKWmWzjlnteGGuP/kBeNuOfFeH0jWaO6qVUPkm0XBZ6Kl8Fg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2922 Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 05:05:23 -0000 On 2021-12-27 13:51, Ole Jacobsen wrote: > I think you mean: > > "BCP78 (currently RFC5378) or it successor" -> > "BCP78 (currently RFC5378, or its successor)" > > its instead of it Yes, of course. Thanks a lot, Ole! Regards, Martin. > > Ole J. Jacobsen > Editor & Publisher > The Internet Protocol Journal > Office: +1 415 550-9433 > Cell: +1 415 370-4628 > T-Mobile: +1 415 889-9821 > Docomo: +81 90 3337 9311‬ > http://protocoljournal.org > > Sent from my iPhone > >> On 26 Dec 2021, at 20:48, Martin J. Dürst wrote: >> >> Just one nit below. > From nobody Mon Dec 27 08:19:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1F43A0DD6 for ; Mon, 27 Dec 2021 08:19:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.95 X-Spam-Level: X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, 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=stpeter.im header.b=MhtiGkQj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ih/e0IdX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36GDXrh8h0mS for ; Mon, 27 Dec 2021 08:19:27 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5DA3A0DD3 for ; Mon, 27 Dec 2021 08:19:27 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 505955C01A6; Mon, 27 Dec 2021 11:19:26 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Mon, 27 Dec 2021 11:19:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stpeter.im; h= message-id:date:mime-version:subject:to:cc:references:from :in-reply-to:content-type:content-transfer-encoding; s=fm1; bh=/ 44PgboO6IWlTYSnbB/sERbR74I93pF0ZtO3FzBpoao=; b=MhtiGkQjPVVpQCYrH ZtlWtXjaOM6DB4MgFjAB/ZXfbpkw6DdqF3Ntuzi2HCPRTtsvYnUm2JsIdPz6PhEn oeRCySfJdrcjTUpnSY4wixXdpcSTpgAU1n8w0be8DqZYCEfty0+uWvlOkMqa3Zd/ 7Bq7APO9CMDKbEuhKKImusocTQ1OU6sTQujo+3KDC2oT6pHTvx0+dSXV2073SXZL 3oUpUkqfzkqIrfbJi7SVcan3h8ABng6CallmDOGzva/p4srH89ht4hTTHVHkChmw A4YVpOQUViQISm+g/LvIlxaJkqLF6bNLmMYIb+7/t2HhFAVwWwYibMXmCj3ecpC1 zc1Bw== 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=fm1; bh=/44PgboO6IWlTYSnbB/sERbR74I93pF0ZtO3FzBpo ao=; b=Ih/e0IdXiIoarMJkZN5ZA8nLi0ug2xn1cg3Qc0ldaTdmhQRqi3rc+LRr1 3UcZE5lXYksCO7XfqFbva2maE1OpyrPcu2FZ1JgXnyKkrhkiAElFNvt2wDFtIPLk t1/kVMMAJW99ywavLORhM551yIIfhMsGNoQoAfYOy3Umwu+OBRrrUzVP0t1jtsCv 8WGIDrwqbtY8XrlVLxIfHJgvxkqA5OwJA7KkPnsRXeWj1xFzg7xV40ec4Yxk5YqJ /ErUZ92kR3L5t9+6q6ErHaWnBe/BaaiEfc86ZraA480YFK6xCAgKurmytNeMn8QY JRyFxV2FBCSbw3cj8DReD1E4LMyqA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddruddujedgkedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthekredttdefjeenucfhrhhomheprfgvthgv rhcuufgrihhnthdqtehnughrvgcuoehsthhpvghtvghrsehsthhpvghtvghrrdhimheqne cuggftrfgrthhtvghrnhepvedtgfettefgffevheetvddugedugfelveeftdelveetgfef gefggfefledukeehnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepshhtphgvthgvrhesshhtphgvthgvrhdrihhm X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Dec 2021 11:19:25 -0500 (EST) Message-ID: <91218bfe-56e8-8e22-7e70-aafe1e7661af@stpeter.im> Date: Mon, 27 Dec 2021 09:19:20 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Ole Jacobsen Cc: rfced-future@iab.org References: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> <72B98B27-2B99-405A-8219-2C8BB5D5F164@me.com> From: Peter Saint-Andre In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 16:19:32 -0000 On 12/26/21 10:05 PM, Martin J. Dürst wrote: > On 2021-12-27 13:51, Ole Jacobsen wrote: >> I think you mean: >> >> "BCP78 (currently RFC5378) or it successor" -> >> "BCP78 (currently RFC5378, or its successor)" >> >> its instead of it > > Yes, of course. Thanks a lot, Ole! If someone can tell me how to cite a BCP in the rfc-kramdown format then we can avoid these circumlocutions. :-) Peter From nobody Mon Dec 27 10:57:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91BB23A109C for ; Mon, 27 Dec 2021 10:57:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.701, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2QjZ5uehTnn for ; Mon, 27 Dec 2021 10:57:14 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74BF3A109B for ; Mon, 27 Dec 2021 10:57:14 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.1.2/8.16.1.2) with ESMTP id 1BRFWk2w030320; Mon, 27 Dec 2021 18:57:08 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=ZmDr4Kj/CIfebX+pMpJJrtQCmmMMx72LIF++oY/aadQ=; b=Xti6vuuBOHWZ6FuNuXslUUJWxg2cS3xqPWDCraes2ke4ZuSEBIjYT4x6A4uwe8pK+cfp 0cZLjYkdt0xl6C+eo4oHiDeTCNMJBID28oYSiSP9bFM2c4Ux/0KVE2/xbwk/tVnrsgg7 kngG2ZPsDEElHmuszNrjJzcfiMUxSVMQ5WGPQOYKHAk59tuWspH1v0cgcPOZIbM4+bZv XJ+XA7tw6GJ/8etZskJUeezZtlGpr3ItA16WV3GsZKcCAMJBrJS7HbLIHy6VOh78JMGL fpLmr7/kBxxW59/2NSt3oF9fUjezv99+GvY0j82PunFh8HfvOHSmLBNVqwkdBAspOwh+ JA== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050096.ppops.net-00190b01. (PPS) with ESMTPS id 3d72s0bsny-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Dec 2021 18:57:07 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 1BRIokcv005257; Mon, 27 Dec 2021 10:57:07 -0800 Received: from email.msg.corp.akamai.com ([172.27.91.21]) by prod-mail-ppoint5.akamai.com with ESMTP id 3d625euanr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 27 Dec 2021 10:57:07 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1497.26; Mon, 27 Dec 2021 13:57:06 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.026; Mon, 27 Dec 2021 13:57:06 -0500 From: "Salz, Rich" To: Peter Saint-Andre CC: "rfced-future@iab.org" Thread-Topic: [Rfced-future] Comments on -07 Thread-Index: AQHX93ZyPTZmMzx730urXQqQg9faT6xGHsaAgAAA4QCAAAPbAIAAvGMA///YQoA= Date: Mon, 27 Dec 2021 18:57:05 +0000 Message-ID: <63007F34-87F5-4F69-8D9B-D69946C35546@akamai.com> References: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> <72B98B27-2B99-405A-8219-2C8BB5D5F164@me.com> <91218bfe-56e8-8e22-7e70-aafe1e7661af@stpeter.im> In-Reply-To: <91218bfe-56e8-8e22-7e70-aafe1e7661af@stpeter.im> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.56.21121100 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: text/plain; charset="utf-8" Content-ID: <632D4709F76C454A8941EAADC5843580@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.425, 18.0.790 definitions=2021-12-27_07:2021-12-24, 2021-12-27 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 spamscore=0 suspectscore=0 malwarescore=0 adultscore=0 mlxlogscore=879 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112270090 X-Proofpoint-GUID: MFZTyMpf1B2b_CzgLUpTQSWITMZTapM0 X-Proofpoint-ORIG-GUID: MFZTyMpf1B2b_CzgLUpTQSWITMZTapM0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.790,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2021-12-27_09,2021-12-24_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 mlxlogscore=917 malwarescore=0 phishscore=0 impostorscore=0 mlxscore=0 suspectscore=0 adultscore=0 priorityscore=1501 spamscore=0 clxscore=1015 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112270090 Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:57:20 -0000 PiAgICBJZiBzb21lb25lIGNhbiB0ZWxsIG1lIGhvdyB0byBjaXRlIGEgQkNQIGluIHRoZSByZmMt a3JhbWRvd24gZm9ybWF0IHRoZW4gDQogICAgd2UgY2FuIGF2b2lkIHRoZXNlIGNpcmN1bWxvY3V0 aW9ucy4gOi0pDQoNClVubGVzcyBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHF1ZXN0aW9uLCBpdCdz IHRoZSBzYW1lIGFzIHlvdSB3b3VsZCBmb3IgUkZDbm5ubi4NCkZvciBleGFtcGxlLCBpbiB0aGUg ZnJvbnQtbWF0dGVyIHRvIDIwMjhiaXMsIEkgaGF2ZToNCglub3JtYXRpdmU6DQoJICBJQU5BRE9D UzogQkNQMjYNCkFuZCBpbiB0aGUgdGV4dCBJIGhhdmUNCglBc3NpZ25tZW50cyBhcmUgY29vcmRp bmF0ZWQgYnkgd3JpdGluZyBhbiAiSUFOQSBDb25zaWRlcmF0aW9ucyIgc2VjdGlvbg0KCWluIGEg ZHJhZnQsIGFzIGRvY3VtZW50ZWQgaW4ge3tJQU5BRE9DU319Lg0KDQoNCg== From nobody Mon Dec 27 12:18:57 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373B43A117A; Mon, 27 Dec 2021 12:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 6-Vw2oP9a5nc; Mon, 27 Dec 2021 12:18:50 -0800 (PST) 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 8E99D3A1179; Mon, 27 Dec 2021 12:18:46 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n1wS8-000DqQ-Jb; Mon, 27 Dec 2021 15:18:40 -0500 Date: Mon, 27 Dec 2021 15:18:34 -0500 From: John C Klensin To: Eliot Lear , Michael StJohns , Jay Daley cc: rfced-future@iab.org Message-ID: <5770F1800AC5065CDED8F988@PSB> In-Reply-To: <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> 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] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:18:55 -0000 --On Thursday, December 23, 2021 07:48 +0100 Eliot Lear wrote: >... > Can you state why we should revisit this issue, what problem > you are trying to solve with the existing text, and why this > responsibility should shift from the LLC? Eliot, I apologize, but I think we need to come back to the other part of this question, one that I raised some weeks ago and to which there was, IIR, no substantive response. Section 5 of the document puts complete responsibility "for the method of and management of the engagement of the RSCE, including selection,...". Section 5.1 goes on to say that there will be a selection committee, but, other than saying that members of the community will be included, leaves the selection and composition of that committee entirely up to the LLC. While I feel better about the situation if we guarantee the RPC visibility into the RSAB, we are, to a considerable degree, still relying on the professional technical and historical publications knowledge and experience of the RSCE to keep the Series on course. Our decision(s) to reduce the authority of the RSCE relative to that of the historical RFC Editor/RSE will make that position challenging in another way, which is that the only effective way to inject that experience, knowledge, and perspective into the system will lie in the ability of the RSCE to educate, explain, and persuade people, perhaps even people who are less interested in thoughtful evaluation of many considerations and more interested in getting on with something they believe is obvious. After studying Section 5, rereading Jay's de facto criteria list (containing properties I believe are necessary but not sufficient) and noting that * there are no requirements in the LLC documents for either the LLC Board or the ExecDir to have expertise in publications management or publications or in evaluating candidates, or even search firms for locating candidates, for such positions and * Discussions on this list suggest considerable differences of opinion about how significant the RSCE role should be. We have probably reached agreement on a middle ground and I do not believe that reopening that discussion would be productive in any way. However, it seems clear that there are still some of us who would prefer that position be given much more authority and others who would prefer that it be further weakened or eliminated entirely. That is a risky combination. Should the LLC --presumably at some time in the distant future when the nuances of these conversations have been forgotten-- develop a preference for either of the more extreme views or even legitimately reach the conclusion that one set of characteristics in the RSCE would make the Series easier to manage, organizing the search process and then selecting the search committee in a way that is consistent with those views could easily, even if inadvertently, determine the results. I suggest (at least) two small changes to 5.1 that I hope will not reopen other issues: (1) Change OLD: , including members from the community, NEW: , including members from the community and representing diverse points of view about the RSCE role, (2) Provide a mechanism for RSAB (or RSWG and RSAB) review of the committee membership. The easiest way I can see to do that without creating a lot of process would be to add, as new second and third sentences of 5.1, NEW: A draft of the proposed membership of the selection committee will be submitted to the RSAB for review. If the RSAB (including the outgoing RSCE if available) concludes doing so would be desirable, they may make suggestions to the LLC about that list and/or propose additional members. That can be modified as needed if we really want the RSWG involved, but I think that would just invite food fights and a reprise of debates we hope are settled and will stay that way. I don't believe this needs to be spelled out in the document, but the above, or at least the recommendations to the LLC, would be a normal part of RSAB discussions and hence not subject to executive session or secrecy rules. The intended checks are openness, transparency, and encouraging broad perspective even were the LLC to develop a blind spot. Nothing above would hobble the LLC's ability to manage the process as laid out earlier in Section 5. For that reason, I don't believe that the introductory material in Section 5 requires modification, but I'd defer to Peter on that. best, john From nobody Mon Dec 27 21:01:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD7D3A0C2F for ; Mon, 27 Dec 2021 21:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.75 X-Spam-Level: X-Spam-Status: No, score=-3.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, 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.20210112.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 HUUyPat64LZ0 for ; Mon, 27 Dec 2021 21:01:50 -0800 (PST) Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C78A43A0C29 for ; Mon, 27 Dec 2021 21:01:49 -0800 (PST) Received: by mail-qt1-x82f.google.com with SMTP id f9so15254341qtk.4 for ; Mon, 27 Dec 2021 21:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=YtfNRPchVN2Ryh+i00Qf48ZdZr2BNyXGY6dosZYyg8o=; b=j+llj8fFKBNinAEWFVSmTxN6E7GQeQBfzzz46zXUDEaempcTUQuAzqxickMgGdPtht Ho7v1IThXAxBBh7e/7lxSMWn2d+/Z9yO6KmTdQBQcrIy9koHW//AZC5i3Xpd66T8yGuF 5EW8bJSgB/4WSa8Vjdx7ghFsPKTtOIuorHSsDe6sE4y7cnelw2Qe8LP5u4i21f3+oBGB D70qFleurZ+bTJFyeFcZsNidJU/jqy409ll1N3tbKhKtfveBnXafem/NRMEnkwf/Okn7 2zTZaiS9JaHqj553O6nDnvgAHi1idELS+tyO2fYKwzOd4frqCL8f2iGbqOtMum6XvJdB C0fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=YtfNRPchVN2Ryh+i00Qf48ZdZr2BNyXGY6dosZYyg8o=; b=lt8xsuzh/uAPcIVbMQQ0YEUaaepjyYBatUFplbDF0v0FdRPANyB1IRZXDojDSjN0Gt fVT0DEqp+eSB8/0XcyZIjz6waUBIebTZIJFNB/yb9s10lynKgEJzr2noy/Ch99hYqRd6 oFksU33SeGClm5r+remwlSZV6HUmeSEjHtWq7fZeEZPQpDXWS9KfLxsg0HAi5YKeq40J IP3CZ8SmpTcXbSPPE2x1622ODvZjg5m+n9sLGAC3H1jlTzhqo1ftzbYEiwnhLXb7mR/E Nr/wtj3Q42GPGcM8ONPObJ9HvUd6cCR7+syyY+CcYGPqZmfJZFJ+e2IMihkSKw4tzYJl futQ== X-Gm-Message-State: AOAM5310KVA0JaBaenHQqVrWhEwkISKXZwR1bD+3wWKbKhuR585TFDdr 0UPYEGwpoANa/olatGGxU9Aq2g== X-Google-Smtp-Source: ABdhPJzOD91xK/20WMagb5uSHP1UHq7j2YFfzyxc1PFqk+0v6vNKj9xQT42x06Zx5OszHHZEdI/zvA== X-Received: by 2002:ac8:524d:: with SMTP id y13mr17447958qtn.512.1640667704787; Mon, 27 Dec 2021 21:01:44 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id j13sm14350529qtr.21.2021.12.27.21.01.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Dec 2021 21:01:44 -0800 (PST) Message-ID: Date: Tue, 28 Dec 2021 00:01:43 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: Eliot Lear , Jay Daley Cc: "rfced-future@iab.org" References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> From: Michael StJohns In-Reply-To: <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 05:01:54 -0000 On 12/23/2021 1:48 AM, Eliot Lear wrote: > Mike, > > For background for all, this text was introduced as part of the > resolution to Issue 104. > > On 23.12.21 00:10, Michael StJohns wrote: >> Selecting an unpaid volunteer via the LLC is possible, but not >> obviously the right thing. > > Can you state why we should revisit this issue, what problem you are > trying to solve with the existing text, and why this responsibility > should shift from the LLC? > > Eliot > > Hi Eliot - Sorry - I missed this when you posted it and only noticed it when John posted. I don't think this is a revisit - or at least I can't find any discussion on the LLC selecting a non-paid RSCE.  I think my assumption was paid, and LLC  was contracting or offering employment, but I think that assumption might not be entirely correct in all cases. I think I covered this in my email response to Jay, but basically: The reason (AFAICT given the all of the discussion not just for 104) the LLC is deeply involved in the selection of the RSCE is because they have to do all the contracting and payment. Contracting obviously (I think) doesn't apply to an unpaid volunteer and hence brings up the question of LLC involvement in the process if an unpaid volunteer is the best fit for a temporary position.  That wasn't discussed during the 104 resolution. If there's a need for a temporary RSCE AND the RSCE will not be paid, then the question is whether leaving this to the LLC is the best thing. The assumptions underlying 104 were all about dealing with temporary vacancies (and were related to other vacancy discussions), not about how such a position might be compensated leading me to ask the question. I think heading somewhat in the direction of both what I wrote (suggesting that the IAB and IESG get a voice at least for a non-paid RSCE) and what John wrote (suggesting that we emphasize a bit more the need for a particular set of expertise in the selection process by the selectors) covers both the paid and non-paid cases. I don't think there needs to be a formal "do this if paid, and do something else if unpaid" model, and I think having the LLC (or the ED) coordinate this still works, but perhaps with some additional input. It's also possible that we write a zero dollar contract with maybe benefits such as paid travel to the IETF, but donated time? Yeah - this is a corner case, but it's one that I grok might (will?) happen and should at least be acknowledged and mapped to the current text. Mike From nobody Tue Dec 28 00:44:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13983A106B; Tue, 28 Dec 2021 00:44:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 8BV9mR8GzsRD; Tue, 28 Dec 2021 00:44:52 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B7DE3A106C; Tue, 28 Dec 2021 00:44:49 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n2869-000Efa-My; Tue, 28 Dec 2021 03:44:45 -0500 Date: Tue, 28 Dec 2021 03:44:40 -0500 From: John C Klensin To: Michael StJohns , Eliot Lear , Jay Daley cc: rfced-future@iab.org Message-ID: In-Reply-To: References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> 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] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:44:58 -0000 --On Tuesday, December 28, 2021 00:01 -0500 Michael StJohns wrote: > On 12/23/2021 1:48 AM, Eliot Lear wrote: >... >> On 23.12.21 00:10, Michael StJohns wrote: >>> Selecting an unpaid volunteer via the LLC is possible, but >>> not obviously the right thing. >>=20 >> Can you state why we should revisit this issue, what problem >> you are trying to solve with the existing text, and why this >> responsibility should shift from the LLC? >... > Hi Eliot - >=20 > Sorry - I missed this when you posted it and only noticed it > when John posted. Mike and Eliot, That is why I have been trying to update subject lines to reflect assorted subthreads. But, if that is not useful to others (and it appears to not be) I will stop it. > I don't think this is a revisit - or at least I can't find any > discussion on the LLC selecting a non-paid RSCE.=C2=A0 I think = my > assumption was paid, and LLC=C2=A0 was contracting or offering > employment, but I think that assumption might not be entirely > correct in all cases. >... =20 > If there's a need for a temporary RSCE AND the RSCE will not > be paid, then the question is whether leaving this to the LLC > is the best thing. >=20 > The assumptions underlying 104 were all about dealing with > temporary vacancies (and were related to other vacancy > discussions), not about how such a position might be > compensated leading me to ask the question. >=20 > I think heading somewhat in the direction of both what I wrote > (suggesting that the IAB and IESG get a voice at least for a > non-paid RSCE) and what John wrote (suggesting that we > emphasize a bit more the need for a particular set of > expertise in the selection process by the selectors) covers > both the paid and non-paid cases. I don't think there needs to > be a formal "do this if paid, and do something else if unpaid" > model, and I think having the LLC (or the ED) coordinate this > still works, but perhaps with some additional input. >=20 > It's also possible that we write a zero dollar contract with > maybe benefits such as paid travel to the IETF, but donated > time? Or waived registration fees, or nothing. =20 There are assorted sayings in the legal profession that the main reason for most contracts is to avoid misunderstandings between parties who are in agreement and acting in good faith, not notions of trying to advantage or enforce one position against another. =20 On that basis, if nothing else, even if the RSCE is going to be completely uncompensated (not even benefits like those mentioned), a formal agreement/ contract that gets mutual expectations written down would probably be worthwhile. I'd expect such a contract might be slightly different from a conventional "we pay you and you do X for the money" contract, but that is probably best left to the LLC and its lawyers. There is also ample precedent in other areas for "one dollar a year" compensation (or, in the IETF's case, maybe "reserved free cookie at meetings") but, again, best left up to the LLC. (If Jay, reading this, is thinking about misunderstandings and problems that could have been avoided with volunteers in the distant past had there been explicit agreements... well, so am I.) > Yeah - this is a corner case, but it's one that I grok might > (will?) happen and should at least be acknowledged and mapped > to the current text. Agreed. But, as you suggest, especially with requirements about the search process similar to what I suggested, the compensated and uncompensated (or paid in cookies) cases may be less different than your original note implied. They would be more different if we were willing to accept a candidate with lower qualifications if that candidate were free (or very inexpensive), but I hope we never go there. Even for compensated people, I'd be very concerned if the LLC were ever to prioritize "low bid" over knowledge and expertise, but, beyond strengthening the search process, I don't see any way to write that principle into the document that would be helpful. best, john From nobody Tue Dec 28 02:24:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BB253A11BD for ; Tue, 28 Dec 2021 02:24:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=WOrBMwxU; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=FDphB7wd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gmi7qaijpQyU for ; Tue, 28 Dec 2021 02:24:21 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55F2C3A11BC for ; Tue, 28 Dec 2021 02:24:21 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 551803200A1E for ; Tue, 28 Dec 2021 05:24:19 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 28 Dec 2021 05:24:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=EjOil3xcHtDmcsY0jnbfOcfuD9s4jud 6XyYQw1ruEwo=; b=WOrBMwxUFfRwDxPcNPZAi6877woQNlxvI7Q8HRtvFyluTC2 QD/9RfT3NKl3ZE1vxBz4kctR2p2Z0+WyF9Vn2QUxGDqNdiujbdWjERNR9z/Z1akX 2yhX4c7GIriX6xvyPfG0jHelRlvXHdukf1i2Oc1ZWTP3AgOBmnzTMB/wCKYvDudl WN87HuCbo9D+0QpD3OK/pWoj7zQWKEnN/CyKuMHcwFyMTDMC9h04kpX02By9mNGX ce6S0Ann54pTePI9mlrlnYYIcFHMhr8QuRYx+6/125gMp18FQHBgJ/gJlDzFZ8xo eOZfQNZ0MT3SXCwEfx4yiFuCv9/ksZCzMRMTjTw== 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=fm1; bh=EjOil3 xcHtDmcsY0jnbfOcfuD9s4jud6XyYQw1ruEwo=; b=FDphB7wdwO/5lsWGkdUDBU gboHurAy81gBC6G7R4RDDnqCm8kYxHo7zaLvfqV44uBmTeqOcG3adHFmG/nQViNh 2VyYqum9CzGpiXnq8W3rxzDmSQXvuAQy1vKpCQ1pCSBeWERul9wq/m9snXX65HGB UK/lUYDQ7hlb+q+agDS3zJovP7Ger2DWwmWeSgEE2dTQCGN9foB7lebatX0NSonE 96qrkNWWdX0vAs8tNQZX2Wz6bx0K7VPaif2lOsgWNzYo/058cSjLvXHpZORwVasC TXMCdnUOUwe6WoPHyqGMhLXhUhBM5T6xR0cvGqIDU3yCyDBaTZJEojo8MyjNkNkA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudduledgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7057D3C00CF; Tue, 28 Dec 2021 05:24:18 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4525-g8883000b21-fm-20211221.001-g8883000b Mime-Version: 1.0 Message-Id: In-Reply-To: <91218bfe-56e8-8e22-7e70-aafe1e7661af@stpeter.im> References: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> <72B98B27-2B99-405A-8219-2C8BB5D5F164@me.com> <91218bfe-56e8-8e22-7e70-aafe1e7661af@stpeter.im> Date: Tue, 28 Dec 2021 21:23:59 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 10:24:27 -0000 On Tue, Dec 28, 2021, at 03:19, Peter Saint-Andre wrote: > If someone can tell me how to cite a BCP in the rfc-kramdown format then > we can avoid these circumlocutions. :-) {{!BCP78}} will work for a normative reference, or {{?BCP78}} for an informative one. From nobody Tue Dec 28 02:25:12 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C65E33A11C7 for ; Tue, 28 Dec 2021 02:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=GxGmWJVy; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=MC9RHG9G Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phDL19zaSsZ0 for ; Tue, 28 Dec 2021 02:25:05 -0800 (PST) Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3F753A11BD for ; Tue, 28 Dec 2021 02:25:05 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 55CFD32009A1 for ; Tue, 28 Dec 2021 05:25:03 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Tue, 28 Dec 2021 05:25:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=bgeFrWuJ88fvowT3TqcK1uUERFlcEcp cibajOEz1Y8Q=; b=GxGmWJVyMgmacAJDDoxV1A3vXEdommJlZkhsBNFa7yj9Ln8 vBYvCSPz9iWoXTN6TSFldyQqjRVGmRtgVC54aZi84kP9X32ECLglGN/Ufg6vGbTS FORdN+CvwKfiAt7usdbam1OptcoYcwVh4QFaEYxpJMgRAvAAJbDq2n4Kb00ADELt MajtmOYrRvqYFf3kwEzQPyyD3EKeOAAiey0kEQ0u+LVpP/Vdmjz8h53RYkCoGEvP kfAtNhuAMzl50Upd85OIl7xlGaCLz10Z3qrjAbWi0HTl7UmUqU4FAwvFypzD4X5w 4FBysfKmoF/foEE8sDCFE20JshbXKP1Kjjpnf7w== 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=fm1; bh=bgeFrW uJ88fvowT3TqcK1uUERFlcEcpcibajOEz1Y8Q=; b=MC9RHG9G5/iFjiiLoCxYXd fPS+VG42tmAtwYeWaUM9mrq06kUQbzvxUV78kzZo+ONRewTSE2ZJzt4Zi55ltFmf tMp9RmALK3YC1Kqev/B8oKZK8ziyjE1KF2AxnbCVu6Hd/JBxwxYm3osXYr8IcTyR JJnw2zt1B84fYZUvzS3fJn+m9lNaVLh0FuQ2Q9Khg38ebSN/nzJmPKPCqMEO9q6T pN0GtMbiMlhs0/v/xSe2vVYlZnnsYRdP9AxKrdt0f6dtcHi56TTPzXqRyBsx1nKV sFgQ7iNOK7vxHEaU5c827kclHQkE4xE11IjA+nAk8O6dsYTkFa01rHzC5n9gL8eg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvuddrudduledgudeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedunecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9EB2D3C00CF; Tue, 28 Dec 2021 05:25:02 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-4525-g8883000b21-fm-20211221.001-g8883000b Mime-Version: 1.0 Message-Id: <5ac6c16d-c25d-4f39-a451-5da4e2263833@beta.fastmail.com> In-Reply-To: <63007F34-87F5-4F69-8D9B-D69946C35546@akamai.com> References: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> <72B98B27-2B99-405A-8219-2C8BB5D5F164@me.com> <91218bfe-56e8-8e22-7e70-aafe1e7661af@stpeter.im> <63007F34-87F5-4F69-8D9B-D69946C35546@akamai.com> Date: Tue, 28 Dec 2021 21:24:44 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 10:25:11 -0000 On Tue, Dec 28, 2021, at 05:57, Salz, Rich wrote: > For example, in the front-matter to 2028bis, I have: > normative: > IANADOCS: BCP26 > And in the text I have > Assignments are coordinated by writing an "IANA Considerations" section > in a draft, as documented in {{IANADOCS}}. You can also do {{!IANADOCS=BCP26}} inline, without the normative section. From nobody Tue Dec 28 08:16:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670BA3A1753; Tue, 28 Dec 2021 08:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0EdIKsq71IfD; Tue, 28 Dec 2021 08:16:14 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 4FB983A1752; Tue, 28 Dec 2021 08:16:11 -0800 (PST) Received: from [192.168.0.229] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BSGG8bS2354037 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 28 Dec 2021 17:16:08 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1640708169; bh=kDPsQsjRL6Lcg4JG6eoqdyYyR+0c+63Oqvavm8CIYPA=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=ezaijdDaGzENvhI+SM7jGiL9jDJZNgpZiM8+Zu5lyu1aL66g4WcY2JTeUms5tYI1S unKzBzwQUNuTaYRtnF+/YzaAf08INOhFNC+3kDOuHcGws8h7jF/RIEBGggs8E0QVrS vzHFam3kx+triMQ5gDjUTATFeZ9B2/IQMBZbbnBA= Message-ID: Date: Tue, 28 Dec 2021 17:16:07 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: John C Klensin , Michael StJohns , Jay Daley Cc: rfced-future@iab.org References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> <5770F1800AC5065CDED8F988@PSB> From: Eliot Lear In-Reply-To: <5770F1800AC5065CDED8F988@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------ta00HDEsWaY4s0SvyFays8bO" Archived-At: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 16:16:20 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------ta00HDEsWaY4s0SvyFays8bO Content-Type: multipart/mixed; boundary="------------595sishqGom0zySwFxyikRrJ"; protected-headers="v1" From: Eliot Lear To: John C Klensin , Michael StJohns , Jay Daley Cc: rfced-future@iab.org Message-ID: Subject: Re: Filling the RSCE position (was: Re: [Rfced-future] Comments on -07) References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> <5770F1800AC5065CDED8F988@PSB> In-Reply-To: <5770F1800AC5065CDED8F988@PSB> --------------595sishqGom0zySwFxyikRrJ Content-Type: multipart/alternative; boundary="------------fLdEwQqBqK0q1uS3uU3OBA97" --------------fLdEwQqBqK0q1uS3uU3OBA97 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgSm9obiwgTWlrZSwgYW5kIG90aGVycy4NCg0KSSBob3BlIHlvdSBhbGwgYXJlIGVuam95 aW5nIHRoZSBob2xpZGF5IHNlYXNvbi7CoCBJIHdhbnQgdG8gbm90ZSB0aGF0IHlvdSANCipE SUQqIHJlcGVhdGVkbHkgcmFpc2UgY29uY2VybiBhYm91dCBleHBlcnRpc2UuIFRoZSBzdWdn ZXN0aW9ucyBiZWxvdyANCmFyZSBhY3Rpb25hYmxlLsKgIEknbSBzdWdnZXN0aW5nIGEgYml0 IG9mIGVkaXRvcmlhbCBjb25zb2xpZGF0aW9uLg0KDQpQbGVhc2Ugc2VlIGJlbG93Lg0KDQpP biAyNy4xMi4yMSAyMToxOCwgSm9obiBDIEtsZW5zaW4gd3JvdGU6DQo+DQo+IEkgc3VnZ2Vz dCAoYXQgbGVhc3QpIHR3byBzbWFsbCBjaGFuZ2VzIHRvIDUuMSB0aGF0IEkgaG9wZSB3aWxs DQo+IG5vdCByZW9wZW4gb3RoZXIgaXNzdWVzOg0KPg0KPiAoMSkgQ2hhbmdlDQo+DQo+IE9M RDoNCj4gCSwgaW5jbHVkaW5nIG1lbWJlcnMgZnJvbSB0aGUgY29tbXVuaXR5LA0KPg0KPiBO RVc6DQo+IAksIGluY2x1ZGluZyBtZW1iZXJzIGZyb20gdGhlIGNvbW11bml0eSBhbmQgcmVw cmVzZW50aW5nDQo+IAlkaXZlcnNlIHBvaW50cyBvZiB2aWV3IGFib3V0IHRoZSBSU0NFIHJv bGUsDQoNCkkgY291bGQgdW5kZXJzdGFuZCB0aGUgImRpdmVyc2UgcG9pbnRzIG9mIHZpZXci IGFzcGVjdC7CoCBJdCdzIGdvb2QgdG8gDQpoZWFyIGZyb20gcGVvcGxlIHdobyB1c2UgdGhl IHNlcnZpY2UgaW4gZGlmZmVyZW50IHdheXMsIGFuZCBldmVuIHBlcmhhcHMgDQpwZW9wbGUg d2hvIGhhdmUgYmVlbiBpbiB0aGUgcHJldmlvdXMgdmVyc2lvbnMgb2YgdGhlIHJvbGUgKGxp a2UgSGVhdGhlciANCmFuZCBKb2huKS4NCg0KQnV0IEkgZG9uJ3QgdW5kZXJzdGFuZCB0aGUg ImFib3V0IHRoZSBSU0NFICpyb2xlKiIgcGFydC4gRmlyc3QsIHRoZSANCnB1cnBvc2Ugb2Yg dGhlIHNlbGVjdGlvbiBjb21taXR0ZWUgaXMgbm90IHRvIGRlYmF0ZSB0aGUgcm9sZSBidXQg dG8gZmluZCANCnF1YWxpZmllZCBjYW5kaWRhdGVzLsKgIFRoZSByb2xlIGlzIGRlZmluZWQg aW4gdGhlIGRvY3VtZW50IGFuZCB0aGUgDQpwcm9jZXNzIHdlIGFyZSBjcmVhdGluZy4NCg0K U2Vjb25kLCBJIGRvbid0IGtub3cgdGhhdCB0aGlzIHdvdWxkIGxlYWQgdG8gdGhlIG91dGNv bWUgeW91IGRlc2lyZS7CoCANCkZvciBpbnN0YW5jZSwgdGhlcmUgYXJlIHNvbWUgcGVvcGxl IHdobyBiZWxpZXZlIHRoYXQgdGhlcmUgc2hvdWxkbid0IGJlIA0Kc3VjaCBhIHJvbGUuwqAg U2hvdWxkIHRoZXkgYmUgaW5jbHVkZWQgaW4gdGhlIHNlbGVjdGlvbiBjb21taXR0ZWU/DQoN CkJ1dCBzZWUgYmVsb3cuDQoNCj4NCj4gKDIpIFByb3ZpZGUgYSBtZWNoYW5pc20gZm9yIFJT QUIgKG9yIFJTV0cgYW5kIFJTQUIpIHJldmlldyBvZg0KPiB0aGUgY29tbWl0dGVlIG1lbWJl cnNoaXAuICBUaGUgZWFzaWVzdCB3YXkgSSBjYW4gc2VlIHRvIGRvIHRoYXQNCj4gd2l0aG91 dCBjcmVhdGluZyBhIGxvdCBvZiBwcm9jZXNzIHdvdWxkIGJlIHRvIGFkZCwgYXMgbmV3IHNl Y29uZA0KPiBhbmQgdGhpcmQgc2VudGVuY2VzIG9mIDUuMSwNCj4NCj4gTkVXOg0KPiAJQSBk cmFmdCBvZiB0aGUgcHJvcG9zZWQgbWVtYmVyc2hpcCBvZiB0aGUgc2VsZWN0aW9uDQo+IAlj b21taXR0ZWUgd2lsbCBiZSBzdWJtaXR0ZWQgdG8gdGhlIFJTQUIgZm9yIHJldmlldy4gIElm DQo+IAl0aGUgUlNBQiAoaW5jbHVkaW5nIHRoZSBvdXRnb2luZyBSU0NFIGlmIGF2YWlsYWJs ZSkNCj4gCWNvbmNsdWRlcyBkb2luZyBzbyB3b3VsZCBiZSBkZXNpcmFibGUsIHRoZXkgbWF5 IG1ha2UNCj4gCXN1Z2dlc3Rpb25zIHRvIHRoZSBMTEMgYWJvdXQgdGhhdCBsaXN0IGFuZC9v ciBwcm9wb3NlDQo+IAlhZGRpdGlvbmFsIG1lbWJlcnMuDQo+DQo+IFRoYXQgY2FuIGJlIG1v ZGlmaWVkIGFzIG5lZWRlZCBpZiB3ZSByZWFsbHkgd2FudCB0aGUgUlNXRw0KPiBpbnZvbHZl ZCwgYnV0IEkgdGhpbmsgdGhhdCB3b3VsZCBqdXN0IGludml0ZSBmb29kIGZpZ2h0cyBhbmQg YQ0KPiByZXByaXNlIG9mIGRlYmF0ZXMgd2UgaG9wZSBhcmUgc2V0dGxlZCBhbmQgd2lsbCBz dGF5IHRoYXQgd2F5Lg0KDQpUaGUgcXVlc3Rpb24gYXQgaGFuZCBpcyByZWFsbHkgdGhpczog ZG8gd2UgdHJ1c3QgdGhlIEVEIHRvIHB1dCB0b2dldGhlciANCmEgc3Ryb25nIHNlbGVjdGlv biBjb21taXR0ZWUgd2l0aG91dCBzdWNoIGEgc3RhdGVtZW50PyBCdXQgSSB0aGluayBib3Ro IA0KY2hhbmdlcyB5b3Ugd2FudCBjb3VsZCBiZSBhY2NvbXBsaXNoZWQgd2l0aCBhIG11Y2gg c2hvcnRlciBjaGFuZ2U6DQoNCk9MRDoNCg0KICAgIFRoZSBJRVRGIExMQyB3aWxsIGZvcm0g YSBzZWxlY3Rpb24gY29tbWl0dGVlLCBpbmNsdWRpbmcgbWVtYmVycyBmcm9tDQogICAgdGhl IGNvbW11bml0eSwgdGhhdCB3aWxsIGJlIHJlc3BvbnNpYmxlIGZvciBtYWtpbmcgYSByZWNv bW1lbmRhdGlvbg0KICAgIHRvIHRoZSBJRVRGIExMQyBmb3IgdGhlIFJTQ0Ugcm9sZS4NCg0K TkVXOg0KDQogICAgKkluIGNvbnN1bHRhdGlvbiB3aXRoIHRoZSBSU0FCKiwgaGUgSUVURiBM TEMgd2lsbCBmb3JtIGEgc2VsZWN0aW9uDQogICAgY29tbWl0dGVlLCBpbmNsdWRpbmcgbWVt YmVycyBmcm9tIHRoZSBjb21tdW5pdHkqd2hvIHJlcHJlc2VudCoqKipkaXZlcnNlIHBlcnNw ZWN0aXZlcyosIHRoYXQgd2lsbCBiZSByZXNwb25zaWJsZQ0KICAgIGZvciBtYWtpbmcgYSBy ZWNvbW1lbmRhdGlvbiB0byB0aGUgSUVURiBMTEMgZm9yIHRoZSBSU0NFIHJvbGUuDQoNClRo b3VnaHRzPw0KDQpFbGlvdA0KDQoNCg== --------------fLdEwQqBqK0q1uS3uU3OBA97 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi John, Mike, and others.

I hope you all are enjoying the holiday season.=C2=A0 I want to no= te that you DID repeatedly raise concern about expertise.=C2=A0= The suggestions below are actionable.=C2=A0 I'm suggesting a bit of= editorial consolidation.

Please see below.

On 27.12.21 21:18, John C Klensin wrote:
<= br> 
I suggest (at least) two sma=
ll changes to 5.1 that I hope will
not reopen other issues:

(1) Change

OLD:
	, including members from the community,

NEW:
	, including members from the community and representing
	diverse points of view about the RSCE role,

I could understand the "diverse points of view" aspect.=C2=A0 It's= good to hear from people who use the service in different ways, and even perhaps people who have been in the previous versions of the role (like Heather and John). =C2=A0

But I don't understand the "about the RSCE role" part.=C2=A0= First, the purpose of the selection committee is not to debate the role but to find qualified candidates.=C2=A0 The role is defined in= the document and the process we are creating.

Second, I don't know that this would lead to the outcome you desire.=C2=A0 For instance, there are some people who believe that there shouldn't be such a role.=C2=A0 Should they be included in th= e selection committee?

But see below.


(2) Provide a mechanism for RSAB (or RSWG and RSAB) review of
the committee membership.  The easiest way I can see to do that
without creating a lot of process would be to add, as new second
and third sentences of 5.1,=20

NEW:
	A draft of the proposed membership of the selection
	committee will be submitted to the RSAB for review.  If
	the RSAB (including the outgoing RSCE if available)
	concludes doing so would be desirable, they may make
	suggestions to the LLC about that list and/or propose
	additional members.

That can be modified as needed if we really want the RSWG
involved, but I think that would just invite food fights and a
reprise of debates we hope are settled and will stay that way.

The question at hand is really this: do we trust the ED to put together a strong selection committee without such a statement?=C2=A0= But I think both changes you want could be accomplished with a much shorter change:

OLD:

   The IETF LLC will form a selection committe=
e, including members from
   the community, that will be responsible for making a recommendation
   to the IETF LLC for the RSCE role.

NEW:

   In consultation with the RSAB, he IETF LLC will form a selectio=
n
   committee, including members from the community who represent
   diverse perspectives, that will be responsible
   for making a recommendation to the IETF LLC for the RSCE role.

Thoughts?

Eliot


--------------fLdEwQqBqK0q1uS3uU3OBA97-- --------------595sishqGom0zySwFxyikRrJ-- --------------ta00HDEsWaY4s0SvyFays8bO Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmHLOEcFAwAAAAAACgkQh7ZrRtnSejOX VAgAsH7hmdUdTVRV+vOdsct7w/qTw/fj/bxHhV/BHIw9Qwtgdcb0GcC5Qa51lreIF4g5AvX+HW+4 EGrEDP5BJdUAuEu8/ECWmfiEhwFgmclLnTJdbG22oh/K/SvOgUhoVVALQy0xRmWVrZRo/dtpewoI GZubQTermWkuaUEVxJRWRC4c09rhi7jbM2Rxr1JE0Bbo9vwP8x828rwMIc9l8hgOVjFfhFhDXGk0 Bu4Y1wUDCYQevy8RErWjzrKTtS5CCTa/lN10xGihJnQO5WXo9o1AS7U9HGptXh1xs7mfE27D/tiz CVKIdhSJcySExIL7p7+Uljo7RxNoyyahPIhiR5PBsA== =6cU7 -----END PGP SIGNATURE----- --------------ta00HDEsWaY4s0SvyFays8bO-- From nobody Tue Dec 28 10:14:37 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 932713A183A for ; Tue, 28 Dec 2021 10:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 piJ5V2egx7rg for ; Tue, 28 Dec 2021 10:14:30 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E1E3A1838 for ; Tue, 28 Dec 2021 10:14:30 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id e128so23528914iof.1 for ; Tue, 28 Dec 2021 10:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bKQvblTUL8azRby2O0YNbOQZLxmRi9hcF5htBCN22i8=; b=MeHfGEUK5TlCn//3EXfbaQBSgbJ76dbIi03KcibkRjb+wbvgxiL4WiovPEJrADymjk AeZMRM7kai4ihYYWBlSDpPr6bJ+TghlvhL/9MsZsnrcTjp3Wrm0inu/+WJ4eQghpdeR1 tGuhdpUbWYlIGcxCUQ/mTIFFQfC3EHn3hmEvJS1a6CPYdylJkq/RFWLXthNBOxGpby7N KRbkW/jgTessBBYcUgN28LnYjWnNpej8a77Eo6HwD8Rwz+GsCfGLouZsTSrUo88B6r5m Si47Ru6SWs5H4ksZF0Nm3neI0MPArOahWG8rw1K2x6Wn3FGsn1UdJYb0C5eCmYDJryWg kN5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bKQvblTUL8azRby2O0YNbOQZLxmRi9hcF5htBCN22i8=; b=p9BLdmAku6QldGdbD8mO+Cgm9DnPEPp5mX+mVxPDD5zeiwnHQITufBDXwvpD+JKvY1 IG141W4Fyjjnvuk/LCH9X0R36krFIjo1V0SdqYZoRDbP+4PKT1Y2dSl+GrdIlEVpMgbQ fmXKmjPn0LOk+BfKRb+F9BhMqaoKy5R1uQvcKyklQH6Sf4FF5QmtpjSuuSUg357OZqfN IokHI/lpkKYEOGApsibtvPQ6My1frB7fNtFD9VGg/WjOeI2W2gOy4k9oCYbSS2P4VOWs H52bR9ghtKp4eNIxOM9SnrApNIsKp/nDli9yq2nbvLx1CJOhQWzQEFKfBBkXyuM4BM+k WJZA== X-Gm-Message-State: AOAM531NRZenrngyMO0a4UUDJRSvnac1x4/h1k0p7OR+v6iWWqpdXkJj uGaNk5knuJYAzDldymULZ96gB+8sxMvGwi9cnBtoiQ== X-Google-Smtp-Source: ABdhPJwYmdFW8CMlwZGvxw1nJnMHrPJ2/e+1lTfKZAhrQeD+oZhHFuToGpYlK0WKu6P5aMFZUcpNLpO7XJezLIFiWbo= X-Received: by 2002:a05:6638:10ed:: with SMTP id g13mr7412183jae.308.1640715268901; Tue, 28 Dec 2021 10:14:28 -0800 (PST) MIME-Version: 1.0 References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> <5770F1800AC5065CDED8F988@PSB> In-Reply-To: From: Eric Rescorla Date: Tue, 28 Dec 2021 10:13:53 -0800 Message-ID: To: Eliot Lear Cc: John C Klensin , Michael StJohns , Jay Daley , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000c7e29205d438ca74" Archived-At: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 18:14:36 -0000 --000000000000c7e29205d438ca74 Content-Type: text/plain; charset="UTF-8" On Tue, Dec 28, 2021 at 8:16 AM Eliot Lear wrote: > Hi John, Mike, and others. > > I hope you all are enjoying the holiday season. I want to note that you > *DID* repeatedly raise concern about expertise. The suggestions below > are actionable. I'm suggesting a bit of editorial consolidation. > > Please see below. > On 27.12.21 21:18, John C Klensin wrote: > > > I suggest (at least) two small changes to 5.1 that I hope will > not reopen other issues: > > (1) Change > > OLD: > , including members from the community, > > NEW: > , including members from the community and representing > diverse points of view about the RSCE role, > > I could understand the "diverse points of view" aspect. It's good to hear > from people who use the service in different ways, and even perhaps people > who have been in the previous versions of the role (like Heather and John). > > > But I don't understand the "about the RSCE *role*" part. First, the > purpose of the selection committee is not to debate the role but to find > qualified candidates. The role is defined in the document and the process > we are creating. > > Second, I don't know that this would lead to the outcome you desire. For > instance, there are some people who believe that there shouldn't be such a > role. Should they be included in the selection committee? > > But see below. > > (2) Provide a mechanism for RSAB (or RSWG and RSAB) review of > the committee membership. The easiest way I can see to do that > without creating a lot of process would be to add, as new second > and third sentences of 5.1, > > NEW: > A draft of the proposed membership of the selection > committee will be submitted to the RSAB for review. If > the RSAB (including the outgoing RSCE if available) > concludes doing so would be desirable, they may make > suggestions to the LLC about that list and/or propose > additional members. > > That can be modified as needed if we really want the RSWG > involved, but I think that would just invite food fights and a > reprise of debates we hope are settled and will stay that way. > > The question at hand is really this: do we trust the ED to put together a > strong selection committee without such a statement? But I think both > changes you want could be accomplished with a much shorter change: > > OLD: > > The IETF LLC will form a selection committee, including members from > the community, that will be responsible for making a recommendation > to the IETF LLC for the RSCE role. > > NEW: > > *In consultation with the RSAB*, he IETF LLC will form a selection > > Nit: "the IETF LLC" > committee, including members from the community *who represent** diverse perspectives*, that will be responsible > for making a recommendation to the IETF LLC for the RSCE role. > > Thoughts? > I agree that diverse perspectives seem good, but this (and Jon's proposed text) seems more aspirational than like requirements text. How would one evaluate whether the LLC had conformed with this? Maybe that's OK, but I would lean towards not including it. -Ekr Eliot > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000c7e29205d438ca74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Dec 28, 2021 at 8:16 AM Eliot= Lear <lear@lear.ch> wrote:
=20 =20 =20

Hi John, Mike, and others.

I hope you all are enjoying the holiday season.=C2=A0 I want to note that you DID repeatedly raise concern about expertise.=C2=A0 The suggestions below are actionable.=C2=A0 I'm suggesting a bit = of editorial consolidation.

Please see below.

On 27.12.21 21:18, John C Klensin wrote:

I suggest (at least) two small changes to 5.1 that I hope will
not reopen other issues:

(1) Change

OLD:
	, including members from the community,

NEW:
	, including members from the community and representing
	diverse points of view about the RSCE role,

I could understand the "diverse points of view" aspect.=C2= =A0 It's good to hear from people who use the service in different ways, and even perhaps people who have been in the previous versions of the role (like Heather and John). =C2=A0

But I don't understand the "about the RSCE role"= ; part.=C2=A0 First, the purpose of the selection committee is not to debate the role but to find qualified candidates.=C2=A0 The role is defined in t= he document and the process we are creating.

Second, I don't know that this would lead to the outcome you desire.=C2=A0 For instance, there are some people who believe that there shouldn't be such a role.=C2=A0 Should they be included in = the selection committee?

But see below.

(2) Provide a mechanism for RSAB (or RSWG and RSAB) review of
the committee membership.  The easiest way I can see to do that
without creating a lot of process would be to add, as new second
and third sentences of 5.1,=20

NEW:
	A draft of the proposed membership of the selection
	committee will be submitted to the RSAB for review.  If
	the RSAB (including the outgoing RSCE if available)
	concludes doing so would be desirable, they may make
	suggestions to the LLC about that list and/or propose
	additional members.

That can be modified as needed if we really want the RSWG
involved, but I think that would just invite food fights and a
reprise of debates we hope are settled and will stay that way.

The question at hand is really this: do we trust the ED to put together a strong selection committee without such a statement?=C2=A0 But I think both changes you want could be accomplished with a much shorter change:

OLD:

   The IETF LLC will form a selection committee, including members=
 from
   the community, that will be responsible for making a recommendation
   to the IETF LLC for the RSCE role.

NEW:

   In consultation with the RSAB, he IETF LLC will form a s=
election
Nit: "the IETF LLC" 
   committee=
, including members from the community who represent
   diverse perspectives, that will be responsible
   for making a recommendation to the IETF LLC for the RSCE role.

Thoughts?

I agree that diverse perspectiv= es seem good, but this (and Jon's proposed text)
seems more a= spirational than like requirements text. How would one evaluate
w= hether the LLC had conformed with this? Maybe that's OK, but I would le= an
towards not including it.

--000000000000c7e29205d438ca74-- From nobody Tue Dec 28 12:03:15 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 942A13A1926 for ; Tue, 28 Dec 2021 12:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-1.852, 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.20210112.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 eQiyeEY5WC7t for ; Tue, 28 Dec 2021 12:03:09 -0800 (PST) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F2B3A1925 for ; Tue, 28 Dec 2021 12:03:08 -0800 (PST) Received: by mail-qk1-x731.google.com with SMTP id f138so18067559qke.10 for ; Tue, 28 Dec 2021 12:03:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=T8AkMxMTBdKI/cCfRArkiH1FUIKDKHgLd5yUZKUIQQo=; b=eats/T1uHfwjsOwzUO9M29dJcu7ctNtjwEndveEg89IOyhTIu+q51407fngxjY6CBf A6heLrZ7nzRqfp1/Az/neXqTkevwMcBudXrb4MlCuXhJoyBfA2ePPwZhAC6QGnZJzO4M xLxjxI8rHgcn6NSDpddPgL7YCIf9Jr8HCSYd1rnX7KqrYD4IlOv14ps6x5NqI0bmN1qm OcVxR3yxu3U0aG1k4MOK/G3XeFt8uEMnBRPkQAri8ObgkkHWnLwh39uAPKgZ8aQULKPG TJSv9iGQn5F9did7ps4uwArj/F6ecfSKhn4+oTHHJonlWClzDI5ql9rMsPieEqA/p2Hw KI+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=T8AkMxMTBdKI/cCfRArkiH1FUIKDKHgLd5yUZKUIQQo=; b=bNpsRhKCFLH3wJ3n+DgTYppqGz82hNbAPF7xYXhSDSjtoGHnVQBpPCQgDL54b3YZzq P+La4x81G72sKO+10Tocr6Ll6jG/aLmFSKkr3+EWeRZJ1UOnKHKaaKt3VCIhGgljm9Ra XImv9YrcjHfXlRyjQZcn2FKxy2MPiVIdUfUVWZVjOQQsmtM5REjwdBBH7Zm0mP+D0F8U Q4RasggtptrXh89sX1Dj3vUWu6n30QBfTq1dNL+UaCHIhpLQbm8tcwQlMASTXR3e9Rpz yeMeG2Q9Q38s5q9OYFNknnQYKDm6lT6sIWYLCjzfUGI8MuIwul+X1GWW5bvVTHoXNJcf OAhQ== X-Gm-Message-State: AOAM530bkHpl03s6N8WcF0+sCLiilS6FVIhn36z/SoE9fdr7bILyjNXJ yo//1DbvEIeIBm+wW7CkBxZnrQ== X-Google-Smtp-Source: ABdhPJzQoZytI8ZEWpK7B12f1Ff0cD9S9QcMjEaW2VcKdPKO0A9JRCrZC0Oh6kjCSL7ENYU0boRbEQ== X-Received: by 2002:a05:620a:4003:: with SMTP id h3mr15940729qko.225.1640721784083; Tue, 28 Dec 2021 12:03:04 -0800 (PST) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id c25sm16532048qkp.31.2021.12.28.12.03.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 28 Dec 2021 12:03:03 -0800 (PST) Message-ID: <8488ed56-2269-4d6f-e124-7abbbd1af29b@nthpermutation.com> Date: Tue, 28 Dec 2021 15:03:01 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Ole Jacobsen Cc: rfced-future@iab.org References: <2ee9e06e-4317-05a7-ece4-bec7e9ae19de@it.aoyama.ac.jp> <72B98B27-2B99-405A-8219-2C8BB5D5F164@me.com> From: Michael StJohns In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Comments on -07 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:03:14 -0000 On 12/27/2021 12:05 AM, Martin J. Dürst wrote: > On 2021-12-27 13:51, Ole Jacobsen wrote: >> I think you mean: >> >> "BCP78 (currently RFC5378) or it successor" -> >> "BCP78 (currently RFC5378, or its successor)" >> >> its instead of it > > Yes, of course. Thanks a lot, Ole! > > Regards,   Martin. It probably should be: "BCP78 (i.e., RFC5738 or its successor)" But that's just wordsmithing! Mike > >> >> Ole J. Jacobsen >> Editor & Publisher >> The Internet Protocol Journal >> Office: +1 415 550-9433 >> Cell: +1 415 370-4628 >> T-Mobile: +1 415 889-9821 >> Docomo: +81 90 3337 9311‬ >> http://protocoljournal.org >> >> Sent from my iPhone >> >>> On 26 Dec 2021, at 20:48, Martin J. Dürst >>> wrote: >>> >>> Just one nit below. >> From nobody Tue Dec 28 12:04:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A0E53A1929; Tue, 28 Dec 2021 12:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mspEvu7O5Re1; Tue, 28 Dec 2021 12:04:23 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9383A1926; Tue, 28 Dec 2021 12:04:19 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n2Ihk-000FgT-6M; Tue, 28 Dec 2021 15:04:16 -0500 Date: Tue, 28 Dec 2021 15:04:10 -0500 From: John C Klensin To: Eliot Lear , Michael StJohns , Jay Daley cc: rfced-future@iab.org Message-ID: <65DF6A48DE82D1A1A9925FE0@PSB> In-Reply-To: References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> <5770F1800AC5065CDED8F988@PSB> 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] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 20:04:28 -0000 --On Tuesday, December 28, 2021 17:16 +0100 Eliot Lear wrote: > Hi John, Mike, and others. >=20 > I hope you all are enjoying the holiday season.=C2=A0 I want = to > note that you *DID* repeatedly raise concern about expertise. > The suggestions below are actionable.=C2=A0 I'm suggesting a = bit > of editorial consolidation. Eliot, I raised several questions about expertise in the RSCE position itself but, as far as I can remember, not about the composition of the selection committee... although I did certainly raise some issues about the Section 5 selection model, at least one of which, IIR, was what led to Jay's posting his "de facto" list. IMO, not worth the time it would take to go back and precisely figure that out. I apologize but I'm going to need to review history as I see it and this note is going to be long. > Please see below. >=20 > On 27.12.21 21:18, John C Klensin wrote: >>=20 >> I suggest (at least) two small changes to 5.1 that I hope = will >> not reopen other issues: >>=20 >> (1) Change >>=20 >> OLD: >> , including members from the community, >>=20 >> NEW: >> , including members from the community and representing >> diverse points of view about the RSCE role, >=20 > I could understand the "diverse points of view" aspect.=C2=A0 = It's > good to hear from people who use the service in different > ways, and even perhaps people who have been in the previous > versions of the role (like Heather and John). >=20 > But I don't understand the "about the RSCE *role*" part. > First, the purpose of the selection committee is not to debate > the role but to find qualified candidates.=C2=A0 The role is > defined in the document and the process we are creating. We have made several decisions (not necessarily about this part of the document and, IIR, a few at your urging) to deal with issues about which we could not easily reach general agreement by use of vague language and assuming the RSWG/RSAB could and would sort things out later if and when needed. The recent discussion about "principles" is an excellent example: while I didn't completely agree with Mike's initial list, I agreed with the general idea (principle?) he was asking for. I assume that, had the discussion been only about that idea among those who believed a clear boundary-setting statement would be desirable, we probably could have gotten to a consensus list. However, others didn't (at least AFAICT) like the idea at all and so we ended up with the current Section 7, which involves much more handwaving and leaving of decisions for the future than I assumed we were heading for when I read Mike's first note on the subject. Probably that is a good outcome. Not specifying exactly what we mean by "heightened scrutiny" and pushing those details off for the future is almost certainly right (and I even suggested some of the text that led to part of the current version of Section 3.2.3), but, when we say what the second paragraph of that section says, we should recognize that it represents a compromise and "kicking can down the road" decision relative to either rigid and very hard-to-change boundaries or leaving everything in the hands of the RSWG/RSAB without any guidance or boundaries. Now, from my point of view at least (and YMMD) the current Section 5 (supplemented by the differentiating language of Section 8.2) are just such a "kicking can down the road" exercise. Section 5 describes the responsibilities of the role and example topics on which the RSCE might be called upon to provide guidance but it nowhere provides any guidance other than "senior technical publishing professional..." about the qualifications for that role. Instead, Section 5.1 pushes the job off onto the LLC and the LLC-appointed selection committee, "tak[ing] into account the definition of the role..." -- a definition Section 3.2.3 and the first part of Section 5 actually do not provide. I bear some of the responsibility for that: when you challenged me to define what I meant by "expertise" in a way that could go into the document, I gave up because that is hard but, equally important, because I concluded that any definition I could produce would be controversial and then would be compromised about and watered down to the point of uselessness (nearly the same reason I gave up on "archival"). I'm ok (although not enthused) with the current text but it means that, inevitably, the selection committee and the LLC will be filling in the many blanks we have left about the definition of the role, possibly even making dynamic adjustments when a highly qualified search firm starts asking questions or even when faced with highly qualified candidates who were very different from each other (would not be the first time for the latter). =20 When Heather was selected, there was broad consensus inside the selection process about the nature of the RSE role (not just a list of things the RSE would do) and most of the qualifications for it, even though a large portion of that consensus was unspoken and derived from a long, mostly oral, tradition. I see no such consensus about the definition of the RSCE role, only the "what that person might do or be asked to do" material. > Second, I don't know that this would lead to the outcome you > desire.=C2=A0 For instance, there are some people who believe = that > there shouldn't be such a role.=C2=A0 Should they be included = in > the selection committee? More or less "yes". But note, before we get to the part below that, if we say nothing, we also don't exclude those people from the selection committee (although me might hope and expect the LLC would be sensible -- more on that below too). If we are going to kick this down the road for reevaluation during the selection process, then we should not cut off points of view at or near at either extreme unless we are prepared to define things much more precisely -- which I don't think we are. > But see below. >=20 >>=20 >> (2) Provide a mechanism for RSAB (or RSWG and RSAB) review of >> the committee membership. The easiest way I can see to do >> that without creating a lot of process would be to add, as >> new second and third sentences of 5.1, >>=20 >> NEW: >> A draft of the proposed membership of the selection >> committee will be submitted to the RSAB for review. If >> the RSAB (including the outgoing RSCE if available) >> concludes doing so would be desirable, they may make >> suggestions to the LLC about that list and/or propose >> additional members. >>=20 >> That can be modified as needed if we really want the RSWG >> involved, but I think that would just invite food fights and = a >> reprise of debates we hope are settled and will stay that = way. >=20 > The question at hand is really this: do we trust the ED to put > together a strong selection committee without such a > statement? I don't think it is. More important, I find turning this into a "do we trust the ED?" question really objectionable: either a "yes" or "no" answer turns into a battle between Jay's defenders and those who dislike him or his style. That leads nowhere other than getting people angry at each other and losing sight of the substantive issues. I will tell you that I trust Jay far more than a hypothetical future ED whose properties and style we cannot guess at other than to expect that they will not have benefited from watching these discussions in real time. Instead, this is about whether it is desirable to put the job of defining the qualifications for the RSCE role (all of the bits that the document does not specify as well as those that it does) entirely into the hands of the LLC or to be sure that the community -- especially as represented by the cast of characters who make up the RSAB -- can have visibility into and help to insure the balance of that selection committee and hence the (necessarily evolving) definition job. =20 So, yes, I think the current ED (and LLC more generally) would do the best job of which they are capable in putting the selection committee together. I have intentionally not suggested changing their having the last word on the matter and would do so if I thought it were necessary to protect against malicious behavior on their part. But I don't think they are omniscient and I think it is entirely possible that they do not fully understand all of the perspectives in these discussions (I am not confident that anyone completely does and some of us have a lot more years of experience and perspective on the issues than the ED or anyone on the LLC Board or staff). And so I'd like a check on a proposed selection committee so that, if it occurs that some important perspective has been omitted, the RSAB can say "you seem to have missed perspective X, which might be useful; how about you consider adding Bob or someone else who can be articulate about it?". Frankly, I prefer making it a bit hard for the LLC to ignore than recommendation even though I think trying to prohibit them from doing so would be a terrible idea. =20 Yes, I am setting up the selection committee to have a food fight but I see that as a better choice than either of the other two options. =20 And, if the LLC, with the advice of the RSAB, wants to put someone on the selection committee who thinks that having an RSCE is completely unnecessary and perhaps would like to select someone who would be ineffectual in the role, I think they should go for it. Should they, accidentally or intentionally, propose a selection committee full of those people (which would astonish me), I'd assume the RSAB would put back. But I would have no problem with one such person as long as the LLC picks someone who, in addition to having those views, is able and willing to work constructively with others to reach a consensus conclusion, one that is informed by what the document has to say about the role. And I trust them to get that right, both because I think they are more than capable of doing so and because I don't see other plausible choices. > But I think both changes you want could be > accomplished with a much shorter change: >=20 > OLD: >=20 > The IETF LLC will form a selection committee, including > members from > the community, that will be responsible for making a > recommendation > to the IETF LLC for the RSCE role. >=20 > NEW: >=20 > *In consultation with the RSAB*, he IETF LLC will form a > selection > committee, including members from the community*who > represent****diverse perspectives*, that will be responsible > for making a recommendation to the IETF LLC for the RSCE > role. >=20 > Thoughts? Well... (i) Better than leaving the text unchanged. (ii) This may go back to your "who do you trust" question, but I think this lowers the responsibility and authority of the LLC and don't consider that a good idea. What I am picturing is the LLC tentatively picking a slate/ committee and then handing it to the RSAB for comment and advice. My expectation is that, if the LLC does a good job (and/or gets lucky), the RSAB will collectively nod approvingly and that will be the end of it. "In consultation with" implies much more of a group decision, one that, if carried out in what seems to have become the IETF way, could easily evolve (unless we explicitly prohibit it) into public calls for candidates, community comments, etc. I don't want to see anything resembling a popularity contest for selection committee members. Equally or more important, I see selection committee membership as not being a particularly fun job and expect that some people who might be among the best candidates would have to be aggressively persuaded to take it on. I think we are much better off with something lots closer to what now appears to be in the draft: the LLC picks a collection of people whom they think would be good at/for the job but, instead of simply making and announcing that decision (or launching a "community consultation"), reviews that decision with the RSAB to ensure that perspectives they (the LLC) might not have captured (or that are overrepresented) get identified and, if appropriate, represented or the proposed membership adjusted. And I am happy to leave it entirely up to the LLC to decide how their initial list of people are identified (although I would personally recommend against a public call for volunteers) and, if arm-twisting is needed, when in the process that is done and by whom. In particular, if the LLC comes to the RSAB with a list of people who have not yet been asked or agreed to serve, I'm fine with that even if it leads to an extra iteration -- up to the LLC. best, john From nobody Tue Dec 28 18:06:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3A83A0A52 for ; Tue, 28 Dec 2021 18:06:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DyG9aq4Kkv_I for ; Tue, 28 Dec 2021 18:06:28 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69CA53A0A50 for ; Tue, 28 Dec 2021 18:06:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 2CD6A411363A; Tue, 28 Dec 2021 18:06:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aug5I34uwJfv; Tue, 28 Dec 2021 18:06:28 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id E7CAC404BFAE; Tue, 28 Dec 2021 18:06:27 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Wed, 29 Dec 2021 15:06:23 +1300 Message-Id: References: <65DF6A48DE82D1A1A9925FE0@PSB> Cc: Eliot Lear , Michael StJohns , rfced-future@iab.org In-Reply-To: <65DF6A48DE82D1A1A9925FE0@PSB> To: John C Klensin X-Mailer: iPhone Mail (19B74) Archived-At: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 02:06:34 -0000 Briefly, this has become one or two orders of magnitude more complex than is= required for this role (remembering that the role as written is very differ= ent from the previous role). The overriding priority for committee members s= hould be that they understand this new role and will therefore find someone w= ho fits this role rather than the previous role. I=E2=80=99ve regularly pus= hed back on having ex-officio appointments to the selection committee becaus= e, from what I=E2=80=99ve seen so far, the number of people who properly und= erstand this new role is actually quite limited in number. Picking a random I= AB/IESG person who isn=E2=80=99t one of those means the committee has to wor= k much harder to bring them to speed.=20 I fully understand the depth of trauma some felt about the previous role and= that the scars are still fresh, but this is a very different role and we do= n=E2=80=99t need to overthink it.=20 Jay --=20 Jay Daley=20 IETF Executive Director exec-director@ietf.org > On 29/12/2021, at 9:04 AM, John C Klensin wrote: >=20 > =EF=BB=BF >=20 > --On Tuesday, December 28, 2021 17:16 +0100 Eliot Lear > wrote: >=20 >> Hi John, Mike, and others. >>=20 >> I hope you all are enjoying the holiday season. I want to >> note that you *DID* repeatedly raise concern about expertise. >> The suggestions below are actionable. I'm suggesting a bit >> of editorial consolidation. >=20 > Eliot, >=20 > I raised several questions about expertise in the RSCE position > itself but, as far as I can remember, not about the composition > of the selection committee... although I did certainly raise > some issues about the Section 5 selection model, at least one of > which, IIR, was what led to Jay's posting his "de facto" list. > IMO, not worth the time it would take to go back and precisely > figure that out. >=20 > I apologize but I'm going to need to review history as I see it > and this note is going to be long. >=20 >> Please see below. >>=20 >>> On 27.12.21 21:18, John C Klensin wrote: >>>=20 >>> I suggest (at least) two small changes to 5.1 that I hope will >>> not reopen other issues: >>>=20 >>> (1) Change >>>=20 >>> OLD: >>> , including members from the community, >>>=20 >>> NEW: >>> , including members from the community and representing >>> diverse points of view about the RSCE role, >>=20 >> I could understand the "diverse points of view" aspect. It's >> good to hear from people who use the service in different >> ways, and even perhaps people who have been in the previous >> versions of the role (like Heather and John). >>=20 >> But I don't understand the "about the RSCE *role*" part. >> First, the purpose of the selection committee is not to debate >> the role but to find qualified candidates. The role is >> defined in the document and the process we are creating. >=20 > We have made several decisions (not necessarily about this part > of the document and, IIR, a few at your urging) to deal with > issues about which we could not easily reach general agreement > by use of vague language and assuming the RSWG/RSAB could and > would sort things out later if and when needed. The recent > discussion about "principles" is an excellent example: while I > didn't completely agree with Mike's initial list, I agreed with > the general idea (principle?) he was asking for. I assume that, > had the discussion been only about that idea among those who > believed a clear boundary-setting statement would be desirable, > we probably could have gotten to a consensus list. However, > others didn't (at least AFAICT) like the idea at all and so we > ended up with the current Section 7, which involves much more > handwaving and leaving of decisions for the future than I > assumed we were heading for when I read Mike's first note on the > subject. Probably that is a good outcome. Not specifying > exactly what we mean by "heightened scrutiny" and pushing those > details off for the future is almost certainly right (and I even > suggested some of the text that led to part of the current > version of Section 3.2.3), but, when we say what the second > paragraph of that section says, we should recognize that it > represents a compromise and "kicking can down the road" > decision relative to either rigid and very hard-to-change > boundaries or leaving everything in the hands of the RSWG/RSAB > without any guidance or boundaries. >=20 > Now, from my point of view at least (and YMMD) the current > Section 5 (supplemented by the differentiating language of > Section 8.2) are just such a "kicking can down the road" > exercise. Section 5 describes the responsibilities of the role > and example topics on which the RSCE might be called upon to > provide guidance but it nowhere provides any guidance other than > "senior technical publishing professional..." about the > qualifications for that role. Instead, Section 5.1 pushes the > job off onto the LLC and the LLC-appointed selection committee, > "tak[ing] into account the definition of the role..." -- a > definition Section 3.2.3 and the first part of Section 5 > actually do not provide. I bear some of the responsibility for > that: when you challenged me to define what I meant by > "expertise" in a way that could go into the document, I gave up > because that is hard but, equally important, because I concluded > that any definition I could produce would be controversial and > then would be compromised about and watered down to the point of > uselessness (nearly the same reason I gave up on "archival"). > I'm ok (although not enthused) with the current text but it > means that, inevitably, the selection committee and the LLC will > be filling in the many blanks we have left about the definition > of the role, possibly even making dynamic adjustments when a > highly qualified search firm starts asking questions or even > when faced with highly qualified candidates who were very > different from each other (would not be the first time for the > latter). =20 >=20 > When Heather was selected, there was broad consensus inside the > selection process about the nature of the RSE role (not just a > list of things the RSE would do) and most of the qualifications > for it, even though a large portion of that consensus was > unspoken and derived from a long, mostly oral, tradition. I see > no such consensus about the definition of the RSCE role, only > the "what that person might do or be asked to do" material. >=20 >> Second, I don't know that this would lead to the outcome you >> desire. For instance, there are some people who believe that >> there shouldn't be such a role. Should they be included in >> the selection committee? >=20 > More or less "yes". But note, before we get to the part below > that, if we say nothing, we also don't exclude those people from > the selection committee (although me might hope and expect the > LLC would be sensible -- more on that below too). If we are > going to kick this down the road for reevaluation during the > selection process, then we should not cut off points of view at > or near at either extreme unless we are prepared to define > things much more precisely -- which I don't think we are. >=20 >> But see below. >>=20 >>>=20 >>> (2) Provide a mechanism for RSAB (or RSWG and RSAB) review of >>> the committee membership. The easiest way I can see to do >>> that without creating a lot of process would be to add, as >>> new second and third sentences of 5.1, >>>=20 >>> NEW: >>> A draft of the proposed membership of the selection >>> committee will be submitted to the RSAB for review. If >>> the RSAB (including the outgoing RSCE if available) >>> concludes doing so would be desirable, they may make >>> suggestions to the LLC about that list and/or propose >>> additional members. >>>=20 >>> That can be modified as needed if we really want the RSWG >>> involved, but I think that would just invite food fights and a >>> reprise of debates we hope are settled and will stay that way. >>=20 >> The question at hand is really this: do we trust the ED to put >> together a strong selection committee without such a >> statement? >=20 > I don't think it is. More important, I find turning this into a > "do we trust the ED?" question really objectionable: either a > "yes" or "no" answer turns into a battle between Jay's defenders > and those who dislike him or his style. That leads nowhere > other than getting people angry at each other and losing sight > of the substantive issues. I will tell you that I trust Jay far > more than a hypothetical future ED whose properties and style we > cannot guess at other than to expect that they will not have > benefited from watching these discussions in real time. > Instead, this is about whether it is desirable to put the job of > defining the qualifications for the RSCE role (all of the bits > that the document does not specify as well as those that it > does) entirely into the hands of the LLC or to be sure that the > community -- especially as represented by the cast of characters > who make up the RSAB -- can have visibility into and help to > insure the balance of that selection committee and hence the > (necessarily evolving) definition job. =20 >=20 > So, yes, I think the current ED (and LLC more generally) would > do the best job of which they are capable in putting the > selection committee together. I have intentionally not > suggested changing their having the last word on the matter and > would do so if I thought it were necessary to protect against > malicious behavior on their part. But I don't think they are > omniscient and I think it is entirely possible that they do not > fully understand all of the perspectives in these discussions (I > am not confident that anyone completely does and some of us have > a lot more years of experience and perspective on the issues > than the ED or anyone on the LLC Board or staff). And so I'd > like a check on a proposed selection committee so that, if it > occurs that some important perspective has been omitted, the > RSAB can say "you seem to have missed perspective X, which might > be useful; how about you consider adding Bob or someone else who > can be articulate about it?". Frankly, I prefer making it a bit > hard for the LLC to ignore than recommendation even though I > think trying to prohibit them from doing so would be a terrible > idea. =20 >=20 > Yes, I am setting up the selection committee to have a food > fight but I see that as a better choice than either of the other > two options. =20 >=20 > And, if the LLC, with the advice of the RSAB, wants to put > someone on the selection committee who thinks that having an > RSCE is completely unnecessary and perhaps would like to select > someone who would be ineffectual in the role, I think they > should go for it. Should they, accidentally or intentionally, > propose a selection committee full of those people (which would > astonish me), I'd assume the RSAB would put back. But I would > have no problem with one such person as long as the LLC picks > someone who, in addition to having those views, is able and > willing to work constructively with others to reach a consensus > conclusion, one that is informed by what the document has to say > about the role. And I trust them to get that right, both > because I think they are more than capable of doing so and > because I don't see other plausible choices. >=20 >> But I think both changes you want could be >> accomplished with a much shorter change: >>=20 >> OLD: >>=20 >> The IETF LLC will form a selection committee, including >> members from >> the community, that will be responsible for making a >> recommendation >> to the IETF LLC for the RSCE role. >>=20 >> NEW: >>=20 >> *In consultation with the RSAB*, he IETF LLC will form a >> selection >> committee, including members from the community*who >> represent****diverse perspectives*, that will be responsible >> for making a recommendation to the IETF LLC for the RSCE >> role. >>=20 >> Thoughts? >=20 > Well... >=20 > (i) Better than leaving the text unchanged. >=20 > (ii) This may go back to your "who do you trust" question, but I > think this lowers the responsibility and authority of the LLC > and don't consider that a good idea. What I am picturing is the > LLC tentatively picking a slate/ committee and then handing it > to the RSAB for comment and advice. My expectation is that, if > the LLC does a good job (and/or gets lucky), the RSAB will > collectively nod approvingly and that will be the end of it. > "In consultation with" implies much more of a group decision, > one that, if carried out in what seems to have become the IETF > way, could easily evolve (unless we explicitly prohibit it) into > public calls for candidates, community comments, etc. I don't > want to see anything resembling a popularity contest for > selection committee members. Equally or more important, I see > selection committee membership as not being a particularly fun > job and expect that some people who might be among the best > candidates would have to be aggressively persuaded to take it > on. I think we are much better off with something lots closer > to what now appears to be in the draft: the LLC picks a > collection of people whom they think would be good at/for the > job but, instead of simply making and announcing that decision > (or launching a "community consultation"), reviews that decision > with the RSAB to ensure that perspectives they (the LLC) might > not have captured (or that are overrepresented) get identified > and, if appropriate, represented or the proposed membership > adjusted. And I am happy to leave it entirely up to the LLC to > decide how their initial list of people are identified (although > I would personally recommend against a public call for > volunteers) and, if arm-twisting is needed, when in the process > that is done and by whom. In particular, if the LLC comes to > the RSAB with a list of people who have not yet been asked or > agreed to serve, I'm fine with that even if it leads to an extra > iteration -- up to the LLC. >=20 > best, > john >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Dec 28 18:55:59 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2BC3A0B29 for ; Tue, 28 Dec 2021 18:55:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.853 X-Spam-Level: X-Spam-Status: No, score=-3.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aS91aTNijexC for ; Tue, 28 Dec 2021 18:55:51 -0800 (PST) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05on2128.outbound.protection.outlook.com [40.107.22.128]) (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 9C59E3A0B21 for ; Tue, 28 Dec 2021 18:55:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EoikfcMUVIggf102KALR1xKxBhe41HGNSLTUObRzSjh9iZWGxJ0h05aQ3CyhbMgHwDMcvR0Cwdnrn7eucR9+JL5CzbkGPGVeyw9UkMp22eSFGJsglZaZETAUGwmWAO8sl9ih2dnOuK+6thpGesTy2FAxT+e9mp9/tHY/yLuSpk48VAl1tzBBWPpCtBnES/nZI3N/zsdHOZ9vQgYu9w0MQ4iAYox3vMe3eruBK7kx51sERLvmKLwl8CoRZZR6kKadKxaSFXWpanCArRUF+FTsQQ+cBK7zU4sAOMYd+zlu3apkiPOur4TtfhubqjFDSTdJbiH7OrwcFzUNqbOSgk4BUw== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=woyWLocwPFgcCaEYjBXUJoIosry6LxoMkgagHeOwZug=; b=ZQZaIxS/Be0NSwMNhdhOoEkcup3alGpbuqNyYY7y7vJZ4xbr73JRDqiHhwF+emeIW1+pArQ5pM4OfF+mZtliQB/Py6snYFH6+gE32u0QY0XYmR/YW0ep6q4o2lWZiRVFlCz8XIsrLT2PWKm/NHrEzjhyLFrvEgHqQUuf7zeoK2elAq42xYgPl61dGK89en46IKWRBVrYR9xXKd9RxmLX2l2/7S6xyfa5P2PAhbyfLeYbLEWNTsvI8v0usFRqsE2cHDwybiiXunIu5ZUUkoM1xC0L9lqhqiRiXJpPOtZ+aR1q4323nkA4nIXBDk6ZR+QMVTwhhwLe0tZXxeXTwHCHrg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=woyWLocwPFgcCaEYjBXUJoIosry6LxoMkgagHeOwZug=; b=X8zqBXilnrTzrg9GhGFvpNln4WPG2UV1t/HlUnFuTiVoQqBfh420URP0doHyFf5nzJdkPHmy4UowFd+bJgWhY0bkgFRCrQeKBKJGquNZZ6lqPMPKqqZR371ob/TRpn2tRrtQ5y1OxXueK/Ln069GobOy5iwIRtN+2GS/nVmUeLSvuZC8B+rwApjpiQNCry+6qMsDdxUc5Wj1A+20iWBNrjngJVlnTWUGd5rCsGi93zcCeo31x/bQSXNKl/d5ouGGAr+SED1Z21Y2CjxIhpnEOwSsDcmMB8hBjvfYTLSdy67sNa3uSHGEVFLHxbqyA/PaumCpShhLp7Ngpro3d4cu8Q== Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie; Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by DB7PR02MB4872.eurprd02.prod.outlook.com (2603:10a6:10:28::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.21; Wed, 29 Dec 2021 02:55:42 +0000 Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::a85c:e144:6533:99ea%4]) with mapi id 15.20.4823.022; Wed, 29 Dec 2021 02:55:42 +0000 Message-ID: <35fbcd4f-061a-a1e5-a488-7ee0340ec003@cs.tcd.ie> Date: Wed, 29 Dec 2021 02:55:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.1 Content-Language: en-US To: Jay Daley , John C Klensin Cc: rfced-future@iab.org, Michael StJohns , Eliot Lear References: <65DF6A48DE82D1A1A9925FE0@PSB> From: Stephen Farrell In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------WGgirKC4ktYwzvCvzKuwKyrM" X-ClientProxiedBy: DB9PR06CA0028.eurprd06.prod.outlook.com (2603:10a6:10:1db::33) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 75739791-2291-4205-f080-08d9ca76b36e X-MS-TrafficTypeDiagnostic: DB7PR02MB4872:EE_ X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True X-Microsoft-Antispam-PRVS: X-TCD-Routed-via-EOP: Routed via EOP X-TCD-ROUTED: Passed-Transport-Routing-Rules X-MS-Oob-TLC-OOBClassifiers: OLM:2958; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: PoIhk27dYIGbReheUGDbX2ZOKFxNZhwq+5ENzOgbJb9RAzgy7l7A2ea1As1ycVDuQVw+Qz/XIasZOpnUVlipf4l9/I8h56fNzbUwoq+iCgCY+gl6dMhF2ApdpuBT2mULkSXXavW6ERsgUVIW4HTusSrmCyT8SsaXqTyVkuABvRdiNEGGD0AK7PLfAHhXa6eKh+EFSKDONyeBcajqhA8ra+7lz9iTRCFMCZ0V9aFfEDUGjHnBemD4rMsghElMPTn04wFfrO5Z8DrN5NG0VDZeyul+1fu7LK1dybvYgW3nbQqIVnSpm5HxYFCoAcNxnXvsIUlFSRXWWjO2xQBKQsoxywD0tz6SMB+WBqHcWoG0+MbLru361dov10G8Q8LKNKTvN5+NFT/BU4B3sVIwhrZr7gzGXMkKgQsT2dH/AFge7aQZ8aunpMVyUexo631BLKtF/Z5jqoxDFXA8/A+6tssW+gULbd1MKbb84y3PHQG5Z4lFCJwQmYuXbR0WGC+HB6K+hU897t08WfYhqSZzjvkPuLOwWVwb9sf+IkIpZnY88u1rB1ss+8NRe5KUOCgH0ef+Kfg8coqRsd54PJYglmMbDcfR0tnjcdtwovY3m7b9XFvt7vOYnerQ1h/VRVoiLCHMlDvD1HINXSOKmKqUyOJ+IVh9yHPOa0trwDDSJ/bjb39CYSNo71hfMPEIR/apSyAgBqj+ipKYKBGRTD+YqogvcfMomtoT+GSr8jZXrrH3ZGQ= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(366004)(36756003)(6512007)(186003)(786003)(316002)(21480400003)(66476007)(66556008)(8676002)(66946007)(110136005)(44832011)(54906003)(2616005)(86362001)(83380400001)(4326008)(8936002)(235185007)(508600001)(38100700002)(6666004)(5660300002)(6486002)(31696002)(6506007)(33964004)(2906002)(31686004)(53546011)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?a2w0ejRDOEZSUlRiU2Rtbkdnbm9KOHFBTGZTd01lWHpEK1VMUTBOT1BpOGdR?= =?utf-8?B?OGdtbm5aY1YyR1V6TGdWNWRjWklDVVRTN1JDVDNzbCtBSkt5cisrNWpacjJs?= =?utf-8?B?RmVzTHQvMVFpb1NvMUN5UDdNakN2QkVycFFuS1JXTzZQMzVyYkc2V3p2ekY1?= =?utf-8?B?eExIOVpQOWhScVR3MWVIYk5PQmkzbndSSkRMbGI2NjZCT0FmN2dvNVlEM3NE?= =?utf-8?B?eldFeVlucHRxeEQ2ZStNK000azFQcXBWRUxuVlNycklCczN2cU4vR0pSSEdx?= =?utf-8?B?bWZvYTh5eVBtUEoxeFRJZUp2dXJsc1AzYnFSQTJvZ1U5eU5CUEpHaVpSNWc1?= =?utf-8?B?cU5wdTVXZXZrRE9ZU0pHNEcwNWp5OUVURUtlT05DeUt6RzllUjF6NzdHUEJh?= =?utf-8?B?bkhPVElKVW1hVlRScThRUmx3cld0SzB1ZXNiY2gyRzJiYVQvZURXdUJYYmNz?= =?utf-8?B?ZnJtdjl0cGdTWjVzQXp6ZEZPcUZqZzB3S0VsQVgyc2FyQUhMRTRnbXo5VTVk?= =?utf-8?B?TzZ2STNSbllidnQ2TGRDSTZhd2JzNDRTbm8xZ3YrbmxKYTdBKzEydVVjU3g5?= =?utf-8?B?VE1uM2FOVElzSHllR3hzd2JJc29CRTFnNWNpT2F0akx3UVhHYXNWZmtldDhl?= =?utf-8?B?V25PNGRGclFGd1FLNFFVOWpZK213MW1XVlhhWGdJeVdONEdoVVdaMitYWXZV?= =?utf-8?B?bkhDUDlVMnFPUlBDNElJZzN3Z083cCswY2FVMlF2T0R3UVJWdnpXOHc0Vkll?= =?utf-8?B?NUdUZjVnaDg3MEtRT3VxQzB3OWNNZ1RqWDdTaVZxdFlRMks2UCtHV2tucWF0?= =?utf-8?B?MVdrZncrN0x5OHZBTDhzUXJIKzhTN3Mvakd5Rmd0QlluRWVBUUU0cC9URHBQ?= =?utf-8?B?aGtZL3BKQ0NFT3BWQlllVmVJejZjMURNQ1lZTmdtRTRaQWFOSVcwYm8vb1pS?= =?utf-8?B?dzBsMHZRZUtORlQ4bU5NbCtoTU5UZCt1aFZYbERQaTA2dWd2KzI1VFZTeXZD?= =?utf-8?B?SzhOSElzWDNEVmVoUHdyWG0wYm15UGtFdUtYc3BPNXMrVlBqdSt4bW1JV0hP?= =?utf-8?B?dnk5N3RqN3lnRHVib2J3NHVqY25SbWFZSkg3SFlZdzhJVUd2VzJYSERYVzcz?= =?utf-8?B?SW5IeFRnTk5tNVp3M0dIY1U3bU1UeUlhTXFoMG9hSk4rNEtVVmNEUWxjaW9v?= =?utf-8?B?dkhsUnFVTllERlU2Qmw3SW5vNmJ0a0JrTWEvUC8yOUFlWlpaN1NmU3psaVVx?= =?utf-8?B?UnJ3aFRFbG1xaWxFTnRLSWhnbWRBRTJRbFZMREw2bytDRndkSitueEtBYWdG?= =?utf-8?B?dmJhOVpSTmZ4QXlIOUJ3OFZtZ0Z6TmhRZW9ZanFyYmk5L3NzN25nRWNPV2ln?= =?utf-8?B?c2NyOHNMNFNrN00xYUlMdkw0TVQ4ME1vbS9oUHh5ekkyZ0dTWkJEQ3BGTmZC?= =?utf-8?B?bFZLaDBzcjBDeHlyUnVkTGxVY09zSzFHU05sa28rWmlyeGdwaWRyVm9EWVhQ?= =?utf-8?B?Q21WczNGL0R2bE9iTjEwdy83UlhzUzBhYUNJUlFIV005NWxKclNoWDA4NEdR?= =?utf-8?B?WUlHTWVlSDR2Mll5NzlteDgvV200c0RLV2czQTZvb01NcjYyTUVsNFdHa2FL?= =?utf-8?B?TjhVVW0zQUN2Zi9oQ3BCVWlVdmVSd2ErOXNJdUxIWWNVRndVTnBwMVZ0Y3lm?= =?utf-8?B?VDVzbjJZbEVwZVBlU1RmUFBTVUJIMFA0VXdNWnZwRFBscC9xVVNteEVwMnJS?= =?utf-8?B?RnZodGV5VGZVSFBVKzBycENFNXUrU3U2QXAweWg5b3pLbk42L2dnUmJIMzkw?= =?utf-8?B?WjV4VzRuTnp4TWdqbzVST3FGbUdUdzhrSld0MlVDazg4OEZ0cFdwWnJlalU4?= =?utf-8?B?eVZ2QnRvZjAwZVNHWVF3Y1RwY1hrczFjc05CMWhnbDBpeWMxTmxGUDlDalgz?= =?utf-8?B?VG9mU21GaEprbFdtWEpXU0NXYytaSXYwSFREazE0QS9RMmFmREtrYWFaelBT?= =?utf-8?B?bm5xOVprVlBpMDZWbGV3K2RuYVlEMDBwR3BQZlFQaXQzU0psQ2xoQ2RqeThS?= =?utf-8?B?WEdwQUNCQzQvb2RNbllOZUtlcHd2bTFzNngwK3NyYnBLeitUNHdrYUtGUS80?= =?utf-8?B?aXEydXphampCaWk2R1M2UTZQY1NEUWlmYTY4NGpmMEwrbFl1bm9vVHpCdnl0?= =?utf-8?Q?5/SXuGY7zHfFWt7hB/OF5IU=3D?= X-OriginatorOrg: cs.tcd.ie X-MS-Exchange-CrossTenant-Network-Message-Id: 75739791-2291-4205-f080-08d9ca76b36e X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Dec 2021 02:55:41.9766 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: f50OpA1fdVqRfgemp7kwJMz7Tbs1Qyg7KUJ2ahuetC34V8nYCxCjPvLXPGbR3814 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR02MB4872 Archived-At: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 02:55:58 -0000 --------------WGgirKC4ktYwzvCvzKuwKyrM Content-Type: multipart/mixed; boundary="------------BJFpUOLRVG8SIhwwtDyFJIlf"; protected-headers="v1" From: Stephen Farrell To: Jay Daley , John C Klensin Cc: rfced-future@iab.org, Michael StJohns , Eliot Lear Message-ID: <35fbcd4f-061a-a1e5-a488-7ee0340ec003@cs.tcd.ie> Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) References: <65DF6A48DE82D1A1A9925FE0@PSB> In-Reply-To: --------------BJFpUOLRVG8SIhwwtDyFJIlf Content-Type: multipart/mixed; boundary="------------HMXmdlGhAzHuYeTP8rqmyR54" --------------HMXmdlGhAzHuYeTP8rqmyR54 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 DQpJIGhhZCBwbGFubmVkIHRvIGlnbm9yZSB0aGlzIHRocmVhZCBhcyBJIGhhdmVuJ3QgcmVh bGx5DQpzaGFyZSBNaWtlL0pvaG4ncyBjb25jZXJucyBzbyBmYXIsIGJ1dC4uLg0KDQpPbiAy OS8xMi8yMDIxIDAyOjA2LCBKYXkgRGFsZXkgd3JvdGU6DQo+IEJyaWVmbHksIHRoaXMgaGFz IGJlY29tZSBvbmUgb3IgdHdvIG9yZGVycyBvZiBtYWduaXR1ZGUgbW9yZSBjb21wbGV4DQo+ IHRoYW4gaXMgcmVxdWlyZWQgZm9yIHRoaXMgcm9sZSAocmVtZW1iZXJpbmcgdGhhdCB0aGUg cm9sZSBhcyB3cml0dGVuDQo+IGlzIHZlcnkgZGlmZmVyZW50IGZyb20gdGhlIHByZXZpb3Vz IHJvbGUpLiAgVGhlIG92ZXJyaWRpbmcgcHJpb3JpdHkNCj4gZm9yIGNvbW1pdHRlZSBtZW1i ZXJzIHNob3VsZCBiZSB0aGF0IHRoZXkgdW5kZXJzdGFuZCB0aGlzIG5ldyByb2xlDQo+IGFu ZCB3aWxsIHRoZXJlZm9yZSBmaW5kIHNvbWVvbmUgd2hvIGZpdHMgdGhpcyByb2xlIHJhdGhl ciB0aGFuIHRoZQ0KPiBwcmV2aW91cyByb2xlLiAgSeKAmXZlIHJlZ3VsYXJseSBwdXNoZWQg YmFjayBvbiBoYXZpbmcgZXgtb2ZmaWNpbw0KPiBhcHBvaW50bWVudHMgdG8gdGhlIHNlbGVj dGlvbiBjb21taXR0ZWUgYmVjYXVzZSwgZnJvbSB3aGF0IEnigJl2ZSBzZWVuDQo+IHNvIGZh ciwgdGhlIG51bWJlciBvZiBwZW9wbGUgd2hvIHByb3Blcmx5IHVuZGVyc3RhbmQgdGhpcyBu ZXcgcm9sZSBpcw0KPiBhY3R1YWxseSBxdWl0ZSBsaW1pdGVkIGluIG51bWJlci4gUGlja2lu ZyBhIHJhbmRvbSBJQUIvSUVTRyBwZXJzb24NCj4gd2hvIGlzbuKAmXQgb25lIG9mIHRob3Nl IG1lYW5zIHRoZSBjb21taXR0ZWUgaGFzIHRvIHdvcmsgbXVjaCBoYXJkZXIgdG8NCj4gYnJp bmcgdGhlbSB0byBzcGVlZC4NCg0KTXkgbWFpbiBpbXByZXNzaW9uIG9mIHRoZSBhYm92ZSBp cyAidGhlIExMQyBkbyB0aGlzIGZvciBhDQpsaXZpbmcsIHNvIHdlIGtub3cgd2hhdCdzIHdo YXQgLSBkb24ndCB5b3Ugdm9sdW50ZWVycyBib3RoZXINCnlvdXJzZWx2ZXMgd2l0aCB3b3Jy eWluZyBhYm91dCBkZXRhaWxzLiIgVGhhdCdzIHVuZm9ydHVuYXRlLA0KYXQgYmVzdC4NCg0K PiBJIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGRlcHRoIG9mIHRyYXVtYSBzb21lIGZlbHQgYWJv dXQgdGhlIHByZXZpb3VzDQo+IHJvbGUgYW5kIHRoYXQgdGhlIHNjYXJzIGFyZSBzdGlsbCBm cmVzaCwgYnV0IHRoaXMgaXMgYSB2ZXJ5IGRpZmZlcmVudA0KPiByb2xlIGFuZCB3ZSBkb27i gJl0IG5lZWQgdG8gb3ZlcnRoaW5rIGl0Lg0KDQpUaGUgbGFuZ3VhZ2UgYWJvdmUgcmVhZHMg dG8gbWUgYXMgaWYgaW50ZW5kZWQgdG8gbWluaW1pc2UgYW5kDQpkZWZsYXRlIG9wcG9zaW5n IHBvc2l0aW9ucyAoZS5nLiB1c2Ugb2YgInRyYXVtYSIgYW5kDQoic2NhcnMiIGFzIGV4YWdn ZXJhdGlvbikuIEkgZG9uJ3QgdGhpbmsgIHN1Y2ggdGFjdGljYWwgdXNlDQpvZiBsYW5ndWFn ZSBpcyBhcHByb3ByaWF0ZSBmb3IgdGhlIExMQy9zZWNyZXRhcmlhdCAobm8gbWF0dGVyDQpo b3cgdGVtcHRpbmcgaXQgbWF5IGJlKS4NCg0KQ2hlZXJzLA0KUy4NCg0KDQo+IA0KPiBKYXkN Cj4gDQo= --------------HMXmdlGhAzHuYeTP8rqmyR54 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Description: OpenPGP public key Content-Transfer-Encoding: quoted-printable -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/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 zSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EEwEIACcFAlo9 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+R2yevRPjRrsN7PJzSf15fQLvCwFwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1cLBcwQQAQgAHRYhBH4X 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 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5wsDcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC 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 8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK 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+ ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb 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 Z0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1R 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/IyQdMLAXAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcK 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+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuzsFNBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB 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 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+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 =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------HMXmdlGhAzHuYeTP8rqmyR54-- --------------BJFpUOLRVG8SIhwwtDyFJIlf-- --------------WGgirKC4ktYwzvCvzKuwKyrM Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmHLzisFAwAAAAAACgkQWrL68XsXK+qC TQ/+NgREiXhXvnZ3SDvIMoKzT7gj9tzDl8/SzBoXFx+7zL+ju2gGgCUPdUJBzFp6gO+swH6A5J+y XgpyqTaNchxYoFBgqBK0Qx5cYgKpdGR9WqlGL+7LB97SaLKTJTfTZpm8OgXp6P+A2XQ3PlkTntGg UDbnRSE+GjT4fazCpPO9CLdBUR9av96GHRVAwe3qt+7AQtB90J6UAcRJEL9bZ/VO4Vx+E4iiq0Q/ qkHaYv2/1K1yiHdoXGPauyqd2Oav+fRL0ByZPli29qrcDVrFRrwl1wO+dOEeQQBBLoT1mFU8dYFg jXweLTTP75B9XZObrN85g0g/TNAQ3QWNoX/tb0dYkts+ap6vHoj17LdgTcTGwUn7q20TZHGkocwK f8yyfQGTEP3s6HWonJuy+hjPAOR3omjjUOo8nHNjDnyjPS6zr0bRfVmHhQeYCjj5HpL93KTciECE q+kCgSb9/11o8VAkNrqKrwK5AzrRaRRnHlgas0GBjqqEFq4cWx6bju6ACZZvJEQX01xpw5fsi9I/ AKPQMnLL72E1mDD33SlscfXZ6glt3aitEUupfxgJcALNVtCx869lYvGp+vYXy3Jei9aI4ZoBkLUF ylqUiecXqY3ngFgoKIUpvnj31wsD/3d1fCd1hjwP+lM3WyOEmehzMuItsOwEZw5StaVpZqOBxGHR C2w= =60s0 -----END PGP SIGNATURE----- --------------WGgirKC4ktYwzvCvzKuwKyrM-- From nobody Tue Dec 28 23:40:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3715F3A0EDD for ; Tue, 28 Dec 2021 23:40:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwTyasIE4RJ9 for ; Tue, 28 Dec 2021 23:40:28 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF0E3A0EDB for ; Tue, 28 Dec 2021 23:40:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 74D57411363A; Tue, 28 Dec 2021 23:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7eMTM_7hgXmY; Tue, 28 Dec 2021 23:40:28 -0800 (PST) Received: from smtpclient.apple (unknown [158.140.230.105]) by ietfx.amsl.com (Postfix) with ESMTPSA id 38522404BFAE; Tue, 28 Dec 2021 23:40:28 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Wed, 29 Dec 2021 20:40:24 +1300 Message-Id: <970576AF-BBF8-4EE7-8AE3-7DB1E27A96C0@ietf.org> References: <35fbcd4f-061a-a1e5-a488-7ee0340ec003@cs.tcd.ie> Cc: John C Klensin , rfced-future@iab.org, Michael StJohns , Eliot Lear In-Reply-To: <35fbcd4f-061a-a1e5-a488-7ee0340ec003@cs.tcd.ie> To: Stephen Farrell X-Mailer: iPhone Mail (19B74) Archived-At: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 07:40:32 -0000 > On 29/12/2021, at 3:56 PM, Stephen Farrell wro= te: >=20 > =EF=BB=BF > I had planned to ignore this thread as I haven't really > share Mike/John's concerns so far, but... >=20 >> On 29/12/2021 02:06, Jay Daley wrote: >> Briefly, this has become one or two orders of magnitude more complex >> than is required for this role (remembering that the role as written >> is very different from the previous role). The overriding priority >> for committee members should be that they understand this new role >> and will therefore find someone who fits this role rather than the >> previous role. I=E2=80=99ve regularly pushed back on having ex-officio >> appointments to the selection committee because, from what I=E2=80=99ve s= een >> so far, the number of people who properly understand this new role is >> actually quite limited in number. Picking a random IAB/IESG person >> who isn=E2=80=99t one of those means the committee has to work much harde= r to >> bring them to speed. >=20 > My main impression of the above is "the LLC do this for a > living, so we know what's what - don't you volunteers bother > yourselves with worrying about details." That's unfortunate, > at best. >=20 That=E2=80=99s quite clearly not what I was saying, but for the avoidance of= doubt, let me try again. My point is not about who chooses the recruitment c= ommittee but what knowledge the committee members need in order to make a su= ccessful appointment. My view is that the members need a deep understanding o= f the new model because it is so different from that before and that is unli= kely to be knowledge that someone will have if they have not been a regular p= articipant in this program.=20 >> I fully understand the depth of trauma some felt about the previous >> role and that the scars are still fresh, but this is a very different >> role and we don=E2=80=99t need to overthink it. >=20 > The language above reads to me as if intended to minimise and > deflate opposing positions (e.g. use of "trauma" and > "scars" as exaggeration). I don't think such tactical use > of language is appropriate for the LLC/secretariat (no matter > how tempting it may be). >=20 Again I think I was quite clear (and both accurate and proportionate in my l= anguage) but again, for the avoidance of doubt, I=E2=80=99ll explain again. M= y point is that the concerns that people have about this appointment seem to= reflect more the history of the preceding role rather than the new model as= proposed in which this is a very different role, with nothing like the auth= ority of the previous role.=20 Jay --=20 Jay Daley=20 IETF Executive Director exec-director@ietf.org > Cheers, > S. >=20 >=20 >> Jay > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Dec 29 00:32:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C05F03A1094; Wed, 29 Dec 2021 00:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.742 X-Spam-Level: X-Spam-Status: No, score=-2.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.852, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Sb3UuJrOxND; Wed, 29 Dec 2021 00:32:25 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 E12123A1093; Wed, 29 Dec 2021 00:32:22 -0800 (PST) Received: from [192.168.0.229] (77-58-147-26.dclient.hispeed.ch [77.58.147.26]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 1BT8WIEg2365646 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Wed, 29 Dec 2021 09:32:18 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1640766739; bh=UtLT0ZIU2D7pj0H/CEq5A1yRkbwcO872iEuq12RHSSw=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=XugDsCgx4PGfaC2rxnQ216nxVvIOmGRl6UzhSGaKrLQAmmIh8j4BEISZw27o89517 hmTJZGFq91goWi9brdLF7eDERYGlJE/LG0T8okWKPJVmfko4HZz5fUvQMT3PxRtIvI h6zUskL6DuySPRn87uSQPmiaMKkH9Hre1zysV1jI= Message-ID: Date: Wed, 29 Dec 2021 09:32:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Content-Language: en-US To: John C Klensin , Michael StJohns , Jay Daley Cc: rfced-future@iab.org References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> <5770F1800AC5065CDED8F988@PSB> <65DF6A48DE82D1A1A9925FE0@PSB> From: Eliot Lear In-Reply-To: <65DF6A48DE82D1A1A9925FE0@PSB> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------2KkuZb5KmshHa8Er0nvcqraE" Archived-At: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 08:32:30 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------2KkuZb5KmshHa8Er0nvcqraE Content-Type: multipart/mixed; boundary="------------cs4HrTTPi96wL7dgnpRA4hFI"; protected-headers="v1" From: Eliot Lear To: John C Klensin , Michael StJohns , Jay Daley Cc: rfced-future@iab.org Message-ID: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> <5770F1800AC5065CDED8F988@PSB> <65DF6A48DE82D1A1A9925FE0@PSB> In-Reply-To: <65DF6A48DE82D1A1A9925FE0@PSB> --------------cs4HrTTPi96wL7dgnpRA4hFI Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgSm9obg0KDQpPbiAyOC4xMi4yMSAyMTowNCwgSm9obiBDIEtsZW5zaW4gd3JvdGU6DQo+ IFtzbmlwXQ0KPiBOb3csIGZyb20gbXkgcG9pbnQgb2YgdmlldyBhdCBsZWFzdCAoYW5kIFlN TUQpIHRoZSBjdXJyZW50DQo+IFNlY3Rpb24gNSAoc3VwcGxlbWVudGVkIGJ5IHRoZSBkaWZm ZXJlbnRpYXRpbmcgbGFuZ3VhZ2Ugb2YNCj4gU2VjdGlvbiA4LjIpIGFyZSBqdXN0IHN1Y2gg YSAia2lja2luZyBjYW4gZG93biB0aGUgcm9hZCINCj4gZXhlcmNpc2UuDQoNCldlIGhhdmUg ZGVmaW5lZCB0aGUgcm9sZSAoSSBkaXNhZ3JlZSB3aXRoIHlvdSBvbiB0aGlzIHBvaW50KS7C oCBJdCBpcyANCmRvbmUgYnJvYWRseSBiZWNhdXNlIHdlIGxhY2sgZXhwZXJpZW5jZSB3aXRo IHRoZSBuYXR1cmUgb2YgdGhlIG5ldyANCnJvbGUuwqAgV2hhdCB3ZSBoYXZlbid0IGRvbmUg aXMgc3BlY2lmaWVkIGpvYiBxdWFsaWZpY2F0aW9ucy4gSSBiZWxpZXZlIA0KdGhhdCByZWZs ZWN0cyBob3cgdGhlIG9yZ2FuaXphdGlvbiBpbiBpdHMgbW9kZXJuIGZvcm0gZG9lcyBoaXJp bmcuwqDCoCANClBlcmhhcHMgdG8gY292ZXIgdGhpcyBwb2ludCwgd2UgaGF2ZSBzYWlkIHRo YXQgdGhlIFJQQyBjYW4gc2VlayB0aGUgDQpvcGluaW9uIG9mIHRoZSBSU0FCIHdoZW4gdGhl cmUgYXJlIGFtYmlndWl0aWVzIG9yIG9taXNzaW9ucyBpbiBvdXIgDQpwcm9jZXNzZXMuwqAg SSBkb24ndCBzZWUgd2h5IHRoZSBzZWxlY3Rpb24gY29tbWl0dGVlIGNvdWxkbid0IGRvIHRo ZSANCnNhbWUsIGlmIHRoZXkgaGF2ZSBxdWVzdGlvbnMuwqAgQW5zd2VycyB3b3VsZCBiZSBw dWJsaWMsIGFuZCBpbiANCnBhcnRpY3VsYXIgZ2l2ZW4gdG8gdGhlIFJTV0cuwqAgV2UgY291 bGQgc2F5IHNvbWV0aGluZyBsaWtlIHRoYXQuwqAgVGhhdCANCndvdWxkIGFsc28gYXZvaWQg ImZvb2QgZmlnaHRzIiBpbiB0aGUgc2VsZWN0aW9uIGNvbW1pdHRlZSwgYnV0IHJhdGhlciAN CmxldHMgdGhlbSB0YWtlIHBsYWNlIG92ZXIgdGltZSB3aGVyZSB0aGV5IHNob3VsZCB0YWtl IHBsYWNlLSB0aGUgUlNXRy4NCg0KVG8gYnJpbmcgdXMgYmFjayB0byB0aGUgKG90aGVyKSB0 ZXh0Og0KDQo+PiBPTEQ6DQo+Pg0KPj4gICAgICBUaGUgSUVURiBMTEMgd2lsbCBmb3JtIGEg c2VsZWN0aW9uIGNvbW1pdHRlZSwgaW5jbHVkaW5nDQo+PiBtZW1iZXJzIGZyb20NCj4+ICAg ICAgdGhlIGNvbW11bml0eSwgdGhhdCB3aWxsIGJlIHJlc3BvbnNpYmxlIGZvciBtYWtpbmcg YQ0KPj4gcmVjb21tZW5kYXRpb24NCj4+ICAgICAgdG8gdGhlIElFVEYgTExDIGZvciB0aGUg UlNDRSByb2xlLg0KPj4NCj4+IE5FVzoNCj4+DQo+PiAgICAgICpJbiBjb25zdWx0YXRpb24g d2l0aCB0aGUgUlNBQiosIGhlIElFVEYgTExDIHdpbGwgZm9ybSBhDQo+PiBzZWxlY3Rpb24N Cj4+ICAgICAgY29tbWl0dGVlLCBpbmNsdWRpbmcgbWVtYmVycyBmcm9tIHRoZSBjb21tdW5p dHkqd2hvDQo+PiByZXByZXNlbnQqKioqZGl2ZXJzZSBwZXJzcGVjdGl2ZXMqLCB0aGF0IHdp bGwgYmUgcmVzcG9uc2libGUNCj4+ICAgICAgZm9yIG1ha2luZyBhIHJlY29tbWVuZGF0aW9u IHRvIHRoZSBJRVRGIExMQyBmb3IgdGhlIFJTQ0UNCj4+IHJvbGUuDQo+Pg0KPj4gVGhvdWdo dHM/DQo+IFdlbGwuLi4NCj4NCj4gKGkpIEJldHRlciB0aGFuIGxlYXZpbmcgdGhlIHRleHQg dW5jaGFuZ2VkLg0KPg0KPiAoaWkpIFRoaXMgbWF5IGdvIGJhY2sgdG8geW91ciAid2hvIGRv IHlvdSB0cnVzdCIgcXVlc3Rpb24sIGJ1dCBJDQo+IHRoaW5rIHRoaXMgbG93ZXJzIHRoZSBy ZXNwb25zaWJpbGl0eSBhbmQgYXV0aG9yaXR5IG9mIHRoZSBMTEMNCj4gYW5kIGRvbid0IGNv bnNpZGVyIHRoYXQgYSBnb29kIGlkZWEuDQoNCk5vdCBhdCBhbGwgdGhlIGludGVudC7CoCBN YXliZSAid2l0aCB7YWR2aWNlL2lucHV0L2d1aWRhbmNlfSBmcm9tLi4uIj8NCg0KUGljayB5 b3VyIGZhdm9yaXRlIG5vdW4gdGhlcmUuwqAgSSB0aGluayB0aGUgb25lIHlvdSBhcmUgbG9v a2luZyBmb3IgdGhhdCANCkkgdGhpbmsgd291bGQgY2F1c2UgcHJvYmxlbXMgaXMgInJldmll dyIuwqAgV2UgZG9uJ3Qgd2FudCB0byBwdXQgdGhlIExMQyANCmluIGEgcG9zaXRpb24gd2hl cmUgdGhleSBjaG9vc2Ugd2l0aG91dCBndWlkYW5jZSBhbmQgdGhlbiB0aGUgUlNBQiBoYXRl cyANCnRoZSBjaG9pY2UgKHRoYXQncyBNb25kYXkgTW9ybmluZyBRdWF0ZXJiYWNraW5nKS7C oCBCZXR0ZXIgdG8gaGF2ZSB0aGUgDQpndWlkYW5jZSBpZiB3ZSdyZSBnb2luZyB0byBnbyBk b3duIHRoaXMgcGF0aCBhdCBhbGwuDQoNCkVsaW90DQoNCg== --------------cs4HrTTPi96wL7dgnpRA4hFI-- --------------2KkuZb5KmshHa8Er0nvcqraE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmHMHRIFAwAAAAAACgkQh7ZrRtnSejMU JAf9FlGR2RwOhtrNmlzz28oUPq2I0RPPHlXABp9ToWzqOSNCJ4K/iyZH1tdKdD+a//sl2sH6aCXQ 55K0DL8ErOD0f83iBNFB/TLrp6YUgdgfv1Dbo02S0Qd9Q3difwJE9Fl58hQ9a2vUPeh/k5dg2Ka/ dRPBAEXwTMHuegVQ2h6ysvupcndekFsFTEbF9uoau9CuSu9KnH+SF24JOSTDCJsvqweIAim2mzA1 b41GNaX0l14RAi+3cGTsLWrqwbAYVKfOlXHjHlrGMVtkLHLpFgS2yG9s/5wxjAMJt1sbEclyPgzm /tUpv6TFu3+Y0/cAwU5DJ9PBD5lpN8llGxCyvgRVUQ== =yPCh -----END PGP SIGNATURE----- --------------2KkuZb5KmshHa8Er0nvcqraE-- From nobody Wed Dec 29 05:46:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE9913A1636; Wed, 29 Dec 2021 05:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vBzaOQGQ2Ja8; Wed, 29 Dec 2021 05:46:18 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A84F3A1635; Wed, 29 Dec 2021 05:46:17 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n2ZHO-000I3A-8R; Wed, 29 Dec 2021 08:46:10 -0500 Date: Wed, 29 Dec 2021 08:46:04 -0500 From: John C Klensin To: Eric Rescorla , Eliot Lear cc: Michael StJohns , Jay Daley , rfced-future@iab.org Message-ID: <721C9F976C0FC510F60EC646@PSB> In-Reply-To: References: <18d1c2c5-cb1d-58d3-d566-0b5f55f7d28f@nthpermutation.com> <9EF86D6B-DA6B-49C4-ABAB-1D594173B96B@ietf.org> <1e33b9cf-6f77-19bd-ca10-a3be0c1e0214@lear.ch> <5770F1800AC5065CDED8F988@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] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 13:46:24 -0000 --On Tuesday, December 28, 2021 10:13 -0800 Eric Rescorla wrote: >... >> NEW: >> >> *In consultation with the RSAB*, he IETF LLC will form a >> selection >> >> Nit: "the IETF LLC" > >> committee, including members from the community *who >> represent** diverse perspectives*, that will be >> responsible for making a recommendation to the IETF LLC >> for the RSCE role. > I agree that diverse perspectives seem good, but this (and > Jon's proposed text) > seems more aspirational than like requirements text. How would > one evaluate whether the LLC had conformed with this? Maybe > that's OK, but I would lean towards not including it. ekr, I'll skip the further explanation that already appeared in my response to Eliot, but let me comment on this "aspirational versus requirements" issue. First, I think you may see a clearer boundary there than I do. If you do, I'd like to understand your definition and how it discriminates. >From my perspective, the whole process and the document are largely aspirational. This isn't Newtonian Physics or even Network Engineering where we can state a goal quantitatively, carry out some action, and then determine, with mathematical certainty or close to it, whether that action produced results that met the goals. Even where the document lays out very specific procedures, it may be possible to determine whether those procedures were followed but the real goal isn't procedure-following, it is producing a better RFC Series and/or a better Internet, both of which are inherently quite subjective and about which, if we were to start getting down to details, we would probably not have consensus. So the current text, which more or less specifies that the LLC selects the search committee and determines and executes the process, giving them absolutely no guidance, is, from my point of view, about as aspirational as it gets, without even spelling out the aspirations of producing a good result. Peter might have written a bit more of that down but he didn't (and, fwiw, in his position, I wouldn't have either -- part of it is obvious and part of it involves things about which we don't have a clear consensus). The problem with it is actually quite concrete, even if not easily measurable. The first principle about the LLC is that it doesn't do things that interfere with or set the course for, the standards process. Now that is, itself, also aspirational: there are enough edge cases that issues have to be worked out, on a case by case basis, with the IESG (at least). As this month's handy example, the LLC could have made an entirely financial decision about whether to hold a partially f2f meeting in March. They considered other issues and consulted more broadly than that and did so, I assume, because of interactions with the IETF and its processes and not just in order to get an estimate of whether enough people would come to get the numbers right. But one of the corollaries to that principle is that it is unreasonable to expect that the LLC, internally, will understand all of the relevant perspectives in the community (whether we aspire for them to do so or not). The downside of outside Directors and of, e.g., not requiring that the ED have ever designed protocols leading to standards track RFCs -- both of which I consider good decisions-- is that it is even more unreasonable to expect them to have that knowledge (whether we aspire to it or not). So, I am trying to build a fairly well defined procedural check into the system to mitigate the risks the current text might cause (even if everyone is acting in good faith and the best interests of the RFC Series and the IETF as they understand them). The check I proposed (perhaps unlike Eliot's modification)involves a clear procedure: the LLC tentatively selects a committee, then presents it to the RSAB and asked for input. If the RSAB says "looks good", then very little time or procedural overhead has been wasted. If they say "you left an important point of view out" we may dodge a bullet. Now, will that improve the result? That is speculative and, if you like, aspirational. But actually less so that the the move loosely defined procedure in -07 because the risk can be understood and this is an last a reasonable attempt at identifying and mitigating it. john From nobody Wed Dec 29 09:03:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6623A18E1; Wed, 29 Dec 2021 09:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N8LJLHVjkUqF; Wed, 29 Dec 2021 09:03:47 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E04953A18E2; Wed, 29 Dec 2021 09:03:46 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1n2cMY-000INe-Q4; Wed, 29 Dec 2021 12:03:42 -0500 Date: Wed, 29 Dec 2021 12:03:37 -0500 From: John C Klensin To: Jay Daley cc: Eliot Lear , Michael StJohns , rfced-future@iab.org Message-ID: In-Reply-To: References: <65DF6A48DE82D1A1A9925FE0@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] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 17:03:52 -0000 --On Wednesday, December 29, 2021 15:06 +1300 Jay Daley wrote: > Briefly, this has become one or two orders of magnitude more > complex than is required for this role (remembering that the > role as written is very different from the previous role). > The overriding priority for committee members should be that > they understand this new role and will therefore find someone > who fits this role rather than the previous role. I've > regularly pushed back on having ex-officio appointments to the > selection committee because, from what I've seen so far, the > number of people who properly understand this new role is > actually quite limited in number. Picking a random IAB/IESG > person who isn't one of those means the committee has to > work much harder to bring them to speed. Jay, Setting aside Stephen's reaction (and my similar one), whatever nostalgia I may feel for the old way of doing things and, hence, the old RSE role, had nothing to do with my comments. I think I understand the new role. It is clear from the above that my understanding is almost certainly different from yours. I got a hint of the differences from your "de facto" note, but this note from you makes the difference much more clear. The more important comment above is about people who "properly understand this new role". While I agree that is important, the above, combined with your proposed sole control of the selection committee and other aspects of the hiring process, would appear to set you up as the sole arbiter of "proper understanding" as well as of the entire hiring and selection process. I'd have a problem with that sole arbiter role even if I was confident that our understanding agreed. I also note that I dud not say anything about an ex-officio appointment to the selection committee. I don't remember anyone else suggesting that either. I think that makes "Picking a random IAB/IESG person..." entirely a red herring. I think the new role is going to be much harder than the old one because it requires, not only bringing a high level of expertise to the table, but of educating and persuading people about the implications of opinions formed on the basis of that expertise rather than being able to simply acting with authority when they think the time is right for that. We've removed the implicit requirement for management experience from the role but not the requirements for in-depth expertise and understanding. Assuming the personalities are right, that education and persuasion role will be easier for someone with more experience and knowledge to draw upon than for a more junior person whose input might be less persuasive. I'm expecting someone in that role who is capable of offering real advice based on their observations of what is going on, and doing so proactively, not just someone who is going to sit around waiting for questions or being presented with things and nodding approvingly. We haven't clearly defined that role or the requirements in the document other than to say "an expert in technical publishing" and "senior technical publishing professional who will apply their deep knowledge of technical publishing processes to the RFC Series" but even those are fairly high requirements. At least as I read them, they set a far higher bar than your de facto list. The role would change significantly if the document said that the RSCE was expected to speak only when spoken to and to answer questions only if they are asked by, e.g., the RSAB, RSWG, or ED but I can't find such text. Based, among other things, on experience doing some consulting for an important technical publisher and interacting with them over decisions similar to those the RFC Series has faced and will face and on experience with the RFC Series that had more to do with strategy than about roles and how they were defined (RFC 4846, 4897, etc., notwithstanding) and participation in the last search process (relevant not because I think the roles are the same but because those qualifications for expertise and deep knowledge are a subset of the criteria the last time around), I think the position is going to be very hard to fill. Based on that same experience and perspective I think that, if a selection is made on the basis of nothing more than your de facto criteria and ability to work well with you, we are not going to end up with the person in that role that many (at least) of us believe the phrases quoted above require. Speaking only for myself, if we are not going to put someone in that position who has enough experience and perspective to exert real influence --not just answer technical publication questions that I'm confident the RPC could handle, at least if they are not micromanaged (but might or might not want to), we should reduce the complexity of the new model by just getting rid of the RSCE position. Now, I don't know what you are picturing and it is probably time that you be much more explicit about it. But, unless you can explain your "proper" understanding of the role --not just identify what you call de facto requirements and then hand-wave-- and there is consensus (at least rough) about that, I think we have three choices (the third of which I hope no one likes): (1) We review our collective expectations of the position and write enough of a description and set of qualifications into the document to provide much of the content of a job posting or RFP without leaving you or your successors as sole arbiters of what the position is about. (2) We provide some (mandatory) mechanism for input into, or review of, the selection committee membership to make sure that diverse perspectives are represented by competent people who are willing to work together. Eliot sees some issues with my version and I see some issues with his but I don't see much point in further discussion of those differences unless we can get the selection process away from the idea of you (with or without discussion within the LLC) being sole arbiter (subject only to your interpretation of the few words in the document) of what the position is about and what sort of qualifications are needed in someone who is selected. See "obnoxious postscript" below for (3). > I fully understand the depth of trauma some felt about the > previous role and that the scars are still fresh, but this is > a very different role and we don't need to overthink it. Whether I think you understand that or have the experience to make the judgment is probably irrelevant as is your claim on the subject. It is a very different role. Maybe I haven't been watching closely enough but, at least in the last few months, I've seen no signs of anyone who does not understand that and think it is very different. And that is what I've said multiple times: another thing that made the old role possible to fill by relying on tradition is that the tradition and precedents were there and clear to those most involved, something that is not the case for this new and very different role. To use an example so deliberately exaggerated that I hope no one will think it is a proposal or serious suggestion, one way to avoid trying to carefully define it would be to appoint Donald Duck to the role for a moderately short term, watch the ways in which his performance is or is not successful, and then revise our expectations and then either eliminate the position (because his failures didn't make any difference) or write a job description based on what we had learned by the end of that period. While I don't think anyone you would be likely to recruit and hire (with or without a selection committee you control) would perform nearly as badly as I would expect from said duck, appointing someone unqualified (however accidentally) and then learning from the experience is not an experiment I would choose to perform if we can avoid it. best, john Obnoxious postscript: There is another way of looking at this, one I mentioned some time ago in the context of an "ultimate authority" discussion and that, IIR, no one found helpful. Let me try again, both to make a strawman counterproposal and to put my suggestion in a different light. The note quoted above reinforces the relevance of mentioning it. As this system has evolved and in the last analysis, the LLC is in charge of almost everything. They control the budget for anything that involves either work or money. They contract for, evaluate, manage, and control the RPC. While I would not expect it to ever happen, they could even deny publication for a particular document, approved by some stream, by forbidding the RPC to invest any resources in it. If the RSWG and RSAB propose a policy change, they can say "too expensive", "no budget", or "not something we are willing to manage" and there is no appeal. They control the RSCE selection, hiring, and evaluation processes and, if it suits their needs, convenience, or management style, could easily (and perhaps inadvertently) reduce that position to something very low-level with no influence on anything except to advise them when they decide they want advice. For those reasons, if there is a difference of opinion about what some provision of the "Model" document or other community-written specifications mean (not limited to the understanding of the RSCE role) and the community does not persuade them to change their view, their opinion will ultimately prevail. While they engage in consultations and other ways to measure community opinions and their own performance, they ultimately make the final decisions and are ultimately accountable to no one other than themselves (with the possible exception of the ISOC Board and the only option there, if it exists at all, would be very drastic). We are, of course, protected from a grim version of that picture by the moral and ethical obligations that the LLC Board and Staff, especially the Executive Director, feel to the community and community consensus but those obligations are, to use ekr's term, aspirational, not anything that is legally binding or enforceable. Given that description, which I believe summarizes the actual reality, perhaps what we should do with this Program is to declare success, thank Peter and the Co-chairs for their efforts, drop this fairly complicated "Model" document (including the RSWG and RSAB ideas), and replace it with an extremely short one that reaffirms the Streams, their relationships, and their independence of each other in terms of what is to be published. It would then say that the policies of the RFC Series and production of documents are ultimately administrative and financial matters to be managed, contracted or hired for as needed, and generally decided upon, by the LLC, encouraging them to engage in consultations with the community or selected subsets of it as they deem appropriate. I don't believe we should do that but it raises questions that may be worth thinking about. And, again thinking about ekr's comments and the reality that almost nothing in the document is actionable (other than giving people new and different titles or affiliations) without LLC decisions; decisions that the LLC has, in principle, the option of not making. Given that, maybe we should be engaging, not in relitigating issues that made sense under the assumption that this Program had authority and could define an RSWG, RSAB, and other roles and put them in charge but recognizing that there is no "in charge" other than the LLC. If those roles are ultimately meaningless except to give non-binding advice to the LLC, perhaps the whole arrangement is much too complicated are likely to be far too expensive of the time of those involved, especially those who might otherwise be working on agendas more directly connected to the development of Internet technology. I did say "obnoxious", didn't I? From nobody Wed Dec 29 11:17:35 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1623A08CD for ; Wed, 29 Dec 2021 11:17:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20210112.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 l5_gUeBSq0DH for ; Wed, 29 Dec 2021 11:17:28 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22B103A08D6 for ; Wed, 29 Dec 2021 11:17:28 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id l3so24927494iol.10 for ; Wed, 29 Dec 2021 11:17:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9JkzC5nly5ZJbIazp8X5MoX7u/87JV1lHKVYXz8VyRg=; b=CxIi3dqdQ5WJKNTzb0VUXPH88AOmLvdAzSsvSTANremUsxmzQEUxBbMM4I5Neoj7nk m7xNEUVrFVt40vJwR8neckrPYAJ8xj+Ir4SQ5byjrcD4XHykCMPhzfx3LSxKSxM5A71T 9KteUAK+dVF4dVQmSs8kMagJRm5eYUPdISmgWYtvWdPHYJcjfcZfoIZyBdu+wFm0KHmF uT1d4Kwhd55/z0Cy6bq/O9YCqif07sSdGHQ2tArvVczf1RATZQutudISCNHNV90rfk4Q Syk2cQYDqfCbBALh1QsuVHkB5anywKgl31SH3DKF639xCDVNSXMIiqY4X11wt3GkIQf2 PLvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9JkzC5nly5ZJbIazp8X5MoX7u/87JV1lHKVYXz8VyRg=; b=xVcZgejC6CHo49RVlRKvsqdgsEXd+qGUIZEDOcvPIIjGyHhupvSvophFo7kliJvrS5 RDujcrN1uS2M49A/n86BjIaPkggb2pQfbpEt0KVJzv/6O7XEKOFa4CzkqdDPO776BIL4 dTHdF2uPeQPzHLjY1OCThDum/OisuD5VTCuQDiq7Sw+0Mx+fPiOzZ0cSmSi7sh2H500H UBqI12/YSFyKHw1DCLsZzEdOdRx7qbnmYktm3uMdNNmjaMOx0KHWUIKiFITXlWVmmtkM 1Y4uTKZx2LXoykWnZf2wKSbYCWg6mTOaQZrajxw1PmSR8+KLHqTgMailwQaViQUhD4Hh ssFA== X-Gm-Message-State: AOAM532G3HcsTkfebFgDyGiBfVdMk2FsrdKIoQHVlhvhr43KSrgVBoms ffh1cTo3RIAo2OLdMjh9mqXyTSO8odqBULWCqW61xQ== X-Google-Smtp-Source: ABdhPJwkJpyUeQkkMahPl0L8VO1CA99joQYt71Sz1lNyBeYOgUWUd82Xt4TMoq9mQue6Z0gZVKIlQS6l9lSOcNpx9s4= X-Received: by 2002:a05:6602:3c6:: with SMTP id g6mr12730992iov.213.1640805443564; Wed, 29 Dec 2021 11:17:23 -0800 (PST) MIME-Version: 1.0 References: <65DF6A48DE82D1A1A9925FE0@PSB> In-Reply-To: From: Eric Rescorla Date: Wed, 29 Dec 2021 11:16:47 -0800 Message-ID: To: John C Klensin Cc: Jay Daley , rfced-future@iab.org, Michael StJohns , Eliot Lear Content-Type: multipart/alternative; boundary="0000000000009c0c3605d44dc92b" Archived-At: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:17:34 -0000 --0000000000009c0c3605d44dc92b Content-Type: text/plain; charset="UTF-8" I see my name being called out here, and I would like to clarify what I meant by aspirational, which is that I considered the language "diverse perspectives" to be too vague to be able to have consensus about whether it had been followed. I agree that these documents *also* have the property that they require the LLC to do things that it might or might not do, even if that clearly violated these documents. However, I think that's different and to a first order is inherent in the structure of having an LLC. The structural component intended to ensure that the board follows the correct process is that the board of directors is largely selected by the community or its delegates. I think that's something other than just "moral and ethical obligation", given that the community can replace them. -Ekr On Wed, Dec 29, 2021 at 9:03 AM John C Klensin wrote: > > > --On Wednesday, December 29, 2021 15:06 +1300 Jay Daley > wrote: > > > Briefly, this has become one or two orders of magnitude more > > complex than is required for this role (remembering that the > > role as written is very different from the previous role). > > The overriding priority for committee members should be that > > they understand this new role and will therefore find someone > > who fits this role rather than the previous role. I've > > regularly pushed back on having ex-officio appointments to the > > selection committee because, from what I've seen so far, the > > number of people who properly understand this new role is > > actually quite limited in number. Picking a random IAB/IESG > > person who isn't one of those means the committee has to > > work much harder to bring them to speed. > > Jay, > > Setting aside Stephen's reaction (and my similar one), whatever > nostalgia I may feel for the old way of doing things and, hence, > the old RSE role, had nothing to do with my comments. I think I > understand the new role. It is clear from the above that my > understanding is almost certainly different from yours. I got a > hint of the differences from your "de facto" note, but this note > from you makes the difference much more clear. > > The more important comment above is about people who "properly > understand this new role". While I agree that is important, > the above, combined with your proposed sole control of the > selection committee and other aspects of the hiring process, > would appear to set you up as the sole arbiter of "proper > understanding" as well as of the entire hiring and selection > process. I'd have a problem with that sole arbiter role even if > I was confident that our understanding agreed. > > I also note that I dud not say anything about an ex-officio > appointment to the selection committee. I don't remember anyone > else suggesting that either. I think that makes "Picking a > random IAB/IESG person..." entirely a red herring. > > I think the new role is going to be much harder than the old one > because it requires, not only bringing a high level of expertise > to the table, but of educating and persuading people about the > implications of opinions formed on the basis of that expertise > rather than being able to simply acting with authority when they > think the time is right for that. We've removed the implicit > requirement for management experience from the role but not the > requirements for in-depth expertise and understanding. Assuming > the personalities are right, that education and persuasion role > will be easier for someone with more experience and knowledge to > draw upon than for a more junior person whose input might be > less persuasive. I'm expecting someone in that role who is > capable of offering real advice based on their observations of > what is going on, and doing so proactively, not just someone who > is going to sit around waiting for questions or being presented > with things and nodding approvingly. > > We haven't clearly defined that role or the requirements in the > document other than to say "an expert in technical publishing" > and "senior technical publishing professional who will apply > their deep knowledge of technical publishing processes to the > RFC Series" but even those are fairly high requirements. At > least as I read them, they set a far higher bar than your de > facto list. The role would change significantly if the document > said that the RSCE was expected to speak only when spoken to and > to answer questions only if they are asked by, e.g., the RSAB, > RSWG, or ED but I can't find such text. Based, among other > things, on experience doing some consulting for an important > technical publisher and interacting with them over decisions > similar to those the RFC Series has faced and will face and on > experience with the RFC Series that had more to do with strategy > than about roles and how they were defined (RFC 4846, 4897, > etc., notwithstanding) and participation in the last search > process (relevant not because I think the roles are the same but > because those qualifications for expertise and deep knowledge > are a subset of the criteria the last time around), I think the > position is going to be very hard to fill. Based on that same > experience and perspective I think that, if a selection is made > on the basis of nothing more than your de facto criteria and > ability to work well with you, we are not going to end up with > the person in that role that many (at least) of us believe the > phrases quoted above require. > > Speaking only for myself, if we are not going to put someone in > that position who has enough experience and perspective to exert > real influence --not just answer technical publication questions > that I'm confident the RPC could handle, at least if they are > not micromanaged (but might or might not want to), we should > reduce the complexity of the new model by just getting rid of > the RSCE position. > > Now, I don't know what you are picturing and it is probably time > that you be much more explicit about it. But, unless you can > explain your "proper" understanding of the role --not just > identify what you call de facto requirements and then > hand-wave-- and there is consensus (at least rough) about that, > I think we have three choices (the third of which I hope no one > likes): > > (1) We review our collective expectations of the position and > write enough of a description and set of qualifications into the > document to provide much of the content of a job posting or RFP > without leaving you or your successors as sole arbiters of what > the position is about. > > (2) We provide some (mandatory) mechanism for input into, or > review of, the selection committee membership to make sure that > diverse perspectives are represented by competent people who are > willing to work together. Eliot sees some issues with my > version and I see some issues with his but I don't see much > point in further discussion of those differences unless we can > get the selection process away from the idea of you (with or > without discussion within the LLC) being sole arbiter (subject > only to your interpretation of the few words in the document) of > what the position is about and what sort of qualifications are > needed in someone who is selected. > > See "obnoxious postscript" below for (3). > > > I fully understand the depth of trauma some felt about the > > previous role and that the scars are still fresh, but this is > > a very different role and we don't need to overthink it. > > Whether I think you understand that or have the experience to > make the judgment is probably irrelevant as is your claim on the > subject. It is a very different role. Maybe I haven't been > watching closely enough but, at least in the last few months, > I've seen no signs of anyone who does not understand that and > think it is very different. And that is what I've said > multiple times: another thing that made the old role possible to > fill by relying on tradition is that the tradition and > precedents were there and clear to those most involved, > something that is not the case for this new and very different > role. > > To use an example so deliberately exaggerated that I hope no one > will think it is a proposal or serious suggestion, one way to > avoid trying to carefully define it would be to appoint Donald > Duck to the role for a moderately short term, watch the ways in > which his performance is or is not successful, and then revise > our expectations and then either eliminate the position (because > his failures didn't make any difference) or write a job > description based on what we had learned by the end of that > period. While I don't think anyone you would be likely to > recruit and hire (with or without a selection committee you > control) would perform nearly as badly as I would expect from > said duck, appointing someone unqualified (however accidentally) > and then learning from the experience is not an experiment I > would choose to perform if we can avoid it. > > best, > john > > Obnoxious postscript: > > There is another way of looking at this, one I mentioned some > time ago in the context of an "ultimate authority" discussion > and that, IIR, no one found helpful. Let me try again, both to > make a strawman counterproposal and to put my suggestion in a > different light. The note quoted above reinforces the relevance > of mentioning it. As this system has evolved and in the last > analysis, the LLC is in charge of almost everything. They > control the budget for anything that involves either work or > money. They contract for, evaluate, manage, and control the > RPC. While I would not expect it to ever happen, they could > even deny publication for a particular document, approved by > some stream, by forbidding the RPC to invest any resources in > it. If the RSWG and RSAB propose a policy change, they can say > "too expensive", "no budget", or "not something we are willing > to manage" and there is no appeal. They control the RSCE > selection, hiring, and evaluation processes and, if it suits > their needs, convenience, or management style, could easily (and > perhaps inadvertently) reduce that position to something very > low-level with no influence on anything except to advise them > when they decide they want advice. For those reasons, if there > is a difference of opinion about what some provision of the > "Model" document or other community-written specifications mean > (not limited to the understanding of the RSCE role) and the > community does not persuade them to change their view, their > opinion will ultimately prevail. While they engage in > consultations and other ways to measure community opinions and > their own performance, they ultimately make the final decisions > and are ultimately accountable to no one other than themselves > (with the possible exception of the ISOC Board and the only > option there, if it exists at all, would be very drastic). > > We are, of course, protected from a grim version of that picture > by the moral and ethical obligations that the LLC Board and > Staff, especially the Executive Director, feel to the community > and community consensus but those obligations are, to use ekr's > term, aspirational, not anything that is legally binding or > enforceable. > > Given that description, which I believe summarizes the actual > reality, perhaps what we should do with this Program is to > declare success, thank Peter and the Co-chairs for their > efforts, drop this fairly complicated "Model" document > (including the RSWG and RSAB ideas), and replace it with an > extremely short one that reaffirms the Streams, their > relationships, and their independence of each other in terms of > what is to be published. It would then say that the policies of > the RFC Series and production of documents are ultimately > administrative and financial matters to be managed, contracted > or hired for as needed, and generally decided upon, by the LLC, > encouraging them to engage in consultations with the community > or selected subsets of it as they deem appropriate. > > I don't believe we should do that but it raises questions that > may be worth thinking about. And, again thinking about ekr's > comments and the reality that almost nothing in the document is > actionable (other than giving people new and different titles or > affiliations) without LLC decisions; decisions that the LLC has, > in principle, the option of not making. Given that, maybe we > should be engaging, not in relitigating issues that made sense > under the assumption that this Program had authority and could > define an RSWG, RSAB, and other roles and put them in charge but > recognizing that there is no "in charge" other than the LLC. If > those roles are ultimately meaningless except to give > non-binding advice to the LLC, perhaps the whole arrangement is > much too complicated are likely to be far too expensive of the > time of those involved, especially those who might otherwise be > working on agendas more directly connected to the development of > Internet technology. > > I did say "obnoxious", didn't I? > > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000009c0c3605d44dc92b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I see my name being called out here, and I would like= to clarify what
I meant by aspirational, which is that I conside= red the language
"diverse perspectives" to be too vague= to be able to have consensus
about whether it had been followed.=

I agree that these documents *also* have the prop= erty that they
require the LLC to do things that it might or migh= t not do, even
if that clearly violated these documents. However,= I think that's
different and to a first order is inherent in= the structure of having
an LLC. The structural component intende= d to ensure that the
board follows the correct process is that th= e board of directors
is largely selected by the community or its = delegates. I think
that's something other than just "mor= al and ethical obligation",
given that the community can rep= lace them.

-Ekr


=
On Wed, De= c 29, 2021 at 9:03 AM John C Klensin <john-ietf@jck.com> wrote:


--On Wednesday, December 29, 2021 15:06 +1300 Jay Daley
<exec-direct= or@ietf.org> wrote:

> Briefly, this has become one or two orders of magnitude more
> complex than is required for this role (remembering that the
> role as written is very different from the previous role).
> The overriding priority for committee members should be that
> they understand this new role and will therefore find someone
> who fits this role rather than the previous role.=C2=A0 I've
> regularly pushed back on having ex-officio appointments to the
> selection committee because, from what I've seen so far, the
> number of people who properly understand this new role is
> actually quite limited in number. Picking a random IAB/IESG
> person who isn't one of those means the committee has to
> work much harder to bring them to speed.

Jay,

Setting aside Stephen's reaction (and my similar one), whatever
nostalgia I may feel for the old way of doing things and, hence,
the old RSE role, had nothing to do with my comments.=C2=A0 I think I
understand the new role.=C2=A0 It is clear from the above that my
understanding is almost certainly different from yours.=C2=A0 I got a
hint of the differences from your "de facto" note, but this note<= br> from you makes the difference much more clear.

The more important comment above is about people who "properly
understand this new role".=C2=A0 =C2=A0While I agree that is important= ,
the above, combined with your proposed sole control of the
selection committee and other aspects of the hiring process,
would appear to set you up as the sole arbiter of "proper
understanding" as well as of the entire hiring and selection
process.=C2=A0 I'd have a problem with that sole arbiter role even if I was confident that our understanding agreed.=C2=A0

I also note that I dud not say anything about an ex-officio
appointment to the selection committee.=C2=A0 I don't remember anyone else suggesting that either.=C2=A0 I think that makes "Picking a
random IAB/IESG person..." entirely a red herring.

I think the new role is going to be much harder than the old one
because it requires, not only bringing a high level of expertise
to the table, but of educating and persuading people about the
implications of opinions formed on the basis of that expertise
rather than being able to simply acting with authority when they
think the time is right for that.=C2=A0 We've removed the implicit
requirement for management experience from the role but not the
requirements for in-depth expertise and understanding.=C2=A0 Assuming
the personalities are right, that education and persuasion role
will be easier for someone with more experience and knowledge to
draw upon than for a more junior person whose input might be
less persuasive.=C2=A0 I'm expecting someone in that role who is
capable of offering real advice based on their observations of
what is going on, and doing so proactively, not just someone who
is going to sit around waiting for questions or being presented
with things and nodding approvingly.

We haven't clearly defined that role or the requirements in the
document other than to say "an expert in technical publishing" and "senior technical publishing professional who will apply
their deep knowledge of technical publishing processes to the
RFC Series" but even those are fairly high requirements.=C2=A0 At
least as I read them, they set a far higher bar than your de
facto list.=C2=A0 The role would change significantly if the document
said that the RSCE was expected to speak only when spoken to and
to answer questions only if they are asked by, e.g., the RSAB,
RSWG, or ED but I can't find such text.=C2=A0 Based, among other
things, on experience doing some consulting for an important
technical publisher and interacting with them over decisions
similar to those the RFC Series has faced and will face and on
experience with the RFC Series that had more to do with strategy
than about roles and how they were defined (RFC 4846, 4897,
etc., notwithstanding) and participation in the last search
process (relevant not because I think the roles are the same but
because those qualifications for expertise and deep knowledge
are a subset of the criteria the last time around), I think the
position is going to be very hard to fill.=C2=A0 Based on that same
experience and perspective I think that, if a selection is made
on the basis of nothing more than your de facto criteria and
ability to work well with you, we are not going to end up with
the person in that role that many (at least) of us believe the
phrases quoted above require.

Speaking only for myself, if we are not going to put someone in
that position who has enough experience and perspective to exert
real influence --not just answer technical publication questions
that I'm confident the RPC could handle, at least if they are
not micromanaged (but might or might not want to), we should
reduce the complexity of the new model by just getting rid of
the RSCE position.

Now, I don't know what you are picturing and it is probably time
that you be much more explicit about it.=C2=A0 =C2=A0But, unless you can explain your "proper" understanding of the role --not just
identify what you call de facto requirements and then
hand-wave-- and there is consensus (at least rough) about that,
I think we have three choices (the third of which I hope no one
likes):

(1) We review our collective expectations of the position and
write enough of a description and set of qualifications into the
document to provide much of the content of a job posting or RFP
without leaving you or your successors as sole arbiters of what
the position is about.

(2) We provide some (mandatory) mechanism for input into, or
review of, the selection committee membership to make sure that
diverse perspectives are represented by competent people who are
willing to work together.=C2=A0 Eliot sees some issues with my
version and I see some issues with his but I don't see much
point in further discussion of those differences unless we can
get the selection process away from the idea of you (with or
without discussion within the LLC) being sole arbiter (subject
only to your interpretation of the few words in the document) of
what the position is about and what sort of qualifications are
needed in someone who is selected.

See "obnoxious postscript" below for (3).

> I fully understand the depth of trauma some felt about the
> previous role and that the scars are still fresh, but this is
> a very different role and we don't need to overthink it.

Whether I think you understand that or have the experience to
make the judgment is probably irrelevant as is your claim on the
subject.=C2=A0 It is a very different role.=C2=A0 Maybe I haven't been<= br> watching closely enough but, at least in the last few months,
I've seen no signs of anyone who does not understand that and
think it is very different.=C2=A0 =C2=A0And that is what I've said
multiple times: another thing that made the old role possible to
fill by relying on tradition is that the tradition and
precedents were there and clear to those most involved,
something that is not the case for this new and very different
role.=C2=A0

To use an example so deliberately exaggerated that I hope no one
will think it is a proposal or serious suggestion, one way to
avoid trying to carefully define it would be to appoint Donald
Duck to the role for a moderately short term, watch the ways in
which his performance is or is not successful, and then revise
our expectations and then either eliminate the position (because
his failures didn't make any difference) or write a job
description based on what we had learned by the end of that
period.=C2=A0 While I don't think anyone you would be likely to
recruit and hire (with or without a selection committee you
control) would perform nearly as badly as I would expect from
said duck, appointing someone unqualified (however accidentally)
and then learning from the experience is not an experiment I
would choose to perform if we can avoid it.

best,
=C2=A0 =C2=A0john

Obnoxious postscript:

There is another way of looking at this, one I mentioned some
time ago in the context of an "ultimate authority" discussion
and that, IIR, no one found helpful.=C2=A0 Let me try again, both to
make a strawman counterproposal and to put my suggestion in a
different light.=C2=A0 The note quoted above reinforces the relevance
of mentioning it.=C2=A0 As this system has evolved and in the last
analysis, the LLC is in charge of almost everything.=C2=A0 They
control the budget for anything that involves either work or
money.=C2=A0 They contract for, evaluate, manage, and control the
RPC.=C2=A0 While I would not expect it to ever happen, they could
even deny publication for a particular document, approved by
some stream, by forbidding the RPC to invest any resources in
it.=C2=A0 If the RSWG and RSAB propose a policy change, they can say
"too expensive", "no budget", or "not something we= are willing
to manage" and there is no appeal.=C2=A0 They control the RSCE
selection, hiring, and evaluation processes and, if it suits
their needs, convenience, or management style, could easily (and
perhaps inadvertently) reduce that position to something very
low-level with no influence on anything except to advise them
when they decide they want advice.=C2=A0 For those reasons, if there
is a difference of opinion about what some provision of the
"Model" document or other community-written specifications mean (not limited to the understanding of the RSCE role) and the
community does not persuade them to change their view, their
opinion will ultimately prevail.=C2=A0 While they engage in
consultations and other ways to measure community opinions and
their own performance, they ultimately make the final decisions
and are ultimately accountable to no one other than themselves
(with the possible exception of the ISOC Board and the only
option there, if it exists at all, would be very drastic).

We are, of course, protected from a grim version of that picture
by the moral and ethical obligations that the LLC Board and
Staff, especially the Executive Director, feel to the community
and community consensus but those obligations are, to use ekr's
term, aspirational, not anything that is legally binding or
enforceable.

Given that description, which I believe summarizes the actual
reality, perhaps what we should do with this Program is to
declare success, thank Peter and the Co-chairs for their
efforts, drop this fairly complicated "Model" document
(including the RSWG and RSAB ideas), and replace it with an
extremely short one that reaffirms the Streams, their
relationships, and their independence of each other in terms of
what is to be published.=C2=A0 It would then say that the policies of
the RFC Series and production of documents are ultimately
administrative and financial matters to be managed, contracted
or hired for as needed, and generally decided upon, by the LLC,
encouraging them to engage in consultations with the community
or selected subsets of it as they deem appropriate.

I don't believe we should do that but it raises questions that
may be worth thinking about.=C2=A0 And, again thinking about ekr's
comments and the reality that almost nothing in the document is
actionable (other than giving people new and different titles or
affiliations) without LLC decisions; decisions that the LLC has,
in principle, the option of not making. Given that, maybe we
should be engaging, not in relitigating issues that made sense
under the assumption that this Program had authority and could
define an RSWG, RSAB, and other roles and put them in charge but
recognizing that there is no "in charge" other than the LLC.=C2= =A0 If
those roles are ultimately meaningless except to give
non-binding advice to the LLC, perhaps the whole arrangement is
much too complicated are likely to be far too expensive of the
time of those involved, especially those who might otherwise be
working on agendas more directly connected to the development of
Internet technology.

I did say "obnoxious", didn't I?





--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000009c0c3605d44dc92b-- From nobody Wed Dec 29 11:50:31 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D13053A09D4 for ; Wed, 29 Dec 2021 11:50:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17Og956rDsiY for ; Wed, 29 Dec 2021 11:50:24 -0800 (PST) Received: from ietfx.ietf.org (ietfx.amsl.com [4.31.198.45]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E9093A09D3 for ; Wed, 29 Dec 2021 11:50:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by ietfx.amsl.com (Postfix) with ESMTP id 09A82411363A; Wed, 29 Dec 2021 11:50:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from ietfx.ietf.org ([4.31.198.45]) by localhost (ietfx.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cep8B33KmqZf; Wed, 29 Dec 2021 11:50:23 -0800 (PST) Received: from smtpclient.apple (122-63-6-192.mobile.spark.co.nz [122.63.6.192]) by ietfx.amsl.com (Postfix) with ESMTPSA id 3CFCF404BFAE; Wed, 29 Dec 2021 11:50:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Jay Daley Mime-Version: 1.0 (1.0) Date: Thu, 30 Dec 2021 08:50:17 +1300 Message-Id: <7D28CA5F-594B-4212-9155-86669654A504@ietf.org> References: Cc: rfced-future@iab.org, Michael StJohns , Eliot Lear In-Reply-To: To: John C Klensin X-Mailer: iPad Mail (19B74) Archived-At: Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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 Dec 2021 19:50:30 -0000 John I agree, the current model does make the ED the sole arbiter of who meets th= e criteria to be on the appointment committee and I can see why you might ha= ve concerns that this could be misused. I have no objection to any checking= mechanism for this, such as your proposed check with the RSAB but please no= te, that would likely delay the appointment of the RSCE by ~3 months because= this process cannot then start until the RSAB is seated. I also btw, have n= o objection to the committee being chosen entirely separately from me. The o= ne thing I would ask if we go that path is that we document, as briefly as p= ossible, the knowledge those people are expected to have. My plan, as previously noted, was to come to this list with a proposed commi= ttee and get feedback that way, as I am obliged to do by section 4.4 or RFC8= 711 (which is phrased much stronger than an aspiration, but that=E2=80=99s a= conversation for another time). Of course, as you have explained, if this i= s not specified in the process then there is a possibility that another ED m= ight not do that. Even if we don=E2=80=99t put any of those safeguards in place, I will contin= ue to find this appointment process disproportionate given that the processe= s for appointing the RPC, Secretariat, and Tools Team PM, all of which proba= bly have more impact than this new role, are nowhere near as deeply specifie= d. =20 Jay (PS. This is likely to be my last post until Jan 24th as I start my summer v= acation later today). --=20 Jay Daley IETF Executive Director=20 exec-director@ietf.org > On 30/12/2021, at 6:04 AM, John C Klensin wrote: >=20 > =EF=BB=BF >=20 > --On Wednesday, December 29, 2021 15:06 +1300 Jay Daley > wrote: >=20 >> Briefly, this has become one or two orders of magnitude more >> complex than is required for this role (remembering that the >> role as written is very different from the previous role). >> The overriding priority for committee members should be that >> they understand this new role and will therefore find someone >> who fits this role rather than the previous role. I've >> regularly pushed back on having ex-officio appointments to the >> selection committee because, from what I've seen so far, the >> number of people who properly understand this new role is >> actually quite limited in number. Picking a random IAB/IESG >> person who isn't one of those means the committee has to >> work much harder to bring them to speed.=20 >=20 > Jay, >=20 > Setting aside Stephen's reaction (and my similar one), whatever > nostalgia I may feel for the old way of doing things and, hence, > the old RSE role, had nothing to do with my comments. I think I > understand the new role. It is clear from the above that my > understanding is almost certainly different from yours. I got a > hint of the differences from your "de facto" note, but this note > from you makes the difference much more clear. >=20 > The more important comment above is about people who "properly > understand this new role". While I agree that is important, > the above, combined with your proposed sole control of the > selection committee and other aspects of the hiring process, > would appear to set you up as the sole arbiter of "proper > understanding" as well as of the entire hiring and selection > process. I'd have a problem with that sole arbiter role even if > I was confident that our understanding agreed. =20 >=20 > I also note that I dud not say anything about an ex-officio > appointment to the selection committee. I don't remember anyone > else suggesting that either. I think that makes "Picking a > random IAB/IESG person..." entirely a red herring. >=20 > I think the new role is going to be much harder than the old one > because it requires, not only bringing a high level of expertise > to the table, but of educating and persuading people about the > implications of opinions formed on the basis of that expertise > rather than being able to simply acting with authority when they > think the time is right for that. We've removed the implicit > requirement for management experience from the role but not the > requirements for in-depth expertise and understanding. Assuming > the personalities are right, that education and persuasion role > will be easier for someone with more experience and knowledge to > draw upon than for a more junior person whose input might be > less persuasive. I'm expecting someone in that role who is > capable of offering real advice based on their observations of > what is going on, and doing so proactively, not just someone who > is going to sit around waiting for questions or being presented > with things and nodding approvingly.=20 >=20 > We haven't clearly defined that role or the requirements in the > document other than to say "an expert in technical publishing" > and "senior technical publishing professional who will apply > their deep knowledge of technical publishing processes to the > RFC Series" but even those are fairly high requirements. At > least as I read them, they set a far higher bar than your de > facto list. The role would change significantly if the document > said that the RSCE was expected to speak only when spoken to and > to answer questions only if they are asked by, e.g., the RSAB, > RSWG, or ED but I can't find such text. Based, among other > things, on experience doing some consulting for an important > technical publisher and interacting with them over decisions > similar to those the RFC Series has faced and will face and on > experience with the RFC Series that had more to do with strategy > than about roles and how they were defined (RFC 4846, 4897, > etc., notwithstanding) and participation in the last search > process (relevant not because I think the roles are the same but > because those qualifications for expertise and deep knowledge > are a subset of the criteria the last time around), I think the > position is going to be very hard to fill. Based on that same > experience and perspective I think that, if a selection is made > on the basis of nothing more than your de facto criteria and > ability to work well with you, we are not going to end up with > the person in that role that many (at least) of us believe the > phrases quoted above require. >=20 > Speaking only for myself, if we are not going to put someone in > that position who has enough experience and perspective to exert > real influence --not just answer technical publication questions > that I'm confident the RPC could handle, at least if they are > not micromanaged (but might or might not want to), we should > reduce the complexity of the new model by just getting rid of > the RSCE position.=20 >=20 > Now, I don't know what you are picturing and it is probably time > that you be much more explicit about it. But, unless you can > explain your "proper" understanding of the role --not just > identify what you call de facto requirements and then > hand-wave-- and there is consensus (at least rough) about that, > I think we have three choices (the third of which I hope no one > likes): >=20 > (1) We review our collective expectations of the position and > write enough of a description and set of qualifications into the > document to provide much of the content of a job posting or RFP > without leaving you or your successors as sole arbiters of what > the position is about. >=20 > (2) We provide some (mandatory) mechanism for input into, or > review of, the selection committee membership to make sure that > diverse perspectives are represented by competent people who are > willing to work together. Eliot sees some issues with my > version and I see some issues with his but I don't see much > point in further discussion of those differences unless we can > get the selection process away from the idea of you (with or > without discussion within the LLC) being sole arbiter (subject > only to your interpretation of the few words in the document) of > what the position is about and what sort of qualifications are > needed in someone who is selected. >=20 > See "obnoxious postscript" below for (3). >=20 >> I fully understand the depth of trauma some felt about the >> previous role and that the scars are still fresh, but this is >> a very different role and we don't need to overthink it.=20 >=20 > Whether I think you understand that or have the experience to > make the judgment is probably irrelevant as is your claim on the > subject. It is a very different role. Maybe I haven't been > watching closely enough but, at least in the last few months, > I've seen no signs of anyone who does not understand that and > think it is very different. And that is what I've said > multiple times: another thing that made the old role possible to > fill by relying on tradition is that the tradition and > precedents were there and clear to those most involved, > something that is not the case for this new and very different > role. =20 >=20 > To use an example so deliberately exaggerated that I hope no one > will think it is a proposal or serious suggestion, one way to > avoid trying to carefully define it would be to appoint Donald > Duck to the role for a moderately short term, watch the ways in > which his performance is or is not successful, and then revise > our expectations and then either eliminate the position (because > his failures didn't make any difference) or write a job > description based on what we had learned by the end of that > period. While I don't think anyone you would be likely to > recruit and hire (with or without a selection committee you > control) would perform nearly as badly as I would expect from > said duck, appointing someone unqualified (however accidentally) > and then learning from the experience is not an experiment I > would choose to perform if we can avoid it. >=20 > best, > john >=20 > Obnoxious postscript: >=20 > There is another way of looking at this, one I mentioned some > time ago in the context of an "ultimate authority" discussion > and that, IIR, no one found helpful. Let me try again, both to > make a strawman counterproposal and to put my suggestion in a > different light. The note quoted above reinforces the relevance > of mentioning it. As this system has evolved and in the last > analysis, the LLC is in charge of almost everything. They > control the budget for anything that involves either work or > money. They contract for, evaluate, manage, and control the > RPC. While I would not expect it to ever happen, they could > even deny publication for a particular document, approved by > some stream, by forbidding the RPC to invest any resources in > it. If the RSWG and RSAB propose a policy change, they can say > "too expensive", "no budget", or "not something we are willing > to manage" and there is no appeal. They control the RSCE > selection, hiring, and evaluation processes and, if it suits > their needs, convenience, or management style, could easily (and > perhaps inadvertently) reduce that position to something very > low-level with no influence on anything except to advise them > when they decide they want advice. For those reasons, if there > is a difference of opinion about what some provision of the > "Model" document or other community-written specifications mean > (not limited to the understanding of the RSCE role) and the > community does not persuade them to change their view, their > opinion will ultimately prevail. While they engage in > consultations and other ways to measure community opinions and > their own performance, they ultimately make the final decisions > and are ultimately accountable to no one other than themselves > (with the possible exception of the ISOC Board and the only > option there, if it exists at all, would be very drastic). >=20 > We are, of course, protected from a grim version of that picture > by the moral and ethical obligations that the LLC Board and > Staff, especially the Executive Director, feel to the community > and community consensus but those obligations are, to use ekr's > term, aspirational, not anything that is legally binding or > enforceable. >=20 > Given that description, which I believe summarizes the actual > reality, perhaps what we should do with this Program is to > declare success, thank Peter and the Co-chairs for their > efforts, drop this fairly complicated "Model" document > (including the RSWG and RSAB ideas), and replace it with an > extremely short one that reaffirms the Streams, their > relationships, and their independence of each other in terms of > what is to be published. It would then say that the policies of > the RFC Series and production of documents are ultimately > administrative and financial matters to be managed, contracted > or hired for as needed, and generally decided upon, by the LLC, > encouraging them to engage in consultations with the community > or selected subsets of it as they deem appropriate. >=20 > I don't believe we should do that but it raises questions that > may be worth thinking about. And, again thinking about ekr's > comments and the reality that almost nothing in the document is > actionable (other than giving people new and different titles or > affiliations) without LLC decisions; decisions that the LLC has, > in principle, the option of not making. Given that, maybe we > should be engaging, not in relitigating issues that made sense > under the assumption that this Program had authority and could > define an RSWG, RSAB, and other roles and put them in charge but > recognizing that there is no "in charge" other than the LLC. If > those roles are ultimately meaningless except to give > non-binding advice to the LLC, perhaps the whole arrangement is > much too complicated are likely to be far too expensive of the > time of those involved, especially those who might otherwise be > working on agendas more directly connected to the development of > Internet technology.=20 >=20 > I did say "obnoxious", didn't I? >=20 >=20 >=20 >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20