From nobody Wed Mar 3 09:55: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 74FBD3A177D for ; Wed, 3 Mar 2021 09:54:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hxW8_36HM6xB for ; Wed, 3 Mar 2021 09:54:57 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 732D13A177E for ; Wed, 3 Mar 2021 09:54:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8721; q=dns/txt; s=iport; t=1614794097; x=1616003697; h=from:mime-version:subject:message-id:date:cc:to; bh=Cl0yfamSJGdBtW4jf+SIDhe699vMX6qamBRB9KSyhK0=; b=DYOLXnSuTmiLSK74/UdohJY5ikOmrhKMp8+bA+PXkuQ7f4dwA2aRB6HE nv0C+/pH7ffGs8tR5H64fkxMzW8yl4WasbGR9P0SG63JPXiObzpeuZ+g1 7k3iOR4RWWBcLz1PDFwPEAO/ZLjSEYk9tLKaLnAy5p1GMd773n4ai+TFG g=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AXAwAyzD9g/xbLJq1bBxwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?g+DdwEnEoRyiQSIMSWUMYgdBAcBAQEKAwEBNAQBAYRNgX0mOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBHGFboZuTwddAoENglUBgwetSHaBMopAExCBOIFThSkBh?= =?us-ascii?q?wiCC4ERJwwQhz6DKzSCCSIEgVUvI002BEMwAg42C1syD1gPnGucU4MGBIMrg?= =?us-ascii?q?TyXNQMfgzeKT4VPkAGyIV6DcwIEBgUCFoFrI4FXMxoIGxVlAYI/PRIZDY4rF?= =?us-ascii?q?o4nQANnAgYBCQEBAwmJTyuBPF0BAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,220,1610409600"; d="asc'?scan'208,217";a="31449705" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Mar 2021 17:54:52 +0000 Received: from [10.61.144.47] ([10.61.144.47]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 123Hsqi9030542 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Mar 2021 17:54:52 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_1F763488-15D9-4D1E-A8AF-6D3D985411ED"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <07F20D85-D894-4848-90B5-2ABA8146BAF6@cisco.com> Date: Wed, 3 Mar 2021 18:54:51 +0100 Cc: Brian Rosen To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.47, [10.61.144.47] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Where we stand, doc editors sought, and doodle X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 Mar 2021 17:54:59 -0000 --Apple-Mail=_1F763488-15D9-4D1E-A8AF-6D3D985411ED Content-Type: multipart/alternative; boundary="Apple-Mail=_37A57AC6-B35E-4864-B6CC-1D11A490F490" --Apple-Mail=_37A57AC6-B35E-4864-B6CC-1D11A490F490 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Greetings, Colleagues. This rather large message addresses the following points, which are = topics we expect to cover next week: Where we stand on Issue 15 Addressing what is permissible to block at the AB level. DISCUSS/NO and tone Document editor search Look out for a doodle As you have seen, the minutes from our last interim are posted, and we = got through a substantial amount of the proposal from Adrian. We have = several big issues to work through a bit more. The first ones we think = we should continue to address are these: Step G in Adrian=E2=80=99s proposal, and specifically the grounds for = the advisory board returning a draft to the working group for further = consideration. As the issue stands, there are two points of view: one = states that members may only do so in the narrow interests of their = streams. The other states that there should be no such restriction. In = considering approaches to reconcile these two positions, the chairs = encourage all members of the group to be innovative in their thinking. = We ourselves are optimistic that there is a solution here that does not = stretch the imagination too far. EKR and Joel kindly have offered to = give this some thought, but as we discussed in our last virtual, = everyone is welcome to make a proposal. Lingering in the background is = the relationship of the RS[EA] to the AB. People making proposals = should keep that in mind. There was lengthy discussion about =E2=80=9CDISCUSS=E2=80=9D versus = =E2=80=9CNO=E2=80=9D, and what happens. While we note Peter = Saint-Andre=E2=80=99s point that there is running code for DISCUSS, we = note the difference between this proposed WG and IETF WGs in that every = AB member is expected to participate; and we *think* the rough consensus = is likely to be that AB members are expected to participate in work = group discussions, and make their concerns known in that process, rather = than the IESG process of reading the document during IETF last call and = raising DISCUSSes then. If a proposal reaches the AB, the AB=E2=80=99s = decision process should not surprise anyone, because positions should be = known. There is an issue about tone. Nobody likes hearing NO, and Adrian=E2=80=99= s point about the presumption of moving a proposal toward approval is = not to be taken lightly. Therefore, rather than using the word = =E2=80=9CNO=E2=80=9D, we suggest =E2=80=9CReturn to working group=E2=80=9D= . We think it quite rare that a draft will actually be returned, but = more likely that differences really will get worked out prior to that = point. An AB member who surprises the WG would not be doing a good job. So=E2=80=A6 Discuss (cough)? The chairs are going to renew our attempts to actively search for a = document editor. Do not be shocked if we come a=E2=80=99knockin on your = door, and whining rights about editor selection of those who themselves = did not volunteer shall be suspended ;-) Finally, please note the doodle poll that will come out shortly for the = interim following the IETF 110 meeting. Brian & Eliot --Apple-Mail=_37A57AC6-B35E-4864-B6CC-1D11A490F490 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Greetings, Colleagues.

This rather large message addresses the = following points, which are topics we expect to cover next = week:

  • Where we stand on Issue 15
    • Addressing what is permissible to block at the = AB level.
    • DISCUSS/NO and tone
  • Document editor search
  • Look out for a = doodle

As you have seen, the minutes from our last interim are = posted, and we got through a substantial amount of the proposal from = Adrian.  We have several big issues to work through a bit more. =  The first ones we think we should continue to address are = these:

Step G = in Adrian=E2=80=99s proposal, and specifically the grounds for the = advisory board returning a draft to the working group for further = consideration. As the issue stands, there are two points of view: one = states that members may only do so in the narrow interests of their = streams.  The other states that there should be no such = restriction.  In considering approaches to reconcile these two = positions, the chairs encourage all members of the group to be = innovative in their thinking.   We ourselves are optimistic that = there is a solution here that does not stretch the imagination too far. =  EKR and Joel kindly have offered to give this some thought, but as = we discussed in our last virtual, everyone is welcome to make a = proposal.  Lingering in the background is the relationship of the = RS[EA] to the AB.  People making proposals should keep that in = mind.

There = was lengthy discussion about =E2=80=9CDISCUSS=E2=80=9D versus =E2=80=9CNO=E2= =80=9D, and what happens.   While we note Peter Saint-Andre=E2=80=99s= point that there is running code for DISCUSS, we note the difference = between this proposed WG and IETF WGs in that every AB member is = expected to participate; and we *think* the rough consensus is = likely to be that AB members are expected to participate in work group = discussions, and make their concerns known in that process, rather than = the IESG process of reading the document during IETF last call and = raising DISCUSSes then.   If a proposal reaches the AB, the = AB=E2=80=99s decision process should not surprise anyone, because = positions should be known.

There is an issue about tone.  Nobody likes hearing NO, = and Adrian=E2=80=99s point about the presumption of moving a proposal = toward approval is not to be taken lightly.  Therefore, rather than = using the word =E2=80=9CNO=E2=80=9D, we suggest =E2=80=9CReturn to = working group=E2=80=9D.  We think it quite rare that a draft will = actually be returned, but more likely that differences really will get = worked out prior to that point.  An AB member who surprises the WG = would not be doing a good job.

So=E2=80=A6 Discuss (cough)? =  

The = chairs are going to renew our attempts to actively search for a document = editor.  Do not be shocked if we come a=E2=80=99knockin on your = door, and whining rights about editor selection of those who themselves = did not volunteer shall be suspended ;-)

Finally, please note the doodle poll = that will come out shortly for the interim following the IETF 110 = meeting.

Brian = & Eliot
= --Apple-Mail=_37A57AC6-B35E-4864-B6CC-1D11A490F490-- --Apple-Mail=_1F763488-15D9-4D1E-A8AF-6D3D985411ED 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmA/zWsACgkQh7ZrRtnS ejNAhQf/YRyghTam/i8GXsBsJvnxH5mDCd1E1xYSkCdiEcHxQu5WPYQJJcRZKzUa OrM9jgNL7zcqVWAoDBUVv1klIj2OOn6p0D2UgXcHLl8v4jqzRf3CeS8QFDpdg5eD 7z5d5a7VOIT4F+xwFsdr7IpKqOJkWJJkox0l3tKVvjHdzRPqKyjcl3nQMlpdP+Cq 4i7NKLcHqwQYo0wkhOziTqa1Npx2TUnCPPNaSpdCeFtcPH3Of1B+jZkG5sVaPHeP dRC27gSxccRkmxBDu0CU6BEM5dmO5OTalKUfX3Nl6mQqy68UsV+ZbnPjEedf+KdI r/KAY/JrXd+5QbBFrK5kjplBg2TdOA== =W4Ko -----END PGP SIGNATURE----- --Apple-Mail=_1F763488-15D9-4D1E-A8AF-6D3D985411ED-- From nobody Wed Mar 3 10:20: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 9F5A53A17E4 for ; Wed, 3 Mar 2021 10:20:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdqUEzgu9xjB for ; Wed, 3 Mar 2021 10:19:59 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A3153A17E2 for ; Wed, 3 Mar 2021 10:19:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1380; q=dns/txt; s=iport; t=1614795599; x=1616005199; h=from:mime-version:subject:message-id:date:to; bh=sfFl0XhVfiKGs0aR0I2DOHI1AO9wWNCpxDCCcrlSw/0=; b=SrT16z5A/mEJudo/YWoO63GxcRkfPUZXmEftmHvuuOOLTiGYPS5iUvba OktgcVCpBKB/N0gItc6GEzDC4ikWkPw6fbdStlMsX6z31p2ECcJcClfrL WPsgoPMtXdzTY4EHpf5Bs+V2pbheOFFGoADSzTpyds6jmy44qbXuJjES9 I=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DVAQAY0j9glxbLJq1iHgEBCxIMhTBWAScShHKJBIgwn?= =?us-ascii?q?HMEBwEBAQoDAQEoDAQBAYZKJjgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBA?= =?us-ascii?q?QEBAQGGNg2GboEzAoNiAYMHD58djhx2gTKEPwGGEwoGgTiBU4wygguBOAwQi?= =?us-ascii?q?CCCSTSCKwSBVHKBKxBmnnmcU4MGBIMrgTyEVJJhAx+DJQERik+FT5ABoBKSb?= =?us-ascii?q?YNzAgQGBQIWgWshgVkzGggbFWUBgj89EhkNjjiDVopaQANnAgYBCQEBAwmME?= =?us-ascii?q?wEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,220,1610409600"; d="asc'?scan'208";a="33884867" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Mar 2021 18:19:54 +0000 Received: from [10.61.144.47] ([10.61.144.47]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 123IJsX2004256 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 3 Mar 2021 18:19:54 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_AE4D8865-9027-45A2-BEE6-7FBDF44554E4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <013DF9C5-FE9A-4433-A8AB-F0748F95084D@cisco.com> Date: Wed, 3 Mar 2021 19:19:53 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.47, [10.61.144.47] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Doodle for April Meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Mar 2021 18:20:01 -0000 --Apple-Mail=_AE4D8865-9027-45A2-BEE6-7FBDF44554E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, Please note that we have had it good for the last few meetings in terms = of timezones working out. As DST transitions begin to take place, = it=E2=80=99s a little trickier. Therefore, please do doodle[1], but = please also do raise concerns if you would rather we had some additional = options. We have time to change course if needs be. Eliot [1] https://doodle.com/poll/4xhvs8bzmiggw5d5 --Apple-Mail=_AE4D8865-9027-45A2-BEE6-7FBDF44554E4 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmA/00kACgkQh7ZrRtnS ejPfLggAmOxLrSNGdvFZAbNue0fYgcSz9T0F/JSIERzEN8TtwA0T5jJd47TTV4Jq fJAETBxTgXcIdgxlEouph9kbBTNeZ/WwYUC5tHX829xgLK2V7XIn6IPAbd6kHUFG A+qR4MdV2T0PDXzNopWbPmnCsOeA5pmeR75EFFHrTGeiaNOLyhd3/2WcmMbNqGYH jKClZaJZY9k0qiZaD8wtoQFpAFh//IMCQaKSmZLsP1d4J913JO0DjPFOpsXSCQPL 7U1yERXvLXSjqDtQhTUnTVS7VeoR6siM6VuV0EFQuidRY/aSRNA0jNYI8aBY4Y2K wVadwzYzVj2tEXJEVx5Bi8/QQuD1sg== =o9jy -----END PGP SIGNATURE----- --Apple-Mail=_AE4D8865-9027-45A2-BEE6-7FBDF44554E4-- From nobody Wed Mar 3 18:32: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 F0DEF3A0B83 for ; Wed, 3 Mar 2021 18:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05w6mTZRr4-1 for ; Wed, 3 Mar 2021 18:32:05 -0800 (PST) Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343053A0B8C for ; Wed, 3 Mar 2021 18:32:05 -0800 (PST) Received: by mail-pl1-x634.google.com with SMTP id c16so5794996ply.0 for ; Wed, 03 Mar 2021 18:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4BCrbmNVG+2tu4FA0QwHRFFJxZijtSbA+n4UcIVgV7g=; b=dZmP3pALUInxd3hrQwFKY8MwkHiq0f567OgodvWJl3i+YpVhHNej/S8riCfGMc3F6a ej3joMrht8CpvGKC3PCVVuhrjy0lFdN8tys1BUY5sOHo08POxrCv4d5xORG6bijkGEOx WstTSeCF4r3623RJ7lFoIizzDtjstVQxO/QN8AMuHRIMp2xS+M3x15W6ADItATfC31Cs 6Uu3cq+L9TOvjynCMIWo4Dnx7Vm7BgITTVlgv4CFtfBxhVkZqaY/savzIlqFMpetf+bw IUx5Xt0cLB32FzrPWdUAzOEEYAxjoghfmEd5xelUKhXM3Ywrh1a47m48crByi6mjrJB5 6lwg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4BCrbmNVG+2tu4FA0QwHRFFJxZijtSbA+n4UcIVgV7g=; b=P/o8XrhL/pfHUfmCPMOjrDnBLDS21uJ9aPpmjt1Hl8A+Jly7LLsYQHWzFqgobBisJL tW9ih0ta8rr0kxvT+vQ4eE+Ay4FMMPjxdzEoi/qoNRaDO/0TFfVPiSpv5reJvViiJaQR rieoMCJdDV/0BhQWMCpWBSOH5+TdGVXgbfd9/TuMsTeHXyjlHG3ez5C+QihRJtIuXX/H ed04eHlBE13UBkPkdpAGilUkXwmh+18/u69Eid6UI8uy8Y859aYaxmmTcvcJdBuTg1kG RHvzVbon5yVQ4wgN4phbToFVXvCw+X7V3ILG3LGrOmCsjNPG3vY+eAK0V9CJ8pzkUdtV Rq6A== X-Gm-Message-State: AOAM533dYP0nWE+GeyXoEK3YgVb7Q8H0j6DbM4wVg0sQm5EYhNNluG7C QzXWlIcut5XxwiCTKalLv8fW6TEJ5UAyBCWB X-Google-Smtp-Source: ABdhPJzjlWpeS9IpE0N0oxSzPqYw6RzpFIBOM0VAlQ+tYB6Xa8xBkUbBqO/ybvXG6nXW+anClZReyA== X-Received: by 2002:a17:90b:1b46:: with SMTP id nv6mr2114653pjb.45.1614825123850; Wed, 03 Mar 2021 18:32:03 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id k128sm26255511pfd.137.2021.03.03.18.32.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Mar 2021 18:32:03 -0800 (PST) To: Eliot Lear , rfced-future@iab.org Cc: Brian Rosen References: <07F20D85-D894-4848-90B5-2ABA8146BAF6@cisco.com> From: Brian E Carpenter Message-ID: Date: Thu, 4 Mar 2021 15:31:57 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <07F20D85-D894-4848-90B5-2ABA8146BAF6@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Where we stand, doc editors sought, and doodle X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Mar 2021 02:32:07 -0000 "Return to working group" works for me. Regards Brian On 04-Mar-21 06:54, Eliot Lear wrote: > Greetings, Colleagues. >=20 > This rather large message addresses the following points, which are top= ics we expect to cover next week: >=20 > * Where we stand on Issue 15 > o Addressing what is permissible to block at the AB level. > o DISCUSS/NO and tone > * Document editor search > * Look out for a doodle >=20 >=20 > As you have seen, the minutes from our last interim are posted, and we = got through a substantial amount of the proposal from Adrian. =C2=A0We ha= ve several big issues to work through a bit more. =C2=A0The first ones we= think we should continue to address are these: >=20 > Step G in Adrian=E2=80=99s proposal, and specifically the grounds for t= he advisory board returning a draft to the working group for further cons= ideration. As the issue stands, there are two points of view: one states = that members may only do so in the narrow interests of their streams. =C2= =A0The other states that there should be no such restriction. =C2=A0In co= nsidering approaches to reconcile these two positions, the chairs encoura= ge all members of the group to be innovative in their thinking. =C2=A0 We= ourselves are optimistic that there is a solution here that does not str= etch the imagination too far. =C2=A0EKR and Joel kindly have offered to g= ive this some thought, but as we discussed in our last virtual, everyone = is welcome to make a proposal. =C2=A0Lingering in the background is the r= elationship of the RS[EA] to the AB. =C2=A0People making proposals should= keep that in mind. >=20 > There was lengthy discussion about =E2=80=9CDISCUSS=E2=80=9D versus =E2= =80=9CNO=E2=80=9D, and what happens. =C2=A0 While we note Peter Saint-And= re=E2=80=99s point that there is running code for DISCUSS, we note the di= fference between this proposed WG and IETF WGs in that every AB member is= expected to participate; and we *think*=C2=A0the rough consensus is like= ly to be that AB members are expected to participate in work group discus= sions, and make their concerns known in that process, rather than the IES= G process of reading the document during IETF last call and raising DISCU= SSes then.=C2=A0 =C2=A0If a proposal reaches the AB, the AB=E2=80=99s dec= ision process should not surprise anyone, because positions should be kno= wn. >=20 > There is an issue about tone. =C2=A0Nobody likes hearing NO, and Adrian= =E2=80=99s point about the presumption of moving a proposal toward approv= al is not to be taken lightly. =C2=A0Therefore, rather than using the wor= d =E2=80=9CNO=E2=80=9D, we suggest =E2=80=9CReturn to working group=E2=80= =9D. =C2=A0We think it quite rare that a draft will actually be returned,= but more likely that differences really will get worked out prior to tha= t point. =C2=A0An AB member who surprises the WG would not be doing a goo= d job. >=20 > So=E2=80=A6 Discuss (cough)? =C2=A0 >=20 > The chairs are going to renew our attempts to actively search for a doc= ument editor. =C2=A0Do not be shocked if we come a=E2=80=99knockin on you= r door, and whining rights about editor selection of those who themselves= did not volunteer shall be suspended ;-) >=20 > Finally, please note the doodle poll that will come out shortly for the= interim following the IETF 110 meeting. >=20 > Brian & Eliot >=20 From nobody Wed Mar 3 18:34: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 A59C33A0BA8 for ; Wed, 3 Mar 2021 18:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=UsYjsfFT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GXVFCmgl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IYpF3ybii857 for ; Wed, 3 Mar 2021 18:34:35 -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 EB8F43A0BA5 for ; Wed, 3 Mar 2021 18:34:34 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id EA45A5C00B6 for ; Wed, 3 Mar 2021 21:34:33 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 03 Mar 2021 21:34:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=NwT3U 2LDmxlICC1rsog6WgcYZ4p85zTkOxLsHfU+hm4=; b=UsYjsfFTHqGMUuAKIBCnO OuEEp8NlpmflVhdQhI0e5tRAodUyz3BEsR8ho4WbUPFWFIkIgkDBPRQV+sNYokHA 80ulgSS2EBVDsWtHXhb0LQwjyAWA+NR62KbXyLiuYIHH94tj32+r5Un2TKVVNgcv XNdGYk2LATPhTK2HwweusI3+JPiUqTj93KxkditqNAWb0Zv++TnaRbT4QIggYzhD BA8WnziOznr0AqLRkji7hajcjj8fS1/1L1d+kQ6eDYMJAS7j3m+MYADNF7WvIMJa D3gPYSsf6FmfXQIraJX/OLz1DxaAYj4TL20+F/vMOt6WN4pfKVsZnyQbKx38PYzW 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=fm2; bh=NwT3U2LDmxlICC1rsog6WgcYZ4p85zTkOxLsHfU+h m4=; b=GXVFCmglYRPFEeYsjqqM/DcN5s5m+yMpVdhqUju+8JqXLu2HmektvDwqB ekj0DznDZPCg7t+4x6NrB8IXjdKHP3CZqDxs3y/7pPc1NdKSm6M3ujX/gZ+jTTcJ RRRrSV5yHo940cKZtg77o/3qg69MJz2BqZGiK58GrazQIsnnkXEO8feyBJYRBJnK +yKzBxhF9z2l/EQViIhdn+TpRm3MU2UPD8OwmJyxU+qW5IRUkGZLu/m1re6MwM1x 22EbxPXnu6Yvqv1aSKYp/2fn1yhrN6s5atTzvG6HJWD+djw2n7xbEcZ5OKR7ZF2x PwSD5/BSr5LaL+Il3ky348Lu2swEg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddtfedggeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgefftefhteejgfejhf fgfeevjefhffffffefhfdtgffgjeeutdelteekveeuudetnecuffhomhgrihhnpehirggs rdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5BC2D4E086A; Wed, 3 Mar 2021 21:34:33 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: In-Reply-To: References: <07F20D85-D894-4848-90B5-2ABA8146BAF6@cisco.com> Date: Thu, 04 Mar 2021 13:34:13 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Where we stand, doc editors sought, and doodle X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Mar 2021 02:34:37 -0000 Likewise. On Thu, Mar 4, 2021, at 13:31, Brian E Carpenter wrote: > "Return to working group" works for me. >=20 > Regards > Brian >=20 > On 04-Mar-21 06:54, Eliot Lear wrote: > > Greetings, Colleagues. > >=20 > > This rather large message addresses the following points, which are = topics we expect to cover next week: > >=20 > > * Where we stand on Issue 15 > > o Addressing what is permissible to block at the AB level. > > o DISCUSS/NO and tone > > * Document editor search > > * Look out for a doodle > >=20 > >=20 > > As you have seen, the minutes from our last interim are posted, and = we got through a substantial amount of the proposal from Adrian. =C2=A0W= e have several big issues to work through a bit more. =C2=A0The first on= es we think we should continue to address are these: > >=20 > > Step G in Adrian=E2=80=99s proposal, and specifically the grounds fo= r the advisory board returning a draft to the working group for further = consideration. As the issue stands, there are two points of view: one st= ates that members may only do so in the narrow interests of their stream= s. =C2=A0The other states that there should be no such restriction. =C2=A0= In considering approaches to reconcile these two positions, the chairs e= ncourage all members of the group to be innovative in their thinking. =C2= =A0 We ourselves are optimistic that there is a solution here that does = not stretch the imagination too far. =C2=A0EKR and Joel kindly have offe= red to give this some thought, but as we discussed in our last virtual, = everyone is welcome to make a proposal. =C2=A0Lingering in the backgroun= d is the relationship of the RS[EA] to the AB. =C2=A0People making propo= sals should keep that in mind. > >=20 > > There was lengthy discussion about =E2=80=9CDISCUSS=E2=80=9D versus = =E2=80=9CNO=E2=80=9D, and what happens. =C2=A0 While we note Peter Saint= -Andre=E2=80=99s point that there is running code for DISCUSS, we note t= he difference between this proposed WG and IETF WGs in that every AB mem= ber is expected to participate; and we *think*=C2=A0the rough consensus = is likely to be that AB members are expected to participate in work grou= p discussions, and make their concerns known in that process, rather tha= n the IESG process of reading the document during IETF last call and rai= sing DISCUSSes then.=C2=A0 =C2=A0If a proposal reaches the AB, the AB=E2= =80=99s decision process should not surprise anyone, because positions s= hould be known. > >=20 > > There is an issue about tone. =C2=A0Nobody likes hearing NO, and Adr= ian=E2=80=99s point about the presumption of moving a proposal toward ap= proval is not to be taken lightly. =C2=A0Therefore, rather than using th= e word =E2=80=9CNO=E2=80=9D, we suggest =E2=80=9CReturn to working group= =E2=80=9D. =C2=A0We think it quite rare that a draft will actually be re= turned, but more likely that differences really will get worked out prio= r to that point. =C2=A0An AB member who surprises the WG would not be do= ing a good job. > >=20 > > So=E2=80=A6 Discuss (cough)? =C2=A0 > >=20 > > The chairs are going to renew our attempts to actively search for a = document editor. =C2=A0Do not be shocked if we come a=E2=80=99knockin on= your door, and whining rights about editor selection of those who thems= elves did not volunteer shall be suspended ;-) > >=20 > > Finally, please note the doodle poll that will come out shortly for = the interim following the IETF 110 meeting. > >=20 > > Brian & Eliot > >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > From nobody Thu Mar 4 09:31: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 19F543A1189; Thu, 4 Mar 2021 09:31:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAIPiJHHr1kf; Thu, 4 Mar 2021 09:30:57 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01483A118F; Thu, 4 Mar 2021 09:30:57 -0800 (PST) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 124HU0n7029063; Thu, 4 Mar 2021 17:30:31 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 : mime-version; s=jan2016.eng; bh=zvLAXTfFK3GR/JE2P9xGwf+E3WtixUj5ntbe4FwJXpQ=; b=mZtti5tLZWrpG9818ItDklPCnH4TUeYPUjKhtml5KXnrDdSlm5tesyaSmk+AtFY9tx62 3ngw+IwsWDvx35GOPUwPh5VhZib9zab7Y9TImnc9Fm/qh5Uvg7Or8OwDOE5TToSjCZ0p fjDHfQ+jBtaWVqzHz9MGW3xROB572Qx1WWw0dOPUj4f8cy1MK6A7M5AhzbGqsQ4U+F9A ibkgS+Q+wSla66pSGam46AFeWw8Sit6ix9JV/Bx39iK2kurt+szXeup80ViPKhzYmqCa rM2rW55OUlF0huqJ3nAo8rj+BtANMey1vYgbgftxYhdhYGO9J4Vc50UkYGTWsj3f5XMM JA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 3732f0uhbm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 04 Mar 2021 17:30:31 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 124HJlLa027635; Thu, 4 Mar 2021 12:30:30 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint2.akamai.com with ESMTP id 36yja4uky7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 04 Mar 2021 12:30:30 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 4 Mar 2021 12:30:29 -0500 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1497.012; Thu, 4 Mar 2021 12:30:29 -0500 From: "Salz, Rich" To: Eliot Lear , "rfced-future@iab.org" CC: Brian Rosen Thread-Topic: [Rfced-future] Where we stand, doc editors sought, and doodle Thread-Index: AQHXEFZa4SPR0UpdpUeFJ/eP3A/8vap0F3eA Date: Thu, 4 Mar 2021 17:30:29 +0000 Message-ID: <7F3B25CC-F9FB-4815-A89C-32466AB3F4AF@akamai.com> References: <07F20D85-D894-4848-90B5-2ABA8146BAF6@cisco.com> In-Reply-To: <07F20D85-D894-4848-90B5-2ABA8146BAF6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.46.21021202 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_7F3B25CCF9FB4815A89C32466AB3F4AFakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-04_05:2021-03-03, 2021-03-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxscore=0 mlxlogscore=901 bulkscore=0 malwarescore=0 adultscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103040081 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-04_05:2021-03-03, 2021-03-04 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 lowpriorityscore=0 adultscore=0 mlxscore=0 spamscore=0 impostorscore=0 phishscore=0 bulkscore=0 priorityscore=1501 malwarescore=0 mlxlogscore=819 clxscore=1011 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103040082 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.19) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint2 Archived-At: Subject: Re: [Rfced-future] Where we stand, doc editors sought, and doodle X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Mar 2021 17:31:02 -0000 --_000_7F3B25CCF9FB4815A89C32466AB3F4AFakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGVyZWZvcmUsIHJhdGhlciB0aGFuIHVzaW5nIHRoZSB3b3JkIOKAnE5P4oCdLCB3ZSBzdWdn ZXN0IOKAnFJldHVybiB0byB3b3JraW5nIGdyb3Vw4oCdLg0KDQpJIHRoaW5rIHRoZSBjb25jZXJu IGFib3V0IHRvbmUgaXMgZXhhY3RseSByaWdodCwgYW5kIEkgYWdyZWUgUjJXRyBpcyAobXVjaCkg YmV0dGVyLg0KDQoNCiAgKiAgIFNv4oCmIERpc2N1c3MgKGNvdWdoKT8NCg0KSVNXWURUDQoNCg0K --_000_7F3B25CCF9FB4815A89C32466AB3F4AFakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjEzMTE1MTgyMjE7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xMzMwODgyNDQ0O30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxNDQ3MTEzNjEw Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoyMjM4OTAw ODQgLTE2NzQzOTI1ODggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2 OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1s ZXZlbC1zdGFydC1hdDozOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBsaXN0 IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3IixzZXJpZjt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13 cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Jm5ic3A7VGhlcmVmb3JlLCByYXRoZXIgdGhhbiB1c2luZyB0 aGUgd29yZCDigJxOT+KAnSwgd2Ugc3VnZ2VzdCDigJxSZXR1cm4gdG8gd29ya2luZyBncm91cOKA nS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgY29uY2VybiBhYm91dCB0b25l IGlzIGV4YWN0bHkgcmlnaHQsIGFuZCBJIGFncmVlIFIyV0cgaXMgKG11Y2gpIGJldHRlci48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzIiPlNv4oCmIERpc2N1c3MgKGNvdWdoKT8gJm5ic3A7PG86cD48L286 cD48L2xpPjwvdWw+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklTV1lEVDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_7F3B25CCF9FB4815A89C32466AB3F4AFakamaicom_-- From nobody Thu Mar 4 10:35: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 4CBE33A13FF for ; Thu, 4 Mar 2021 10:35:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIsOToToHRjA for ; Thu, 4 Mar 2021 10:35:27 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 471403A1403 for ; Thu, 4 Mar 2021 10:35:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1665; q=dns/txt; s=iport; t=1614882927; x=1616092527; h=from:mime-version:subject:date:references:to:in-reply-to: message-id; bh=jPPjDPkK9lG0BYvGNe/KfAqFmNuO7ziiiXBgUkw6Cdc=; b=l5rlA3fPNOKEK1BtRj6YsksAWr6F+5iJyQAtRkKO/u2L2N+e5ioTFYgY 59xdUTc6gWbHYZ8O4oB4H2bCCcrByFzQwwJPG7j+688S3ooO6gdRdGYyB jQSx6qsRSb3z+V19h1Lag/9YEazS6p6mWDKcX7LnvlDEd9RviGKtjiKxr 8=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0D4AAAPKEFglxbLJq1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4MhVgEnEjGEQYkEiFicSwQHAQEBCgMBASgMBAEBhE0CgXsmOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DYZEAQEBAwEjWwsLGCoCAlcZgnABg?= =?us-ascii?q?mYhD64FdoEyhD8BhhMKBoE4gVOLcEKCC4E4HIJXPoJcBIIrgkk0gisEgVRyg?= =?us-ascii?q?SsQZp55nFODBoMvgTyEVJJhAx+DJRKKT4VPkAGgEpJtg3MCBAYFAhaBayGBW?= =?us-ascii?q?TMaCBsVZQGCPj4SGQ2OOINWilpAAy8CNgIGAQkBAQMJjBMBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,223,1610409600"; d="asc'?scan'208";a="33859437" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 04 Mar 2021 18:35:03 +0000 Received: from [10.61.144.38] ([10.61.144.38]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 124IZ2Uv022011 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 4 Mar 2021 18:35:02 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_18E6526E-5D1C-4F32-85C2-482688A39A52"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 4 Mar 2021 19:35:01 +0100 References: <013DF9C5-FE9A-4433-A8AB-F0748F95084D@cisco.com> To: rfced-future@iab.org In-Reply-To: <013DF9C5-FE9A-4433-A8AB-F0748F95084D@cisco.com> Message-Id: X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.38, [10.61.144.38] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Doodle for April Meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Mar 2021 18:35:30 -0000 --Apple-Mail=_18E6526E-5D1C-4F32-85C2-482688A39A52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Ah=E2=80=A6 it occurred to me that I didn=E2=80=99t say when we want to = finish the poll. Let=E2=80=99s say Monday 17.00 GMT. Eliot > On 3 Mar 2021, at 19:19, Eliot Lear = wrote: >=20 > Signed PGP part > Hi everyone, >=20 > Please note that we have had it good for the last few meetings in = terms of timezones working out. As DST transitions begin to take place, = it=E2=80=99s a little trickier. Therefore, please do doodle[1], but = please also do raise concerns if you would rather we had some additional = options. We have time to change course if needs be. >=20 > Eliot >=20 > [1] https://doodle.com/poll/4xhvs8bzmiggw5d5 >=20 >=20 --Apple-Mail=_18E6526E-5D1C-4F32-85C2-482688A39A52 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBBKFUACgkQh7ZrRtnS ejNBJQgAv4OkAWPWTvqJujgDd/11fBbOtU7SV0VbzZp97l0gqrzGYQJ1fmvOUpjw SrARZhyuAymRfmn1CF59xlp7exQg1cWyiUckQqHZVQlg4DpoIM4iLGE0mst45W7D ER/R4wzwwqHREje5qhKNC/aVi2Oh7mCKUbpqJv8WX5Y29/ZDdHoXyuHk2NzJ1WJL 34grYne7ubtkkxJMKWNbHEXqnvFP6pRaG+7nN1RCXGgynhpzi/3qxfgB+lMgEwWF HDz9qfKnVyedU6ktYke82Pxy6qypNgZCbMue4CxLqeeofAldQ4U/BXEuKUHA9c08 GBRB0ImBY78HlN/gLbeKXpCoWxc1sw== =dge9 -----END PGP SIGNATURE----- --Apple-Mail=_18E6526E-5D1C-4F32-85C2-482688A39A52-- From nobody Mon Mar 8 06:16: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 5DE443A2AC0 for ; Mon, 8 Mar 2021 06:16:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SkbJhQXrYR9 for ; Mon, 8 Mar 2021 06:16:09 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4FB43A29A3 for ; Mon, 8 Mar 2021 06:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=995; q=dns/txt; s=iport; t=1615212969; x=1616422569; h=from:mime-version:subject:message-id:date:to; bh=fte7naztnwI4HXsB9kZkpbH1h+5uGjPo5glfOj/qs3o=; b=gGwj+cG4lP6iQYdCRm4WfDYrKIsTCW3/uVtYcScgOMK0x+3JN3AQu4Dm jY1Ghga0JbQRaNsWAd+I0isQKk+dihhfYB/HCfZLdyiy2JlygUZl9uHkW ciL9nCp4JROKAmST4iXHDBSkSu5+OQGWw/Xj6rH3JbGP4Z+857bebKlGc 4=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CwAADqMEZgjBbLJq1iHQICCRQFBUGBPAcMAQGDdQEnE?= =?us-ascii?q?o12mTiJc4FpEwQHAQEBCgMBATQEAQGGSiY1CA4CAwEBAQMCAwEBAQEFAQEBA?= =?us-ascii?q?gEGBBQBAQEBhkdDAQEBAwcEhhCFIQGDB54ajhx0gTSKQRCBOQGBUocJhSiCC?= =?us-ascii?q?4E4HIIqAYV1gn2CKwSjbJxagwgEgyuBPJc7Ax+DJwGQNJAQsxSDdQIEBgUCF?= =?us-ascii?q?oFWATWBWTMaCBsVZQGCPz0SGQ2OKw0JjidAA2cCBgoBAQMJhASDLId2AQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,232,1610409600"; d="asc'?scan'208";a="34010612" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Mar 2021 14:16:06 +0000 Received: from [10.61.144.54] ([10.61.144.54]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 128EG6C9031142 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 8 Mar 2021 14:16:06 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_4851AA18-D6F1-4EB3-B627-D9C3D4DFF8DB"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <4E33FFB6-C337-4EEE-8DD3-8D833C03E3EC@cisco.com> Date: Mon, 8 Mar 2021 15:16:05 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.54, [10.61.144.54] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] Minute taker needed for tomorrow X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 14:16:10 -0000 --Apple-Mail=_4851AA18-D6F1-4EB3-B627-D9C3D4DFF8DB Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Customary fee paid ;-) Thanks, Eliot --Apple-Mail=_4851AA18-D6F1-4EB3-B627-D9C3D4DFF8DB 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBGMaUACgkQh7ZrRtnS ejNLZwf9F51cyEmWvNqH1ipNyXNwGTS6hqHgGSbrqgIWxEZ6253y4zGmRb4iYq8M mcKjHWMLi0LAcSYpt+Ex3lpfu6e/BdoRSI7sfLw9KpEkZYSZNMF68n+8TKWJw3UV KPRWwl0EzMVlveD7DDoODAf2N6qDXUhqp2hNKbLqIwtjBRsB22X1fl+Mmis0qv7g lkLTOnmdHMGabN1uvOvh0iRde45+D+vo137IcX6fJr7Nz85Mhbk+494X8n48wusE x+nMJ556d2WpFHVd3ZZhiO0vYFChTAIwSkVCqE0wIATHhX2wWl06YTYV7+qrr10l PvN3nFPR8BCXzpKIjUduPaBcLpSq/g== =Ve2v -----END PGP SIGNATURE----- --Apple-Mail=_4851AA18-D6F1-4EB3-B627-D9C3D4DFF8DB-- From nobody Mon Mar 8 15:44: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 2C5153A1A06 for ; Mon, 8 Mar 2021 15:44:55 -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.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbp3A1STqGCq for ; Mon, 8 Mar 2021 15:44:54 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E768C3A1A09 for ; Mon, 8 Mar 2021 15:44:53 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id a9so11262534qkn.13 for ; Mon, 08 Mar 2021 15:44:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=mLP2OA8jYaQAwTnN+4zbiFHM1DPUkxPrDcF0z21bRD0=; b=AsA72zuKm2KjTxkxKAzcaTjvRf8kwgpT1wSpMhl2urpwX2b4Fax2E4sl4qXT7kgMkp nb2FRPLPPPt/FX6kGcdTzGelxek4Z/gIczxxasQqWBlfKdcGblBqCUZ7MPGNM1WVwZXh Ka2Hf4Q9fLGEGLwdoKf+35spwgNkr+mx8Qb+YUobBXmnLEWg5n1Q64jjzctalNozqVvj QFUiRKdjcYNurr85eWW6iwhLKi/O13LEN/43O8kiKSCeOpjO1VJzKshTA4OJBE7pXcrd AhOYqF8vJjCNVcXj3uU6utBZUbnqNIz2KrHMDUqGwUeObhhBYbYOwy57mWXIok7r/WXo BWdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=mLP2OA8jYaQAwTnN+4zbiFHM1DPUkxPrDcF0z21bRD0=; b=c6xPbq+7WfjlNONkHnCSDkEvNEfYniJxvUOkBjFgw++N6Lqd3CMdyRPUsv0PUItXRH 9oIFSbsYx0k5NlKpOgqGKsxvWWQvO63eE5H/Fjwmmia5UIIti0Yw3Z9kf45HnMOIgkDR 4vis5v2EAjnS6LIqgAzhsIHYQwN4lbmZjtrEZYUdvJhQfivx4PBaHSRfZWiCDiiawxbY 4hnuYTOef17Uqirsg0jwY/zn2pNudxT+9qMcaItz0SGx3NTqEV0xd3ZlA+I/FG2FtWXX GK6z5FxbpZYxjJWdAcvXBUmYu50N5TDmQC6IWhYO+mSZS2nOVDnVhnFJRXy9xQuNiKvg Vefg== X-Gm-Message-State: AOAM532vZX/vQStFI7MhwNtMPjgxSBYwbdFu2EvTZGKt97M4/kXPwgLp ZFqoxaaedn0famR/gBbMYjFAxfD177OtHkWWxH4= X-Google-Smtp-Source: ABdhPJw5PrLg7atBsD/Dr6HddpfgcDxTVOSuYsJ98vI+7/hJv6nVonUiUwweWgfdoDnxMGhVRNPGTg== X-Received: by 2002:a05:620a:248e:: with SMTP id i14mr23205446qkn.245.1615247091696; Mon, 08 Mar 2021 15:44:51 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id a9sm8616135qtx.96.2021.03.08.15.44.51 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Mar 2021 15:44:51 -0800 (PST) To: rfced-future@iab.org From: Michael StJohns Message-ID: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> Date: Mon, 8 Mar 2021 18:44:50 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Mar 2021 23:44:55 -0000 Hi - This is certainly not something for long discussion related to the model, just something that I thought of that might be a useful set of deliverables for the future RSE/A/whatever. In a long ago discussion, we had various discussion/rants about the spaghetti like nature of certain of the standards families (TLS and DNS spring to mind) and the difficulty for someone reading RFCs without IETF experience to figure out which RFCs are actually necessary to build a working protocol engine. Perhaps one of the great services an RSE might do is to write a series of "Welcome to the DNS protocol suite - would you like instructions?" RFCs that actually attempt to describe how a particular group of RFCs relate to each other.  As has been noted elsewhere, these are probably not documents that would attract enough volunteer hours to create.  They would also be somewhat formulaic, and ideally more an annotated bibilography than a new set of standards documents. As I noted above, this is just a side idea to be ruminated on rather than anything to feed into the endless maw of the current discussion. Mike From nobody Mon Mar 8 20:00: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 231163A0DEA for ; Mon, 8 Mar 2021 20:00:22 -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 1b1NVU6Cy-QE for ; Mon, 8 Mar 2021 20:00:20 -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 A70943A0DE4 for ; Mon, 8 Mar 2021 20:00:20 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lJTXe-000Ccf-UQ; Mon, 08 Mar 2021 23:00:18 -0500 Date: Mon, 08 Mar 2021 23:00:12 -0500 From: John C Klensin To: Michael StJohns cc: rfced-future@iab.org Message-ID: In-Reply-To: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 04:00:22 -0000 --On Monday, March 8, 2021 18:44 -0500 Michael StJohns wrote: > Hi - >=20 > This is certainly not something for long discussion related to > the model, just something that I thought of that might be a > useful set of deliverables for the future RSE/A/whatever. >=20 > In a long ago discussion, we had various discussion/rants > about the spaghetti like nature of certain of the standards > families (TLS and DNS spring to mind) and the difficulty for > someone reading RFCs without IETF experience to figure out > which RFCs are actually necessary to build a working protocol > engine. >=20 > Perhaps one of the great services an RSE might do is to write > a series of "Welcome to the DNS protocol suite - would you > like instructions?" RFCs that actually attempt to describe how > a particular group of RFCs relate to each other.=C2=A0 As has = been > noted elsewhere, these are probably not documents that would > attract enough volunteer hours to create.=C2=A0 They would = also be > somewhat formulaic, and ideally more an annotated bibilography > than a new set of standards documents. >=20 > As I noted above, this is just a side idea to be ruminated on > rather than anything to feed into the endless maw of the > current discussion. Mike, While I would very much like to see something along those lines, history suggests it would not be easy, as least without some rather basic changes in how the IETF does business. In particular... * The original purpose for assigning STD numbers (IIR, an RFC Editor initiative at the beginning) was to bind multiple specifications that, together, comprised a standard as well as to provide a stable reference as specifications were replaced. That idea largely failed despite because the number assignments were bound to documents at the Internet Standard maturity level and we have never been as good at getting things to that level as RFC 2026 and then RFC 6410 anticipated. Assorted proposals to work around that part of the problem by assigning STD numbers to Proposed Standards have been unable to get enough traction with the IESG to even turn into good discussions. (If anything thinks that attitude has changed, I'd be happy to re-post an ancient I-D.) * One of the main objectives of the late Newtrk WG as its work evolved was to create a framework for documents that would describe the standards for particular topic areas and tie the relevant documents together with some explanation as to how they would fit together. IIR, annotated bibliographies were one of the options Newtrk considered although it rapidly concluded that more would be need. IMO, there were two lessons from that experience. One was that the IESG felt that it needed firm control over what such documents might say and what documents to link together (there are lots of edge cases where documents overlap into different areas as we discovered again for procedural documents during the IASA2 WG work). The other was that the IESG concluded that would require more effort than the results would justify and therefore declined to let the WG output documents go into IETF Last Call. So, yes. And yes it is a problem. But, unless things have changed more than I think they have (and for the better), I cannot imagine the IESG allowing an independent person (and LLC contractor or employee) to do that job, at least without Last Call and extensive final nit-picking and expressions of personal preferences on each document. I'm not even sure they would be wrong if they took that position as such things probably should represent community consensus. best, john From nobody Mon Mar 8 21:47: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 AB93B3A1331 for ; Mon, 8 Mar 2021 21:47:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uA3DfNDEdAGn for ; Mon, 8 Mar 2021 21:47:46 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410134.outbound.protection.outlook.com [40.107.141.134]) (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 219F93A132F for ; Mon, 8 Mar 2021 21:47:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cjv1fYvea/HQwcWetSH9O4sInYbd4XQ42NrXz+dkO86U4BEZN7ROeXv1tC/DYGrXpq150Lj2sbNvv6AXKgHW+yrPsoJ1F+rqETYHZxnpYECEzlMxBMBo+PvLLU2cL9BbIibrhuMdTFtYczr6xu53FchLqr4AvCRHXz8V2LoCdmzU3UmWOYV/JQEb3IHN51EwgxmQ/ke3NT0np9XFchRPcaB/1E/6fT2F4n2FTVcY2Ln789jCURoScZWQlSsDf9xfU6iP5wW7oahrClrEcdHZH2qz1G/pqbOxcMZkDWP4dycBlR2qVk93/m3OxBjxZX8IsXF9OKZKhLLfz3ZmLGHa9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=juUlGtFXa/d2HNVx1DvjmqRhwVV4crBJkBm9FbNKBBE=; b=MpdCmXx6fzk9MFa2dy9VuwcDr48LUhkBwcCkYFg8wuPDnil/xHKQ4G69tHhPmV9rEByYc2OX3/IYcaD/J7t+jassDP7mwkr++3A5lDlhbPamlLSfsXlT1zBodCxctleaoRGukwruwqYkW7RA7/TWjxcj//Qd8lvQs6W7Y9RuTWlfPtG2QkUvsh8ES2eGwAy1BhigN3c+x7iWutwScKoeOQV0QUzbNKQqtR6+zxgHrYbXy2rGNRmio/f6Mh5bwzziW6TAQcytZr0MI7EeRfhRKPo3hdLda4UPMPt/Hr7b2xx0tB7BsBEsnUfQ5mBms9GtOf1JNOypIoNQoiQEJD6xWA== 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=juUlGtFXa/d2HNVx1DvjmqRhwVV4crBJkBm9FbNKBBE=; b=AbtPu4fsVq/LxYis+QcvC49tqnvrSf9TanH47t9DfLPr0BN0iYVkKUpq+0hYYpjrsiUqIeH98oYYwsOEueH+OuqCEQKBtUl47S8TSKgRKPJ/oS7ae1wPEa4a78Pmo4cTEioYKZe6a6lxUJXBAgPWab0NiRdoImSId8mjWHq2fBY= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB6074.jpnprd01.prod.outlook.com (2603:1096:402:37::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.19; Tue, 9 Mar 2021 05:47:40 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2%4]) with mapi id 15.20.3912.027; Tue, 9 Mar 2021 05:47:39 +0000 To: John C Klensin , Michael StJohns Cc: rfced-future@iab.org References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <664f4b0e-d817-f844-c85a-b3e44d5b6282@it.aoyama.ac.jp> Date: Tue, 9 Mar 2021 14:47:37 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.83] X-ClientProxiedBy: TYAP286CA0024.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:8014::11) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.11.2] (133.2.210.83) by TYAP286CA0024.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:8014::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3912.17 via Frontend Transport; Tue, 9 Mar 2021 05:47:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: cee5637e-2d5f-403c-6728-08d8e2bed9a4 X-MS-TrafficTypeDiagnostic: TYAPR01MB6074: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: C6p1K4y2ZibFPOEDMrYc9ZHVMP150TEJ2cQOULTcmTSXLzT5PaokEAlFhcI1StAi3acXR1PHdLbBcf8RoCeoYZxCQhusD6ZLeFnja0+xc7PXhasdoe/CsT2T241G1vhN87RVnHGSWHKNzX7deNt4aCiopGAR5cNEhB/z8K21awdd0J9K/DX4lp/UC1I4G6igU/CRVnTzDyQtmMojJSpXT9kJnO6RuUSOAS1a6q9iHMlt7yC/wt8geX5MW8Nqyh1S1Dh0BYXEGRtubpYUTgWmkuLFOWJk5VZxoheDR0pfjA2e32HYT8zflEhNMjANjUrq1VfrsXJnISGPLfx3mLLsOX7qE2wH8YEe/LhWcnbIQVx1avDFDdSY6M+F4wudlxoRHI1FguqknzuorAK0sn9R1Wj8Mf9G7mGagJ53QSOgZ+CwV3SizhhXqS4qLAseLVf96Rmis7e/AqKZrxsinR3UMXhEG6vOZE3txCeKInebaxHnFcG3GTSiQAsVNQO5ECXuM//ugKZXSTAAELDV+8AyAiDi6wWqrvpIff55QDIwICoERhqm38Nhx835MQwT9dp0jPFtZo4f5V+li8NP0TDcPcrFhWS0Z1TyphRLWcEm+tk= 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)(396003)(39850400004)(346002)(136003)(366004)(4326008)(110136005)(66476007)(26005)(186003)(16526019)(6486002)(8676002)(83380400001)(66574015)(5660300002)(2906002)(86362001)(8936002)(66556008)(66946007)(31686004)(53546011)(2616005)(36916002)(52116002)(16576012)(31696002)(316002)(478600001)(956004)(786003)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?RmMveCtQZmNEdEVIMW9takJzdVE1bzNkeVhibnp3ZXIwYWtnNWp0TXVZN1hk?= =?utf-8?B?TWxobHlBWWpGVEgrQnRHZStoV2ZTNDhSZHZTZEsyNStVWVptSXNYTDRxVXEr?= =?utf-8?B?a1JsaGJiUXBjeldQUktJYmU4V3I2bVNYVFJEdzZBclhpY2QyQUN6Z0Q3Unda?= =?utf-8?B?QkVMTHJhRWNFTWR4RGZVc0E3Qm1nM2dqMDl0Y3F1VmErd1BoTzdQa2djMmhV?= =?utf-8?B?VVZUZGozbU0vMkJGNTBGVTZ4eUk0RW9rR2l2aUt1QUJyeFlSdHIzWjA5NE9D?= =?utf-8?B?RG1xaUdVUjdhMlUweFNzaVhONUFVNGFmRENxV040R0cxUkF6NnpFeWRQcmFo?= =?utf-8?B?OXhuNEEwZWxQcURYbFl3WnhQek4zZDZEZ3gxdE82WEgzR002Y0hoelkyMWxS?= =?utf-8?B?eHBwbm1uV0hJcnVsMDlVYW44RlFwYktEQXlkclA0VXBmUlNqeWlrRHdSUklU?= =?utf-8?B?TE1BWjBuMHExVzEzTjZOV245YmFmQkZ4V0FWV283Sm4yTlRnTGlkYlU3MFhP?= =?utf-8?B?a2NKbXNqaHprazFwTE44Vm5Lak1tMlNMNW9NeU5YSlpkazFOcEo4dzJXb1dK?= =?utf-8?B?NkQxN3NTYy9QZ3BPbzFjNjNqNDU0ZFFpUXR4ZEtxU2JISG9WcGJnN2ZwSGR6?= =?utf-8?B?UEZmZGgvb1lEbUdoQ1FaNUpYV1Y4K2g5Nk9RYjlMaUVUT1Vnczd5dUg3YUpj?= =?utf-8?B?RFE3TW1waWlJM01lOXo3VjlDcmZyWHlNTjZKWVJDME1vWSt5MU9zL1d3eWtr?= =?utf-8?B?Z3hZQmF0YXUyc2E2c2hTWGZraWhieXZ3VWszSDhBTmgyWEpPQm9NSGJpZU00?= =?utf-8?B?U2o0dHdVdlJIcFlib0ltbzZ5dHFjcllaaU1SUzZvYXJycEhBdUp2SzZwZjBo?= =?utf-8?B?SUMvek1PZTlRL2psN0NDMGcyZFVhSUdPeGlHenlsVW1XMFZGdUNLV3hxcFMr?= =?utf-8?B?c0tDMGZNZ2JRRWpQS1M1dkVFTzBLSExnVHJoQnpiVjNWdnVVS2ZoQTV4ZXQy?= =?utf-8?B?MVZ1YzNIQzRpbUtxM2NoOTdocDdUaldxUld1T0ZUazBHYm4rQk4zTFBMMFhQ?= =?utf-8?B?VjdjVVZ1QTFmdGZ2ZFVFb2NuZWpWWTFneEFIb1BGVUN4R3Z0bjdlS0hHaDNu?= =?utf-8?B?RlVqUkNSeGNHbHRrM0tEL2VpQXFZWENsZTg1WU80WmJQdnptV1JYN3lUOXNT?= =?utf-8?B?NEp6OWY3TnhEV29ESStUTUdueU9vK3BqVW4vVTVTdlVsd2NoNVA4YlFuVEpL?= =?utf-8?B?VzU3czhPUkROcVFWVnlqRzV3VWFSeW55bkRvbnpHOEJNOUVsZHNmMGdQaFVy?= =?utf-8?B?RWVLdkQ1UzgrOTc3czdDdlZtanJNREI0eEJQc2djSExtTDBYR2pmRE1xRE9r?= =?utf-8?B?bnV1Y005MTZlNzc0eWJyUVJnYndybzRvdEVlaFJaSUFJOWJRK2tuZ1NMYlpI?= =?utf-8?B?emdrZWR2d1lyQWx5YlZIcU8rS2xTc3lFYmdUeFY1WThmalZROTY2ZlRWN1M3?= =?utf-8?B?S0hvcmVPNGFBeURRVFJ0M3oxMWl4UXhEN3R3OTIyUGZIZmUzbm5Pa3JzOHhT?= =?utf-8?B?eFZPZXJTWkE3OHB6RWxjY1g5U3lQWTZxaDYvSVpINjNOTE90UXNGbnhqdC9M?= =?utf-8?B?TFhqSFdjVFJmL1pHeHNjZ2l3Qkx0R1M4TnViVXBZVER6Z2lGMXRzb2pNSC85?= =?utf-8?B?NVN5L1RJcENZRmRlbDBwY2N2eTRWanlMYktpdnREMkVTNHhJNHlEYy9iVGpG?= =?utf-8?Q?WDr50Y4z52v0o0+FxqmtRXiYbx+fdXtVj/ywygW?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: cee5637e-2d5f-403c-6728-08d8e2bed9a4 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Mar 2021 05:47:39.8069 (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: MBqAU3TCJ2tQwghklBIp6SH8yoGaTwWSsUQT5avqJt/huwnw+mro+Q7fIgl7y9hUXG7bkH1jGOilreIHhwZZ4A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB6074 Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 05:47:49 -0000 Hello Michael, others, To add to what John said, there are additional problems with your idea. One is that even for people quite familiar with some area such as TLS and DNS, it's difficult to figure out the exact boundaries (that's maybe a different way of expressing what John mentioned below when explaining that one would expect the IESG to want to be involved). Second, such documents wouldn't have such a long lifespan, because they have to be updated as soon as something changes (and both TLS and DNS are definitely still being worked on). That would also include the danger that a first version of such a document was successful, but there wasn't enough energy for updates. This could be even more confusing than the situation we have now. Third, and most important in the context of this mailing list, is that I think we have (something close to) consensus that the RSE/A/whatever should/will have expertise in technical publishing. However, my personal guess would be that such a person would have close to zero experience e.g. about TLS or DNS, which would not make them very qualified for the job you propose. Speaking even more generally, I think the job of technical publishing (starting with the editing of technical documents up to strategic functions) is quite different from the job of authoring technical documents (such as RFCs). Regards, Martin. On 09/03/2021 13:00, John C Klensin wrote: > > > --On Monday, March 8, 2021 18:44 -0500 Michael StJohns > wrote: > >> Hi - >> >> This is certainly not something for long discussion related to >> the model, just something that I thought of that might be a >> useful set of deliverables for the future RSE/A/whatever. >> >> In a long ago discussion, we had various discussion/rants >> about the spaghetti like nature of certain of the standards >> families (TLS and DNS spring to mind) and the difficulty for >> someone reading RFCs without IETF experience to figure out >> which RFCs are actually necessary to build a working protocol >> engine. >> >> Perhaps one of the great services an RSE might do is to write >> a series of "Welcome to the DNS protocol suite - would you >> like instructions?" RFCs that actually attempt to describe how >> a particular group of RFCs relate to each other.  As has been >> noted elsewhere, these are probably not documents that would >> attract enough volunteer hours to create.  They would also be >> somewhat formulaic, and ideally more an annotated bibilography >> than a new set of standards documents. >> >> As I noted above, this is just a side idea to be ruminated on >> rather than anything to feed into the endless maw of the >> current discussion. > > Mike, > > While I would very much like to see something along those lines, > history suggests it would not be easy, as least without some > rather basic changes in how the IETF does business. In > particular... > > * The original purpose for assigning STD numbers (IIR, an RFC > Editor initiative at the beginning) was to bind multiple > specifications that, together, comprised a standard as well as > to provide a stable reference as specifications were replaced. > That idea largely failed despite because the number assignments > were bound to documents at the Internet Standard maturity level > and we have never been as good at getting things to that level > as RFC 2026 and then RFC 6410 anticipated. Assorted proposals > to work around that part of the problem by assigning STD numbers > to Proposed Standards have been unable to get enough traction > with the IESG to even turn into good discussions. (If anything > thinks that attitude has changed, I'd be happy to re-post an > ancient I-D.) > > * One of the main objectives of the late Newtrk WG as its work > evolved was to create a framework for documents that would > describe the standards for particular topic areas and tie the > relevant documents together with some explanation as to how they > would fit together. IIR, annotated bibliographies were one of > the options Newtrk considered although it rapidly concluded that > more would be need. IMO, there were two lessons from that > experience. One was that the IESG felt that it needed firm > control over what such documents might say and what documents to > link together (there are lots of edge cases where documents > overlap into different areas as we discovered again for > procedural documents during the IASA2 WG work). The other was > that the IESG concluded that would require more effort than the > results would justify and therefore declined to let the WG > output documents go into IETF Last Call. > > So, yes. And yes it is a problem. But, unless things have > changed more than I think they have (and for the better), I > cannot imagine the IESG allowing an independent person (and LLC > contractor or employee) to do that job, at least without Last > Call and extensive final nit-picking and expressions of personal > preferences on each document. I'm not even sure they would be > wrong if they took that position as such things probably should > represent community consensus. > > best, > john > -- 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 Mon Mar 8 23:43: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 DFE9F3A1681 for ; Mon, 8 Mar 2021 23:42:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGLJdrwM8jgU for ; Mon, 8 Mar 2021 23:42:52 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 670283A169A for ; Mon, 8 Mar 2021 23:42:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4791; q=dns/txt; s=iport; t=1615275766; x=1616485366; h=from:mime-version:subject:message-id:date:to; bh=e9DlXlETTgWP9Ym87yKQZXC0N6ZqJtkZ7hHLLILQ0cw=; b=i0wvoT+h7PnzpWthX2c4w5UNqzQXNDzxpXpPRUcOVbhyxcXO/1il2eiB qm9Ql1zmR8O84P4I55bfXINz8LcB5hQXqAGbA3kHPQFQoU9rD44WTYuif DEAiqxoa14/aoIrZGqREBRY2W7R+on4SegrH0pbbWxaADpLbCFsWTQFgF E=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DIAQAtJkdglxbLJq1aHgEBCxIMhTBWAScShHKJBIhXl?= =?us-ascii?q?CuGNYFoBAcBAQEKAwEBKAwEAQGGTCY4EwIDAQEBAwIDAQEBAQUBAQECAQYEF?= =?us-ascii?q?AEBAQEBAQEBhjYNhm51PgKBBoJcAYMHD50zjhV2gTKKRgoGgTmBU4UqAYcHg?= =?us-ascii?q?guBESccgxaCXAKBJYEHgkk0ggkiBIMEJgRTIoEqBIEkkC+LL4EgnFyDCQSDK?= =?us-ascii?q?4E9hFaSZwMfk2CQEqAuknyDdQIEBgUCFoFrIYFZMxoIGxVlAYI/PRIZDY44g?= =?us-ascii?q?1aKWkADZwIGAQkBAQMJjWgBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,234,1610409600"; d="asc'?scan'208,217";a="33971743" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Mar 2021 07:42:44 +0000 Received: from [10.61.144.48] ([10.61.144.48]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 1297ghKe002204 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 9 Mar 2021 07:42:44 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_F9B48EB9-F237-45BC-8A91-E6E6EA13F829"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Tue, 9 Mar 2021 08:42:42 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.48, [10.61.144.48] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Doc editor: Peter Saint-Andre X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 07:43:01 -0000 --Apple-Mail=_F9B48EB9-F237-45BC-8A91-E6E6EA13F829 Content-Type: multipart/alternative; boundary="Apple-Mail=_2B82BA78-E6AE-4841-84E9-59D6C65F4809" --Apple-Mail=_2B82BA78-E6AE-4841-84E9-59D6C65F4809 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear colleagues, We have a volunteer as document editor for our work. Peter Saint-Andre = has graciously offered to take up the charge. For those of you who = don=E2=80=99t know Peter (I think most of you do), he is a former = applications area director, the large contributor to the Jabber = community, a long time IETFer, and the current chair of the RSOC. Peter = currently works for Mozilla. Peter will be responsible for documenting in =E2=80=9Ccode=E2=80=9D the = decisions that we have made and will make. He will work with the chairs = to make sure that the normative text he inserts is agreed by the working = group, particularly the Big Stuff, like the approval process (WG, AB, = etc), the role and name of the RS[EA], appeals, chair selection, etc. = He=E2=80=99ll be conservative about what he puts in in that context. He=E2=80=99ll also handle the non-normative and editorial changes so = that the document doesn=E2=80=99t come out reading like a camel (a horse = designed by committee). We=E2=80=99ll ask that Peter try to have a first draft out for our next = interim that covers what we=E2=80=99ve already agreed, and that can be = seen here = in the tracker. This is a big job. I ask that you lend Peter your support and your = sympathy as he takes on this rather large task. Eliot --Apple-Mail=_2B82BA78-E6AE-4841-84E9-59D6C65F4809 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Dear colleagues,

We have a volunteer as document editor for our work. =  Peter Saint-Andre has graciously offered to take up the charge. =  For those of you who don=E2=80=99t know Peter (I think most of you = do), he is a former applications area director, the large contributor to = the Jabber community, a long time IETFer, and the current chair of the = RSOC.  Peter currently works for Mozilla.

Peter will be responsible for = documenting in =E2=80=9Ccode=E2=80=9D the decisions that we have made = and will make.  He will work with the chairs to make sure that the = normative text he inserts is agreed by the working group, particularly = the Big Stuff, like the approval process (WG, AB, etc), the role and = name of the RS[EA], appeals, chair selection, etc.  He=E2=80=99ll = be conservative about what he puts in in that context.

He=E2=80=99ll also = handle the non-normative and editorial changes so that the document = doesn=E2=80=99t come out reading like a camel (a horse designed by = committee).

We=E2=80=99ll ask that Peter try to have a first draft out = for our next interim that covers what we=E2=80=99ve already agreed, and = that can be seen here in the tracker.

This is a big job.  I ask that you = lend Peter your support and your sympathy as he takes on this rather = large task.

Eliot
= --Apple-Mail=_2B82BA78-E6AE-4841-84E9-59D6C65F4809-- --Apple-Mail=_F9B48EB9-F237-45BC-8A91-E6E6EA13F829 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBHJvIACgkQh7ZrRtnS ejNxfAf7BpkQzLKq00dGxhCEsBhecS/5kLhwyNpPzp4C1dRFx7GQOZNiEkQE3RCC vVTPn4HxcGgbTr+Aowl/XwAIw/svBKpkGcRKgtHz0XZBC8cdjeXnD4e3DwXWLlOa iUCOLDaeuBCrxUiF94xC48xie3ZAiHhjZiMfqAPa4eOz+4jZ7l0q/7Q4PQsfaTCX Mn89saeVW2ZY67zXX06ZLIKM9+Zx2vSmvUyuzU5NNse/fcGWWx9AfhRoKw+cqsqK YMdgFGJiNnMBOK76Ubx8FcvCVAcHdy4BfdAlSlNU5S1oAPSw7b4uAMieq24zlq3v XD1K6RKjw2pdYjp49hrbme5lcWWvDw== =C/Fw -----END PGP SIGNATURE----- --Apple-Mail=_F9B48EB9-F237-45BC-8A91-E6E6EA13F829-- From nobody Tue Mar 9 00:01: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 490103A1690 for ; Tue, 9 Mar 2021 00:01:37 -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 azoZp3DeEAkt for ; Tue, 9 Mar 2021 00:01:35 -0800 (PST) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E7593A033F for ; Tue, 9 Mar 2021 00:01:29 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:2d04:4c87:7823:5635] (unknown [IPv6:2a00:ac00:4000:400:2d04:4c87:7823:5635]) (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 EF002600315; Tue, 9 Mar 2021 10:01:18 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1615276879; bh=CQMvPCZ/E0UcG7WRHc9EPPtdcgCrVeHnxiEE6lkk0Pw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=BFzwvS59tbb4Q/NNeMqIrnYWcxBNdqmG7LzXZW3HZkvw3Mks8rQLMg3Gpj5eJ+xYW XoJbfmWBbQupJgLt4TSXnqLa1aa7rxz5BbGdCNfkdpgdBIBMe2ebV9qMeMItxE4TT+ jJe5jtp6vaNb8J7Bh5czluy4f/nk4nGrCVFrSmD8= From: Lars Eggert Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_19A8986D-6721-4C6D-B554-3B25FA591337"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 9 Mar 2021 10:01:18 +0200 In-Reply-To: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> X-MailScanner-ID: EF002600315.A2E35 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 08:01:37 -0000 --Apple-Mail=_19A8986D-6721-4C6D-B554-3B25FA591337 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2021-3-9, at 1:44, Michael StJohns wrote: > Perhaps one of the great services an RSE might do is to write a series = of "Welcome to the DNS protocol suite - would you like instructions?" = RFCs that actually attempt to describe how a particular group of RFCs = relate to each other. I'm not sure an RSE would be best qualified to author such a document. = But a WG certainly can, like TCPM did for TCP: = https://datatracker.ietf.org/doc/html/rfc7414 Thanks, Lars --Apple-Mail=_19A8986D-6721-4C6D-B554-3B25FA591337 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmBHK04ACgkQVLXDCb9w wVc7Jw/+JG8DwL2LzqXRa2lFQ8221OdMVOMBaHoi+An+bv8D1EpMRAP5GeGAHh7h FDYS9esOcKXs0h4RvWnyz5FcJTp3VE7p8nJBuDuLmg/L4n4DbKG5HRoZnzzPunLy CPEgwWgZepDOu1lpvi5fVY6m3zF/m7w+NKpkmZKuo5od1k37M6WTLBX4ZY7sJCAd 32r6EdiGu3ttX19fInlcQzaqlOoGcUb7vcr46B116dLfREMx7puvXnK1yyG4oy+O pAwgvq6Bit2XRG2QfYVLKndOrYmJJ93fbzBVXFY/A0KQ1DsuOGXfCzXA29HdoXXr qc8o0beaziW0npQF0QUvIydnouaH+zWzCCfpNUqfn0iWFNgsvNq87IoA5WgLSN3X WosNmYGFiS4CU2hkzVNdEKZpE9ysMi/HDRFNnLqXG5pGuNQoP5HaiNRLX04BuJ8J eYmvNIDLyR51o9/9f4O4geLHSVqU67MhU6ySmFAKlfLK0dajn0IXBYHAfgoPJnmX uRnpZ8uVpwWkZ0jieHCi1s9NPe5TZ5nZmTdpqdE6dmq56Qkpk+s/DknMn6g9Y+nY +s1H0aplgTWBhNYZ6B//llw97TU6pyllZ1xb+nUqesBifww87uZ8kK8SeKF92Lpl e0iBOkxl1/hi63cs9uA4AplleyCNGq1eLwoyOysCbK9ob/L41AU= =ukHT -----END PGP SIGNATURE----- --Apple-Mail=_19A8986D-6721-4C6D-B554-3B25FA591337-- From nobody Tue Mar 9 00:23: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 3A1183A1727 for ; Tue, 9 Mar 2021 00:23:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tri_1uQXjpdF for ; Tue, 9 Mar 2021 00:23:38 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237863A1729 for ; Tue, 9 Mar 2021 00:23:38 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DvpBc37zLzyTw; Tue, 9 Mar 2021 09:23:36 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Tue, 9 Mar 2021 09:23:36 +0100 Cc: Michael StJohns , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 636971015.911621-89ce8e1a7eb931389d02140c40a60fa8 Content-Transfer-Encoding: quoted-printable Message-Id: <4882D61E-042B-477C-9DC3-FDD309ACC9E6@tzi.org> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> To: Lars Eggert X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 08:23:41 -0000 On 2021-03-09, at 09:01, Lars Eggert wrote: >=20 > I'm not sure an RSE would be best qualified to author such a document. = But a WG certainly can, like TCPM did for TCP: = https://datatracker.ietf.org/doc/html/rfc7414 But they rarely do (*). So I think it is an interesting question how this can be = encouraged/helped with by providing/organizing additional resources; not = sure the RSE would play a big role in such a process but they might have = a coordinating one. (Recently, the RPC has recruited some rather technically savvy copy = editors=E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten (*) yeah=E2=80=A6 draft-bormann-6lo-6lowpan-roadmap-00 6LoWPAN Roadmap and Implementation Guide 2013-10-21 9 pages Expired =09 draft-bormann-core-roadmap-05 CoRE Roadmap and Implementation Guide 2013-10-21 22 pages Expired From nobody Tue Mar 9 00:33: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 2919B3A175E for ; Tue, 9 Mar 2021 00:33:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 WWiu-wI8Ti-1 for ; Tue, 9 Mar 2021 00:33:16 -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 B1D743A175D for ; Tue, 9 Mar 2021 00:33:16 -0800 (PST) Received: from [IPv6:2a00:ac00:4000:400:2d04:4c87:7823:5635] (unknown [IPv6:2a00:ac00:4000:400:2d04:4c87:7823:5635]) (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 25958600314; Tue, 9 Mar 2021 10:32:57 +0200 (EET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1615278777; bh=ivsX+RmoKMImrsRY0qFr9Yu7aHQIDO++lZ4Cg46U4OI=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=weMgw/wB+cRAsujkEbVqXU8bat2cksjXt4Vv9pb1tht/KwLKOPS41OqI74owCNjav DAiU1S/+Xn6HJ1kUIVL9V88BfKWgQn+6ZHk1IkDKe3zJiDJSYmrId4XsXkdp0UkMmA 1EtE/g+K40BiGeXdaO7uH+w9Gh6oP/aVxrzJ0Jpc= From: Lars Eggert Message-Id: <3C08B269-F5CB-4EA3-B703-E9C95AD68827@eggert.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A5BC91C9-0D7A-4296-8A0D-49944B958808"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 9 Mar 2021 10:32:55 +0200 In-Reply-To: <4882D61E-042B-477C-9DC3-FDD309ACC9E6@tzi.org> Cc: Michael StJohns , rfced-future@iab.org To: Carsten Bormann References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <4882D61E-042B-477C-9DC3-FDD309ACC9E6@tzi.org> X-MailScanner-ID: 25958600314.A13F3 X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 08:33:18 -0000 --Apple-Mail=_A5BC91C9-0D7A-4296-8A0D-49944B958808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2021-3-9, at 10:23, Carsten Bormann wrote: > So I think it is an interesting question how this can be = encouraged/helped with by providing/organizing additional resources; not = sure the RSE would play a big role in such a process but they might have = a coordinating one. > (Recently, the RPC has recruited some rather technically savvy copy = editors=E2=80=A6) based on the experience in TCPM, I really think such documents need to = be written and reviewed by the technical community. The cases where a - = technically savvy - outsider could produce such a document are probably = exactly those cases where one isn't really needed. Thanks, Lars --Apple-Mail=_A5BC91C9-0D7A-4296-8A0D-49944B958808 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAmBHMrcACgkQVLXDCb9w wVdG2Q/+IiXDQ1spb/lautNSoSL/JQYD35oVFQHQMcV0nDFUmjicBrreSZjVo1aw R+YWGifLjTbZHDF3qEexaE43rhexF+v2nr6ysoiY+wU4vxcFJmYY4BZOUg+oUNHU WGpBZ65Ow2bqS+XkDrB3x87Y8ec9vN6Iic1ujUVeSo6UcM6Pgrdo2bv0cn9O7eAD XoK+fLz9q7Jpa0muvUr8OIwSv2KRI4wJ8BGpchTU6GbHICUBp11G2klCmWsTjp3A Txf6YivjPG9vnQ8WLD79nTAngK6d0/k0gYvrc4vh/SMNGyM+umXd/fBjsEjOGaw3 ABm/YusGeBfi5t3cgJaqQ6VSzYvcv/pRViyUfMZP2lblVEcziUD4iDlhVLcdhrPJ XTwCtS4rtLfNUnaUlfdqVrQpMqHBusY0hdoFD3DxqZoRWyrq6XST1bsBBXiu+aLp rLVRQdDY5KD7oQHl9XJsLIg94W1ueXGeGdK+PZmcOCAz64G9bVX+PsJNAng+a8j9 xLT64MKzfz2SEoNL14/EktxHLU6BOyV8+Xfn7E090NeHL/2S0q4Qmoivq5whyUJt EgdQbiXoWGHayAEZ/B97F4dga+8+cjBMeBMY3Q1gaCd1u6G2o2HM6k8dKFQiYzwG gdKSJBFSQ5PgiSVjN6kk+Cce1Q3aJDIbF4CC99Kd3jSFGDcqsq0= =zbgM -----END PGP SIGNATURE----- --Apple-Mail=_A5BC91C9-0D7A-4296-8A0D-49944B958808-- From nobody Tue Mar 9 01:21: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 1C7BE3A1616 for ; Tue, 9 Mar 2021 01:21:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yk_ZFdw1Ce4 for ; Tue, 9 Mar 2021 01:20:58 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD6B23A1848 for ; Tue, 9 Mar 2021 01:20:58 -0800 (PST) Received: from [192.168.217.123] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4DvqSn0lm7zyX7; Tue, 9 Mar 2021 10:20:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: <3C08B269-F5CB-4EA3-B703-E9C95AD68827@eggert.org> Date: Tue, 9 Mar 2021 10:20:56 +0100 Cc: rfced-future@iab.org, Michael StJohns X-Mao-Original-Outgoing-Id: 636974456.477847-bfcb38c5768c660bad4b46eab757ceed Content-Transfer-Encoding: quoted-printable Message-Id: <7047AACE-C3D7-4A91-B176-25021336A1EC@tzi.org> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <4882D61E-042B-477C-9DC3-FDD309ACC9E6@tzi.org> <3C08B269-F5CB-4EA3-B703-E9C95AD68827@eggert.org> To: Lars Eggert X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 09:21:01 -0000 On 2021-03-09, at 09:32, Lars Eggert wrote: >=20 > based on the experience in TCPM, I really think such documents need to = be written and reviewed by the technical community. The cases where a - = technically savvy - outsider could produce such a document are probably = exactly those cases where one isn't really needed. The best way to get an answer on the Internet is to put out the wrong = answer. If there is a threat that a roadmap will be produced, that will unleash = unprecedented energy(*)=E2=80=A6 Gr=C3=BC=C3=9Fe, Carsten (*) Yeah, I hope not all of that will be destructive. From nobody Tue Mar 9 03:55: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 207E03A1ACA for ; Tue, 9 Mar 2021 03:55:26 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eO4GErNFAQE7 for ; Tue, 9 Mar 2021 03:55:24 -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 7D62D3A1AC9 for ; Tue, 9 Mar 2021 03:55:24 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lJaxJ-000FD9-HE; Tue, 09 Mar 2021 06:55:17 -0500 Date: Tue, 09 Mar 2021 06:55:11 -0500 From: John C Klensin To: Lars Eggert , Carsten Bormann cc: rfced-future@iab.org, Michael StJohns Message-ID: In-Reply-To: <3C08B269-F5CB-4EA3-B703-E9C95AD68827@eggert.org> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <4882D61E-042B-477C-9DC3-FDD309ACC9E6@tzi.org> <3C08B269-F5CB-4EA3-B703-E9C95AD68827@eggert.org> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 11:55:26 -0000 --On Tuesday, March 9, 2021 10:32 +0200 Lars Eggert wrote: > Hi, >=20 > On 2021-3-9, at 10:23, Carsten Bormann wrote: >> So I think it is an interesting question how this can be >> encouraged/helped with by providing/organizing additional >> resources; not sure the RSE would play a big role in such a >> process but they might have a coordinating one. (Recently, >> the RPC has recruited some rather technically savvy copy >> editors=E2=80=A6) >=20 > based on the experience in TCPM, I really think such documents > need to be written and reviewed by the technical community. > The cases where a - technically savvy - outsider could produce > such a document are probably exactly those cases where one > isn't really needed. FWIW, I agree. Nut, as has been pointed out, while there have been exceptions, motivating WGs to do to the work and then keep up with it -- and motivating those who support people-s participation in WGs to support it-- has often proven quite difficult. So, as Martin mentioned (and that was discussed at length in Newtrk with the same conclusion) such documents need to be actively maintained and therefore may not be suitable for the RFC Series. There may be other ways around the problems but those I have seen are not consistent with the current IETF culture. One interacts with an issue that has come up many time in the context of the RFC Editor Function, which is whether IETF Stream documents should undergo final, or at least preliminary, editing prior to IETF Last Call. john From nobody Tue Mar 9 06:19: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 A3BF23A0D6F for ; Tue, 9 Mar 2021 06:19:57 -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 XxzW8TYhsrRt for ; Tue, 9 Mar 2021 06:19:55 -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 98EBE3A083E for ; Tue, 9 Mar 2021 06:19:55 -0800 (PST) Received: by mail-pl1-x631.google.com with SMTP id 30so2071464ple.4 for ; Tue, 09 Mar 2021 06:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=+wc/OoGiG7ZKAOWczm2JwndoPKPD2X8bDW1nCCJfrwk=; b=W41ieU/E+UTYbYKTX658hefZ7u1v2g5rq6Lsffr45CPaQW918Bz6dhRHehh/aX/Mjc 8J53PE6gQfK16z9xqGTBaS+0WnlPPgnHmhKXvRiPrLWGn3eUW5uVGJluKYI+v1ccaM3B fvFoNBs79Gxeq8GIl5aZk+bwbTwyeeo4HVvTCsFV+Yq3MewBQEHNs+0FXP+C3Wof1RJg 4GL2gm+J3aaUiYlakQVlrHfl0C18oRxtHJSc/xrxnIafrc3fsN+lvbz/Xn6LzcEJ5mN+ POAzZ96P/YqYrudbjuB+D9Boi1BTtNvLUBeM1jCy07E5EqC6TPgFdCMahyPXlklWW0Ta O21w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=+wc/OoGiG7ZKAOWczm2JwndoPKPD2X8bDW1nCCJfrwk=; b=Xs5JGtNswEPLY1gvtxCBtDpt92YlPdhxoNFfIu0ajSJOCzkYaN7SUctfGLKohcjxcw v3YoMKSM/8ZlgEqxt37VlsSYqbTvx3KRyPZjvE5giao6q1324CEINndm006lH70vWrhi X3z+rOcgqMVbMELHU5x9zykzofYJb9WZBeog+SFCsIRG+IbNVALssnEvO3VArhjiDGcK 2rgR49yirKnLsfoXwVtUzODqsthTLtpB+iHJrUeMXnybo8RmX46gQsO40hRbmVn931Kn FX3gk1CoFEh9hs7P0r+UWWEtJRPkEOcLz/kwDYkQy3CAoPIF54uoDXf0rS24ksnvliwP sLWA== X-Gm-Message-State: AOAM532D944JaZizKKaf5YLbn1V/KsKdDePo6sX8kF7GLV0mQTGNVuGc unonKUpHg1rIgZ107ae/xN8= X-Google-Smtp-Source: ABdhPJzHWSR4hul+q0ZuAzfVTiypY8XaUJUHWDEvaR3gEHBINbdOmEaYw5na4v5o3Ayjy7lYncETjA== X-Received: by 2002:a17:90b:508:: with SMTP id r8mr5019584pjz.83.1615299593684; Tue, 09 Mar 2021 06:19:53 -0800 (PST) Received: from ?IPv6:2601:647:5a00:9b7:ac7d:4d93:4ec0:d0b6? ([2601:647:5a00:9b7:ac7d:4d93:4ec0:d0b6]) by smtp.gmail.com with ESMTPSA id w26sm10597565pfn.33.2021.03.09.06.19.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Mar 2021 06:19:53 -0800 (PST) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_76ADADB1-975B-448A-8295-D00A357DC827"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Tue, 9 Mar 2021 06:19:50 -0800 In-Reply-To: Cc: Bob Hinden , Michael StJohns , rfced-future@iab.org To: Lars Eggert References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 14:19:58 -0000 --Apple-Mail=_76ADADB1-975B-448A-8295-D00A357DC827 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Mar 9, 2021, at 12:01 AM, Lars Eggert wrote: >=20 > Signed PGP part > Hi, >=20 > On 2021-3-9, at 1:44, Michael StJohns wrote: >> Perhaps one of the great services an RSE might do is to write a = series of "Welcome to the DNS protocol suite - would you like = instructions?" RFCs that actually attempt to describe how a particular = group of RFCs relate to each other. >=20 > I'm not sure an RSE would be best qualified to author such a document. = But a WG certainly can, like TCPM did for TCP: = https://datatracker.ietf.org/doc/html/rfc7414 I agree. Another possibility is for an area directorate to hold the pen. I also = wonder if this should be an RFC or a web page. Bob --Apple-Mail=_76ADADB1-975B-448A-8295-D00A357DC827 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmBHhAYACgkQrut0EXfn u6hKOQf/e0O33qqdnBPbxpfai6k9H9U6gPvGDU9WKxAuWCrVcx5FN7yh+bxDUOkR u2gtKzT9tt6VWRcz6oy8O5TdUkgW1zIyI1puI9IO3pMkuwU3bJ4T93PUwquB/P8j skoLisU38WRYp33yMeB0EwTYJ4kuhoSRae4M4Asoil2+jXBaEWjovZOXqkod0NT8 DjviMVn10Rw7IguSM9j8gwlqSnMuSGwhPQ62BaKK7PB98LsVsIoxmFmH1jdFRa08 TVoRYik0bkKWi+/DEIizdDgmK3g3Gw6PGOJHS450hiPdeQzPBbDZORF+GIYO4rE6 fvwAXEtnX6jISvRyFBMiAJ0xkFx2Ew== =Ijps -----END PGP SIGNATURE----- --Apple-Mail=_76ADADB1-975B-448A-8295-D00A357DC827-- From nobody Tue Mar 9 11:14: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 EB60C3A17AE for ; Tue, 9 Mar 2021 11:14:27 -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, 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 Pno0qDMH6p3Z; Tue, 9 Mar 2021 11:14:26 -0800 (PST) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 0CF8B3A17AC; Tue, 9 Mar 2021 11:14:25 -0800 (PST) From: Jay Daley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_5F3D56C6-4441-4AF2-B72E-94D83828E280" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Wed, 10 Mar 2021 08:14:23 +1300 In-Reply-To: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 19:14:28 -0000 --Apple-Mail=_5F3D56C6-4441-4AF2-B72E-94D83828E280 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 9/03/2021, at 12:44 PM, Michael StJohns = wrote: >=20 > Hi - >=20 > This is certainly not something for long discussion related to the = model, just something that I thought of that might be a useful set of = deliverables for the future RSE/A/whatever. >=20 > In a long ago discussion, we had various discussion/rants about the = spaghetti like nature of certain of the standards families (TLS and DNS = spring to mind) and the difficulty for someone reading RFCs without IETF = experience to figure out which RFCs are actually necessary to build a = working protocol engine. >=20 > Perhaps one of the great services an RSE might do is to write a series = of "Welcome to the DNS protocol suite - would you like instructions?" = RFCs that actually attempt to describe how a particular group of RFCs = relate to each other. As has been noted elsewhere, these are probably = not documents that would attract enough volunteer hours to create. They = would also be somewhat formulaic, and ideally more an annotated = bibilography than a new set of standards documents. >=20 > As I noted above, this is just a side idea to be ruminated on rather = than anything to feed into the endless maw of the current discussion. I have a naive question - has any thought been given to doing this = bottom up not top down, say by defining a fixed set of technology tags = (DNS, TLS etc) and having the authors apply those to their documents? Jay >=20 > Mike >=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_5F3D56C6-4441-4AF2-B72E-94D83828E280 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 9/03/2021, at 12:44 PM, Michael StJohns <msj@nthpermutation.com> wrote:

Hi = -

This is certainly not something for long = discussion related to the model, just something that I thought of that = might be a useful set of deliverables for the future RSE/A/whatever.

In a long ago discussion, we had various = discussion/rants about the spaghetti like nature of certain of the = standards families (TLS and DNS spring to mind) and the difficulty for = someone reading RFCs without IETF experience to figure out which RFCs = are actually necessary to build a working protocol engine.

Perhaps one of the great services an RSE might = do is to write a series of "Welcome to the DNS protocol suite - would = you like instructions?" RFCs that actually attempt to describe how a = particular group of RFCs relate to each other.  As has been noted = elsewhere, these are probably not documents that would attract enough = volunteer hours to create.  They would also be somewhat formulaic, = and ideally more an annotated bibilography than a new set of standards = documents.

As I noted above, this is just a = side idea to be ruminated on rather than anything to feed into the = endless maw of the current discussion.

I = have a naive question - has any thought been given to doing this bottom = up not top down, say by defining a fixed set of technology tags (DNS, = TLS etc) and having the authors apply those to their = documents?

Jay


Mike


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

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

= --Apple-Mail=_5F3D56C6-4441-4AF2-B72E-94D83828E280-- From nobody Tue Mar 9 11:42: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 9551F3A07BA for ; Tue, 9 Mar 2021 11:42:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W01EVN45Qnsl for ; Tue, 9 Mar 2021 11:42:33 -0800 (PST) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72BA03A07A4 for ; Tue, 9 Mar 2021 11:42:33 -0800 (PST) Received: by mail-pl1-x62c.google.com with SMTP id w7so3647849pll.8 for ; Tue, 09 Mar 2021 11:42:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=4/eq5mLN3GO6Dfbu3deBJ9Dgfdeen+m8ZqTC6j99Q1U=; b=p0btm3YWn3fyDMQAKKvGqBF+LNdnEWO9OuVCFomtlJ347Yh47QqTdrurQK/aFPSMIE FQlzUoqB2icB4yHNEgL+MUrlH7J9Q1Pdm3oGPHGS3jv2MrfMs84aZNK3t2kK4JeRRjNA ZD88zsK0YoZj4DvmLh9unN+eTVwMZ3hsVjalmzDcW5a/Ou7qjy+Rwu0uidzquM4ZfuPy 0NMNFDstG28pMVLhPL+42NxY6I1TtlbHkuB7znlMbdgMsj4JgDs+gzusN6/PbphtkGvw 7+YkUH1+gR6nYRvkFxN1daHXpAqjZQh/Mlap86UgmEhsX5M0iFaOUqmC6PJ3a4Ge6vXt pSlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=4/eq5mLN3GO6Dfbu3deBJ9Dgfdeen+m8ZqTC6j99Q1U=; b=J/KA+VEwYSxxSX7xdd/K6jlH4QxLAp0hoJ/OlsNEIUp/y4emSlSDuoE+rh21Yl2/VH IOF6dLs421OP76MQfsQm+dd0nAVDzbeVfZwP3QAwNtN5oSgRUgN/CMu0wdwu8f6krs9v Me2+Q3IxXlQFC7oL8cixqTyd/YC5KC5iP4e4HfoCsB8RZf8jkL+dWF66P8GEhqzAKDFZ NJeG0RJSPjMA54GBDCnOM0vLdqOiOncy3lV0k6dItRS7tCZ/gWBiA0RJtbdlMGUM/Xlw SYKMGoTczdHphdtVjPk+Jb0eZqGvyXgyS1MqyQpeizTYO0LATpnegRXOZRF+OI3ymNlY RMgw== X-Gm-Message-State: AOAM5328WB1V8GOoil3dTjr4mZ+wvDLXnGQsya/i/EWazklSvWVVamlQ RilmtlOqkGbjRTmgb4nNsqpuQLFItVFBWA== X-Google-Smtp-Source: ABdhPJzpOveqM8pQyOnMGOiNET1TuTjasojr9bi4AoYuNqTb8tSkGhfL/A8T01If8O0y/1efCcWLfw== X-Received: by 2002:a17:902:8306:b029:e6:125c:1a3a with SMTP id bd6-20020a1709028306b02900e6125c1a3amr5385895plb.65.1615318951530; Tue, 09 Mar 2021 11:42:31 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id n11sm13735594pgm.30.2021.03.09.11.42.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Mar 2021 11:42:30 -0800 (PST) To: Jay Daley , Michael StJohns Cc: rfced-future@iab.org References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Wed, 10 Mar 2021 08:42:26 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 19:42:35 -0000 On 10-Mar-21 08:14, Jay Daley wrote: >=20 >=20 >> On 9/03/2021, at 12:44 PM, Michael StJohns > wrote: >> >> Hi - >> >> This is certainly not something for long discussion related to the mod= el, just something that I thought of that might be a useful set of delive= rables for the future RSE/A/whatever. >> >> In a long ago discussion, we had various discussion/rants about the sp= aghetti like nature of certain of the standards families (TLS and DNS spr= ing to mind) and the difficulty for someone reading RFCs without IETF exp= erience to figure out which RFCs are actually necessary to build a workin= g protocol engine. >> >> Perhaps one of the great services an RSE might do is to write a series= of "Welcome to the DNS protocol suite - would you like instructions?" RF= Cs that actually attempt to describe how a particular group of RFCs relat= e to each other.=C2=A0 As has been noted elsewhere, these are probably no= t documents that would attract enough volunteer hours to create.=C2=A0 Th= ey would also be somewhat formulaic, and ideally more an annotated bibilo= graphy than a new set of standards documents. >> >> As I noted above, this is just a side idea to be ruminated on rather t= han anything to feed into the endless maw of the current discussion. >=20 > I have a naive question - has any thought been given to doing this bott= om up not top down, say by defining a fixed set of technology tags (DNS, = TLS etc) and having the authors apply those to their documents? If (and that is not a trivial "if") authors have consistently got the nor= mative references right, the normative dependency graphs that are already= around will have that effect. (For that matter, the "cluster" mechanism = used by the RFC Editor has much the same effect, but it's lost when the R= FCs are published and the cluster dissolves.) However, exercises like RFC 8504 show that it's hard work to get these th= ings right, and they are out of date almost instantly. This is a problem area the IETF has been dancing around for years. I beli= eve that Lars is correct that in the end it's only subject matter experts= (typically the WG) that can get it right, but automatically generated de= pendency graphs should certainly help. draft-kuehlewind-update-tag is als= o relevant. But above all, encouragement from the IESG and WG Chairs to write such do= cuments is needed. Whether they are published as RFCs or web pages is a b= it secondary. Regards Brian From nobody Tue Mar 9 12:17: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 B7F883A0A25 for ; Tue, 9 Mar 2021 12:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV-YCGcAuEzn for ; Tue, 9 Mar 2021 12:17:47 -0800 (PST) Received: from gabriel-vm-2.zfn.uni-bremen.de (gabriel-vm-2.zfn.uni-bremen.de [134.102.50.17]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1793A0A02 for ; Tue, 9 Mar 2021 12:17:47 -0800 (PST) Received: from [192.168.217.118] (p5089a828.dip0.t-ipconnect.de [80.137.168.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-vm-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4Dw62d02m7zyXc; Tue, 9 Mar 2021 21:17:44 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Carsten Bormann In-Reply-To: Date: Tue, 9 Mar 2021 21:17:44 +0100 Cc: Jay Daley , Michael StJohns , rfced-future@iab.org X-Mao-Original-Outgoing-Id: 637013864.201032-b4e9eaf8b8f7f319da045561db5654a7 Content-Transfer-Encoding: quoted-printable Message-Id: <0219B568-3FDC-4BEA-B0AD-3F70857F374A@tzi.org> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 20:17:50 -0000 On 2021-03-09, at 20:42, Brian E Carpenter = wrote: >=20 > However, exercises like RFC 8504 show that it's hard work to get these = things right, and they are out of date almost instantly. I think we can all agree that node requirements, roadmaps, etc. are a = class of documents that our current processes are not prepared to put = out consistently. We can say that this is hard and we need to try harder, but I don=E2=80=99= t believe that will work. Instead, we will need to think about ways to encourage this that go way = beyond an occasional nag mail. Of course, I=E2=80=99m thinking about = ways to create an organizational responsibility, but I=E2=80=99m also = aware that that=E2=80=99s not a cakewalk. > This is a problem area the IETF has been dancing around for years. I = believe that Lars is correct that in the end it's only subject matter = experts (typically the WG) that can get it right, but automatically = generated dependency graphs should certainly help. = draft-kuehlewind-update-tag is also relevant. All for all the tools help we can get. But we also need people that can keep these candles lit, even if these = may not be able to create all the content that needs to go in there. > But above all, encouragement from the IESG and WG Chairs to write such = documents is needed. Whether they are published as RFCs or web pages is = a bit secondary. Actually, no. There is no way to get this done as a web page (~ wiki). Publishing them as an RFC is the only way they will have high quality = (or happen in the first place). But we need to get there, and encouragement only takes us so far. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 9 12:30: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 B3ACA3A0AE1; Tue, 9 Mar 2021 12:30:06 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGof5VEjCc4E; Tue, 9 Mar 2021 12:30:05 -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 529CE3A0ADF; Tue, 9 Mar 2021 12:30:05 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lJizT-000Hok-Ou; Tue, 09 Mar 2021 15:30:03 -0500 Date: Tue, 09 Mar 2021 15:29:57 -0500 From: John C Klensin To: Jay Daley , Michael StJohns cc: rfced-future@iab.org Message-ID: <6F87EA1632F5D6EA93F9A81E@PSB> In-Reply-To: References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline 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] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 20:30:07 -0000 --On Wednesday, March 10, 2021 08:14 +1300 Jay Daley wrote: >> On 9/03/2021, at 12:44 PM, Michael StJohns >> wrote: >... >> In a long ago discussion, we had various discussion/rants >> about the spaghetti like nature of certain of the standards >> families (TLS and DNS spring to mind) and the difficulty for >> someone reading RFCs without IETF experience to figure out >> which RFCs are actually necessary to build a working protocol >> engine. >> >> Perhaps one of the great services an RSE might do is to write >> a series of "Welcome to the DNS protocol suite - would you >> like instructions?" RFCs that actually attempt to describe >> how a particular group of RFCs relate to each other. As has >> been noted elsewhere, these are probably not documents that >> would attract enough volunteer hours to create. They would >> also be somewhat formulaic, and ideally more an annotated >> bibilography than a new set of standards documents. >... > I have a naive question - has any thought been given to doing > this bottom up not top down, say by defining a fixed set of > technology tags (DNS, TLS etc) and having the authors apply > those to their documents? Yes. There have long been provisions for assigning keywords (aka "tags") to documents, with either authors or the RFC Editor staff putting them in. What has not happened is standardization on a vocabulary for those tags that would get them assigned in the right places and no where else. Similar to my earlier comments, at least one reason has been IESG disinterest in having the extra work done and then checking it. john From nobody Tue Mar 9 12:47: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 B092A3A0C00 for ; Tue, 9 Mar 2021 12:47:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jKmkM1jC3nAL for ; Tue, 9 Mar 2021 12:47:37 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C1A3A0BFF for ; Tue, 9 Mar 2021 12:47:37 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id a9so14520083qkn.13 for ; Tue, 09 Mar 2021 12:47:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=RL3vh3yEFSdRpqvvtjjKmw9Rzr146AGYUHCVWp5OTaY=; b=TgICf2buf2Yd51pCOdq6AO/xs/h5sAuRqOLbYaLFAHiWKFZMlHKOMQbAY9ed5DCaD5 uBvDUj8z0kv3WuNul8FOAtRS2KzE9GT8cFko6YVq8XZ9QZT91QRMFMnZkuGMu7owJenc m4W7hk8Wll9uMme2c/TaxFRYfpO26O0QZ76y9hHwp5yxA2mC2stODmzbp7dSB7h5fqQv 0QbtqXUb6T6h5tQHa77UF5HKLRfUKp5IgsYQkvM4+wuq4x36egQWGKAf+G5SpFCi759g 2tJmRhJJh3CYGXYr/vDuFukfiyIKcAdabdSV7dGt9uMsxem3CKICmsO2sM677obE3P0/ n1RA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=RL3vh3yEFSdRpqvvtjjKmw9Rzr146AGYUHCVWp5OTaY=; b=fxTxEQvy0UlbjTA3OW9nIWyl577rvuguviZbydudg6X+vQQX9wCWk/hCoiim07q34k B2PyQMLg79zF63hRCNgH0JFhcVinGjj39tbPktNbKmgZ7oBT6xGUlavdK+2lhezR65dF WqErGez2UicoC+EALH/AxTlLkqY4JnVzEF2u0DvMs6eFXfQVi/PnaGOuulgBWiijD6n+ FHxwK5hpt+30NMJALtjiph2m8EcOWMd11xoNV8xEemTb0SWqeeD9KztwXz3sJ2yl4R0j M8aRnjWPeZb13pjtoV0+EbAh7tapWwBIAStMcTn79AmjvqcfX3EV+vmDJ5XcnmmNq7dy oHHg== X-Gm-Message-State: AOAM531JLzKv12xFx99A4nBAKNzxCbHNkqpV/TD46H6e0NwzmW7Hez0/ cqR89PiU1jzHYI97nIMAXEv7RMl4xRx7cd0R9ek= X-Google-Smtp-Source: ABdhPJwLi54hbuwzxXZpD4vlzp8oiKAWftfI51zb97kgaaHCy2rE9bxzZt8lLGEHZMXDqvXfknev/A== X-Received: by 2002:a05:620a:1467:: with SMTP id j7mr27352642qkl.136.1615322855066; Tue, 09 Mar 2021 12:47:35 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id l129sm11051825qkd.76.2021.03.09.12.47.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 Mar 2021 12:47:34 -0800 (PST) To: Carsten Bormann , Brian E Carpenter Cc: Jay Daley , rfced-future@iab.org References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <0219B568-3FDC-4BEA-B0AD-3F70857F374A@tzi.org> From: Michael StJohns Message-ID: <0173ce6f-4522-5338-f259-b928e8508fb9@nthpermutation.com> Date: Tue, 9 Mar 2021 15:47:33 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 MIME-Version: 1.0 In-Reply-To: <0219B568-3FDC-4BEA-B0AD-3F70857F374A@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 20:47:39 -0000 On 3/9/2021 3:17 PM, Carsten Bormann wrote: > On 2021-03-09, at 20:42, Brian E Carpenter wrote: >> However, exercises like RFC 8504 show that it's hard work to get these things right, and they are out of date almost instantly. > I think we can all agree that node requirements, roadmaps, etc. are a class of documents that our current processes are not prepared to put out consistently. > > We can say that this is hard and we need to try harder, but I don’t believe that will work. > > Instead, we will need to think about ways to encourage this that go way beyond an occasional nag mail. Of course, I’m thinking about ways to create an organizational responsibility, but I’m also aware that that’s not a cakewalk. Hence my thought to throw paid resources at it. > >> This is a problem area the IETF has been dancing around for years. I believe that Lars is correct that in the end it's only subject matter experts (typically the WG) that can get it right, but automatically generated dependency graphs should certainly help. draft-kuehlewind-update-tag is also relevant. > All for all the tools help we can get. > But we also need people that can keep these candles lit, even if these may not be able to create all the content that needs to go in there. > >> But above all, encouragement from the IESG and WG Chairs to write such documents is needed. Whether they are published as RFCs or web pages is a bit secondary. > Actually, no. There is no way to get this done as a web page (~ wiki). > Publishing them as an RFC is the only way they will have high quality (or happen in the first place). > But we need to get there, and encouragement only takes us so far. > > Grüße, Carsten > My thought here is that while the RSE/A might not be the final author on the document, they certainly can be the facilitator and nag.  I'm thinking back to the DOCSIS security standards where our facilitator was not the primary driving force for technical content, but was for getting to a conclusion with actual written text and was hired for that specific purpose. I think these documents  should probably be RFCs mainly because RFCs are a snapshot in time that an implementer can look at and say - hmm, published in March of 2021, so I need to see if there are other documents that I care about that have been written later. And last, I don't actually think this is a standards type thing that the IESG should necessarily care about/push, but a document series thing that provides explanatory meta material that really helps frame the specifications. Mike From nobody Tue Mar 9 13:36: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 EF0393A0DE0 for ; Tue, 9 Mar 2021 13:36:46 -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_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jz4NwdMrxWpC for ; Tue, 9 Mar 2021 13:36:44 -0800 (PST) Received: from donkey.elm.relay.mailchannels.net (donkey.elm.relay.mailchannels.net [23.83.212.49]) (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 A20B63A0DE1 for ; Tue, 9 Mar 2021 13:36:44 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 41299183107; Tue, 9 Mar 2021 21:36:43 +0000 (UTC) Received: from pdx1-sub0-mail-a60.g.dreamhost.com (100-96-16-22.trex.outbound.svc.cluster.local [100.96.16.22]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id B1833183051; Tue, 9 Mar 2021 21:36:42 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a60.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.96.16.22 (trex/6.0.2); Tue, 09 Mar 2021 21:36:43 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Little-Trade: 757b9e41774485a5_1615325802996_1497796454 X-MC-Loop-Signature: 1615325802996:2279243443 X-MC-Ingress-Time: 1615325802995 Received: from pdx1-sub0-mail-a60.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a60.g.dreamhost.com (Postfix) with ESMTP id 6FB317EF8E; Tue, 9 Mar 2021 13:36:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=FQWpDtAgsxBJzyszUMErbINbhTY=; b=v/Hu9H9wtxL FORnXQjmpW2kdqqmIO8647shR/3KE/7++zXE4xH0c1rPjenx897uC0IGbdgcGZ0P tjFa0ZOYeZJYg4phE+iYgMQICefOewTzajYDRq971pKk4lu2+w9aK9pEBv8dp1aH cExHCWk9WLcMuDbZWodAIF/GLmo8lefs= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a60.g.dreamhost.com (Postfix) with ESMTPSA id 43D387EE47; Tue, 9 Mar 2021 13:36:39 -0800 (PST) Date: Tue, 9 Mar 2021 15:36:36 -0600 X-DH-BACKEND: pdx1-sub0-mail-a60 From: Nico Williams To: Michael StJohns Cc: Carsten Bormann , Brian E Carpenter , rfced-future@iab.org, Jay Daley Message-ID: <20210309213636.GI30153@localhost> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <0219B568-3FDC-4BEA-B0AD-3F70857F374A@tzi.org> <0173ce6f-4522-5338-f259-b928e8508fb9@nthpermutation.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0173ce6f-4522-5338-f259-b928e8508fb9@nthpermutation.com> User-Agent: Mutt/1.9.4 (2018-02-28) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 21:36:47 -0000 On Tue, Mar 09, 2021 at 03:47:33PM -0500, Michael StJohns wrote: > On 3/9/2021 3:17 PM, Carsten Bormann wrote: > > Instead, we will need to think about ways to encourage this that go > > way beyond an occasional nag mail. Of course, I=E2=80=99m thinking a= bout > > ways to create an organizational responsibility, but I=E2=80=99m also= aware > > that that=E2=80=99s not a cakewalk. >=20 > Hence my thought to throw paid resources at it. Yes. The ITU-T produces very high-quality documents, most likely because it's not a volunteer organization and they (must? I think?) have tech writers on staff. I'm not suggesting that the IETF go that way in general, but for putting together series of RFCs as RFCs for the community to review, I think this would be great. One FTE could probably get us all the series we care about in a few years. Nico --=20 From nobody Tue Mar 9 15:20: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 ABF3E3A110C for ; Tue, 9 Mar 2021 15:20:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.85 X-Spam-Level: X-Spam-Status: No, score=-1.85 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iecc.com header.b=YtjaW6/W; dkim=pass (2048-bit key) header.d=taugh.com header.b=Tqj0Illi Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id evbH6xo-ucHC for ; Tue, 9 Mar 2021 15:20:08 -0800 (PST) Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4B463A110B for ; Tue, 9 Mar 2021 15:20:08 -0800 (PST) Received: (qmail 78244 invoked from network); 9 Mar 2021 23:20:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1319f.604802a6.k2103; bh=ygKBkvZhulK1bWCsBzYxKAINAeBkPC1YJzmWlR3rG74=; b=YtjaW6/WAj02xV9q+7vs6wupEqghzPqAIf8B+6ejn+4hYnO0u1qjIObHnZtkjkr3paiIVTzL6n2MPDORGmtbQza8VgCUPQH/eVscntzd+qKLT8ViclgUBAeRB9FRPSA+RohKQElRdfj0kgbsoxQzPJY8oD5l/Vl+Gzrn62JtJwrVJWX1PBRDdzxuLa97mS92U+ngmw4aUh1izQdgmC0JNo5iOqcuE7GML6Qqr6HU7PcaM80i0HzpDAPpCTaAQmDgP5SpK4LP2PA7JOj2NhainPxeg7IloMIESqviqqwRFYvCfGxvf6TmA2mV6/fVuSESmdcWgCX2MQXkWuKa4YEzJg== DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:cleverness; s=1319f.604802a6.k2103; bh=ygKBkvZhulK1bWCsBzYxKAINAeBkPC1YJzmWlR3rG74=; b=Tqj0Illi10U+adHB8OZ6qXL70COEd6qoZlWb35Op9Hh5TZO+ZygH+Cchd0Z0G+kwo5lQVZ5sEco/iURLVvkfOCsQLX0dsfPRwM5PJnlnIlSQo9m52wKDwKbrkfaAF7REwEccG3pevak1Fk81F1l25B4B4fCKDfQfcIcujRY5Mc977XQ45wCAirWrTahh/2blPNp9OYe+aMfyWt8O9uGKRl++JkO2raKGidfjmOwRzC4LcwC0R5Ec2/7LeyGMDdMttAVruvxsMv5Wo4y91+G9HXLhZh4MFAOtI06hEq8UUMMYKtftffW4WL+FzJUkgLL3kUflGBfBFlk1Rk71e08kPA== Received: from ary.qy ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2 ECDHE-RSA AES-256-GCM AEAD) via TCP6; 09 Mar 2021 23:20:06 -0000 Received: by ary.qy (Postfix, from userid 501) id B08F06FEA7D4; Tue, 9 Mar 2021 18:20:05 -0500 (EST) Date: 9 Mar 2021 18:20:05 -0500 Message-Id: <20210309232005.B08F06FEA7D4@ary.qy> From: "John Levine" To: rfced-future@iab.org Cc: lars@eggert.org In-Reply-To: Organization: Taughannock Networks X-Headerized: yes Cleverness: minimal Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Mar 2021 23:20:11 -0000 In article you write: >-=-=-=-=-=- > >Hi, > >On 2021-3-9, at 1:44, Michael StJohns wrote: >> Perhaps one of the great services an RSE might do is to write a series of "Welcome to the DNS protocol suite - would >you like instructions?" RFCs that actually attempt to describe how a particular group of RFCs relate to each other. > >I'm not sure an RSE would be best qualified to author such a document. But a WG certainly can, like TCPM did for TCP: >https://datatracker.ietf.org/doc/html/rfc7414 I have a technical background and could write stuff like that, but Heather's background is different and I doubt she could have, at least not without a lot of technical help. (Editing it into coherent readable shape is a different issue.) I think the pile of requirements here already makes it unlikely that we will find a qualified candidate who wants the job, so I would doubly not count on the unlikely person writing technical material. If we think this sort of roadmap is valuable, put it in the budget and put it out for bid as a separate thing. R's, John From nobody Tue Mar 9 19:12: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 4ED9B3A18BA; Tue, 9 Mar 2021 19:12: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 carZQ7hYwOAl; Tue, 9 Mar 2021 19:12:53 -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 ACA7E3A18B9; Tue, 9 Mar 2021 19:12:53 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lJpHH-000JV4-2D; Tue, 09 Mar 2021 22:12:51 -0500 Date: Tue, 09 Mar 2021 22:12:44 -0500 From: John C Klensin To: Nico Williams , Michael StJohns cc: rfced-future@iab.org, Carsten Bormann , Jay Daley Message-ID: <882F63E249CF9298EBCA3BF2@PSB> In-Reply-To: <20210309213636.GI30153@localhost> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <0219B568-3FDC-4BEA-B0AD-3F70857F374A@tzi.org> <0173ce6f-4522-5338-f259-b928e8508fb9@nthpermutation.com> <20210309213636.GI30153@localhost> 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] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 03:12:55 -0000 --On Tuesday, March 9, 2021 15:36 -0600 Nico Williams wrote: > On Tue, Mar 09, 2021 at 03:47:33PM -0500, Michael StJohns > wrote: >> On 3/9/2021 3:17 PM, Carsten Bormann wrote: >> > Instead, we will need to think about ways to encourage this >> > that go way beyond an occasional nag mail. Of course, >> > I'm thinking about ways to create an organizational >> > responsibility, but I'm also aware that that's not a >> > cakewalk. >> >> Hence my thought to throw paid resources at it. > > Yes. The ITU-T produces very high-quality documents, most > likely because it's not a volunteer organization and they > (must? I think?) have tech writers on staff. Nico, please be careful about this sort of comparison. THey not only have tech writers (to get back to a distinct made early in this group, not copy editors), but tech writers who are skilled in the subject matter and staff members assigned to each SG who are presumed to be skilled in the subject matter. They also do almost all of the editing before documents go out for final review by the national members so, at the time that review starts, the documents are expected to be in their final states both technically and editorially. ISO, at the TC level, is very similar. Once a specification becomes a standard, it is assigned an identifier that stays with it forever. For example, to know which version of X.509 or ISO 3166 is being referenced, one needs to have the adoption year. And, when a document is forked or supplemented in some way, the norm is to split subset the numbering scheme, e.g., ISO 3166 started out as a single spec but when identifiers for non-country entities were added, we ended up with ISO 3166-1, ISO 3166-2, and ISO 3166-3, with the current versions formally known as ISO 3166-1:2020, ISO 3166-2:2020, and ISO 3166-3:2020. Both bodies, but especially ISO, also have fixed periods after which a standard must be reviewed and then reaffirmed, revised (i.e., replaced), or withdrawen. None of our pattern of incremental "update" documents, forks and side branches, and documents that are not opened for decades are consistent with that way of doing things. If we tried to apply their system to TCP, we might have had IETF 793:1981, been forced to formally review and reaffirm it around 1984 or 1985 (producing something that might be formally known as IETF:1981R1985) with a new version, IETF 793:1989, incorporating the RFC 1123 updates; then IETF 793:1989R1992, IETF 793:1989R1995, and so on until IETF 793:2001 incorporating the additions of RFc 3168, and... In the ITU, technical standards (aka "Recommendations") are also identified by a subseries classification, e.g., X.509 but E.123. That is a technical decision that has, IIR, occasionally be the subject of debate about, e.g., scope of Study Groups. That can help understand what documents go together too.... or not. Systems like that have many attractions as does getting documents into what is expected to be final form before the equivalent of our Last Call. In addition to the high-quality documents you mention, the model eliminates any risk that documents may change in ways that some might consider substantive after the fact by private agreements between the IESG (or particular ADs) and authors after Last Call ends and without verification by the community. The numbering systems largely eliminate the "which documents do I need to look at to know what the standard actually is" problem. There is also no opportunity for confusion about whether BCPs override Proposed Standards, the meaning of verified errata, and so on: when those organizations publish documents that are not what we would call standards track, they use completely different terminology. For example, ISO used to have three categories of Technical Reports, one of which was used for things that seemed to be good ideas but that could not achieve sufficient consensus and were affectionately known as "substandards". There are disadvantages as well. They have nothing equivalent to an individual submission. Editing before final general/public review works because, by the time a document gets to that stage, it has been through enough layers of review that changes that would require significant re-editing are quite rare. By contrast, our Last Call process is often the first time at document has been seen by anyone outside the WG that developed it so editing before Last Call would result in the RFC Editor Function needing to process many documents twice and some more times than that. For many years, we also used to claim (and could document) that our process was much faster than theirs and that the rapidly-developing ARPANET and Internet needed "fast". There are enough complicating factors and exogenous variables that valid statistical comparisons would be nearly impossible, but many of us believe that is no longer true. > I'm not suggesting that the IETF go that way in general, but > for putting together series of RFCs as RFCs for the community > to review, I think this would be great. One FTE could > probably get us all the series we care about in a few years Depending on how we define what we care about (agreement on that subject could, itself, take a few years). The people doing the work would need to be technical experts in the subject matter (not "just" technical editors). And, because there are few (if any) people expert in all of the IETF's work areas, you might need different people per Area and maybe different people within some areas. So, yes... but everything is connected to everything else and be careful what you wish for. john From nobody Tue Mar 9 19:13: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 29DB13A18B9 for ; Tue, 9 Mar 2021 19:13:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=r6RKq0m7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bKK7lXHE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GaCLG_CHDmq2 for ; Tue, 9 Mar 2021 19:13:28 -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 9C9AC3A18BA for ; Tue, 9 Mar 2021 19:13:28 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id EB7225C0178; Tue, 9 Mar 2021 22:13:27 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 09 Mar 2021 22:13:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=L 8rHFKz3I/DEhs3QcMdUhDdlq5lFbI3lY76v7r9I7tQ=; b=r6RKq0m78iqlAUEET T6YQnJYKSn/ELcfi8yFAZOWJDGcR5qVhZDNKYS/8YMp4RoE3bzzivBQB3qj/bv39 oFuwE3ewJKAlblCcA2CuI+d8qqWG8r9gmXJjBWaK3zi2m6vXS5yFjqdstW+IGHCw hBMUWYzaFq62tGMqTuwv/doiijz4r8n1dsBmy4UaGBDjUuicC7Od9UDhwfiIyT8Z Cr/LzS2GqbEgqaVDad6+pE2VqJooqMSQZ9bbncaRzH9XpWsR0SgWQYpAHlxemQhP 5z7I1egzvkIq7CFJna9U5oBY3RxTdszUEfbFzqGkCLObh6a8YvrZ0th3Ogz5PqsD LS+ZA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=L8rHFKz3I/DEhs3QcMdUhDdlq5lFbI3lY76v7r9I7 tQ=; b=bKK7lXHEYW0IEVtzM7KOC6nv5sGOQIciPKhc0bOBTP/3eRtmg6VcZPj6m WvuRpu4Ou0hVMwgSZZcLb2CeRR9yB95y9F8K2grj49KhURd/CDkpsPfFYNWLv6iq 23y0IV6a9ZiR6ktIT1qARb9Nz8b+WfrowNeDrbgXtApNXwe8P/vqpSDlp3JiV+++ hNqSM4qRPMZWG9j9LQr/9ZyhhszcfOFM2EkLyEFb95BxVJLR75yjZD5hek3nt2uR vPLLhpMjShyxt04JqCVutV29y7XQ+BQnnvUZdGC2ReT5T1ViEPTJTJQvTv9j8WxG 1lRQwgPUOlAd6iU4B7/h2Ga5n7Z1A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddujedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnhepieeivdettdevkefftdeuhefhleevff duheeuheegjeevueeufeefffejiefhlefgnecuffhomhgrihhnpehrfhgtrdhfhihipdhi rggsrdhorhhgpdhmnhhothdrnhgvthenucfkphepudduledrudejrdduheekrddvhedune cuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohht sehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 7D9C224005C; Tue, 9 Mar 2021 22:13:25 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: Date: Wed, 10 Mar 2021 14:13:22 +1100 Cc: Michael StJohns , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <49E13344-7CE1-4B8A-8831-D2AF3AF6B3ED@mnot.net> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> To: Jay Daley X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Mar 2021 03:13:31 -0000 FWIW, I prototyped this here: https://rfc.fyi/ ... but haven't seen much in the way of contributed tags. I'm = considering writing a bot of some sort to facilitate that (Twitter? = Jabber? Dunno). Cheers, > On 10 Mar 2021, at 6:14 am, Jay Daley wrote: >=20 >=20 >=20 >> On 9/03/2021, at 12:44 PM, Michael StJohns = wrote: >>=20 >> Hi - >>=20 >> This is certainly not something for long discussion related to the = model, just something that I thought of that might be a useful set of = deliverables for the future RSE/A/whatever. >>=20 >> In a long ago discussion, we had various discussion/rants about the = spaghetti like nature of certain of the standards families (TLS and DNS = spring to mind) and the difficulty for someone reading RFCs without IETF = experience to figure out which RFCs are actually necessary to build a = working protocol engine. >>=20 >> Perhaps one of the great services an RSE might do is to write a = series of "Welcome to the DNS protocol suite - would you like = instructions?" RFCs that actually attempt to describe how a particular = group of RFCs relate to each other. As has been noted elsewhere, these = are probably not documents that would attract enough volunteer hours to = create. They would also be somewhat formulaic, and ideally more an = annotated bibilography than a new set of standards documents. >>=20 >> As I noted above, this is just a side idea to be ruminated on rather = than anything to feed into the endless maw of the current discussion. >=20 > I have a naive question - has any thought been given to doing this = bottom up not top down, say by defining a fixed set of technology tags = (DNS, TLS etc) and having the authors apply those to their documents? >=20 > Jay >=20 >>=20 >> Mike >>=20 >>=20 >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=20 > Jay Daley > IETF Executive Director > jay@ietf.org >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Wed Mar 10 18:29: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 780133A0CF9 for ; Wed, 10 Mar 2021 18:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.119 X-Spam-Level: X-Spam-Status: No, score=-7.119 tagged_above=-999 required=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_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=WIIOWvbo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WK/G10vc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4cjv61u2b1I for ; Wed, 10 Mar 2021 18:29:43 -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 712883A0CF8 for ; Wed, 10 Mar 2021 18:29:43 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 9566E5C0158 for ; Wed, 10 Mar 2021 21:29:42 -0500 (EST) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Wed, 10 Mar 2021 21:29:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=jPpiKOt 7kpZFvZTCRjQ5ShrXkRxn0oByQQI3VmhZoTk=; b=WIIOWvboti1jW9GbRsJYByh nsDvOrec6G9+CBqcpMYiejk/AWSKJ3q+abqljef920Ky6CxClF/46ZpccWgGh9dS z+30rwsh0pMVv2ApGFg9VBHs7RsYRsYeWBQIizUb2Q7ugky2p6eavazrR+7cFRrA zY2Bovygfya1oR+OKlw+iQIW9/8nSU2Iar1D5fzPw8yDhpbsi3qPiNf3ggRqOA1F rHV4GrLMggJ+afszhdC+wYarvTSmRwI2+Dkv/gd/WSYEUV4v7WSRMun9NLbfJ+HH Rf+24iYbMUSXIQ7b9pxxIdw2IzPn2ATT4G0JxhWeLUS0vss+GL0cF+ZUpUIg/Ew= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jPpiKO t7kpZFvZTCRjQ5ShrXkRxn0oByQQI3VmhZoTk=; b=WK/G10vcKp5/aVw1XZf0Ta fQNUIqIB9Dgh+NucFYMkugS4clTCLVd/V2/+vh/Qje8bn06N30EUPFR+AFs63hxk xMgayTZnhszsDQPNtMxQVIgo9npKeJ7D8+rGc7Llz8gxj5Ls8yVTeD014tb4cO4r 0dHJLlhEd3Yq4FFUfXJcyxLKcQi4K85KKIAWXBAh5bBDoYOS5/MqvPrKwvsEY0VW bv6k0KXftMtq/h933SbgYs3n+pwrhug8Rrvl9boD/IG7d7LbKMeH3tUEWmJPGIWs vBj90ufYJ/bJ4ssHmAsOpXQ3KJqN4JOk5WLWxNJB2w6WRneJiHiIVPwpiOF/RZJQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudduledggeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerredtnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeelveevgeeihf elhfeiffffgfehkeejfeeifffhiefhkeehgeeugfdvffehffdtteenucffohhmrghinhep rhhftgdrfhihihdpihgrsgdrohhrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghdomhgvshhmthhpohhu thhgohhinhhgqdgsrhhonhhgpeepfhgrshhtmhgrihhlthgvrghmrdgtohhmsehfrghsth hmrghilhdrfhhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EDC7F260005D; Wed, 10 Mar 2021 21:29:41 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-206-g078a48fda5-fm-20210226.001-g078a48fd Mime-Version: 1.0 Message-Id: In-Reply-To: <49E13344-7CE1-4B8A-8831-D2AF3AF6B3ED@mnot.net> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <49E13344-7CE1-4B8A-8831-D2AF3AF6B3ED@mnot.net> Date: Thu, 11 Mar 2021 13:29:21 +1100 From: "Bron Gondwana" To: rfced-future@iab.org Content-Type: multipart/alternative; boundary=c702357e4f24411caa11f61baf190a54 Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 02:29:45 -0000 --c702357e4f24411caa11f61baf190a54 Content-Type: text/plain And even without much in the way of contributed tags - it's the first place I go when I'm looking for related specs these days, because it's fast and it's easy to use. Thanks Mark for prototyping :) Cheers, Bron. On Wed, Mar 10, 2021, at 14:13, Mark Nottingham wrote: > FWIW, I prototyped this here: > https://rfc.fyi/ > > ... but haven't seen much in the way of contributed tags. I'm considering writing a bot of some sort to facilitate that (Twitter? Jabber? Dunno). > > Cheers, > > > > On 10 Mar 2021, at 6:14 am, Jay Daley > wrote: > > > > > > > >> On 9/03/2021, at 12:44 PM, Michael StJohns > wrote: > >> > >> Hi - > >> > >> This is certainly not something for long discussion related to the model, just something that I thought of that might be a useful set of deliverables for the future RSE/A/whatever. > >> > >> In a long ago discussion, we had various discussion/rants about the spaghetti like nature of certain of the standards families (TLS and DNS spring to mind) and the difficulty for someone reading RFCs without IETF experience to figure out which RFCs are actually necessary to build a working protocol engine. > >> > >> Perhaps one of the great services an RSE might do is to write a series of "Welcome to the DNS protocol suite - would you like instructions?" RFCs that actually attempt to describe how a particular group of RFCs relate to each other. As has been noted elsewhere, these are probably not documents that would attract enough volunteer hours to create. They would also be somewhat formulaic, and ideally more an annotated bibilography than a new set of standards documents. > >> > >> As I noted above, this is just a side idea to be ruminated on rather than anything to feed into the endless maw of the current discussion. > > > > I have a naive question - has any thought been given to doing this bottom up not top down, say by defining a fixed set of technology tags (DNS, TLS etc) and having the authors apply those to their documents? > > > > Jay > > > >> > >> Mike > >> > >> > >> -- > >> Rfced-future mailing list > >> Rfced-future@iab.org > >> https://www.iab.org/mailman/listinfo/rfced-future > > > > -- > > Jay Daley > > IETF Executive Director > > jay@ietf.org > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > -- > Mark Nottingham https://www.mnot.net/ > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --c702357e4f24411caa11f61baf190a54 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
And even without much in the way of contributed tags - it'= s the first place I go when I'm looking for related specs these days, be= cause it's fast and it's easy to use.

Thanks Mark for prototyping :)

Cheers,
=

Bron.

On Wed, Mar 10, 2021, at 14:13, Mark Notti= ngham wrote:
FWIW, I prototyped this here:
  https://rfc.fyi/

... but haven't seen much in the wa= y of contributed tags. I'm considering writing a bot of some sort to fac= ilitate that (Twitter? Jabber? Dunno).

Cheers,
<= div style=3D"font-family:Arial;">

> On 10 Mar 2021, at= 6:14 am, Jay Daley <jay@ietf.org> wrote:
> 
<= /div>
> 
> 
>> 
>> Hi -
>> 
>= ;> This is certainly not something for long discussion related to the= model, just something that I thought of that might be a useful set of d= eliverables for the future RSE/A/whatever.
>> 
= >> In a long ago discussion, we had various discussion/rants about= the spaghetti like nature of certain of the standards families (TLS and= DNS spring to mind) and the difficulty for someone reading RFCs without= IETF experience to figure out which RFCs are actually necessary to buil= d a working protocol engine.
= >> 
>> Perha= ps one of the great services an RSE might do is to write a series of "We= lcome to the DNS protocol suite - would you like instructions?" RFCs tha= t actually attempt to describe how a particular group of RFCs relate to = each other.  As has been noted elsewhere, these are probably not do= cuments that would attract enough volunteer hours to create.  They = would also be somewhat formulaic, and ideally more an annotated bibilogr= aphy than a new set of standards documents.
>> 
>> As I noted above, this is just a side idea to be ruminated on = rather than anything to feed into the endless maw of the current discuss= ion.
> 
> I have a naive question - has any tho= ught been given to doing this bottom up not top down, say by defining a = fixed set of technology tags (DNS, TLS etc) and having the authors apply= those to their documents?
&g= t; 
> Jay
> 
>> 
= >> Mike
>> <= br>
>> 
>> -- 
>> Rfced-future mailing list
<= div style=3D"font-family:Arial;">> 
> -- 
= > Jay Daley
> IETF Exec= utive Director
> 
= > -- 
> Rfced-futu= re mailing list
Mark Nottingham   https://www.mnot.net/
-- 
Rfced-future mailing list
<= br>

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


<= /html> --c702357e4f24411caa11f61baf190a54-- From nobody Wed Mar 10 19:58: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 C73873A0BF8 for ; Wed, 10 Mar 2021 19:58:39 -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, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiRHyC3ox5H2 for ; Wed, 10 Mar 2021 19:58:37 -0800 (PST) Received: from insect.birch.relay.mailchannels.net (insect.birch.relay.mailchannels.net [23.83.209.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 A5AA63A0BF9 for ; Wed, 10 Mar 2021 19:58:37 -0800 (PST) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id CCA43322CC5; Thu, 11 Mar 2021 03:58:35 +0000 (UTC) Received: from pdx1-sub0-mail-a39.g.dreamhost.com (100-101-162-9.trex.outbound.svc.cluster.local [100.101.162.9]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 6569F322BDB; Thu, 11 Mar 2021 03:58:35 +0000 (UTC) X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com Received: from pdx1-sub0-mail-a39.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384) by 100.101.162.9 (trex/6.1.1); Thu, 11 Mar 2021 03:58:35 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com X-MailChannels-Auth-Id: dreamhost X-Madly-Turn: 3255357824c1faa4_1615435115691_227484814 X-MC-Loop-Signature: 1615435115691:1295056358 X-MC-Ingress-Time: 1615435115691 Received: from pdx1-sub0-mail-a39.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a39.g.dreamhost.com (Postfix) with ESMTP id 2F7087E697; Wed, 10 Mar 2021 19:58:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=nwuOp2U+c0j4nG cknoSIopQLwwE=; b=IIDZcyiroN32FXZ+5F0EJRlia7gG0q4rClBVVKwp5K0c+g aw6e973m082s6oqf4SjZNs9BIhrPbTEdp7YAHXNd3NTw1b+9OSQQa5EsV3rPnfLG kAsF1h5BFsv7Twy8kxErPnSF7ybPf1bNZXgCdyYq245MbJkn/zTNZ5ISAi/tY= Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a39.g.dreamhost.com (Postfix) with ESMTPSA id 284977EE56; Wed, 10 Mar 2021 19:58:31 -0800 (PST) Date: Wed, 10 Mar 2021 21:58:28 -0600 X-DH-BACKEND: pdx1-sub0-mail-a39 From: Nico Williams To: John C Klensin Cc: rfced-future@iab.org Message-ID: <20210311035223.GK30153@localhost> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <0219B568-3FDC-4BEA-B0AD-3F70857F374A@tzi.org> <0173ce6f-4522-5338-f259-b928e8508fb9@nthpermutation.com> <20210309213636.GI30153@localhost> <882F63E249CF9298EBCA3BF2@PSB> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <882F63E249CF9298EBCA3BF2@PSB> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 03:58:40 -0000 On Tue, Mar 09, 2021 at 10:12:44PM -0500, John C Klensin wrote: > > I'm not suggesting that the IETF go that way in general, but > > for putting together series of RFCs as RFCs for the community > > to review, I think this would be great. One FTE could > > probably get us all the series we care about in a few years > > Depending on how we define what we care about (agreement on that > subject could, itself, take a few years). The people doing the > work would need to be technical experts in the subject matter > (not "just" technical editors). And, because there are few (if > any) people expert in all of the IETF's work areas, you might > need different people per Area and maybe different people within > some areas. I am indeed assuming that curating a set of sets of RFCs is less work, and requires less skill and expertise, than writing those RFCs took to begin with, though obviously it would require more skill and expertise than most tech writers. If your point is that the floor on skill and expertise required would make the person in question too valuable to industry, and too capable of more interesting work, to bother working for ISOC to do this work for whatever ISOC would pay... Well, I think you might be right, but still, we might be able to find such a person, and if we did, it might be worth the effort and money. > So, yes... but everything is connected to everything else and be > careful what you wish for. I'm pretty darned sure I can't wish the IETF into an ITU-T/ISO style organization :) And I wouldn't wish that anyways. Nico -- From nobody Thu Mar 11 07:36: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 0B1CC3A1118 for ; Thu, 11 Mar 2021 07:36:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.6 X-Spam-Level: X-Spam-Status: No, score=-14.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0uVF-kbRwK1 for ; Thu, 11 Mar 2021 07:36:01 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02A5C3A110B for ; Thu, 11 Mar 2021 07:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1058; q=dns/txt; s=iport; t=1615476961; x=1616686561; h=from:mime-version:subject:message-id:date:to; bh=43oyefXvL2kbtgeW8SWIg9VRl9Foc/DJFHlbwivfcaM=; b=WFJO5z+ymwR4A8eg2FflvHDj0kJqgrhgi2fo66FjBH1ldPAINrHV2ThG L9gXY3MS1iVveCmbpWcnJDMX4ssNLptMvowFKWCh7YWO3b8b3hNWO5+51 4TdQ/xmXWdgVML8bz4iLPwEkVjVlKNTF4NiINE9kzlRn8H89M81QPijFO I=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0A1AgB4NkpglxbLJq1aHgEBCxIMQIFECwKDH1YBJxKNd?= =?us-ascii?q?ogckH2LcAQHAQEBCgMBASoKBAEBhkMmNwYOAgMBAQEDAgMBAQEBBQEBAQIBB?= =?us-ascii?q?gQUAQEBAQEBAQGGNggFQwEQAYswAYMHD51tjhV0gTSEPwEDAgKGCQoGgTkBg?= =?us-ascii?q?VKHCoUogguBOAwQgisBg0YCA4Ipgn2CKwSEAWYLnwecX4MKBIMsgT2EV5JpA?= =?us-ascii?q?x+DKgERiliFU5AZiUiWb5MDg3UCBAYFAhaBaiKBWTMaCBsVZQGCPz0SGQ2OO?= =?us-ascii?q?IhqhUZAA2cCBgoBAQMJgz+JQAEB?= IronPort-HdrOrdr: A9a23:hgqb1aPREQemAsBcTiijsMiAIKoaSvp033AA0UdtRRtJNvGJjs zGppkm/DL9lTp5YhAdsP+aPq3oexnh3Lp4+5MYM7vnfASOggWVBaVj6Yen/DH6AS358YdmuZ tISKR1BN3uAVUSt6+TizWQKcoqw9WM7cmT6tv28nEFd2FXQpAlyw94DwqBe3cGJzVuNN4eCI eW4NZBqn6Gf3kaB/7LY0Utbqzku8DBko7gbFo9IyMfrCOKjT+u9dfBYnql4is= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,241,1610409600"; d="asc'?scan'208";a="34047475" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Mar 2021 15:35:56 +0000 Received: from [10.61.144.50] ([10.61.144.50]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 12BFZtf1025716 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Mar 2021 15:35:56 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_89E205D3-F2D8-49E7-B3F8-7168756D7725"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <6357FCB3-D108-4B67-8660-049472B31DBC@cisco.com> Date: Thu, 11 Mar 2021 16:35:54 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.50, [10.61.144.50] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Minutes uploaded X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Mar 2021 15:36:04 -0000 --Apple-Mail=_89E205D3-F2D8-49E7-B3F8-7168756D7725 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please see = https://datatracker.ietf.org/meeting/110/materials/minutes-110-rfcefdp-00.= --Apple-Mail=_89E205D3-F2D8-49E7-B3F8-7168756D7725 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBKONoACgkQh7ZrRtnS ejPCgAf+KLtrT1/Dsqz9qbrI4cyCyk2q1yxmWEcN38oiZ72Ati0+P6eFdfjg1IgJ LY040uX7idgnzrIaqCcBzkd7Vawn7Tv3EhAIv+mh1YtP8sQ/wZDrC1jdJZwuxfT4 2J2HLXAcWFyPc3FtFePq7LnGVjOXzfxtibSMiJKUZPqoL5YAqDmqeC7XOOqWEzVM 9lwX/6x50k+aWTtRG7l0o9H2CrUtPNkl/b5GcQRAkM5YrCpTtbw1yqqMrfVaBtkM h55pvjMl1jSiQzdi49z3deMOdJfcP91e0JJ/78PBnioPutw4ADcPbhYR2rHMquxB zJryOJJX8gfz3LGbbYX2ft6g68Q7vw== =aw+k -----END PGP SIGNATURE----- --Apple-Mail=_89E205D3-F2D8-49E7-B3F8-7168756D7725-- From nobody Sun Mar 14 18:12: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 C67613A0DE4 for ; Sun, 14 Mar 2021 18:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHBQq7HdCCoY for ; Sun, 14 Mar 2021 18:12:01 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-eopbgr1410138.outbound.protection.outlook.com [40.107.141.138]) (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 731B83A0DE2 for ; Sun, 14 Mar 2021 18:12:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SvzT6b/bsBVeOJ7ikaeIwXZhFRfIb2wZtQmC/tQ34cyAz+hPbARbFJ8iV73wBy1k6VZMqmaPjTsMkfLZk+ZoGAIP4buC9uJlvHmEb0sUQWeTITlayEKQOWDepad8t7Pw5fyXqnGwIdtOeEHr5WBk/xSrqPuWCwXRgvRj8SZLNp/AKmDp7RhDlOqhC87wCuG/rNfUjEMO/ffDQnhIVoN3gmMTbgaokWuxSi4ImimAI0fCvxla/ddpEWftFHH+FnfSBNdlhU33OdqF1j4J5v4mpVwwPuW2OZRpus86osMhFfcqzb2QFCyy162YLWnbyKEhZ7LQZr6l9zGiNUl/ss5S8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a1Wg5fXkqPA6bnSKaHuPXXpmhwR+qF1HovvbeLemKPA=; b=g+6vh7uiqEyW0gXTeuUDnaeVirQ1sfBdCRo2cW6OZVxV6zGZTs8U9g0iY2i0gS3/LoUz3xFykLOC4ZRlNLiirL7lboGktTiFm3Mx6T8+R41RTFdZslucGRtvyvWoJ21SLIU6SV3c9u+8WRiZD2WQ+k/WrutNx2rZblx1xuV10v7SXYILL1USkLZk/YNlejDuV3vvLimn7TqHBZWbkN35qdP7Gsqhqw1azdWkaPqPXR3gEuNaz4U48hZuKU4aZxp4Xuaxad9ciiFbDlx5j+LCv5Baqf0h25zhmj5wVrZqQTHsGrdQjkM7BY7H/jARx7kQkHHPplwKk900UaxPaiBF/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=a1Wg5fXkqPA6bnSKaHuPXXpmhwR+qF1HovvbeLemKPA=; b=Mha+c8gzTnHzSYb9MuPvcRIbrpyojKq912yfPCCKFzqgK4lzLokOqUQxs9diJw75E+UUKNWWphi4btSX0VytbCrjs1h054sjXje2lSsZqfvkvtO+FMQcMI7NwgQ1hH6thi9w7qY64GkSqml0TXGy4ox5KOo6I/XBmRx2IJ4x/H4= Authentication-Results: iab.org; dkim=none (message not signed) header.d=none;iab.org; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB4608.jpnprd01.prod.outlook.com (2603:1096:404:125::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31; Mon, 15 Mar 2021 01:11:55 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2%4]) with mapi id 15.20.3933.032; Mon, 15 Mar 2021 01:11:55 +0000 References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> To: "rfced-future@iab.org" From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University X-Forwarded-Message-Id: <161551347322.9380.3417782072654776845@ietfa.amsl.com> Message-ID: <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> Date: Mon, 15 Mar 2021 10:11:54 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.0 In-Reply-To: <161551347322.9380.3417782072654776845@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [223.217.46.174] X-ClientProxiedBy: TYAPR01CA0041.jpnprd01.prod.outlook.com (2603:1096:404:28::29) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.7] (223.217.46.174) by TYAPR01CA0041.jpnprd01.prod.outlook.com (2603:1096:404:28::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3933.31 via Frontend Transport; Mon, 15 Mar 2021 01:11:55 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 916f7f1a-6c51-444a-88d2-08d8e74f5323 X-MS-TrafficTypeDiagnostic: TYAPR01MB4608: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8273; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pM0kWlEhMcSRou3JWyKEtMSD1w0VESkDszxnUBwV/RXbZ3/xtO1zov5DA/FZz0U/1uGp2oSSG1ozG8eE0hnGytQQIKknJ9ifY6dARBThgbju1q5HFuzCG2PSkNRko4kxNioE96lD2ib93s5XYFanBiIkl+bbiWUtyT3t2O6HkoOiWTcwrS2OkANsNagaGALY7Bk6RV+s0cst2hO/sMF9b2475wtwXjBslT0L/kGahtYdzZEF5mZ3QrKQd845WWNdwV1Ddgcgy7acvKl1BZtVMLSxSGICSx2BeM28Rh0Kd5xZTXHjKXkPIDSPQWnASfmT5WUTlgaoVmhJwB79v7T++7nNN70AoNGCYkIz75WmS72+Qzaca3hV6ZGKlD1QHiwWMoobCteMrw28SiojwZ+bjiF0GzPbNfpbIFyUSAI/ojnFwMgpVAPH/HcNErHgjHrDEvAtlIM8lNsc2H8LulpV91+2LQz+zglBxGG92eEGocZ/DulD7cRNA0UhBy5s5wogzoheEfCrpRPVYjL67BaSRd7BaPbyW7+w6l1LbuDl5l9621h8g9W/WP5oZwSUGonsZqWQBKI+MIPs7O/T/07AdMd4fg4SR5FKRDGXalqRkGEuxaFL9wPk6gZTIQmCuDkreA2qE4i6F7VD77FE/yOpDfMBBwoRlDmSclFBZ/25ySnPCH+cZ7TlxgLK64HuLokAMLZGvpcIYZVeDSBre7u9GbV3J5e6/OOg477AbtVmh2U= 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)(396003)(376002)(346002)(136003)(366004)(966005)(31696002)(8676002)(16526019)(66476007)(186003)(478600001)(66574015)(83380400001)(66556008)(2906002)(8936002)(956004)(31686004)(52116002)(36916002)(316002)(66946007)(6916009)(786003)(16576012)(86362001)(5660300002)(6486002)(26005)(2616005)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?aXpvRmJ0UkYrQ29LcHMwR0tTc3BhdFYvdWppK3hLdUNKRzhPbzZXd2w5aVZO?= =?utf-8?B?QWd0SDZ5b2FuNDRGOE1UL2lzVzdwdjJtb1dFdzdvVUdIb0xvNTVwM1ZQaGVo?= =?utf-8?B?NDU4ZEl1T1lybW0zL0pndlJUcmMzNzNtNzJveklnSlBVcHhCN1pKbmowRXRh?= =?utf-8?B?RHU0N29RR04rM0hwb0ZwandTWXBwSUpLT2pkRURuQWVFbDhOREtTSk5PcTRo?= =?utf-8?B?K2EzTERhTjd3VG1Tc1RxOWRmZmlnUThhUlVxeERraXB4UGNEZE9zMHpicHYy?= =?utf-8?B?b1hzME5id2hVVnpqMTVIRW8rc1QvbjJGU3NqamNWWE9XaDVaVmdIb3dPZUIz?= =?utf-8?B?NFBBMFYrR08wUmVKYXRReFJjTThIMHBGWWdtaDZXTTJHQm8vNkhsY3M1Q2I5?= =?utf-8?B?RDBRbWxtMXBsRjV6bFNPd2pTNXB3K2lvSmI0MTlKTE1VbE0zRitBbXg5Q0wz?= =?utf-8?B?dDQ4VCtVd04vcXppZFp4cGdIRjkrVTdEc1hTZWxvUTlvMmZYQytYdmF0RExF?= =?utf-8?B?b1Vsa2VZbklzVlR0aGIrdDRncFducDI5YUY1ZFBlOEEvbFVDQzBiR1NXTUtv?= =?utf-8?B?U2dCbEcxQWltMmVxbm1nNEJSbjdnK05xeUllRUhsakwxdnBWakhid3dDOHFR?= =?utf-8?B?NHl1VWtuM2JyVmZwMlhuTVUwRlhqSWdDTURqMmtpeFpjaFJvTDdkelJRYm02?= =?utf-8?B?M3RtenRXNFA1QzE0RUxPT084cWhjcDlCelBwdGhLMkFmNUpld3RLSmlheW5m?= =?utf-8?B?ZGcrc1dlRUJ5dEJaSGI0RXh0MVVyUnlwZ3RIVkliMUhNLzVHaVEwQUZJZFNW?= =?utf-8?B?QlZCRkNZU1FKK2dOcU8xZ3hqV0doaEFHWEZydlhpN2FkUFlJbnlYNXJ5N1lC?= =?utf-8?B?d0l5K3dOTSs5cGZyNHo1Wnpxdit4eThXRVBkNW1heDJNV0JhUlc0Z1lXaFMr?= =?utf-8?B?VDBnYW5WWDgrdHNUc0d4aC9QSEVSVmt6eEpWVGFRekhoT1F5V2YvN1VDZk5N?= =?utf-8?B?THl0SHYvakNreEZ0SnN2dEc4VE1lV2pzQkdJRVNjNzh1NXpLTGVvQnpCVVdq?= =?utf-8?B?YkY4TVRYa3FESmtnc2pwZWdsUmdWeUNrVWlLMHkxSFhFdy9KZ2YwcWlmOVh3?= =?utf-8?B?NUo4TDB4b0R4UXh4SFJVc01SQ3FyMW1tWTFjd0o0RVZ5NVdaVlRzejJGZm1s?= =?utf-8?B?TS9LdENSMy9lYXBpL1pqVVVNSklFVzlhN2I5eFJON25xSEFkVHoyZmdmRCtm?= =?utf-8?B?YjR0YjliSlNCa0MwajVIbWswR0ZsU2NiSENDQzJVRG5XV3JRVmkrNzFlK3Zx?= =?utf-8?B?VnNBN2RMZW5YMktKL3I3TkdaSkg4R3ErTnlsVkdlVzVkWVdGbmhTKzJ3RmZh?= =?utf-8?B?WG9kN2F0WWZOR1lZbzNBQ3B5VEh3cDNDeVczOG5tYk9lUmJvZXduRExSZEE3?= =?utf-8?B?eWtaRFhyTjhYbDJhWUY4L2JvcWxFemlkTExDdzluaEZDOGxZai9vRVZpUkZ0?= =?utf-8?B?VTdudGt1YWErTC84bFlUQUYvQUJ5RWpiMXM4d3lBZWxkZ1VNUXpHRDFkajBL?= =?utf-8?B?aXl4Q0tlcVZOWHRQRHdxZk5CaHl5bUNQcDh6QVJBUXRETlhZOStGaDZaYTJB?= =?utf-8?B?MmNGWU1lU1VUMExOVzVCTElKc1owSEFPZkI2QVpHQTRoM1BDUWM5eGoxT01N?= =?utf-8?B?eW02aUJ6NEVJSEZtUjJxRGUrTXU3WGhWSFRyUy9CR21Mczk0NVVHK3hmUkdZ?= =?utf-8?Q?viSorhUiDM2lLAVsIRnoUsUb2xxsmt7rLNmr6oy?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 916f7f1a-6c51-444a-88d2-08d8e74f5323 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Mar 2021 01:11:55.7121 (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: uXftMibx8/qzuvTaJTTWS3JmEyaEOiIv2CBqRn42UkDLn2SDqY9WI4Z62CxHOsqLbMEDLXjEzyVB538wpSuLXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB4608 Archived-At: Subject: [Rfced-future] Fwd: I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 01:12:04 -0000 I think this draft is a simple example of work that might in some way or another in the future be done by the roles and in the structures that we are currently working on. Regards, Martin. -------- Forwarded Message -------- Subject: I-D Action: draft-nottingham-where-does-that-come-from-00.txt Date: Thu, 11 Mar 2021 17:44:33 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Clarifying IETF Document Status Author : Mark Nottingham Filename : draft-nottingham-where-does-that-come-from-00.txt Pages : 7 Date : 2021-03-11 Abstract: There is widespread confusion about the status of Internet-Drafts and RFCs, especially regarding their association with the IETF and other streams. This document recommends several interventions to more closely align reader perceptions with actual document status. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-nottingham-where-does-that-come-from/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-nottingham-where-does-that-come-from-00.html Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt . From nobody Mon Mar 15 02:39: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 980F13A0FD1; Mon, 15 Mar 2021 02:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 RCjtLqow9n6L; Mon, 15 Mar 2021 02:39:27 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAC0B3A0FD3; Mon, 15 Mar 2021 02:39:26 -0700 (PDT) Received: from p200300dee71fe600952d9c4c89be3ee1.dip0.t-ipconnect.de ([2003:de:e71f:e600:952d:9c4c:89be:3ee1]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lLjh3-00029N-JO; Mon, 15 Mar 2021 10:39:21 +0100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <49E13344-7CE1-4B8A-8831-D2AF3AF6B3ED@mnot.net> Date: Mon, 15 Mar 2021 10:39:20 +0100 Cc: Jay Daley , rfced-future@iab.org, Michael StJohns Content-Transfer-Encoding: quoted-printable Message-Id: <6C54895B-D207-4A91-84FF-42813928DD2F@kuehlewind.net> References: <5d3e8031-2202-6a49-6bce-61c46bf0eb26@nthpermutation.com> <49E13344-7CE1-4B8A-8831-D2AF3AF6B3ED@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1615801167;d95e2e60; X-HE-SMSGID: 1lLjh3-00029N-JO Archived-At: Subject: Re: [Rfced-future] Side idea X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 15 Mar 2021 09:39:29 -0000 We also have this on a per-wg level: https://www.ietf.org/topics/keywords/ > On 10. Mar 2021, at 04:13, Mark Nottingham wrote: >=20 > FWIW, I prototyped this here: > https://rfc.fyi/ >=20 > ... but haven't seen much in the way of contributed tags. I'm = considering writing a bot of some sort to facilitate that (Twitter? = Jabber? Dunno). >=20 > Cheers, >=20 >=20 >> On 10 Mar 2021, at 6:14 am, Jay Daley wrote: >>=20 >>=20 >>=20 >>> On 9/03/2021, at 12:44 PM, Michael StJohns = wrote: >>>=20 >>> Hi - >>>=20 >>> This is certainly not something for long discussion related to the = model, just something that I thought of that might be a useful set of = deliverables for the future RSE/A/whatever. >>>=20 >>> In a long ago discussion, we had various discussion/rants about the = spaghetti like nature of certain of the standards families (TLS and DNS = spring to mind) and the difficulty for someone reading RFCs without IETF = experience to figure out which RFCs are actually necessary to build a = working protocol engine. >>>=20 >>> Perhaps one of the great services an RSE might do is to write a = series of "Welcome to the DNS protocol suite - would you like = instructions?" RFCs that actually attempt to describe how a particular = group of RFCs relate to each other. As has been noted elsewhere, these = are probably not documents that would attract enough volunteer hours to = create. They would also be somewhat formulaic, and ideally more an = annotated bibilography than a new set of standards documents. >>>=20 >>> As I noted above, this is just a side idea to be ruminated on rather = than anything to feed into the endless maw of the current discussion. >>=20 >> I have a naive question - has any thought been given to doing this = bottom up not top down, say by defining a fixed set of technology tags = (DNS, TLS etc) and having the authors apply those to their documents? >>=20 >> Jay >>=20 >>>=20 >>> Mike >>>=20 >>>=20 >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >> --=20 >> Jay Daley >> IETF Executive Director >> jay@ietf.org >>=20 >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Mon Mar 15 06:33:10 2021 Return-Path: X-Original-To: rfced-future@iab.org Delivered-To: rfced-future@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B5CD3A11C2; Mon, 15 Mar 2021 06:33:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF-Announce" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.27.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161581518818.3931.1361700683805422123@ietfa.amsl.com> Date: Mon, 15 Mar 2021 06:33:08 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2021-04-06 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 13:33:08 -0000 The RFC Editor Future Development (rfcefdp) Program will hold a virtual interim meeting on 2021-04-06 from 20:00 to 22:00 UTC. Agenda: Draft Agenda: 1. Note Well 2. Agenda Bashing 3. Review a. First look at Peter's draft and comments (15 minutes) b. Results of consensus call on proposed way forward on RSE AB process and RS[EA] interaction 4. Next steps 5. AOB Join the meeting by clicking on the link below: https://cisco.webex.com/cisco/j.php?MTID=m884d5c6d11a3b5048be2cc9cb1844d0d Information about remote participation: https://cisco.webex.com/cisco/j.php?MTID=m884d5c6d11a3b5048be2cc9cb1844d0d From nobody Mon Mar 15 07:05:18 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458AD3A1254 for ; Mon, 15 Mar 2021 07:05:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OCvolfaA-7a for ; Mon, 15 Mar 2021 07:05:15 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 836153A1251 for ; Mon, 15 Mar 2021 07:05:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id CD875300B5C for ; Mon, 15 Mar 2021 10:05:12 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id YhyPrGNN3HUQ for ; Mon, 15 Mar 2021 10:05:11 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 3E76530009B for ; Mon, 15 Mar 2021 10:05:11 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Mon, 15 Mar 2021 10:05:11 -0400 References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> To: "rfced-future@iab.org" In-Reply-To: <161551347322.9380.3417782072654776845@ietfa.amsl.com> Message-Id: X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 14:05:17 -0000 I think the logo in RFCs is a good idea. However, in I-Ds, we often put = forward an idea thinking that we know which stream it will land, but due = to comments or other events the document lands in a different stream. =20= Russ -------- Forwarded Message -------- Subject: I-D Action: draft-nottingham-where-does-that-come-from-00.txt Date: Thu, 11 Mar 2021 17:44:33 -0800 From: internet-drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : Clarifying IETF Document Status Author : Mark Nottingham Filename : = draft-nottingham-where-does-that-come-from-00.txt Pages : 7 Date : 2021-03-11 Abstract: There is widespread confusion about the status of Internet-Drafts and RFCs, especially regarding their association with the IETF and other streams. This document recommends several interventions to more closely align reader perceptions with actual document status. From nobody Mon Mar 15 10:47: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 389943A187A for ; Mon, 15 Mar 2021 10:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mlukRWbTjSs for ; Mon, 15 Mar 2021 10:47:07 -0700 (PDT) Received: from smtp91.ord1c.emailsrvr.com (smtp91.ord1c.emailsrvr.com [108.166.43.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 752983A1879 for ; Mon, 15 Mar 2021 10:47:07 -0700 (PDT) X-Auth-ID: fluffy@iii.ca Received: by smtp4.relay.ord1c.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 9064DA0087; Mon, 15 Mar 2021 13:47:06 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Cullen Jennings In-Reply-To: <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> Date: Mon, 15 Mar 2021 11:47:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> To: "rfced-future@iab.org" X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Classification-ID: 294fdf95-0ed8-45c2-91b5-9e6cd1c7c926-1-1 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 17:47:09 -0000 I=E2=80=99m think have the logo in the RFC, and a authoritative location = to get them from is a good idea.=20 > On Mar 14, 2021, at 7:11 PM, Martin J. D=C3=BCrst = wrote: >=20 > I think this draft is a simple example of work that might in some way = or another in the future be done by the roles and in the structures that = we are currently working on. >=20 > Regards, Martin. >=20 >=20 > -------- Forwarded Message -------- > Subject: I-D Action: draft-nottingham-where-does-that-come-from-00.txt > Date: Thu, 11 Mar 2021 17:44:33 -0800 > From: internet-drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Clarifying IETF Document Status > Author : Mark Nottingham > Filename : = draft-nottingham-where-does-that-come-from-00.txt > Pages : 7 > Date : 2021-03-11 >=20 > Abstract: > There is widespread confusion about the status of Internet-Drafts = and > RFCs, especially regarding their association with the IETF and other > streams. This document recommends several interventions to more > closely align reader perceptions with actual document status. >=20 >=20 > The IETF datatracker status page for this draft is: > = https://datatracker.ietf.org/doc/draft-nottingham-where-does-that-come-fro= m/ >=20 > There is also an HTML version available at: > = https://www.ietf.org/archive/id/draft-nottingham-where-does-that-come-from= -00.html >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > . >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Mon Mar 15 12:45: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 C0C413A0AFE for ; Mon, 15 Mar 2021 12:45:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WX9cftJDGc97 for ; Mon, 15 Mar 2021 12:45:01 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC2A73A0AE2 for ; Mon, 15 Mar 2021 12:45:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4Dzn250hnLz6G7sB; Mon, 15 Mar 2021 12:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1615837501; bh=9vDRF+UqXaZ1yCEyrqOVHv0NHDSwCn4jbz2FR2VJOLM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=XzmoEkCSmjwGm74e64bLcfJBz7QC2BjYJwOiXFRqYP0MU2QNVQx7MR1U0PV9Zt8T4 lgzlr9S6u79SQiPAxsDCGttP4FjQRdL9szZuy1s/6UkWskSdh6uvlq4Taj/3/fR2Ww Phk8ljGf5leLuogkJJNGl45fmCrg1JF+LkiIEkFc= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.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 maila2.tigertech.net (Postfix) with ESMTPSA id 4Dzn243QQBz6G7fw; Mon, 15 Mar 2021 12:45:00 -0700 (PDT) To: Cullen Jennings , "rfced-future@iab.org" References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> From: "Joel M. Halpern" Message-ID: <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> Date: Mon, 15 Mar 2021 15:44:59 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 19:45:04 -0000 If one wants an authoritative location for RFCs, then one gets them from rfc-editor.org. The logos may be a good idea. (We have an unfortunate problem that there is no decision process for resolving that part. It isn't the IETF's call by itself.) Yours, Joel On 3/15/2021 1:47 PM, Cullen Jennings wrote: > > I’m think have the logo in the RFC, and a authoritative location to get them from is a good idea. > > >> On Mar 14, 2021, at 7:11 PM, Martin J. Dürst wrote: >> >> I think this draft is a simple example of work that might in some way or another in the future be done by the roles and in the structures that we are currently working on. >> >> Regards, Martin. >> >> >> -------- Forwarded Message -------- >> Subject: I-D Action: draft-nottingham-where-does-that-come-from-00.txt >> Date: Thu, 11 Mar 2021 17:44:33 -0800 >> From: internet-drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> >> >> Title : Clarifying IETF Document Status >> Author : Mark Nottingham >> Filename : draft-nottingham-where-does-that-come-from-00.txt >> Pages : 7 >> Date : 2021-03-11 >> >> Abstract: >> There is widespread confusion about the status of Internet-Drafts and >> RFCs, especially regarding their association with the IETF and other >> streams. This document recommends several interventions to more >> closely align reader perceptions with actual document status. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-nottingham-where-does-that-come-from/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-nottingham-where-does-that-come-from-00.html >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >> . >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > From nobody Mon Mar 15 13:15: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 2EEE13A0D7C for ; Mon, 15 Mar 2021 13:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FHALf27MovB9 for ; Mon, 15 Mar 2021 13:15:41 -0700 (PDT) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 197C23A0D2D for ; Mon, 15 Mar 2021 13:15:41 -0700 (PDT) Received: by mail-pg1-x52e.google.com with SMTP id v14so14203934pgq.2 for ; Mon, 15 Mar 2021 13:15:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Mq6jlHwbNABANV2g3iNzANyuOtj8GLN8dUL2cO1LykQ=; b=tI9MiRMmlTsX6CNHvw/65UIKmiQNHuqw4xInlOgbueYEzRyDdvy8yJ6xzBi1PXwoIC 29FxaS8qQb/nJmY+jg/q1qZTytwTHtqSBhQc55tytuyGpzOoxBeq3rfY9Cjtljj9JEX+ Ipe2TDpRP4hWaB/tbVUq74kUyWGmDYLpVAyUTTbezAD6vEyZ44HYQ+zQlGNY1uyySkSZ P+6YEfcfoUgQuOIvDVhL/qdtEmo2lRWqdAkmAF1ok1eL7JLq7rYlAtMrsn+aYkRCmWX/ 6O5mZpTEQwjhakYdjmeCmUOfT7bRg146rByD5Avv60gQ/IiIndQforBU0wjXcdtxPOEF 7Ywg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Mq6jlHwbNABANV2g3iNzANyuOtj8GLN8dUL2cO1LykQ=; b=V2HPqeUtHvdnH109PsmV9dRJBXgNyZjlsVW1pRBVCYYBErCi6quCFxeIwa1LWtOr0x K1dw2ZLA31bgHhVWLEbBHxDFDTZIPAScrT3U6K2sHkcOyxn3PklURI6bA3yd+aCkOjdo fpLlb5soGFXkkiGdM9vlFM31AlBwKPyJGkRedY4mt0elhW3EH0pvAqmnTzQ4qzs8tdo6 u58jzUF4xx2ovEVkD3t8MAXlRbZxq+XocUfutqiumJqUXQ4Wv4Q72uZvAOs4bEbC8gdG ABjZtetMxosrhLNLAFKcTL9yVXsj5VGwSt4UrMJUb2+3+Ppui4D7CSgnpPn6Cf50uxAV w8ZQ== X-Gm-Message-State: AOAM533hOHGSq5lZVqFEmcSfTwqzhNzfwzm5kejtKMBHeNHiUE6n+/uQ PxAD+xWOve5kc+VffNCDeIAb3EBqPfUZdA== X-Google-Smtp-Source: ABdhPJxstJu5G0oUVgfPjP0QbCseNMHPwRJkCjMLNjWi/yN0nrHm1ZT/nz63JdpWRRbIEIZkAzFjXQ== X-Received: by 2002:a63:f202:: with SMTP id v2mr755334pgh.24.1615839338851; Mon, 15 Mar 2021 13:15:38 -0700 (PDT) Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id i17sm15605828pfq.135.2021.03.15.13.15.37 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Mar 2021 13:15:38 -0700 (PDT) To: rfced-future@iab.org References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Tue, 16 Mar 2021 09:15:34 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 20:15:42 -0000 I'm not completely convinced that a logo is a good idea. But something, c= ertainly, in every PDF, HTML or HTMLized rendering: for example a simple = status line in big bold letters: Informational (IETF) Informational (IAB) Informational (IRTF) Informational (Independent) Experimental (IETF) Experimental (IRTF) Experimental (Independent) Best Current Practice (IETF) Proposed Standard (IETF) Standard (IETF) and retrofit: Obsolete Historic Status Unknown Regards Brian Carpenter On 16-Mar-21 08:44, Joel M. Halpern wrote: > If one wants an authoritative location for RFCs, then one gets them fro= m=20 > rfc-editor.org. >=20 > The logos may be a good idea. (We have an unfortunate problem that=20 > there is no decision process for resolving that part. It isn't the=20 > IETF's call by itself.) >=20 > Yours, > Joel >=20 > On 3/15/2021 1:47 PM, Cullen Jennings wrote: >> >> I=E2=80=99m think have the logo in the RFC, and a authoritative locati= on to get them from is a good idea. >> >> >>> On Mar 14, 2021, at 7:11 PM, Martin J. D=C3=BCrst wrote: >>> >>> I think this draft is a simple example of work that might in some way= or another in the future be done by the roles and in the structures that= we are currently working on. >>> >>> Regards, Martin. >>> >>> >>> -------- Forwarded Message -------- >>> Subject: I-D Action: draft-nottingham-where-does-that-come-from-00.tx= t >>> Date: Thu, 11 Mar 2021 17:44:33 -0800 >>> From: internet-drafts@ietf.org >>> Reply-To: internet-drafts@ietf.org >>> To: i-d-announce@ietf.org >>> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts di= rectories. >>> >>> >>> Title : Clarifying IETF Document Status >>> Author : Mark Nottingham >>> Filename : draft-nottingham-where-does-that-come-from-00.txt >>> Pages : 7 >>> Date : 2021-03-11 >>> >>> Abstract: >>> There is widespread confusion about the status of Internet-Drafts = and >>> RFCs, especially regarding their association with the IETF and oth= er >>> streams. This document recommends several interventions to more >>> closely align reader perceptions with actual document status. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-nottingham-where-does-that-com= e-from/ >>> >>> There is also an HTML version available at: >>> https://www.ietf.org/archive/id/draft-nottingham-where-does-that-come= -from-00.html >>> >>> >>> Please note that it may take a couple of minutes from the time of sub= mission >>> until the htmlized version and diff are available at tools.ietf.org. >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> >>> _______________________________________________ >>> I-D-Announce mailing list >>> I-D-Announce@ietf.org >>> https://www.ietf.org/mailman/listinfo/i-d-announce >>> Internet-Draft directories: http://www.ietf.org/shadow.html >>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>> . >>> >>> --=20 >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> >=20 From nobody Mon Mar 15 13:37: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 6E44E3A0B69 for ; Mon, 15 Mar 2021 13:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.347 X-Spam-Level: X-Spam-Status: No, score=-2.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, 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 xbsQBKqT7p1B for ; Mon, 15 Mar 2021 13:37:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2ED3A0B68 for ; Mon, 15 Mar 2021 13:37:39 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 12FKYOB6031772; Mon, 15 Mar 2021 20:37:38 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=AnjncS7yXOd1ueuNyqYa4GvRSET7+aWTvi4z2YeaMO0=; b=VTQC6x14v8BdbMCrFHLt92CiinWYNTHh2HeKaz4jxcczOADnfdmeQ01WuBtehhX17Yq9 DbVpEBAaVVp/x/7wI0j5bNfJNMz4N/0W0iuP8cxh3fOE1acM2RWAwg5DZNQ8S9r3Z2ji BaOjerBHa9xgkdVM6rwOSbNkyU7IrHPL6rcbMIPmIksTxh6PEmFIGtQH/RAOE1WLeM2U ggsy4j1abTI3dCVu6uswpjBzVCkrmKtWBGSCJRVNbWWYxTc2Wb5iQwU/Sy+RCxcuxpzo bQGaqzdrYROkvwm/ScDR09ZweAWP48hs4NlwJfKjM0/rMk1XsUNKkKdcZHLh3HwQXjgp pg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 378ptve0rx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Mar 2021 20:37:38 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 12FKZ0nV019639; Mon, 15 Mar 2021 16:37:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 378sm3n8w0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 15 Mar 2021 16:37:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Mar 2021 16:37:36 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.012; Mon, 15 Mar 2021 16:37:36 -0400 From: "Salz, Rich" To: "Joel M. Halpern" , Cullen Jennings , "rfced-future@iab.org" Thread-Topic: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt Thread-Index: AQHXGcM8yop/aER670CQBNaMaqCPbKqFtuWA///LVgA= Date: Mon, 15 Mar 2021 20:37:35 +0000 Message-ID: References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> In-Reply-To: <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: text/plain; charset="utf-8" Content-ID: <00CCDC884FCA4F449B84F040BB970A6D@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-15_12:2021-03-15, 2021-03-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxscore=0 spamscore=0 suspectscore=0 phishscore=0 mlxlogscore=377 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103150140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-15_12:2021-03-15, 2021-03-15 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 impostorscore=0 mlxlogscore=299 priorityscore=1501 mlxscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 phishscore=0 spamscore=0 malwarescore=0 adultscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103150140 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 20:37:41 -0000 PiAgICBUaGUgbG9nb3MgbWF5IGJlIGEgZ29vZCBpZGVhLiAgKFdlIGhhdmUgYW4gdW5mb3J0dW5h dGUgcHJvYmxlbSB0aGF0IA0KICAgIHRoZXJlIGlzIG5vIGRlY2lzaW9uIHByb2Nlc3MgZm9yIHJl c29sdmluZyB0aGF0IHBhcnQuICBJdCBpc24ndCB0aGUgDQogICAgSUVURidzIGNhbGwgYnkgaXRz ZWxmLikNCg0KSXQgaXMgdXAgdG8gdGhlIElFVEYgVHJ1c3QsIGFzIHRoZSBsb2dvIGlzIHBhcnQg b2YgdGhlIGludGVsbGVjdHVhbCBwcm9wZXJ0eSB0aGV5IG1hbmFnZS4NCiANCg0K From nobody Mon Mar 15 13:51: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 2A9AE3A0E3B for ; Mon, 15 Mar 2021 13:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o5tBi5Vi_p5B for ; Mon, 15 Mar 2021 13:51:01 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3AB3A0E39 for ; Mon, 15 Mar 2021 13:51:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4DzpVF04B3z6G99X; Mon, 15 Mar 2021 13:51:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1615841461; bh=rFmMUGs+0RB85mFu5iBMtMvlKqgwFpwkg8aCOmqDqv0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=B0Y3MBEZebW5diLXGNoPoTRnPu2a+qfITfwdlOIco5Y+6CgyKm6voufqHzgEpkuiw 2qz3ivgvq9+AFQ4bf5KacMcdc00le7yPZXOWQSZsNIZnxbOTKh5vW8LrQf+k5Qf2fp MUKrA+uJiTsPFW68Ye4WLH5lCte2CtouFJEGffjU= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.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 4DzpVD3LQlz6G7nC; Mon, 15 Mar 2021 13:51:00 -0700 (PDT) To: "Salz, Rich" , "rfced-future@iab.org" References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> From: "Joel M. Halpern" Message-ID: <26589181-75d0-889a-10d8-625a4a0ca174@joelhalpern.com> Date: Mon, 15 Mar 2021 16:50:58 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 20:51:02 -0000 I may have phrased my point badly. My concern is not whether we can get permission to use the logos. The Trust will do what it is told in terms of making such available to the IETF. The problem is that this "program" has a very narrow remit, and until it finishes and determines what the structure should be, there is no program authorized to make the level of decision to decide to modify the format by including different logos (or bold header lines, or...). (John Levine's remit is carefully narrow. And the RSOC is not decisional. Assuming it still exists, it is oversight.) Yours, Joel On 3/15/2021 4:37 PM, Salz, Rich wrote: >> The logos may be a good idea. (We have an unfortunate problem that > there is no decision process for resolving that part. It isn't the > IETF's call by itself.) > > It is up to the IETF Trust, as the logo is part of the intellectual property they manage. > > From nobody Mon Mar 15 14:41: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 9F4703A0FEA for ; Mon, 15 Mar 2021 14:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JDcJCUpKNzG5 for ; Mon, 15 Mar 2021 14:40:57 -0700 (PDT) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41633A0FE5 for ; Mon, 15 Mar 2021 14:40:57 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id g24so10274892qts.6 for ; Mon, 15 Mar 2021 14:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=x7ltCAUd5wCi8ikvNdHS7tDvnSvFhXPGrVxLWA8eYS0=; b=LqOBh7Uy5+6YzcQtJ2b/ky9qGVRO3HkyUXRlOOkWs5hOOClo8wYM4yo9GtqL5/6xNb bywaYGQvJXYub5v+ozzL9MflRkWgHBSgghbCbtcGMTvECUZHe7kCQALlXqL5SBP7zK+L WJ+YsNlCvwcAlBSrFgNrcLUb+sKJbW3pjDrIVyMPxHlKSIRcho8nqbdd8PT8oZKo4Jua /mcpFSgvdDkI/gqCnBFJh+LN8W0yKoFJPx7FdyrR385a+w85EXkppiBXFxRchFNFIGBS Qk7LYmoG16vAeySU4gkXcFHpYepWoNIsTtl+OTlJsdfl7HFpQmlf2J//PrrPYwCW70lI PBTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=x7ltCAUd5wCi8ikvNdHS7tDvnSvFhXPGrVxLWA8eYS0=; b=i451r2kTV6uZysLTiZowvx1w+rk3zbnftQYZIX0vKJ/ml7yXjVrPdEaHNNbc96JqTv RrIaJT5aZPV5JIHkAS4X7pRkk6RC/Fk5pPXf7+EtYa08vsTXl1B1ZvIJ9ukQCilBFZHq enKiWml+Vduel3WvZo3KgaGRezJEaAR8S+2mr2duYrGJsIo8BVxgxBOfWr/PLSVtE//O veMehs7jkN3GeuQme7YyTyU7gxj1EcM/BafFt0kGmGq2sn9ttXNpPR3lxI9/4L3HX59X FD6XMR9Ul7hEIyWu3aC/mWMHbtA2R67qnmPPLvspxaEegCKyB1c6mXMSWaPtSP0wrdWF VIeA== X-Gm-Message-State: AOAM530a+rygfL4U+mEujMNwXuRerbbMW8ZQzXVeffNoiZ8VT5sQECzm 3LvQINqkf6A8qGtrUEAeET1T1O+NaIQzAzHr7NGGtsUM X-Google-Smtp-Source: ABdhPJxXC3LEokJ2E+2uh9q+KVbhwUtmrv1WJTTtuVyvqUqI4erxa5Pr1P5jaI/ISOjzouwqJz30pMABvwtYJqOXhlM= X-Received: by 2002:ac8:44cc:: with SMTP id b12mr24615842qto.382.1615844456103; Mon, 15 Mar 2021 14:40:56 -0700 (PDT) MIME-Version: 1.0 References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> <26589181-75d0-889a-10d8-625a4a0ca174@joelhalpern.com> In-Reply-To: <26589181-75d0-889a-10d8-625a4a0ca174@joelhalpern.com> From: "Andrew G. Malis" Date: Mon, 15 Mar 2021 17:40:40 -0400 Message-ID: To: "Joel M. Halpern" Cc: "rfced-future@iab.org" Content-Type: multipart/alternative; boundary="000000000000d1831605bd9a1a17" Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 21:41:00 -0000 --000000000000d1831605bd9a1a17 Content-Type: text/plain; charset="UTF-8" Joel, Since there's no one entity that currently has remit to make a decision of this sort, perhaps it's up to each stream manager to decide whether to have a logo or not for their stream, although it would be nice if they all agreed. :-) Actually, I think Brian's suggestion and a logo are both good ideas. These days, branding is everything. Cheers, Andy On Mon, Mar 15, 2021 at 4:51 PM Joel M. Halpern wrote: > I may have phrased my point badly. My concern is not whether we can get > permission to use the logos. The Trust will do what it is told in terms > of making such available to the IETF. The problem is that this > "program" has a very narrow remit, and until it finishes and determines > what the structure should be, there is no program authorized to make the > level of decision to decide to modify the format by including different > logos (or bold header lines, or...). (John Levine's remit is carefully > narrow. And the RSOC is not decisional. Assuming it still exists, it > is oversight.) > > Yours, > Joel > > On 3/15/2021 4:37 PM, Salz, Rich wrote: > >> The logos may be a good idea. (We have an unfortunate problem that > > there is no decision process for resolving that part. It isn't the > > IETF's call by itself.) > > > > It is up to the IETF Trust, as the logo is part of the intellectual > property they manage. > > > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000d1831605bd9a1a17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Joel,

Since there's no one entity t= hat currently has remit to make a decision of this sort, perhaps it's u= p to each stream manager to decide whether to have a logo or not for their = stream, although it would be nice if they all agreed. :-)

Actually, I think Brian's suggestion and a logo=C2=A0are both g= ood ideas. These days, branding is everything.

Che= ers,
Andy


On Mon, Mar 15, 2021 at 4:51 PM Joe= l M. Halpern <jmh@joelhalpern.com= > wrote:
= I may have phrased my point badly.=C2=A0 My concern is not whether we can g= et
permission to use the logos.=C2=A0 The Trust will do what it is told in ter= ms
of making such available to the IETF.=C2=A0 The problem is that this
"program" has a very narrow remit, and until it finishes and dete= rmines
what the structure should be, there is no program authorized to make the level of decision to decide to modify the format by including different logos (or bold header lines, or...).=C2=A0 (John Levine's remit is care= fully
narrow.=C2=A0 And the RSOC is not decisional.=C2=A0 Assuming it still exist= s, it
is oversight.)

Yours,
Joel

On 3/15/2021 4:37 PM, Salz, Rich wrote:
>>=C2=A0 =C2=A0 =C2=A0The logos may be a good idea.=C2=A0 (We have an= unfortunate problem that
>=C2=A0 =C2=A0 =C2=A0 there is no decision process for resolving that pa= rt.=C2=A0 It isn't the
>=C2=A0 =C2=A0 =C2=A0 IETF's call by itself.)
>
> It is up to the IETF Trust, as the logo is part of the intellectual pr= operty they manage.
>=C2=A0 =C2=A0
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000d1831605bd9a1a17-- From nobody Mon Mar 15 14:55: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 B629F3A1052 for ; Mon, 15 Mar 2021 14:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 waFWJky352YL for ; Mon, 15 Mar 2021 14:55:26 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id D30E83A1053 for ; Mon, 15 Mar 2021 14:55:25 -0700 (PDT) From: Jay Daley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Tue, 16 Mar 2021 10:55:21 +1300 References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> <26589181-75d0-889a-10d8-625a4a0ca174@joelhalpern.com> To: "rfced-future@iab.org" In-Reply-To: Message-Id: <639A972F-5DFE-49A6-9A5D-40B7598F5F2A@ietf.org> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2021 21:55:28 -0000 You may all be interested in the following note I=E2=80=99ve just sent = to the tools-discuss list: > As we all know, RFCs are published on three sites: RFC Editor site, = Datatracker and tools.ietf.org; and I-Ds on a different three: = www.ietf.org, Datatracker and tools.ietf.org. These documents are = published in TXT, HTMLised TXT, native HTML, PDF and XML, with different = sites publishing different combinations, different metadata, different = features, different URL structures and different combinations of links = to each other. >=20 > To understand this and to help the various groups/people think about = what changes are needed to declutter this, I=E2=80=99ve been through = each of the three site and drawn up a comprehensive feature matrix: >=20 > = https://docs.google.com/spreadsheets/d/1Ljj4QV6YmvQo4F8MtydZH9owvwH-dMOJcw= Saz5CW4E0/edit?usp=3Dsharing >=20 > I so far have not looked at this through the lens of sub-series (e.g = BCP) >=20 > Please let me know if you see any errors or omissions. >=20 > Jay >=20 > PS the switch between RFC 8179 and RFC 8719 for examples is deliberate = not a typo. The matrix currently does not include logos or stream names as the = former are not used and the latter are ubiquitous. Jay --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Mon Mar 15 15:51: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 D51713A11DE for ; Mon, 15 Mar 2021 15:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Q7iW3+PP; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=e0mofhWk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOXRqrzXx-4E for ; Mon, 15 Mar 2021 15:51:03 -0700 (PDT) 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 C75EF3A11DC for ; Mon, 15 Mar 2021 15:51:03 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 5B6FB5C00AB for ; Mon, 15 Mar 2021 18:51:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 15 Mar 2021 18:51:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=from :content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; s=fm2; bh=m9ZXoFwlSY O2EpWKyRkvrJb9RUCZHb24gxPoHrAP60M=; b=Q7iW3+PP/twuKQmF6kPDWhzQ/P MmrX9feyRqnbPGEzvnxATvy2G1d7mvvEffDRTL1lZZHLtn6JiLHbH8M8V3nzYO1m ky7sc0b6eAiVwz2dxjPTX13vMa7R3WnJRDHVSZMTlbRmHaks23I1REr6XXBL+tdw EztS7WF0v2Pc51OP9637acPiLiT2b+HlCfVgNqn7Eye9isX5BiGgIO91q2kJdHyK EnafuhCVCTJehmZdFfCv3I2K4eyYqy3wNvdnJCVwktxpTGZ+2OmsETQy2F3Rqz/u k11ghD/d1jiXU4pY+bqMW7mZA16lQiJpOeV/u7NwhPtSOhtVc13XnZNFlNcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=m9ZXoFwlSYO2EpWKyRkvrJb9RUCZHb24gxPoHrAP6 0M=; b=e0mofhWkcGxi/mJx7VCg2L0h7jhlIrGGjS8S1DY4ElK0FIublk1oIdw1L 6Nm4sUvvY3RaYxRjuki7NMYnzYO9c9q++lRn+nGtfuiI+aEogSsXSRPYcTbF+vJP Z84u+ei/Tw0XzHGWOR1BvkGEh53OHNNugf2ftHo8XVOd5BJQstYBXj39lsoRvTBS 02Rmk7xZbYhm/ca3e7iRafULrUDMuf5xyjN3oVA/0RYc7qcpZuWJzJAZ74U4juEe DoH729U2FR8wV9R3DoHhgi73FwqrGOfMx8l/NFXgyCxPAKYj/wI+sl14ITdhigVY qgybYeqBPFRHfyc5Fsea2CXbjQlfQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefuddgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefhtgfgggfuffhfvfgjkffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuggftrfgrthhtvghrnheplefgtdekhfduuedufefghfegfefhhf ffkeejgfdvtdfhfedujefggfetudduvdefnecuffhomhgrihhnpehtihhmvggrnhguuggr thgvrdgtohhmpdifvggsvgigrdgtohhmpdhivghtfhdrohhrghdpmhhnohhtrdhnvghtne cukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecu rfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 0AA80108005C for ; Mon, 15 Mar 2021 18:50:59 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Tue, 16 Mar 2021 09:50:57 +1100 References: <161581518818.3931.1361700683805422123@ietfa.amsl.com> To: rfced-future@iab.org In-Reply-To: <161581518818.3931.1361700683805422123@ietfa.amsl.com> Message-Id: <3010C728-AE3B-4418-B0AF-18E157FC927D@mnot.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2021-04-06 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 15 Mar 2021 22:51:06 -0000 See also: = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DRFC+Editor+Fut= ure+Development+%28rfcefdp%29+PROGRAM+Virtual+Meeting&iso=3D20210406T20&p1= =3D1440&ah=3D2 > On 16 Mar 2021, at 12:33 am, IAB Executive Administrative Manager = wrote: >=20 > The RFC Editor Future Development (rfcefdp) Program will hold > a virtual interim meeting on 2021-04-06 from 20:00 to 22:00 UTC. >=20 > Agenda: > Draft Agenda: >=20 > 1. Note Well > 2. Agenda Bashing > 3. Review > a. First look at Peter's draft and comments (15 minutes) > b. Results of consensus call on proposed way forward on RSE AB = process and RS[EA] interaction > 4. Next steps > 5. AOB >=20 > Join the meeting by clicking on the link below: >=20 > = https://cisco.webex.com/cisco/j.php?MTID=3Dm884d5c6d11a3b5048be2cc9cb1844d= 0d >=20 > Information about remote participation: > = https://cisco.webex.com/cisco/j.php?MTID=3Dm884d5c6d11a3b5048be2cc9cb1844d= 0d >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce -- Mark Nottingham https://www.mnot.net/ From nobody Mon Mar 15 19:36: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 E257D3A17E9 for ; Mon, 15 Mar 2021 19:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 E6plosWkbRwm for ; Mon, 15 Mar 2021 19:36:02 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CB53A17ED for ; Mon, 15 Mar 2021 19:36:02 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id e26so7814827pfd.9 for ; Mon, 15 Mar 2021 19:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2ihb+qgPQJFk+HpnWbVLfaZds5WYVb0uJqOzp/VJDJA=; b=MIJcHoRUwTSKqZFlvES0sQWbpiiHTEzhRViM6uTJ7o0pjElf/Xq6V3hGWtckCKJfWZ qyn0MDUDkNtQ18BlvavTeli9ssPIdkzXD4la9nYw2YgvnlwDSerBaPUpGeaAAgArcBoY z8WVH076Bt6XKPGzGmaoANZNdugpHmT7oahdYXTAPU8xwAw4CwfsLUlcWmtNtJhuIsqa jLqEEYKtKzpcK1S3Or6w4VrQz/Msddh5IRTJJ+wvUhNddN/1tSuQBRCNLnyGJQZawL5Y HMbRfYocd1lbDNXTbpO3Q0yerRIJIDkBpsha+lMnySfxRsWsIKtbawqdM42y76WOz6Hg y5pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2ihb+qgPQJFk+HpnWbVLfaZds5WYVb0uJqOzp/VJDJA=; b=n1PMrs0QdkjrEGhDT0bb2AeNUmL2z7c8RD6wytWpKyiUtiturVl4nsz5sdnCxyn+ZQ yfL4A9xHdeYjaccqqmOeCRmy6v4AZBBFLK/6CugcCevLqmgFDkfURFhf4nitqALDguDc U6+zII5vsYclDEvudccSKWlMN2Iq/82nf0DqTJ7McHh3kQn4zh7z/b0/jQP1W5T/Q3SO zB0WwBF8ik1rtdrcwVUP1pVHNUTmYI9TBrk4wOvnNS0z8oasNupd3bo83jCUOlSGAUEz 1ltUu9LSgSyp+oa90+aVyruCS0KDsTFfk7sGuakJRJWmA+15WTGu+0v8OyD9p7PCC1hD j7+Q== X-Gm-Message-State: AOAM532tSQB2Zm34IpsMWfzsBeLxtq/QHKqa50PjVOXgBlEdIScbGoZZ 9zOPMnHmewsfOERiQ5MuaUW0w+mKyJIq5YXa X-Google-Smtp-Source: ABdhPJwWFAzAHc2joloWbXs1AVka8WyC6eehKZOB14JN34LbtRxwNP1oCWh4xwuMXhEZpWo/44HW0w== X-Received: by 2002:aa7:9205:0:b029:1ec:8eab:7ca3 with SMTP id 5-20020aa792050000b02901ec8eab7ca3mr13093523pfo.20.1615862161754; Mon, 15 Mar 2021 19:36:01 -0700 (PDT) Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id a19sm14679087pfc.65.2021.03.15.19.35.59 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Mar 2021 19:36:01 -0700 (PDT) To: "Andrew G. Malis" , "Joel M. Halpern" Cc: "rfced-future@iab.org" References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> <26589181-75d0-889a-10d8-625a4a0ca174@joelhalpern.com> From: Brian E Carpenter Message-ID: <8e350936-81a5-0090-63d5-1d4653809b81@gmail.com> Date: Tue, 16 Mar 2021 15:35:56 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 02:36:04 -0000 On 16-Mar-21 10:40, Andrew G. Malis wrote: > Joel, >=20 > Since there's no one entity that currently has remit to make a decision= of this sort, perhaps it's up to each stream manager to decide whether t= o have a logo or not for their stream, although it would be nice if they = all agreed. :-) >=20 > Actually, I think Brian's suggestion and a logo=C2=A0are both good idea= s. These days, branding is everything. Here's how my suggestion might look: https://www.cs.auckland.ac.nz/~brian/rfc1X.html https://www.cs.auckland.ac.nz/~brian/rfc8989X.html Brian From nobody Thu Mar 18 06:21: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 17AE83A2B78 for ; Thu, 18 Mar 2021 06:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=OMcRL+CV; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=eDPO9s30 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVIqzJetjR0G for ; Thu, 18 Mar 2021 06:21:23 -0700 (PDT) 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 D14C23A2B59 for ; Thu, 18 Mar 2021 06:21:23 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 0D1A71031; Thu, 18 Mar 2021 09:21:21 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Thu, 18 Mar 2021 09:21:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=8nUE+jF cd+h0k6z5qX+JEeEyxW3O5SFqxs+TdgLaUB8=; b=OMcRL+CVkIG+JyFKoXqBlE2 tOKkU9SeYSanNyWBfD8HeuPDSAVENj1fh42D79YKRkUA9fTJVj4sqb0flQL/HG5M eG/gOUNvO63lKSQlwMutA6/wthbeO5XzJ4Gab03VhSWkPGzNwH6oHVddD/8BWVQI AuiBuCmja+3zR1PtGL0/9Vv+u+0xHLye4Dc9PItOMPNFRWQDHSOI9utUp+DIyQks b7gn33aM0Q6gFN0d0eCkJvZ9wgpXSdwsQieqKesDCjGBAMnAwtUWEGcjTEBaLKFW XDLikc/bsOkUSqfj5Gz5cNVJ2zLMcT3woqzoD1+9GhSwOajyxvz+E/izTklkqJQ= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=8nUE+j Fcd+h0k6z5qX+JEeEyxW3O5SFqxs+TdgLaUB8=; b=eDPO9s30Kg6ksYRX6Sh+8+ /wOPaoFHQjGFDvH1S6QBcbUNWW6SO7pc23Y49yb5bWEA8HvWA3x7aR/tgtb6uClC wNQJTSOm2h7k133Fm80aZ0PT0if0nSfsHbV3lzO5pX2ruhpx7C7PZl4nM0kL1cIR RTNsNRGUMsDzXw2fEZhJ3ymlIKhpz4DRc2IPs7DlUgSpV5X4dDE9xmDKSPfQUBfE 7TndC3jucolioK3FMoL3t2cOEnQbmk9xJa/f6LDa2n68RNmJwwrnTKIEDzvWm6aM ulse56cczWPToEJk6L3CXodXBNeA2/xAyZTmxGWGL6TtOzfnEgKZM6Ck1uIYm7eQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefiedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsegrtd erreerreejnecuhfhrohhmpedfuehrohhnucfiohhnugifrghnrgdfuceosghrohhnghes fhgrshhtmhgrihhlthgvrghmrdgtohhmqeenucggtffrrghtthgvrhhnpeekuddtieejgf euhfejheetlefhtdeuvdduvdegueelteehfeehieevtdegheekffenucffohhmrghinhep rhhftgdqvgguihhtohhrrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhlthgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 25CA7260005D; Thu, 18 Mar 2021 09:21:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-271-g88286cf463-fm-20210318.001-g88286cf4 Mime-Version: 1.0 Message-Id: In-Reply-To: <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> Date: Fri, 19 Mar 2021 00:21:00 +1100 From: "Bron Gondwana" To: "Joel M. Halpern" , "Cullen Jennings" , "rfced-future@iab.org" Content-Type: multipart/alternative; boundary=2e77111e06a14623a8a2ba39d4b32a24 Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?I-D_Action=3A_draft-nottingham-where-do?= =?utf-8?q?es-that-come-from-00=2Etxt?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 13:21:25 -0000 --2e77111e06a14623a8a2ba39d4b32a24 Content-Type: text/plain On Tue, Mar 16, 2021, at 06:44, Joel M. Halpern wrote: > If one wants an authoritative location for RFCs, then one gets them from > rfc-editor.org. I am new enough to the IETF that I can tell you for sure that before I joined the IETF there's no way that I would have known that "rfc-editor.org" was the authoritative location for the IETF's RFCs. Lots of other organisations and open source projects also call their specs "RFC" - it's the IETF brand that I would have recognised. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --2e77111e06a14623a8a2ba39d4b32a24 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Tue, Mar 16, 2021, at 06:44, Joel M. Halpern wrote:
=
If one wants an authoritative location for RFCs, then one= gets them from 
rfc-edi= tor.org.

I am new enough to the IETF that I = can tell you for sure that before I joined the IETF there's no way that = I would have known that "rfc-editor.org" was the authoritative location = for the IETF's RFCs.  Lots of other organisations and open source p= rojects also call their specs "RFC" - it's the IETF brand that I would h= ave recognised.

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty = Ltd
  brong@fastmailteam.com
<= /div>


--2e77111e06a14623a8a2ba39d4b32a24-- From nobody Thu Mar 18 08:17: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 8EE643A2D99 for ; Thu, 18 Mar 2021 08:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.248, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YbSq1ixl8KrL for ; Thu, 18 Mar 2021 08:17:08 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A1833A2D98 for ; Thu, 18 Mar 2021 08:17:08 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 12IFAT6B002971; Thu, 18 Mar 2021 15:17:04 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 : mime-version; s=jan2016.eng; bh=Dx8EQ88nmVbGMPKmKSiU/wvcEFvifyvGaCYYGBPKE7A=; b=mXChzX8c+UCUqMsfbHA8qb6PLt1y2bHiBhC6H2qAuGGEUZyCAo8ytcJuCf4sPQWug2jX lqm+qAXuZx1vxR4e/63EhY31Sav7jN/VM4D4uz8jn/qtmgMKTJVN9yFJ7DJ62JSBLaoY F7q00ryfExe3S9fb/tSMb6FpyIzZbtBSHVJSNEg9UsaHsu5kYeH+UbMlFPIhBaWAhv44 4OZ3hxtnFeye7lfW4yK0EsB2FqU0JeFUx/EoLXk0w/83CyRAsv2LYnxx4h1+ww+xwp9p WLc0T0wnM0W93yfTEtt8ssMrV4I09IH08/yszDxSUZZFqTRkfFwFUKgcRwsikYT/CFcQ WA== Received: from prod-mail-ppoint3 (a72-247-45-31.deploy.static.akamaitechnologies.com [72.247.45.31] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 378ppvpmvk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 15:17:04 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 12IF5G55006073; Thu, 18 Mar 2021 11:17:03 -0400 Received: from email.msg.corp.akamai.com ([172.27.165.114]) by prod-mail-ppoint3.akamai.com with ESMTP id 37c4w92eww-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 18 Mar 2021 11:17:03 -0400 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com (172.27.165.121) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.165.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 18 Mar 2021 10:17:02 -0500 Received: from USTX2EX-DAG1MB3.msg.corp.akamai.com ([172.27.165.121]) by ustx2ex-dag1mb3.msg.corp.akamai.com ([172.27.165.121]) with mapi id 15.00.1497.012; Thu, 18 Mar 2021 10:17:01 -0500 From: "Salz, Rich" To: Bron Gondwana , "Joel M. Halpern" , Cullen Jennings , "rfced-future@iab.org" Thread-Topic: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt Thread-Index: AQHXG/meAPA4oYvh3k+b7PdKeOASXaqJ7EwA Date: Thu, 18 Mar 2021 15:17:01 +0000 Message-ID: <0F8F33CC-C359-40D1-B75C-44821AE3C239@akamai.com> References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.164.43] Content-Type: multipart/alternative; boundary="_000_0F8F33CCC35940D1B75C44821AE3C239akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-18_09:2021-03-17, 2021-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 adultscore=0 mlxscore=0 spamscore=0 mlxlogscore=879 suspectscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103180109 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-18_09:2021-03-17, 2021-03-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 lowpriorityscore=0 adultscore=0 mlxscore=0 mlxlogscore=795 clxscore=1015 bulkscore=0 suspectscore=0 spamscore=0 impostorscore=0 priorityscore=1501 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2103180110 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.31) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint3 Archived-At: Subject: Re: [Rfced-future] I-D Action: draft-nottingham-where-does-that-come-from-00.txt X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 15:17:10 -0000 --_000_0F8F33CCC35940D1B75C44821AE3C239akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCiAgKiAgIEkgYW0gbmV3IGVub3VnaCB0byB0aGUgSUVURiB0aGF0IEkgY2FuIHRlbGwgeW91 IGZvciBzdXJlIHRoYXQgYmVmb3JlIEkgam9pbmVkIHRoZSBJRVRGIHRoZXJlJ3Mgbm8gd2F5IHRo YXQgSSB3b3VsZCBoYXZlIGtub3duIHRoYXQgInJmYy1lZGl0b3Iub3JnIiB3YXMgdGhlIGF1dGhv cml0YXRpdmUgbG9jYXRpb24gZm9yIHRoZSBJRVRGJ3MgUkZDcy4gIExvdHMgb2Ygb3RoZXIgb3Jn YW5pc2F0aW9ucyBhbmQgb3BlbiBzb3VyY2UgcHJvamVjdHMgYWxzbyBjYWxsIHRoZWlyIHNwZWNz ICJSRkMiIC0gaXQncyB0aGUgSUVURiBicmFuZCB0aGF0IEkgd291bGQgaGF2ZSByZWNvZ25pc2Vk Lg0KDQpTbyBtYXliZSB3ZSBtYWtlIHJmYy5pZXRmLm9yZyBiZSBhIENOQU1FIHRvIHBvaW50IHRv IHJmYy1lZGl0b3Iub3JnID8NCg0K --_000_0F8F33CCC35940D1B75C44821AE3C239akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0 UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjIwNjI3MTA3MDI7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOjEyODkxMDkyODAgNTY3MzIxODA4IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3 Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxl dmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OkFyaWFsO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8dWwg c3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBh cmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPkkg YW0gbmV3IGVub3VnaCB0byB0aGUgSUVURiB0aGF0IEkgY2FuIHRlbGwgeW91IGZvciBzdXJlIHRo YXQgYmVmb3JlIEkgam9pbmVkIHRoZSBJRVRGIHRoZXJlJ3Mgbm8gd2F5IHRoYXQgSSB3b3VsZCBo YXZlIGtub3duIHRoYXQgJnF1b3Q7cmZjLWVkaXRvci5vcmcmcXVvdDsNCiB3YXMgdGhlIGF1dGhv cml0YXRpdmUgbG9jYXRpb24gZm9yIHRoZSBJRVRGJ3MgUkZDcy4mbmJzcDsgTG90cyBvZiBvdGhl ciBvcmdhbmlzYXRpb25zIGFuZCBvcGVuIHNvdXJjZSBwcm9qZWN0cyBhbHNvIGNhbGwgdGhlaXIg c3BlY3MgJnF1b3Q7UkZDJnF1b3Q7IC0gaXQncyB0aGUgSUVURiBicmFuZCB0aGF0IEkgd291bGQg aGF2ZSByZWNvZ25pc2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TbyBtYXliZSB3ZSBtYWtlIHJmYy5pZXRmLm9yZyBiZSBhIENOQU1F IHRvIHBvaW50IHRvIHJmYy1lZGl0b3Iub3JnID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_0F8F33CCC35940D1B75C44821AE3C239akamaicom_-- From nobody Thu Mar 18 13:59: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 B87F63A3466 for ; Thu, 18 Mar 2021 13:59:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.819 X-Spam-Level: X-Spam-Status: No, score=-2.819 tagged_above=-999 required=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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmailteam.com header.b=iYgTa00H; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZBGa5XlB Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qd5e8ekj5Vp for ; Thu, 18 Mar 2021 13:59:49 -0700 (PDT) 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 5AD373A3461 for ; Thu, 18 Mar 2021 13:59:49 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 627061030; Thu, 18 Mar 2021 16:59:48 -0400 (EDT) Received: from imap41 ([10.202.2.91]) by compute2.internal (MEProxy); Thu, 18 Mar 2021 16:59:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= fastmailteam.com; h=mime-version:message-id:in-reply-to :references:date:from:to:subject:content-type; s=fm2; bh=7qstZAe HBND9k5VJ93fxofociQS0KEEVbCgtQWA5YdM=; b=iYgTa00HnbeTVfEXmuw1h5/ aHQ2HlrjJwZMWmAB455Vwyd3hbSvsmyy3r06AZ1o4sXeFBqvNKWDerXPyO36IwxU ncwMi9R/eqR7caFy7pCN3nXqcQS2ne8tRs4fwdT4k7+V/6tpRGLiZiBcw3C+qylx C5WpsLy57kUOYa+WPeQKdZvJ72t3WO4NbFLCw4JyJ2J1PwnHA0AH3D/yNsXxE1L3 vmrcWMKROPtRJUfrT4WoP9dLdA5DSfwTEN3dYoSoOMAEj7PGzLhF3mdIVP+rP3fl TTkGhxKZ8fNZwP8Db8nSnhB77HBxaJl0p3LfMb0py7ZHAI0pV6X2RE4o9mfp5uA= = DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=7qstZA eHBND9k5VJ93fxofociQS0KEEVbCgtQWA5YdM=; b=ZBGa5XlB0aCjvIqrn8A34U 6+g2ErwQcMHC1Gv+4qLkuaYH1H9h5/PDGSxqRTMhhXlGT/B7RdP0/s9Dme+eWF8T PVDbCxOSHWqQrkOvYcfJoww7liplfpMOhwpSWkvPGOQUprAm2r6eXBd9MnzsRrhj 3jK222TqPo+XKlDFWGYUAVmGkN3P+B99b5Pm5k60iTOoPVaepdGMPZUWP3jDlC4g +eXkjxsnNvvZ5EtjI+3tTekKTgt4/mlKZfMpSijCyPIfMwgu8RQWWXNBx2GkpoLx RX2dNI02pq0caoEYEza6Z/UQKM6cVtiJ0KkjWvau0LdBr26Wl/jrmLNX7UMY63SA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudefiedgudegiecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesrg dtreerreerjeenucfhrhhomhepfdeurhhonhcuifhonhgufigrnhgrfdcuoegsrhhonhhg sehfrghsthhmrghilhhtvggrmhdrtghomheqnecuggftrfgrthhtvghrnhepheetvdfgte ffudetkedtveetueejvdevueeiudejheeffeevteffgeehjeetvdeunecuffhomhgrihhn pehrfhgtqdgvughithhorhdrohhrghdpihgvthhfrdhorhhgnecuvehluhhsthgvrhfuih iivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepsghrohhnghesfhgrshhtmhgrihhl thgvrghmrdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id E2AE2260005D; Thu, 18 Mar 2021 16:59:46 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-271-g88286cf463-fm-20210318.001-g88286cf4 Mime-Version: 1.0 Message-Id: In-Reply-To: <0F8F33CC-C359-40D1-B75C-44821AE3C239@akamai.com> References: <161551347322.9380.3417782072654776845@ietfa.amsl.com> <83a8009f-1db9-7b81-2023-cf2b18bb3b5e@it.aoyama.ac.jp> <9d80dd67-0fd3-be8e-8130-b726f4881dc8@joelhalpern.com> <0F8F33CC-C359-40D1-B75C-44821AE3C239@akamai.com> Date: Fri, 19 Mar 2021 07:59:25 +1100 From: "Bron Gondwana" To: "Salz, Rich" , "Joel M. Halpern" , "Cullen Jennings" , "rfced-future@iab.org" Content-Type: multipart/alternative; boundary=25e3456ce2014d15a6860416209ccef0 Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?I-D_Action=3A_draft-nottingham-where-do?= =?utf-8?q?es-that-come-from-00=2Etxt?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Mar 2021 20:59:51 -0000 --25e3456ce2014d15a6860416209ccef0 Content-Type: text/plain On Fri, Mar 19, 2021, at 02:17, Salz, Rich wrote: > > * I am new enough to the IETF that I can tell you for sure that before I joined the IETF there's no way that I would have known that "rfc-editor.org" was the authoritative location for the IETF's RFCs. Lots of other organisations and open source projects also call their specs "RFC" - it's the IETF brand that I would have recognised. > > So maybe we make rfc.ietf.org be a CNAME to point to rfc-editor.org ? I'm not sure I understand how that would help - maybe my understanding of CNAMEs is totally off - most of my knowledge is how they interact (badly) with email routing - but my impression is that users wouldn't be more likely to see "ietf" in either search results or the URL bar after following a link to rfc.ietf.org if it was CNAME. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd brong@fastmailteam.com --25e3456ce2014d15a6860416209ccef0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable
On Fri, Mar 19, 2021, at 02:17, Salz, Rich wrote:
=

 

  • I am new enough to the IETF that I can= tell you for sure that before I joined the IETF there's no way that I w= ould have known that "rfc-editor.org" was the authoritative location for the IETF's RFCs.  Lots of other= organisations and open source projects also call their specs "RFC" - it= 's the IETF brand that I would have recognised.

 =

So maybe we make rfc.ietf.org b= e a CNAME to point to rfc-editor.org ? 


I'm not sure I understand how that would help - maybe my unde= rstanding of CNAMEs is totally off - most of my knowledge is how they in= teract (badly) with email routing - but my impression is that users woul= dn't be more likely to see "ietf" in either search results or the URL ba= r after following a link to rfc.ietf.org if it was CNAME.

Bron.


--
  Bron Gondwana, CEO, = Fastmail Pty Ltd
  brong@fastmail= team.com


--25e3456ce2014d15a6860416209ccef0-- From nobody Wed Mar 24 06:03: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 D3B2F3A2C5C for ; Wed, 24 Mar 2021 06:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r1P387kN1iEi for ; Wed, 24 Mar 2021 06:02:53 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6CDA3A2C59 for ; Wed, 24 Mar 2021 06:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33119; q=dns/txt; s=iport; t=1616590972; x=1617800572; h=from:mime-version:subject:message-id:date:cc:to; bh=x0nvu322w5TjAwEInvuVD+j2r6kxIUDxkr7JoO6ndLU=; b=Of34hmxwB3YCEHZj80JksBwleU5LMd9gIXTm7OihFIwFBiAod5tbBpWO A5viBhkX7LoujqIYOwv+xshqYPvqjSZ+RHSKluR5T4lPxaDl5iISuoKRR GmzdNVGuWca1i7nX9TtBNCRtYTjtLEb/bAUxo/s/NBFGj3NWNdr5ByDb1 I=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ANAAAxN1tglxbLJq1aHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?AcBAQsBgSKBflYBFRISMQKEQIgkYIhFh3qHLIs/FIFoBAcBAQEKAwEBKgoEA?= =?us-ascii?q?QGEUIF/JjQJDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAQEBhjYNhmgGS?= =?us-ascii?q?wQCBUgLCgKBBoJcAYMHD6pFd4EyikMKBoE5AYFShSoBhUt6QoILgRInHIIJI?= =?us-ascii?q?oNMAoEXCQkBEgFgglc1gisEgUsJBmZuAwcTFREKBhQMAUUrMwYCBAkFBgcnH?= =?us-ascii?q?zQHkC0sjFyGHYR+kEeBFIMQgzmBQ4RckwYDH4NIimqFYSyQCYZgkDOJUpJWC?= =?us-ascii?q?UcBg34CBAYFAhaBVDhrXQwHMxoIGxU7KgGCPj4SGQ2OKw0Jg02KWkADLwYyA?= =?us-ascii?q?gYBCQEBAwmINQEB?= IronPort-HdrOrdr: A9a23:Dd9MXaCwxOvO0MPlHelN55DYdL4zR+YMi2QD/UoZc3xoW+afkN 2jm+le6A/shF8qNU0ItNicNMC7IE/02oVy5eAqV4uKeAX9omOnIMVD4OLZrQHIPy37+qpj2b x7c654YeedMXFAgcz34Ba1Hr8bqbHtzImTmezcw31xJDsEV4hc6W5Ce2WmO3wzYAFHAJYjfa DshPZvln6HZWkdaNi9Cz0jWeXOzue78K7OUFohGwMt7hWIgHeTzIPCVzKc3hsYTlp0sNIfzV Q= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,274,1610409600"; d="asc'?scan'208,217";a="34457196" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Mar 2021 13:02:50 +0000 Received: from [10.61.144.78] ([10.61.144.78]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 12OD2nxM020511 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Mar 2021 13:02:49 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_32697731-55E8-40B5-A1A6-64B31C3A9C5B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> Date: Wed, 24 Mar 2021 14:02:48 +0100 Cc: Brian Rosen To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.78, [10.61.144.78] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 24 Mar 2021 13:02:58 -0000 --Apple-Mail=_32697731-55E8-40B5-A1A6-64B31C3A9C5B Content-Type: multipart/alternative; boundary="Apple-Mail=_54640A34-B0AD-4D07-A756-32D05E2FF681" --Apple-Mail=_54640A34-B0AD-4D07-A756-32D05E2FF681 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Everyone, Thanks for your patience. As promised at our meeting, the chairs are = putting forward a proposal to move forward. This proposal comes in two parts. The first part is the process for how = drafts are developed and approved =E2=80=93 or not. It is loosely based = on what Joel presented at IETF 110, but also incorporates earlier agreed = text about the RFCWG. In this proposal, the RS[EA] does get a say on = the Approval Board. However, that person=E2=80=99s is one voice out of = five. As a companion part of this proposal, and as discussed at IETF 110, the = second part discusses the hiring and oversight of the RS[EA]. A few points: The first part in particular is intended as a compromise between very = different points of view. We do not expect anyone to be perfectly happy = with what is written, but we do ask everyone at this late stage to = withhold objections unless they positively cannot live with what is = written. Assuming there is rough consensus for this base text, changes can be = made again based on rough consensus. Surely some will be needed here = and there. The second part of the proposal is something on which we have spent less = time. It provides a fair amount of freedom to the LLC to set timing and = working method of the role. We expect this text to evolve a bit more, = but again ask that it be accepted as base text. Our proposal is that people take a day or so to read through and = consider both texts, and then ask questions or comment on list. When = commenting settles down, we will open a consensus call. Because there = was a specific request for the accountability text as part of all of = this, the consensus call will be to take both parts as a whole as base = text. Without further ado, please see the text below, which can also be found = on GitHub: = https://github.com/intarchboard/program-rfced-future/blob/master/draft-evo= lution-process.md = And = https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-= and-accountability.md = Eliot & Brian =E2=80=94 Part 1 DRAFT RFC Evolution Process Scope This procedure is applicable to the evolution processes relating to the = management and evolution of the RFC series, including format, tooling, = publication, dissemination, and overall management of the series. Structure The RFC evolution process is governed as follows: The RFC Working Group, whose job it is to develop proposed changes, and = establish community consensus of those changes. The The RFC Approval Board, whose job it is to provide final review of = proposals. Each group is described below. The RFC Working Group (RFCWG) All RFCWG meetings are open to any participant, subject to intellectual = property policies which must be consistent to those of the IETF [Note = Well]. At body's initial formation, all discussions are to take place on = open mailing lists, and anyone is welcome to comment / discuss. The = RFCWG may decide by rough consensus to use additional forms of = communication (for example, Github as specified in [RFC8874]) that are = consistent with [RFC2418]. The group will conform itself to an = anti-harassment policy consistent with [RFC7154,RFC7776]. IETF chair and the Independent Submissions Editor shall each appoint and = oversee a co-chair of the RFCWG. The RFC Approval Board (RFCAB) The RFC Approval Board consists of representatives from each RFC stream = (at the time of this writing, the IAB, the IETF, the IRTF, and the = Indepenent Series), as well as the RS[EA]. The sole function of this = group is to review draft proposals approvedby the RFCWG. The RFCAB may = choose its chair as it sees fit. The group is primarily expected to = operate via email and through any necessary tooling. A record of all = proceedings (no matter the form) will be kept. Update Process The following procedure is used to update the RFC process: Someone writes a draft proposal in the form of an Internet-Draft. If there is sufficient interest in the proposal, RFCWG will adopt the = proposal as a working draft, much the same way a working group of the = IETF would. The RFCWG will then further develop the proposal. All members of the = RFCAB are expected to participate in discussion relating to all = proposals. At some point, if the chairs believe there may be rough consensus exists = for the proposal to advance, they will issue a working group last call. After a suitable period of time, the chairs will determine whether rough = consensus for the proposal exists. If comments have been received and = substantial changes have been made, it is expected that additional last = calls may be made. Once working group consensus is established, a community call for = comments will be issued. Should substantial comments be received, the = working group will again consider those comments and make revisions as = they see fit. At this same time, the RFCAB will consider the proposal. Should substantial changes be made, additional community calls for = comment should be issued, and again comments considered. Once all comments have been been addressed, the working group chairs = will transmit the latest proposal to the RFCAB. Within a reasonable period of time, the RFCAB will then poll on the = proposal. Positions may be as follows: "YES": the proposal should be approved "CONCERN" : the proposal raises substantial concerns that must be = addressed. "RECUSE" : the person holding the position has a conflict of interest. Anyone holding a "CONCERN" position MUST explain their concern to the = community in detail. The explanation may or may not be actionable. A CONCERN may be made for two reasons: The proposal represents a serious problem for the group a particular = member represents. The member believes that the proposal would cause serious harm to the = overall series, including harm to the long term health and viability of = the series. No CONCERN should ever come as a surprise to the RFCWG. If a CONCERN exists, discussion will take place within the RFCWG. Again, = all RFCAB members MUST participate. If all CONCERN positions are addressed, then the proposal is approved. = Again, if substantial changes have been made, an additional call for = community input should be made. If, after a suitable period of time, any CONCERN positions remain, a = formal vote of the RFCAB is taken. If a majority of RFCAB members vote = to approve, the proposal is approved. Otherwise, it is returned to the = RFCWG. In the case of a tie, the proposal is approved. When a proposal is approved, a notification is sent to the community, = and it is published as an RFC. The roles of the LLC Board and ED LLC Board members, staff, and the Executive Director, are invited to = participate as community members in the RFCWG to the extent permitted by = any relevant LLC policies. Appeals Appeals of RFCAB decisions may only be made based on process failures, = and not on the substance of a proposal. These appeals SHALL be made to = the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY = decide only whether a process failure occurred, and what if any = corrective action should take place. Discussion The intent of this policy is to provide an open forum by which policies = and procedures of the RFC series are evolved. The general expectation is = that all interested parties will participate in the RFCWG, and that only = under extreme circumstances should the RFCAB members have to hold = "CONCERN" positions. To avoid that situation, WG members are encouraged = to take RFCAB concerns seriously, and RFCAB members are encouraged to = make those concerns known early, and to be responsive to the community. = In particular, people are encouraged to respect the value of each = stream, and the long term health and viability of the RFC series. This process is intended to be one of continuous consultation. In = particular, RFCAB members should be consulting with their constuent = groups on an ongoing basis, so that when the time comes to consider a = proposal, there should be no surprises. Appointing bodies are expected = to establish whatever processes they deem appropriate to facilitate this = goal. Part 2 DRAFT DRAFT DRAFT RS[EA] Selection The RS[EA] will be searched for and vetted by a committee formed by the = ED, taking into account the role definition = and any detailed job description that we further develop. = The search committee may ask others to take part in the selection = process in confidence. The initial length of service shall be for one = year, but then further extensions will be for three to five years. RS[EA] Ongoing Performance Evaluation Periodically, the ED will send out to the community a call for input on = the performance of the RS[EA]. The evaluation will be based on criteria = specified in the role definition. Was the RS[EA] an active participant = in all/most meetings? Did the RS[EA] provide useful advice to the RPC = and to the WG? Did the RS[EA] exercise good judgment in terms of any = role he or she would have had on the Approval Body? Was the RS[EA] = effective in advising the community on appropriate actions to take or = not take? The ED will then review the feedback, consulting with stream manager = representatives, and then produce a recommendation to the LLC Board. The = LLC will then make a decision, taking into account that recommendation. Whether the RS[EA] role is structured as a contractual or employee = relationship is left to the LLC and ED to determine. --Apple-Mail=_54640A34-B0AD-4D07-A756-32D05E2FF681 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Everyone,

Thanks for your patience.  As = promised at our meeting, the chairs are putting forward a proposal to = move forward. 

This proposal comes in two parts.  The first part is the = process for how drafts are developed and approved =E2=80=93 or not. =  It is loosely based on what Joel presented at IETF 110, but also = incorporates earlier agreed text about the RFCWG.  In this = proposal, the RS[EA] does get a say on the Approval Board. =  However, that person=E2=80=99s is one voice out of five.

As a companion part of = this proposal, and as discussed at IETF 110, the second part discusses = the hiring and oversight of the RS[EA].

A few points:

  • The first part in particular is intended as a compromise = between very different points of view.  We do not expect anyone to = be perfectly happy with what is written, but we do ask everyone at this = late stage to withhold objections unless they positively cannot live = with what is written.
  • Assuming there is rough = consensus for this base text, changes can be made again based on rough = consensus.  Surely some will be needed here and there.
  • The second part of the proposal is something on which we have = spent less time.  It provides a fair amount of freedom to the LLC = to set timing and working method of the role.  We expect this text = to evolve a bit more, but again ask that it be accepted as base = text.

Our proposal is that people take a day or so to read through = and consider both texts, and then ask questions or comment on list. =  When commenting settles down, we will open a consensus call. =  Because there was a specific request for the accountability text = as part of all of this, the consensus call will be to take both parts as = a whole as base text.

Without further ado, please see the text below, which can = also be found on GitHub:

https://github.com/intarchboard/program-rfced-future/blob/maste= r/draft-evolution-process.md

And

https://github.com/intarchboard/program-rfced-future/blob/maste= r/rse-hire-and-accountability.md

Eliot & Brian

=E2=80=94
Part 1


DRAFT RFC Evolution = Process

Scope

This procedure = is applicable to the evolution processes relating to the management and = evolution of the RFC series, including format, tooling, publication, = dissemination, and overall management of the series.

Structure

The RFC evolution process is = governed as follows:

  • The RFC = Working Group, whose job it is to develop proposed changes, and = establish community consensus of those changes.
  • The The RFC = Approval Board, whose job it is to provide final review of = proposals.

Each group is = described below.

The RFC Working Group = (RFCWG)

All RFCWG meetings are open = to any participant, subject to intellectual property policies which must = be consistent to those of the IETF [Note Well]. At body's initial = formation, all discussions are to take place on open mailing lists, and = anyone is welcome to comment / discuss. The RFCWG may decide by rough = consensus to use additional forms of communication (for example, Github = as specified in [RFC8874]) that are consistent with [RFC2418]. The group = will conform itself to an anti-harassment policy consistent with = [RFC7154,RFC7776].

IETF chair and = the Independent Submissions Editor shall each appoint and oversee a = co-chair of the RFCWG. 

The RFC Approval = Board (RFCAB)

The RFC Approval = Board consists of representatives from each RFC stream (at the time of = this writing, the IAB, the IETF, the IRTF, and the Indepenent Series), = as well as the RS[EA]. The sole function of this group is to review = draft proposals approvedby the RFCWG. The RFCAB may choose its chair as = it sees fit. The group is primarily expected to operate via email and = through any necessary tooling. A record of all proceedings (no matter = the form) will be kept.

Update Process

The following procedure is used = to update the RFC process:

  1. Someone writes = a draft proposal in the form of an Internet-Draft.
  2. If there is = sufficient interest in the proposal, RFCWG will adopt the proposal as a = working draft, much the same way a working group of the IETF = would.
  3. The RFCWG will then further develop the proposal. All = members of the RFCAB are expected to participate in discussion relating = to all proposals.
  4. At some point, if the chairs believe there may be = rough consensus exists for the proposal to advance, they will issue a = working group last call.
  5. After a = suitable period of time, the chairs will determine whether rough = consensus for the proposal exists. If comments have been received and = substantial changes have been made, it is expected that additional last = calls may be made.
  6. Once working group consensus is established, a = community call for comments will be issued. Should substantial comments = be received, the working group will again consider those comments and = make revisions as they see fit. At this same time, the RFCAB will = consider the proposal.
  7. Should = substantial changes be made, additional community calls for comment = should be issued, and again comments considered.
  8. Once all = comments have been been addressed, the working group chairs will = transmit the latest proposal to the RFCAB.

  9. Within a reasonable period of time, the RFCAB will then poll on = the proposal. Positions may be as follows:

    • "YES": the proposal should be approved
    • "CONCERN" : the proposal raises substantial concerns that must be = addressed.
    • "RECUSE" : the person holding the position has a = conflict of interest.

    Anyone = holding a "CONCERN" position MUST explain their concern to the community = in detail. The explanation may or may not be actionable.

    A CONCERN = may be made for two reasons:

    • The proposal represents a serious problem for the = group a particular member represents.
    • The member = believes that the proposal would cause serious harm to the overall = series, including harm to the long term health and viability of the = series.

    No CONCERN should ever come as a surprise to = the RFCWG.

  10. If a CONCERN exists, discussion will take = place within the RFCWG. Again, all RFCAB members MUST = participate.

  11. If all CONCERN positions are addressed, = then the proposal is approved. Again, if substantial changes have been = made, an additional call for community input should be made.

  12. If, after a suitable period of time, any CONCERN positions = remain, a formal vote of the RFCAB is taken. If a majority of RFCAB = members vote to approve, the proposal is approved. Otherwise, it is = returned to the RFCWG. In the case of a tie, the proposal is = approved.

  13. When a proposal is approved, a = notification is sent to the community, and it is published as an = RFC.

The roles of the LLC = Board and ED

LLC Board = members, staff, and the Executive Director, are invited to participate = as community members in the RFCWG to the extent permitted by any = relevant LLC policies.

Appeals

Appeals of RFCAB = decisions may only be made based on process failures, and not on the = substance of a proposal. These appeals SHALL be made to the ISOC BoT = within thirty days of the RFCAB decision. The ISOC BoT MAY decide only = whether a process failure occurred, and what if any corrective action = should take place.

Discussion

The intent of this policy is to = provide an open forum by which policies and procedures of the RFC series = are evolved. The general expectation is that all interested parties will = participate in the RFCWG, and that only under extreme circumstances = should the RFCAB members have to hold "CONCERN" positions. To avoid that = situation, WG members are encouraged to take RFCAB concerns seriously, = and RFCAB members are encouraged to make those concerns known early, and = to be responsive to the community. In particular, people are encouraged = to respect the value of each stream, and the long term health and = viability of the RFC series.

This process is intended to be one of = continuous consultation. In particular, RFCAB members should be = consulting with their constuent groups on an ongoing basis, so that when = the time comes to consider a proposal, there should be no surprises. = Appointing bodies are expected to establish whatever processes they deem = appropriate to facilitate this goal.





Part 2

DRAFT DRAFT = DRAFT

RS[EA] = Selection

The RS[EA] will be searched = for and vetted by a committee formed by the ED, taking into account = the role definition and any = detailed job description that we further develop. The search committee = may ask others to take part in the selection process in confidence. The = initial length of service shall be for one year, but then further = extensions will be for three to five years.

RS[EA] Ongoing Performance Evaluation

Periodically, the ED will send = out to the community a call for input on the performance of the RS[EA]. = The evaluation will be based on criteria specified in the role = definition. Was the RS[EA] an active participant in all/most meetings? = Did the RS[EA] provide useful advice to the RPC and to the WG? Did the = RS[EA] exercise good judgment in terms of any role he or she would have = had on the Approval Body? Was the RS[EA] effective in advising the = community on appropriate actions to take or not take?

The ED will then review the = feedback, consulting with stream manager representatives, and then = produce a recommendation to the LLC Board. The LLC will then make a = decision, taking into account that recommendation.

Whether the RS[EA] role is structured as = a contractual or employee relationship is left to the LLC and ED to = determine.

= --Apple-Mail=_54640A34-B0AD-4D07-A756-32D05E2FF681-- --Apple-Mail=_32697731-55E8-40B5-A1A6-64B31C3A9C5B 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBbOHgACgkQh7ZrRtnS ejMb3Qf/TMw8bDGjYzIVTUHeE3BSKSmrj1RJqReQTa3/l+1RrX2D8KF5FLmTfz0N 1a6brdlJXjiq8Ot/H+YGcQc3DBt4ytKr4mUX7ESNdntHa64Moem20HsanThTjkw2 0trzQwPiLidpLML1L9X9Gv8ANBATdJeVfyy6p2I01GeNK0EvBSM2DubeaMaenfPh 2KNO9lqSZ07u/wHIBE83g9hpfJDOOzNrZn5CBe1RMXKPJnWbudvmhgSnaBCnu1cI mrsdQkNXd4Rjld9ELmNWHDGDqKtY0eWJvBbsftMRcnYO6u0yNAOo99VGfthPYFrB dEaxyvUCdhvSGWlBDNAt2hUzQDILCQ== =2p0h -----END PGP SIGNATURE----- --Apple-Mail=_32697731-55E8-40B5-A1A6-64B31C3A9C5B-- From nobody Wed Mar 24 16:39: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 709243A11F7 for ; Wed, 24 Mar 2021 16:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MSCLYJJAO63h for ; Wed, 24 Mar 2021 16:39:43 -0700 (PDT) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400098.outbound.protection.outlook.com [40.107.140.98]) (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 1145F3A11F6 for ; Wed, 24 Mar 2021 16:39:42 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iX3CnTwDSPv2UTt8CiiD6t3AIqXvL+6EQnfS4tDXTuRh1BIQ+s5prjyCDamQ4C5bVjvS4i9qWapa7vJJLxfrhf19lsAZoOXYJHMKMMEdil8hTC2sHdU0tdQloMFVYZ9oH7Z0DTOQN7u9eRgDg+hR1nrfm6jXlhruK8ZFmZbQbsxha8d9iGzXRQVP5BI5T+bLRgNb50rfbMcEi4NkkyU7fN6reN16hp8yXERbYtQUfcHrX80lsBR92uSDbOeIZUpomZz2s/HC3BDUM/f+avCmbn2WvhUF/AYOeVjsanyG0zitCd4ClXLErGUtCr0zQT+9zUvcxLSDfaXw5TPNtbh5rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XgtNl/QcnBjAxAu9sgb0XWfxbEbV1L+srKJ6Xexqvxg=; b=Yp3P3Q1vyVN6/Ys5+G3DhL3t3AwN04fYo8DFyZZQGVUtSQuCT2T38sdZCAkYQiiOAYe/D0yrY49w6DtYvWraHk9gHgO1V/D1lzaFoiKMlEaKbTLGl5RaCt6sx2hj7jeukbVINg8DetNWKkTPACPFZT4b8GkvOnKyYraT9dfb+ZA8nyzk11CRCGTvtuuQrArQ3hfhC/T6lRL8YLNDtKnG11qhY3E2BlIo5MHgfB7V21bNrZ+NtNsgGcgEZZbRqLdU1+XQeSfkKTyprxxgqsRq/G0+IavB2NKzI0HLKdEXBKBFDd+pcBX4N8B5OqPnUykiYhKq/b2BPE6rdjLvHS4GsA== 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=XgtNl/QcnBjAxAu9sgb0XWfxbEbV1L+srKJ6Xexqvxg=; b=l/XG5cCqMQHdjg17lQTsySXul/wuWD0e8aCqqQ9W7PtBtY28Ip3aEmfOkSCjfv+hUqpcBILlDH6P9FvDCY5oNLFwdCLibGj2KWopS6qL9V2xQPOre0O2jkrsTy74RAPEIyMZJuOSFmQeQSJ7uIhfKNurGe1ceazryOsnmzwYNL0= Authentication-Results: brianrosen.net; dkim=none (message not signed) header.d=none;brianrosen.net; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYYPR01MB6569.jpnprd01.prod.outlook.com (2603:1096:400:c4::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3955.27; Wed, 24 Mar 2021 23:39:39 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2%4]) with mapi id 15.20.3977.024; Wed, 24 Mar 2021 23:39:39 +0000 To: Eliot Lear , rfced-future@iab.org Cc: Brian Rosen References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Thu, 25 Mar 2021 08:39:36 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 In-Reply-To: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [223.217.46.174] X-ClientProxiedBy: TYAPR01CA0172.jpnprd01.prod.outlook.com (2603:1096:404:ba::16) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.7] (223.217.46.174) by TYAPR01CA0172.jpnprd01.prod.outlook.com (2603:1096:404:ba::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3977.24 via Frontend Transport; Wed, 24 Mar 2021 23:39:39 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 4a516732-69a9-498a-9b89-08d8ef1e1752 X-MS-TrafficTypeDiagnostic: TYYPR01MB6569: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: pfwL5UGpf/CTBseYbqtTBP5qQVssWRZIKE8tPAn2ktO8w38TCG+xOg9AjmGBRsa89s/tyBRkFYdDD7797B4u3EyqojMSIjbepbVtB1o8/cb9RYMhtAQD6vOk+iUT8hbZcqo7d7aPBoQ3xEdo0FE40YVQ+1tkWuo/xF7hMO2rXv49K7Df5oy2dMY2SqOf0ArrUXWSEyAq/XhdryHD7E0Xkoqvgg99E9As5ZePEs4Ulus9N7R2b4Tm93fzfmLvUnnUMBgg708syQBouPgAWWFAyd6LeytMWd+ehBbUll1knPi/xu666p96SsFgah8lhytpn6no/xYmmdyIciw0mt9gks/ukGYbdaUBJXcpxvx0gMrt2fgBMDoVh4dXG3T2O36i1SqMVE20fOTpr9D7DTTSR9IymPxZzW9LOEbY3XrjSMnmzxx2Iq+RmGIibRpX9U0R1uW+nhkuLl/ykbmZjnujyRPglNohO1Q9VaFFdUJrhrcDA4JhoXGvuCgFh7dvwcuRbAJfcRnZ3cDYXc7502633Z6mAmenFiKMHceaDp3J/EvPH3j1IYFFzI9CXmVvFfmv41s5NKmJIk/EbzwacRBEr0J7ZZJydH7+X6m512LBH4eZi60s/GB6MD/SZeAcjyoOVqXJpXD7hyO9Oj9CbMHiKxLjdqAjoLXwQWuiW2hevsz6e6gZb7XYkwV7Nt1klFbJ22iwGyh/0vIIMQQnXjdRi8qfQv6/y/QNmwCFr6fJeDmmEEzD+K0hnIm/hlvFXZsJxdoVhrRMOGEvnphSG9aTQ1xBGH68UFwJUOXs2gvGHoYfz3pUsy1fVKy4bCNaFtDN X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(376002)(366004)(39840400004)(136003)(346002)(2906002)(478600001)(8676002)(8936002)(66946007)(31696002)(966005)(66476007)(6486002)(52116002)(86362001)(36916002)(66574015)(31686004)(83380400001)(16526019)(6666004)(4326008)(956004)(2616005)(5660300002)(38100700001)(30864003)(53546011)(16576012)(316002)(786003)(26005)(186003)(66556008)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bmhiMCtRZ2VHSk9sZlVxSjU5ZCtlMksvK1c3N0N3bklRTVZqSDd6Yzl6cU9R?= =?utf-8?B?Y3VIcUdqMTJQOEhjWGhxcWMrUUVLbGtJTnJrMTdqdG5PelhnRHc1ZHIwMTBm?= =?utf-8?B?R3pOQ05JbVRQKzdPTDJ2U0E0clN2SHlLVU9qSzZiNVRDalNlWjB5QTdjMjlP?= =?utf-8?B?bkFoaFVhNW5uamRxK3hYakYvYXhxT251NDNtL1hFMmdFUkZ0MlViVEx3dVdw?= =?utf-8?B?Y00zTVN0a0NGVlFtdUNjSkw2dm1zU0JMM2xwVGNJeXk5UTNGN2N3bTdSRHp5?= =?utf-8?B?b2EyZUFNT1dVWDdJRVRPcURGcjhvcTRTWUt2a3lXWGZtdjVBSlVBNkVEcGNE?= =?utf-8?B?TDBDNStpd0dVL3YwcXhoWHRwdlorREZCNFk2MXBCT01vNlkzME5yMi9TNXUz?= =?utf-8?B?MVVEb3NaZ0xuUExRSzhQaDNBOUwwYVJVTGN2Q0l2Q3U1ZlVFYWNPUDNIa2RB?= =?utf-8?B?eGVLdW55Z2hKVVdEaWRqR2ZMYldiV3BkMTVlWUU0SzN1Y3l2blUzTmJFREpx?= =?utf-8?B?bnBQQ3V5WTMzay9ObDdLYnZOUVNtVkJSQVpKRTVHMTRTQUx1Z09ueE9hT1dH?= =?utf-8?B?SkcvMzMxY1dLa012Nmt3RWpkdnZjVzNtcENFQTZNMm04UHVOWE9FQTJQVHA5?= =?utf-8?B?WEE2MW81ai9lVUE4ekErVXVTV0VOeU05b1NaNGtvWWt1bDhLbXE3eGRFVnhl?= =?utf-8?B?bGVJeGxEbVRNVVpodjNhb2JOSnAzTzMzMEFFbDQ3ODF6OGxXdjUyVnNISEha?= =?utf-8?B?bDJ0eGRjSW1ydGZ4elJ5aUlKQmFicmcvYnJkeEEwd2RtRVpBTktWd2o4NTZO?= =?utf-8?B?dHlOdDd5OE5ERnhWQm1rTWw3NFo2aWtOaWdVazlpdkRFbDc3RFE2MUtSb1pj?= =?utf-8?B?M28zMERQOWJ1bkhKcDEveE5SeXAydS8yWnFZVmI4NTBXWTc1ZWJNRlJPZ21N?= =?utf-8?B?OWwxeHN6cHBxR3RKYXlwWG1OTmVYTGxEMUhtbTJVOGoxUnFRbzAwUGQ0aUNw?= =?utf-8?B?bTJXZTlIdFp1d0RPeG1UbDRiOEtSc1NCYWpBd29UOW1MS3RGb3ZmamVUODNJ?= =?utf-8?B?d0hrRmVReFZiUU04eXRJSUIvRFdibWErZTR2QUNiVlNyVlV0VEJ1K0F0Q0Zm?= =?utf-8?B?bERPem00Zjdkck4zajJNZ3RFQ3hzZlJCQUVXcXVFRFhtZnZqZjd2SUNyUTBO?= =?utf-8?B?T0VjbVZaRUg5SWQxWkViVDR4R0w4VFZ6N0Y4WHgyYU40dUIybzRpbkt0T0dx?= =?utf-8?B?Z2RMSHNvMk43TkkveUJYUHVQYW9qMm94QjB4T3FNUnNIc00yQ2ZrZGZmRm12?= =?utf-8?B?Y2xLcGZtcjF1Wm1oUElsZEtRSXFqRDRZZ2xhSFZxeDBmNVFHNkpHOS9SN3Fr?= =?utf-8?B?Zld4VDQ0ckJHSHl4dldPL0ZXUU43aVg1ZURKT2J4SXV2bmxGdkNWNkdPTFhL?= =?utf-8?B?Z3hNZ2JReDYxQnljZ1draldhdFl6UUI0VUVOeXV3YTNXSGlMcTZXWVYrMVdH?= =?utf-8?B?QW9iaEhsNmxObzlYMDNSeUxXSWtsckIycVpBRmlOYUFaNGloeld1bTYrTjlM?= =?utf-8?B?NzdZSnl5TFdOOGYwdWQzanFGNUZ4Z3lNdG5RZ0JhM1JaMDZRaVo5R2FwSGJi?= =?utf-8?B?T05mdmlZb1cyTE5Gc1UzMnFEbk45cFA4U1ppcU4xcHlEY3JlRUFBdCtQb1Bo?= =?utf-8?B?WkpKaXE4cHFTZW1LbCtTV05hN1lkWXR5ZnlHQTJaR0wxU3RON3lVVDBiaUVJ?= =?utf-8?Q?KnL5s0il1ZZcRhEYaD4CqK0xWTb8Fvr2c06VPES?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 4a516732-69a9-498a-9b89-08d8ef1e1752 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Mar 2021 23:39:39.4283 (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: DIheHv1t/laF6eDfEfpzP9M0Rt9DGZp6ZOQGKZXfr7OBVGjgqDKzOaNtpgmC19fC9hskqb1CjiHnYJhOle011Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYYPR01MB6569 Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 24 Mar 2021 23:39:46 -0000 Hello Eliot, everyone, On 2021/03/24 22:02, Eliot Lear wrote: > Everyone, > > Thanks for your patience. As promised at our meeting, the chairs are putting forward a proposal to move forward. > > This proposal comes in two parts. The first part is the process for how drafts are developed and approved – or not. It is loosely based on what Joel presented at IETF 110, but also incorporates earlier agreed text about the RFCWG. In this proposal, the RS[EA] does get a say on the Approval Board. However, that person’s is one voice out of five. > > As a companion part of this proposal, and as discussed at IETF 110, the second part discusses the hiring and oversight of the RS[EA]. Many thanks for your proposals. I have read them, and agree with the general direction. > A few points: > > The first part in particular is intended as a compromise between very different points of view. We do not expect anyone to be perfectly happy with what is written, but we do ask everyone at this late stage to withhold objections unless they positively cannot live with what is written. > Assuming there is rough consensus for this base text, changes can be made again based on rough consensus. Surely some will be needed here and there. > The second part of the proposal is something on which we have spent less time. It provides a fair amount of freedom to the LLC to set timing and working method of the role. We expect this text to evolve a bit more, but again ask that it be accepted as base text. > > Our proposal is that people take a day or so to read through and consider both texts, and then ask questions or comment on list. When commenting settles down, we will open a consensus call. Because there was a specific request for the accountability text as part of all of this, the consensus call will be to take both parts as a whole as base text. > > Without further ado, please see the text below, which can also be found on GitHub: > > https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md > > And > > https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md > > Eliot & Brian > > — > Part 1 > > > DRAFT RFC Evolution Process > Scope > This procedure is applicable to the evolution processes relating to the management and evolution of the RFC series, including format, tooling, publication, dissemination, and overall management of the series. > > Structure > The RFC evolution process is governed as follows: > > The RFC Working Group, whose job it is to develop proposed changes, and establish community consensus of those changes. > The The RFC Approval Board, whose job it is to provide final review of proposals. Nit: Superfluous 'The'. I noticed at least one other place where there were repeated words. > Each group is described below. > > The RFC Working Group (RFCWG) > > All RFCWG meetings are open to any participant, subject to intellectual property policies which must be consistent to those of the IETF [Note Well]. At body's initial formation, all discussions are to take place on open mailing lists, and anyone is welcome to comment / discuss. The RFCWG may decide by rough consensus to use additional forms of communication (for example, Github as specified in [RFC8874]) that are consistent with [RFC2418]. The group will conform itself to an anti-harassment policy consistent with [RFC7154,RFC7776]. > > IETF chair and the Independent Submissions Editor shall each appoint and oversee a co-chair of the RFCWG. > > The RFC Approval Board (RFCAB) > > The RFC Approval Board consists of representatives from each RFC stream (at the time of this writing, the IAB, the IETF, the IRTF, and the Indepenent Series), as well as the RS[EA]. The sole function of this group is to review draft proposals approvedby the RFCWG. The RFCAB may choose its chair as it sees fit. The group is primarily expected to operate via email and through any necessary tooling. A record of all proceedings (no matter the form) will be kept. > > Update Process > The following procedure is used to update the RFC process: > > Someone writes a draft proposal in the form of an Internet-Draft. > If there is sufficient interest in the proposal, RFCWG will adopt the proposal as a working draft, much the same way a working group of the IETF would. > The RFCWG will then further develop the proposal. All members of the RFCAB are expected to participate in discussion relating to all proposals. > At some point, if the chairs believe there may be rough consensus exists for the proposal to advance, they will issue a working group last call. > After a suitable period of time, the chairs will determine whether rough consensus for the proposal exists. If comments have been received and substantial changes have been made, it is expected that additional last calls may be made. > Once working group consensus is established, a community call for comments will be issued. Should substantial comments be received, the working group will again consider those comments and make revisions as they see fit. At this same time, the RFCAB will consider the proposal. > Should substantial changes be made, additional community calls for comment should be issued, and again comments considered. > Once all comments have been been addressed, the working group chairs will transmit the latest proposal to the RFCAB. > Within a reasonable period of time, the RFCAB will then poll on the proposal. Positions may be as follows: > > "YES": the proposal should be approved > "CONCERN" : the proposal raises substantial concerns that must be addressed. > "RECUSE" : the person holding the position has a conflict of interest. > Anyone holding a "CONCERN" position MUST explain their concern to the community in detail. The explanation may or may not be actionable. > > A CONCERN may be made for two reasons: > > The proposal represents a serious problem for the group a particular member represents. > The member believes that the proposal would cause serious harm to the overall series, including harm to the long term health and viability of the series. > No CONCERN should ever come as a surprise to the RFCWG. > > If a CONCERN exists, discussion will take place within the RFCWG. Again, all RFCAB members MUST participate. > > If all CONCERN positions are addressed, then the proposal is approved. Again, if substantial changes have been made, an additional call for community input should be made. > > If, after a suitable period of time, any CONCERN positions remain, a formal vote of the RFCAB is taken. If a majority of RFCAB members vote to approve, the proposal is approved. Otherwise, it is returned to the RFCWG. In the case of a tie, the proposal is approved. > > When a proposal is approved, a notification is sent to the community, and it is published as an RFC. > > The roles of the LLC Board and ED > > LLC Board members, staff, and the Executive Director, are invited to participate as community members in the RFCWG to the extent permitted by any relevant LLC policies. > > Appeals > Appeals of RFCAB decisions may only be made based on process failures, and not on the substance of a proposal. These appeals SHALL be made to the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY decide only whether a process failure occurred, and what if any corrective action should take place. > > Discussion > The intent of this policy is to provide an open forum by which policies and procedures of the RFC series are evolved. The general expectation is that all interested parties will participate in the RFCWG, and that only under extreme circumstances should the RFCAB members have to hold "CONCERN" positions. To avoid that situation, WG members are encouraged to take RFCAB concerns seriously, and RFCAB members are encouraged to make those concerns known early, and to be responsive to the community. In particular, people are encouraged to respect the value of each stream, and the long term health and viability of the RFC series. > > This process is intended to be one of continuous consultation. In particular, RFCAB members should be consulting with their constuent groups on an ongoing basis, so that when the time comes to consider a proposal, there should be no surprises. Appointing bodies are expected to establish whatever processes they deem appropriate to facilitate this goal. The main points that I'd like to discuss further (after in general adopting the above proposal!) are: - "In the case of a tie, the proposal is approved.": That would essentially mean 2 for, 2 against, and 1 recuse. I think that's a very thin base for a change. - There are various pointers to IETF process and the relevant RFCs. In order to avoid future discussions and hairsplitting, I think it would be good to somewhere state that where there are accidental differences in wording, the intent is to align with IETF process. > Part 2 > > DRAFT DRAFT DRAFT > RS[EA] Selection > The RS[EA] will be searched for and vetted by a committee formed by the ED, taking into account the role definition and any detailed job description that we further develop. The search committee may ask others to take part in the selection process in confidence. The initial length of service shall be for one year, but then further extensions will be for three to five years. > > RS[EA] Ongoing Performance Evaluation > Periodically, the ED will send out to the community a call for input on the performance of the RS[EA]. The evaluation will be based on criteria specified in the role definition. Was the RS[EA] an active participant in all/most meetings? Did the RS[EA] provide useful advice to the RPC and to the WG? Did the RS[EA] exercise good judgment in terms of any role he or she would have had on the Approval Body? Was the RS[EA] effective in advising the community on appropriate actions to take or not take? > > The ED will then review the feedback, consulting with stream manager representatives, and then produce a recommendation to the LLC Board. The LLC will then make a decision, taking into account that recommendation. > > Whether the RS[EA] role is structured as a contractual or employee relationship is left to the LLC and ED to determine. This excludes all the day-to-day activity that past and current role holders have had. I think that's the direction this group has been moving towards, and I can live with it, but I think we need to work this out much more carefully, to avoid gaps or overlaps (with the potential of conflict) especially in areas such as style guide,... Regards, Martin. From nobody Thu Mar 25 08:00: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 557D03A24BD for ; Thu, 25 Mar 2021 08:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjVZ9KzlBHXl for ; Thu, 25 Mar 2021 08:00:10 -0700 (PDT) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFDB93A24D4 for ; Thu, 25 Mar 2021 08:00:10 -0700 (PDT) Received: by mail-oi1-x22e.google.com with SMTP id d12so2374714oiw.12 for ; Thu, 25 Mar 2021 08:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=eKd631RzxojjK3dCosimpNR7liTT5XduwH+/wwZnifI=; b=cU4Oo7Ekwee/kiiVIqfKzqHhrAGm/UUwLMcdG7ZKquwuHB09tH4BhszmrL/W4/oyIM 7kvH1yggftIiCu/LlngOsh6hWFejPryz5HZQs/2AmfwE8gErm2ESkr2YQLQg8c+B5PEV 3QvNSEG86FJ9EcYGgK70epIvh+xRYHfO7aC7DL+NuAaHym3jsiH6sLbSOVa23RVxbzHT ur8YP1R30Vc1Fg/FGYBa2p8tZm6iCD6kTw8MAfbHNULnCReyOcyxUmAqatcOhyPvPWKD 79hrypcXIOMqiX3fzueoI7Uddj/Faw4YmuEd7hnLb/sewgaJOfaX4DrhbUXex4YvExBu hYAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=eKd631RzxojjK3dCosimpNR7liTT5XduwH+/wwZnifI=; b=CIxiQILPVUKTy7+vPJqr69pbCZXjk6/1/LfHWGdA2h2Udvt6NLUBvi8kpOCbDyddGw YImNpz5LgRhVqwEqvdY5f+tSQLkDYXwMHB8v4xIhPoPszcy0cksNUAtj024IhMvVpIYC t96vNqsCNhWYvt5BjXBRfvBuz2ect1y8Fq1YpHbugDccdEvCnbCW9T1npjbU3FqX4Sxi 28olor5FqFmq3Ie20mVu8af1taoPHEB+6hwOTKwNrxvNmTx5qKg/ZJ/ml3bMCetkDJFy m5/rFU6L6vyL4z9HMVpQIY/BP2McxpeJVts9VMdG19eC8gBpDlVMpraZeD2rCgQhdPe8 b5xg== X-Gm-Message-State: AOAM5305PPm/Qxe9B5ltxiAitwVO2n2AcwE1GlRYKh6skbY+kufTiZE6 HsLRleO9+cBL2dVD85V+cG+ISYUxB5Bp8L+JvSZEQw== X-Google-Smtp-Source: ABdhPJzwfW/3ddsXDf7lid67bZ/yef2B27ZD1jAfTOf9VYBOOexgtku2nt1/LqVRypXcu/RF2/webiGOypqK8fv+ldE= X-Received: by 2002:a54:450c:: with SMTP id l12mr6549942oil.133.1616684409158; Thu, 25 Mar 2021 08:00:09 -0700 (PDT) MIME-Version: 1.0 References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> In-Reply-To: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> From: Wes Hardaker Date: Thu, 25 Mar 2021 07:59:33 -0700 Message-ID: To: Eliot Lear Cc: rfced-future@iab.org, Brian Rosen Content-Type: multipart/alternative; boundary="000000000000ec0f3605be5dabb3" Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Mar 2021 15:00:14 -0000 --000000000000ec0f3605be5dabb3 Content-Type: text/plain; charset="UTF-8" > > > The initial length of service shall be for one year, but then further > extensions will be for three to five years. > Where did this particular timing come from? -- Wes Hardaker USC/ISI --000000000000ec0f3605be5dabb3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=C2=A0The initial length of service shall b= e for one year, but then further extensions will be for three to five years= .


Where did this particular timin= g come from?
--
<= div dir=3D"ltr">Wes Hardaker
USC/ISI
--000000000000ec0f3605be5dabb3-- From nobody Thu Mar 25 08:46: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 A7B633A25E3 for ; Thu, 25 Mar 2021 08:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.847 X-Spam-Level: X-Spam-Status: No, score=-9.847 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.251, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ytHEoKt6cVD for ; Thu, 25 Mar 2021 08:46:00 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 522943A25E0 for ; Thu, 25 Mar 2021 08:46:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3303; q=dns/txt; s=iport; t=1616687160; x=1617896760; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=fvFeg7b0RmZy176C8l+uEV4NvEjgi1MdqASPaZibc/s=; b=I/qhWngq627rwhmNLwLa5gY6Z0oYFh71W95wYEgI9da57vOUFIsR1xiw INwrNCq44wQ+HyI6HEhvTJZIUjtf1mKbNjqP03g4LnFos7zqtVtyFT115 sXmAaYYlfPFKNK2RXmAb4QyA5My6n8SrVLbaTmN4SxDcAQA77ir5+PJPJ U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0APAAC9rlxglxbLJq1aDg4BAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IE8BwEBCwGBIoJUAScSMYxmYIggKId3jEiGI4F8BAcBAQEKAwEBNAQBAYRQA?= =?us-ascii?q?oF9JjQJDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQEBAQEBhkOGRAEBAQMBe?= =?us-ascii?q?QULCwQBEy5XBhOCcAGCZiGqT3WBNIVYhHcQgTkBgVKFKoZGQoILgTkMEIIrL?= =?us-ascii?q?j6IC4IrBIVNkXmMXpx4gxCDOYFDl2UDH5QXkDeGYK0wAYN+AgQGBQIWgVQ4g?= =?us-ascii?q?VszGggbFWUBgj4+EhkNjisNCRSNUUJAAy84AgYKAQEDCYdqAQE?= IronPort-HdrOrdr: A9a23:8rdcDKEzuw3eQjJapLqEaseALOonbusQ8zAX/mp6ICYlEfCwvc aogfgdyFvImC8cMUtNpfmsMLSNKEm8ybdb+o8UVI3JYCDHvy+SIJhm/c/exVTbexHW0uJGz6 9vf+xfBbTLYGRSqcb/7E2GH807wN+BmZrGuc7kw31gTR5nZshbhm8TNi+hHkJ7XwVAD5Yifa Dsg/ZvnSaqengcc62AaEUtYu6rnayoqLvWJToPBxsq82C1/FeVwY+/NQSE1REDVD4K5rEu/Q H+4mrEz5Tmle2nwRnB0GKW1bBqoZ/Kz9tOA9HksLlzFgnR X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,277,1610409600"; d="asc'?scan'208,217";a="34493113" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2021 15:45:56 +0000 Received: from [10.61.144.86] ([10.61.144.86]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 12PFjtBr011551 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Mar 2021 15:45:55 GMT From: Eliot Lear Message-Id: <8F1600B1-C282-4C00-9270-02FB5009B2B0@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_CCAF5BA6-C499-4111-AB1F-6BB4B5242460"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 25 Mar 2021 16:45:54 +0100 In-Reply-To: Cc: Eliot Lear , rfced-future@iab.org, Brian Rosen To: Wes Hardaker References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.86, [10.61.144.86] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Mar 2021 15:46:11 -0000 --Apple-Mail=_CCAF5BA6-C499-4111-AB1F-6BB4B5242460 Content-Type: multipart/alternative; boundary="Apple-Mail=_DE9BA0D2-8E93-4305-9795-86A63B6838C9" --Apple-Mail=_DE9BA0D2-8E93-4305-9795-86A63B6838C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Wes, > On 25 Mar 2021, at 15:59, Wes Hardaker wrote: >=20 >=20 > The initial length of service shall be for one year, but then further = extensions will be for three to five years. >=20 >=20 > Where did this particular timing come from? > -- The discussion indicated that this was a hard job to learn, and so it = might be that either side wants an out after that period. Eliot --Apple-Mail=_DE9BA0D2-8E93-4305-9795-86A63B6838C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Wes,

On 25 Mar 2021, at 15:59, Wes Hardaker <hardaker@isi.edu> = wrote:


 The initial length of = service shall be for one year, but then further extensions will be for = three to five years.


Where did this particular timing come = from?
--


The discussion indicated = that this was a hard job to learn, and so it might be that either side = wants an out after that period.

Eliot

= --Apple-Mail=_DE9BA0D2-8E93-4305-9795-86A63B6838C9-- --Apple-Mail=_CCAF5BA6-C499-4111-AB1F-6BB4B5242460 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBcsDIACgkQh7ZrRtnS ejNqlAgA25m8uvoqHaNYIlaswQSvHGkD1CbfCiNvd4lB8Qk3Qm2mxCOCI/CVJz3X uEUPBqbyjCl4tUn2espLmIBPaq1BxXCaL+oLVD3AHtiZPGf2fYRF6acD28WhNFR+ uX2r8dG+jfy5ZYKGu63UwJFtC+14wdFYNOZO8TdFm5a7CwaIhV+M5JXkgix5cPBt zCVlQHpmbyIhpHmFU4YKeZ2byvPg7KXs4hxi0CO9b/XSBUUytkKBOk47QSCpKbK2 8sdArGPezfga9rcDVu2PtL3IRfpQehDiJfhn0p6LsOzcY/vP0eCnNOyetVOfEmy9 LA4XieDJ8lgEbGsPVU3vr/zwz9LsHQ== =0xmx -----END PGP SIGNATURE----- --Apple-Mail=_CCAF5BA6-C499-4111-AB1F-6BB4B5242460-- From nobody Thu Mar 25 12:48: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 5FCEF3A2B40 for ; Thu, 25 Mar 2021 12:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YfIM48hZwvDg for ; Thu, 25 Mar 2021 12:48:37 -0700 (PDT) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A115A3A2B3E for ; Thu, 25 Mar 2021 12:48:16 -0700 (PDT) Received: by mail-pg1-x52c.google.com with SMTP id l76so2866172pga.6 for ; Thu, 25 Mar 2021 12:48:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ekepal3+Ot+FENnaT8EXatjDxY5weWb9aVVsMahcz+o=; b=SuhRsNHSV27EsXx9cGsG4kW4AgNIwO9uvBWiA55kIuh168cJrxY7wrZqr7mvPhzMiB 3WLr08mKktKxfJ6LRant/O3jxtLSpbsCGZt1Ruhv3JQDIUjGGV2I4rtZTrnCN94fqjrg MZEruqEZON+q52cQaYzqtFpOiTbZhJSN4jZ7h0uWy8q26a7GR18WNjwEcj4Pde7/TJ93 Zzz26kr1GUkIrOwRD2UZUA8kDm9tBEzpCY9ZYazcDrINy6I7LSdbUcqkWLifBxtjSqi/ eAX6a0Ln9FzQJY3PVhoV8UwAPga1jBtbANPNj5XDMk1wHhQprzsHbwLZS2IgUZtzvL+o W15Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ekepal3+Ot+FENnaT8EXatjDxY5weWb9aVVsMahcz+o=; b=Npt17sVt3dsh4K86KoS/L+0yHYPnjQwDmvtjBem8Kkl6SpG0oPx16/wA/HLFiHsgzz ljKo+TK9PvjPmvmdSURkVwSjBxxhrC9GCz3fI9nz9sqsOfHh3yQz7F6ODY7b70JuA8WF ZsZFZyBl7fPhq/FdcQksQSBUK1mip48BcuII4WubDQ2cVfF54xdnqxgPxE9KoWnQC9aR cyEWiedkDLHZNoYqUAuX0TWiJK2UcpAJeoklgfuRBAV8Y7HcrFueivwDGshtrrKSNOQN rNUgZN/+UsYGXsjBljxxQq/beAabJfaPLi9lG9XOHV3OzlX3dUsh3D3G0ndTWl3Av4G7 yccA== X-Gm-Message-State: AOAM531T1Cm67u2vglYTJBNr9yZ16Beu02EiunqiTDp3aH55zmSPN9fS MJ8o2FOPEipQ2OGFAT+Wd5s= X-Google-Smtp-Source: ABdhPJxoGYxK7O7eogEb448Ws6yjz19WEVnhjGXc2sJ8ip479t1nsQ4tQbtKw7dgSErnOBnSVXFTsA== X-Received: by 2002:a17:902:bd4b:b029:e6:a4a1:9d8b with SMTP id b11-20020a170902bd4bb02900e6a4a19d8bmr11957520plx.56.1616701695255; Thu, 25 Mar 2021 12:48:15 -0700 (PDT) Received: from [10.1.0.95] (223-165-19-195.liverton.net.nz. [223.165.19.195]) by smtp.gmail.com with ESMTPSA id fs9sm6232904pjb.40.2021.03.25.12.48.12 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Mar 2021 12:48:14 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org Cc: Brian Rosen References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> From: Brian E Carpenter Message-ID: <7638dfe0-59ce-168a-2878-cfd01aa65fe0@gmail.com> Date: Fri, 26 Mar 2021 08:48:11 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Mar 2021 19:48:43 -0000 Hi, I'm broadly OK with Part 1. I noted a few points as I read it, as below, but they are non-blocking. As for Part 2, it doesn't tackle the tricky bit of actually defining the RS[EA] job. Apart from that, it makes sense. > A CONCERN may be made for two reasons: >From experience with IESG DISCUSS, I think we need to briefly specify what reasons are not allowed. > No CONCERN should ever come as a surprise to the RFCWG. What does that mean? > 13. When a proposal is approved, a notification is sent to the community, and it is published as an RFC. We seem to need a new stream. > LLC Board members, staff, and the Executive Director, are invited to participate as community members And RFC editor staff I hope. Regards Brian Carpenter From nobody Thu Mar 25 13:10: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 993E13A2BC8 for ; Thu, 25 Mar 2021 13:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mQfD0c3qtKS for ; Thu, 25 Mar 2021 13:10:39 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55B3B3A2BC7 for ; Thu, 25 Mar 2021 13:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1952; q=dns/txt; s=iport; t=1616703039; x=1617912639; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Nozuar3gfj2ZHB22iA3JFeo9swnbvnzpM3jo/YsKlaU=; b=BOgDuYyGcSHQEPrkwSx6RLMy5A5npqML1u3zk3fat7XpsPj7g//oiwWa WEcGQXMJoK7Z71GGNvqw9+VF5+bvkMKVNe+AU8XhlWsiSkMHAp0Z/ufIl dlWuusUWtpWC8r7Hct75IqLLk52S6SDvZvsSfgggXW5Ja3WUDFZqOcVtY U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AMAACk7VxglxbLJq1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?TwHAQELAYN2AScSMYxmYIhIiiqQOBSBaAQHAQEBCgMBATQEAQGEUAKBfSY0C?= =?us-ascii?q?Q4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYZDhkQBAQEBAgF5BQsLG?= =?us-ascii?q?C4hNgYTgnABglUDDiGrJnWBNIVYgk4NghcQgTkBgVKLcEKCC4E5DBCCKy4+g?= =?us-ascii?q?h6BbQESAYNsgisEhU0RB54/nB1bgxCDOYFDkjSFMgMfg0iQUCyQDIZgnRuQF?= =?us-ascii?q?gGDfgIEBgUCFoFUOGtwMxoIGxVlAYI+PhIZDY44HY4TQAMvAjYCBgoBAQMJh?= =?us-ascii?q?20BAQ?= IronPort-HdrOrdr: A9a23:0F/3Tq0WdslMjSXlhKmAQwqjBDAkLtp033Aq2lEZdDV+eKWj5q OTtd4c0gL5jytUZWE4lbm7VJWobHvA+fdOgLU5EqylWGDd0leADIYn1of6xi2lJiuWzI5g/I NtabJ3BtG1LVUSt6vHyS25F9pl/9Wd6qCvgo7loEtFdg1hZ6F+4woRMG/yeXFefwVICYE0E5 CR/KN81l+dUE4KZce2DGRtZYb+juDM/aiWAyIuNloC4AmKgSjA0s+fLzGomjEDTjhI3bAutU /CngCR3NTEj9iLjjnBymTU85Na3OHE9+IGLsmNhs8JQw+c7TqVWA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,278,1610409600"; d="asc'?scan'208";a="34438324" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2021 20:10:34 +0000 Received: from [10.61.144.71] ([10.61.144.71]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 12PKAYcB029254 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Mar 2021 20:10:34 GMT From: Eliot Lear Message-Id: <17C66F4B-63E7-470F-9445-F6232178E512@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_EB0F2BF5-5D11-4300-8FE6-F0FBC72C17AC"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Thu, 25 Mar 2021 21:10:27 +0100 In-Reply-To: <7638dfe0-59ce-168a-2878-cfd01aa65fe0@gmail.com> Cc: Eliot Lear , rfced-future@iab.org, Brian Rosen To: Brian E Carpenter References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> <7638dfe0-59ce-168a-2878-cfd01aa65fe0@gmail.com> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.71, [10.61.144.71] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 25 Mar 2021 20:10:45 -0000 --Apple-Mail=_EB0F2BF5-5D11-4300-8FE6-F0FBC72C17AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Brian, I just want to answer your question below in this email: > On 25 Mar 2021, at 20:48, Brian E Carpenter = wrote: >=20 > Hi, >=20 > I'm broadly OK with Part 1. I noted a few points as I read it, as = below, but they are non-blocking. >=20 > As for Part 2, it doesn't tackle the tricky bit of actually defining = the RS[EA] job. Apart from that, it makes sense. >=20 >> A CONCERN may be made for two reasons: >=20 >> =46rom experience with IESG DISCUSS, I think we need to briefly = specify what reasons are not allowed. >=20 >> No CONCERN should ever come as a surprise to the RFCWG. >=20 > What does that mean? It means that by the time a poll occurs in the AB, if someone holds a = CONCERN, that person should have made those views known much earlier in = the process, prior to and during consensus call, so that nobody is = surprised. Remember, all AB members are expected to participate in the = RFCWG. Eliot --Apple-Mail=_EB0F2BF5-5D11-4300-8FE6-F0FBC72C17AC 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBc7jMACgkQh7ZrRtnS ejNFvAf/RWIdinOcyG5FIoHKy8CCrGdsZNPpkYmxsSkpRA8IQvr8m7wGsKteDTyq NQLWIHuD39gU2tZRq1ub8kJbH0TPXvg/5wFcbg1/7ZTJSvBFPynmZLv4oClwqubk iNOL8SNolnaufmoBiBOu8blxaQy0N7SnAhbZ7wdAvpOo2zbn+VzDvHEgKJSGxV43 MZY4W+VumoyjQJNkD1RDq9qj5JlLOjmwBeLZVsrx7hHSgj2zjkUE/E60Mez7zTy/ LSgf7jFwZz1nRfVc14Ngh1hPhYfPQraEopf5POCZpOoXo3yOGJDw44U1xj8AyEYV VidsrIagiayxC/YAPwXJRmd0rhCTnA== =VCUg -----END PGP SIGNATURE----- --Apple-Mail=_EB0F2BF5-5D11-4300-8FE6-F0FBC72C17AC-- From nobody Thu Mar 25 22:24: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 3486D3A1043 for ; Thu, 25 Mar 2021 22:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8Ri9OyH4mY1 for ; Thu, 25 Mar 2021 22:24:14 -0700 (PDT) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB31C3A1045 for ; Thu, 25 Mar 2021 22:24:13 -0700 (PDT) Received: by mail-wr1-x42f.google.com with SMTP id v4so4378227wrp.13 for ; Thu, 25 Mar 2021 22:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=5K1OX0vr5FPUU2FcNlX0Zp8ckvlyloEZ22XDnxvp/yU=; b=injhLfn9OZFCSc3I+GVAEE5eyANUd86UUY7owxWQcYGgvU06TfKqvjRcmNiE179gJ8 A1IBGNTVbzwCTqQa8KNeWFiTjOX269MXWZwcB2td8CDxH0/lj/QOUfFmL+S3nQSAV1JL TzFZgNI7p+irtAkLFE+R08nDILxIfrdzlyObsQPoI6OPSVCjUOUqvX0u4amEDwYrBP5h kgfhOdID6oGIOd3xnonq6iyFa7dvW3/u4RRGEeZfSIhZmilAAQ7phU+KgpOrZVuixapv fjaOEtUBYxyKYr0yDpQ4E0U92LB8HNYOxvwelzOUAtzqEDNUZ/1Z3vkRV6U56xFGVASg ehag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=5K1OX0vr5FPUU2FcNlX0Zp8ckvlyloEZ22XDnxvp/yU=; b=ZskQp/WSCuYnk5iqJ7/eF9HUylBnZZgVAu2zz8x6CPMbRa7XlHRAkk7Ic0NFcvmurP MlvcJQQ/lKqoiz9CWJU1uINDztS3GTRTIVkhL8B4i93FaLABUYviOc2IsCT4LqCDbSOg HFFZmQEIjpqAkmqVCa/t63QQ4OgieToJ5H+9LbdDSnSa4+El6iQnGpJj+9Ne5+fZuZN2 SLpjClhj7NRfUDV1D/9cYIHaHUdcz4soC6Mu5kxFWxLegmiGr0J3QKJIDc3HgToNTMon WcGS1E7Zb3NdRAvQ3jJY0z+wd+0obadvtzXjxfRrg09LhbDC/0xqPhjMr/w8ZKbmb2JO vYsQ== X-Gm-Message-State: AOAM530JkqzUGcB6wpMWVws3S0/LTGIHWXk52A/RrcQQshyrD1PhS9Yl ibMXppccBt+FcMbuaUOpzJs= X-Google-Smtp-Source: ABdhPJy9N0EXGACv+CAPOmPtE5oFttkHz8pIjNhM19aQjEw2yjYg96WLo1qTFGkMd1MxR1M4Dbv7SQ== X-Received: by 2002:adf:fbcc:: with SMTP id d12mr12244180wrs.151.1616736246536; Thu, 25 Mar 2021 22:24:06 -0700 (PDT) Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id n8sm9103491wrm.70.2021.03.25.22.24.05 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 25 Mar 2021 22:24:06 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EF95B204-41EB-43AE-9537-99DF44110264"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Thu, 25 Mar 2021 22:24:01 -0700 In-Reply-To: <17C66F4B-63E7-470F-9445-F6232178E512@cisco.com> Cc: Bob Hinden , Brian Carpenter , rfced-future@iab.org, Brian Rosen To: Eliot Lear References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> <7638dfe0-59ce-168a-2878-cfd01aa65fe0@gmail.com> <17C66F4B-63E7-470F-9445-F6232178E512@cisco.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 26 Mar 2021 05:24:18 -0000 --Apple-Mail=_EF95B204-41EB-43AE-9537-99DF44110264 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Eliot, > On Mar 25, 2021, at 1:10 PM, Eliot Lear = wrote: >=20 > Signed PGP part > Hi Brian, >=20 > I just want to answer your question below in this email: >=20 >> On 25 Mar 2021, at 20:48, Brian E Carpenter = wrote: >>=20 >> Hi, >>=20 >> I'm broadly OK with Part 1. I noted a few points as I read it, as = below, but they are non-blocking. >>=20 >> As for Part 2, it doesn't tackle the tricky bit of actually defining = the RS[EA] job. Apart from that, it makes sense. >>=20 >>> A CONCERN may be made for two reasons: >>=20 >>> =46rom experience with IESG DISCUSS, I think we need to briefly = specify what reasons are not allowed. >>=20 >>> No CONCERN should ever come as a surprise to the RFCWG. >>=20 >> What does that mean? >=20 > It means that by the time a poll occurs in the AB, if someone holds a = CONCERN, that person should have made those views known much earlier in = the process, prior to and during consensus call, so that nobody is = surprised. Remember, all AB members are expected to participate in the = RFCWG. There are always going to be surprises. Someone will think of something = they didn=E2=80=99t think of earlier. Bob --Apple-Mail=_EF95B204-41EB-43AE-9537-99DF44110264 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmBdb/EACgkQrut0EXfn u6hxmwf+Or8shMLrROtMqxPRxA5KlN/eQTj+tyv7t51GZsNO94HAxjbBSeceAUvR I/FAn9r8+XjVRFSgONoWv3IZl+iN93WGUCG/Y+6uNfO0CV8smL519LL5VlwdU+Ir Y0V22xMn08PmBJr6oGM+XYU7NX4nHNW/OnIkjizgTnO6wDBMyqAmkkq7Wx2uLJSN f0iGCVu5tCKNaDwqn5azuEOBh583j2KdXSBVBzuFp55wyhQXskWijzxSPb1Ov4IX oXahrXT1F+N5pLTDOwaXp7fgl4ciBhdHmB2DV5cXXzPEw5UGSFRSVYIrbw6bCVZw Td1JI0YZdQQWoPdsW5+/sIniUQ5Asw== =VaRK -----END PGP SIGNATURE----- --Apple-Mail=_EF95B204-41EB-43AE-9537-99DF44110264-- From nobody Fri Mar 26 06:11: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 E6B0F3A1E43 for ; Fri, 26 Mar 2021 06:11:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id twzSAqTndjBz for ; Fri, 26 Mar 2021 06:11:11 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D92D3A1E46 for ; Fri, 26 Mar 2021 06:11:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4F6MmZ6Fn2z6G8sK; Fri, 26 Mar 2021 06:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1616764270; bh=pCXbZs7Eso4UCxP+s/NHHWLNvgl3JmScH8RKS1oDoQA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=CsvwQH3iO8UCJ1NU6MUaB16bRKe1Def/BjX5IdW7rsiqXOftsasD8fHxSnA3YA8fc EW4lQiR0QqCyYpfyPOCgfCnW3lJYkNkC9XlIyE+jB/AFdFm3x8CGYsJ3qCwh8XHGXn +tbqX6igHgjg2L0tBUPkwYs36zFFjR40GrQhzf5Y= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.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 maila2.tigertech.net (Postfix) with ESMTPSA id 4F6MmY5kczz6G7yp; Fri, 26 Mar 2021 06:11:09 -0700 (PDT) To: Bob Hinden Cc: rfced-future@iab.org, Brian Rosen References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> <7638dfe0-59ce-168a-2878-cfd01aa65fe0@gmail.com> <17C66F4B-63E7-470F-9445-F6232178E512@cisco.com> From: "Joel M. Halpern" Message-ID: <7a5d0c16-1c31-6a31-0eda-06208e297794@joelhalpern.com> Date: Fri, 26 Mar 2021 09:11:08 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 26 Mar 2021 13:11:16 -0000 That (unexpected things happen, problems are sometimes notice late, ...) is why it (raising with the WG before raising a CONCERN) is a SHOULD and not a MUST. Yours, Joel On 3/26/2021 1:24 AM, Bob Hinden wrote: > Eliot, > >> On Mar 25, 2021, at 1:10 PM, Eliot Lear wrote: >> >> Signed PGP part >> Hi Brian, >> >> I just want to answer your question below in this email: >> >>> On 25 Mar 2021, at 20:48, Brian E Carpenter wrote: >>> >>> Hi, >>> >>> I'm broadly OK with Part 1. I noted a few points as I read it, as below, but they are non-blocking. >>> >>> As for Part 2, it doesn't tackle the tricky bit of actually defining the RS[EA] job. Apart from that, it makes sense. >>> >>>> A CONCERN may be made for two reasons: >>> >>>> From experience with IESG DISCUSS, I think we need to briefly specify what reasons are not allowed. >>> >>>> No CONCERN should ever come as a surprise to the RFCWG. >>> >>> What does that mean? >> >> It means that by the time a poll occurs in the AB, if someone holds a CONCERN, that person should have made those views known much earlier in the process, prior to and during consensus call, so that nobody is surprised. Remember, all AB members are expected to participate in the RFCWG. > > There are always going to be surprises. Someone will think of something they didn’t think of earlier. > > Bob > > > From nobody Fri Mar 26 08:52: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 4FBF53A21A6 for ; Fri, 26 Mar 2021 08:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7hU1Yk_FHbr for ; Fri, 26 Mar 2021 08:52:12 -0700 (PDT) Received: from mail-wr1-x430.google.com (mail-wr1-x430.google.com [IPv6:2a00:1450:4864:20::430]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C8313A21A3 for ; Fri, 26 Mar 2021 08:52:12 -0700 (PDT) Received: by mail-wr1-x430.google.com with SMTP id j7so6137405wrd.1 for ; Fri, 26 Mar 2021 08:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xEq72fhMIccnpKHHuqzn6ZURkIBJhws4BVGejpEXnrU=; b=HoPCimxDvXO6RtaqGPneQZoltyJqi94G+yo17ox4Ve70iJSt0LbmfW0pFp3G5HQK1Q EmXvNGT9AQYjfWu7WQC1qmn1LtXknPjNtO8Gke5/Vlu+NYZIcILeY1s7RpBpR9j10BS8 /5I82uO5odV20pXPaFA8ua8rHv0Ud1kzMRdxEAUgaYwsoe8zWk7AwiL9sSsryKVN6qa7 +5RU8kzhXiij7nlo3uQPN+wv++vorrOq7xa2ZwuAMiv1YtACnuFQ+bNpIKzJ3l8xVegX sLPU92Qzt6m87IQb06KOyFXm2LtbraZuo5VNI5z8mH9U5Eif3BoKutWTLzNG9Cf044N6 AL6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xEq72fhMIccnpKHHuqzn6ZURkIBJhws4BVGejpEXnrU=; b=kBij4qEIBOR4bE3OIB7tWVWzZ/KlzWnO4lnhcaXyHD9obfpyaIGhcYb64FvdZ6k3zt Cda/KGkjNQADwGboNxXXi5r5Jb2qyfqJ7OberuLG3ZualYEbGtQjuwsKdMh9uypHV8tw 4mlfERMmQzA0KlPvkGuyNSV4WHG1+jihjip2sbVbcEy7NlLK9Nqd6zxP7w1h3/szq7Yl MU9I6x/qe+STpZm3eZvxlxZzcJd4v4ZFqev9WCvfulKgEzplCdICsnNXMTlu410OBwoN qvfqJbO8NyjdE+2omk/s2RDQIOenFtEVwsr8YprWADvhmXikENw5PepnfH9lj6wVR2Iy SRTw== X-Gm-Message-State: AOAM531QdbI/BZ3bLfHhrZcdCKbENtjPS2NqkTxBsMqLJ1XO6436WBHt TuOkjkQS3M42DX8d2wpBSXY= X-Google-Smtp-Source: ABdhPJyXhiaspVMmIu/qZqzGNif+taLwm1C2BelRrZ51svWVW+7+xV1ku/qeotrWK+ib/UzYG8hoaQ== X-Received: by 2002:a5d:640b:: with SMTP id z11mr14881895wru.327.1616773929263; Fri, 26 Mar 2021 08:52:09 -0700 (PDT) Received: from [10.0.0.199] (c-24-5-53-184.hsd1.ca.comcast.net. [24.5.53.184]) by smtp.gmail.com with ESMTPSA id f2sm12536228wmp.20.2021.03.26.08.52.07 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 26 Mar 2021 08:52:08 -0700 (PDT) From: Bob Hinden Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AED7843A-3627-4886-A4C0-B4C177AF6EA3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) Date: Fri, 26 Mar 2021 08:52:05 -0700 In-Reply-To: <7a5d0c16-1c31-6a31-0eda-06208e297794@joelhalpern.com> Cc: Bob Hinden , rfced-future@iab.org, Brian Rosen To: "Joel M. Halpern" References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> <7638dfe0-59ce-168a-2878-cfd01aa65fe0@gmail.com> <17C66F4B-63E7-470F-9445-F6232178E512@cisco.com> <7a5d0c16-1c31-6a31-0eda-06208e297794@joelhalpern.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 26 Mar 2021 15:52:17 -0000 --Apple-Mail=_AED7843A-3627-4886-A4C0-B4C177AF6EA3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Joel, > On Mar 26, 2021, at 6:11 AM, Joel M. Halpern = wrote: >=20 > That (unexpected things happen, problems are sometimes notice late, = ...) is why it (raising with the WG before raising a CONCERN) is a = SHOULD and not a MUST. =E2=80=9Cshould ever=E2=80=9D seems pretty close to a MUST. I think it would be worthwhile to expand this text, or remove it. Bob > Yours, > Joel >=20 > On 3/26/2021 1:24 AM, Bob Hinden wrote: >> Eliot, >>> On Mar 25, 2021, at 1:10 PM, Eliot Lear = wrote: >>>=20 >>> Signed PGP part >>> Hi Brian, >>>=20 >>> I just want to answer your question below in this email: >>>=20 >>>> On 25 Mar 2021, at 20:48, Brian E Carpenter = wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> I'm broadly OK with Part 1. I noted a few points as I read it, as = below, but they are non-blocking. >>>>=20 >>>> As for Part 2, it doesn't tackle the tricky bit of actually = defining the RS[EA] job. Apart from that, it makes sense. >>>>=20 >>>>> A CONCERN may be made for two reasons: >>>>=20 >>>>> =46rom experience with IESG DISCUSS, I think we need to briefly = specify what reasons are not allowed. >>>>=20 >>>>> No CONCERN should ever come as a surprise to the RFCWG. >>>>=20 >>>> What does that mean? >>>=20 >>> It means that by the time a poll occurs in the AB, if someone holds = a CONCERN, that person should have made those views known much earlier = in the process, prior to and during consensus call, so that nobody is = surprised. Remember, all AB members are expected to participate in the = RFCWG. >> There are always going to be surprises. Someone will think of = something they didn=E2=80=99t think of earlier. >> Bob --Apple-Mail=_AED7843A-3627-4886-A4C0-B4C177AF6EA3 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----- iQEzBAEBCgAdFiEEm0rfRsOCoyamPexGrut0EXfnu6gFAmBeAyUACgkQrut0EXfn u6g+7gf9GLp2RIIe/39nUjgH0/RyefTaKfvvzBOh1q/hKLDuJ19RyhpuvZlp0xul tzxyZ479MBCH43+F2IlIXrT4TAFeSGQ1A+gtQh8IQpRiU3q1QXS9hOG60lThlGdb AwutycOtKu/XZeIP2os2I7D/NH6utv7nZfOtAzhPkUaao2c1eJrQ0JfwKDrI2eOd Y58e2H98RY2cXcmGMJ7dVZL3uEfVdoy+moZ5obbQ8ZCjKEjcmQgjbkDmFNiAQrpW 2+Ndm0l60vb8KWC2x3R6IDzIO8rD+AtxVwqcHR31ZsHGX/vy9AtSpqov9PpPJfx7 9/i1T2UXRT0aOFTYDkJmBLpWoatkBA== =9sX1 -----END PGP SIGNATURE----- --Apple-Mail=_AED7843A-3627-4886-A4C0-B4C177AF6EA3-- From nobody Sun Mar 28 18:56: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 4B5303A2C94 for ; Sun, 28 Mar 2021 18:56:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=OKwsGfkF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Gi7Hh6uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RzB2ojWs6xoj for ; Sun, 28 Mar 2021 18:55:59 -0700 (PDT) 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 790DC3A2C95 for ; Sun, 28 Mar 2021 18:55:59 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id DF4E715A2; Sun, 28 Mar 2021 21:55:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Sun, 28 Mar 2021 21:55:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=G ijVCzVnUpDxi7VmP+oFRFAyj7A3X3qqMTx9tHOgtwU=; b=OKwsGfkFeS0ULp9iJ +wk1zKY18xhytksHk/6Dm1vOg5YPt2OWXVL5caKxeW2+KZVQCa+/SenCcggEt9fd LxowX+kKMHly51mUOqjny2tWE2dWYmYLzZizWododyVxbbSa8taDf26Cmsdqn/H7 x/XF7WBFZ9MvVXkdjTq2w2jQjsXIU1rxtna18YhRlvt1PPp1yi+6D32EVVRvGi5o GKHBeMvpkIR/dTqC5csddyxedLsmqNyvaeBTSdIa6k6XWPTcRRDYMizPccqa/qtK 9ElYffO5UwFMhWXjm/7i2fCeZKTCj7ht1A0fxMnL7TNQg1Q7aIhlefAoACmvl7A9 MD3RQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=GijVCzVnUpDxi7VmP+oFRFAyj7A3X3qqMTx9tHOgt wU=; b=Gi7Hh6uk6XCw2fTjytpUD156pwmOqFKsjlz4DYC3iAuLLWIMzEV0hkthr Njzj7XsRXDw9q1knuAZpyT24wqllRdVqgPAgp43ds/lJcOFEEcg/rKzZ2+o8knMB B7YOEfoqQovELEjIYDnBzX8PM9JLhvtIfIlVtWr7XazovjNSeFVRIl3l7QgeK/s0 aSNdkpVRaFdQA0/PU4shmoPD+pV1HUHoxl5WXiSevAlGj8LDFJgRwYHtIX7UVks4 WOI1wgwrLH8v4WVu0VaPTHyX+x79N6sF8JwMEg4t61spLMpVTudP44cU3Kw6QlFC Xn+kUnBq4DdpXxMY9sgKDL5S+J7uQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudehjedghedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpefgudfhvdelffegudeiudehteetfefgiedtjeefjeefudetudffhedvieelvddv ffenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhirggsrdhorhhgpdhmnhhothdrnh gvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 8BE521080054; Sun, 28 Mar 2021 21:55:50 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> Date: Mon, 29 Mar 2021 12:55:48 +1100 Cc: rfced-future@iab.org, Brian Rosen Content-Transfer-Encoding: quoted-printable Message-Id: References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 29 Mar 2021 01:56:04 -0000 Hi Eliot, I agree that there's still much to discuss, and adjust, but I'll refrain = from nit-picking to say that this looks like it moves us forward. Cheers, > On 25 Mar 2021, at 12:02 am, Eliot Lear = wrote: >=20 > Everyone, >=20 > Thanks for your patience. As promised at our meeting, the chairs are = putting forward a proposal to move forward.=20 >=20 > This proposal comes in two parts. The first part is the process for = how drafts are developed and approved =E2=80=93 or not. It is loosely = based on what Joel presented at IETF 110, but also incorporates earlier = agreed text about the RFCWG. In this proposal, the RS[EA] does get a = say on the Approval Board. However, that person=E2=80=99s is one voice = out of five. >=20 > As a companion part of this proposal, and as discussed at IETF 110, = the second part discusses the hiring and oversight of the RS[EA]. >=20 > A few points: >=20 > =E2=80=A2 The first part in particular is intended as a = compromise between very different points of view. We do not expect = anyone to be perfectly happy with what is written, but we do ask = everyone at this late stage to withhold objections unless they = positively cannot live with what is written. > =E2=80=A2 Assuming there is rough consensus for this base text, = changes can be made again based on rough consensus. Surely some will be = needed here and there. > =E2=80=A2 The second part of the proposal is something on which = we have spent less time. It provides a fair amount of freedom to the = LLC to set timing and working method of the role. We expect this text = to evolve a bit more, but again ask that it be accepted as base text. >=20 > Our proposal is that people take a day or so to read through and = consider both texts, and then ask questions or comment on list. When = commenting settles down, we will open a consensus call. Because there = was a specific request for the accountability text as part of all of = this, the consensus call will be to take both parts as a whole as base = text. >=20 > Without further ado, please see the text below, which can also be = found on GitHub: >=20 > = https://github.com/intarchboard/program-rfced-future/blob/master/draft-evo= lution-process.md >=20 > And >=20 > = https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-= and-accountability.md >=20 > Eliot & Brian >=20 > =E2=80=94 > Part 1 >=20 >=20 > DRAFT RFC Evolution Process > Scope > This procedure is applicable to the evolution processes relating to = the management and evolution of the RFC series, including format, = tooling, publication, dissemination, and overall management of the = series. >=20 > Structure > The RFC evolution process is governed as follows: >=20 > =E2=80=A2 The RFC Working Group, whose job it is to develop = proposed changes, and establish community consensus of those changes. > =E2=80=A2 The The RFC Approval Board, whose job it is to provide = final review of proposals. > Each group is described below. >=20 > The RFC Working Group (RFCWG) >=20 > All RFCWG meetings are open to any participant, subject to = intellectual property policies which must be consistent to those of the = IETF [Note Well]. At body's initial formation, all discussions are to = take place on open mailing lists, and anyone is welcome to comment / = discuss. The RFCWG may decide by rough consensus to use additional forms = of communication (for example, Github as specified in [RFC8874]) that = are consistent with [RFC2418]. The group will conform itself to an = anti-harassment policy consistent with [RFC7154,RFC7776]. >=20 > IETF chair and the Independent Submissions Editor shall each appoint = and oversee a co-chair of the RFCWG.=20 >=20 > The RFC Approval Board (RFCAB) >=20 > The RFC Approval Board consists of representatives from each RFC = stream (at the time of this writing, the IAB, the IETF, the IRTF, and = the Indepenent Series), as well as the RS[EA]. The sole function of this = group is to review draft proposals approvedby the RFCWG. The RFCAB may = choose its chair as it sees fit. The group is primarily expected to = operate via email and through any necessary tooling. A record of all = proceedings (no matter the form) will be kept. >=20 > Update Process > The following procedure is used to update the RFC process: >=20 > =E2=80=A2 Someone writes a draft proposal in the form of an = Internet-Draft. > =E2=80=A2 If there is sufficient interest in the proposal, RFCWG = will adopt the proposal as a working draft, much the same way a working = group of the IETF would. > =E2=80=A2 The RFCWG will then further develop the proposal. All = members of the RFCAB are expected to participate in discussion relating = to all proposals. > =E2=80=A2 At some point, if the chairs believe there may be = rough consensus exists for the proposal to advance, they will issue a = working group last call. > =E2=80=A2 After a suitable period of time, the chairs will = determine whether rough consensus for the proposal exists. If comments = have been received and substantial changes have been made, it is = expected that additional last calls may be made. > =E2=80=A2 Once working group consensus is established, a = community call for comments will be issued. Should substantial comments = be received, the working group will again consider those comments and = make revisions as they see fit. At this same time, the RFCAB will = consider the proposal. > =E2=80=A2 Should substantial changes be made, additional = community calls for comment should be issued, and again comments = considered. > =E2=80=A2 Once all comments have been been addressed, the = working group chairs will transmit the latest proposal to the RFCAB. > =E2=80=A2 Within a reasonable period of time, the RFCAB will = then poll on the proposal. Positions may be as follows: >=20 > =E2=80=A2 "YES": the proposal should be approved > =E2=80=A2 "CONCERN" : the proposal raises substantial = concerns that must be addressed. > =E2=80=A2 "RECUSE" : the person holding the position has = a conflict of interest. > Anyone holding a "CONCERN" position MUST explain their concern to the = community in detail. The explanation may or may not be actionable. >=20 > A CONCERN may be made for two reasons: >=20 > =E2=80=A2 The proposal represents a serious problem for = the group a particular member represents. > =E2=80=A2 The member believes that the proposal would = cause serious harm to the overall series, including harm to the long = term health and viability of the series. > No CONCERN should ever come as a surprise to the RFCWG. >=20 > =E2=80=A2 If a CONCERN exists, discussion will take place within = the RFCWG. Again, all RFCAB members MUST participate. >=20 > =E2=80=A2 If all CONCERN positions are addressed, then the = proposal is approved. Again, if substantial changes have been made, an = additional call for community input should be made. >=20 > =E2=80=A2 If, after a suitable period of time, any CONCERN = positions remain, a formal vote of the RFCAB is taken. If a majority of = RFCAB members vote to approve, the proposal is approved. Otherwise, it = is returned to the RFCWG. In the case of a tie, the proposal is = approved. >=20 > =E2=80=A2 When a proposal is approved, a notification is sent to = the community, and it is published as an RFC. >=20 > The roles of the LLC Board and ED >=20 > LLC Board members, staff, and the Executive Director, are invited to = participate as community members in the RFCWG to the extent permitted by = any relevant LLC policies. >=20 > Appeals > Appeals of RFCAB decisions may only be made based on process failures, = and not on the substance of a proposal. These appeals SHALL be made to = the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY = decide only whether a process failure occurred, and what if any = corrective action should take place. >=20 > Discussion > The intent of this policy is to provide an open forum by which = policies and procedures of the RFC series are evolved. The general = expectation is that all interested parties will participate in the = RFCWG, and that only under extreme circumstances should the RFCAB = members have to hold "CONCERN" positions. To avoid that situation, WG = members are encouraged to take RFCAB concerns seriously, and RFCAB = members are encouraged to make those concerns known early, and to be = responsive to the community. In particular, people are encouraged to = respect the value of each stream, and the long term health and viability = of the RFC series. >=20 > This process is intended to be one of continuous consultation. In = particular, RFCAB members should be consulting with their constuent = groups on an ongoing basis, so that when the time comes to consider a = proposal, there should be no surprises. Appointing bodies are expected = to establish whatever processes they deem appropriate to facilitate this = goal. >=20 >=20 >=20 >=20 > Part 2 >=20 > DRAFT DRAFT DRAFT > RS[EA] Selection > The RS[EA] will be searched for and vetted by a committee formed by = the ED, taking into account the role definition and any detailed job = description that we further develop. The search committee may ask others = to take part in the selection process in confidence. The initial length = of service shall be for one year, but then further extensions will be = for three to five years. >=20 > RS[EA] Ongoing Performance Evaluation > Periodically, the ED will send out to the community a call for input = on the performance of the RS[EA]. The evaluation will be based on = criteria specified in the role definition. Was the RS[EA] an active = participant in all/most meetings? Did the RS[EA] provide useful advice = to the RPC and to the WG? Did the RS[EA] exercise good judgment in terms = of any role he or she would have had on the Approval Body? Was the = RS[EA] effective in advising the community on appropriate actions to = take or not take? >=20 > The ED will then review the feedback, consulting with stream manager = representatives, and then produce a recommendation to the LLC Board. The = LLC will then make a decision, taking into account that recommendation. >=20 > Whether the RS[EA] role is structured as a contractual or employee = relationship is left to the LLC and ED to determine. > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Sun Mar 28 19:42: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 707A63A2D99; Sun, 28 Mar 2021 19:42:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 KeqTIG6G5_Z5; Sun, 28 Mar 2021 19:42:11 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25A653A0D8C; Sun, 28 Mar 2021 19:42:10 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12T2eX3U020795; Mon, 29 Mar 2021 03:42:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=mAdo7SNAkETkAMfWvZ3cVWfYilflf2OEypEb3mNO8wA=; b=PLLfjZ4/hLkx+CQf7eyQbdWU92rjrmnLfU8tVeGOAfwtVai5r0QLcenfOTeYYHvsbrP8 yFk7k5JBrFi1Wr7gTpgb4ofc/AaFjUr8mcFaJPS7YZCtEJec0F1249kfrbgl9LCtgF03 mlIKcoJtECKbqDBaJI0tWJqCd3MYugvowEK6QB452Pa9kn39zLXgAQpT6pQb8ufBY7VJ bnhLusR1wY5oGWKLgktqsk/gr876Bft0A36VcjP7qkWVnhTqU1bOxpyvYUev/3ya0MnK uUQ64kFOYA53dKGCNJLaaW2wjQ4dEDHiaXNWZx/shw2xGQTXvQdqUDd0GScFOsj3IovF fw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 37k23e0h77-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 29 Mar 2021 03:42:08 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 12T2ZQN1031936; Sun, 28 Mar 2021 22:42:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 37j01ycfhr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 28 Mar 2021 22:42:07 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 28 Mar 2021 22:42:06 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.012; Sun, 28 Mar 2021 22:42:06 -0400 From: "Salz, Rich" To: Eliot Lear , "rfced-future@iab.org" CC: Brian Rosen Thread-Topic: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight Thread-Index: AQHXIK4ImKGAbh1jp0ePSzh7xXRsu6qaSNoA Date: Mon, 29 Mar 2021 02:42:06 +0000 Message-ID: <524752D1-927C-46F3-AD75-380F17656FC1@akamai.com> References: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> In-Reply-To: <52799FD5-F97E-413E-888C-C44656B8AB7E@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: multipart/alternative; boundary="_000_524752D1927C46F3AD75380F17656FC1akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-28_14:2021-03-26, 2021-03-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=964 bulkscore=0 malwarescore=0 mlxscore=0 phishscore=0 adultscore=0 spamscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103250000 definitions=main-2103290018 X-Proofpoint-GUID: Q0J3sXNGyFZzW_bXntrLnDL2d-hJ-BZJ X-Proofpoint-ORIG-GUID: Q0J3sXNGyFZzW_bXntrLnDL2d-hJ-BZJ X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-28_14:2021-03-26, 2021-03-28 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 priorityscore=1501 suspectscore=0 malwarescore=0 mlxlogscore=891 adultscore=0 lowpriorityscore=0 mlxscore=0 spamscore=0 bulkscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103250000 definitions=main-2103290019 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [Rfced-future] Chairs' Proposal to move forward on process and RS[EA] Oversight X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 29 Mar 2021 02:42:15 -0000 --_000_524752D1927C46F3AD75380F17656FC1akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBjYW4gbGl2ZSB3aXRoIHRoZSB0ZXh0LiAgTmljZSB3b3JrIQ0KDQoNCg== --_000_524752D1927C46F3AD75380F17656FC1akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <22887A7A5FD49545B18F40EE7422F668@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjM4ODM4Njc5NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTA1NTgxODc0MDt9DQpA bGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NjYyMTI1MDU5Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMjAwMTk1NjYwNDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDINCgl7bXNvLWxpc3QtaWQ6MTc5NDk4MzE1MjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6 LTYzMDAzOTY0O30NCkBsaXN0IGwyOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9zdHlsZT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi10b3A6MTEuMjVwdDtt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRlIj4NCjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+SSBjYW4gbGl2ZSB3aXRoIHRoZSB0ZXh0LiZuYnNwOyBOaWNlIHdvcmsh PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi10b3A6MTEuMjVwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndoaXRl Ij4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi10b3A6MTEuMjVwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bztiYWNrZ3JvdW5kOndo aXRlIj4NCjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_524752D1927C46F3AD75380F17656FC1akamaicom_-- From nobody Tue Mar 30 10:51: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 1C0513A1C91 for ; Tue, 30 Mar 2021 10:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.898 X-Spam-Level: X-Spam-Status: No, score=-11.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcpIQhY8ccrK for ; Tue, 30 Mar 2021 10:51:27 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E38683A1C8D for ; Tue, 30 Mar 2021 10:51:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27032; q=dns/txt; s=iport; t=1617126687; x=1618336287; h=from:mime-version:subject:message-id:date:to; bh=sGuPN507me+Ra+j9gR9LT1U+K/GP8k9LooDsyD8Ylmo=; b=EfJ+FmRrV9nmYBkmcbuqY67i0qs9+Zn9qeu4RXLicM1TjYXuZVrq5OO5 ph/tPXAdTZv51TnFoknrwSPkRNO4kh7ZEWB3soRRwxJiUeb36UJiPtxlM EeUPgRIkOZWT12tuJJHmoCnkfsBJt4gZmf2yLkHYuziwacANd8pA08pdy w=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ATAAD1Y2NglxbLJq1aHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?QYBAQsBgyBWAScSMQKEP4kEiEuPJ4s/FIFoBAcBAQEKAwEBLAgEAQGESwOBf?= =?us-ascii?q?yY1CA4CAwEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQGGNg2GaAZLBE8VA?= =?us-ascii?q?oEGglwBgwcPnQuOFXeBMoRWGIVRCgaBOQGBUoUqAYVSekKCC4ESJxyCCYEOg?= =?us-ascii?q?QSBXAICgRUJCQESAWCCVzWCKwSBSwkGZm4DBxMFEAkICgYUDAFFKzMGAgQJC?= =?us-ascii?q?wcnH5BpLIxehh+EfpBKgRSDEYM6gUSEXpMMAx+DSIpvhWOQOIZgkDWJUpJcU?= =?us-ascii?q?AGDfgIEBgUCFoFWAjRrXQwHMxoIGxVlAYI+PhIZDY4rCwIJg02KWz8DLwYMJ?= =?us-ascii?q?gIGAQkBAQMJiR8BAQ?= IronPort-HdrOrdr: A9a23:kmhX0KrmQmLduaXxQa18vX4aV5rCeYIsi2QD101hICF9WMqeis yogbAnxQb54Qx9ZFgMkc2NUZPgfVry7phwiLN6AZ6HUBP9sGWlaKFuhLGN/xTFGynzstFQzr 1hda8WMrHNJGN3h8r7/wW0euxIqLK62Zq1juTTxWoFd25XQpxnhj0YNi+rVml/RAxLHvMCZf mhz/sCgSa8cnIKacn+IX8JU4H41rj2vaOjRwIaDBg67wTLtxeU0frRFhiV2Qp2aUIs/Ysf X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,291,1610409600"; d="asc'?scan'208,217";a="34562321" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Mar 2021 17:51:22 +0000 Received: from [10.61.144.91] ([10.61.144.91]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 12UHpL7M007140 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 30 Mar 2021 17:51:22 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_6C02FD81-27A3-4924-A3B8-6E9913E6028B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Message-Id: Date: Tue, 30 Mar 2021 19:51:20 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.91, [10.61.144.91] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 30 Mar 2021 17:51:32 -0000 --Apple-Mail=_6C02FD81-27A3-4924-A3B8-6E9913E6028B Content-Type: multipart/alternative; boundary="Apple-Mail=_7563581B-8192-4C39-A309-13B6BBCB6E3D" --Apple-Mail=_7563581B-8192-4C39-A309-13B6BBCB6E3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The chairs appreciate comments received, and we now believe that it is = ok to start a consensus call on the chairs=E2=80=99 proposal on both = the draft evolution process and the RSE hire and accountability text, = taken as a whole. If you have already indicated your support for the = proposal, the chairs will note this. We would like to hear from all = interested participants. If you would like to indicate either support = or objection, please feel free to do so by Tuesday, April 13th. If there is rough consensus, this text will be included in the = editor=E2=80=99s draft. It can be further amended with rough consensus, = and the chairs expect there to be some of that. Again, we see this as = compromise text, and so we are hoping that this is a good enough = starting point for further modifications. As a reminder, we have an interim meeting scheduled for next Tuesday, = April 6th, 2021, at 20:00 GMT, when of course this proposal will be on = the agenda for people to discuss. More about that agenda in the next = day or two. The text can be found on GitHub in two parts at the following URLs: = https://github.com/intarchboard/program-rfced-future/blob/master/draft-evo= lution-process.md = = https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-= and-accountability.md = And it is below for your consideration as well. Brian and Eliot DRAFT RFC Evolution Process = Scope This procedure is applicable to the evolution processes relating to the = management and evolution of the RFC series, including format, tooling, = publication, dissemination, and overall management of the series. = Structure The RFC evolution process is governed as follows: The RFC Working Group, whose job it is to develop proposed changes, and = establish community consensus of those changes. The The RFC Approval Board, whose job it is to provide final review of = proposals. Each group is described below. = The RFC Working Group (RFCWG) All RFCWG meetings are open to any participant, subject to intellectual = property policies which must be consistent to those of the IETF [Note = Well]. At body's initial formation, all discussions are to take place on = open mailing lists, and anyone is welcome to comment / discuss. The = RFCWG may decide by rough consensus to use additional forms of = communication (for example, Github as specified in [RFC8874]) that are = consistent with [RFC2418]. The group will conform itself to an = anti-harassment policy consistent with [RFC7154,RFC7776]. IETF chair and the Independent Submissions Editor shall each appoint and = oversee a co-chair of the RFCWG. = The RFC Approval Board (RFCAB) The RFC Approval Board consists of representatives from each RFC stream = (at the time of this writing, the IAB, the IETF, the IRTF, and the = Indepenent Series), as well as the RS[EA]. The sole function of this = group is to review draft proposals approvedby the RFCWG. The RFCAB may = choose its chair as it sees fit. The group is primarily expected to = operate via email and through any necessary tooling. A record of all = proceedings (no matter the form) will be kept. = Update Process The following procedure is used to update the RFC process: Someone writes a draft proposal in the form of an Internet-Draft. If there is sufficient interest in the proposal, RFCWG will adopt the = proposal as a working draft, much the same way a working group of the = IETF would. The RFCWG will then further develop the proposal. All members of the = RFCAB are expected to participate in discussion relating to all = proposals. At some point, if the chairs believe there may be rough consensus exists = for the proposal to advance, they will issue a working group last call. After a suitable period of time, the chairs will determine whether rough = consensus for the proposal exists. If comments have been received and = substantial changes have been made, it is expected that additional last = calls may be made. Once working group consensus is established, a community call for = comments will be issued. Should substantial comments be received, the = working group will again consider those comments and make revisions as = they see fit. At this same time, the RFCAB will consider the proposal. Should substantial changes be made, additional community calls for = comment should be issued, and again comments considered. Once all comments have been been addressed, the working group chairs = will transmit the latest proposal to the RFCAB. Within a reasonable period of time, the RFCAB will then poll on the = proposal. Positions may be as follows: "YES": the proposal should be approved "CONCERN" : the proposal raises substantial concerns that must be = addressed. "RECUSE" : the person holding the position has a conflict of interest. Anyone holding a "CONCERN" position MUST explain their concern to the = community in detail. The explanation may or may not be actionable. A CONCERN may be made for two reasons: The proposal represents a serious problem for the group a particular = member represents. The member believes that the proposal would cause serious harm to the = overall series, including harm to the long term health and viability of = the series. No CONCERN should ever come as a surprise to the RFCWG. If a CONCERN exists, discussion will take place within the RFCWG. Again, = all RFCAB members MUST participate. If all CONCERN positions are addressed, then the proposal is approved. = Again, if substantial changes have been made, an additional call for = community input should be made. If, after a suitable period of time, any CONCERN positions remain, a = formal vote of the RFCAB is taken. If a majority of RFCAB members vote = to approve, the proposal is approved. Otherwise, it is returned to the = RFCWG. In the case of a tie, the proposal is approved. When a proposal is approved, a notification is sent to the community, = and it is published as an RFC. = The roles of the LLC Board and ED LLC Board members, staff, and the Executive Director, are invited to = participate as community members in the RFCWG to the extent permitted by = any relevant LLC policies. = Appeals Appeals of RFCAB decisions may only be made based on process failures, = and not on the substance of a proposal. These appeals SHALL be made to = the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY = decide only whether a process failure occurred, and what if any = corrective action should take place. = Discussion The intent of this policy is to provide an open forum by which policies = and procedures of the RFC series are evolved. The general expectation is = that all interested parties will participate in the RFCWG, and that only = under extreme circumstances should the RFCAB members have to hold = "CONCERN" positions. To avoid that situation, WG members are encouraged = to take RFCAB concerns seriously, and RFCAB members are encouraged to = make those concerns known early, and to be responsive to the community. = In particular, people are encouraged to respect the value of each = stream, and the long term health and viability of the RFC series. This process is intended to be one of continuous consultation. In = particular, RFCAB members should be consulting with their constuent = groups on an ongoing basis, so that when the time comes to consider a = proposal, there should be no surprises. Appointing bodies are expected = to establish whatever processes they deem appropriate to facilitate this = goal. DRAFT DRAFT DRAFT = RS[EA] Selection The RS[EA] will be searched for and vetted by a committee formed by the = ED, taking into account the role definition = and any detailed job description that we further develop. = The search committee may ask others to take part in the selection = process in confidence. The initial length of service shall be for one = year, but then further extensions will be for three to five years. = RS[EA] Ongoing Performance Evaluation Periodically, the ED will send out to the community a call for input on = the performance of the RS[EA]. The evaluation will be based on criteria = specified in the role definition. Was the RS[EA] an active participant = in all/most meetings? Did the RS[EA] provide useful advice to the RPC = and to the WG? Did the RS[EA] exercise good judgment in terms of any = role he or she would have had on the Approval Body? Was the RS[EA] = effective in advising the community on appropriate actions to take or = not take? The ED will then review the feedback, consulting with stream manager = representatives, and then produce a recommendation to the LLC Board. The = LLC will then make a decision, taking into account that recommendation. Whether the RS[EA] role is structured as a contractual or employee = relationship is left to the LLC and ED to determine. --Apple-Mail=_7563581B-8192-4C39-A309-13B6BBCB6E3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
The chairs appreciate comments received, and we now believe = that it is ok to start a  consensus call on the chairs=E2=80=99 = proposal on both the draft evolution process and the RSE hire and = accountability text, taken as a whole.  If you have already = indicated your support for the proposal, the chairs will note this. =  We would like to hear from all interested = participants.  If you would like to indicate either support or = objection, please feel free to do so by Tuesday, April 13th.

If there is rough = consensus, this text will be included in the editor=E2=80=99s draft. =  It can be further amended with rough consensus, and the chairs = expect there to be some of that.  Again, we see this as compromise = text, and so we are hoping that this is a good enough starting point for = further modifications.

As a reminder, we have an interim meeting scheduled for next = Tuesday, April 6th, 2021, at 20:00 GMT, when of course this proposal = will be on the agenda for people to discuss.  More about that = agenda in the next day or two.

The text can be found on GitHub in two = parts at the following URLs:

https://github.com/intarchboard/program-rfced-future/blob/maste= r/draft-evolution-process.md
https://github.com/intarchboard/program-rfced-future/blob/maste= r/rse-hire-and-accountability.md

And it is below for your consideration = as well.

Brian = and Eliot


DRAFT RFC Evolution = Process

Scope

This procedure is applicable to the evolution processes = relating to the management and evolution of the RFC series, including = format, tooling, publication, dissemination, and overall management of = the series.

Structure

The RFC evolution process is governed as follows:

  • The RFC Working Group, whose job it is to = develop proposed changes, and establish community consensus of those = changes.
  • The The RFC Approval Board, whose job it is = to provide final review of proposals.

Each group = is described below.

The RFC Working Group (RFCWG)

All RFCWG = meetings are open to any participant, subject to intellectual property = policies which must be consistent to those of the IETF [Note Well]. At = body's initial formation, all discussions are to take place on open = mailing lists, and anyone is welcome to comment / discuss. The RFCWG may = decide by rough consensus to use additional forms of communication (for = example, Github as specified in [RFC8874]) that are consistent with = [RFC2418]. The group will conform itself to an anti-harassment policy = consistent with [RFC7154,RFC7776].

IETF chair and the = Independent Submissions Editor shall each appoint and oversee a co-chair = of the RFCWG.

The RFC Approval Board (RFCAB)

The RFC = Approval Board consists of representatives from each RFC stream (at the = time of this writing, the IAB, the IETF, the IRTF, and the Indepenent = Series), as well as the RS[EA]. The sole function of this group is to = review draft proposals approvedby the RFCWG. The RFCAB may choose its = chair as it sees fit. The group is primarily expected to operate via = email and through any necessary tooling. A record of all proceedings (no = matter the form) will be kept.

Update = Process

The following procedure is used to update the = RFC process:

  1. Someone = writes a draft proposal in the form of an Internet-Draft.

  2. If there is sufficient interest in the = proposal, RFCWG will adopt the proposal as a working draft, much the = same way a working group of the IETF would.

  3. The RFCWG will then further develop the proposal. All members = of the RFCAB are expected to participate in discussion relating to all = proposals.

  4. At some point, if the = chairs believe there may be rough consensus exists for the proposal to = advance, they will issue a working group last call.

  5. After a suitable period of time, the chairs = will determine whether rough consensus for the proposal exists.  If = comments have been received and substantial changes have been made, it = is expected that additional last calls may be made.

  6. Once working group consensus is established, a = community call for comments will be issued. Should substantial comments = be received, the working group will again consider those comments and = make revisions as they see fit. At this same time, the RFCAB will = consider the proposal.

  7. Should = substantial changes be made, additional community calls for comment = should be issued, and again comments considered.

  8. Once all comments have been been addressed, the working = group chairs will transmit the latest proposal to the RFCAB.

  9. Within a reasonable period of time, the RFCAB = will then poll on the proposal. Positions may be as follows:

    • "YES": the proposal should be approved
    • "CONCERN" : the proposal raises substantial concerns that = must be addressed.
    • "RECUSE" : the person holding the = position has a conflict of interest.

    Anyone = holding a "CONCERN" position MUST explain their concern to the community = in detail. The explanation may or may not be actionable.

    A CONCERN may be made for two reasons:

    • The proposal represents a serious problem for the group a = particular member represents.
    • The member believes = that the proposal would cause serious harm to the overall series, = including harm to the long term health and viability of the = series.

    No CONCERN should ever come as a surprise = to the RFCWG.

  10. If a CONCERN exists, = discussion will take place within the RFCWG. Again, all RFCAB members = MUST participate.

  11. If all CONCERN = positions are addressed, then the proposal is approved. Again, if = substantial changes have been made, an additional call for community = input should be made.

  12. If, after a = suitable period of time, any CONCERN positions remain, a formal vote of = the RFCAB is taken. If a majority of RFCAB members vote to approve, the = proposal is approved. Otherwise, it is returned to the RFCWG. In the = case of a tie, the proposal is approved.

  13. When a proposal is approved, a notification is sent to the = community, and it is published as an RFC.

The roles of the LLC Board and ED

LLC Board = members, staff, and the Executive Director, are invited to participate = as community members in the RFCWG to the extent permitted by any = relevant LLC policies.

Appeals

Appeals of RFCAB decisions may only be made based on process = failures, and not on the substance of a proposal. These appeals SHALL be = made to the ISOC BoT within thirty days of the RFCAB decision. The ISOC = BoT MAY decide only whether a process failure occurred, and what if any = corrective action should take place.

Discussion

The intent of this policy is to = provide an open forum by which policies and procedures of the RFC series = are evolved. The general expectation is that all interested parties will = participate in the RFCWG, and that only under extreme circumstances = should the RFCAB members have to hold "CONCERN" positions. To avoid that = situation, WG members are encouraged to take RFCAB concerns seriously, = and RFCAB members are encouraged to make those concerns known early, and = to be responsive to the community. In particular, people are encouraged = to respect the value of each stream, and the long term health and = viability of the RFC series.

This process is intended = to be one of continuous consultation. In particular, RFCAB members = should be consulting with their constuent groups on an ongoing basis, so = that when the time comes to consider a proposal, there should be no = surprises. Appointing bodies are expected to establish whatever = processes they deem appropriate to facilitate this goal.

DRAFT DRAFT DRAFT

RS[EA] = Selection

The RS[EA] will be searched for and vetted = by a committee formed by the ED, taking into account the role definition and any detailed = job description that we further develop. The search committee may ask = others to take part in the selection process in confidence. The initial = length of service shall be for one year, but then further extensions = will be for three to five years.

RS[EA] Ongoing Performance Evaluation

Periodically, the ED will send out to the community a call = for input on the performance of the RS[EA]. The evaluation will be based = on criteria specified in the role definition. Was the RS[EA] an active = participant in all/most meetings? Did the RS[EA] provide useful advice = to the RPC and to the WG? Did the RS[EA] exercise good judgment in terms = of any role he or she would have had on the Approval Body? Was the = RS[EA] effective in advising the community on appropriate actions to = take or not take?

The ED will then review the feedback, = consulting with stream manager representatives, and then produce a = recommendation to the LLC Board. The LLC will then make a decision, = taking into account that recommendation.

Whether the = RS[EA] role is structured as a contractual or employee relationship is = left to the LLC and ED to determine.

= --Apple-Mail=_7563581B-8192-4C39-A309-13B6BBCB6E3D-- --Apple-Mail=_6C02FD81-27A3-4924-A3B8-6E9913E6028B 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBjZRgACgkQh7ZrRtnS ejNgfwgAmiMNFj06FXk48UTXjjpG6UowtNOAQ046AaCJlxb+04j/iWlm1BMMeObO D5vHM2i0F6DYUDVk/z376z0GLCB9AVCZknkATn3HGtjGuQ0Mwg+HZNyHVuqyBkl4 eX+7Yue5280c8S8qpTNZWBIHPbZIDQ7M7JA7OdNOOphxi/LOSoYapogYp4x4X+ed iSpxK7Nqq0Dm9qCT77kcorqK+0zroGQg5uUgWV9QU5keesGFDpt9Iwr07y1X5pVL 1CH5+NyE0iakC97RqbNU+jc8Zz3JitFnANVSOx0DmV+HliUM7xsuwZu9VJFRSpq3 CiDwt08MwFTeaqllfy5DSSmZuvXZjA== =1/vY -----END PGP SIGNATURE----- --Apple-Mail=_6C02FD81-27A3-4924-A3B8-6E9913E6028B-- From nobody Tue Mar 30 13:46: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 0E2633A0BF8 for ; Tue, 30 Mar 2021 13:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtoy1tq3Bgb5 for ; Tue, 30 Mar 2021 13:46:27 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B523A0BF3 for ; Tue, 30 Mar 2021 13:46:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4F91h275KKz1nsPl; Tue, 30 Mar 2021 13:46:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1617137186; bh=KX/SFAm2Cec4+dXY9Tw2u5bpVZxHgLI28DEETP5HECc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=h85PeYun5i4/nwZ2hj5h+6KC8XQd4IDAh4ejxqsDUnIeValCya854vrTYYufloXQ5 83hg194eVwzPRScBDloXBKHpydEktRz3omLURoOaUthU+lwNqpm6sP4abKaj2NsYx/ r8eHDs747RQniQUaXr8Emu73MBAUdNnUO/lGMaqo= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.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 4F91h16hsJz1nsPg; Tue, 30 Mar 2021 13:46:24 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org References: From: "Joel M. Halpern" Message-ID: <7ba05dfd-72bd-4c95-9649-82334607f504@joelhalpern.com> Date: Tue, 30 Mar 2021 16:46:23 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 30 Mar 2021 20:46:33 -0000 I support using those two pieces of text as the WG starting point for building a document and process we can get (rough) consensus on. Yours, Joel On 3/30/2021 1:51 PM, Eliot Lear wrote: > The chairs appreciate comments received, and we now believe that it is > ok to start a  consensus call on the chairs’ proposal on both the draft > evolution process and the RSE hire and accountability text, taken as a > whole.  If you have already indicated your support for the proposal, the > chairs will note this. *We would like to hear from all interested > participants*.  If you would like to indicate either support or > objection, please feel free to do so by Tuesday, April 13th. > > If there is rough consensus, this text will be included in the editor’s > draft.  It can be further amended with rough consensus, and the chairs > expect there to be some of that.  Again, we see this as compromise text, > and so we are hoping that this is a good enough starting point for > further modifications. > > As a reminder, we have an interim meeting scheduled for next Tuesday, > April 6th, 2021, at 20:00 GMT, when of course this proposal will be on > the agenda for people to discuss.  More about that agenda in the next > day or two. > > The text can be found on GitHub in two parts at the following URLs: > > https://github.com/intarchboard/program-rfced-future/blob/master/draft-evolution-process.md > > https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-and-accountability.md > > > And it is below for your consideration as well. > > Brian and Eliot > > > DRAFT RFC Evolution Process > > > > > > Scope > > This procedure is applicable to the evolution processes relating to the > management and evolution of the RFC series, including format, tooling, > publication, dissemination, and overall management of the series. > > > > > > Structure > > The RFC evolution process is governed as follows: > > * The RFC Working Group, whose job it is to develop proposed changes, > and establish community consensus of those changes. > * The The RFC Approval Board, whose job it is to provide final review > of proposals. > > Each group is described below. > > > > > > The RFC Working Group (RFCWG) > > All RFCWG meetings are open to any participant, subject to intellectual > property policies which must be consistent to those of the IETF [Note > Well]. At body's initial formation, all discussions are to take place on > open mailing lists, and anyone is welcome to comment / discuss. The > RFCWG may decide by rough consensus to use additional forms of > communication (for example, Github as specified in [RFC8874]) that are > consistent with [RFC2418]. The group will conform itself to an > anti-harassment policy consistent with [RFC7154,RFC7776]. > > IETF chair and the Independent Submissions Editor shall each appoint and > oversee a co-chair of the RFCWG. > > > > > > The RFC Approval Board (RFCAB) > > The RFC Approval Board consists of representatives from each RFC stream > (at the time of this writing, the IAB, the IETF, the IRTF, and the > Indepenent Series), as well as the RS[EA]. The sole function of this > group is to review draft proposals approvedby the RFCWG. The RFCAB may > choose its chair as it sees fit. The group is primarily expected to > operate via email and through any necessary tooling. A record of all > proceedings (no matter the form) will be kept. > > > > > > Update Process > > The following procedure is used to update the RFC process: > > 1. > > Someone writes a draft proposal in the form of an Internet-Draft. > > 2. > > If there is sufficient interest in the proposal, RFCWG will adopt > the proposal as a working draft, much the same way a working group > of the IETF would. > > 3. > > The RFCWG will then further develop the proposal. All members of the > RFCAB are expected to participate in discussion relating to all > proposals. > > 4. > > At some point, if the chairs believe there may be rough consensus > exists for the proposal to advance, they will issue a working group > last call. > > 5. > > After a suitable period of time, the chairs will determine whether > rough consensus for the proposal exists.  If comments have been > received and substantial changes have been made, it is expected that > additional last calls may be made. > > 6. > > Once working group consensus is established, a community call for > comments will be issued. Should substantial comments be received, > the working group will again consider those comments and make > revisions as they see fit. At this same time, the RFCAB will > consider the proposal. > > 7. > > Should substantial changes be made, additional community calls for > comment should be issued, and again comments considered. > > 8. > > Once all comments have been been addressed, the working group chairs > will transmit the latest proposal to the RFCAB. > > 9. > > Within a reasonable period of time, the RFCAB will then poll on the > proposal. Positions may be as follows: > > * "YES": the proposal should be approved > * "CONCERN" : the proposal raises substantial concerns that must > be addressed. > * "RECUSE" : the person holding the position has a conflict of > interest. > > Anyone holding a "CONCERN" position MUST explain their concern to > the community in detail. The explanation may or may not be actionable. > > A CONCERN may be made for two reasons: > > * The proposal represents a serious problem for the group a > particular member represents. > * The member believes that the proposal would cause serious harm > to the overall series, including harm to the long term health > and viability of the series. > > No CONCERN should ever come as a surprise to the RFCWG. > > 10. > > If a CONCERN exists, discussion will take place within the RFCWG. > Again, all RFCAB members MUST participate. > > 11. > > If all CONCERN positions are addressed, then the proposal is > approved. Again, if substantial changes have been made, an > additional call for community input should be made. > > 12. > > If, after a suitable period of time, any CONCERN positions remain, a > formal vote of the RFCAB is taken. If a majority of RFCAB members > vote to approve, the proposal is approved. Otherwise, it is returned > to the RFCWG. In the case of a tie, the proposal is approved. > > 13. > > When a proposal is approved, a notification is sent to the > community, and it is published as an RFC. > > > > > > The roles of the LLC Board and ED > > LLC Board members, staff, and the Executive Director, are invited to > participate as community members in the RFCWG to the extent permitted by > any relevant LLC policies. > > > > > > Appeals > > Appeals of RFCAB decisions may only be made based on process failures, > and not on the substance of a proposal. These appeals SHALL be made to > the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY > decide only whether a process failure occurred, and what if any > corrective action should take place. > > > > > > Discussion > > The intent of this policy is to provide an open forum by which policies > and procedures of the RFC series are evolved. The general expectation is > that all interested parties will participate in the RFCWG, and that only > under extreme circumstances should the RFCAB members have to hold > "CONCERN" positions. To avoid that situation, WG members are encouraged > to take RFCAB concerns seriously, and RFCAB members are encouraged to > make those concerns known early, and to be responsive to the community. > In particular, people are encouraged to respect the value of each > stream, and the long term health and viability of the RFC series. > > This process is intended to be one of continuous consultation. In > particular, RFCAB members should be consulting with their constuent > groups on an ongoing basis, so that when the time comes to consider a > proposal, there should be no surprises. Appointing bodies are expected > to establish whatever processes they deem appropriate to facilitate this > goal. > > > DRAFT DRAFT DRAFT > > > > > > RS[EA] Selection > > The RS[EA] will be searched for and vetted by a committee formed by the > ED, taking into account the role definition >  and > any detailed job description that we further develop. The search > committee may ask others to take part in the selection process in > confidence. The initial length of service shall be for one year, but > then further extensions will be for three to five years. > > > > > > RS[EA] Ongoing Performance Evaluation > > Periodically, the ED will send out to the community a call for input on > the performance of the RS[EA]. The evaluation will be based on criteria > specified in the role definition. Was the RS[EA] an active participant > in all/most meetings? Did the RS[EA] provide useful advice to the RPC > and to the WG? Did the RS[EA] exercise good judgment in terms of any > role he or she would have had on the Approval Body? Was the RS[EA] > effective in advising the community on appropriate actions to take or > not take? > > The ED will then review the feedback, consulting with stream manager > representatives, and then produce a recommendation to the LLC Board. The > LLC will then make a decision, taking into account that recommendation. > > Whether the RS[EA] role is structured as a contractual or employee > relationship is left to the LLC and ED to determine. > > From nobody Tue Mar 30 15:12: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 658BE3A10E9; Tue, 30 Mar 2021 15:12:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.915 X-Spam-Level: X-Spam-Status: No, score=-1.915 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixPV3WoVQZJg; Tue, 30 Mar 2021 15:12:27 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA3E43A10F2; Tue, 30 Mar 2021 15:12:24 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12UMCLJg000462; Tue, 30 Mar 2021 23:12:21 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6DA3E2203A; Tue, 30 Mar 2021 23:12:21 +0100 (BST) Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id 587BD22032; Tue, 30 Mar 2021 23:12:21 +0100 (BST) Received: from LAPTOPK7AS653V ([84.93.2.51]) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 12UMCKTL032186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 30 Mar 2021 23:12:20 +0100 Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: In-Reply-To: Date: Tue, 30 Mar 2021 23:12:19 +0100 Organization: Old Dog Consulting Message-ID: <061a01d725b1$c0fe4f50$42faedf0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_061B_01D725BA.22C416E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGmeGo9gWbaOJfSTzSUtRtBn0LBlKr+bpWw Content-Language: en-gb X-Originating-IP: 84.93.2.51 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-26062.002 X-TM-AS-Result: No--18.136-10.0-31-10 X-imss-scan-details: No--18.136-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26062.002 X-TMASE-Result: 10--18.135700-10.000000 X-TMASE-MatchedRID: HQYVVRq48Rw7iuZ/mdYYtoYTfLL+dl7ldDgJT0cEhOIugPi2f29YklHc aoiihQM4JyE4wEjvuNBPecEIo68AS0X+NKU+2Zr+EbDIcGnEqTpth1r0fdARdf1rjZtMqOTh7Ls 70A4WWwseh2nHejoau4S/TV9k6ppAlFGUu7DBzhi9YHdXZWILhxFlwJhVcSVOfRvRoQWnTHDCZX thWVuBOmYBzHSlpuK6fY+iJfFQBxelAfiiC1VA/U+u3rM3lFPndltGwnQcMsuNXZUPHfHpqSWcJ +E7Mdng6+NW68cvyd3N+qWlu2ZxaAH9Qt+fIXSvr1uVaZUKda89o/zfJjIK5PVigNEWT95fMlS1 TrjqiZZUtGORxgxurU6PG3UB9o6G2FA7wK9mP9cKfrbmG+DbUGavykzRKsvAJk0ODvl0KB4+Jck 2RObbKpTh6178RNH0HTcjQ7W4FBHjLrHqvAiSy2oB3Oi2v/DuhI0Mn1BGPmXpFiWi7Vr7GWJHMG 3qJf1GK/vKySl7Mu8JRKZB9eITIpTb3PKAwoR/JAJnnzjW4nTl36G1k49pwj40U98d2c1YnMvC6 7olx77y+H2tU9PVgwNZ/MOWCKL7ftMGQDsmQ9WZfDRE1uqSgvpq7lu964eMsu07x2cYg8oRncsX QaqCC2lR0XGai07A4J04kDID6v4yyi+n+H050X923Dm1WtF6I6ppAYiaFiXW0NdbzTWI+mqPPLF zDKS7UaO4KF/Hftd2GcWKGZufBZfau+Sc1iUTMCFeUKir/8pfrFN2iUp6mSSlLQddIe/WB2Xzec XaI8ii1w0PYZvqFHCO70QAsBdCTXhEHixAlLmbKItl61J/yZUdXE/WGn0FVoTa5lFknUEojRtIB R+kcOJGF26G8SWy8lP6F/raTZg+3cueg060kPkyV2fdI0pcrjZPhTmgf1ozjpPZTUPFueTZFP+b /R/8NkUSDDq742k= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 30 Mar 2021 22:12:31 -0000 This is a multipart message in MIME format. ------=_NextPart_000_061B_01D725BA.22C416E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Eliot and Brian for the work you=E2=80=99ve put into this. =20 I can support this version forming the basis of an I-D that we tinker = with a little. =20 Nits (which can wait, but might as well be fixed going into the I-D): s/the Indepenent Series/the Independent Stream/ s/approvedby/approved by/ s/there may be rough consensus exists/rough consensus exists/ s/constuent/constituent/ =20 Cheers, Adrian =20 From: Rfced-future On Behalf Of Eliot = Lear Sent: 30 March 2021 18:51 To: rfced-future@iab.org Subject: [Rfced-future] Consensus Call for Chairs Proposal: Please = comment by April 13th =20 The chairs appreciate comments received, and we now believe that it is = ok to start a consensus call on the chairs=E2=80=99 proposal on both = the draft evolution process and the RSE hire and accountability text, = taken as a whole. If you have already indicated your support for the = proposal, the chairs will note this. We would like to hear from all = interested participants. If you would like to indicate either support = or objection, please feel free to do so by Tuesday, April 13th. =20 If there is rough consensus, this text will be included in the = editor=E2=80=99s draft. It can be further amended with rough consensus, = and the chairs expect there to be some of that. Again, we see this as = compromise text, and so we are hoping that this is a good enough = starting point for further modifications. =20 As a reminder, we have an interim meeting scheduled for next Tuesday, = April 6th, 2021, at 20:00 GMT, when of course this proposal will be on = the agenda for people to discuss. More about that agenda in the next = day or two. =20 The text can be found on GitHub in two parts at the following URLs: =20 https://github.com/intarchboard/program-rfced-future/blob/master/draft-ev= olution-process.md https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire= -and-accountability.md =20 And it is below for your consideration as well. =20 Brian and Eliot =20 =20 DRAFT RFC Evolution Process Scope This procedure is applicable to the evolution processes relating to the = management and evolution of the RFC series, including format, tooling, = publication, dissemination, and overall management of the series. Structure The RFC evolution process is governed as follows: * The RFC Working Group, whose job it is to develop proposed changes, = and establish community consensus of those changes. * The The RFC Approval Board, whose job it is to provide final review of = proposals. Each group is described below. The RFC Working Group (RFCWG) All RFCWG meetings are open to any participant, subject to intellectual = property policies which must be consistent to those of the IETF [Note = Well]. At body's initial formation, all discussions are to take place on = open mailing lists, and anyone is welcome to comment / discuss. The = RFCWG may decide by rough consensus to use additional forms of = communication (for example, Github as specified in [RFC8874]) that are = consistent with [RFC2418]. The group will conform itself to an = anti-harassment policy consistent with [RFC7154,RFC7776]. IETF chair and the Independent Submissions Editor shall each appoint and = oversee a co-chair of the RFCWG. The RFC Approval Board (RFCAB) The RFC Approval Board consists of representatives from each RFC stream = (at the time of this writing, the IAB, the IETF, the IRTF, and the = Indepenent Series), as well as the RS[EA]. The sole function of this = group is to review draft proposals approvedby the RFCWG. The RFCAB may = choose its chair as it sees fit. The group is primarily expected to = operate via email and through any necessary tooling. A record of all = proceedings (no matter the form) will be kept. Update Process The following procedure is used to update the RFC process: 1. Someone writes a draft proposal in the form of an Internet-Draft. 2. If there is sufficient interest in the proposal, RFCWG will adopt the = proposal as a working draft, much the same way a working group of the = IETF would. 3. The RFCWG will then further develop the proposal. All members of the = RFCAB are expected to participate in discussion relating to all = proposals. 4. At some point, if the chairs believe there may be rough consensus = exists for the proposal to advance, they will issue a working group last = call. 5. After a suitable period of time, the chairs will determine whether = rough consensus for the proposal exists. If comments have been received = and substantial changes have been made, it is expected that additional = last calls may be made. 6. Once working group consensus is established, a community call for = comments will be issued. Should substantial comments be received, the = working group will again consider those comments and make revisions as = they see fit. At this same time, the RFCAB will consider the proposal. 7. Should substantial changes be made, additional community calls for = comment should be issued, and again comments considered. 8. Once all comments have been been addressed, the working group chairs = will transmit the latest proposal to the RFCAB. 9. Within a reasonable period of time, the RFCAB will then poll on the = proposal. Positions may be as follows: * "YES": the proposal should be approved * "CONCERN" : the proposal raises substantial concerns that must be = addressed. * "RECUSE" : the person holding the position has a conflict of interest. Anyone holding a "CONCERN" position MUST explain their concern to the = community in detail. The explanation may or may not be actionable. A CONCERN may be made for two reasons: * The proposal represents a serious problem for the group a particular = member represents. * The member believes that the proposal would cause serious harm to the = overall series, including harm to the long term health and viability of = the series. No CONCERN should ever come as a surprise to the RFCWG. 10. If a CONCERN exists, discussion will take place within the RFCWG. = Again, all RFCAB members MUST participate. 11. If all CONCERN positions are addressed, then the proposal is = approved. Again, if substantial changes have been made, an additional = call for community input should be made. 12. If, after a suitable period of time, any CONCERN positions remain, a = formal vote of the RFCAB is taken. If a majority of RFCAB members vote = to approve, the proposal is approved. Otherwise, it is returned to the = RFCWG. In the case of a tie, the proposal is approved. 13. When a proposal is approved, a notification is sent to the = community, and it is published as an RFC. The roles of the LLC Board and ED LLC Board members, staff, and the Executive Director, are invited to = participate as community members in the RFCWG to the extent permitted by = any relevant LLC policies. Appeals Appeals of RFCAB decisions may only be made based on process failures, = and not on the substance of a proposal. These appeals SHALL be made to = the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY = decide only whether a process failure occurred, and what if any = corrective action should take place. Discussion The intent of this policy is to provide an open forum by which policies = and procedures of the RFC series are evolved. The general expectation is = that all interested parties will participate in the RFCWG, and that only = under extreme circumstances should the RFCAB members have to hold = "CONCERN" positions. To avoid that situation, WG members are encouraged = to take RFCAB concerns seriously, and RFCAB members are encouraged to = make those concerns known early, and to be responsive to the community. = In particular, people are encouraged to respect the value of each = stream, and the long term health and viability of the RFC series. This process is intended to be one of continuous consultation. In = particular, RFCAB members should be consulting with their constuent = groups on an ongoing basis, so that when the time comes to consider a = proposal, there should be no surprises. Appointing bodies are expected = to establish whatever processes they deem appropriate to facilitate this = goal. DRAFT DRAFT DRAFT RS[EA] Selection The RS[EA] will be searched for and vetted by a committee formed by the = ED, taking into account the role definition = and any detailed job description that we further develop. = The search committee may ask others to take part in the selection = process in confidence. The initial length of service shall be for one = year, but then further extensions will be for three to five years. RS[EA] Ongoing Performance Evaluation Periodically, the ED will send out to the community a call for input on = the performance of the RS[EA]. The evaluation will be based on criteria = specified in the role definition. Was the RS[EA] an active participant = in all/most meetings? Did the RS[EA] provide useful advice to the RPC = and to the WG? Did the RS[EA] exercise good judgment in terms of any = role he or she would have had on the Approval Body? Was the RS[EA] = effective in advising the community on appropriate actions to take or = not take? The ED will then review the feedback, consulting with stream manager = representatives, and then produce a recommendation to the LLC Board. The = LLC will then make a decision, taking into account that recommendation. Whether the RS[EA] role is structured as a contractual or employee = relationship is left to the LLC and ED to determine. ------=_NextPart_000_061B_01D725BA.22C416E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks Eliot and Brian for the work = you=E2=80=99ve put into this.

 

I can = support this version forming the basis of an I-D that we tinker with a = little.

 

Nits (which = can wait, but might as well be fixed going into the = I-D):

s/the Indepenent Series/the = Independent Stream/

s/approvedby/approved by/

s/there may be rough = consensus exists/rough consensus exists/

s/constuent/constituent/=

 

Cheers,

Adrian

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Eliot = Lear
Sent: 30 March 2021 18:51
To: = rfced-future@iab.org
Subject: [Rfced-future] Consensus Call = for Chairs Proposal: Please comment by April = 13th

 

The = chairs appreciate comments received, and we now believe that it is ok to = start a  consensus call on the chairs=E2=80=99 proposal on both the = draft evolution process and the RSE hire and accountability text, taken = as a whole.  If you have already indicated your support for the = proposal, the chairs will note this.  We would like to hear from = all interested participants.  If you would like to indicate = either support or objection, please feel free to do so by Tuesday, April = 13th.

 

If there is rough consensus, this text will be = included in the editor=E2=80=99s draft.  It can be further amended = with rough consensus, and the chairs expect there to be some of that. =  Again, we see this as compromise text, and so we are hoping that = this is a good enough starting point for further = modifications.

 

As a reminder, we have an interim meeting scheduled = for next Tuesday, April 6th, 2021, at 20:00 GMT, when of course this = proposal will be on the agenda for people to discuss.  More about = that agenda in the next day or two.

 

The text can be found on GitHub in two parts at the = following URLs:

 

https://github.com/intarchboard/program-r= fced-future/blob/master/rse-hire-and-accountability.md

=

 

And it is below for your consideration as = well.

 

Brian and Eliot

 

 

DRAFT RFC = Evolution Process

Scope

This = procedure is applicable to the evolution processes relating to the = management and evolution of the RFC series, including format, tooling, = publication, dissemination, and overall management of the = series.

Structure

The RFC = evolution process is governed as follows:

  • The RFC Working Group, whose job it is to develop proposed = changes, and establish community consensus of those = changes.
  • The The RFC Approval Board, whose job it is to provide = final review of proposals.

Each group = is described below.

The RFC Working Group = (RFCWG)

All RFCWG = meetings are open to any participant, subject to intellectual property = policies which must be consistent to those of the IETF [Note Well]. At = body's initial formation, all discussions are to take place on open = mailing lists, and anyone is welcome to comment / discuss. The RFCWG may = decide by rough consensus to use additional forms of communication (for = example, Github as specified in [RFC8874]) that are consistent with = [RFC2418]. The group will conform itself to an anti-harassment policy = consistent with [RFC7154,RFC7776].

IETF chair = and the Independent Submissions Editor shall each appoint and oversee a = co-chair of the RFCWG.

The RFC Approval Board = (RFCAB)

The RFC = Approval Board consists of representatives from each RFC stream (at the = time of this writing, the IAB, the IETF, the IRTF, and the Indepenent = Series), as well as the RS[EA]. The sole function of this group is to = review draft proposals approvedby the RFCWG. The RFCAB may choose its = chair as it sees fit. The group is primarily expected to operate via = email and through any necessary tooling. A record of all proceedings (no = matter the form) will be kept.

Update = Process

The = following procedure is used to update the RFC process:

  1. Someone writes a draft proposal in the form of an = Internet-Draft.
  2. If there is sufficient interest in the proposal, RFCWG will = adopt the proposal as a working draft, much the same way a working group = of the IETF would.
  3. The RFCWG will then further develop the proposal. All = members of the RFCAB are expected to participate in discussion relating = to all proposals.
  4. At some point, if the chairs believe there may be rough = consensus exists for the proposal to advance, they will issue a working = group last call.
  5. After a suitable period of time, the chairs will determine = whether rough consensus for the proposal exists.  If comments have = been received and substantial changes have been made, it is expected = that additional last calls may be made.
  6. Once working group consensus is established, a community = call for comments will be issued. Should substantial comments be = received, the working group will again consider those comments and make = revisions as they see fit. At this same time, the RFCAB will consider = the proposal.
  7. Should substantial changes be made, additional community = calls for comment should be issued, and again comments = considered.
  8. Once all comments have been been addressed, the working = group chairs will transmit the latest proposal to the = RFCAB.
  9. Within a reasonable period of time, the RFCAB will then = poll on the proposal. Positions may be as = follows:
    • "YES": the proposal should be = approved
    • "CONCERN" : the proposal raises substantial = concerns that must be addressed.
    • "RECUSE" : the person holding the position has a = conflict of interest.

Anyone holding a "CONCERN" position MUST explain their = concern to the community in detail. The explanation may or may not be = actionable.

A CONCERN may be made for two reasons:

    • The proposal represents a serious problem for the group a = particular member represents.
    • The member believes that the proposal would cause serious = harm to the overall series, including harm to the long term health and = viability of the series.

No CONCERN should ever come as a surprise to the = RFCWG.

  1. If a CONCERN exists, discussion will take place within the = RFCWG. Again, all RFCAB members MUST participate.
  2. If all CONCERN positions are addressed, then the proposal = is approved. Again, if substantial changes have been made, an additional = call for community input should be made.
  3. If, after a suitable period of time, any CONCERN positions = remain, a formal vote of the RFCAB is taken. If a majority of RFCAB = members vote to approve, the proposal is approved. Otherwise, it is = returned to the RFCWG. In the case of a tie, the proposal is = approved.
  4. When a proposal is approved, a notification is sent to the = community, and it is published as an RFC.

The = roles of the LLC Board and ED

LLC Board = members, staff, and the Executive Director, are invited to participate = as community members in the RFCWG to the extent permitted by any = relevant LLC policies.

Appeals

Appeals of = RFCAB decisions may only be made based on process failures, and not on = the substance of a proposal. These appeals SHALL be made to the ISOC BoT = within thirty days of the RFCAB decision. The ISOC BoT MAY decide only = whether a process failure occurred, and what if any corrective action = should take place.

Discussion

The intent = of this policy is to provide an open forum by which policies and = procedures of the RFC series are evolved. The general expectation is = that all interested parties will participate in the RFCWG, and that only = under extreme circumstances should the RFCAB members have to hold = "CONCERN" positions. To avoid that situation, WG members are = encouraged to take RFCAB concerns seriously, and RFCAB members are = encouraged to make those concerns known early, and to be responsive to = the community. In particular, people are encouraged to respect the value = of each stream, and the long term health and viability of the RFC = series.

This = process is intended to be one of continuous consultation. In particular, = RFCAB members should be consulting with their constuent groups on an = ongoing basis, so that when the time comes to consider a proposal, there = should be no surprises. Appointing bodies are expected to establish = whatever processes they deem appropriate to facilitate this = goal.

DRAFT DRAFT = DRAFT

RS[EA] Selection

The RS[EA] = will be searched for and vetted by a committee formed by the ED, taking = into account the role definition and any detailed job = description that we further develop. The search committee may ask others = to take part in the selection process in confidence. The initial length = of service shall be for one year, but then further extensions will be = for three to five years.

RS[EA] Ongoing Performance = Evaluation

Periodically= , the ED will send out to the community a call for input on the = performance of the RS[EA]. The evaluation will be based on criteria = specified in the role definition. Was the RS[EA] an active participant = in all/most meetings? Did the RS[EA] provide useful advice to the RPC = and to the WG? Did the RS[EA] exercise good judgment in terms of any = role he or she would have had on the Approval Body? Was the RS[EA] = effective in advising the community on appropriate actions to take or = not take?

The ED will = then review the feedback, consulting with stream manager = representatives, and then produce a recommendation to the LLC Board. The = LLC will then make a decision, taking into account that = recommendation.

Whether the = RS[EA] role is structured as a contractual or employee relationship is = left to the LLC and ED to = determine.

------=_NextPart_000_061B_01D725BA.22C416E0-- From nobody Tue Mar 30 20:48: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 6F6833A1708 for ; Tue, 30 Mar 2021 20:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 2TyvtvuvjslG for ; Tue, 30 Mar 2021 20:48:52 -0700 (PDT) Received: from mail-ua1-x932.google.com (mail-ua1-x932.google.com [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7830D3A1705 for ; Tue, 30 Mar 2021 20:48:52 -0700 (PDT) Received: by mail-ua1-x932.google.com with SMTP id q18so5697228uas.11 for ; Tue, 30 Mar 2021 20:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kROrJsRRpzjeIdTHTW6gmdIehhkI/MoFPdX0bnJfT7s=; b=BFiqyTZ8fxQmtT0JqxKR2jwbP4lqTncBJ5nkADWJF9VRWEmVjcf2bz8ZhzEp2ndC8y CIMG04iE+Gx5APHHlP+X/x5a5k1IaiFX5YY2Ue0C9DFD1nsHfGauHy+5g7m6hJk1MqrW shzzkxqpH9BeC4HzvOod20AP5QZ/DDuxfDuI1vsi5GBCF+xtsX4UbuAFG/yAV7z4j52N 7NHwuUzr24TzZQ9SWk6ED3X3pmccWf3YZzF9yTKQYZVUjAjhAwv4Fv+axarzNUmbvRCA StCqy3WHfRDa0QzXhh82vRtO3SMZE3s9tX/V08D2LChNJMTaG+x5r+mmSkthBd5bhEDS 2UYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kROrJsRRpzjeIdTHTW6gmdIehhkI/MoFPdX0bnJfT7s=; b=XirAma1MunQOQdCTeYTBkNkaq4lnWCWXfSCZ1wnu3+bM9FaBlKH1Nm6TEUVaVRNUB7 Rv7Sk43Qxvhnmu3PJtdyeIoI6Ttpsg73FCih5IFlJYUtKDqAkUZzAalT00HYbtwoRRL1 mGla0wwT5yPXYGFx1HpPqoLk6n1i1WELbDZDO1y0Z6xLoBnRzLcLHpl1rcRlMSjkVXni ahMq4pe1ZMCDwWIaUFiZxpArhnSU0IwtYs0kPkKh/PFRysLUrW24YeSYtSZSU7mB8Y8q Ixmbrk5pyx8I5Kc5LoY7j+KjFSv0+OpvB2h8M6ECoOk2nnmltIYbcOBKu1RcChcToSYT RumQ== X-Gm-Message-State: AOAM531FqvBtUbhel73O0Pu3WqWN4gn0e8DeiprOWSCV1kGahufhiwP3 wz4jrqc+hLnNVg3mPVzl9yhr6lu7zQ3rakuNKe6mwtnY5Ig= X-Google-Smtp-Source: ABdhPJwlb2UcT54B+c3leRzu36pZvH//likGKlV4gwgpEs/X6dlQe2/7V+cRR9TopCGIsqh7CyqBwhPBL+qNN24PgtA= X-Received: by 2002:ab0:6645:: with SMTP id b5mr396285uaq.109.1617162529402; Tue, 30 Mar 2021 20:48:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nevil Brownlee Date: Wed, 31 Mar 2021 16:48:22 +1300 Message-ID: To: Eliot Lear Cc: rfced-future@iab.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 31 Mar 2021 03:48:57 -0000 Hi Eliot: I agree that these two documents reflect all this group's discussions to date, and make a good starting point for a final RFC. I note that the "Role of the RSE/A" is in a separate file, that makes it three documents to combine. Also, since the "RSE/A Selection" document proposes that the LLC ED will be responsible for the RSE/A, I wonder whether Jay has been consulted about it? CHeers, Nevil On Wed, Mar 31, 2021 at 6:51 AM Eliot Lear wrote: > > The chairs appreciate comments received, and we now believe that it is ok= to start a consensus call on the chairs=E2=80=99 proposal on both the dra= ft evolution process and the RSE hire and accountability text, taken as a w= hole. If you have already indicated your support for the proposal, the cha= irs will note this. We would like to hear from all interested participants= . If you would like to indicate either support or objection, please feel f= ree to do so by Tuesday, April 13th. > > If there is rough consensus, this text will be included in the editor=E2= =80=99s draft. It can be further amended with rough consensus, and the cha= irs expect there to be some of that. Again, we see this as compromise text= , and so we are hoping that this is a good enough starting point for furthe= r modifications. > > As a reminder, we have an interim meeting scheduled for next Tuesday, Apr= il 6th, 2021, at 20:00 GMT, when of course this proposal will be on the age= nda for people to discuss. More about that agenda in the next day or two. > > The text can be found on GitHub in two parts at the following URLs: > > https://github.com/intarchboard/program-rfced-future/blob/master/draft-ev= olution-process.md > https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire= -and-accountability.md > > And it is below for your consideration as well. > > Brian and Eliot > > > DRAFT RFC Evolution Process > > Scope > > This procedure is applicable to the evolution processes relating to the m= anagement and evolution of the RFC series, including format, tooling, publi= cation, dissemination, and overall management of the series. > > Structure > > The RFC evolution process is governed as follows: > > The RFC Working Group, whose job it is to develop proposed changes, and e= stablish community consensus of those changes. > The The RFC Approval Board, whose job it is to provide final review of pr= oposals. > > Each group is described below. > > The RFC Working Group (RFCWG) > > All RFCWG meetings are open to any participant, subject to intellectual p= roperty policies which must be consistent to those of the IETF [Note Well].= At body's initial formation, all discussions are to take place on open mai= ling lists, and anyone is welcome to comment / discuss. The RFCWG may decid= e by rough consensus to use additional forms of communication (for example,= Github as specified in [RFC8874]) that are consistent with [RFC2418]. The = group will conform itself to an anti-harassment policy consistent with [RFC= 7154,RFC7776]. > > IETF chair and the Independent Submissions Editor shall each appoint and = oversee a co-chair of the RFCWG. > > The RFC Approval Board (RFCAB) > > The RFC Approval Board consists of representatives from each RFC stream (= at the time of this writing, the IAB, the IETF, the IRTF, and the Indepenen= t Series), as well as the RS[EA]. The sole function of this group is to rev= iew draft proposals approvedby the RFCWG. The RFCAB may choose its chair as= it sees fit. The group is primarily expected to operate via email and thro= ugh any necessary tooling. A record of all proceedings (no matter the form)= will be kept. > > Update Process > > The following procedure is used to update the RFC process: > > Someone writes a draft proposal in the form of an Internet-Draft. > > If there is sufficient interest in the proposal, RFCWG will adopt the pro= posal as a working draft, much the same way a working group of the IETF wou= ld. > > The RFCWG will then further develop the proposal. All members of the RFCA= B are expected to participate in discussion relating to all proposals. > > At some point, if the chairs believe there may be rough consensus exists = for the proposal to advance, they will issue a working group last call. > > After a suitable period of time, the chairs will determine whether rough = consensus for the proposal exists. If comments have been received and subs= tantial changes have been made, it is expected that additional last calls m= ay be made. > > Once working group consensus is established, a community call for comment= s will be issued. Should substantial comments be received, the working grou= p will again consider those comments and make revisions as they see fit. At= this same time, the RFCAB will consider the proposal. > > Should substantial changes be made, additional community calls for commen= t should be issued, and again comments considered. > > Once all comments have been been addressed, the working group chairs will= transmit the latest proposal to the RFCAB. > > Within a reasonable period of time, the RFCAB will then poll on the propo= sal. Positions may be as follows: > > "YES": the proposal should be approved > "CONCERN" : the proposal raises substantial concerns that must be address= ed. > "RECUSE" : the person holding the position has a conflict of interest. > > Anyone holding a "CONCERN" position MUST explain their concern to the com= munity in detail. The explanation may or may not be actionable. > > A CONCERN may be made for two reasons: > > The proposal represents a serious problem for the group a particular memb= er represents. > The member believes that the proposal would cause serious harm to the ove= rall series, including harm to the long term health and viability of the se= ries. > > No CONCERN should ever come as a surprise to the RFCWG. > > If a CONCERN exists, discussion will take place within the RFCWG. Again, = all RFCAB members MUST participate. > > If all CONCERN positions are addressed, then the proposal is approved. Ag= ain, if substantial changes have been made, an additional call for communit= y input should be made. > > If, after a suitable period of time, any CONCERN positions remain, a form= al vote of the RFCAB is taken. If a majority of RFCAB members vote to appro= ve, the proposal is approved. Otherwise, it is returned to the RFCWG. In th= e case of a tie, the proposal is approved. > > When a proposal is approved, a notification is sent to the community, and= it is published as an RFC. > > The roles of the LLC Board and ED > > LLC Board members, staff, and the Executive Director, are invited to part= icipate as community members in the RFCWG to the extent permitted by any re= levant LLC policies. > > Appeals > > Appeals of RFCAB decisions may only be made based on process failures, an= d not on the substance of a proposal. These appeals SHALL be made to the IS= OC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY decide on= ly whether a process failure occurred, and what if any corrective action sh= ould take place. > > Discussion > > The intent of this policy is to provide an open forum by which policies a= nd procedures of the RFC series are evolved. The general expectation is tha= t all interested parties will participate in the RFCWG, and that only under= extreme circumstances should the RFCAB members have to hold "CONCERN" posi= tions. To avoid that situation, WG members are encouraged to take RFCAB con= cerns seriously, and RFCAB members are encouraged to make those concerns kn= own early, and to be responsive to the community. In particular, people are= encouraged to respect the value of each stream, and the long term health a= nd viability of the RFC series. > > This process is intended to be one of continuous consultation. In particu= lar, RFCAB members should be consulting with their constuent groups on an o= ngoing basis, so that when the time comes to consider a proposal, there sho= uld be no surprises. Appointing bodies are expected to establish whatever p= rocesses they deem appropriate to facilitate this goal. > > DRAFT DRAFT DRAFT > > RS[EA] Selection > > The RS[EA] will be searched for and vetted by a committee formed by the E= D, taking into account the role definition and any detailed job description= that we further develop. The search committee may ask others to take part = in the selection process in confidence. The initial length of service shall= be for one year, but then further extensions will be for three to five yea= rs. > > RS[EA] Ongoing Performance Evaluation > > Periodically, the ED will send out to the community a call for input on t= he performance of the RS[EA]. The evaluation will be based on criteria spec= ified in the role definition. Was the RS[EA] an active participant in all/m= ost meetings? Did the RS[EA] provide useful advice to the RPC and to the WG= ? Did the RS[EA] exercise good judgment in terms of any role he or she woul= d have had on the Approval Body? Was the RS[EA] effective in advising the c= ommunity on appropriate actions to take or not take? > > The ED will then review the feedback, consulting with stream manager repr= esentatives, and then produce a recommendation to the LLC Board. The LLC wi= ll then make a decision, taking into account that recommendation. > > Whether the RS[EA] role is structured as a contractual or employee relati= onship is left to the LLC and ED to determine. > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- ----------------------------------- Nevil Brownlee, Taupo, NZ From nobody Wed Mar 31 02:02: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 72A043A20E1; Wed, 31 Mar 2021 02:02:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BuFmpmH7hRE2; Wed, 31 Mar 2021 02:02:47 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87CD63A20E4; Wed, 31 Mar 2021 02:02:47 -0700 (PDT) Received: from p200300dee71fe600fcaa0550d6afc28f.dip0.t-ipconnect.de ([2003:de:e71f:e600:fcaa:550:d6af:c28f]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lRWkL-0004vj-M2; Wed, 31 Mar 2021 11:02:41 +0200 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: Wed, 31 Mar 2021 11:02:39 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <47B92D05-8A64-4183-BDE9-A48B348007CA@kuehlewind.net> References: To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1617181367;6ab0c968; X-HE-SMSGID: 1lRWkL-0004vj-M2 Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 31 Mar 2021 09:02:53 -0000 Hi Eliot, hi all, Thanks for putting this together. I think this is a good starting point = for a document. There are a couple of topics that didn=E2=80=99t get a = lot of discussion yet and probably will need some more. E.g. I would = consider the follow three points in that category: - selection of the wg chairs - ISOC in the appeal chain (if we all agree that we want that, we really = should contact the BoT early on) - Creation of the search committee Mirja > On 30. Mar 2021, at 19:51, Eliot Lear = wrote: >=20 > The chairs appreciate comments received, and we now believe that it is = ok to start a consensus call on the chairs=E2=80=99 proposal on both = the draft evolution process and the RSE hire and accountability text, = taken as a whole. If you have already indicated your support for the = proposal, the chairs will note this. We would like to hear from all = interested participants. If you would like to indicate either support = or objection, please feel free to do so by Tuesday, April 13th. >=20 > If there is rough consensus, this text will be included in the = editor=E2=80=99s draft. It can be further amended with rough consensus, = and the chairs expect there to be some of that. Again, we see this as = compromise text, and so we are hoping that this is a good enough = starting point for further modifications. >=20 > As a reminder, we have an interim meeting scheduled for next Tuesday, = April 6th, 2021, at 20:00 GMT, when of course this proposal will be on = the agenda for people to discuss. More about that agenda in the next = day or two. >=20 > The text can be found on GitHub in two parts at the following URLs: >=20 > = https://github.com/intarchboard/program-rfced-future/blob/master/draft-evo= lution-process.md > = https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-= and-accountability.md >=20 > And it is below for your consideration as well. >=20 > Brian and Eliot >=20 >=20 > DRAFT RFC Evolution Process >=20 >=20 > Scope >=20 > This procedure is applicable to the evolution processes relating to = the management and evolution of the RFC series, including format, = tooling, publication, dissemination, and overall management of the = series. >=20 >=20 > Structure >=20 > The RFC evolution process is governed as follows: >=20 > =E2=80=A2 The RFC Working Group, whose job it is to develop = proposed changes, and establish community consensus of those changes. > =E2=80=A2 The The RFC Approval Board, whose job it is to provide = final review of proposals. > Each group is described below. >=20 >=20 > The RFC Working Group (RFCWG) >=20 > All RFCWG meetings are open to any participant, subject to = intellectual property policies which must be consistent to those of the = IETF [Note Well]. At body's initial formation, all discussions are to = take place on open mailing lists, and anyone is welcome to comment / = discuss. The RFCWG may decide by rough consensus to use additional forms = of communication (for example, Github as specified in [RFC8874]) that = are consistent with [RFC2418]. The group will conform itself to an = anti-harassment policy consistent with [RFC7154,RFC7776]. >=20 > IETF chair and the Independent Submissions Editor shall each appoint = and oversee a co-chair of the RFCWG. >=20 >=20 > The RFC Approval Board (RFCAB) >=20 > The RFC Approval Board consists of representatives from each RFC = stream (at the time of this writing, the IAB, the IETF, the IRTF, and = the Indepenent Series), as well as the RS[EA]. The sole function of this = group is to review draft proposals approvedby the RFCWG. The RFCAB may = choose its chair as it sees fit. The group is primarily expected to = operate via email and through any necessary tooling. A record of all = proceedings (no matter the form) will be kept. >=20 >=20 > Update Process >=20 > The following procedure is used to update the RFC process: >=20 > =E2=80=A2 Someone writes a draft proposal in the form of an = Internet-Draft. >=20 > =E2=80=A2 If there is sufficient interest in the proposal, RFCWG = will adopt the proposal as a working draft, much the same way a working = group of the IETF would. >=20 > =E2=80=A2 The RFCWG will then further develop the proposal. All = members of the RFCAB are expected to participate in discussion relating = to all proposals. >=20 > =E2=80=A2 At some point, if the chairs believe there may be = rough consensus exists for the proposal to advance, they will issue a = working group last call. >=20 > =E2=80=A2 After a suitable period of time, the chairs will = determine whether rough consensus for the proposal exists. If comments = have been received and substantial changes have been made, it is = expected that additional last calls may be made. >=20 > =E2=80=A2 Once working group consensus is established, a = community call for comments will be issued. Should substantial comments = be received, the working group will again consider those comments and = make revisions as they see fit. At this same time, the RFCAB will = consider the proposal. >=20 > =E2=80=A2 Should substantial changes be made, additional = community calls for comment should be issued, and again comments = considered. >=20 > =E2=80=A2 Once all comments have been been addressed, the = working group chairs will transmit the latest proposal to the RFCAB. >=20 > =E2=80=A2 Within a reasonable period of time, the RFCAB will = then poll on the proposal. Positions may be as follows: >=20 > =E2=80=A2 "YES": the proposal should be approved > =E2=80=A2 "CONCERN" : the proposal raises substantial = concerns that must be addressed. > =E2=80=A2 "RECUSE" : the person holding the position has = a conflict of interest. > Anyone holding a "CONCERN" position MUST explain their concern to the = community in detail. The explanation may or may not be actionable. >=20 > A CONCERN may be made for two reasons: >=20 > =E2=80=A2 The proposal represents a serious problem for = the group a particular member represents. > =E2=80=A2 The member believes that the proposal would = cause serious harm to the overall series, including harm to the long = term health and viability of the series. > No CONCERN should ever come as a surprise to the RFCWG. >=20 > =E2=80=A2 If a CONCERN exists, discussion will take place within = the RFCWG. Again, all RFCAB members MUST participate. >=20 > =E2=80=A2 If all CONCERN positions are addressed, then the = proposal is approved. Again, if substantial changes have been made, an = additional call for community input should be made. >=20 > =E2=80=A2 If, after a suitable period of time, any CONCERN = positions remain, a formal vote of the RFCAB is taken. If a majority of = RFCAB members vote to approve, the proposal is approved. Otherwise, it = is returned to the RFCWG. In the case of a tie, the proposal is = approved. >=20 > =E2=80=A2 When a proposal is approved, a notification is sent to = the community, and it is published as an RFC. >=20 >=20 > The roles of the LLC Board and ED >=20 > LLC Board members, staff, and the Executive Director, are invited to = participate as community members in the RFCWG to the extent permitted by = any relevant LLC policies. >=20 >=20 > Appeals >=20 > Appeals of RFCAB decisions may only be made based on process failures, = and not on the substance of a proposal. These appeals SHALL be made to = the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY = decide only whether a process failure occurred, and what if any = corrective action should take place. >=20 >=20 > Discussion >=20 > The intent of this policy is to provide an open forum by which = policies and procedures of the RFC series are evolved. The general = expectation is that all interested parties will participate in the = RFCWG, and that only under extreme circumstances should the RFCAB = members have to hold "CONCERN" positions. To avoid that situation, WG = members are encouraged to take RFCAB concerns seriously, and RFCAB = members are encouraged to make those concerns known early, and to be = responsive to the community. In particular, people are encouraged to = respect the value of each stream, and the long term health and viability = of the RFC series. >=20 > This process is intended to be one of continuous consultation. In = particular, RFCAB members should be consulting with their constuent = groups on an ongoing basis, so that when the time comes to consider a = proposal, there should be no surprises. Appointing bodies are expected = to establish whatever processes they deem appropriate to facilitate this = goal. >=20 > DRAFT DRAFT DRAFT >=20 >=20 > RS[EA] Selection >=20 > The RS[EA] will be searched for and vetted by a committee formed by = the ED, taking into account the role definition and any detailed job = description that we further develop. The search committee may ask others = to take part in the selection process in confidence. The initial length = of service shall be for one year, but then further extensions will be = for three to five years. >=20 >=20 > RS[EA] Ongoing Performance Evaluation >=20 > Periodically, the ED will send out to the community a call for input = on the performance of the RS[EA]. The evaluation will be based on = criteria specified in the role definition. Was the RS[EA] an active = participant in all/most meetings? Did the RS[EA] provide useful advice = to the RPC and to the WG? Did the RS[EA] exercise good judgment in terms = of any role he or she would have had on the Approval Body? Was the = RS[EA] effective in advising the community on appropriate actions to = take or not take? >=20 > The ED will then review the feedback, consulting with stream manager = representatives, and then produce a recommendation to the LLC Board. The = LLC will then make a decision, taking into account that recommendation. >=20 > Whether the RS[EA] role is structured as a contractual or employee = relationship is left to the LLC and ED to determine. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Mar 31 05:09: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 3DFAE3A2634 for ; Wed, 31 Mar 2021 05:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BC8uhObTaQ7Z for ; Wed, 31 Mar 2021 05:09:46 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0477B3A0C94 for ; Wed, 31 Mar 2021 05:09:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2603; q=dns/txt; s=iport; t=1617192586; x=1618402186; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=t3ma7KM+7J2MDFhjBXw99wk+hZnOPG5l3SLHL15xzg0=; b=aumxmAfNMXSLG1nWcCMBv1YP7Phc2SCt43AgVxGNBn1IPZqtLMnIwx4o 7mlZGJPv1MUv4VjaCAaUA4eKreLVhNVTVoCkp358fAJT4LvCr6QmayzFb STNt0WpguB3wtiMoKjhFN0ZB7aeTPB/g4DPG6iusp1DbgUL0cxrZzf/KC 4=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BUAACEZWRglxbLJq1aGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAYIQg3cBJxIxhEGJBIhLA5xfBAcBAQEKAwEBNAQBAYRQAoF8JjgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBhkOGRAEBAQMBDg8GQhQFCwsOC?= =?us-ascii?q?ioCAlcGE4JwAYJmIaotd4EyhViEZhCBOYFTi3dCgguBEicMEIJZPoEEgx6DN?= =?us-ascii?q?DWCKwSBVRCBDDkSFA0MCIEoBgEtnmCcfIMRgzqBRZdsAx+DSIpwhWSQPIZir?= =?us-ascii?q?TkBg38CBAYFAhaBayGBWzMaCBsVZQGCPj4SGQ2ONgIejhQ/Ay84AgYBCQEBA?= =?us-ascii?q?wmOfAEB?= IronPort-HdrOrdr: A9a23:HuHdmKhrAX5xWEpqof+ujXIzInBQXlgji2hD6mlwRA09T+Wzna mV7Zcm/DXzjyscX2xlpMCYNMC7LU/02JZp7eAqXIuKcxLhvAKTRr1KzYyn+DH4Hj27y+g178 ddWoxzEsf5A1Q/rcuS2mSFOvIhxNXCz6yyn+fZyB5WIj1CUK1r4wdnBgvzKCQfLzVuPpY3GI GR4cBKvVObCBEqR/6mDXoIVfWrnbP2va/hCCR2ZSIP2U2rhTOs5KWSKWn94j4uFxVS3Lwl7W /J1yv+66nLiYDc9jbsk0nO8p9RhNztjuFmOfXJoM0UJjLw4zzYA7hcZw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.81,293,1610409600"; d="asc'?scan'208";a="34586919" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2021 12:09:41 +0000 Received: from [10.61.144.91] ([10.61.144.91]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 12VC9e0O029643 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 31 Mar 2021 12:09:41 GMT From: Eliot Lear Message-Id: <35526D99-6D0E-4734-8FBE-BE9CC2C228C1@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_60B08173-4832-4859-8222-CDFF4ED622A2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) Date: Wed, 31 Mar 2021 14:09:40 +0200 In-Reply-To: <47B92D05-8A64-4183-BDE9-A48B348007CA@kuehlewind.net> Cc: rfced-future@iab.org To: Mirja Kuehlewind References: <47B92D05-8A64-4183-BDE9-A48B348007CA@kuehlewind.net> X-Mailer: Apple Mail (2.3654.60.0.2.21) X-Outbound-SMTP-Client: 10.61.144.91, [10.61.144.91] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 31 Mar 2021 12:09:52 -0000 --Apple-Mail=_60B08173-4832-4859-8222-CDFF4ED622A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [resend] Thanks, Mirja. Yes, I suspect that there will be a lot of discussion on = the points you mentioned as we amend the base text. Just to explain the = logic of each of these: > On 31 Mar 2021, at 11:02, Mirja Kuehlewind = wrote: >=20 > Hi Eliot, hi all, >=20 > Thanks for putting this together. I think this is a good starting = point for a document. There are a couple of topics that didn=E2=80=99t = get a lot of discussion yet and probably will need some more. E.g. I = would consider the follow three points in that category: >=20 > - selection of the wg chairs > - ISOC in the appeal chain (if we all agree that we want that, we = really should contact the BoT early on) These two address a point that Mike made: the IAB has an outsized = influence on the AB because two members are directly appointed (the IAB = stream representative and the ISE), and it has influence on two others = (the IRTF stream and IESG stream representatives). As a stream = manager, the IAB is conflicted. Thus it should not be involved in = process appeals when it could very easily be a party. This, I believe, = was Brian=E2=80=99s Carpenters original logic. We similarly attempted = to balance power in the chairs, recognizing that the ISOC BoT would = probably not be in a good position to pick them. Feel free to propose alternatives as we enter the next phase of this = process. > - Creation of the search committee That was part and parcel of the proposal for oversight, which we thought = had to be married to hiring. Again, feel free to propose alternatives. Eliot --Apple-Mail=_60B08173-4832-4859-8222-CDFF4ED622A2 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmBkZoQACgkQh7ZrRtnS ejMPkAgAjcmuqF9BUkT3+yTzTZDmzvQQDYIFYp25FVkxZzxM5gMBVrqB2Lw7qTh7 QyLM/jk6FTa+PHbgPFFkTANxbJAMUE6ldXPDSA2bWOtFJZHhvW9zkO4FPYuZVdJb a/zF6NLHKxcFIs2lLxfiSWb9Whb2e752ma2hGJ4uS/01NH3TspwoeqQg7t7yvMtw 0TwejFNFhmZIq9Wt7gsQVtrkZKwaN4IBuqt5fVzsMXgLV/nf+DUWY6AZyFELPXp0 ws+yw4c1h2rpQtZggATnvns2sQFNdCzVyrM77+rx8+fVcx/S112bSZc8l4Vc3BQs 7Q1DDiUml9J4owohj8cMwQdch9cNVw== =CtNN -----END PGP SIGNATURE----- --Apple-Mail=_60B08173-4832-4859-8222-CDFF4ED622A2-- From nobody Wed Mar 31 09:05: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 403F73A2D64; Wed, 31 Mar 2021 09:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_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 YfswGDNQHIKG; Wed, 31 Mar 2021 09:05:20 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5DE3A2D2F; Wed, 31 Mar 2021 09:05:19 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 12VG0i2l021807; Wed, 31 Mar 2021 17:05:16 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=+OEHwpM8cMcgEIHuuyx/DMwLSTBVHOQ4rxzdBnmLzzM=; b=S2tXKzx6y1oUVDlDuDXzOytJumX4TpCLGnmqZfhEpy/jcJoCLgWDxjUIWJa+ljl8tCzi fYGPz3cOQM2XecpPIxdYpj2k4yV3o1zLO1qum6GQQcbSjcjo6oUXWA3jLfoegrGfo8jv 2CX7nPMA8Ix06rrh7aZhnukKM6YXIxu4SUTzGLBzMqtgOlYKtsm686ku0iB3p1D5ExVI ZWOwe6IPg5WbWW6aRlK3yJMDHofLgTwsk6IbuHPYbfNbcL3C12NFJxYD5LyJt+SYArUJ 6lB8dH0wHMCf90sP4p6MDpDxnJTOfMcsf2D48FOhT9fjYaSxctC5ie6RaB6YzbVSMdlf Vg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 37manfadjn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 31 Mar 2021 17:05:16 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 12VFniHV032162; Wed, 31 Mar 2021 12:05:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 37mb43a1f6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 31 Mar 2021 12:05:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 31 Mar 2021 12:05:14 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.012; Wed, 31 Mar 2021 12:05:14 -0400 From: "Salz, Rich" To: Eliot Lear , "rfced-future@iab.org" Thread-Topic: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th Thread-Index: AQHXJY1VqzETkX3Al06+3Fm6X/6MhKqeRCoA Date: Wed, 31 Mar 2021 16:05:14 +0000 Message-ID: <0C201DB9-10C4-47F8-A444-7E383111325A@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.47.21031401 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: multipart/alternative; boundary="_000_0C201DB910C447F8A4447E383111325Aakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-31_06:2021-03-31, 2021-03-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=917 bulkscore=0 phishscore=0 spamscore=0 malwarescore=0 adultscore=0 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103300000 definitions=main-2103310109 X-Proofpoint-ORIG-GUID: b-LpE9AM0-j8yo6OZEj6dyomM8GVdN-T X-Proofpoint-GUID: b-LpE9AM0-j8yo6OZEj6dyomM8GVdN-T X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.761 definitions=2021-03-31_08:2021-03-31, 2021-03-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 mlxscore=0 spamscore=0 bulkscore=0 priorityscore=1501 phishscore=0 impostorscore=0 lowpriorityscore=0 mlxlogscore=848 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2103300000 definitions=main-2103310109 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.18) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint1 Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 31 Mar 2021 16:05:29 -0000 --_000_0C201DB910C447F8A4447E383111325Aakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TmljZSBqb2IsIEkgc3VwcG9ydCB0aGlzIGFzIHRoZSBiYXNpcyBmb3IgbW92aW5nIGZvcndhcmQu DQo= --_000_0C201DB910C447F8A4447E383111325Aakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <8E3A483AB3886B43AA9133FF6385FC1C@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAg MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0x OjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJp Ow0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp Zjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjQ1MDE3MzIzMDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTIwMzM4NzM1Njt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxDQoJe21zby1saXN0LWlkOjExMzM2 NDQ5NjY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zMTI5MzcyMDY7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGlu O30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSIgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5OaWNlIGpvYiwg SSBzdXBwb3J0IHRoaXMgYXMgdGhlIGJhc2lzIGZvciBtb3ZpbmcgZm9yd2FyZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0C201DB910C447F8A4447E383111325Aakamaicom_-- From nobody Wed Mar 31 09:16: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 0DFDB3A2D63; Wed, 31 Mar 2021 09:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdRrNRZQDuxU; Wed, 31 Mar 2021 09:16:24 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232063A2D61; Wed, 31 Mar 2021 09:16:19 -0700 (PDT) Received: from p200300dee71fe600fcaa0550d6afc28f.dip0.t-ipconnect.de ([2003:de:e71f:e600:fcaa:550:d6af:c28f]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1lRdVw-0007PM-CZ; Wed, 31 Mar 2021 18:16:16 +0200 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: <35526D99-6D0E-4734-8FBE-BE9CC2C228C1@cisco.com> Date: Wed, 31 Mar 2021 18:16:15 +0200 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <31C79F91-2316-43D2-9A00-9D61DD7B58C7@kuehlewind.net> References: <47B92D05-8A64-4183-BDE9-A48B348007CA@kuehlewind.net> <35526D99-6D0E-4734-8FBE-BE9CC2C228C1@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1617207379;1e2bf275; X-HE-SMSGID: 1lRdVw-0007PM-CZ Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 31 Mar 2021 16:16:30 -0000 Hi Eloit, Just one quick comment/reply, or actually two, below (without intending = to move this discussion too far for now). > On 31. Mar 2021, at 14:09, Eliot Lear = wrote: >=20 > [resend] >=20 > Thanks, Mirja. Yes, I suspect that there will be a lot of discussion = on the points you mentioned as we amend the base text. Just to explain = the logic of each of these: >=20 >> On 31 Mar 2021, at 11:02, Mirja Kuehlewind = wrote: >>=20 >> Hi Eliot, hi all, >>=20 >> Thanks for putting this together. I think this is a good starting = point for a document. There are a couple of topics that didn=E2=80=99t = get a lot of discussion yet and probably will need some more. E.g. I = would consider the follow three points in that category: >>=20 >> - selection of the wg chairs >> - ISOC in the appeal chain (if we all agree that we want that, we = really should contact the BoT early on) >=20 >=20 > These two address a point that Mike made: the IAB has an outsized = influence on the AB because two members are directly appointed (the IAB = stream representative and the ISE), and it has influence on two others = (the IRTF stream and IESG stream representatives). As a stream = manager, the IAB is conflicted. Thus it should not be involved in = process appeals when it could very easily be a party. This, I believe, = was Brian=E2=80=99s Carpenters original logic. We similarly attempted = to balance power in the chairs, recognizing that the ISOC BoT would = probably not be in a good position to pick them. It=E2=80=99s very often the case for appeals to the IESG (if an appeal = happen) that one of the ADs is part of the action that the appealed. = Usually that=E2=80=99s not a problem as that AD of course recuses from = any discussion of that appeal. If the appeal is against a decision of = the AB (it could also be about a wg decision), the IAB stream manager = and IRTF chair should recuse as well. I=E2=80=99m less concerned about = the IAB picking the IRTF chair and ISE because usually these positions = are rather long term (so it=E2=80=99s not the same IAB) and there is not = influence by the IAB on these two people after the selection. Regarding ISOC, I=E2=80=99m not sure how the BoT would feel about being = kind of the first contact for an appeal (rather than something like a = last resort as they are today). So what I was saying is if thee group = wants that, we should urgently talk to them. But it feels to me that we = first need to discuss a bit more to be sure what we want. Mirja =20 >=20 > Feel free to propose alternatives as we enter the next phase of this = process. >=20 >=20 >> - Creation of the search committee >=20 > That was part and parcel of the proposal for oversight, which we = thought had to be married to hiring. Again, feel free to propose = alternatives. >=20 > Eliot > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Mar 31 15:24: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 228FB3A3976 for ; Wed, 31 Mar 2021 15:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.119 X-Spam-Level: X-Spam-Status: No, score=-2.119 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=BHprvBl+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QczQ7ZI/ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbzKilIOVniq for ; Wed, 31 Mar 2021 15:24:08 -0700 (PDT) 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 6B4513A39B3 for ; Wed, 31 Mar 2021 15:24:03 -0700 (PDT) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 400EB206F; Wed, 31 Mar 2021 18:24:02 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 31 Mar 2021 18:24:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=l zcmCYQxxb1kthdJn/O6AIer82uuyWEcFti2Lom7KU4=; b=BHprvBl+qPtr2x27F qwnbrJ3EpqUn9QimJcSpri/B5mTRJwVEcPJBmBouS3rSVkTbW+fcODLrRGcKukgq 1uAEzNv3FoT6qoQRQmWcNwWzsAOkk7jODM3MDL5DF1rc+2WdEYzR/VxsWZnd3J1s 8waR03JVzhmqNC7TK1LTBbM3qq2wLeA3fO8d0bfQXZz0kr85ZxRz8KwUJK2QLDIB Dnrt66wTuSeGOv8yrwB6jL72b2IJyZJ+6DzCp+hWLJr9dkrUF7FJzDKp+an2bHYl OiYUYKhgYoOf6DLAD5W4ORFHJPy607R2s04jsI0wqhSIlx7bVnlJaxa0FfEKI1v+ 40gsw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=lzcmCYQxxb1kthdJn/O6AIer82uuyWEcFti2Lom7K U4=; b=QczQ7ZI/VFesBhMb10uYbA1rvlZ/ryI6I8neDDVH/AHzu3PQNEopMYByM 6bMfjWJzJ38B9yqOODL8/5ytMOr6ohc3vmBiBpmLs+7AVerqxxy0RUpULNDRrVmm dJoUsMhnMzCkJYQs7GtRZDHc5pRujoPK9N7BVYHXyhyUAEZEzCUdwvz6MVfn7g62 kg5nEPvIkA8hMh8UIiegxr50uZrD6yrU/HQS9ILXco5hDovJrystRfpAWzkgTK0n Eu48LnkInhUaL6gDrjIrQwlEPc0kQRbUVKw6Ob6EfoTSK4UOgsjhG2rzx0Jg7cqi J6YSFRRKVbQZHOEAPgtSQVNpuI6Bg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrudeifedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpefgudfhvdelffegudeiudehteetfefgiedtjeefjeefudetudffhedvieelvddv ffenucffohhmrghinhepghhithhhuhgsrdgtohhmpdhirggsrdhorhhgpdhmnhhothdrnh gvthenucfkphepudduledrudejrdduheekrddvhedunecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvth X-ME-Proxy: Received: from [192.168.7.30] (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id 8B0F824005E; Wed, 31 Mar 2021 18:23:59 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.60.0.2.21\)) From: Mark Nottingham In-Reply-To: Date: Thu, 1 Apr 2021 09:23:57 +1100 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <31A9EA92-2EE3-45BB-9196-F339F41DAC67@mnot.net> References: To: Eliot Lear X-Mailer: Apple Mail (2.3654.60.0.2.21) Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 31 Mar 2021 22:24:14 -0000 Hi Eliot, I'm fine with this text, provided that we can file issues against this = text and expect to have them seriously considered by the group. In other = words, I'm interpreting your question here as what we'd consider a Call = for Adoption in the WGs I participate in regularly -- this text is a = good starting point, but isn't sacrosanct, and doesn't have any higher = bar for changes than usual. If your intent differs from that (e.g., we need some sort of consensus = to even consider an issue), please say so. Cheers, > On 31 Mar 2021, at 4:51 am, Eliot Lear = wrote: >=20 > The chairs appreciate comments received, and we now believe that it is = ok to start a consensus call on the chairs=E2=80=99 proposal on both = the draft evolution process and the RSE hire and accountability text, = taken as a whole. If you have already indicated your support for the = proposal, the chairs will note this. We would like to hear from all = interested participants. If you would like to indicate either support = or objection, please feel free to do so by Tuesday, April 13th. >=20 > If there is rough consensus, this text will be included in the = editor=E2=80=99s draft. It can be further amended with rough consensus, = and the chairs expect there to be some of that. Again, we see this as = compromise text, and so we are hoping that this is a good enough = starting point for further modifications. >=20 > As a reminder, we have an interim meeting scheduled for next Tuesday, = April 6th, 2021, at 20:00 GMT, when of course this proposal will be on = the agenda for people to discuss. More about that agenda in the next = day or two. >=20 > The text can be found on GitHub in two parts at the following URLs: >=20 > = https://github.com/intarchboard/program-rfced-future/blob/master/draft-evo= lution-process.md > = https://github.com/intarchboard/program-rfced-future/blob/master/rse-hire-= and-accountability.md >=20 > And it is below for your consideration as well. >=20 > Brian and Eliot >=20 >=20 > DRAFT RFC Evolution Process >=20 >=20 > Scope >=20 > This procedure is applicable to the evolution processes relating to = the management and evolution of the RFC series, including format, = tooling, publication, dissemination, and overall management of the = series. >=20 >=20 > Structure >=20 > The RFC evolution process is governed as follows: >=20 > =E2=80=A2 The RFC Working Group, whose job it is to develop = proposed changes, and establish community consensus of those changes. > =E2=80=A2 The The RFC Approval Board, whose job it is to provide = final review of proposals. > Each group is described below. >=20 >=20 > The RFC Working Group (RFCWG) >=20 > All RFCWG meetings are open to any participant, subject to = intellectual property policies which must be consistent to those of the = IETF [Note Well]. At body's initial formation, all discussions are to = take place on open mailing lists, and anyone is welcome to comment / = discuss. The RFCWG may decide by rough consensus to use additional forms = of communication (for example, Github as specified in [RFC8874]) that = are consistent with [RFC2418]. The group will conform itself to an = anti-harassment policy consistent with [RFC7154,RFC7776]. >=20 > IETF chair and the Independent Submissions Editor shall each appoint = and oversee a co-chair of the RFCWG. >=20 >=20 > The RFC Approval Board (RFCAB) >=20 > The RFC Approval Board consists of representatives from each RFC = stream (at the time of this writing, the IAB, the IETF, the IRTF, and = the Indepenent Series), as well as the RS[EA]. The sole function of this = group is to review draft proposals approvedby the RFCWG. The RFCAB may = choose its chair as it sees fit. The group is primarily expected to = operate via email and through any necessary tooling. A record of all = proceedings (no matter the form) will be kept. >=20 >=20 > Update Process >=20 > The following procedure is used to update the RFC process: >=20 > =E2=80=A2 Someone writes a draft proposal in the form of an = Internet-Draft. >=20 > =E2=80=A2 If there is sufficient interest in the proposal, RFCWG = will adopt the proposal as a working draft, much the same way a working = group of the IETF would. >=20 > =E2=80=A2 The RFCWG will then further develop the proposal. All = members of the RFCAB are expected to participate in discussion relating = to all proposals. >=20 > =E2=80=A2 At some point, if the chairs believe there may be = rough consensus exists for the proposal to advance, they will issue a = working group last call. >=20 > =E2=80=A2 After a suitable period of time, the chairs will = determine whether rough consensus for the proposal exists. If comments = have been received and substantial changes have been made, it is = expected that additional last calls may be made. >=20 > =E2=80=A2 Once working group consensus is established, a = community call for comments will be issued. Should substantial comments = be received, the working group will again consider those comments and = make revisions as they see fit. At this same time, the RFCAB will = consider the proposal. >=20 > =E2=80=A2 Should substantial changes be made, additional = community calls for comment should be issued, and again comments = considered. >=20 > =E2=80=A2 Once all comments have been been addressed, the = working group chairs will transmit the latest proposal to the RFCAB. >=20 > =E2=80=A2 Within a reasonable period of time, the RFCAB will = then poll on the proposal. Positions may be as follows: >=20 > =E2=80=A2 "YES": the proposal should be approved > =E2=80=A2 "CONCERN" : the proposal raises substantial = concerns that must be addressed. > =E2=80=A2 "RECUSE" : the person holding the position has = a conflict of interest. > Anyone holding a "CONCERN" position MUST explain their concern to the = community in detail. The explanation may or may not be actionable. >=20 > A CONCERN may be made for two reasons: >=20 > =E2=80=A2 The proposal represents a serious problem for = the group a particular member represents. > =E2=80=A2 The member believes that the proposal would = cause serious harm to the overall series, including harm to the long = term health and viability of the series. > No CONCERN should ever come as a surprise to the RFCWG. >=20 > =E2=80=A2 If a CONCERN exists, discussion will take place within = the RFCWG. Again, all RFCAB members MUST participate. >=20 > =E2=80=A2 If all CONCERN positions are addressed, then the = proposal is approved. Again, if substantial changes have been made, an = additional call for community input should be made. >=20 > =E2=80=A2 If, after a suitable period of time, any CONCERN = positions remain, a formal vote of the RFCAB is taken. If a majority of = RFCAB members vote to approve, the proposal is approved. Otherwise, it = is returned to the RFCWG. In the case of a tie, the proposal is = approved. >=20 > =E2=80=A2 When a proposal is approved, a notification is sent to = the community, and it is published as an RFC. >=20 >=20 > The roles of the LLC Board and ED >=20 > LLC Board members, staff, and the Executive Director, are invited to = participate as community members in the RFCWG to the extent permitted by = any relevant LLC policies. >=20 >=20 > Appeals >=20 > Appeals of RFCAB decisions may only be made based on process failures, = and not on the substance of a proposal. These appeals SHALL be made to = the ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY = decide only whether a process failure occurred, and what if any = corrective action should take place. >=20 >=20 > Discussion >=20 > The intent of this policy is to provide an open forum by which = policies and procedures of the RFC series are evolved. The general = expectation is that all interested parties will participate in the = RFCWG, and that only under extreme circumstances should the RFCAB = members have to hold "CONCERN" positions. To avoid that situation, WG = members are encouraged to take RFCAB concerns seriously, and RFCAB = members are encouraged to make those concerns known early, and to be = responsive to the community. In particular, people are encouraged to = respect the value of each stream, and the long term health and viability = of the RFC series. >=20 > This process is intended to be one of continuous consultation. In = particular, RFCAB members should be consulting with their constuent = groups on an ongoing basis, so that when the time comes to consider a = proposal, there should be no surprises. Appointing bodies are expected = to establish whatever processes they deem appropriate to facilitate this = goal. >=20 > DRAFT DRAFT DRAFT >=20 >=20 > RS[EA] Selection >=20 > The RS[EA] will be searched for and vetted by a committee formed by = the ED, taking into account the role definition and any detailed job = description that we further develop. The search committee may ask others = to take part in the selection process in confidence. The initial length = of service shall be for one year, but then further extensions will be = for three to five years. >=20 >=20 > RS[EA] Ongoing Performance Evaluation >=20 > Periodically, the ED will send out to the community a call for input = on the performance of the RS[EA]. The evaluation will be based on = criteria specified in the role definition. Was the RS[EA] an active = participant in all/most meetings? Did the RS[EA] provide useful advice = to the RPC and to the WG? Did the RS[EA] exercise good judgment in terms = of any role he or she would have had on the Approval Body? Was the = RS[EA] effective in advising the community on appropriate actions to = take or not take? >=20 > The ED will then review the feedback, consulting with stream manager = representatives, and then produce a recommendation to the LLC Board. The = LLC will then make a decision, taking into account that recommendation. >=20 > Whether the RS[EA] role is structured as a contractual or employee = relationship is left to the LLC and ED to determine. >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Wed Mar 31 18:43: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 107473A0CCC for ; Wed, 31 Mar 2021 18:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQt297nMx9xr for ; Wed, 31 Mar 2021 18:43:30 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F4B3A0CC4 for ; Wed, 31 Mar 2021 18:43:16 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id t18so253283pjs.3 for ; Wed, 31 Mar 2021 18:43:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=pDUjr0GXm3wCXGqKoqbOK5yUyQix5QJBkPcP3ZYSsEU=; b=AOec/sxDfP5sHFJJ4s6ppg+EIt019DiZOUnXwebfNW7/u+DlLaF4A5ETd+DlM94EOr FqMIahcYhYCk4Tu2xyNiTlbBJokKo9QCNzOEsb2mFjAgkyG7Fov4Aitjayahq0GgrVRv wLlcpFC/Bg3zPCqeAAq0vvptkj4m/KrZCucjCPIHzlYRQqH/IebZXOtEmH0VB7xGYvaY SfR+QDyEZ292Nwy3UuxRdBC+Jj1iOTq9pW8+6Fj9lOTVwBYvP/P3vuXGeLSAuAGfcFD+ ASqPqN95UcUMcHeCO5PLxAl3MJueiq7wP8JkT9axZP4R3WKUCfP+VPmFbqyPGYywFDav d09w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pDUjr0GXm3wCXGqKoqbOK5yUyQix5QJBkPcP3ZYSsEU=; b=VJ8Exno3u8zV2QWN47R32M2ubRty5ohXosvIyNOC2nCVGLrthmxWNPGutb2xZZ7oIM MZi4OPuvQXHVFd7mTka2HZ95lcnaHpPUXvzAsjJ5C/r8X+goMWUlvBnZe9W/qYxm9mmT mv+XrjRxz+PBqaDSzCpO4FQw6/RH++f2eu7nT410YxvfJZPgwlPrf8a1ywjyCRSiNzV3 VCoN2GHgvC09b3NrsfcLUtH5wJBjkvYG0o+D+KfJV1nGxZ80xl72zEZaa01sTXeiF/pC WNZoqNLrYhtj8wwtjnwGgHYzgPaPqOLB7b4bvtNPg9sijTg+iwNnx/F5Q3mOK/tC7jM7 GjEA== X-Gm-Message-State: AOAM5331CSGxFIzt8qioh6wM7KCG2rJfcbwaRcuw5CoqAbJhm0oFe3Oq CKyEFPIKTyRsovfvmgGN5uZXDDwm8zCzQg== X-Google-Smtp-Source: ABdhPJwI1svJpCbueXc/cBpsqXpFy1XydA8OFxrXLS4zFI649g+5jBSd70QuopJsYUW93ivX0CG33g== X-Received: by 2002:a17:902:a5c1:b029:e7:3ee0:a1e9 with SMTP id t1-20020a170902a5c1b02900e73ee0a1e9mr5822761plq.82.1617241393828; Wed, 31 Mar 2021 18:43:13 -0700 (PDT) Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id 38sm3558821pgk.30.2021.03.31.18.43.11 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 31 Mar 2021 18:43:13 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: <8e1ea525-7e47-cab9-ec67-058bbaaed2f1@gmail.com> Date: Thu, 1 Apr 2021 14:43:09 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Consensus Call for Chairs Proposal: Please comment by April 13th X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Apr 2021 01:43:32 -0000 Support (repeating myself, I think). As long as we are not also adopting = the draft on the RS[EA] role, which I feel needs more work before adoptio= n. Regards Brian Carpenter On 31-Mar-21 06:51, Eliot Lear wrote: > The chairs appreciate comments received, and we now believe that it is = ok to start a =C2=A0consensus call on the chairs=E2=80=99 proposal on bot= h the draft evolution process and the RSE hire and accountability text, t= aken as a whole. =C2=A0If you have already indicated your support for the= proposal, the chairs will note this. =C2=A0*We would like to hear from a= ll interested participants*. =C2=A0If you would like to indicate either s= upport or objection, please feel free to do so by Tuesday, April 13th. >=20 > If there is rough consensus, this text will be included in the editor=E2= =80=99s draft. =C2=A0It can be further amended with rough consensus, and = the chairs expect there to be some of that. =C2=A0Again, we see this as c= ompromise text, and so we are hoping that this is a good enough starting = point for further modifications. >=20 > As a reminder, we have an interim meeting scheduled for next Tuesday, A= pril 6th, 2021, at 20:00 GMT, when of course this proposal will be on the= agenda for people to discuss. =C2=A0More about that agenda in the next d= ay or two. >=20 > The text can be found on GitHub in two parts at the following URLs: >=20 > https://github.com/intarchboard/program-rfced-future/blob/master/draft-= evolution-process.md > https://github.com/intarchboard/program-rfced-future/blob/master/rse-hi= re-and-accountability.md >=20 > And it is below for your consideration as well. >=20 > Brian and Eliot >=20 >=20 > DRAFT RFC Evolution Process >=20 >=20 > >=20 >=20 > Scope >=20 > This procedure is applicable to the evolution processes relating to the= management and evolution of the RFC series, including format, tooling, p= ublication, dissemination, and overall management of the series. >=20 >=20 > >=20 >=20 > Structure >=20 > The RFC evolution process is governed as follows: >=20 > * The RFC Working Group, whose job it is to develop proposed changes,= and establish community consensus of those changes. > * The The RFC Approval Board, whose job it is to provide final review= of proposals. >=20 > Each group is described below. >=20 >=20 > >=20 >=20 > The RFC Working Group (RFCWG) >=20 > All RFCWG meetings are open to any participant, subject to intellectual= property policies which must be consistent to those of the IETF [Note We= ll]. At body's initial formation, all discussions are to take place on op= en mailing lists, and anyone is welcome to comment / discuss. The RFCWG m= ay decide by rough consensus to use additional forms of communication (fo= r example, Github as specified in [RFC8874]) that are consistent with [RF= C2418]. The group will conform itself to an anti-harassment policy consis= tent with [RFC7154,RFC7776]. >=20 > IETF chair and the Independent Submissions Editor shall each appoint an= d oversee a co-chair of the RFCWG. >=20 >=20 > >=20 >=20 > The RFC Approval Board (RFCAB) >=20 > The RFC Approval Board consists of representatives from each RFC stream= (at the time of this writing, the IAB, the IETF, the IRTF, and the Indep= enent Series), as well as the RS[EA]. The sole function of this group is = to review draft proposals approvedby the RFCWG. The RFCAB may choose its = chair as it sees fit. The group is primarily expected to operate via emai= l and through any necessary tooling. A record of all proceedings (no matt= er the form) will be kept. >=20 >=20 > >=20 >=20 > Update Process >=20 > The following procedure is used to update the RFC process: >=20 > 1. >=20 > Someone writes a draft proposal in the form of an Internet-Draft. >=20 > 2. >=20 > If there is sufficient interest in the proposal, RFCWG will adopt t= he proposal as a working draft, much the same way a working group of the = IETF would. >=20 > 3. >=20 > The RFCWG will then further develop the proposal. All members of th= e RFCAB are expected to participate in discussion relating to all proposa= ls. >=20 > 4. >=20 > At some point, if the chairs believe there may be rough consensus e= xists for the proposal to advance, they will issue a working group last c= all. >=20 > 5. >=20 > After a suitable period of time, the chairs will determine whether = rough consensus for the proposal exists.=C2=A0 If comments have been rece= ived and substantial changes have been made, it is expected that addition= al last calls may be made. >=20 > 6. >=20 > Once working group consensus is established, a community call for c= omments will be issued. Should substantial comments be received, the work= ing group will again consider those comments and make revisions as they s= ee fit. At this same time, the RFCAB will consider the proposal. >=20 > 7. >=20 > Should substantial changes be made, additional community calls for = comment should be issued, and again comments considered. >=20 > 8. >=20 > Once all comments have been been addressed, the working group chair= s will transmit the latest proposal to the RFCAB. >=20 > 9. >=20 > Within a reasonable period of time, the RFCAB will then poll on the= proposal. Positions may be as follows: >=20 > * "YES": the proposal should be approved > * "CONCERN" : the proposal raises substantial concerns that must = be addressed. > * "RECUSE" : the person holding the position has a conflict of in= terest. >=20 > Anyone holding a "CONCERN" position MUST explain their concern to t= he community in detail. The explanation may or may not be actionable. >=20 > A CONCERN may be made for two reasons: >=20 > * The proposal represents a serious problem for the group a parti= cular member represents. > * The member believes that the proposal would cause serious harm = to the overall series, including harm to the long term health and viabili= ty of the series. >=20 > No CONCERN should ever come as a surprise to the RFCWG. >=20 > 10. >=20 > If a CONCERN exists, discussion will take place within the RFCWG. A= gain, all RFCAB members MUST participate. >=20 > 11. >=20 > If all CONCERN positions are addressed, then the proposal is approv= ed. Again, if substantial changes have been made, an additional call for = community input should be made. >=20 > 12. >=20 > If, after a suitable period of time, any CONCERN positions remain, = a formal vote of the RFCAB is taken. If a majority of RFCAB members vote = to approve, the proposal is approved. Otherwise, it is returned to the RF= CWG. In the case of a tie, the proposal is approved. >=20 > 13. >=20 > When a proposal is approved, a notification is sent to the communit= y, and it is published as an RFC. >=20 >=20 > >=20 >=20 > The roles of the LLC Board and ED >=20 > LLC Board members, staff, and the Executive Director, are invited to pa= rticipate as community members in the RFCWG to the extent permitted by an= y relevant LLC policies. >=20 >=20 > >=20 >=20 > Appeals >=20 > Appeals of RFCAB decisions may only be made based on process failures, = and not on the substance of a proposal. These appeals SHALL be made to th= e ISOC BoT within thirty days of the RFCAB decision. The ISOC BoT MAY dec= ide only whether a process failure occurred, and what if any corrective a= ction should take place. >=20 >=20 > >=20 >=20 > Discussion >=20 > The intent of this policy is to provide an open forum by which policies= and procedures of the RFC series are evolved. The general expectation is= that all interested parties will participate in the RFCWG, and that only= under extreme circumstances should the RFCAB members have to hold "CONCE= RN" positions. To avoid that situation, WG members are encouraged to take= RFCAB concerns seriously, and RFCAB members are encouraged to make those= concerns known early, and to be responsive to the community. In particul= ar, people are encouraged to respect the value of each stream, and the lo= ng term health and viability of the RFC series. >=20 > This process is intended to be one of continuous consultation. In parti= cular, RFCAB members should be consulting with their constuent groups on = an ongoing basis, so that when the time comes to consider a proposal, the= re should be no surprises. Appointing bodies are expected to establish wh= atever processes they deem appropriate to facilitate this goal. >=20 >=20 > DRAFT DRAFT DRAFT >=20 >=20 > >=20 >=20 > RS[EA] Selection >=20 > The RS[EA] will be searched for and vetted by a committee formed by the= ED, taking into account the=C2=A0role definition =C2=A0and = any detailed job description that we further develop. The search committe= e may ask others to take part in the selection process in confidence. The= initial length of service shall be for one year, but then further extens= ions will be for three to five years. >=20 >=20 > >=20 >=20 > RS[EA] Ongoing Performance Evaluation >=20 > Periodically, the ED will send out to the community a call for input on= the performance of the RS[EA]. The evaluation will be based on criteria = specified in the role definition. Was the RS[EA] an active participant in= all/most meetings? Did the RS[EA] provide useful advice to the RPC and t= o the WG? Did the RS[EA] exercise good judgment in terms of any role he o= r she would have had on the Approval Body? Was the RS[EA] effective in ad= vising the community on appropriate actions to take or not take? >=20 > The ED will then review the feedback, consulting with stream manager re= presentatives, and then produce a recommendation to the LLC Board. The LL= C will then make a decision, taking into account that recommendation. >=20 > Whether the RS[EA] role is structured as a contractual or employee rela= tionship is left to the LLC and ED to determine. >=20 >=20