From nobody Mon Jan 4 08:55:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C96DC3A0E80 for ; Mon, 4 Jan 2021 08:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.071 X-Spam-Level: X-Spam-Status: No, score=-8.071 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVJgt0q68kgh for ; Mon, 4 Jan 2021 08:55:53 -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 326FC3A0E7E for ; Mon, 4 Jan 2021 08:55:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4246; q=dns/txt; s=iport; t=1609779353; x=1610988953; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=m3PS+azFxdRDQeH3Tu2WhQEWCEi7QjMNqHk42VdVpZw=; b=Y3NaIkKnpHOOfyoFIOuBe7va0O70PcdlGNhjqbpz1CKVl3aSaxvopwMR kOPqYUNVbB+rmAu9VwXfGhUSnHRUEyu9qzxiE7p0bVRiZgItYXYkf5CsR 67xON3Ko+YNNyIwwtNUWbOyYovnP7pD7Y88vQIZkHtsputywvJQZra/tJ o=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DHAwBOSPNfjBbLJq1iHgEBCxIMhgcBIBKEbYkEiCsDl?= =?us-ascii?q?BuGNIFoBAcBAQEKAwEBLwQBAYRKAoFwJjgTAgMBAQEDAgMBAQEBBQEBAQIBB?= =?us-ascii?q?gQUAQEBAYZGhXQBBAEjSwsFCw8+AgJXBoM5AYJmIK5adoEyhViEVxCBOIFTi?= =?us-ascii?q?1ZBggCBOByCIXOEAAkBEgEHgzI0giwEgVQBb4FXAm6UA4kznCiDAIMngTeWe?= =?us-ascii?q?gMfkwaPSo5MowSDbgIEBgUCFoFtIWlwMxoIGxVlAYI/PRIZDY47jjBAA2cCB?= =?us-ascii?q?gEJAQEDCY4aAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,474,1599523200"; d="asc'?scan'208,217";a="32324531" 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 Jan 2021 16:55:48 +0000 Received: from [10.61.232.106] ([10.61.232.106]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 104Gtk13004642 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Jan 2021 16:55:47 GMT From: Eliot Lear Message-Id: <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6E67464E-94A6-4227-A2F7-F4C27EC6D0B2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 4 Jan 2021 17:55:46 +0100 In-Reply-To: <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> Cc: Brian E Carpenter , rfced-future@iab.org To: "Joel M. Halpern" References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <056684f2-ab2c-5b85-4dfd-bada78e1e528@joelhalpern.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.232.106, [10.61.232.106] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Jan 2021 16:55:55 -0000 --Apple-Mail=_6E67464E-94A6-4227-A2F7-F4C27EC6D0B2 Content-Type: multipart/alternative; boundary="Apple-Mail=_B565731E-2918-4A05-877C-708741D0DB4C" --Apple-Mail=_B565731E-2918-4A05-877C-708741D0DB4C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Coming back to this, I believe we are now up to the following text: > All strategic body meetings are open to the public. At body's initial = formation, all discussions are to take place on open mailing lists, and = anyone is welcome to comment / discuss. The strategic body may decide = by rough consensus to use additional forms of communication that are = consistent with [RFC2418]. The purpose of the change is to accommodate the discussion between Joel = and EKR, and to address Brian=E2=80=99s point. I have removed = references to =E2=80=9Cissues=E2=80=9D because that made it sound like = each issue must be initiated in email (EKR=E2=80=99s point, and my poor = wording earlier). Rather, we will leave it til later for the group to = decide best how to operate, so long as they remain within the confines = of RFC 2418 (Brian=E2=80=99s point). I am hoping we can move off of this issue, but given the discussion, = we=E2=80=99ll do another consensus call after people have had an = opportunity to comment on the above. Eliot --Apple-Mail=_B565731E-2918-4A05-877C-708741D0DB4C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Coming back to this, I believe we are now up to the following = text:

All = strategic body meetings are open to the public.  At = body's initial formation, all discussions are = to take place on open mailing lists, and anyone is welcome to = comment / discuss.  The strategic body may = decide by rough consensus to use additional = forms of communication that are consistent with = [RFC2418].

The purpose of the change is to accommodate the discussion = between Joel and EKR, and to address Brian=E2=80=99s point.  I have = removed references to =E2=80=9Cissues=E2=80=9D because that made it = sound like each issue must be initiated in email (EKR=E2=80=99s point, = and my poor wording earlier).  Rather, we will leave it til later = for the group to decide best how to operate, so long as they remain = within the confines of RFC 2418 (Brian=E2=80=99s point).

I am hoping we can move = off of this issue, but given the discussion, we=E2=80=99ll do another = consensus call after people have had an opportunity to comment on the = above.

Eliot
= --Apple-Mail=_B565731E-2918-4A05-877C-708741D0DB4C-- --Apple-Mail=_6E67464E-94A6-4227-A2F7-F4C27EC6D0B2 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/zSJIACgkQh7ZrRtnS ejO9nwf/V4HHXfEnlEBXnhabaTbNq4cYeTlMQQ17uorl757/lp7+AoAq7V1SPLCu O/J680yrN2bU0vPP+Cbm2yyCKMCgmDmojI3mL0yyo9I6iHAwjUbT446OXasVB0E5 aeIEUZukGDCFWPTgdwdty8xGGMi0Y8m81DQuq3PAV3r7y1BriHXqKwyQ9Okf/062 wPeygdkhP+DeNoPxfP/W/kEUaLCUut0xADBgXP3ysbwzjNffcMreTe0NUEWIucjE knv8enIE26imbK1Du9IwqRio2+mXLAqZrygfp0ZmQZ3zBfqW/WK4KqVPxHPGXJGm kfS3rJqVFWOWsd8V0liJm2zByn+GEw== =Gt6c -----END PGP SIGNATURE----- --Apple-Mail=_6E67464E-94A6-4227-A2F7-F4C27EC6D0B2-- From nobody Mon Jan 4 09:08:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 386553A0EA0 for ; Mon, 4 Jan 2021 09:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5BU-Zw3uSwU for ; Mon, 4 Jan 2021 09:08:40 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 183BD3A0E9F for ; Mon, 4 Jan 2021 09:08:40 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id y19so65846320lfa.13 for ; Mon, 04 Jan 2021 09:08:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9PEG1Qt2v1Z3UQRCH51jLbGPTKCzkFTKCLYNNbUoDaQ=; b=MeNV5ztqnujzy4FDNJm4VWoeyhm+ZMqqzsEq010kNfTyxIGFAkQTtfgwjg5/s9w8kY 2qzQm6g0cCSy4N9kFYU+jb8RannhO0aw1C3hLmfFKGDcrWBEp38DojMkE6TPxcZLK6Ap L4JPR27zIRATeW2Xd2T0ZbsRp0bD8mrvALYKyquwHniR53mBZz9U035T1tl6fAcQczYf 0tgWYPMC5ZToYiQhvOmCXQjjh/pQcTvdr1DygAUgS9A48M9hr8+UVeXTRTMZyQt3a6Z2 OpwOl0223avPeWnrnP1DZkJEAmgziLkHQBBNFVLFNoG29/UR91JNK9tdKD7qU3mpzZks I+jA== 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=9PEG1Qt2v1Z3UQRCH51jLbGPTKCzkFTKCLYNNbUoDaQ=; b=c/Cm+BrCIZ0xc+F+MKhV4bE4Pc4PZPkw1qU68VLxskSxD4IT9RgWdeFokFYbzOv0jp s+BqqBbYCbcDq67t3BqlY0Hwiy7est4OM4sGWCEeOj7lOQb0VCEsybRuPBoLgApKZrms jsEOQ7K68AZdXzMJrD2B4RfFQAv+qfpFAQIQhO69aN3Os2xwbC354KhIlGDcnUEkggDZ UfLtaK6CB/oEbRewvY2wzO4vV4wZweHP+d4HfaM4r328o6jWP9z2aXL6a1CUTqE1eHIH ZGMLAP15OZVkl5ulDpfX6y6D8V/hTckurmgsOklu/wSrHIbnaA2cvveOQu4rQ4DIIeUF 88FQ== X-Gm-Message-State: AOAM533hbJVtI0/kS+IgN5bSKYgdJzs5edpK2iPWBcGcx74WFWKRiNlh TYFh549uIkO+FoI0bvjtVroWNFgdz3KXY4Cb6JM2vpuArPrT1A== X-Google-Smtp-Source: ABdhPJxytjNyd/aOxPkpUu5BaiM+5RhpYZbgtbueiPIar+0485aJphfI5aGDxK6IVYDMbLS1wlEuX6XHdI2nR/zXLoo= X-Received: by 2002:a2e:9f53:: with SMTP id v19mr34541741ljk.109.1609780118139; Mon, 04 Jan 2021 09:08:38 -0800 (PST) MIME-Version: 1.0 References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <056684f2-ab2c-5b85-4dfd-bada78e1e528@joelhalpern.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> In-Reply-To: <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> From: Eric Rescorla Date: Mon, 4 Jan 2021 09:08:02 -0800 Message-ID: To: Eliot Lear Cc: "Joel M. Halpern" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000001bc66a05b8162437" Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Jan 2021 17:08:43 -0000 --0000000000001bc66a05b8162437 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 4, 2021 at 8:56 AM Eliot Lear wrote: > Coming back to this, I believe we are now up to the following text: > > All strategic body meetings are open to the public. *At body's initial > formation,* all discussions *are to* take place on open mailing lists, > and anyone is welcome to comment / discuss. The strategic body may > decide *by rough consensus* to use additional forms of communication that > are consistent with [RFC2418]. > > > The purpose of the change is to accommodate the discussion between Joel > and EKR, and to address Brian=E2=80=99s point. I have removed references= to > =E2=80=9Cissues=E2=80=9D because that made it sound like each issue must = be initiated in > email (EKR=E2=80=99s point, and my poor wording earlier). Rather, we wil= l leave it > til later for the group to decide best how to operate, so long as they > remain within the confines of RFC 2418 (Brian=E2=80=99s point). > I'd like to see a citation to 8874 here to make clear that we're not saying that that's not permitted. For instance, at the end "such as those described in RFC 8874" -Ekr > I am hoping we can move off of this issue, but given the discussion, we= =E2=80=99ll > do another consensus call after people have had an opportunity to comment > on the above. > > > Eliot > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000001bc66a05b8162437 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 4, 2021 at 8:56 AM Eliot = Lear <lear=3D40cisco.com@d= marc.ietf.org> wrote:
Coming back to this,= I believe we are now up to the following text:

All strategic body meetings are open to the pu= blic. =C2=A0At body's initial formation,=C2=A0all discussions=C2= =A0are to take place on open mailing lists, and anyone is welcome to= comment / discuss. =C2=A0The=C2=A0strategic body may decide=C2=A0by rough consensus= =C2=A0to use additional forms of communication that are consistent with [RF= C2418].
=

The purpose= of the change is to accommodate the discussion between Joel and EKR, and t= o address Brian=E2=80=99s point.=C2=A0 I have removed references to =E2=80= =9Cissues=E2=80=9D because that made it sound like each issue must be initi= ated in email (EKR=E2=80=99s point, and my poor wording earlier).=C2=A0 Rat= her, we will leave it til later for the group to decide best how to operate= , so long as they remain within the confines of RFC 2418 (Brian=E2=80=99s p= oint).

I'd like to se= e a citation to 8874 here to make clear that we're not saying that that= 's not permitted.

For instance, at the end &qu= ot;such as those described in RFC 8874"

-Ekr<= /div>



I = am hoping we can move off of this issue, but given the discussion, we=E2=80= =99ll do another consensus call after people have had an opportunity to com= ment on the above.
=C2=A0
--0000000000001bc66a05b8162437-- From nobody Mon Jan 4 09:54: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 52AD73A0ED2 for ; Mon, 4 Jan 2021 09:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.772 X-Spam-Level: X-Spam-Status: No, score=-8.772 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.373, 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, 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 P2xUe-V76e7f for ; Mon, 4 Jan 2021 09:54:23 -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 801E43A0ED1 for ; Mon, 4 Jan 2021 09:54:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6032; q=dns/txt; s=iport; t=1609782863; x=1610992463; h=from:mime-version:subject:message-id:date:cc:to; bh=j+Ao/AM2wo335aSVdNHy7rExw9YMvH0En70b5HcHGvc=; b=lOlfWuWlg/8A0YCl50ME5imXAA81b2OvlDowul6w1H2MVw011PVQrmKJ Qeg6ZYEw745PpBVXay7Kdh3aV7wnGAKqKyP9KVGZSAegM8x/RJ+KL4sdg UH/zFUvaG2TIYLjF9qRXJjvU6DqDjyhiWIPU4CHYboTJqF+V5WOg/Qg8a A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DWAwDuVfNfjBbLJq1ihXlXASASLoQ/iQSIBiWUHoY0g?= =?us-ascii?q?WgEBwEBAQoDAQEnCAQBAYRKgXImOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBA?= =?us-ascii?q?QEBhjoMhh1WHz4ChBgBgwYPrkV2gTKEPwEDAgELAkABhRsKBoE4gVOMF4IAg?= =?us-ascii?q?TgMEIVxAgEBAYEig1I0giwEgyJJDgIgEDYLFHoRi0SQcpwogwCDJ4E3hEyMH?= =?us-ascii?q?4YPAx+DKYorhTKPSp8bkjWDbgIEBgUCFoFtITmBIDMaCBsVOyoBgj4TKxIZD?= =?us-ascii?q?Y4tDgmDToUUhUVAAzACNQIGAQkBAQMJjTpgAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,474,1599523200"; d="asc'?scan'208,217";a="32386746" 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; 04 Jan 2021 17:54:19 +0000 Received: from [10.61.232.106] ([10.61.232.106]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 104HsI6l023108 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 4 Jan 2021 17:54:19 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_B8A9D508-E108-40D5-8BBB-0D40035510CE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: Date: Mon, 4 Jan 2021 18:54:17 +0100 Cc: Brian Rosen To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Outbound-SMTP-Client: 10.61.232.106, [10.61.232.106] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Happy New Year and Status X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Jan 2021 17:54:25 -0000 --Apple-Mail=_B8A9D508-E108-40D5-8BBB-0D40035510CE Content-Type: multipart/alternative; boundary="Apple-Mail=_E848EB28-0DB3-46FB-AB94-C471CF06F62B" --Apple-Mail=_E848EB28-0DB3-46FB-AB94-C471CF06F62B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear colleagues, Happy New Year. Thanks to all who attended our last f2f and who have = been participating on list. Brian has uploaded minutes from the = previous meeting to the data tracker, which you can find here = . We have a few ongoing activities. We want to highlight three: We are closing in on what the chairs hope will be rough consensus Issue = 13 on openness of the strategic body. We are hoping that this will not = take meeting time. We have had a very productive discussion about a model in which there is = a working group and a review body. The chairs think this is probably = the most productive use of our next face-to-face time, in terms of = understanding the composition and responsibilities of each. I am working on developing a bit of a spreadsheet for the existing = responsibilities of the RSE, so that we can have an easy comparison of = proposals, and also so that we don=E2=80=99t miss any responsibilities. = This is taken RFC8728 Section 2. I=E2=80=99ll try to have that out in = the next few days. You can get a sneak peek of this here = . It=E2=80=99s pretty rudimentary. Finally, we want to bring two logistical points to your attention: We will have our next interim on the 12th of January at 20:00 GMT. = Please see the message from the secretariat to this list for logistics. We would like to shortly start a doodle for the February meeting. Our = impression at this point is that the 20:00 GMT time is not too painful = for a good number of people. If you think we need to vary the time, = would you kindly just reply to Brian and me directly? Thanks, Eliot & Brian --Apple-Mail=_E848EB28-0DB3-46FB-AB94-C471CF06F62B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear = colleagues,

Happy = New Year. Thanks to all who attended our last f2f and who have been = participating on list.  Brian has uploaded minutes from the = previous meeting to the data tracker, which you can find here.

We have a few ongoing activities.  We want to highlight = three:

  • We are closing in on what the = chairs hope will be rough consensus Issue 13 on openness of the = strategic body.  We are hoping that this will not take meeting = time.
  • We have had a very productive discussion about = a model in which there is a working group and a review body.  The = chairs think this is probably the most productive use of our next = face-to-face time, in terms of understanding the composition and = responsibilities of each.
  • I am working on developing = a bit of a spreadsheet for the existing responsibilities of the RSE, so = that we can have an easy comparison of proposals, and also so that we = don=E2=80=99t miss any responsibilities.  This is taken RFC8728 = Section 2.  I=E2=80=99ll try to have that out in the next few days. =  You can get a sneak peek of this here.  It=E2=80=99s = pretty rudimentary.

Finally, we want to bring two = logistical points to your attention:

  • We will have our next interim on the 12th of January at 20:00 = GMT.  Please see the message from the secretariat to this list for = logistics.
  • We would like to shortly start a doodle = for the February meeting.  Our impression at this point is that the = 20:00 GMT time is not too painful for a good number of people. =  If you think we need to vary the time, would you kindly just reply = to Brian and me directly? 

Thanks,

Eliot & Brian
= --Apple-Mail=_E848EB28-0DB3-46FB-AB94-C471CF06F62B-- --Apple-Mail=_B8A9D508-E108-40D5-8BBB-0D40035510CE 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/zVkoACgkQh7ZrRtnS ejPCtgf8DMDuQbCRaaAVwoMODT4aRyuXShuYqcVgEEB+P5glZujYV397MTGrGEjI 4464euiBeFc6VUw0jZQ6VT3+7hpfAEJnFi3wh0CIi+/JklNNob381sLXw82BoIdA 1WKRXvGNO+/yrtjWhGOkRcfmDgngzsOlgUAAkgAHCmJN86wLEnEhYq/5J8NyadED HciFPGs61UhZPiVsQVuoLCTTOdyC7F/fLP7n8HJuL4GgmbYxp/1V6H/S8UdrL8QZ rrdGFl31tgfCZrEMWmfs7jujiIJ49j+tfd8moW+n4NMgtX0l3pjz7tQtklGLMSC7 aAftEEK5g+nxD79tf92I7YlfRuUJZw== =hX7h -----END PGP SIGNATURE----- --Apple-Mail=_B8A9D508-E108-40D5-8BBB-0D40035510CE-- From nobody Mon Jan 4 15:04: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 A57CD3A09E9 for ; Mon, 4 Jan 2021 15:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 AkK8dKWiiqGF for ; Mon, 4 Jan 2021 15:04:02 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0AA3A09D7 for ; Mon, 4 Jan 2021 15:04:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0CEF4300B45 for ; Mon, 4 Jan 2021 18:04:00 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id erWGjIVaEiUZ for ; Mon, 4 Jan 2021 18:03:59 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 20613300A01 for ; Mon, 4 Jan 2021 18:03:59 -0500 (EST) 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, 4 Jan 2021 18:04:00 -0500 References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> To: rfced-future@iab.org In-Reply-To: <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> Message-Id: <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 Jan 2021 23:04:05 -0000 Looking at RFC 8728, there is an expectation that the RSE should see the = stream manager as customers. RFC 8728, s2.1: "The RSE is expected to = cooperate closely with the IETF LLC and the stream managers." I always = assumed that the IETF LLC was included here because that is the legal = entity that holds the contract, not because they represent an additional = customer. In addition, RFC 8728, s2.1.2.1.2 says that the RSE makes policies that = are good for the "broader Internet community". However, I do not think = we have reached consensus on the topic of "customers". We do not have a = way to represent the broader community as an RFC Series customer. The = idea of a NomCom selected at-large person has been suggested, but I do = not think that is not going to make it better. Russ From nobody Mon Jan 4 16:32:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEB73A0BF0 for ; Mon, 4 Jan 2021 16:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=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.262, 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 NcPEj1AagbIG for ; Mon, 4 Jan 2021 16:32:53 -0800 (PST) Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C9603A0BED for ; Mon, 4 Jan 2021 16:32:53 -0800 (PST) Received: by mail-pl1-x629.google.com with SMTP id s15so15430553plr.9 for ; Mon, 04 Jan 2021 16:32:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=p22cXDDgmFiMZBH2XYfvujTAz79HwYFaQ+viX07PtXE=; b=YbMrLK5DC54pBO1gNm+LCbjthcioxhbpQzlb8duZZp/1A8N+TKz0V3FDAwIsE7YAmU q7BX9FxuO8tiQm/3Y4yH0+WG4cx04phkW8E/a8NPMEQbfw/mJKoPYz6XH0cZT/A18oCD i8a5R8gXh95iQ74jgC7xAvGQXs1ypEVJO7gBkru1Htu7m7IAQc0aD1WIhyefmBEGhJTz Fpxn+AKOZK/YH10aSNp2RBabgSGbGpCfsMg/JpkVTgdAduytLUIzDAqGOhr3ISFfp4kS 4bD7Y4Bt9yKjkIv5GOKXNwiVpTfFbTMv2yzwBKD+KExVPgSyLqBjBzXk1XFvCB/pO9jx Ko0A== 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=p22cXDDgmFiMZBH2XYfvujTAz79HwYFaQ+viX07PtXE=; b=JPEf5mb1xSm4K6HgUVlKjppBzJG2BB47xcmS6GIBrZmp6Q2AEmzqa631UJBAYFmWT3 ou7RqE/eNhS0DTwdDN4nuAlSPIyizB1DaM+C/1PqurTe9WeTLxT2zacLVoUcysUYf/94 Fp6MCjVIR137eF/Yf3hsj1bcUc6wu4EofMsUGTOHIMJDS0s0ZeHJ7W7sklW3vVPae2ye h0mccVkaF03bZMYp15z3GENBzPRj4/P774+K0J80L0YISBSWwqHSj8d1+YI47843Bjv9 RyVGu1nXLXaJ8m46rj88C0LWMTw74cxGJqaQC+MiWaCzlp+9ZGt6KTuNx1u7ix7hdpdi JF9Q== X-Gm-Message-State: AOAM530++a91bfGYpHVKopBXgWuqzJqjAhQd6P0eJVy0HpB1FYZ9PcpA FFVkfCLuSAxGG5zICQP6zbcLXLjCPrWtpg== X-Google-Smtp-Source: ABdhPJzV9+D2BqOmx7L43fhkq3v6IQnkI5ko2uATu9DimYBbzNtAQCuOEbVvlUOF/1EgrTKVDmzE+g== X-Received: by 2002:a17:90a:eacf:: with SMTP id ev15mr1462386pjb.174.1609806771981; Mon, 04 Jan 2021 16:32:51 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id v2sm22201730pgs.50.2021.01.04.16.32.50 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Jan 2021 16:32:51 -0800 (PST) To: rfced-future@iab.org References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> From: Brian E Carpenter Message-ID: <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> Date: Tue, 5 Jan 2021 13:32:46 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 00:32:54 -0000 On 05-Jan-21 12:04, Russ Housley wrote: > Looking at RFC 8728, there is an expectation that the RSE should see the stream manager as customers. RFC 8728, s2.1: "The RSE is expected to cooperate closely with the IETF LLC and the stream managers." I always assumed that the IETF LLC was included here because that is the legal entity that holds the contract, not because they represent an additional customer. > > In addition, RFC 8728, s2.1.2.1.2 says that the RSE makes policies that are good for the "broader Internet community". However, I do not think we have reached consensus on the topic of "customers". We do not have a way to represent the broader community as an RFC Series customer. The idea of a NomCom selected at-large person has been suggested, but I do not think that is not going to make it better. Agreed, that is more of a mechanism to reduce the chances of groupthink. I think the best thing we can do at the level of process & structure is what we already seem to agree about - having an open, anyone-can-join discussion forum. We could of course do things like open, anyone-can-answer surveys when there are specific questions to be answered but that's an operational matter. How the discussions & surveys are made known to the wider community also seems like an operational matter, as part of outreach in general. Probably we should define clearly who's responsible for such outreach. Brian From nobody Mon Jan 4 17:04: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 70A653A0C3D for ; Mon, 4 Jan 2021 17:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.159 X-Spam-Level: X-Spam-Status: No, score=-2.159 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, 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 OXjB-R3lqx79 for ; Mon, 4 Jan 2021 17:04:54 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60C13A0C3B for ; Mon, 4 Jan 2021 17:04:54 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id u21so19855848qtw.11 for ; Mon, 04 Jan 2021 17:04:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=Yr5uFx/r+LLrqpXq69WUD3YQXVkOZxRPiI0srwqrfqc=; b=AamXRFFnLZ9jQbGH44lkql4MwFBGODcmjKgOINfNa6JfYwbTzaYM1an6EcQmefz06+ PbSvoQMLqzwM5WjU1VHu3gKYCBs8P4gEf7JU7RyzbvWJaejEk/SoC/rTL5357gx9VTn7 MsQ1wPTA/GgqFqk2Ymsj8XlrvcT0H66JOrsbJRhymVMc26iWsTKb4nM6ZMso8heEtOU2 mbboLCo1f1/lKWzE6xFy60TfWgU4Sy4rqCbpqSOQK/b8th/gD3ZUr8xd0Mmnaebw9KTL 6DDhlnw2k/tBXjh8Pxn67TlZIcitpYU1SBUn9O9ZqKLiVcrI1SzIEFa/vVGuh4aS+t+8 Ph6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=Yr5uFx/r+LLrqpXq69WUD3YQXVkOZxRPiI0srwqrfqc=; b=m6WCNaTYPvlFuXnu5ox5/1VEze+x/dHpR8iCi+69pnH1+zXPEd10ctxMLa30ry014c nH9wehCRMdJJa2oLMS1KD+j9ImuW9vgiND17R88Q/u6yfJO0AYJWNy5i4zFF8uMzAkaf baSFzSo4iUWB2hGIU44OjoXd+Mo+y7zxTOPaO79i9b3Js3A0EHUIdSBT7HBYmDDngPW1 O3TpAcVu0/trweYDooKm+pQ6YcutYPtV6lHruFVqtstDgZ3FTZ6B9oAG9F2NuN3So6w9 wIcUAGdLi4ufr/sP0Y3rqY9i9qcxiINEnd59NYlM2xwqBHoSP8xeE8aSoiAkO75YNj0C XQzg== X-Gm-Message-State: AOAM532aLpptcKLGZJvfGkHSkBeAWozn0KXgAihugKhC/70W19ctuah5 jzx+TywCMTeJ2AkOyEBfVbNFEUiy7j3FObR3 X-Google-Smtp-Source: ABdhPJwZ90QQXu7NbDD9CTZ3NICpEoEm8qYPahOeSEaH72tYMZpZ4gaMng384o7bEGAHAw5HzIjtFw== X-Received: by 2002:ac8:6f41:: with SMTP id n1mr73274690qtv.170.1609808693072; Mon, 04 Jan 2021 17:04:53 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id c139sm37302064qke.24.2021.01.04.17.04.52 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 04 Jan 2021 17:04:52 -0800 (PST) To: rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <056684f2-ab2c-5b85-4dfd-bada78e1e528@joelhalpern.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> From: Michael StJohns Message-ID: <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> Date: Mon, 4 Jan 2021 20:04:51 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> Content-Type: multipart/alternative; boundary="------------A53BF8CE93BC47F90C455888" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 01:04:56 -0000 This is a multi-part message in MIME format. --------------A53BF8CE93BC47F90C455888 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Reposting this as it seems to have gotten ignored: > Instead: > > > "All strategic bodies are open to the public.  All strategic issue > discussions will take place on open mailing lists, and anyone is > welcome to comment/discuss.  On a document by document basis, the > strategic body may decide by rough consensus, and with the assent of > the designated editors, to use additional forms of communication > consistent with [RFC2418] for the production of a given document.  Use > of those forms of communication does not replace the responsibility of > the editors to bring major strategic issues with the document to the > mailing list." > > > Github is pretty much the worst way to have a discussion such as we're > currently having and I expect that things like writing an SOW or even > deciding what the charter might be needs to be kept on the mailing > list.  It may make sense for a given document for the editing of > various content, but not for the day to day operation of the group. > > Later, Mike The key problem here is that there's a big difference between how you do the strategic discussions of the WG and the actual work for a given document and that's not being captured by the text below.    This is NOT an IETF WG and is not going to be producing implementable specifications (please don't quibble about what I mean here).   To be honest, I don't actually think that anyone but the RSE is going to be producing documents (and very few of those!) and I'd really like to avoid placing the RSE in a straight jacket requiring them to use a system that adds to their work without actually improving the end product.  Later, Mike On 1/4/2021 11:55 AM, Eliot Lear wrote: > Coming back to this, I believe we are now up to the following text: > >> |All strategic body meetings are open to the public. *At body's >> initial formation,* all discussions *are to* take place on open >> mailing lists, and anyone is welcome to comment / discuss. ||The >> |strategic body may decide *by rough consensus* to use additional >> forms of communication that are consistent with [RFC2418]. > * > * > The purpose of the change is to accommodate the discussion between > Joel and EKR, and to address Brian’s point.  I have removed references > to “issues” because that made it sound like each issue must be > initiated in email (EKR’s point, and my poor wording earlier). >  Rather, we will leave it til later for the group to decide best how > to operate, so long as they remain within the confines of RFC 2418 > (Brian’s point). > > I am hoping we can move off of this issue, but given the discussion, > we’ll do another consensus call after people have had an opportunity > to comment on the above. > > Eliot > --------------A53BF8CE93BC47F90C455888 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Reposting this as it seems to have gotten ignored:

Instead:


"All strategic bodies are open to the public.  All strategic issue discussions will take place on open mailing lists, and anyone is welcome to comment/discuss.  On a document by document basis, the strategic body may decide by rough consensus, and with the assent of the designated editors, to use additional forms of communication consistent with [RFC2418] for the production of a given document.  Use of those forms of communication does not replace the responsibility of the editors to bring major strategic issues with the document to the mailing list."


Github is pretty much the worst way to have a discussion such as we're currently having and I expect that things like writing an SOW or even deciding what the charter might be needs to be kept on the mailing list.  It may make sense for a given document for the editing of various content, but not for the day to day operation of the group.

Later, Mike

The key problem here is that there's a big difference between how you do the strategic discussions of the WG and the actual work for a given document and that's not being captured by the text below.    This is NOT an IETF WG and is not going to be producing implementable specifications (please don't quibble about what I mean here).   To be honest, I don't actually think that anyone but the RSE is going to be producing documents (and very few of those!) and I'd really like to avoid placing the RSE in a straight jacket requiring them to use a system that adds to their work without actually improving the end product.

 Later, Mike






On 1/4/2021 11:55 AM, Eliot Lear wrote:
Coming back to this, I believe we are now up to the following text:

All strategic body meetings are open to the public.  At body's initial formation, all discussions are to take place on open mailing lists, and anyone is welcome to comment / discuss.  The strategic body may decide by rough consensus to use additional forms of communication that are consistent with [RFC2418].

The purpose of the change is to accommodate the discussion between Joel and EKR, and to address Brian’s point.  I have removed references to “issues” because that made it sound like each issue must be initiated in email (EKR’s point, and my poor wording earlier).  Rather, we will leave it til later for the group to decide best how to operate, so long as they remain within the confines of RFC 2418 (Brian’s point).

I am hoping we can move off of this issue, but given the discussion, we’ll do another consensus call after people have had an opportunity to comment on the above.

Eliot


--------------A53BF8CE93BC47F90C455888-- From nobody Mon Jan 4 18:02:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B7D43A0CEA for ; Mon, 4 Jan 2021 18:02:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 dRBaQGvy3O-K for ; Mon, 4 Jan 2021 18:02:36 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B108D3A0CE9 for ; Mon, 4 Jan 2021 18:02:36 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kwbgB-000Kvc-24; Mon, 04 Jan 2021 21:02:35 -0500 Date: Mon, 04 Jan 2021 21:02:29 -0500 From: John C Klensin To: Brian E Carpenter , rfced-future@iab.org Message-ID: In-Reply-To: <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 02:02:38 -0000 --On Tuesday, January 5, 2021 13:32 +1300 Brian E Carpenter wrote: > On 05-Jan-21 12:04, Russ Housley wrote: >> Looking at RFC 8728, there is an expectation that the RSE >> should see the stream manager as customers. RFC 8728, s2.1: >> "The RSE is expected to cooperate closely with the IETF LLC >> and the stream managers." I always assumed that the IETF LLC >> was included here because that is the legal entity that holds >> the contract, not because they represent an additional >> customer. >> >> In addition, RFC 8728, s2.1.2.1.2 says that the RSE makes >> policies that are good for the "broader Internet community". >> However, I do not think we have reached consensus on the >> topic of "customers". We do not have a way to represent the >> broader community as an RFC Series customer. The idea of a >> NomCom selected at-large person has been suggested, but I do >> not think that is not going to make it better. > > Agreed, that is more of a mechanism to reduce the chances of > groupthink. > > I think the best thing we can do at the level of process & > structure is what we already seem to agree about - having an > open, anyone-can-join discussion forum. We could of course do > things like open, anyone-can-answer surveys when there are > specific questions to be answered but that's an operational > matter. How the discussions & surveys are made known to the > wider community also seems like an operational matter, as part > of outreach in general. > > Probably we should define clearly who's responsible for such > outreach. Brian, While I agree with all of that, I think it is important to come back to Russ's question, which is one that has been a problem for this effort for well over a year now. While I don't think it is helpful to try to prioritize "customers" or what we might call stakeholders in another context, there are at least three groups of users of the series we tend to forget about (or excessively de-emphasize) as we try to sort through issues of representation, questions to be answered when we think about surveys, and particular needs. Two examples: (1) Despite our best efforts, and often a good degree of consensus within the IETF, sometimes we produce specifications that either do not work or that fail to get traction. In some cases, the reason, at least in retrospect, is that we solved a problem that no one cared about or that was just overtaken by events. In others, we just get it wrong or discover that we solved the wrong problem. Especially in the latter cases, and also when the consensus turns out to be somewhat rough, it is important to have good records of different ways that the issues were thought about, different proposed solutions, etc., so that, if we need to come back to the topic(s), we have the potential for getting a head start and not reinventing the previous style of wheel. While, as things are defined today, this mostly interacts with the Independent Stream, I note that (regardless of what the authors intended) RFC 8789 does not prohibit publishing a document with which the IETF participant community is in violent disagreement as long as there is IETF consensus that it should be published. (2) Part of the use of the RFC Series is to publish standards, as distinct from, e.g., evolving engineering specifications. A key audience for standards are people using them in procurement specifications and expecting that assertions of conformance on the part of those producing products will be meaningful, stable enough to outlast procurement cycles, and helpful in predicting interoperability and interchangeability. Precisely because we sometimes lose sight of that distinction and its importance, it is important that the RFC Editor function (as well as relevant streams and the IANA function) be sensitive to the issues involved and the constraints they put on the style and presentation of publications. We have had, and will probably continue to have, difficulty getting good direct representation of those interests. Even if we could find a token procurement person or two (of the bean-counting subspecies or otherwise) and get them into a WG, panel, board, or survey population, it is not clear that we are good at listening or putting ourselves into their positions and perspectives. However, that does not make the perspective and requirements any less important. best, john From nobody Mon Jan 4 22:06:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3CA3A00D8 for ; Mon, 4 Jan 2021 22:06:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZB0IzunWenJ for ; Mon, 4 Jan 2021 22:06:47 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB653A00D3 for ; Mon, 4 Jan 2021 22:06:47 -0800 (PST) Received: from xse410.mail2web.com ([66.113.197.156] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kwfUP-0015hk-Op for rfced-future@iab.org; Tue, 05 Jan 2021 07:06:43 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4D927g6L1XzLRg for ; Mon, 4 Jan 2021 22:06:39 -0800 (PST) Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kwfUN-0005o3-Pm for rfced-future@iab.org; Mon, 04 Jan 2021 22:06:39 -0800 Received: (qmail 13498 invoked from network); 5 Jan 2021 06:06:39 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 5 Jan 2021 06:06:39 -0000 To: John C Klensin , Brian E Carpenter , rfced-future@iab.org References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> From: Christian Huitema Message-ID: <87e7b1df-0a73-631a-f0f3-313fe2f4223c@huitema.net> Date: Mon, 4 Jan 2021 22:06:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.197.156 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.61) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+VfvUYPwyzXA6t1XwnLEdiPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KuMf rgCtBOx5JllovohK6yVKZR2tNRPIxp/vINc/oXVUSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVOYls9BJhJ1jb0Wp7qcRKLJotTbzF8bFslzcWfB/84WX1KHe/ FVcvFYE7DSY4uAuvkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dj1kvSgT4G6Wgcnfwvu7dYoQ wlDoYzCQs5vMprmP2D5Zb3UQT3xbkHqpqmyCe4PiKVv0wNAmy0z4NCWU5AbBg6tDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAlnH918E1R4YKo/dz55KCB+S3h1ESmlc3/lS5x7qxkdlaevuL ga0PcbAhcwHrDi/j4iuANTIsWbQIHqZrRL/6m+JRXxKF5tPxTxfD0dMN+t5ZfFf5uQ8WYF4JQeLb +1UGdXjZjh2PRg3GRvi3cJu32dKN9/YGRrhMRGhIOTxMW00yF8F1u0YDQf8cLP9taeSLFY0fPBnF 89BphpBNlUg+TzHwBTL1+6vDOMemz/4I88NDcmnEJ4r7C+SwLRamrhQTd3PrpJpP5ewAjeqkzRNl ucyd+NO2McmveAr4ch9F7rE89jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 06:06:49 -0000 On 1/4/2021 6:02 PM, John C Klensin wrote: > (2) Part of the use of the RFC Series is to publish standards, > as distinct from, e.g., evolving engineering specifications. A > key audience for standards are people using them in procurement > specifications and expecting that assertions of conformance on > the part of those producing products will be meaningful, stable > enough to outlast procurement cycles, and helpful in predicting > interoperability and interchangeability. Precisely because we > sometimes lose sight of that distinction and its importance, it > is important that the RFC Editor function (as well as relevant > streams and the IANA function) be sensitive to the issues > involved and the constraints they put on the style and > presentation of publications. John, I don't think that the RFC edition function can have any meaningful influence on the creation of documents "stable enough to outlast procurement cycles". Documents do not become unstable, the technology that they described becomes obsolete. It is often supplanted by the arrival of a new tech, often documented in new series of RFC. Do you see a future in which the RFC Edition function might refuse to publish new documents by fear of making previously published RFC "unstable"? I don't. Besides, competition from new tech is not the only reason for instability. We also have to account for deployment experience, unforeseen security issues, or changes in the technology landscape. This is not something that the RFC Edition can influence. -- Christian Huitema From nobody Mon Jan 4 22:24: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 749A43A044A for ; Mon, 4 Jan 2021 22:24:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_dMtq4gDG4o for ; Mon, 4 Jan 2021 22:24:54 -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 1AC9B3A0418 for ; Mon, 4 Jan 2021 22:24:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10864; q=dns/txt; s=iport; t=1609827894; x=1611037494; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=WmpZT1KQPVGwgfXYudGtLjzN+EDkzrdK4pc60rbyC2w=; b=O2XNCloLDxlJG43UdDcbKRf448PoC4u6i945HVNTsFXhdEtpewrspGrF 4F8hv23TUJaPfqUQdZcbZiKb4ykmE3RKyxMeZPFLOMqYtIc3ourWdlo7k S1s3xGCPVDgZ9YaTQ9TH7LaBaVPpRWc5X/KcjOzKHNs03Ax1yF7EreCLJ A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AUAwDwBfRf/xbLJq1iHAECAgEHARQBBAQBghCBdoErV?= =?us-ascii?q?wEgEi6EP4kEiCsDlByGNIFoBAcBAQEKAwEBGAEKDAQBAYRKAoFwJjgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgRxhWEMhXMBAQEDAQEBIUsLBQsLGCoCAicwBhODJ?= =?us-ascii?q?gGCZiAPrUh2gTKFWIRdCgaBOIFTi1ZBggCBOByCITU+gl0BgSIJARIBB4MyN?= =?us-ascii?q?IIsBIFUAW9gAVYgAjk1MkABbY8UjEOcKYMAgyeBN5Z9Ax+DKYorhTKPSo5Mo?= =?us-ascii?q?wmDbgIEBgUCFoFtI2dwMxoIGxU7KgGCPj4SGQ2XJoVFQAMwNwIGAQkBAQMJj?= =?us-ascii?q?UIBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,476,1599523200"; d="asc'?scan'208,217";a="29967671" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jan 2021 06:24:49 +0000 Received: from [10.61.249.103] ([10.61.249.103]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 1056Onl7005018 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 5 Jan 2021 06:24:49 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_29FFCF9E-70A2-40EA-AB2D-E60D0CE2FAC3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 5 Jan 2021 07:24:48 +0100 In-Reply-To: <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <056684f2-ab2c-5b85-4dfd-bada78e1e528@joelhalpern.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.249.103, [10.61.249.103] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 06:24:56 -0000 --Apple-Mail=_29FFCF9E-70A2-40EA-AB2D-E60D0CE2FAC3 Content-Type: multipart/alternative; boundary="Apple-Mail=_0301BF38-88F8-4176-A828-7E3131B5767B" --Apple-Mail=_0301BF38-88F8-4176-A828-7E3131B5767B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I saw it but could not imagine there would be rough consensus for text = that requires a working methods discussion for every document. Eliot > On 5 Jan 2021, at 02:04, Michael StJohns = wrote: >=20 > Reposting this as it seems to have gotten ignored: >=20 >> Instead: >>=20 >>=20 >>=20 >> "All strategic bodies are open to the public. All strategic issue = discussions will take place on open mailing lists, and anyone is welcome = to comment/discuss. On a document by document basis, the strategic body = may decide by rough consensus, and with the assent of the designated = editors, to use additional forms of communication consistent with = [RFC2418] for the production of a given document. Use of those forms of = communication does not replace the responsibility of the editors to = bring major strategic issues with the document to the mailing list." >>=20 >>=20 >>=20 >> Github is pretty much the worst way to have a discussion such as = we're currently having and I expect that things like writing an SOW or = even deciding what the charter might be needs to be kept on the mailing = list. It may make sense for a given document for the editing of various = content, but not for the day to day operation of the group. >>=20 >> Later, Mike >=20 >=20 > The key problem here is that there's a big difference between how you = do the strategic discussions of the WG and the actual work for a given = document and that's not being captured by the text below. This is NOT = an IETF WG and is not going to be producing implementable specifications = (please don't quibble about what I mean here). To be honest, I don't = actually think that anyone but the RSE is going to be producing = documents (and very few of those!) and I'd really like to avoid placing = the RSE in a straight jacket requiring them to use a system that adds to = their work without actually improving the end product. >=20 > Later, Mike >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 1/4/2021 11:55 AM, Eliot Lear wrote: >> Coming back to this, I believe we are now up to the following text: >>=20 >>> All strategic body meetings are open to the public. At body's = initial formation, all discussions are to take place on open mailing = lists, and anyone is welcome to comment / discuss. The strategic body = may decide by rough consensus to use additional forms of communication = that are consistent with [RFC2418]. >>=20 >>=20 >> The purpose of the change is to accommodate the discussion between = Joel and EKR, and to address Brian=E2=80=99s point. I have removed = references to =E2=80=9Cissues=E2=80=9D because that made it sound like = each issue must be initiated in email (EKR=E2=80=99s point, and my poor = wording earlier). Rather, we will leave it til later for the group to = decide best how to operate, so long as they remain within the confines = of RFC 2418 (Brian=E2=80=99s point). >>=20 >> I am hoping we can move off of this issue, but given the discussion, = we=E2=80=99ll do another consensus call after people have had an = opportunity to comment on the above. >>=20 >> Eliot >>=20 >>=20 >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_0301BF38-88F8-4176-A828-7E3131B5767B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = saw it but could not imagine there would be rough consensus for text = that requires a working methods discussion for every document.

Eliot

On 5 Jan 2021, at 02:04, Michael StJohns <msj@nthpermutation.com> wrote:

=20
Reposting this as it seems to have gotten ignored:

Instead:


"All strategic bodies are open to the = public.  All strategic issue discussions will take place on open mailing lists, and anyone is welcome to comment/discuss.  On a document by document basis, the strategic body may decide by rough consensus, and with the assent of the designated editors, to use additional forms of communication consistent with [RFC2418] for the production of a given document.  Use of those forms of communication does not replace the responsibility of the editors to bring major strategic issues with the document to the mailing list."


Github is pretty much the worst way to have a = discussion such as we're currently having and I expect that things like writing an SOW or even deciding what the charter might be needs to be kept on the mailing list.  It may make sense = for a given document for the editing of various content, but not for the day to day operation of the group.

Later, Mike

The key problem here is that there's = a big difference between how you do the strategic discussions of the WG and the actual work for a given document and that's not being captured by the text below.    This is NOT an IETF = WG and is not going to be producing implementable specifications (please don't quibble about what I mean here).   To be honest, I don't = actually think that anyone but the RSE is going to be producing documents (and very few of those!) and I'd really like to avoid placing the RSE in a straight jacket requiring them to use a system that adds to their work without actually improving the end product.

 Later, Mike






On 1/4/2021 11:55 AM, Eliot Lear = wrote:
=20 Coming back to this, I believe we are now up to the following text:

All = strategic body meetings are open to the public.  At= body's initial formation, all = discussions are to take place on open mailing = lists, and anyone is welcome to comment / discuss. =  The strategic body may decide by = rough consensus to use additional forms of = communication that are consistent with [RFC2418].

The purpose of the change is to accommodate the discussion between Joel and EKR, and to address Brian=E2=80=99s = point.  I have removed references to =E2=80=9Cissues=E2=80=9D = because that made it sound like each issue must be initiated in email (EKR=E2=80=99s = point, and my poor wording earlier).  Rather, we will leave it = til later for the group to decide best how to operate, so long as they remain within the confines of RFC 2418 (Brian=E2=80=99s = point).

I am hoping we can move off of this issue, but = given the discussion, we=E2=80=99ll do another consensus call after = people have had an opportunity to comment on the above.

Eliot


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

= --Apple-Mail=_0301BF38-88F8-4176-A828-7E3131B5767B-- --Apple-Mail=_29FFCF9E-70A2-40EA-AB2D-E60D0CE2FAC3 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/0BjAACgkQh7ZrRtnS ejM+GQf/b+/18LKOuFRnYBt/iEbQv4p18U/yzwxtTTHei8OVCToG1i8UQ+GVBq3p qnn/0VzYE3W43lEs4vo3pdH4KYHX3KavLHrxdnTRMoKkwIiJJrXio5DoCFR8yYJJ PBGL8VKbNl5ADMQGDoO7xbDQX4WMZyIXubLka1DdQDxs6Zq2F7ZmFCoWhMH4jhNp w7IAYkXxKA9GGzzV9YSFzD0QXBQZwwiaGv2ccz/h0ROrMEXzBxBAwyEvideHH1Tq Qri6kxG7ZngNVLlrwR1ItqJja4MPgQNuyP+4cg3YLhMPXx6e18uitgoNqvZyKUyw KZtS+td4YG9ggpHhkvmy0eLNHJ40TA== =zhTf -----END PGP SIGNATURE----- --Apple-Mail=_29FFCF9E-70A2-40EA-AB2D-E60D0CE2FAC3-- From nobody Tue Jan 5 11:01:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CED8E3A117C for ; Tue, 5 Jan 2021 11:01:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKsL6razxPV2 for ; Tue, 5 Jan 2021 11:01:23 -0800 (PST) Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCDA63A0ECA for ; Tue, 5 Jan 2021 11:01:19 -0800 (PST) Received: by mail-qt1-x835.google.com with SMTP id h19so404066qtq.13 for ; Tue, 05 Jan 2021 11:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=tJO5paImIsOy4zHRjj2vCvuprU4mM4JejBx2UKXB8nc=; b=n/YpCXV6OYrqHcM2oybb6jDFR0xYjaKGyaXtWaAwjAsd0ErdtW5sUeRZv9VNV9mqfB SUQC1Lyq5YRPXDq2qnQo9P9pjrGoRKLQCsXLFBbnys3tru3JjPQPpp7QdVNilafRnKQj cSKTiJmQySWMAM274B33FTgYc03rAo68Ss2VV4iuT4mbE+iJh3uPJCnzv6FTgJxy64s4 voi6UapiYiD9u+6ITLsu+Rp/ApEjPAlSWmPTI+tzSdzBE/5utlICJDnA0b2kfMxgQWI1 Mjul+fS1VF9/tSHCgMC14z87SXDndMrEK+3G7eLySI2oAAuDJGNRiv7rr7EvGkrsszSa 0nxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=tJO5paImIsOy4zHRjj2vCvuprU4mM4JejBx2UKXB8nc=; b=p6oOIHWUr+u7D550RR0k94aLB2xcmVuhJFV13Yf/nfoxjka4H9bpRMJTgdFjdpzbk9 T9ZtyeF5bjdhFftmQvM3HnbmCJRzS1y5FJuk5r+RJipQLtXEHVGrTeLQQJ8r92/Vp6Lh 9bG+W7gtoZH1FbltYjJ+kZLhG8edhLGLv93JkQ7IoTwEY08xHrr+bUZvoMIOgqioxTB3 McwnQfbI9T8/XeI8idfGJ7sib9h2nsD6Ujp/VKFbDhLWVL2YKNv/uyi3bdgyF6C9fyjl 2pWqbnE5c+oIQJ/8mguB2TyWVe4cv0p8YsAsVvhn08JEGJ4zJU7xenyQf39+jbaR4f6Q 5HDw== X-Gm-Message-State: AOAM5305/R19W4lUi7oONSxwAP9vHz4/CxUtf+h3jAnqz+OKTo3yEZWs QfpZPapKmucD1upvXqNFJVTf66zYPWp+fnCa X-Google-Smtp-Source: ABdhPJxOpSv/XQLzcQwn+60y0C1B7Mm/lxzBfQ7Dawt95vEfC6hAJnyQYjaqhSkWdqYbcNsyoT607Q== X-Received: by 2002:ac8:588d:: with SMTP id t13mr906126qta.156.1609873278371; Tue, 05 Jan 2021 11:01:18 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id h16sm38375qko.135.2021.01.05.11.01.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 05 Jan 2021 11:01:17 -0800 (PST) To: Eliot Lear Cc: rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <056684f2-ab2c-5b85-4dfd-bada78e1e528@joelhalpern.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> From: Michael StJohns Message-ID: <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> Date: Tue, 5 Jan 2021 14:01:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------518373901284A2C696249157" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 19:01:27 -0000 This is a multi-part message in MIME format. --------------518373901284A2C696249157 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hmm... I didn't realize the role of the chair included ignoring submissions?  If you disagreed with what I proposed, then say so and why, rather than just passing over it. In any event, it's not the chair's role to imagine consensus, rather the role requires you to actively seek it. I could see something like GIT being used for a document such as the XML vocabulary which might benefit from a fast iteration (propose/implement/test/approve or remove) model.   However, reviewing the documents that had Heather as the author  or editor,  I think for the most part they benefited from the slow iteration model of publish draft/receive comments/revise draft. Or more bluntly, forcing the development of all documents into one model with many micro authors may actively harm or substantially delay the production of some documents necessary to evolve the series.  cf RFC8153 for an example of a document which might have been harmed or delayed. I see the proposed language here as an attempt to allow for the later imposition of a model which will always micromanage the authors by random participants and I just don't think that's sustainable or useful. Later, Mike On 1/5/2021 1:24 AM, Eliot Lear wrote: > I saw it but could not imagine there would be rough consensus for text > that requires a working methods discussion for every document. > > Eliot > >> On 5 Jan 2021, at 02:04, Michael StJohns > > wrote: >> >> Reposting this as it seems to have gotten ignored: >> >>> Instead: >>> >>> >>> "All strategic bodies are open to the public.  All strategic issue >>> discussions will take place on open mailing lists, and anyone is >>> welcome to comment/discuss.  On a document by document basis, the >>> strategic body may decide by rough consensus, and with the assent of >>> the designated editors, to use additional forms of communication >>> consistent with [RFC2418] for the production of a given document.  >>> Use of those forms of communication does not replace the >>> responsibility of the editors to bring major strategic issues with >>> the document to the mailing list." >>> >>> >>> Github is pretty much the worst way to have a discussion such as >>> we're currently having and I expect that things like writing an SOW >>> or even deciding what the charter might be needs to be kept on the >>> mailing list.  It may make sense for a given document for the >>> editing of various content, but not for the day to day operation of >>> the group. >>> >>> Later, Mike >> >> The key problem here is that there's a big difference between how you >> do the strategic discussions of the WG and the actual work for a >> given document and that's not being captured by the text below.    >> This is NOT an IETF WG and is not going to be producing implementable >> specifications (please don't quibble about what I mean here).   To be >> honest, I don't actually think that anyone but the RSE is going to be >> producing documents (and very few of those!) and I'd really like to >> avoid placing the RSE in a straight jacket requiring them to use a >> system that adds to their work without actually improving the end >> product. >> >>  Later, Mike >> >> >> >> >> >> >> On 1/4/2021 11:55 AM, Eliot Lear wrote: >>> Coming back to this, I believe we are now up to the following text: >>> >>>> |All strategic body meetings are open to the public. *At body's >>>> initial formation,* all discussions *are to* take place on open >>>> mailing lists, and anyone is welcome to comment / discuss. ||The >>>> |strategic body may decide *by rough consensus* to use additional >>>> forms of communication that are consistent with [RFC2418]. >>> * >>> * >>> The purpose of the change is to accommodate the discussion between >>> Joel and EKR, and to address Brian’s point.  I have removed >>> references to “issues” because that made it sound like each issue >>> must be initiated in email (EKR’s point, and my poor wording >>> earlier).  Rather, we will leave it til later for the group to >>> decide best how to operate, so long as they remain within the >>> confines of RFC 2418 (Brian’s point). >>> >>> I am hoping we can move off of this issue, but given the discussion, >>> we’ll do another consensus call after people have had an opportunity >>> to comment on the above. >>> >>> Eliot >>> >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > --------------518373901284A2C696249157 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hmm... I didn't realize the role of the chair included ignoring submissions?  If you disagreed with what I proposed, then say so and why, rather than just passing over it.

In any event, it's not the chair's role to imagine consensus, rather the role requires you to actively seek it.

I could see something like GIT being used for a document such as the XML vocabulary which might benefit from a fast iteration (propose/implement/test/approve or remove) model.   However, reviewing the documents that had Heather as the author  or editor,  I think for the most part they benefited from the slow iteration model of publish draft/receive comments/revise draft. 

Or more bluntly, forcing the development of all documents into one model with many micro authors may actively harm or substantially delay the production of some documents necessary to evolve the series.  cf RFC8153 for an example of a document which might have been harmed or delayed.

I see the proposed language here as an attempt to allow for the later imposition of a model which will always micromanage the authors by random participants and I just don't think that's sustainable or useful.

Later, Mike


On 1/5/2021 1:24 AM, Eliot Lear wrote:
I saw it but could not imagine there would be rough consensus for text that requires a working methods discussion for every document.

Eliot

On 5 Jan 2021, at 02:04, Michael StJohns <msj@nthpermutation.com> wrote:

Reposting this as it seems to have gotten ignored:

Instead:


"All strategic bodies are open to the public.  All strategic issue discussions will take place on open mailing lists, and anyone is welcome to comment/discuss.  On a document by document basis, the strategic body may decide by rough consensus, and with the assent of the designated editors, to use additional forms of communication consistent with [RFC2418] for the production of a given document.  Use of those forms of communication does not replace the responsibility of the editors to bring major strategic issues with the document to the mailing list."


Github is pretty much the worst way to have a discussion such as we're currently having and I expect that things like writing an SOW or even deciding what the charter might be needs to be kept on the mailing list.  It may make sense for a given document for the editing of various content, but not for the day to day operation of the group.

Later, Mike

The key problem here is that there's a big difference between how you do the strategic discussions of the WG and the actual work for a given document and that's not being captured by the text below.    This is NOT an IETF WG and is not going to be producing implementable specifications (please don't quibble about what I mean here).   To be honest, I don't actually think that anyone but the RSE is going to be producing documents (and very few of those!) and I'd really like to avoid placing the RSE in a straight jacket requiring them to use a system that adds to their work without actually improving the end product.

 Later, Mike






On 1/4/2021 11:55 AM, Eliot Lear wrote:
Coming back to this, I believe we are now up to the following text:

All strategic body meetings are open to the public.  At body's initial formation, all discussions are to take place on open mailing lists, and anyone is welcome to comment / discuss.  The strategic body may decide by rough consensus to use additional forms of communication that are consistent with [RFC2418].

The purpose of the change is to accommodate the discussion between Joel and EKR, and to address Brian’s point.  I have removed references to “issues” because that made it sound like each issue must be initiated in email (EKR’s point, and my poor wording earlier).  Rather, we will leave it til later for the group to decide best how to operate, so long as they remain within the confines of RFC 2418 (Brian’s point).

I am hoping we can move off of this issue, but given the discussion, we’ll do another consensus call after people have had an opportunity to comment on the above.

Eliot


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


--------------518373901284A2C696249157-- From nobody Tue Jan 5 11:18:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB6C3A11CA for ; Tue, 5 Jan 2021 11:18:06 -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 Lzh8xKUq__WY for ; Tue, 5 Jan 2021 11:18:05 -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 130803A11AE for ; Tue, 5 Jan 2021 11:18:05 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kwrqD-0000hP-NE; Tue, 05 Jan 2021 14:18:01 -0500 Date: Tue, 05 Jan 2021 14:17:55 -0500 From: John C Klensin To: Christian Huitema , Brian E Carpenter , rfced-future@iab.org Message-ID: <05277F6D504C4604E3555899@PSB> In-Reply-To: <87e7b1df-0a73-631a-f0f3-313fe2f4223c@huitema.net> References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <87e7b1df-0a73-631a-f0f3-313fe2f4223c@huitema.net> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 19:18:13 -0000 --On Monday, January 4, 2021 22:06 -0800 Christian Huitema wrote: > > On 1/4/2021 6:02 PM, John C Klensin wrote: >> (2) Part of the use of the RFC Series is to publish standards, >> as distinct from, e.g., evolving engineering specifications. >> A key audience for standards are people using them in >> procurement specifications and expecting that assertions of >> conformance on the part of those producing products will be >> meaningful, stable enough to outlast procurement cycles, and >> helpful in predicting interoperability and >> interchangeability. Precisely because we sometimes lose sight >> of that distinction and its importance, it is important that >> the RFC Editor function (as well as relevant streams and the >> IANA function) be sensitive to the issues involved and the >> constraints they put on the style and presentation of >> publications. > > John, > > I don't think that the RFC edition function can have any > meaningful influence on the creation of documents "stable > enough to outlast procurement cycles". Documents do not become > unstable, the technology that they described becomes obsolete. > It is often supplanted by the arrival of a new tech, often > documented in new series of RFC. Do you see a future in which > the RFC Edition function might refuse to publish new documents > by fear of making previously published RFC "unstable"? I > don't. Besides, competition from new tech is not the only > reason for instability. We also have to account for deployment > experience, unforeseen security issues, or changes in the > technology landscape. This is not something that the RFC > Edition can influence. Christian, I agree with what you write above, including your conclusion. However, there have been fairly recent proposals that we make incremental changes to RFCs rather than creating new documents and that we integrate approved errata into the text of RFCs. Even now, we make "HTML with inline errata" available as one of the formats in the RFC Editor's repository. I would expect an RSx to have sufficient knowledge to take a professionally competent position, and be willing to educate others, about the issues such proposals might raise relative to what I wrote above. I also think it is important that any oversight committee or process have participants who would be able and willing to understand those issues and the tradeoffs involved and, ideally, that it would have members who would notice and identify those issues if the RSx failed to do so. Does that make the interaction with the RFC Editor Function and what it can influence more clear? best, john From nobody Tue Jan 5 11:46: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 EC7843A0FCD for ; Tue, 5 Jan 2021 11:46:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=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.262, 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 8gLkXtcdLblv for ; Tue, 5 Jan 2021 11:46:14 -0800 (PST) Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com [IPv6:2607:f8b0:4864:20::1035]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18FC53A0EC9 for ; Tue, 5 Jan 2021 11:46:14 -0800 (PST) Received: by mail-pj1-x1035.google.com with SMTP id lj6so264073pjb.0 for ; Tue, 05 Jan 2021 11:46:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=MVBUvp9f+/Hoz08kL3JaNvZYCSxXkPNAzqhsQH/sxjQ=; b=LrC50/p/Sovp5fkBgScQGSmiDqkd2ygeIa8VOb8iCw8NZ4Sa5uX2Km/UU2bXuyqIum aEb2KmdeR1P6GyMTs2vQRpxbNmA4fY6ZTMzuiNXBYUubcgb1LszrOL+QOzy2nbM4idkx Zy80SVUzluucFAqun7SwimHka2lHDanFJl0hAQ8wbH5tdQB4DE+xaO/dz5Hx8cDaRp7C /MxopTA0Y3DXThLwFe9SKy3M+loqykkJgNiiucnwcelt4CwmlZLpHM4kpT72PKwuQYHd FxyOMHkcbbG5hAAmOYOQ8M3JrD3dxovAKFPQRYkjsa7s7EDViYD/sMH9EX3kLX5ynhbi IHdg== 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=MVBUvp9f+/Hoz08kL3JaNvZYCSxXkPNAzqhsQH/sxjQ=; b=Gb4uZ6YMY5wqcmF7If9EklePO7gyFviOQmlodOpS/6RJqOoCar3xE2YVyuMdkecG3x kweXxu1n3uJFs2lIkFekZjI8bazUNQGibgra1xgq7J/oDH+e+xqKhsft2qN5HLN+3mnw pkIQsJq6UuJFszrVi2q+VEHUaWBLOqx3ZLmAgifVAHZDmoh9lnZmlnNNe7O06zbiJoe/ DSr1dtMkquLhzYQIcSjU3Q2O4PUSislkgY3OjY1hfOLGxVNufsPKVJx8X53GUxyXFeON KJg3B9qewIZ5/hiQ2Lup+5Aa7fJIZTXKPwJ2+RZmX3BHJlj0QGJpUSgrZKTVRYj/28S+ vtZA== X-Gm-Message-State: AOAM53136AOyzhSi53bEzilW64SWQ4Op2sZJTmKnXttgSBYTvLdJBcgJ wGgeh8wCuOne5Xo+GCP2YDvwYUocz0tw7w== X-Google-Smtp-Source: ABdhPJyfbaRnxGUHjzqztHYwPUdn7yP8nixF2edTySfvhrU+Cl+46k2MHLKgSU7oko1PgCmuI120Ug== X-Received: by 2002:a17:90b:1882:: with SMTP id mn2mr750444pjb.236.1609875973071; Tue, 05 Jan 2021 11:46:13 -0800 (PST) Received: from [192.168.178.25] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id b129sm8219pgc.52.2021.01.05.11.46.11 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2021 11:46:12 -0800 (PST) To: rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <056684f2-ab2c-5b85-4dfd-bada78e1e528@joelhalpern.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Wed, 6 Jan 2021 08:46:08 +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] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 19:46:16 -0000 Hmm. I really think the issue of whether it's document-by-document or not= doesn't need to be decided as a matter of principle; that is the power o= f simply invoking RFC2418, with or without mentioning RFC 8874 as ekr sug= gested. FWIW, RFC 8874 itself gives primacy to email. ("A working group c= hair MUST consult the working group mailing list for any issue that is po= tentially contentious.") [That said, Eliot, absence of comment on Mike's message doesn't really in= dicate consensus either way, especially during the holiday period.] Regards Brian Carpenter On 05-Jan-21 19:24, Eliot Lear wrote: > I saw it but could not imagine there would be rough consensus for text = that requires a working methods discussion for every document. >=20 > Eliot >=20 >> On 5 Jan 2021, at 02:04, Michael StJohns > wrote: >> >> Reposting this as it seems to have gotten ignored: >> >>> Instead: >>> >>> >>> "All strategic bodies are open to the public.=C2=A0 All strategic iss= ue discussions will take place on open mailing lists, and anyone is welco= me to comment/discuss.=C2=A0 On a document by document basis, the strateg= ic body may decide by rough consensus, and with the assent of the designa= ted editors, to use additional forms of communication consistent with [RF= C2418] for the production of a given document.=C2=A0 Use of those forms o= f communication does not replace the responsibility of the editors to bri= ng major strategic issues with the document to the mailing list." >>> >>> >>> Github is pretty much the worst way to have a discussion such as we'r= e currently having and I expect that things like writing an SOW or even d= eciding what the charter might be needs to be kept on the mailing list.=C2= =A0 It may make sense for a given document for the editing of various con= tent, but not for the day to day operation of the group. >>> >>> Later, Mike >> >> The key problem here is that there's a big difference between how you = do the strategic discussions of the WG and the actual work for a given do= cument and that's not being captured by the text below.=C2=A0=C2=A0=C2=A0= This is NOT an IETF WG and is not going to be producing implementable sp= ecifications (please don't quibble about what I mean here).=C2=A0=C2=A0 T= o be honest, I don't actually think that anyone but the RSE is going to b= e producing documents (and very few of those!) and I'd really like to avo= id placing the RSE in a straight jacket requiring them to use a system th= at adds to their work without actually improving the end product. >> >> =C2=A0Later, Mike >> >> >> >> >> >> >> On 1/4/2021 11:55 AM, Eliot Lear wrote: >>> Coming back to this, I believe we are now up to the following text: >>> >>>> |All strategic body meetings are open to the public. =C2=A0*At body'= s initial formation,*=C2=A0all discussions=C2=A0*are to* take place on op= en mailing lists, and anyone is welcome to comment / discuss. =C2=A0||The= =C2=A0|strategic body may decide=C2=A0*by rough consensus*=C2=A0to use ad= ditional forms of communication that are consistent with [RFC2418]. >>> * >>> * >>> The purpose of the change is to accommodate the discussion between Jo= el and EKR, and to address Brian=E2=80=99s point. =C2=A0I have removed re= ferences to =E2=80=9Cissues=E2=80=9D because that made it sound like each= issue must be initiated in email (EKR=E2=80=99s point, and my poor wordi= ng earlier). =C2=A0Rather, we will leave it til later for the group to de= cide best how to operate, so long as they remain within the confines of R= FC 2418 (Brian=E2=80=99s point). >>> >>> I am hoping we can move off of this issue, but given the discussion, = we=E2=80=99ll do another consensus call after people have had an opportun= ity to comment on the above. >>> >>> Eliot >>> >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Tue Jan 5 12:11:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D303A11AE for ; Tue, 5 Jan 2021 12:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QTwGsiuUE39 for ; Tue, 5 Jan 2021 12:11:41 -0800 (PST) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B9493A11AF for ; Tue, 5 Jan 2021 12:11:41 -0800 (PST) Received: by mail-pf1-x42b.google.com with SMTP id t22so390231pfl.3 for ; Tue, 05 Jan 2021 12:11:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=0GpD+QM5uG88GVpeRZa9Ps3HvOZXjtohOjzTd6nbLkI=; b=fkZlog13AmO2JuPvBijZ/IKKmJwWUTACdfHhxxRe1rsvTvmrlNPNfiToOZ84u+uAHZ aKG/gj6L00HDKJWfePWAOarJ4HGr4jnGOTGoBPVSpgMLidneRtQktws5ZL5vfsb7eLhv HoHpZup0V6VJFgo3d/Sn6GBMypJ+JczyBbvkdfFGC567/DH4g8NQZFKYWSJ5vtPwfVaf zol6h4yo5PDPE0dK4tfq7CFFXfpLG170oiMr9UnmilxGfQZQOSQUfFyMW71yJFoW3lP+ 2GXINCaPjEAmIMTtaBw3Flx3ceu0KGFThbAFp525T2fAkVA0ME6s/q5cntayW56rG38x Dz/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0GpD+QM5uG88GVpeRZa9Ps3HvOZXjtohOjzTd6nbLkI=; b=ilUE+v2QlJsirKlkjfNU/OUOYP+nvrJZULN9t/L9PsmH34hkY9mT8vtJ0hUIe0qJdZ oNifeAIG/BaK/EFZ8hyqZPRw3bJH0uBxKTKFJUxsNF4MlVO6WdYuzd/NtxXOjH7ejAGo cVvLGOuYRwLqvt8PO3/5jL2H4wvIAC/e4+IH3csssfm6EnBerrKQ+SPPth+PSWGm8ugT 8bwOfATF0FlOc1xUZrCiySpwz6p0dhUSKHLfkeAHLaA8yX42353XDFWsxZupOhlqp/fq G7rAkFkQzrQCXR+tu8+mrrySEmx50y7fyWQlMVxs3Fo9hQ8k5j9AqsmZxUMyBzlJoRJh TjbQ== X-Gm-Message-State: AOAM533j945zvrWaglmEN40VsYb19NthAUv5mzkAzpbwnu1yyitncdwF iTmZKyi2C4ey83BlPsZqfsm2h2pouhCTDw== X-Google-Smtp-Source: ABdhPJwwB4RBrNYzwOk3oVBahMQ7sk/DPxlPMF2i3Bks1xm/Nhsr0sqdt0RiusITH351NP8PMqm4iQ== X-Received: by 2002:a63:db57:: with SMTP id x23mr890851pgi.131.1609877500432; Tue, 05 Jan 2021 12:11:40 -0800 (PST) Received: from [192.168.178.25] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id u3sm59312pjf.52.2021.01.05.12.11.38 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2021 12:11:39 -0800 (PST) To: John C Klensin , rfced-future@iab.org References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> From: Brian E Carpenter Message-ID: <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> Date: Wed, 6 Jan 2021 09:11:35 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 20:11:43 -0000 Excuse front-posting but I think I'm setting off in yet another slightly different direction. Do we even *know* in any meaningful way who reads RFCs apart from people active in the existing four streams? Yes, we assume that the readers include operators, implementers, procurement departments, government officials, academics etc., but we don't have a real analysis; we don't know how many people this means and we certainly don't have a mailing list. (FYI there are 367 email addresses subscribed to rfc-interest, which means that it is clearly a small fraction of the customers. Although I would love to know who 1152701570@qq.com, 243372854@qq.com and their numerical friends are.) I feel that before we make too many assumptions about how to represent the customers, we need some actual facts about who they are and how we could talk to them. Getting those facts might cost some momey and effort, but I think it would be justified. Regards Brian On 05-Jan-21 15:02, John C Klensin wrote: > > > --On Tuesday, January 5, 2021 13:32 +1300 Brian E Carpenter > wrote: > >> On 05-Jan-21 12:04, Russ Housley wrote: >>> Looking at RFC 8728, there is an expectation that the RSE >>> should see the stream manager as customers. RFC 8728, s2.1: >>> "The RSE is expected to cooperate closely with the IETF LLC >>> and the stream managers." I always assumed that the IETF LLC >>> was included here because that is the legal entity that holds >>> the contract, not because they represent an additional >>> customer. >>> >>> In addition, RFC 8728, s2.1.2.1.2 says that the RSE makes >>> policies that are good for the "broader Internet community". >>> However, I do not think we have reached consensus on the >>> topic of "customers". We do not have a way to represent the >>> broader community as an RFC Series customer. The idea of a >>> NomCom selected at-large person has been suggested, but I do >>> not think that is not going to make it better. >> >> Agreed, that is more of a mechanism to reduce the chances of >> groupthink. >> >> I think the best thing we can do at the level of process & >> structure is what we already seem to agree about - having an >> open, anyone-can-join discussion forum. We could of course do >> things like open, anyone-can-answer surveys when there are >> specific questions to be answered but that's an operational >> matter. How the discussions & surveys are made known to the >> wider community also seems like an operational matter, as part >> of outreach in general. >> >> Probably we should define clearly who's responsible for such >> outreach. > > Brian, > > While I agree with all of that, I think it is important to come > back to Russ's question, which is one that has been a problem > for this effort for well over a year now. While I don't think > it is helpful to try to prioritize "customers" or what we might > call stakeholders in another context, there are at least three > groups of users of the series we tend to forget about (or > excessively de-emphasize) as we try to sort through issues of > representation, questions to be answered when we think about > surveys, and particular needs. > > Two examples: > > (1) Despite our best efforts, and often a good degree of > consensus within the IETF, sometimes we produce specifications > that either do not work or that fail to get traction. In some > cases, the reason, at least in retrospect, is that we solved a > problem that no one cared about or that was just overtaken by > events. In others, we just get it wrong or discover that we > solved the wrong problem. Especially in the latter cases, and > also when the consensus turns out to be somewhat rough, it is > important to have good records of different ways that the issues > were thought about, different proposed solutions, etc., so that, > if we need to come back to the topic(s), we have the potential > for getting a head start and not reinventing the previous style > of wheel. While, as things are defined today, this mostly > interacts with the Independent Stream, I note that (regardless > of what the authors intended) RFC 8789 does not prohibit > publishing a document with which the IETF participant community > is in violent disagreement as long as there is IETF consensus > that it should be published. > > (2) Part of the use of the RFC Series is to publish standards, > as distinct from, e.g., evolving engineering specifications. A > key audience for standards are people using them in procurement > specifications and expecting that assertions of conformance on > the part of those producing products will be meaningful, stable > enough to outlast procurement cycles, and helpful in predicting > interoperability and interchangeability. Precisely because we > sometimes lose sight of that distinction and its importance, it > is important that the RFC Editor function (as well as relevant > streams and the IANA function) be sensitive to the issues > involved and the constraints they put on the style and > presentation of publications. > > We have had, and will probably continue to have, difficulty > getting good direct representation of those interests. Even if > we could find a token procurement person or two (of the > bean-counting subspecies or otherwise) and get them into a WG, > panel, board, or survey population, it is not clear that we are > good at listening or putting ourselves into their positions and > perspectives. However, that does not make the perspective and > requirements any less important. > > best, > john > > From nobody Tue Jan 5 12:57: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 153463A121B for ; Tue, 5 Jan 2021 12:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4xJqoyTAWTJ for ; Tue, 5 Jan 2021 12:57:34 -0800 (PST) Received: from mail-qv1-xf2f.google.com (mail-qv1-xf2f.google.com [IPv6:2607:f8b0:4864:20::f2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9326B3A121D for ; Tue, 5 Jan 2021 12:57:34 -0800 (PST) Received: by mail-qv1-xf2f.google.com with SMTP id d11so324465qvo.11 for ; Tue, 05 Jan 2021 12:57:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vOdXajiwXFYswmJFa6ZPwMLtyqDCQlcqLpqYOoqBxno=; b=WF0ZcLy1MAQ4UONNc8j2N68zqUp4YPbssdGIzYvA+shD12tOm6cpNwCBdH2OAzhHej /PWHJLCoXyDzcdObGH+rL29N2mCw8xBD0T9GhotvuZBJDlp97oFdBPXL3x3OOzwHfnMU uK7db2Lsj/+lcRKs1Vwsi8huzIYKHk+rFL99ODl6gHJPFafO3GhTXQr9KE/9LJaFPyMF 5TFG/z8717u9ztauksGtsqhWqDM9HkBz7RQnshN3MFNpaxxkVFV65RxA5Xe4ouruSGYR NrglS06CVC5qlOnm3drpifAkAM5RXeacedil60xcWS/yr8JJaKPMU+fxKvvGOQGQM4Si klpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vOdXajiwXFYswmJFa6ZPwMLtyqDCQlcqLpqYOoqBxno=; b=M6LCjqV5yanIBoQ3lh/64tD8eOmZ81jez8xxocRjMKm60CNnRhqqWUEFoDflp2YqW8 ABffNSsTY5vDFdCDp3hpAMkujm+TB5JN6dUlwdqvzhsVOZ+7bG7Soo5B77pclWbdQYyC jrM5f7xytZXzYjUNBLvwIxEl0tNha6t2cbYJ519YH5TwcIALmdeXP5QfwupBsDqXGD9f i/oA5HUyFDwp3DCvn/e8E7bwL48bKa07T6UlsnHgLlQIu4lKca/hjneFrGQrmG70BPLW D4V7gylW8YJRZP/kG4wQvwGylGVe7aK26/GXDT1L0oWcfDjgbHlz8EiSyhvnpk+EGN59 bZ8g== X-Gm-Message-State: AOAM531Q4asqFJ4oudaQySCLUCMR2aUvFpE0i7zg+Iskp1WOzmWw7r0i 9embHSso+PJJJD/xbouz5r4HEJEEmW+0qTTP X-Google-Smtp-Source: ABdhPJyYdVt8DvdLzAC8+nZzcEtl2wm4JOFC7N85PIdCVz5nurid6cVqJtl+6wfj4afX9Cojq/jGhA== X-Received: by 2002:a0c:c211:: with SMTP id l17mr1245623qvh.53.1609880253551; Tue, 05 Jan 2021 12:57:33 -0800 (PST) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id l204sm285543qke.56.2021.01.05.12.57.32 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2021 12:57:33 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Brian Rosen In-Reply-To: <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> Date: Tue, 5 Jan 2021 15:57:31 -0500 Cc: John C Klensin , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 20:57:37 -0000 I don=E2=80=99t think it=E2=80=99s that hard. Example: I work on the emergency call system, 9-1-1 in the U.S. There is a new = system, Next Generation 9-1-1, which is based on a number of IETF RFCs = including the SIP RFCs (3261,=E2=80=A6) and several specific emergency = call RFCs such as RFC6881, RFC4119, RFC5222. There is a technical standard, NENA-STA-010, which has a normative = reference to these IETF standards. I work with states deploying this = system. They have RFPs that require adherence to NENA-STA-010, and = often expressly require support of the referenced standards. Vendors = respond to the RFPs and commit to various levels of conformance. They = get into contracts that commit them to conformance. So the customers are the state government entities, although they = don=E2=80=99t read the RFCs initially, and the vendors, who do. I have = been specifically involved with verification and validation studies that = are commissioned by a state to determine if the winning vendor=E2=80=99s = software meets the contract requirements. Sometimes we do find cases = where they don=E2=80=99t implement the standard, and we point that out = to the state. The state then decides if they believe that constitutes a = violation of the contract. Usually, they negotiate some kind of = =E2=80=9Ccure=E2=80=9D, mostly time to come into conformance. =20 That=E2=80=99s a pretty clear case of how an RFC, and conformance to it, = gets into contracts, and testing, and potentially legal wrangling = (although the latter hasn=E2=80=99t occurred on an RFC compliance issue = in my experience yet). None of the entire universe I=E2=80=99ve = described, other than me, typically participates in the IETF process. = Some (vendors) read the documents, and implement them. Brian > On Jan 5, 2021, at 3:11 PM, Brian E Carpenter = wrote: >=20 > Excuse front-posting but I think I'm setting off in yet another > slightly different direction. >=20 > Do we even *know* in any meaningful way who reads RFCs apart from > people active in the existing four streams? >=20 > Yes, we assume that the readers include operators, implementers, > procurement departments, government officials, academics etc., but we > don't have a real analysis; we don't know how many people this means > and we certainly don't have a mailing list. (FYI there are 367 email > addresses subscribed to rfc-interest, which means that it is clearly a > small fraction of the customers. Although I would love to know who > 1152701570@qq.com, 243372854@qq.com and their numerical friends are.) >=20 > I feel that before we make too many assumptions about how to represent > the customers, we need some actual facts about who they are and how > we could talk to them. Getting those facts might cost some momey and > effort, but I think it would be justified. >=20 > Regards > Brian >=20 > On 05-Jan-21 15:02, John C Klensin wrote: >>=20 >>=20 >> --On Tuesday, January 5, 2021 13:32 +1300 Brian E Carpenter >> wrote: >>=20 >>> On 05-Jan-21 12:04, Russ Housley wrote: >>>> Looking at RFC 8728, there is an expectation that the RSE >>>> should see the stream manager as customers. RFC 8728, s2.1: >>>> "The RSE is expected to cooperate closely with the IETF LLC >>>> and the stream managers." I always assumed that the IETF LLC >>>> was included here because that is the legal entity that holds >>>> the contract, not because they represent an additional >>>> customer. >>>>=20 >>>> In addition, RFC 8728, s2.1.2.1.2 says that the RSE makes >>>> policies that are good for the "broader Internet community". >>>> However, I do not think we have reached consensus on the >>>> topic of "customers". We do not have a way to represent the >>>> broader community as an RFC Series customer. The idea of a >>>> NomCom selected at-large person has been suggested, but I do >>>> not think that is not going to make it better. >>>=20 >>> Agreed, that is more of a mechanism to reduce the chances of >>> groupthink. >>>=20 >>> I think the best thing we can do at the level of process & >>> structure is what we already seem to agree about - having an >>> open, anyone-can-join discussion forum. We could of course do >>> things like open, anyone-can-answer surveys when there are >>> specific questions to be answered but that's an operational >>> matter. How the discussions & surveys are made known to the >>> wider community also seems like an operational matter, as part >>> of outreach in general. >>>=20 >>> Probably we should define clearly who's responsible for such >>> outreach. >>=20 >> Brian, >>=20 >> While I agree with all of that, I think it is important to come >> back to Russ's question, which is one that has been a problem >> for this effort for well over a year now. While I don't think >> it is helpful to try to prioritize "customers" or what we might >> call stakeholders in another context, there are at least three >> groups of users of the series we tend to forget about (or >> excessively de-emphasize) as we try to sort through issues of >> representation, questions to be answered when we think about >> surveys, and particular needs. >>=20 >> Two examples: >>=20 >> (1) Despite our best efforts, and often a good degree of >> consensus within the IETF, sometimes we produce specifications >> that either do not work or that fail to get traction. In some >> cases, the reason, at least in retrospect, is that we solved a >> problem that no one cared about or that was just overtaken by >> events. In others, we just get it wrong or discover that we >> solved the wrong problem. Especially in the latter cases, and >> also when the consensus turns out to be somewhat rough, it is >> important to have good records of different ways that the issues >> were thought about, different proposed solutions, etc., so that, >> if we need to come back to the topic(s), we have the potential >> for getting a head start and not reinventing the previous style >> of wheel. While, as things are defined today, this mostly >> interacts with the Independent Stream, I note that (regardless >> of what the authors intended) RFC 8789 does not prohibit >> publishing a document with which the IETF participant community >> is in violent disagreement as long as there is IETF consensus >> that it should be published. >>=20 >> (2) Part of the use of the RFC Series is to publish standards, >> as distinct from, e.g., evolving engineering specifications. A >> key audience for standards are people using them in procurement >> specifications and expecting that assertions of conformance on >> the part of those producing products will be meaningful, stable >> enough to outlast procurement cycles, and helpful in predicting >> interoperability and interchangeability. Precisely because we >> sometimes lose sight of that distinction and its importance, it >> is important that the RFC Editor function (as well as relevant >> streams and the IANA function) be sensitive to the issues >> involved and the constraints they put on the style and >> presentation of publications. >>=20 >> We have had, and will probably continue to have, difficulty >> getting good direct representation of those interests. Even if >> we could find a token procurement person or two (of the >> bean-counting subspecies or otherwise) and get them into a WG, >> panel, board, or survey population, it is not clear that we are >> good at listening or putting ourselves into their positions and >> perspectives. However, that does not make the perspective and >> requirements any less important. >>=20 >> best, >> john >>=20 >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue Jan 5 13:17: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 225523A0115 for ; Tue, 5 Jan 2021 13:17:14 -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 QSRoDwrIA5vO for ; Tue, 5 Jan 2021 13:17:12 -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 1D69C3A0114 for ; Tue, 5 Jan 2021 13:17:12 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kwthW-0001YV-Kw; Tue, 05 Jan 2021 16:17:10 -0500 Date: Tue, 05 Jan 2021 16:17:04 -0500 From: John C Klensin To: Brian E Carpenter , rfced-future@iab.org Message-ID: In-Reply-To: <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:17:14 -0000 --On Wednesday, January 6, 2021 09:11 +1300 Brian E Carpenter wrote: > Excuse front-posting but I think I'm setting off in yet another > slightly different direction. > > Do we even *know* in any meaningful way who reads RFCs apart > from people active in the existing four streams? > > Yes, we assume that the readers include operators, > implementers, procurement departments, government officials, > academics etc., but we don't have a real analysis; we don't > know how many people this means and we certainly don't have a > mailing list. (FYI there are 367 email addresses subscribed to > rfc-interest, which means that it is clearly a small fraction > of the customers. Although I would love to know who > 1152701570@qq.com, 243372854@qq.com and their numerical > friends are.) > > I feel that before we make too many assumptions about how to > represent the customers, we need some actual facts about who > they are and how we could talk to them. Getting those facts > might cost some momey and effort, but I think it would be > justified. Brian, While I am very sympathetic to you desire for that information, there are at least two problems with trying to get those data of which you (and we) should be aware). (1) Even for rfc-interest, it is easy to tell how many people are subscribed, but hard or impossible to tell how many are actually reading it, much less to characterize the profiles of the latter. In particular, remembering that we require that people sign up for a list to post to it, which can (and occasionally demonstrably has) resulted in people signing up to some IETF lists to post a one-time comment (often good) or to spam the list (almost never good), there may be such signups there. Possibly relevant, I assume I'm not the only person who is at least fairly active in the IETF and on this list, who is subscribed for digests, and who might actually read them a couple of times a month. (2) The procurement people I'm concerned about typically use and cite RFCs but it is very rare that they actually read them. Instead, they are typically told by others (sometimes even us) which RFCs describe a particular set of requirements and they dutifully write them into contracts. Only if something goes wrong that appears to be a problem --one for which the specifications in those RFCs would seem to be applicable-- do people in their sphere of influence and authority typically start reading. Those "people" are often lawyers and those supporting them. That does not make the procurement types any less important as users of/ customers for RFCs. It makes having the specs clear and precise enough that it is possible to tell what is supposed to be conforming behavior and what is not (as Christian points out, that is not a problem the RFC Editor can affect very much... and we have steadily reduced how much over the last decade or two) but also that they documents themselves and their presentation be stable enough that there is minimal possibility of disputes over, or having to do estensive detective work to infer, exactly when the specification was at the time contracts were signed or went into effect. john From nobody Tue Jan 5 13:23: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 CB55E3A0365 for ; Tue, 5 Jan 2021 13:23:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.262, 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 (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bYuSWDlXDgn for ; Tue, 5 Jan 2021 13:23:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDECB3A033F for ; Tue, 5 Jan 2021 13:23:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AE496BE3E; Tue, 5 Jan 2021 21:23:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJhoDF2szmCQ; Tue, 5 Jan 2021 21:23:01 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CE92CBE24; Tue, 5 Jan 2021 21:23:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1609881781; bh=/JwrBv2PVBt9f3O3Lxdkn1nRvm8pCM2IBamFwIqUBIo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=SYJ7R+BfSKiUzeyOaIEDFEyFhsYpIA/av5FHSx6Z5W4/Q1+krF5dwPKth8pbTdfkP NlavB+T6Gdw24SEQ9t4eute+M4KeUTdPE/p2XoXC+QFzkjGx/gEtxZhi+4aJQnuRVV Sb0XYT9ot7FbCW8seD7WPBYgqU2REr7588wkilRs= To: Brian E Carpenter , rfced-future@iab.org References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> From: Stephen Farrell Message-ID: <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> Date: Tue, 5 Jan 2021 21:22:58 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZWgmgItg9uUfmM4yGNwXLzZTIk9x1qne4" Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:23:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZWgmgItg9uUfmM4yGNwXLzZTIk9x1qne4 Content-Type: multipart/mixed; boundary="yC1pFub8Shah06KRx8xMntCiG36Lh82vG"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , rfced-future@iab.org Message-ID: <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> Subject: Re: [Rfced-future] Who are the customers? References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> In-Reply-To: <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> --yC1pFub8Shah06KRx8xMntCiG36Lh82vG Content-Type: multipart/mixed; boundary="------------5DD92A67D95EEB7ADBD2AC0B" Content-Language: en-US This is a multi-part message in MIME format. --------------5DD92A67D95EEB7ADBD2AC0B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 05/01/2021 20:11, Brian E Carpenter wrote: > Getting those facts might cost some momey and > effort, but I think it would be justified. If we do need to know more about that (*), then wouldn't that really be a task for an incoming RSE and not this group? Cheers, S. (*) I'm not really convinced yet - I do think we know enough about who those readers are, we just don't know if they care about all the stuff we're talking about here;-) And I'm not sure that's a thing we could usefully find out about TBH. --------------5DD92A67D95EEB7ADBD2AC0B Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------5DD92A67D95EEB7ADBD2AC0B-- --yC1pFub8Shah06KRx8xMntCiG36Lh82vG-- --ZWgmgItg9uUfmM4yGNwXLzZTIk9x1qne4 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl/02LMFAwAAAAAACgkQWrL68XsXK+oX yw/6AzBVRVua6ePvL6KkeKd/dsd6koh4EHdvwgnQgA0eLXJMLyamobYFOheIvOQHgR0IGnvozMKs AoUT5V5loAxCIxkHIklF45XHiAm5NSbnLR47hL/1J8Q+0ejrMhWcxhAjUOwfqhn8dtrHmOym7rso q/jf+4gt11cY/oMAZ22lSClnirynP2WlgU9kSaIFe1MOxEeA9alnUO6TeRVp2e4KIuSDFr43XG0T xWvKEvSGwZmwGhqrJaDwMDueejYaZpxI/obgT2Xf6nxjUwubXscwSbq3E6NtGiohrdr33zMEIHwN mGloINMD//UUQClTE+BShUvWTUL/0pxz/aKHCz5ej3i5815UBKIoSFlimW/uWJuNu8dP5hL2SR4h vsDTptq06fL4frJtJv6AK2MlvC/cb4lRCma70Tv7ezxHgbrfYfuLLIYAP+KUYi/KznQBxyBaoYsS qIXOGX79Wks/q9XRnu1SuXzBXbjaRqeJImviWCNfAlxe+tvZbfqHVuuWh3xCuWNu33XeFeq8lUth 62002m2bYksMmzGA42LPdbtUXk93dyuoLaRl4kX7NZf1mFSzDt5D9myYCCoUw3yFjWS/epm4FxSC R8/blcKnsuCZD71GAzGnsUEQjVu3RM7JUWr9VUykW5pvdfZzNQrmrhiogxy8YLv4QR6PSstRmBun w6g= =wGcm -----END PGP SIGNATURE----- --ZWgmgItg9uUfmM4yGNwXLzZTIk9x1qne4-- From nobody Tue Jan 5 13:24:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71D4A3A03F4 for ; Tue, 5 Jan 2021 13:24:27 -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 mQpXFjDPBocC for ; Tue, 5 Jan 2021 13:24:26 -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 486C03A03F1 for ; Tue, 5 Jan 2021 13:24:26 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kwtoV-0001bO-VQ; Tue, 05 Jan 2021 16:24:23 -0500 Date: Tue, 05 Jan 2021 16:24:17 -0500 From: John C Klensin To: Brian Rosen , Brian E Carpenter cc: rfced-future@iab.org Message-ID: In-Reply-To: References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:24:27 -0000 Brian, An excellent and specific example of what I was trying to describe in more general terms in a note that crossed yours in the email. The situation you describe is a little special (but typical of procurements and contracts in regulatory/ regulated environments) because a third party, outside the organization structure of the procurement person or department, is determining what RFCs are required and referenced. In a more typical commercial environment, it is the RFCs that are referenced rather than an intermediate industry or regulatory standard (not developed by the IETF) that, in turn, references them.=20 I don't think that, in the end, that distinction is very important to the understanding Brian Carpenter is looking for. Hence +1 to what you wrote. john --On Tuesday, January 5, 2021 15:57 -0500 Brian Rosen wrote: > > I don't think it's that hard. >=20 > Example: > I work on the emergency call system, 9-1-1 in the U.S. There > is a new system, Next Generation 9-1-1, which is based on a > number of IETF RFCs including the SIP RFCs (3261,=E2=80=A6) = and > several specific emergency call RFCs such as RFC6881, RFC4119, > RFC5222. >=20 > There is a technical standard, NENA-STA-010, which has a > normative reference to these IETF standards. I work with > states deploying this system. They have RFPs that require > adherence to NENA-STA-010, and often expressly require support > of the referenced standards. Vendors respond to the RFPs and > commit to various levels of conformance. They get into > contracts that commit them to conformance. >=20 > So the customers are the state government entities, although > they don't read the RFCs initially, and the vendors, who do. > I have been specifically involved with verification and > validation studies that are commissioned by a state to > determine if the winning vendor's software meets the > contract requirements. Sometimes we do find cases where they > don't implement the standard, and we point that out to the > state. The state then decides if they believe that > constitutes a violation of the contract. Usually, they > negotiate some kind of "cure", mostly time to come into > conformance. =20 >=20 > That's a pretty clear case of how an RFC, and conformance to > it, gets into contracts, and testing, and potentially legal > wrangling (although the latter hasn't occurred on an RFC > compliance issue in my experience yet). None of the entire > universe I've described, other than me, typically > participates in the IETF process. Some (vendors) read the > documents, and implement them. >=20 > Brian From nobody Tue Jan 5 13:31: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 9F0AE3A07F5 for ; Tue, 5 Jan 2021 13:31:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.36 X-Spam-Level: X-Spam-Status: No, score=-2.36 tagged_above=-999 required=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.262, 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 yKEblaXJ_zz3 for ; Tue, 5 Jan 2021 13:31:34 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B5513A07EA for ; Tue, 5 Jan 2021 13:31:34 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id c79so504005pfc.2 for ; Tue, 05 Jan 2021 13:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=DVI7YFBcMABqp6ZfOZPCwLlDeEDQ2y3rfmzSpr9Ig8o=; b=MpBnvnnSaFVnW6KhHpInQPVkKKEu6HtJ215ES9yGrT2y60prytIZaugXHOevpKz4UF thf9SWrUFEYRkKSS1/dSKCgAFdWOsa1EB+3H3Oz9AoWTg2j8U/I+mzfjUgnC8iUN9Pdd AHofdm8BufRc8bGxxxHvA87sLR2EDkTiH88hOgaX5P+InXhj8bhbJTocMEDdP4NGqECE KAdtz2auNDJ8Ccdn7fLdSf9XP5EXZ6uEoulq+HXGkjd43wl1+sLMGv8PyFZReQDpfNPi Ce6Sg1AWoelxYEBTDP067oXvZw5Sg9mV6h3F0qsHEKNFRBpi7GTSKpeCEdQBfwu234/N GrfA== 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=DVI7YFBcMABqp6ZfOZPCwLlDeEDQ2y3rfmzSpr9Ig8o=; b=ugUSyNuGvzRSWWy7+FGBC8ztMS/PZRm+XKoM3iuWj3TzFycsdI9i64OxTcjfduc9Dk GGz6iA7x0gHTL6Y1IQvwRpGrVgyLnSnvIFkhxiIIAhn13ZqwKKS73nTe1O9UpNOsb99x vcwaB2UHsm7+WriHW8101vFFv6AIHVmZuosf7B2VBu0wUgSJpu+GoFLfESdIrfHN9JJ3 Zm+kH5SCofCJYFDBJy6AJPHnDs/Ni5dEoIuzBIeL4WJOAUSh9BIGBAzE6rNOdG+3ufrd x4x9jQieJ+Dv7L21GaKahIW7nj5w/edRcq6Sve4VCCygQjt7nBtCGIvyJdB933MkRZIP lx0g== X-Gm-Message-State: AOAM5323UbTfkZMNQCDOOooFTQYsj33WsS7cCv+dOD5aPWUDeYi2G3Lb a3RVK1ve3BwkppM9fRylgLFyDif7xwZK6A== X-Google-Smtp-Source: ABdhPJwPQAxcRAI2eydmy5xHi7AfxbKlDfGYymCDozCDe2VtK2KbA+dMupWcUywPn+HtBZ5m0VDcsA== X-Received: by 2002:a62:e408:0:b029:19e:2c4b:6a8e with SMTP id r8-20020a62e4080000b029019e2c4b6a8emr958548pfh.30.1609882293614; Tue, 05 Jan 2021 13:31:33 -0800 (PST) Received: from [192.168.178.25] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id v6sm297089pfi.31.2021.01.05.13.31.31 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Jan 2021 13:31:32 -0800 (PST) To: Stephen Farrell , rfced-future@iab.org References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> From: Brian E Carpenter Message-ID: Date: Wed, 6 Jan 2021 10:31:28 +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: <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:31:36 -0000 On 06-Jan-21 10:22, Stephen Farrell wrote: > > Hiya, > > On 05/01/2021 20:11, Brian E Carpenter wrote: >> Getting those facts might cost some momey and >> effort, but I think it would be justified. > > If we do need to know more about that (*), then > wouldn't that really be a task for an incoming > RSE and not this group? > Except that at the moment we have no idea how best to represent the requirements and issues of those customers in the "open" strategy discussion. In that sense, there are empty seats at the table. (And I am not disagreeing with John Klensin's or Brian Rosen's comments at all. Just observing that the majority of the customers simply aren't represented in our discussions.) Brian > Cheers, > S. > > (*) I'm not really convinced yet - I do think we > know enough about who those readers are, we just > don't know if they care about all the stuff we're > talking about here;-) And I'm not sure that's > a thing we could usefully find out about TBH. > From nobody Tue Jan 5 13:42: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 B62083A0864 for ; Tue, 5 Jan 2021 13:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.261 X-Spam-Level: X-Spam-Status: No, score=-2.261 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GyP90bw0rpP3 for ; Tue, 5 Jan 2021 13:42:34 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8D03A085E for ; Tue, 5 Jan 2021 13:42:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B34A0BE2E; Tue, 5 Jan 2021 21:42:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPHg9PH4tO0x; Tue, 5 Jan 2021 21:42:26 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id C4C51BE24; Tue, 5 Jan 2021 21:42:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1609882945; bh=f58xLHtt/uM2UbrPSuMLBgNXPdyVN5HoHvwM+aj9g70=; h=Subject:To:References:From:Date:In-Reply-To:From; b=NUvMS5JbVyzOvFIw5Kl5LEw238LO3mwGYlLUMTcU+qo221+4+PkIQ49oMpIjSTmTL wG5da/7WASDYAazxEc1o3iNsBT3ndh5VtzR81Sv3E4yknTXSorgLAp+dP67VXX1Qv+ aSwWRDC9yw6zz/W1JsXXaeVL/1xkT5fCRxWeNDmo= To: Brian E Carpenter , rfced-future@iab.org References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> From: Stephen Farrell Message-ID: <698db290-48d2-d4ed-6271-a452464f19c9@cs.tcd.ie> Date: Tue, 5 Jan 2021 21:42:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6cudcp36oBWAxEFnyI3yqTkLIGbCcQkOr" Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:42:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --6cudcp36oBWAxEFnyI3yqTkLIGbCcQkOr Content-Type: multipart/mixed; boundary="scz3iRURv0JSTBrHafu1Id76e2vnqeD9Z"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , rfced-future@iab.org Message-ID: <698db290-48d2-d4ed-6271-a452464f19c9@cs.tcd.ie> Subject: Re: [Rfced-future] Who are the customers? References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> In-Reply-To: --scz3iRURv0JSTBrHafu1Id76e2vnqeD9Z Content-Type: multipart/mixed; boundary="------------C342631A6A9172030638D18C" Content-Language: en-US This is a multi-part message in MIME format. --------------C342631A6A9172030638D18C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 05/01/2021 21:31, Brian E Carpenter wrote: > Except that at the moment we have no idea how best to > represent the requirements and issues of those customers > in the "open" strategy discussion. In that sense, there > are empty seats at the table. (And I am not disagreeing > with John Klensin's or Brian Rosen's comments at all. > Just observing that the majority of the customers simply > aren't represented in our discussions.) Sure. (As an aside, I'd prefer call them readers and not customers - the latter seems to me to have an unintended assumption that all readers that count are doing something commercial, and I don't think that's true.) I still think that finding out about all that, and maybe proposing what, if anything to do about the results, seems like a fine thing for an RSE to do, and impractical before we have a new RSE. (So maybe we're identifying another characteristic of a good incoming RSE - be able to go find out who reads RFCs and what they might want and bring that info and/or proposals back to the putative "strategy WG" for consideration.) Cheers, S. --------------C342631A6A9172030638D18C Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------C342631A6A9172030638D18C-- --scz3iRURv0JSTBrHafu1Id76e2vnqeD9Z-- --6cudcp36oBWAxEFnyI3yqTkLIGbCcQkOr Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl/03UAFAwAAAAAACgkQWrL68XsXK+ry iw//X1/eI+I503MVh4AjjfCr0nh4CsPBf1MUopTrlqweCqG66pmIZ7pFjW27dv0WQiynIPtZ3jLc rAC48T6VU7c4yZdU84QFgjCoke3q6LPfc0rfhyqPBQnvYG6QMMWHVHAqmEBHwXmvbh1R6FdvRL5Q /0eIzAMjfhFu37m5M7AJiVGptXmbKQYOC9q1BBQfdGjL1jXuoIgRqNdFlpKWf+tx/vXugFbXxUa9 zTS5hxYDB+38pJjz3QOGCJvIbE80xADZxOPsAK8l5cvKvTwHnJm1oa1P4Il4LsTKv6vbQNZrKhjO HDQYrhOTHrw1ZeLfkchuzK6TVEleJgb2Rb1+sdEWuMW9Jw2QPQfDPeB/SUc2Dm1KvNp/D3WyL+q8 zdQHkOy34j++EpJ5LxxzCaYVIpj0D+M46/z0cV3k0428JVdLfFQwB/u8UgnToWONxNWA5nouFJzl uEvsVZRov5LBv95bm89l+2VlQeaxiitoHcMbrW+Ww+0snsffd+6iqfvhJdEoWfHuOXjThOPRE7yR GUaJFpEc6wAS/8196AUmXPsprxVypGZntBKqnubMB2L70lLwCpKrHhZ6LS6UajsCUzZOXQmw4Dmc biJ3+upUGRwducJyXM+82d4e+Gip58+wTgCYyd13hfr3jzUPIKMgf0WBtdDxH3FqIraHqmcW49fa N7Q= =fABS -----END PGP SIGNATURE----- --6cudcp36oBWAxEFnyI3yqTkLIGbCcQkOr-- From nobody Tue Jan 5 13:44: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 7E35B3A09BC for ; Tue, 5 Jan 2021 13:43:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJKl1Wjsoe0I for ; Tue, 5 Jan 2021 13:43:51 -0800 (PST) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FE3D3A0ADD for ; Tue, 5 Jan 2021 13:43:51 -0800 (PST) Received: by mail-lf1-x12f.google.com with SMTP id h22so2013661lfu.2 for ; Tue, 05 Jan 2021 13:43:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=BPx5wiz/k2xC6aIWh7SO2uvaInaeZQE6+hN8LvwBdCQ=; b=zaK6M+99wPQ/c0BRsQwXB9vKHZwz8zbm/0tWid5QZKdJi+8wd8i7ZGaGOYa62EWKmO moj9XVMM7pAADlDBbjkXgvv4CAkie3R/37IouL8Pxmn5flrB2DbmkwLIzuqEkQn2KFJA nSev3Y5ngnmVt6sfSw1GZ9T5634u6+AFQqqVsD/1/CqId67Oe5B+SUbqZVSqpJzvgnTQ ilqMvuPGe00YvxVNdsLsrTntEMI3c92AzO55zmCksR/H4plj52or5ya+SAyR28W5bLE6 ZP44NcfvKmwMEcDalNgOopCeFylFPeFYJUak0WB2QD0ld196i5kUpXz5JkZH0Soqd4zs UKOw== 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=BPx5wiz/k2xC6aIWh7SO2uvaInaeZQE6+hN8LvwBdCQ=; b=jTCiEiq/lN/yg8+JQc490skvxglYd8ZEadr0F1V2r7+AeoQGyazfdOuWTvYmNGGt1w VUuw7ttVcrzlze2+OZVYdBpfYKvqzlAwaTsOGrvk3fcAimMJ9+E2LDmATTzNByCeUYK0 lUoxzz4nlScr9qUi3emg+twZ0HnKq3N+0ij49uMjY9vrdQxQ2k38jnkDboR3Ivm14G7s DJ9gtyq4yZO9Ih+ybxVaDhb50OkVHRZ3MUpfMhgkX82MANvGwjZEr2vuPzElRgu1B8hM BrSdY2gnuJaIZnkd3S6iQ+nBOX3iVy6pTCDNtZN/0lLxEiIXbOZmN5JHZKOAB/rHG9FV oC+A== X-Gm-Message-State: AOAM5330IqLUbotkqw7JZ9LAOcljOmso/N6VCs4thVMjRwNbQNRCf7mR NEZF1yHbkWJknSt9WR2V3aWWDNrjNq2AD8P+aDLwpQ== X-Google-Smtp-Source: ABdhPJwD/pmW21rKNrBs7cZvWIs/MXMueJG77IB2FIJ0DGuZpbVkXAveQns9I37suGFKx9akP8DVd0HInh9fFjm8Ka4= X-Received: by 2002:a05:6512:3284:: with SMTP id p4mr503395lfe.245.1609883029647; Tue, 05 Jan 2021 13:43:49 -0800 (PST) MIME-Version: 1.0 References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> In-Reply-To: From: Eric Rescorla Date: Tue, 5 Jan 2021 13:43:13 -0800 Message-ID: To: Brian E Carpenter Cc: Stephen Farrell , rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000001ccfd605b82e1af2" Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 21:43:59 -0000 --0000000000001ccfd605b82e1af2 Content-Type: text/plain; charset="UTF-8" On Tue, Jan 5, 2021 at 1:31 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 06-Jan-21 10:22, Stephen Farrell wrote: > > > > Hiya, > > > > On 05/01/2021 20:11, Brian E Carpenter wrote: > >> Getting those facts might cost some momey and > >> effort, but I think it would be justified. > > > > If we do need to know more about that (*), then > > wouldn't that really be a task for an incoming > > RSE and not this group? > > > > Except that at the moment we have no idea how best to > represent the requirements and issues of those customers > in the "open" strategy discussion. In that sense, there > are empty seats at the table. (And I am not disagreeing > with John Klensin's or Brian Rosen's comments at all. > Just observing that the majority of the customers simply > aren't represented in our discussions.) > Isn't this generally true? If you think of the IETF's ordinary output as technologies as opposed to specifications, then it seems like the customers of those technologies (e.g., end-users) basically aren't represented at IETF. It's not clear to me how this is different. Indeed, arguably it's better in that IETF participants generally are direct consumers of technical specifications -- though of course not the only consumers -- so hopefully have some idea of the concerns of other consumers. -Ekr > Brian > > > Cheers, > > S. > > > > (*) I'm not really convinced yet - I do think we > > know enough about who those readers are, we just > > don't know if they care about all the stuff we're > > talking about here;-) And I'm not sure that's > > a thing we could usefully find out about TBH. > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000001ccfd605b82e1af2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Jan 5, 2021 at 1:31 PM Brian = E Carpenter <brian.e.carp= enter@gmail.com> wrote:
On 06-Jan-21 10:22, Stephen Farrell wrote:
>
> Hiya,
>
> On 05/01/2021 20:11, Brian E Carpenter wrote:
>> Getting those facts might cost some momey and
>> effort, but I think it would be justified.
>
> If we do need to know more about that (*), then
> wouldn't that really be a task for an incoming
> RSE and not this group?
>

Except that at the moment we have no idea how best to
represent the requirements and issues of those customers
in the "open" strategy discussion. In that sense, there
are empty seats at the table. (And I am not disagreeing
with John Klensin's or Brian Rosen's comments at all.
Just observing that the majority of the customers simply
aren't represented in our discussions.)

=
Isn't this generally true? If you think of the IETF's ordinary= output as technologies as opposed to specifications, then it seems like th= e customers of those technologies (e.g., end-users) basically aren't re= presented at IETF. It's not clear to me how this is different. Indeed, = arguably it's better in that IETF participants generally are direct con= sumers of technical specifications -- though of course not the only consume= rs -- so hopefully have some idea of the concerns of other consumers.

-Ekr


=C2=A0 =C2=A0Brian

> Cheers,
> S.
>
> (*) I'm not really convinced yet - I do think we
> know enough about who those readers are, we just
> don't know if they care about all the stuff we're
> talking about here;-) And I'm not sure that's
> a thing we could usefully find out about TBH.
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000001ccfd605b82e1af2-- From nobody Wed Jan 6 01:12:03 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DEF3A123E for ; Wed, 6 Jan 2021 01:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZVVoIEPAOE8 for ; Wed, 6 Jan 2021 01:12:01 -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 9AA6D3A123D for ; Wed, 6 Jan 2021 01:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6805; q=dns/txt; s=iport; t=1609924320; x=1611133920; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=F8z63rRk4w9AkViCQPP3PPlgXWyAUXbhi9UFe+VFscI=; b=fxzsloFzz7USHY0xFTr1gJ8s5WCMDzU1r5cl8js4h9a9rSqoB9Wx1rIQ kaSaiTQE8h1AcjWy7VgDdTBirIGwso+bG0UjjDQtt+MSoO+5z7gSX6D3p TGajS1uI5ZMRoBXQENe9i4InWyi7JgAXwI3HZf/X5T1tBdDkaPv8ebhFQ k=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BUAQAPfvVf/xbLJq1iHQEBAQEJARIBBQUBgX4FAQsBg?= =?us-ascii?q?XUGgXwBIBIuhD+JBIgMJQOUHIY1gWgEBwEBAQoDAQEvBAEBhEoCgXAmNwYOA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgRxhW2FcwEBAQMBI1YFCwsYKgICVwYTgltLA?= =?us-ascii?q?YJmIK4jdoEyhViEYxCBOAGBUotYQYIAgTgMEIJWPoQAg1Y0giwEgldNAQNzg?= =?us-ascii?q?UUVBgKcR5wpgwCDJ4E3ln4DH6JXjk6jC4NvAgQGBQIWgWwkgVczGggbFWUBg?= =?us-ascii?q?j4+EhkNnGtAAzA3AgYBCQEBAwmNFAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,479,1599523200"; d="asc'?scan'208,217";a="30000472" 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; 06 Jan 2021 09:11:56 +0000 Received: from ams3-vpn-dhcp6586.cisco.com (ams3-vpn-dhcp6586.cisco.com [10.61.89.185]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 1069BtM5025246 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Jan 2021 09:11:56 GMT From: Eliot Lear Message-Id: <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_10062FB5-5EF5-4012-8E6F-74BDFED9878C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Wed, 6 Jan 2021 10:11:54 +0100 In-Reply-To: <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> Cc: rfced-future@iab.org To: Michael StJohns References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <056684f2-ab2c-5b85-4dfd-bada78e1e528@joelhalpern.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.89.185, ams3-vpn-dhcp6586.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 09:12:03 -0000 --Apple-Mail=_10062FB5-5EF5-4012-8E6F-74BDFED9878C Content-Type: multipart/alternative; boundary="Apple-Mail=_33300A71-26DC-45AD-9C2A-6502966E153B" --Apple-Mail=_33300A71-26DC-45AD-9C2A-6502966E153B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Jan 2021, at 20:01, Michael StJohns = wrote: >=20 > Hmm... I didn't realize the role of the chair included ignoring = submissions? If you disagreed with what I proposed, then say so and = why, rather than just passing over it. >=20 > In any event, it's not the chair's role to imagine consensus, rather = the role requires you to actively seek it. Not your job to tell the chairs what the chair's job is in this forum. = If you have a complaint, take it up the chairs privately or with the = IAB. >=20 > I could see something like GIT being used for a document such as the = XML vocabulary which might benefit from a fast iteration = (propose/implement/test/approve or remove) model. However, reviewing = the documents that had Heather as the author or editor, I think for = the most part they benefited from the slow iteration model of publish = draft/receive comments/revise draft. >=20 > Or more bluntly, forcing the development of all documents into one = model with many micro authors may actively harm or substantially delay = the production of some documents necessary to evolve the series. cf = RFC8153 for an example of a document which might have been harmed or = delayed. See Brian=E2=80=99s response, but your proposal runs counter to the = compromise that Joel and EKR were aiming toward, and would require folks = like EKR and Mark to drag the entire WG into a per document debate which = I don=E2=80=99t for a moment believe there would garner their or = others=E2=80=99 approval. However, I am happy to be proven wrong. > I see the proposed language here as an attempt to allow for the later = imposition of a model which will always micromanage the authors by = random participants and I just don't think that's sustainable or useful. Where do you see that imposition being made? What the text says is that = the WG will decide on its communication methods based on rough = consensus. Eliot --Apple-Mail=_33300A71-26DC-45AD-9C2A-6502966E153B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 5 Jan 2021, at 20:01, Michael StJohns <msj@nthpermutation.com> wrote:

=20
Hmm... I didn't realize the role of = the chair included ignoring submissions?  If you disagreed with = what I proposed, then say so and why, rather than just passing over = it.

In any event, it's not the chair's = role to imagine consensus, rather the role requires you to actively seek it.

Not your job to tell the chairs what the chair's job is = in this forum.  If you have a complaint, take it up the chairs = privately or with the IAB.


I could see something like GIT being used for a document such as the XML vocabulary which might benefit from a fast iteration (propose/implement/test/approve or remove) model.   However, reviewing the documents that had Heather as = the author  or editor,  I think for the most part they = benefited from the slow iteration model of publish draft/receive comments/revise draft. 

Or more bluntly, forcing the development of all documents into one model with many micro authors may actively harm or substantially delay the production of some documents necessary to evolve the series.  cf RFC8153 = for an example of a document which might have been harmed or delayed.

See = Brian=E2=80=99s response, but your proposal runs counter to the = compromise that Joel and EKR were aiming toward, and would require folks like EKR and Mark to drag the entire WG = into a per document debate which I don=E2=80=99t for a moment believe = there would garner their or others=E2=80=99 approval.  However, I = am happy to be proven wrong.

I see the = proposed language here as an attempt to allow for the later imposition = of a model which will always micromanage the authors by random = participants and I just don't think that's sustainable or = useful. 

Where do you see = that imposition being made?  What the text says is that the WG will = decide on its communication methods based on rough = consensus.

Eliot
= --Apple-Mail=_33300A71-26DC-45AD-9C2A-6502966E153B-- --Apple-Mail=_10062FB5-5EF5-4012-8E6F-74BDFED9878C 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/1ftoACgkQh7ZrRtnS ejMA5ggAxTCj+wtWLXG1++AYeXpaF0x1CKJL9ZRvtpvO9Scv+wSmaelkYJBGKo6H 3D7iV9H05pydA4OyZIWBuT52KJTx93kR5pMviEGlAuMkphsy8ZFfpjBhNGe/U0gm 6koufXxnXoIw7ZaYcqpYt9syYBD80QiwryERt/Zi5/OSQ2KZE2u4xCNruV9xnBmu i8So4cZfDtJU7b6Y8zFvy5uo2unkE8qZW4jQvpZ3UavOyMf5TSF+Juyzda8X5smt M5xSzNqFMeJUv59Bnu7BeUvGg92PtBG4B6yAlPqH93wMutvyOzcNX1PAY479uBqV QH3AbHBa02e41Lqd/c6G6X/xer8zFQ== =/63a -----END PGP SIGNATURE----- --Apple-Mail=_10062FB5-5EF5-4012-8E6F-74BDFED9878C-- From nobody Wed Jan 6 07:29: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 B10A63A0E9F for ; Wed, 6 Jan 2021 07:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SnZBeYTWy_Pq for ; Wed, 6 Jan 2021 07:29:27 -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 23AB13A0EA4 for ; Wed, 6 Jan 2021 07:29:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8694; q=dns/txt; s=iport; t=1609946967; x=1611156567; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=wN3NarhF6tOBCx555B9AAqT2pf4Zw6NC6qlunulI+I0=; b=OloF2DMJfIKLs/NWeYk7hg44fjNNKE4u/9xksaa3+HBT0wMMq4kFecMF AOMs2vNbVT46yEkgkvNpjqGZO+bSD47VFamVnvd462lfa8cTnd4/cluR8 ycvVUma8pyuvT+CzAMaD9psu5L00LTOsTzwMOQwmAjM+XGlHFDsGqLn5Q M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BsAgCZ1vVfjBbLJq1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4MhVwEgEi6EP4kEiDEDihuKAYgdBAcBAQEKAwEBGAEKDAQBAYRKAoFwJjgTA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAYY6DIVzAQEBAwEBASFLCwULCQIOC?= =?us-ascii?q?icDAgIhBh8RBhODJgGCVQMOIA+SZ5sSdoEyhViCQQ2CFAoGgTiBU4YlhTNBg?= =?us-ascii?q?gCBOByBWH4+ghtCAYIWgmI0giwEgwABGGIiOTVMZ5JSiTSbUViDAIMngTeRY?= =?us-ascii?q?YUdAx+TBo9RohmPQINvAgQGBQIWgW0hgVkzGggbFTsqAYI+PhIZDY4tDgmIY?= =?us-ascii?q?oVFQAMwAjUCBgEJAQEDCY0UAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,480,1599523200"; d="asc'?scan'208,217";a="32443421" 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; 06 Jan 2021 15:29:23 +0000 Received: from [10.61.244.121] ([10.61.244.121]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 106FTMQc005429 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 6 Jan 2021 15:29:22 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_D6F8CD5D-DAF9-44EF-8798-080BE3599B5D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Wed, 6 Jan 2021 16:29:21 +0100 In-Reply-To: Cc: Brian E Carpenter , rfced-future@iab.org, Stephen Farrell To: Eric Rescorla References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.244.121, [10.61.244.121] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 15:29:30 -0000 --Apple-Mail=_D6F8CD5D-DAF9-44EF-8798-080BE3599B5D Content-Type: multipart/alternative; boundary="Apple-Mail=_7CAAAA63-4476-403D-BE11-1C49C823E471" --Apple-Mail=_7CAAAA63-4476-403D-BE11-1C49C823E471 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Top posting: Can I just ask two questions? As a practical matter, how has the =E2=80=9Ccustomer=E2=80=9D/=E2=80=9Crea= der=E2=80=9D been represented in the past? How should the =E2=80=9Ccustomer=E2=80=9D/=E2=80=9Creader=E2=80=9D be = represented in the future? Is this something the RSE really did, and if so how? Eliot > On 5 Jan 2021, at 22:43, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, Jan 5, 2021 at 1:31 PM Brian E Carpenter = > = wrote: > On 06-Jan-21 10:22, Stephen Farrell wrote: > > > > Hiya, > > > > On 05/01/2021 20:11, Brian E Carpenter wrote: > >> Getting those facts might cost some momey and > >> effort, but I think it would be justified. > > > > If we do need to know more about that (*), then > > wouldn't that really be a task for an incoming > > RSE and not this group? > > >=20 > Except that at the moment we have no idea how best to > represent the requirements and issues of those customers > in the "open" strategy discussion. In that sense, there > are empty seats at the table. (And I am not disagreeing > with John Klensin's or Brian Rosen's comments at all. > Just observing that the majority of the customers simply > aren't represented in our discussions.) >=20 > Isn't this generally true? If you think of the IETF's ordinary output = as technologies as opposed to specifications, then it seems like the = customers of those technologies (e.g., end-users) basically aren't = represented at IETF. It's not clear to me how this is different. Indeed, = arguably it's better in that IETF participants generally are direct = consumers of technical specifications -- though of course not the only = consumers -- so hopefully have some idea of the concerns of other = consumers. >=20 > -Ekr >=20 >=20 > Brian >=20 > > Cheers, > > S. > > > > (*) I'm not really convinced yet - I do think we > > know enough about who those readers are, we just > > don't know if they care about all the stuff we're > > talking about here;-) And I'm not sure that's > > a thing we could usefully find out about TBH. > > >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future = > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_7CAAAA63-4476-403D-BE11-1C49C823E471 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Top = posting:

Can I just = ask two questions?

  • As a practical matter, how has the =E2=80=9Ccustomer=E2=80=9D/=E2= =80=9Creader=E2=80=9D been represented in the past?   
  • How should the =E2=80=9Ccustomer=E2=80=9D/=E2=80=9Creader=E2=80= =9D be represented in the future?

Is this something the RSE really = did, and if so how?

Eliot


On 5 Jan 2021, at 22:43, Eric Rescorla <ekr@rtfm.com> = wrote:



On Tue, Jan 5, 2021 at 1:31 PM Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:
On 06-Jan-21 10:22, Stephen Farrell = wrote:
>
> Hiya,
>
> On 05/01/2021 20:11, Brian E Carpenter wrote:
>> Getting those facts might cost some momey and
>> effort, but I think it would be justified.
>
> If we do need to know more about that (*), then
> wouldn't that really be a task for an incoming
> RSE and not this group?
>

Except that at the moment we have no idea how best to
represent the requirements and issues of those customers
in the "open" strategy discussion. In that sense, there
are empty seats at the table. (And I am not disagreeing
with John Klensin's or Brian Rosen's comments at all.
Just observing that the majority of the customers simply
aren't represented in our discussions.)

Isn't this generally = true? If you think of the IETF's ordinary output as technologies as = opposed to specifications, then it seems like the customers of those = technologies (e.g., end-users) basically aren't represented at IETF. = It's not clear to me how this is different. Indeed, arguably it's better = in that IETF participants generally are direct consumers of technical = specifications -- though of course not the only consumers -- so = hopefully have some idea of the concerns of other consumers.

-Ekr


   Brian

> Cheers,
> S.
>
> (*) I'm not really convinced yet - I do think we
> know enough about who those readers are, we just
> don't know if they care about all the stuff we're
> talking about here;-) And I'm not sure that's
> a thing we could usefully find out about TBH.
>

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

= --Apple-Mail=_7CAAAA63-4476-403D-BE11-1C49C823E471-- --Apple-Mail=_D6F8CD5D-DAF9-44EF-8798-080BE3599B5D 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/111EACgkQh7ZrRtnS ejMRRggArQzw8bK3jHxJfM+Qji0855ap47jtMYCM5u2g1pxYLckLMb+/Ov+QkT+b Y9wKOvrWsaXhkaIypIZ68Aivyl4kO7uT+1lhE5PmtIjtlEUDim87+uujh4A0kUkZ ME0DAoI/x2BhvBIDyW2vWpaXH8HRoB/QAJwFfEOY6NqLk7tRANXiHknGEyIlvEw1 Gvnm6ymlZlK9jruD5Oryv7VqKae9PToofDXyEK1Xpr+YbUyT5jNcljrBSRsOeBM7 gh2jL0Z3ZZsVSii++MjdsquIXNK2nuwYzzCXMUJCtPPI0uClHhaON9RH/ANgAuGu JsgouiA9cMdxU3pPCxpPJP5pIIsSPg== =gawZ -----END PGP SIGNATURE----- --Apple-Mail=_D6F8CD5D-DAF9-44EF-8798-080BE3599B5D-- From nobody Wed Jan 6 09:15:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07C73A1031; Wed, 6 Jan 2021 09:15:42 -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 pQlyGmZLUVBY; Wed, 6 Jan 2021 09:15:41 -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 68E663A1028; Wed, 6 Jan 2021 09:15:41 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kxCPK-00084l-Cf; Wed, 06 Jan 2021 12:15:38 -0500 Date: Wed, 06 Jan 2021 12:15:32 -0500 From: John C Klensin To: Eliot Lear , Eric Rescorla cc: rfced-future@iab.org, Stephen Farrell Message-ID: In-Reply-To: References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 17:15:43 -0000 Eliot, I can't speak for the last administration or two (and hence am not interpreting the "RSE" part of your questions narrowly) but, historically, there has been keen awareness of the existence and needs of those communities of "customers". I even remember a long-ago conversation from which I inferred that part of the rationale for line-item RFC Editor funding was the needs of procurement offices. There was also keen awareness of a group of customers/readers who have not been mentioned in the current rounds of discussions: historians who might, 50, 100, or more years from now, try to understand what had happened and why. Because the "customer" may not actually read the RFCs and/or may be a few steps removed (see Brian Rosen's explanation) and because the "reader" may not present tense or even present decade, perhaps you question should be about "customer"/"reader"/"user". I'm not picking nits here - as soon as the question is about who is "represented" and how, those differences become important. Your question and that history brings us back to one of the issues we keep circling around: If we want to be sure those issues are addressed, one possibility is to write a job description and then pick an RSE who is sensitive to the issues and needs _and_ then give them authority. If, instead, we are determined to deal with those issues by community-populated oversight bodies, then those bodies must be defined and populated so they don't, collectively, lose sight of important issues and thereby bring us to either a too-narrow focus on easily measured objectives, notions that the RSE and/or the RPC are "just contractors" who can be easily replaced, or both. best, john --On Wednesday, January 6, 2021 16:29 +0100 Eliot Lear wrote: > Top posting: > > Can I just ask two questions? > > As a practical matter, how has the "customer"/"reader" > been represented in the past? How should the > "customer"/"reader" be represented in the future? > > Is this something the RSE really did, and if so how? From nobody Wed Jan 6 15:26:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3C23A139F for ; Wed, 6 Jan 2021 15:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HP8Eha0CX4aI for ; Wed, 6 Jan 2021 15:26:53 -0800 (PST) Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D0B53A139E for ; Wed, 6 Jan 2021 15:26:52 -0800 (PST) Received: by mail-il1-x132.google.com with SMTP id q5so4895561ilc.10 for ; Wed, 06 Jan 2021 15:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=LoH1Fo05mPoNgKatfnOaNtflBXq4xQRvH/QhdrIhjs4=; b=f06U/mWrOpu92F1CfzgmX8Bn7HG1U/vEdZTeUq9jsf7AZP37OB8neSMhTNPEkP/HQM 2kc9LU3f32+Oij9UbTkHkquM6vHKMwLPxIAojlXU1h3RtetTzHzZt4xAme1goHRMJIL9 0xEmRgdyXcjKjNUBVsCEeTTibrVwtfZfGj7d9YrN6k+Zu6twLxEzFza7ZIukdd/1Uixr r20Htzm0Z1uGDC4yut3fvY/dCQiy6RSP8a0z6seK8kdmDM3FiXl4zPHHU8yjuziovhoQ N80ud+ujteiRB0bjsTYJohpeT/9riYqpIUKa41ckRBTpvWKeACgLF84h/H6LINCb4spn sdrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=LoH1Fo05mPoNgKatfnOaNtflBXq4xQRvH/QhdrIhjs4=; b=fkHSpJIcE4LOC6m+/3IRQkJGI2SXipq6yGRKiPxQS4yUpY/jweG9MdMXpwxDWxIjwd 4tYHyN22WOUQaU9tn7CuCCOxBMHp2LtUII0aRr7KEPmbkQWaHo+P7hrAa/QfrjPAD/76 hX37Y/27XmspN0yW4ne8fEUszF9gic6YiVT5xjiOLUeLFab7WHT3P1OBOd72ityLqe2y cTaLAJtPxG2i2jPrNl6cN+nPDbEt0p5zYo2Dot/I9tKXGpXAuHQOd1RFi5btXxaXEej3 z5plfloInurf5iAJvME7jTKRcGKodQWqAuTJ1oGU7U8m3pA8d1jUjtiNrDWia06MsiwF 7Jkg== X-Gm-Message-State: AOAM533/jOYH2YkV58JyIWSLt60aTHRHPo1ZjzPRuTeACPJNTGoh2gff 2e21rQgZUDD0mN/LYeZQAReadgP+KiaYc3RZ X-Google-Smtp-Source: ABdhPJz6ImyLyylMflo+SE+sSw8OYvokGjzLwGBsnVnO9ZyCjz+b5iLqStX8Wq4geqjIe2Y/ah2GpA== X-Received: by 2002:a92:bf09:: with SMTP id z9mr6285700ilh.194.1609975611825; Wed, 06 Jan 2021 15:26:51 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id n4sm2894414ilm.63.2021.01.06.15.26.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Jan 2021 15:26:49 -0800 (PST) To: Eliot Lear Cc: rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> From: Michael StJohns Message-ID: Date: Wed, 6 Jan 2021 18:26:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> Content-Type: multipart/alternative; boundary="------------4789B626D164B0E55A1BD11A" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 23:26:55 -0000 This is a multi-part message in MIME format. --------------4789B626D164B0E55A1BD11A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Inline On 1/6/2021 4:11 AM, Eliot Lear wrote: > > >> On 5 Jan 2021, at 20:01, Michael StJohns > > wrote: >> >> Hmm... I didn't realize the role of the chair included ignoring >> submissions?  If you disagreed with what I proposed, then say so and >> why, rather than just passing over it. >> >> In any event, it's not the chair's role to imagine consensus, rather >> the role requires you to actively seek it. > > Not your job to tell the chairs what the chair's job is in this forum. >  If you have a complaint, take it up the chairs privately or with the IAB. That's your take away?  Do you actually disagree on your role here?  You made the dismissive comment on the list - it seems to me that the list is the right place to respond. > >> >> I could see something like GIT being used for a document such as the >> XML vocabulary which might benefit from a fast iteration >> (propose/implement/test/approve or remove) model. However, reviewing >> the documents that had Heather as the author  or editor,  I think for >> the most part they benefited from the slow iteration model of publish >> draft/receive comments/revise draft. >> >> Or more bluntly, forcing the development of all documents into one >> model with many micro authors may actively harm or substantially >> delay the production of some documents necessary to evolve the >> series.  cf RFC8153 for an example of a document which might have >> been harmed or delayed. > > See Brian’s response, but your proposal runs counter to the compromise > that Joel and EKR were aiming toward, and would *require* folks like > EKR and Mark to drag the entire WG into a per document debate which I > don’t for a moment believe there would garner their or others’ > approval.  However, I am happy to be proven wrong. The fact that I went in a different direction than Joel and Brian does not render my comments invalid.   As I understand it, once there's a consensus, it takes a new consensus to change.  Lack of consensus leads to the status quo.  Which means that it might be hard to change back once we go down a particular path.  Changing this to a per document discussion prevents that and avoids treating all documents as requiring the same during the development process.   Just saying "initially" just kicks the can down the road for a decision that may materially affect the negotiation of the RSE contract.  See below. > >> I see the proposed language here as an attempt to allow for the later >> imposition of a model which will always micromanage the authors by >> random participants and I just don't think that's sustainable or useful. > > Where do you see that imposition being made?  What the text says is > that the WG will decide on its communication methods based on rough > consensus. You again avoided addressing the second clause of my proposal - to wit that it requires the concurrence of the designated author/editor to impose a given editorial process on a given document. _*I anticipate that most of the documents in this stream will be authored  or edited by the hired expert.*_ I've not seen convincing discussion to the contrary.  Unlike a normal WG where an author who is faced with the prospect of having to edit via GITHUB can simply decline to offer their volunteer services, I would expect that the RSE would not have that option. I note with interest the discussions taking place on the IETF list on the subject line "Old directions in social media" that is spot on this topic. Or put it another way - do we expect the SOW will require the expert to have skills related to Github?   If the WG changes its "consensus" after the SOW is let or the expert is hired, will we expect the expert to conform to the WG consensus and learn a new tool set? Later, Mike > > Eliot --------------4789B626D164B0E55A1BD11A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Inline

On 1/6/2021 4:11 AM, Eliot Lear wrote:


On 5 Jan 2021, at 20:01, Michael StJohns <msj@nthpermutation.com> wrote:

Hmm... I didn't realize the role of the chair included ignoring submissions?  If you disagreed with what I proposed, then say so and why, rather than just passing over it.

In any event, it's not the chair's role to imagine consensus, rather the role requires you to actively seek it.

Not your job to tell the chairs what the chair's job is in this forum.  If you have a complaint, take it up the chairs privately or with the IAB.

That's your take away?  Do you actually disagree on your role here?  You made the dismissive comment on the list - it seems to me that the list is the right place to respond.



I could see something like GIT being used for a document such as the XML vocabulary which might benefit from a fast iteration (propose/implement/test/approve or remove) model.   However, reviewing the documents that had Heather as the author  or editor,  I think for the most part they benefited from the slow iteration model of publish draft/receive comments/revise draft. 

Or more bluntly, forcing the development of all documents into one model with many micro authors may actively harm or substantially delay the production of some documents necessary to evolve the series.  cf RFC8153 for an example of a document which might have been harmed or delayed.

See Brian’s response, but your proposal runs counter to the compromise that Joel and EKR were aiming toward, and would require folks like EKR and Mark to drag the entire WG into a per document debate which I don’t for a moment believe there would garner their or others’ approval.  However, I am happy to be proven wrong.


The fact that I went in a different direction than Joel and Brian does not render my comments invalid.   As I understand it, once there's a consensus, it takes a new consensus to change.  Lack of consensus leads to the status quo.  Which means that it might be hard to change back once we go down a particular path.  Changing this to a per document discussion prevents that and avoids treating all documents as requiring the same during the development process.   Just saying "initially" just kicks the can down the road for a decision that may materially affect the negotiation of the RSE contract.  See below.


I see the proposed language here as an attempt to allow for the later imposition of a model which will always micromanage the authors by random participants and I just don't think that's sustainable or useful. 

Where do you see that imposition being made?  What the text says is that the WG will decide on its communication methods based on rough consensus.

You again avoided addressing the second clause of my proposal - to wit that it requires the concurrence of the designated author/editor to impose a given editorial process on a given document.  I anticipate that most of the documents in this stream will be authored  or edited by the hired expert.  I've not seen convincing discussion to the contrary.  Unlike a normal WG where an author who is faced with the prospect of having to edit via GITHUB can simply decline to offer their volunteer services, I would expect that the RSE would not have that option.  

I note with interest the discussions taking place on the IETF list on the subject line "Old directions in social media" that is spot on this topic.  

Or put it another way - do we expect the SOW will require the expert to have skills related to Github?   If the WG changes its "consensus" after the SOW is let or the expert is hired, will we expect the expert to conform to the WG consensus and learn a new tool set?


Later, Mike



Eliot


--------------4789B626D164B0E55A1BD11A-- From nobody Wed Jan 6 15:33:33 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9303A13AA for ; Wed, 6 Jan 2021 15:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikIqu74XFNfr for ; Wed, 6 Jan 2021 15:33:30 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 252303A13A8 for ; Wed, 6 Jan 2021 15:33:30 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id l11so10571489lfg.0 for ; Wed, 06 Jan 2021 15:33:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=xyOK/8ZZY2jIFJ1H1AH/tyHI8TAUWLPBByLUyV2Gb6U=; b=JPAUjMqdwrvc/DfqSx++lSMfZ8GpxIt3SMYIlk384+RJ5VS6JotPp7mKTUjbUWws/F zPp6M4KaKHc3qF649phJ8QONiqxUOYn7Keyj/57OSZ2OQXfhCZ9RdZjEcDp4aQEwzWSK GQmyGETfcnkMMQXjFGA7QbrvBBeu8WolIDWZU3sMJJ633M3BZbCHKz8zBYOF1Gbm1k8i 88gJm/V+Tp4TAu4GvA06+lczh1XV4bH2nw/lxZOmvakrKg36Jn6IlJ2Kjp6fON//rBKv jCCWK4QehRGlxg1eevoSM+66xfpoqOdjWZlOOIIvuOy7GjblivYe6B6FVzlyqRncpTJ+ U2eg== 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=xyOK/8ZZY2jIFJ1H1AH/tyHI8TAUWLPBByLUyV2Gb6U=; b=sBVorF5X1SwqxzXY9enqqvvxHttkhrBCUvxztwvIIXWGEL/wBw8SRZRI34YIiPOR8q IcKz2jA+noKYFT2xIhzJoZenqk0pCxG4hrhqSjTrp2eBHneLqCejz/t1bQcuNV30uy7X fKGKD332M3Cclh0myIgBtTLBkaKsfVdkACDRpy9yCXnp7IqU6mzwn7JhcePqNh4ZqHoz bt5Rg3YewkCEiE8BRuDEpxQ+K4e37EEncB8RTmOnzjSRCgb4BzvxJvL/fNZHH5PYhIdF UP6eB2wLF7Nv7HralNJpw9x2efIEF+mPQvRkpFswJrqG2PJ1p8iJ2TpWF3IfOx1ML75h L58w== X-Gm-Message-State: AOAM533CBiupfGcr1HBgAalrI+ZATujkP2VafDka8uC0QBCy0XOj8PlZ 4IIL4oAJwJmrfPFviG01fwZ9eB/mVZzGk9txRPNAGA== X-Google-Smtp-Source: ABdhPJwWHdFGrm5e62Km3NnQrHNgTbvtokqC6EkIRtxkBtv0ioUt/YJnBZaR/LKpv/0ngCGdqV0fWFfHVZFjdV2eg+Y= X-Received: by 2002:a19:4f4b:: with SMTP id a11mr2568114lfk.579.1609976008211; Wed, 06 Jan 2021 15:33:28 -0800 (PST) MIME-Version: 1.0 References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> In-Reply-To: From: Eric Rescorla Date: Wed, 6 Jan 2021 15:32:52 -0800 Message-ID: To: Michael StJohns Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000011217f05b843c02f" Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 23:33:32 -0000 --00000000000011217f05b843c02f Content-Type: text/plain; charset="UTF-8" On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns wrote: > > You again avoided addressing the second clause of my proposal - to wit > that it requires the concurrence of the designated author/editor to impose > a given editorial process on a given document. *I anticipate that most > of the documents in this stream will be authored or edited by the hired > expert.* I've not seen convincing discussion to the contrary. > I don't know what you would find convincing, but I don't anticipate this nor do I think it's desirable. -Ekr --00000000000011217f05b843c02f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 6, 2021 at 3:27 PM Michae= l StJohns <m= sj@nthpermutation.com> wrote:
=20 =20 =20

You again avoided addressing the second clause of my proposal= - to wit that it requires the concurrence of the designated author/editor to impose a given editorial process on a given document.=C2=A0 I anticipate that most of the documents in this stream will be authored=C2=A0 or edited by the hired expert.<= /u>=C2=A0 I've not seen convincing discussion to the contrary.=C2=A0

I don't know what you would find convincing, but = I don't anticipate this nor do I think it's desirable.
-Ekr

--00000000000011217f05b843c02f-- From nobody Wed Jan 6 15:49:04 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42093A13D0 for ; Wed, 6 Jan 2021 15:49:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LEn18dklSFq for ; Wed, 6 Jan 2021 15:49:02 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F8073A149C for ; Wed, 6 Jan 2021 15:48:50 -0800 (PST) Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 881F7230C4; Wed, 6 Jan 2021 15:48:50 -0800 (PST) From: Wes Hardaker To: Michael StJohns Cc: Eliot Lear , rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> Date: Wed, 06 Jan 2021 15:48:50 -0800 In-Reply-To: (Michael StJohns's message of "Wed, 6 Jan 2021 18:26:48 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Jan 2021 23:49:03 -0000 I'd like to point out (without quoting the conversation) that the goal of this group is to get consensus by gather the opinions and thoughts of everyone. No thought should be left on the cutting room floor unless there is consensus to do so. However, to achieve consensus it does require statements of affirmation or disagreement otherwise a statement or suggestion by just 1 person does not a consensus make. I do believe that anyone can create a pull request or an issue (unless I've missed a WG direction somewhere), which is also a way to ensure something doesn't get dropped. -- Wes Hardaker USC/ISI From nobody Wed Jan 6 22:50:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046523A0AEE for ; Wed, 6 Jan 2021 22:50:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fK7I2YghLFjL for ; Wed, 6 Jan 2021 22:50:37 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B123A0ADF for ; Wed, 6 Jan 2021 22:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16214; q=dns/txt; s=iport; t=1610002236; x=1611211836; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=AsQLJFlI0cEPIFe264Gh7Kojr+VufDsIViKQexioPXI=; b=lRzd7u1gZQXJ00I6NKtpSEFsEoiQROfd2cLafsXMmCY5TtZuRRwnII63 oluF1OKzmCmkjOouAN6Qir7p1e2lgJKmd9CyeYUQlU2sGYP0LvNtnSKfe kHy6p+KEY03ssi/8/K3WDCt2g8lZhOXUSPdVQgVVzzCev5g8rD0scEsxl 0=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0C/AADYrvZfjBbLJq1iHQEBAQEJARIBBQUBgX4FAQsBg?= =?us-ascii?q?XUGgXwBIBIuhD+JBIgNJQOUHYY1gWgEBwEBAQoDAQEvBAEBhEoCgXAmNwYOA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAYZGhXMBAQEBAgEjSA4FCwsYJwMCA?= =?us-ascii?q?kYRBhOCW0sBgmYgrX52gTKFWIRoEIE4AYFSi1hBggCBOAwQglY+hAB0gmI0g?= =?us-ascii?q?iwEgj4GExsyAQNqCVlJCBsEEQYBAQEDLpwWnCmDAIMngTeWfQMfkweJZIVtj?= =?us-ascii?q?lCjDINvAgQGBQIWgWwigVkzGggbFTsqAYI+PhIZDY47jjBAAzA3AgYBCQEBA?= =?us-ascii?q?wmMLAEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,329,1602547200"; d="asc'?scan'208,217";a="32460862" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2021 06:50:32 +0000 Received: from [10.61.217.161] ([10.61.217.161]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 1076oVi0004518 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 7 Jan 2021 06:50:31 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4CD1EA35-6741-444C-BDC0-1601CE2D7076"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 7 Jan 2021 07:50:30 +0100 In-Reply-To: Cc: rfced-future@iab.org To: Michael StJohns References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.217.161, [10.61.217.161] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 06:50:39 -0000 --Apple-Mail=_4CD1EA35-6741-444C-BDC0-1601CE2D7076 Content-Type: multipart/alternative; boundary="Apple-Mail=_70A127BD-80F2-4DD1-B3EC-71C4C1301FA9" --Apple-Mail=_70A127BD-80F2-4DD1-B3EC-71C4C1301FA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 7 Jan 2021, at 00:26, Michael StJohns = wrote: >=20 > Inline >=20 > On 1/6/2021 4:11 AM, Eliot Lear wrote: >>=20 >>=20 >>> On 5 Jan 2021, at 20:01, Michael StJohns > wrote: >>>=20 >>> Hmm... I didn't realize the role of the chair included ignoring = submissions? If you disagreed with what I proposed, then say so and = why, rather than just passing over it. >>>=20 >>> In any event, it's not the chair's role to imagine consensus, rather = the role requires you to actively seek it. >>=20 >> Not your job to tell the chairs what the chair's job is in this = forum. If you have a complaint, take it up the chairs privately or with = the IAB. > That's your take away? Do you actually disagree on your role here? = You made the dismissive comment on the list - it seems to me that the = list is the right place to respond. >=20 If you have a problem with a chair=E2=80=99s behavior, take that up with = the chairs or with their overseers. That=E2=80=99s what we tell people = to do in a working group. That=E2=80=99s what you should do here. On being dismissive, my apologies for that. What you proposed had just = been objected to by EKR. That is, he objected to text that would have = stated a default position that required case-by-case decisions on how to = use tooling. The text you saw from me was an attempt to record the = resolution to EKR=E2=80=99s concern that he and Joel found common ground = on. And as a reminder, it is proposed text. >=20 >>=20 >>>=20 >>> I could see something like GIT being used for a document such as the = XML vocabulary which might benefit from a fast iteration = (propose/implement/test/approve or remove) model. However, reviewing = the documents that had Heather as the author or editor, I think for = the most part they benefited from the slow iteration model of publish = draft/receive comments/revise draft. >>>=20 >>> Or more bluntly, forcing the development of all documents into one = model with many micro authors may actively harm or substantially delay = the production of some documents necessary to evolve the series. cf = RFC8153 for an example of a document which might have been harmed or = delayed. >>=20 >> See Brian=E2=80=99s response, but your proposal runs counter to the = compromise that Joel and EKR were aiming toward, and would require folks = like EKR and Mark to drag the entire WG into a per document debate which = I don=E2=80=99t for a moment believe there would garner their or = others=E2=80=99 approval. However, I am happy to be proven wrong. >=20 > The fact that I went in a different direction than Joel and Brian does = not render my comments invalid. As I understand it, once there's a = consensus, it takes a new consensus to change. Lack of consensus leads = to the status quo. Which means that it might be hard to change back = once we go down a particular path. Changing this to a per document = discussion prevents that and avoids treating all documents as requiring = the same during the development process. Just saying "initially" just = kicks the can down the road for a decision that may materially affect = the negotiation of the RSE contract. See below. >=20 Thank you for commenting on the current proposed text. This group can = comment on the substance of what you wrote, but so far, I see you in the = rough as the only person objecting to the current proposed text, modulo = whether we add an informational reference to RFC 8874. Again, that is = subject to others commenting. >>=20 >>> I see the proposed language here as an attempt to allow for the = later imposition of a model which will always micromanage the authors by = random participants and I just don't think that's sustainable or useful. >>=20 >> Where do you see that imposition being made? What the text says is = that the WG will decide on its communication methods based on rough = consensus. > You again avoided addressing the second clause of my proposal - to wit = that it requires the concurrence of the designated author/editor to = impose a given editorial process on a given document. >=20 That presumes a case-by-case assessment, and this is not a simple = editorial process, but how the group communicates. > I anticipate that most of the documents in this stream will be = authored or edited by the hired expert. I've not seen convincing = discussion to the contrary. Unlike a normal WG where an author who is = faced with the prospect of having to edit via GITHUB can simply decline = to offer their volunteer services, I would expect that the RSE would not = have that option. >=20 > I note with interest the discussions taking place on the IETF list on = the subject line "Old directions in social media" that is spot on this = topic. >=20 > Or put it another way - do we expect the SOW will require the expert = to have skills related to Github? If the WG changes its "consensus" = after the SOW is let or the expert is hired, will we expect the expert = to conform to the WG consensus and learn a new tool set? >=20 >=20 >=20 The group can comment on the rest of this. Eliot --Apple-Mail=_70A127BD-80F2-4DD1-B3EC-71C4C1301FA9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 7 Jan 2021, at 00:26, Michael StJohns <msj@nthpermutation.com> wrote:

=20
Inline

On 1/6/2021 4:11 AM, Eliot Lear = wrote:
=20

On 5 Jan 2021, at 20:01, Michael StJohns = <msj@nthpermutation.com> wrote:

=20
Hmm... I didn't realize the role of the chair included ignoring submissions?  = If you disagreed with what I proposed, then say so and why, rather than just passing over it.

In any event, it's not the chair's role to imagine consensus, rather the role requires you to actively seek it.

Not your job to tell the chairs what the chair's job is in this forum.  If you have a complaint, take it up the chairs = privately or with the IAB.

That's your take away?  Do you = actually disagree on your role here?  You made the dismissive comment on the list - it seems = to me that the list is the right place to = respond.


If = you have a problem with a chair=E2=80=99s behavior, take that up with = the chairs or with their overseers. That=E2=80=99s what we tell people = to do in a working group.  That=E2=80=99s what you should do = here.

On being dismissive, my = apologies for that.  What you proposed had just been objected to by EKR.  That is, he = objected to text that would have stated a default position that required = case-by-case decisions on how to use tooling.  The text you saw = from me was an attempt to record the resolution to EKR=E2=80=99s concern = that he and Joel found common ground on.  And as a reminder, it is = proposed text.




I could see something like GIT being used for a document such as the XML vocabulary which might benefit from a fast iteration (propose/implement/test/approve or remove) model.   However, reviewing the documents that had Heather as the author  or editor,  I think for the most part = they benefited from the slow iteration model of publish draft/receive comments/revise draft. 
=

Or more bluntly, forcing = the development of all documents into one model with many micro authors may actively harm or substantially delay the production of some documents necessary to evolve the series.  cf RFC8153 for an example of a document = which might have been harmed or delayed.

See Brian=E2=80=99s response, but your proposal runs counter to = the compromise that Joel and EKR were aiming toward, and would require folks like EKR and Mark to drag the entire WG into a per document debate which I don=E2=80=99t for a = moment believe there would garner their or others=E2=80=99 approval. =  However, I am happy to be proven wrong.


The fact that I went in a different direction than = Joel and Brian does not render my comments invalid.   As I understand = it, once there's a consensus, it takes a new consensus to change.  = Lack of consensus leads to the status quo.  Which means that it might = be hard to change back once we go down a particular path.  = Changing this to a per document discussion prevents that and avoids treating all documents as requiring the same during the development process.   Just saying "initially" just = kicks the can down the road for a decision that may materially affect the negotiation of the RSE contract.  See below.


Thank = you for commenting on the current proposed text. This group can comment = on the substance of what you wrote, but so far, I see you in the rough = as the only person objecting to the current proposed text, modulo = whether we add an informational reference to RFC 8874.  Again, that = is subject to others commenting.


I see the proposed language here as an attempt to allow for the later imposition of a model which will always micromanage the authors by random participants and I just don't think that's sustainable or useful. 

Where do you see that imposition being made? =  What the text says is that the WG will decide on its communication methods based on rough consensus.

You again avoided addressing the second = clause of my proposal - to wit that it requires the concurrence of the designated author/editor to impose a given editorial process on a given document. 


That= presumes a case-by-case assessment, and this is not a simple editorial = process, but how the group communicates.

I anticipate that = most of the documents in this stream will be authored  or edited by the hired = expert.  I've not seen convincing discussion to the contrary.  Unlike = a normal WG where an author who is faced with the prospect of having to edit via GITHUB can simply decline to offer their volunteer services, I would expect that the RSE would not have that option.

I note with interest the discussions taking place = on the IETF list on the subject line "Old directions in social media" that is spot on this topic.  

Or put it another way - do we expect the SOW will = require the expert to have skills related to Github?   If the WG = changes its "consensus" after the SOW is let or the expert is hired, will we expect the expert to conform to the WG consensus and learn a new tool set?


The = group can comment on the rest of this.

Eliot


= --Apple-Mail=_70A127BD-80F2-4DD1-B3EC-71C4C1301FA9-- --Apple-Mail=_4CD1EA35-6741-444C-BDC0-1601CE2D7076 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/2rzYACgkQh7ZrRtnS ejPLVwf+Kc64i+ycvmKmeKhYGJpJKaMhRILG+DXhYqv7+dZLFX71eEbG6ZWAM41E GtAfNwUxmyFN93Xmv33sbDHyec3Am1XsP/7G6lwAHEqsufUEpVxiPe7oOo2SpDEs IMk977M/+J3lKrmcWHAGveOQRGVv4YtJlu9tdVXXErOAGGVIgFcyUBmVjHizFsTy qjIRbTmHgTxhOHTwmBA92Dp1sDuSdn+Yvq7UoGyqfiWhKYiaxUJmmPxasrh4xzGu Lu23C1voFohiwqsaI33s18+Svxdtg6+PjU1KK0m8Ha07RxuA+1xEdV1sFrDn0M9P rw3uBrLA/pdOBQLp3Mc+3mx0+lRe9A== =jMtT -----END PGP SIGNATURE----- --Apple-Mail=_4CD1EA35-6741-444C-BDC0-1601CE2D7076-- From nobody Thu Jan 7 14:32: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 D17803A0A9E for ; Thu, 7 Jan 2021 14:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=LMgUqwpc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=XMpvYUbV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GbcUeqFfRq_X for ; Thu, 7 Jan 2021 14:31:57 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40EF23A0AD6 for ; Thu, 7 Jan 2021 14:31:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 97BBC5C013E for ; Thu, 7 Jan 2021 17:31:54 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Thu, 07 Jan 2021 17:31:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=2P+tR0QfBKIVNEDahB/6hqPWF26Feu4 VhISXR0jR0Ws=; b=LMgUqwpc4tFFFFjaQvHYpYiYfgLI/cJJ6aeROj3BvCSSb0s k9K6SJ7YDzBstXGxT/uDE6OEPn0yjIbs1Duze9VH9glET7NMZNuoB1hK61zkDRt0 ir2eDXMhdY+OJAJYlB8rdVhCGq/cc0wRchA7Fk0VZTSvJaig9efeih775alnj9dR Mu8LTDeU1V4GkqVtTk5Xk3K1X+IyIDrwXAqj1C5XJ5M3DZQKgexNrPrUO2sjuYpv 1l0fD09z3KFh1pj+JKMI7H+lPLfwe5iYv5e+a30iPqhMnBbyQ5oxCKi15oQYo58K 1HtqVi/l3Lo18AwhuWWIl0jIfeYE9miS7CEhJOA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2P+tR0 QfBKIVNEDahB/6hqPWF26Feu4VhISXR0jR0Ws=; b=XMpvYUbVPWZz3HYJoKsSKr Fg5wrVVv3WJcYTusqtDjzx0lFYWhpxYhSKum7mnoR5oz+TwHpWT2lJlsTM3cpGmv 6zvcCULtvEJLvi/ThSe5U5cUJCkQRzduAatv7ZGM+DXZFepiph8XvJNeBgSIOSsy CbNVb7SsBOlJDILkKnW6n9hln1qP9Q60P7v8VfFf6fNotH2jidBrf2hpx8N+xxH4 BdLW03GKKE/21QJ4M8WZcZNK2xI191EuKiMTQbd8ZuNCTJzzYfq01n0DcT3poQOr e8ctPmtw1o2UWR0xUmKBO/lDR+9AXMtt2BNgUBHKttCsFTdMRgmcKEZCtIDoa5vA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrvdegfedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 48FD6201A8; Thu, 7 Jan 2021 17:31:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.1-61-gb52c239-fm-20201210.001-gb52c2396 Mime-Version: 1.0 Message-Id: <83f310b6-d795-42c3-99a3-837291964bfe@www.fastmail.com> In-Reply-To: <747AF8E6F186475B187D6A4A@PSB> References: <747AF8E6F186475B187D6A4A@PSB> Date: Fri, 08 Jan 2021 09:31:35 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Point of clarification on terms X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jan 2021 22:31:59 -0000 On Tue, Dec 29, 2020, at 05:46, John C Klensin wrote: > A colleague of ours, one who is probably too smart to be > following this list, once suggested (approximately... don't > remember the exact quote) that another body in the Internet > administration and standards space was an experiment in how many > bureaucrats, politicians, and lawyers it took at replace one > part-time engineer. I hope that was said with a healthy dose of irony. The reason you replace that part-time engineer in that way is because the thing they are doing is important enough to build an institution to support. You do that because good governance is worth the price. > As we create, and then try to carefully > define, more and more structure, presumably because we do not > trust ourselves to appoint or hire the right individuals and > hold them accountable (for their work rather than for not > saluting every time some other body comes to a conclusion), I > wonder if we are not heading down the same path with the RFC > Editor function. There's a thread on the W3C AC forum where they are discussing the value of building institutions that survive failures in the benevolent dictator/philosopher king model. We can talk about institutions for ensuring individuals are accountable, or we could look to vesting power in the institution itself. I hope that my preference for the latter has been made clear already. I thought it timely to repeat it and this email seemed like a good jumping-off point. From nobody Fri Jan 8 06:56: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 AA2313A1014 for ; Fri, 8 Jan 2021 06:56:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jx5CXd4ZBS0N for ; Fri, 8 Jan 2021 06:56:30 -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 9532B3A1013 for ; Fri, 8 Jan 2021 06:56:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7830; q=dns/txt; s=iport; t=1610117789; x=1611327389; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=OUl6Jt5rwlN3RiR7b3Uuk84AjWYsO8suhVEQPoRkeRE=; b=OCzzKaaJYKFXtu/idHAR29Rc1SNKyVbahAYX/fbe4RMT3dwb5xwxFBfK eIVoejvIZTrG4ZUg6WVgD8BH/LKRrxQ5DfQ1PW/2KbPhWUA5rBuKrJLWj s6RxSxMDn/tog1RikNJEgkXPwm2hJ91xPR599DFhXjYAH29PHh4zvD7RC 4=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DsAABZcfhfjBbLJq1iHQICCRQFBYF/BQwBg3cBIBIuh?= =?us-ascii?q?D+JBIgSJQOUHYY1gWgEBwEBAQoDAQEvBAEBhEoCgXEmNwYOAgMBAQEDAgMBA?= =?us-ascii?q?QEBBQEBAQIBBgQUAQEBAYZGhXMBAQEDASNWBQsLGCoCAlcGExSDEoJnIK05d?= =?us-ascii?q?oEyhViEZhCBOAGBUotYQYIAgTgMEIJWPoQkgzI0giwEgwABVkaBOQFlIBGbY?= =?us-ascii?q?JwqgwCDJ4E3lwEDH4Mpj2IrjyiwfwReg28CBAYFAhaBbCKBWTMaCBsVZQGCP?= =?us-ascii?q?j4SGQ2OO44wQAMwNwIGAQkBAQMJjE0BAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,331,1602547200"; d="asc'?scan'208,217";a="32503242" 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; 08 Jan 2021 14:56:25 +0000 Received: from [10.61.167.187] ([10.61.167.187]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 108EuOWV028287 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jan 2021 14:56:25 GMT From: Eliot Lear Message-Id: <848A19ED-5373-4DCF-A7BC-AED8BD40EC96@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_DA7064D8-F4E5-4D92-89FB-74BB686E294D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 8 Jan 2021 15:56:23 +0100 In-Reply-To: Cc: Eliot Lear , Eric Rescorla , rfced-future@iab.org, Stephen Farrell To: John C Klensin References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.167.187, [10.61.167.187] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 14:56:32 -0000 --Apple-Mail=_DA7064D8-F4E5-4D92-89FB-74BB686E294D Content-Type: multipart/alternative; boundary="Apple-Mail=_E2D18B78-7585-4DE3-9CDA-DDEA324C6AFC" --Apple-Mail=_E2D18B78-7585-4DE3-9CDA-DDEA324C6AFC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi John, Thanks for writing this. I just have one follow-up point for you and = the group. > On 6 Jan 2021, at 18:15, John C Klensin wrote: >=20 > Eliot, >=20 > I can't speak for the last administration or two (and hence am > not interpreting the "RSE" part of your questions narrowly) but, > historically, there has been keen awareness of the existence and > needs of those communities of "customers". I even remember a > long-ago conversation from which I inferred that part of the > rationale for line-item RFC Editor funding was the needs of > procurement offices. There was also keen awareness of a group > of customers/readers who have not been mentioned in the current > rounds of discussions: historians who might, 50, 100, or more > years from now, try to understand what had happened and why. >=20 > Because the "customer" may not actually read the RFCs and/or may > be a few steps removed (see Brian Rosen's explanation) and > because the "reader" may not present tense or even present > decade, perhaps you question should be about > "customer"/"reader"/"user". I'm not picking nits here - as > soon as the question is about who is "represented" and how, > those differences become important. >=20 > Your question and that history brings us back to one of the > issues we keep circling around: If we want to be sure those > issues are addressed, one possibility is to write a job > description and then pick an RSE who is sensitive to the issues > and needs _and_ then give them authority. If, instead, we are > determined to deal with those issues by community-populated > oversight bodies, then those bodies must be defined and > populated so they don't, collectively, lose sight of important > issues and thereby bring us to either a too-narrow focus on > easily measured objectives, notions that the RSE and/or the RPC > are "just contractors" who can be easily replaced, or both. There are several bars that this group can set to answer Russ=E2=80=99 = question: Better than what we have What we have Less than what we have Of course we have to understand what we have to make a determination. = As to who performs this function, that could be the RSE or it could be = others, or it could be no one, depending on where the group wants to set = the bar. This gets to a point that Mirja raised: it could be that we = are overloading the function too much (I=E2=80=99m not advocating that = view, I=E2=80=99m just stating that it has been mentioned in a broader = context). Eliot --Apple-Mail=_E2D18B78-7585-4DE3-9CDA-DDEA324C6AFC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = John,

Thanks for = writing this.  I just have one follow-up point for you and the = group.  

On 6 Jan 2021, at 18:15, John C Klensin = <john-ietf@jck.com> wrote:

Eliot,

I can't speak for the = last administration or two (and hence am
not interpreting = the "RSE" part of your questions narrowly) but,
historically, there has been keen awareness of the existence = and
needs of those communities of "customers".  I = even remember a
long-ago conversation from which I = inferred that part of the
rationale for line-item RFC = Editor funding was the needs of
procurement offices. =  There was also keen awareness of a group
of = customers/readers who have not been mentioned in the current
rounds of discussions: historians who might, 50, 100, or = more
years from now, try to understand what had happened = and why.

Because the "customer" may not = actually read the RFCs and/or may
be a few steps removed = (see Brian Rosen's explanation) and
because the "reader" = may not present tense or even present
decade, perhaps you = question should be about
"customer"/"reader"/"user". =   I'm not picking nits here - as
soon as the = question is about who is "represented" and how,
those = differences become important.

Your question = and that history brings us back to one of the
issues we = keep circling around: If we want to be sure those
issues = are addressed, one possibility is to write a job
description= and then pick an RSE who is sensitive to the issues
and = needs _and_ then give them authority.  If, instead, we are
determined to deal with those issues by = community-populated
oversight bodies, then those bodies = must be defined and
populated so they don't, collectively, = lose sight of important
issues and thereby bring us to = either a too-narrow focus on
easily measured objectives, = notions that the RSE and/or the RPC
are "just contractors" = who can be easily replaced, or both.  

There = are several bars that this group can set to answer Russ=E2=80=99 = question:

  • Better than what we have
  • What we have
  • Less than what we = have

Of = course we have to understand what we have to make a determination. =  As to who performs this function, that could be the RSE or it = could be others, or it could be no one, depending on where the group = wants to set the bar.  This gets to a point that Mirja raised: it = could be that we are overloading the function too much (I=E2=80=99m not = advocating that view, I=E2=80=99m just stating that it has been = mentioned in a broader context).

Eliot

= --Apple-Mail=_E2D18B78-7585-4DE3-9CDA-DDEA324C6AFC-- --Apple-Mail=_DA7064D8-F4E5-4D92-89FB-74BB686E294D 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/4cpcACgkQh7ZrRtnS ejPXQQf7BXkz/mjEXnd0iaLYtsfaAhE+bbW3HJv0wejO61n5XAZ6Nhn1zgOCZibn XBitiGBt9V1AUcRvDXhNJXyqc5EmsGkYO848+LenBLGaVf0UozJmGV4vyZycJRHb WwPU6bZGH86o5GrIT4vyJFYbYVtD/Y/WrD0lNG+6iGscNV/ehn/nwHtjA68wmuqE 6glpiNPRGTKyVI3VegDHiF5GRA8bdwgawmcoLASG5ySQf6Vep/tKk+a3eopU4m/m +PTVbGU8bw6q9kfVG4eqxYDfryfNve3lukzWO4FrU4W7TRC/Suy+WrQT1Y1APHBg ed1aryaWSGrrVD7oN/7HrXMyKIO3pw== =JPAW -----END PGP SIGNATURE----- --Apple-Mail=_DA7064D8-F4E5-4D92-89FB-74BB686E294D-- From nobody Fri Jan 8 09:12: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 E068F3A1167 for ; Fri, 8 Jan 2021 09:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCsdDJxcfJdm for ; Fri, 8 Jan 2021 09:12:11 -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 593D73A1165 for ; Fri, 8 Jan 2021 09:12:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13473; q=dns/txt; s=iport; t=1610125931; x=1611335531; h=from:mime-version:subject:message-id:date:to; bh=8CN1Qkr2EwDRhKBwrIAAiYfLP2D00ANwHnvDgsJWDw8=; b=F0z1plm+b0Ioslk8wV6PMnkiDO/w9gQHaWAX0xPHfsltiuwK6AMRQWiG pZeAIk66w66cJ3O26qwU/hQRitjjqEoq03mQ386ytnGBu0YNFPnHJr79T nCzZ26Bt5MOHale1eIABLNVYCM1gNki4H/6eC0wSgbGoQI9YT4xZOIJ+7 I=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DgCAB7kfhfjBbLJq1iHgEBCxIMggQLgSNZgSVXASASL?= =?us-ascii?q?oQ/iQSINoMahFWMMW6HLwQHAQEBCgMBARsUBAEBhj0mNwYOAgMBAQEDAgMBA?= =?us-ascii?q?QEBBQEBAQIBBgQUAQEBAYYNBicMhh2BMwKBBoMSAYMGnyaOHHaBMopIEIE4g?= =?us-ascii?q?VOLWEGCAIE4HIFYiRI0giwEgm0DNWoORDM+nHucKoMAgyeBN4RMkjUDFgmiX?= =?us-ascii?q?rFhg28CBAYFAhaBbCI5gSAzGggbFTsqAYI+CTUSGQ2NDIEvgQsBA4dchUVAA?= =?us-ascii?q?zA3AgYBCQEBAwmMTQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,331,1602547200"; d="asc'?scan'208,217";a="32444583" 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; 08 Jan 2021 17:12:07 +0000 Received: from ams3-vpn-dhcp306.cisco.com (ams3-vpn-dhcp306.cisco.com [10.61.65.50]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 108HC6SL002793 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 8 Jan 2021 17:12:07 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_0A6C894F-1F75-41E3-8023-5599EFA4109C"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: Date: Fri, 8 Jan 2021 18:12:05 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.65.50, ams3-vpn-dhcp306.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] Current RSE responsibilities X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 17:12:14 -0000 --Apple-Mail=_0A6C894F-1F75-41E3-8023-5599EFA4109C Content-Type: multipart/alternative; boundary="Apple-Mail=_0D8E50DB-60D7-4375-894A-894D15728E8F" --Apple-Mail=_0D8E50DB-60D7-4375-894A-894D15728E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi everyone, As promised at our last F2F, here is the table of current = responsibilities of the RSE. It may not be perfectly stated here. I am = trying to be succinct. If you want to edit the source on Google, just = ping me. Even better, if you want to take ownership of it, there will = be great thanks. The intent is here is not to say that all of these responsibilities have = to be fulfilled by the next RS[EA] or even that they have to be = fulfilled by anyone, but merely that we recognize what is currently = being done and decide who does what, what if anything gets added, and = what if anything gets left behind. If you like, we can go down this list at our interim. A note, of course this has to do with the discussion we=E2=80=99re = having about who represents the broader community. May I encourage = people to continue that conversation as well? Eliot RFC 8728 Section Responsibility 2 rfc-editor.org 2.1 Quality, continuity, and evolution of the series 2.1.1 Performance of the RPC and Publisher function 2.1.1 Creates documentation and structures that will allow for = continuity of the RFC Series in the face of changes in contracts and = personnel. 2.1.1 Issues that go beyond the RFC Production Center or Publisher = functions, such as cross-stream coordination of priorities. 2.1.2.1 Primary point of contact to the IETF on matters relating to the = RFC Series in general, or policy matters relating to specific documents 2.1.2.1.1 Supports volunteerism 2.1.2.1.2 Identifies materially concerned interest groups within = the Internet community and reaching out to them 2.1.2.1.2 Works with the community to achieve policy that meets = the overall quality, continuity, and evolution goals the RSE is charged = with meeting. 2.1.2.2 Represents the Series externally. 2.1.3 Ongoing development of production and publication 2.1.4 Broad community engagement 2.1.4 Provide vision for evolution of the publication environment --Apple-Mail=_0D8E50DB-60D7-4375-894A-894D15728E8F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi everyone,

As promised at our last F2F, here is the table of current = responsibilities of the RSE.  It may not be perfectly stated here. =  I am trying to be succinct.  If you want to edit the source = on Google, just ping me.  Even better, if you want to take = ownership of it, there will be great thanks.

The intent is here is not to say that all of these responsibilities have = to be fulfilled by the next RS[EA] or even that they have to be = fulfilled by anyone, but merely that we recognize what is currently = being done and decide who does what, what if anything gets added, and = what if anything gets left behind.

If you like, we can go down this list = at our interim.

A note, of course this has to do with the discussion we=E2=80=99= re having about who represents the broader community.  May I = encourage people to continue that conversation as well?

Eliot

RFC 8728
SectionResponsibility
2rfc-editor.org
2.1Quality, = continuity, and evolution of the series
2.1.1Performance of the RPC = and Publisher function
2.1.1Creates documentation and structures that will allow for = continuity of the RFC Series in the face of changes in contracts and = personnel.
2.1.1Issues that = go beyond the RFC Production Center or Publisher functions, such as = cross-stream coordination of priorities.
2.1.2.1Primary point of contact to the IETF on matters relating to = the RFC Series in general, or policy matters relating to specific = documents
2.1.2.1.1Supports volunteerism
2.1.2.1.2Identifies materially concerned = interest groups within the Internet community and reaching out to = them
2.1.2.1.2Works with the community to achieve policy that meets the = overall quality, continuity, and evolution goals the RSE is charged with = meeting.
2.1.2.2Represents the Series = externally.
2.1.3Ongoing = development of production and publication
2.1.4Broad community = engagement
2.1.4Provide = vision for evolution of the publication = environment

= --Apple-Mail=_0D8E50DB-60D7-4375-894A-894D15728E8F-- --Apple-Mail=_0A6C894F-1F75-41E3-8023-5599EFA4109C 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/4kmUACgkQh7ZrRtnS ejMIhgf/csqvZyxU/Skp2eP2P9D0o69Z1o9LiFUBEuXEF9qCnGVeTo7JPUCSRGKK GqCIa2W0oVrrZ0rjbttA2vwccv1xGsiIog/NtcRQluTnR9fhO3e5KPt2heZRZUge FHWhlF/YK0Ok8th3r864+Q2x/H/RU5KFhPB8PSVDJRjp2iXbL2mTHJEt+PhO6Z04 df2V9YLhRB4v6QVICrfBeqWe/lBP/rHLQrliSd59SeVcz6R85/O6TZP3QF6SaVW8 t0JSeo9bcuz0YiybqbK8lfcvrt1HfwHeI2ijgsaDBY7w6rU/H2+/PSicjxNEGlzM x59O4cCELthWFwSrJ+YlJmYa2ATDdg== =EXxD -----END PGP SIGNATURE----- --Apple-Mail=_0A6C894F-1F75-41E3-8023-5599EFA4109C-- From nobody Fri Jan 8 09:34:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1E03A10D3; Fri, 8 Jan 2021 09:34:54 -0800 (PST) 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, MAY_BE_FORGED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODpd_Y2TvbFB; Fri, 8 Jan 2021 09:34:52 -0800 (PST) Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B4A3A0EB5; Fri, 8 Jan 2021 09:34:50 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 108HYm99017613; Fri, 8 Jan 2021 17:34:48 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 845B722032; Fri, 8 Jan 2021 17:34:48 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 6DB3C2203A; Fri, 8 Jan 2021 17:34:48 +0000 (GMT) Received: from LAPTOPK7AS653V (217.139.51.84.dyn.plus.net [84.51.139.217] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 108HYlk0004995 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jan 2021 17:34:47 GMT Reply-To: From: "Adrian Farrel" To: "'Eliot Lear'" , References: In-Reply-To: Date: Fri, 8 Jan 2021 17:34:46 -0000 Organization: Old Dog Consulting Message-ID: <062201d6e5e4$8f514320$adf3c960$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0623_01D6E5E4.8F525490" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLLRq+cnTF/GAslbV6QptP2z37jyag1OSew Content-Language: en-gb X-Originating-IP: 84.51.139.217 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-25900.001 X-TM-AS-Result: No--15.056-10.0-31-10 X-imss-scan-details: No--15.056-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25900.001 X-TMASE-Result: 10--15.055600-10.000000 X-TMASE-MatchedRID: HQYVVRq48Rw7iuZ/mdYYtto4g/Zvpl9f8uEHZJ6TKqK5GoIIFHPu/71I IWbmPaI2BGjU6Ie7CGoGLRKL2Nexjbw2HnQG+TrAMTkWY9HYyZE1meqslyNScw2ukv6bnJo70nu iD3uQWdnMKw4IHEOndf9aOTfDNjtlDqaUR6lw5a9XPwnnY5XL5L0s/9CBVD+VHHXhdzbY69/kuZ y8gQzvdY8wj7plu2iO3nHtGkYl/VqDwntrnEWhGUl/J9Ro+MABjn92T7igP2udFKRjWcDhzlPgH /D/p8gpl8quHiKVRoev+kNtyTw7SjyW+6AAWIU/O7BMOlfyKLQgscTOabHjbfDKpGE42bMdi+Mj wbFVmjpq0QqhYus7ZKyBo9Jaui9GfGBcniZ3HmBPrt6zN5RT5wLR0gdFC5sgh2dGdZqdf5Zv72l 2jY0UHxo/F4wweNBu5Qo03mEdwAGXOVo0UPe9FHt8F07wTFIuqIK2Am1JSGwcIaIUXJieGYG0Fd EhY+8f6CfXrfUCBisF5SnBHIsu+qRrttr6flcLy1Sekjh1GG8NUQPYKAFNBELQS0ocv1tAcTEoI /fCIXEYU3eZ1m5+n9WvZ0LprH5q2waSiRqt+AP8MiS+SwxIEYXndB3+8eSrUvfNpDqRIqKI40w6 RysGJoc7+Qb8+03pCLQsumV/5S+CFkqa43bHmwMuv289VbCIxUDTxL3vuSD4+veoc+y9mWZhpDh dH8fMLEu3XubSvQFitzfafzhYegHBpPquNCJ0fbFGiNyAhi4kKmD5FRkD30dgNo8Hh3T7HN8E5V 9DSKcBmyRCHqEtfUmSRRbSc9s3oR125t7qTX6bKItl61J/yZUdXE/WGn0FSlnU38LCY8vzV9FEg EqY0Cs3zPQeiEbe/nnwJ52QYi9DgHwbv13hPI63CG1dTjqut8QrMNqn/kV5ptvq7xLvzpZ7LhB6 FHFBqKyzS4Pv3LUwfE8HCZjis9lNIydUVoWKsBbdJjyomm9YEyOwlywUtg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Current RSE responsibilities X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 17:34:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0623_01D6E5E4.8F525490 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Thanks Eliot, =20 Useful to have this list. Should help us focus on: * What tasks we want to be continued * What roles we want to take responsibility for the tasks * What skillsets we need to fill the roles * =20 In view of the recent thread about John contacting the archival = repositories for RFCs, may be worth picking this up specifically from = section 2.1.4 as an additional task =E2=80=9CEnsure long-term archive of = RFCs is maintained=E2=80=9D =20 Cheers, Adrian =20 From: Rfced-future On Behalf Of Eliot = Lear Sent: 08 January 2021 17:12 To: rfced-future@iab.org Subject: [Rfced-future] Current RSE responsibilities =20 Hi everyone, =20 As promised at our last F2F, here is the table of current = responsibilities of the RSE. It may not be perfectly stated here. I am = trying to be succinct. If you want to edit the source on Google, just = ping me. Even better, if you want to take ownership of it, there will = be great thanks. =20 The intent is here is not to say that all of these responsibilities have = to be fulfilled by the next RS[EA] or even that they have to be = fulfilled by anyone, but merely that we recognize what is currently = being done and decide who does what, what if anything gets added, and = what if anything gets left behind. =20 If you like, we can go down this list at our interim. =20 A note, of course this has to do with the discussion we=E2=80=99re = having about who represents the broader community. May I encourage = people to continue that conversation as well? =20 Eliot =20 RFC 8728 =09 Section Responsibility 2 rfc-editor.org =20 2.1 Quality, continuity, and evolution of the series 2.1.1 Performance of the RPC and Publisher function 2.1.1 Creates documentation and structures that will allow for continuity of = the RFC Series in the face of changes in contracts and personnel. 2.1.1 Issues that go beyond the RFC Production Center or Publisher functions, = such as cross-stream coordination of priorities. 2.1.2.1 Primary point of contact to the IETF on matters relating to the RFC = Series in general, or policy matters relating to specific documents 2.1.2.1.1 Supports volunteerism 2.1.2.1.2 Identifies materially concerned interest groups within the Internet = community and reaching out to them 2.1.2.1.2 Works with the community to achieve policy that meets the overall = quality, continuity, and evolution goals the RSE is charged with = meeting. 2.1.2.2 Represents the Series externally. 2.1.3 Ongoing development of production and publication 2.1.4 Broad community engagement 2.1.4 Provide vision for evolution of the publication environment =20 ------=_NextPart_000_0623_01D6E5E4.8F525490 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Thanks = Eliot,

 

Useful to = have this list. Should help us focus on:

  • What tasks we want to be = continued
  • What roles we want to take = responsibility for the tasks
  • What skillsets we need = to fill the roles
  •  
In view of = the recent thread about John contacting the archival repositories for = RFCs, may be worth picking this up specifically from section 2.1.4 as an = additional task =E2=80=9CEnsure long-term archive of RFCs is = maintained=E2=80=9D

 

Cheers,

Adrian

 

From: Rfced-future = <rfced-future-bounces@iab.org> On Behalf Of Eliot = Lear
Sent: 08 January 2021 17:12
To: = rfced-future@iab.org
Subject: [Rfced-future] Current RSE = responsibilities

 

Hi = everyone,

 

As promised at our last F2F, here is the table of = current responsibilities of the RSE.  It may not be perfectly = stated here.  I am trying to be succinct.  If you want to edit = the source on Google, just ping me.  Even better, if you want to = take ownership of it, there will be great = thanks.

 

The intent is here is not to say that all = of these responsibilities have to be fulfilled by the next RS[EA] or = even that they have to be fulfilled by anyone, but merely that we = recognize what is currently being done and decide who does what, what if = anything gets added, and what if anything gets left = behind.

 

If you like, we can go down this list at our = interim.

 

A = note, of course this has to do with the discussion we=E2=80=99re having = about who represents the broader community.  May I encourage people = to continue that conversation as well?

 

Eliot

 

RFC = 8728

Section

Responsibility<= o:p>

2

rfc-editor.org

2.1<= /span>

Quality, = continuity, and evolution of the = series

2.1.1

Performance of = the RPC and Publisher function

2.1.1

Creates = documentation and structures that will allow for continuity of the RFC = Series in the face of changes in contracts and = personnel.

2.1.1

Issues that go = beyond the RFC Production Center or Publisher functions, such as = cross-stream coordination of = priorities.

2.1.2.1

Primary point = of contact to the IETF on matters relating to the RFC Series in general, = or policy matters relating to specific = documents

2.1.2.1.1<= /o:p>

Supports = volunteerism

2.1.2.1.2<= /o:p>

Identifies = materially concerned interest groups within the Internet community and = reaching out to them

2.1.2.1.2<= /o:p>

Works with the = community to achieve policy that meets the overall quality, continuity, = and evolution goals the RSE is charged with = meeting.

2.1.2.2

Represents the = Series externally.

2.1.3

Ongoing = development of production and = publication

2.1.4

Broad = community engagement

2.1.4

Provide vision = for evolution of the publication = environment

 

------=_NextPart_000_0623_01D6E5E4.8F525490-- From nobody Fri Jan 8 09:55:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFE93A1195 for ; Fri, 8 Jan 2021 09:55:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN3wZiRcIVt7 for ; Fri, 8 Jan 2021 09:55:17 -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 3FCBD3A0E1C for ; Fri, 8 Jan 2021 09:55:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26757; q=dns/txt; s=iport; t=1610128517; x=1611338117; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=nTF4KU7+vHDP4mURtPrflyAZzfMGaMGoBVcfIKtWpjM=; b=Uj7DjVRzQend84tKWZOan6o2qAAcC3GbFq4fqPfHkwIlHNyKknsizpid x2/zoCCYwwR/jErqJWQvaLoqX7oKjs734sPoe73xjadpD+wEODybemd5Z kmaWZrfLpX2QdHqjCXUWVd6+y4kXNEjM+9FVWBkKFpGXFeJb9hZEev2Yd s=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BlAQCZm/hfjBbLJq1iHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?gQBAQsBgSJTBoElVwEgEi6EP4kEiDUDgxeEVY0fhy8EBwEBAQoDAQElCgQBA?= =?us-ascii?q?YRKAoFxJjcGDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQGGDQYnDIVzAQEBA?= =?us-ascii?q?wEjVgULCxEEAQEBIAoCAk8IGRSDEgGCZiAPrSt2gTKEPwETQUSEZRCBOAGBU?= =?us-ascii?q?otYQYIAgREnHIFYfj6CXQIChHWCYASBVIEZAzIDEEUBFA5EMz6BCptxnCqDA?= =?us-ascii?q?IMngTeETJIpDAMfol6fJ5I6g28CBAYFAhaBbCI5gSAzGggbFTsqAYI+CTUSG?= =?us-ascii?q?Q2NDIEhDgmBAgEDgkiFFIVFQAMwNwIGAQkBAQMJjE0BAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,332,1602547200"; d="asc'?scan'208,217";a="32506775" 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; 08 Jan 2021 17:55:13 +0000 Received: from ams3-vpn-dhcp306.cisco.com (ams3-vpn-dhcp306.cisco.com [10.61.65.50]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 108HtCrK005919 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 8 Jan 2021 17:55:12 GMT From: Eliot Lear Message-Id: <632331CB-621C-48D4-ACC2-219770969125@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9D8C5509-1117-4312-82B0-1771C7C7A4D7"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 8 Jan 2021 18:55:11 +0100 In-Reply-To: <062201d6e5e4$8f514320$adf3c960$@olddog.co.uk> Cc: rfced-future@iab.org To: adrian@olddog.co.uk References: <062201d6e5e4$8f514320$adf3c960$@olddog.co.uk> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.65.50, ams3-vpn-dhcp306.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Current RSE responsibilities X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 17:55:20 -0000 --Apple-Mail=_9D8C5509-1117-4312-82B0-1771C7C7A4D7 Content-Type: multipart/alternative; boundary="Apple-Mail=_C02514CC-3BB8-45AF-BD87-FFB75AF51989" --Apple-Mail=_C02514CC-3BB8-45AF-BD87-FFB75AF51989 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Adrian and thanks. I added the extra line. FWIW, the sheet I=E2=80=99= m using is here = . Eliot > On 8 Jan 2021, at 18:34, Adrian Farrel wrote: >=20 > Thanks Eliot, >=20 > Useful to have this list. Should help us focus on: > What tasks we want to be continued > What roles we want to take responsibility for the tasks > What skillsets we need to fill the roles >=20 > In view of the recent thread about John contacting the archival = repositories for RFCs, may be worth picking this up specifically from = section 2.1.4 as an additional task =E2=80=9CEnsure long-term archive of = RFCs is maintained=E2=80=9D >=20 > Cheers, > Adrian >=20 > From: Rfced-future On Behalf Of Eliot = Lear > Sent: 08 January 2021 17:12 > To: rfced-future@iab.org > Subject: [Rfced-future] Current RSE responsibilities >=20 > Hi everyone, >=20 > As promised at our last F2F, here is the table of current = responsibilities of the RSE. It may not be perfectly stated here. I am = trying to be succinct. If you want to edit the source on Google, just = ping me. Even better, if you want to take ownership of it, there will = be great thanks. >=20 > The intent is here is not to say that all of these responsibilities = have to be fulfilled by the next RS[EA] or even that they have to be = fulfilled by anyone, but merely that we recognize what is currently = being done and decide who does what, what if anything gets added, and = what if anything gets left behind. >=20 > If you like, we can go down this list at our interim. >=20 > A note, of course this has to do with the discussion we=E2=80=99re = having about who represents the broader community. May I encourage = people to continue that conversation as well? >=20 > Eliot >=20 > RFC 8728 > Section > Responsibility > 2 > rfc-editor.org > 2.1 > Quality, continuity, and evolution of the series > 2.1.1 > Performance of the RPC and Publisher function > 2.1.1 > Creates documentation and structures that will allow for continuity of = the RFC Series in the face of changes in contracts and personnel. > 2.1.1 > Issues that go beyond the RFC Production Center or Publisher = functions, such as cross-stream coordination of priorities. > 2.1.2.1 > Primary point of contact to the IETF on matters relating to the RFC = Series in general, or policy matters relating to specific documents > 2.1.2.1.1 > Supports volunteerism > 2.1.2.1.2 > Identifies materially concerned interest groups within the Internet = community and reaching out to them > 2.1.2.1.2 > Works with the community to achieve policy that meets the overall = quality, continuity, and evolution goals the RSE is charged with = meeting. > 2.1.2.2 > Represents the Series externally. > 2.1.3 > Ongoing development of production and publication > 2.1.4 > Broad community engagement > 2.1.4 > Provide vision for evolution of the publication environment --Apple-Mail=_C02514CC-3BB8-45AF-BD87-FFB75AF51989 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Adrian and thanks.  I added the extra line.  FWIW, the sheet = I=E2=80=99m using is here.

Eliot

On 8 Jan = 2021, at 18:34, Adrian Farrel <adrian@olddog.co.uk> wrote:

Thanks Eliot,
 
Useful to have this list. Should help us focus on:
  • What tasks we want to be continued
  • What roles we want to take responsibility = for the tasks
  • What skillsets we = need to fill the roles
  •  
In view of the recent thread about John contacting the = archival repositories for RFCs, may be worth picking this up = specifically from section 2.1.4 as an additional task =E2=80=9CEnsure = long-term archive of RFCs is maintained=E2=80=9D
 
Cheers,
Adrian
 
From: Rfced-future <rfced-future-bounces@iab.org> On Behalf = Of Eliot Lear
Sent: 08 January 2021 17:12
To: rfced-future@iab.org
Subject: [Rfced-future] Current RSE = responsibilities
 
Hi everyone,
 
As = promised at our last F2F, here is the table of current responsibilities = of the RSE.  It may not be perfectly stated here.  I am trying = to be succinct.  If you want to edit the source on Google, just = ping me.  Even better, if you want to take ownership of it, there = will be great thanks.
 
The = intent is here is not to say that all of these responsibilities have = to be fulfilled by the next RS[EA] or even that they have to be = fulfilled by anyone, but merely that we recognize what is currently = being done and decide who does what, what if anything gets added, and = what if anything gets left behind.
 
If = you like, we can go down this list at our interim.
 
A = note, of course this has to do with the discussion we=E2=80=99re having = about who represents the broader community.  May I encourage people = to continue that conversation as well?
 
Eliot
 
RFC 8728
Section
Responsibility
2
rfc-editor.org
2.1
Quality, continuity, and evolution of the series
2.1.1
Performance of the RPC and Publisher function
2.1.1
Creates documentation and structures that will allow for = continuity of the RFC Series in the face of changes in contracts and = personnel.
2.1.1
Issues that go beyond the RFC Production Center or Publisher = functions, such as cross-stream coordination of priorities.
2.1.2.1
Primary point of contact to the IETF on matters relating to = the RFC Series in general, or policy matters relating to specific = documents
2.1.2.1.1
Supports volunteerism
2.1.2.1.2
Identifies materially concerned interest groups within the = Internet community and reaching out to them
2.1.2.1.2
Works with the community to achieve policy that meets the = overall quality, continuity, and evolution goals the RSE is charged with = meeting.
2.1.2.2
Represents the Series externally.
2.1.3
Ongoing development of production and publication
2.1.4
Broad community engagement
2.1.4
Provide vision for evolution of the publication = environment

= --Apple-Mail=_C02514CC-3BB8-45AF-BD87-FFB75AF51989-- --Apple-Mail=_9D8C5509-1117-4312-82B0-1771C7C7A4D7 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/4nH8ACgkQh7ZrRtnS ejMD+wf+NjoYJR4n4dxaki85AYLn2bmga1L5WZIWloYL3i6kbloHsaARKD1lUez/ Aaf3SmBqiNVFeTg0k5h4IeXFC5TmjElvzIlnym3QY3gO4v69uhNxjpHxLZyYH8/b jRtITLpm3q4HtNa7xONSYkaehNUIF+QeN6v7Al96SkPQd1UvgpNrctWTBuuXzuac NC21yyEjxd4ZaV/CwO5Yv7QMfSY29ddHYsP0E27hRWxcpsH5E2cYBaQ5JtYhxRQS inG0UdNg1J7wQx1RITFQ4daPA6Shcgsp7PwTBY29Qsf1tRE+psU1VeCO1lAxY9C2 qkbZRIVSVMLQbjgN+MDzDfapRqs3KQ== =pUZC -----END PGP SIGNATURE----- --Apple-Mail=_9D8C5509-1117-4312-82B0-1771C7C7A4D7-- From nobody Fri Jan 8 10:59: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 642E03A11D5 for ; Fri, 8 Jan 2021 10:59:06 -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 8ZRXP3nnVDMv for ; Fri, 8 Jan 2021 10:59:04 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB4F43A11D8 for ; Fri, 8 Jan 2021 10:59:04 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1kxwyT-00027Y-4G; Fri, 08 Jan 2021 13:59:01 -0500 Date: Fri, 08 Jan 2021 13:58:55 -0500 From: John C Klensin To: Eliot Lear cc: Eric Rescorla , rfced-future@iab.org, Stephen Farrell Message-ID: In-Reply-To: <848A19ED-5373-4DCF-A7BC-AED8BD40EC96@cisco.com> References: <25B2F8BF-ECCA-44E3-A542-78AEE89CD08B@cisco.com> <7AE85A6C-07B1-4E13-8774-EA8591944122@vigilsec.com> <31B53D7E-C5A3-4102-9287-2E24DFA2D813@vigilsec.com> <9b191b28-f279-81f3-f055-77fd65629bf8@gmail.com> <9e737182-e70e-c99b-a0e6-1b334aea6301@gmail.com> <5a455872-78b0-30a5-f333-0a3c309ccf14@cs.tcd.ie> <848A19ED-5373-4DCF-A7BC-AED8BD40EC96@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Who are the customers? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 18:59:06 -0000 --On Friday, January 8, 2021 15:56 +0100 Eliot Lear wrote: > Hi John, > > Thanks for writing this. I just have one follow-up point for > you and the group. > >> On 6 Jan 2021, at 18:15, John C Klensin >> wrote: >> >> Eliot, >> >> I can't speak for the last administration or two (and hence am >> not interpreting the "RSE" part of your questions narrowly) >> but, historically, there has been keen awareness of the >> existence and needs of those communities of "customers". I >> even remember a long-ago conversation from which I inferred >> that part of the rationale for line-item RFC Editor funding >> was the needs of procurement offices. There was also keen >> awareness of a group of customers/readers who have not been >> mentioned in the current rounds of discussions: historians >> who might, 50, 100, or more years from now, try to understand >> what had happened and why. >... > There are several bars that this group can set to answer > Russ' question: > > Better than what we have > What we have > Less than what we have And we could try to set those bars differently depending on whether "what we have" is interpreted as "today", "during Heather's term before things started to melt down" [1], or "during the Postel, or maybe Postel-Braden, period". In the second case, "before" because I think she became less effective on a number of issues that are part of this discussion once things started to go back and various parts of the organizational structure started second-guessing her and/or excluding her from relevant discussions. In addition, one might answer differently depending on whether "what we have" is interpreted in terms of general principles and goals or in terms of particular sets of operational decisions and procedures. In particular, many of the principles (some possibly not articulated explicitly and to a general audience) that Postel tried to follow might still be applicable today but things have changed a lot in 20+ years and we'd expect the implementation details to be very different. Some of the principles have changed too: some of us can remember when there was an assumption that the RFC Editor would perform a technical review on most of the submitted documents. > Of course we have to understand what we have to make a > determination. As to who performs this function, that could > be the RSE or it could be others, or it could be no one, > depending on where the group wants to set the bar. This gets > to a point that Mirja raised: it could be that we are > overloading the function too much (I'm not advocating that > view, I'm just stating that it has been mentioned in a > broader context). I see that concern as a question of trying to find the right balance. Certainly there is a risk of overloading the position and, in particular, of heaping enough responsibilities and requirements for different skills and expertise onto the job that no one human, or at least no human we would have any hope of recruiting, would be able to do it. On the other hand, it is not hard to imagine splitting functions up enough that no one person really has a complete overview and priorities get set and decisions made by whomever is most determined, loudest, and/or has the most time on their hands to drag out arguments. One particular risk in that area is that, because almost any decision might have financial implications, decisions could, by default, end up being made on the basis of what is good for the IETF Administration LLC rather than what is going for the Internet or the RFC Series. john [1] I'm not sure whether there is agreement on when the meltdown started or if they might make a difference, but there are clearly some plausible points prior to when Heather stepped down or announced her intention to not seek a new contract. From nobody Sat Jan 9 16:08: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 38F593A0BBC for ; Sat, 9 Jan 2021 16:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEy4is-tR8UL for ; Sat, 9 Jan 2021 16:08:09 -0800 (PST) Received: from mail-io1-xd36.google.com (mail-io1-xd36.google.com [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82DBB3A0BB8 for ; Sat, 9 Jan 2021 16:08:09 -0800 (PST) Received: by mail-io1-xd36.google.com with SMTP id q137so13904405iod.9 for ; Sat, 09 Jan 2021 16:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=t+kPw2uLi4Zj8AbxCPVI9zCgsGpnvv+xBsA7xGM03mg=; b=14MR22RsvM8p1Jm+Aaiib0bTPNbFBKG6l/OWdFC1f581O0pIs4ylgumpC+33a9y4rd iFj8PG57gWeXWXhnEuAA+XEAb+DI26mMBdXy6fy+T0+Bt+Y/Qisbw+fuiepTXLm0bX2y b5VDPpPLyc7fC/bplAiz0Lq+lWJhuFcxhyJobe3U9pty8rhDf8zBwvpcev2Zf63HL/XH HicLO7OjagQb5z9iqmQkbh8O+qwtMmYNfTrFmCs5Q5WuCwYFa0ybE3GbVLeVoVl2P9mP BXBboBa5k0Q31LeqJDv9QhppFKniSec9ITDZgzprQWNBHEg+OnSt5LEsVubY42epooBU UTkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=t+kPw2uLi4Zj8AbxCPVI9zCgsGpnvv+xBsA7xGM03mg=; b=mREEqYisEaltE0NAlF/mwYsWyM5lgu09pGzkedenKCU/aCt/KeaW8689ahGqV1tL5l Ku9m5Z2dA5CMkXdnCI2MQ/BY+P3dRGcAORn+/enmrQ9SROo7kG0Z3T1dcFpXEZqnSA7B viNuze3xTE9iJj8FGgfL1d0Py0SWqa4AEqJLRN7DhTYbIq4oa1URpnRUVbo0rKvhZLjk pQ832tZin24Bb/wrxHr89i0xqonl7KdCMghvz74n0BxPVlL0ensd712cuz2pgTkl828q +JXQ1T7V99LU3orpPKqTye77tqjRAjdJHSG1NqJeJz8JAaPAVDGVJgsmVE2fXx6iboBw ZE5Q== X-Gm-Message-State: AOAM530j3PtXQpbZ4Whduz/pkXEdmmx43gXyuSJnNU82X6Qa6KpsTC/Z AMBjHDzKFwKLNE/4k1LKb3ds/5k62lJG2Sv0 X-Google-Smtp-Source: ABdhPJyHzbVJU9f+g9ZyksgHn/p+qACHQhNy53KXRqtPmzj8RrxoWjhKiuU66Ju5iHKNltzsDohW8g== X-Received: by 2002:a5d:9d42:: with SMTP id k2mr10405870iok.151.1610237288135; Sat, 09 Jan 2021 16:08:08 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id z4sm8175082ioh.32.2021.01.09.16.08.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 09 Jan 2021 16:08:07 -0800 (PST) To: Eric Rescorla Cc: Eliot Lear , rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> From: Michael StJohns Message-ID: <84e21c52-f5fd-9792-0778-aa5013a2751d@nthpermutation.com> Date: Sat, 9 Jan 2021 19:08:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------7DFF2991F3306F2F60161472" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 00:08:11 -0000 This is a multi-part message in MIME format. --------------7DFF2991F3306F2F60161472 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/6/2021 6:32 PM, Eric Rescorla wrote: > > > On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns > wrote: > > > You again avoided addressing the second clause of my proposal - to > wit that it requires the concurrence of the designated > author/editor to impose a given editorial process on a given > document. _*I anticipate that most of the documents in this stream > will be authored  or edited by the hired expert.*_ I've not seen > convincing discussion to the contrary. > > I don't know what you would find convincing, but I don't anticipate > this nor do I think it's desirable. > > -Ekr > Hi Ekr - You should have no objection to my text as you think it will never come into play.  If you're right, it's an ignorable clause. Basically, I'm trying to ensure that we don't try and micromanage a hired expert. * If the expert is just making pronouncements from the Mount rather than doing most of the document work, then your approach will work. * If the expert is doing most of the work, then forcing them into a document production model that they're not familiar with, that adds to their workload and adds to our costs should mostly be avoided. * If there's some balance,  forcing the hired person to adopt a particular work model is comes up against "a contractor decides how to accomplish an assignment" vs the model of an employee who can be told exactly how to accomplish an assignment and will definitely affect the contract negotiation (and may adversely affect the set of people willing to do the job). For your question, what I would find convincing is a specific commitment from several volunteers with backing from their employers for some level of effort over the next 4 or so years adding up to at least 25% FTE cumulative.   I don't actually expect that level of commitment, nor for that matter much normal IETF participant interest in this set of problems once we complete this set of discussions.   It doesn't make anyone money and it doesn't directly impact shipment of products. I could be wrong - but history suggests I'm not. Later, Mike --------------7DFF2991F3306F2F60161472 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/6/2021 6:32 PM, Eric Rescorla wrote:


On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns <msj@nthpermutation.com> wrote:

You again avoided addressing the second clause of my proposal - to wit that it requires the concurrence of the designated author/editor to impose a given editorial process on a given document.  I anticipate that most of the documents in this stream will be authored  or edited by the hired expert.  I've not seen convincing discussion to the contrary. 

I don't know what you would find convincing, but I don't anticipate this nor do I think it's desirable.

-Ekr

Hi Ekr -

You should have no objection to my text as you think it will never come into play.  If you're right, it's an ignorable clause. 

Basically, I'm trying to ensure that we don't try and micromanage a hired expert. 

  • If the expert is just making pronouncements from the Mount rather than doing most of the document work, then your approach will work. 
  • If the expert is doing most of the work, then forcing them into a document production model that they're not familiar with, that adds to their workload and adds to our costs should mostly be avoided.
  • If there's some balance,  forcing the hired person to adopt a particular work model is comes up against "a contractor decides how to accomplish an assignment" vs the model of an employee who can be told exactly how to accomplish an assignment and will definitely affect the contract negotiation (and may adversely affect the set of people willing to do the job).

For your question, what I would find convincing is a specific commitment from several volunteers with backing from their employers for some level of effort over the next 4 or so years adding up to at least 25% FTE cumulative.   I don't actually expect that level of commitment, nor for that matter much normal IETF participant interest in this set of problems once we complete this set of discussions.   It doesn't make anyone money and it doesn't directly impact shipment of products. 

I could be wrong - but history suggests I'm not.

Later, Mike


--------------7DFF2991F3306F2F60161472-- From nobody Sun Jan 10 08:00:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9083A106D for ; Sun, 10 Jan 2021 08:00:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wAlG-iCrdEBt for ; Sun, 10 Jan 2021 08:00:18 -0800 (PST) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C9523A1075 for ; Sun, 10 Jan 2021 08:00:18 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id o19so34350517lfo.1 for ; Sun, 10 Jan 2021 08:00:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iYXackcQ2jeL1BFEHejCaD1uC9gZ6rw4R9WjA2wlRUU=; b=Ylxv4UHJ7DF/mnHMsvsaPmAgaV7uEKRJ9suhQ+wkbe1gCYd2VWR5zRJ79zweJygHwL M0UPC0NXPeMog3TVsSiNt1gZLo3Qq79n7rghznkqUV8PJWgSrV/T8gzBsEOqXkZw6uiy lKy/OfjnvdpspfyGYjvvn8mnARjKQzOMYF0YluCDQAZyjfd/KHJaeyolZtOr5yK/shrx z7L+3mE16mGe1mqAfwI1tDk6lTrAEbStKMwD9T0cXW0JVYRKzfBlQVxao2WwazN3hnPR 6qynMeTLsqd6TrzC0mz8x3BYKB8cTGpA+7jR3dfgeeyrRGC3byAKYUT7qa74ijdfykNT w/Uw== 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=iYXackcQ2jeL1BFEHejCaD1uC9gZ6rw4R9WjA2wlRUU=; b=hvjNtkPHZGuQQEKWlT8huP7BVvb3LjFI3Hto+7cigdTfTfDAACHv7iDeocTbvXLWZI pdF9O5KuIF0ek/+CS0MmvFLUq3bywPxFdbzUKvcNbpTbv/stGUGKxYbJLmKlngVx4wEY xi0Lk96XIsQe5BZJR04lYu8CKUhL+HWJ3VnLIk+be3MBhHxEpVEpmKMgfy2XW+aa/nPr WCrR+a7QrrxNm2D5KEgOlxZLSV7ZoSYpVMGtaREmJGFFEznkx9OrcrsmVb2I6w/G/BRh 3IlArSUrS8g8ZXrPYFgRGn84W8cr2eh12kzohOMnGhOexB1RMpbR5mOJmd9ZWn6m29kN cWng== X-Gm-Message-State: AOAM532AvL3ZNbvLXcyEO4w88LV9iAxM20wp0o2dfdJlJl1f3CzqbLc+ vpue/qin6b3Gphtn/c60yBljsUUtKrsCtEJobNaWuw== X-Google-Smtp-Source: ABdhPJz0KQnUcWRnmlBl2MkrD4NUysl47fvYb+ASXScZoJUUbffQFNB6QCT3L2Wz3eDTo/h/tOhP6fDZBDM6L7sdzUY= X-Received: by 2002:ac2:44ba:: with SMTP id c26mr5236430lfm.132.1610294415966; Sun, 10 Jan 2021 08:00:15 -0800 (PST) MIME-Version: 1.0 References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> <84e21c52-f5fd-9792-0778-aa5013a2751d@nthpermutation.com> In-Reply-To: <84e21c52-f5fd-9792-0778-aa5013a2751d@nthpermutation.com> From: Eric Rescorla Date: Sun, 10 Jan 2021 08:00:00 -0800 Message-ID: To: Michael StJohns Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000a5d48805b88de2b3" Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 16:00:20 -0000 --000000000000a5d48805b88de2b3 Content-Type: text/plain; charset="UTF-8" On Sat, Jan 9, 2021 at 4:08 PM Michael StJohns wrote: > On 1/6/2021 6:32 PM, Eric Rescorla wrote: > > > > On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns > wrote: > >> >> You again avoided addressing the second clause of my proposal - to wit >> that it requires the concurrence of the designated author/editor to impose >> a given editorial process on a given document. *I anticipate that most >> of the documents in this stream will be authored or edited by the hired >> expert.* I've not seen convincing discussion to the contrary. >> > I don't know what you would find convincing, but I don't anticipate this > nor do I think it's desirable. > > -Ekr > > Hi Ekr - > > You should have no objection to my text as you think it will never come > into play. If you're right, it's an ignorable clause. > > Basically, I'm trying to ensure that we don't try and micromanage a hired > expert. > > - If the expert is just making pronouncements from the Mount rather > than doing most of the document work, then your approach will work. > - If the expert is doing most of the work, then forcing them into a > document production model that they're not familiar with, that adds to > their workload and adds to our costs should mostly be avoided. > > This is where I don't agree. The needs of the WG are more important than the needs of the RSE, and if that adds to our costs, then so be it. FWIW, to the extent to which we are concerned about unfamiliar production models, I suspect that our bespoke production tools are a far greater obstacle than Github. -Ekr --000000000000a5d48805b88de2b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Jan 9, 2021 at 4:08 PM Michae= l StJohns <m= sj@nthpermutation.com> wrote:
=20 =20 =20
On 1/6/2021 6:32 PM, Eric Rescorla wrote:
=20


On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns <msj@nthpermutation.com> wrote:

You again avoided addressing the second clause of my proposal - to wit that it requires the concurrence of the designated author/editor to impose a given editorial process on a given document.=C2=A0 I anticipate that most of the documents in this stream will be authored=C2=A0 or edited by the hired expert.= =C2=A0 I've not seen convincing discussion to the contrary.=C2= =A0

I don't know what you would find convincing, but I don&#= 39;t anticipate this nor do I think it's desirable.

-Ekr

Hi Ekr -

You should have no objection to my text as you think it will never come into play.=C2=A0 If you're right, it's an ignorabl= e clause.=C2=A0

Basically, I'm trying to ensure that we don't try and microm= anage a hired expert.=C2=A0

  • If the expert is just making pronouncements from the Mount rather than doing most of the document work, then your approach will work.=C2=A0
  • If the expert is doing most of the work, then forcing them into a document production model that they're not familiar with= , that adds to their workload and adds to our costs should mostly be avoided.
This is where I don= 9;t agree. The needs of the WG are more important than the needs of the RSE= , and if that adds to our costs, then so be it.

FW= IW, to the extent to which we are concerned about unfamiliar production mod= els, I suspect that our bespoke production tools are a far greater obstacle= than Github.

-Ekr
--000000000000a5d48805b88de2b3-- From nobody Sun Jan 10 13:51:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 698013A132C for ; Sun, 10 Jan 2021 13:51:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.158 X-Spam-Level: X-Spam-Status: No, score=-2.158 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNcEl1nJS_pT for ; Sun, 10 Jan 2021 13:51:22 -0800 (PST) Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF8F3A132D for ; Sun, 10 Jan 2021 13:51:22 -0800 (PST) Received: by mail-il1-x12d.google.com with SMTP id q1so16383553ilt.6 for ; Sun, 10 Jan 2021 13:51:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=0th4mSAeg221NG+7et6Nhll/1It59uRBipripebjYeQ=; b=TMcAoFHYfMNG0Q9UJFL71iQ2MU8XJ6hMs33bDEwoGas0KXquwh5KY7WlGWrTQLA8My dXiBA/NRUokwvte4vqF491jI7LHF6Dd+lNT4r4yKetdSf2RIrMaSEuMuY8/Y0MFXCDlL Ohb5sXOeb76I8NViiANaLeIdX0w01fMoO1n2Xjcp199kDQSnzvEX+oBTg2OjAdooGIV+ ogZll1LmRZNLkWcGOm0BIv3a73EBdqDMpdHYszkIpdOtRSUN/fastL8yH+jZI6bovuDf QVkeTPlHxU+rZfoOEHg+iHV0kicoCb8Ymkguzw9ecSiIsndA1Z34ZkG2shbup/FHbbjU GZKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=0th4mSAeg221NG+7et6Nhll/1It59uRBipripebjYeQ=; b=QE2h8kzlKi5WWOAA+q5SQ22EZJ9Cz2UKmGsUNZY5sZSUhFClP8B2BP6UH5qeREST6H agAfgyOxGA5I5AX/A+BGbkd6XmOP+Ram2m6EBp4aRzYGCMLoHl4Rfg36sGtqDBg7VeGg T9ID2oj8o7qWPc7T4B/WI3uIVWKeqehhQroEKUIbr/uB46pL47W5PhaOkx1kxBMY9A2K XPoCy/z4Yx/wqqHEix97NXp+qEHts9CMdXyqCatNw99AqDtZppaLBo800WpX8GZnfLzY qwHk+9DYwPI6Q6NrM3dhzbxgNyBbVQNfxV7Q11qczs2Y8NbwPBKjebHJxitazDriRqgu b6fA== X-Gm-Message-State: AOAM533Wr4FpvNp9Yc5ip1GfiMP0gOCDW6pMPvkrjs9JvSKISi+T1A2z COBxwqoH+S+NSt7r7s56tbbv0uQAWPWPVZTS X-Google-Smtp-Source: ABdhPJwSoLiIPQUv0v+xCYqPl0KnVfPNW8RCf/hn16CZKlS0Kj/vOKAeYTL4j4cWohlM9gkeopLSaA== X-Received: by 2002:a92:aa0a:: with SMTP id j10mr2918546ili.52.1610315481206; Sun, 10 Jan 2021 13:51:21 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id h1sm13389260ilj.8.2021.01.10.13.51.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 10 Jan 2021 13:51:20 -0800 (PST) To: Eric Rescorla Cc: rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <07aa9478-ca0c-aed3-8a9a-312a78172a5f@joelhalpern.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> <84e21c52-f5fd-9792-0778-aa5013a2751d@nthpermutation.com> From: Michael StJohns Message-ID: Date: Sun, 10 Jan 2021 16:51:17 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A8C5E2D2FB2C8577B2E915FB" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 21:51:24 -0000 This is a multi-part message in MIME format. --------------A8C5E2D2FB2C8577B2E915FB Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/10/2021 11:00 AM, Eric Rescorla wrote: > > > On Sat, Jan 9, 2021 at 4:08 PM Michael StJohns > wrote: > > On 1/6/2021 6:32 PM, Eric Rescorla wrote: >> >> >> On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns >> > wrote: >> >> >> You again avoided addressing the second clause of my proposal >> - to wit that it requires the concurrence of the designated >> author/editor to impose a given editorial process on a given >> document. _*I anticipate that most of the documents in this >> stream will be authored  or edited by the hired expert.*_  >> I've not seen convincing discussion to the contrary. >> >> I don't know what you would find convincing, but I don't >> anticipate this nor do I think it's desirable. >> >> -Ekr >> > Hi Ekr - > > You should have no objection to my text as you think it will never > come into play.  If you're right, it's an ignorable clause. > > Basically, I'm trying to ensure that we don't try and micromanage > a hired expert. > > * If the expert is just making pronouncements from the Mount > rather than doing most of the document work, then your > approach will work. > * If the expert is doing most of the work, then forcing them > into a document production model that they're not familiar > with, that adds to their workload and adds to our costs should > mostly be avoided. > > This is where I don't agree. The needs of the WG are more important > than the needs of the RSE, and if that adds to our costs, then so be it. So what you're saying is that a random self-selected collection of IETF participants can not only tell a contractor what to do, but how to do it?  I note that the RSOC tried this, it wasn't a random self-selected collection,  and it didn't go well.    I don't believe this is viable.  I also don't believe its in keeping with the discussions we've already had. I any event, it's not the "needs of the WG" that are more important, but that the long term needs of the community should guide the WG and the RSE rather than the ephemeral demands of a few participants at a given time. > > FWIW, to the extent to which we are concerned about unfamiliar > production models, I suspect that our bespoke production tools are a > far greater obstacle than Github. Not really.  I edit in Emacs XML mode, PHB (I think) has a tool to convert MS Word, you've got a Kramdown to XML tool.  I'm sure there are at least 3 or 4 others.    There's a great difference between "you must deliver documents that are in the form described by " vs "you must do all of your document production using Github and   AND produce documents that are .... ". Or horrors - "you must do all of your document production via Microsoft Teams and Word and must open an issue for each and every change you make to the document" I actually think that whoever we get is not going to have all that much problem producing useful XML by whatever means.  Its also possible you can convince them that Github (or whatever flavor of the month we've moved on to in a few years) is a useful approach.   Who knows?  But let's avoid legislating this. Later, Mike > > -Ekr --------------A8C5E2D2FB2C8577B2E915FB Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/10/2021 11:00 AM, Eric Rescorla wrote:


On Sat, Jan 9, 2021 at 4:08 PM Michael StJohns <msj@nthpermutation.com> wrote:
On 1/6/2021 6:32 PM, Eric Rescorla wrote:


On Wed, Jan 6, 2021 at 3:27 PM Michael StJohns <msj@nthpermutation.com> wrote:

You again avoided addressing the second clause of my proposal - to wit that it requires the concurrence of the designated author/editor to impose a given editorial process on a given document.  I anticipate that most of the documents in this stream will be authored  or edited by the hired expert.  I've not seen convincing discussion to the contrary. 

I don't know what you would find convincing, but I don't anticipate this nor do I think it's desirable.

-Ekr

Hi Ekr -

You should have no objection to my text as you think it will never come into play.  If you're right, it's an ignorable clause. 

Basically, I'm trying to ensure that we don't try and micromanage a hired expert. 

  • If the expert is just making pronouncements from the Mount rather than doing most of the document work, then your approach will work. 
  • If the expert is doing most of the work, then forcing them into a document production model that they're not familiar with, that adds to their workload and adds to our costs should mostly be avoided.
This is where I don't agree. The needs of the WG are more important than the needs of the RSE, and if that adds to our costs, then so be it.

So what you're saying is that a random self-selected collection of IETF participants can not only tell a contractor what to do, but how to do it?  I note that the RSOC tried this, it wasn't a random self-selected collection,  and it didn't go well.    I don't believe this is viable.  I also don't believe its in keeping with the discussions we've already had.

I any event, it's not the "needs of the WG" that are more important, but that the long term needs of the community should guide the WG and the RSE rather than the ephemeral demands of a few participants at a given time.


FWIW, to the extent to which we are concerned about unfamiliar production models, I suspect that our bespoke production tools are a far greater obstacle than Github.

Not really.  I edit in Emacs XML mode, PHB (I think) has a tool to convert MS Word, you've got a Kramdown to XML tool.  I'm sure there are at least 3 or 4 others.    There's a great difference between "you must deliver documents that are in the form described by <xml2rfc etc>" vs "you must do all of your document production using Github and <pick a tool>  AND produce documents that are .... ".  

Or horrors - "you must do all of your document production via Microsoft Teams and Word and must open an issue for each and every change you make to the document"

I actually think that whoever we get is not going to have all that much problem producing useful XML by whatever means.  Its also possible you can convince them that Github (or whatever flavor of the month we've moved on to in a few years) is a useful approach.   Who knows?  But let's avoid legislating this.

Later, Mike




-Ekr


--------------A8C5E2D2FB2C8577B2E915FB-- From nobody Sun Jan 10 18:48: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 32CA23A14CE for ; Sun, 10 Jan 2021 18:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MApAto8KdMW3 for ; Sun, 10 Jan 2021 18:48:51 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDB03A14CC for ; Sun, 10 Jan 2021 18:48:50 -0800 (PST) Received: from xse173.mail2web.com ([66.113.196.173] helo=xse.mail2web.com) by mx134.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1kynGA-0017hV-QC for rfced-future@iab.org; Mon, 11 Jan 2021 03:48:48 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4DDdSW6wlyz1Bnw for ; Sun, 10 Jan 2021 18:48:43 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1kynG7-0006eT-Sa for rfced-future@iab.org; Sun, 10 Jan 2021 18:48:43 -0800 Received: (qmail 17374 invoked from network); 11 Jan 2021 02:48:43 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.253]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 11 Jan 2021 02:48:42 -0000 To: Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> <84e21c52-f5fd-9792-0778-aa5013a2751d@nthpermutation.com> From: Christian Huitema Message-ID: Date: Sun, 10 Jan 2021 18:48:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 66.113.196.173 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.173/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.173/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/Kuc5 QJ0khQtZvfYbs3ZFrg1wGYjbvhzWX8Co+5c+eruaSxIRXVMlFuiz/acFNeeXt8QYiTpLCsrpI++d V3X+sU8EjDl/TcHIzdK6zs6813067eibU04JcTWQKv3WukWvpFXLV7EjmSE5wYBiRiaIZSi88A2w zVszU7vvUXN2fiw/LSf7q7XsQU29jXGtXEc4yN1paiVoQiig279hArmEazQFKXtiuAJ3NtoLAk8I JKi6HHnknBCFB2XCjKE4atFSdBe4BPzpam1U3Cj9xZx6U4O3QM22Wm73+PngL70p9A+WFDVoKv7C h+bugCmBCoi4dPPF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dlAMC5uyzWopS9Dc1M1eieYq TmOjsnJ/iP/r+XYfJUDjUcQxN+lOXZTJTku7S6JWDow/mc7UHSY/Kg5qDA+OJU3ujwN5vAr2fQEN gxhN/KmvgWDJyQhGvT8x+8ZryF6sGUbZVPi0bE+zStYbSuOFVkkKu19hO5DULTHYDQNvhFY/c+f9 fXrDq4tPylXwlFwJrs1JUwMuz9iOZmBYRrYf0n1m4zuNRcgRKiGg7nXFaZTx26XSvuqDb6Zf+dx5 dgaZqrHTWRjRLK/rGHECkFeaAOY9va+zHJ1uMyxbJq8sS5DA9QD4Mrh3Bu2caezxvyq0YcMzxHWq +DzXvdqOFJyZFEBrwytzyq4nhu0+m3/YUu4UViekgyyW3O5RhlUL6+pD+okHwEE9dSrTROzD4Zdv KoVh3+MrOOK4NgfP/RZivWtTxypUhWZ7DV/QthUn4wTjFg== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 02:48:52 -0000 On 1/10/2021 1:51 PM, Michael StJohns wrote: > So what you're saying is that a random self-selected collection of > IETF participants can not only tell a contractor what to do, but how > to do it?  I note that the RSOC tried this, it wasn't a random > self-selected collection,  and it didn't go well.    I don't believe > this is viable.  I also don't believe its in keeping with the > discussions we've already had. As a matter of fact, the RSOC did *NOT* try to tell the RSE what to do. -- Christian Huitema From nobody Sun Jan 10 19:29: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 D92E53A14FB for ; Sun, 10 Jan 2021 19:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 tagged_above=-999 required=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.262, 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 sAfrPDEKveTX for ; Sun, 10 Jan 2021 19:29:28 -0800 (PST) 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 E85AA3A14FA for ; Sun, 10 Jan 2021 19:29:27 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id w2so2271581pfc.13 for ; Sun, 10 Jan 2021 19:29:27 -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=xbjbrAr75WSEcOaQJRZix1HIelEx/jFvC2dP6ypSv58=; b=SH95hsLYDCY/wOxyG9mZ/h9RbiAmKHMbVi0FVlVr56QAt47aB3tkuqr21a0rERyFnL FWlFOYG3y6NKQbtNzHOYhUqu3MNSGilON4NC8Cyj5uaNgJnADAguVYh4bvA0RRVcc4v7 9VR4F7qHjYUmejCV7xKzZgnQb0LLTQn5WbwjG/8xPuFMzmJaal26LR1nJunVtNGBM37n vr+p6X8OKjn5S0ghvXg+WZl7NhaWUBmyjRLzQj/9tpCTuwZCd22LNKRLBHFnEKyD0O0r BZJnvPsvPBe5swTUhevVNAjySAFhlPbgeR40G2U2o+7kLL4PJ8erEw9QP1yvYTIqicTI uERA== 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=xbjbrAr75WSEcOaQJRZix1HIelEx/jFvC2dP6ypSv58=; b=XjabRT+X/8grv/J2IRDCaTu/1NJIKYoumE9P7yl3w0wpJ3n4K80PUjWlG8W/E4I3w0 cOzNVxxbvNkB7cji/UO01KaezN7nS/aGdC+cLATrix5PTuRzdos99OYEzGumTJ63eLAj SA1l2/oCzAYZff/MAngeN1NxEx1l2A+IqV4EUNY+0kfLs/HUo7grmU617EyAgPK+jf93 Mcc/l129C4Z99yDszsXy1j/oE6hpVNM6NOWaWxOdImKynAfOwYUw0jSmTOhVEUF+IEBv h7XXQYBOrvifARTUwOso6aedFic6/2kuDIFN0SAApd5DAKiEHB6h5l0R+dLcEq7pXYW2 5Z3Q== X-Gm-Message-State: AOAM531+DB9Zo5m0ms7wdi0K/9WatUsrNhZwP2JvP8MOSukejY4mlYKk W1GYwVan3crqJBmTPPIzBZPS+/AWnS0l1Q== X-Google-Smtp-Source: ABdhPJwpZxXqVxNS7z45VmQVMUfvbjwcS5KAEDPM2Kx0Yw3wDwUs5kEpQPqclykIF+yh4SKQPiRaqQ== X-Received: by 2002:a62:d142:0:b029:19e:62a0:ca1a with SMTP id t2-20020a62d1420000b029019e62a0ca1amr17438356pfl.80.1610335766930; Sun, 10 Jan 2021 19:29:26 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id 5sm16678162pff.125.2021.01.10.19.29.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Jan 2021 19:29:26 -0800 (PST) To: Christian Huitema , Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> <84e21c52-f5fd-9792-0778-aa5013a2751d@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Mon, 11 Jan 2021 16:29:21 +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] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 03:29:29 -0000 On 11-Jan-21 15:48, Christian Huitema wrote: >=20 > On 1/10/2021 1:51 PM, Michael StJohns wrote: >> So what you're saying is that a random self-selected collection of=20 >> IETF participants can not only tell a contractor what to do, but how=20 >> to do it?=C2=A0 I note that the RSOC tried this, it wasn't a random=20 >> self-selected collection,=C2=A0 and it didn't go well.=C2=A0=C2=A0=C2=A0= I don't believe=20 >> this is viable.=C2=A0 I also don't believe its in keeping with the=20 >> discussions we've already had. >=20 > As a matter of fact, the RSOC did *NOT* try to tell the RSE what to do.= >=20 > -- Christian Huitema I think my best suggestion for this line of discussion is to stop it as being rather unproductive. We have a lot of running code that tells us that over-thinking procedures in advance leads to more harm than good.= I am bit at a loss to see what's wrong with saying "follow RFC 2418" and leaving it to the people involved to take detailed procedural decisions *when they need to be taken*. Who knows whether GitHub will still be flavour of the month 5 years from now? Brian C From nobody Mon Jan 11 15:32: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 B37FD3A157A for ; Mon, 11 Jan 2021 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.16 X-Spam-Level: X-Spam-Status: No, score=-2.16 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.262, 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 YkrBz9VsGEte for ; Mon, 11 Jan 2021 15:32:27 -0800 (PST) Received: from mail-il1-x129.google.com (mail-il1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FE03A1428 for ; Mon, 11 Jan 2021 15:32:19 -0800 (PST) Received: by mail-il1-x129.google.com with SMTP id n9so1119129ili.0 for ; Mon, 11 Jan 2021 15:32:18 -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=0vP0IjUwxhOuuRekYbAyQiHmaiOgwyO+/ksld47g2CI=; b=ZRZO9lBZtLE7+a2bJv3PhXQj+F/VQSypFswK5Bsr5ZX1aBxjmljaLcRsyAUroNtExh owMaxqifS158W7uzIzo+aEkoL6QCc3du/gNxQOHNOJ7y23UTTP0lS6J3+q42Jh3eUETF UfxIWG/2CvNUpYFdRAbM9p8QQXY04CZQvs1r+98Sdt0oqV44w+xIYx2+4iTDY0BcgirY SykZFf4Afr/blEbXNsqQvh2MXnFFee3glhIreOyof7Y69flD5Uy4DykuV6rfDeDu3kyr h4VAU+drYnDMyUKH/7Y6MXUmYRW8rCZXiXueubg8Kb0+5EKClJ/rXyMK2JikjNix80Ma vvqA== 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=0vP0IjUwxhOuuRekYbAyQiHmaiOgwyO+/ksld47g2CI=; b=JDNiwSiHqXsMg/3SFgYLQv0NJevjRxkAiBK3QPDzrAwC41cmAiPgJu18su5GYN/WP8 kvlgGTAuDIvh3/IHUkLPNcKWNnwS/pSlf9RfNgSDNUmozEqB2rVf6Tin3Ul2vpWqb+K2 5nyz2dgiw1yRk1g6njjH8Yy992dSDV0yUzSzCftmfxdProjRrw9zTcfIpCdIsNJPN1kC 7kyccZe1eHjnkx/sYndNMWn6ABN9+aS3QTTwkT7I5gwx4NCtAmIR5nJxN+BtGrXGLT1r 9MC9guW+60bY0QLdVmGOrl+o/0mReehf8OI2aTZfJvSzuyiisUDQaBnhrvikEc0k3O/O jBOA== X-Gm-Message-State: AOAM530ebe5HKllFlQlwxkyuGmWhs+/3G09F3RJJqEOxrUyWhbgcDKCY Hznxr2dsQHaDHU0ofuiXY+BA6iL2ieUTCyzE X-Google-Smtp-Source: ABdhPJx6U2LAvHNI1gP4JNy8fvSWBuXB5BnYqDWt7QoPj2g/n885qxJ3gu2dHp2UHroBzMdDrrfXLw== X-Received: by 2002:a92:c5a7:: with SMTP id r7mr1308671ilt.219.1610407937918; Mon, 11 Jan 2021 15:32:17 -0800 (PST) Received: from [192.168.1.23] (pool-108-28-189-254.washdc.fios.verizon.net. [108.28.189.254]) by smtp.gmail.com with ESMTPSA id d3sm146786iow.32.2021.01.11.15.32.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jan 2021 15:32:17 -0800 (PST) To: Brian E Carpenter , Christian Huitema , Eric Rescorla Cc: rfced-future@iab.org References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> <84e21c52-f5fd-9792-0778-aa5013a2751d@nthpermutation.com> From: Michael StJohns Message-ID: Date: Mon, 11 Jan 2021 18:32:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jan 2021 23:32:36 -0000 On 1/10/2021 10:29 PM, Brian E Carpenter wrote: > On 11-Jan-21 15:48, Christian Huitema wrote: >> On 1/10/2021 1:51 PM, Michael StJohns wrote: >>> So what you're saying is that a random self-selected collection of >>> IETF participants can not only tell a contractor what to do, but how >>> to do it?  I note that the RSOC tried this, it wasn't a random >>> self-selected collection,  and it didn't go well.    I don't believe >>> this is viable.  I also don't believe its in keeping with the >>> discussions we've already had. >> As a matter of fact, the RSOC did *NOT* try to tell the RSE what to do. >> >> -- Christian Huitema > I think my best suggestion for this line of discussion is to stop it > as being rather unproductive. We have a lot of running code that tells > us that over-thinking procedures in advance leads to more harm than good. > I am bit at a loss to see what's wrong with saying "follow RFC 2418" > and leaving it to the people involved to take detailed procedural > decisions *when they need to be taken*. Who knows whether GitHub will > still be flavour of the month 5 years from now? > > Brian C > > Hi Brian - the problem is that this isn't actually going to look much like a WG looks.  It probably won't have an WG style charter (with defined documents and an end date), it will need to last indefinitely, and it won't be homed to the IESG IRTF or IAB, and it will probably have the oversight body embedded in it (e.g. the stream managers plus a few others).  Among other things, we're going to have IETF funded participants (RSE and RPC and perhaps Jay), with defined responsibilities that may or may not collide with what the WG is doing.  So saying just follow 2418 is going to require a bit of surgery on that document to make it apply to this process. If all of you were willing to basically say that none of the WG process stuff applied to the RSE and RPC unless they agreed it did, I'd be fine with the compromise text.  And there must not be blowback if they decline. But Ekr made it clear that he views the WG as having the ability to circumscribe and direct the RSE through consensus in ways that I think are problematic. If you'd actually address the amount of authority you expect WG consensus to have over a contracted for individual or organization, and how that authority would interact with the contract oversight, we might be able to progress here. Later - Mike ps - I've got an appointment that conflicts with the call tomorrow.  I hope to catch the latter end of the call, but don't count on my attendance. From nobody Tue Jan 12 04:34:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 952B03A11DD for ; Tue, 12 Jan 2021 04:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O7NSk6hwZcEh for ; Tue, 12 Jan 2021 04:34:51 -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 91BE63A0BEF for ; Tue, 12 Jan 2021 04:34:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2327; q=dns/txt; s=iport; t=1610454890; x=1611664490; h=from:mime-version:subject:message-id:date:to; bh=NBp6uVV2ksXnhS4duPnnrLF8G+keNx9mDKbptRkanpk=; b=Gd8ooSnmrIUMOmqfQcZhUInEGbhy+l0cct7eVR5dz5fhmZJQZdOYJTy7 trNfcYbCD7fpXFZBpsFQwTw9YZvmSLHYAagBatuph5F16OOB5XxqkGJK0 ob3OuVnaS3DGM4ksMloP6FjMFciECwMYIAS+exd9gkDGro+UfinPiSsDF c=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BjAwBPlv1fjBbLJq1iHgEBCxIMQIFEC4MhVwEgEo1xn?= =?us-ascii?q?F6GBTCBaAQHAQEBCgMBASUKBAEBhj4mNwYOAgMBAQEDAgMBAQEBBQEBAQIBB?= =?us-ascii?q?gQUAQEBAYY6DIVqgScBhFgBgwYPn1uOHHSBNIQ/AYYLCgaBOIFTi15BggCBO?= =?us-ascii?q?ByCKINJBBQDgQyBB4J/giwEg3tQFp1vnCqDAYMngTeETZI0Ax+DKYovlQifK?= =?us-ascii?q?IkLiTCDbwIEBgUCFoFsIoFZMxoIGxVlAYI/PRIZDY47g1eKWUADZwIGCgEBA?= =?us-ascii?q?wmNWwEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,341,1602547200"; d="asc'?scan'208,217";a="32531951" 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; 12 Jan 2021 12:34:46 +0000 Received: from ams3-vpn-dhcp3656.cisco.com (ams3-vpn-dhcp3656.cisco.com [10.61.78.72]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 10CCYjai011034 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 12 Jan 2021 12:34:46 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_64CDC0B8-5A63-4C9D-937A-5A9128700987"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: Date: Tue, 12 Jan 2021 13:34:44 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.78.72, ams3-vpn-dhcp3656.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Please Doodle for the February Interim 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: Tue, 12 Jan 2021 12:34:54 -0000 --Apple-Mail=_64CDC0B8-5A63-4C9D-937A-5A9128700987 Content-Type: multipart/alternative; boundary="Apple-Mail=_91DDBD81-2EE4-42E6-80D4-E8E0CCE85E4E" --Apple-Mail=_91DDBD81-2EE4-42E6-80D4-E8E0CCE85E4E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear colleagues, Please doodle for our February interim meeting: https://doodle.com/poll/4e5hcs9quc2fy5hi?utm_source=3Dpoll&utm_medium=3Dli= nk = Poll will close Friday, January 15th. Eliot --Apple-Mail=_91DDBD81-2EE4-42E6-80D4-E8E0CCE85E4E Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear colleagues,

Please doodle for our February interim meeting:


Poll will close Friday, January 15th.

Eliot
--Apple-Mail=_91DDBD81-2EE4-42E6-80D4-E8E0CCE85E4E-- --Apple-Mail=_64CDC0B8-5A63-4C9D-937A-5A9128700987 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/9l2QACgkQh7ZrRtnS ejO4iAf/cvxZPTQqq/mK6gOteSNXxNxrhRCvV2PIBmMQsueLohzkE3kKxNOzCT2I jjAL0phaUU5Veic+FegNyrRfwYeQFyU773wvCb5Raf2BSXdse8CvDdmatz9i0v58 cviA/Ax4tuvobCrK1RxfRD0TV3id+HjHhlrhsTBExF49qBUItDBEIGH4aqlJYdA8 wT3Y1GOWTVh63fxn0KHmLvx6u8PLa+kr5qIBv7lneMtmokM+kja0XHhxKq9kqLun NTZtB2ojxwzGbm56JhhfBgOF2rf8qc11SRdNQGm3Ihkw+YWwq2B9/fKD0wHYkemf qgfqPG9KZEIup7S4TxLgJwftJrJM0A== =hzeu -----END PGP SIGNATURE----- --Apple-Mail=_64CDC0B8-5A63-4C9D-937A-5A9128700987-- From nobody Tue Jan 12 05:15:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 458AD3A1232 for ; Tue, 12 Jan 2021 05:15:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zrr6FUet0HLw for ; Tue, 12 Jan 2021 05:15:47 -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 262103A1225 for ; Tue, 12 Jan 2021 05:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6645; q=dns/txt; s=iport; t=1610457347; x=1611666947; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=NFixLNmbGsEI1IpIK8IrBjYc5R9mtaU1+QxOXxrc8Bg=; b=Qo6bzQjuPJbIDOlT099CTHmpRBTu/yTMIL98I1n/YbRsIkOCcYLJIB96 rKYW3FmBggyU/iJDcou0VdK8V9o7e4CUtfvTktRzd6iMEzBcmzw3kzncW NGFZnorqZ7VADz6XGT4gfA71t7lF29QSZiRV+6gZvvxJ+Rmbcoy8esjO+ w=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BmAwD1n/1fjBbLJq1iHQEBAQEJARIBBQUBgg+BI4JVA?= =?us-ascii?q?SASLoQ/iQSIFyUDh22MMogdBAcBAQEKAwEBLwQBAYRKAoFyJjgTAgMBAQEDA?= =?us-ascii?q?gMBAQEBBQEBAQIBBgQUAQEBAYZGhXMBAQEDASNWBQsLGCoCAlcGE4MmAYJmI?= =?us-ascii?q?K4DdoEyhViEehCBOIFThR+GP0GCAIE4DBCCVj6HVjSCLASBVYEdMwNzgSkSK?= =?us-ascii?q?muSLok3nCqDAYMngTeXAQMfomCOUaMSg28CBAYFAhaBbSGBWTMaCBsVZQGCP?= =?us-ascii?q?j4SGQ2OO44wQAMwNwIGAQkBAQMJjVsBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,341,1602547200"; d="asc'?scan'208,217";a="32532750" 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; 12 Jan 2021 13:15:43 +0000 Received: from ams3-vpn-dhcp3656.cisco.com (ams3-vpn-dhcp3656.cisco.com [10.61.78.72]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 10CDFgGG018144 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Jan 2021 13:15:42 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_4B611E3D-A71B-4C99-BD7D-DD7432C8617E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 12 Jan 2021 14:15:41 +0100 In-Reply-To: Cc: Brian E Carpenter , Christian Huitema , Eric Rescorla , rfced-future@iab.org To: Michael StJohns References: <50807633-0780-4F0F-BC99-3E2983C5377E@cisco.com> <2f29a27d-0231-0ad4-cd8a-24dcfe5666b3@nthpermutation.com> <8be85e80-e093-a483-4bfd-4831bb684ab8@nthpermutation.com> <34d1e6a3-6245-2aee-5299-c526a4f14120@gmail.com> <432096ed-a3a3-3a4c-837c-128753d388a4@joelhalpern.com> <5F792469-8ED7-406A-BF9C-66C1A1F14FC9@cisco.com> <5e0da399-8e59-da81-574a-7409bf184681@nthpermutation.com> <1434f1fe-7d5f-35ca-cd49-89b5949fef94@nthpermutation.com> <14FEF253-D8F3-4455-96E8-C9A5D6050CD9@cisco.com> <84e21c52-f5fd-9792-0778-aa5013a2751d@nthpermutation.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.78.72, ams3-vpn-dhcp3656.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 13: new text X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 13:15:49 -0000 --Apple-Mail=_4B611E3D-A71B-4C99-BD7D-DD7432C8617E Content-Type: multipart/alternative; boundary="Apple-Mail=_632EDA57-65A1-42C2-B914-211CFAB2E4D8" --Apple-Mail=_632EDA57-65A1-42C2-B914-211CFAB2E4D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, Just on this point: > On 12 Jan 2021, at 00:32, Michael StJohns = wrote: >=20 > If you'd actually address the amount of authority you expect WG = consensus to have over a contracted for individual or organization, and = how that authority would interact with the contract oversight, we might = be able to progress here. The group has agreed (memorialized in Issue 4) that the LLC is legally & = financially responsible for all contracts, but that doesn=E2=80=99t go = quite so far as to address your point. So let=E2=80=99s pull text from = your draft: The search committee is responsible for creating the RFP and Statement of Work (SOW) documentation to fill the position of RSE, and for seeking the approval for the search to proceed from the LLC board. Any proposed SOW is expected to consistent with the documents that set out the roles and responsibilities of the RSE. Under the model we are now discussing, it is unclear who takes on this = responsibility, and it is clear that we need to resolve the question. = I=E2=80=99ve opened Issue 25 on this point. Eliot --Apple-Mail=_632EDA57-65A1-42C2-B914-211CFAB2E4D8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mike,

Just on this = point:

On 12 Jan 2021, at 00:32, Michael StJohns = <msj@nthpermutation.com> wrote:

If you'd actually address the = amount of authority you expect WG consensus to have over a contracted = for individual or organization, and how that authority would interact = with the contract oversight, we might be able to progress = here.


The group has agreed = (memorialized in Issue 4) that the LLC is legally & financially = responsible for all contracts, but that doesn=E2=80=99t go quite so = far as to address your point.  So let=E2=80=99s pull text from your = draft:

  =  The search committee is responsible for creating the RFP = and
   Statement of Work (SOW) documentation to fill = the position of RSE,
   and for seeking the = approval for the search to proceed from the LLC
   board.  Any proposed SOW is expected to = consistent with the documents
   that set out the roles and = responsibilities of the RSE.  

Under the model we are now discussing, it is unclear who takes on this = responsibility, and it is clear that we need to = resolve the question.  I=E2=80=99ve opened Issue 25 on this = point.

Eliot
= --Apple-Mail=_632EDA57-65A1-42C2-B914-211CFAB2E4D8-- --Apple-Mail=_4B611E3D-A71B-4C99-BD7D-DD7432C8617E 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/9oP0ACgkQh7ZrRtnS ejOgZwf/SzlORZlNBmNBx6mJEk9w8gjk8yZ8jEzaH2q8UFv6Wa/XdEBM3qLMIwSS Nusg/qGp9ZmU8zmruSImVGiu1wdF9tiT3Y5CTg7FkVwm6WXaJe4lbT4jE22uuzbm f34oeDaWpKvkbN9JgNoKMuhMsQtmQ8tpfwsx2xcx+MLDiaP9EytRkOAhffj9Kdmg upvJKsiKdr4QuYCx37liMFktcTWVL1oM6OluV4wNo8lqI6czfzEBrI1/3TqQEiwz b/Xlakjm+ZEBKCGkNQ7RBL7LBXLWBzWT8/eQ5XebRErerh+Yj8ZiU7SQM39OKN8A j+gtzDeC3X0Ocnf6aD48m0OOxDrgKQ== =qisc -----END PGP SIGNATURE----- --Apple-Mail=_4B611E3D-A71B-4C99-BD7D-DD7432C8617E-- From nobody Tue Jan 12 07:01:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBB503A138A for ; Tue, 12 Jan 2021 07:01:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN1yekwIa9pR for ; Tue, 12 Jan 2021 07:01:41 -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 E9C0A3A1396 for ; Tue, 12 Jan 2021 07:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1996; q=dns/txt; s=iport; t=1610463701; x=1611673301; h=from:mime-version:subject:message-id:date:to; bh=8V3zZqwtcpqzCGPYfMN1obLGedN/FOk0gZibIHQAhmA=; b=E1jij0wQou1RVaBmuwEetmxSsbJPegOD6Oh57NthgU47WsX7SxUJjHVT kAH83OSNh3ORx2WyEPZesGCHwCogLtNuMyZm1P0B3c0vIvgRKAlkoxTzo xVxbipPyJ9/Tl3hxYUYW+raCIP3CRkUo6t2SClxGTfb9nFOgu8zq3BKGb U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CRBwCNuP1fjBbLJq1iHgEBCxIMghGDH1cBIBKNcYgXl?= =?us-ascii?q?EeGBYIYBAcBAQEKAwEBJQoEAQGGPiY4EwIDAQEBAwIDAQEBAQUBAQECAQYEF?= =?us-ascii?q?AEBAQGGOgxDFgGFEIEnAQKEVgGDBg+fY44cdIE0hEMDDUGFMgoGgTiBU4wfg?= =?us-ascii?q?gCBOAwQhXECAwGCKIJ/giwEg3tmkX6LcZwqgwEEgyOBN4RNkjQDH6JgnyiSO?= =?us-ascii?q?4NvAgQGBQIWgW0hgVkzGggbFWUBgj89EhkNjjuIa4VFQAN+CYhihHkBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,341,1602547200"; d="asc'?scan'208,217";a="32534702" 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; 12 Jan 2021 15:01:36 +0000 Received: from ams3-vpn-dhcp3656.cisco.com (ams3-vpn-dhcp3656.cisco.com [10.61.78.72]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 10CF1Z7a018875 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 12 Jan 2021 15:01:36 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_ABBCDF8C-08AC-4A4E-BD74-8290C4FD7CCF"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: <226F2787-DF0A-4269-B39B-09E42980CDE9@cisco.com> Date: Tue, 12 Jan 2021 16:01:35 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.78.72, ams3-vpn-dhcp3656.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] Slides for today's meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 15:01:43 -0000 --Apple-Mail=_ABBCDF8C-08AC-4A4E-BD74-8290C4FD7CCF Content-Type: multipart/alternative; boundary="Apple-Mail=_9145AF14-1416-4D18-A7A3-6F65839103CE" --Apple-Mail=_9145AF14-1416-4D18-A7A3-6F65839103CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Can be found at = https://datatracker.ietf.org/doc/slides-interim-2021-rfcefdp-01-sessa-chai= rs-slides/ = Eliot --Apple-Mail=_9145AF14-1416-4D18-A7A3-6F65839103CE Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Can be found at https://datatracker.ietf.org/doc/slides-interim-2021-rfcefdp-01-sessa-chairs-slides/

Eliot
--Apple-Mail=_9145AF14-1416-4D18-A7A3-6F65839103CE-- --Apple-Mail=_ABBCDF8C-08AC-4A4E-BD74-8290C4FD7CCF 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/9uc8ACgkQh7ZrRtnS ejNUJwgAsiUMfRMCM+kIzm3QHqI7ie5zA0JSER+YQA8Xna6pwHIHPOk0gc5TQ/m6 6gULRpQphVXpwaVZXp/xSBftNad7BbHON9BU0IkiusMaXGJXio2lOTFGSaUCumSv JzfU8mSGvR3hc+madaFwvw0q7lUFLBU9FwvBPee3GhUxnnYZtFLuH8WqHCm9pmyc 30sKjmuFyrWthh6HBCOgNDnC8iTU47VZqmKw1aX+i6SWM3o/t3NqAr3Owp8HbZlq zRLdozOVOhdWeYilymlLsdcvyN8Y4aoT28/QAcEdT0dGMG/k8CHX2ohKv7RZrPh4 GZPCBbIjSdazGOeuP/ZM48P0udycyg== =Yjg0 -----END PGP SIGNATURE----- --Apple-Mail=_ABBCDF8C-08AC-4A4E-BD74-8290C4FD7CCF-- From nobody Tue Jan 12 07:02:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29AD93A1380 for ; Tue, 12 Jan 2021 07:02:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=brianrosen-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHzoV8Zfy5XK for ; Tue, 12 Jan 2021 07:02:16 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049A13A137B for ; Tue, 12 Jan 2021 07:02:16 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id p187so4680109iod.4 for ; Tue, 12 Jan 2021 07:02:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brianrosen-net.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=cyj+KYPuCXM0mmXObK3wLhOm0HJFfBKPnWb603UkB2E=; b=kkDQGREacAQUMc5Feu0bX2NDTM/d22BG7IP/zI92p3pM2CsOEA3IPhaq0xo1xDPOUL 5sMCUK+aDShKpcHJdOM7Hz0LXS5oZVv+RMbghPPAvyXAUaE/TH0uyDiGPWLA8JuAIVy4 cu6nvOH45GiEq9XTe5ZqKG5sBLJSokQP9kuEw8Nbn7da65Jxe0r1g0DrjQ9miSJknVJH ZekwPt/FID9bz+XBAf/7vnLxdUlrVWiWS4b4UgxLbC+6PBc74eotUp7gFwulQV8OZF65 d2Jxwqu+Q+HbeNNqhiNSexPTXHcGUgQwpWBzpubUIN8cOWjtJ3tSBhY3XDsqQZ46Si4o vSJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=cyj+KYPuCXM0mmXObK3wLhOm0HJFfBKPnWb603UkB2E=; b=WkQKTyEvknRtot+sEiUrSv0oAqlflFm3ScSka0hqKxB2G2BB5qN7n+rUQwis30bTTd BWkeXyz5Z3WkTxpE6BK/X0ou4CGyQ16/j1MpSRPW4+/kCwZogQy61Ktb7das8U9c39Kn KC+53ordteFRkfvNe2yRd49VyLH2g7PulEdEc02Rm1yGrjjZ/PMeUZog1fpZU5I0bSmn 3+7oiLVchtSNkpWo0WzqrcD2cSvEeE9FqmCId5+JniaHNmGvAzcbWxYakBG+FJ1YoGg0 ClWM8YUGqQJPk8yPBFhSlQl6X8OktmgpG4aB24872gJoIE91hitto34CsYbPthpz+v1b u/vw== X-Gm-Message-State: AOAM533viByw/rGTiQPh4dx/axRzM9CSb1GqnGVzTaUeCxmIPZ70vdTS fhQ2tp+oua4GGEe3uBjD98RyAdWZBEwiiizB X-Google-Smtp-Source: ABdhPJyLcyh6+5m8O2ZhGXSrEWJspFMYvbYpnfIQeGjor8xjfEqFem35PNuIhA6QwQSDgrfu7bQ7UQ== X-Received: by 2002:a92:cda1:: with SMTP id g1mr4372074ild.267.1610463734976; Tue, 12 Jan 2021 07:02:14 -0800 (PST) Received: from brians-mbp-2871.lan (dynamic-acs-24-154-119-158.zoominternet.net. [24.154.119.158]) by smtp.gmail.com with ESMTPSA id v14sm2187604ilu.78.2021.01.12.07.02.14 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Jan 2021 07:02:14 -0800 (PST) From: Brian Rosen 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\)) Message-Id: Date: Tue, 12 Jan 2021 10:02:13 -0500 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Rfced-future] Note Takers for today's interim X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 15:02:18 -0000 We need note takers for today=E2=80=99s meeting. Any way you want to = take them will work, but the codimd way is nice and usually has helpers.= From nobody Wed Jan 13 02:22: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 026B73A0C33 for ; Wed, 13 Jan 2021 02:22:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.972 X-Spam-Level: X-Spam-Status: No, score=-9.972 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zgtf2IQNFpdt for ; Wed, 13 Jan 2021 02:22:45 -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 D0D333A0C35 for ; Wed, 13 Jan 2021 02:22:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4278; q=dns/txt; s=iport; t=1610533365; x=1611742965; h=from:mime-version:subject:message-id:date:to; bh=/aoIxg2Fe/8vysV6PeQYt++zDwNhBU0XZb1q/xBif8o=; b=JDRTSYtxesJXaHE+PMIQ1gi0yh+CeHwOo7SkvQGdFcbDPiBc19Bcc9zR Kt44YHRTrAS0NOkT0ekuNzvoLMIhvOOSk3pUfa54bc4Hmvh+X7FeiNnI5 vt1vUPV7V3AtcW7RRmhRICdH2gXJYx1DHRmKMxlqt8fdUsfw7zXD8olzR w=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AOBAAsyf5fjBbLJq1YCh4BAQsSDIUwVwEgEi6EP4kEi?= =?us-ascii?q?BkllCKGNYFoBAcBAQEKAwEBIwwEAQGGNyY4EwIDAQEBAwIDAQEBAQUBAQECA?= =?us-ascii?q?QYEFAEBAQGGOgyGHXUpFQKEGAGDBg+fTo4cdoEyilgKBoE4gVOFH4cAggCBO?= =?us-ascii?q?AwQgUGFShpsDoJLNIIsBIN7IEYLgXCPWIwcnCqDAYMngTeXAQMfgymKL5UIs?= =?us-ascii?q?WODbwIEBgUCFoFtIYFZMxoIGxVlAYI/PRIZDVeNZINXillAAzACNQIGAQkBA?= =?us-ascii?q?QMJjVsBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,344,1602547200"; d="asc'?scan'208,217";a="32622792" 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; 13 Jan 2021 10:22:40 +0000 Received: from ams3-vpn-dhcp131.cisco.com (ams3-vpn-dhcp131.cisco.com [10.61.64.131]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 10DAMdpp020378 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 13 Jan 2021 10:22:40 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_6C437F6D-B51B-4197-9E45-7B03A3EDB822"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: <0204D154-0843-4882-B1D9-E1CE6D8CC4C2@cisco.com> Date: Wed, 13 Jan 2021 11:22:37 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.64.131, ams3-vpn-dhcp131.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] AIs from yesterday's call X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 10:22:47 -0000 --Apple-Mail=_6C437F6D-B51B-4197-9E45-7B03A3EDB822 Content-Type: multipart/alternative; boundary="Apple-Mail=_320D06B9-6B79-4991-BFB7-2393F0CCA064" --Apple-Mail=_320D06B9-6B79-4991-BFB7-2393F0CCA064 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks to everyone who joined the meeting yesterday. This is just a = very brief note about actions coming out of the call, a recording of = which can be found here = : John Klensin agreed to take a look at relevant BCPs governing meeting = participation, to identify aspects that we would need to adapt to our = use. This, to incorporate anti-harassment, IPR/Note Well stuff to = augment the text that we have for Issue 13. More on this when the = minutes come out. EKR agreed to take a swing at the function and management of the = oversight body, taking into account our discussion. Extra credit if he = can come up with composition. Note that anyone else is welcome to do the = same. We=E2=80=99re asking for a view of both within 2 weeks, but of course = this is =E2=80=9Cbest effort=E2=80=9D service. The are obviously not full minutes. We=E2=80=99ll get those done in the = next few days. Please remember to doodle if you haven=E2=80=99t = already. Deadline is Friday. Eliot --Apple-Mail=_320D06B9-6B79-4991-BFB7-2393F0CCA064 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Thanks to everyone who joined the meeting yesterday. =  This is just a very brief note about actions coming out of the = call, a recording of which can be found here:

  • John Klensin agreed = to take a look at relevant BCPs governing meeting participation, to = identify aspects that we would need to adapt to our use.  This, to = incorporate anti-harassment, IPR/Note Well stuff to augment the text = that we have for Issue 13.  More on this when the minutes come = out.
  • EKR agreed to take a swing at the function and = management of the oversight body, taking into account our discussion. =  Extra credit if he can come up with composition. Note that anyone = else is welcome to do the same.

We=E2=80=99re asking for a view of both = within 2 weeks, but of course this is =E2=80=9Cbest effort=E2=80=9D = service.

The = are obviously not full minutes.  We=E2=80=99ll get those done in = the next few days.  Please remember to doodle if you haven=E2=80=99t = already.  Deadline is Friday.

Eliot
= --Apple-Mail=_320D06B9-6B79-4991-BFB7-2393F0CCA064-- --Apple-Mail=_6C437F6D-B51B-4197-9E45-7B03A3EDB822 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl/+ye4ACgkQh7ZrRtnS ejNydwf/aJsVbd0aNllMiYw3fFuJfWpypBkNIE1rKUPFPqIb1tfYPlm4iOF1k3v4 fkGJjOMJqWCIqvxiyH4iyQosKkUyiXyjRMtA4p5XwEgVS0KLHwU35cAEMlXt6nu5 A5fwooL4rdKv8Dmnv1nJUUTv5tjYP2aEbdpEnpF1kcOtCFMVjnxW7pE4rraAtWDP StfJqYfIIRNOW+lomnfT8nNEj4YeCyCv1J/QAK7m7k7a2dE6C4oqMTh1jg9PDF0Z /dq9VUra7nYqlA8FDS+l8zsOaTuiCLcuTqgjKeXhvRa9aTjPtkegPwGHotxzIwbE wl5wc4/yQP0qlFdP3Yz2IoBLCEY71g== =FYfH -----END PGP SIGNATURE----- --Apple-Mail=_6C437F6D-B51B-4197-9E45-7B03A3EDB822-- From nobody Fri Jan 15 08:04:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB1863A0C1D for ; Fri, 15 Jan 2021 08:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.973 X-Spam-Level: X-Spam-Status: No, score=-9.973 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, 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 f0zPB166J0xb for ; Fri, 15 Jan 2021 08:04:18 -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 C51CD3A0C1C for ; Fri, 15 Jan 2021 08:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1027; q=dns/txt; s=iport; t=1610726657; x=1611936257; h=from:mime-version:subject:message-id:date:to; bh=XtvmptzU3c5YCatz9+/ERA4ZGRMs13kHykxsNVJpEuo=; b=iymDi4QIoDUuW1kikhi21orBwH9GeVMxGQ5+6sxd2oWNGkvMCidN1hBJ PnHsOVE5/Tq4eSEo7Iulp3smCxGNEV8owqnoY2yzAbIRXhfiO00gxibWK p5bt5PgfMsE8gsiyeyAiWQkOLfwqM79/Y0YxB7c7zhzSTbZdxYL1ZeAZd k=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BKAwDbuwFgjBbLJq1iHgEBCxIMQIFEC4MhVwEgEo1ym?= =?us-ascii?q?RuLbgQHAQEBCgMBASUKBAEBhjomNwYOAgMBAQEDAgMBAQEBBQEBAQIBBgQUA?= =?us-ascii?q?QEBAYY6DItqAYMGD6A8jhx0gTSEQAGFeAoGgTiBU4Z+hGJBggCBOByCVj6CX?= =?us-ascii?q?QQUA4ITgn+CLASDe1AWnXecLoMBgyiBN4RPkjkDH4MYARGKL4U1j1qfM4kNi?= =?us-ascii?q?TODcAIEBgUCFoFsIoFZMxoIGxVlAYI/PRIZDY47g1eKWUADZwIGCgEBAwmNB?= =?us-ascii?q?QEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,349,1602547200"; d="asc'?scan'208";a="32689253" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jan 2021 16:04:13 +0000 Received: from [10.61.222.164] ([10.61.222.164]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 10FG4DZj027500 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 15 Jan 2021 16:04:13 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_F85B6E7D-B856-4AB7-947A-842257EAA111"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: Date: Fri, 15 Jan 2021 17:04:12 +0100 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.222.164, [10.61.222.164] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] reminder: please doodle for next interim meeting X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jan 2021 16:04:21 -0000 --Apple-Mail=_F85B6E7D-B856-4AB7-947A-842257EAA111 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii https://doodle.com/poll/4e5hcs9quc2fy5hi?utm_source=poll&utm_medium=link --Apple-Mail=_F85B6E7D-B856-4AB7-947A-842257EAA111 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmABvPwACgkQh7ZrRtnS ejO+/ggAuCNyCmPrJJmcIQKzRVd/k64ebZ5kXGautCtJ/8O053CkvR1GaxUdvEFE Lzv6uZUtCsBR3Fz3fJ9WA58HPyxFfuLXo15wy9EDyyohFRM/180TW0sxwJ04BVS4 9lJYSQLZch3r2umN19Upplgy5ecZ+G7NEiVHsVcP/jCmx7ngyZR1FWHzLHus0gR0 dcD7uWUdEdPHhI0Hugck0bwTgo1YKZX9kNAFYICXduV0/gRHe2pUE4bvPTOfKq1M 6b6LNObI6/amcIe9vV31MEiUXshNr59Fi9aPQxr02QuEcqJR+5bekwrOgdUzHnQI 0bdA9pSeoDE/Me0jXbOPhugGt5tbBg== =tvjr -----END PGP SIGNATURE----- --Apple-Mail=_F85B6E7D-B856-4AB7-947A-842257EAA111-- From nobody Tue Jan 19 07:15:20 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 317BD3A1599; Tue, 19 Jan 2021 07:15:11 -0800 (PST) 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.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161106931092.26557.6554667492371437703@ietfa.amsl.com> Date: Tue, 19 Jan 2021 07:15:11 -0800 Archived-At: Subject: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2021-02-18 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: Tue, 19 Jan 2021 15:15:11 -0000 The RFC Editor Future Development (rfcefdp) Program will hold a virtual interim meeting on 2021-02-18 from 21:00 to 23:00 Europe/Zurich (20:00 to 22:00 UTC). Agenda: We will continue to work on our issues list, with a focus on establishing parameters of how the oversight body and open working group function. Information about remote participation: https://cisco.webex.com/cisco/j.php?MTID=meada1c54dde3cfddb8022e917f944279 From nobody Tue Jan 19 15:20:46 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAFAC3A1879 for ; Tue, 19 Jan 2021 15:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=g60d6nUN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=WcXonZa1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmNZr7eVpZWK for ; Tue, 19 Jan 2021 15:20:44 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0AD43A1874 for ; Tue, 19 Jan 2021 15:20:43 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 09AF95C0182 for ; Tue, 19 Jan 2021 18:20:43 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Tue, 19 Jan 2021 18:20:43 -0500 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=fm1; bh=E3L1zl0X7y Cr+YVbhjD7Iec9I3dVst9q5UCiDSDSI0c=; b=g60d6nUNkbWhy8o/kUH6M7ZUqz bDyZ+QbKZdDzfz230qayr5SPd0lKBLj/IWqpbrcupbq6M24mnrjdFiH6jgOlNTfi YHq8F/Ir71FKr9O7lZW27RGjNh7ikSIr7RigxiQ7g0OiHn6gAeTfg8E1bK/G70bI /afsLeIWkXUQRnFO3+N+nrkjBsEwmE5MNnWRXF3MhpzbAuweGVq4oCQJXAjIMzDa v+iaQitrK/BZmp0SkCFRyCxTk29BRlsp1d0xDR/1Gq8LChLsAcaZQEGTPewWbOIp JMAAVt1gTQO9sFTxDvweN+0C3NMYCPf+m7+CcrbQZe8vHKV56qcK8/Iq0WOw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=E3L1zl0X7yCr+YVbhjD7Iec9I3dVst9q5UCiDSDSI 0c=; b=WcXonZa1b0ZOZ/JVlryDHD+dA44Id/t7Ip5bPiTJ7ZGFBTQtkv2RyNcV/ sv619r44yqebtwQzMIcU1mBLDDPfW3lkOu7tmS/wxNPKRgiZc4h++v/CVIYjyRw3 pHmxzuEDTxXqEuWRxpDAjQ0td8Ju4JLCjzvTfTjzrYrkeVwl6+gsrwoalUTz0IEX UHDvDrVbj/Gc6Lpa1kDgtu0nrIRdxSifCEMcrGNFf7k98Ab+yBli7Ocykoj5uSrH zdHGxN/4Qj4T1CqxsUil5lI6vi1brdvrZX5QM2jrKq3l5UYcYdGuBHPdMnL0PbXA HVQO1QmVqvzqtXT9rjdD1M46gDnGw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddugddutdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhephfgtgfgguffffhfvjgfkofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeefgedvteefvdetuddvfefgieffueffve ekleetgeegudfgtddtvdekjeffiefhveenucffohhmrghinhepthhimhgvrghnuggurght vgdrtghomhdpfigvsggvgidrtghomhdpihgrsgdrohhrghdpmhhnohhtrdhnvghtnecukf hppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghrufhiiigvpedtnecurfgr rhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvght 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 338381080063 for ; Tue, 19 Jan 2021 18:20:40 -0500 (EST) 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.40.0.2.32\)) Date: Wed, 20 Jan 2021 10:20:38 +1100 References: <161106931092.26557.6554667492371437703@ietfa.amsl.com> To: rfced-future@iab.org In-Reply-To: <161106931092.26557.6554667492371437703@ietfa.amsl.com> Message-Id: <7C624C95-B57C-4718-A918-81E9BC69FB01@mnot.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) Archived-At: Subject: Re: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2021-02-18 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jan 2021 23:20:46 -0000 For convenience: = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DRFC+Editor+Fut= ure+Development+Program+Meeting&iso=3D20210218T20&p1=3D1440&ah=3D2 Note that there's icalendar link from that. > On 20 Jan 2021, at 2:15 am, IAB Executive Administrative Manager = wrote: >=20 > The RFC Editor Future Development (rfcefdp) Program will hold > a virtual interim meeting on 2021-02-18 from 21:00 to 23:00 = Europe/Zurich (20:00 to 22:00 UTC). >=20 > Agenda: > We will continue to work on our issues list, with a focus on = establishing > parameters of how the oversight body and open working group function. >=20 > Information about remote participation: > = https://cisco.webex.com/cisco/j.php?MTID=3Dmeada1c54dde3cfddb8022e917f9442= 79 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jan 19 16:45:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8387C3A0C66 for ; Tue, 19 Jan 2021 16:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=DidEbWTa; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=P7kkzQT3 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CFlRJ8om0jju for ; Tue, 19 Jan 2021 16:45:37 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26BAA3A0B05 for ; Tue, 19 Jan 2021 16:45:25 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 2F4151619 for ; Tue, 19 Jan 2021 19:45:24 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 19 Jan 2021 19:45:24 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=EFZDHI2fqeIm3F1krM9DGAfZdN3DO/5 F543y6nMAaEM=; b=DidEbWTaXZ32WuFEwssfawlEbQChxmhCE3pNaJp4RATSk/n vMlO9KoOPRFtdVLSQpROQv+aa9SoeS3Dj8XUq683/UAT63m3I2wvN5221FotGzOR IMsBIOE51Mbt0qOKK4XkjEDY8wMLPTYhvr+AotfMNLPy0RTzRNK2oPAUaMU4SGX2 mPqXEn8evqwkNokSJQkOAZRaopaXjrhKq0BTUQh2Hi3Sr7DBZtJnhsuFLyJpGHyr JqqS5rU7krCUIQNNUTW0SCgb6pWhtSVtEnTwFwmVDgZ0VJwMEshiJ68vvP8sgLML 3vORjketBY/yN6OS7BrmSm7m2cZ6/eFeaceVLqw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=EFZDHI 2fqeIm3F1krM9DGAfZdN3DO/5F543y6nMAaEM=; b=P7kkzQT37qcwZ8Vy8zbipR z314wobk5jbc7OOWcc7fL8/qMMVbX4BfZi64LfrRbXGzdLqQ6Is2JkO6GFS4wpwx 1rtLzjsfIBhZqxzyi8J80JWIAavi+LWPnU9BcAchDlK6uUP6BxBdHG64MRofSOL4 bcn5IgVSeMMwSOEL6LSKHd1Un7ds/w2lgYH+2LG8gFqLYCEyvyPPTB1/MXZoLXak D5FlUWeZlEyRQ+O5V6TsdAcEje3rH0jKlHtirLRGfj9yUrrwLz298dJrm/LBoRPS Kmpwj9l6NgFYtMU5KePoVF8o1rzzFjkQ3rShLRlP5Zd7nQIoYJdio1K0mrcBMR4w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledruddugddvjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepveekgeetjeehveefheetke euiefhtedtkefhffetfeetkeekieejieegudffjedvnecuffhomhgrihhnpehivghtfhdr ohhrghdpthhimhgvrghnuggurghtvgdrtghomhdpfigvsggvgidrtghomhdpihgrsgdroh hrghdpmhhnohhtrdhnvghtnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehm rghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8EC284E005D; Tue, 19 Jan 2021 19:45:23 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-45-g48392560e8-fm-20210104.001-g48392560 Mime-Version: 1.0 Message-Id: <8e6db416-579e-445b-95c5-5cfc62d68f4f@www.fastmail.com> In-Reply-To: <7C624C95-B57C-4718-A918-81E9BC69FB01@mnot.net> References: <161106931092.26557.6554667492371437703@ietfa.amsl.com> <7C624C95-B57C-4718-A918-81E9BC69FB01@mnot.net> Date: Wed, 20 Jan 2021 11:45:04 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?RFC_Editor_Future_Development_=28rfcefd?= =?utf-8?q?p=29_PROGRAM_Virtual_Meeting=3A_2021-02-18?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Jan 2021 00:45:40 -0000 This is also in the upcoming meetings calendar, which I thoroughly recommend: https://datatracker.ietf.org/meeting/upcoming.ics - it even puts most meetings in the early morning, so it rarely pollutes my working hours. Of course, neither the upcomings meetings calendar, nor Mark's link, contain a link to the webex session, which always trips me up. Finding these emails at the time of the call means I'm inevitably late.. On Wed, Jan 20, 2021, at 10:20, Mark Nottingham wrote: > For convenience: > > https://www.timeanddate.com/worldclock/fixedtime.html?msg=RFC+Editor+Future+Development+Program+Meeting&iso=20210218T20&p1=1440&ah=2 > > Note that there's icalendar link from that. > > > > On 20 Jan 2021, at 2:15 am, IAB Executive Administrative Manager wrote: > > > > The RFC Editor Future Development (rfcefdp) Program will hold > > a virtual interim meeting on 2021-02-18 from 21:00 to 23:00 Europe/Zurich (20:00 to 22:00 UTC). > > > > Agenda: > > We will continue to work on our issues list, with a focus on establishing > > parameters of how the oversight body and open working group function. > > > > Information about remote participation: > > https://cisco.webex.com/cisco/j.php?MTID=meada1c54dde3cfddb8022e917f944279 > > > > -- > > 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 > From nobody Wed Jan 20 00:01: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 59A633A0C33 for ; Wed, 20 Jan 2021 00:01:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.973 X-Spam-Level: X-Spam-Status: No, score=-9.973 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, 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 7nhYQNz80uym for ; Wed, 20 Jan 2021 00:01:46 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B603A0BDE for ; Wed, 20 Jan 2021 00:01:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2982; q=dns/txt; s=iport; t=1611129706; x=1612339306; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=n4MZ0iKZ+0SJ00GD9rtdUw4157FIrgjM/YlBAQmz7xM=; b=B9VlWBbERSeP0+63CzQNYHoAkrj0oEYfk52drl5XI1XcOefMrE2d7WFC 1x8l1YHArm6lcOVxsUZORKc5rcsFfVz9qTKUpMjGkybeccs40DSIXyhHq Rg9Nnn1ZhLnnUeIlHsIR315AixfJ34ZTvSQOsfgirC5QiwOMzWaRg9c+M I=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BEAgD04QdgjBbLJq1GHBwBAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFPgyFXASASL41EiEwDnD0EBwEBAQoDAQEYDwgEAQGESgKBdSY4EwIDAQEBA?= =?us-ascii?q?wIDAQEBAQUBAQECAQYEFAEBAQGGOgyFcwEBAQMBAQFsCwULCw4KLicwBhODJ?= =?us-ascii?q?gGCZiAPQK42dIE0hVmEaAoGgTiBU4tkQYIAgREnHIJWPoEEgVkBAQIBFoUTg?= =?us-ascii?q?iwEgnCBBQICAiIuCwsqPhlQOZtvnDCDAYMogTeEUJI5Ax+TD49bnkRzkkSDc?= =?us-ascii?q?AIEBgUCFoFtIYFZMxoIGxU7KgGCPj4SGQ1YjVUMAgkUgzqEWTuFRUADMAI1A?= =?us-ascii?q?gYKAQEDCYwiAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,360,1602547200"; d="asc'?scan'208";a="32791155" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Jan 2021 08:01:44 +0000 Received: from [10.61.223.70] ([10.61.223.70]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 10K81ht6026466 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 20 Jan 2021 08:01:44 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B681F5AE-6B7B-459B-8DF1-8F055BB84C7A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Wed, 20 Jan 2021 09:01:43 +0100 In-Reply-To: <8e6db416-579e-445b-95c5-5cfc62d68f4f@www.fastmail.com> Cc: rfced-future@iab.org To: Martin Thomson References: <161106931092.26557.6554667492371437703@ietfa.amsl.com> <7C624C95-B57C-4718-A918-81E9BC69FB01@mnot.net> <8e6db416-579e-445b-95c5-5cfc62d68f4f@www.fastmail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.223.70, [10.61.223.70] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2021-02-18 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 20 Jan 2021 08:01:48 -0000 --Apple-Mail=_B681F5AE-6B7B-459B-8DF1-8F055BB84C7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Martin and Mark, Thanks for pointing that out. I will take that as a suggestion to = repost the meeting information Day Of. Eliot > On 20 Jan 2021, at 01:45, Martin Thomson wrote: >=20 > This is also in the upcoming meetings calendar, which I thoroughly = recommend: https://datatracker.ietf.org/meeting/upcoming.ics - it even = puts most meetings in the early morning, so it rarely pollutes my = working hours. >=20 > Of course, neither the upcomings meetings calendar, nor Mark's link, = contain a link to the webex session, which always trips me up. Finding = these emails at the time of the call means I'm inevitably late.. >=20 > On Wed, Jan 20, 2021, at 10:20, Mark Nottingham wrote: >> For convenience: >>=20 >> = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DRFC+Editor+Fut= ure+Development+Program+Meeting&iso=3D20210218T20&p1=3D1440&ah=3D2 >>=20 >> Note that there's icalendar link from that. >>=20 >>=20 >>> On 20 Jan 2021, at 2:15 am, IAB Executive Administrative Manager = wrote: >>>=20 >>> The RFC Editor Future Development (rfcefdp) Program will hold >>> a virtual interim meeting on 2021-02-18 from 21:00 to 23:00 = Europe/Zurich (20:00 to 22:00 UTC). >>>=20 >>> Agenda: >>> We will continue to work on our issues list, with a focus on = establishing >>> parameters of how the oversight body and open working group = function. >>>=20 >>> Information about remote participation: >>> = https://cisco.webex.com/cisco/j.php?MTID=3Dmeada1c54dde3cfddb8022e917f9442= 79 >>>=20 >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_B681F5AE-6B7B-459B-8DF1-8F055BB84C7A 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAH42cACgkQh7ZrRtnS ejOuXwf7BOSmfETkoin2K+blwsNWbGFUrVwvqv2N34HBrfxm6G5FQ4PfvnLD7vk0 WM7B6fA/Ts5U+JL9CHrxF3EdiJTSHPMRLeUbQgjFEmaMQkASe5xsiUu9RWxEHjJz fkCTfS6WJjfEuOWMg2GxbV7uUTQwWA5q4jAE3W6JkKW1D80QPiTs2V+5knvJBpZV XWx2a/OyUka8JB/5/YU5XVnSLLoNFG5yOrH8KKeDJR98KxIE7LhUjc7YohwduZEL rzdtpYhXu4siaraKJtDXLcLvwILQZPGYSspj01tJPfu0AILx2zS7YjrhqhrbL2jg qGpybuyv429sSQqq+kAT4uiNWoKl+w== =xlM9 -----END PGP SIGNATURE----- --Apple-Mail=_B681F5AE-6B7B-459B-8DF1-8F055BB84C7A-- From nobody Mon Jan 25 07: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 6EBB33A144E for ; Mon, 25 Jan 2021 07:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9miJqfO9vDU7 for ; Mon, 25 Jan 2021 07:10:39 -0800 (PST) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA443A145A for ; Mon, 25 Jan 2021 07:10:38 -0800 (PST) Received: by mail-lj1-x233.google.com with SMTP id p13so15716500ljg.2 for ; Mon, 25 Jan 2021 07:10:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rgb79AQMc6nuz+b+6LPMWa67wfrZWPlTRy3GZVDyafM=; b=KaxoP9vXJGrtbg5Mt2XtzC12ZIao0QAnQDmzrDldgChCJUO6rf73LbEYnE0TsLC3Vc mlhcdzpIx+fx99amIW0M37HufGTby1rgZ5Y1evkEMFUQJgkN7+LIi4JFLzlUmtvGVhj5 te1A8PG2+2bTqlWznutlrMiiuszT4nKAoQSnfZyFhievWZufu6qws8mc/FZrBjnB9evH EzfwzaiNBMCw47et8YwvkKUODVL8d3zzIzsYgEm+nITM66TAV+UB5psSmZU72iAVoKGS V3uh/57/yANJBjdzG3KqPcywQv5wPyAQ/w14wsQdjyaKOZu2JcjSWVpT9UGjemofXrDI 3N4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rgb79AQMc6nuz+b+6LPMWa67wfrZWPlTRy3GZVDyafM=; b=A6Ic6tKCd/1a5kZdk0WaNeM5rByUU4wsWqUSmlOBVHzRwuhGpqI8siSvMOBKfHIME2 FMum7HLfqDPtcsiP0weHnAa3tIO7wbnWTcajXRCs8MOqkXXAsBmWny62/gTKcX6B52wk mQ5xd8dyP4xDdl4xsKqwvyVwubK7Ama/0mvJFcW9kyPVoT35RFFk1raDQ50KabDZDRN/ azKRUOlALd1xz84qkcMQkyQC2SL0CKveY0CI8WMfXo/61cOqsBar+LfYaNUpcFPcnovZ +7RLmpYtXvsOh7ueCu9/iNDUakKc3VN5wTLtJdTIv0CR/YmxMrWNVnEfaVms5urs4w3L 46Yg== X-Gm-Message-State: AOAM5325FuzLuIL9tSM1h/dhtH8LCbkiOCxXie8PwQd14duT82PU7D7O KM5DlKrEsyMtD7Bw8nnp2YsjPplU3gl+WNYUl/9ywpJHcpmhdQ== X-Google-Smtp-Source: ABdhPJwTYWFph4P7Oqb9KHux0YBCdJyIjog9ongcc1B3/nS9+f++I1rHoRDYFF+PIklFeBsb/N46ibz3vSl0NZhwYPo= X-Received: by 2002:a2e:8106:: with SMTP id d6mr399180ljg.217.1611587436171; Mon, 25 Jan 2021 07:10:36 -0800 (PST) MIME-Version: 1.0 From: Eric Rescorla Date: Mon, 25 Jan 2021 07:10:00 -0800 Message-ID: To: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000a887b705b9baf0ab" Archived-At: Subject: [Rfced-future] Proposed "Oversight Body" structure X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 15:10:44 -0000 --000000000000a887b705b9baf0ab Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I was asked to come up with a proposal for what to do about a proposed oversight body. The current overall proposals are for a two-level structure, which has: An open WG that is responsible for producing proposed changes to the RFC series An Approval Body [name TBD] which is responsible for approving the output of the WG At the last interim, it seemed like there were at least three rationales that people thought that the AB might potentially use to disapprove a proposed change: 1. It didn=E2=80=99t work for one of the Streams 2. The process wasn=E2=80=99t followed 3. They didn=E2=80=99t agree with the contents I heard a fair amount of agreement on the first two of these, but also a number of people objecting to (3) on the grounds that the AB shouldn=E2=80=99t be overriding the judgement of the WG. Conflicts between = the IESG and WGs on the contents of documents have been a persistent feature of the current system, leading to, for instance, the DISCUSS criteria. Given the amount of distrust of leadership making decisions here, I think we should consider not replicating that structure. It also seems to me that the function of determining whether something works for the individual Streams is a question for the Stream Managers, but they=E2=80=99re not particularly well positioned to determine whether the process has been followed. Given that this WG is likely to exist under the auspices of the IAB and they are likely to select the chairs, it seems like they are the natural body to determine whether the process was followed. With that in mind, what I propose is the following: An RFC Stream Manager Committee (RSMC) would be formed, consisting solely of the four Stream Managers. They would need to approve each process change, but objections need to be limited to the question of whether a specific change would cause harm to their own Stream. The specific voting rules are TBD, but the obvious choices are unanimity or 3/4 supermajority. If we require unanimity, that creates the concern of allowing one manager to stonewall, which seems suboptimal. The IAB would be responsible for ensuring that the process was followed. I think the easiest way to do this is not for them to formally approve documents coming out of the WG but rather for them to be an appeals body. However, the appeal grounds should be limited to process issues, not substantive objections. I hear that there are concerns that the WG won=E2=80=99t listen to expert advice. In my opinion, = the right balance here is that the expert gets an opportunity to speak and the process requires they be heard and the WG explicitly decide not to take their opinion, but the WG is the final decision maker. Then =E2=80=9CW= G did not fully consider and decide on whether to take expert advice=E2=80=9D can become an appeal ground, but it=E2=80=99s not an opportunity for the IA= B to substitute their own judgement for the WG=E2=80=99s. In short, the WG would be responsible for the strategic work, but would be subject to two forms of narrowly scoped review: the stream managers for "this will break my stream" and the IAB for "the process wasn't followed". -Ekr --000000000000a887b705b9baf0ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I was asked to come up with a proposal for what to do abou= t a
proposed oversight body.

The current overall proposals are fo= r a two-level structure, which
has:

An open WG that is responsibl= e for producing proposed changes to the
RFC series An Approval Body [nam= e TBD] which is responsible for
approving the output of the WG

At= the last interim, it seemed like there were at least three
rationales t= hat people thought that the AB might potentially use to disapprove a propos= ed change:

1. It didn=E2=80=99t work for one of the Streams
2. Th= e process wasn=E2=80=99t followed
3. They didn=E2=80=99t agree with the = contents

I heard a fair amount of agreement on the first two of thes= e, but also
a number of people objecting to (3) on the grounds that the = AB
shouldn=E2=80=99t be overriding the judgement of the WG. Conflicts be= tween the
IESG and WGs on the contents of documents have been a persiste= nt
feature of the current system, leading to, for instance, the DISCUSS<= br>criteria. Given the amount of distrust of leadership making decisionshere, I think we should consider not replicating that structure.

It= also seems to me that the function of determining whether something
wor= ks for the individual Streams is a question for the Stream
Managers, but= they=E2=80=99re not particularly well positioned to determine
whether t= he process has been followed. Given that this WG is likely to
exist unde= r the auspices of the IAB and they are likely to select the
chairs, it s= eems like they are the natural body to determine whether
the process was= followed.

With that in mind, what I propose is the following:
An RFC Stream Manager Committee (RSMC) would be formed, consisting
sol= ely of the four Stream Managers. They would need to approve each
process= change, but objections need to be limited to the question of
whether a = specific change would cause harm to their own Stream.=C2=A0 The
specific= voting rules are TBD, but the obvious choices are unanimity
or 3/4 supe= rmajority. If we require unanimity, that creates the
concern of allowing= one manager to stonewall, which seems suboptimal.

The IAB would be = responsible for ensuring that the process was
followed. I think the easi= est way to do this is not for them to
formally approve documents coming = out of the WG but rather for them to
be an appeals body. However, the ap= peal grounds should be limited to
process issues, not substantive object= ions. I hear that there are
concerns that the WG won=E2=80=99t listen to= expert advice. In my opinion, the
right balance here is that the expert= gets an opportunity to speak and
the process requires they be heard and= the WG explicitly decide not to
take their opinion, but the WG is the f= inal decision maker. Then =E2=80=9CWG
did not fully consider and decide = on whether to take expert advice=E2=80=9D
can become an appeal ground, b= ut it=E2=80=99s not an opportunity for the IAB
to substitute their own j= udgement for the WG=E2=80=99s.

In short, the WG would be responsible= for the strategic work, but would
be subject to two forms of narrowly s= coped review: the stream
managers for "this will break my stream&qu= ot; and the IAB for "the
process wasn't followed".

-Ekr

--000000000000a887b705b9baf0ab-- From nobody Mon Jan 25 07:32:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D09053A14A1 for ; Mon, 25 Jan 2021 07:32:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.7 X-Spam-Level: X-Spam-Status: No, score=-7.7 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J1v8ISoJ83Nn for ; Mon, 25 Jan 2021 07:32:35 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4397F3A149F for ; Mon, 25 Jan 2021 07:32:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11622; q=dns/txt; s=iport; t=1611588755; x=1612798355; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=r7YiDaVgpqhY0f2QXbKk8/So9aqum3b7OlVbymLfoFY=; b=Mno9BBPa7+iyOR5XRlIq5X7A9FQZ/k6ah/hMx9pDxrypuVgcxtBDJLyb aXDRHqCHB6poYwpgZaRGINWzKJaSPHqi/2xh9HGkHu7idN3NxV5SdDADj PZB6ieRebM9bDA2r+LBHs85IJqNTt1KYrlo/uPJ0DE4rGZHrnvRSuMxO8 M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AZBAAY5A5gjBbLJq1iHgEBCxIMggQLgyFXASASL4RAi?= =?us-ascii?q?QSIVQOBBZMfhiGBfAQHAQEBCgMBARgBDAoEAQGESgKBeSY2Bw4CAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBBQBAQEBhjoMhXMBAQEDAQEBDBVCBgMLBQsLDgoqAgInM?= =?us-ascii?q?AYTH4MHAYJmIA+xUnaBMoVZhHcKBoE4gVOFKIZDQYIAgREnHIIhNT6CXQEBg?= =?us-ascii?q?TaDQjSCLASBSw8LAV4yDCclGRgiLQwqDDoRJQIOYZpZgR6cMoMBgymBN4RQk?= =?us-ascii?q?j8DH4MrijSVGZ89kWleg3ACBAYFAhaBXQ0kgVkzGggbFTsqAYI+PhIZDY4tD?= =?us-ascii?q?gmDToUUhUVAAzA3AgYBCQEBAwmJT4JGAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,373,1602547200"; d="asc'?scan'208,217";a="32927477" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jan 2021 15:32:08 +0000 Received: from dhcp-10-61-106-207.cisco.com (dhcp-10-61-106-207.cisco.com [10.61.106.207]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 10PFW79d006138 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Jan 2021 15:32:08 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AEDC248C-2439-4E9E-9CC4-516C301A24E9"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Mon, 25 Jan 2021 16:32:06 +0100 In-Reply-To: Cc: rfced-future@iab.org To: Eric Rescorla References: X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.106.207, dhcp-10-61-106-207.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Proposed "Oversight Body" structure X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 15:32:38 -0000 --Apple-Mail=_AEDC248C-2439-4E9E-9CC4-516C301A24E9 Content-Type: multipart/alternative; boundary="Apple-Mail=_A11E5413-5526-431D-B8AE-564F9E5C24B6" --Apple-Mail=_A11E5413-5526-431D-B8AE-564F9E5C24B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thank you, Eric. We now have a concrete proposal the supervisory body = and on how appeals are managed. I also know that John is working hard = (perhaps too hard!) on his action item, as we will soon see. May I ask colleagues to please review and comment on the text below? I = have created a copy of the specific text below at = https://github.com/intarchboard/rfced-future/blob/master/wg-approval-body.= txt = . For those people who would like to create PRs, that is fine. = Please keep discussion here, and of course, people should feel free to = propose changes on list. Eliot > On 25 Jan 2021, at 16:10, Eric Rescorla wrote: >=20 > I was asked to come up with a proposal for what to do about a > proposed oversight body. >=20 > The current overall proposals are for a two-level structure, which > has: >=20 > An open WG that is responsible for producing proposed changes to the > RFC series An Approval Body [name TBD] which is responsible for > approving the output of the WG >=20 > At the last interim, it seemed like there were at least three > rationales that people thought that the AB might potentially use to = disapprove a proposed change: >=20 > 1. It didn=E2=80=99t work for one of the Streams > 2. The process wasn=E2=80=99t followed > 3. They didn=E2=80=99t agree with the contents >=20 > I heard a fair amount of agreement on the first two of these, but also > a number of people objecting to (3) on the grounds that the AB > shouldn=E2=80=99t be overriding the judgement of the WG. Conflicts = between the > IESG and WGs on the contents of documents have been a persistent > feature of the current system, leading to, for instance, the DISCUSS > criteria. Given the amount of distrust of leadership making decisions > here, I think we should consider not replicating that structure. >=20 > It also seems to me that the function of determining whether something > works for the individual Streams is a question for the Stream > Managers, but they=E2=80=99re not particularly well positioned to = determine > whether the process has been followed. Given that this WG is likely to > exist under the auspices of the IAB and they are likely to select the > chairs, it seems like they are the natural body to determine whether > the process was followed. >=20 > With that in mind, what I propose is the following: >=20 > An RFC Stream Manager Committee (RSMC) would be formed, consisting > solely of the four Stream Managers. They would need to approve each > process change, but objections need to be limited to the question of > whether a specific change would cause harm to their own Stream. The > specific voting rules are TBD, but the obvious choices are unanimity > or 3/4 supermajority. If we require unanimity, that creates the > concern of allowing one manager to stonewall, which seems suboptimal. >=20 > The IAB would be responsible for ensuring that the process was > followed. I think the easiest way to do this is not for them to > formally approve documents coming out of the WG but rather for them to > be an appeals body. However, the appeal grounds should be limited to > process issues, not substantive objections. I hear that there are > concerns that the WG won=E2=80=99t listen to expert advice. In my = opinion, the > right balance here is that the expert gets an opportunity to speak and > the process requires they be heard and the WG explicitly decide not to > take their opinion, but the WG is the final decision maker. Then =E2=80=9C= WG > did not fully consider and decide on whether to take expert advice=E2=80= =9D > can become an appeal ground, but it=E2=80=99s not an opportunity for = the IAB > to substitute their own judgement for the WG=E2=80=99s. >=20 > In short, the WG would be responsible for the strategic work, but = would > be subject to two forms of narrowly scoped review: the stream > managers for "this will break my stream" and the IAB for "the > process wasn't followed". >=20 > -Ekr >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_A11E5413-5526-431D-B8AE-564F9E5C24B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thank= you, Eric.  We now have a concrete proposal the supervisory body = and on how appeals are managed.  I also know that John is working = hard (perhaps too hard!) on his action item, as we will soon see.

May I = ask colleagues to please review and comment on the text below?  I = have created a copy of the specific text below at https://github.com/intarchboard/rfced-future/blob/master/wg-app= roval-body.txt.  For those people who would like to create PRs, = that is fine.  Please keep discussion here, and of course, people = should feel free to propose changes on list.

Eliot

On 25 = Jan 2021, at 16:10, Eric Rescorla <ekr@rtfm.com> wrote:

I was asked to come up with a = proposal for what to do about a
proposed oversight = body.

The current overall proposals are for = a two-level structure, which
has:

An open WG that is responsible for producing proposed changes = to the
RFC series An Approval Body [name TBD] which is = responsible for
approving the output of the WG

At the last interim, it seemed like there were = at least three
rationales that people thought that the AB = might potentially use to disapprove a proposed change:

1. It didn=E2=80=99t work for one of the Streams
2. The process wasn=E2=80=99t followed
3. They = didn=E2=80=99t agree with the contents

I = heard a fair amount of agreement on the first two of these, but also
a number of people objecting to (3) on the grounds that the = AB
shouldn=E2=80=99t be overriding the judgement of the = WG. Conflicts between the
IESG and WGs on the contents of = documents have been a persistent
feature of the current = system, leading to, for instance, the DISCUSS
criteria. = Given the amount of distrust of leadership making decisions
here, I think we should consider not replicating that = structure.

It also seems to me that the = function of determining whether something
works for the = individual Streams is a question for the Stream
Managers, = but they=E2=80=99re not particularly well positioned to determine
whether the process has been followed. Given that this WG is = likely to
exist under the auspices of the IAB and they are = likely to select the
chairs, it seems like they are the = natural body to determine whether
the process was = followed.

With that in mind, what I propose = is the following:

An RFC Stream Manager = Committee (RSMC) would be formed, consisting
solely of the = four Stream Managers. They would need to approve each
process change, but objections need to be limited to the = question of
whether a specific change would cause harm to = their own Stream.  The
specific voting rules are TBD, = but the obvious choices are unanimity
or 3/4 = supermajority. If we require unanimity, that creates the
concern of allowing one manager to stonewall, which seems = suboptimal.

The IAB would be responsible = for ensuring that the process was
followed. I think the = easiest way to do this is not for them to
formally approve = documents coming out of the WG but rather for them to
be = an appeals body. However, the appeal grounds should be limited to
process issues, not substantive objections. I hear that there = are
concerns that the WG won=E2=80=99t listen to expert = advice. In my opinion, the
right balance here is that the = expert gets an opportunity to speak and
the process = requires they be heard and the WG explicitly decide not to
take their opinion, but the WG is the final decision maker. = Then =E2=80=9CWG
did not fully consider and decide on = whether to take expert advice=E2=80=9D
can become an = appeal ground, but it=E2=80=99s not an opportunity for the IAB
to substitute their own judgement for the WG=E2=80=99s.

In short, the WG would be responsible for the = strategic work, but would
be subject to two forms of = narrowly scoped review: the stream
managers for "this will = break my stream" and the IAB for "the
process wasn't followed".

-Ekr

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

= --Apple-Mail=_A11E5413-5526-431D-B8AE-564F9E5C24B6-- --Apple-Mail=_AEDC248C-2439-4E9E-9CC4-516C301A24E9 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAO5HYACgkQh7ZrRtnS ejN17wgAxrUrfxH7Fh05A69vUBKWwf0B0CEUWudyddaeAbEl/dPT0KvBpw7l7fbd h+I5OI3TYgl04qd8Cth7NAV4pz8Sp5QA7tSVGULEbpwhgePmRyoXYsfDHyEzxvWe ez4VuF5StjPbSGAvG9QfqqEQr0OdVD8HclKbBlixpAu7BO5SEzFhpwvmn1xn/0m/ dmGkAA52lqVWN6mHBJLTOVMglLEAm4GOXvHo/iEr1rve2nhFemPAjayvcg2kUdvX vXLj+GmLn6JsmtYTDrVrkf/urKKqHSnM7hlkP+wf5BKqL3xvRgYJOmzGUHrJ/RTi oZCogBYqKyAR61oulc3EZdQZUskPRw== =Op7C -----END PGP SIGNATURE----- --Apple-Mail=_AEDC248C-2439-4E9E-9CC4-516C301A24E9-- From nobody Mon Jan 25 07:33: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 408053A149F for ; Mon, 25 Jan 2021 07:33:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[DKIMWL_WL_HIGH=-0.25, 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 mhqpgdS7uSkz for ; Mon, 25 Jan 2021 07:33:03 -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 1FAB83A14A1 for ; Mon, 25 Jan 2021 07:33:02 -0800 (PST) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 10PFNWDY026776; Mon, 25 Jan 2021 15:33:02 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=7KqO0rUqsFRXoxX5qBGmTig6sjzGx8nAfbnZRCokB8Y=; b=AaC+oKlD/A1PtZJPCTBtYqGBtZI8TTKJ35l0oC6g9xElld/Relmp1zA6dajbCBLnmZiu GY6psDHXEftYsou+yJPT4hPCwOmy/iGCVGYFJ+hPJPMY24zhzBZiNQQcE7k91WNDOZVU zA7GkWpUb82wAXvM18rEw50DtkCe883GGQCCtx9Jb0+q63XurVIIijC41k1dBNuNo846 WA9uYvcsolgy0MsiVW6Q9oF/E+Cy4Y/HY+xZGeQSjEEzxt7PRvgBMxm4Lfl4j1hbAB5r qcWpg5lbAKsrCNUjfy8klOVUUVvlAuQYP2lKYGrAb3UcdzxMVKGgNPOoEbHZMejlK0Ke Zg== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 368bxhjhca-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 25 Jan 2021 15:33:02 +0000 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 10PFX0pP022585; Mon, 25 Jan 2021 07:33:00 -0800 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint5.akamai.com with ESMTP id 368jnfnhw4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 25 Jan 2021 07:33:00 -0800 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; Mon, 25 Jan 2021 10:32:59 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.010; Mon, 25 Jan 2021 10:32:59 -0500 From: "Salz, Rich" To: Eric Rescorla , "rfced-future@iab.org" Thread-Topic: [Rfced-future] Proposed "Oversight Body" structure Thread-Index: AQHW8yxEwLcxPZNEuESNT7gHNOBY+6o4eF+A Date: Mon, 25 Jan 2021 15:32:58 +0000 Message-ID: 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.45.21011103 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.27.118.139] Content-Type: multipart/alternative; boundary="_000_CE29C62FFDC54EDEA93C2AD13EFCCD71akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-25_06:2021-01-25, 2021-01-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 phishscore=0 malwarescore=0 suspectscore=0 mlxlogscore=999 adultscore=0 spamscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101250090 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-25_06:2021-01-25, 2021-01-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=960 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 phishscore=0 impostorscore=0 bulkscore=0 lowpriorityscore=0 mlxscore=0 clxscore=1015 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101250089 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.60) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint5 Archived-At: Subject: Re: [Rfced-future] Proposed "Oversight Body" structure X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 15:33:04 -0000 --_000_CE29C62FFDC54EDEA93C2AD13EFCCD71akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSByZWFsbHkgbGlrZWQgc2VlaW5nIHRoZSByYXRpb25hbGUgYmVoaW5kIHRoZSBwcm9wb3NhbC4N Cg0KSSBhZ3JlZSB3aXRoIGFsbCBvZiBpdC4NCg0K --_000_CE29C62FFDC54EDEA93C2AD13EFCCD71akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEi IHZsaW5rPSIjOTU0RjcyIiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcmVhbGx5IGxpa2VkIHNl ZWluZyB0aGUgcmF0aW9uYWxlIGJlaGluZCB0aGUgcHJvcG9zYWwuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgYWdyZWUgd2l0aCBhbGwgb2YgaXQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_CE29C62FFDC54EDEA93C2AD13EFCCD71akamaicom_-- From nobody Mon Jan 25 07: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 8DCF33A14AD for ; Mon, 25 Jan 2021 07:48:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zX8DJPEVF5IN for ; Mon, 25 Jan 2021 07:48:42 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E133A14B4 for ; Mon, 25 Jan 2021 07:48:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DPZ623xQsz1p0D9; Mon, 25 Jan 2021 07:48:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1611589722; bh=FpJUqd0dnE9wZqmqwEgSACzi1CaJ2cbonN3tgTINN78=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=TGHRQaN8w2DSTdAj2oRArVeh1zCi7FjHPto5sNdjsvjQQ/U9W49smESKL64ALWz/6 kvxq1r1Fa3w4d0FShZS/i/DFRTUcGSoUhamxZOcH7kQ5TEINgmJ4qX9BaD93MC2TSZ vwRBTG22Tcss7/9j+g1GSeAJGI8FeYeFFUND/JM8= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DPZ620M6rz1ny2c; Mon, 25 Jan 2021 07:48:41 -0800 (PST) To: Eliot Lear Cc: rfced-future@iab.org References: From: "Joel M. Halpern" Message-ID: <57b53ec9-5f4d-a40b-4258-b9816e7b174c@joelhalpern.com> Date: Mon, 25 Jan 2021 10:48:40 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Proposed "Oversight Body" structure X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 15:48:44 -0000 If we take the premise that the quasi-WG is always technically correct, then most of what Eric proposes follows. However, I do not accept that premise. Even in cases where WGs are actually technically expert on their area, I have seen them make significant mistakes that are called by other review. This proposal removes all such external review. Also, this proposal removes all respect for and meaningful inclusion of the hired expert, reducing them to a participant in the WG. While such reduction is appropriate for IETF technical WGs, it does not seem appropriate for this body. Particularly when we are trying to recover from a debacle of insufficient respect for hired experts. Given that the disagreement is about the basic premise, I do not see any point in trying to craft an alternative proposal. Yours, Joel On 1/25/2021 10:32 AM, Eliot Lear wrote: > Thank you, Eric.  We now have a concrete proposal the supervisory body > and on how appeals are managed.  I also know that John is working hard > (perhaps too hard!) on his action item, as we will soon see. > > May I ask colleagues to please review and comment on the text below?  I > have created a copy of the specific text below at > https://github.com/intarchboard/rfced-future/blob/master/wg-approval-body.txt > . >  For those people who would like to create PRs, that is fine.  Please > keep discussion here, and of course, people should feel free to propose > changes on list. > > Eliot > >> On 25 Jan 2021, at 16:10, Eric Rescorla > > wrote: >> >> I was asked to come up with a proposal for what to do about a >> proposed oversight body. >> >> The current overall proposals are for a two-level structure, which >> has: >> >> An open WG that is responsible for producing proposed changes to the >> RFC series An Approval Body [name TBD] which is responsible for >> approving the output of the WG >> >> At the last interim, it seemed like there were at least three >> rationales that people thought that the AB might potentially use to >> disapprove a proposed change: >> >> 1. It didn’t work for one of the Streams >> 2. The process wasn’t followed >> 3. They didn’t agree with the contents >> >> I heard a fair amount of agreement on the first two of these, but also >> a number of people objecting to (3) on the grounds that the AB >> shouldn’t be overriding the judgement of the WG. Conflicts between the >> IESG and WGs on the contents of documents have been a persistent >> feature of the current system, leading to, for instance, the DISCUSS >> criteria. Given the amount of distrust of leadership making decisions >> here, I think we should consider not replicating that structure. >> >> It also seems to me that the function of determining whether something >> works for the individual Streams is a question for the Stream >> Managers, but they’re not particularly well positioned to determine >> whether the process has been followed. Given that this WG is likely to >> exist under the auspices of the IAB and they are likely to select the >> chairs, it seems like they are the natural body to determine whether >> the process was followed. >> >> With that in mind, what I propose is the following: >> >> An RFC Stream Manager Committee (RSMC) would be formed, consisting >> solely of the four Stream Managers. They would need to approve each >> process change, but objections need to be limited to the question of >> whether a specific change would cause harm to their own Stream.  The >> specific voting rules are TBD, but the obvious choices are unanimity >> or 3/4 supermajority. If we require unanimity, that creates the >> concern of allowing one manager to stonewall, which seems suboptimal. >> >> The IAB would be responsible for ensuring that the process was >> followed. I think the easiest way to do this is not for them to >> formally approve documents coming out of the WG but rather for them to >> be an appeals body. However, the appeal grounds should be limited to >> process issues, not substantive objections. I hear that there are >> concerns that the WG won’t listen to expert advice. In my opinion, the >> right balance here is that the expert gets an opportunity to speak and >> the process requires they be heard and the WG explicitly decide not to >> take their opinion, but the WG is the final decision maker. Then “WG >> did not fully consider and decide on whether to take expert advice” >> can become an appeal ground, but it’s not an opportunity for the IAB >> to substitute their own judgement for the WG’s. >> >> In short, the WG would be responsible for the strategic work, but would >> be subject to two forms of narrowly scoped review: the stream >> managers for "this will break my stream" and the IAB for "the >> process wasn't followed". >> >> -Ekr >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > > From nobody Mon Jan 25 08:10: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 919663A14C6 for ; Mon, 25 Jan 2021 08:10:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TedzCXUbTHXA for ; Mon, 25 Jan 2021 08:10:43 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 043A03A14C4 for ; Mon, 25 Jan 2021 08:10:43 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id a12so10421230lfb.1 for ; Mon, 25 Jan 2021 08:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/v72ZAxKRF/fKpKyIVb4DwNtm2+zgZrZrqozmREQI/8=; b=yusOxB2IyQCjI/3kPjdr+xBk7XqhGt/D3ULS1CZwjPSrcGgpLdnnRCyLwgDT/Mi4/E 7keHTwhBR1ZuCV2puBgYO+vRLH2Y0ypc43FQLo0YbqhJtG9kSSurkVvOOaa+zbTLWvQc ekQd5nFgOlBLU9guYUdCOOU3dO1Cyd+SXLjymQYp11wfblSKCE7KiEzNupCoS2rg38sq MdwEFqKCW1GQjdGQP6E8SA2/1hS8jsHL5IrGmW4GrS1XH0iUXGCr2lrqTkoNi+Oc9Xgb JdFAisc88O1vEAN46PlY0qdJossdfSJBm0JRZZfeEEDztKCn2AJDwQ0Ug5uLa9BBpvmD dJSw== 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=/v72ZAxKRF/fKpKyIVb4DwNtm2+zgZrZrqozmREQI/8=; b=IRDavpjR9vXhaelnagH2Zngv383LOtotxGAZu7ZV+qqX+NVlVJCqQP/QKBe4UlvjV8 zkQHihH5neCsRO0lNtJFkfazpzm0GvDcvl8UG+lnZlxT8Xhs8vX+I+vy1So6spXMJzXa 1qcosTPZfrz1fJ0SxdikOhtmsZ2DFecXsrazpSYnApbk4v0zScnYF+EmiZkbXqh8zGq8 2vYd46s+sPuy+rQbp3Pf31JtcBa+BHPoFCELVDInOyFzMwlYjpbGPd65u3UUiTsm2i3D ylRkcJwAhurDk10cxTyGIgaxRlShBRmx1N2dAq2w8QckNK0zC/wwnkWhCw0zN2u+Hkyz 0n7A== X-Gm-Message-State: AOAM533bYJIKQSFc2aePfsX96Q3BLVmDBd14YWUqbDa8CDe/5BY9OFAW 8CFRFvJJMIIIvcIkU6RZqkqGD6Lj0kZPPz6arqwfjg== X-Google-Smtp-Source: ABdhPJxbQafH3BVxhgqYJhNl/U4j1Wi7mQURj15Xmq3LKEPBo9NZLsVhk1Esf8iPe3YE6bYJ/YE3xhT+eBoaTiEUy7U= X-Received: by 2002:a19:c519:: with SMTP id w25mr597343lfe.16.1611591041199; Mon, 25 Jan 2021 08:10:41 -0800 (PST) MIME-Version: 1.0 References: <57b53ec9-5f4d-a40b-4258-b9816e7b174c@joelhalpern.com> In-Reply-To: <57b53ec9-5f4d-a40b-4258-b9816e7b174c@joelhalpern.com> From: Eric Rescorla Date: Mon, 25 Jan 2021 08:10:05 -0800 Message-ID: To: "Joel M. Halpern" Cc: Eliot Lear , rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000088c3e805b9bbc7c8" Archived-At: Subject: Re: [Rfced-future] Proposed "Oversight Body" structure X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 16:10:44 -0000 --00000000000088c3e805b9bbc7c8 Content-Type: text/plain; charset="UTF-8" On Mon, Jan 25, 2021 at 7:48 AM Joel M. Halpern wrote: > If we take the premise that the quasi-WG is always technically correct, > then most of what Eric proposes follows. > However, I do not accept that premise. > FWIW, this is not *precisely* my premise. Rather, my premise is that despite there being differences of opinion about the right thing to do, the way to resolve those differences is through our ordinary mechanisms. Of course, sometimes that procedure will yield decisions which turn out to be bad -- just as our current procedure of WG design followed by IETF LC and IESG review sometimes makes mistakes -- but that's true of any decision procedure. > Also, this proposal removes all respect for and meaningful inclusion of > the hired expert, reducing them to a participant in the WG. Well, that's not my intent. Rather, I think that they should have a clear advisory role and in the case where they disagree with the WG the chairs ensure they are heard, but that the WG should be the ultimate decision maker. Perhaps that's the right place to start: consider the situation where the WG has strong consensus for some course of action and the expert disagrees, and the WG continues to have consensus even after hearing the expert out. What do people believe the right outcome is? -Ekr --00000000000088c3e805b9bbc7c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 25, 2021 at 7:48 AM Joel = M. Halpern <jmh@joelhalpern.com> wrote:
If= we take the premise that the quasi-WG is always technically correct,
then most of what Eric proposes follows.
However, I do not accept that premise.


=C2=A0
Also, this= proposal removes all respect for and meaningful inclusion of
the hired expert, reducing them to a participant in the WG.=C2=A0

Well, that's not my intent. Rather, I think tha= t they should have a clear
advisory role and in the case where th= ey disagree with the WG the chairs ensure
they are heard, but tha= t the WG should be the ultimate decision maker.

Pe= rhaps that's the right place to start: consider the situation where the= WG
has strong consensus for some course of action and the expert= disagrees,
and the WG continues to have consensus even after hea= ring the expert out.
What do people believe the right outcome= is?

-Ekr

--00000000000088c3e805b9bbc7c8-- From nobody Mon Jan 25 08:56:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 095543A1507 for ; Mon, 25 Jan 2021 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIywzTRIksli for ; Mon, 25 Jan 2021 08:56:19 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CDA13A1505 for ; Mon, 25 Jan 2021 08:56:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 7D700300B9E for ; Mon, 25 Jan 2021 11:56:16 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id gfNN3hGJvagI for ; Mon, 25 Jan 2021 11:56:15 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id E3B84300AFC; Mon, 25 Jan 2021 11:56:14 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.17\)) From: Russ Housley In-Reply-To: Date: Mon, 25 Jan 2021 11:56:16 -0500 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <6C588D4E-AF7C-408A-A0A6-A1599ED0D67F@vigilsec.com> References: To: Eric Rescorla X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Proposed "Oversight Body" structure X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 16:56:21 -0000 > On Jan 25, 2021, at 10:10 AM, Eric Rescorla wrote: >=20 > I was asked to come up with a proposal for what to do about a > proposed oversight body. >=20 > The current overall proposals are for a two-level structure, which > has: >=20 > An open WG that is responsible for producing proposed changes to the > RFC series An Approval Body [name TBD] which is responsible for > approving the output of the WG >=20 > At the last interim, it seemed like there were at least three > rationales that people thought that the AB might potentially use to = disapprove a proposed change: >=20 > 1. It didn=E2=80=99t work for one of the Streams > 2. The process wasn=E2=80=99t followed > 3. They didn=E2=80=99t agree with the contents >=20 > I heard a fair amount of agreement on the first two of these, but also > a number of people objecting to (3) on the grounds that the AB > shouldn=E2=80=99t be overriding the judgement of the WG. Conflicts = between the > IESG and WGs on the contents of documents have been a persistent > feature of the current system, leading to, for instance, the DISCUSS > criteria. Given the amount of distrust of leadership making decisions > here, I think we should consider not replicating that structure. >=20 > It also seems to me that the function of determining whether something > works for the individual Streams is a question for the Stream > Managers, but they=E2=80=99re not particularly well positioned to = determine > whether the process has been followed. Given that this WG is likely to > exist under the auspices of the IAB and they are likely to select the > chairs, it seems like they are the natural body to determine whether > the process was followed. >=20 > With that in mind, what I propose is the following: >=20 > An RFC Stream Manager Committee (RSMC) would be formed, consisting > solely of the four Stream Managers. They would need to approve each > process change, but objections need to be limited to the question of > whether a specific change would cause harm to their own Stream. The > specific voting rules are TBD, but the obvious choices are unanimity > or 3/4 supermajority. If we require unanimity, that creates the > concern of allowing one manager to stonewall, which seems suboptimal. >=20 > The IAB would be responsible for ensuring that the process was > followed. I think the easiest way to do this is not for them to > formally approve documents coming out of the WG but rather for them to > be an appeals body. However, the appeal grounds should be limited to > process issues, not substantive objections. I hear that there are > concerns that the WG won=E2=80=99t listen to expert advice. In my = opinion, the > right balance here is that the expert gets an opportunity to speak and > the process requires they be heard and the WG explicitly decide not to > take their opinion, but the WG is the final decision maker. Then =E2=80=9C= WG > did not fully consider and decide on whether to take expert advice=E2=80= =9D > can become an appeal ground, but it=E2=80=99s not an opportunity for = the IAB > to substitute their own judgement for the WG=E2=80=99s. >=20 > In short, the WG would be responsible for the strategic work, but = would > be subject to two forms of narrowly scoped review: the stream > managers for "this will break my stream" and the IAB for "the > process wasn't followed". I was thinking that the ballot process should be similar to the IESG WG = chartering process. You need at least one YES ballot position and no BLOCK ballot positions. = With the assumption that most BLOCK positions will be associated with = detail, not the whole idea, the BLOCK will lead to a problem solving = discussion. After discussion, if the BLOCK is not sorted out, then the a vote is a = reasonable next step. This would be similar to the IESG override = process. I would think that 2/3rds voting YES would be a good approach = to overriding a BLOCK by a stream manager. Russ From nobody Mon Jan 25 10:19: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 556223A170E for ; Mon, 25 Jan 2021 10:19:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.221 X-Spam-Level: X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7bHcCWNRD0h3 for ; Mon, 25 Jan 2021 10:19:36 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BCBA3A170C for ; Mon, 25 Jan 2021 10:19:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DPdS80Rqxz1ny2c; Mon, 25 Jan 2021 10:19:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1611598776; bh=jkDAJy525O6XhAXLignu0xu6Y6OY6dtE56OfYH+oufw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Iu5f5GGj2y46bX4oIa6Tkl59IeMR8qH9TMytOAWSVUVasktog8UvWkXlL9BsR6SBL MknrilIxYxgFU7J7v4kAwccnG1/UEoYvLplDzn1+2e7M5I7odnaKOKGzG4zsN1RTCY S5cQJyRPc4vaaxvvN6S3u5qrQDl2a6g+Lb4f5/QU= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DPdS73g9zz1ntRs; Mon, 25 Jan 2021 10:19:35 -0800 (PST) To: Eric Rescorla Cc: rfced-future@iab.org References: <57b53ec9-5f4d-a40b-4258-b9816e7b174c@joelhalpern.com> From: "Joel M. Halpern" Message-ID: Date: Mon, 25 Jan 2021 13:19:34 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.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] Proposed "Oversight Body" structure X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 18:19:37 -0000 I will try to give my take on the question you asked. To keep it clear what I am answering, that part is below. Thank you, Joel On 1/25/2021 11:10 AM, Eric Rescorla wrote: ... > Perhaps that's the right place to start: consider the situation where the WG > has strong consensus for some course of action and the expert disagrees, > and the WG continues to have consensus even after hearing the expert out. > What do people believe the right outcome is? > > -Ekr I suspect that there is no right answer to this question, since it probably depends upon the myriad details. Having said that, I also recognize that the resolution procedure needs to exist independent of the details. Personally, it seems like having the RSE on the approval body, with an equal vote with the stream heads, and the body allowed to apply technical judgment, seems as reasonable as anything I can think of. I am assuming that it takes a majority of the approval body to approve a document for this discussion. If the RSE can't persuade two of the 4 stream heads that there is a real problem, then the RSE will have to figure out how to work with the result being approved. Yours, Joel From nobody Mon Jan 25 11:47: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 83BC23A1843 for ; Mon, 25 Jan 2021 11:47:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.011 X-Spam-Level: X-Spam-Status: No, score=0.011 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pdLFaBun87M7 for ; Mon, 25 Jan 2021 11:47:30 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19BDB3A1842 for ; Mon, 25 Jan 2021 11:47:29 -0800 (PST) Received: from xse47.mail2web.com ([66.113.196.47] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1l47pf-00199O-E9 for rfced-future@iab.org; Mon, 25 Jan 2021 20:47:28 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4DPgPS5Zs5zPHv for ; Mon, 25 Jan 2021 11:47:24 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1l47pc-0003kc-Ki for rfced-future@iab.org; Mon, 25 Jan 2021 11:47:24 -0800 Received: (qmail 23847 invoked from network); 25 Jan 2021 19:47:23 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.250]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jan 2021 19:47:23 -0000 To: Eric Rescorla , rfced-future@iab.org References: From: Christian Huitema Message-ID: Date: Mon, 25 Jan 2021 11:47:22 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: 66.113.196.47 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.47/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.47/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/Kkxa xbjFtHXwfWAPVzp//E3rtcjzPLB8l26cZcetnKkDSxIRXVMlFuiz/acFNeeXt8QYiTpLCsrpI++d V3X+sU+0Wgdc/GZKNJjKl2gkxoET7eibU04JcTWQKv3WukWvpDD6pXOTxoV/sw4j/mx5W+O88A2w zVszU7vvUXN2fiw/LSf7q7XsQU29jXGtXEc4yN1paiVoQiig279hArmEazQFKXtiuAJ3NtoLAk8I JKi6HHnknBCFB2XCjKE4atFSdBe4BPzpam1U3Cj9xZx6U4O3QM22Wm73+PngL70p9A+WFDVoKv7C h+bugCmBCoi4dPPF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dj1kvSgT4G6Wgcnfwvu7dYr8 02c46XHC2jj2ServnkG9INa9keScZ6Xn0u45yYETx72XL1Ux5dFgcYMIZ7yeG33RtFuayQSHKxuV s+RmqoRq3CRiRJK4GhOXBQPqhauyDwA81q43+Ot7OOfb+EzrJBK3h1ESmlc3/lS5x7qxkdla0H99 gtYBP6FcMZ+DsBDygp+2rPcYELslCDAPu0gomGlRXxKF5tPxTxfD0dMN+t5ZLshnSRaFnCn2F0Qa DrfVVfoPFZIShBSdpVJW5HbjQTCUIzbw71BPKv8cPtVshTSLr6YHJu91A3avrF49rf9JcoEpejCA XczArXyV+OFXiMtbLPp9n350Mbemie5JWWm/MpxAyl4q1x5O0+PBD/gPmWjXVA9S7TnWXDlmMpVd cwCFwrnT0GQK/7labXRdXAB+MS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 19:47:31 -0000 On 1/25/2021 7:10 AM, Eric Rescorla wrote: > I was asked to come up with a proposal for what to do about a > proposed oversight body. > > The current overall proposals are for a two-level structure, which > has: > > An open WG that is responsible for producing proposed changes to the > RFC series An Approval Body [name TBD] which is responsible for > approving the output of the WG > > At the last interim, it seemed like there were at least three > rationales that people thought that the AB might potentially use to > disapprove a proposed change: > > 1. It didn’t work for one of the Streams > 2. The process wasn’t followed > 3. They didn’t agree with the contents > > I heard a fair amount of agreement on the first two of these, but also > a number of people objecting to (3) on the grounds that the AB > shouldn’t be overriding the judgement of the WG. Conflicts between the > IESG and WGs on the contents of documents have been a persistent > feature of the current system, leading to, for instance, the DISCUSS > criteria. Given the amount of distrust of leadership making decisions > here, I think we should consider not replicating that structure. > > It also seems to me that the function of determining whether something > works for the individual Streams is a question for the Stream > Managers, but they’re not particularly well positioned to determine > whether the process has been followed. Given that this WG is likely to > exist under the auspices of the IAB and they are likely to select the > chairs, it seems like they are the natural body to determine whether > the process was followed. > > With that in mind, what I propose is the following: > > An RFC Stream Manager Committee (RSMC) would be formed, consisting > solely of the four Stream Managers. They would need to approve each > process change, but objections need to be limited to the question of > whether a specific change would cause harm to their own Stream. The > specific voting rules are TBD, but the obvious choices are unanimity > or 3/4 supermajority. If we require unanimity, that creates the > concern of allowing one manager to stonewall, which seems suboptimal. > > The IAB would be responsible for ensuring that the process was > followed. I think the easiest way to do this is not for them to > formally approve documents coming out of the WG but rather for them to > be an appeals body. However, the appeal grounds should be limited to > process issues, not substantive objections. I hear that there are > concerns that the WG won’t listen to expert advice. In my opinion, the > right balance here is that the expert gets an opportunity to speak and > the process requires they be heard and the WG explicitly decide not to > take their opinion, but the WG is the final decision maker. Then “WG > did not fully consider and decide on whether to take expert advice” > can become an appeal ground, but it’s not an opportunity for the IAB > to substitute their own judgement for the WG’s. > > In short, the WG would be responsible for the strategic work, but would > be subject to two forms of narrowly scoped review: the stream > managers for "this will break my stream" and the IAB for "the > process wasn't followed". I largely agree with this proposal, except for the lack of some kind of community wide consultation. The proposal addresses two failure modes, hampering the management of streams and not following due process. I understand why we might not want to invest a small body with the power of overriding WG consensus. But I am concerned about a different failure mode, group-think in the WG blindsiding the community at large. This is addressed in the IETF process by the IETF last call. I believe we need something similar here, some kind of "community last call", and that the Approval Body should be entrusted to verify that issues raised during this community last call are properly addressed. -- Christian Huitema From nobody Mon Jan 25 12:31: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 0059D3A1896 for ; Mon, 25 Jan 2021 12:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRxLYS85KlIp for ; Mon, 25 Jan 2021 12:31:37 -0800 (PST) Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83123A189A for ; Mon, 25 Jan 2021 12:31:36 -0800 (PST) Received: by mail-lf1-x12b.google.com with SMTP id q8so19689433lfm.10 for ; Mon, 25 Jan 2021 12:31:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Zcz3oJ+fUnHYvx807xGR+g5GCh9Vw7995If1xKQkjlo=; b=C09haWwBEaOIeeEbHlzAoBzVyvuagsuOO/EKAfb6ZcKpQyOzK59pExFtAoRMcbJPmF S8SgIgLk0MNL6RKny8f4Cjr5kzCuCY0rHvIqj1fYILjHEn7lUaF90DlthF4Oaj2VqQgX FUp43AzY7TBoLnKGC3IhPIsQd2lMDxySBfRo+i5oSk/istHcSFK80QBz0LLx7o1TY6OE e7TQB9jiuJHFthaHr8IYxvL5/O+iiMm/pNtwJEWoh7bSw6fwpTbtCjYlcs/Z6N+pUcck e0gih1LIWrBn7XvQfVsXoTHAdDEAV8ZKWmu12nMFw+iVqNWbJS4H40eQ6v4XiXzuMKQe CpxQ== 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=Zcz3oJ+fUnHYvx807xGR+g5GCh9Vw7995If1xKQkjlo=; b=iVcTi5DAidTaSHS/fhmIP+P5mfDR6cuMUgLImLickFAdcwOxjn02nFSmFVcOJJJ7/9 xBxzgyncQMV/AoBgd6T2315yjCXR0B+ucuX8DQ/dUozYQoYE8fANr37Na3e+lhQh94xs sB+CyZZtw012xGwghZ0vr0BdzVOP4yA3qLhs9st4oa7Vhkd/6OyfLcjX3E5y+5MJsaLt 6ib+xal3OB+akai/S7173xqK/wvwNmoHBKEc+N7NgrqrISVswtThOYaPQOpbhvYuQbfj EW0Db/aaGRX1yAwaCMpe7gekzlDkUQqY4vaakvducSGffHBNoM/W9ShxCpKxais0yxmm gKpw== X-Gm-Message-State: AOAM531CfmTtTNYyeu4T0scuh6MDLD72xW5i/u18Z7X9CoHvmoAQpKmo r7kou8GKgDE3nQ3ufeJaKgL+PalpqfqpXB65AFHMO0OtZPEWGg== X-Google-Smtp-Source: ABdhPJyPCrzPhoh/9KoTYVOMnBl7Gd83O9qWOTS+25LOaX1px94zYVElr1yzWx6tzcyFz0+5JmgyaU6JiQ7cnnMqDwU= X-Received: by 2002:a19:456:: with SMTP id 83mr1046511lfe.113.1611606694522; Mon, 25 Jan 2021 12:31:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Mon, 25 Jan 2021 12:30:58 -0800 Message-ID: To: Christian Huitema Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000008b85ce05b9bf6c68" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 20:31:39 -0000 --0000000000008b85ce05b9bf6c68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jan 25, 2021 at 11:47 AM Christian Huitema wrote: > > On 1/25/2021 7:10 AM, Eric Rescorla wrote: > > I was asked to come up with a proposal for what to do about a > > proposed oversight body. > > > > The current overall proposals are for a two-level structure, which > > has: > > > > An open WG that is responsible for producing proposed changes to the > > RFC series An Approval Body [name TBD] which is responsible for > > approving the output of the WG > > > > At the last interim, it seemed like there were at least three > > rationales that people thought that the AB might potentially use to > > disapprove a proposed change: > > > > 1. It didn=E2=80=99t work for one of the Streams > > 2. The process wasn=E2=80=99t followed > > 3. They didn=E2=80=99t agree with the contents > > > > I heard a fair amount of agreement on the first two of these, but also > > a number of people objecting to (3) on the grounds that the AB > > shouldn=E2=80=99t be overriding the judgement of the WG. Conflicts betw= een the > > IESG and WGs on the contents of documents have been a persistent > > feature of the current system, leading to, for instance, the DISCUSS > > criteria. Given the amount of distrust of leadership making decisions > > here, I think we should consider not replicating that structure. > > > > It also seems to me that the function of determining whether something > > works for the individual Streams is a question for the Stream > > Managers, but they=E2=80=99re not particularly well positioned to deter= mine > > whether the process has been followed. Given that this WG is likely to > > exist under the auspices of the IAB and they are likely to select the > > chairs, it seems like they are the natural body to determine whether > > the process was followed. > > > > With that in mind, what I propose is the following: > > > > An RFC Stream Manager Committee (RSMC) would be formed, consisting > > solely of the four Stream Managers. They would need to approve each > > process change, but objections need to be limited to the question of > > whether a specific change would cause harm to their own Stream. The > > specific voting rules are TBD, but the obvious choices are unanimity > > or 3/4 supermajority. If we require unanimity, that creates the > > concern of allowing one manager to stonewall, which seems suboptimal. > > > > The IAB would be responsible for ensuring that the process was > > followed. I think the easiest way to do this is not for them to > > formally approve documents coming out of the WG but rather for them to > > be an appeals body. However, the appeal grounds should be limited to > > process issues, not substantive objections. I hear that there are > > concerns that the WG won=E2=80=99t listen to expert advice. In my opini= on, the > > right balance here is that the expert gets an opportunity to speak and > > the process requires they be heard and the WG explicitly decide not to > > take their opinion, but the WG is the final decision maker. Then =E2=80= =9CWG > > did not fully consider and decide on whether to take expert advice=E2= =80=9D > > can become an appeal ground, but it=E2=80=99s not an opportunity for th= e IAB > > to substitute their own judgement for the WG=E2=80=99s. > > > > In short, the WG would be responsible for the strategic work, but would > > be subject to two forms of narrowly scoped review: the stream > > managers for "this will break my stream" and the IAB for "the > > process wasn't followed". > > I largely agree with this proposal, except for the lack of some kind of > community wide consultation. The proposal addresses two failure modes, > hampering the management of streams and not following due process. I > understand why we might not want to invest a small body with the power > of overriding WG consensus. But I am concerned about a different failure > mode, group-think in the WG blindsiding the community at large. This is > addressed in the IETF process by the IETF last call. I believe we need > something similar here, some kind of "community last call", and that the > Approval Body should be entrusted to verify that issues raised during > this community last call are properly addressed. > Thanks for making this suggestion. I agree that it would be an improvement. -Ekr --0000000000008b85ce05b9bf6c68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jan 25, 2021 at 11:47 AM Chri= stian Huitema <huitema@huitema.ne= t> wrote:

On 1/25/2021 7:10 AM, Eric Rescorla wrote:
> I was asked to come up with a proposal for what to do about a
> proposed oversight body.
>
> The current overall proposals are for a two-level structure, which
> has:
>
> An open WG that is responsible for producing proposed changes to the > RFC series An Approval Body [name TBD] which is responsible for
> approving the output of the WG
>
> At the last interim, it seemed like there were at least three
> rationales that people thought that the AB might potentially use to > disapprove a proposed change:
>
> 1. It didn=E2=80=99t work for one of the Streams
> 2. The process wasn=E2=80=99t followed
> 3. They didn=E2=80=99t agree with the contents
>
> I heard a fair amount of agreement on the first two of these, but also=
> a number of people objecting to (3) on the grounds that the AB
> shouldn=E2=80=99t be overriding the judgement of the WG. Conflicts bet= ween the
> IESG and WGs on the contents of documents have been a persistent
> feature of the current system, leading to, for instance, the DISCUSS > criteria. Given the amount of distrust of leadership making decisions<= br> > here, I think we should consider not replicating that structure.
>
> It also seems to me that the function of determining whether something=
> works for the individual Streams is a question for the Stream
> Managers, but they=E2=80=99re not particularly well positioned to dete= rmine
> whether the process has been followed. Given that this WG is likely to=
> exist under the auspices of the IAB and they are likely to select the<= br> > chairs, it seems like they are the natural body to determine whether > the process was followed.
>
> With that in mind, what I propose is the following:
>
> An RFC Stream Manager Committee (RSMC) would be formed, consisting
> solely of the four Stream Managers. They would need to approve each > process change, but objections need to be limited to the question of > whether a specific change would cause harm to their own Stream. The > specific voting rules are TBD, but the obvious choices are unanimity > or 3/4 supermajority. If we require unanimity, that creates the
> concern of allowing one manager to stonewall, which seems suboptimal.<= br> >
> The IAB would be responsible for ensuring that the process was
> followed. I think the easiest way to do this is not for them to
> formally approve documents coming out of the WG but rather for them to=
> be an appeals body. However, the appeal grounds should be limited to > process issues, not substantive objections. I hear that there are
> concerns that the WG won=E2=80=99t listen to expert advice. In my opin= ion, the
> right balance here is that the expert gets an opportunity to speak and=
> the process requires they be heard and the WG explicitly decide not to=
> take their opinion, but the WG is the final decision maker. Then =E2= =80=9CWG
> did not fully consider and decide on whether to take expert advice=E2= =80=9D
> can become an appeal ground, but it=E2=80=99s not an opportunity for t= he IAB
> to substitute their own judgement for the WG=E2=80=99s.
>
> In short, the WG would be responsible for the strategic work, but woul= d
> be subject to two forms of narrowly scoped review: the stream
> managers for "this will break my stream" and the IAB for &qu= ot;the
> process wasn't followed".

I largely agree with this proposal, except for the lack of some kind of community wide consultation. The proposal addresses two failure modes,
hampering the management of streams and not following due process. I
understand why we might not want to invest a small body with the power
of overriding WG consensus. But I am concerned about a different failure mode, group-think in the WG blindsiding the community at large. This is addressed in the IETF process by the IETF last call. I believe we need
something similar here, some kind of "community last call", and t= hat the
Approval Body should be entrusted to verify that issues raised during
this community last call are properly addressed.

<= /div>
Thanks for making this suggestion. I agree that it would be an im= provement.

-Ekr
--0000000000008b85ce05b9bf6c68-- From nobody Mon Jan 25 15:00: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 338423A19E4 for ; Mon, 25 Jan 2021 15:00:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sGXMpTx9-PLc for ; Mon, 25 Jan 2021 15:00:40 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400115.outbound.protection.outlook.com [40.107.140.115]) (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 50F563A19E3 for ; Mon, 25 Jan 2021 15:00:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BdLw6vF0WXWlvd4AtSU+FonIGSC4pfElisiwM6+p3AGnNYdhPYA1l/1f20Sw0DJ2Cs+mfDNZLGlX6wRznqXZV7uhOCM+zv94gTfq8OJX5IiGD2PAaoyPAuszNCQXXwNYO9GFRcznNlhqCKBrXcGSqjTfElnBia6J129bBdCR4wp2yLW4tnaoCAaRfL8LbMd/iFdCFzgLpqh+CmmBZ5GCiqPQ+Mo0TfbhgZ5dWwi1Pp+t/t8BUpkaQl2RNnUY0pmvJutG0O2dDiCbnEqXWGsztKXBoU8MQvjs0nCY/AOXhwhl95QTdoxEhW2hbakxANONH+eNiY7RzW6/QJgicG5FtQ== 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=Yh9IUOf/jbG/d9PEpWrdV6Kxg62a+EDknOGhJHrsDDc=; b=lu/G8ozbfjdJ7AxAixt3Cfg6P4TcPRBOkJdP8WilY0Da9s/7HbAfi0KnCO6IfyXV60Nu0NQhDdJpfkNUWP4zIvKTjISpDW0AVJpZxRZycMAgUpcEQLLpRFDrcaDlUYwvPJuycBnCV4n7zLe4YTAIUlIsFrO5y6RFpoPS+PHrDcY9BT8yXy+KehhbgUa7wwLlxyWR7FdF+xBBIl0xnDYE+tPRuygPlg6mengxRTkRYU4bNvEv/ToYi87JDXskRCP9sq80lAK210ChJoLsg2k7SHvLHEsavHLLVGmcC6tLOluiHS35jYkrjbUHfd00ol88RhYSXAmET9A88c5+L1B1LQ== 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=Yh9IUOf/jbG/d9PEpWrdV6Kxg62a+EDknOGhJHrsDDc=; b=Vp68yaPx2jqwBNkSG7GNC1J9rFGlnM4h7XxatomH2DRhk1aq3s/pwIs96QR5xG5PFzsIbOtNulDdYUuj7YjY9GRVkJQSCrOWhb1zTkC3+E7B2Mv413f6tj11zy9oP/W6vjRgFDe2bEaFsOAui3Fi1bekhWiGAIYGGERkkmjxrmA= 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 TYAPR01MB2253.jpnprd01.prod.outlook.com (2603:1096:404:2::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.14; Mon, 25 Jan 2021 23:00:35 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3784.019; Mon, 25 Jan 2021 23:00:35 +0000 To: rfced-future@iab.org References: <57b53ec9-5f4d-a40b-4258-b9816e7b174c@joelhalpern.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <04a57094-b1c8-a993-1a02-dbbc3c4101b2@it.aoyama.ac.jp> Date: Tue, 26 Jan 2021 08:00:33 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [223.217.186.153] X-ClientProxiedBy: TYAP286CA0013.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:8015::18) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.6] (223.217.186.153) by TYAP286CA0013.JPNP286.PROD.OUTLOOK.COM (2603:1096:404:8015::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11 via Frontend Transport; Mon, 25 Jan 2021 23:00:35 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 6c2afabf-c3b7-4c3b-0b11-08d8c1850660 X-MS-TrafficTypeDiagnostic: TYAPR01MB2253: 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: 5FhzZN3cfESeER0r2Y2jY4nfLzrnMHHQW8SlF9iOgYlGdJk0AGamN7423GLPaf8cg3osYw9DsFKZTk/Amq0cQulWxHQqxNn5YnRyu38/p91doyDhOMFicfquRSRbH1+EHwjMnct0Gf8si3FyYQwzUZJMlI0Ya4wmQPuWvhW+Uy63JA5fk6GCJlhWqZGomHiXqGLTfTm186cpL2VH4jv86o+zn50nonfXXEH8zQ7eiT+J/xPT23dRh2pxB97H8U0rm6qbnSCJxydkAgtWyXwsItT+f/81MqfUsD5zLAUVn7VNPDn2hS/VtPeMucshjsj5qlY/VI1+f66JoBK3zsozuupXlWDB2a3XD9CzUefdHUD1HUQ5oMPGrPiBNmqngwmL0odtZEHBz7qC13/g3ZJuvuFt4evqGU9lUH6F2hRpZi3DqEF3UVZJxe2peb1wIrZTzrkgG72cxXDHYAg15yWkdlL+Iurxx79gE4hfMAT6a+0= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(39840400004)(376002)(346002)(366004)(396003)(136003)(66556008)(66946007)(36916002)(186003)(6486002)(478600001)(52116002)(53546011)(956004)(2906002)(2616005)(316002)(5660300002)(31686004)(16576012)(26005)(66476007)(31696002)(8936002)(786003)(8676002)(16526019)(86362001)(6916009)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?WmpsWWxDZTU1NW5qb214bVNoVkVMSlJ3U1pjRjQ2bXpzQXdnZTBpb1FDaHVl?= =?utf-8?B?SmVUWjU5ck1GdDRzdHFOY3BZc2Zzb0NjcTBtOGpIMVI3YzRJVzNWNFRXbnN0?= =?utf-8?B?SjRTYnJaVllTTUtNVGhyT3hhU29hUStTNWNxdGc0NytTVm5lNFhBNjNWV296?= =?utf-8?B?WWFCOEMwT29qQnQvSEhVTXdZZWhTbVdOTjM1QzQxRS9qbTZRWDRGK1I5cW02?= =?utf-8?B?cEtvU3FJWG5TUWpGellwc1hBS3ltWjhrUzdqSXFsaS9OcmlIeGhsR21EOTA2?= =?utf-8?B?M0xiZnZ5L1g1K0Y0Q2tIL3c3ZkM2OVFPeHJQUXVpQTV5ejM5L3J2bU1GaWc5?= =?utf-8?B?bktkeVppTnZOdUFwM01UdVlROW54WVpaQ2NZYXNQU3BJVU5aTlBJZHFFVUp4?= =?utf-8?B?VFRuRDN6MTdMcThydzQwKzUwK3hDZVhwU212UHQ2ZE85N3l6NkswLzFSVnZv?= =?utf-8?B?L2wycy80bzkyYkhlMS81V25GV1lOOEUvQ0JBeHdHa2Urb2FmWHJXY29USlZx?= =?utf-8?B?QXhmMVpGK00xNnNqbjM1WlZhMldHd0VvcUkrVVVmclZBRkxESVpMamJvdEgv?= =?utf-8?B?N09DZ3NTb3RiTC85YmZLSUd3WlZVNHNudWVSME53cUUxUXJjTExHTzBSRmdv?= =?utf-8?B?U3lRTXV1N2UzRWdQNFhXc2RuTjF0UUs0dDVZSitFM0JtMFZsUUtrTGNtZG5S?= =?utf-8?B?Y28xWktCWkhLVlYwY0JqUmY1Uy95c2h1ZGExWmp5bEZaWTVZdS9KRi95dWJw?= =?utf-8?B?SkhOVTJTWGtyQWZpcmE1VTJHOTVaWVZJbWxGQXBrcFJMclBrSU95aEEyRm05?= =?utf-8?B?c2VZZVNMWmZ0SHB0bFRBRmFYQmlUUTR5cUpSWDZYU002eVBvcHo2NmZ0SmNL?= =?utf-8?B?UFEwZ1Q3T3RjY2ViZ3hvSkJiKzNNTGU0RTlpTGh6MXJFUVU1U1dra1BnZVdx?= =?utf-8?B?VFUvWXhqWXRUZ1pVS1R3cVROVlF1RU45a01OZjZ6MXJuenllNUJVKzJ1TWZl?= =?utf-8?B?aFBBUng0ZDhxcXh3azEvOXB5N1ZJQkYwYjA4MWtpV0pwbVZGRlRxMnowdWpl?= =?utf-8?B?aEI5TlJFNmZFcTFLR3R6TEI4aUpMQld1bGtlZFp1dzIwM1NPa0JJWUtMTURy?= =?utf-8?B?TENOcHJjWWVWMFRmWmZ3cUt0REtPNjBybGpsRnF4dGpFbyttWFdrLy8xYklM?= =?utf-8?B?am1Oa3diTW9xOHlzdjdCdUZaZGh0SXNEWldzM3dYVXBGZG5sUXlMNVUwRlln?= =?utf-8?B?a0dlaE5XQzhYVDgybmgzYkI1cDdVenpzUEZhdk0rbHJsV3FndUsvMXdqN2Ex?= =?utf-8?B?Z2k2a3IwQXZISXRweE9ZajIrZnRHTndXWlBsMmpUUXlPaXQ4Mzd5V2dHVkFU?= =?utf-8?B?bWpYQWs5UE1lOWFHbDZjeVVheXpZSk83MUZwWS92aFR6bFdaSGhvQysxUnp1?= =?utf-8?B?djRObnEvVmNuMStsdytVQ3ZKeWJsb2FkTWhCQzl3PT0=?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 6c2afabf-c3b7-4c3b-0b11-08d8c1850660 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Jan 2021 23:00:35.5838 (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: vNl07QaorQB1wkkkveqtKdckz4duzKsYsKUMQ8aZ79mtan6WomhDeOF2mFxKFBujQqtJ9IhE5/3eXkbhV7G+kw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB2253 Archived-At: Subject: Re: [Rfced-future] Proposed "Oversight Body" structure X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jan 2021 23:00:42 -0000 On 26/01/2021 01:10, Eric Rescorla wrote: > On Mon, Jan 25, 2021 at 7:48 AM Joel M. Halpern wrote: > >> If we take the premise that the quasi-WG is always technically correct, >> then most of what Eric proposes follows. >> However, I do not accept that premise. >> > > FWIW, this is not *precisely* my premise. Rather, my premise is that despite > there being differences of opinion about the right thing to do, the way to > resolve > those differences is through our ordinary mechanisms. Of course, sometimes > that procedure will yield decisions which turn out to be bad -- just as our > current > procedure of WG design followed by IETF LC and IESG review sometimes > makes mistakes -- but that's true of any decision procedure. The advantage of having IETF LC and IESG review after WG consensus is that the same stuff is looked at at least three times. This has a higher chance of avoiding group think and finding issues relevant in a wider perspective. As Christian also pointed out, the current proposal is rather under-developed in this respect. Regards, Martin. From nobody Mon Jan 25 16:13: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 33F513A1A25 for ; Mon, 25 Jan 2021 16:13:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.003 X-Spam-Level: X-Spam-Status: No, score=0.003 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKAPstgeQNPQ for ; Mon, 25 Jan 2021 16:13:12 -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 9200B3A1A23 for ; Mon, 25 Jan 2021 16:13:12 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1l4Byp-000Flg-7W for rfced-future@iab.org; Mon, 25 Jan 2021 19:13:11 -0500 Date: Mon, 25 Jan 2021 19:13:05 -0500 From: John C Klensin To: rfced-future@iab.org Message-ID: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: [Rfced-future] Notes on documents affected by the changes we are discussing... (long, with exec summary) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 00:13:15 -0000 Hi. When I volunteered to do this, I had a different, and far smaller, task in mind. While it did not slow down the schedule because I just went ahead (I apologize for that -- delays due to non-IETF reasons), I also note that the 13 January Action Item (AI) list indicated there would be further clarification in the minutes which, AFAICT, have still not appeared. Executive Summary: Trying to trace through the IPR and behavior (anti-harrassment, etc.) implications of our work and any potential new entity we might create leads, not only from one document to the others, but uncovers references to documents that are not obviously related, with references to other documents, some of which have not been updated to reflect changes in the RFC Editor function since the mid-1990s or earlier and some of which do not exist at all. It is not clear to me that we need to pump out and drain that cesspool (and there is one particular recommendation below about a better way to handle the problem) but we will not have a firm foundation for a new setup until the issues are further identified and at least a plan is in place for remedying them. Some of the comments and suggestions below overlap with existing Issues in the Program/WG. After getting thoroughly bogged down, I decided to view this exercise as a separate activity and cross-check rather than going carefully through the Issues list and trying to reconcile the two. Documents and comments: Documents are in no particular order. If this and the inter-document relationships were part of a program, some of us would be making nasty comments about spaghetti. Also forgive small differences in formatting and style -- this was developed over multiple days and I concluded it was better to send it than to spend more time sorting those things out. BCP 11/ RFC 2028 thread (RFCs 2028, 3668, 3979, 8717) Summary: RFC 2028, "The Organizations Involved in the IETF Standards Process" actually describes organizations. The three updates are about IPR issues, not organizations or structures (see below). The RFC Editor is discussed in Section 2.1 but all that section really does is to point to the definition of the Series in RFC 2026 (see below) and to a definition of functions and selection procedures in a document cited as "The RFC Editor Charter [G]". Reference [G] reads "Work in Progress". Action required: A review of 2028 indicates that it is badly outdated and in need of work. It cites documents as "in progress" for which no progress has been made in close to a quarter-century. In some cases, documents that change its contents have been published but without any identification of their updating 2028. For example, RFC 4844 (and hence the later 8729) rather clearly updated the substance of 2028 even though they are not the "RFC Editor Charter" to which 2028 refers. A quick scan of the IPR documents as specifically related to 2028 does not seem to indicate anything this group would need to adjust or change but see the separate discussion of RFC 8717 (BCP 101) below. Another example, while not our problem, is that 2028 still claims that the IAB appoints the IETF Chair, text that has never been updated. At minimum for us, RFC 2028 should be updated by pointing to new structure or charter documents or by pointing to a successor for RFC 8729. Preferably, we should convince the IESG that an overhaul of 2028 is needed and then just incorporate new/ better RFC Editor function references into it. For that "overhaul the whole thing" option, I sent a summary to the gendispatch mailing list over the weekend, https://mailarchive.ietf.org/arch/msg/gendispatch/NZ6QfxWlFvkh7jkHvBwNxKd7TR8/ BCP 9/ RFC 2026 Summary: RFC 2026 Section 2.1 describes the RFC Series. It is one of the places were "archival" appears (i.e., if we intend to change that, further work will be required). If we are doing a cleanup, the sentence explaining how to obtain RFCs is probably in need of updating, probably to point to an RFC Editor-maintained document. The sentence "RFC publication is the direct responsibility of the RFC Editor, under the general direction of the IAB." will almost certainly require modification depending on what we decide to do. A number of references, including those to what is now the style guide, the assertion that the ASCII form is definitive for standards-track documents, and the pointers to documents we are no longer maintaining ("Internet Official Protocol Standards" was dealt with in RFC 7100), are probably in need of explicit updating. Action required: If things continue on their current path, remove or update the comment about general direction by the IAB. As with 2028 above and several other documents described below, some general cleaning-up should be performed by someone. See the "Job Description" comments at the end. Intellectual Property Rights in IETF Technology (RFC8179/BCP79) (while IETF-specific, also adopted by the IRTF (https://irtf.org/policies/ipr) Summary: This document/BCP is essentially about patents which, as far as I can tell, have not in the past and should not in the future impact the RFC Editor. Action required: Probably not, but requiring conformance along the lines of the IRTF policy would not be harmful. Rights Contributors Provide to the IETF Trust (RFC5378/BCP78) And Rights in documentation more generally (RFC 5744 - Independent Stream; RFC 5745 - IAB Stream; RFC 8721 (and predecessor 5377)- Advice to Trustees) Summary: RFC 5738, Section 1, points to RFC 2028 for a definition of "RFC Editor". See rant above. Section 3.6 (and the somewhat redundant Section 5.9) implies that the IETF Trust need not (and perhaps does not or should not) own the copyrights to Informational RFCs and "RFCs submitted as RFC Editor Contributions" (not our problem, but, I believe, inconsistent with contemporary practice) and suggests (in terminology of today's structure) that the authority of the Trust is limited to documents "in the RFC format used by the IETF". Probably not our problem either, but, in the current "only the XML is the canonical/ archival form" model, it is not clear what "the format used by the IETF" means. RFC 8721 sheds no light on this other than noting the long-standing tradition of allowing translations and suggesting it continue. Terms such as "published by the RFC Editor" appear in other places, such as Section 4 of RFC 5378, and points to the "RFC Editor web page" for more information, where there is no sign of any such information (see "Job Description" below). Action required: Probably none unless we need the new entity to endorse the BCP 78 policies either as an entity independent of other IETF-related bodies or as part of an RFC Editor Stream should we decide to create one, probably following the IAB model outlined in Section 11. Note, however, that the other streams have been much more careful to apply BCP 79 than they have been about BCP 78 (e.g., as I read the IRTF summary cited above, it is entirely about BCP 79 and disclosures -- BCP 78 is not cited or mentioned), a problem that is further complicated by the slightly convoluted language in RFC 5378 about non-IETF documents. In addition, if one were to endorse/ require conformance along the lines of BCP 78, it is not clear that its definition of "Contribution" would work for the sort of discussions I think we are assuming would occur in the working group or oversight body. Charter of the Internet Architecture Board (IAB) (RFC 2850/BCP0039) Summary: Mentions responsibility for the RFC Editor. It also specifies that the RFC Editor is an liaison member of the IAB. Depending on what other decisions we make, that may no longer be appropriate and we may need to sort out whether the RSE/A, RPC, or both, should have liaisons to the IESG. It also occurs to me that having the RSE/A be an ex-officio member of the LLC Board might improve communications, facilitate discussion of tradeoffs about possibly courses of action that would require money or other resources, and provide a barrier against treating the RSE/A and/or the entire RFC Editor Function as "just contractors". Action required: If we continue on what I think is our current path, the IAB responsibility for the RFC Editor will need to come out. And we need to sort the liaison issues out. RFC Editor Model (Version 2) (RFC 8728 and the earlier 6635) We know this is going to need to be reworked; no summary here. The RFC Series and RFC Editor (RFC 8729 and the earlier 4844) Summary: Like RFC 2850, mentions a liaison from the RFC Editor to the IAB, which we might want to review in the context of whatever we figure out (see above). Section 2.d discusses the RFC Editor function but in general enough terms to probably be ok. Action required: Probably none unless we conclude that the new structure eliminates the need or desire for a liaison from the RFC Editor to the IAB or that we need to move new liaison or ex-officio member role into this (see above). RFC Streams, Headers, and Boilerplates (RFC 7841 and the earlier 5741) Summary: The document does not appear to need modification as a side-effect of our work. Of course the question of who would have the authority to modify it is key to many of our conversations. Action required: Probably none. Independent Submission Editor Model (RFC 8730 and the earlier RFC 5620 and 6548) Summary: Mentions interactions with the RSE and appointment by the IAB. If we create a new oversight mechanism, decouple the RSE/A function, and/or RSE/A appointment from the IAB, we may want to review whether having the IAB appoint the ISE is still appropriate. The text does mention the RSOC in section 2, so, if we are eliminating that body (and possibly replacing it with something else), that sentence would need adjustment. Action: Probably remove comment about the RSE in Section 2. Depending on what else we decide, possibly adjust text about appointment by the IAB and/or being responsible to the IAB. IETF Anti-Harassment Procedures (RFC 7776/RFC 8716) Summary: this document is veryfocused on the IETF. If the strategic and policy activities of the RFC Editor Function are going to be treated as a new and separate body, similar rules, ideally tracking the IETF ones as they evolve, are probably in order. It would seem sensible to piggyback on the IETF process, including using the IETF Ombudsteam structure, advisors, and membership if the IETF is willing, but there could be bad optics if someone associated with a non-IETF interest in the series got into a harrassment dispute with people active in the IETF and apparently trying to advocate its interests against those of other groups. Action required: Decide whether we are concerned about the risks of using an IETF process and team. If we decide we are nor (or that the risks are acceptable), work out details with the IESG and create documentation incorporating their rule and system. If not, we would need to figure out whether the RFC Editor Function or its strategic and policy components need their own policy and build and document that. IESG Procedures for Handling of Independent and IRTF Stream Submissions (RFC 5742) Summary: This document discusses the relationship between the IESG and documents from the Independent and IRTF Streams. If we are going to create a separate "RFC Editor" Stream (under some name), we need to address whether the IESG and/or the IAB should be requested to perform reviews similar to these, a question that is probably independent of ones about representation from the Streams in any oversight body or process. Action required: Once we determine whether there will be a separate stream and how it is managed, come back to the question of whether there should be formal documents reviews by the IESG, IAB, and/or some other body or bodies. Finally... Job Description: If we had discovered the connections (or disconnections) and inconsistencies among these various documents a couple of years ago, it would have been entirely reasonable to go to the RSE and say "go sort that out, recommend fixes, draw others in as needed, and make recommendations to the IESG, IAB, and/or IAOC as needed. How we would get that done under the new system? Indeed, trying to figure out how we would expect many of the problems identified above --ones that we should be able to dodge as too low-level to be addressed by the Program/WG-- may raise another interesting challenge for the "who is responsible for what" discussions. And, before someone suggests it, several of the issues involved are sufficiently intimately entangled with the standards process to put them into the area where the LLC is forbidden to go. best, john From nobody Mon Jan 25 17:21:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F113A1A96 for ; Mon, 25 Jan 2021 17:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwJnEUIg9EIa for ; Mon, 25 Jan 2021 17:21:48 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF5C03A1A92 for ; Mon, 25 Jan 2021 17:21:47 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id a20so712509pjs.1 for ; Mon, 25 Jan 2021 17:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=wIpVrigM2m5mumzZi4/b4kbweSfbkm3CyfQ4GgfPNCM=; b=tadhAx5UWUv6jaUcCJdC8a8lGHnBbSlH///KedgnTHv/TnNX5uVAHUy7vOAiKiCWCG 5ypJQSspvyBufcpUeCwjBiSBI6HLudfjlywggSQv0Wik8LLDBIjgUYouDGeWR97DboAx z6w0Tl4gZdQ9nYjKa93CwjbnfVODlR9LbtcrGwrSUtbeQyxnvaifX7LKxU7bSBNZn6Pp 5wu13jj5mMxBTcj27/MiIiVeJShiBWueUieS2Ze3tdjaUljKQbTwm1ic0vACsrzdjyFD zfmjQDJnZzU5TbvIQ2bOHAUWZ5gApcTheKBh4b1WCxyvLEo4JX76O9CAEXwPLH3aHWaR nO0A== 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=wIpVrigM2m5mumzZi4/b4kbweSfbkm3CyfQ4GgfPNCM=; b=Ubnkam+w3OdK0bJR/kzdF6tQt+QdyAAemPNqZGICBmkzoLm8z2yi5k3yTgDYb14GKW Gxy8oCUeOQDsGs6zaCNqZ+yBgLapomnOaXmt6KOVAq1AVCreHtrGg8z+6vUVG3rsJqzb +dt1HJxv26tRMYZzVg5Sp+mpCgWBeeKhSmwWlqIm6ovVrjIvFCBsw+uRfUaUkx2Wws0w Xw5KWE8CNR/ldbcgYzvJhcbDviEQuam0Qy+9PrSPRFbfaMUKslXZosKvAmfvD4CJMi6f n5FzVYBIB4ddfCTRCbMhBOAhiSAWFMlsDFZezGcCPgpse9ovF3ZG+DHOUDVEyEcO0j14 5q3A== X-Gm-Message-State: AOAM530LtE6HU2bV2LrJG4h8nKP13U0245d3vHjuLyqoC4Y+nUTAqwjp CbzG0cKK6ewnsggjA4z7LRjaSqIVoibffQ== X-Google-Smtp-Source: ABdhPJxFiO/e0u8Du/OYoryPM62Omc5nOr30/cCYM05F4iS8W7CCQb9zbiSDlAP1X8nW7Byxv6mYlA== X-Received: by 2002:a17:903:248e:b029:df:e75a:68f7 with SMTP id p14-20020a170903248eb02900dfe75a68f7mr3480861plw.9.1611624106761; Mon, 25 Jan 2021 17:21:46 -0800 (PST) Received: from [192.168.1.117] (125-236-230-222.adsl.xtra.co.nz. [125.236.230.222]) by smtp.gmail.com with ESMTPSA id a5sm17165128pgl.41.2021.01.25.17.21.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jan 2021 17:21:45 -0800 (PST) To: Christian Huitema , Eric Rescorla , rfced-future@iab.org References: From: Brian E Carpenter Message-ID: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> Date: Tue, 26 Jan 2021 14:21:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 01:21:50 -0000 Several comments in line: On 26-Jan-21 08:47, Christian Huitema wrote: >=20 > On 1/25/2021 7:10 AM, Eric Rescorla wrote: >> I was asked to come up with a proposal for what to do about a >> proposed oversight body. >> >> The current overall proposals are for a two-level structure, which >> has: >> >> An open WG that is responsible for producing proposed changes to the >> RFC series An Approval Body [name TBD] which is responsible for >> approving the output of the WG >> >> At the last interim, it seemed like there were at least three >> rationales that people thought that the AB might potentially use to=20 >> disapprove a proposed change: >> >> 1. It didn=E2=80=99t work for one of the Streams >> 2. The process wasn=E2=80=99t followed >> 3. They didn=E2=80=99t agree with the contents >> >> I heard a fair amount of agreement on the first two of these, but also= >> a number of people objecting to (3) on the grounds that the AB >> shouldn=E2=80=99t be overriding the judgement of the WG. Conflicts bet= ween the >> IESG and WGs on the contents of documents have been a persistent >> feature of the current system, leading to, for instance, the DISCUSS >> criteria. Given the amount of distrust of leadership making decisions >> here, I think we should consider not replicating that structure. >> >> It also seems to me that the function of determining whether something= >> works for the individual Streams is a question for the Stream >> Managers, but they=E2=80=99re not particularly well positioned to dete= rmine >> whether the process has been followed. Given that this WG is likely to= >> exist under the auspices of the IAB and they are likely to select the >> chairs, it seems like they are the natural body to determine whether >> the process was followed. >> >> With that in mind, what I propose is the following: >> >> An RFC Stream Manager Committee (RSMC) would be formed, consisting >> solely of the four Stream Managers. They would need to approve each >> process change, but objections need to be limited to the question of >> whether a specific change would cause harm to their own Stream. The >> specific voting rules are TBD, but the obvious choices are unanimity >> or 3/4 supermajority. If we require unanimity, that creates the >> concern of allowing one manager to stonewall, which seems suboptimal. This is not sufficient. There needs to be somebody there who can speak for the RFC Editor function and say, if necessary, "This will break the RFC editing service itself." In the emerging proposal, that person can really only be the RSA/E themself, assuming we don't want to put a representative of the RFC Editor contractor in the process. Also, I think we'd need a rep from the contracting agency (i.e. the LLC) who can say, if necessary, "This will break the contract or budget". >> >> The IAB would be responsible for ensuring that the process was >> followed. I think the easiest way to do this is not for them to >> formally approve documents coming out of the WG but rather for them to= >> be an appeals body. However, the appeal grounds should be limited to >> process issues, not substantive objections. I hear that there are >> concerns that the WG won=E2=80=99t listen to expert advice. In my opin= ion, the >> right balance here is that the expert gets an opportunity to speak and= >> the process requires they be heard and the WG explicitly decide not to= >> take their opinion, but the WG is the final decision maker. Then =E2=80= =9CWG >> did not fully consider and decide on whether to take expert advice=E2=80= =9D >> can become an appeal ground, but it=E2=80=99s not an opportunity for t= he IAB >> to substitute their own judgement for the WG=E2=80=99s. >> >> In short, the WG would be responsible for the strategic work, but woul= d >> be subject to two forms of narrowly scoped review: the stream >> managers for "this will break my stream"=20 As noted, there are other things that might break. >> and the IAB for "the >> process wasn't followed". I am far from convinced that the IAB is a valid representative of the community served by RFCs. (It *is* a valid representative of the community creating RFCs, but that's different.) Unfortunately I don't have a better suggestion at the moment. =20 > I largely agree with this proposal, except for the lack of some kind of= =20 > community wide consultation. The proposal addresses two failure modes, = > hampering the management of streams and not following due process. I=20 > understand why we might not want to invest a small body with the power = > of overriding WG consensus. But I am concerned about a different failur= e=20 > mode, group-think in the WG blindsiding the community at large. This is= =20 > addressed in the IETF process by the IETF last call. I believe we need = > something similar here, some kind of "community last call", and that th= e=20 > Approval Body should be entrusted to verify that issues raised during=20 > this community last call are properly addressed. Agreed, but there is another aspect of the same problem, as we have often= discussed: how to send a Last Call to the RFC user community, not just to= the RFC writing community? As noted some time ago, the rfc-interest list doesn't even scratch the surface. Regards Brian From nobody Mon Jan 25 17:30: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 972D13A1AA2 for ; Mon, 25 Jan 2021 17:30:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0OUnJzxsSaKg for ; Mon, 25 Jan 2021 17:30:35 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92A1D3A1A8D for ; Mon, 25 Jan 2021 17:30:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7A9BBBE4C; Tue, 26 Jan 2021 01:30:33 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ConsdEg1-0Sf; Tue, 26 Jan 2021 01:30:32 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D337FBE2C; Tue, 26 Jan 2021 01:30:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1611624631; bh=MPYJluCSoiSaKkzhwjVh4WET43kmgKGV6bdx5cLF1/A=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FanHpqTbb1odK6qdsbqgPx0hni9Y9U9kQ0yAjSO/+h8V727mbgkqLxUCMxJD6Lxsr y6pNPaM9hu9TyAoBWCm3eq/8ig8HlswmdhuXfIBYRVcOxmIjW7q1Q86EPYFWKvumqx XplQriqeF13ss9zjGmLwS6YRlrzqj51dMK8386d4= To: Brian E Carpenter , Christian Huitema , Eric Rescorla , rfced-future@iab.org References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> From: Stephen Farrell Message-ID: <97069df1-fb55-589a-06da-b316f17e2254@cs.tcd.ie> Date: Tue, 26 Jan 2021 01:30:31 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 In-Reply-To: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="tR0CZMZWwPCnNgPrO2u5A1T6kKudlyob0" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 01:30:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tR0CZMZWwPCnNgPrO2u5A1T6kKudlyob0 Content-Type: multipart/mixed; boundary="6nr6TZwY8t5yQKD7oEvvU557Uis9rq1wc"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , Christian Huitema , Eric Rescorla , rfced-future@iab.org Message-ID: <97069df1-fb55-589a-06da-b316f17e2254@cs.tcd.ie> Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> In-Reply-To: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> --6nr6TZwY8t5yQKD7oEvvU557Uis9rq1wc Content-Type: multipart/mixed; boundary="------------35EC56C2541A47BABC2C6379" Content-Language: en-US This is a multi-part message in MIME format. --------------35EC56C2541A47BABC2C6379 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, I keep saying it but I must be wrong as nobody ever seems to notice:-) On 26/01/2021 01:21, Brian E Carpenter wrote: > Agreed, but there is another aspect of the same problem, as we have > often discussed: how to send a Last Call to the RFC user community, > not just to the RFC writing community? For such arcane topics, which these are bound to be - to make a genuine effort to reach the biggest subset of the people who read RFCs: we should write an RFC. (Hey, that'd also match the expansion of the acronym too:-) While the above is not perfect, ISTM any other option has to be less good, when the target is the set of people who read RFCs. Someone could send mail and tweet about it too of course but the text in an RFC is what'd be best, almost by definition. Cheers, S. --------------35EC56C2541A47BABC2C6379 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------35EC56C2541A47BABC2C6379-- --6nr6TZwY8t5yQKD7oEvvU557Uis9rq1wc-- --tR0CZMZWwPCnNgPrO2u5A1T6kKudlyob0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAPcLcFAwAAAAAACgkQWrL68XsXK+oS BQ//TRpuTpJg+4wWhhPdrzGpiCl3iDVhsMpwScT3UZ+XOmVvvq4bqTxplDuUL+gmcjmgWlnY2EHO GoTbfnfZzpL7Yjk9BwZrN7XlYT2aqLVIeorDzTGwLabiRNdiYqB4DobnmesSIabD9BhPARsmkCIp XlnaZIUiZxNlEJVhwzQzTYATGvC7uXSQlZ2kGBwAMyQ6bM/4LhhdEfkITU+Z3g2r2ad7fBIOJ1Ne +sg6HWLRJ59lPYJFrYz8a0tfBgUePHhlxo+dCpkRWTf+NZndVmRrvXp/LYHMSyAy7DK2uZwE16d5 WdjJqygRZV7RndtX9ZnAq7b1tAA3dQB0I1qtxp8kiQYHP41UIsCFA9qGJshIpKf9UmtR02F3lL/0 D/oQdFMTfmVPF2yfHKk40ihqjAMZk4Nz+GFvOdQdWMaF+gDe3EbxotJ6W6S5dCh6/2bXj5oXRrB7 ivp1EXnAYF+jr/BKu+GQBAR584TZhhW739Znr/yzCeEdDyXSoKMGkd/YI2rjH94UGBRzuQ1UpjcU FyDAxBR/EusVZ0fDVI3wAA+rNIJP/SF/vkRrMWnfbeBTwOavD5mDz/uZMWymDEgJyquSJtu4E6kx mmIv7KdjSEIOtQ8XkS6tOmWGsOLZE7xt305IziSE4qb57sZVW6XUsWQPMLlhPhZAKMkDzT/BWjCB FNo= =9xEs -----END PGP SIGNATURE----- --tR0CZMZWwPCnNgPrO2u5A1T6kKudlyob0-- From nobody Mon Jan 25 23:15:14 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECF93A1CB9 for ; Mon, 25 Jan 2021 23:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id boxFoOP5KZk1 for ; Mon, 25 Jan 2021 23:15:11 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D215E3A1CB8 for ; Mon, 25 Jan 2021 23:15:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2166; q=dns/txt; s=iport; t=1611645311; x=1612854911; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=crMmZWPwH9FSbjWNodRLdMC/dca7r265chDVDxsnDtw=; b=kRKS18c2H6lkTexCGRfIcIvUTDWn8tUnGF77L1+vEXcYTINNiEbsy5rL Geu+JaNBsTnM2uPth79j2owYUaz9nx19bwwIj2nY0UMvrZIKyPvsAGi6x c9+gHGiIwHWJN0Mi2lrL2AZBQ9l4GvLw6tOX53Llp4oncAm2DJNw72r3H Y=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AGAQAdwA9gjBbLJq1iHQEBAQEJARIBBQUBgX4FAQsBg?= =?us-ascii?q?3cBIBIvhECJBIgwJQOcQQQHAQEBCgMBAS8EAQGESgKBeSY3Bg4CAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBBQBAQEBhkaFcwEBAQMBI1YFCwkCGCoCAlcGExSDEgGCZ?= =?us-ascii?q?iCWYpo8Gjx2gTKFWYR5EIE4AYFSi2tBggCBOAwQglY+h1c0giwEgVWCGoFTb?= =?us-ascii?q?RMxkjeJPpwygwGDKYE3kHqGFQMfgys6j2CPM7E0UINwAgQGBQIWgWwigVkzG?= =?us-ascii?q?ggbFWUBgj4+EhkNjjsdjhNAAzA3AgYBCQEBAwmMFQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,375,1602547200"; d="asc'?scan'208";a="32946674" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jan 2021 07:15:06 +0000 Received: from dhcp-10-61-106-5.cisco.com (dhcp-10-61-106-5.cisco.com [10.61.106.5]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 10Q7F56T002060 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jan 2021 07:15:06 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_BD2B20FF-B942-43CE-AF0D-5EC595968B33"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 26 Jan 2021 08:15:05 +0100 In-Reply-To: <97069df1-fb55-589a-06da-b316f17e2254@cs.tcd.ie> Cc: Brian E Carpenter , Christian Huitema , Eric Rescorla , rfced-future@iab.org To: Stephen Farrell References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <97069df1-fb55-589a-06da-b316f17e2254@cs.tcd.ie> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.106.5, dhcp-10-61-106-5.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 07:15:13 -0000 --Apple-Mail=_BD2B20FF-B942-43CE-AF0D-5EC595968B33 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Stephen > On 26 Jan 2021, at 02:30, Stephen Farrell = wrote: >=20 > On 26/01/2021 01:21, Brian E Carpenter wrote: >> Agreed, but there is another aspect of the same problem, as we have >> often discussed: how to send a Last Call to the RFC user community, >> not just to the RFC writing community? >=20 > For such arcane topics, which these are bound to be - to make > a genuine effort to reach the biggest subset of the people > who read RFCs: we should write an RFC. (Hey, that'd also > match the expansion of the acronym too:-) With the caveat that I am extrapolating from a sample size of 1, what = Brian pointed out was that specific requirements get written into = various other standards, and those standards get clicked through to get = to specific RFCs. If one really wanted to play with fire to address = this, one could intercept the URL for those specific RFCs and throw up = an informational notice, like =E2=80=9Cbefore you download, we are = looking for your feedback=E2=80=A6=E2=80=9D. That in itself would = probably produce some script breakage, but the topic might be a good one = for the new working group to tackle. Eliot --Apple-Mail=_BD2B20FF-B942-43CE-AF0D-5EC595968B33 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAPwXkACgkQh7ZrRtnS ejPYQwgAziqPdyi6wekjZ2CvcKPyRTF/dAAxJT5YuDX5J0vBIZvx2Fi04dg6qEyP TdUyPXdczezxFUVPerJZ0R9naKCxnsUTBOs5/vLn9GzXjjPAZ36eCmYsBo1t8Pak R0g2OBh6ragZoK50fEendjZ77UL9i/5veZUgVbdh/cS2tNHkl+6Y9DH9nJAfda5B +oT2vm6oG1e3Sq5g04z1azaIh175YcclENMIxTmG9dekAmGdSI4OyyUosgxVMIib Rgos3QSDePjuQa22K/KgN00trN4nlYY3VdtNQr6c9oL75q2A5BwKbclj63rk2Gi+ sCu+lf55CCCSl0SarjdCsD/t2cOLQA== =nPPO -----END PGP SIGNATURE----- --Apple-Mail=_BD2B20FF-B942-43CE-AF0D-5EC595968B33-- From nobody Mon Jan 25 23:19: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 438EB3A1CC2 for ; Mon, 25 Jan 2021 23:19:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdz0o7nlemvB for ; Mon, 25 Jan 2021 23:19:43 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE8D03A1CC3 for ; Mon, 25 Jan 2021 23:19:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1208; q=dns/txt; s=iport; t=1611645582; x=1612855182; h=from:mime-version:subject:message-id:date:cc:to; bh=al1YUR38loylpWn1F98RsaOLPI/JNxgZI7h+yrhyvU4=; b=Vw4Nb4OciquLaqgUJPLVNkHWLBNy6+iig6XWROtuItoKw8ZxRQc+5P0Z v1ecSPXs/wN3H3ypTY+3l892/iCqpLkD8FFQJs928jSl1Zf6fV4x9EKRT m38JowB1vHpALTgojx4Gyh+G6qmz+/4beoU2y+2ysAa2GPfx54kL972ZY 4=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CwAQA+wQ9gjBbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?T4EAQELAQGDH1cBIBIvjUSIMJB6i28EBwEBAQoDAQEnCAQBAYRKgXsmNwYOA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgQUAQEBAYY6DEMBAQQLAYYehHcBgwYPsVd0g?= =?us-ascii?q?TSERAIBhgsKBoE4AYFSjCyCAIE4DBCCKIFwgVkCAQKCKYMAgiwEgyxRAmYLn?= =?us-ascii?q?XicMoMBBIMlgTeEUJI/Ax+DGQERijSVGZ89kkeDcAIEBgUCFoFsIoFZMxoIG?= =?us-ascii?q?xVlAYI+EysSGQ2OOQKIa4VFQAMwAjUCBgoBAQMJhTuBE4VHAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,375,1602547200"; d="asc'?scan'208";a="32946742" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jan 2021 07:19:38 +0000 Received: from dhcp-10-61-106-5.cisco.com (dhcp-10-61-106-5.cisco.com [10.61.106.5]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 10Q7JbfR015167 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jan 2021 07:19:38 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_8A5F6563-7F3D-4D42-9D59-3F4714AA1723"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Message-Id: <49944C8E-1089-4CE0-B215-4AB6403C1359@cisco.com> Date: Tue, 26 Jan 2021 08:19:37 +0100 Cc: Brian Rosen To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.106.5, dhcp-10-61-106-5.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Draft minutes for 12 jan meeting 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: Tue, 26 Jan 2021 07:19:44 -0000 --Apple-Mail=_8A5F6563-7F3D-4D42-9D59-3F4714AA1723 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please note, these are likely to be updated once more as they do not yet = incorporate the jabber discussion. = https://datatracker.ietf.org/meeting/interim-2021-rfcefdp-01/materials/min= utes-interim-2021-rfcefdp-01-202101122000-00.html --Apple-Mail=_8A5F6563-7F3D-4D42-9D59-3F4714AA1723 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAPwokACgkQh7ZrRtnS ejOJxQf7BQPyRe+4NUtmYoz48veKwfSPejQRZSd7y0PzZZGnxeyFKrZ5mYJnUk2m fW2QyZzVCouxfUfEQqC25vObhb6u6sHtARMGYT25Qdss/yib5WTKc2/Uj3+RFnAC hl7ZYP1cCtj5Ij+oTr7dqsxjWJZjVlF5IKt+Y2ZOi9MpmTlQjelpVuiFHdJdXHK2 Z8IhRrAkuXbV/z4B7rlcUwJfRVfuLfxhWccttM0zVjoZKjkj4JFzqHpaVdziSHWL hip/F67K7QZV+6OTVX0cek6knoe2yU72TIDMPbmDm+VVrCaaHv6Ki+ubfE+UpA+K O/V5E3hGKT1pvb7cBeX3RUbdd/K+3Q== =3hZQ -----END PGP SIGNATURE----- --Apple-Mail=_8A5F6563-7F3D-4D42-9D59-3F4714AA1723-- From nobody Mon Jan 25 23:37:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C973A0AEC for ; Mon, 25 Jan 2021 23:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.701 X-Spam-Level: X-Spam-Status: No, score=-7.701 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0MFQgUUzMZb for ; Mon, 25 Jan 2021 23:37:19 -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 5A0D73A0AE1 for ; Mon, 25 Jan 2021 23:37:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2035; q=dns/txt; s=iport; t=1611646639; x=1612856239; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Qktt2e+Rb4GZGvM7B9WaaLniCEKptlrGZHocvAWl1cw=; b=NoHDhd7DE7+CHcGFB82t1KtXlBujgMKwbgW5z5qJI2jDMf4FudWGMo/M Wut2V1Ll3oxzm9gdVmUv/5TPB4hvN4C6tkaH1WnPE8b5+sbPBz0SCTiJG dgIeVRX+FpWxSA1NrQf2J49UpxTdUTUCn/fSFhNydQpNhNLYSD343SrJc c=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0DtAgA6xg9gjBbLJq1iHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?U+BdoICASASjXOIMCWcRAQHAQEBCgMBAS8EAQGESgKBeSY4EwIDAQEBAwIDA?= =?us-ascii?q?QEBAQUBAQECAQYEFAEBAQGGRoV0BnkQCzsLVwaDOQGDBrFxdIE0hVmEeRCBO?= =?us-ascii?q?IFTi2tBggCBEScMEIIoLj6IC4IKIgSBT4FaPggwRjpxnFicMoMBgymBN5cPA?= =?us-ascii?q?x+ieLEiYoNwAgQGBQIWgW0hgVkzGggbFWUBgj89EhkNji0OCRSOE0ADZwIGC?= =?us-ascii?q?gEBAwmMFQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,375,1602547200"; d="asc'?scan'208";a="32948758" 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; 26 Jan 2021 07:37:15 +0000 Received: from dhcp-10-61-106-5.cisco.com (dhcp-10-61-106-5.cisco.com [10.61.106.5]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 10Q7bDph019324 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 26 Jan 2021 07:37:15 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1BD5C736-45DF-47D6-9A4E-111ECBBA8C77"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Tue, 26 Jan 2021 08:37:12 +0100 In-Reply-To: Cc: rfced-future@iab.org To: John C Klensin References: X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.106.5, dhcp-10-61-106-5.cisco.com X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Notes on documents affected by the changes we are discussing... (long, with exec summary) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jan 2021 07:37:22 -0000 --Apple-Mail=_1BD5C736-45DF-47D6-9A4E-111ECBBA8C77 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thank you, John, for this comprehensive review. You accomplished two = tasks, both of which are important: Where we got hung up in our last interim meeting was understanding = precisely what it would mean to apply WG procedures to this new WG that = does not report into the IESG. You discussed the ramifications of this. = Thank you. I believe the intent of the group (and people should be = free to disagree) is that we do a pass on BCP 25 that includes RFCs = 2418, 3934, 7776 (and 7437 by extension), and 8716, to see if we can = substitute roles of area directors for some other people. I will add = this to the issue tracker, but I wonder if you would like to make an = attempt at just that activity? The other thing you did was that you spotted places where other sets of = documents relating to the function of the RFC Editor and various other = roles would need to be updated. To me, these seem like good things = (text and all) to go into the issue tracker, so that they get covered in = our output documents. Thanks again, Eliot --Apple-Mail=_1BD5C736-45DF-47D6-9A4E-111ECBBA8C77 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAPxqgACgkQh7ZrRtnS ejPoaggAqhRuujwGpjUPMG5zUO3viuPYZqqEyGkCG0Nr423Zh9txhvd8QByhGQVJ HCSWuLJa7wvmso7qHCtRgzGAhzylElBTruto3JHKgsrtKIwm7l+PltW26eFab0zM 3t3L8GiBAv47YYTX26x5ecxzq6vvwpoBrweBuxjS6m7Udi8msIegTwpbBzwnzrH5 TYYoaI17Ff56encePHw7fpY+0dO/WDS/1HDynN4DJfIHIXPrLEkfwB1EaCtptdh5 MPOss568g68KPlmJ7rklBT55Y9/9m8uFLBdZ0o6WVAgsRbrqy1tKKgoqFssHztc3 ebvyKu79TX9XV7sC84hgbaGTLC1s1g== =QxBd -----END PGP SIGNATURE----- --Apple-Mail=_1BD5C736-45DF-47D6-9A4E-111ECBBA8C77-- From nobody Tue Jan 26 22:34:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5853A137F for ; Tue, 26 Jan 2021 22:34:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=CGjsGhf9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=jNrhhn/J Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SC7ma-vKm2bx for ; Tue, 26 Jan 2021 22:34:49 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F6B43A137E for ; Tue, 26 Jan 2021 22:34:49 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 79454A9B for ; Wed, 27 Jan 2021 01:34:47 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 27 Jan 2021 01:34:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=QALR21qimAaCst45VBtlJm8ZZY12Uve xlqMAyd667GA=; b=CGjsGhf9iuzW54NfxwSgaV4r/ihujFF0VZbJ28WPuwdWaff coDJvQChy4M1BzvFp3SpKl5KV5shKDNb/u6UXFxp6b9zSnXnduuwLr9Ttt2n1o1t vF+lxnLFnxToMtAf1kNQR8DZq0H32EpqDq7FKWMCz/aZBWcWtOrM9yu+xyTe/jpk h5cRfTK4jUrXyIRM9WOK7tUQTlSMnZ4DR8WNY1YGSSQW9EOBWsIN3IZS5GjRk35o nJsTd/BvjTsWtkzN3tFd58YpN1pkv3M30mtJBnhZwY0nSCTMczpC3qkE2be7Rqif EGy6LBZGZGZyGqFUcdCMXerfwJFr+yfKUq0q3lw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=QALR21 qimAaCst45VBtlJm8ZZY12UvexlqMAyd667GA=; b=jNrhhn/J+l5VPf7fj0LGJ7 6VkDGg4UyJo58/4XJ9pRQkNXf5RmntzoARqJlh8qN1mNO+nIf1yIAfm2FfK4AmRv iTbfW+MAq7GPlNhfGTSEiLIW0mXjZOTXA+iD02LatuqSaxkVwhT9u1GXWuhLA9w/ cmPkVDf/prhTZZQgt2prab9dJp/1xwxR1MMEnHEmjfOm+fGPHJoYTDDVPATItSDf FWCIvhVxDCQBi7/YaQ94I7539PaYyOHno/N6oUrmIMdpbRTwDEgszupQ5UsvnVHG PwB5MfBiXxhQp7GTvyPVQvA7jDQJW1EcH4NumYxJN2otbSnhjG9zpBORBKE+tZJQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdejgdelkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtkefhvd fhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id D21F24E0062; Wed, 27 Jan 2021 01:34:46 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8 Mime-Version: 1.0 Message-Id: <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> In-Reply-To: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> Date: Wed, 27 Jan 2021 17:34:26 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Community_last_call_=28was_Re=3A_Propos?= =?utf-8?q?ed_=22Oversight_Body=22_structure=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 06:34:54 -0000 On Tue, Jan 26, 2021, at 12:21, Brian E Carpenter wrote: > This is not sufficient. There needs to be somebody there who can speak > for the RFC Editor function and say, if necessary, "This will break > the RFC editing service itself." In the emerging proposal, that person > can really only be the RSA/E themself, assuming we don't want to put > a representative of the RFC Editor contractor in the process. > > Also, I think we'd need a rep from the contracting agency (i.e. the LLC) > who can say, if necessary, "This will break the contract or budget". I think that the latter suffices for the former. Let's say that it is the LLC. They can be responsible for determining whether their contractor is able to handle the change. That seems like a pretty reasonable amendment in addition to Christian's request for a formal public review process (which I support). From nobody Wed Jan 27 05:51: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 52E773A1190 for ; Wed, 27 Jan 2021 05:51:34 -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 qcnVsg5H22nI for ; Wed, 27 Jan 2021 05:51:32 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49A353A118F for ; Wed, 27 Jan 2021 05:51:32 -0800 (PST) Received: from p200300dee71fe600c9b8fa4b0f766cae.dip0.t-ipconnect.de ([2003:de:e71f:e600:c9b8:fa4b:f76:6cae]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1l4lED-0007pI-4Q; Wed, 27 Jan 2021 14:51:25 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> Date: Wed, 27 Jan 2021 14:51:23 +0100 Cc: Christian Huitema , Eric Rescorla , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <2569EC66-2ABC-495E-8F86-0F82B3009189@kuehlewind.net> References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1611755492;95e821bf; X-HE-SMSGID: 1l4lED-0007pI-4Q Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 13:51:34 -0000 Hi Brian, hi Ekr, hi Christian, hi all, Thanks for putting this proposal together! Look like a good way forward = to me. Please see further below. > On 26. Jan 2021, at 02:21, Brian E Carpenter = wrote: >=20 > Several comments in line: >=20 > On 26-Jan-21 08:47, Christian Huitema wrote: >>=20 >> On 1/25/2021 7:10 AM, Eric Rescorla wrote: >>> I was asked to come up with a proposal for what to do about a >>> proposed oversight body. >>>=20 >>> The current overall proposals are for a two-level structure, which >>> has: >>>=20 >>> An open WG that is responsible for producing proposed changes to the >>> RFC series An Approval Body [name TBD] which is responsible for >>> approving the output of the WG >>>=20 >>> At the last interim, it seemed like there were at least three >>> rationales that people thought that the AB might potentially use to=20= >>> disapprove a proposed change: >>>=20 >>> 1. It didn=E2=80=99t work for one of the Streams >>> 2. The process wasn=E2=80=99t followed >>> 3. They didn=E2=80=99t agree with the contents >>>=20 >>> I heard a fair amount of agreement on the first two of these, but = also >>> a number of people objecting to (3) on the grounds that the AB >>> shouldn=E2=80=99t be overriding the judgement of the WG. Conflicts = between the >>> IESG and WGs on the contents of documents have been a persistent >>> feature of the current system, leading to, for instance, the DISCUSS >>> criteria. Given the amount of distrust of leadership making = decisions >>> here, I think we should consider not replicating that structure. >>>=20 >>> It also seems to me that the function of determining whether = something >>> works for the individual Streams is a question for the Stream >>> Managers, but they=E2=80=99re not particularly well positioned to = determine >>> whether the process has been followed. Given that this WG is likely = to >>> exist under the auspices of the IAB and they are likely to select = the >>> chairs, it seems like they are the natural body to determine whether >>> the process was followed. >>>=20 >>> With that in mind, what I propose is the following: >>>=20 >>> An RFC Stream Manager Committee (RSMC) would be formed, consisting >>> solely of the four Stream Managers. They would need to approve each >>> process change, but objections need to be limited to the question of >>> whether a specific change would cause harm to their own Stream. The >>> specific voting rules are TBD, but the obvious choices are unanimity >>> or 3/4 supermajority. If we require unanimity, that creates the >>> concern of allowing one manager to stonewall, which seems = suboptimal. >=20 > This is not sufficient. There needs to be somebody there who can speak > for the RFC Editor function and say, if necessary, "This will break > the RFC editing service itself." In the emerging proposal, that person > can really only be the RSA/E themself, assuming we don't want to put > a representative of the RFC Editor contractor in the process. >=20 > Also, I think we'd need a rep from the contracting agency (i.e. the = LLC) > who can say, if necessary, "This will break the contract or budget". So I think it=E2=80=99s two different questions about a) what and from = whom we need to hear during the process and b) who should be on the = approval body. Input can be provided either to the working group directly or to the = approval body (in form of liaisons or =E2=80=9Cnon-voting=E2=80=9D = member - basically other people who participate in meetings). E.g. if = the RSx or Jay, or anybody else brings a concern to the approval body = and can convince someone there that it is a real problem, I think that = problem will be handled adequately. So for the approval body we need people who can listen and have a good = overview about want=E2=80=99s going on in their respective part of the = community. And I=E2=80=99d say the stream manager might be well = positioned for that. See on a follow up point below. >=20 >>>=20 >>> The IAB would be responsible for ensuring that the process was >>> followed. I think the easiest way to do this is not for them to >>> formally approve documents coming out of the WG but rather for them = to >>> be an appeals body. However, the appeal grounds should be limited to >>> process issues, not substantive objections. I hear that there are >>> concerns that the WG won=E2=80=99t listen to expert advice. In my = opinion, the >>> right balance here is that the expert gets an opportunity to speak = and >>> the process requires they be heard and the WG explicitly decide not = to >>> take their opinion, but the WG is the final decision maker. Then = =E2=80=9CWG >>> did not fully consider and decide on whether to take expert = advice=E2=80=9D >>> can become an appeal ground, but it=E2=80=99s not an opportunity for = the IAB >>> to substitute their own judgement for the WG=E2=80=99s. >>>=20 >>> In short, the WG would be responsible for the strategic work, but = would >>> be subject to two forms of narrowly scoped review: the stream >>> managers for "this will break my stream"=20 >=20 > As noted, there are other things that might break. >=20 >>> and the IAB for "the >>> process wasn't followed". >=20 > I am far from convinced that the IAB is a valid representative of the > community served by RFCs. (It *is* a valid representative of the > community creating RFCs, but that's different.) Not sure if the IAB need to be a valid representative of the community = in that role. If the question is if the process was followed, the main = requirement is that we have an appeal body that was not part of the = process so far. >=20 > Unfortunately I don't have a better suggestion at the moment. >=20 >> I largely agree with this proposal, except for the lack of some kind = of=20 >> community wide consultation. The proposal addresses two failure = modes,=20 >> hampering the management of streams and not following due process. I=20= >> understand why we might not want to invest a small body with the = power=20 >> of overriding WG consensus. But I am concerned about a different = failure=20 >> mode, group-think in the WG blindsiding the community at large. This = is=20 >> addressed in the IETF process by the IETF last call. I believe we = need=20 >> something similar here, some kind of "community last call", and that = the=20 >> Approval Body should be entrusted to verify that issues raised during=20= >> this community last call are properly addressed. >=20 > Agreed, but there is another aspect of the same problem, as we have = often > discussed: how to send a Last Call to the RFC user community, not just = to > the RFC writing community? As noted some time ago, the rfc-interest = list > doesn't even scratch the surface. There is the other point about stream manager that I wanted to make. I = think stream managers actually represent their part of the community. As = such I don=E2=80=99t see it as the stream managers role to decide = (except for small points that are straight forward) but to check for = consensus in their community. Each stream has an own process for that = and I think we should make use of those established processes. Yes, that doesn=E2=80=99t reach all the readers/consumers but that also = true for all documents that we publish in each stream. Mirja >=20 > Regards > Brian >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed Jan 27 09:13: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 6C7BC3A09E7 for ; Wed, 27 Jan 2021 09:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7x27bBIo0fA for ; Wed, 27 Jan 2021 09:13:46 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8FD3A09CF for ; Wed, 27 Jan 2021 09:13:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2E627300B8A for ; Wed, 27 Jan 2021 12:13:44 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0kkyQPEzd1UB for ; Wed, 27 Jan 2021 12:13:42 -0500 (EST) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 729C0300B84 for ; Wed, 27 Jan 2021 12:13:42 -0500 (EST) 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: Wed, 27 Jan 2021 12:13:43 -0500 References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> To: rfced-future@iab.org In-Reply-To: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> Message-Id: <623D2C2D-2AC3-4670-8956-DF29F0245DA6@vigilsec.com> X-Mailer: Apple Mail (2.3445.104.17) Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 17:13:50 -0000 On Tue, Jan 26, 2021, at 12:21, Brian E Carpenter wrote: > This is not sufficient. There needs to be somebody there who can speak > for the RFC Editor function and say, if necessary, "This will break > the RFC editing service itself." In the emerging proposal, that person > can really only be the RSA/E themself, assuming we don't want to put > a representative of the RFC Editor contractor in the process. >=20 > Also, I think we'd need a rep from the contracting agency (i.e. the = LLC) > who can say, if necessary, "This will break the contract or budget". I think the RFC Production Center and the IETF Admin LLC need to have = advisor roles. They can answer questions about the publication process, = budget, and contractor capabilities. There may be some tough calls = where the community wants something that will cause big changes. We = have lived this. The transition to the XML v3 schema has process and = budget impacts. Yet, we are doing it. I think the addition os a Last Call into the process is a good idea, but = we need to figure out a way to announce it very broadly. I assume the = announcement will point to a place for the discussion to take place, but = it should not be last-call@ietf.org. Russ From nobody Wed Jan 27 10:48: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 25D2E3A0D00 for ; Wed, 27 Jan 2021 10:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 073nQ85H6WlO for ; Wed, 27 Jan 2021 10:47:59 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011813A0CFE for ; Wed, 27 Jan 2021 10:47:58 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id b17so1545164plz.6 for ; Wed, 27 Jan 2021 10:47:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=JWHPeROUsG1smPQWRs4P6k3pSBT/tS7GJZxXmhMRtoA=; b=dQSM7PtmkPmgdtvMktBt3NmEpX4C+yUnWqGifqAx966kJL5mabsH7x/zq2IDAC0YyW vxNw9Qkfr+3ByOgUgVEB1pvYW8+zX0W7ELvN9R4aARPWsTkkX/s9b3pkkCgzo4ML5EhG 2Dc+OQcZtNwrz67FS1f4f9GTlUHNpcOx6Vw9RTihiNbbS71J6mkLlxl+RdZezUPxY6C1 Gt0U5DUOWbi6yqMwCWF9UmgvE0E7Uk50L8EQYwigjDTEfAT5WeHPNRD3r6cGoCYSLo91 kF54XrqwED8THmCQ97dR7zsJm6UHatFgW0G4JrSLCHJ9cO00X4rD1+jw6W2EGU+Of94M PsHQ== 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=JWHPeROUsG1smPQWRs4P6k3pSBT/tS7GJZxXmhMRtoA=; b=NJa1jtzi37mPLs/Z1hUln7syADCyqm0SAUpuGlYy3h5aUsQpKkyCRT/fnyjhu0R0eq mK8sMHu1w2Ryey4RLuiz5cxjYKdWK23SxSpsKna7CyUQxzLFBD7EqKdy1kCJZgwxHqbt A8SN37Jsv/k/2F7dmMtgcA2+D0fktldT4pGxDh/vBrMauX7UhZhi+vhCzGn0GJBKddqg F69yMOPFjjuc935GDqdfpaAkvt3uPqFVdWxu6RyOGhVRH5SZZagG22tUJZQFIJu/r/6x 10E2eCPcrMun6iOPMNQLBL1r8Hq/pzkelFsLI0ttAo/TEOsUh/IvCLZmSq+KG4yRbNaW dxvA== X-Gm-Message-State: AOAM530XwLBc/3D5zrFfZTsCeGBOPDk8WwungFKuCqeQVP708fPzQFOT sJHtHJ67Hym0jIbGl1ITqCARvh8tzBXU4w== X-Google-Smtp-Source: ABdhPJzTeJ7aby5YFEZOfG/DP+lur6SwhxGLrSUbUXPFHxleymjpS8nUDB305+8Yiab3S6vMIoukUA== X-Received: by 2002:a17:90a:6c26:: with SMTP id x35mr7190150pjj.52.1611773277907; Wed, 27 Jan 2021 10:47:57 -0800 (PST) Received: from [192.168.1.117] (125-236-230-222.adsl.xtra.co.nz. [125.236.230.222]) by smtp.gmail.com with ESMTPSA id g17sm3124560pfk.184.2021.01.27.10.47.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jan 2021 10:47:57 -0800 (PST) To: Martin Thomson , rfced-future@iab.org References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> From: Brian E Carpenter Message-ID: <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> Date: Thu, 28 Jan 2021 07:47:53 +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: <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 18:48:00 -0000 Martin, On 27-Jan-21 19:34, Martin Thomson wrote: > On Tue, Jan 26, 2021, at 12:21, Brian E Carpenter wrote: >> This is not sufficient. There needs to be somebody there who can speak >> for the RFC Editor function and say, if necessary, "This will break >> the RFC editing service itself." In the emerging proposal, that person >> can really only be the RSA/E themself, assuming we don't want to put >> a representative of the RFC Editor contractor in the process. >> >> Also, I think we'd need a rep from the contracting agency (i.e. the LLC) >> who can say, if necessary, "This will break the contract or budget". > > I think that the latter suffices for the former. Not really. I don't mean that the RSA/E would be concerned about operational breakage. I was thinking about comments like: "This proposal will damage the RFC Series as an archival series, because..." or "This proposal will damage the reputation of the series because..." or "This proposal won't work as the WG expects because..." or, of course, things that I can't imagine since I'm not an expert in technical publishing. Most of us aren't, which is why we need an RSA/E in the first place. Brian > Let's say that it is the LLC. They can be responsible for determining whether their contractor is able to handle the change. > > That seems like a pretty reasonable amendment in addition to Christian's request for a formal public review process (which I support). > From nobody Wed Jan 27 15:35: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 58AA73A0D6F for ; Wed, 27 Jan 2021 15:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=a6Zur4zg; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ag7OrQiP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w8JArGpl2tww for ; Wed, 27 Jan 2021 15:35:56 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0101E3A0D64 for ; Wed, 27 Jan 2021 15:35:55 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 44DA095D for ; Wed, 27 Jan 2021 18:35:54 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 27 Jan 2021 18:35:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=7m5Lu12a3dq46UnEU3jy1KaDNAglFxi 7RoF140qOYek=; b=a6Zur4zgC2KxEEvoCzhhjSPuPDl8t9rjg3EI0+ambkydXan y9ZyXkFoYU6XT0TMhuEjYZHqTB+jiGJxnDvyqJqxlmPYK5oZltpa3VAWe2BM8EoP 3AY5HYw3JAAovMqz80aBgU5ecYaqcmyfkdgRbckbqJ5RH/hs601lRdWGkeGDSr1+ Oec4XMkEuubp3uPzm1YMrxLqGDK8MFrwxZz8vsCP8PZUCgZvAcR0SIVgdX+WPstm Dj2QJUK3GiWBNi1nhlN3M0G5RVxcPQ4VqpYkO4C+vJZB11otmR63gGBCJ7vwwZne BDGFllMnl7PTYyROJ/7omo3khSbOniNDIuJUnIQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=7m5Lu1 2a3dq46UnEU3jy1KaDNAglFxi7RoF140qOYek=; b=ag7OrQiPMgvkFX6e+M9t7s x/alNndLFPzU4HqmBo5H9b6OUNl8aoPaV17aDx07/Ax2FPqbPX/g+kFY4hrsoj2/ yHSFohs9aHSa2uGRlGB00XBe2CymtqNYrqdcra4xqIkhJyIdSkWxovvDNerA17ls z2HtphVSBL4/f/c2NUV3zpDhMZT/D2ItNMLi9WsSPuG6LfOxnj1MuYWOSc9Q8DRF JQiHQmJqM/jUdsV5kEBr/hrXCNx8x2B1fRDv9wT3T3J+L+t19SEfw/ahxARxFCZ2 OG3l7foi8j4YYi3yj+AB/JmH5lKeLAwWgmxtTnmB4/1MZcjyYN3z3FNnkVOqjvAg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtkefhvd fhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7E6F74E0064; Wed, 27 Jan 2021 18:35:53 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8 Mime-Version: 1.0 Message-Id: <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> In-Reply-To: <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> Date: Thu, 28 Jan 2021 10:35:33 +1100 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Community_last_call_=28was_Re=3A_Propos?= =?utf-8?q?ed_=22Oversight_Body=22_structure=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 23:35:58 -0000 On Thu, Jan 28, 2021, at 05:47, Brian E Carpenter wrote: > Not really. I don't mean that the RSA/E would be concerned about > operational breakage. I was thinking about comments like: > > "This proposal will damage the RFC Series as an archival series, because..." > or > "This proposal will damage the reputation of the series because..." > or > "This proposal won't work as the WG expects because..." > or, of course, things that I can't imagine since I'm not an expert > in technical publishing. Most of us aren't, which is why we need > an RSA/E in the first place. I think that was addressed in Ekr's proposal (or at least it was to my satisfaction). That is, the advisor would be expected to provide this input to the working group analogue as part of consideration of any change. If that input was considered, but not accepted, then that is within process and the expert could be "in the rough" as occasionally happens to domain experts in other fields. (Noting of course the hazard of that is well understood and that understanding should be particularly well-noted in any documentation we create.) In other words, the working group analogue is able to do damage to these things if it reaches broad consensus. Generally though, I would expect harms along those lines to be balanced by advantages in other ways, which makes the overall assessment situational, difficult, and nuanced. That is why I think that the open forum is the most appropriate way to ensure that those concerns are surfaced, heard, and addressed. The only grounds for blocking a proposal that has consensus of the WGA is for the approval body to reject it or if the process was not properly followed. The approval body is given fairly narrow grounds upon which they can reject something. That all said, you might consider the above reasons to be included as reasons for a stream manager to block something, depending on the details of the situation. For example, any stream might reasonably regard input that suggests catastrophic loss of series credibility as a threat to the viability of that stream. From nobody Wed Jan 27 15:46:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BCAC3A0D93 for ; Wed, 27 Jan 2021 15:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAJcGrSdOKOi for ; Wed, 27 Jan 2021 15:46:17 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17703A0C99 for ; Wed, 27 Jan 2021 15:46:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DR0c92jkwz1ny8R; Wed, 27 Jan 2021 15:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1611791177; bh=oiZHML7fiC6tNcZYKb+Qhg5Qd5TXr0szIvEQMQb5fBk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Lgwg6dtg1J5k2oDt9syZcXLRCiTa8A4klk2+xgUdxlVNsqx+IEFXJEg8bJKx16QJT Avq0W1qkBoBDpJ9fBIkAz87z/hbFsFGkhSnh7CKmN9ZVxxQ34hw2qq/5Zrqmy1UJxE A+Xk4P8NvemOGWyMh1rMN68fJh4vtNlbTvyetQsg= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DR0c868nSz1nvc4; Wed, 27 Jan 2021 15:46:16 -0800 (PST) To: Martin Thomson , rfced-future@iab.org References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 27 Jan 2021 18:46:15 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Jan 2021 23:46:19 -0000 The big difference is that in normal IETF working groups, the people making decision are themselves experts in the field. That's why people trust us to make these decisions. In this case, the "wg" members are not experts in the field of technical publishing. I do not think "sorry, the RSE?A was in the rough" is really enough. And given teh history of even skilled working groups making occaisonal significant technical mistakes, I do not think it suffices for the review body to be barred from saying "you blew it". Yours, Joel On 1/27/2021 6:35 PM, Martin Thomson wrote: > On Thu, Jan 28, 2021, at 05:47, Brian E Carpenter wrote: >> Not really. I don't mean that the RSA/E would be concerned about >> operational breakage. I was thinking about comments like: >> >> "This proposal will damage the RFC Series as an archival series, because..." >> or >> "This proposal will damage the reputation of the series because..." >> or >> "This proposal won't work as the WG expects because..." >> or, of course, things that I can't imagine since I'm not an expert >> in technical publishing. Most of us aren't, which is why we need >> an RSA/E in the first place. > > I think that was addressed in Ekr's proposal (or at least it was to my satisfaction). > > That is, the advisor would be expected to provide this input to the working group analogue as part of consideration of any change. If that input was considered, but not accepted, then that is within process and the expert could be "in the rough" as occasionally happens to domain experts in other fields. (Noting of course the hazard of that is well understood and that understanding should be particularly well-noted in any documentation we create.) In other words, the working group analogue is able to do damage to these things if it reaches broad consensus. Generally though, I would expect harms along those lines to be balanced by advantages in other ways, which makes the overall assessment situational, difficult, and nuanced. That is why I think that the open forum is the most appropriate way to ensure that those concerns are surfaced, heard, and addressed. > > The only grounds for blocking a proposal that has consensus of the WGA is for the approval body to reject it or if the process was not properly followed. The approval body is given fairly narrow grounds upon which they can reject something. > > That all said, you might consider the above reasons to be included as reasons for a stream manager to block something, depending on the details of the situation. For example, any stream might reasonably regard input that suggests catastrophic loss of series credibility as a threat to the viability of that stream. > From nobody Wed Jan 27 16:04: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 D72733A0DFE for ; Wed, 27 Jan 2021 16:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=YDIf6lSw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=F0JE4quj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUZpHx0SObBx for ; Wed, 27 Jan 2021 16:04:50 -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 370873A0DF9 for ; Wed, 27 Jan 2021 16:04:50 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 4AE165C01DF; Wed, 27 Jan 2021 19:04:49 -0500 (EST) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 27 Jan 2021 19:04:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=9eHfwRndvULiQ8BaOUGqmn6h65BhiNe uSanOlioJP3A=; b=YDIf6lSwOuftQazxszZxCck+d9EyertcU4r3Lc5UXOs11As xPlRSu4oyPBZhKhtGpzlEr7f3wNm+LcTO1BGJ9hkQIXgJFYh7imMyo+vnQn6dL5U xqZK0G/37uoto6UAEXnuuVEQqceNiDXD4oHwy5n+qSGvZvMG3Ra+5/8c9QH9MHP8 QIi3QgJr7pUltiqnrPgaWlM7Fm3ept3rybIcDQivlKsc5QiPPaFSG8B0VKRnjj9N jwA9ii+/hvXvT9wzI+F9HKs5ZrjQpkdVeB6zkcV1xWvg8kNQIUFbv2+8TSwUjKp1 98lL28F3plyL61/f4ZivfqUvtQE7J5g9fso5HxA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=9eHfwR ndvULiQ8BaOUGqmn6h65BhiNeuSanOlioJP3A=; b=F0JE4qujV1Btxe93WV9Okw DWVgBcFXTEpT/kpJEKc0+sfcRFt8I3njrQ+ofpC3LBhjeun/Psu0CYP/qSJ/4hDs JLoJE306OLk/OLuh7AE6Mtj7uNQzBcA+qmgCAINQze6M/e9K8V3sjMoXbqwMQqdo PAmy2BPsMoIWCY1dErfDIERl+J5AVmmCd8nmaRxlzSC81eBouadAynQL1TIn7vpn qYtTOL/l97GDfQPabXdTYZD2Rpv8vNtnyfRsK+vWkiDqQN1vB8V8X12REbsv8WYq wiyIKIpKwcGXUUqZ+K7jzWt/5B24CZXyaOqY5Fc+4Pku1aQYXJ/yzXZGXt75zKPg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdelgddujecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepheefteduudduhedtkefhvd fhteelffdujeegjeffheffveekudeigfeuveekfeelnecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CCE944E0063; Wed, 27 Jan 2021 19:04:48 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-84-gfc141fe8b8-fm-20210125.001-gfc141fe8 Mime-Version: 1.0 Message-Id: <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> In-Reply-To: References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> Date: Thu, 28 Jan 2021 11:04:28 +1100 From: "Martin Thomson" To: "Joel M. Halpern" , rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Community_last_call_=28was_Re=3A_Propos?= =?utf-8?q?ed_=22Oversight_Body=22_structure=29?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 00:04:53 -0000 On Thu, Jan 28, 2021, at 10:46, Joel M. Halpern wrote: > The big difference is that in normal IETF working groups, the people > making decision are themselves experts in the field. That's why people > trust us to make these decisions. This oversimplifies things. As a regular participant in discussions, I often find that the level of expertise in various subject areas varies greatly. When everything is working (which is most of the time) I am able to offer my particular expertise and rely on others for theirs. We each defer to others in areas where we recognize our own shortcomings. You seem to be suggesting that participants in this process won't do the same. I can't accept that argument. I appreciate that we might need systems in place to cover the difficulty in communicating across disciplinary lines, but that does not - for me - extend to reification of the advisory role. From nobody Wed Jan 27 16:09: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 6C2D23A0EDF for ; Wed, 27 Jan 2021 16:09:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlBn4XkZaxZi for ; Wed, 27 Jan 2021 16:09:08 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63313A0DFE for ; Wed, 27 Jan 2021 16:09:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DR16X3Yp0z1nvPZ; Wed, 27 Jan 2021 16:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1611792548; bh=YDPA5feHZ3koFI+RLKxy6BP86GsmdSGPhh9HvaU/ew0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=lrdm01DJKUeYA9GRyX2bnUCC02P/kykYQwwjXhVYi0Zg3fwo/HkgpGqHGWNoVlMsy S5u4YuyjWF+eiKxyTAHPR1XX4EiC6tNEAHOXLKmpYirAU1zUGQ900p5XDIYLbp71NV vTyFPMpP+L0UKaVr4UxCP3+8JRERYv3Mqn7xHjDM= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DR16W6ZY5z1nvCD; Wed, 27 Jan 2021 16:09:07 -0800 (PST) To: Martin Thomson , rfced-future@iab.org References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> From: "Joel M. Halpern" Message-ID: Date: Wed, 27 Jan 2021 19:09:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 00:09:17 -0000 The question is not how it works when everything works right. An amazing range of structures will work when everything goes right. My concern is what guardrails we have to help us when things go wrong. This is rather similar to the point several lawyers have made to me over the years about contracts. The contract isn't for when the business is working smoothly. It is for when things go wrong. Yours, Joel On 1/27/2021 7:04 PM, Martin Thomson wrote: > On Thu, Jan 28, 2021, at 10:46, Joel M. Halpern wrote: >> The big difference is that in normal IETF working groups, the people >> making decision are themselves experts in the field. That's why people >> trust us to make these decisions. > > This oversimplifies things. As a regular participant in discussions, I often find that the level of expertise in various subject areas varies greatly. When everything is working (which is most of the time) I am able to offer my particular expertise and rely on others for theirs. We each defer to others in areas where we recognize our own shortcomings. > > You seem to be suggesting that participants in this process won't do the same. I can't accept that argument. I appreciate that we might need systems in place to cover the difficulty in communicating across disciplinary lines, but that does not - for me - extend to reification of the advisory role. > From nobody Wed Jan 27 18:18: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 B61003A1113 for ; Wed, 27 Jan 2021 18:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cD-czCHPyYlL for ; Wed, 27 Jan 2021 18:18:55 -0800 (PST) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72273A1107 for ; Wed, 27 Jan 2021 18:18:55 -0800 (PST) Received: by mail-pg1-x532.google.com with SMTP id j2so1621563pgl.0 for ; Wed, 27 Jan 2021 18:18:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=JTw5PzN1aOKDK58PwWsq+MQUOqRcxtfPN3Qk3J3KoHs=; b=e+qpVYzgPbpXgIk/znW/MncKhOY/c8+aI8WYBeVg/M/JWLWIjTkddxhM8k5ANBmIGy 3gYF8sEAv57N5jgZuS6yx/jy6e3JsNZY9DvqDnXgB3nb0NXrG2Penmuq1HQDbJ4r9gg/ zD/hYbGzToqBLqLaGe6kHmWsH/fHsSLOwkEG4SJ44JDM7BT5aicfjW76cqG2LcP7PCws sZjW8PisstQ3KBMLBAeQ20NV/Vv5ND8ySvWLX3iq+nKRbIF/SilZefS1RtPswZGKcYLP zDiaFhIFiA5QGPt+t1S2linH38lmtFhDQxt5xBDEUviW1cZLGglf21juSogVVCk9UaOt 2sUQ== 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=JTw5PzN1aOKDK58PwWsq+MQUOqRcxtfPN3Qk3J3KoHs=; b=kw7E9Q2Hhit+wyCbadzu5pV2SPin9eaoJwCiCzN4zcoOXxI9YcnEfrzTenPqnk6th3 vzs1nkwlODlozodRHx4itNkjKqT/ijRN6t0emdtFfaRMpKpB/pBsqzAUtwQZXnMsCz7u YlH/IOCyceccGKqiPXTpKNNTAzpcmMgRzIfS7+iUAokrAt3vvMf+3hQ1mzY8v9bQEcjL MaaeBHs3umfiw0kgjHmgqrmHTVN2ZZk9aDDIVBt5g0Wd6WqTTMXNUR/IRTDzcJn1P5YO UDVlK+2XxQqrmQszxXqCmQjTKz1UuSy3Zq0O9ezFtBlOlC+l8RqgG6/2RkOU1eMXaOhl DmKw== X-Gm-Message-State: AOAM531ziZOjQzbYU1C2iRGsGaBhoW+He+UnD3j8r1nZZc/dCB/Q+Epf YWMnu5eMDrVk8y45zsWzymZBJ283ZAKDBw== X-Google-Smtp-Source: ABdhPJxkv+J2j+YiRAaOkqqp26OkYF/HZyiVKbUlMouxikdDiw6+XfNUdlzPlHR8JmLGZEUcVGaLxQ== X-Received: by 2002:a62:8c8d:0:b029:1bb:b6de:c872 with SMTP id m135-20020a628c8d0000b02901bbb6dec872mr13469766pfd.68.1611800334586; Wed, 27 Jan 2021 18:18:54 -0800 (PST) Received: from [192.168.1.117] (125-236-230-222.adsl.xtra.co.nz. [125.236.230.222]) by smtp.gmail.com with ESMTPSA id a31sm3413141pgb.93.2021.01.27.18.18.52 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jan 2021 18:18:53 -0800 (PST) To: Martin Thomson , "Joel M. Halpern" , rfced-future@iab.org References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> From: Brian E Carpenter Message-ID: <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> Date: Thu, 28 Jan 2021 15:18:48 +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: <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 02:18:57 -0000 On 28-Jan-21 13:04, Martin Thomson wrote: > On Thu, Jan 28, 2021, at 10:46, Joel M. Halpern wrote: >> The big difference is that in normal IETF working groups, the people >> making decision are themselves experts in the field. That's why people >> trust us to make these decisions. > > This oversimplifies things. As a regular participant in discussions, I often find that the level of expertise in various subject areas varies greatly. When everything is working (which is most of the time) I am able to offer my particular expertise and rely on others for theirs. We each defer to others in areas where we recognize our own shortcomings. > > You seem to be suggesting that participants in this process won't do the same. I can't accept that argument. I appreciate that we might need systems in place to cover the difficulty in communicating across disciplinary lines, but that does not - for me - extend to reification of the advisory role. The suggestion is not to give the RSA/E a pocket veto by putting them in the approval group. It's to make sure the approval group will hear directly from the expert, in the case (hopefully rare) where the common sense and/or groupthink of the WG has led to a proposal that the publishing expert thinks is seriously wrong. We give the security ADs a "DISCUSS" button; why wouldn't we give the technical publishing expert one too? Brian From nobody Thu Jan 28 05:52: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 C14613A14FD for ; Thu, 28 Jan 2021 05:52:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ROp0W0TYEKCl for ; Thu, 28 Jan 2021 05:51:59 -0800 (PST) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A7C3A14FF for ; Thu, 28 Jan 2021 05:51:59 -0800 (PST) Received: by mail-lf1-x12c.google.com with SMTP id m22so7675663lfg.5 for ; Thu, 28 Jan 2021 05:51:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XI2YLQsDIYo6LthTE8HjlpOjOXn0wTzMrjJYzRISwr8=; b=Cbw9I5gmuQoC4+RwraqQVN5hByawcThpxVxGWWzLt5P+ZbEY4+MDFvEN1h6aoppz4i 7kmLMlHSBVPCOFZnBC1VcEZh/Fsrgnl96KAGoGxEFuqq8thiZ+mZoKZ67LMCpc2cPYfO I727Oj3bXVTQfCfHjuR0VBK/6qMLsxkRfYuF1FynQdC7U0jRSS/PtIw+EPddc0aEFY2Z gfXZJ/k8di4nqP4ZQVWpHUPKBTIQ09+eJGKGzEttBZXzvAEYwrPk3TYByVdt/nHHbMK5 xbkphKCeE6Z3E39YqG5upqi1SGwIhAVMH8OqU7rPzx8i6mIBt3yqYLlS6ZBF/m0X1s35 14bw== 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=XI2YLQsDIYo6LthTE8HjlpOjOXn0wTzMrjJYzRISwr8=; b=EaGolEwgZgEeA328F/bf0pEv1pMn7mtpa3DE0yNApiTOh4fo06hwzTaqwP5uLN1Cfr SF21ISQxnIjGEjBtq4VdvIeMsuhGQgw2Y1BQ/sdns9QSNsQltXiv8RMVMGwf00fh8xh+ QX+RrffUKvMVYh51vkEx4EokTwfgLGMQVMogrPnC8pw6ZTvndw7QcjJsKV4f4kQ5j1hQ qyxCRJ6j12rUiFvSEGCFj+vIpJdVCoRvS8Nhvv+O7HJ8iIKvuPYAyFzrgxgs3FYMr0P2 pIRIHBMf+I4U+awc0Gae6JxVcpnfrLIYlyfFBD4K7nM7D6jvLrYB6ty4LC0lSeZULk4J ZBog== X-Gm-Message-State: AOAM532rpHn+Fyfts4alPvxRQXTHGZ8X9rgD4s2eyBtktNzVlL7IUTUe PEWYOO48vP9fAWa7UK8uObOFUAKUNWo7cBkBbaflyA== X-Google-Smtp-Source: ABdhPJxWvmXcd8fyUsQk3tHZHaRDJtrg+GmIbdgBXE+ngU7Hdq4t3Ida9U2Bxa0b9PaIxUqcRXErGML54arWWfJpX5Q= X-Received: by 2002:a19:6447:: with SMTP id b7mr7355917lfj.206.1611841917235; Thu, 28 Jan 2021 05:51:57 -0800 (PST) MIME-Version: 1.0 References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> In-Reply-To: <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> From: Eric Rescorla Date: Thu, 28 Jan 2021 05:51:21 -0800 Message-ID: To: Brian E Carpenter Cc: Martin Thomson , "Joel M. Halpern" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000e94c6105b9f630d5" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 13:52:01 -0000 --000000000000e94c6105b9f630d5 Content-Type: text/plain; charset="UTF-8" On Wed, Jan 27, 2021 at 6:19 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 28-Jan-21 13:04, Martin Thomson wrote: > > On Thu, Jan 28, 2021, at 10:46, Joel M. Halpern wrote: > >> The big difference is that in normal IETF working groups, the people > >> making decision are themselves experts in the field. That's why people > >> trust us to make these decisions. > > > > This oversimplifies things. As a regular participant in discussions, I > often find that the level of expertise in various subject areas varies > greatly. When everything is working (which is most of the time) I am able > to offer my particular expertise and rely on others for theirs. We each > defer to others in areas where we recognize our own shortcomings. > > > > You seem to be suggesting that participants in this process won't do the > same. I can't accept that argument. I appreciate that we might need > systems in place to cover the difficulty in communicating across > disciplinary lines, but that does not - for me - extend to reification of > the advisory role. > The suggestion is not to give the RSA/E a pocket veto by putting them in > the approval group. It's to make sure the approval group will hear directly > from the expert, in the case (hopefully rare) where the common sense and/or > groupthink of the WG has led to a proposal that the publishing expert > thinks is seriously wrong. Well, the structures I proposed were intended to ensure this. Presumably if the RSA/E believes something is seriously wrong, then that will be raised to the attention of the committee or the IAB. Perhaps it would make sense to have them to prepare a review which is provided to the committee and the IAB. > We give the security ADs a "DISCUSS" button; > why wouldn't we give the technical publishing expert one too? > The security ADs are selected via our quasi-democratic nomcom process [0].This role is not. -Ekr [0] Yes, I am aware that not all the stream managers are selected via this process, but they are the representatives of their streams equities in this case. --000000000000e94c6105b9f630d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 27, 2021 at 6:19 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 28-Jan-21 13:04, Martin Thomson wrote:
> On Thu, Jan 28, 2021, at 10:46, Joel M. Halpern wrote:
>> The big difference is that in normal IETF working groups, the peop= le
>> making decision are themselves experts in the field.=C2=A0 That= 9;s why people
>> trust us to make these decisions.
>
> This oversimplifies things.=C2=A0 As a regular participant in discussi= ons, I often find that the level of expertise in various subject areas vari= es greatly.=C2=A0 When everything is working (which is most of the time) I = am able to offer my particular expertise and rely on others for theirs.=C2= =A0 We each defer to others in areas where we recognize our own shortcoming= s.
>
> You seem to be suggesting that participants in this process won't = do the same.=C2=A0 I can't accept that argument.=C2=A0 I appreciate tha= t we might need systems in place to cover the difficulty in communicating a= cross disciplinary lines, but that does not - for me - extend to reificatio= n of the advisory role.
The suggestion is not to give the RSA/E a pocket veto by putting them in the approval group. It's to make sure the approval group will hear dire= ctly
from the expert, in the case (hopefully rare) where the common sense and/or=
groupthink of the WG has led to a proposal that the publishing expert
thinks is seriously wrong.

Well, the struc= tures I proposed were intended to ensure this. Presumably if the RSA/E beli= eves something is seriously wrong, then that will be raised to the attentio= n of the committee or the IAB. Perhaps it would make sense to have them to = prepare a review which is provided to the committee and the IAB.
<= div>=C2=A0
We give t= he security ADs a "DISCUSS" button;
why wouldn't we give the technical publishing expert one too?

The security ADs are selected via our quasi-demo= cratic nomcom process [0].This role is not.

-= Ekr

[0] Yes, I am aware that not all the stream ma= nagers are selected via this process, but they are the representatives of t= heir streams equities in this case.
--000000000000e94c6105b9f630d5-- From nobody Thu Jan 28 12:50: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 BF5703A1744 for ; Thu, 28 Jan 2021 12:50:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ANdN_nnZ7j81 for ; Thu, 28 Jan 2021 12:50:29 -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 50C5B3A1743 for ; Thu, 28 Jan 2021 12:50:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3988; q=dns/txt; s=iport; t=1611867029; x=1613076629; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=JuwPFzwwd8pxi9N+Z9JwoHjidMFhxCpjjTp4rbkNJBk=; b=CX9vJBgqBKATZStWb0hYITzB7Asl3IB5eF+jOcfORh0reUZf0Y9ZwaR6 EV6lHyfUgpLpY44bbHDLwWZvjeJHylNd45Rw8F0xI0HHW7FlKoeHEW9aw JO+zSeZ5wR7P/TEo9gXEtsEhrt7d+JJpT1ARl4LBZryTdgoHt6aQLr1ji c=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BRBQCLIhNg/xbLJq1iHgEBCxIMggQLgSOCVAEjEoRvi?= =?us-ascii?q?QSIUYdujDiIHQQHAQEBCgMBAS8EAQGESgKBeSY3Bg4CAwEBAQMCAwEBAQEFA?= =?us-ascii?q?QEBAgEGBHGFboV0AQQBI1YQCwQKNAICVwYngxIBgmYgtGh2gTKFWYRjEIE4g?= =?us-ascii?q?VOFKIZDQYIAgTgcglY+h1c0giwEgkiDBZNiiUGcNoMAgymBOJcUAxYJkyOPY?= =?us-ascii?q?bIYg3ECBAYFAhaBbCSBVzMaCBsVZQGCPz0SGQ2OWI4TQANnAgYBCQEBAwmMF?= =?us-ascii?q?QEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,383,1602547200"; d="asc'?scan'208,217";a="30599198" 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; 28 Jan 2021 20:50:25 +0000 Received: from [10.61.223.99] ([10.61.223.99]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 10SKoOxJ026421 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 28 Jan 2021 20:50:24 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F049C78E-0B6F-4DC3-A24E-686846E92322"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Thu, 28 Jan 2021 21:50:23 +0100 In-Reply-To: <2569EC66-2ABC-495E-8F86-0F82B3009189@kuehlewind.net> Cc: Brian E Carpenter , rfced-future@iab.org, Eric Rescorla , Christian Huitema To: Mirja Kuehlewind References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <2569EC66-2ABC-495E-8F86-0F82B3009189@kuehlewind.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.223.99, [10.61.223.99] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Jan 2021 20:50:32 -0000 --Apple-Mail=_F049C78E-0B6F-4DC3-A24E-686846E92322 Content-Type: multipart/alternative; boundary="Apple-Mail=_15FA835A-86BF-428A-929A-C4E9D221D2E6" --Apple-Mail=_15FA835A-86BF-428A-929A-C4E9D221D2E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mirja On this point: >=20 > There is the other point about stream manager that I wanted to make. I = think stream managers actually represent their part of the community. As = such I don=E2=80=99t see it as the stream managers role to decide = (except for small points that are straight forward) but to check for = consensus in their community. Each stream has an own process for that = and I think we should make use of those established processes. What would you envision the IETF stream representative decision process = being? Eliot --Apple-Mail=_15FA835A-86BF-428A-929A-C4E9D221D2E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mirja

On this = point:


There is the = other point about stream manager that I wanted to make. I think stream = managers actually represent their part of the community. As such I = don=E2=80=99t see it as the stream managers role to decide (except for = small points that are straight forward) but to check for consensus in = their community. Each stream has an own process for that and I think we = should make use of those established processes.

What would you = envision the IETF stream representative decision process = being?

Eliot
= --Apple-Mail=_15FA835A-86BF-428A-929A-C4E9D221D2E6-- --Apple-Mail=_F049C78E-0B6F-4DC3-A24E-686846E92322 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmATI48ACgkQh7ZrRtnS ejMHXQgAoAJHM47TzEs01G6/JbSI0YLJ/fDKT9PSePS4pRADNaM8ltO3uuDuqmNN N5CgMXoWQMXMuwS1L31n0zPTOVR69l7PE9//1/C5nYo6ZvCU05eHpRGpqRFadjfJ EyDCHuU8SUt0zT5SKCtXqLdYl6ZWnHcXQdFhZ6SfwxNnMp8qDOb2Etqsv8968hYd FdiiNiTQgsQEvYn3GbILeUiN5qjcfGc3B2DtU+3VsYWXdEexYt69FpgjUY9sBGPK XCOZc8+ZkGyM8Y8xnJh/Am4c448Ft1pf7uE9fJAAdtsZXiTVLSkNt4bP2dDT5Mcc rOoDh0gMvJqy/fjd6ErcjZeYYevDRQ== =GSIQ -----END PGP SIGNATURE----- --Apple-Mail=_F049C78E-0B6F-4DC3-A24E-686846E92322-- From nobody Thu Jan 28 16:01:22 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2F2B3A1801 for ; Thu, 28 Jan 2021 16:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKtRwx7p4I05 for ; Thu, 28 Jan 2021 16:01:19 -0800 (PST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3B33A1800 for ; Thu, 28 Jan 2021 16:01:19 -0800 (PST) Received: by mail-pj1-x1034.google.com with SMTP id a20so4821974pjs.1 for ; Thu, 28 Jan 2021 16:01:19 -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=+VZbkiBvt7UqAn4q5cdhIZsCKY8drMo22cvWj9NlfB0=; b=nE+dvkMc9P31zI9KqoGbwpvafhQ9CK8AZJ6hFoXrpRICvEfFi58Vh4pyrgLWT0H4ci K56p7r72kZh88z1CLVLsk/Iz5FvJzjhyQAeOZba6GMwXhQfQ5v1dJD3WJbTJ6e9aO3ow uCJegT9TVHalXVMzTNeODeWOdJpZXYyqjnA5JuRr8QdGOWcnj3wymUv3GL/rJpjcTb5D Xoyu2SGmy+OA2K1wXHvf2lDK7tPFIWGWLEfWRm+0Xh98WRhHUJPbQ82EyWuDqOrERrkn WlBOpuKGxj5vSyKYWMowTZJJU1AKj3yDGY4i8ItA/JNnm9xKhJbTXS+ttOkmYdPqL9s7 GpRg== 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=+VZbkiBvt7UqAn4q5cdhIZsCKY8drMo22cvWj9NlfB0=; b=m+ZrmUaI21SWe80KLMp/DPg+ZRXoBC0GQx5MbfBHBS+pkHrQGA6/Fcscer3SgmrjSf cR/9ZdDI9fopApXMfmzV5Pscu1fI8SItBdq280Ps43o+qUrKM5dibIfb8OZ0L8KFePs6 bVsVxK8gkVWx8NuTn0fAw25xoV0TGV24mqScLKpO/8/lRR7vZHH9uarxB0G6ybd97qhR PlzbMKsfRUKRyuK8wxBHJRG5Sv8xmIEhDo845i7xSucnp2ug37OLvprhpdpoOw81CEe/ 3RWVndDfO1WEJmazI5yRr02WyQ2k1C2gHefQYNMZQNxVh2e5iQXsgfaZQXuoS72cDIp/ MJyw== X-Gm-Message-State: AOAM532QZW3ngcXSkda+k+PPvSdtb7e4HVWCTGdWp3zwproYF/UzX+pK w3+mYNlA6iZ+Y3fmvMxd2PULFyPtcp5Iow== X-Google-Smtp-Source: ABdhPJw21a8qxePIrlZlN4WIQ9iw7bCXiXfN3kQS1Zcx7SwXyJB48hNACvx7E/ZjUUr+gXbs8AxuYw== X-Received: by 2002:a17:902:854b:b029:db:c725:edcd with SMTP id d11-20020a170902854bb02900dbc725edcdmr1567132plo.64.1611878477039; Thu, 28 Jan 2021 16:01:17 -0800 (PST) Received: from [192.168.1.117] (125-236-230-222.adsl.xtra.co.nz. [125.236.230.222]) by smtp.gmail.com with ESMTPSA id 21sm6374672pfh.56.2021.01.28.16.01.13 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jan 2021 16:01:16 -0800 (PST) To: Eric Rescorla Cc: Martin Thomson , "Joel M. Halpern" , rfced-future@iab.org References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> From: Brian E Carpenter Message-ID: <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> Date: Fri, 29 Jan 2021 13:01:10 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 00:01:21 -0000 On 29-Jan-21 02:51, Eric Rescorla wrote: >=20 >=20 > On Wed, Jan 27, 2021 at 6:19 PM Brian E Carpenter > wrote: >=20 > On 28-Jan-21 13:04, Martin Thomson wrote: > > On Thu, Jan 28, 2021, at 10:46, Joel M. Halpern wrote: > >> The big difference is that in normal IETF working groups, the pe= ople > >> making decision are themselves experts in the field.=C2=A0 That'= s why people > >> trust us to make these decisions. > > > > This oversimplifies things.=C2=A0 As a regular participant in dis= cussions, I often find that the level of expertise in various subject are= as varies greatly.=C2=A0 When everything is working (which is most of the= time) I am able to offer my particular expertise and rely on others for = theirs.=C2=A0 We each defer to others in areas where we recognize our own= shortcomings. > > > > You seem to be suggesting that participants in this process won't= do the same.=C2=A0 I can't accept that argument.=C2=A0 I appreciate that= we might need systems in place to cover the difficulty in communicating = across disciplinary lines, but that does not - for me - extend to reifica= tion of the advisory role. > The suggestion is not to give the RSA/E a pocket veto by putting th= em in > the approval group. It's to make sure the approval group will hear = directly > from the expert, in the case (hopefully rare) where the common sens= e and/or > groupthink of the WG has led to a proposal that the publishing expe= rt > thinks is seriously wrong.=20 >=20 >=20 > Well, the structures I proposed were intended to ensure this. Presumabl= y if the RSA/E believes something is seriously wrong, then that will be r= aised to the attention of the committee or the IAB. Perhaps it would make= sense to have them to prepare a review which is provided to the committe= e and the IAB. > =C2=A0 >=20 > We give the security ADs a "DISCUSS" button; > why wouldn't we give the technical publishing expert one too? >=20 >=20 > The security ADs are selected via our quasi-democratic nomcom process [= 0].This role is not. I don't see that as relevant. If we select this person on the grounds tha= t they know more about technical publishing than the rest of us do, that = seems like exactly what we need as a finger on the DISCUSS button. Brian >=20 > -Ekr >=20 > [0] Yes, I am aware that not all the stream managers are selected via t= his process, but they are the representatives of their streams equities i= n this case. From nobody Thu Jan 28 16:08:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2A063A1804 for ; Thu, 28 Jan 2021 16:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8DPv4gJabm0 for ; Thu, 28 Jan 2021 16:08:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8703A1801 for ; Thu, 28 Jan 2021 16:08:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2958BBE2E; Fri, 29 Jan 2021 00:08:49 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IR_2bLMoboeK; Fri, 29 Jan 2021 00:08:47 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5E62BBE2C; Fri, 29 Jan 2021 00:08:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1611878927; bh=l6Uv7xpVss+sT23zVbqxwcnnLtIaBKjtuTZwrork+yw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hp0hdkjEG6cYmbOMPPBKywn+Ib46+DECUXGIaMr+I1BJe5fTtwYvgpTgZxtIV3sny 7MFk0Zj/pVrOumNShBm3KjAM0yXqW4v2LVqTOa4JoLQs3njNV0XVoc4bJ1qJunK1MQ jHvf5/svkOhIwCAC+LkobPsghsyKsMnll85FCAyk= To: Brian E Carpenter , Eric Rescorla Cc: rfced-future@iab.org, "Joel M. Halpern" , Martin Thomson References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> From: Stephen Farrell Message-ID: <18b7fb60-b029-b9f6-5438-f0c4c47f5081@cs.tcd.ie> Date: Fri, 29 Jan 2021 00:08:46 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uuUpr0G5tClAopOfDu6PyuJmwEFhzv2NG" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 00:08:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uuUpr0G5tClAopOfDu6PyuJmwEFhzv2NG Content-Type: multipart/mixed; boundary="vTLZMcL5qPQQV81Ghd6vIg6uXEzEcM84j"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , Eric Rescorla Cc: rfced-future@iab.org, "Joel M. Halpern" , Martin Thomson Message-ID: <18b7fb60-b029-b9f6-5438-f0c4c47f5081@cs.tcd.ie> Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> In-Reply-To: <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> --vTLZMcL5qPQQV81Ghd6vIg6uXEzEcM84j Content-Type: multipart/mixed; boundary="------------7C6AFAEFED977EACE5E388B6" Content-Language: en-US This is a multi-part message in MIME format. --------------7C6AFAEFED977EACE5E388B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 29/01/2021 00:01, Brian E Carpenter wrote: > If we select this person on the grounds that they know more about > technical publishing than the rest of us do, that seems like exactly > what we need as a finger on the DISCUSS button. FWIW, I'm very sympathetic to that. Though at the same time I don't think we need to too closely follow the IETF WG setup quite so much here when it comes to final approval of changes to the status quo. I've a related question. Apologies if I missed that being already resolved, but does the RSE(A) also get to initiate new activities off their own bat, or only with approval of someone(s) else? Ta, S. --------------7C6AFAEFED977EACE5E388B6 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------7C6AFAEFED977EACE5E388B6-- --vTLZMcL5qPQQV81Ghd6vIg6uXEzEcM84j-- --uuUpr0G5tClAopOfDu6PyuJmwEFhzv2NG Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmATUg4FAwAAAAAACgkQWrL68XsXK+r1 NBAA0A0fq6nnuXcYIhQXOBiA9KchgsuPAd5IqweseKK62P3hQnH8XoFUWSkR4pkvziIJcuW1aUYZ /V46cn1G7ISPkJfrE5b7Muo1TIbYKmcgcjVP6n864zegIrnHL1kkGXX1wdYiKJA6SDxcFbWluXew vpXj2/FFtISWoy7aJd82XbZs82s2YwLemdAwBLbgkNLdPeuXWLzSG8vgMpqsqKR/GuCAIA5cqmDx nYQG7cOlAY3jqIrKwZ4FOuY8EL6p59hlCAgVX2YZEc+R7otkBdcHdu1n0+7dnyDEMD9Ptx+/4gpU zCRkh/OcM1Cb0PEX+aXm9kIjGjty3EIlDRCWAkRw/CqpgXCYCiHXlBrDL3LzcI+ClTu90aNRSDqe CrOZ9iY0y2PLPhvcN2++bOdystVSZzLsOd66OoJqMmFx3Zp9Dd7Z+9e9HEsLXfKUnOTJGgb8n2Zm uM/WIUI8abM5vQyZGKB10EMiOU2GGXRdgV+wAR6/9lE9w7xIobJ01WIR31AGqulNTLihvVHIYEvd cyYSLkSa1Pv7CpDqlGh4Us/ZRWzphB5mPpa+XHlwdrsNU+j872lSbtKtyKoMzMH8H9hd+NzPAeOJ DFGmMM97MT4Z7GafUEnKfzCgEcCaL45akeXLJTbWZ/0VNWP6a3Zdc6C1W9Qk1t+Wm+htQcclUkwQ CWQ= =OCoR -----END PGP SIGNATURE----- --uuUpr0G5tClAopOfDu6PyuJmwEFhzv2NG-- From nobody Thu Jan 28 16:18:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF12C3A00C9 for ; Thu, 28 Jan 2021 16:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ajI9VOFn0jKk for ; Thu, 28 Jan 2021 16:18:48 -0800 (PST) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C90563A00F7 for ; Thu, 28 Jan 2021 16:18:35 -0800 (PST) Received: by mail-lj1-x232.google.com with SMTP id v15so5542831ljk.13 for ; Thu, 28 Jan 2021 16:18:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cxby/SM7qrIJEYEVS+le0fNmpEvii2Zn/WCfdFkdLUI=; b=s/SB/XZsz9lSUy3EtmAwgPMSkrfKzLHP12Gz/d9IVIQs7Hja/TLd+m9VjidYzX9tOv Soyozk3xsWBcF02wiMSI6C4tqzUei9eFWNpwz+ACmsuYHnln29t4SM43l+8ELluYRcjN wNFnBYVDN6hqCfCk/SgyhMmrkUDY2jvEbRwUPJyS+hpwSWa9kiJA5MyeB2W/5osGa1SE CtFmegNA4eWvId4nqm9UM3OzHeg9t2L6HRcPRFWwbSXasA6svXfl8i7J/kuwIduC36wD F2m/lfn+MwNW0Hu2fUlcPy7XSapILtWHVqpRAar3bPhaWO7NLrnAb2pvwZWml5s0E6e4 LDcw== 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=cxby/SM7qrIJEYEVS+le0fNmpEvii2Zn/WCfdFkdLUI=; b=Byhku1qRM/fLryPLBtmaaE91ugoY2xwhu7IpsYWqu7Hawu5ylRsmCXk80fFmyaEr/u 7u+Uv66jtgTTdDuIRrRr55b8z3vKnZ6OVQV9L8LlAm90BmZP5QZoG8KJLe/PVEDHdJ8O eks3xHfHbS59s9SxxJxvOFQokXRbpM6kvQDb7+97eWwfeZC4qt3fvZ4KIxv2/HVXEgOn YGRQaERt5EuB0efQSo45fxeIGilHz/Y7uHc8kgoM/emHyVCMBPERVBHCvw6phk0GqT3h 2oQsQcNSqcyefAdssfvDEUuWLu/5H2M9u52lkhoNChg9+45ZaCbXxbIpluuXTJYzzois YKMw== X-Gm-Message-State: AOAM531NcM84teMhEK4ux5uQOZDOWSlyTy2nfhdf/KToMr1PqBR6yROW p9pEHKp/m7352carb1qwQYhHY5GRf03tjXW6Bai93A== X-Google-Smtp-Source: ABdhPJzcDhVKSvX2ow4cDzIQuAfmL2L/F0KhaTTS4SU8i8Bf5K1A3pu+AmXpDInGfVDsDG+r8sizdA0rTgEdbUiVyyE= X-Received: by 2002:a2e:9d96:: with SMTP id c22mr991981ljj.109.1611879514005; Thu, 28 Jan 2021 16:18:34 -0800 (PST) MIME-Version: 1.0 References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> In-Reply-To: <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> From: Eric Rescorla Date: Thu, 28 Jan 2021 16:17:57 -0800 Message-ID: To: Brian E Carpenter Cc: Martin Thomson , "Joel M. Halpern" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000da796305b9fef1f2" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 00:18:50 -0000 --000000000000da796305b9fef1f2 Content-Type: text/plain; charset="UTF-8" On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 29-Jan-21 02:51, Eric Rescorla wrote: > > > > > > On Wed, Jan 27, 2021 at 6:19 PM Brian E Carpenter < > brian.e.carpenter@gmail.com > wrote: > > > > On 28-Jan-21 13:04, Martin Thomson wrote: > > > On Thu, Jan 28, 2021, at 10:46, Joel M. Halpern wrote: > > >> The big difference is that in normal IETF working groups, the > people > > >> making decision are themselves experts in the field. That's why > people > > >> trust us to make these decisions. > > > > > > This oversimplifies things. As a regular participant in > discussions, I often find that the level of expertise in various subject > areas varies greatly. When everything is working (which is most of the > time) I am able to offer my particular expertise and rely on others for > theirs. We each defer to others in areas where we recognize our own > shortcomings. > > > > > > You seem to be suggesting that participants in this process won't > do the same. I can't accept that argument. I appreciate that we might > need systems in place to cover the difficulty in communicating across > disciplinary lines, but that does not - for me - extend to reification of > the advisory role. > > The suggestion is not to give the RSA/E a pocket veto by putting > them in > > the approval group. It's to make sure the approval group will hear > directly > > from the expert, in the case (hopefully rare) where the common sense > and/or > > groupthink of the WG has led to a proposal that the publishing expert > > thinks is seriously wrong. > > > > > > Well, the structures I proposed were intended to ensure this. Presumably > if the RSA/E believes something is seriously wrong, then that will be > raised to the attention of the committee or the IAB. Perhaps it would make > sense to have them to prepare a review which is provided to the committee > and the IAB. > > > > > > We give the security ADs a "DISCUSS" button; > > why wouldn't we give the technical publishing expert one too? > > > > > > The security ADs are selected via our quasi-democratic nomcom process > [0].This role is not. > > I don't see that as relevant. I guess we'll have to disagree on that point. I see it as a matter of democratic legitimacy. If we select this person on the grounds that they know more about technical > publishing than the rest of us do, that seems like exactly what we need as > a finger on the DISCUSS button. > We engage a lawyer who is also an expert on topics that we are not, and which are rather more consequential if we screw them up, and yet we don't give them a veto. -Ekr Brian > > > > > -Ekr > > > > [0] Yes, I am aware that not all the stream managers are selected via > this process, but they are the representatives of their streams equities in > this case. > > --000000000000da796305b9fef1f2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 28, 2021 at 4:01 PM Brian= E Carpenter <brian.e.carpenter@gmail.com> wrote:
On 29-Jan-21 02:51, Eric Rescorla wrote:<= br> >
>
> On Wed, Jan 27, 2021 at 6:19 PM Brian E Carpenter <brian.e.carpenter@gmail.co= m <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0On 28-Jan-21 13:04, Martin Thomson wrote:
>=C2=A0 =C2=A0 =C2=A0> On Thu, Jan 28, 2021, at 10:46, Joel M. Halper= n wrote:
>=C2=A0 =C2=A0 =C2=A0>> The big difference is that in normal IETF = working groups, the people
>=C2=A0 =C2=A0 =C2=A0>> making decision are themselves experts in = the field.=C2=A0 That's why people
>=C2=A0 =C2=A0 =C2=A0>> trust us to make these decisions.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> This oversimplifies things.=C2=A0 As a regular= participant in discussions, I often find that the level of expertise in va= rious subject areas varies greatly.=C2=A0 When everything is working (which= is most of the time) I am able to offer my particular expertise and rely o= n others for theirs.=C2=A0 We each defer to others in areas where we recogn= ize our own shortcomings.
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> You seem to be suggesting that participants in= this process won't do the same.=C2=A0 I can't accept that argument= .=C2=A0 I appreciate that we might need systems in place to cover the diffi= culty in communicating across disciplinary lines, but that does not - for m= e - extend to reification of the advisory role.
>=C2=A0 =C2=A0 =C2=A0The suggestion is not to give the RSA/E a pocket ve= to by putting them in
>=C2=A0 =C2=A0 =C2=A0the approval group. It's to make sure the appro= val group will hear directly
>=C2=A0 =C2=A0 =C2=A0from the expert, in the case (hopefully rare) where= the common sense and/or
>=C2=A0 =C2=A0 =C2=A0groupthink of the WG has led to a proposal that the= publishing expert
>=C2=A0 =C2=A0 =C2=A0thinks is seriously wrong.
>
>
> Well, the structures I proposed were intended to ensure this. Presumab= ly if the RSA/E believes something is seriously wrong, then that will be ra= ised to the attention of the committee or the IAB. Perhaps it would make se= nse to have them to prepare a review which is provided to the committee and= the IAB.
> =C2=A0
>
>=C2=A0 =C2=A0 =C2=A0We give the security ADs a "DISCUSS" butt= on;
>=C2=A0 =C2=A0 =C2=A0why wouldn't we give the technical publishing e= xpert one too?
>
>
> The security ADs are selected via our quasi-democratic nomcom process = [0].This role is not.

I don't see that as relevant.

I guess = we'll have to disagree on that point. I see it as a matter of democrati= c legitimacy.


If we select this person on the grounds that th= ey know more about technical publishing than the rest of us do, that seems = like exactly what we need as a finger on the DISCUSS button.

We engage a lawyer who is also an expert on topics th= at we are not, and which are rather more consequential if we screw them up,= and yet we don't give them a veto.

-Ekr<= /div>

=C2=A0 =C2=A0Brian

>
> -Ekr
>
> [0] Yes, I am aware that not all the stream managers are selected via = this process, but they are the representatives of their streams equities in= this case.

--000000000000da796305b9fef1f2-- From nobody Thu Jan 28 18:44: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 D34553A03EB for ; Thu, 28 Jan 2021 18:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CxN4HthV1PDC for ; Thu, 28 Jan 2021 18:44:04 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-eopbgr1400093.outbound.protection.outlook.com [40.107.140.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 C9E1F3A02BC for ; Thu, 28 Jan 2021 18:44:03 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VzcZjSG8/Ny2S5lE8VL8q/Z2M/BY52a5uEFkjlsUP1beowTzW46TGKgYBv62d15IKKnjBjCr83+d2ZOmlFvBWF4UmmwZbAUGwv3q0yhMTNuTAgvAn4PvfNe+TdpsY2EybkCJkG1MGYlaTpMopT9FTpkwBghRJUAxUV2rhKuvV+XfXRHhJlgyf60XHVFu1yT8n262xjObD+/Q4b3EiknZG4Pai3UVOwivPmeh84t4ry+9TJsqASJ8Ttoetd+oimQKzsxI//y8TGUn2/afAqXScX7JqpkxnTGf25Mp9UqqpBblilyI1YZPL443sTeWa8lJgF8etp9pXM6zmRwHSom0VQ== 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=2vy5lRnEcgdf7pOdrVrmRokb1v8GKwZXBNKT/HTI1tQ=; b=Kh/WcCJWllOInc7+/KFlkHZCaQ+V9S2up+cf9L7zsXsgUnM0njv5wpqnq4BArvPDDRwI1EaY46r6EhQH8UKUimsGrGTpJtHW6tUvKHu+FdV/NOrljfy6ZqlGk81dFl4eW0CvXA2XTrF0oTx7S1pa8zWEGljaF6RHRiYiBj6paCfuX/GjJi84QZN22gKsilUwB7JyMzVkorlie4hKLlCKpdD2JjESs81dEdN4+5KDaL7CB1TCjxO+g6hTaK70l4f0HjKAAnp4Vve1SvK4MDa1Tgl6+Hu/Vcqof+yH4zIWJIsJ5qqgrNHyLL9VFtoaVTeM35p57D2jJWHRzEP6R+a1Ng== 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=2vy5lRnEcgdf7pOdrVrmRokb1v8GKwZXBNKT/HTI1tQ=; b=J3GKRjOMrE9+hwDSBlgWsutBnrpfzq/eZ8grBEceW2i3B9Q3tldFTHUMIFQsDwOlUIjdU2aiRtXwIBItm7yZ8VWUXtW6MRkPyUneGlsNdREcMilca7SJieWKZhI3d4FesNN6MQyPABC7e+TrHHCRF36Owdohb7RPxQ7PowjNx+Q= Authentication-Results: lowentropy.net; dkim=none (message not signed) header.d=none;lowentropy.net; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TYAPR01MB3599.jpnprd01.prod.outlook.com (2603:1096:404:c4::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.13; Fri, 29 Jan 2021 02:43:56 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::946a:9db2:a4b5:6b1f%7]) with mapi id 15.20.3805.016; Fri, 29 Jan 2021 02:43:56 +0000 To: Eric Rescorla , Brian E Carpenter Cc: rfced-future@iab.org, "Joel M. Halpern" , Martin Thomson References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <75b44a43-564b-e097-00ac-db57fea149f8@it.aoyama.ac.jp> Date: Fri, 29 Jan 2021 11:43:54 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [223.217.186.153] X-ClientProxiedBy: TY1PR01CA0154.jpnprd01.prod.outlook.com (2603:1096:402:1::30) 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.6] (223.217.186.153) by TY1PR01CA0154.jpnprd01.prod.outlook.com (2603:1096:402:1::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3805.16 via Frontend Transport; Fri, 29 Jan 2021 02:43:55 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 2b275f36-9602-4198-ccb8-08d8c3ffb8c4 X-MS-TrafficTypeDiagnostic: TYAPR01MB3599: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: B8sFhJvzZ/4COXjCHDJD4Je/pqoK/LyqJRop9a3ENOVJGcEKXwyibsakMVMGG1V3IizeVW/hw5Fl1JoXYeTFGny3k1iDqvNpfgL+dJPAQy+mBG9MyMRwl85DlTotg4erpuAsS1xLUohlI0Vg69W5V9z6Z5JDro85JfJat9tG/3RKbqC5/e1MdszaXwujY/HtRIuoRDswYUETia0W/NAcCPnK6kmN/84eavaFSkTiEJFOCNcjXqoL8TKsrswiamI5gYk//X0wy/YwaFLpdUjsiU570LXC8hDdSlkbY0DCVkqD5EzELhyzEqWlVNY1YAY8lQo80GbT3vVs8NMFbW/7iMiWGEjQmPVlI7KYmrstBaKGfJ0VGOl+vOkLymQJcYG2rV8VyPSGDntIAPLjmx6UEoG5k5P1sP0HFqePr29LcOgYy0dvwaSZQBDZHMgsEYBUSxxZqPiHZ6u/ktUu6Si07ZVOv4F5tMrlwelLmJ0HpLHulRGi4D9s/BN1vxOkWql44JliA3awAsZdzHb9YH/iqdB0AS6ZU6nLoGy81EVI9LHpMefD88gi5AMDcf/btrYlzgkWbLvAOyjstWopTQFP0q05fEnx9HJ2TlQaUuksuhg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(136003)(396003)(39840400004)(376002)(346002)(6486002)(66556008)(16576012)(186003)(31686004)(26005)(956004)(8936002)(2906002)(16526019)(110136005)(786003)(86362001)(4326008)(2616005)(316002)(54906003)(478600001)(36916002)(52116002)(5660300002)(53546011)(66946007)(66476007)(8676002)(31696002)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?T3g3U1lWQTRWWUpXeXRJUytCUVpVTUxvUlRyNlVKc2czcE9wd0N6RlJtSlJN?= =?utf-8?B?cXZMb1NDa0d3SnB0dlpsZjkxdndkVlZBcDh1MjhQZzlUM09IaXBWLzlwdTVD?= =?utf-8?B?VjNpUE9hRjB2dVo0MWlPWVJxZ1R3VWJXdHkvZEI5dERLMmFQN2R2UmVHb0VB?= =?utf-8?B?TzRPdWIxdzdQYmhLYmZaa0F3TEc1Y3NaanVZZmZtdUVkaE9Ka0l4YmdDZkds?= =?utf-8?B?c0tJNm9YSGxWVzFtUU4yVmtyYnBEbU5RYy9VUVJ4TG40RFA2NllwUURheVVK?= =?utf-8?B?UmdncTJBdENZbzlFb2tZMGh0M3ZyK29LbmhnaGdBZFYxc0NXTXN1M0hFN3FP?= =?utf-8?B?cXVnUG5LOS83ZWhIRVRibjRaUmxwK3RJQ2puYmdPbXBBSzBiazBQWkVOK2R3?= =?utf-8?B?SjU3dDl5Sm4xZkNRemtWUDVjKzYvM1lOMTZyUXBPSTVncUVLWkFWaktwOC9Z?= =?utf-8?B?L0x5ektrZGlEMGcvaldlRlhtUVQyazFLalpDWmppeXdnZU5UQ1pBRktxR3Zo?= =?utf-8?B?T2d0eDJLNXdnTW81NHRPS3BNRkJmTUt5R2xHUXVReGZUWG1MM3dINEQrdjgr?= =?utf-8?B?WUR5azZPQ2FIZDRuaVhXc1RvQnNDdUpDSjN4czlXNVpNMEhQV2FvRnlvb3VU?= =?utf-8?B?V3A5RE84NTltZ2hjNGttTTNrYWlxQmU3VzU5MUwrYlZnWWEwS05wRXFOYzJZ?= =?utf-8?B?Z2hadWtZNnJaNXBYZ3lpUHpXTVZveXNWejJ3Tko1UEJJOWRyLzFSQlo0QS9P?= =?utf-8?B?dTIxa2NXK3Z2V2dRdTBtRTNrV0lYRGlhTEZEZXVwZjFUTFNNaXFaMEdYWkpa?= =?utf-8?B?cklMTWZqNEhDYUx3T2NydHRkbGJHNng5V2w0MTdJMkdWcll4VkJFenVyRFEv?= =?utf-8?B?ekFQRlVLRlRVRCtmV3RhNDVlTUExNDRlVGQzRnBYcThmOVBDY0p0REJpZStI?= =?utf-8?B?dVc3blNJU3hqT1dEU2xhaXVtci8yWTlEbTRwT3RzWlZVOVFDYkJMcERQaU14?= =?utf-8?B?RitDSFhpVnJub2lCR09wdm0zN0N4V0Yza21BUzFVOXRIZTBMMWJ2aUpZQVQ0?= =?utf-8?B?a3B0ZVU4VmUyQjBCTE1LdlhqSlI2YWJpV1BZd2RSSjNXUnk3bW9hZEl2bmZB?= =?utf-8?B?QS9maStVbnRDNzBWRUlkbkVvL1NtY0wrWVZMbjlYMTBhampCYXpFbExTSzFa?= =?utf-8?B?RDBOZVo0ZXJuUDhuZkNSeWNMei8wekpJVTNaQUJZUm9tYm9UaTFlTHE3TUFh?= =?utf-8?B?TGtsbEVRYmhpTEJiYlM0bmxGR1JrdDlCT2JMb1ZURTNwNlF3cGJGcnpweTdU?= =?utf-8?B?MFZLRDVqcjZ3M0tpTnpmVzdjN2xCYjVsUi85YTNyWmF0enNGYko4RzdUM1gx?= =?utf-8?B?ZDR0bUJodEo5R0t5Mm9VclJSN2plbTFFQWFoS1AwaHUzcmphY1MwZUJwdjdR?= =?utf-8?B?cEFVa1dZNy9QM1VVNktFUkVWckc0Y2tkWHVmZ3NnPT0=?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 2b275f36-9602-4198-ccb8-08d8c3ffb8c4 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 29 Jan 2021 02:43:55.9127 (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: dX5ORgxkVE3z1Dgc1hqRGe+TLqmYPS5I/n4qEyKVWxjlaIrxz6G8BLDOl2JgYrQZ30ioUqdJpNHO88WmbItz8g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TYAPR01MB3599 Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 02:44:06 -0000 On 29/01/2021 09:17, Eric Rescorla wrote: > On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >> If we select this person on the grounds that they know more about technical >> publishing than the rest of us do, that seems like exactly what we need as >> a finger on the DISCUSS button. >> > > We engage a lawyer who is also an expert on topics that we are not, and > which are rather more consequential if we screw them up, and yet we don't > give them a veto. The expertise of lawyers is more widely acknowledged by most participants because most participants are more accustomed to deal with lawyers, and know that some stuff has to be left to the lawyers. Also, lawyers are more used to attempts to screw them up, and know what to ignore, how to defend themselves, and so on. It's difficult to imagine that a lawyer would quit because they were treated as "just a contractor", because being treated as "just a contractor" wouldn't happen to the lawyer in the first place, or only to the extent that they would be used to be as part of their usual business. This seems to be quite different for an expert in technical publishing. They are not licensed, they don't have any arms to twist, and so on. Also, I think "give them a veto" may exaggerate a bit. A DISCUSS formally is a veto, but many DISCUSSes have been retracted without the raiser having gotten exactly what they originally proposed. Regards, Martin. From nobody Thu Jan 28 19: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 637F73A084A for ; Thu, 28 Jan 2021 19:11:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 Nj2ceK2DCe5a for ; Thu, 28 Jan 2021 19:11:14 -0800 (PST) Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E85B43A083E for ; Thu, 28 Jan 2021 19:11:13 -0800 (PST) Received: by mail-pg1-x52d.google.com with SMTP id g15so5682188pgu.9 for ; Thu, 28 Jan 2021 19:11:13 -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=P3eROkSUrhDUuFBvgNomEMvWxrre8JL7xMy8daJyw7Q=; b=awmhfJ5rD33/xr51FSWfAcVGAOloJzLcgtpbimM3/Y9YAwVBjzzmHVoiKNZyHrrkl9 zOkVWV5SkiGHaW1h7W9l0pPDcCODbqpdOeHjbwTcrjcBK2HAVAdAwWLXPM961QrmFoGN eVRxUJMdaWhHQEpCyngF0/No9wnxvxfDHK6aKok9KVleAhIwnH0mfjNkSbZ705gAycqU Kau0OR8kwLf/4NRFNJVfE8YXFUW7PbXwkQTrM7+jNSRs2zttRLlQ78uhlti3DOlmspC6 +69DQmWAAYBMnB9AshVPTf4lSNcZhkBJHy/7OHH9HS3dMcuXE1s5Fo+xBhd8ikNOwUAB 6lYw== 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=P3eROkSUrhDUuFBvgNomEMvWxrre8JL7xMy8daJyw7Q=; b=uHTKH6Kf9ltCYvgqtBhoiaeUVg0S+09j3MDn3Iut0zxj2AAlw5/MfHDYaV4J/k7zXi ig89gyUUjgSrgl/aARBRPNF2KRQzpEVqPJYhuGzu+uQ8jWtDa0o+mLZAGwCMNlsBicwk bygndR7uQGU5V1lyW0ry6ME+zY6LA3bgDQI1blIGxQMAcGMBhVY/5Amq6c5ZV4QAGmMQ zifz4S52zSeqDFgIoT8PDO4pPcVntUZO/4QdJR5nwtnTzMgI3GXsmy2XC+8dQ3WsNHn0 ThBzeSemg1zXcybKvXNkA3z5djr3CTq/38nIygS0GOlUxypSacr+PCDSUBNA7srWFhcg lPbg== X-Gm-Message-State: AOAM532ult26bl3NrHzutx1AX3na541EoX9VlaxfNahpBuRyw0QxuqKf 9D5jIttZw//1w0xhPlJFX7s= X-Google-Smtp-Source: ABdhPJwU4dheF29ZofGY79O8aGTdb7iQjPoIWpgLnlGr0gdXP6G+4Q3TAmY83Umu0JiOLursqxaZ/A== X-Received: by 2002:a63:5fcf:: with SMTP id t198mr2449488pgb.226.1611889873496; Thu, 28 Jan 2021 19:11:13 -0800 (PST) Received: from [192.168.1.117] (125-236-230-222.adsl.xtra.co.nz. [125.236.230.222]) by smtp.gmail.com with ESMTPSA id o13sm6748164pfg.124.2021.01.28.19.11.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 28 Jan 2021 19:11:12 -0800 (PST) To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Eric Rescorla Cc: rfced-future@iab.org, "Joel M. Halpern" , Martin Thomson References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> <75b44a43-564b-e097-00ac-db57fea149f8@it.aoyama.ac.jp> From: Brian E Carpenter Message-ID: Date: Fri, 29 Jan 2021 16:11:06 +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: <75b44a43-564b-e097-00ac-db57fea149f8@it.aoyama.ac.jp> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 03:11:15 -0000 A point below which may appear picky but is actually fundemental to this = disagreement: On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: > On 29/01/2021 09:17, Eric Rescorla wrote: >> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >=20 >>> If we select this person on the grounds that they know more about tec= hnical >>> publishing than the rest of us do, that seems like exactly what we ne= ed as >>> a finger on the DISCUSS button. >>> >> >> We engage a lawyer who is also an expert on topics that we are not, an= d >> which are rather more consequential if we screw them up, and yet we do= n't >> give them a veto. >=20 > The expertise of lawyers is more widely acknowledged by most=20 > participants because most participants are more accustomed to deal with= =20 > lawyers, and know that some stuff has to be left to the lawyers. Also, = > lawyers are more used to attempts to screw them up, and know what to=20 > ignore, how to defend themselves, and so on. It's difficult to imagine = > that a lawyer would quit because they were treated as "just a=20 > contractor", because being treated as "just a contractor" wouldn't=20 > happen to the lawyer in the first place, or only to the extent that the= y=20 > would be used to be as part of their usual business. >=20 > This seems to be quite different for an expert in technical publishing.= =20 > They are not licensed, they don't have any arms to twist, and so on. >=20 > Also, I think "give them a veto" may exaggerate a bit. A DISCUSS=20 > formally is a veto, but many DISCUSSes have been retracted without the = > raiser having gotten exactly what they originally proposed. No, a DISCUSS is *not* formally a veto. It is quite narrowly defined and there is a procedure for overriding a DISCUSS. See https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ Indeed, a similar definition and procedure would be appropriate in this case too.=20 Brian >=20 > Regards, Martin. >=20 From nobody Thu Jan 28 19:34: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 DD0E03A0977 for ; Thu, 28 Jan 2021 19:34:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l25LNpFitEv0 for ; Thu, 28 Jan 2021 19:34:47 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB283A0964 for ; Thu, 28 Jan 2021 19:34:47 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id v15so5933070ljk.13 for ; Thu, 28 Jan 2021 19:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MVSINOdr/fbSMjxl4ZrltGdDz/vY1rzYpkXinjGBoao=; b=d2Q5ec8deiUBHET6tseeu+QSzVK7KLEB8iChSmhnrFo0NZUfuPimn47biQivdlVkqD Qkfgbxb8mTP5Jzcq7CF1Zy/qrMrH30zZ6ccdGYclWsKQsKYUlvNRa0Bh0vfcKqu/Mo91 ZLSUAadqcyQZeEaYHw0PZvWfSQrPbh2SnMfY+JKmMQHLc/VU+zoECugx3o1Szq5VClwO CdISzf+S0/n0OK+W6bqrAzOxsmqoft9gUf5/RaAk94Xefv9Le79AijWzTqtFKAHQh311 ojxSgNGXwDLL9+rE4qMY3IgedYj4VmR7hwJ+wFPRKxEj0sbkhcS0N1pcEkAkDJXDH/c7 tZ9A== 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=MVSINOdr/fbSMjxl4ZrltGdDz/vY1rzYpkXinjGBoao=; b=HmSPAfsCp4bj3QkvAU3Mgyq6H2J21nRlwYQs5ZjXPbdSFCB4GpWLzZk+t8iNrWAFeR CpHMKBS4tr3tQO0sOJ0Mv+ZGVfY2BBkd+yZsLbqOiAeYcl39P17n0nE2aTVvv4LotgHG 71iv6PuHxqGJ1pGZEnf33zvf8WVkI59utrLp1T1lBytE53JVP5W5IgtLyMcDJj3VjMdL Lbs8KQLrXvEzyca/48CUqmspe6wWyKfmrP9WnHsgMsK+LgF9NEhOxj03HU0nUuA2wbZD gZ59t5c5qG6e1XpGuOWlSzMS+0fgh9uLJfqY2sOksf0X63O6iLGVPSjIpWrkW2Jkf0fy Fk0g== X-Gm-Message-State: AOAM531wZZOqaQ9iIJJpXlxPBzeWltc4wjfADsZ8U1lyV5uOsi0XFmbY N2LuSf/he+RKAx9LodYz800TZZfrgAxntIB2nn0x7g== X-Google-Smtp-Source: ABdhPJzaKyrbH+LM594ijDNOq65FteEtYGxJ7PzysCtMwyUqZ7iL3/YEEmnh2lFO/C/nj6lPJM2vA23p24fpiR/3I28= X-Received: by 2002:a2e:9b83:: with SMTP id z3mr1345286lji.82.1611891285234; Thu, 28 Jan 2021 19:34:45 -0800 (PST) MIME-Version: 1.0 References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> <75b44a43-564b-e097-00ac-db57fea149f8@it.aoyama.ac.jp> In-Reply-To: <75b44a43-564b-e097-00ac-db57fea149f8@it.aoyama.ac.jp> From: Eric Rescorla Date: Thu, 28 Jan 2021 19:34:08 -0800 Message-ID: To: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= Cc: Brian E Carpenter , rfced-future@iab.org, "Joel M. Halpern" , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000007926cd05ba01afe5" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 03:34:49 -0000 --0000000000007926cd05ba01afe5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 28, 2021 at 6:44 PM Martin J. D=C3=BCrst wrote: > On 29/01/2021 09:17, Eric Rescorla wrote: > > On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter > > >> If we select this person on the grounds that they know more about > technical > >> publishing than the rest of us do, that seems like exactly what we nee= d > as > >> a finger on the DISCUSS button. > >> > > > > We engage a lawyer who is also an expert on topics that we are not, and > > which are rather more consequential if we screw them up, and yet we don= 't > > give them a veto. > > The expertise of lawyers is more widely acknowledged by most > participants because most participants are more accustomed to deal with > lawyers, and know that some stuff has to be left to the lawyers. Also, > lawyers are more used to attempts to screw them up, Just to clarify my less than awesome writing "screw them up" in this refers to the topics, not the lawyers. -Ekr --0000000000007926cd05ba01afe5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 28, 2021 at 6:44 PM Marti= n J. D=C3=BCrst <duerst@it.aoy= ama.ac.jp> wrote:
On 29/01/2021 09:17, Eric Rescorla wrote:
> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter

>> If we select this person on the grounds that they know more about = technical
>> publishing than the rest of us do, that seems like exactly what we= need as
>> a finger on the DISCUSS button.
>>
>
> We engage a lawyer who is also an expert on topics that we are not, an= d
> which are rather more consequential if we screw them up, and yet we do= n't
> give them a veto.

The expertise of lawyers is more widely acknowledged by most
participants because most participants are more accustomed to deal with lawyers, and know that some stuff has to be left to the lawyers. Also,
lawyers are more used to attempts to screw them up,

Just to clarify my less than awesome writing "screw them up&q= uot; in this refers
to the topics, not the lawyers.

-Ekr

--0000000000007926cd05ba01afe5-- From nobody Thu Jan 28 19:36: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 AC78D3A0977 for ; Thu, 28 Jan 2021 19:36:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1i4djoJoDQYw for ; Thu, 28 Jan 2021 19:36:09 -0800 (PST) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 945EE3A096C for ; Thu, 28 Jan 2021 19:36:08 -0800 (PST) Received: by mail-lf1-x134.google.com with SMTP id b2so10587764lfq.0 for ; Thu, 28 Jan 2021 19:36:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cYwOUV+XLGOR6EWZFhZ2gC19fB/Hf9PMBFhEo/Tu8+U=; b=YD1cQ98T5kFiJKfCCeeWm2+qRTY1qsBtS5Xh7TGO88O+CmNyft+AjDd8WN2WQmYT+Q cZffvjG34aP8btw0jbLasbnUWx5teYARZlv7EA+BHKt0P9D2xjtVEHPx8sTRNYtGhGqn fMmhDi6vSWf9BYxCVVVP9zEO+J/VNb8DGTNjyZVhnEr8fvYe/K512CqOyMCNal5kzZz8 tAAnkP4SE/fPOaPmvdNcruPmYoNE333luDXrrEtpyJ8jTUHSWRRhVS9odCQvYzMGk/mC olKzEp/1XlRpbFY/fJR0EtUJmKMx7UNFyG7Jrndxp7xHypwKPy8zlfDZSRGwDF/WZVu/ P1PA== 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=cYwOUV+XLGOR6EWZFhZ2gC19fB/Hf9PMBFhEo/Tu8+U=; b=C1DPwn7vi509t4xzWdMKYtDou1NCPdpdl0uYgpH2djmWrroCvBYmXIbhHlR7rP6VNo WxAUgdyBjdAHbaG5HZv/GmOiJiCv+8mJyHUiiYTYsClca33dAWRyyumvZJ9Wy4VOSE7Z 3FPuNUWZ0v3qZn0rgsUnoub41fMxMyKepOq5BA7ZVTX2KpHREg/rydYcD6BIY6BOusib NkVtlaI8ogkPhnbNAi9kWeaCDdWAU1Z/oaHHA+tOrX062iyl8c/GhqeyRZGEtQVap9Ky MZELLtC9LVvKyN6bJgx9cZzbZegKFbfOOM6iRp90XrPxLUIvpNQevSQDMUQt0fGRyA7w REJg== X-Gm-Message-State: AOAM532xh3PvMOzS7/fJCYmkAEcaR1Akvo8wKOAusaXvF2z0+IgA3M87 PlKaedP1Ti9I/oZAmN2uOisXy9N87yl+N7gHXBGbPA== X-Google-Smtp-Source: ABdhPJyAYMrVTRBy8f1C5yR+ohc4sUJadn8ziCCXIa0Fxi5q83FHz/JU7HHLKw3DaP5vUocy39gI2BE3Z9A4/FGKexw= X-Received: by 2002:ac2:46c4:: with SMTP id p4mr1067454lfo.579.1611891366661; Thu, 28 Jan 2021 19:36:06 -0800 (PST) MIME-Version: 1.0 References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> <75b44a43-564b-e097-00ac-db57fea149f8@it.aoyama.ac.jp> In-Reply-To: From: Eric Rescorla Date: Thu, 28 Jan 2021 19:35:30 -0800 Message-ID: To: Brian E Carpenter Cc: =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , rfced-future@iab.org, "Joel M. Halpern" , Martin Thomson Content-Type: multipart/alternative; boundary="00000000000053a59b05ba01b4cf" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 03:36:11 -0000 --00000000000053a59b05ba01b4cf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jan 28, 2021 at 7:11 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > A point below which may appear picky but is actually fundemental to this > disagreement: > > On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: > > On 29/01/2021 09:17, Eric Rescorla wrote: > >> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter > > > >>> If we select this person on the grounds that they know more about > technical > >>> publishing than the rest of us do, that seems like exactly what we > need as > >>> a finger on the DISCUSS button. > >>> > >> > >> We engage a lawyer who is also an expert on topics that we are not, an= d > >> which are rather more consequential if we screw them up, and yet we > don't > >> give them a veto. > > > > The expertise of lawyers is more widely acknowledged by most > > participants because most participants are more accustomed to deal with > > lawyers, and know that some stuff has to be left to the lawyers. Also, > > lawyers are more used to attempts to screw them up, and know what to > > ignore, how to defend themselves, and so on. It's difficult to imagine > > that a lawyer would quit because they were treated as "just a > > contractor", because being treated as "just a contractor" wouldn't > > happen to the lawyer in the first place, or only to the extent that the= y > > would be used to be as part of their usual business. > > > > This seems to be quite different for an expert in technical publishing. > > They are not licensed, they don't have any arms to twist, and so on. > > > > Also, I think "give them a veto" may exaggerate a bit. A DISCUSS > > formally is a veto, but many DISCUSSes have been retracted without the > > raiser having gotten exactly what they originally proposed. > > No, a DISCUSS is *not* formally a veto. It is quite narrowly defined > and there is a procedure for overriding a DISCUSS. See > https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ > Indeed, a similar definition and procedure would be appropriate in > this case too. > Fair enough. To the best of my knowledge we don't give our lawyer a vote on, for instance, the LLC Board. -Ekr --00000000000053a59b05ba01b4cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Jan 28, 2021 at 7:11 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
A point below which may appear picky but is actually fundem= ental to this disagreement:

On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote:
> On 29/01/2021 09:17, Eric Rescorla wrote:
>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter
>
>>> If we select this person on the grounds that they know more ab= out technical
>>> publishing than the rest of us do, that seems like exactly wha= t we need as
>>> a finger on the DISCUSS button.
>>>
>>
>> We engage a lawyer who is also an expert on topics that we are not= , and
>> which are rather more consequential if we screw them up, and yet w= e don't
>> give them a veto.
>
> The expertise of lawyers is more widely acknowledged by most
> participants because most participants are more accustomed to deal wit= h
> lawyers, and know that some stuff has to be left to the lawyers. Also,=
> lawyers are more used to attempts to screw them up, and know what to <= br> > ignore, how to defend themselves, and so on. It's difficult to ima= gine
> that a lawyer would quit because they were treated as "just a > contractor", because being treated as "just a contractor&quo= t; wouldn't
> happen to the lawyer in the first place, or only to the extent that th= ey
> would be used to be as part of their usual business.
>
> This seems to be quite different for an expert in technical publishing= .
> They are not licensed, they don't have any arms to twist, and so o= n.
>
> Also, I think "give them a veto" may exaggerate a bit. A DIS= CUSS
> formally is a veto, but many DISCUSSes have been retracted without the=
> raiser having gotten exactly what they originally proposed.

No, a DISCUSS is *not* formally a veto. It is quite narrowly defined
and there is a procedure for overriding a DISCUSS. See
https://www.ietf.org/about/g= roups/iesg/statements/iesg-discuss-criteria/
Indeed, a similar definition and procedure would be appropriate in
this case too.

Fair enough. To the bes= t of my knowledge we don't give our lawyer
a vote on, for ins= tance, the LLC Board.

-Ekr

--00000000000053a59b05ba01b4cf-- From nobody Thu Jan 28 19:56:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77083A09E0 for ; Thu, 28 Jan 2021 19:56:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 J5wfAcuasGzW for ; Thu, 28 Jan 2021 19:56:17 -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 65C8B3A09C5 for ; Thu, 28 Jan 2021 19:56:17 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id k193so7607820qke.6 for ; Thu, 28 Jan 2021 19:56:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=2N2DevcTL1mcQa8LbeenScZ0ILCj4LwXOYz+fhw6pEA=; b=aSFYiAaT/9PVo3zQWptf1x+apyYMn28HkOmC9KZQEucrbAQxGUvFDq+miXiMTLQJjs AhbrtiLYWjzFQW7kJ3WG24lguIAv/tJ+EzWhmp1YRX6kglIFSdCyBI7/1OoipQ9cyy/b PnAyuRXpON/ADor/8zcrMCFbrLJS6nXk8GTyx//7+1Ruoc3L8g1Mts0Nppf5uftyfJ4B LS+YHvStZS0p75TKcdPQatYynkQg1EDmlhHbq7S4ys6XudSQJPExecjqYPuGQW6lBqcE 8lA/ElNnXen4CE9Pgk5F5r5y5dFAl92zWFHMe7pqc+qE04FKbS1n+gXBjTC5cBRl56a1 i9Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=2N2DevcTL1mcQa8LbeenScZ0ILCj4LwXOYz+fhw6pEA=; b=i205ZYafiJjvEb7fBxtqMytY+mS7hJWokpo90Itpkb+VTbELf/cS9eHCAKNBLdtPPA TqRV+fID1hLG834MZNeHxhgzwT87GP8wq4HtlX9MwH/pMPZA+M9+yKf+kGzxGXUfpYGF m777vIbVqIqSlugyducig/j0FTDv2zKoK564fslI7kN/QjAc2/TBRcCKCm4iZld7prlv U5bT2GR0FUC74/J2yMZ4XyQg+WWEPXpFGxWbkJddh6hDY/wQuPHmUiT+3Y9w4hq6UJcH 2oEAUTVnFs1X2ioq0FrUYSEjg3lSa1xsYEjZvVvEFq/TbQoX062UBIpjWWmNujF170Lb tOWw== X-Gm-Message-State: AOAM532oWJBr+zS2FoPydgKLZVQ9fo5knG9R8+F/Ohl1WQ3vKO2RHR/b yaDNwzu8ogrLO6muWZAY7WVSKXNjKgsDJTfC X-Google-Smtp-Source: ABdhPJykXySBoLyS5O8o4sUrPLv0FXbDJZ1bzY4KaHCvx1VImE5vxmgOz+Qan8VLpXmiG9jbOihfrA== X-Received: by 2002:a37:902:: with SMTP id 2mr2437169qkj.178.1611892575827; Thu, 28 Jan 2021 19:56:15 -0800 (PST) Received: from [192.168.1.23] ([138.88.204.18]) by smtp.gmail.com with ESMTPSA id p188sm4166176qkf.89.2021.01.28.19.56.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 28 Jan 2021 19:56:14 -0800 (PST) To: rfced-future@iab.org References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> <75b44a43-564b-e097-00ac-db57fea149f8@it.aoyama.ac.jp> From: Michael StJohns Message-ID: Date: Thu, 28 Jan 2021 22:56:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------03BC38EB49AD1B09DADF515E" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 03:56:19 -0000 This is a multi-part message in MIME format. --------------03BC38EB49AD1B09DADF515E Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/28/2021 10:35 PM, Eric Rescorla wrote: > > > On Thu, Jan 28, 2021 at 7:11 PM Brian E Carpenter > > wrote: > Fair enough. To the best of my knowledge we don't give our lawyer > a vote on, for instance, the LLC Board. > > -Ekr > > Yet, by design, the LLC board includes people that have other skills than writing protocols or chairing WGs and one of the current members is a lawyer and does get a vote. Later, Mike --------------03BC38EB49AD1B09DADF515E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 1/28/2021 10:35 PM, Eric Rescorla wrote:


On Thu, Jan 28, 2021 at 7:11 PM Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Fair enough. To the best of my knowledge we don't give our lawyer
a vote on, for instance, the LLC Board.

-Ekr


Yet, by design, the LLC board includes people that have other skills than writing protocols or chairing WGs and one of the current members is a lawyer and does get a vote.

Later, Mike

--------------03BC38EB49AD1B09DADF515E-- From nobody Thu Jan 28 21:18:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D90843A0C2F for ; Thu, 28 Jan 2021 21:18:26 -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 wvxiJv0-AdyK for ; Thu, 28 Jan 2021 21:18:24 -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 8DDF63A0C2E for ; Thu, 28 Jan 2021 21:18:24 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1l5MAo-000HJi-Oy; Fri, 29 Jan 2021 00:18:22 -0500 Date: Fri, 29 Jan 2021 00:18:17 -0500 From: John C Klensin To: Eliot Lear cc: rfced-future@iab.org Message-ID: In-Reply-To: References: X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] Notes on documents affected by the changes we are discussing... (long, with exec summary) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 05:18:27 -0000 --On Tuesday, January 26, 2021 08:37 +0100 Eliot Lear wrote: > Thank you, John, for this comprehensive review. You > accomplished two tasks, both of which are important: > > Where we got hung up in our last interim meeting was > understanding precisely what it would mean to apply WG > procedures to this new WG that does not report into the IESG. > You discussed the ramifications of this. Thank you. I > believe the intent of the group (and people should be free to > disagree) is that we do a pass on BCP 25 that includes RFCs > 2418, 3934, 7776 (and 7437 by extension), and 8716, to see if > we can substitute roles of area directors for some other > people. I will add this to the issue tracker, but I wonder if > you would like to make an attempt at just that activity? I think this proves the adage that no good deed goes unpunished. I left most of the BCP 25 thread out of my previous discussion because, after a quick look, I concluded that little of it (other than the anti-harassment material) would be helpful. More complete discussion below but my quick summary after going through the documents again and more carefully is that IETF WGs may actually not be a good model for the body we are discussing (referred to as the "WG", in quotes, below) because of the rather complex set of structures that surround them. Perhaps IRTF RGs or the IAB itself might be better models. In principle, another possibility would be some of our various "teams" but, AFAIK, we have no consensus specification about what those are and how they work. References to the "previous document", "earlier note", or similar language below are to the first posting in this thread, https://mailarchive.ietf.org/arch/msg/rfced-future/URQPy34rGCWF5k-yU-xvXkTNY-I >... Executive Summary and Conclusion: Unlike the previous effort (the first in this thread), this did not prove to be a particularly helpful exercise and there is reason to believe that trying to adapt the IETF WG model may not be fruitful. -------- Discussion of specific documents... IETF Working Group Guidelines and Procedures (RFC 2818): Summary: This document is very specific to IETF WGs, especially WGs involved with developing specifications that are intended to become standards. It goes into great detail about the specifics of WG structure, how WGs are formed and charters are specified (including criteria that we arguably no longer use and provisions that we sometimes ignore although this document makes no provision for doing so), the role of BOFs, WG termination, and so on, none of which appear to be directly applicable to our needs. Parts of Section 3, "Working Group Operation" might be adapted to our needs, but even there, there are enough specific references to IETF management structures, issues, meeting arrangements, etc., to require significant editing. It may be worth noting in that context that RFC 2418 refers to RFC 2028 for a discussion of conflict of interest issues and there is no such discussion in 2028 (see lengthy discussion of that document in my earlier note) The document also discusses appeals and points to RFC 2026. Action required/Conclusion: If we need a document to describe how the new "WG" functions, a new document will need to be written. That document should be much shorter and complex than 2418 because the RFC Editor Function group (aka "WG") will presumably start with a charter written by this group; the new document will need, at most, text about how to amend and evolve it. It may be possible to appropriate and adapt some text from RFC 2418, but far less text and with more difficulty than I think we have been assuming. And we still need to sort out relationships to other bodies, appeals of decisions (if any), and so on. To respond to Eliot's question in particular, there does not appear to be any obvious and plausible way to replace the role of the Area Director (AD) with something/ someone else, both because the AD role is too entangled with other functions and roles in 2418 and because we give ADs (selected by the Nomcom specifically for the purpose of managing WGs) vast discretionary authority. The only way I can see to get to that type of relationship with the RFC Editor function would be to either create a very strong RSE, probably stronger than even those of us who advocate going in that direction believe to be desirable, or to define an RFT (RFC Series Tsar) and figure out how to get one selected. Updates to RFC 2418 Regarding the Management of IETF Mailing Lists (RFC 3934) Summary: Gives WG Chairs explicit responsibility for WG mailing lists including authority to temporarily suspend posting privileges. If also limits the ability of the Chair to suspend posting privileges to a maximum of 30 days at a time. Action required: If we are going to follow the WG model, we'd presumably need a new document in which most of this was duplicated or incorporated by reference, explicitly assigning those responsibilities. We would also need to review the 30 day limit and the point at which major Posting Rights actions would be required (see RFC 3683, below). Comment: Not entirely clear to me that having those responsibilities rest with the "WG" Chair would be a good idea, so we should at least discuss who to assign to one or both. A Practice for Revoking Posting Rights to IETF Mailing Lists (RFC 3683) Summary: Included here because RFC 3934 references it, as does the discussion of that document, above. Interestingly, it is written to apply to "IETF Mailing Lists" and it has never been clear whether an IESG Posting Rights action under its provisions would apply to the IAB mailing list (presumably including rfc-interest, the RFC Advisory Board list, IAB Program lists, and the IAB list itself), lists that are part of the ISE function, IRTF lists, LLC lists and anything else that is not a strictly IETF list that I've forgotten. Action required: Clarify whether an RFC 3683 posting rights action would apply to open lists associated with the RFC Editor Function (and/or the "WG" specifically) and/or whether there should be a mechanism for semi-permanently revoking Posting Rights for people posting to some of all lists associated with the RFC Editor Function. Increasing the Number of Area Directors in an IETF Area (RFC 7475) Summary: Not relevant IETF Anti-Harassment Procedures (RFC 7776, 8716) Discussed in previous (2021-01-25) note. IETF Administrative Support Activity 2.0: Consolidated Updates to IETF Administrative Terminology. (RFC 8717) Summary: This just makes the "IETF Executive Director" -> "Managing Director, IETF Secretariat" change. Action required: Probably none because the paragraph that is changed is IESG-specific. See RFC 2418 above. best, john From nobody Thu Jan 28 21:28: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 38D743A0C3B for ; Thu, 28 Jan 2021 21:28:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.279 X-Spam-Level: X-Spam-Status: No, score=-1.279 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, KHOP_HELO_FCRDNS=0.399, MIME_QP_LONG_LINE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EclZaprmBcVK for ; Thu, 28 Jan 2021 21:28:50 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D2C3A0C38 for ; Thu, 28 Jan 2021 21:28:50 -0800 (PST) Received: from [172.17.122.52] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 10T5Sjn7091722 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 28 Jan 2021 23:28:46 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1611898127; bh=Juo10tflxrwyKrQzUZZTjZH4u9N8QCjSmecFKvPwd0E=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=nTULdkJhP36L924Jtfq4LSzeDnt1gxlLEAY8xt4iMfcb/aLGcenPHfWDxkpvnKlKS IPMKGiyrcB/xd1zQda16WQJ3ZzekGh4wg8mes2aGUeTAPMHllA6GIc+xm2d1x5Ho65 nRibrS4rnaDELB55/5YA4Cd1uCl1kyFNvH4Se+Es= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.122.52] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Adam Roach Mime-Version: 1.0 (1.0) Date: Thu, 28 Jan 2021 23:28:39 -0600 Message-Id: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> References: Cc: =?utf-8?Q?"Martin_J._D=C3=BCrst"?= , Eric Rescorla , rfced-future@iab.org, "Joel M. Halpern" , Martin Thomson In-Reply-To: To: Brian E Carpenter X-Mailer: iPhone Mail (18C66) Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 05:28:53 -0000 > On Jan 28, 2021, at 21:11, Brian E Carpenter = wrote: >=20 > =EF=BB=BFA point below which may appear picky but is actually fundemental t= o this disagreement: >=20 >> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: >>> On 29/01/2021 09:17, Eric Rescorla wrote: >>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >>=20 >>>> If we select this person on the grounds that they know more about techn= ical >>>> publishing than the rest of us do, that seems like exactly what we need= as >>>> a finger on the DISCUSS button. >>>>=20 >>>=20 >>> We engage a lawyer who is also an expert on topics that we are not, and >>> which are rather more consequential if we screw them up, and yet we don'= t >>> give them a veto. >>=20 >> The expertise of lawyers is more widely acknowledged by most=20 >> participants because most participants are more accustomed to deal with=20= >> lawyers, and know that some stuff has to be left to the lawyers. Also,=20= >> lawyers are more used to attempts to screw them up, and know what to=20 >> ignore, how to defend themselves, and so on. It's difficult to imagine=20= >> that a lawyer would quit because they were treated as "just a=20 >> contractor", because being treated as "just a contractor" wouldn't=20 >> happen to the lawyer in the first place, or only to the extent that they=20= >> would be used to be as part of their usual business. >>=20 >> This seems to be quite different for an expert in technical publishing.=20= >> They are not licensed, they don't have any arms to twist, and so on. >>=20 >> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS=20 >> formally is a veto, but many DISCUSSes have been retracted without the=20= >> raiser having gotten exactly what they originally proposed. >=20 > No, a DISCUSS is *not* formally a veto. It is quite narrowly defined > and there is a procedure for overriding a DISCUSS. See > https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ > Indeed, a similar definition and procedure would be appropriate in > this case too. The most important aspect of a DISCUSS ballot is that, if an AD holding it i= s alone in their conviction, the position can be overridden =E2=80=94 on sub= stance, not process =E2=80=94 by the remaining ADs. I have grave concerns ab= out allowing someone to be alone in their disagreement (expert or not) witho= ut recourse. /a= From nobody Thu Jan 28 23:38:44 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C60C3A0D5C for ; Thu, 28 Jan 2021 23:38:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m21p9o-o6y15 for ; Thu, 28 Jan 2021 23:38:41 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4E0C3A0D58 for ; Thu, 28 Jan 2021 23:38:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9229; q=dns/txt; s=iport; t=1611905920; x=1613115520; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=KAIr9RHOAqVPIoJiHyNxWhxuOpqqrcD9Wfwwrd/oOkY=; b=RpEI3YJT3NAofSTwn/GJds0lT1ZZ3i+fcnf/h2KEIiVBB9TCUEG+7qwy +G2mY+n/73B5UtNoxiwduJ/g2vp3/q1aJts9kA3dOYxBwO+xPELyqfaiF YpjSWp8g8NMqAPoWfo8NUjoZMlIAl0YjJbv6JiR1O68t3eNFcncZVugSt 8=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CSAQBAuhNglxbLJq1iHgEBCxIMggQLgSOCVAEjEi+EQ?= =?us-ascii?q?IkEiFCHbow4hiGBfAQHAQEBCgMBAS8EAQGESgKBeSY2Bw4CAwEBAQMCAwEBA?= =?us-ascii?q?QEFAQEBAgEGBBQBAQEBAQEBAYZDhXMBAQEDASNIDgULCxgqAgJXBhMfgwcBg?= =?us-ascii?q?mYgtCJ2gTKFWYRbEIE4gVOFKIZDQYIAgTgcgiEHLj6ECINPNIIsBIJIY0aBX?= =?us-ascii?q?BGdEpw2gwCDKYE4lxQDH4MuijmFPCuPNrE2YoNxAgQGBQIWgV0CL4FZMxoIG?= =?us-ascii?q?xVlAYI+PhIZDY47ji4CQAMwNwIGAQkBAQMJjBUBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,384,1602547200"; d="asc'?scan'208,217";a="33044989" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2021 07:38:36 +0000 Received: from [10.61.223.99] ([10.61.223.99]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 10T7cZjt003104 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jan 2021 07:38:36 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_27FD28BD-D112-4A99-A824-55476CFADED7"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 29 Jan 2021 08:38:35 +0100 In-Reply-To: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> Cc: rfced-future@iab.org To: Adam Roach References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.223.99, [10.61.223.99] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] what would happen with a veto? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 07:38:43 -0000 --Apple-Mail=_27FD28BD-D112-4A99-A824-55476CFADED7 Content-Type: multipart/alternative; boundary="Apple-Mail=_8CE8E938-0A75-4A53-B217-FDFCF4859331" --Apple-Mail=_8CE8E938-0A75-4A53-B217-FDFCF4859331 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Adam, I hope you don=E2=80=99t mind that I=E2=80=99m taking your note as = an opportunity to explore some hypotheticals. Really I made a left turn = with it, but the DISCUSS discussion is as good of jump off point as any = ;-) > On 29 Jan 2021, at 06:28, Adam Roach wrote: >=20 > The most important aspect of a DISCUSS ballot is that, if an AD = holding it is alone in their conviction, the position can be overridden = =E2=80=94 on substance, not process =E2=80=94 by the remaining ADs. I = have grave concerns about allowing someone to be alone in their = disagreement (expert or not) without recourse. To my knowledge a single DISCUSS has never been overridden. One can = draw one of two conclusions from that: either we pick really good ADs = who would not be overridden, or the process of overriding an AD is too = onerous. Whether you want a veto override or a supermajority will = depend on the purpose of approval. I think EKR is arguing for a process veto based on something breaking = one of the streams (please correct me if I=E2=80=99m wrong). Let=E2=80=99= s say in a fictitious example, the WG decided to eliminate the = distinction between normative and informative references. This would = arguably break the IETF stream. At that point, the IETF stream manager = would object. How that person would object is its own interesting = question, but putting that aside for now, the objection is lodged. What would happen next? Doc could be returned to the WG The veto is somehow overridden by the approval body The veto is appealed Looking at the latter two options, what is the basis for overriding and = what is the basis for appeal? If the basis for appeal is whether = process was followed to override, then that is mechanical: either it was = or it wasn=E2=80=99t. This is what I think EKR is suggesting (again, = correct me if I am wrong). Otherwise if the appeals body might be asked = to consider the substance: is the stream going to break? What is the basis for veto override? I think this is where the question = of, =E2=80=9CIs the stream really going to break=E2=80=9D comes to play = under EKR=E2=80=99s proposal (yet again, correct me if I am wrong). Now let=E2=80=99s replace the above example with some other theoretical = (hopefully otherwise unimaginable) example like =E2=80=9Cthis won=E2=80=99= t generate documents that blind people can read=E2=80=9D. The WG has = decided that they don=E2=80=99t care.* Does this =E2=80=9Cbreak a = stream=E2=80=9D? Is the mechanical check on appeal all that mechanical = in terms of interpreting what =E2=80=9Cbreaking a stream=E2=80=9D means? = Should there be another check? Should the doc go through? These are just some thought exercises for people to consider as they = evaluate proposals. It=E2=80=99s not that these sorts of cases would be = expected to come up often, and it is up to this group to decide whether = to optimize for them or whether that would go too far. Eliot * The not-so-crazy version of this would be discussion of color in = diagrams. --Apple-Mail=_8CE8E938-0A75-4A53-B217-FDFCF4859331 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Adam,= I hope you don=E2=80=99t mind that I=E2=80=99m taking your note as an = opportunity to explore some hypotheticals.  Really I made a left = turn with it, but the DISCUSS discussion is as good of jump off point as = any ;-)

On 29 Jan 2021, at 06:28, Adam Roach <adam@nostrum.com> = wrote:

The most important aspect of a DISCUSS ballot is that, if an = AD holding it is alone in their conviction, the position can be = overridden =E2=80=94 on substance, not process =E2=80=94 by the = remaining ADs. I have grave concerns about allowing someone to be alone = in their disagreement (expert or not) without = recourse.

To= my knowledge a single DISCUSS has never been overridden.  One can = draw one of two conclusions from that: either we pick really good ADs = who would not be overridden, or the process of overriding an AD is too = onerous.  Whether you want a veto override or a supermajority will = depend on the purpose of approval.

I think EKR is arguing for a process = veto based on something breaking one of the streams (please correct me = if I=E2=80=99m wrong).  Let=E2=80=99s say in a fictitious example, = the WG decided to eliminate the distinction between normative and = informative references.  This would arguably break the IETF stream. = At that point, the IETF stream manager would object.  How that = person would object is its own interesting question, but putting that = aside for now, the objection is lodged.

What would happen next?

  • Doc could be returned to the = WG
  • The veto is somehow overridden by the approval = body
  • The veto is appealed

Looking at the latter two = options, what is the basis for overriding and what is the basis for = appeal?  If the basis for appeal is whether process was followed to = override, then that is mechanical: either it was or it wasn=E2=80=99t. =  This is what I think EKR is suggesting (again, correct me if I am = wrong).  Otherwise if the appeals body might be asked to consider = the substance: is the stream going to break?

What is the basis for veto override? =  I think this is where the question of, =E2=80=9CIs the stream = really going to break=E2=80=9D comes to play under EKR=E2=80=99s = proposal (yet again, correct me if I am wrong).

Now let=E2=80=99s replace the above = example with some other theoretical (hopefully otherwise unimaginable) = example like =E2=80=9Cthis won=E2=80=99t generate documents that blind = people can read=E2=80=9D.  The WG has decided that they don=E2=80=99t= care.*  Does this =E2=80=9Cbreak a stream=E2=80=9D?  Is the = mechanical check on appeal all that mechanical in terms of interpreting = what =E2=80=9Cbreaking a stream=E2=80=9D means? Should there be another = check?  Should the doc go through?

These are just some thought exercises = for people to consider as they evaluate proposals.  It=E2=80=99s = not that these sorts of cases would be expected to come up often, and it = is up to this group to decide whether to optimize for them or whether = that would go too far.

Eliot

* The not-so-crazy version of this would be discussion of = color in diagrams.
= --Apple-Mail=_8CE8E938-0A75-4A53-B217-FDFCF4859331-- --Apple-Mail=_27FD28BD-D112-4A99-A824-55476CFADED7 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmATu3sACgkQh7ZrRtnS ejM8wgf/QV5MHozE/ne1aDA0cHlHiR6c+BAz3IxrpMhYZudGOXiT+ITMZZ8+/M9n GHY4QCI1AW8/zorkkiNMnG0ypBZVhpgsczzZqCq1KVZq2ATruVFWblpz8kEFz00e 3AKMUo+rRNVaqAS4UPeUfc4UI+ePWZGoi70m5+A/MNYoCELxFpZ/z+MSC3uybDNk bqZ+SqjCoJUo9WTW4saWO4UtJSddef/d1wEOHGxTZ3hqu4mAC3Zm3lK2L9cRxlcy L90fWCz5l0ZH2hhmgIYuPdOTjjXngc83WoaSz3Jn3idquu28g/dyIuqngIBN+rQl uwPrFxiqAMk5GraxDNmLXogcRCjyUQ== =GpDm -----END PGP SIGNATURE----- --Apple-Mail=_27FD28BD-D112-4A99-A824-55476CFADED7-- From nobody Fri Jan 29 02:33: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 8A40D3A0A2C; Fri, 29 Jan 2021 02:33:36 -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 NZjA0V6tMJQd; Fri, 29 Jan 2021 02:33:34 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC33A3A0147; Fri, 29 Jan 2021 02:33:25 -0800 (PST) Received: from p200300dee71fe6004d8c59e34053365e.dip0.t-ipconnect.de ([2003:de:e71f:e600:4d8c:59e3:4053:365e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1l5R5b-0001fa-Cs; Fri, 29 Jan 2021 11:33:19 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Fri, 29 Jan 2021 11:33:16 +0100 Cc: rfced-future@iab.org, Eric Rescorla , Christian Huitema Content-Transfer-Encoding: quoted-printable Message-Id: <678F587C-B6C0-4DA7-8BFE-3B5B10F4776A@kuehlewind.net> References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <2569EC66-2ABC-495E-8F86-0F82B3009189@kuehlewind.net> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1611916405;7e6800f2; X-HE-SMSGID: 1l5R5b-0001fa-Cs Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 10:33:37 -0000 > On 28. Jan 2021, at 21:50, Eliot Lear = wrote: >=20 > Hi Mirja >=20 > On this point: >=20 >>=20 >> There is the other point about stream manager that I wanted to make. = I think stream managers actually represent their part of the community. = As such I don=E2=80=99t see it as the stream managers role to decide = (except for small points that are straight forward) but to check for = consensus in their community. Each stream has an own process for that = and I think we should make use of those established processes. >=20 > What would you envision the IETF stream representative decision = process being? Each stream manage reviews the documents and then decides if the change = in the document should be brought to the respective community for = further feedback. In case of the IETF stream manager we would use the = IETF last call process, IAB would put the document for discussion (and = maybe vote) on an IAB agenda, the IRTF chair might request a review from = thee IRSG, and the ISE could check with its review committee. I don=E2=80=99t think it has to be a requirement that we run this = process for all documents and I think it's okay to trust the stream = managers judgement which ones should go that route. However, we could = also do that for all documents as I don=E2=80=99t expect a too high = load. Or we could also make different decision here for the different = streams, e.g. start an IETF last call for all documents because why = not=E2=80=A6 Mirja >=20 > Eliot > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Fri Jan 29 02:37: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 3EB8D3A0A2E for ; Fri, 29 Jan 2021 02:37:30 -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 NAy7Lcy64E0O for ; Fri, 29 Jan 2021 02:37:28 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEC5C3A0A2C for ; Fri, 29 Jan 2021 02:37:28 -0800 (PST) Received: from p200300dee71fe6004d8c59e34053365e.dip0.t-ipconnect.de ([2003:de:e71f:e600:4d8c:59e3:4053:365e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1l5R9a-00064d-V4; Fri, 29 Jan 2021 11:37:26 +0100 From: Mirja Kuehlewind 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: Fri, 29 Jan 2021 11:37:26 +0100 References: <073fd49d-c30b-dc8d-7365-b8b1ead3e3a3@gmail.com> <6c91736b-6573-42bc-958e-5b7e2bd93398@www.fastmail.com> <537f6376-28c3-01f1-eb83-47198693104d@gmail.com> <20d3a537-eea0-45f6-87f7-0c459769397d@www.fastmail.com> <31f61086-fb67-4170-92aa-d972ccb8c524@www.fastmail.com> <1449d690-bb8a-76d4-f4fd-f2240fb4ece1@gmail.com> <6e1c6861-0152-50c4-30d3-0713d6c19116@gmail.com> <75b44a43-564b-e097-00ac-db57fea149f8@it.aoyama.ac.jp> To: Michael StJohns , rfced-future@iab.org In-Reply-To: Message-Id: <95E96C09-8316-48A9-A5AC-A9F61EF364A6@kuehlewind.net> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1611916648;48e7a0a8; X-HE-SMSGID: 1l5R9a-00064d-V4 Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 10:37:30 -0000 I think those on the board who have a vote/ballot should be selected by = the some community process and have a fixed term to ensure we have some = refreshment over time. I wouldn=E2=80=99t want to see one of these = position to be bound to one specific person. However, for the RSx I = would actually like to have a person for a long time to provide = continuity and enable that person to build up RFC specific expertise. = That=E2=80=99s the conflict for me. > On 29. Jan 2021, at 04:56, Michael StJohns = wrote: >=20 > On 1/28/2021 10:35 PM, Eric Rescorla wrote: >>=20 >>=20 >> On Thu, Jan 28, 2021 at 7:11 PM Brian E Carpenter = wrote: >=20 >> Fair enough. To the best of my knowledge we don't give our lawyer >> a vote on, for instance, the LLC Board. >>=20 >> -Ekr >>=20 >>=20 >=20 > Yet, by design, the LLC board includes people that have other skills = than writing protocols or chairing WGs and one of the current members is = a lawyer and does get a vote. >=20 > Later, Mike >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Fri Jan 29 04:53:36 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A273A0C6D; Fri, 29 Jan 2021 04:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.079 X-Spam-Level: X-Spam-Status: No, score=-2.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3istwqq7tIp; Fri, 29 Jan 2021 04:53:32 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEEF33A0C66; Fri, 29 Jan 2021 04:53:31 -0800 (PST) Received: from [172.17.121.48] (76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253]) (authenticated bits=0) by nostrum.com (8.16.1/8.16.1) with ESMTPSA id 10TCrTeS012497 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 29 Jan 2021 06:53:30 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1611924810; bh=zVjdyaXHPoxYYvYZ9DfqwxtfkaGuMG+HpBhNdXRgfaQ=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=vnqL7KinFdCnjU0cN1nowY0TRPeqM/I+3rTf2U7B3+ll1J8a+KSI57+XTiccOs+6a LJ8mcnaK69b0GYigvKk0sirvrcwcWyOzywXjdxpdcJevxbliYFfaybNE3B6oiNtS/x g3exCEmgPFc3iMB3y5UXZag/TEJalx1+AbeccwDM= X-Authentication-Warning: raven.nostrum.com: Host 76-218-40-253.lightspeed.dllstx.sbcglobal.net [76.218.40.253] claimed to be [172.17.121.48] To: Eliot Lear Cc: rfced-future@iab.org References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> From: Adam Roach Message-ID: <64e9cabf-7ea5-c990-0794-2a9bf560bfc8@nostrum.com> Date: Fri, 29 Jan 2021 06:53:23 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1656C1A379ED875C77E7ED99" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] what would happen with a veto? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 12:53:34 -0000 This is a multi-part message in MIME format. --------------1656C1A379ED875C77E7ED99 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/29/2021 1:38 AM, Eliot Lear wrote: > Adam, I hope you don’t mind that I’m taking your note as an > opportunity to explore some hypotheticals.  Really I made a left turn > with it, but the DISCUSS discussion is as good of jump off point as > any ;-) > >> On 29 Jan 2021, at 06:28, Adam Roach > > wrote: >> >> The most important aspect of a DISCUSS ballot is that, if an AD >> holding it is alone in their conviction, the position can be >> overridden — on substance, not process — by the remaining ADs. I have >> grave concerns about allowing someone to be alone in their >> disagreement (expert or not) without recourse. > > To my knowledge a single DISCUSS has never been overridden.  One can > draw one of two conclusions from that: either we pick really good ADs > who would not be overridden, or the process of overriding an AD is too > onerous. No US president has ever been impeached and convicted, and yet I don't think anyone would think it prudent to remove the process. The presence of the mechanism is generally sufficient to compel behavior that avoids its technical invocation -- and in that second sentence, I'm talking about the DISCUSS ballot override procedure as much as impeachment. In my three years on the IESG, single-DISCUSS-override process invocations were *nearly* brought to bear in at least two cases; and without getting into the details, I can say that I believe the presence of the process served its intended purpose without actually being invoked. >  Whether you want a veto override or a supermajority will depend on > the purpose of approval. > > I think EKR is arguing for a process veto based on something breaking > one of the streams (please correct me if I’m wrong). If only process vetos are allowed, and if all process-related issues can be appealed and overridden, then all vetos can be appealed and overridden. If that's what we want to write down, then I'm happy. The remainder of your discussion prompts are good, and I definitely think they need to be explored. However, my limited time to participate in this effort doesn't afford me the luxury of addressing everything. I do have a strong top-level concern about the ability of a hired expert (or any other person who cannot be removed by a community-initiated process) to unilaterally veto an overwhelming community position without recourse to appeal the *substance* of the decision, and that's the point I dropped in to make. I hope this topic gets driven to ground before we churn too much on the decision structure of the stream managers. /a --------------1656C1A379ED875C77E7ED99 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 1/29/2021 1:38 AM, Eliot Lear wrote:
Adam, I hope you don’t mind that I’m taking your note as an opportunity to explore some hypotheticals.  Really I made a left turn with it, but the DISCUSS discussion is as good of jump off point as any ;-)

On 29 Jan 2021, at 06:28, Adam Roach <adam@nostrum.com> wrote:

The most important aspect of a DISCUSS ballot is that, if an AD holding it is alone in their conviction, the position can be overridden — on substance, not process — by the remaining ADs. I have grave concerns about allowing someone to be alone in their disagreement (expert or not) without recourse.

To my knowledge a single DISCUSS has never been overridden.  One can draw one of two conclusions from that: either we pick really good ADs who would not be overridden, or the process of overriding an AD is too onerous.


No US president has ever been impeached and convicted, and yet I don't think anyone would think it prudent to remove the process. The presence of the mechanism is generally sufficient to compel behavior that avoids its technical invocation -- and in that second sentence, I'm talking about the DISCUSS ballot override procedure as much as impeachment. In my three years on the IESG, single-DISCUSS-override process invocations were *nearly* brought to bear in at least two cases; and without getting into the details, I can say that I believe the presence of the process served its intended purpose without actually being invoked.


 Whether you want a veto override or a supermajority will depend on the purpose of approval.

I think EKR is arguing for a process veto based on something breaking one of the streams (please correct me if I’m wrong).


If only process vetos are allowed, and if all process-related issues can be appealed and overridden, then all vetos can be appealed and overridden. If that's what we want to write down, then I'm happy.

The remainder of your discussion prompts are good, and I definitely think they need to be explored. However, my limited time to participate in this effort doesn't afford me the luxury of addressing everything. I do have a strong top-level concern about the ability of a hired expert (or any other person who cannot be removed by a community-initiated process) to unilaterally veto an overwhelming community position without recourse to appeal the *substance* of the decision, and that's the point I dropped in to make. I hope this topic gets driven to ground before we churn too much on the decision structure of the stream managers.

/a

--------------1656C1A379ED875C77E7ED99-- From nobody Fri Jan 29 05:04: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 12C033A0CB1 for ; Fri, 29 Jan 2021 05:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yn5V4OCWrlTS for ; Fri, 29 Jan 2021 05:04:48 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 791053A0C87 for ; Fri, 29 Jan 2021 05:04:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DRyH4242wz1p0DV for ; Fri, 29 Jan 2021 05:04:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1611925488; bh=D1Ey9ayr25CyxDwaBMeGp4OAK81wxuvcqYSZk3jt1vk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=gjRzHSIOvj6HW/I8u51VAaCH6zEGVmEqlPfjRbxNSXq3zSLJOliNt9LAj2nWl+AfL frK22tlUZckB9vEvgRacPFOaP50duRSExYOvdf5Ht64sYMwIrcLMKt3FMX4nSlcqQK pmofkRPN5ZVxTXbOHG9rjz/2pRiz2nZf4lskB67w= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DRyH3675mz1ny8R for ; Fri, 29 Jan 2021 05:04:47 -0800 (PST) To: "rfced-future@iab.org" References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> From: "Joel M. Halpern" Message-ID: Date: Fri, 29 Jan 2021 08:04:47 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 13:04:52 -0000 I hope that I am misreading Adam and EKR. As far as I can tell, they are arguing against a proposal no one made. What I suggested was that the RSE/A be a full member of the approval body with an equal vote with the stream manager. I explicitly noted that this would mean that under most voting regimes this would require the RSE/A to be able to persuade at least one stream manager to agree with them about the importance of whatever problem they are raising. It might even require them to be able to get two stream heads to agree with them. Other folks phrased this in terms of the discuss procedure, with the same kind of discuss over-ride that the IESG uses (which in this case would mean that the 4 stream heads could over-ride a discuss by the RSE/A). It may be that one proposal called for the RSE/A to have a full veto, but that is not what I have seen folks asking for, and not what I asked for. Yours, Joel On 1/29/2021 12:28 AM, Adam Roach wrote: > > >> On Jan 28, 2021, at 21:11, Brian E Carpenter wrote: >> >> A point below which may appear picky but is actually fundemental to this disagreement: >> >>> On 29-Jan-21 15:43, Martin J. Dürst wrote: >>>> On 29/01/2021 09:17, Eric Rescorla wrote: >>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >>> >>>>> If we select this person on the grounds that they know more about technical >>>>> publishing than the rest of us do, that seems like exactly what we need as >>>>> a finger on the DISCUSS button. >>>>> >>>> >>>> We engage a lawyer who is also an expert on topics that we are not, and >>>> which are rather more consequential if we screw them up, and yet we don't >>>> give them a veto. >>> >>> The expertise of lawyers is more widely acknowledged by most >>> participants because most participants are more accustomed to deal with >>> lawyers, and know that some stuff has to be left to the lawyers. Also, >>> lawyers are more used to attempts to screw them up, and know what to >>> ignore, how to defend themselves, and so on. It's difficult to imagine >>> that a lawyer would quit because they were treated as "just a >>> contractor", because being treated as "just a contractor" wouldn't >>> happen to the lawyer in the first place, or only to the extent that they >>> would be used to be as part of their usual business. >>> >>> This seems to be quite different for an expert in technical publishing. >>> They are not licensed, they don't have any arms to twist, and so on. >>> >>> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS >>> formally is a veto, but many DISCUSSes have been retracted without the >>> raiser having gotten exactly what they originally proposed. >> >> No, a DISCUSS is *not* formally a veto. It is quite narrowly defined >> and there is a procedure for overriding a DISCUSS. See >> https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ >> Indeed, a similar definition and procedure would be appropriate in >> this case too. > > The most important aspect of a DISCUSS ballot is that, if an AD holding it is alone in their conviction, the position can be overridden — on substance, not process — by the remaining ADs. I have grave concerns about allowing someone to be alone in their disagreement (expert or not) without recourse. > > /a > From nobody Fri Jan 29 05:11: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 0431F3A0C9D for ; Fri, 29 Jan 2021 05:11:57 -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 iLINsSP48VPn for ; Fri, 29 Jan 2021 05:11:55 -0800 (PST) Received: from mta5.iomartmail.com (mta5.iomartmail.com [62.128.193.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 168953A0CAC for ; Fri, 29 Jan 2021 05:11:53 -0800 (PST) Received: from vs1.iomartmail.com (vs1.iomartmail.com [10.12.10.121]) by mta5.iomartmail.com (8.14.4/8.14.4) with ESMTP id 10TDBpYq018862 for ; Fri, 29 Jan 2021 13:11:51 GMT Received: from vs1.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 9857022046 for ; Fri, 29 Jan 2021 13:11:51 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs1.iomartmail.com (Postfix) with ESMTPS id 8CD122204A for ; Fri, 29 Jan 2021 13:11:51 +0000 (GMT) Received: from LAPTOPK7AS653V ([84.93.31.76]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 10TDBoro026203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 29 Jan 2021 13:11:51 GMT Reply-To: From: "Adrian Farrel" To: Date: Fri, 29 Jan 2021 13:11:49 -0000 Organization: Old Dog Consulting Message-ID: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: Adb2PsbFobnl9eaiQJ+dQSLxTAUWrA== Content-Language: en-gb X-Originating-IP: 84.93.31.76 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-25940.007 X-TM-AS-Result: No--6.847-10.0-31-10 X-imss-scan-details: No--6.847-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25940.007 X-TMASE-Result: 10--6.847400-10.000000 X-TMASE-MatchedRID: Djm3w85wKJYOwAmmWH5kBMGNvKPnBgOaY15QS1IgC34M74Nf6tTB9kqd VWWu3VopbCPdIHIWlsB4G16E+RCsJYgMxLezTxJOXMhTEepcH5ACC8zqHvcG2i99T+uJIleReth ZeskUR64YwN/e/L16IuRWmhsaZSQr7ns6Ai0dhJnFVAV8vDjN/6kTsFLKwsgi5X8t/NkKVxlSdc too8ZOvkOCs+c0B90vWR+qPiBvoN5JH11OOVB0yWWUn40LZq9JMVx/3ZYby7/nfFax/mCNzBI0e PrNo/nExQa08gWL1ZtdMT+zVZPqwdwT6zxh2KcjbMGKOuLn5FXjhprYYSWlnXy/Hx1AgJrrLURe LvdYkFpAYjaOMhQBRPOWwwvjhd0LXqXbeU5hqGsntzf0FIYhlLq5gapsvWFSnmT4H7Ihzd29293 C9JPlc13U5i4vdFnSFpmAaTp4vV+fKUb9jqfM9I61Z+HJnvsOfS0Ip2eEHny+qryzYw2E8Avgps XypsAMDMq3z/Y/gtUgBwKKRHe+r6Zxujv+E3/01XRUrZuEgznpvsQOiGo6A1q4ApyAUoGXPAcC3 reuNzM= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 13:11:57 -0000 Hi, I've been chewing on this thought for a while and trying to keep up with the list (but please excuse me if this has come up and I missed it). The thrust of Ekr's proposal (1/25) seems reasonable, but I have a concern about how we handle the people who might be considerably impacted by any changes the WG might come up with, but who are not present in the WG. Now, I can usually get behind, "If you want to influence the work, participate in the work." That is certainly how we have operated in the IETF, and generally it gives good results for producing quality technical specifications. But I think that this WG might be in a slightly different space. In practice, we are asking people who are consumers of RFCs to participate in the discussions about the publication format etc. when they might not even be aware that the forum exists, and might anyway be unaccustomed to this way of working. In some cases, the stakeholders might even be one step removed from the RFCs (for example, regulators who want to point at RFCs, but who do not actually implement or read them). My concern is that one or two people turning up from these large but under-represented classes of stakeholder may be swamped by our normal "rough consensus" process. I am not saying that their voices will not be heard, nor that the correct mechanisms will not be used to consider their input. But I am worried that they will lack the experience and expertise to make their points stick in this WG, and that, if push comes to shove, their voice will be seen as a minority and they will be placed "in the rough". Of course, the chairs of the WG will have a considerable responsibility to make sure that things go well for everyone, but in the end, they also call rough consensus. They are only advocates for participants in ensuring that their voice has the opportunity to be heard. So my questions are: Who is the advocate for the under-represented stakeholders? Whose job is it to actively search out relevant opinions? Who has the role of champion for these groups of RFC consumers to make sure that the decisions the WG make do not negatively impact them? Thanks, Adrian From nobody Fri Jan 29 06:07: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 E87593A0D21 for ; Fri, 29 Jan 2021 06:07:38 -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 1QDbz1hzQ55D for ; Fri, 29 Jan 2021 06:07:37 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F9D13A0D18 for ; Fri, 29 Jan 2021 06:07:37 -0800 (PST) Received: from p200300dee71fe6004d8c59e34053365e.dip0.t-ipconnect.de ([2003:de:e71f:e600:4d8c:59e3:4053:365e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1l5UQs-0002I4-Vv; Fri, 29 Jan 2021 15:07:31 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: Date: Fri, 29 Jan 2021 15:07:28 +0100 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1611929257;82134c15; X-HE-SMSGID: 1l5UQs-0002I4-Vv Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 14:07:39 -0000 Hi Joel, I think what we discussed to far and what people might have on their = mind is a ballot-like model as used by the IESG where every single = DISCUSS position blocks publication (and not a majority voting which you = seem to have on mind, right?). Mirja > On 29. Jan 2021, at 14:04, Joel M. Halpern = wrote: >=20 > I hope that I am misreading Adam and EKR. As far as I can tell, they = are arguing against a proposal no one made. >=20 > What I suggested was that the RSE/A be a full member of the approval = body with an equal vote with the stream manager. I explicitly noted = that this would mean that under most voting regimes this would require = the RSE/A to be able to persuade at least one stream manager to agree = with them about the importance of whatever problem they are raising. It = might even require them to be able to get two stream heads to agree with = them. Other folks phrased this in terms of the discuss procedure, with = the same kind of discuss over-ride that the IESG uses (which in this = case would mean that the 4 stream heads could over-ride a discuss by the = RSE/A). >=20 > It may be that one proposal called for the RSE/A to have a full veto, = but that is not what I have seen folks asking for, and not what I asked = for. >=20 > Yours, > Joel >=20 > On 1/29/2021 12:28 AM, Adam Roach wrote: >>> On Jan 28, 2021, at 21:11, Brian E Carpenter = wrote: >>>=20 >>> =EF=BB=BFA point below which may appear picky but is actually = fundemental to this disagreement: >>>=20 >>>> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: >>>>> On 29/01/2021 09:17, Eric Rescorla wrote: >>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >>>>=20 >>>>>> If we select this person on the grounds that they know more about = technical >>>>>> publishing than the rest of us do, that seems like exactly what = we need as >>>>>> a finger on the DISCUSS button. >>>>>>=20 >>>>>=20 >>>>> We engage a lawyer who is also an expert on topics that we are = not, and >>>>> which are rather more consequential if we screw them up, and yet = we don't >>>>> give them a veto. >>>>=20 >>>> The expertise of lawyers is more widely acknowledged by most >>>> participants because most participants are more accustomed to deal = with >>>> lawyers, and know that some stuff has to be left to the lawyers. = Also, >>>> lawyers are more used to attempts to screw them up, and know what = to >>>> ignore, how to defend themselves, and so on. It's difficult to = imagine >>>> that a lawyer would quit because they were treated as "just a >>>> contractor", because being treated as "just a contractor" wouldn't >>>> happen to the lawyer in the first place, or only to the extent that = they >>>> would be used to be as part of their usual business. >>>>=20 >>>> This seems to be quite different for an expert in technical = publishing. >>>> They are not licensed, they don't have any arms to twist, and so = on. >>>>=20 >>>> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS >>>> formally is a veto, but many DISCUSSes have been retracted without = the >>>> raiser having gotten exactly what they originally proposed. >>>=20 >>> No, a DISCUSS is *not* formally a veto. It is quite narrowly defined >>> and there is a procedure for overriding a DISCUSS. See >>> = https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ >>> Indeed, a similar definition and procedure would be appropriate in >>> this case too. >> The most important aspect of a DISCUSS ballot is that, if an AD = holding it is alone in their conviction, the position can be overridden = =E2=80=94 on substance, not process =E2=80=94 by the remaining ADs. I = have grave concerns about allowing someone to be alone in their = disagreement (expert or not) without recourse. >> /a >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Fri Jan 29 06:16:20 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647D63A0D2D for ; Fri, 29 Jan 2021 06:16:19 -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 wi9flvEFhxzi for ; Fri, 29 Jan 2021 06:16:16 -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 B662D3A0D28 for ; Fri, 29 Jan 2021 06:16:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5422; q=dns/txt; s=iport; t=1611929775; x=1613139375; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=aVqiNETZEArh8/ItdPWnPZPqMGTs5utrH59noQYsJfI=; b=P7Y1ly5bqLKlXNMTux48VfKsTzjerGG51vN3Bkz4D6cOsEc195XyD5fK IFrR02oG0AujDWD95vtf8IdO2MljCjNSxy0m8i6EkKAWj+uRDrWM0K/9I aLHgho2y7R48sftZzo4t6n6grpP8l7ttgjYI8dTerZZZvz58d1RJ9rynF A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AhAABLFxRglxbLJq1iHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?QUBAQsBgXWBK1YBIxIvhECJBIgpJQOKHZAqgXwEBwEBAQoDAQEYDQoEAQGES?= =?us-ascii?q?gKBeSY2Bw4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DYVzAQEBA?= =?us-ascii?q?wEBASFIAwsFCwsOCioCAiEGMAYTFIMSAYJVAw4gD7NodoEyhVmCOQ2CFgoGg?= =?us-ascii?q?TgBgVKLa0GCAIERJwwQglY+ghtCAQGEeDSCLASBZR88gUEEKyxpBgI2nG2bX?= =?us-ascii?q?VmDAIMpgTiRcYUjAx+TI49hokmOTx5ig3ECBAYFAhaBXQEwgVkzGggbFTsqA?= =?us-ascii?q?YIKAQEBMT4SGQ2BF40kHYhOhUVAAzACNQIGAQkBAQMJjBUBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,385,1602547200"; d="asc'?scan'208";a="33054707" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2021 14:16:11 +0000 Received: from [10.61.223.99] ([10.61.223.99]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 10TEGAmG003710 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jan 2021 14:16:11 GMT From: Eliot Lear Message-Id: <5F33D199-0C67-4700-A07D-C335DE088809@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_E5B45AF4-8BD7-4EB6-AE81-B3FDD5182F7F"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 29 Jan 2021 15:16:09 +0100 In-Reply-To: <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> Cc: "rfced-future@iab.org" To: Mirja Kuehlewind References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.223.99, [10.61.223.99] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 14:16:19 -0000 --Apple-Mail=_E5B45AF4-8BD7-4EB6-AE81-B3FDD5182F7F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I think Joel meant =E2=80=9Cvoting system=E2=80=9D in a generic way, = IESG-like DISCUSS being just one such approach. > On 29 Jan 2021, at 15:07, Mirja Kuehlewind = wrote: >=20 > Hi Joel, >=20 > I think what we discussed to far and what people might have on their = mind is a ballot-like model as used by the IESG where every single = DISCUSS position blocks publication (and not a majority voting which you = seem to have on mind, right?). >=20 > Mirja >=20 >=20 >=20 >> On 29. Jan 2021, at 14:04, Joel M. Halpern = wrote: >>=20 >> I hope that I am misreading Adam and EKR. As far as I can tell, they = are arguing against a proposal no one made. >>=20 >> What I suggested was that the RSE/A be a full member of the approval = body with an equal vote with the stream manager. I explicitly noted = that this would mean that under most voting regimes this would require = the RSE/A to be able to persuade at least one stream manager to agree = with them about the importance of whatever problem they are raising. It = might even require them to be able to get two stream heads to agree with = them. Other folks phrased this in terms of the discuss procedure, with = the same kind of discuss over-ride that the IESG uses (which in this = case would mean that the 4 stream heads could over-ride a discuss by the = RSE/A). >>=20 >> It may be that one proposal called for the RSE/A to have a full veto, = but that is not what I have seen folks asking for, and not what I asked = for. >>=20 >> Yours, >> Joel >>=20 >> On 1/29/2021 12:28 AM, Adam Roach wrote: >>>> On Jan 28, 2021, at 21:11, Brian E Carpenter = wrote: >>>>=20 >>>> =EF=BB=BFA point below which may appear picky but is actually = fundemental to this disagreement: >>>>=20 >>>>> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: >>>>>> On 29/01/2021 09:17, Eric Rescorla wrote: >>>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >>>>>=20 >>>>>>> If we select this person on the grounds that they know more = about technical >>>>>>> publishing than the rest of us do, that seems like exactly what = we need as >>>>>>> a finger on the DISCUSS button. >>>>>>>=20 >>>>>>=20 >>>>>> We engage a lawyer who is also an expert on topics that we are = not, and >>>>>> which are rather more consequential if we screw them up, and yet = we don't >>>>>> give them a veto. >>>>>=20 >>>>> The expertise of lawyers is more widely acknowledged by most >>>>> participants because most participants are more accustomed to deal = with >>>>> lawyers, and know that some stuff has to be left to the lawyers. = Also, >>>>> lawyers are more used to attempts to screw them up, and know what = to >>>>> ignore, how to defend themselves, and so on. It's difficult to = imagine >>>>> that a lawyer would quit because they were treated as "just a >>>>> contractor", because being treated as "just a contractor" wouldn't >>>>> happen to the lawyer in the first place, or only to the extent = that they >>>>> would be used to be as part of their usual business. >>>>>=20 >>>>> This seems to be quite different for an expert in technical = publishing. >>>>> They are not licensed, they don't have any arms to twist, and so = on. >>>>>=20 >>>>> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS >>>>> formally is a veto, but many DISCUSSes have been retracted without = the >>>>> raiser having gotten exactly what they originally proposed. >>>>=20 >>>> No, a DISCUSS is *not* formally a veto. It is quite narrowly = defined >>>> and there is a procedure for overriding a DISCUSS. See >>>> = https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ >>>> Indeed, a similar definition and procedure would be appropriate in >>>> this case too. >>> The most important aspect of a DISCUSS ballot is that, if an AD = holding it is alone in their conviction, the position can be overridden = =E2=80=94 on substance, not process =E2=80=94 by the remaining ADs. I = have grave concerns about allowing someone to be alone in their = disagreement (expert or not) without recourse. >>> /a >>=20 >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_E5B45AF4-8BD7-4EB6-AE81-B3FDD5182F7F 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAUGKoACgkQh7ZrRtnS ejO6yAf8CCVpM7Mffu8Ng2QyFA9iykfqG5xG27AIqqnvFiLjueOZzDA0kF9Bc/px t0oJOJKMHDmiYmNkacAG5oj/OBXYrFgf93Y0wte7wToIG53dGlYrk8YAVet/7f95 KqJzOsQbse5CE2yBMYNWdqK9en89IacjiSCeiRfRUiWUsjmYJZuGB+eRiZmvoMbd Wo+XO3jeh42k3WQRBiW5w+1nXUCX19bVtvgUxcK4v0Ls3Sa/P8bHQQEq7LesO9Yx Xs0OqjvHG+mrx3cJswRvKaXj7ts9HnAcO5zxYP5cZhVvmq2y11oGyyNMe8sNx4wr E2u9ogKt3a5a1E5ZgUJeGuOVVnBdLg== =iznQ -----END PGP SIGNATURE----- --Apple-Mail=_E5B45AF4-8BD7-4EB6-AE81-B3FDD5182F7F-- From nobody Fri Jan 29 06:17: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 DE30C3A0D2A for ; Fri, 29 Jan 2021 06:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4--g-sXcWsU for ; Fri, 29 Jan 2021 06:17:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C02713A0D2B for ; Fri, 29 Jan 2021 06:16:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A5C92BE55; Fri, 29 Jan 2021 14:16:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fyZtKbUeGdg; Fri, 29 Jan 2021 14:16:56 +0000 (GMT) Received: from [10.244.2.242] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E9905BE64; Fri, 29 Jan 2021 14:16:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1611929816; bh=y+SmG7eG0xI3GdqbGjfsjELxzYI/K/HQafw5j75uZSU=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=PLssx1p+JRT7W7xR+/+DFay7KR7Re+XOlymW1qyaAP2zt1z8+cSS5xv/8aF7DM0JC eY7se1Mofs10bSDqbKkgQVNLVxmaVotHQj+Y0+8bn6HHLkJjRK7P0T1H0korJZMo5Z WQfMOYq8NxxZ8tY4uT7NGUVzNreQfzhOyq/lp5ig= To: Mirja Kuehlewind , "Joel M. Halpern" Cc: "rfced-future@iab.org" References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> From: Stephen Farrell Message-ID: Date: Fri, 29 Jan 2021 14:16:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9YbA5NSzTKlP1GpCg1NNkrkZxUB35oj6D" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 14:17:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9YbA5NSzTKlP1GpCg1NNkrkZxUB35oj6D Content-Type: multipart/mixed; boundary="RiAlvgvBsTglgvANR52vMMMdDLo4a8ugs"; protected-headers="v1" From: Stephen Farrell To: Mirja Kuehlewind , "Joel M. Halpern" Cc: "rfced-future@iab.org" Message-ID: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> In-Reply-To: <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> --RiAlvgvBsTglgvANR52vMMMdDLo4a8ugs Content-Type: multipart/mixed; boundary="------------01DB700D5801C582BBF377C8" Content-Language: en-US This is a multi-part message in MIME format. --------------01DB700D5801C582BBF377C8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Still wondering if we're not covering all the kinds of decisions needed, sorry;-) On 29/01/2021 14:07, Mirja Kuehlewind wrote: > I think what we discussed to far and what people might have on their > mind is a ballot-like model as used by the IESG where every single > DISCUSS position blocks publication (and not a majority voting which > you seem to have on mind, right?). The above assumes that most/all decisions are based around document approval. Heather put in place an archival agreement for RFCs with a couple of archiving institutions. Regardless of whether one thinks that was fantastic or not needed, ISTM the set of activities required wouldn't map well to a WG/IESG-like document approval process. I'm a bit worried we're ignoring such things, perhaps because we're more used to haggling over how many DISCUSS ballots fit on the head of a pin:-) Cheers, S. --------------01DB700D5801C582BBF377C8 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------01DB700D5801C582BBF377C8-- --RiAlvgvBsTglgvANR52vMMMdDLo4a8ugs-- --9YbA5NSzTKlP1GpCg1NNkrkZxUB35oj6D Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAUGNcFAwAAAAAACgkQWrL68XsXK+qU phAAvNQNiXOLwce5dWP7J001E5eAB7pXcVC9wnPUgBkJckSJcg7bIHnDfBJ1O2u/VCQnxvaikVq5 4RfQmRU6VieVmzTZIfT4ArEd3c0od9eWtpJ5vkr4641IaZYeIQK4qPMfdB/m5E6NKm7qKrne5WiV GGAuvjBYzTmqrERKJKnfrfb35ZdRddDzHGTyh+lB10oB9JdXZnJWQAJlJRYFdumDdH+DIOlDFBc0 BzuyIvynhI13ZQyIVC20A18yXD/S+ZIJXeYn3PZKHQ9H3whUQL0KolKl8lJV7cwymNb9R1GXjyQx 2/A95Bx/P7as7S1KeUnBavXHiKH3nxV2Uwp3Ikx8qSee9Ye8X7R7WWyYgo2g49cayjWR2GfiVB7y YOcKsodEiIxsanpbWDYJDNXDU3IwfgEdm/2DEe2yGzDUxPZPH7El7QMrG9WOXGdM+DCPF1fR/8LT yLyH4Ye9RB746m7gI8WM2D0ZAdAOGQTKawdpRe2/UQBuyp/VhoApaiqZd4GkvmjCX+sgN/o++qCw T7J7g3P2KPavvVLlh8xC0GTk6r8ZlvdT1wnxbOqB7w82SRs1InQoCCIcoh2pHlC2I3MEaLkhEzLj IsdpFO+8ZXu9iMRjwazMwKPmoxe6haekF/6nVatWSM96y6nNyMXf43uj1yOd6zlNNoZfh/jQzmja YnY= =Rh+B -----END PGP SIGNATURE----- --9YbA5NSzTKlP1GpCg1NNkrkZxUB35oj6D-- From nobody Fri Jan 29 06:21:55 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF62A3A0D38 for ; Fri, 29 Jan 2021 06:21:53 -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 0iqwlwunLWKr for ; Fri, 29 Jan 2021 06:21:52 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8583A0D37 for ; Fri, 29 Jan 2021 06:21:52 -0800 (PST) Received: from p200300dee71fe6004d8c59e34053365e.dip0.t-ipconnect.de ([2003:de:e71f:e600:4d8c:59e3:4053:365e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1l5Uej-0005eX-QT; Fri, 29 Jan 2021 15:21:49 +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: Date: Fri, 29 Jan 2021 15:21:49 +0100 Cc: "Joel M. Halpern" , "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> To: Stephen Farrell X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1611930112;6f26d189; X-HE-SMSGID: 1l5Uej-0005eX-QT Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 14:21:54 -0000 Please see below. > On 29. Jan 2021, at 15:16, Stephen Farrell = wrote: >=20 >=20 > Still wondering if we're not covering all the > kinds of decisions needed, sorry;-) >=20 > On 29/01/2021 14:07, Mirja Kuehlewind wrote: >> I think what we discussed to far and what people might have on their >> mind is a ballot-like model as used by the IESG where every single >> DISCUSS position blocks publication (and not a majority voting which >> you seem to have on mind, right?). >=20 > The above assumes that most/all decisions are > based around document approval. Heather put in > place an archival agreement for RFCs with a > couple of archiving institutions. Regardless of > whether one thinks that was fantastic or not > needed, ISTM the set of activities required > wouldn't map well to a WG/IESG-like document > approval process. Not sure. The process I would see in future for these kind of things is = that something like this would be proposed to the working group in form = of a short document (that also explains why this is useful or needed). = That document would be approved and published and then the LLC will help = to execute such agreements. It might look like overhead to have a = document here but I think it would actually be useful now to have some = documentation of why Heather thought these agreements are important. Mirja >=20 > I'm a bit worried we're ignoring such things, > perhaps because we're more used to haggling > over how many DISCUSS ballots fit on the head > of a pin:-) >=20 > Cheers, > S. >=20 > From nobody Fri Jan 29 06:23: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 035303A0D3C for ; Fri, 29 Jan 2021 06:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LQV0wnLZNue for ; Fri, 29 Jan 2021 06:23:20 -0800 (PST) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EACF3A0D27 for ; Fri, 29 Jan 2021 06:23:20 -0800 (PST) Received: from p200300dee71fe6004d8c59e34053365e.dip0.t-ipconnect.de ([2003:de:e71f:e600:4d8c:59e3:4053:365e]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1l5Ug9-0006Do-Nb; Fri, 29 Jan 2021 15:23:17 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <5F33D199-0C67-4700-A07D-C335DE088809@cisco.com> Date: Fri, 29 Jan 2021 15:23:15 +0100 Cc: "rfced-future@iab.org" Content-Transfer-Encoding: quoted-printable Message-Id: <580589E3-CBE1-44D4-9965-02C13EAFBB1E@kuehlewind.net> References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <5F33D199-0C67-4700-A07D-C335DE088809@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1611930200;a182bc23; X-HE-SMSGID: 1l5Ug9-0006Do-Nb Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 14:23:22 -0000 Yes, I just wanted to say that I believe Joel and Adam/EKR have to = different systems in mind and therefore might be taking past each other = a bit=E2=80=A6 just trying to help=E2=80=A6 > On 29. Jan 2021, at 15:16, Eliot Lear wrote: >=20 > I think Joel meant =E2=80=9Cvoting system=E2=80=9D in a generic way, = IESG-like DISCUSS being just one such approach. >=20 >> On 29 Jan 2021, at 15:07, Mirja Kuehlewind = wrote: >>=20 >> Hi Joel, >>=20 >> I think what we discussed to far and what people might have on their = mind is a ballot-like model as used by the IESG where every single = DISCUSS position blocks publication (and not a majority voting which you = seem to have on mind, right?). >>=20 >> Mirja >>=20 >>=20 >>=20 >>> On 29. Jan 2021, at 14:04, Joel M. Halpern = wrote: >>>=20 >>> I hope that I am misreading Adam and EKR. As far as I can tell, = they are arguing against a proposal no one made. >>>=20 >>> What I suggested was that the RSE/A be a full member of the approval = body with an equal vote with the stream manager. I explicitly noted = that this would mean that under most voting regimes this would require = the RSE/A to be able to persuade at least one stream manager to agree = with them about the importance of whatever problem they are raising. It = might even require them to be able to get two stream heads to agree with = them. Other folks phrased this in terms of the discuss procedure, with = the same kind of discuss over-ride that the IESG uses (which in this = case would mean that the 4 stream heads could over-ride a discuss by the = RSE/A). >>>=20 >>> It may be that one proposal called for the RSE/A to have a full = veto, but that is not what I have seen folks asking for, and not what I = asked for. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/29/2021 12:28 AM, Adam Roach wrote: >>>>> On Jan 28, 2021, at 21:11, Brian E Carpenter = wrote: >>>>>=20 >>>>> =EF=BB=BFA point below which may appear picky but is actually = fundemental to this disagreement: >>>>>=20 >>>>>> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: >>>>>>> On 29/01/2021 09:17, Eric Rescorla wrote: >>>>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >>>>>>=20 >>>>>>>> If we select this person on the grounds that they know more = about technical >>>>>>>> publishing than the rest of us do, that seems like exactly what = we need as >>>>>>>> a finger on the DISCUSS button. >>>>>>>>=20 >>>>>>>=20 >>>>>>> We engage a lawyer who is also an expert on topics that we are = not, and >>>>>>> which are rather more consequential if we screw them up, and yet = we don't >>>>>>> give them a veto. >>>>>>=20 >>>>>> The expertise of lawyers is more widely acknowledged by most >>>>>> participants because most participants are more accustomed to = deal with >>>>>> lawyers, and know that some stuff has to be left to the lawyers. = Also, >>>>>> lawyers are more used to attempts to screw them up, and know what = to >>>>>> ignore, how to defend themselves, and so on. It's difficult to = imagine >>>>>> that a lawyer would quit because they were treated as "just a >>>>>> contractor", because being treated as "just a contractor" = wouldn't >>>>>> happen to the lawyer in the first place, or only to the extent = that they >>>>>> would be used to be as part of their usual business. >>>>>>=20 >>>>>> This seems to be quite different for an expert in technical = publishing. >>>>>> They are not licensed, they don't have any arms to twist, and so = on. >>>>>>=20 >>>>>> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS >>>>>> formally is a veto, but many DISCUSSes have been retracted = without the >>>>>> raiser having gotten exactly what they originally proposed. >>>>>=20 >>>>> No, a DISCUSS is *not* formally a veto. It is quite narrowly = defined >>>>> and there is a procedure for overriding a DISCUSS. See >>>>> = https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ >>>>> Indeed, a similar definition and procedure would be appropriate in >>>>> this case too. >>>> The most important aspect of a DISCUSS ballot is that, if an AD = holding it is alone in their conviction, the position can be overridden = =E2=80=94 on substance, not process =E2=80=94 by the remaining ADs. I = have grave concerns about allowing someone to be alone in their = disagreement (expert or not) without recourse. >>>> /a >>>=20 >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Fri Jan 29 06:33:56 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D1D3A0D63 for ; Fri, 29 Jan 2021 06:33:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XXyYcqxEMNih for ; Fri, 29 Jan 2021 06:33:54 -0800 (PST) Received: from mail-lf1-x129.google.com (mail-lf1-x129.google.com [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C6493A0D60 for ; Fri, 29 Jan 2021 06:33:54 -0800 (PST) Received: by mail-lf1-x129.google.com with SMTP id q12so12750109lfo.12 for ; Fri, 29 Jan 2021 06:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b/0zhvmBkhJ8Azs0i+iHBE+YtH4cKJSPKDT9Mh5uNzk=; b=c7g/4OgntodiwYdAYACDNlQWl/5de8w/taxDprBbjSn4++oOMHctlJn206vMeaHIBC +sgnVP0YScJv3fLzEdoML32evEqZNfyHMq0jDbmGd9TMOizPdUGmkWhOhivH5U9hjcZG fAJCCnayGmp5rb3jgAOTyJjf9a02ijjt/lfH8/WFTrgPAONQhFfscbKpZVSHsrL58JbV XqKs7mpwYheWz8MYhCkE5aNMRqVXw2MJU7cX2jXlLwxglFAzitk1PUtj/ACMjmPy7ktf QhQIHCF67kCExuooaP9ZPXXzl9h+m5XZceaedik7usFEJEO5373GrwPyhZ0FRG3hXozR zc2Q== 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=b/0zhvmBkhJ8Azs0i+iHBE+YtH4cKJSPKDT9Mh5uNzk=; b=ZsgC4OkFzx7sCh9DTNSF3bONHeQQrD7doR/g/GDJ1cHLXqj8XUpOm/Gc6ldCTqLkpN 5sxPzEFe8pKwZIdViU3kZApbrLvnkJK7Z2mUGBJriHsBlG3PlXPiTfMCImDJxMiSThr5 IRYWF+RsNfiVSI5FeYne4krC3sJX6Q4V/HB/MTk41BBy5bOHwvFk36gc+mztcxhqWp5V AeHdgA/WzsxBGNu3Qf+syddURWpI4bQRVB3Mtyij9pjv+yBnAdHHObJ4fCpA0GpuA3rQ WbF8YRW83izZh4RcQNXAwOTytpJu5NaAv6hObKcL/cGZDsz1rzmRv/yG3WAvFa4EyEfe dlTQ== X-Gm-Message-State: AOAM5316ngxJgXhbyWhG7Q1XJEGOEx3y5v3kaugnHWSrQI2y54m6Eban fNvjhEUv517KFJHGGUaTEQU5rY42xFQPTl23FeiLlmrzmTRnhQ== X-Google-Smtp-Source: ABdhPJyE2jM1DYDHTZb1oSeQl3RzRa5pcTNWBBXjiraYh1cEy5lHqVfpEJi8vn5ojcjf/enDqKfgvTCPbjNe5Y9ilm8= X-Received: by 2002:ac2:46c4:: with SMTP id p4mr2290664lfo.579.1611930832488; Fri, 29 Jan 2021 06:33:52 -0800 (PST) MIME-Version: 1.0 References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> In-Reply-To: From: Eric Rescorla Date: Fri, 29 Jan 2021 06:33:16 -0800 Message-ID: To: "Joel M. Halpern" Cc: "rfced-future@iab.org" Content-Type: multipart/alternative; boundary="000000000000ac5fbc05ba0ae452" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 14:33:56 -0000 --000000000000ac5fbc05ba0ae452 Content-Type: text/plain; charset="UTF-8" On Fri, Jan 29, 2021 at 5:05 AM Joel M. Halpern wrote: > I hope that I am misreading Adam and EKR. As far as I can tell, they > are arguing against a proposal no one made. > > What I suggested was that the RSE/A be a full member of the approval > body with an equal vote with the stream manager. Understood. I am not in favor of this. I believe the actual decision making should be done by people who were selected by a community-driven process, rather than hired experts. -Ekr --000000000000ac5fbc05ba0ae452 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 29, 2021 at 5:05 AM Joel = M. Halpern <jmh@joelhalpern.com> wrote:
I = hope that I am misreading Adam and EKR.=C2=A0 As far as I can tell, they are arguing against a proposal no one made.

What I suggested was that the RSE/A be a full member of the approval
body with an equal vote with the stream manager.=C2=A0
--000000000000ac5fbc05ba0ae452-- From nobody Fri Jan 29 07:06:07 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED79F3A106E for ; Fri, 29 Jan 2021 07:06:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEi57YBc-JNt for ; Fri, 29 Jan 2021 07:06:00 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7B673A105A for ; Fri, 29 Jan 2021 07:05:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B81F4BE64; Fri, 29 Jan 2021 15:05:57 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 94w-mrzsXzQz; Fri, 29 Jan 2021 15:05:56 +0000 (GMT) Received: from [10.244.2.242] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 05529BE55; Fri, 29 Jan 2021 15:05:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1611932756; bh=1e3e4nRzO4S9ZubMhuOT68zyg6USzCJv8P0SN3bHEk0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=QorVipOQBz4IBbjyEAMytAbWE0teGmSjGP63ZYSqZFd5Z6FbtbF4PvxdrByPc9iop hYZZdhSsTKe2IZjOcCz6V4+yPez+PcSqFF3CD1iBXOlDbkvApjiVv8KUrnYFa1mCyC jRQjjQ1fpWawDYE5U8lE6AEi8QPS42xo/9Yrg+CA= To: Mirja Kuehlewind Cc: "Joel M. Halpern" , "rfced-future@iab.org" References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> From: Stephen Farrell Message-ID: <0648bdbb-c084-cf8c-eca2-364e89b97aab@cs.tcd.ie> Date: Fri, 29 Jan 2021 15:05:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="U8bOSo0ouHTh2pXs6fhKBnvtZTDRozSSU" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 15:06:06 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --U8bOSo0ouHTh2pXs6fhKBnvtZTDRozSSU Content-Type: multipart/mixed; boundary="kW5q4cwT8BpMmp9qnVlZgtoFBOQFoVlTP"; protected-headers="v1" From: Stephen Farrell To: Mirja Kuehlewind Cc: "Joel M. Halpern" , "rfced-future@iab.org" Message-ID: <0648bdbb-c084-cf8c-eca2-364e89b97aab@cs.tcd.ie> Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> In-Reply-To: --kW5q4cwT8BpMmp9qnVlZgtoFBOQFoVlTP Content-Type: multipart/mixed; boundary="------------2C6B85C6FE94D40477DC37DF" Content-Language: en-US This is a multi-part message in MIME format. --------------2C6B85C6FE94D40477DC37DF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 29/01/2021 14:21, Mirja Kuehlewind wrote: > Not sure. The process I would see in future for these kind of things > is that something like this would be proposed to the working group in > form of a short document (that also explains why this is useful or > needed). That document would be approved and published and then the > LLC will help to execute such agreements. It might look like overhead > to have a document here but I think it would actually be useful now > to have some documentation of why Heather thought these agreements > are important. I fear that misses the point. Assuming for a second that that archiving arrangement was a good plan, a document-based approach could quite likely have lead to asking the LLC to go issue an RFP or some such, and I reckon that'd be a worse outcome. In that case, and perhaps in many other cases, I believe there were a number of informal investigation steps before anything was agreed, so while yes, it'd have been good if the arrangement had been documented after it was arrived at, (and maybe that happened, I don't know), I'd worry that driving everything via document publication and approval is just a bad plan. S. --------------2C6B85C6FE94D40477DC37DF Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------2C6B85C6FE94D40477DC37DF-- --kW5q4cwT8BpMmp9qnVlZgtoFBOQFoVlTP-- --U8bOSo0ouHTh2pXs6fhKBnvtZTDRozSSU Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAUJFMFAwAAAAAACgkQWrL68XsXK+rZ PQ//QzTkK+xq+t2MObh27wSjyLBAL/fRSTPUrYSC1c5t1eUjKVeLcgip1GsczpN4qVhlS5RNS1vF 9yn71DhKXYgph2DsHuOVp+lTpheqA+0YDiZdwRl976OTyCO5tMNbHUdS+Thl7s+NkypMCSvftACD Q3crIZ/Du/ZWNSvCKoLNqAQ0t0alzPYeXdSJn00GQn5Di6mEUXzLF1mSFHRcrKW6RT5eo4eoRQSZ 91NW8NYCFtNYzmTgBSPhL7SbNb6APiUvkoU8d/Wv/ALSRfDh2ymAQaE6i7dvN0EeyxBGIgA9VZ36 FJuPtFfXLwD6zYv4Fcr3Pm257/JHir2c9RyOaVSMCzIN3CEbpUtW/x9RAbxObmm5+iGcbmMGpRO6 AUJWc49cbQUrjUpT3Um/kvEesnWWHQGKHTmb/3gs5lm5rtvrPNQlfqn+GV5jaXvoaQl5iZie9VtO fOurHTdxSv/ZAi/km4Sl5N6gLGDIOnO/IDu0t9RLhts5PpLolvGsSVbd8yyvyvGXaiC7GouY9F69 R64NPtkWqsxJTTBAvdYHSnJ12NPykGjtDR1a7oz9rRem5C7WQdBGLy5yteJaqhwz+RDiODlYcGtP Ukb6iQzvv/WqbM8pGMvG2EuKsKbRbpPk3gmuXGRpEzg+ph/t6PK7L/pFF4pS5V9bdWzwaJWhXeMY BAo= =T8UH -----END PGP SIGNATURE----- --U8bOSo0ouHTh2pXs6fhKBnvtZTDRozSSU-- From nobody Fri Jan 29 07:06:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D083A1160 for ; Fri, 29 Jan 2021 07:06:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2gAGSrRFgjJd for ; Fri, 29 Jan 2021 07:06:13 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 163D03A1106 for ; Fri, 29 Jan 2021 07:06:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4DS0z55xXxz1nvqy; Fri, 29 Jan 2021 07:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1611932769; bh=S9XAxaolsTKSL9ZQxPs9XHO2ln9dhxDr88LqV0G9N2g=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=hZ17AALajRtPSNULey7SxLGd7eWZOy/EqUDi39Jydpso8d7roIqvUxF7BeviIZXKn 9kuVNbgHj/pBVmpbqGRCYl43eesZ4pEvkVPrCYreRv0UOnkSAdoYcYe6MecaB3h2KS 9b0eTxcI7gvMuVsm2H2CoMYoKOEN81pJ5Fa0sR8Y= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4DS0z521BHz1nv8b; Fri, 29 Jan 2021 07:06:09 -0800 (PST) To: Mirja Kuehlewind Cc: "rfced-future@iab.org" References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> From: "Joel M. Halpern" Message-ID: Date: Fri, 29 Jan 2021 10:06:08 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 15:06:19 -0000 I would like an approach along the lines of the IESG discuss where one objector forces serious discussion, but unless that objector can get support, they eventually have to yield. I can live with a majority vote proposaal (which would require the RSE/A to be able to get two supporters to block something.) What I was commenting on specifically was those who were objecting to giving the RSE/A a veto, when that was not what was asked. I understand from EKRs response to my message that even with those approaches, he does support this, and wants only community appointed people having any say in the approval. I do not see how to get past so fundamental a degree of disagreement. But I hope we can. Yours, Joel PS: I suspect Stephen has a good point that focusing on the documents may cause us to miss important aspects of what we are discussing, even if we (reasonably) assume that all decisions need to end up documented. On 1/29/2021 9:07 AM, Mirja Kuehlewind wrote: > Hi Joel, > > I think what we discussed to far and what people might have on their mind is a ballot-like model as used by the IESG where every single DISCUSS position blocks publication (and not a majority voting which you seem to have on mind, right?). > > Mirja > > > >> On 29. Jan 2021, at 14:04, Joel M. Halpern wrote: >> >> I hope that I am misreading Adam and EKR. As far as I can tell, they are arguing against a proposal no one made. >> >> What I suggested was that the RSE/A be a full member of the approval body with an equal vote with the stream manager. I explicitly noted that this would mean that under most voting regimes this would require the RSE/A to be able to persuade at least one stream manager to agree with them about the importance of whatever problem they are raising. It might even require them to be able to get two stream heads to agree with them. Other folks phrased this in terms of the discuss procedure, with the same kind of discuss over-ride that the IESG uses (which in this case would mean that the 4 stream heads could over-ride a discuss by the RSE/A). >> >> It may be that one proposal called for the RSE/A to have a full veto, but that is not what I have seen folks asking for, and not what I asked for. >> >> Yours, >> Joel >> >> On 1/29/2021 12:28 AM, Adam Roach wrote: >>>> On Jan 28, 2021, at 21:11, Brian E Carpenter wrote: >>>> >>>> A point below which may appear picky but is actually fundemental to this disagreement: >>>> >>>>> On 29-Jan-21 15:43, Martin J. Dürst wrote: >>>>>> On 29/01/2021 09:17, Eric Rescorla wrote: >>>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >>>>> >>>>>>> If we select this person on the grounds that they know more about technical >>>>>>> publishing than the rest of us do, that seems like exactly what we need as >>>>>>> a finger on the DISCUSS button. >>>>>>> >>>>>> >>>>>> We engage a lawyer who is also an expert on topics that we are not, and >>>>>> which are rather more consequential if we screw them up, and yet we don't >>>>>> give them a veto. >>>>> >>>>> The expertise of lawyers is more widely acknowledged by most >>>>> participants because most participants are more accustomed to deal with >>>>> lawyers, and know that some stuff has to be left to the lawyers. Also, >>>>> lawyers are more used to attempts to screw them up, and know what to >>>>> ignore, how to defend themselves, and so on. It's difficult to imagine >>>>> that a lawyer would quit because they were treated as "just a >>>>> contractor", because being treated as "just a contractor" wouldn't >>>>> happen to the lawyer in the first place, or only to the extent that they >>>>> would be used to be as part of their usual business. >>>>> >>>>> This seems to be quite different for an expert in technical publishing. >>>>> They are not licensed, they don't have any arms to twist, and so on. >>>>> >>>>> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS >>>>> formally is a veto, but many DISCUSSes have been retracted without the >>>>> raiser having gotten exactly what they originally proposed. >>>> >>>> No, a DISCUSS is *not* formally a veto. It is quite narrowly defined >>>> and there is a procedure for overriding a DISCUSS. See >>>> https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ >>>> Indeed, a similar definition and procedure would be appropriate in >>>> this case too. >>> The most important aspect of a DISCUSS ballot is that, if an AD holding it is alone in their conviction, the position can be overridden — on substance, not process — by the remaining ADs. I have grave concerns about allowing someone to be alone in their disagreement (expert or not) without recourse. >>> /a >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future > From nobody Fri Jan 29 10:42: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 31E843A1216 for ; Fri, 29 Jan 2021 10:42:39 -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 qCsUygYHauWx for ; Fri, 29 Jan 2021 10:42:37 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA3DF3A0C88 for ; Fri, 29 Jan 2021 10:42:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6757; q=dns/txt; s=iport; t=1611945757; x=1613155357; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Drf7fToo6B/hjO+JcmxSF6vhtrqKwqj2gQlZVE4Axm8=; b=HXeDV2up898u9LDcK33xgRKGzporHRbIK6t8OgNg1krxUi3y9xYrlNH/ 10JH/4BYG4uIUvKSQtyJkgOELriuL/v4LxNHaeQBG1lcCnshBueXjyPVN xQhMdqfjVDECRJMyqteq/QoLdI8I2myc1x9UGYGczhGz34grTSJEZkr9g 4=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AVAQDFVhRglxbLJq1iHAEBAQEBAQcBARIBAQQEAQGCD?= =?us-ascii?q?4F2gStWASMSL4RAiQSIUQOKHZImBAcBAQEKAwEBGA0KBAEBhEoCgXkmOBMCA?= =?us-ascii?q?wEBAQMCAwEBAQEFAQEBAgEGBBQBAQEBAQEBAYY2DYVzAQEBAwEBASFIAwsFC?= =?us-ascii?q?wsYKgICIQYwBhMUgxIBglUDDiAPs1p2gTKFWYJIDYIWCgaBOIFTi2tBggCBE?= =?us-ascii?q?SccglY+ghtCAQGEeDSCLASBZR8jGWtGEAQeDSxpBgI2nG2bXVmDAIMpgTiRc?= =?us-ascii?q?YUjAx+jBKJJjk8eYoNxAgQGBQIWgW0hgVkzGggbFTsqAYIKAQEBMT4SGQ2BF?= =?us-ascii?q?40kHYhOhUVAAzACNQIGAQkBAQMJjBUBAQ?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,386,1602547200"; d="asc'?scan'208";a="33058676" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Jan 2021 18:42:32 +0000 Received: from ams3-vpn-dhcp6592.cisco.com (ams3-vpn-dhcp6592.cisco.com [10.61.89.191]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 10TIgVU2030813 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Jan 2021 18:42:32 GMT From: Eliot Lear Message-Id: <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F9012C98-0570-4923-A251-DCEA3E0F5987"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Fri, 29 Jan 2021 19:42:30 +0100 In-Reply-To: Cc: "rfced-future@iab.org" To: "Joel M. Halpern" References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.89.191, ams3-vpn-dhcp6592.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 18:42:39 -0000 --Apple-Mail=_F9012C98-0570-4923-A251-DCEA3E0F5987 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is there a middle ground here in which the RSE/A acts as an ex-officio = non-voting member of the approval body, who can raise issues that would = =E2=80=9Cbreak the series=E2=80=9D but have to garner some amount of = support from voting members to halt a proposal? This would move the = ballgame to what does it mean, =E2=80=9Cbreak the series=E2=80=9D. Eliot > On 29 Jan 2021, at 16:06, Joel M. Halpern wrote: >=20 > I would like an approach along the lines of the IESG discuss where one = objector forces serious discussion, but unless that objector can get = support, they eventually have to yield. I can live with a majority vote = proposaal (which would require the RSE/A to be able to get two = supporters to block something.) > What I was commenting on specifically was those who were objecting to = giving the RSE/A a veto, when that was not what was asked. >=20 > I understand from EKRs response to my message that even with those = approaches, he does support this, and wants only community appointed = people having any say in the approval. >=20 > I do not see how to get past so fundamental a degree of disagreement. = But I hope we can. >=20 > Yours, > Joel >=20 > PS: I suspect Stephen has a good point that focusing on the documents = may cause us to miss important aspects of what we are discussing, even = if we (reasonably) assume that all decisions need to end up documented. >=20 > On 1/29/2021 9:07 AM, Mirja Kuehlewind wrote: >> Hi Joel, >> I think what we discussed to far and what people might have on their = mind is a ballot-like model as used by the IESG where every single = DISCUSS position blocks publication (and not a majority voting which you = seem to have on mind, right?). >> Mirja >>> On 29. Jan 2021, at 14:04, Joel M. Halpern = wrote: >>>=20 >>> I hope that I am misreading Adam and EKR. As far as I can tell, = they are arguing against a proposal no one made. >>>=20 >>> What I suggested was that the RSE/A be a full member of the approval = body with an equal vote with the stream manager. I explicitly noted = that this would mean that under most voting regimes this would require = the RSE/A to be able to persuade at least one stream manager to agree = with them about the importance of whatever problem they are raising. It = might even require them to be able to get two stream heads to agree with = them. Other folks phrased this in terms of the discuss procedure, with = the same kind of discuss over-ride that the IESG uses (which in this = case would mean that the 4 stream heads could over-ride a discuss by the = RSE/A). >>>=20 >>> It may be that one proposal called for the RSE/A to have a full = veto, but that is not what I have seen folks asking for, and not what I = asked for. >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 1/29/2021 12:28 AM, Adam Roach wrote: >>>>> On Jan 28, 2021, at 21:11, Brian E Carpenter = wrote: >>>>>=20 >>>>> =EF=BB=BFA point below which may appear picky but is actually = fundemental to this disagreement: >>>>>=20 >>>>>> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: >>>>>>> On 29/01/2021 09:17, Eric Rescorla wrote: >>>>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >>>>>>=20 >>>>>>>> If we select this person on the grounds that they know more = about technical >>>>>>>> publishing than the rest of us do, that seems like exactly what = we need as >>>>>>>> a finger on the DISCUSS button. >>>>>>>>=20 >>>>>>>=20 >>>>>>> We engage a lawyer who is also an expert on topics that we are = not, and >>>>>>> which are rather more consequential if we screw them up, and yet = we don't >>>>>>> give them a veto. >>>>>>=20 >>>>>> The expertise of lawyers is more widely acknowledged by most >>>>>> participants because most participants are more accustomed to = deal with >>>>>> lawyers, and know that some stuff has to be left to the lawyers. = Also, >>>>>> lawyers are more used to attempts to screw them up, and know what = to >>>>>> ignore, how to defend themselves, and so on. It's difficult to = imagine >>>>>> that a lawyer would quit because they were treated as "just a >>>>>> contractor", because being treated as "just a contractor" = wouldn't >>>>>> happen to the lawyer in the first place, or only to the extent = that they >>>>>> would be used to be as part of their usual business. >>>>>>=20 >>>>>> This seems to be quite different for an expert in technical = publishing. >>>>>> They are not licensed, they don't have any arms to twist, and so = on. >>>>>>=20 >>>>>> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS >>>>>> formally is a veto, but many DISCUSSes have been retracted = without the >>>>>> raiser having gotten exactly what they originally proposed. >>>>>=20 >>>>> No, a DISCUSS is *not* formally a veto. It is quite narrowly = defined >>>>> and there is a procedure for overriding a DISCUSS. See >>>>> = https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ >>>>> Indeed, a similar definition and procedure would be appropriate in >>>>> this case too. >>>> The most important aspect of a DISCUSS ballot is that, if an AD = holding it is alone in their conviction, the position can be overridden = =E2=80=94 on substance, not process =E2=80=94 by the remaining ADs. I = have grave concerns about allowing someone to be alone in their = disagreement (expert or not) without recourse. >>>> /a >>>=20 >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_F9012C98-0570-4923-A251-DCEA3E0F5987 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAUVxcACgkQh7ZrRtnS ejONewgAyWmnlPzvdCYv7WVjX5jgvZb2pmG51GskW+D2K85/fPRFXkM/z3oEU1NE jbrDyuIaP4rEof1biPTljQOY2XZmrfEHgrLtDIouAC7vvrMn7DQmJEhCpLFwZxGh OEzeUXFmImE1+fq/bCj1/G87QdEXedTvXn2M0JLmNlBegfEPKWCqk2w7ur89i7la Pero9J0udNI0gPXyFj2TryhDhC+BwmZyte6NuKL4nTZuMUxsGZTud6SelW6aV5MQ DJTtIX3YgRosT+D5rREtNHBoj3Dm4+mjTzVbGxpNe4Irp5hZXnIDNOyvYB/mJ9q1 oljOwItpt2NGPUhkOVxF4yklZaMdRA== =wcAE -----END PGP SIGNATURE----- --Apple-Mail=_F9012C98-0570-4923-A251-DCEA3E0F5987-- From nobody Fri Jan 29 14:24: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 020563A133D; Fri, 29 Jan 2021 14:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FaOIKrrYYyso; Fri, 29 Jan 2021 14:24:29 -0800 (PST) Received: from hans.rg.net (hans.rg.net [IPv6:2001:418:1::42]) by ietfa.amsl.com (Postfix) with ESMTP id F20C73A133A; Fri, 29 Jan 2021 14:24:28 -0800 (PST) Received: from [IPv6:2601:1c0:cb00:5dd1:9022:6e1:d68:78f2] ([IPv6:2601:1c0:cb00:5dd1:9022:6e1:d68:78f2]) (authenticated bits=0) by hans.rg.net (8.16.1/8.15.2) with ESMTPSA id 10TMOKa8058113 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NOT); Fri, 29 Jan 2021 22:24:23 GMT (envelope-from llynch@civil-tongue.net) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) From: Lucy Lynch In-Reply-To: <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> Date: Fri, 29 Jan 2021 14:24:14 -0800 Cc: "Joel M. Halpern" , rfced-future@iab.org Message-Id: <3091F0DD-3D30-41E2-8F8A-58C9CACBC923@civil-tongue.net> References: <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> To: Eliot Lear X-Mailer: iPad Mail (18C66) Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 22:24:31 -0000 > On Jan 29, 2021, at 10:42 AM, Eliot Lear wrote: >=20 > =EF=BB=BFIs there a middle ground here in which the RSE/A acts as an ex-of= ficio non-voting member of the approval body, who can raise issues that woul= d =E2=80=9Cbreak the series=E2=80=9D but have to garner some amount of suppo= rt from voting members to halt a proposal? Not for me - I strongly believe that the RSE/A needs active inclusion and a v= oting role here. The long term health and usability of the series for all th= e use cases outside of steam authors must have weight in these discussions. A= body composed of just the stream editors will be to short sighted and if th= e RSE/A is included it should be as a full member. > This would move the ballgame to what does it mean, =E2=80=9Cbreak the ser= ies=E2=80=9D. >=20 > Eliot >=20 >> On 29 Jan 2021, at 16:06, Joel M. Halpern wrote: >>=20 >> I would like an approach along the lines of the IESG discuss where one ob= jector forces serious discussion, but unless that objector can get support, t= hey eventually have to yield. I can live with a majority vote proposaal (wh= ich would require the RSE/A to be able to get two supporters to block someth= ing.) >> What I was commenting on specifically was those who were objecting to giv= ing the RSE/A a veto, when that was not what was asked. >>=20 >> I understand from EKRs response to my message that even with those approa= ches, he does support this, and wants only community appointed people having= any say in the approval. >>=20 >> I do not see how to get past so fundamental a degree of disagreement. But= I hope we can. >>=20 >> Yours, >> Joel >>=20 >> PS: I suspect Stephen has a good point that focusing on the documents may= cause us to miss important aspects of what we are discussing, even if we (r= easonably) assume that all decisions need to end up documented. >>=20 >>> On 1/29/2021 9:07 AM, Mirja Kuehlewind wrote: >>> Hi Joel, >>> I think what we discussed to far and what people might have on their min= d is a ballot-like model as used by the IESG where every single DISCUSS posi= tion blocks publication (and not a majority voting which you seem to have on= mind, right?). >>> Mirja >>>> On 29. Jan 2021, at 14:04, Joel M. Halpern wrote:= >>>>=20 >>>> I hope that I am misreading Adam and EKR. As far as I can tell, they a= re arguing against a proposal no one made. >>>>=20 >>>> What I suggested was that the RSE/A be a full member of the approval bo= dy with an equal vote with the stream manager. I explicitly noted that this= would mean that under most voting regimes this would require the RSE/A to b= e able to persuade at least one stream manager to agree with them about the i= mportance of whatever problem they are raising. It might even require them t= o be able to get two stream heads to agree with them. Other folks phrased t= his in terms of the discuss procedure, with the same kind of discuss over-ri= de that the IESG uses (which in this case would mean that the 4 stream heads= could over-ride a discuss by the RSE/A). >>>>=20 >>>> It may be that one proposal called for the RSE/A to have a full veto, b= ut that is not what I have seen folks asking for, and not what I asked for. >>>>=20 >>>> Yours, >>>> Joel >>>>=20 >>>> On 1/29/2021 12:28 AM, Adam Roach wrote: >>>>>> On Jan 28, 2021, at 21:11, Brian E Carpenter wrote: >>>>>>=20 >>>>>> =EF=BB=BFA point below which may appear picky but is actually fundeme= ntal to this disagreement: >>>>>>=20 >>>>>>> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: >>>>>>>> On 29/01/2021 09:17, Eric Rescorla wrote: >>>>>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter >>>>>>>=20 >>>>>>>>> If we select this person on the grounds that they know more about t= echnical >>>>>>>>> publishing than the rest of us do, that seems like exactly what we= need as >>>>>>>>> a finger on the DISCUSS button. >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> We engage a lawyer who is also an expert on topics that we are not,= and >>>>>>>> which are rather more consequential if we screw them up, and yet we= don't >>>>>>>> give them a veto. >>>>>>>=20 >>>>>>> The expertise of lawyers is more widely acknowledged by most >>>>>>> participants because most participants are more accustomed to deal w= ith >>>>>>> lawyers, and know that some stuff has to be left to the lawyers. Als= o, >>>>>>> lawyers are more used to attempts to screw them up, and know what to= >>>>>>> ignore, how to defend themselves, and so on. It's difficult to imagi= ne >>>>>>> that a lawyer would quit because they were treated as "just a >>>>>>> contractor", because being treated as "just a contractor" wouldn't >>>>>>> happen to the lawyer in the first place, or only to the extent that t= hey >>>>>>> would be used to be as part of their usual business. >>>>>>>=20 >>>>>>> This seems to be quite different for an expert in technical publishi= ng. >>>>>>> They are not licensed, they don't have any arms to twist, and so on.= >>>>>>>=20 >>>>>>> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS >>>>>>> formally is a veto, but many DISCUSSes have been retracted without t= he >>>>>>> raiser having gotten exactly what they originally proposed. >>>>>>=20 >>>>>> No, a DISCUSS is *not* formally a veto. It is quite narrowly defined >>>>>> and there is a procedure for overriding a DISCUSS. See >>>>>> https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criter= ia/ >>>>>> Indeed, a similar definition and procedure would be appropriate in >>>>>> this case too. >>>>> The most important aspect of a DISCUSS ballot is that, if an AD holdin= g it is alone in their conviction, the position can be overridden =E2=80=94 o= n substance, not process =E2=80=94 by the remaining ADs. I have grave concer= ns about allowing someone to be alone in their disagreement (expert or not) w= ithout recourse. >>>>> /a >>>>=20 >>>> -- >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future >>=20 >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Fri Jan 29 18:59: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 D24863A0475 for ; Fri, 29 Jan 2021 18:59:16 -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 gxFBTm9xo41M for ; Fri, 29 Jan 2021 18:59:14 -0800 (PST) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C16EF3A046B for ; Fri, 29 Jan 2021 18:59:14 -0800 (PST) Received: by mail-vs1-xe30.google.com with SMTP id v19so5939325vsf.9 for ; Fri, 29 Jan 2021 18:59:14 -0800 (PST) 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=t8rpxWVLcX+bCBbleMruq8oiGe3gamnkgCSYCCARYLA=; b=Z7Hp5p+cnyOnLHdZ2Zw/KVYoOqhgVVxB1oJH3EyZr5B3y56j5X8cNfNMTQiRcyhXzZ +o75XYYLsZckjO7tgbKj8NvTMj2o87ppW9b7NkEA2ke/eRCiHLWvX4MoCImhSDXnaaMW WGW6f5p6ehWGQLxBuaSrHxFyP/chuzoY3PqjDdm+G7/cyt1BfyQme6f6C3BSLjtTqZLb oSeVnU10hnJBLbFKhGGn9dyupDYdK12MHhx5/CHkJz4aVJQWV2acTHUMUQADzZU8EWDr SyotlXQ+WTn8paPpqZE0jI6lp5dnw4usIVbjpNsd4k4pHc0uyNPRiVVKDp/iKeM3yX3B xiAQ== 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=t8rpxWVLcX+bCBbleMruq8oiGe3gamnkgCSYCCARYLA=; b=KjMbMLcNN3Nos/WuXKBNQe0YUYNqc805HKKV0UlBcgWzOC6gws2sZSkt48+i3o3K17 xz4rFCeUC5ALN4Lnoxt7xtIHexksIB2oAGYVBkezsoC45XVaIR0HkMKf0kz8k3JLVndp YArFm/t1mwCWkFnU4FW2qzLzN9ieoxLqHPj4n/ULaFhdpqPrSeBgBcZz3IfGbt7x9fwO XBOgH1WzJJK9wzG2/2sLYaF8RQRvtidhjkypF2+S7NiJfCvWxzdbUS+h2C9sqLJ31MRg EiFCXsK90DJpK8gxxUsKmTodoIWJ/wQkLvcfFYRH8PMps5wliAMaRiV6fgVZRN1U3mqh Ej+g== X-Gm-Message-State: AOAM532uQQHv4m5F2odvF/w8IUI6zLzXIbP++dvc0JV5UQbutFFRuoK4 AhgPkm1ZKho6LstyT9DEPTE29jCds9KAbcwgbpM6dck0Yztj2g== X-Google-Smtp-Source: ABdhPJzoNOJblb3/IXHaG87tLIi0jlXHhPrJjwa+oGD1ejE1WjdNu8wpoBufrShOa8ZL9SfGTqsHP0HsCur33pF8Tf4= X-Received: by 2002:a67:300b:: with SMTP id w11mr4911686vsw.26.1611975553484; Fri, 29 Jan 2021 18:59:13 -0800 (PST) MIME-Version: 1.0 References: <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> <3091F0DD-3D30-41E2-8F8A-58C9CACBC923@civil-tongue.net> In-Reply-To: <3091F0DD-3D30-41E2-8F8A-58C9CACBC923@civil-tongue.net> From: Nevil Brownlee Date: Sat, 30 Jan 2021 15:58:46 +1300 Message-ID: To: rfced-future@iab.org Cc: Nevil Brownlee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2021 02:59:17 -0000 Hi all: I reckon there's a lot of pointless argument on this list! The RSE/A does not have veto powers over the rest of the oversight committee, a workable consensus is needed for every proposed change. Also, I agree completely with Lucy - the RSE/A eeds active inclusion and a voting role here. Also, the RSE/A does not have veto powers over the rest of the oversight committee, a workable consensus is needed for every proposed change Cheers, Nevil On Sat, Jan 30, 2021 at 11:24 AM Lucy Lynch wrote= : > > On Jan 29, 2021, at 10:42 AM, Eliot Lear wrote: > > > > =EF=BB=BFIs there a middle ground here in which the RSE/A acts as an ex= -officio non-voting member of the approval body, who can raise issues that = would =E2=80=9Cbreak the series=E2=80=9D but have to garner some amount of = support from voting members to halt a proposal? > > Not for me - I strongly believe that the RSE/A needs active inclusion and= a voting role here. The long term health and usability of the series for a= ll the use cases outside of steam authors must have weight in these discuss= ions. A body composed of just the stream editors will be to short sighted a= nd if the RSE/A is included it should be as a full member. > > > This would move the ballgame to what does it mean, =E2=80=9Cbreak the = series=E2=80=9D. ----------------------------------- Nevil Brownlee, Taupo, NZ From nobody Fri Jan 29 19:25:09 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8873A08ED for ; Fri, 29 Jan 2021 19:25:07 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2knqkM8kO3l0 for ; Fri, 29 Jan 2021 19:25:02 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id B6D283A08D6 for ; Fri, 29 Jan 2021 19:24:56 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.41.76]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 10U3OQPT023248 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 29 Jan 2021 19:24:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1611977095; x=1612063495; i=@elandsys.com; bh=58xZ/OW+1lX5QqYfQCmmmCdsValOx4/ZzgMTyceYN4U=; h=Date:To:From:Subject:In-Reply-To:References; b=xqCCX6uKieQK5Npq2QsnUpI+9mpXcoF2qb2ouR1CM1gA2SbWAjek2RojomOwNccNS WdY+HY4PXwU4pZ0FbwnFIOxg2eQ2wb2+qzQf1JfsHfItBQ0GCBwfYbln6XKNCUB+Ty xbkTS7ikSrTNiPJmisKfBDZ1xEclwnmEQItd+Dy8= Message-Id: <6.2.5.6.2.20210129192046.07efeb30@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Fri, 29 Jan 2021 19:24:05 -0800 To: rfced-future@iab.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2021 03:25:07 -0000 Dear Program Chairs, Is there a Last Call on a proposal? Regards, S. Moonesamy From nobody Sat Jan 30 00:54: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 5CE813A0C84 for ; Sat, 30 Jan 2021 00:54:01 -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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dS1oD7A8qT4B for ; Sat, 30 Jan 2021 00:53:57 -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 2EAB53A0C82 for ; Sat, 30 Jan 2021 00:53:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1261; q=dns/txt; s=iport; t=1611996837; x=1613206437; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=WhOqrMM8kP+99x6LgLbG0SqQ3Bx7jwjG68cWKlFdoGo=; b=erbqES+lMVv4uZwl9MJ8lOG8Pq3gDT/ynuqVRr0T8cWaAe4WwA3ZmtZL JaOuGVAGmkLwsoU96vjc/iPKp90bdEtxYI7Rq5GXLJehhsuEMWYeqM63w UHFs2e8Eu/vgFGTMVgDYv0pohXikSIeV121kZ0vvyRvwwwZonYHaVXFsR M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BqAAAVHhVgjBbLJq1iHQEBAQEJARIBBQUBQIE9BgELA?= =?us-ascii?q?YN2ASMSL41EiCsokFSJcxSBaAQHAQEBCgMBAS8EAQGESgKBeSY2Bw4CAwEBA?= =?us-ascii?q?QMCAwEBAQEFAQEBAgEGBBQBAQEBhkeFcwEBAQMBeQULCxguVwYTFIMSAYJmI?= =?us-ascii?q?LMkdIE0hVmEaxCBOAGBUotrQYIAgTgMEIJWPoQEhAeCLASDLoFYS2GcPpw2g?= =?us-ascii?q?wCDKYE4lxQDH4McAZAGj2GyGINxAgQGBQIWgV0MJYFZMxoIGxVlAYI+PhIZD?= =?us-ascii?q?Y47HY4TQAMwNwIGCgEBAwmMFQEB?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,387,1602547200"; d="asc'?scan'208";a="33008917" 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 Jan 2021 08:53:53 +0000 Received: from [10.61.249.9] ([10.61.249.9]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 10U8rqq8016612 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 30 Jan 2021 08:53:53 GMT From: Eliot Lear Message-Id: <410B0496-789D-4579-8454-779CADCE0074@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_F0198B74-F6FC-4989-B55A-C18FA7300674"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Sat, 30 Jan 2021 09:53:51 +0100 In-Reply-To: <6.2.5.6.2.20210129192046.07efeb30@elandnews.com> Cc: rfced-future@iab.org To: S Moonesamy References: <6.2.5.6.2.20210129192046.07efeb30@elandnews.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.61.249.9, [10.61.249.9] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2021 08:54:01 -0000 --Apple-Mail=_F0198B74-F6FC-4989-B55A-C18FA7300674 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi SM > On 30 Jan 2021, at 04:24, S Moonesamy wrote: >=20 > Dear Program Chairs, >=20 > Is there a Last Call on a proposal? Not for any particular draft. However we have completed a number of = consensus calls. I will send separate messages on that. Eliot --Apple-Mail=_F0198B74-F6FC-4989-B55A-C18FA7300674 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAVHp8ACgkQh7ZrRtnS ejOj0wf/VTc4TgIqo/Oj33vX84z4Ro+bc0w1bdIOvDDAobwB02NUdt8qWQVCeG55 Upk59fr+LIl7Ur0xdJdT9LgrjTrvXv+DeyXSd8saeblOdxp1p2jwawgZN3IZx1+H Vi1S626CVdU18U6eyx72nkmsYKblPoflFUqYCjBJawvTttJewINeXytqgACK1r93 QIG6AOFhlxR6boOk2LwQ8WKZBL3iOxRI1jHZ791COXUjZzubKl6kdQlfvAcjAfrr 0ViHs1snE/FGOpTtR02Ffv77a7abaXQ2e4DGKHm3Bl6h/CiiDSB95k0NybKv0Y7h SmcAzzF/F8WfGTaNngePxNNPPEncTQ== =Ouzo -----END PGP SIGNATURE----- --Apple-Mail=_F0198B74-F6FC-4989-B55A-C18FA7300674-- From nobody Sat Jan 30 16:55:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02BB53A12A5 for ; Sat, 30 Jan 2021 16:55:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r-Bhk9lRQBw6 for ; Sat, 30 Jan 2021 16:55:47 -0800 (PST) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4E93A12A4 for ; Sat, 30 Jan 2021 16:55:47 -0800 (PST) Received: by mail-pj1-x1031.google.com with SMTP id e9so8831502pjj.0 for ; Sat, 30 Jan 2021 16:55:47 -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=bMdZJ3K38VHajftS9BWmLu2/rABYcY46TvBX95ciqzE=; b=DPxUQEc8CovhSeEkymQNm0JQ4KK4h7HmSDbFERPQlzfG1iIRAxf542iGOiUAVG33d6 PcLrERg6bcvFdVokhXkh3lz64yjWXYK4qZje+EwXFYPbcqaJazjwqvaygsXSnCU0a2CZ s8j1vdhwYeFRZOrwDeIpEqRN/7n6jv2ufladhp7fQ0e6ws64vw1q8GTrZxXFLxGfPoHm veGl9o1HQfe6mjHANvIAqAyTUxGit/7vSAjelqHiaOj0UfSU87p7Yotc5gu2dmXHpPsz SakxjaoqklcHsn5qluvixdCAr109/c9GNM2DNASk7mHv/efteVRQRb1LMSa96nIZT86z EGug== 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=bMdZJ3K38VHajftS9BWmLu2/rABYcY46TvBX95ciqzE=; b=a5cLOEQEs0xDJx+qO0DApAEMLyGqTeBt3Jpytkbdd2B8KAwOB2XoSfTW6b08fYK3R3 iz9SM3U4Hh7KN/+yZVceQrmGYvhyZep709V6sjO2KmIPjx5KxRdaeDu3+cNh2JYymp+w ds8cucaw1OgwMJEgRnb0XK9KhhZcmVtxUFL8p2vLAq3piR2WRukp68c09/xby4ASw2BN IFef2N3iicn0prsS5YCz5cbJoZ1cBm4Kd2ysa49BYB2IC2nS1opplRYSpv4hO+CsOldw Cj4Q2MHMD3v7xLyq0DS3fUrNOfnnc0YrUhCsNm+PlTX8g+j9gPHyXas5i2LXhd5sE0Jm LMHw== X-Gm-Message-State: AOAM5335s7WermCBQXUciR8Tgo6Hs53GpIAw8v8LGby1sYlPHaCUIEbx LLEDf2PeHPIKxyiOYU6JOd8= X-Google-Smtp-Source: ABdhPJyQC4KC0os5/flxKNzzj7XCzKA3oOa+suj6RBn/yCLBsGei/6azQhYBs2zQH+RtyGgsREjfGg== X-Received: by 2002:a17:90a:670f:: with SMTP id n15mr11155820pjj.175.1612054546742; Sat, 30 Jan 2021 16:55:46 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id b67sm13006922pfa.140.2021.01.30.16.55.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jan 2021 16:55:45 -0800 (PST) To: Eliot Lear , rfced-future@iab.org Cc: Brian Rosen References: <49944C8E-1089-4CE0-B215-4AB6403C1359@cisco.com> From: Brian E Carpenter Message-ID: <5ae24238-3f8a-878d-0121-04ccaa18d181@gmail.com> Date: Sun, 31 Jan 2021 13:55:40 +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: <49944C8E-1089-4CE0-B215-4AB6403C1359@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Draft minutes for 12 jan meeting 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: Sun, 31 Jan 2021 00:55:49 -0000 Hi, I just noticed this phrase: > All strategic body meetings are open to any participant, subject to Note Well provisions. The explicit mention of "Note Well" seems strange. Firstly, it's IETF jargon, which would be unclear to the public at large. But more to the point, the wording of the Note Well is very specific to the IETF rules. So while I agree with the spirit, I think the actual words need to be more generic, such as "subject to defined and published rules of participation." Regards Brian Carpenter On 26-Jan-21 20:19, Eliot Lear wrote: > Please note, these are likely to be updated once more as they do not yet incorporate the jabber discussion. > > https://datatracker.ietf.org/meeting/interim-2021-rfcefdp-01/materials/minutes-interim-2021-rfcefdp-01-202101122000-00.html > > From nobody Sat Jan 30 17:06: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 960403A12AD for ; Sat, 30 Jan 2021 17:06: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=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 N1pUSRubMOPs for ; Sat, 30 Jan 2021 17:06:04 -0800 (PST) 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 F18483A12AC for ; Sat, 30 Jan 2021 17:06:03 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id f63so9095662pfa.13 for ; Sat, 30 Jan 2021 17:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=vON5Nl8aP1IuxNMGnfYrQVJeQbA0KIfNQSnSUTWB5Zk=; b=bMbKnYRvWyX14DJ+8k1DN3d+aIkkvLQfzAGN2LAjb/S1l9AWVRq6+JbfZJoc/oS/zR KW11D269GqU4gb2JOuXNKsR1XvgmryxSDz1lv0m4SqIQ23TED5QYalYa/njWP0UKn0Ui JsgW7LSl9KJe4jHNrF9Y+qBYWlo3tB66rtvh6OpqmrT3amDUrz9/duGCMOYDn929CAJk KtvtGDzMFZkCMfVBBcIyoyiZ8FzGkSL2xS6wKtC/R1y610CLGtWfLAVTC0s+H5EiHsTl FjQvKSn8bUoYnqX5YALISNwSN4+ssDby5UOD64g/4Gjj2tgWpB1jA8BrkRQxRmEx2rGx 6XAA== 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=vON5Nl8aP1IuxNMGnfYrQVJeQbA0KIfNQSnSUTWB5Zk=; b=PJ2jeD0UYcuULfnmkdGgd90d+DThLEn7lp+sba3YusliQGn5T8G4vSbt5zTpAyLmWN FwXELREV3MZb/izfMaXXG3/rPDd5fpLotoRw9l57q0+HcOdgTabzkVgliUkBSl8QuvXo 9wrkspipwdf5R8xLzl2kYbS3Xjd33/jSvCgXFo9kdS0YgBmw29jAES0Ribf/KpW4uiPA JgEikcgwUg1mTxqvTduxSLRj1EOGvGTdCzTJE7yVTJFC8baij18wwYTqCicwfqgGUQQI Bn45jg2XLjZS/9EtboEcvMHYm0Nt+fC4KxGlckbnseyj+7KkxBTOrFBQaz9wVKKXE8v0 ZiRg== X-Gm-Message-State: AOAM533NTFCqQNRUWQep/rdLeOJXe4g09z/9O36875Tjjn6On0PI/0TR RAO61pkLKUqOuxFNKN7rF1OiRESr7OG9Uw== X-Google-Smtp-Source: ABdhPJzLDfbuscS9xY1tLtjdo/7+2/LFKQ+IybzvLTHanbuGhOVp/Y1rKWuDhcEYbVpS0rSGZxELUg== X-Received: by 2002:a63:1458:: with SMTP id 24mr10823474pgu.441.1612055162977; Sat, 30 Jan 2021 17:06:02 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id k15sm13087280pfi.94.2021.01.30.17.06.00 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jan 2021 17:06:02 -0800 (PST) To: adrian@olddog.co.uk, rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> From: Brian E Carpenter Message-ID: <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> Date: Sun, 31 Jan 2021 14:05: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: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 01:06:07 -0000 On 30-Jan-21 02:11, Adrian Farrel wrote: ... > So my questions are: Who is the advocate for the under-represented > stakeholders? Whose job is it to actively search out relevant opinions? Who > has the role of champion for these groups of RFC consumers to make sure that > the decisions the WG make do not negatively impact them? We could, of course, specify this as one of the things the RSA/E should handle. I'd certainly have felt it as a very natural job for the RSE in the previous regime. I do agree that it's important. Newspapers that ignore their readers soon don't have many readers. Brian C From nobody Sat Jan 30 23:51:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B14053A0BDF for ; Sat, 30 Jan 2021 23:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvYFPID3DDQ8 for ; Sat, 30 Jan 2021 23:51:46 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 506F13A0BDE for ; Sat, 30 Jan 2021 23:51:46 -0800 (PST) Received: from xse271.mail2web.com ([66.113.197.17] helo=xse.mail2web.com) by mx135.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1l67WK-0019KM-1u for rfced-future@iab.org; Sun, 31 Jan 2021 08:51:45 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4DT3Dp02qvz2178 for ; Sat, 30 Jan 2021 23:51:38 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1l67WD-0004Rd-So for rfced-future@iab.org; Sat, 30 Jan 2021 23:51:37 -0800 Received: (qmail 9318 invoked from network); 31 Jan 2021 07:51:37 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.250]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 31 Jan 2021 07:51:37 -0000 To: Brian E Carpenter , adrian@olddog.co.uk, rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> From: Christian Huitema Message-ID: Date: Sat, 30 Jan 2021 23:51:38 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: 66.113.197.17 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/HyzyXAr7dmxeoxCoydHLpPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KodY kzIbZiMbhiRbuXNd1zGonaNQbqJUPRwZtKOTN8gOSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVR4viV7miyo7GvEGp97Zbg5otTbzF8bFslzcWfB/84WVsvCwp YJpdb4B2L4Z5wQyKkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkgOaZXY1D 3Tei6L4lTC3Kzv6blagzf/fouhj8KehojfmLb5mum9xAXSaS3KKPtTZXWZip9+GhedmPokL8D3vh veYLhIg92+wH02ylfDiSQ0sYFBl6VX84fRovDGikEvLu7vlxwPg5iSJU22qtYbc2zIvhSJcbnX/H QqL/X9rNCJCc6iESJvKm1NV8gkr+Wu8ScVDXinOVyuIpITQ9z3M3DCinc6hm4Yij/9/ori/8mFXM bF4myMzDGDFHZjM6aMr8FM9Os16ieQbW7HL304rcjkQ8sY6azDfvavJWi0ECJgjYpEFoi75E4I64 qGaGHDSiyaxfFQ1w34FqYc4W3dbMgAFVnde1UJCYLdcfX0Bx8d2pY65+CGBwo5OtuZ2LpuKwLlgf bQDdFkvXx/UUTxjhC65769TqbX47GQon7bvTbe+HPMGUwtWP9AHlR07AVfzMXPWlFdaGOH191uXj gjQN/QhIsG4cAWAFT3uQUJNI4qF7ZQBqyc1GyCr/v+u82V37vPhDHbllA+YkdR5e+mX9LKCtiQUJ 9KD/MrpHctjQnvLvpZLSAr3jBzAtGBhZHAsUZRWsGw8ac2InzcAP/gmxwN0KNlbBL2b62GY/uj4p NNGN5GEk3PlEMsNY2LGpB08V6U0LjBzYuQztdAThgtWSU38npyyk2aAnE8r1sSEhcpI= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 07:51:48 -0000 On 1/30/2021 5:05 PM, Brian E Carpenter wrote: > I do agree that it's important. Newspapers that ignore their readers > soon don't have many readers. Yes, it definitely is important. But I hardly believe that this is mostly related to the technicalities of managing publication. When we publish specifications for Internet protocols, we want to make sure that these protocols get implemented and deployed. Yes, the documents describing these protocols should be easy to read. But they should also address real problems and solve them through good engineering practice. That's not something to delegate to just a few publication experts. That's a task for the entire community, and especially for the IETF leadership. -- Christian Huitema From nobody Sun Jan 31 01:26: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 56D1C3A0A02 for ; Sun, 31 Jan 2021 01:26:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adLEbEimfaUY for ; Sun, 31 Jan 2021 01:26:15 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE8E3A09FA for ; Sun, 31 Jan 2021 01:26:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8181; q=dns/txt; s=iport; t=1612085175; x=1613294775; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=uucXrZAW8pjHmzhX0YxK9fjIYmTGUTSe9yMgDPGj5kI=; b=k+lE242o8HEI+T6JFRyB6mgZMEEcA+guWsmLmz7I273+YhqfD2cjNdwX IwWL2VUvHy9orckmdoni6EtE+SLEAYabfnzf2xZ7nO2ggsdKAnbcbRcJ1 VQM1t+VWc8wfMA7/xkhtxV9PdTgRmNNmjPFdEObcRXpiQ8TA0RI89jg+y Q=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0CpAAAcdxZgjBbLJq1iHAEBAQEBAQcBARIBAQQEAQGBf?= =?us-ascii?q?gQBAQsBgyBWASMSMIRAiQSIKiUDih2KCYY1gWgEBwEBAQoDAQEnCAQBAYRKA?= =?us-ascii?q?oF5JjcGDgIDAQEBAwIDAQEBAQUBAQECAQYEFAEBAQGGOg2FcwEBBAEjSwsFC?= =?us-ascii?q?yMqAgIhNgYTgyYBglUDDiAPsnJ2gTKERAIBgRKCOg2CFgoGgTgBgVKFKIIth?= =?us-ascii?q?BZBggCBOAwQgihsghtCAgECgR6DVzSCLASBVBFjYkcOAiBGCw8RM06QEIxVm?= =?us-ascii?q?yc5WoMAgymBOYRSjSSFJQMfgy+KPYU/iXKFdp9Ogn+PUoNyAgQGBQIWgWwiL?= =?us-ascii?q?IEtMxoIGxVlAYI+EysSGQ2OOx2IToVFQAMwAjUCBgEJAQEDCYwVAQE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.79,390,1602547200"; d="asc'?scan'208,217";a="33086094" 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; 31 Jan 2021 09:26:10 +0000 Received: from [10.209.198.254] ([10.209.198.254]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 10V9Q96B020703 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 31 Jan 2021 09:26:10 GMT From: Eliot Lear Message-Id: <0EA9E312-A795-4208-BF94-4B12C9D62311@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8067AE0D-14BF-4366-8A85-8A940FBEB30B"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Date: Sun, 31 Jan 2021 10:26:08 +0100 In-Reply-To: <5ae24238-3f8a-878d-0121-04ccaa18d181@gmail.com> Cc: rfced-future@iab.org, Brian Rosen To: Brian E Carpenter References: <49944C8E-1089-4CE0-B215-4AB6403C1359@cisco.com> <5ae24238-3f8a-878d-0121-04ccaa18d181@gmail.com> X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Outbound-SMTP-Client: 10.209.198.254, [10.209.198.254] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] **Consensus Check** Issue 13: Is participation in the strategy body is open to all? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 09:26:17 -0000 --Apple-Mail=_8067AE0D-14BF-4366-8A85-8A940FBEB30B Content-Type: multipart/alternative; boundary="Apple-Mail=_E14D5AB7-CDC5-4E1B-A92B-BAE3FDC8564C" --Apple-Mail=_E14D5AB7-CDC5-4E1B-A92B-BAE3FDC8564C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian, Thank you. Yours was one of three comments that need addressing: EKR: see that we have an anti-harassment policy John Klensin performed a review of BCP 25 (thank you again, John. The = punishment for your good deed is at an end (for now)). Brian: tweak to make less IETFy. Here=E2=80=99s the resultant text. Please comment no later than 12 = February, but see below before you do. > All strategic body meetings are open to any participant, subject to = intellectual property policies that are 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 strategic body 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]. I propose that we leave it to the document editor to propose what it = means to be consistent with RFCs 2418 and Note Well, based on John = Klensin=E2=80=99s latest note, or whether that person recommends that = the first document out of the new WG contain such amendments. If we = need to circle back on such things later, we can do that once we have = more of the structure fleshed out. **CAUTION** Please avoid bike shedding on a matter on which we largely agree. I you = have a real problem, speak now. Otherwise, we really have to be moving = on. Eliot > On 31 Jan 2021, at 01:55, Brian E Carpenter = wrote: >=20 > Hi, >=20 > I just noticed this phrase: >=20 >> All strategic body meetings are open to any participant, subject = to Note Well provisions. >=20 > The explicit mention of "Note Well" seems strange. Firstly, it's IETF = jargon, which would be unclear to the public at large. But more to the = point, the wording of the Note Well is very specific to the IETF rules. >=20 > So while I agree with the spirit, I think the actual words need to be = more generic, such as "subject to defined and published rules of = participation." >=20 > Regards > Brian Carpenter >=20 > On 26-Jan-21 20:19, Eliot Lear wrote: >> Please note, these are likely to be updated once more as they do not = yet incorporate the jabber discussion. >>=20 >> = https://datatracker.ietf.org/meeting/interim-2021-rfcefdp-01/materials/min= utes-interim-2021-rfcefdp-01-202101122000-00.html >>=20 >>=20 --Apple-Mail=_E14D5AB7-CDC5-4E1B-A92B-BAE3FDC8564C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hi Brian,

Thank you.  Yours was one of three comments that need = addressing:

  • EKR: see that we have an = anti-harassment policy
  • John Klensin performed a = review of BCP 25 (thank you again, John.  The punishment for your = good deed is at an end (for now)).
  • Brian: tweak to = make less IETFy.

Here=E2=80=99s the resultant text.  Please comment no = later than 12 February, but see below before you do.

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

I propose that we leave it to the = document editor to propose what it means to be consistent with RFCs 2418 = and Note Well, based on John Klensin=E2=80=99s latest note, or whether = that person recommends that the first document out of the new WG contain = such amendments.  If we need to circle back on such things later, = we can do that once we have more of the structure fleshed out.

**CAUTION**

Please avoid bike = shedding on a matter on which we largely agree.  I you have a real problem, speak now.  Otherwise, we really = have to be moving on.

Eliot


On 31 = Jan 2021, at 01:55, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Hi,
I just noticed this phrase:

   All = strategic body meetings are open to any participant, subject to Note = Well provisions.

The explicit = mention of "Note Well" seems strange. Firstly, it's IETF jargon, which = would be unclear to the public at large. But more to the point, the = wording of the Note Well is very specific to the IETF rules.

So while I agree with the spirit, I think the = actual words need to be more generic, such as "subject to defined and = published rules of participation."

Regards   Brian Carpenter

On = 26-Jan-21 20:19, Eliot Lear wrote:
Please note, these are likely to be updated once more as = they do not yet incorporate the jabber discussion.

https://datatracker.ietf.org/meeting/interim-2021-rfcefdp-01/ma= terials/minutes-interim-2021-rfcefdp-01-202101122000-00.html



= --Apple-Mail=_E14D5AB7-CDC5-4E1B-A92B-BAE3FDC8564C-- --Apple-Mail=_8067AE0D-14BF-4366-8A85-8A940FBEB30B 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmAWd7AACgkQh7ZrRtnS ejM+rQf+MjeQHHWqThmdxr0FXdmVHQGEFKZGozSLzpIk4CYYh7VO8aDBEj4fCqK2 mbyGzukQluMJY7Kf2j/DLJZieHCe7JjdUh/czmDxhVrOJVlLr0L3t6e+poQ1WUWk o02rlTolFuvIMYb3wdN3qZX9lLzZ6wbXtyOqaY2bQi82OOMzHlHhbKk3R1tJF6aS v4wrV4NDqkUPYqFJH8wUGfq4qlfIo+286f/SHUYcbbtEYcrMXRe9r7xryM9C+q46 P+r1PdPSMmRe3P/q1bonmpGPCnNOHBXuuCHwt1V3mJZLBBbpTxm+MAezkJRU4wy0 7CsD5WyRvdcc9x1vJnwR5Ov7EKxgdw== =qeaM -----END PGP SIGNATURE----- --Apple-Mail=_8067AE0D-14BF-4366-8A85-8A940FBEB30B-- From nobody Sun Jan 31 03:09:28 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 388903A0BF7 for ; Sun, 31 Jan 2021 03:09:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 5Vovgmmhi4Eb for ; Sun, 31 Jan 2021 03:09:25 -0800 (PST) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B143A0BF3 for ; Sun, 31 Jan 2021 03:09:24 -0800 (PST) Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 10VB9JB9032122; Sun, 31 Jan 2021 11:09:20 GMT Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CFB9522044; Sun, 31 Jan 2021 11:09:19 +0000 (GMT) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs2.iomartmail.com (Postfix) with ESMTPS id BAEAF22042; Sun, 31 Jan 2021 11:09:19 +0000 (GMT) Received: from LAPTOPK7AS653V ([84.93.31.76]) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 10VB9IOU032585 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 31 Jan 2021 11:09:19 GMT Reply-To: From: "Adrian Farrel" To: "'Christian Huitema'" , "'Brian E Carpenter'" , References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> In-Reply-To: Date: Sun, 31 Jan 2021 11:09:19 -0000 Organization: Old Dog Consulting Message-ID: <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIxOzb1K7FOVzc7vzw9Sqa6JmeniwKczi4xAXwnpoqpbESEcA== Content-Language: en-gb X-Originating-IP: 84.93.31.76 X-Thinkmail-Auth: adrian@olddog.co.uk X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-25942.003 X-TM-AS-Result: No--5.553-10.0-31-10 X-imss-scan-details: No--5.553-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25942.003 X-TMASE-Result: 10--5.552800-10.000000 X-TMASE-MatchedRID: byfwvk+IcRnxIbpQ8BhdbLzgL/eLACDEUUf+3caqXwKu3rQv8dm85SDY CKQAPC7jYEscYzb7nbbX5LP4TxoD+UblpaxJfSRzNOTokZutCG6rDPxf3LbqpN95RnTaoXbSiY7 hQw7btzf55RHsOadGlzcxJfIcnxZ9Q8+LSipOfwSyaXLtlwnZHCvoW4znCb0dtXl9IxEPXOohlG 9iTcYtat2871Os2vZwyV9Z03l5ASPviLZq0+Z2NudNi+0D4LmKmJEP17UT6evggFPPs+IAaXsyg Y4tPtxeKw3AB667zKeFDet6pUjZENGhojt61Qb98irf7wNB3Sj3Jf81Zy+zdNZd/DOmlnxIIQwd t8FiOhQVsSBpN3nvmKZ6wxB0+Iq69V2JvI8fDHJEdW06rtEkZH0tCKdnhB58GtkvK5L7RXGw7M6 dyuYKg/cUt5lc1lLglxhPCV6M7c3MH85EPsIlHAE4UPtuMaXufNzLar0jDDSSATvuUuWGWa3hd0 jehzTdlExlQIQeRG0= X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 11:09:27 -0000 Christian, You make my point for me, thank you. I ask again, in our new proposed format: Who is the advocate for the = under-represented stakeholders? Whose job is it to actively search out = relevant opinions? Who has the role of champion for these groups of RFC = consumers to make sure that the decisions the WG make do not negatively impact them? Regards, Adrian -----Original Message----- From: Christian Huitema =20 Sent: 31 January 2021 07:52 To: Brian E Carpenter ; = adrian@olddog.co.uk; rfced-future@iab.org Subject: Re: [Rfced-future] The voices of stakeholders On 1/30/2021 5:05 PM, Brian E Carpenter wrote: > I do agree that it's important. Newspapers that ignore their readers > soon don't have many readers. Yes, it definitely is important. But I hardly believe that this is=20 mostly related to the technicalities of managing publication. When we=20 publish specifications for Internet protocols, we want to make sure that = these protocols get implemented and deployed. Yes, the documents=20 describing these protocols should be easy to read. But they should also=20 address real problems and solve them through good engineering practice.=20 That's not something to delegate to just a few publication experts.=20 That's a task for the entire community, and especially for the IETF=20 leadership. -- Christian Huitema From nobody Sun Jan 31 08: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 628A63A10DB for ; Sun, 31 Jan 2021 08:39:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.25, 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 ThFBJNAW7vkV for ; Sun, 31 Jan 2021 08:39:46 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB5D3A10DA for ; Sun, 31 Jan 2021 08:39:46 -0800 (PST) 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 10VGSWI2013810; Sun, 31 Jan 2021 16:39:43 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=0fEP4kpCfoM6lf8VynXrlvZd3mjqVOUr4Cn2fDYnuho=; b=HEo9O+14Di3oBNqDR/yaowLRDBwEJs53omX5VmX9wy0NKOza2Yo52Szo2R9ZVehlS+hp 0Sju5Dcr3FwmgXyZlon0Eo3LjqneSvjpZ+SvpQI2Bj/N4mprItuHb+Pz1cjEaGhCHsTU baBDnZKYk9BcMaIHbMvtRigmGY6lDPEqY68SXvEiV2zJUt/ajnXDpl46XDHZhBtFpA8d b/3keuQ4iq0HzALslbxzDtXvgSzo/0a+VkIuke4Qe0JKVuoXE2oTiyLv+hY4mPED4T2h oUr74zwyAutENQduj1nbMRqKqNQOZ3vysnuQXy+VFN26FnSlNN4BlJqitoXDevA1dmOj +Q== Received: from prod-mail-ppoint4 (a72-247-45-32.deploy.static.akamaitechnologies.com [72.247.45.32] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 36d0rce2yr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 Jan 2021 16:39:43 +0000 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 10VGYvIA023872; Sun, 31 Jan 2021 11:39:43 -0500 Received: from email.msg.corp.akamai.com ([172.27.165.118]) by prod-mail-ppoint4.akamai.com with ESMTP id 36d3p2tpph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Sun, 31 Jan 2021 11:39:42 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.165.119) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.165.121) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Sun, 31 Jan 2021 10:39:42 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.165.119]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.165.119]) with mapi id 15.00.1497.010; Sun, 31 Jan 2021 10:39:42 -0600 From: "Salz, Rich" To: Brian E Carpenter , Eliot Lear , "rfced-future@iab.org" CC: Brian Rosen Thread-Topic: [Rfced-future] Draft minutes for 12 jan meeting uploaded Thread-Index: AQHW87OjnOLVkGCqukSQZ2LXKWTkjapBVMQAgACz7wA= Date: Sun, 31 Jan 2021 16:39:41 +0000 Message-ID: References: <49944C8E-1089-4CE0-B215-4AB6403C1359@cisco.com> <5ae24238-3f8a-878d-0121-04ccaa18d181@gmail.com> In-Reply-To: <5ae24238-3f8a-878d-0121-04ccaa18d181@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.45.21011103 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: <6627F6098682E94485C42FE7B8BED56F@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.737 definitions=2021-01-31_05:2021-01-29, 2021-01-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 adultscore=0 malwarescore=0 mlxlogscore=783 phishscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101310094 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.369, 18.0.737 definitions=2021-01-31_05:2021-01-29, 2021-01-31 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 priorityscore=1501 clxscore=1011 suspectscore=0 malwarescore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 mlxlogscore=700 spamscore=0 impostorscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101310094 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 72.247.45.32) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint4 Archived-At: Subject: Re: [Rfced-future] Draft minutes for 12 jan meeting 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: Sun, 31 Jan 2021 16:39:47 -0000 PiAgICAgU28gd2hpbGUgSSBhZ3JlZSB3aXRoIHRoZSBzcGlyaXQsIEkgdGhpbmsgdGhlIGFjdHVh bCB3b3JkcyBuZWVkIHRvIGJlIG1vcmUgZ2VuZXJpYywgc3VjaCBhcyAic3ViamVjdCB0byBkZWZp bmVkIGFuZCBwdWJsaXNoZWQgcnVsZXMgb2YgcGFydGljaXBhdGlvbi4iDQoNCkkgd291bGQgcmF0 aGVyIGtlZXAgdGhlIElFVEYgbmF0dXJlIHZlcnkgZXhwbGljaXQuICBQZXJoYXBzDQoJU3ViamVj dCB0byB0aGUgSUVURiBwb2xpY2llcyBhcyBkZXNjcmliZWQgYXQgLi4uICh0aGUgIk5vdGUgV2Vs bCIgaW4gSUVURiB0ZXJtcykNCg0KDQo= From nobody Sun Jan 31 11:50:21 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4CB3A11F7 for ; Sun, 31 Jan 2021 11:50:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m8vpaHLof0_h for ; Sun, 31 Jan 2021 11:50:19 -0800 (PST) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C8983A11F6 for ; Sun, 31 Jan 2021 11:50:19 -0800 (PST) Received: by mail-pg1-x535.google.com with SMTP id j2so8918093pgl.0 for ; Sun, 31 Jan 2021 11:50:19 -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=pGT/6uQQaq/t9Lbey012zT0APANkDOJYB1IBTMKw2o8=; b=IU/b7J9grk5R/pBeLRH+bKhkKTzEEw2fiCmPV/dFIgOO3+MMZp1Rmvq4AJQQ6ZV4JD +DmY7vOWY1UVt6aA/9WXTK4X/HcPC1rbELRwC8uncLvlBjGYL4eo2IHf77+r228gasph SVhl5R7Y7THqlaJXnhLXczAJqLZ62xKzJDb1dBiQJyt3qMcMZsJmGwYl9wEx43wJAiJo j67jabi99o/KTD6tUkLEFa3E1Ody4hKGJxtG41QOxPeK0d+QwGQqdfBJy1d3Aq513CME RSnQVHHK8oU6uSKM3kevBCCnJMMkVvDOMl4+zDZWTTxiIM3kHSfultxbDrNo63LnqLHb 0L+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=pGT/6uQQaq/t9Lbey012zT0APANkDOJYB1IBTMKw2o8=; b=Ydxfi+iNbZQT3/iRhCai9XXkliWR7Nn0kvAti7RQT0yVn8M8r/qEggLpf7V1uJTWIn j0tpscE1dOAqXJi8nVgEhvNZHqHE8CfReyFfLShDR+StV1dkISdQbymiIk0ad/7frFEI brQGPHhfndLi36OMeCkwahrVvy+yaze97ZybcWYEem6l3agO5334CEqrMNnOX5O9bqmj WjmwDP2NgGC2GXQgDnFHLE9Kdk5KUTLlJzNJwXD1zNIvRI5rTECTyJOtNV4lnCKpQ9KG tzqctIZXUPMlzaD4EVi1stytD2XbdF2UzyZaugWh5IDpaS78MMVqW0fwCD9IJYH+2/Sa QXbw== X-Gm-Message-State: AOAM533/EBg+IlO+VRP0FvJw6Ph7J+wKp69S+EBA8Ba+ZBE10FVHsxJp +Zpx/n1qE+4J3MDd5zEybHA= X-Google-Smtp-Source: ABdhPJxRcfPNEgw8XvMhZ4QfNnHrvTq1JjAGLQNqC7fz7aIKqeufNTTCZofn1R2YE+HARnKWOpEX1w== X-Received: by 2002:aa7:8bc3:0:b029:1ba:7a2:7720 with SMTP id s3-20020aa78bc30000b02901ba07a27720mr13037198pfd.3.1612122618451; Sun, 31 Jan 2021 11:50:18 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id x5sm13901844pjl.1.2021.01.31.11.50.15 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jan 2021 11:50:17 -0800 (PST) To: "Salz, Rich" , Eliot Lear , "rfced-future@iab.org" Cc: Brian Rosen References: <49944C8E-1089-4CE0-B215-4AB6403C1359@cisco.com> <5ae24238-3f8a-878d-0121-04ccaa18d181@gmail.com> From: Brian E Carpenter Message-ID: <60f50126-8ff2-6bab-c91f-05f0dfe618fd@gmail.com> Date: Mon, 1 Feb 2021 08:50:13 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Draft minutes for 12 jan meeting 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: Sun, 31 Jan 2021 19:50:20 -0000 On 01-Feb-21 05:39, Salz, Rich wrote: >> So while I agree with the spirit, I think the actual words need to be more generic, such as "subject to defined and published rules of participation." > > I would rather keep the IETF nature very explicit. Perhaps > Subject to the IETF policies as described at ... (the "Note Well" in IETF terms) I didn't intend anything else in spirit. But since the IESG presumably will not be in the approval chain for output documents we can't simply say that IETF rules apply. Some careful wordsmithing is needed. Brian From nobody Sun Jan 31 11:53: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 1C0B13A11FA for ; Sun, 31 Jan 2021 11:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rl5tb1BV5RWh for ; Sun, 31 Jan 2021 11:53:32 -0800 (PST) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 445B43A11F8 for ; Sun, 31 Jan 2021 11:53:32 -0800 (PST) Received: by mail-pl1-x632.google.com with SMTP id g3so8799723plp.2 for ; Sun, 31 Jan 2021 11:53:32 -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=//YCQfDBb33dddnVV1+BspyDYEstfl9HU9r5tjsIb6M=; b=K5TcwkyV1/eHKzQiQJfHS4boQUt+LwYXeKkukegh5x26jkRcVeNHZnYxyPcBV2z/is NUo19NIbwe/rfGLS2VbHz9g6BIOzHSouvf9r8R7KntFI+ERtal0JedvWVkFRROwDOz7+ G9s+J5nQKAr2YEjUg3cgv5NJBUFR1mAGEJ0Lww/dKGIn3HYo9CKcokjLZyrbmvJdknum Ov0hcDJJB0Ei3XwmaKs5EIKYQC9Lu9sPotCwOCDn2mHM/d0ZiE1Q34rq12VJGwyisJU8 Fl4jzKiA/zkmniFBGlBsW9qXN7+0a/87CDlwZVkhoxeOxnl6qkCjd5546Ywm0FVgzCZZ OlYQ== 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=//YCQfDBb33dddnVV1+BspyDYEstfl9HU9r5tjsIb6M=; b=lWEpndQfKuWBx5jNKmpjbKE7x7O8MaE7tDFnyifxLg3c/z5QZTgCxLZL9WKEgmPFSC Q07H2yvvm7KszidbhqybGs+goG5cyU/OIV439476LZTZZo8Nb9a2iXfpr12VP2ze9O08 Y8HJFiV2O4nt8t4iZ3ovLXw1z+2CqE1keOj5aKQ5PR7tNmILnD+tiC13Rx1XaXwEbkEQ Op9QBS4iEhQJd1OTtm2iCd1nrIoPG5cfAztmSTwF7fYaXATUSAT1tugRH2CKdsqwbNOP MFxxn4d1G9VqDUnyRO/IkwxdaWaEvF7620lcDxHUv/JDFlxj/85p637NBt8ierDgHN33 tZzA== X-Gm-Message-State: AOAM532gPnGkMte8lhrJAH0ABqSGnTNJ4F1Rw4LvzE7klk5OP940sZFW OzU0VS/VRsqAfrla13Lnc3Y= X-Google-Smtp-Source: ABdhPJwscE8ADyrbNyn33knzR9k4AEjvncr0VUjBolZX6FJtZ3LEVdCObKCzYkLcPkoygnoAWgImzw== X-Received: by 2002:a17:90a:4209:: with SMTP id o9mr14312776pjg.75.1612122811560; Sun, 31 Jan 2021 11:53:31 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id 101sm13128186pjo.38.2021.01.31.11.53.29 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jan 2021 11:53:30 -0800 (PST) To: Eliot Lear Cc: rfced-future@iab.org, Brian Rosen References: <49944C8E-1089-4CE0-B215-4AB6403C1359@cisco.com> <5ae24238-3f8a-878d-0121-04ccaa18d181@gmail.com> <0EA9E312-A795-4208-BF94-4B12C9D62311@cisco.com> From: Brian E Carpenter Message-ID: <6fcb32ee-878a-a336-5382-64e8438660dd@gmail.com> Date: Mon, 1 Feb 2021 08:53: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: <0EA9E312-A795-4208-BF94-4B12C9D62311@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] **Consensus Check** Issue 13: Is participation in the strategy body is open to all? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 19:53:34 -0000 Yes, for our present purposes that seems fine. As I just noted to Rich, t= he final description will need careful wordsmithing, but I think that "co= nsistent with IETF..." does it for now. Regards Brian C On 31-Jan-21 22:26, Eliot Lear wrote: > Hi Brian, >=20 > Thank you. =C2=A0Yours was one of three comments that need addressing: >=20 > * EKR: see that we have an anti-harassment policy > * John Klensin performed a review of BCP 25 (thank you again, John. =C2= =A0The punishment for your good deed is at an end (for now)). > * Brian: tweak to make less IETFy. >=20 >=20 > Here=E2=80=99s the resultant text. =C2=A0Please comment no later than 1= 2 February, but see below before you do. >=20 >> All strategic body meetings are open to any participant, subject to in= tellectual property policies that are consistent to those of the IETF [No= te Well]. At body's initial formation, all discussions are to take place = on open mailing lists, and anyone is welcome to comment / discuss. The st= rategic body may decide by rough consensus to use additional forms of com= munication (for example, Github as specified in [RFC8874]) that are consi= stent with [RFC2418]. =C2=A0The group will conform itself to an anti-hara= ssment policy consistent with [RFC7154,RFC7776]. >=20 > I propose that we leave it to the document editor to propose what it me= ans to be consistent with RFCs 2418 and Note Well, based on John Klensin=E2= =80=99s latest note, or whether that person recommends that the first doc= ument out of the new WG contain such amendments. =C2=A0If we need to circ= le back on such things later, we can do that once we have more of the str= ucture fleshed out. >=20 > **CAUTION** >=20 > Please avoid bike shedding on a matter on which we largely agree. =C2=A0= I you have a *real*=C2=A0problem, speak now. =C2=A0Otherwise, we really h= ave to be moving on. >=20 > Eliot >=20 >=20 >> On 31 Jan 2021, at 01:55, Brian E Carpenter > wrote: >> >> Hi, >> >> I just noticed this phrase: >> >>> =C2=A0=C2=A0=C2=A0All strategic body meetings are open to any partici= pant, subject to Note Well provisions. >> >> The explicit mention of "Note Well" seems strange. Firstly, it's IETF = jargon, which would be unclear to the public at large. But more to the po= int, the wording of the Note Well is very specific to the IETF rules. >> >> So while I agree with the spirit, I think the actual words need to be = more generic, such as "subject to defined and published rules of particip= ation." >> >> Regards >> =C2=A0=C2=A0Brian Carpenter >> >> On 26-Jan-21 20:19, Eliot Lear wrote: >>> Please note, these are likely to be updated once more as they do not = yet incorporate the jabber discussion. >>> >>> https://datatracker.ietf.org/meeting/interim-2021-rfcefdp-01/material= s/minutes-interim-2021-rfcefdp-01-202101122000-00.html >>> >>> >=20 From nobody Sun Jan 31 12:44: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 628E23A1234 for ; Sun, 31 Jan 2021 12:44:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.697 X-Spam-Level: X-Spam-Status: No, score=-1.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kjaG19aGDkv2 for ; Sun, 31 Jan 2021 12:44:04 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 358773A1233 for ; Sun, 31 Jan 2021 12:43:59 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.2.166]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id 10VKhYMn005848 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 31 Jan 2021 12:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1612125829; x=1612212229; i=@elandsys.com; bh=PGKatdqiM69F7Xs8/04CRmhUIGUhKJZ0SDYKM6/RigQ=; h=Date:To:From:Subject:Cc:In-Reply-To:References; b=wfP8xQ72HC4zxD95efz3RpRLaXTrXotN+1pgqeo2Bm1M82rsC/P4k2xjvDtfJMCxB OD28q6KI5Hlu2obkhj98GzetdLuE8KXCIakP3zRLPuG3+vScZ1ZSknXiYKJeH93VPE lMl48+6qHdT4xUiBYlbHlw1TJalr5pd3IgBE5gYs= Message-Id: <6.2.5.6.2.20210131123708.152f5838@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sun, 31 Jan 2021 12:43:13 -0800 To: adrian@olddog.co.uk, rfced-future@iab.org From: S Moonesamy Cc: Christian Huitema , Brian E Carpenter In-Reply-To: <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 20:44:08 -0000 Hi Adrian, At 03:09 AM 31-01-2021, Adrian Farrel wrote: >I ask again, in our new proposed format: Who is the advocate for the >under-represented stakeholders? Whose job is it to actively search >out relevant opinions? Who has the role of champion for these groups >of RFC consumers to make sure that >the decisions the WG make do not negatively impact them? The person who is better suited for that job is the RFC Series Editor. It is unlikely that under-represented stakeholders would be regular participants of the group in which the decision is taken. Regards, S. Moonesamy From nobody Sun Jan 31 12:44:25 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 529063A1234; Sun, 31 Jan 2021 12:44:24 -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 2SghvxB-f3H0; Sun, 31 Jan 2021 12:44:22 -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 780F53A1233; Sun, 31 Jan 2021 12:44:22 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1l6Ja0-000HTG-AM; Sun, 31 Jan 2021 15:44:20 -0500 Date: Sun, 31 Jan 2021 15:44:14 -0500 From: John C Klensin To: Eliot Lear , Brian E Carpenter cc: rfced-future@iab.org, Brian Rosen Message-ID: In-Reply-To: <0EA9E312-A795-4208-BF94-4B12C9D62311@cisco.com> References: <49944C8E-1089-4CE0-B215-4AB6403C1359@cisco.com> <5ae24238-3f8a-878d-0121-04ccaa18d181@gmail.com> <0EA9E312-A795-4208-BF94-4B12C9D62311@cisco.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [Rfced-future] **Consensus Check** Issue 13: Is participation in the strategy body is open to all? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 20:44:24 -0000 Eliot, I think this is ok, but with three reservations, two of which may involve "discuss now or discuss later" decisions on which I hope you and Brian will decide: (1) Its being ok is contingent on there being consensus about there being a "strategic body" and, perhaps more specifically, what those words actually mean in more detail and precision than the handwaving that has been necessary to get us as far as we are now. (2) Part of what my little investigation turned up (although it was not a new discovery) is that most of the IETF's IPR policies, including much of the focus of the current Note Well, are on patent issues and disclosures. I cannot imagine any situation in which the "strategic body" ought to be discussing anything subject to active patents that would require licensing or similar actions, especially in the context around which the IETF's policies were designed: allowing working groups to weigh issues and choices that might involve encumbered technologies that might be better technologically against unencumbered ones with more technical limitations. Remember in that context that, while discouraged, a disclosure that says "it's mine and you can't have it" is permitted. So, while this might fall into the category of things to be revisited when the wordsmithing starts, I believe we would be better off explicitly prohibiting any discussion in the strategy body that would require disclosure if it occurred under IETF rules. If we went down that path, any IPR comments would need to reference only BCP 78. (3) If there is a single conclusion from my tour of the combination of the IETF IPR policies and descriptions of organizational structure and relationships, it is that, while the IRP policies themselves are clear (although the Note Well is a moving target that has often made a number of assumptions tied closely to the IETF), the rest, including documents and relationships the IPR policies depend on, are a tangled mess. A vague comment about "consistent to (sic) those of the IETF" can be interpreted as dragging all of that in, including the IETF's appeals chain, with the latter giving bodies oversight that we have at least discussed taking away from them. Similarly, the "Note Well" not only assumes more from the IETF than we might intend, we need to remember that it is not a reference but a demand that people pay attention to specified documents it references. Again, depending on how "wordsmithing" is defied, perhaps in that category. best, john --On Sunday, January 31, 2021 10:26 +0100 Eliot Lear wrote: > Hi Brian, > > Thank you. Yours was one of three comments that need > addressing: > > EKR: see that we have an anti-harassment policy > John Klensin performed a review of BCP 25 (thank you again, > John. The punishment for your good deed is at an end (for > now)). Brian: tweak to make less IETFy. > > Here's the resultant text. Please comment no later than 12 > February, but see below before you do. > >> All strategic body meetings are open to any participant, >> subject to intellectual property policies that are 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 >> strategic body 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]. > > > I propose that we leave it to the document editor to propose > what it means to be consistent with RFCs 2418 and Note Well, > based on John Klensin's latest note, or whether that person > recommends that the first document out of the new WG contain > such amendments. If we need to circle back on such things > later, we can do that once we have more of the structure > fleshed out. > > **CAUTION** > > Please avoid bike shedding on a matter on which we largely > agree. I you have a real problem, speak now. Otherwise, we > really have to be moving on. > > Eliot > > >> On 31 Jan 2021, at 01:55, Brian E Carpenter >> wrote: >> >> Hi, >> >> I just noticed this phrase: >> >>> All strategic body meetings are open to any participant, >>> subject to Note Well provisions. >> >> The explicit mention of "Note Well" seems strange. Firstly, >> it's IETF jargon, which would be unclear to the public at >> large. But more to the point, the wording of the Note Well is >> very specific to the IETF rules. >> >> So while I agree with the spirit, I think the actual words >> need to be more generic, such as "subject to defined and >> published rules of participation." >> >> Regards >> Brian Carpenter >> >> On 26-Jan-21 20:19, Eliot Lear wrote: >>> Please note, these are likely to be updated once more as >>> they do not yet incorporate the jabber discussion. >>> >>> https://datatracker.ietf.org/meeting/interim-2021-rfcefdp-01 >>> /materials/minutes-interim-2021-rfcefdp-01-202101122000-00.h >>> tml >>> >>> > From nobody Sun Jan 31 13:04:39 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7AD3A1256 for ; Sun, 31 Jan 2021 13:04:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.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 NJ2LYHsy9Uwi for ; Sun, 31 Jan 2021 13:04:37 -0800 (PST) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93EB23A1254 for ; Sun, 31 Jan 2021 13:04:36 -0800 (PST) Received: by mail-lj1-x22f.google.com with SMTP id r14so17148737ljc.2 for ; Sun, 31 Jan 2021 13:04:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=triH8vyxzeHjkOXHNpZ8uIUmY0+ISbOzEmobQ9SOO9E=; b=y9d9TpjahcAfAbQkyAq8Q9Fxi/YeXXf0XzmQxmkQZWy6mPPxGRd1vzIehMn2jcUOPi RwV8RVAb1EK83qODlzcpC/OvkM/J2X7dlXzZD7eWYPCGC4SNsWbEahwzOnjlOxZ6PmD9 o/6HZLoNERPst9TFj9cpt1Q+ZyWw9yjnFXW6laVEhWKKu2JIsmIEv00ACmLz/Su6bdcI F4fF7vcpUw9NHuU3BY6UQ6K+KH7ouKdauqX5VfX9YD8arE/QDLsC+eIsdhZZGAlQxx1z wBMO7zRron0XYps4H0XZ7xc7BfXd5/VEbTQMaspJ0sE7KrEv4H5cucEtESpq2/hkIg8A nwFA== 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=triH8vyxzeHjkOXHNpZ8uIUmY0+ISbOzEmobQ9SOO9E=; b=l5hnEWQzMXzeTS6OlMRW42ZCEE1mPfirA5SNTEm51lMPjVcPn054zbiTsjbjqKnorM 0sGj3Lk9K98uRil46/fGOMZz+Na+XK7uTCMyX+uvu0Dmf85VagT19GEiPkGhjwHMZsqV VWP6jEC4GKxFceZXmo8zxhg13cYGh6p26Ff+K88AM/InG0Wy70lwa6wVtfLLuSFncsVX ml+iQKz7HibBMyEcarJDRw7Ze8rKpO5EzmtmZ4wBgwhqAvHEFy+1e+bvv7GGWo/2iVJZ giZGepmF03hdlRA3plLpESH11O7LsAvSSOUYGZD0K4RntPAqNRsutM2I/WV784vYws/x Wfng== X-Gm-Message-State: AOAM533s+czejz7o/mTVYMnJHcgK8SSdcrM26gNu7y2ll1xuu3mVk1CC d4+gdMNnW16c375+1a1mIidVSqVXEKqmxOyCyoDkmw== X-Google-Smtp-Source: ABdhPJxU2eA19vNzUkSPNq3r2l5HD4nKtwqJX9z4AI2VQB7iwnayzeAMZYcs6bTvLzuglkOJ7l0uvYinrMCoocS3qVk= X-Received: by 2002:a2e:3e19:: with SMTP id l25mr8476772lja.217.1612127074640; Sun, 31 Jan 2021 13:04:34 -0800 (PST) MIME-Version: 1.0 References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> In-Reply-To: <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> From: Eric Rescorla Date: Sun, 31 Jan 2021 13:03:57 -0800 Message-ID: To: Eliot Lear Cc: "Joel M. Halpern" , "rfced-future@iab.org" Content-Type: multipart/alternative; boundary="0000000000009df4b505ba38951b" Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:04:39 -0000 --0000000000009df4b505ba38951b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jan 29, 2021 at 10:42 AM Eliot Lear wrote: > Is there a middle ground here in which the RSE/A acts as an ex-officio > non-voting member of the approval body, who can raise issues that would > =E2=80=9Cbreak the series=E2=80=9D but have to garner some amount of supp= ort from voting > members to halt a proposal? This would move the ballgame to what does it > mean, =E2=80=9Cbreak the series=E2=80=9D. > I can live with this. -Ekr > Eliot > > > On 29 Jan 2021, at 16:06, Joel M. Halpern wrote: > > > > I would like an approach along the lines of the IESG discuss where one > objector forces serious discussion, but unless that objector can get > support, they eventually have to yield. I can live with a majority vote > proposaal (which would require the RSE/A to be able to get two supporters > to block something.) > > What I was commenting on specifically was those who were objecting to > giving the RSE/A a veto, when that was not what was asked. > > > > I understand from EKRs response to my message that even with those > approaches, he does support this, and wants only community appointed peop= le > having any say in the approval. > > > > I do not see how to get past so fundamental a degree of disagreement. > But I hope we can. > > > > Yours, > > Joel > > > > PS: I suspect Stephen has a good point that focusing on the documents > may cause us to miss important aspects of what we are discussing, even if > we (reasonably) assume that all decisions need to end up documented. > > > > On 1/29/2021 9:07 AM, Mirja Kuehlewind wrote: > >> Hi Joel, > >> I think what we discussed to far and what people might have on their > mind is a ballot-like model as used by the IESG where every single DISCUS= S > position blocks publication (and not a majority voting which you seem to > have on mind, right?). > >> Mirja > >>> On 29. Jan 2021, at 14:04, Joel M. Halpern > wrote: > >>> > >>> I hope that I am misreading Adam and EKR. As far as I can tell, they > are arguing against a proposal no one made. > >>> > >>> What I suggested was that the RSE/A be a full member of the approval > body with an equal vote with the stream manager. I explicitly noted that > this would mean that under most voting regimes this would require the RSE= /A > to be able to persuade at least one stream manager to agree with them abo= ut > the importance of whatever problem they are raising. It might even requi= re > them to be able to get two stream heads to agree with them. Other folks > phrased this in terms of the discuss procedure, with the same kind of > discuss over-ride that the IESG uses (which in this case would mean that > the 4 stream heads could over-ride a discuss by the RSE/A). > >>> > >>> It may be that one proposal called for the RSE/A to have a full veto, > but that is not what I have seen folks asking for, and not what I asked f= or. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 1/29/2021 12:28 AM, Adam Roach wrote: > >>>>> On Jan 28, 2021, at 21:11, Brian E Carpenter < > brian.e.carpenter@gmail.com> wrote: > >>>>> > >>>>> =EF=BB=BFA point below which may appear picky but is actually funde= mental to > this disagreement: > >>>>> > >>>>>> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: > >>>>>>> On 29/01/2021 09:17, Eric Rescorla wrote: > >>>>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter > >>>>>> > >>>>>>>> If we select this person on the grounds that they know more abou= t > technical > >>>>>>>> publishing than the rest of us do, that seems like exactly what > we need as > >>>>>>>> a finger on the DISCUSS button. > >>>>>>>> > >>>>>>> > >>>>>>> We engage a lawyer who is also an expert on topics that we are > not, and > >>>>>>> which are rather more consequential if we screw them up, and yet > we don't > >>>>>>> give them a veto. > >>>>>> > >>>>>> The expertise of lawyers is more widely acknowledged by most > >>>>>> participants because most participants are more accustomed to deal > with > >>>>>> lawyers, and know that some stuff has to be left to the lawyers. > Also, > >>>>>> lawyers are more used to attempts to screw them up, and know what = to > >>>>>> ignore, how to defend themselves, and so on. It's difficult to > imagine > >>>>>> that a lawyer would quit because they were treated as "just a > >>>>>> contractor", because being treated as "just a contractor" wouldn't > >>>>>> happen to the lawyer in the first place, or only to the extent tha= t > they > >>>>>> would be used to be as part of their usual business. > >>>>>> > >>>>>> This seems to be quite different for an expert in technical > publishing. > >>>>>> They are not licensed, they don't have any arms to twist, and so o= n. > >>>>>> > >>>>>> Also, I think "give them a veto" may exaggerate a bit. A DISCUSS > >>>>>> formally is a veto, but many DISCUSSes have been retracted without > the > >>>>>> raiser having gotten exactly what they originally proposed. > >>>>> > >>>>> No, a DISCUSS is *not* formally a veto. It is quite narrowly define= d > >>>>> and there is a procedure for overriding a DISCUSS. See > >>>>> > https://www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/ > >>>>> Indeed, a similar definition and procedure would be appropriate in > >>>>> this case too. > >>>> The most important aspect of a DISCUSS ballot is that, if an AD > holding it is alone in their conviction, the position can be overridden = =E2=80=94 > on substance, not process =E2=80=94 by the remaining ADs. I have grave co= ncerns > about allowing someone to be alone in their disagreement (expert or not) > without recourse. > >>>> /a > >>> > >>> -- > >>> Rfced-future mailing list > >>> Rfced-future@iab.org > >>> https://www.iab.org/mailman/listinfo/rfced-future > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000009df4b505ba38951b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Jan 29, 2021 at 10:42 AM Elio= t Lear <lear=3D40cisco.com= @dmarc.ietf.org> wrote:
Is there a middle ground here in which the RSE/A acts as an = ex-officio non-voting member of the approval body, who can raise issues tha= t would =E2=80=9Cbreak the series=E2=80=9D but have to garner some amount o= f support from voting members to halt a proposal?=C2=A0 This would move the= ballgame to what does it mean, =E2=80=9Cbreak the series=E2=80=9D.

I can live with this.

-Ekr


Eliot

> On 29 Jan 2021, at 16:06, Joel M. Halpern <jmh@joelhalpern.com> wrote:
>
> I would like an approach along the lines of the IESG discuss where one= objector forces serious discussion, but unless that objector can get suppo= rt, they eventually have to yield.=C2=A0 I can live with a majority vote pr= oposaal (which would require the RSE/A to be able to get two supporters to = block something.)
> What I was commenting on specifically was those who were objecting to = giving the RSE/A a veto, when that was not what was asked.
>
> I understand from EKRs response to my message that even with those app= roaches, he does support this, and wants only community appointed people ha= ving any say in the approval.
>
> I do not see how to get past so fundamental a degree of disagreement. = But I hope we can.
>
> Yours,
> Joel
>
> PS: I suspect Stephen has a good point that focusing on the documents = may cause us to miss important aspects of what we are discussing, even if w= e (reasonably) assume that all decisions need to end up documented.
>
> On 1/29/2021 9:07 AM, Mirja Kuehlewind wrote:
>> Hi Joel,
>> I think what we discussed to far and what people might have on the= ir mind is a ballot-like model as used by the IESG where every single DISCU= SS position blocks publication (and not a majority voting which you seem to= have on mind, right?).
>> Mirja
>>> On 29. Jan 2021, at 14:04, Joel M. Halpern <jmh@joelhalpern.com> wrote= :
>>>
>>> I hope that I am misreading Adam and EKR.=C2=A0 As far as I ca= n tell, they are arguing against a proposal no one made.
>>>
>>> What I suggested was that the RSE/A be a full member of the ap= proval body with an equal vote with the stream manager.=C2=A0 I explicitly = noted that this would mean that under most voting regimes this would requir= e the RSE/A to be able to persuade at least one stream manager to agree wit= h them about the importance of whatever problem they are raising.=C2=A0 It = might even require them to be able to get two stream heads to agree with th= em.=C2=A0 Other folks phrased this in terms of the discuss procedure, with = the same kind of discuss over-ride that the IESG uses (which in this case w= ould mean that the 4 stream heads could over-ride a discuss by the RSE/A).<= br> >>>
>>> It may be that one proposal called for the RSE/A to have a ful= l veto, but that is not what I have seen folks asking for, and not what I a= sked for.
>>>
>>> Yours,
>>> Joel
>>>
>>> On 1/29/2021 12:28 AM, Adam Roach wrote:
>>>>> On Jan 28, 2021, at 21:11, Brian E Carpenter <brian.e.carpent= er@gmail.com> wrote:
>>>>>
>>>>> =EF=BB=BFA point below which may appear picky but is a= ctually fundemental to this disagreement:
>>>>>
>>>>>> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: >>>>>>> On 29/01/2021 09:17, Eric Rescorla wrote:
>>>>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpen= ter
>>>>>>
>>>>>>>> If we select this person on the grounds th= at they know more about technical
>>>>>>>> publishing than the rest of us do, that se= ems like exactly what we need as
>>>>>>>> a finger on the DISCUSS button.
>>>>>>>>
>>>>>>>
>>>>>>> We engage a lawyer who is also an expert on to= pics that we are not, and
>>>>>>> which are rather more consequential if we scre= w them up, and yet we don't
>>>>>>> give them a veto.
>>>>>>
>>>>>> The expertise of lawyers is more widely acknowledg= ed by most
>>>>>> participants because most participants are more ac= customed to deal with
>>>>>> lawyers, and know that some stuff has to be left t= o the lawyers. Also,
>>>>>> lawyers are more used to attempts to screw them up= , and know what to
>>>>>> ignore, how to defend themselves, and so on. It= 9;s difficult to imagine
>>>>>> that a lawyer would quit because they were treated= as "just a
>>>>>> contractor", because being treated as "j= ust a contractor" wouldn't
>>>>>> happen to the lawyer in the first place, or only t= o the extent that they
>>>>>> would be used to be as part of their usual busines= s.
>>>>>>
>>>>>> This seems to be quite different for an expert in = technical publishing.
>>>>>> They are not licensed, they don't have any arm= s to twist, and so on.
>>>>>>
>>>>>> Also, I think "give them a veto" may exa= ggerate a bit. A DISCUSS
>>>>>> formally is a veto, but many DISCUSSes have been r= etracted without the
>>>>>> raiser having gotten exactly what they originally = proposed.
>>>>>
>>>>> No, a DISCUSS is *not* formally a veto. It is quite na= rrowly defined
>>>>> and there is a procedure for overriding a DISCUSS. See=
>>>>> https:/= /www.ietf.org/about/groups/iesg/statements/iesg-discuss-criteria/
>>>>> Indeed, a similar definition and procedure would be ap= propriate in
>>>>> this case too.
>>>> The most important aspect of a DISCUSS ballot is that, if = an AD holding it is alone in their conviction, the position can be overridd= en =E2=80=94 on substance, not process =E2=80=94 by the remaining ADs. I ha= ve grave concerns about allowing someone to be alone in their disagreement = (expert or not) without recourse.
>>>> /a
>>>
>>> --
>>> Rfced-future mailing list
>>> Rfce= d-future@iab.org
>>> https://www.iab.org/mailman/listinfo/r= fced-future
>
> --
> Rfced-future mailing list
> Rfced-future= @iab.org
> https://www.iab.org/mailman/listinfo/rfced-fut= ure

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000009df4b505ba38951b-- From nobody Sun Jan 31 13:22: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 075BD3A127C for ; Sun, 31 Jan 2021 13:22:31 -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 S8Od1sHiUfQw; Sun, 31 Jan 2021 13:22:29 -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 DD6ED3A1137; Sun, 31 Jan 2021 13:22:27 -0800 (PST) From: Jay Daley Message-Id: <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_D7DE59C2-F1D9-4815-8FA0-D2AFC461BCED" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 1 Feb 2021 10:22:25 +1300 In-Reply-To: <6.2.5.6.2.20210131123708.152f5838@elandnews.com> Cc: Adrian Farrel , rfced-future@iab.org, Christian Huitema To: S Moonesamy References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:22:31 -0000 --Apple-Mail=_D7DE59C2-F1D9-4815-8FA0-D2AFC461BCED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 1/02/2021, at 9:43 AM, S Moonesamy wrote: >=20 > Hi Adrian, > At 03:09 AM 31-01-2021, Adrian Farrel wrote: >> I ask again, in our new proposed format: Who is the advocate for the = under-represented stakeholders? Whose job is it to actively search out = relevant opinions? Who has the role of champion for these groups of RFC = consumers to make sure that >> the decisions the WG make do not negatively impact them? >=20 > The person who is better suited for that job is the RFC Series Editor. = It is unlikely that under-represented stakeholders would be regular = participants of the group in which the decision is taken. The more I read people discuss "what are the needs of the readers of = RFCs" the more it becomes clear that answering that question requires a = major project of extensive data gathering across a wide range of = communities and AFAICT nobody has done that because nobody has referred = to it. Therefore it seems extremely unlikely that we can find the kind = of expert needed for an RSE/A, who is already in a position to advocate = for the under-represented stakeholders with any degree of confidence. = It would certainly be possible to find an RSE/A who is also capable of = running such a project, but that would require considerable time and = effort if it is to be done properly. If this project were decoupled = from the RSE/A then that would simplify the role specification by = removing a long-standing messy area. A broader project could also = result in multiple "advocates for under-represented stakeholders" with a = common evidential understanding, not just a single RSE/A, Jay >=20 > Regards, > S. Moonesamy=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_D7DE59C2-F1D9-4815-8FA0-D2AFC461BCED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On 1/02/2021, at 9:43 AM, S Moonesamy <sm+ietf@elandsys.com> wrote:

Hi = Adrian,
At 03:09 AM 31-01-2021, Adrian Farrel wrote:
I ask again, in our new = proposed format: Who is the advocate for the under-represented = stakeholders? Whose job is it to actively search out relevant opinions? = Who has the role of champion for these groups of RFC consumers to make = sure that
the decisions the WG make do not negatively = impact them?

The person who is = better suited for that job is the RFC Series Editor.  It is = unlikely that under-represented stakeholders would be regular = participants of the group in which the decision is taken.

The = more I read people discuss "what are the needs of the readers of RFCs" = the more it becomes clear that answering that question requires a major = project of extensive data gathering across a wide range of communities = and AFAICT nobody has done that because nobody has referred to it. = Therefore it seems extremely unlikely that we can find the kind of = expert needed for an RSE/A, who is already in a position to advocate for = the under-represented stakeholders with any degree of confidence. =  It would certainly be possible to find an RSE/A who is also = capable of running such a project, but that would require considerable = time and effort if it is to be done properly.  If this project were = decoupled from the RSE/A then that would simplify the role specification = by removing a long-standing messy area.  A broader project could = also result in multiple "advocates for under-represented stakeholders" = with a common evidential understanding, not just a single = RSE/A,

Jay


Regards,
S. Moonesamy
--
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=_D7DE59C2-F1D9-4815-8FA0-D2AFC461BCED-- From nobody Sun Jan 31 13:27: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 EBD673A127C for ; Sun, 31 Jan 2021 13:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRuo_QKh0407 for ; Sun, 31 Jan 2021 13:27:28 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CB553A127D for ; Sun, 31 Jan 2021 13:27:28 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 61E39BE51; Sun, 31 Jan 2021 21:27:26 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nV9WgVgFB2Ml; Sun, 31 Jan 2021 21:27:24 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 9EEDBBE50; Sun, 31 Jan 2021 21:27:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1612128444; bh=Vuv3kp5KjHEKUTCkYqbu/7y9E+BX8ArAM3snlAAXDHA=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=g0kWwllH9a1NdWbvz6ibxN3uZE95QySYgD33MWEmif4Xa4ket+6+7rWnnU+u5nEUg huOGR5IRe5ko066IOHddwb1E+W8fCBx4wWWoCVjXL7BbkK4shqWwvNzbgaXwOmtL2H uCUWc74nqUeZ/jEewx2GRB4zSiyUoruMqnP5R/JQ= To: Jay Daley , S Moonesamy Cc: rfced-future@iab.org, Adrian Farrel , Christian Huitema References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> From: Stephen Farrell Message-ID: <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> Date: Sun, 31 Jan 2021 21:27:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="y8h5g3Cqwzv5GNp0w7hM3GUQe4Y5OL1dX" Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:27:31 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --y8h5g3Cqwzv5GNp0w7hM3GUQe4Y5OL1dX Content-Type: multipart/mixed; boundary="lyf5m6GvS65uRuJWDD5S5feGFvutkih5W"; protected-headers="v1" From: Stephen Farrell To: Jay Daley , S Moonesamy Cc: rfced-future@iab.org, Adrian Farrel , Christian Huitema Message-ID: <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> Subject: Re: [Rfced-future] The voices of stakeholders References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> In-Reply-To: <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> --lyf5m6GvS65uRuJWDD5S5feGFvutkih5W Content-Type: multipart/mixed; boundary="------------EDF21468A92C4062042DC949" Content-Language: en-US This is a multi-part message in MIME format. --------------EDF21468A92C4062042DC949 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 31/01/2021 21:22, Jay Daley wrote: > If this project were decoupled from the RSE/A then that would > simplify the role specification by removing a long-standing messy > area. Personally, I think that'd be a mistake. I think we'd be better off to find a RSE/A, and task them with tackling this issue, but in the knowledge that it's a long-term and not a short-term project. IOW, 50 years of RFCs I think means we don't need an answer very urgently and we're ok to evolve relatively slowly. (I figure I'd actually prefer evolution in the series to be a bit quicker than we've seen in the past, but not that much quicker.) Cheers, S. --------------EDF21468A92C4062042DC949 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------EDF21468A92C4062042DC949-- --lyf5m6GvS65uRuJWDD5S5feGFvutkih5W-- --y8h5g3Cqwzv5GNp0w7hM3GUQe4Y5OL1dX Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAXILsFAwAAAAAACgkQWrL68XsXK+p5 tw/+MlDXQi4cX63z/pIJf/CStHuWyTV4XoeQ2JJM6t+Ui/QI+F9m6kBRGlxBKrRFBSXh4+Dq040T wrUQSDjHlLkAvaYVE531MmQRrA96tPvXOsf9m5btXB+l5tp9ish1UWstoivwJhUz60P0YbyETuex BoDreULWYzP9YJUJTJXwcYQv0Aq2a94BWJvZ9D8tI+hbQ/vFSiuaYsMN74apprCfgF9c5tpk1Mxu PB9RfGrI6UCC9Pnus8QVQROZMozV+Ij4p5pMR1MzP+Xo1oZzz1lIGj+7b/h12zzK79siVoZaZ9BK FLJSS+vDTHfpz6cKELh6xgfOUmnDC5+ZE6k3TxiUnWCWJu3CAAeJ0OhjNj/+Gu+s6/Qdq+dqUPIb l6ZWoPGqcey540penYmQkLxstyBwPlY2+hKOgPUPMm+k6tX9h641A/5r6TIVkUQnAahdfM850dmO J/t6/p1DcoAeNRiK5xD1ffn46sqjz1gnHRy5IZeJ34k+++bgBZb6uxcQaZ54gslsV/N94wbAWgF/ wUGyascjYTi5FlmThULFzJGylmUamlYB9zavKxmzxJ57MAFyuaoNbbiwNKiS7zGcMA7IqmQksn88 W8NuzP2ri4E+g5+p+11u0zZu8NrGfqRn00FvvqPdSD9P6xiJzVj9hZamvKsh0MlTMhZeyuJS2bOD 0T0= =oECa -----END PGP SIGNATURE----- --y8h5g3Cqwzv5GNp0w7hM3GUQe4Y5OL1dX-- From nobody Sun Jan 31 13:35:49 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 913B83A1285 for ; Sun, 31 Jan 2021 13:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A76TFj8Uk34q for ; Sun, 31 Jan 2021 13:35:46 -0800 (PST) Received: from mail-pg1-x52e.google.com (mail-pg1-x52e.google.com [IPv6:2607:f8b0:4864:20::52e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF3FB3A1284 for ; Sun, 31 Jan 2021 13:35:46 -0800 (PST) Received: by mail-pg1-x52e.google.com with SMTP id o63so10659775pgo.6 for ; Sun, 31 Jan 2021 13:35:46 -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=HJY6QCtVrvXKfcTHJ7Cf6CfedBTuRnMX3YpG8QPFLNI=; b=WNzis0cfhqZh5YRHG2j0PnVfGnH38KK/V+6b3mYPtjQX0eY+j0BrSLZ8QQ6UixQz8r FQn9rkRfmjvOJif+Wwelt/1DJjKwdtTiMzyz6aDBl19ErXCAA1ZT2LMrRdEs8xuPItNZ ZfJLcoWzwMahrYgvw69ZI9nBFyPv0I/NFEgtcRKaCKjBlttmXb+2hLo11UpznnkTDxAg gbkf0gaLUcEX/yQnW3+sdoNbzDF6uxtkYpsUq1tW6Wbd50RmzwBy0DAdaaxvho16N6LD TYnB7Py+UYHXtnw3cfRvbwj9shDo2OsUMV8F4c4Mdqtg2VLxdBM6r6m2VxpUTTf3vv9j dEtA== 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=HJY6QCtVrvXKfcTHJ7Cf6CfedBTuRnMX3YpG8QPFLNI=; b=D4uv6bV/3JLz0mx5z9gtSSzRiZqHKhHmtMi9VjEvKxz7awdADrExFFUq+WJYrOkk89 j7w2bKwrhJoJdeMiKO7XmNoadRT0KLr1o4bqrld2x/CNeIa9rwEYNz6kkWtYGl6XVDKj s4k9Bk+GDHRIXNhK40hsUdLiOpoT0YcUSoNsouNWv7Y1U8gn4y8/AE8aXRFmg7yuI4Io +ZzGsnuMSwy8BnAgAEWRRlVYcTJGc/J9tX+8EnR8AmWTs9kVnXzEy1kGZgp/vtjaweGg WaKGz/7uWc0pHliM5PtxW3b2wcPQJiv3uX0iDA2UXSXuHuq6GrteJbOrVnXRCP0u1D23 WhZA== X-Gm-Message-State: AOAM530EkYb40Q9oQY1JhlyyL4NYkNng3F3kjM9Pil5BnOhPhxySgCIK IX6WW44brrBZ4wrIfb9l+Cng/bXQf2rUsw== X-Google-Smtp-Source: ABdhPJycf+CnLRe7XNNbo4EamgffYYPdRSOVjN7nOT82Nl96BtJI+mKcn4SiK3KB+alSsBrOHA3epw== X-Received: by 2002:a65:590d:: with SMTP id f13mr14115613pgu.38.1612128946008; Sun, 31 Jan 2021 13:35:46 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id j9sm15057708pgb.47.2021.01.31.13.35.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jan 2021 13:35:45 -0800 (PST) To: Eric Rescorla , Eliot Lear Cc: "rfced-future@iab.org" , "Joel M. Halpern" References: <07432DA9-A499-4887-98CB-B2EEA3622815@nostrum.com> <3A16F845-7BD8-452B-ABCD-D3BFAED0617C@kuehlewind.net> <2BC6841C-2CA7-4B9B-BA6B-957B72D060A8@cisco.com> From: Brian E Carpenter Message-ID: Date: Mon, 1 Feb 2021 10:35:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Community last call (was Re: Proposed "Oversight Body" structure) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:35:49 -0000 That's how I think the DISCUSS in the IESG was really intended to work an= yway. Regards Brian C On 01-Feb-21 10:03, Eric Rescorla wrote: >=20 >=20 > On Fri, Jan 29, 2021 at 10:42 AM Eliot Lear > wrote: >=20 > Is there a middle ground here in which the RSE/A acts as an ex-offi= cio non-voting member of the approval body, who can raise issues that wou= ld =E2=80=9Cbreak the series=E2=80=9D but have to garner some amount of s= upport from voting members to halt a proposal?=C2=A0 This would move the = ballgame to what does it mean, =E2=80=9Cbreak the series=E2=80=9D. >=20 >=20 > I can live with this. >=20 > -Ekr >=20 >=20 > Eliot >=20 > > On 29 Jan 2021, at 16:06, Joel M. Halpern > wrote: > > > > I would like an approach along the lines of the IESG discuss wher= e one objector forces serious discussion, but unless that objector can ge= t support, they eventually have to yield.=C2=A0 I can live with a majorit= y vote proposaal (which would require the RSE/A to be able to get two sup= porters to block something.) > > What I was commenting on specifically was those who were objectin= g to giving the RSE/A a veto, when that was not what was asked. > > > > I understand from EKRs response to my message that even with thos= e approaches, he does support this, and wants only community appointed pe= ople having any say in the approval. > > > > I do not see how to get past so fundamental a degree of disagreem= ent. But I hope we can. > > > > Yours, > > Joel > > > > PS: I suspect Stephen has a good point that focusing on the docum= ents may cause us to miss important aspects of what we are discussing, ev= en if we (reasonably) assume that all decisions need to end up documented= =2E > > > > On 1/29/2021 9:07 AM, Mirja Kuehlewind wrote: > >> Hi Joel, > >> I think what we discussed to far and what people might have on t= heir mind is a ballot-like model as used by the IESG where every single D= ISCUSS position blocks publication (and not a majority voting which you s= eem to have on mind, right?). > >> Mirja > >>> On 29. Jan 2021, at 14:04, Joel M. Halpern > wrote: > >>> > >>> I hope that I am misreading Adam and EKR.=C2=A0 As far as I can= tell, they are arguing against a proposal no one made. > >>> > >>> What I suggested was that the RSE/A be a full member of the app= roval body with an equal vote with the stream manager.=C2=A0 I explicitly= noted that this would mean that under most voting regimes this would req= uire the RSE/A to be able to persuade at least one stream manager to agre= e with them about the importance of whatever problem they are raising.=C2= =A0 It might even require them to be able to get two stream heads to agre= e with them.=C2=A0 Other folks phrased this in terms of the discuss proce= dure, with the same kind of discuss over-ride that the IESG uses (which i= n this case would mean that the 4 stream heads could over-ride a discuss = by the RSE/A). > >>> > >>> It may be that one proposal called for the RSE/A to have a full= veto, but that is not what I have seen folks asking for, and not what I = asked for. > >>> > >>> Yours, > >>> Joel > >>> > >>> On 1/29/2021 12:28 AM, Adam Roach wrote: > >>>>> On Jan 28, 2021, at 21:11, Brian E Carpenter > wrote: > >>>>> > >>>>> =EF=BB=BFA point below which may appear picky but is actually= fundemental to this disagreement: > >>>>> > >>>>>> On 29-Jan-21 15:43, Martin J. D=C3=BCrst wrote: > >>>>>>> On 29/01/2021 09:17, Eric Rescorla wrote: > >>>>>>> On Thu, Jan 28, 2021 at 4:01 PM Brian E Carpenter > >>>>>> > >>>>>>>> If we select this person on the grounds that they know mor= e about technical > >>>>>>>> publishing than the rest of us do, that seems like exactly= what we need as > >>>>>>>> a finger on the DISCUSS button. > >>>>>>>> > >>>>>>> > >>>>>>> We engage a lawyer who is also an expert on topics that we = are not, and > >>>>>>> which are rather more consequential if we screw them up, an= d yet we don't > >>>>>>> give them a veto. > >>>>>> > >>>>>> The expertise of lawyers is more widely acknowledged by most= > >>>>>> participants because most participants are more accustomed t= o deal with > >>>>>> lawyers, and know that some stuff has to be left to the lawy= ers. Also, > >>>>>> lawyers are more used to attempts to screw them up, and know= what to > >>>>>> ignore, how to defend themselves, and so on. It's difficult = to imagine > >>>>>> that a lawyer would quit because they were treated as "just = a > >>>>>> contractor", because being treated as "just a contractor" wo= uldn't > >>>>>> happen to the lawyer in the first place, or only to the exte= nt that they > >>>>>> would be used to be as part of their usual business. > >>>>>> > >>>>>> This seems to be quite different for an expert in technical = publishing. > >>>>>> They are not licensed, they don't have any arms to twist, an= d so on. > >>>>>> > >>>>>> Also, I think "give them a veto" may exaggerate a bit. A DIS= CUSS > >>>>>> formally is a veto, but many DISCUSSes have been retracted w= ithout the > >>>>>> raiser having gotten exactly what they originally proposed. > >>>>> > >>>>> No, a DISCUSS is *not* formally a veto. It is quite narrowly = defined > >>>>> and there is a procedure for overriding a DISCUSS. See > >>>>> https://www.ietf.org/about/groups/iesg/statements/iesg-discus= s-criteria/ > >>>>> Indeed, a similar definition and procedure would be appropria= te in > >>>>> this case too. > >>>> The most important aspect of a DISCUSS ballot is that, if an A= D holding it is alone in their conviction, the position can be overridden= =E2=80=94 on substance, not process =E2=80=94 by the remaining ADs. I ha= ve grave concerns about allowing someone to be alone in their disagreemen= t (expert or not) without recourse. > >>>> /a > >>> > >>> -- > >>> Rfced-future mailing list > >>> Rfced-future@iab.org > >>> https://www.iab.org/mailman/listinfo/rfced-future > > > > -- > > Rfced-future mailing list > > Rfced-future@iab.org > > https://www.iab.org/mailman/listinfo/rfced-future >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Sun Jan 31 13:42: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 EE8D33A128E for ; Sun, 31 Jan 2021 13:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 sIDwSy7YlLLE for ; Sun, 31 Jan 2021 13:42:02 -0800 (PST) Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2166C3A128F for ; Sun, 31 Jan 2021 13:42:02 -0800 (PST) Received: by mail-pf1-x42e.google.com with SMTP id w18so10263414pfu.9 for ; Sun, 31 Jan 2021 13:42:02 -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=+kSNzDhCj5UiaDS+3SxKxjXZa7NpSi5+TX/yurGvJyo=; b=U80e4fvvmNOVZrsrRXjt4fryir2FSCpebGNt8XT/BZ6kJrfoiwTBAzPL+hI6OzXFxh Ez25Lt7UWQhJLQGbeUnAqYiJucjj6s64AqYyO33DhQH/3NLSiyfEDxvx6i2ST28xyKgp 5rcAhk9nPF39PbCRnl+0sGuBKSx3rlBbBgb498KNuIYSAE3kY+A2OLFjPrIw0ChGEutB McQ8JrOTH7fcCQNBURzRvxIt0nQhhWSKRPDcQzFqVc0/iFmKGG+8xP6hKBqePBvntPGk nc6lPyJG2oaYpOsjoLoTdYXNBk+Up9fB1Rm1Puy6O3G4KK7agh6sfQmOqzjWF/V3XL0E phcw== 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=+kSNzDhCj5UiaDS+3SxKxjXZa7NpSi5+TX/yurGvJyo=; b=SrSrnA+lhqR6s2r7VIY5xt3YnAxwv+jWlROY8ATFz7800GI54nTKKp75C5QD53Ol5Z xuIsVimzYXjv3LgcKgd5i/lL8GTfNtrXc0/yW2liJtCnqtDodew05n4qMp1oyQgO+6Uq Mu16p1gWId6KPi+RLzrR4Hn45XLWW/BQnHBBUMFymKA2iAf3jFn8cxAN2mgD2X6pCNbR 4Ira6TP3mphPtbDCoOtiPeEgP5cF76qj6NJ+/+37tRd5vegZVJ3n0vongTw/Xfu1deJH iiMfl8ApE/XXRyMhjuzON+19SD4p8YQr25zKxZ67UTUEKSwEi1CsfnOMVEUij6xZWRzL QdEA== X-Gm-Message-State: AOAM532rNvyiC7RyU/uutKd5Az3eDKhT69wJpAcNw/wFZw6UM++C2vhu dNNGjHyGKQZ/Tk1xtYZVHO0= X-Google-Smtp-Source: ABdhPJyuknIOnzvcSy1d2y7wCWNZFKq8r2rWLZr2VWqnKohO+iwlL5mZQ/uaWiC0HqK7GQ4YyCN63g== X-Received: by 2002:a62:2aca:0:b029:1bb:4349:f889 with SMTP id q193-20020a622aca0000b02901bb4349f889mr13350661pfq.26.1612129321568; Sun, 31 Jan 2021 13:42:01 -0800 (PST) Received: from [192.168.178.20] ([151.210.131.28]) by smtp.gmail.com with ESMTPSA id s1sm13064990pjg.17.2021.01.31.13.41.55 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Jan 2021 13:41:58 -0800 (PST) To: Stephen Farrell , Jay Daley , S Moonesamy Cc: rfced-future@iab.org, Adrian Farrel , Christian Huitema References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> From: Brian E Carpenter Message-ID: Date: Mon, 1 Feb 2021 10:41:52 +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: <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:42:04 -0000 On 01-Feb-21 10:27, Stephen Farrell wrote: > > Hiya, > > On 31/01/2021 21:22, Jay Daley wrote: >> If this project were decoupled from the RSE/A then that would >> simplify the role specification by removing a long-standing messy >> area. > Personally, I think that'd be a mistake. I think we'd be > better off to find a RSE/A, and task them with tackling this > issue, but in the knowledge that it's a long-term and not > a short-term project. IOW, 50 years of RFCs I think means > we don't need an answer very urgently and we're ok to evolve > relatively slowly. (I figure I'd actually prefer evolution > in the series to be a bit quicker than we've seen in the > past, but not that much quicker.) Sure. But Jay is correct that it isn't necessarily part of the skill set we could reasonably require of the RSA/E. However, they could certainly be tasked with commissioning such an effort (very possibly via the LLC). Brian C From nobody Sun Jan 31 13:46:51 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 654033A12CC for ; Sun, 31 Jan 2021 13:46:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id or5vB99VUmle for ; Sun, 31 Jan 2021 13:46:43 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE7EC3A12C1 for ; Sun, 31 Jan 2021 13:46:42 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id AB423BE53; Sun, 31 Jan 2021 21:46:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zt23d5CN8haC; Sun, 31 Jan 2021 21:46:39 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B028FBE50; Sun, 31 Jan 2021 21:46:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1612129598; bh=NiBTpkNtQiXwaFvpX9Tn56a/iay8CbXvaUTws/6JIjY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=UMiL//D2RrbIzVWCEFsq5ctP7R3Df4Qh/WQlLKWTD2IfLeIdiRrcfShZywcV3KAb0 cO7ZycZNAMLIeQ4Vk2K+1ZMhPRNKleki933MZWaUNh98csGp6V1QS6UfIFvoUkfJ/D PaA4i4dzkkDDYMRRfqn2/rOKkqa78DfhuvOb7klI= To: Brian E Carpenter , Jay Daley , S Moonesamy Cc: rfced-future@iab.org, Adrian Farrel , Christian Huitema References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> From: Stephen Farrell Message-ID: Date: Sun, 31 Jan 2021 21:46:37 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Na46Xti2rEOjQRgH4cMiMHtMLlsYawH4q" Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:46:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Na46Xti2rEOjQRgH4cMiMHtMLlsYawH4q Content-Type: multipart/mixed; boundary="Z9s0KyLv0fRD5UfDjjO2BYm20JvCx0yss"; protected-headers="v1" From: Stephen Farrell To: Brian E Carpenter , Jay Daley , S Moonesamy Cc: rfced-future@iab.org, Adrian Farrel , Christian Huitema Message-ID: Subject: Re: [Rfced-future] The voices of stakeholders References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> In-Reply-To: --Z9s0KyLv0fRD5UfDjjO2BYm20JvCx0yss Content-Type: multipart/mixed; boundary="------------2349F75F4A8633D0D3110058" Content-Language: en-US This is a multi-part message in MIME format. --------------2349F75F4A8633D0D3110058 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 31/01/2021 21:41, Brian E Carpenter wrote: > Sure. But Jay is correct that it isn't necessarily part of > the skill set we could reasonably require of the RSA/E. > However, they could certainly be tasked with commissioning > such an effort (very possibly via the LLC). Could be, sure. I'd say parts of that task could well be handled fine via an RFP issued by the LLC. (Not by LLC staff themselves I'd hope, lest the LLC headcount expand too much.) But (again personally) I think owning that task is a core part of being an RSE/A. Absent that ISTM we'd be hiring a fancily-titled managing copy editor. Cheers, S. --------------2349F75F4A8633D0D3110058 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------2349F75F4A8633D0D3110058-- --Z9s0KyLv0fRD5UfDjjO2BYm20JvCx0yss-- --Na46Xti2rEOjQRgH4cMiMHtMLlsYawH4q Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAXJT4FAwAAAAAACgkQWrL68XsXK+os Fw/+I7oSHyQVImeCCwjq4YaTEqWAVWvyg69o6DC+obmf6G668ZyfK6K8q/mMLIqPG3DipOFGw7JZ 95nxkJK1YR8Mlo/gKqkMDeul5LZtI+oDgVS/cW+AEqOnUJZztEuW0Kt2AQHLmJ+xXMyIefqQ0kK9 Jog8Fwl9/UoCOP1mty4zHzn8ZBfkQFCYc48N1O3QINXpBlwS/C/wqdHU4IP1ahBpZNsMCDHjtJGR Cuk/wBrKE0tpN9fETYFweqTqUPebCy8IuIplotgEIpYVxp4o8aTLNFSdComfj9Rtsic9AIaLKO4V UCWZRNCZLX6prMYx+DA2cuogk6OSuL1Q2s09/Bm3kxa/+uGs1M1FA718LzGJjjrgJ0bujBQaoCpC TkMwdTXB3bQ4yeSpsOdXCAJn4fNTrZ4W6YteIV38pMLEm1/UVg1GWBY6UuwfL0ub39fEiEsm0Y91 EEYe4BdzPJ1bnfPqPG1spTf8g3eby7oj2QzEJHwcgeHjqeDP1X9M73jFx0ktbVfGtpD7+wbD02BT CAm7FDDZuDRAITrMRMu1CZYUPCOaj12V4dk3Al3bQe7cZtF5EyHA7f7w3vNDq2XasVH9kLnr3CGo 1X7+AAsp/HtWdjiPUXiiMSt/ipOI7RoNjkkQZF6+J43EDI56ofyyjo8DTLw+TCORnerbZX4sXPzF 7UI= =ddNR -----END PGP SIGNATURE----- --Na46Xti2rEOjQRgH4cMiMHtMLlsYawH4q-- From nobody Sun Jan 31 13:53: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 53DDC3A129D for ; Sun, 31 Jan 2021 13:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=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 MFR_BpySmlli for ; Sun, 31 Jan 2021 13:53:27 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFDF83A127C for ; Sun, 31 Jan 2021 13:53:26 -0800 (PST) Received: from xse395.mail2web.com ([66.113.197.141] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1l6Keo-000Wyh-2s for rfced-future@iab.org; Sun, 31 Jan 2021 22:53:24 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4DTPvx1Z25z1TkG for ; Sun, 31 Jan 2021 13:53:17 -0800 (PST) Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1l6Kej-0002YQ-3e for rfced-future@iab.org; Sun, 31 Jan 2021 13:53:17 -0800 Received: (qmail 31324 invoked from network); 31 Jan 2021 21:53:16 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.250]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 31 Jan 2021 21:53:16 -0000 To: S Moonesamy , adrian@olddog.co.uk, rfced-future@iab.org References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> From: Christian Huitema Message-ID: Date: Sun, 31 Jan 2021 13:53:18 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <6.2.5.6.2.20210131123708.152f5838@elandnews.com> Content-Type: multipart/alternative; boundary="------------ED5148EF49EACF2C1583E1C7" Content-Language: en-US X-Originating-IP: 66.113.197.141 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT/p0a7I3yiqNIVLhIDkCssjPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KrtU BY8myW35UtmgpbFA1wq4VK1OHTxPSh5nC0Bkf3oGSxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVR4viV7miyo7GvEGp97Zbg5otTbzF8bFslzcWfB/84WX1KHe/ FVcvFYE7DSY4uAuvkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkgOaZXY1D 3Tei6L4lTC3Kzv6blagzf/fouhj8KehojfmLb5mum9xAXSaS3KKPtTZXWZip9+GhedmPokL8D3vh veYLhIg92+wH02ylfDiSQ0sYFBl6VX84fRovDGikEvLu7vlxwPg5iSJU22qtYbc2zIvhSJcbnX/H QqL/X9rNCJCc6iESJvKm1NV8gkr+Wu8ScVDXinOVyuIpITQ9z3M3DCinc6hm4Yij/9/ori/8mFV4 V97ui3VA1OEF+KxGdWeo/K3355kDkS/EC7rTAgyxbYPljy1wcsVasJP6JKhhq4HYpEFoi75E4I64 qGaGHDSiyaxfFQ1w34FqYc4W3dbMgAFVnde1UJCYLdcfX0Bx8d2J0pUY+7YKlhzdUVogH5xEPoG5 7STqNK1Cd+uQb3g+R65769TqbX47GQon7bvTbe8ofgfTqGP2DodDP+w9hCNkXPWlFdaGOH191uXj gjQN/UgmFnDejR5GAcPZptnyFMHKJeZ3BUaI/ohfl5wMgKYvXw+nBpSCKZIbZZvSwd+SQxZlzVty mVydDKFB2f6LxLLeNHk15VolAGHS5rCXQKDy9EJw0oDs3IuV1P3CACJRKC3Z/gUfBR81DfdjOw7H zLAtNKciZu/UXm5Ymo0KIdV9iR3bHfnMCIEU+nrglojKwHii07T4YjLFruZMfnLuYZ8= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:53:28 -0000 This is a multi-part message in MIME format. --------------ED5148EF49EACF2C1583E1C7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/31/2021 12:43 PM, S Moonesamy wrote: > Hi Adrian, > At 03:09 AM 31-01-2021, Adrian Farrel wrote: >> I ask again, in our new proposed format: Who is the advocate for the >> under-represented stakeholders? Whose job is it to actively search >> out relevant opinions? Who has the role of champion for these groups >> of RFC consumers to make sure that >> the decisions the WG make do not negatively impact them? > > The person who is better suited for that job is the RFC Series > Editor.  It is unlikely that under-represented stakeholders would be > regular participants of the group in which the decision is taken. I don't think so. We have more or less agreed that this is a matter of knowing who the RFC "consumers" are and understand what their unmet needs might be. In a commercial business, that's a task for marketing departments and business managers. If I look at past RSE hiring processes, market research and business management were not high on the list of hiring criteria. If I look at RFC 8728, I don't find any mention of market studies, user panels and the like. Indeed, doing such studies would be very hard when the budgeted workload is only "approximately 20 hrs per week". So, no, the RFC Series Editor is not the better suited person for that job. -- Christian Huitema --------------ED5148EF49EACF2C1583E1C7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


On 1/31/2021 12:43 PM, S Moonesamy wrote:
Hi Adrian,
At 03:09 AM 31-01-2021, Adrian Farrel wrote:
I ask again, in our new proposed format: Who is the advocate for the under-represented stakeholders? Whose job is it to actively search out relevant opinions? Who has the role of champion for these groups of RFC consumers to make sure that
the decisions the WG make do not negatively impact them?

The person who is better suited for that job is the RFC Series Editor.  It is unlikely that under-represented stakeholders would be regular participants of the group in which the decision is taken.


I don't think so. We have more or less agreed that this is a matter of knowing who the RFC "consumers" are and understand what their unmet needs might be. In a commercial business, that's a task for marketing departments and business managers. If I look at past RSE hiring processes, market research and business management were not high on the list of hiring criteria. If I look at RFC 8728, I don't find any mention of market studies, user panels and the like. Indeed, doing such studies would be very hard when the budgeted workload is only "approximately 20 hrs per week". So, no, the RFC Series Editor is not the better suited person for that job.

-- Christian Huitema

--------------ED5148EF49EACF2C1583E1C7-- From nobody Sun Jan 31 14:12: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 45FEF3A12BA for ; Sun, 31 Jan 2021 14:12:25 -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 XTfSPErFr_-f; Sun, 31 Jan 2021 14:12:23 -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 0970B3A12B7; Sun, 31 Jan 2021 14:12:21 -0800 (PST) From: Jay Daley Message-Id: <7C7419E7-A8FC-4CE4-BE45-598DBCEE40C0@ietf.org> Content-Type: multipart/signed; boundary="Apple-Mail=_857702F5-B3BB-42B3-85C9-F335118FE231"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 1 Feb 2021 11:12:19 +1300 In-Reply-To: Cc: Brian E Carpenter , S Moonesamy , rfced-future@iab.org, Adrian Farrel , Christian Huitema To: Stephen Farrell References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 22:12:25 -0000 --Apple-Mail=_857702F5-B3BB-42B3-85C9-F335118FE231 Content-Type: multipart/alternative; boundary="Apple-Mail=_8D7FD5F4-9EB9-4F7F-B712-9A7F45C85BE2" --Apple-Mail=_8D7FD5F4-9EB9-4F7F-B712-9A7F45C85BE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1/02/2021, at 10:46 AM, Stephen Farrell = wrote: >=20 >=20 > Hiya, >=20 > On 31/01/2021 21:41, Brian E Carpenter wrote: >> Sure. But Jay is correct that it isn't necessarily part of >> the skill set we could reasonably require of the RSA/E. >> However, they could certainly be tasked with commissioning >> such an effort (very possibly via the LLC). >=20 > Could be, sure. I'd say parts of that task could well > be handled fine via an RFP issued by the LLC. (Not by > LLC staff themselves I'd hope, lest the LLC headcount > expand too much.) >=20 > But (again personally) I think owning that task is a > core part of being an RSE/A. I don=E2=80=99t believe that someone can only advocate for a position if = they have personally collected the data to support that position. It = should be entirely possible for the RSE/A to advocate based on a = detailed report produced by a third party. Jay > Absent that ISTM we'd be > hiring a fancily-titled managing copy editor. >=20 > Cheers, > S. > -- Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_8D7FD5F4-9EB9-4F7F-B712-9A7F45C85BE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 1/02/2021, at 10:46 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:


Hiya,

On 31/01/2021 21:41, Brian E Carpenter = wrote:
Sure. But Jay = is correct that it isn't necessarily part of
the skill set = we could reasonably require of the RSA/E.
However, they = could certainly be tasked with commissioning
such an = effort (very possibly via the LLC).

Could be, sure. I'd say parts of that task could well
be handled fine via an RFP issued by the LLC. (Not by
LLC staff themselves I'd hope, lest the LLC headcount
expand too much.)

But (again = personally) I think owning that task is a
core part of = being an RSE/A.

I don=E2=80=99t believe that someone can only = advocate for a position if they have personally collected the data to = support that position.  It should be entirely possible for the = RSE/A to advocate based on a detailed report produced by a third = party.

Jay

Absent that ISTM = we'd be
hiring a fancily-titled managing copy editor.

Cheers,
S.
<OpenPGP_0x= 5AB2FAF17B172BEA.asc>

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

= --Apple-Mail=_8D7FD5F4-9EB9-4F7F-B712-9A7F45C85BE2-- --Apple-Mail=_857702F5-B3BB-42B3-85C9-F335118FE231 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----- iQIzBAEBCAAdFiEEteUdwVZRcQwi2bcWICxpEHTRWFMFAmAXK0MACgkQICxpEHTR WFOGFw/+JXe0/S6psVfC+BVQprICrelitHP84D+deX2FKQib0RUT7HPtR11D4YZf uAfpJ/unk6TX9E0O32Pv+6JS2Rn/zuUbr4D9E5Bj48vNvAH7HotTLWPhXDxXMC64 q/sDLajdyjnyFL5RqQzM7aYsyXkAsJX4lirMDgJAip/zNGXcyphf5vd5szgXI8bI s5int8TF8iDWGcSqY4BJc+h8cG5laSUCpBkMYygCmVqIagplzBpgzUJEBGEWEEpE BkkGdC/EeRCWdqLGvJiHN4EfMsR93VnNuZ5GY7LUIsojVlOGF1F7ZhXUMM2snpH9 D2iAXcXm9HFly9vBkvVpSxOOUps6bOjf/mY2TrOWxxVw+lFGePr98Gyj0E2NcQLr qWItDf6QzBxl5O5jIdl8M3dWfBLbAGFDy0XfwM22izypgzwOGr2dljhxO3iBkKep uP4QezHbYAvw4VmzwFgdkTY/Qw+TLBQHlXVX6hPHkhEQth4AeR4c1ENDFXtpXHig QV8mludha0ezHChQ+9cRs7SHA7wTIPKe19MICPATyyMkQYyJlmaVvHmU6Hj66bud 5S+ttyT17WNjYOJXQy/eBPUV/Mk7aR1dObPYiVOWGTKBUQEqvxtrFguAS4G+Dwlv Q2YRpbf4qBP+8VIoF/qNSj0d/V29WBWAi0JpUpvsZ1suTfn45Zw= =d7Hk -----END PGP SIGNATURE----- --Apple-Mail=_857702F5-B3BB-42B3-85C9-F335118FE231-- From nobody Sun Jan 31 14:14: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 6E44C3A12BA for ; Sun, 31 Jan 2021 14:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2au7h97GVngg for ; Sun, 31 Jan 2021 14:14:49 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7BDD3A12BB for ; Sun, 31 Jan 2021 14:14:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9BCD4BE53; Sun, 31 Jan 2021 22:14:46 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8liV34tgsiM; Sun, 31 Jan 2021 22:14:45 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CDEF6BE50; Sun, 31 Jan 2021 22:14:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1612131285; bh=/8LsnixLI8t4cLrmBiIE5qKEkXDB+92ysYl3HMYkrzE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jszswPvltXc04jB7NxlcBubraQfCTJxm9if5ShnEM5BVMn1ikZwbZ0up3JdyHuLWi kkwQxsiLfXAKZfQEv08XGhbsPhwfiBzOL5L7oU+tYZ7IQBNzq1uAAvidDg6wTybeTj 51JF7DX89FyB8aG6t904wwbvQKMAQHb8XSMgJqMY= To: Jay Daley Cc: rfced-future@iab.org, Adrian Farrel , Christian Huitema , S Moonesamy References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> <7C7419E7-A8FC-4CE4-BE45-598DBCEE40C0@ietf.org> From: Stephen Farrell Message-ID: <690beb68-a437-8220-6c1f-f1f1523bdbb6@cs.tcd.ie> Date: Sun, 31 Jan 2021 22:14:44 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <7C7419E7-A8FC-4CE4-BE45-598DBCEE40C0@ietf.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ZsltoE6KdK6l56KJA3pXkMDUsX7iffEZb" Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 22:14:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ZsltoE6KdK6l56KJA3pXkMDUsX7iffEZb Content-Type: multipart/mixed; boundary="15ZEGm4ubkfFIF8N5PLmX2PhDN6XRcxEK"; protected-headers="v1" From: Stephen Farrell To: Jay Daley Cc: rfced-future@iab.org, Adrian Farrel , Christian Huitema , S Moonesamy Message-ID: <690beb68-a437-8220-6c1f-f1f1523bdbb6@cs.tcd.ie> Subject: Re: [Rfced-future] The voices of stakeholders References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> <7C7419E7-A8FC-4CE4-BE45-598DBCEE40C0@ietf.org> In-Reply-To: <7C7419E7-A8FC-4CE4-BE45-598DBCEE40C0@ietf.org> --15ZEGm4ubkfFIF8N5PLmX2PhDN6XRcxEK Content-Type: multipart/mixed; boundary="------------F474719DF2827773F37A88EF" Content-Language: en-US This is a multi-part message in MIME format. --------------F474719DF2827773F37A88EF Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, On 31/01/2021 22:12, Jay Daley wrote: > I don=E2=80=99t believe that someone can only advocate for a position i= f they > have personally collected the data to support that position. It > should be entirely possible for the RSE/A to advocate based on a > detailed report produced by a third party. Of course. It's more a matter of who initiates and decides what information is required. I think that's something that needs to be an RSE/A task. It's fine if the LLC arrange for the work to be done well, but deciding what's needed isn't IMO something for the LCC to do itself. S. --------------F474719DF2827773F37A88EF Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------F474719DF2827773F37A88EF-- --15ZEGm4ubkfFIF8N5PLmX2PhDN6XRcxEK-- --ZsltoE6KdK6l56KJA3pXkMDUsX7iffEZb Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAXK9QFAwAAAAAACgkQWrL68XsXK+qi mw//Qgrz076bfwbSLDZ/SRbTCcmXEBiM+KAUX6VUVjmxide9LVXg9JyE4Gl6hN1iMhbxk7C8poPw ejTCZthgmwz9UwtengeW05HaLAACI8EO/mMt3eJKbXEvxvkUhcg+5q3FeAURJ+GJZbx0hinKYvgc stQFxuGdmbNLdPfW+DKmJFQllmRJShsN7hM0jFYEsHs8inh/po8Rfksc2D7xXVerB7hCCKwDM8SG WWS5kDjKbQ4iO9ref17jKUdTkn+dg1bLUxEUPp/E2ji++kRomduvkTQDhTtBxwCUmQU2MsHcmDmA J2V8/sSHxUSroyOAiP+1mySNgnmJWScG1KFzU3QQHmuE/hC6NqAeoPNixxTwJSPOiAghh28ZN+EC T4N3J4WAxeqsoN0P4praCOwwdVR790gElccTqezWao3HIxm94OrqxNQBL6RCiZJK59drV40jbA9U PyFs2TXOYeLBhG+5flNQGaQ9NPr135rpalrn/dTCTliXADVaaSbxovAZ48vmkYv6nMJCPppoi0d4 c79pzVFl2d8H+tr8bzBekvh1xNbXuNdWwuN2UKZCJGieqZ8DFh/surYsdFtxayGJkWRYYQToV8Kj /RE+o/0Bqv6vJEk/izKbFUqt58AmSfgA6C33Soanty+tPlx76PCJErkgVtXPSRIBxDntINkxm6Yx YkU= =UaJL -----END PGP SIGNATURE----- --ZsltoE6KdK6l56KJA3pXkMDUsX7iffEZb-- From nobody Sun Jan 31 14:23:41 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6F93A12CA for ; Sun, 31 Jan 2021 14:23:39 -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 pspyZKqlNbdi; Sun, 31 Jan 2021 14:23:38 -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 CCEC93A12C9; Sun, 31 Jan 2021 14:23:36 -0800 (PST) From: Jay Daley Message-Id: <3BAB89B0-DFE4-4599-A7F4-F59A3DCE582B@ietf.org> Content-Type: multipart/signed; boundary="Apple-Mail=_D2DE51C2-E40B-4F32-8B4A-2D30F49506CE"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 1 Feb 2021 11:23:34 +1300 In-Reply-To: <690beb68-a437-8220-6c1f-f1f1523bdbb6@cs.tcd.ie> Cc: rfced-future@iab.org, Adrian Farrel , Christian Huitema , S Moonesamy To: Stephen Farrell References: <04a101d6f640$4e9d2670$ebd77350$@olddog.co.uk> <600faf0e-5c74-6144-d6f1-7a3f01a4a4d0@gmail.com> <05e201d6f7c1$868acb00$93a06100$@olddog.co.uk> <6.2.5.6.2.20210131123708.152f5838@elandnews.com> <34CA553A-6013-478D-B5C1-9272FF6B2DEE@ietf.org> <1b1c2430-970c-8348-f9c6-6265adb1f71c@cs.tcd.ie> <7C7419E7-A8FC-4CE4-BE45-598DBCEE40C0@ietf.org> <690beb68-a437-8220-6c1f-f1f1523bdbb6@cs.tcd.ie> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] The voices of stakeholders X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 22:23:39 -0000 --Apple-Mail=_D2DE51C2-E40B-4F32-8B4A-2D30F49506CE Content-Type: multipart/alternative; boundary="Apple-Mail=_FF4A372E-3F4C-4F65-AFB1-0EA2315D27DF" --Apple-Mail=_FF4A372E-3F4C-4F65-AFB1-0EA2315D27DF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1/02/2021, at 11:14 AM, Stephen Farrell = wrote: >=20 > Signed PGP part >=20 > Hiya, >=20 > On 31/01/2021 22:12, Jay Daley wrote: >> I don=E2=80=99t believe that someone can only advocate for a position = if they >> have personally collected the data to support that position. It >> should be entirely possible for the RSE/A to advocate based on a >> detailed report produced by a third party. > Of course. It's more a matter of who initiates and decides > what information is required. I think that's something that > needs to be an RSE/A task. It's fine if the LLC arrange for > the work to be done well, but deciding what's needed isn't > IMO something for the LCC to do itself. I wasn=E2=80=99t thinking of the LLC controlling or doing this. Having the RSE/A control it seems to decouple it both from the community = members who raise the issue regularly, and from the streams who produce = the content in the first place. Jay >=20 > S. > >=20 >=20 -- Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_FF4A372E-3F4C-4F65-AFB1-0EA2315D27DF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 1/02/2021, at 11:14 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:

Signed PGP part

Hiya,

On 31/01/2021 22:12, Jay Daley wrote:
I don=E2=80=99t believe that someone can only = advocate for a position if they
have personally collected = the data to support that position.  It
should be = entirely possible for the RSE/A to advocate based on a
detailed report produced by a third party.
Of course. It's more a matter of who initiates = and decides
what information is required. I think that's = something that
needs to be an RSE/A task. It's fine if the = LLC arrange for
the work to be done well, but deciding = what's needed isn't
IMO something for the LCC to do = itself.

I wasn=E2=80=99t thinking of the LLC controlling = or doing this.

Having the RSE/A = control it seems to decouple it both from the community members who = raise the issue regularly, and from the streams who produce the content = in the first place.  

Jay


S.
<OpenPGP_0x= 5AB2FAF17B172BEA.asc>