From nobody Sat May 1 14:38:29 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21BBD3A117F for ; Sat, 1 May 2021 14:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 QjiAET44_vwy for ; Sat, 1 May 2021 14:38:26 -0700 (PDT) Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (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 AC1F43A117E for ; Sat, 1 May 2021 14:38:26 -0700 (PDT) Received: by mail-pl1-x630.google.com with SMTP id v13so787135ple.9 for ; Sat, 01 May 2021 14:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=yC4+GYY6h2MM05ueeRPBNtTogZu9I3zmvavFUKewit0=; b=Zdt+YOx+PgdCNczVGa761tfXlRb8hFfMUvwzS38Q9kfyGcES8bR/21AA5zrj3pXTDh OEeSlvZPv+WdtF9L9041kIgw/f9dYpwjAuMLBvmOYD5NwdYAbSM2QHsNdkE20GkgVXZK FFvAX+jfJJgdjdFAAaPXO9SLk5a89f6j+NjPOssBN5xSu3bb9EhvE25nrc/GxBBM734X o5aY05YvVvuxfd5R8iQVFXR9Ocb/D03V9T9jo32qP+scrNOyNIgFJFgu7el/YLN/37dp jY1RBqhlj7PYQukKiZdNcNtnIax9JxSPwyGgpsFs47Bjl+kc4gjxKuO25zo53CtUNuiO msdg== 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=yC4+GYY6h2MM05ueeRPBNtTogZu9I3zmvavFUKewit0=; b=dvisJU+HG68rIAvXbMHhm6rX2D0jFN961k9+ZSSgQdgU84lZG7lJfeE0XwabC6k+un JV8iiyuLooMC+wTSntU8wAQq47fyezZMf+WxNCUeYvjlLr0h3YISuBs/URwVAjLTGEr8 4WVENExswS97p5IeG2D8FBNgP+P203fDFhxm0M5CrdugLld29BIPf5cIaVHBsVL2jZRY Sym0fFarGpJFF9Owb3z0LhmC5i4GrXVRRPCnkvGfG/vwK+mQBx2I+r2I/3y2GQ21v4Ed LLM1KrQuf3NSfdVm6bVo5BnKiETd23wdqdORSYlHfBxa1ivc6Rzzv4w+utgNhxR9XLFE Yodg== X-Gm-Message-State: AOAM533LT1Oynr5+vJsTNF2v7A0I+SdD2y6B5BGJWm2TldFzIGHyFhZ+ e7E/hVelwFqD63f1Ib26h5L6VMzlNQYB8Q== X-Google-Smtp-Source: ABdhPJzFfM+1ZCUjR8z5O26brDXnGeIgCZmuQ7UMLsChlelaFLFbfZWZYG2N7LTJga6QypAY7Sra4w== X-Received: by 2002:a17:90a:4748:: with SMTP id y8mr12248529pjg.31.1619905105404; Sat, 01 May 2021 14:38:25 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d3sm6116644pgu.8.2021.05.01.14.38.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 May 2021 14:38:24 -0700 (PDT) To: Peter Saint-Andre , "Joel M. Halpern" , rfced-future@iab.org References: <287b0a81-018b-be7e-bacd-258799257c17@mozilla.com> <7fbef1fe-2e5b-3ad7-e416-500c224d2a1e@mozilla.com> From: Brian E Carpenter Message-ID: Date: Sun, 2 May 2021 09:38:19 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <7fbef1fe-2e5b-3ad7-e416-500c224d2a1e@mozilla.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] ultimate policy authority (was: Re: draft-saintandre-rfced-model) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 May 2021 21:38:28 -0000 Hi Peter, On 30-Apr-21 11:54, Peter Saint-Andre wrote: > Apologies for the delayed reply. Expect many messages soon. I might > modify subject lines (as here) so that we can keep better track of the > topics. >=20 > On 4/5/21 1:51 PM, Joel M. Halpern wrote: >> It ia a bit hard to tell which parts of the document the chairs (and >> you) believe have rough consensus, and which parts are just starting >> points you threw in to help. >=20 > If it's any consolation, I'm not convinced that *any* parts of the > document have rough consensus yet. >=20 >> As far as I can tell, the following: >> =C2=A0 The IETF LLC shall also provide a structure for defining polici= es >> =C2=A0 regarding the RFC series.=C2=A0 This document specifies such a = structure >> =C2=A0 through a new RFC Series Working Group (RSWG), which shall subm= it its >> =C2=A0 policy proposals to a new RFC Series Approval Board (RSAB). >> is an interesting idea which has not been discussed on the list.=C2=A0=20 It has >> multiple implications, including technically giving the LLC the >> authority to change this structure. >> I expect you put it in as a first cut for "what does it mean to get th= is >> adopted?" which is indeed important. >=20 > I'm not wedded to that phrasing. What I was trying to capture is that > there might need to be some ultimate authority for the policy-defining > structure (RSWG, RSAB, etc.) that is being specified in *this* document= =2E > Naively that might seem to be the IETF LLC,=20 Not to me. The LLC is a servant of the community, but the ultimate author= ity has to be some representative of the the community: so far, we seem to be in rough agreement that the authority is the RSWG+RSAB (and its appeal chain). Clearly the LLC's responsibilities have to be well-defined within that framework, so that the contracts and performance criteria can also be well-defined. And thinking about the RSOC's problems, one of our goals should IMHO be to ensure that we don't mix up contractual oversight (the LLC's role) with policy/strategy choices (the community's role). Brian =20 > but on the other hand > perhaps there is joint authority held among the entities that name > members of the RFC Series Approval Board (RSAB) - or something else > entirely. Whatever definition we settle on might have implications for > the appeals process, too. >=20 > Peter >=20 From nobody Sat May 1 15:13: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 EC5F53A12E7 for ; Sat, 1 May 2021 15:13:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhpoBDZbNbAc for ; Sat, 1 May 2021 15:13:16 -0700 (PDT) Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58933A12E4 for ; Sat, 1 May 2021 15:13:16 -0700 (PDT) Received: by mail-pj1-x102c.google.com with SMTP id g24so151997pji.4 for ; Sat, 01 May 2021 15:13:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=tKMYZDEphWKkroXxR5Sir6Yx4flFE2DLa7jXfj4Nx10=; b=i9SvuTYHIIBh+FPd4/wiMkZkqAhIQZknAnBKV8PZZqZLi8QXlnGjk8oABSdTe11671 2+Mb1Rcs3wgTPqs0BuCMBm1WdHEHuYmgppl0iJn8Zp5CxwlvW7d035J19an3r0AW88LC RlFFiygGaSzzHshKhiV4DKzVghHs0iYYzB6zsJXMbygM11xCpZWs4YYbCiZtc0yUowDj mpVVo1Mx3jJKGXXOBHjHup7rS/I/aRiX5XemKot4Tj2m6RNWyaGU6rgN/yEBJOhRkjZj y09cKDc1MToXcB/aTYlsRfaWL4ftc8FG8YVQorXgYgmHZz5UQTffxPJae7J4nUBV7YSg FbYw== 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=tKMYZDEphWKkroXxR5Sir6Yx4flFE2DLa7jXfj4Nx10=; b=CYtRZdERQgwxJrIUUlXXD3OGW5QkE5iDbP4j/PxnlWPNuFmazt9G4BxVLFF9NvmBzN 79dMdJzYTOXDiZgszumvCaOE7bXQXX0RDBhLTCc94xNRbJCDdegWS3wmmrUNDKt+5OKH atoK+iPhu4mxiGV9xqfEOkehzkIYutDcQx4sMEDMWZMN4HoW6zJQU8dt86ySCXhq1M8+ fZV2e6yl23UUPUGjAfssn6zpGzIpiwtvjGuI1Z0tYM9lYDfX4S2GXioGIDFXN9bN2Mjp 5AsAXLAbNyYHSq2ABaNu2fi2v7lVwo0vP3DZcN23uSoAMuvOG3HBYjYfQ1roFRUdIga1 GUKg== X-Gm-Message-State: AOAM532QGQxh/zsmuEPYzw+BotVzOO/1KKKFSBI7mdylC0zp7EAZBVh/ swM4GhwVP2X/8wMWQEFf5A8= X-Google-Smtp-Source: ABdhPJxxwD+9Fu/7fi8rOW6pXhBCcTzpCz52HWryRodmMwzWVAifzysNtFRB5M9T3hYRr3XhvZExhA== X-Received: by 2002:a17:902:ac89:b029:e6:d199:29ac with SMTP id h9-20020a170902ac89b02900e6d19929acmr12147203plr.46.1619907195210; Sat, 01 May 2021 15:13:15 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 123sm5069834pfz.127.2021.05.01.15.13.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 May 2021 15:13:14 -0700 (PDT) To: Eliot Lear Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind , Michael StJohns References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> From: Brian E Carpenter Message-ID: <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> Date: Sun, 2 May 2021 10:13:09 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 May 2021 22:13:21 -0000 On 30-Apr-21 02:29, Eliot Lear wrote: > >=20 > Hmm=E2=80=A6. Sounds like a volunteer. Please feel free to suggest mor= e text! Ow, ow, that hurts. Well, here's a first cut (actually a second cut, part= ly based on https://datatracker.ietf.org/doc/html/draft-carpenter-rfced-m= odel-00#section-8): Recruitment of the RFC Series Advisor=20 The LLC is expected to lead the process of searching for and recruiting an RSA whenever necessary. The LLC will constitute a search committee representing the LLC and the various RFC streams. Each stream manager in the RSAB will either be a member of the search committee themself or nominate their stream's representative. The search committee will operate confidentially but must publish a description of its procedures and a timetable. [Some sort of equal opportunity/diversity statement, or do we take that for granted?] Role of the RFC Series Advisor This person will be a senior professional with deep knowledge of technical publishing. The RSA will operate by providing expert advice to the RSWG, and if requested to the RPC, on any relevant matters. For example, the RSA might be consulted about proposed changes to the style guide, RFC formatting in general, web presence, copyright matters, or archiving policy. The RSA is expected to attend and actively participate in all RSWG meetings and on-line discussions. The RSA is expected to be proactive by keeping the RSWG well-informed and by raising new issues as appropriate.=20 Further, the RSA is expected to ensure that RSWG consensus is well documented and communicated to the community, the LLC, and the RPC. This may include document authorship. The RSA is expected to show leadership for improvements to the RFC Series, for developing vision and policy documents, and for establishing community consensus for them. The RSA will operate under a part-time professional services contract with the LLC, with performance review by the LLC in consultation with the RSAB. Hope this helps... Brian C >=20 > >=20 > Eliot >=20 >> On 29 Apr 2021, at 01:00, Brian E Carpenter wrote: >> >> Eliot, >> >>>> My personal bias is to provide those we empower with latitude to nav= igate these sorts of situations, but that requires trust, something of wh= ich we seem to not enjoy an overabundance. >> >> I tend to agree, so I think we should focus more on defining the RSE/A=20 role, and then simply writing general requirements about the search commi= ttee (who constitutes it and which interests are represented). If we can'= t trust the person who constitutes it, we are in very deep trouble anyway= =2E (Previously, RFC8728 put the RSOC in charge of the search process, bu= t gave no details whatever.) >> >> Brian >> >> On 28-Apr-21 21:02, Eliot Lear wrote: >>> Hi Martin, >>> >>>> On 28 Apr 2021, at 10:51, Martin J. D=C3=BCrst wrote: >>>> >>>> Hello Eliot, >>>> >>>> On 2021-04-28 17:25, Eliot Lear wrote: >>>>> I have a different question that we should ask about anything that = goes into the doc: >>>>> Do we need to decide the question of who is on a search committee a= t this stage? >>>> >>>> If by "at this stage", you mean the next few weeks, then I'd answer = with NO. I guess we should first have a better description of the job its= elf. >>>> >>>> If by "at this stage", you mean the current overall process (which y= ou co-chair), then I'd tend to answer with YES. But some good arguments m= ight be able to convince me otherwise. >>> >>> >>> I will present my view of both sides of this argument, but it is obvi= ously for this working group to decide how it wants to proceed. >>> >>> We can say, =E2=80=9Chere is how the search committee will be formed,=20 here would be its members, here is who they shall consult, here is the vo= ting process by which they will decide, here are the decision criteria an= d their relative weights.=E2=80=9D >>> >>> On the one hand, when we are specific, there is no room for confusion=20 as to what will happen at each stage of the process. On the other hand, = that doesn=E2=80=99t guarantee, and may not even increase, the likelihood=20 of a good outcome. To get all of that stuff right would mean that we ful= ly understand the nature of the role and that either that nature is fixed=20 or our successors are committing to a revision of the process from time t= o time to reflect changes. We would also have to be able to amongst ours= elves agree that we have all of this right, based on the experience of ha= ving hired precisely ONE RFC Editor somewhat along these lines, with peop= le differing as to the quality of that experience. >>> >>> On the other hand, we can trust that the LLC will be mindful of all o= f this, and will form a search committee along general parameters to meet=20 the needs of key stakeholders, including the streams, as well as perhaps = others. The LLC could absolutely get this wrong. At that point, our suc= cessors might decide to further refine the process. >>> >>> My personal bias is to provide those we empower with latitude to navi= gate these sorts of situations, but that requires trust, something of whi= ch we seem to not enjoy an overabundance. >>> >>> Eliot >>> >>> >> >=20 From nobody Sat May 1 15:25:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACD1C3A1392 for ; Sat, 1 May 2021 15:25:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1OZ_eIfDl_c8 for ; Sat, 1 May 2021 15:25:40 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 424DD3A1391 for ; Sat, 1 May 2021 15:25:40 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id v191so1521881pfc.8 for ; Sat, 01 May 2021 15:25:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ggTeA3PLRGWMHSvrHgrn8kKKj+7434rmCoz0NK25AO0=; b=jvb0/JeT54TK7qouw3YD3Uav0vde16VKbmTzCl++9Dep5YgeWPwvhfGZb/5jEL5K9g KBtN0fEDVoJD0kxidbm6sIff4WxAVc4B+YBRqmpK+R4zlw5AZYG17X+s6UWtUr6P82Fq Xe7xu6p+XrAKyzdwJ+aEHCtYjq5onSFG/IK5Dht3Tau9Y0ntvlWcuhfJJ3EBrStnO4NB a66U1JpmMYtjUVaFVjAGSBbRL7tqDaTob+oEqWAiuXmzOujSgX/iKUIo0UrNqc83gllW LYhMdyZhU50uhvHpCc6qcDje+wnrB8X76NHA+rLhcdkyiLGCq0b9GxLL6vVv4bw48Dl5 +pdg== 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=ggTeA3PLRGWMHSvrHgrn8kKKj+7434rmCoz0NK25AO0=; b=UtARFiZ0xmJ11d/GG3C9lxG91fO2fPfuI660ZoLxU5IPh9YaBGBCbNoGhOf9c1j6qd hDfOZyv7DR7S90/Pekc4JanLVCRTyyaDyB4+0gzaSBramj1hM+UUkta3mjxMTjrOUJzi vOeFu3t3B8RPYq4gJXRhVHgX4WSWgRS7S+38DuJRvoJ0jsNK4mdXT5ed8zruL3+YdhJD so7QDkPcCPzpvZwffgsJTixalJoAs6U3X3ESpBkyC2QANJ/0KfX4MMda49sExggmEoRP JZ9iWDhv+8hCQAuprivZTRH1zgxu3lRJSfO7zSYLa/Kk9R8aM37tO0RU55nG+Gwdrait qVYg== X-Gm-Message-State: AOAM530SwR+nwbYpzUrG1qF/PYLXoJt57LOsVaoQVbaBLhjHC5iJ6ZJt 8jIcvb5ch3lvirL7inV60s6W+CVcABaTRg== X-Google-Smtp-Source: ABdhPJz5djI200YKSiEkw0ZrjPw6xkzStRuzNWavRLsoerl/gTQBHmcWgz5H5YTq68++gmWL4rHTrg== X-Received: by 2002:a63:f07:: with SMTP id e7mr11234308pgl.341.1619907937982; Sat, 01 May 2021 15:25:37 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id m12sm5790072pgn.24.2021.05.01.15.25.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 May 2021 15:25:37 -0700 (PDT) To: Peter Saint-Andre , Lars Eggert Cc: rfced-future@iab.org References: <287b0a81-018b-be7e-bacd-258799257c17@mozilla.com> <4B8700CD-4A49-4180-B4EF-CE70F7D53593@eggert.org> From: Brian E Carpenter Message-ID: <8fc013ab-e09b-dfa0-3225-00c29b8dde4e@gmail.com> Date: Sun, 2 May 2021 10:25:32 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] RSAE contract duration [draft-saintandre-rfced-model] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 May 2021 22:25:42 -0000 On 30-Apr-21 12:20, Peter Saint-Andre wrote: ... >> Section 6.1, paragraph 2, comment: >>> process in confidence. The initial length of service shall be for >>> one year, but then further extensions will be for three to five >>> years. >> >> It will IMO be difficult to hire the desired senior professional on a one-year >> contract. > > Whatever we decide on, I'll incorporate in the text. I'm somehwat against being too specific, since circumstances may change. Something like: Subject to individual circumstances, the expected length of service is expected to be at least three years, but with a mutually acceptable probationary period. [There's also the issue of what employment law applies in the country concerned, if we happened to hire an RSAE outside the US. In some countries, contracts greater than X months are treated as normal employment with all its implications.] Brian From nobody Sat May 1 15:35: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 3D0313A0765 for ; Sat, 1 May 2021 15:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 ceHsjlc-mnHN for ; Sat, 1 May 2021 15:35:39 -0700 (PDT) Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A4A3A0744 for ; Sat, 1 May 2021 15:35:38 -0700 (PDT) Received: by mail-pj1-x102b.google.com with SMTP id gj14so946092pjb.5 for ; Sat, 01 May 2021 15:35:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=E1/MgfQwXKFwelyv9o1mYJwwQTAl917um/oWshr7/BI=; b=FeYi68elIVTKpkxqUzNVXyPSDcODVSsBY0XfJmhTWtLamMs/+98LnmMmWgxvbkKmNF moynMe2SMMhDdKbbSDkDP0p/PVzOxJMaqM/LfQdBdYZTRH8P2Inyk/aHiewgKhcELFwD Wr2QC/ne8ZbNuQ9FWZPy5fb0NCZyyq7HlFowGm4z73UM2BpzUwFAgUYU38vwOX13nssA 5r7x9QZF4A7mh1e9svjFGKLvE0y4aEDLsFMMUOc7wXqyna9nH3DH8Hhg8se5gdO6oydi OxLIkI3lLaqSgu9CiM09qnVOZiH1q/rx9QauEIupGTHyXGxBPzaOwdE4ughgZHDdC2cy lsyQ== 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=E1/MgfQwXKFwelyv9o1mYJwwQTAl917um/oWshr7/BI=; b=UDi77GMQvrgeLaMTQZyd8rsRbiEot7Hqh0IXEMbd0Ucgc1xNBQ5rbGlkT3ijXvlbtg nF6ABfZmRG7/Kpu7sHUEcsBIDVWOoFzR1uEY+hRu08t+TksoUUQdU0kv14Y98gOfQ7xq hYABj0MV2nPBKcGnzn7EtQgXlZSURQskSma9zWmtx97gQhKfnH3ICskjj/Xl/SUtEDwN KJWw4JyisSmShJP+xcmMh269XWD57qkIl+38su7NzTEESsCi0x/3GKvRd/5yHXBsh2OL ccRjW5/D9fmFGYwqcSmCY34l251peEutXWYqCo7nCTQZHx0p1jsRFXPP2evqkaoUrA53 5VEQ== X-Gm-Message-State: AOAM533GJ0lRzPWFoM+NujHDMoIzY76QDL7wK+pfxJRmPBsdNInHUyw7 9yTAl+JBWb2BdD9ZnOYOBOtwCae7rVtC0w== X-Google-Smtp-Source: ABdhPJxfgRGrBJM3Oiv0lBs63ZeDbfCDxvfYN0Z+X65whAh5cHllXgkQfTwVtgO+i1C4S9ujLBAeXA== X-Received: by 2002:a17:90b:46d3:: with SMTP id jx19mr22315751pjb.31.1619908537787; Sat, 01 May 2021 15:35:37 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j7sm5271931pfd.129.2021.05.01.15.35.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 May 2021 15:35:37 -0700 (PDT) To: Eliot Lear , Michael StJohns Cc: rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> From: Brian E Carpenter Message-ID: <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> Date: Sun, 2 May 2021 10:35:33 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 May 2021 22:35:43 -0000 On 27-Apr-21 19:49, Eliot Lear wrote: > Issue 50. > >> On 27 Apr 2021, at 04:05, Michael StJohns wrote: >> >> The first paragraph of section 5.1.2, specifically the sentence beginning "The sole function..." does not appear to represent a consensus, and from my point of view is likely to contribute to a failure of the process. >> >> Basically, there needs to be a way for the RSAB to move documents along that they believe are necessary to provide for the operation of their streams and the overall RFC series, even if they are unable to gain consensus within the RSWG. And that assumes (and this is not necessarily valid) that the RSWG is both populated and functional. >> >> Loud noises (or total silence) in the RSWG should not prevent the RSAB from authoring a document, providing it for community comment and publishing it to address a need the RSWG has no interest in addressing. >> >> Section 5.2.2 must change to admit for RSAB originated documents. I'm not sure about this. Of course the RSAB can author a draft and bring it to the RSWG for discussion. But if they can't get consensus from the [subset of the] community [interested enough to join the RSWG] why does that give them the right to publish it anyway? We wouldn't accept the IESG publishing a draft that manifestly didn't have IETF rough consensus and we probably wouldn't let the IAB get away with it either. Why would we explicitly allow the RSAB to do so? Brian From nobody Sat May 1 15:36:13 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B3D3A0762 for ; Sat, 1 May 2021 15:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQjG-K9x7twe for ; Sat, 1 May 2021 15:36:06 -0700 (PDT) Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BD793A0691 for ; Sat, 1 May 2021 15:36:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4FXkbp1jsJz6GB5D; Sat, 1 May 2021 15:36:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1619908566; bh=NZ7jW1ixgJcY1WVCX5LqnNjYB3LOWdAJUEFcBFycGK4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Oy5u2Sz7v83Ony77icp/z4S3gD+3S8RiYtPz/cosaSzm1cwxYH/0ioGXsajOQH77q yrows7StvpvChkQ9bJqvEmXrwDyjI8khkrUFUTEjmc1TyRWd+pTUfAszIq/mTlpKQR JpJD2Eo6pgSVd5ZpS69IQD7i8xP+GzobPMwcgj/Q= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4FXkbm48QMz6G8x8; Sat, 1 May 2021 15:36:04 -0700 (PDT) To: Brian E Carpenter , Eliot Lear Cc: rfced-future@iab.org, Mirja Kuehlewind , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Russ Housley , Michael StJohns References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> From: "Joel M. Halpern" Message-ID: <6b406593-23b7-6db4-4f78-15832814be12@joelhalpern.com> Date: Sat, 1 May 2021 18:36:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 01 May 2021 22:36:12 -0000 Should the job dscription mention the RSAB? Yours, Joel On 5/1/2021 6:13 PM, Brian E Carpenter wrote: > On 30-Apr-21 02:29, Eliot Lear wrote: >> >> >> Hmm…. Sounds like a volunteer. Please feel free to suggest more text! > > Ow, ow, that hurts. Well, here's a first cut (actually a second cut, partly based on https://datatracker.ietf.org/doc/html/draft-carpenter-rfced-model-00#section-8): > > Recruitment of the RFC Series Advisor > > The LLC is expected to lead the process of searching for and > recruiting an RSA whenever necessary. The LLC will constitute a > search committee representing the LLC and the various RFC streams. > Each stream manager in the RSAB will either be a member of the > search committee themself or nominate their stream's representative. > The search committee will operate confidentially but must publish > a description of its procedures and a timetable. > > [Some sort of equal opportunity/diversity statement, or do we take > that for granted?] > > Role of the RFC Series Advisor > > This person will be a senior professional with deep knowledge of > technical publishing. > > The RSA will operate by providing expert advice to the RSWG, and if > requested to the RPC, on any relevant matters. For example, the RSA > might be consulted about proposed changes to the style guide, RFC > formatting in general, web presence, copyright matters, or archiving > policy. > > The RSA is expected to attend and actively participate in all RSWG > meetings and on-line discussions. The RSA is expected to be > proactive by keeping the RSWG well-informed and by raising new issues > as appropriate. > > Further, the RSA is expected to ensure that RSWG consensus is well > documented and communicated to the community, the LLC, and the RPC. > This may include document authorship. > > The RSA is expected to show leadership for improvements to the > RFC Series, for developing vision and policy documents, and for > establishing community consensus for them. > > The RSA will operate under a part-time professional services contract > with the LLC, with performance review by the LLC in consultation with > the RSAB. > > Hope this helps... > > Brian C > >> >> >> >> Eliot >> >>> On 29 Apr 2021, at 01:00, Brian E Carpenter wrote: >>> >>> Eliot, >>> >>>>> My personal bias is to provide those we empower with latitude to navigate these sorts of situations, but that requires trust, something of which we seem to not enjoy an overabundance. >>> >>> I tend to agree, so I think we should focus more on defining the RSE/A > role, and then simply writing general requirements about the search committee (who constitutes it and which interests are represented). If we can't trust the person who constitutes it, we are in very deep trouble anyway. (Previously, RFC8728 put the RSOC in charge of the search process, but gave no details whatever.) >>> >>> Brian >>> >>> On 28-Apr-21 21:02, Eliot Lear wrote: >>>> Hi Martin, >>>> >>>>> On 28 Apr 2021, at 10:51, Martin J. Dürst wrote: >>>>> >>>>> Hello Eliot, >>>>> >>>>> On 2021-04-28 17:25, Eliot Lear wrote: >>>>>> I have a different question that we should ask about anything that goes into the doc: >>>>>> Do we need to decide the question of who is on a search committee at this stage? >>>>> >>>>> If by "at this stage", you mean the next few weeks, then I'd answer with NO. I guess we should first have a better description of the job itself. >>>>> >>>>> If by "at this stage", you mean the current overall process (which you co-chair), then I'd tend to answer with YES. But some good arguments might be able to convince me otherwise. >>>> >>>> >>>> I will present my view of both sides of this argument, but it is obviously for this working group to decide how it wants to proceed. >>>> >>>> We can say, “here is how the search committee will be formed, > here would be its members, here is who they shall consult, here is the voting process by which they will decide, here are the decision criteria and their relative weights.” >>>> >>>> On the one hand, when we are specific, there is no room for confusion > as to what will happen at each stage of the process. On the other hand, that doesn’t guarantee, and may not even increase, the likelihood > of a good outcome. To get all of that stuff right would mean that we fully understand the nature of the role and that either that nature is fixed > or our successors are committing to a revision of the process from time to time to reflect changes. We would also have to be able to amongst ourselves agree that we have all of this right, based on the experience of having hired precisely ONE RFC Editor somewhat along these lines, with people differing as to the quality of that experience. >>>> >>>> On the other hand, we can trust that the LLC will be mindful of all of this, and will form a search committee along general parameters to meet > the needs of key stakeholders, including the streams, as well as perhaps others. The LLC could absolutely get this wrong. At that point, our successors might decide to further refine the process. >>>> >>>> My personal bias is to provide those we empower with latitude to navigate these sorts of situations, but that requires trust, something of which we seem to not enjoy an overabundance. >>>> >>>> Eliot >>>> >>>> >>> >> > From nobody Sat May 1 18:07: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 804163A1214 for ; Sat, 1 May 2021 18:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id awj5m9cdDYuf for ; Sat, 1 May 2021 18:07:25 -0700 (PDT) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-eopbgr1320112.outbound.protection.outlook.com [40.107.132.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A2A63A1211 for ; Sat, 1 May 2021 18:07:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HbxhI+NFkwbRVB/QQY9aj9jYsJSBvo7LleRC7VxAop5MGxRSF/5JYj/s5GoQmTzYrnxIaNkqwEOXGmJCJQiJH+4rnzImG4NThguEFO+tB1YWLL64QqIbaAoIK3xdhvejsyD4i0EGCLb0kwfiNYohmD5xnRnI8am67PwQHEtHUsvc24SCjRqKadxyHlbFVb7m2EGAczrGpxrbkV+3d3k9x6UW5rwgZOJE4+ze14R/+RfNS3+dSMchVM2gNJTBsPEg3cPy2kxjKVZOZ6xJ4lzEMDe/VlU4aQJzDOlaqemUIHRSO5X6FNchO3RqYnJ8lNPfrNm4cjynYeBe0oWM/eXTfQ== 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=QYePpUrUZ7L11sSo+vb/ISTZfMOrv/YNYx5pM/SSGbQ=; b=Lua/HfAjvKHcEZzNCP8huDbf2aExbqRWJb+DwCjkBbSeE74L9M9mBJYk5RtbPrEFH1WLDEnPKJ0rVb8gN0rKwLo++1zktSzq8BfnZfl3V37pbb1Jr2dcK7iZm8hNgTEHj9c1x5CP6u0xfxXcIjbc+4InHDJNOMt502bip+/rdu0850Djxy75+KJlf2ubtij6UhfSXeBRq5OJO8d7Of9XWKhAf95YQf7n8HkizH7yRDDPKjyR0C6kRXsIJLQBOJ46yuxf7Ptg+acRw30JKV9xl2Q2Q26R37Rm9b2r9SlKB0+XhPOL9iN/lCxZxbNeEppMdGjqAB3rk2fRsA61ZYyblA== 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=QYePpUrUZ7L11sSo+vb/ISTZfMOrv/YNYx5pM/SSGbQ=; b=TkWQCIIpWeyVPPNElFb5cJSwdB4q40OxTa6a7rerN/I2LP98zjWCL/+vw185SA6Q7PNIY6TJg0WvwOYeDHci6t58PoODlgnJwsSMlqekr4NPgNOXRMZQRzpzYBxP1e6LwBbqA4R6REvhZUIaslIwKJblEC6lLaDI7gdkmyki8PU= Authentication-Results: nthpermutation.com; dkim=none (message not signed) header.d=none;nthpermutation.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB4268.jpnprd01.prod.outlook.com (2603:1096:404:d7::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.35; Sun, 2 May 2021 01:07:15 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::5996:7da1:39fe:eca2%4]) with mapi id 15.20.4087.041; Sun, 2 May 2021 01:07:15 +0000 To: "Joel M. Halpern" , Brian E Carpenter , Eliot Lear Cc: rfced-future@iab.org, Mirja Kuehlewind , Russ Housley , Michael StJohns References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <6b406593-23b7-6db4-4f78-15832814be12@joelhalpern.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <321116ed-c97b-664d-ec6c-d63eab9a90d2@it.aoyama.ac.jp> Date: Sun, 2 May 2021 10:07:14 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 In-Reply-To: <6b406593-23b7-6db4-4f78-15832814be12@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [125.205.106.154] X-ClientProxiedBy: TYCPR01CA0087.jpnprd01.prod.outlook.com (2603:1096:405:3::27) 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.5] (125.205.106.154) by TYCPR01CA0087.jpnprd01.prod.outlook.com (2603:1096:405:3::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4087.28 via Frontend Transport; Sun, 2 May 2021 01:07:15 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 5ee95d85-a366-4667-5357-08d90d069fda X-MS-TrafficTypeDiagnostic: TY2PR01MB4268: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: IL11BJ+DsFrUnd//NO/V3Mxy171pcZaNZ+0GAvhpKVCt6FCcLK39zDZpFVrz/cHr6sxszUx8KzGHS8GZy08zbmmUACEv9Io3ncQRJ3ur3/Ye8AFhD3Boey8lv7MX6KlhLXYUY3tsNqOt4cB7PXRPhTH/zi3OSm+v1LNNRhn+M386TTGMRiWl+bY/tppGAtX6Rh/vMHF+fdtPsAMRZInjfq8do6hmhOlvBpbfj3qDNTtCXwYVXjBSqP2X9vpf8HdrqzJkt/sGT5TBz7KMq9tvG/JSqmqrtmtLgVxcvcQ65xVZnxxg7oKjK41e27h63ujoMbfC0fBFOS8tiDfEo+msm5O7g/sQBpARfeXFfNXU5ITILbyZHTqaK8q2WRBZkl43gLTZddd3i0wIDoZbUvzHaz6eD5ecH4XhGak89u62SmQpdI1xbZWTEPtEm97EFtW4rITgQTDCxgL2VtBQ+xOzEZuawDbglavgo12Oe8B9xvYMFCucb/W0+w32a0hfoWN01uKrPPU/THiwMWXXg/umot8ElzpvgDUMRHkTWod/7Is0qkeCoVTpFg2Xaj3m88Igbmi7nlDqsN80IlAlVIdCv85KEULD1Zr6PbtgoN8h4wlqXXmcAcc7XsnzzO01vycs9lSEkkMPt0QPAoNpOS1k0Yz6B50Be4+Ufm3YYSe0XjCrnQ4xJ/QxueGQMUXk6l3XWy4vfslEyWR7Ag7lHNL5Y9gurJi1T3VGSzHSYl3Z1eEEnm6uu4u2b/kELxVvttcvv629ko5nZhlw68Z/g3zueyXfvLPLu3XidyRjI6MvQNg= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(376002)(346002)(39840400004)(396003)(366004)(478600001)(31686004)(966005)(6486002)(36916002)(38350700002)(8936002)(5660300002)(2906002)(86362001)(53546011)(8676002)(38100700002)(31696002)(26005)(52116002)(16526019)(186003)(66476007)(54906003)(110136005)(786003)(66574015)(316002)(2616005)(16576012)(83380400001)(4326008)(956004)(66946007)(66556008)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?b2lFUVlQeENOanptSTZBM0lxcVFQRFlqZVFocDE5MEtBbDdVWDNEUUhPVFFB?= =?utf-8?B?MnZHdm1rdjhvNjZON3BFb3pldW1NQUwzSUxQS0V6eDBrQXJTRGM1WHJRR1Zu?= =?utf-8?B?QllVU2xGelpYUmRIeWh2Ym0rTEF0eDA1ZFpQeTIvdEU1YWRHNmQ2SWt6T1h4?= =?utf-8?B?WmZjUmgyeWRXUXk3YnVoeGthSGppRVBFMmRrSGNBNmROS3U5K01wQUtKNFJa?= =?utf-8?B?VTRxdmdSTHdZY2ZnL3AvNy8ySzBCdnNIZ05iSlFsSmJndXpZQUUxN3JHWXM0?= =?utf-8?B?SUR5dXhSZUo3VEs3RVlFbDhkanlNbkhkOUtwek1Ma0ZGUFVWQlRnUzV3VnBG?= =?utf-8?B?QmJPdGp6OTRvaTZFZzJkcHpiVnJOaUtqLzY0bi9UVUFLOUtvTmFYT3hQSkJP?= =?utf-8?B?RlhzaWhtUVdqRmhGUlJkelV4NjVBTU01dlhQL1FrdmhWbEp5aGFIc3JZdHlp?= =?utf-8?B?Y2dJOHlpU1ZLZXl2c3RybkpJV1IyR2VINitPUXhacjNpYUNjYTNtQzVFR28x?= =?utf-8?B?T3o3V1poVi9iS2pOK3dkaktIMmxwbDJQb0FocnFCSG5oUmlhbCt5ZTEzalpK?= =?utf-8?B?OVdrT0NyOTVBaTlxbTIvNzJLWW5lOUk5RUcyNm5nVXdMTk1rWkxydVU4dGo4?= =?utf-8?B?OTZmNVh5VGJNWGEwY01Jd1V4YjhCeFh2S2k2bHFSN0VzR1Nka05CdnB5Wm1Q?= =?utf-8?B?TjZpV1MvY3BwS1lTTTl5U280RUgya2xCLzFOSlhiYTc3WTV3Q3dOVlRpaC9X?= =?utf-8?B?bktMSktwcUt1aWp6azlGOGtWRVJ6OFR3OENZNDlpdWhBYUFpK0o4WjFxWHNl?= =?utf-8?B?TnFhOGdvaGc4cVBJUlFUemt2dUZnRGxpaEhkTVI4VHVXQmJyTjFmNkhVcGdh?= =?utf-8?B?YWxINzg0TFlXQ3VDNGNsUGtDOHZEYThmc0tScWg3UlVrdi9IbjJRUHJ3YW8w?= =?utf-8?B?bWkyRkkzaU9sb1JPRzZZMnhXbElPaWNUQ0Y5MVNvV2diazh5eGZzTlhzN3dX?= =?utf-8?B?Tk9jZXpaTUNpQTVEMFFYMFVMcGxIRUs4enV0Z25tVStYUDgyTHY1VW5ZbjVZ?= =?utf-8?B?NDJidzM1ZklSUFB6YmxOL0hhSGtYN29nek53UzZpRllFcXRmaWNMRWx3eWNW?= =?utf-8?B?L0Qzemk1RTB5d3czM3hEdUpyU0diS1N4MnpsVHhmQ2Y4SmlwbUc5UFhYQnhC?= =?utf-8?B?NXIrWHNCY3RyZHBLeGxuQ29zM2RUOGRCN1pqaWZBUHhtbG45c2draDVJSWs4?= =?utf-8?B?dnZKcDIvblVpeEVLbWg2SmtSUERpZHVoR0dSbzAvRW85YTF4bjhKWnZkT3Iy?= =?utf-8?B?WjJqTzlzNjYvaHVWL1V6am1TMVp1b1FDY3lPVC9zK1ZjWldIMUFlSllZdlZm?= =?utf-8?B?V0RJZ0pJQ2RQWkJzaXlNZXpwU0d5V2dkNDBQSUsvV3c1S200TWlxS2EwQWhB?= =?utf-8?B?a3AwbE5UWW8wVE9hZWs2dkppNTZTYlN5UTMxQWdKUzZSdlJIUitQTVV4cXlX?= =?utf-8?B?czVPdmE2bmFPMEM2dzMzdHNoNWlESUZnR0dpL1Q2clpVdjBCRWE2cHR3Mitq?= =?utf-8?B?MzZjajUxTDcyNDlkb3dBV2FVUzZtcTdhclFqRUxyUFFuQlRrZGRWcFdXMFlK?= =?utf-8?B?SGJmNVcyK0NHdmV6c3NqN2JPWXRKSUxhWGNjZms5ZnpaOHdtQmt3Zmg0SjZi?= =?utf-8?B?NmIzcTdIZmI1dGo3bnd4UjhoUlNpMFBIVXFVNHRQdnFWbzdSRnJRd3h4S2Uz?= =?utf-8?Q?FJdSDomUmPELfNdN+ASvuhau5oLSXOLxML8skf8?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 5ee95d85-a366-4667-5357-08d90d069fda X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 May 2021 01:07:15.3890 (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: uY8Z4gijPRgez4nYgfDUNufHtjgvZtiKZsW1BSLlkqkAYkrXr6GhecvGrc4o97yHpavzNkJ+D05bxO8wyDa37w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB4268 Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 May 2021 01:07:32 -0000 On 2021-05-02 07:36, Joel M. Halpern wrote: > Should the job dscription mention the RSAB? Well, it does, but only as the last word in the last sentence. I think changing "RSWG" to "RSWG and RSAB" (except for "RSWG consensus", probably) might do the job. Regards, Martin. > Yours, > Joel > > On 5/1/2021 6:13 PM, Brian E Carpenter wrote: >> On 30-Apr-21 02:29, Eliot Lear wrote: >>> >>> >>> Hmm…. Sounds like a volunteer.  Please feel free to suggest more text! >> >> Ow, ow, that hurts. Well, here's a first cut (actually a second cut, >> partly based on >> https://datatracker.ietf.org/doc/html/draft-carpenter-rfced-model-00#section-8): >> >> >> Recruitment of the RFC Series Advisor >> >>     The LLC is expected to lead the process of searching for and >>     recruiting an RSA whenever necessary. The LLC will constitute a >>     search committee representing the LLC and the various RFC streams. >>     Each stream manager in the RSAB will either be a member of the >>     search committee themself or nominate their stream's representative. >>     The search committee will operate confidentially but must publish >>     a description of its procedures and a timetable. >> >>     [Some sort of equal opportunity/diversity statement, or do we take >>     that for granted?] >> >> Role of the RFC Series Advisor >> >>     This person will be a senior professional with deep knowledge of >>     technical publishing. >> >>     The RSA will operate by providing expert advice to the RSWG, and if >>     requested to the RPC, on any relevant matters.  For example, the RSA >>     might be consulted about proposed changes to the style guide, RFC >>     formatting in general, web presence, copyright matters, or archiving >>     policy. >> >>     The RSA is expected to attend and actively participate in all RSWG >>     meetings and on-line discussions. The RSA is expected to be >>     proactive by keeping the RSWG well-informed and by raising new issues >>     as appropriate. >> >>     Further, the RSA is expected to ensure that RSWG consensus is well >>     documented and communicated to the community, the LLC, and the RPC. >>     This may include document authorship. >> >>     The RSA is expected to show leadership for improvements to the >>     RFC Series, for developing vision and policy documents, and for >>     establishing community consensus for them. >> >>     The RSA will operate under a part-time professional services contract >>     with the LLC, with performance review by the LLC in consultation with >>     the RSAB. >> >> Hope this helps... >> >>      Brian C >> >>> >>> >>> >>> Eliot >>> >>>> On 29 Apr 2021, at 01:00, Brian E Carpenter >>>> wrote: >>>> >>>> Eliot, >>>> >>>>>> My personal bias is to provide those we empower with latitude to >>>>>> navigate these sorts of situations, but that requires trust, >>>>>> something of which we seem to not enjoy an overabundance. >>>> >>>> I tend to agree, so I think we should focus more on defining the RSE/A >> role, and then simply writing general requirements about the search >> committee (who constitutes it and which interests are represented). If >> we can't trust the person who constitutes it, we are in very deep >> trouble anyway. (Previously, RFC8728 put the RSOC in charge of the >> search process, but gave no details whatever.) >>>> >>>>    Brian >>>> >>>> On 28-Apr-21 21:02, Eliot Lear wrote: >>>>> Hi Martin, >>>>> >>>>>> On 28 Apr 2021, at 10:51, Martin J. Dürst >>>>>> wrote: >>>>>> >>>>>> Hello Eliot, >>>>>> >>>>>> On 2021-04-28 17:25, Eliot Lear wrote: >>>>>>> I have a different question that we should ask about anything >>>>>>> that goes into the doc: >>>>>>> Do we need to decide the question of who is on a search committee >>>>>>> at this stage? >>>>>> >>>>>> If by "at this stage", you mean the next few weeks, then I'd >>>>>> answer with NO. I guess we should first have a better description >>>>>> of the job itself. >>>>>> >>>>>> If by "at this stage", you mean the current overall process (which >>>>>> you co-chair), then I'd tend to answer with YES. But some good >>>>>> arguments might be able to convince me otherwise. >>>>> >>>>> >>>>> I will present my view of both sides of this argument, but it is >>>>> obviously for this working group to decide how it wants to proceed. >>>>> >>>>> We can say, “here is how the search committee will be formed, >> here would be its members, here is who they shall consult, here is the >> voting process by which they will decide, here are the decision >> criteria and their relative weights.” >>>>> >>>>> On the one hand, when we are specific, there is no room for confusion >> as to what will happen at each stage of the process.  On the other >> hand, that doesn’t guarantee, and may not even increase, the likelihood >> of a good outcome.  To get all of that stuff right would mean that we >> fully understand the nature of the role and that either that nature is >> fixed >> or our successors are committing to a revision of the process from >> time to time to reflect changes.  We would also have to be able to >> amongst ourselves agree that we have all of this right, based on the >> experience of having hired precisely ONE RFC Editor somewhat along >> these lines, with people differing as to the quality of that experience. >>>>> >>>>> On the other hand, we can trust that the LLC will be mindful of all >>>>> of this, and will form a search committee along general parameters >>>>> to meet >> the needs of key stakeholders, including the streams, as well as >> perhaps others.  The LLC could absolutely get this wrong.  At that >> point, our successors might decide to further refine the process. >>>>> >>>>> My personal bias is to provide those we empower with latitude to >>>>> navigate these sorts of situations, but that requires trust, >>>>> something of which we seem to not enjoy an overabundance. >>>>> >>>>> Eliot >>>>> >>>>> >>>> >>> >> > . -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Sat May 1 18:27: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 797033A15A3 for ; Sat, 1 May 2021 18:27:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rygd-9xKWW5n for ; Sat, 1 May 2021 18:27:19 -0700 (PDT) Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A07F33A15A0 for ; Sat, 1 May 2021 18:27:19 -0700 (PDT) Received: by mail-pg1-x532.google.com with SMTP id t22so1269859pgu.0 for ; Sat, 01 May 2021 18:27:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=CGIBnYsRhdlLdMslr7tzxbTnkI1hg7mDh/l6iIDn2i4=; b=ltqHhm74WH2ALgV3yPS9U/9tXKRPtg1mHCzuhBqHqPeu1V2Y9OTCcNBjD+DWWUFyLx vtAJ8gWf8AN3z+z5/9e3S/LQZl08pCWIWhh3IsoNzgR/hQlujCuFisBdDx3h7IR57DTE Ybnbz+z/JdVfdZ7KBHy7Zr7BlYhv+reyFv79HM2/0U6dh9sAJH+amYf7Qg2U77PtZvvd 7GeMXhYaECqTe/iTcDKCapRVFUOZtub0tEodRgp88j5rPyVUYC7ORnrshol8pr8fdImi o5Ih7ovaZhgdX1cyooc5d8lCDJqOcmd4X9RY3qWGSkHJl4mvQlsnb4v/FQA23HkvZKxO eUyQ== 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=CGIBnYsRhdlLdMslr7tzxbTnkI1hg7mDh/l6iIDn2i4=; b=f6XgtVgr7P3nChD9wBKXk90AYfBh102WQR3HYjmPHUoHlX2O676Hkc5SwX5Fqqs0cL x9CqFBCY0T25qh/WR8cUQH/RIsJ9M1p48G1sYqkY5CqK5HMVIIKnViLq3En7Hfsvz6Km TYnCyw6ZmmvlCGVrg/vhgBndFB2w+zW/oWkT63xEuMNN8NH6Luu1Fs6avHAv+cwBEA4e Z8HPDg5HjNFL5qdT/qg+m161b5v9o1+Hfo9V5qeBXdEBlHIzfwKNM2AwPk6iunBpG1IP ENvc9d3cn6iPQMeqbfR3XOY79c70Vx9i9ssv6UmdAS5Tme6bcMgu4z53utr8Xgo/++RX Zyug== X-Gm-Message-State: AOAM530xS+BcGjXmnWsuTNPrLeBech4aNf7p60YwHDIk7IU+a+e1mhQe DtBH1GGzHq8uWC1+uWULPCw= X-Google-Smtp-Source: ABdhPJxIfensaYYTHiZ2FfYhsc0sdHz0s8fJGFVdKGzqLFEj/GPkPvPQPgwQq9q1YyiUzJdK++sdnw== X-Received: by 2002:a63:f056:: with SMTP id s22mr11497405pgj.369.1619918838505; Sat, 01 May 2021 18:27:18 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j127sm5605378pfg.124.2021.05.01.18.27.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 01 May 2021 18:27:17 -0700 (PDT) To: "Joel M. Halpern" , Eliot Lear Cc: rfced-future@iab.org, Mirja Kuehlewind , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Russ Housley , Michael StJohns References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <6b406593-23b7-6db4-4f78-15832814be12@joelhalpern.com> From: Brian E Carpenter Message-ID: Date: Sun, 2 May 2021 13:27:11 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <6b406593-23b7-6db4-4f78-15832814be12@joelhalpern.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 May 2021 01:27:24 -0000 On 02-May-21 10:36, Joel M. Halpern wrote: > Should the job dscription mention the RSAB? Yes, good catch, thanks. Brian =20 > Yours, > Joel >=20 > On 5/1/2021 6:13 PM, Brian E Carpenter wrote: >> On 30-Apr-21 02:29, Eliot Lear wrote: >>> >>> >>> Hmm=E2=80=A6. Sounds like a volunteer. Please feel free to suggest m= ore text! >> >> Ow, ow, that hurts. Well, here's a first cut (actually a second cut, p= artly based on https://datatracker.ietf.org/doc/html/draft-carpenter-rfce= d-model-00#section-8): >> >> Recruitment of the RFC Series Advisor >> >> The LLC is expected to lead the process of searching for and >> recruiting an RSA whenever necessary. The LLC will constitute a >> search committee representing the LLC and the various RFC streams.= >> Each stream manager in the RSAB will either be a member of the >> search committee themself or nominate their stream's representativ= e. >> The search committee will operate confidentially but must publish >> a description of its procedures and a timetable. >> >> [Some sort of equal opportunity/diversity statement, or do we take= >> that for granted?] >> >> Role of the RFC Series Advisor >> >> This person will be a senior professional with deep knowledge of >> technical publishing. >> >> The RSA will operate by providing expert advice to the RSWG, and i= f >> requested to the RPC, on any relevant matters. For example, the R= SA >> might be consulted about proposed changes to the style guide, RFC >> formatting in general, web presence, copyright matters, or archivi= ng >> policy. >> >> The RSA is expected to attend and actively participate in all RSWG= >> meetings and on-line discussions. The RSA is expected to be >> proactive by keeping the RSWG well-informed and by raising new iss= ues >> as appropriate. >> >> Further, the RSA is expected to ensure that RSWG consensus is well= >> documented and communicated to the community, the LLC, and the RPC= =2E >> This may include document authorship. >> >> The RSA is expected to show leadership for improvements to the >> RFC Series, for developing vision and policy documents, and for >> establishing community consensus for them. >> >> The RSA will operate under a part-time professional services contr= act >> with the LLC, with performance review by the LLC in consultation w= ith >> the RSAB. >> >> Hope this helps... >> >> Brian C >> >>> >>> >>> >>> Eliot >>> >>>> On 29 Apr 2021, at 01:00, Brian E Carpenter wrote: >>>> >>>> Eliot, >>>> >>>>>> My personal bias is to provide those we empower with latitude to n= avigate these sorts of situations, but that requires trust, something of = which we seem to not enjoy an overabundance. >>>> >>>> I tend to agree, so I think we should focus more on defining the RSE= /A >> role, and then simply writing general requirements about the search co= mmittee (who constitutes it and which interests are represented). If we c= an't trust the person who constitutes it, we are in very deep trouble any= way. (Previously, RFC8728 put the RSOC in charge of the search process, b= ut gave no details whatever.) >>>> >>>> Brian >>>> >>>> On 28-Apr-21 21:02, Eliot Lear wrote: >>>>> Hi Martin, >>>>> >>>>>> On 28 Apr 2021, at 10:51, Martin J. D=C3=BCrst wrote: >>>>>> >>>>>> Hello Eliot, >>>>>> >>>>>> On 2021-04-28 17:25, Eliot Lear wrote: >>>>>>> I have a different question that we should ask about anything tha= t goes into the doc: >>>>>>> Do we need to decide the question of who is on a search committee=20 at this stage? >>>>>> >>>>>> If by "at this stage", you mean the next few weeks, then I'd answe= r with NO. I guess we should first have a better description of the job i= tself. >>>>>> >>>>>> If by "at this stage", you mean the current overall process (which=20 you co-chair), then I'd tend to answer with YES. But some good arguments = might be able to convince me otherwise. >>>>> >>>>> >>>>> I will present my view of both sides of this argument, but it is ob= viously for this working group to decide how it wants to proceed. >>>>> >>>>> We can say, =E2=80=9Chere is how the search committee will be forme= d, >> here would be its members, here is who they shall consult, here is the=20 voting process by which they will decide, here are the decision criteria = and their relative weights.=E2=80=9D >>>>> >>>>> On the one hand, when we are specific, there is no room for confusi= on >> as to what will happen at each stage of the process. On the other han= d, that doesn=E2=80=99t guarantee, and may not even increase, the likelih= ood >> of a good outcome. To get all of that stuff right would mean that we = fully understand the nature of the role and that either that nature is fi= xed >> or our successors are committing to a revision of the process from tim= e to time to reflect changes. We would also have to be able to amongst o= urselves agree that we have all of this right, based on the experience of=20 having hired precisely ONE RFC Editor somewhat along these lines, with pe= ople differing as to the quality of that experience. >>>>> >>>>> On the other hand, we can trust that the LLC will be mindful of all=20 of this, and will form a search committee along general parameters to mee= t >> the needs of key stakeholders, including the streams, as well as perha= ps others. The LLC could absolutely get this wrong. At that point, our = successors might decide to further refine the process. >>>>> >>>>> My personal bias is to provide those we empower with latitude to na= vigate these sorts of situations, but that requires trust, something of w= hich we seem to not enjoy an overabundance. >>>>> >>>>> Eliot >>>>> >>>>> >>>> >>> >> From nobody Sun May 2 08:01: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 C931C3A0B16 for ; Sun, 2 May 2021 08:01:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QHKjDHR7J4bI for ; Sun, 2 May 2021 08:01:05 -0700 (PDT) Received: from mail-oi1-x22a.google.com (mail-oi1-x22a.google.com [IPv6:2607:f8b0:4864:20::22a]) (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 BF2953A0B01 for ; Sun, 2 May 2021 08:01:05 -0700 (PDT) Received: by mail-oi1-x22a.google.com with SMTP id m13so3101257oiw.13 for ; Sun, 02 May 2021 08:01:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lDYA4DgMRTcZzvPfut7MwpkNoe2hhcq1LCdMUuLfpos=; b=okXhyJ/Qj4AbMw77lyU54BwYax+IK+UKsdLtkA8iB/XCBZaSrgrzabd7njhMOy46d6 KVCFo2ikEGmQ2m2tnuD6r46iPSyoH+7eFWgW95TP4SsrPQqgUb797gFBir2zI2aTYUeG elkBTNgCb72rgpli6uYiLUHrtMZp0gw/NLcje2jJLgCIfSAnoGWrFZZQuAfB3wZwFLe/ oxvyX5oQVrSyELAH4epEl7FnwF9uFQlqc74IxI7YkUg4zMw8SeC6ZZpfdgp5JHxENY2L B+PtylMG0UlZQkUt7EzcE1yK0Xk6bUfNvaNT5Y80V7QIEO26TvqVibyAk65SeGT76vEe qNRA== 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=lDYA4DgMRTcZzvPfut7MwpkNoe2hhcq1LCdMUuLfpos=; b=KHj8B4ACX5KA1OPWvFgn5wVe6tiCutdGPPX2TVwHNvcbAyJSmcKeoDLEVnU6RmlmFs IL4pRSXyMij7bP23d3p2grMWiwMXaQ46TrWgxaVUJ6qQrZspPUis5FCjej24p4eztsX1 8jwW4nqbTLRubOL1wkf3T3/RTYe4/wd16HSzGWqiXm74cxgFRHiv19nt39sACOQm4eHw 56IoYz+m8llOZeIaG09oOWPhIvoUsARlpI1YjMw90XwMHU1vnl5V1bQxENGvszaGCJZw uYFPiooXCiO3Cir/gXLlEcpU6Xssu14krFEUHybRFc2hog7l0UtAN4dqez2pOMK3SZYb gq2Q== X-Gm-Message-State: AOAM530CZCDv6wMj5q3eeMLC3kpqJ0O0fG1enURa8XBjW1g/mqza1dwZ V3Z+8fCCgaeDMSdwngB18FVGauSTROvPNWKAUA/RGw== X-Google-Smtp-Source: ABdhPJzew1NX1ezB+5kSPI/zDKYKYUOGKQR6CpDeZlLEevQV11UrVfVBpbKy9tJ8B20z+garRUz+5q0vX6mi0J7FzD4= X-Received: by 2002:a05:6808:bcf:: with SMTP id o15mr11053771oik.133.1619967664158; Sun, 02 May 2021 08:01:04 -0700 (PDT) MIME-Version: 1.0 References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> In-Reply-To: <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> From: Wes Hardaker Date: Sun, 2 May 2021 08:00:27 -0700 Message-ID: To: Brian E Carpenter Cc: Eliot Lear , rfced-future@iab.org, Mirja Kuehlewind , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Russ Housley , Michael StJohns Content-Type: multipart/alternative; boundary="0000000000002b9a9f05c15a1ddc" Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 02 May 2021 15:01:08 -0000 --0000000000002b9a9f05c15a1ddc Content-Type: text/plain; charset="UTF-8" > > > > The RSA is expected to show leadership for improvements to the > RFC Series, for developing vision and policy documents, and for > establishing community consensus for them. > The pessimist in me wonders if "for establishing community consensus" sounds like this is an easy task that is always achievable. To put it another way, is it clear enough that functionally the RSA is an (A)visor because it lacks true authority over the situation. IE, community consensus is a mandatory part of the process. [I suspect that anyone considering applying for the position will hopefully ready through the litany of documents that make up our publishing system and wouldn't expect to come in and say "we're all switching to Libre Office" or something. Hopefully.] -- Wes Hardaker USC/ISI --0000000000002b9a9f05c15a1ddc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=C2=A0 =C2=A0The RSA is expected to show leadership for improvements to the=
=C2=A0 =C2=A0RFC Series, for developing vision and policy documents, and fo= r
=C2=A0 =C2=A0establishing community consensus for them.

The pessimist in me wonders if "for establishing comm= unity consensus" sounds like this is an easy task that is always achie= vable.

To put it another way, is it clear enough t= hat functionally the RSA is an (A)visor because it lacks true authority ove= r the situation.=C2=A0 IE, community consensus is a mandatory part of the p= rocess.

[I suspect=C2=A0that anyone considering ap= plying for the position will hopefully ready through the litany of document= s that make up our publishing system and wouldn't expect to come in and= say "we're all switching to Libre Office" or something.=C2= =A0 Hopefully.]
--
Wes Hardaker
USC/ISI
--0000000000002b9a9f05c15a1ddc-- From nobody Sun May 2 19:30: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 944F03A1B5A for ; Sun, 2 May 2021 19:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=syNTDGa1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DLeN0MGd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iSJZ71Odzoqz for ; Sun, 2 May 2021 19:29:57 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3200E3A1B52 for ; Sun, 2 May 2021 19:29:57 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 0E6741BBF for ; Sun, 2 May 2021 22:29:53 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Sun, 02 May 2021 22:29:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=cZtKYV3c7aJ1R5btpSACwnT+AW45PNu 9EZYF9/XLsto=; b=syNTDGa1WyoYVVhIhNKQsOKciGhC4biAb6jels6BtG4rzEB OjdjyohCG1vYSHdsS3qgvo231uyxbGAneC1wUG71+mHAClZJ/9wQUo4rd2qB9Wim 69vsDZIgzKNkXQwrbg1ugGDpTc17/rRjttE002i+hT5uXvy4ZcM4o6TuJao+niLs VJFvyPAN7dNlXIf+f7YWO9J7+xduOu9pYg+WxGjZVTeGAJUV8q8ejExqUhcijuMA QhQpYQwS20UZvXccVe/4Y90P6oUa1Q31QnJRIcA2WZXcje/dusZtiCRb1H8+v7uu ermpQMX/5kADXw3MPWXtojytqepHbqCCf1rVSrw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=cZtKYV 3c7aJ1R5btpSACwnT+AW45PNu9EZYF9/XLsto=; b=DLeN0MGdXpbVZlKXj4Bkxq t3lKqg2mWqv7cTFPiAkLno/CZsVboqTeZdbHLascNAdn3RUbXVXHoIjTeCp1TiQe hSxBJd6rICaAmSVyTzDCDg/vCX/bnvtCslUOQ420GeSJFM9sSIyniYsNYuDFIXw0 teX1B6hMDxDrUeh3r/9viyZemKhtn+q+xf+mVOg89gc2WWP7LFNafxWVLa3JILGS 6A/cA17SzBIOeM3puTbbI8Ng+aKOL/UyG6cJH9lHA9XZ0OJ6dgIE/aP2/4UX27ow PotPTarthvurPZtg6cfzQrulh8TNM5ZW+bwUwZc7H1rmtgP80+YImxTb1bljzJvg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefvddgudefvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepkeetueeikedtkeelfe ekvefhkeffvedvvefgkefgleeugfdvjeejgeffieegtdejnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5B5EC4E009C; Sun, 2 May 2021 22:29:53 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b Mime-Version: 1.0 Message-Id: <36d4343a-c04f-4ed3-b8db-2f6e0cd5eb2d@www.fastmail.com> In-Reply-To: References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> Date: Mon, 03 May 2021 12:29:33 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 02:30:03 -0000 On Mon, May 3, 2021, at 01:00, Wes Hardaker wrote: > The pessimist in me wonders if "for establishing community consensus" > sounds like this is an easy task that is always achievable. > > To put it another way, is it clear enough that functionally the RSA is > an (A)visor because it lacks true authority over the situation. IE, > community consensus is a mandatory part of the process. I share that concern. Perhaps the right way to phrase this is that the RSA is expected to be an active contributor to the RSWG. This includes proposing improvements to the vision for the RFC series or the policies and procedures that govern its operation. The RSA will engage in discussion with the RSWG on proposals that they and others make. I think that might avoid establishing unrealistic expectations. From nobody Sun May 2 19:57: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 4E6C43A1C5F for ; Sun, 2 May 2021 19:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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=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 hkN6QbdzUdPo for ; Sun, 2 May 2021 19:57:23 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F61E3A1C5E for ; Sun, 2 May 2021 19:57:23 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id 197so3534144qkl.12 for ; Sun, 02 May 2021 19:57:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=MLD48tY4sdlpraImTgxxAnqWrYTAOpo9CJAaRB1QS2U=; b=rs9yjpWz8ProGh4I6qI/ViFEPJ+hHqzimfn1vaJO3RKiSW0/NDbSYhkjpFlPiqeWXQ qSl4ZkvfEW5F+wEWKeyof5DSTIOnfKkMdjZkmk2D8Q2VW0NPFkxT+K9RqeE0QJEE9N8S /6ZsMJnlJP4Qk5m7sxlsCzHUwsbcHHRW4Tq6XND7cJzqU/UnJfEqmZDBCrZxmMhRHsZm 4prnce5HqNfzoZ8CJZZJwjRL92Hkh7WV5woc2O21t6utl1aKmTwRFOodQfBH5F/4wN3N wR8gIfse47Hqr/Zg93cVJshYpiZG54CoC/MampuqCci9ccmZOPvng4i07Eki9zSW1L/e CQpw== 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=MLD48tY4sdlpraImTgxxAnqWrYTAOpo9CJAaRB1QS2U=; b=jTDOenXdlkrE+Xh+7A+7cAz4Di0AlgSfQV/KqnoSNQeU48MVVZCjCDm9fUP6X9KUNB yAQIcpkPd+2KKe+bTKTz9NP/FNS9V5/YKDFmWD8jONDxbmheXH0sUw0bzmSfgeTeNphu YMZHEUbRDGiOK7L+VsJhbQgDwv6TvgaUohUMxVns9WjWzbvHRzLzaexomH+mGkrpLI8S tYgUFpDChAn3oVQnFsDpn6PmPVuiq8RE3X71AzTP8hi6gRdVS0gCaxP1N1wxxWa5LZ4R G64Y0ua+IlRJOej02+Qv9NRtv0B+7NDHh7dbbnIGIHLnR07wt3tPd+fhAaWM77HtWy/c FF4g== X-Gm-Message-State: AOAM530rraLePDQu+1N3hzyhIV4ZnX3TTmSL6cFO84KOepn0VCkh5ezX vReNLGpaNQHLYjXuXKTKhIM+GA== X-Google-Smtp-Source: ABdhPJwZLdQI2oHq6jxpe7yAafhZrBrM+ULLt/X9BK4WgvFlDyygVjwhED1zs1rxA7Tx4oMjg3aaKg== X-Received: by 2002:a05:620a:1036:: with SMTP id a22mr5206651qkk.186.1620010641962; Sun, 02 May 2021 19:57:21 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id u18sm7511175qku.39.2021.05.02.19.57.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 May 2021 19:57:21 -0700 (PDT) To: Brian E Carpenter , Eliot Lear Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> From: Michael StJohns Message-ID: Date: Sun, 2 May 2021 22:57:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 02:57:28 -0000 Comment just on the text. On 5/1/2021 6:13 PM, Brian E Carpenter wrote: > On 30-Apr-21 02:29, Eliot Lear wrote: >> >> >> Hmm…. Sounds like a volunteer. Please feel free to suggest more text! > Ow, ow, that hurts. Well, here's a first cut (actually a second cut, partly based on https://datatracker.ietf.org/doc/html/draft-carpenter-rfced-model-00#section-8): > > Recruitment of the RFC Series Advisor > > The LLC is expected to lead the process of searching for and > recruiting an RSA whenever necessary. The LLC will constitute a > search committee representing the LLC and the various RFC streams. > Each stream manager in the RSAB will either be a member of the > search committee themself or nominate their stream's representative. > The search committee will operate confidentially but must publish > a description of its procedures and a timetable. > > [Some sort of equal opportunity/diversity statement, or do we take > that for granted?] It's unclear that the stream managers or their designees will have any specific expertise in selecting an editor type, nor for that matter time or interest over and above their commitments to the IAB/IESG/IRTF, and the already stressed out ISE ( :-) ) .  I believe the RSAB needs some form of input into the criteria, and should get several opportunities to meet with the candidates and make their comments known to the LLC board.  I'm thinking that constraining the LLC in the above manner will lead to a non-optimal result. > > Role of the RFC Series Advisor > > This person will be a senior professional with deep knowledge of > technical publishing. > > The RSA will operate by providing expert advice to the RSWG, and if > requested to the RPC, on any relevant matters. For example, the RSA > might be consulted about proposed changes to the style guide, RFC > formatting in general, web presence, copyright matters, or archiving > policy. Keep in mind that the neither the  RSAB nor the RSWG are tasking entities under the new formation.  Whatever you have in mind needs to fit within the constraints of what's possible with a contract.    I think the above is general enough for the RSWG, but may require specific covering contract language for the RPC as it's a contract with its own constraints. The text above is not all inclusive of the role of the RSA/E. E.g. there are tasking and responsibilities that I expect the RSA/E will have that have nothing to do with the RSWG, especially on a day to day tactical basis.  E.g. "The role of the RSA/E includes providing expert..." and "...if requested by the LLC within the contract terms, shall provide advice to the RPC..." > The RSA is expected to attend and actively participate in all RSWG > meetings and on-line discussions. The RSA is expected to be > proactive by keeping the RSWG well-informed and by raising new issues > as appropriate. Yup.  General enough.   But s/RSWG/community/.   The RSWG is not a filter for the RSA/E or vice versa. > > Further, the RSA is expected to ensure that RSWG consensus is well > documented and communicated to the community, the LLC, and the RPC. > This may include document authorship. Um... what?  This puts the RSA as a process facilitator for the RSWG and gives them responsibilities to keep the record of the RSWG???  That's new AFAICT.  The document authorship does not necessarily imply the rest of this. > > The RSA is expected to show leadership for improvements to the > RFC Series, for developing vision and policy documents, and for > establishing community consensus for them. This describes the RSA/E responsibility - it needs to be balanced with authority to make things work.  Otherwise we might as well hire a ghost writer. > > The RSA will operate under a part-time professional services contract > with the LLC, with performance review by the LLC in consultation with > the RSAB. The form of the engagement is up to the LLC and the RSA/E.  It might be as you describe above, or it might be employment.   This was already settled elsewhere I believe. > > Hope this helps... > > Brian C > From nobody Sun May 2 20:02: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 E54553A1C87 for ; Sun, 2 May 2021 20:02:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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=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 htokaDkKbmXh for ; Sun, 2 May 2021 20:02:50 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52AC93A1B55 for ; Sun, 2 May 2021 20:02:50 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id z5so2781593qts.3 for ; Sun, 02 May 2021 20:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=aJCyr8WmuohqXH/996Ka4xxOEFrScwbNnxzX4WPbyP4=; b=g/6SBJrEitNeEKt4SYoTSyyuAM+jjWLAQk2mdOoLiph+FYH/t1Ivcv16WLav50Whvn QgYEEmbGtvYsLLrHHBKcNMAJqoHj9xNbA7v0aGDgrWBBD2w4QQSUhD8EZQ+wZPtLfPl3 x2WqHF8vp65Iqfwki6m6sSgDEGnOHkrxrG3mtjZtHXatZQhV+SL6EwxSNCod4iFmxWsF gcaUnmCnUOqN1uavsmk8DfTEDS5sbzIb7GRKFsGN8XkXsX+D5UPsBzFBiqJQPm1MWga/ h0bpTY/ReA1ODe1RhGGpGAkryfZQ2vWZaaiS2tzcXLhtuznOZqzOyVJrYPBOMEZ1w1M3 pBzQ== 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=aJCyr8WmuohqXH/996Ka4xxOEFrScwbNnxzX4WPbyP4=; b=NP1NBdcgeRXiSxLiaSyKFgMKNKNyhM+uqKLUjLyKtm1vohtPuW9zXpvkhw/ywWzP8H RFqaT3X7vBNXadTEHOl/tna4V+FUQQQ8/of11ecTlqnozs3M3pgvQrxY5rMQPI95pl6V ThLiPWyHhWO9YukaLG+JYq5lPFELHkXbTpLJMfYnY6+Q7+vJgB1jDw411OW3IvLnxJ1x 31BR/XV7T0DHo1M9XtIoI+ADO1juvh+kMfLQkT5fswfXOrIvIElPteagpRRdyWfvm0rB K3muLrfbrnQZIwFYQjItYKJFbwnobIv5fOBYQ/gTGfIwux1dV8u99iiwfJ41CSNKCzbn /sCw== X-Gm-Message-State: AOAM5338CQ+l2zpqre52ENwbhjIHcBb92o6+Zjwqbcwvvh7M4thKJF1u tGO9v7+kP0EEhpn8SC8MWQkINOfokXQBXU9R X-Google-Smtp-Source: ABdhPJxqp4sEOA9hHZK95MOFn2uaO79Chb3Aa0ZFuy62zkz4vnagv8sqm1vlYzNMQf0nymi5CDwFtA== X-Received: by 2002:ac8:75ca:: with SMTP id z10mr15081940qtq.137.1620010967843; Sun, 02 May 2021 20:02:47 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id h16sm7658672qto.11.2021.05.02.20.02.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 May 2021 20:02:46 -0700 (PDT) To: Mirja Kuehlewind Cc: Russ Housley , rfced-future@iab.org References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> From: Michael StJohns Message-ID: Date: Sun, 2 May 2021 23:02:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 03:02:55 -0000 Hi Mirja - See my note to Brian - but lack of applicable expertise, and lack of time spring to mind.  I'd rather have a few people with specific knowledge and an ability to commit to time to the search, than many with no one really responsible for actually performing the work, or lacking the aforementioned specific knowledge of what makes a good editor/publisher. I think the better alternative is make sure the streams (not the stream manager per se) have substantial input into the job description (details past what we're working on here), and an opportunity to interview the various candidates and make their concerns and thoughts known to the search team.  I think the search team then gets to do its job and present the candidates in some sort of ranked order to the LLC for contract negotiations. Mike On 4/28/2021 4:12 AM, Mirja Kuehlewind wrote: > Hi Mike, > > Why do you think the stream manager should not be part of the search committee? > > Mirja > > > >> On 27. Apr 2021, at 21:58, Michael StJohns wrote: >> >> On 4/27/2021 1:55 PM, Russ Housley wrote: >>> At the same time, the person that is selected needs to work well with the stream managers, so they need to be included directly or indirectly. >>> >>> Russ >> >> Yes! I'd probably leave them off of the search committee, but I would probably arrange for interviews between the RSAB and the various candidates with the search committee present. >> >> Mike >> >> >>>> On Apr 26, 2021, at 10:09 PM, Michael StJohns wrote: >>>> >>>> Section 6.1 - Composition of the search team. Explicit include or exclude of any of the RSAB, the RSWG participants or chairs? Other Nomcom selected folk? The process needs to be fair, and the selection criteria should be such that bias on the selection committee is minimized. >>>> >>>> >>>> -- >>>> 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 From nobody Sun May 2 20:17: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 44E643A1CFC for ; Sun, 2 May 2021 20:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-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=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 TVGFX_cP_QV9 for ; Sun, 2 May 2021 20:17:15 -0700 (PDT) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 E3B5C3A1CFA for ; Sun, 2 May 2021 20:17:14 -0700 (PDT) Received: by mail-qk1-x734.google.com with SMTP id q127so3883368qkb.1 for ; Sun, 02 May 2021 20:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=2xxdzbk4Hf/psrc1SG18HFTWj2fxOwXANKMKRQ90KPo=; b=2JPYRkhn/0eQunD3j1HgNl0GI4dgq07DxzJFezZXE3oIJSfFiQOUTqE8d2QlXvwPS+ iCZjInmA4HjwsSdpb9OZqictVz4XBKwF2uTmGyqiOG+cqJU4lM5+pYY1D1YaGQYHdFao V0f1p0tIn9HEwv4cf/XHEm7TKV5TdGAfXrkElz+O7AkAsXGtQecUVqPU6x2AKg/FX7G2 to6LU5SehSRk21gJbG6VoE1E3Vzratirhdm07kYQ/dGlaoVbJknB9vwYlLNzvHeS2QQW Yc9YJI95h2OIdayu0kL/RWze34DadOFGFSUbXQrJbfAvzbP9UgGZX3qA8VbdhFFO7Leb NUZw== 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=2xxdzbk4Hf/psrc1SG18HFTWj2fxOwXANKMKRQ90KPo=; b=PPj2t/kjviYiRqm8DZXkhfluFaMLV21rtywy/NzpP6/jF4N/ec6TxBX/yM/tTqDOft F5BUqCPtpTzeUwUKFef+yzgyDAuL8HbR8dt8rF7+EZhtCoM2HmHbmki05l41Jj8RrhZr WTLCLXNHH+4fljnezDuOBRZkCGdp2Apzch6a6AoZ4oM4j/aGIs8alAM5viA8NSvvkeNO jJm2KQJaQFwOGZX7bbzj2FtJ55OId1pFvuoXnTpv5uzJzPBbAXbLhNU8E71UGo/wdV31 Ai+SoERgmpE2j5yZcGGopHA7nhhsuS0WCJjAk4bKjOlFbNRgJcTWvBSYKIeFUnn0IaVK bo3A== X-Gm-Message-State: AOAM530gNEaV16nNB3tURjBV994dIkbZN/BwecDHf1XSiIm0T3JK27cQ Gh7aYFeerFJ1h4fFx5/bWg/oKnPfRhfHSt/y X-Google-Smtp-Source: ABdhPJyLAy2z8IC3hbEfNaygkXIy3fPTeCVDOEqAv+NCjpLFsm1lPNxwBF6KKXFr7d1gr8ydD7k6CA== X-Received: by 2002:a05:620a:232:: with SMTP id u18mr16501175qkm.213.1620011832620; Sun, 02 May 2021 20:17:12 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id h8sm7774548qkj.4.2021.05.02.20.17.11 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 May 2021 20:17:12 -0700 (PDT) To: Brian E Carpenter , Eliot Lear Cc: rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> From: Michael StJohns Message-ID: <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> Date: Sun, 2 May 2021 23:17:10 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 03:17:19 -0000 Below On 5/1/2021 6:35 PM, Brian E Carpenter wrote: > On 27-Apr-21 19:49, Eliot Lear wrote: >> Issue 50. >> >>> On 27 Apr 2021, at 04:05, Michael StJohns wrote: >>> >>> The first paragraph of section 5.1.2, specifically the sentence beginning "The sole function..." does not appear to represent a consensus, and from my point of view is likely to contribute to a failure of the process. >>> >>> Basically, there needs to be a way for the RSAB to move documents along that they believe are necessary to provide for the operation of their streams and the overall RFC series, even if they are unable to gain consensus within the RSWG. And that assumes (and this is not necessarily valid) that the RSWG is both populated and functional. >>> >>> Loud noises (or total silence) in the RSWG should not prevent the RSAB from authoring a document, providing it for community comment and publishing it to address a need the RSWG has no interest in addressing. >>> >>> Section 5.2.2 must change to admit for RSAB originated documents. > I'm not sure about this. Of course the RSAB can author a draft and bring it to the RSWG for discussion. But if they can't get consensus from the [subset of the] community [interested enough to join the RSWG] why does that give them the right to publish it anyway? > > We wouldn't accept the IESG publishing a draft that manifestly didn't have IETF rough consensus and we probably wouldn't let the IAB get away with it either. Why would we explicitly allow the RSAB to do so? > > Brian You're mistakenly conflating community consensus with RSWG consensus, and I submit those are nowhere close to the same thing. I think there are three paths through this process - and these are similar to what we do with the IESG already: The "normal path" of RSWG origination -> RSWG consensus -> Community Consensus (e.g. LC which I think needs to be weighted more than RSWG consensus) -> RSAB approval -> publication RSAB Origination -> RSWG commentary -> Community Consensus -> RSAB Approval -> Publication Individual Origination -> RSAB Adoption -> RSWG Commentary -> Community Consensus -> RSAB Approval -> Publication If the RSWG fails, or as is more likely, is three angry participants plus the RSAB, it doesn't act as a blocking point for the RSAB to actually get required work done.  The RSAB still needs to make its case to the community to go forward, and it has to address any comments made by the RSWG participants, but it has a path forward if it can convince the rest of us. Also, I submit that we've published MANY documents by the IESG and IAB that have had grumbling by the community, but I would argue lack true community consensus - usually due to an extreme lack of interest by the community as a whole.  cf pretty much any of the documents related to the operation of the RSOC.   Or for that matter, many of the documents we used to take over the RFC process from ISI in the first place. Later, Mike From nobody Sun May 2 20: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 5A81F3A1D08 for ; Sun, 2 May 2021 20:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 klYqgZmJ0hOg for ; Sun, 2 May 2021 20:18:54 -0700 (PDT) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C71EF3A1D07 for ; Sun, 2 May 2021 20:18:54 -0700 (PDT) Received: by mail-qk1-x735.google.com with SMTP id i67so733555qkc.4 for ; Sun, 02 May 2021 20:18:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=g+tDLMedwF4bYU29dScE+FFPPcuUZ5sVavJpvPGgG7E=; b=eGjIjjLVgesJ3EPPBThScfpFK70Hebg2ucM1NYlxRHhgPGAjOWvFSpiSA0XVcjm6Yk hcYVxMAIfYi1gOocLOpXwSaLlwzeuT4U/IbwIMEZNZY2uetXa718lcchidCMHSFVp2E5 r1JaWBm8qiCiIlidGukej3h3mN9dLql0zeisSBo6TTwqnvSvqGim6s66ryR2hu6FAu1T gpfp186WyX88DwLucYaL7d1TkVHPqs7q5qf9pTIeVVcsxIxvtLMXvOqTPBvvwTsBHd8s 7cE/cp4icpioCHgpyaPyr4LLiK7OXbuxXxpdgtlLhLxwjt9WT/FHfTno7RACaMczoGiK 10kA== 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=g+tDLMedwF4bYU29dScE+FFPPcuUZ5sVavJpvPGgG7E=; b=cLRkAWSFBvjhQiaQ/yfozc77vXsLYZuBa0PQxPFJqh1F8W1wJ/4YJHtz5RvSOMoO9h YGHGsXaa7Abv4J90SPV2aF3vuLfkMGeDSMbV2BkwvXPDISM5Dnu3RoA0zoKhXpUpwRpg jYGBT1WSNKB7NMaaviG9gI8d7NMcLuFXivXMY37ZE1AUUMHS3QnLlzrbxAlvd/qtLiI7 dZj+gWUZqZcSqpXkrXwII46Em9y99g67SiFjEGQbweOfIONOC1hUtPkcX5/OwnQP64hb Yob9wumbHmVnLFmlSVmHbOkBcq6uuv+tAs9Ehy8ZD7U5hngVwhHEsxBgRi8w8RjrUzjH L1+Q== X-Gm-Message-State: AOAM531wWBsZ3YItGSf8qRWb/3XQ0vzG70aGMldJpL1THOO8PCMA++7K kUYsE50IMuiiXKzjDF1089apSAeZ4xEuinO5 X-Google-Smtp-Source: ABdhPJzimkTZng0ml+S4+xfokNz8LGxHj91lszk3Es5+yyED7NeT9z+x5u8D3VAcHcU8jQtYCrQ0Wg== X-Received: by 2002:a37:a051:: with SMTP id j78mr797000qke.216.1620011933038; Sun, 02 May 2021 20:18:53 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id u4sm7454347qkp.22.2021.05.02.20.18.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 02 May 2021 20:18:52 -0700 (PDT) To: Wes Hardaker Cc: rfced-future@iab.org References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> From: Michael StJohns Message-ID: Date: Sun, 2 May 2021 23:18:51 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DFC9FC7090DFF938E2F08818" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 03:18:57 -0000 This is a multi-part message in MIME format. --------------DFC9FC7090DFF938E2F08818 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/2/2021 11:00 AM, Wes Hardaker wrote: > > > >    The RSA is expected to show leadership for improvements to the >    RFC Series, for developing vision and policy documents, and for >    establishing community consensus for them. > > > The pessimist in me wonders if "for establishing community consensus" > sounds like this is an easy task that is always achievable. > > To put it another way, is it clear enough that functionally the RSA is > an (A)visor because it lacks true authority over the situation. To be clear, you meant the above to have a "?" at the end - correct? > IE, community consensus is a mandatory part of the process. > > [I suspect that anyone considering applying for the position will > hopefully ready through the litany of documents that make up our > publishing system and wouldn't expect to come in and say "we're all > switching to Libre Office" or something.  Hopefully.] > -- > Wes Hardaker > USC/ISI --------------DFC9FC7090DFF938E2F08818 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/2/2021 11:00 AM, Wes Hardaker wrote:


   The RSA is expected to show leadership for improvements to the
   RFC Series, for developing vision and policy documents, and for
   establishing community consensus for them.

The pessimist in me wonders if "for establishing community consensus" sounds like this is an easy task that is always achievable.

To put it another way, is it clear enough that functionally the RSA is an (A)visor because it lacks true authority over the situation. 

To be clear, you meant the above to have a "?" at the end - correct?

IE, community consensus is a mandatory part of the process.

[I suspect that anyone considering applying for the position will hopefully ready through the litany of documents that make up our publishing system and wouldn't expect to come in and say "we're all switching to Libre Office" or something.  Hopefully.]
--
Wes Hardaker
USC/ISI


--------------DFC9FC7090DFF938E2F08818-- From nobody Sun May 2 21:43: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 9FB293A1FE8 for ; Sun, 2 May 2021 21:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=o8PkLoqX; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nSJgccS+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoqsgcC56MyP for ; Sun, 2 May 2021 21:43:42 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DEA13A1FE5 for ; Sun, 2 May 2021 21:43:42 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id A4911193C for ; Mon, 3 May 2021 00:43:37 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 03 May 2021 00:43:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=422UTzAonnIdygVkpeyo63ar5W8F5Sr 4tVLUy3fjWlA=; b=o8PkLoqXtKWNeWiXQBnQOtWApGkb1PHhXuixxDJ3Ingubae otPCgUuus9MKy/WQWaKMNvMJwcKWaKOWanzVreJEb62KtFOh3UBaxoB+bBTp/nhv tYv4ebygyHbOiVoWf7RWCMZLNEMkNXWHtgnMniA3edm7+PJmyw9wGv2lZNBT65jv QWFJ2tEAUxcaZopOFkWgksu6fDFdZslkK/RuBDrR8L6N0yuMRaNMZLAlaZ2staiP sVtLFXs9j6atAbRuruOZZIqUi56Bukve/i/a4e+W0UU+UsksRyQwSIh28r0AUPMt 6jmPyad1fKx8Zs/yUTfDSAN7c/JpdKRvl9RAcjw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=422UTz AonnIdygVkpeyo63ar5W8F5Sr4tVLUy3fjWlA=; b=nSJgccS+mNiDkpnAWbEBBJ 4eEaM2Vvt4FTJjNkm98bf2alxNnlPSk5q0ftmWqlNFA56L3PuwEv7moeHlOusAau 7XuX35Da0XL9GwkfsgXROmaElTBoAmaln1oHOtAUoRnpqrg0jYwUxLePzttCKJZT YhJycZuk87XqKHZiuFJ9+/4Ove4+U0JdAvsPCY8OAMRSFHFaUKi59r1tDW3l+6om KSxUSOsvznGFgkzIq4T1qHZa0JAqLYDRKxth3dlsT8KEx31UW02A74hdx3ndySdM Os5r+7Ooox3EvDrfJNjVY0CXsdYJGqb8/6zs5v3vmnjcthPoLAE59tMIQ9K1aU0A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeffedgtdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 021D64E016F; Mon, 3 May 2021 00:43:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b Mime-Version: 1.0 Message-Id: <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> In-Reply-To: <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> Date: Mon, 03 May 2021 14:43:15 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 04:43:48 -0000 On Mon, May 3, 2021, at 13:17, Michael StJohns wrote: > You're mistakenly conflating community consensus with RSWG consensus, > and I submit those are nowhere close to the same thing. I don't think that it's a mistake, but a feature. Though I acknowledge the usual conditions (who can be bothered to turn up and comment) are challenging, deliberately deciding that the two reduce to the same in every way I can imagine. Do you have arguments in favour of the alternative paths that indicate valuable features? I realize that you are concerned about things getting stuck in committee. Providing the RSAB the tools to ignore that community is dramatically different than acknowledging that the rough consensus thing is imperfect and working within those constraints. I don't agree that by insisting that a Working Group reach consensus, we are creating a system that is overly prone to this obstruction attack. Yes, obstructionist behaviour is hard to deal with, but we know how if there is the will to do it. From nobody Mon May 3 00:49: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 F17003A0EEA for ; Mon, 3 May 2021 00:49:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CyLR9slqIMMq for ; Mon, 3 May 2021 00:49:19 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B87283A0EE5 for ; Mon, 3 May 2021 00:49:19 -0700 (PDT) Received: from p200300dee707b30081a6c705ec136d0d.dip0.t-ipconnect.de ([2003:de:e707:b300:81a6:c705:ec13:6d0d]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1ldTKJ-0007qB-80; Mon, 03 May 2021 09:49:11 +0200 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: Mon, 3 May 2021 09:49:09 +0200 Cc: Peter Saint-Andre , "Joel M. Halpern" , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <92AEF5DA-0278-4ED0-9A1D-166F952FEEAF@kuehlewind.net> References: <287b0a81-018b-be7e-bacd-258799257c17@mozilla.com> <7fbef1fe-2e5b-3ad7-e416-500c224d2a1e@mozilla.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1620028159;b2b58222; X-HE-SMSGID: 1ldTKJ-0007qB-80 Archived-At: Subject: Re: [Rfced-future] ultimate policy authority (was: Re: draft-saintandre-rfced-model) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 07:49:22 -0000 > On 1. May 2021, at 23:38, Brian E Carpenter = wrote: >=20 > And thinking about the RSOC's problems, one of our goals > should IMHO be to ensure that we don't mix up contractual oversight = (the > LLC's role) with policy/strategy choices (the community's role). +1= From nobody Mon May 3 06:28: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 6B38B3A1189 for ; Mon, 3 May 2021 06:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx_sbib0IfmT for ; Mon, 3 May 2021 06:28:40 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7A23A1185 for ; Mon, 3 May 2021 06:28:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11620; q=dns/txt; s=iport; t=1620048520; x=1621258120; h=from:mime-version:subject:message-id:date:to; bh=j91H89LxBRbLs/ETPxFUknk3WxrnwM0dUzjr5PuRkmQ=; b=JzRlihYgM/A8YdkbBOf/ROlgvhskusEuzLVFjBV5lQsO/nM9Nain8icx DaldmINYTtAV3Vy0eye/dTlFyDPT3/tATyMMQ4h6IpSOqaiNaM6LSuv4M SmPmnpCZgdeG2HC0Zx7JO6fr7ifFipySQRdeEDqylPcLAurjnj/Z19XkR c=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ANAAAf+o9glxbLJq1aHAEBAQEBAQcBARIBAQQEAQGCA?= =?us-ascii?q?wcBAQsBgyFWAScShHWIJGCIcJRZhimBfAQHAQEBCgMBASwIBAEBhk4mNAkOA?= =?us-ascii?q?gQBAQEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBaIVQDYZuSDU2Aj+DJAGDB?= =?us-ascii?q?w+ZPY4WeoEygQGJcQoGgToBgVKFMgGGWkOCC4EVJxyDHYJgAgIYhF02gisEg?= =?us-ascii?q?VWBIYELIAINFz8MOwQ1YJEAi16BKp0YgxoEg0GBSYRrkzUFIoNUiwyWQqEuk?= =?us-ascii?q?1oBhAYCBAYFAhaBVDiBWzMaCBsVZQGCPz0SGQ6OOINXil8/A2cCBgEJAQEDC?= =?us-ascii?q?Y0PAQE?= IronPort-HdrOrdr: A9a23:Wt8eRKp6CSMOYpJhKZW3eC4aV5rCeYIsi2QD101hICF9WMqeis yogbAnxQb54Qx9ZFgMkc2NUZPgfVry7phwiLN6AZ6HUBP9sGWlaKFuhLGN/xTFGynzstFQzr 1hda8WMrHNJGN3h8r7/wW0euxIqLK62Zq1juTTxWoFd25XQpxnhj0YNi+rVml/RAxLHvMCZf mhz/sCgSa8cnIKacn+IX8JU4H41rj2vaOjRwIaDBg67wTLtxeU0frRFhiV2Qp2aUIs/Ysf X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,270,1613433600"; d="asc'?scan'208,217";a="35624052" 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; 03 May 2021 13:28:35 +0000 Received: from smtpclient.apple ([10.61.144.27]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 143DSY3F027480 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 3 May 2021 13:28:35 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_7A0D0A5D-11C2-49F2-88FB-4B864806E779"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: Date: Mon, 3 May 2021 15:28:33 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.27, [10.61.144.27] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] House keeping: propose to close issues 4-8, 10, 12, 13, 15 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 13:28:45 -0000 --Apple-Mail=_7A0D0A5D-11C2-49F2-88FB-4B864806E779 Content-Type: multipart/alternative; boundary="Apple-Mail=_D963922C-3367-4A46-ABDA-A7649258419D" --Apple-Mail=_D963922C-3367-4A46-ABDA-A7649258419D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [I thought I had sent this, but apparently not.] All, We have previously marked as consensus a number of issues, and we have = agreed on at least a starting point. We got there through a circuitous = route, requiring some cleanup. Thus I propose to close the following = issues, with the proviso of course that new issues can be open on the = text that is present. Please comment within two weeks of this posting if you have concerns. = If anyone has concerns, we=E2=80=99ll leave these issues open for = discussion, but let=E2=80=99s do so in the context of what other = overlapping issues there are. Issue #4: LLC legally & finanicially responsible for all contracts = Issue #5: RFC production and publishing are service contract(s) = I believe Peter has already provided text that covers the RPC and the = RSEA. New issues, of course may be opened (indeed one already is, and = is more specific than the above). Issue #6: Streams have content control = Text should be added to Section 4 that reflects this decision. N.B., = there is an active discussion in the IETF right now about whether = terminology (blacklist/whitelist) should be enforced during the RFC = editorial process. =46rom my perspective, the RFCWG can take this up = once it is formed, but our consensus view that streams have content = control stands until then. Issue #7: A separate body debates strategy = This issue is now subsumed by other issues. I propose to close. Issue #8: This body must include stream representatives. = The text that was agreed to as a starting point incorporates this point. = If there are issues with body representation, a separate issue should = be opened. Issue #10: Is there a figurehead and thought leader of some kind? = Issue #12: Is the expert an advisor (RSA) vs an executive editor (RSE) = The text agreed to as the starting point addresses #10. What we lack is = a decision on the name of the role. That is now issue # 24. I propose = to close issues 10 and 12. Issue #13: Is participation in the strategy body is open to all? = Peter has incorporated consensus text. (It is indicated that there is = an open issue. Peter, please mark open issues with their #). I propose = to close. Issue #15: Who makes final decisions on strategy? = = The starting point includes a structure to address this point. I = propose to close. Eliot --Apple-Mail=_D963922C-3367-4A46-ABDA-A7649258419D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[I thought I had sent this, but apparently not.]

All,

We have previously = marked as consensus a number of issues, and we have agreed on at least a = starting point.  We got there through a circuitous route, requiring = some cleanup.  Thus I propose to close the following issues, with = the proviso of course that new issues can be open on the text that is = present.

Please = comment within two weeks of this posting if you have concerns.  If = anyone has concerns, we=E2=80=99ll leave these issues open for = discussion, but let=E2=80=99s do so in the context of what other = overlapping issues there are.
  

Issue #4: LLC= legally & finanicially responsible for all contracts
Issue #5: RFC= production and publishing are service contract(s)

I believe Peter has = already provided text that covers the RPC and the RSEA.  New = issues, of course may be opened (indeed one already is, and is more = specific than the above).

Issue #6: Str= eams have content control

Text should be added to Section 4 that = reflects this decision.  N.B., there is an active discussion in the = IETF right now about whether terminology (blacklist/whitelist) should be = enforced during the RFC editorial process.  =46rom  my = perspective, the RFCWG can take this up once it is formed, but our = consensus view that streams have content control stands until = then.

Issue = #7: A = separate body debates strategy

This issue is now subsumed by other = issues.  I propose to close.

Issue #8: Thi= s body must include stream representatives.

The text that was agreed to as a = starting point incorporates this point.  If there are issues with = body representation, a separate issue should be opened.

Issue #10: Is= there a figurehead and thought leader of some kind?
Issue #12: Is= the expert an advisor (RSA) vs an executive editor (RSE)

The text agreed to as = the starting point addresses #10. What we lack is a decision on the name = of the role.  That is now issue # 24. I propose to close issues 10 = and 12.

Issue = #13: Is= participation in the strategy body is open to all?

Peter has incorporated = consensus text.  (It is indicated that there is an open issue. =  Peter, please mark open issues with their #).  I propose to = close.

Issue = #15: Wh= o makes final decisions on strategy?

The starting point = includes a structure to address this point.  I propose to = close.

Eliot
= --Apple-Mail=_D963922C-3367-4A46-ABDA-A7649258419D-- --Apple-Mail=_7A0D0A5D-11C2-49F2-88FB-4B864806E779 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCP+oEACgkQh7ZrRtnS ejMcbgf8DmlHGgR2PYEOG/6uz9sdnEGJ9E9RCDqMIoOO7IPjzpKLK9mlztrI1mtL 9oahei05SdEDNIhp6N3MZRHHphqZXAmuCqwRn+9V+JKWO6phPXQc/CHTk5r37XkG MLXiwylXGCZC/BFbQgs2v8gM357ikE+KuDdmjYYV+h2T0ob0DiSl2qo+zavuWeJx hlAdCrxeYVoKWdz+Ge8Q+A5cjZbzR/pY5e08fzsJ2mWEeM7RTie4wgGF/0tWqd1C qWtaC/dGmnbqOXIfQ7BfO86XQv5/YT4pIOt5yZkWwZrMQlqA0KX/O8F6s/nrwENB +kJ6MgeKRXguAiSrcMqtxxuGZfG15A== =fUxP -----END PGP SIGNATURE----- --Apple-Mail=_7A0D0A5D-11C2-49F2-88FB-4B864806E779-- From nobody Mon May 3 13:44: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 BB65F3A102C for ; Mon, 3 May 2021 13:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CJBh5Xem6ycY for ; Mon, 3 May 2021 13:44:16 -0700 (PDT) Received: from mail-oo1-xc29.google.com (mail-oo1-xc29.google.com [IPv6:2607:f8b0:4864:20::c29]) (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 B34EA3A102B for ; Mon, 3 May 2021 13:44:16 -0700 (PDT) Received: by mail-oo1-xc29.google.com with SMTP id h9-20020a4a94090000b02901f9d4f64172so1538493ooi.5 for ; Mon, 03 May 2021 13:44:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=U583lp9Y8lXomLVWqRmzLEf6P6nHh7+Z/RVegt6n3Mw=; b=CtM9k4PWXcree24yURc/JbKmgo4DVyfsVKV9tXRR8EhNlEKKz5/t16cC6FNzo3/Uwz CVT8hHTOXgu7cJ8W1z0zGDN8b+rXtl9uwgYfZ1SPrQq4gqxWSXgG4zlMn7bd+kBm56hH 5LCIYg+ZNDXGWRVcmyip2h1n5hRFcyui/n9APR+UcA6ijsPc5+Pue80nQOHcDV+Gzitu 4sVLcwCYAtolUStieTtHcpu/XaojOyRuy5CpG1JCZWgde0PUWx7T4cv8MczInuiAG7ce oGaYhuan6HUa7M+oiCfE6yLKMratDutJeezvMwjttqlE5UCztGv4aVUuG5sXKEg59iGO VaqQ== 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=U583lp9Y8lXomLVWqRmzLEf6P6nHh7+Z/RVegt6n3Mw=; b=rM0KZT8wlcbFB7rKCu01/gltkQXH7HgvQypQ5wFRCBIcdLs46zlHxkxesn7ef4AARs XrMEt7v/3YrO3Nol2P8uLeUhMFqyriQ+zdusvfaGLRUJVvIq5LCFYtgvptN3ZVHpgyUW Q0E2ryfjIb/tXe9kVy8TuSELt9wfTqiNFtZL7HX08QL/rQyifQ1SZyJqJwLHroFniPiv I4pPn6iQwSg9DVOKlP8HT9ZOvaE0J+A5ATg/sAx9osw60hANXzFxRLSxr5IN8JbvyCA+ Q2v7lx77l3abvzMVOAaP9ELn9Wz6D50ZkNcVnfpfpUzS6AFqmegH1Cm0Z5xGbvypPKoB vtHw== X-Gm-Message-State: AOAM533Uk8M2XmIhEhcIlA0+YRthQOq5cdCpDAxLJCAadt6Pu4P+EaLE K1lwUkUEVPT5cvpRARI2lTLURKH0qZaZ5Y56rh0g8A== X-Google-Smtp-Source: ABdhPJzGO1J2R/s9VhGFcvOVtbyv60OzJTFfyTHktW4HGr4QoU1ps9PW14DLQsDr7AbjBdbni7y8ccmUAyzrB99JDoI= X-Received: by 2002:a4a:8d81:: with SMTP id i1mr16516906ook.55.1620074655285; Mon, 03 May 2021 13:44:15 -0700 (PDT) MIME-Version: 1.0 References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> In-Reply-To: From: Wes Hardaker Date: Mon, 3 May 2021 13:43:38 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000569b7505c1730645" Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 03 May 2021 20:44:21 -0000 --000000000000569b7505c1730645 Content-Type: text/plain; charset="UTF-8" > > > The pessimist in me wonders if "for establishing community consensus" > sounds like this is an easy task that is always achievable. > > To put it another way, is it clear enough that functionally the RSA is an > (A)visor because it lacks true authority over the situation. > > To be clear, you meant the above to have a "?" at the end - correct? > Yes Mike, should have been a ?. Sorry about that. -- Wes Hardaker USC/ISI --000000000000569b7505c1730645 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

The pessimist in me wonders if "for establishing community consensus" sounds like this is an easy task that is always achievable.

To put it another way, is it clear enough that functionally the RSA is an (A)visor because it lacks true authority over the situation.=C2=A0

To be clear, you meant the above to have a "?" at the end = - correct?


Yes Mike, shou= ld have been a ?.=C2=A0 Sorry about that.

--
=
Wes HardakerUSC/ISI
--000000000000569b7505c1730645-- From nobody Mon May 3 17:04:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163AF3A19FB for ; Mon, 3 May 2021 17:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=YCUP/D8J; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=v2N+sUQT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dUW0Jkc_oxLq for ; Mon, 3 May 2021 17:04:36 -0700 (PDT) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 373543A19F1 for ; Mon, 3 May 2021 17:04:36 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 3A8E31A2D for ; Mon, 3 May 2021 20:04:35 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Mon, 03 May 2021 20:04:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=jVzDhcuRxEf0s3Pz3qVURqCCk6eEQeq qGjMKIYK2A/8=; b=YCUP/D8JwXX6+kfmBaoKJ3UcaeBJbhCNXi5Id0vSdHKeryk tbtjdZu1w+HONPWT3XHjXfCDPO/7oDS7KmqqNDQuB66Jbxgg6GK4lqR67gu30CJH Z7EfmLaUUB4MtLnJvRo4d/Vw7HVBJ3akzU+tjSFozU0YRLzPG3uEslhd5ZlI6aLG 5AITXMkzr7keBwjUaXWKhZvguJGYB3bn2omDuZLAnRBdwtERG/B5v8dFffK8l4Zd +2lxtJEgVzPMr0UrEHLblIQtyyyY8o3K0f9f8qVDHr5XdqadVBTAm0m4nMYSK7pF yx8qKOlQKdfaxnNcqjJDMNqOcy8dNmsNO4I52Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=jVzDhc uRxEf0s3Pz3qVURqCCk6eEQeqqGjMKIYK2A/8=; b=v2N+sUQTp5TnTULe6d1mIg 1R1cuunSA9u38yv43f8gKa4JCXQrllfm5FZwV5XnEXme12hox/WLIZMg4Jj8JdY7 2KZHS8slIL4i6bpqn4s+ugoemHLCF8oEwGYmpRkMYrIfQbvibHISZuGkRztTsw8q IYJCcczqMFt8JT6MxetETOvTLtYBC15YGaRkw6EtZAe6I/EPQDE2fyQwIaAKH6fN PsIiUKRCsUznht8Xv3bIjrwoqzXHK9n7ghNQ4tBonlt2fHJn+2nAMR+TpClWByI8 ArxOxR58D/EGD8BYpgEUxBQjbNX3wSvjMPamAQFOYpPGqvQ6734k+UkU6PoykDlQ == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefhedgfedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeejueffveeigfeuvdfhte fhueekjeeukeeftdeifeevvedutdekvdeigeefhfffteenucffohhmrghinhepghhithhh uhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrh homhepmhhtsehlohifvghnthhrohhphidrnhgvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5B66A4E018C; Mon, 3 May 2021 20:04:34 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-403-gbc3c488b23-fm-20210419.005-gbc3c488b Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 04 May 2021 10:04:14 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?House_keeping=3A_propose_to_close_issue?= =?utf-8?q?s_4-8=2C__10=2C_12=2C_13=2C_15?= X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 May 2021 00:04:41 -0000 I think that most of these are good. Just two comments... On Mon, May 3, 2021, at 23:28, Eliot Lear wrote: > Issue #6: Streams have content control > > > Text should be added to Section 4 that reflects this decision. N.B., > there is an active discussion in the IETF right now about whether > terminology (blacklist/whitelist) should be enforced during the RFC > editorial process. From my perspective, the RFCWG can take this up > once it is formed, but our consensus view that streams have content > control stands until then. What we should say is: Streams can have editorial policies of their own as long as they aren't in conflict with those of the series. That's different than what I understand by content control, which is deciding what is published. Which I think we all agree remains, provided that the content that a stream decides to publish is not in conflict with editorial policies of the series as a whole. I will note that the series itself has very loose editorial policies. It doesn't even choose between British and American English. Tightening those would be possible through the process we are designing. The terminology debate is probably not where I would start, but it is one possible option. Whatever the change though, the potential for conflict between stream and series policies is a good example of a valid reason that the RSAB might reject what the RSWG produces. > Issue #15: Who makes final decisions on strategy? > > > The starting point includes a structure to address this point. I > propose to close. I see that we are still debating this at some level, so I would leave this for the moment. Unless I missed us concluding that debate. From nobody Mon May 3 19:05: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 B7F633A1E74 for ; Mon, 3 May 2021 19:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICEUck43pv8m for ; Mon, 3 May 2021 19:05:36 -0700 (PDT) Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C75D3A1E73 for ; Mon, 3 May 2021 19:05:36 -0700 (PDT) Received: by mail-pf1-x433.google.com with SMTP id p4so5901055pfo.3 for ; Mon, 03 May 2021 19:05:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6gqemMpP37I20eHM4Y8GS1hznb0nYu3aiEcT/rcPhkE=; b=DklLvRDQrcLR19uKoV4PkAEd8oJ2giIBePj9Z7+jjvAD8Q4addUbwMawGUfgpDOhBv 9hyBnPkuygd05CAE8MlXe1HzSl0ll3eOe+a5pICxowtgW8iAcRRVYpiEZL3y+I0lE/u7 ye4syD3krjdGdhMPSSV1+BkwJL54n6u71ajKvZfLtueb+pYgEVA1XKWpzXtsxbBLEAA9 zo1MDW/Tbmb4iLiIkAmiglUIjRNh4Uz+d7QfSbGGmQm9yN08pyB+u10vDLOA7YS0wGgi Km1VqgdLIjpZykOeOcInedXLyDX3KrLVrUtQFmY2LjxkfxZFCukB34Ra9ST6hzanYEt/ 4MtQ== 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=6gqemMpP37I20eHM4Y8GS1hznb0nYu3aiEcT/rcPhkE=; b=iZMrmzweI9h+uPyB/dBa7Kh+uiaSaLI0BEC26C+WU6X6xzgY3mrAwHRlcGDiD85WmE JrT1drbM9mqhQhll5YBUnP0HV4a6eA/HPfZFyOUZOQ7Hs1Hlu814dBpeua3Re9ZezU+Z m51VfCg4X9HQsiMgYVa0IWkJIeYJ9i0f7M/d9koJBrDuI8wWad4QlB12XCkPAOMYw/uB KmYacWzEXA0K6ZN6dMOzQ7mlzQAFvaCYAAhQ10KtRCEbb7BppzEHCDzSuSUoTatbAWgS hiW8472O9YhWP+GslAOSsqzgzFSHwluvLRsfHSNZAixZvRCtzBiw0+PqOKhBvvj85nxh J27w== X-Gm-Message-State: AOAM532N0AI5YC1O3vhnkE8oUPXu3bm58pNo3SMwo1b7914r1ZF4IcU1 qnfqqHjR9Jk8FUi0ERWuSxY= X-Google-Smtp-Source: ABdhPJzvy8Bjvdl1NkWhFGIEcRcpWeLj/Ao1q4tu6c7RV1vJlfMjlddp0S+GeRHo8aMpR6RLPTc0qA== X-Received: by 2002:a17:90a:a081:: with SMTP id r1mr24555458pjp.101.1620093935093; Mon, 03 May 2021 19:05:35 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id h76sm9560470pfe.161.2021.05.03.19.05.31 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 19:05:34 -0700 (PDT) To: Michael StJohns , Eliot Lear Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> From: Brian E Carpenter Message-ID: <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> Date: Tue, 4 May 2021 14:05:29 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 May 2021 02:05:39 -0000 Hi Mike, On 03-May-21 14:57, Michael StJohns wrote: > Comment just on the text. >=20 > On 5/1/2021 6:13 PM, Brian E Carpenter wrote: >> On 30-Apr-21 02:29, Eliot Lear wrote: >>> >>> >>> Hmm=E2=80=A6. Sounds like a volunteer. Please feel free to suggest m= ore text! >> Ow, ow, that hurts. Well, here's a first cut (actually a second cut, p= artly based on https://datatracker.ietf.org/doc/html/draft-carpenter-rfce= d-model-00#section-8): >> >> Recruitment of the RFC Series Advisor >> >> The LLC is expected to lead the process of searching for and >> recruiting an RSA whenever necessary. The LLC will constitute a >> search committee representing the LLC and the various RFC streams.= >> Each stream manager in the RSAB will either be a member of the >> search committee themself or nominate their stream's representativ= e. >> The search committee will operate confidentially but must publish >> a description of its procedures and a timetable. >> >> [Some sort of equal opportunity/diversity statement, or do we take= >> that for granted?] >=20 > It's unclear that the stream managers or their designees will have any = > specific expertise in selecting an editor type, nor for that matter tim= e=20 > or interest over and above their commitments to the IAB/IESG/IRTF, and = > the already stressed out ISE ( :-) ) .=C2=A0 I believe the RSAB needs s= ome=20 > form of input into the criteria, and should get several opportunities t= o=20 > meet with the candidates and make their comments known to the LLC=20 > board.=C2=A0 I'm thinking that constraining the LLC in the above manner=20 will=20 > lead to a non-optimal result. I didn't intend it to be constraining. Indeed, RSAB members might not be experienced in hiring senior staff, but the streams certainly have a word to say. So maybe: The LLC will constitute a search committee including representation of the LLC and the various RFC streams. >> Role of the RFC Series Advisor >> >> This person will be a senior professional with deep knowledge of >> technical publishing. >> >> The RSA will operate by providing expert advice to the RSWG, and i= f >> requested to the RPC, on any relevant matters. For example, the R= SA >> might be consulted about proposed changes to the style guide, RFC >> formatting in general, web presence, copyright matters, or archivi= ng >> policy. >=20 > Keep in mind that the neither the=C2=A0 RSAB nor the RSWG are tasking=20 > entities under the new formation.=C2=A0 Whatever you have in mind needs=20 to=20 > fit within the constraints of what's possible with a contract.=C2=A0=C2= =A0=C2=A0 I=20 > think the above is general enough for the RSWG, but may require specifi= c=20 > covering contract language for the RPC as it's a contract with its own = > constraints. Sure, but do we need to say that here? It isn't a formal job description.= > The text above is not all inclusive of the role of the RSA/E. E.g. ther= e=20 > are tasking and responsibilities that I expect the RSA/E will have that=20 > have nothing to do with the RSWG, especially on a day to day tactical=20 > basis.=C2=A0 E.g. "The role of the RSA/E includes providing expert..." = and=20 > "...if requested by the LLC within the contract terms, shall provide=20 > advice to the RPC..." >=20 >> The RSA is expected to attend and actively participate in all RSWG= >> meetings and on-line discussions. The RSA is expected to be >> proactive by keeping the RSWG well-informed and by raising new iss= ues >> as appropriate. >=20 > Yup.=C2=A0 General enough.=C2=A0=C2=A0 But s/RSWG/community/.=C2=A0=C2=A0=20 The RSWG is not a=20 > filter for the RSA/E or vice versa. I'd prefer s/RSWG/RSWG and the community/ =20 >> >> Further, the RSA is expected to ensure that RSWG consensus is well= >> documented and communicated to the community, the LLC, and the RPC= =2E >> This may include document authorship. >=20 > Um... what?=C2=A0 This puts the RSA as a process facilitator for the RS= WG and=20 > gives them responsibilities to keep the record of the RSWG???=C2=A0 Tha= t's=20 > new AFAICT.=C2=A0 The document authorship does not necessarily imply th= e rest=20 > of this. True. But given the lamentable and unpolished "minutes" that most IETF WG= s produce, which definitely don't satisfy RFC2418, I intended what I wrote.= Obviously, that's open for discussion. >> The RSA is expected to show leadership for improvements to the >> RFC Series, for developing vision and policy documents, and for >> establishing community consensus for them. >=20 > This describes the RSA/E responsibility - it needs to be balanced with = > authority to make things work.=C2=A0 Otherwise we might as well hire a = ghost=20 > writer. To be clear, "show leadership" doesn't mean "manage", since we are saying= that authority lies with the RSWG and RSAB. But this is the nub of the RS= A vs RSE discussion, so probably needs one of Eliot's issue numbers of its = own. >> The RSA will operate under a part-time professional services contr= act >> with the LLC, with performance review by the LLC in consultation w= ith >> the RSAB. >=20 > The form of the engagement is up to the LLC and the RSA/E.=C2=A0 It mig= ht be=20 > as you describe above, or it might be employment.=C2=A0=C2=A0 This was = already=20 > settled elsewhere I believe. I've lost track of whether that's a consensus position or not. My persona= l opinion is that there's 99% probability it will be a contractor rather than an at-will employee, but we can certainly leave this flexible. Brian C From nobody Mon May 3 19:10: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 B82C43A1E9B for ; Mon, 3 May 2021 19:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 kPigd0aVdd69 for ; Mon, 3 May 2021 19:10:31 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 7BE443A1E93 for ; Mon, 3 May 2021 19:10:31 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id v191so5861139pfc.8 for ; Mon, 03 May 2021 19:10:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=/aiKUX6UUFMeP0oexp9N5m+Wr/fRHKBAgfRYpi6kAFU=; b=VBmjxogKCz84qBzSmCZYG2R4Z9YomAJwRDtEM6pqxmeEwUQVfrWSSQyyF3JuXTfdp/ hnGUoMu4w2rbHsbLz2vh3EYZToEn6sOvzR71DeWY/Sxtntup5nMlJttjkJbRujx3uGjf sRxTEPGMcyH54u8Oq6pUxsgiGhH/5Rb57P7ITepcVM0ansv0ONk9C0KdpzEwq0WubCrl +Rb9h/bCGw+WZVW923cfXU9K+w8ZO3NPMC5wsRzCTHNF7qRFRtPJFB9QWb/rOVyC6fUo 9cs7ALdT9REn4xl4o/BNAMJXcqsRMi6Z7hSNM5QsYLTbCF/tbh6vewNu282DrjlKeWEZ 8fkA== 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=/aiKUX6UUFMeP0oexp9N5m+Wr/fRHKBAgfRYpi6kAFU=; b=kivo28No+ZSgCoyHsVtCuysOqblkHm9QJHAYGngLRabi7m7sHN/82Jt+pT8Q8dCcZf Bv2LIOckb3+LFdamrubjTXXP7L2lzJv49KXh9Ivw5xBVLiEbgMsnYnK5e5M5fUebyoRe jaF7nfsJFUKe179DdxPgOIwppaQtigkw7CqRifoJSgSqMalR06QJNa0kbcB0QtT7hb5x SVwsKGv8/YbWqV1bOu6TEH/Ab+xuYR4hovAhzhaz051vwOHifDY2WEEC8kvgSnkppA22 tsfiU2nxSVBu1acJkAHm5f/VLH6B5roCK7OBFLDO0OfE/xlTDpp7IJm2rMgkTIcHCeMC vngg== X-Gm-Message-State: AOAM5323Dnww3eIIE+ZzBDIIuVd5PIQopa96rEEOBiovRywDpVHSNAFK XnZW/gfgMIUr1YiUzoIVdKu7M0IxTy5DiA== X-Google-Smtp-Source: ABdhPJzXSx2IQ0Tg4UnzUu+4leTYozL7aTuhiHtV69ZVZyDbOquFpI1mYS9n7WeKtQqeLsSHG3rWGA== X-Received: by 2002:a63:ea06:: with SMTP id c6mr21318029pgi.401.1620094230375; Mon, 03 May 2021 19:10:30 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 66sm6592509pfg.181.2021.05.03.19.10.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 19:10:29 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <36d4343a-c04f-4ed3-b8db-2f6e0cd5eb2d@www.fastmail.com> From: Brian E Carpenter Message-ID: <74546410-e2d3-8212-a611-783e9032e819@gmail.com> Date: Tue, 4 May 2021 14:10:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <36d4343a-c04f-4ed3-b8db-2f6e0cd5eb2d@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 May 2021 02:10:33 -0000 On 03-May-21 14:29, Martin Thomson wrote: > On Mon, May 3, 2021, at 01:00, Wes Hardaker wrote: >> The pessimist in me wonders if "for establishing community consensus" >> sounds like this is an easy task that is always achievable. >> >> To put it another way, is it clear enough that functionally the RSA is >> an (A)visor because it lacks true authority over the situation. IE, >> community consensus is a mandatory part of the process. > > I share that concern. Perhaps the right way to phrase this is that the RSA is expected to be an active contributor to the RSWG. This includes proposing improvements to the vision for the RFC series or the policies and procedures that govern its operation. The RSA will engage in discussion with the RSWG on proposals that they and others make. Well, I agree, and I thought that was what my draft text said, plus a bit more to replace the term "thought leader" that people objected to a few months ago. But basically all this is implied by the term "advisor" IMHO. Brian C > I think that might avoid establishing unrealistic expectations. > From nobody Mon May 3 19:15:24 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6383A1EC7 for ; Mon, 3 May 2021 19:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FKCWp8Sy31qF for ; Mon, 3 May 2021 19:15:18 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 200343A1EC5 for ; Mon, 3 May 2021 19:15:17 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id y32so5326563pga.11 for ; Mon, 03 May 2021 19:15:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=gIpHAq3uJWafUOqQZu2N24A/MfDxrl45oxOKJ4Af1kU=; b=A0EZvs/4v5RqJ+/4obI1qWo1xUKJ4CNRHLr+8x+6GKz8fX87hcnyyU+bXnGGmFRjrD GOc2+O8giRFL7pzP19K8LReDM9J2RYtLUgAV0+erNN8R6XXwOK6X6Y+DuyCStNRNisgd sKebCGteWviQ00c71gVTUBnIYCZlXF8ZPULUlvpde/WLK2qtUBxopYL0dh3QKtN1a1eD mi2dC9KW9aWmO17TyVROHclPGEqfq8FLWqJPZibhExkaQmC6/3W8x2RPZQvkoC63vkFQ ncZgOYhNUzm2gS0a20usNH3OyOUzuBRjMk22EOHpED5Nt8ME7QZeRBOt3B8/LZSxIqXa KTxQ== 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=gIpHAq3uJWafUOqQZu2N24A/MfDxrl45oxOKJ4Af1kU=; b=OHLzOwmkh+q9ZIlDSLpSTHTHTol9mZOQYZBeAVBwXtMI3gIVx+FeRot+VRzEAwdPbD isZdCl1tv+pjN+hqEQqt7mP+tdvE+5vFZKE0Vn+lIeYnVnka5BFWc1Ufu4pKWPHV3NJ8 Mv2Scu5unAAG1XvOhDVoUcClcqcunLVhnkskAMW0efgzp51aSosTzyh2JgDdGOLSVraQ rvq8UMgtkFktw/L/Ch5HZ4ng+cM7R3rMgFC2U2mWVtZQexFhBJ2FpohDRBoKKelR52B9 /OSwogNgjw36uPEVyt2fXQGLXVWUCeXySxm4t72ABFn9lxeHyFO1B+y8YXhGDJ1kYnIf vFRg== X-Gm-Message-State: AOAM533s91iXLcjRKyuv2+lIWwG9gV4cSI08YKuXKUn1IXjQPgPMSe6F h58IhCMXi4t+L9UHg60VkwE= X-Google-Smtp-Source: ABdhPJwU9O2YOUz4NAGWNSRwEUpKzEzQfNg5q0PCfnhraisyFNgIZsva5oBUCCOJwpyirulU3HP00w== X-Received: by 2002:a05:6a00:1a02:b029:27f:f7ce:49d8 with SMTP id g2-20020a056a001a02b029027ff7ce49d8mr21498710pfv.24.1620094517032; Mon, 03 May 2021 19:15:17 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id j7sm1160877pjw.4.2021.05.03.19.15.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 19:15:16 -0700 (PDT) To: Michael StJohns , Mirja Kuehlewind Cc: rfced-future@iab.org, Russ Housley References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> From: Brian E Carpenter Message-ID: <4562bcfc-352d-c0e5-684c-d060861a6b95@gmail.com> Date: Tue, 4 May 2021 14:15:12 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 May 2021 02:15:23 -0000 Mike, On 03-May-21 15:02, Michael StJohns wrote: > Hi Mirja - >=20 > See my note to Brian - but lack of applicable expertise, and lack of=20 > time spring to mind.=C2=A0 I'd rather have a few people with specific=20 > knowledge and an ability to commit to time to the search, than many wit= h=20 > no one really responsible for actually performing the work, or lacking = > the aforementioned specific knowledge of what makes a good editor/publi= sher. >=20 > I think the better alternative is make sure the streams (not the stream=20 > manager per se) have substantial input into the job description (detail= s=20 > past what we're working on here), and an opportunity to interview the=20 > various candidates and make their concerns and thoughts known to the=20 > search team.=C2=A0 I think the search team then gets to do its job and = > present the candidates in some sort of ranked order to the LLC for=20 > contract negotiations. Anyone who's going to know who the candidates are will be inside the search team's bubble of confidentiality. I don't see how we can=20 reasonably exclude the stream managers or their delegates from that, whoever conducts the search itself. Brian C >=20 > Mike >=20 >=20 >=20 > On 4/28/2021 4:12 AM, Mirja Kuehlewind wrote: >> Hi Mike, >> >> Why do you think the stream manager should not be part of the search c= ommittee? >> >> Mirja >> >> >> >>> On 27. Apr 2021, at 21:58, Michael StJohns w= rote: >>> >>> On 4/27/2021 1:55 PM, Russ Housley wrote: >>>> At the same time, the person that is selected needs to work well wit= h the stream managers, so they need to be included directly or indirectly= =2E >>>> >>>> Russ >>> >>> Yes! I'd probably leave them off of the search committee, but I woul= d probably arrange for interviews between the RSAB and the various candid= ates with the search committee present. >>> >>> Mike >>> >>> >>>>> On Apr 26, 2021, at 10:09 PM, Michael StJohns wrote: >>>>> >>>>> Section 6.1 - Composition of the search team. Explicit include or = exclude of any of the RSAB, the RSWG participants or chairs? Other Nomcom=20 selected folk? The process needs to be fair, and the selection criteria=20 should be such that bias on the selection committee is minimized. >>>>> >>>>> >>>>> --=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 From nobody Mon May 3 19:20: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 B52723A1EF7 for ; Mon, 3 May 2021 19:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 We-HDurIK7Km for ; Mon, 3 May 2021 19:19:59 -0700 (PDT) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A128C3A1EF6 for ; Mon, 3 May 2021 19:19:59 -0700 (PDT) Received: by mail-pg1-x533.google.com with SMTP id m12so5338461pgr.9 for ; Mon, 03 May 2021 19:19:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=E1JWSwSPNAaqoY01FXqhxcQuhaDqMmkH22hWgJ8cmBw=; b=EA8I+tVTby2tapf0kNNYc0lz8CMRUk+6jBWCWtz6ZmKVWZFtAb0oEPf2XKxXStavfv yEvwMCMYV/lQADFnbsjDoYXKyozvFIvxpuAJalRlio9EJrnpK1W/QGz8r4pR/fEGEelg TEptGE/I8mlvWf7wwvl1ZnTRWAE8YPLyf6suS3VHUL3PlbH4oHcS1yRo896k1QH5+QDn oOL4u6VlUuDOSIIXAo8EEZ222ofp3UMDLVEG5FN6Pqrx59SJzVJ7YDw18/WDUTkCreBa IWxE52dv9JZbcPl/4iNxPvzYxRjqECQXkjnEKTV15F0bedPDpTjtwerZo+sDvJJGVcrs Qhag== 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=E1JWSwSPNAaqoY01FXqhxcQuhaDqMmkH22hWgJ8cmBw=; b=iuLV7JftHkpX1Q1gv1j8OJVRJQsqKgB4l8tEMyToVEirWmHeJwHIQAqs6CgmHHlhg8 uAx8cep9V2Jz2vhdCcMAey2d9ZAbpWTnIb4e+S91KhBTzu272ArUGJOsHuiXtgx+P53a 1tH1QAZuQk/Dvx3Czz4h+X6cXwkl0UzhhyQHaoR3QSIXX8c4PwljcfOWBLszQBjw8iIw 23xUFmE5JGmBcV3j7ZrLtCPkM6qWMUmaqPvi1elI6UX6MFvO8OHZTVWMTQXAxR1Z8EJj qS5Wxc1L0Z2EEBc2rAni6awhwjaYlIM/uuQHz3KnIezbrLoCzwXGavsDr2eOUSytcWsP 1t3Q== X-Gm-Message-State: AOAM532DnHf0gSEdFy10nn5h62Xk1FYHAOUFv3P0oDjx/bZ/LY8CXp4T Ysv8d+tZ/I/GpNA9Iphx007Kbgl/5xivrg== X-Google-Smtp-Source: ABdhPJzgOQyDfS1OK+KT9grguMtzl3qtLROryW31/iIFjd11AKPaX4ojhbae5fnR4y+QJQec34uwiQ== X-Received: by 2002:a63:7e13:: with SMTP id z19mr8751127pgc.184.1620094798456; Mon, 03 May 2021 19:19:58 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w2sm7580197pfq.52.2021.05.03.19.19.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 03 May 2021 19:19:57 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> From: Brian E Carpenter Message-ID: <8c625bdc-eb6b-6c22-8de6-d4ef01179c7d@gmail.com> Date: Tue, 4 May 2021 14:19:54 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 May 2021 02:20:01 -0000 On 03-May-21 16:43, Martin Thomson wrote: > On Mon, May 3, 2021, at 13:17, Michael StJohns wrote: >> You're mistakenly conflating community consensus with RSWG consensus, >> and I submit those are nowhere close to the same thing. I'm conflating them because we don't really have a better proxy for the community than the people who show up on an open mailing list. Of course we can also do things like post anonymous surveys, but the results can inform the RSWG. > > I don't think that it's a mistake, but a feature. Though I acknowledge the usual conditions (who can be bothered to turn up and comment) are challenging, deliberately deciding that the two reduce to the same in every way I can imagine. Do you have arguments in favour of the alternative paths that indicate valuable features? > > I realize that you are concerned about things getting stuck in committee. Providing the RSAB the tools to ignore that community is dramatically different than acknowledging that the rough consensus thing is imperfect and working within those constraints. I don't agree that by insisting that a Working Group reach consensus, we are creating a system that is overly prone to this obstruction attack. Yes, obstructionist behaviour is hard to deal with, but we know how if there is the will to do it. Yes. But remember that this won't be an IETF WG, so we'll need to import more than just RFC2418 to have all the weapons we need. Brian From nobody Tue May 4 08:37: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 050EF3A0C77 for ; Tue, 4 May 2021 08:36:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 tcuZCkYhCuzM for ; Tue, 4 May 2021 08:36:57 -0700 (PDT) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 269A23A0C38 for ; Tue, 4 May 2021 08:36:56 -0700 (PDT) Received: by mail-qt1-x829.google.com with SMTP id a18so6593794qtj.10 for ; Tue, 04 May 2021 08:36:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=9RoHXKyuQ915KsD8zQGS20jg51Wcf9tdkzWBhjaRbxo=; b=eCIJXIXmiC+AYNFb+LQS6spGNzv53cLaooDuYylSb4cPV7odfUt8TKsSCHio4N+wiL pCjnIy26KD6lnuVXITJlYu21mCgMqFg9JKQR/6stfYgPCFTitNsh3+1RgUDbm3VADj99 47sAfkraTsYV645BdZrJfkOQ1No08dk3MKwzBpCClyNvX9Aou+P9QW6JDAuQeVeH5a5U SOfkO785J8WUXHq0DIj98I+ivFDpO9yfDUKJ5D7z7XeuESWLOHd2jZeWyFJ4mlbBAddQ KxUOb/VXapKHQk0rrWXNlZ6Ow+qyZgU8japaCTelBg9K0EFSDFWaXLKIMy9McgiclJbI 1dnA== 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=9RoHXKyuQ915KsD8zQGS20jg51Wcf9tdkzWBhjaRbxo=; b=rfKheB6sEPQRxqftFC9l0BV/Posmj8kTj58MM9NYJmpTK9WFYdyGe6/5ws1QZX6srW bImlCKE//Hb9OLFcKqwc2JoJYlVwlERDG4ighR6sEt2yaISv9d914zXS83Ad+utO7Mb/ heGsjHbgzfGvcDt3xN4GjtlslKoZbmpEItKmywuy+iIArB49Q0dx5pr0zKhPTz7cPqPK jxnDoZa5zowkoi2mAIcicXLNU9YHLvmeyzp2SDS31dTQxKoUxjZOmKXRYL7GiZY8mL2e PBMJ+tCdD4wHCz89hG7JAbpcO3hk17JQWkG59o6gFQLwKEDP26emdegHliafVci9Qyh1 OlwQ== X-Gm-Message-State: AOAM530rP3oU110hfiptGZwPE7BYuYs3ii60JM+85jr5dTM+9gFTkso9 ithNQZy2BGdC2wqhnOACPHWKdw== X-Google-Smtp-Source: ABdhPJzCI/D31pFGXMw3ddXjTFP6/4BBgFrV2dLND2IcVPbm9j3y3NN2L98Hzlj/BuqRAGnjbIOveg== X-Received: by 2002:a05:622a:104f:: with SMTP id f15mr4743768qte.31.1620142614625; Tue, 04 May 2021 08:36:54 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id n16sm2682241qtl.48.2021.05.04.08.36.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 08:36:53 -0700 (PDT) To: Brian E Carpenter , Eliot Lear Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> From: Michael StJohns Message-ID: <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> Date: Tue, 4 May 2021 11:36:53 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> Content-Type: multipart/alternative; boundary="------------E2D9C4828CA72D63DC6C2291" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 May 2021 15:37:01 -0000 This is a multi-part message in MIME format. --------------E2D9C4828CA72D63DC6C2291 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/3/2021 10:05 PM, Brian E Carpenter wrote: >>> Further, the RSA is expected to ensure that RSWG consensus is well >>> documented and communicated to the community, the LLC, and the RPC. >>> This may include document authorship. >> Um... what?  This puts the RSA as a process facilitator for the RSWG and >> gives them responsibilities to keep the record of the RSWG???  That's >> new AFAICT.  The document authorship does not necessarily imply the rest >> of this. > True. But given the lamentable and unpolished "minutes" that most IETF WGs > produce, which definitely don't satisfy RFC2418, I intended what I wrote. > Obviously, that's open for discussion. > Um...  in what universe does "note taker and minute keeper" equate to "senior professional"?   There's also the fact that the note taker in general is less able to participate in the discussion. The fact that you're already projecting that the WG chairs will not be able to run an adequate process does not to me suggest that we try and fix that brokenness by laying trivial jobs on the RSE/A. Are we trying to sabotage the hiring process already? Later, Mike --------------E2D9C4828CA72D63DC6C2291 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/3/2021 10:05 PM, Brian E Carpenter wrote:
    Further, the RSA is expected to ensure that RSWG consensus is well
    documented and communicated to the community, the LLC, and the RPC.
    This may include document authorship.

Um... what?  This puts the RSA as a process facilitator for the RSWG and 
gives them responsibilities to keep the record of the RSWG???  That's 
new AFAICT.  The document authorship does not necessarily imply the rest 
of this.

True. But given the lamentable and unpolished "minutes" that most IETF WGs
produce, which definitely don't satisfy RFC2418, I intended what I wrote.
Obviously, that's open for discussion.

Um...  in what universe does "note taker and minute keeper" equate to "senior professional"?   There's also the fact that the note taker in general is less able to participate in the discussion.

The fact that you're already projecting that the WG chairs will not be able to run an adequate process does not to me suggest that we try and fix that brokenness by laying trivial jobs on the RSE/A.

Are we trying to sabotage the hiring process already?

Later, Mike

--------------E2D9C4828CA72D63DC6C2291-- From nobody Tue May 4 13:01: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 CCD833A10CB for ; Tue, 4 May 2021 13:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37wfSgJ9eAmm for ; Tue, 4 May 2021 13:00:57 -0700 (PDT) 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 602663A10C7 for ; Tue, 4 May 2021 13:00:57 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id p4so141348pfo.3 for ; Tue, 04 May 2021 13:00:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wlPc1OvO7EAEIJCA7Q61WEwh4GCNU4wf0ccQ7Emu7lw=; b=Px+/zOw2hLb9wFCgm5ihHE8BGC3sY1VPziH2pLLIHUolcK0TrFRoXvVKCfqZVyVbeb Br+jZ316TlkPX+TdWCBiOBgRRg5WL4OQisgs5wuFo0CbvS8XkwZ49XWzMXB4bAKdvQNu HBC3pZRkLe0x7a7yijWQ4Bh3kIDmC3OTaUbgrFReBNhLFeU/uqoAEXh1g1MHUvEHMFac PTlENQn7K/WJxIuqq5HhVlREW20lRZS5macnMLYG/BJh60c6h5eXKhE4Z0KlbLOcnFDo JvDWWR5jpdEmIMyFz6jbEv5BxE2dOMW4mjmsc0g5m2+D5UYn85l4+0Hl1Ru5I7wihDCo kCsQ== 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=wlPc1OvO7EAEIJCA7Q61WEwh4GCNU4wf0ccQ7Emu7lw=; b=HVM3EfSlfSL4wH2UvbBvWVZ3gASB89VA2CUigTy/xEviFwT6fBrAVnPLn2ZZpqcVNw fp+OEr4ubylrGU9JWqN7awx8KEhJwHDTJp9/Co8o6SvVjJRm+aWH8oVvvuP6X5kJgZJl cQgMPYUpjvpzX0QVg06N88cGkWkb7raaHoWjnAkS2G6zXSaaG3DOPrXs1tSG7T+yL4pd cDD8WY4lNUcyEZ54xCbfdrgXAhSEqx2PVppv6OogtqBD8fS68asQ6DIwGTldtOKv8o+S yC1GwwBNv4f6LtGybwGakUYsaMMPzogvY+AIu7RqLS1oZfXS+JW9HtvU5vIZqvPsqac2 oc0Q== X-Gm-Message-State: AOAM530xU/zAb2fWJdaGUt/M1k7Eaavdz+OnhOudtkDNIUXA5Hk0x8v4 YF69evkqbY5QFPONLV4yF3U= X-Google-Smtp-Source: ABdhPJzoF/ISBFAAxV8bpHH6S6zvE3fpjqSfnaVSNFqKHKQ31H7lsShaVdpWoKOJA6GXRUhtuKLpAg== X-Received: by 2002:a17:90a:7142:: with SMTP id g2mr29740681pjs.77.1620158456232; Tue, 04 May 2021 13:00:56 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:db7:d041:a2d:ce65? ([2406:e003:100d:901:db7:d041:a2d:ce65]) by smtp.gmail.com with ESMTPSA id u6sm12900600pfi.44.2021.05.04.13.00.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 13:00:55 -0700 (PDT) To: Michael StJohns , Eliot Lear Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> From: Brian E Carpenter Message-ID: Date: Wed, 5 May 2021 08:00:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 May 2021 20:01:00 -0000 On 05-May-21 03:36, Michael StJohns wrote: > On 5/3/2021 10:05 PM, Brian E Carpenter wrote: >>>> Further, the RSA is expected to ensure that RSWG consensus is we= ll >>>> documented and communicated to the community, the LLC, and the R= PC. >>>> This may include document authorship. >>> Um... what?=C2=A0 This puts the RSA as a process facilitator for the = RSWG and=20 >>> gives them responsibilities to keep the record of the RSWG???=C2=A0 T= hat's=20 >>> new AFAICT.=C2=A0 The document authorship does not necessarily imply = the rest=20 >>> of this. >> True. But given the lamentable and unpolished "minutes" that most IETF=20 WGs >> produce, which definitely don't satisfy RFC2418, I intended what I wro= te. >> Obviously, that's open for discussion. >> > Um...=C2=A0 in what universe does "note taker and minute keeper" equate=20 to "senior professional"?=C2=A0=C2=A0 There's also the fact that the note=20 taker in general is less able to participate in the discussion. Yes. I didn't mean to specify that the RSA/E actually takes the notes. Bu= t somebody needs to make sure it gets done properly, and our experience wit= h community volunteer WG chairs is that many of them don't get it done prop= erly. See any recent set of IETF Proceedings for examples. Brian =20 > The fact that you're already projecting that the WG chairs will not be = able to run an adequate process does not to me suggest that we try and fi= x that brokenness by laying trivial jobs on the RSE/A. >=20 > Are we trying to sabotage the hiring process already? >=20 > Later, Mike >=20 From nobody Tue May 4 13:10: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 21A083A1154 for ; Tue, 4 May 2021 13:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.898 X-Spam-Level: X-Spam-Status: No, score=-11.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hG3IccUSOyTj for ; Tue, 4 May 2021 13:10:20 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F90D3A114B for ; Tue, 4 May 2021 13:10:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7309; q=dns/txt; s=iport; t=1620159020; x=1621368620; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=sdpwoyHU1N64Z9NYD1cbWJ8pZJ29EvtWV/v19R8G2tI=; b=X1wfO9xfbwhrrjf2Xfj/mHv/NcduhEB1W5hQ2sPFzjYDov7mZ+bh+5QO OBzGxdJSMmeMxZfJB+uUHSaQk2D4fGHIWQCy1jUbKk8yAaqZpTV6cDZjn 7HH/9FTeNWWU6WCJd+zr5V8+4zM/+HBP3zhPFXGQWEiALlhIPoxK0CdHg c=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0ACAADQqJFglxbLJq1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBggQEAQEBAQsBgSKCVQEnEjGERIkEiHSHf4I1iiOGKYF8BAcBA?= =?us-ascii?q?QEKAwEBNAQBAYRQAoF8JjUIDgIEAQEBAwIDAQEBAQEFAQEBAgEGBBQBAQEBA?= =?us-ascii?q?QEBAWiFXYZEAQEEASNRBQULFwwqAgIhHBoGExSCXQGCVQMOIah+eoEygQGEY?= =?us-ascii?q?YJJDYIXEIE6AYFShTIBhlpDgguBFScchTuFOzaCKwSBSxuBeoESbZ8QnD5bg?= =?us-ascii?q?xoEg0GBSZJehUIFIqUjpE2PWWWEBgIEBgUCFoFWATWBWzMaCBsVZQGCPj4SG?= =?us-ascii?q?Q6OOI42PwMvAjYCBgEJAQEDCY0PAQE?= IronPort-HdrOrdr: A9a23:Le9sL6NvwxEXJ8BcTkOjsMiAIKoaSvp033AA3SlKOH9oW+afkN 2jm+le6A/shF8qNE0ItNicNMC7IE/02oVy5eAqV4uKfA6jg2ewKZEn0I2K+V3dMgnz7PRU26 slU6UWMrDNJHx7icq/3wWiCdYnx7C8n5yAvuvVw3dzQQwCUcgJhDtRMQqVHlZ7QwNLH/MCZf +hz/BarDmtc2l/VKqGL0QCNtKzxeHjpdbDaR4CCwVP0njrsRqYrJjnDhOfwhASFxRIzLtKyx miryXJooO+rvq81hjQk1X20q0Tst7gxtxfbfb87fQoFg== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,272,1613433600"; d="asc'?scan'208,217";a="35720581" 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; 04 May 2021 20:10:15 +0000 Received: from smtpclient.apple ([10.61.144.35]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 144KABL9025276 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 May 2021 20:10:12 GMT From: Eliot Lear Message-Id: <6E7E6396-92F8-43ED-A391-DFFEA256F577@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_C82770A3-A6F9-49AC-B8D9-E7F35447EF65"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 4 May 2021 22:10:11 +0200 In-Reply-To: Cc: Michael StJohns , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind To: Brian E Carpenter References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.35, [10.61.144.35] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Who minutes meetings? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 20:10:25 -0000 --Apple-Mail=_C82770A3-A6F9-49AC-B8D9-E7F35447EF65 Content-Type: multipart/alternative; boundary="Apple-Mail=_60C31BF5-46DC-45DD-A186-4820E6E25F29" --Apple-Mail=_60C31BF5-46DC-45DD-A186-4820E6E25F29 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Brian, > On 4 May 2021, at 22:00, Brian E Carpenter = wrote: >=20 > Yes. I didn't mean to specify that the RSA/E actually takes the notes. = But > somebody needs to make sure it gets done properly, and our experience = with > community volunteer WG chairs is that many of them don't get it done = properly. > See any recent set of IETF Proceedings for examples. Let=E2=80=99s decompose this a bit into two questions: Is it important that someone accurately capture decisions and action = items in the form of minutes for the (a) RSWG and (b) the RSAB? Who does the job? I think there will likely be agreement on (1). On (2), we have a lot of = latitude at the stage in the game. The ED could see to this, the LLC = could see to this, the RS[EA] could see to this, or we could rely on a = volunteer in the community. Maybe there are other possibilities. Eliot --Apple-Mail=_60C31BF5-46DC-45DD-A186-4820E6E25F29 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Brian,

On 4 May 2021, at 22:00, Brian = E Carpenter <brian.e.carpenter@gmail.com> wrote:

Yes. I didn't = mean to specify that the RSA/E actually takes the notes. But
somebody needs to make sure it = gets done properly, and our experience with
community volunteer WG chairs is = that many of them don't get it done properly.
See any recent set of IETF = Proceedings for examples.


Let=E2=80=99= s decompose this a bit into two questions:

  1. Is it important that someone accurately capture decisions and = action items in the form of minutes for the (a) RSWG and (b) the = RSAB?
  2. Who does the job?

I think there will likely be = agreement on (1).  On (2), we have a lot of latitude at the stage = in the game.  The ED could see to this, the LLC could see to this, = the RS[EA] could see to this, or we could rely on a volunteer in the = community.  Maybe there are other possibilities.

Eliot
= --Apple-Mail=_60C31BF5-46DC-45DD-A186-4820E6E25F29-- --Apple-Mail=_C82770A3-A6F9-49AC-B8D9-E7F35447EF65 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCRqiMACgkQh7ZrRtnS ejOA7Af/Tdv1p2SB0nZZCkDs1wFzm5QxKLRQkyadtFhhtk5Ul2dfMCrnoAqTy4gE symivTM94H0dfsi/xXLfKF0QcbwMB1WbG1s7JtlOcdUAJJKz3+1ZsjPFreEyL2sQ O/ig8hc5RpZtsmRFathTUd6g7qQ8ETo4/0aylPKY9Z0hupR+KOZuQYsgrxeM15ia tnzA+TC5HlOOxQoaYSnoOZVrDosgB3HuF+7X3KacBIm+eN6/sWg6qmwpiEV1E2aq Jm6adz5p7BQwBbtfXHBhbYYGOMLxARir4pNdueVqg04JtfggFRuwvVjzP4e/2ssQ r+6hQ2OuwBKtJW+0D00gI5fpf1C8aQ== =rxh0 -----END PGP SIGNATURE----- --Apple-Mail=_C82770A3-A6F9-49AC-B8D9-E7F35447EF65-- From nobody Tue May 4 13:23: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 775973A11E4 for ; Tue, 4 May 2021 13:23:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 sv9xk8W7Q4xf for ; Tue, 4 May 2021 13:23:35 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 9126B3A11E3 for ; Tue, 4 May 2021 13:23:35 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id j11so4168557qtn.12 for ; Tue, 04 May 2021 13:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=b7K7HCeQ2i3iBlWvFYB8u/K/D3In0l1wljFQ/7qPvto=; b=FyCtXwokkRL/qrhjd1HPqMGg33I49uZKeuo9JKG+Ddcbed584zaEcbOAWhUUO6gcxE pi65QzkpzihCfryE7tr7ib7RxxpVYu+WfTN/lJ6tQtM3MEF9VjKLEKGDBz8GCPtk0z0D 7FrrmqjFalOJpqIh27Z/s9ePKPvIbGYyiBd/7UZyQvWooVUtwIsyJlrSnBxaUMEZERx+ rD+LKPbQaoTJLL1r78AsF7v8JuKiUuGzoNiRWNOrAph9FYr3DSp5k9YCeN2Qgkhljugh mkRpAwhyYjnlPHTfqeyU8BMFUy9ef0AYgRk7KjCf6bpw1z++0DIeWPZAQZ2rXI0mFHjk mWdw== 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=b7K7HCeQ2i3iBlWvFYB8u/K/D3In0l1wljFQ/7qPvto=; b=PQS/JiQl6L+TFjupN9Vn9tpW7ZDIc2TjnqPKjTTPBZgK9xjkWo4W9FFm2B9HIKFKge +ow51c2x5nerSst44RAJChLBhfxVCqYoFqTinKEEkwUEfiO2DrPc/DkRA8YzsGCERkVv +6NqnovnG456QgmvJu7AzGwbfspmetWFLWdLLmitZMjESKBDdJ1937QWaU/wGY7VOAAd UlEqu6ZBy8u1QARDFI/AWXK4TkOL9Mf5Y3EsoBMx3ohK8y9+BRwHLw6F+ffbtQ/V5GvN 6QulNZm6179XcEWg76F6eS+4JgdqCeJlAysv2MaGY7grxaXm8R5y1Icjzx0bCK+7Nm5/ oOhg== X-Gm-Message-State: AOAM532HrPUPi4nrFBdSA8kLM/sQQKjXMooCz4lRGQ78fbulUrq575Np fvopqDCUD5cD2aLxlohdnj0T+A== X-Google-Smtp-Source: ABdhPJyVKap3nGW5ohrrfkvNYORzf9W9CrPGm1tZ591AV5dQbykxJF8H5X5Iwaj584ra8E+1cfybTw== X-Received: by 2002:ac8:e09:: with SMTP id a9mr24461758qti.238.1620159813446; Tue, 04 May 2021 13:23:33 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id 14sm2122976qkg.32.2021.05.04.13.23.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 13:23:32 -0700 (PDT) To: Eliot Lear , Brian E Carpenter Cc: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> <6E7E6396-92F8-43ED-A391-DFFEA256F577@cisco.com> From: Michael StJohns Message-ID: <030a108e-2e1d-52cf-d08e-be4013924e3e@nthpermutation.com> Date: Tue, 4 May 2021 16:23:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <6E7E6396-92F8-43ED-A391-DFFEA256F577@cisco.com> Content-Type: multipart/alternative; boundary="------------C5615C37C4057C3D7C65DC40" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Who minutes meetings? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 20:23:39 -0000 This is a multi-part message in MIME format. --------------C5615C37C4057C3D7C65DC40 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/4/2021 4:10 PM, Eliot Lear wrote: > Brian, > >> On 4 May 2021, at 22:00, Brian E Carpenter >> > wrote: >> >> Yes. I didn't mean to specify that the RSA/E actually takes the >> notes. But >> somebody needs to make sure it gets done properly, and our experience >> with >> community volunteer WG chairs is that many of them don't get it done >> properly. >> See any recent set of IETF Proceedings for examples. > > > Let’s decompose this a bit into two questions: > > 1. Is it important that someone accurately capture decisions and > action items in the form of minutes for the (a) RSWG and (b) the RSAB? > 2. Who does the job? > > > I think there will likely be agreement on (1).  On (2), we have a lot > of latitude at the stage in the game.  The ED could see to this, the > LLC could see to this, the RS[EA] could see to this, or we could rely > on a volunteer in the community.  Maybe there are other possibilities. > > Eliot Why is this not deferred to each of the groups to decide when they get operational? --------------C5615C37C4057C3D7C65DC40 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/4/2021 4:10 PM, Eliot Lear wrote:
Brian,

On 4 May 2021, at 22:00, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

Yes. I didn't mean to specify that the RSA/E actually takes the notes. But
somebody needs to make sure it gets done properly, and our experience with
community volunteer WG chairs is that many of them don't get it done properly.
See any recent set of IETF Proceedings for examples.


Let’s decompose this a bit into two questions:

  1. Is it important that someone accurately capture decisions and action items in the form of minutes for the (a) RSWG and (b) the RSAB?
  2. Who does the job?

I think there will likely be agreement on (1).  On (2), we have a lot of latitude at the stage in the game.  The ED could see to this, the LLC could see to this, the RS[EA] could see to this, or we could rely on a volunteer in the community.  Maybe there are other possibilities.

Eliot

Why is this not deferred to each of the groups to decide when they get operational?  

--------------C5615C37C4057C3D7C65DC40-- From nobody Tue May 4 13:47: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 17FF33A12F1 for ; Tue, 4 May 2021 13:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.898 X-Spam-Level: X-Spam-Status: No, score=-11.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5r48z2GbWjtI for ; Tue, 4 May 2021 13:47:52 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8900E3A12F0 for ; Tue, 4 May 2021 13:47:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2898; q=dns/txt; s=iport; t=1620161271; x=1621370871; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=E/vTiMczL/Xjjl6L1mFs1kK273c9Fpq8YvBO7+ALFL0=; b=HxmL/DBN+sDWiIpZnykmXuX2v5ammf10lB9OXFnrCKDv9h8FNolXzwBk LoQMR+EeRyOJRF16szsziI9ILx6gR8KHh2tkESFa14MvMHoJ+s5pzKMpn qjSU87AwUoTxmnAe0WzMf0aofGncLlO9f3leGNkMg5vF5b8ODKnWg3HIN E=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AUAACWspFg/xbLJq1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBggYCAQEBAQsBg3cBJxIxhESJBIhNKJRXiCUEBwEBAQoDAQE0B?= =?us-ascii?q?AEBhFACgXwmNwYOAgQBAQEDAgMBAQEBAQUBAQECAQYEcROFXYZEAQEBAwEjV?= =?us-ascii?q?gULCwQBBwwqAgI9GgYTgnEBgmYhqHx6gTKBAYRhhG0QgToBgVKFMgGGWkOCC?= =?us-ascii?q?4E8DBCCXz6HWTaCKwSEcmgplFOKGZ0ZgxqDRYFJmCAFIqUjtEJJhAYCBAYFA?= =?us-ascii?q?haBaiSBWTMaCBsVZQGCPj4SGQ6cbj8DLzgCBgEJAQEDCY0PAQE?= IronPort-HdrOrdr: A9a23:f1h9362PQQqOcSPXFByj2AqjBDAkLtp033Aq2lEZdDV+eKWj5q OTtd4c0gL5jytUZWE4lbm7VJWobHvA+fdOgLU5EqylWGDd0leADIYn1of6xi2lJiuWzI5g/I NtabJ3BtG1LVUSt6vHyS25F9pl/9Wd6qCvgo7loEtFdg1hZ6F+4woRMG/yeXFefwVICYE0E5 CR/KN81l+dUE4KZce2DGRtZYb+juDM/aiWAyIuNloC4AmKgSjA0s+fLzGomjEDTjhI3bAutU /CngCR3NTEj9iLjjnBymTU85Na3OHE9+IGLsmNhs8JQw+c7TqVWA== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,272,1613433600"; d="asc'?scan'208,217";a="33288310" 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; 04 May 2021 20:47:46 +0000 Received: from smtpclient.apple ([10.61.144.35]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 144KljSd000392 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 4 May 2021 20:47:46 GMT From: Eliot Lear Message-Id: <2DABF3F9-3549-4B6D-8A55-4ED566A23F75@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_064CFB59-B60E-4617-ADC1-99F2565DD688"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 4 May 2021 22:47:44 +0200 In-Reply-To: <030a108e-2e1d-52cf-d08e-be4013924e3e@nthpermutation.com> Cc: Brian E Carpenter , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind To: Michael StJohns References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> <6E7E6396-92F8-43ED-A391-DFFEA256F577@cisco.com> <030a108e-2e1d-52cf-d08e-be4013924e3e@nthpermutation.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.35, [10.61.144.35] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Who minutes meetings? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 20:47:57 -0000 --Apple-Mail=_064CFB59-B60E-4617-ADC1-99F2565DD688 Content-Type: multipart/alternative; boundary="Apple-Mail=_E6739A1B-1C57-4C25-BB5C-21A6D044FD0D" --Apple-Mail=_E6739A1B-1C57-4C25-BB5C-21A6D044FD0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 4 May 2021, at 22:23, Michael StJohns = wrote: >>=20 > Why is this not deferred to each of the groups to decide when they get = operational? >=20 Also a perfectly reasonable approach. What I would suggest is that if = that is this group=E2=80=99s decision, some general request be in the = doc for the LLC provide such administrative support as the groups may = require. Eliot --Apple-Mail=_E6739A1B-1C57-4C25-BB5C-21A6D044FD0D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 4 May 2021, at 22:23, Michael StJohns <msj@nthpermutation.com> wrote:

Why is this not deferred to each of the = groups to decide when they get operational?  


Also a perfectly = reasonable approach.  What I would suggest is that if that is this = group=E2=80=99s decision, some general request be in the doc for the LLC = provide such administrative support as the groups may require.

Eliot
= --Apple-Mail=_E6739A1B-1C57-4C25-BB5C-21A6D044FD0D-- --Apple-Mail=_064CFB59-B60E-4617-ADC1-99F2565DD688 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCRsvEACgkQh7ZrRtnS ejOjewf/dN9PhYw71ZYtdOeOUol+pucWUjYLtHoKtBRhKmXDEpNsmVzeYJMlGVz2 JjGE3gAEmXO30oWYf6wtshfOgPG7TqoQUzzId+uys0boEYMrmSCQhOqTNTF1buJe TMjY2xqlx0Dq5sK5f9F/GYO5aeG3Clo/zLsaoSmKE7m1OuZ6uBPQ7rQIF7aKjUJH su2BihEJ7SQP50x/aeOKjh918FGgva4RbLo9CKJII19iTDdn/FOZ12IuwpqajpOt 6q+N91zuK8Djx2Il9+BqLU8KcG72V+oQoVVQDWiEsIcAMenmaqwAk/WdpqubFewb IvD7laOoaqxX/8Vofb75jUvtMPGMHw== =XVTL -----END PGP SIGNATURE----- --Apple-Mail=_064CFB59-B60E-4617-ADC1-99F2565DD688-- From nobody Tue May 4 14:09: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 AFC613A1418 for ; Tue, 4 May 2021 14:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-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=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 f73RhESY8ger for ; Tue, 4 May 2021 14:09:44 -0700 (PDT) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E0EE3A1415 for ; Tue, 4 May 2021 14:09:44 -0700 (PDT) Received: by mail-qk1-x733.google.com with SMTP id 76so8283197qkn.13 for ; Tue, 04 May 2021 14:09:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=e/XO8SRcTqmYlW+zB/dSFVqXItrrLWy85s6EFwVZxaQ=; b=veZB6g16bq7xFl80qJDUgPDsdOLhcCp393gzEEt+3RaeX3Gwh8jf462gDMaFpTn36M WCo5TANk2emVP/utGB43S4jC/XQDCyxYsWhnm5dvwoHc8CldQ6GjzR1qHCLZNXN5N5BV kmL4DCBZgBUfTdaDsNxVwp+U5gjNyblmPxUF9G8FnnuN2eYbKgBg4Ub/WthJtOVcxrd5 9JB2Pja7Hm8hX1r16q48+OWwhsSw/NawquTlOLvBRbuKTEvvb897X0kwP8wGNSUpERX5 cj/naf4UQNTdr/sx8yc7Lmug1fahwCaE1w+VYkyHCuwpi+K7D9Kn9RUhjEqr9cqmg2ZU Qvbw== 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=e/XO8SRcTqmYlW+zB/dSFVqXItrrLWy85s6EFwVZxaQ=; b=T60MQ9JHCCYVLEKfD+hU4C1H9SODzuk9aGrJaZ7FmIRN1ipi1wusrQY8Pmd+g98slI IyzhTwgez2lb0B2BtrgJq/z+EcWmX919B1Uhc46aFz8OlDLhcXfDEs8B1Fok/PQ+PmSE bNd3Ir40Z8RgkoVyhaaTfHf16LH8sodRsEL155ZgbtTteVRpFBwvHNtOnaWqRjS3WkbW 9NaDxMHTV4B4wrachPsa7c7lc73YqQRmXGHumo3hB75l8CMvkNVURERq98keELXTUAbr +xX6fFHcGyckpnMJNUDk1lG5W21jXGmcrJW20iHwqlvKH5G1GXDFCkOEXtTlfBAxACwm xE/Q== X-Gm-Message-State: AOAM532ihYYwguQ+/uTiSVXFJnZ/jAuExGg74jWhJioYLgdeobqobmjf aAmB6ed2nxCoCGldh9N+ZiRL0A== X-Google-Smtp-Source: ABdhPJwOH2CfQmH9CAEoQfuwNOhpYDmipB2kCWZBLP6vNDaHMQNw8WmpKD2Q03QJ0w7VmYDVMAFbAg== X-Received: by 2002:a05:620a:2903:: with SMTP id m3mr26548539qkp.37.1620162582630; Tue, 04 May 2021 14:09:42 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id p190sm11996721qke.13.2021.05.04.14.09.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 04 May 2021 14:09:41 -0700 (PDT) To: Eliot Lear Cc: Brian E Carpenter , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> <6E7E6396-92F8-43ED-A391-DFFEA256F577@cisco.com> <030a108e-2e1d-52cf-d08e-be4013924e3e@nthpermutation.com> <2DABF3F9-3549-4B6D-8A55-4ED566A23F75@cisco.com> From: Michael StJohns Message-ID: Date: Tue, 4 May 2021 17:09:41 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2DABF3F9-3549-4B6D-8A55-4ED566A23F75@cisco.com> Content-Type: multipart/alternative; boundary="------------213489FA37D867766A9F1363" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Who minutes meetings? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 21:09:49 -0000 This is a multi-part message in MIME format. --------------213489FA37D867766A9F1363 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/4/2021 4:47 PM, Eliot Lear wrote: > > >> On 4 May 2021, at 22:23, Michael StJohns > > wrote: >>> >> Why is this not deferred to each of the groups to decide when they >> get operational? >> > > Also a perfectly reasonable approach.  What I would suggest is that if > that is this group’s decision, some general request be in the doc for > the LLC provide such administrative support as the groups may require. > > Eliot LLC not RSA/E is fine with me. Hmm.. ok - topic for the document:    What on-going support will the RSAB and RSWG require from the LLC?  I.e. something similar to what's currently provided to the IESG and IAB or something completely different? --------------213489FA37D867766A9F1363 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/4/2021 4:47 PM, Eliot Lear wrote:


On 4 May 2021, at 22:23, Michael StJohns <msj@nthpermutation.com> wrote:

Why is this not deferred to each of the groups to decide when they get operational?  


Also a perfectly reasonable approach.  What I would suggest is that if that is this group’s decision, some general request be in the doc for the LLC provide such administrative support as the groups may require.

Eliot

LLC not RSA/E is fine with me. 

Hmm.. ok - topic for the document:    What on-going support will the RSAB and RSWG require from the LLC?  I.e. something similar to what's currently provided to the IESG and IAB or something completely different?

--------------213489FA37D867766A9F1363-- From nobody Tue May 4 14:24: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 081D53A14B1 for ; Tue, 4 May 2021 14:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zkB2lm1-2fuO for ; Tue, 4 May 2021 14:24:51 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 18ACF3A14AC for ; Tue, 4 May 2021 14:24:50 -0700 (PDT) From: Jay Daley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <5AF18B7B-3681-45BB-8D61-DAF0DCAB2732@ietf.org> Date: Wed, 5 May 2021 09:24:47 +1200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Rfced-future] Suggestions for "RSEA Ongoing Performance Evaluation" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 04 May 2021 21:24:54 -0000 I=E2=80=99ve reviewed 6.2 "RSEA Ongoing Performance Evaluation" of = draft-saintandre-rfced-model and I wonder if it is possible for a draft = recommendation from the IETF Executive Director to be presented to the = RSAB, excluding the RSEA, and an official view of the RSAB to be = included in the final recommendation to the LLC Board? My concern here is that community feedback, while often of high quality, = may potentially be biased or incomplete and the RSAB is probably best = placed to take a view on that. Also, I think it would be useful to note why this recommendation has to = go to the LLC Board rather than just being handled by the IETF Executive = Director, otherwise this document may inadvertently set a precedent for = other contracts. Finally, I assume the feedback, summary of feedback and the = recommendation are confidential? If not then that should be clearly = stated. Jay --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Tue May 4 15:26: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 486FB3A17D6 for ; Tue, 4 May 2021 15:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 Hk5mljL20D7z for ; Tue, 4 May 2021 15:26:14 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 B078B3A17D1 for ; Tue, 4 May 2021 15:26:13 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id c3so11566685lfs.7 for ; Tue, 04 May 2021 15:26:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+uLcQ+mj1D2/aaDYvQzdSIjoTPU5xrKx5g610QHJejg=; b=M9IidKrMn8jLGfaWz3B9SrF5L+LnVV+O9Kmv21WIjK9iTp7V4cexJTVT09sXJJ5PRs X3FS630Z0MSz1Uj86FYHayOxDZemKpkG3Jh/KQMkaXxgggA82WN9A/VdQDR5rZ10jons lLpKQvVGkiG3UEYZVGcVtkwiIqUq98KVykSG7MyTKjg7lMDvIhIphuhqtNYdBQfeHzwy sQ5QuACtFIjqCWqBeTDRKdP7rpIl1IPhYPkUuKk695uO6rb0OzT6SK1VZpnQS5UBvxiF sNBaqMUnQo7sD4oVClxBu1wPLGGw9id589jjaNwYUkYFS86w+czaiS2vyKHKuvBzTRrZ aoFg== 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=+uLcQ+mj1D2/aaDYvQzdSIjoTPU5xrKx5g610QHJejg=; b=LzU0iUtI/M+iYzxEhcBNAbsE45pZweMz/bhbxIxzrCZ6xNUQoVCNOZFXJ+CxsP6bmC 9+SYymnTqJvWkuyPjidRxaunMUDEElOeLM72VsJaZ1F/sAWKMLRhrL//1I3ywXTf5grc afpowbeN15fSLpplfV4JMEbtnR4K+PT5EaWeM8ZAd4qwt9hFBs0PFhFNsTxX6CZCE0Ug +mYgj275Yr6ssqvMdbXkQ8dfBFY5PkJRDlbR5c5qzjVBXJIJoyyoKhi9NaQyeXi/wZ5i ISMyhBsY26Y+gIskSa+DfGGtap2xUJAGbm6SaJ+zMPelk1oLrwaCB4EmiLq3mQQ/zjzE egoQ== X-Gm-Message-State: AOAM530WetOndq6UXPipbHzfbMiWIaHbeXgM+zqpwjEcSFjQcI8pqKL9 5VCeARdaTYN6uPfBjcEq+1HiX6k66UJd7LtgopQ= X-Google-Smtp-Source: ABdhPJzpX57GE948B6nhiY7BYRuaosfR8PsGMRE/goPyj9FwOGwyUdHoRrJEFjJKiGIXxCy1tRmic84ixqxcNuIIYbQ= X-Received: by 2002:ac2:52a9:: with SMTP id r9mr18876583lfm.308.1620167170875; Tue, 04 May 2021 15:26:10 -0700 (PDT) MIME-Version: 1.0 References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> <6E7E6396-92F8-43ED-A391-DFFEA256F577@cisco.com> <030a108e-2e1d-52cf-d08e-be4013924e3e@nthpermutation.com> <2DABF3F9-3549-4B6D-8A55-4ED566A23F75@cisco.com> In-Reply-To: From: Brian Carpenter Date: Wed, 5 May 2021 10:25:58 +1200 Message-ID: To: Michael StJohns Cc: Eliot Lear , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , rfced-future@iab.org, Russ Housley , Mirja Kuehlewind Content-Type: multipart/alternative; boundary="000000000000b265fa05c18890a4" Archived-At: Subject: Re: [Rfced-future] Who minutes meetings? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 May 2021 22:26:19 -0000 --000000000000b265fa05c18890a4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes, putting this on the LLC is fine by me. As long as it's somebody's job. Regards, Brian Carpenter (via tiny screen & keyboard) On Wed, 5 May 2021, 09:09 Michael StJohns, wrote: > On 5/4/2021 4:47 PM, Eliot Lear wrote: > > > > On 4 May 2021, at 22:23, Michael StJohns wrote: > > > Why is this not deferred to each of the groups to decide when they get > operational? > > > Also a perfectly reasonable approach. What I would suggest is that if > that is this group=E2=80=99s decision, some general request be in the doc= for the > LLC provide such administrative support as the groups may require. > > Eliot > > LLC not RSA/E is fine with me. > > Hmm.. ok - topic for the document: What on-going support will the RSAB > and RSWG require from the LLC? I.e. something similar to what's currentl= y > provided to the IESG and IAB or something completely different? > --000000000000b265fa05c18890a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes, putting this on the LLC is fine by me. As long as it= 's somebody's job.

R= egards,
=C2=A0=C2=A0=C2=A0 Brian Carpenter
=C2=A0=C2=A0=C2=A0 (via ti= ny screen & keyboard)

On Wed, 5 May 2021, 09:09 Michael StJohns, &= lt;msj@nthpermutation.com>= wrote:
=20 =20 =20
On 5/4/2021 4:47 PM, Eliot Lear wrote:
=20

On 4 May 2021, at 22:23, Michael StJohns <msj@nthperm= utation.com> wrote:

Why is this not deferred to each of the groups to decide when they get operational?=C2=A0=C2=A0


Also a perfectly reasonable approach.=C2=A0 What I would suggest is that if that is this group=E2=80=99s decision, some gene= ral request be in the doc for the LLC provide such administrative support as the groups may require.

Eliot

LLC not RSA/E is fine with me.=C2=A0

Hmm.. ok - topic for the document:=C2=A0=C2=A0=C2=A0 What on-going s= upport will the RSAB and RSWG require from the LLC?=C2=A0 I.e. something similar = to what's currently provided to the IESG and IAB or something completely different?

--000000000000b265fa05c18890a4-- From nobody Tue May 4 18:33: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 EFDA53A1E0A for ; Tue, 4 May 2021 18:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kuj3kJAs0QZ9 for ; Tue, 4 May 2021 18:33:45 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 68B423A1E00 for ; Tue, 4 May 2021 18:33:45 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id z14so234917ioc.12 for ; Tue, 04 May 2021 18:33:45 -0700 (PDT) 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=AkpwY4kS1ZdhWm4+C7diGN0Kev3+c9uLGPuqMrvCg50=; b=qsuoMGe38XDcZp+1km9PGio5KeDPtG4w5n1UwOmWUBw43n9L3TAXWGrbM7CnBL2xij ty2NnYLthSXvAojZv5ey7pwbjj4OGqCe68mRpH3wqF1oRtVbds92UQHJYTOGrn+JGRcd x8vW3a5mG0vpVQDl84GtCD4nnWW2wRkTMvwj7R7iV9cIdg+rSxmJPdzBUJmQWBhBSc2v FLcG+Zc2HHHefas8aHqqKu4m1LkkzrcIh+vZchx6BI1YgYLFGoxo8zl27GZYlUkAg8mw tMg3XurZECWMqhUNptUy3MwOe3uL0v9ZkALcpQtZfHCHRYGaaTqNLnn/wTbmxJVBgDCs Xnqg== 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=AkpwY4kS1ZdhWm4+C7diGN0Kev3+c9uLGPuqMrvCg50=; b=trF1SqfwxnNoZ+GREKhshjyGHIkDG+nUdOnJ7cj572dGLHDApw3nnoVperjGcDnH4c FlWuC8N8KmsS9P6+qqqynNL6q3/RO/Dh5HDMkctLjClaUxatEpDDgUtasaiZKBD+CMzC yBHq1OolQL60MDUDpXVr3KFvd3CBkK0bLuXrNs/tr1DRo3XTJvCRbybQgLwKzuleWEQw DrtInYJz7fAoK2/6OQayRzG97OZd22LVlr31UvkZTEQFpxjtAH83hZPEdmA9oFsqVv3Q JuAUsiw6LzXZ3MzvnxQ7zSLfDRCqmwIdTr/s3DZs6LshkYwTywiBbyNFmhZhyvg4wgDc B+9Q== X-Gm-Message-State: AOAM530UDjktthdJjUtfHE2zUB5mWhCnYZPiQkQ0BElGPiP3i2StmlQA ETNUTlFycTqfZ7529XMqmrZ6AFK68iq3pz/7GaFyIw== X-Google-Smtp-Source: ABdhPJw/zIhlUV+haUKytrtxdd9OSa0oDJwWJNuAigZag8PvUKsMsF9tjEbjFZMQ8PbxAlRm763uTcLsgrYwJlVmTYU= X-Received: by 2002:a6b:7944:: with SMTP id j4mr17500469iop.60.1620178424116; Tue, 04 May 2021 18:33:44 -0700 (PDT) MIME-Version: 1.0 References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> In-Reply-To: From: Eric Rescorla Date: Tue, 4 May 2021 18:33:07 -0700 Message-ID: To: Brian E Carpenter Cc: Michael StJohns , Eliot Lear , rfced-future@iab.org, Mirja Kuehlewind , =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , Russ Housley Content-Type: multipart/alternative; boundary="000000000000714a4105c18b2f03" Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 01:33:50 -0000 --000000000000714a4105c18b2f03 Content-Type: text/plain; charset="UTF-8" On Tue, May 4, 2021 at 1:01 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 05-May-21 03:36, Michael StJohns wrote: > > On 5/3/2021 10:05 PM, Brian E Carpenter wrote: > >>>> Further, the RSA is expected to ensure that RSWG consensus is well > >>>> documented and communicated to the community, the LLC, and the > RPC. > >>>> This may include document authorship. > >>> Um... what? This puts the RSA as a process facilitator for the RSWG > and > >>> gives them responsibilities to keep the record of the RSWG??? That's > >>> new AFAICT. The document authorship does not necessarily imply the > rest > >>> of this. > >> True. But given the lamentable and unpolished "minutes" that most IETF > WGs > >> produce, which definitely don't satisfy RFC2418, I intended what I > wrote. > >> Obviously, that's open for discussion. > >> > > Um... in what universe does "note taker and minute keeper" equate > to "senior professional"? There's also the fact that the note > taker in general is less able to participate in the discussion. > > Yes. I didn't mean to specify that the RSA/E actually takes the notes. But > somebody needs to make sure it gets done properly, and our experience with > community volunteer WG chairs is that many of them don't get it done > properly. > See any recent set of IETF Proceedings for examples. > I'm less sure than Brian that we need to significantly improve on minutes quality, but if we have consensus on that, I agree that we cannot rely on volunteers. -Ekr > Brian > > > The fact that you're already projecting that the WG chairs will not be > able to run an adequate process does not to me suggest that we try and fix > that brokenness by laying trivial jobs on the RSE/A. > > > > Are we trying to sabotage the hiring process already? > > > > Later, Mike > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000714a4105c18b2f03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 4, 2021 at 1:01 PM Brian = E Carpenter <brian.e.carp= enter@gmail.com> wrote:
On 05-May-21 03:36, Michael StJohns wrote:
> On 5/3/2021 10:05 PM, Brian E Carpenter wrote:
>>>>=C2=A0 =C2=A0 =C2=A0Further, the RSA is expected to ensure = that RSWG consensus is well
>>>>=C2=A0 =C2=A0 =C2=A0documented and communicated to the comm= unity, the LLC, and the RPC.
>>>>=C2=A0 =C2=A0 =C2=A0This may include document authorship. >>> Um... what?=C2=A0 This puts the RSA as a process facilitator f= or the RSWG and
>>> gives them responsibilities to keep the record of the RSWG???= =C2=A0 That's
>>> new AFAICT.=C2=A0 The document authorship does not necessarily= imply the rest
>>> of this.
>> True. But given the lamentable and unpolished "minutes" = that most IETF
WGs
>> produce, which definitely don't satisfy RFC2418, I intended wh= at I wrote.
>> Obviously, that's open for discussion.
>>
> Um...=C2=A0 in what universe does "note taker and minute keeper&q= uot; equate
to "senior professional"?=C2=A0=C2=A0 There's also the fact t= hat the note
taker in general is less able to participate in the discussion.

Yes. I didn't mean to specify that the RSA/E actually takes the notes. = But
somebody needs to make sure it gets done properly, and our experience with<= br> community volunteer WG chairs is that many of them don't get it done pr= operly.
See any recent set of IETF Proceedings for examples.
<= br>
I'm less sure than Brian that we need to significantly im= prove on minutes quality, but if we have consensus on that, I agree=C2=A0 t= hat we cannot rely on volunteers.

-Ekr


=C2=A0 =C2=A0Brian

> The fact that you're already projecting that the WG chairs will no= t be able to run an adequate process does not to me suggest that we try and= fix that brokenness by laying trivial jobs on the RSE/A.
>
> Are we trying to sabotage the hiring process already?
>
> Later, Mike
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000714a4105c18b2f03-- From nobody Tue May 4 18:41: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 BEDB73A1E47 for ; Tue, 4 May 2021 18:41:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=I5cWrpCY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BWusdIBQ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNVYoycBzT5U for ; Tue, 4 May 2021 18:41:05 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FCEB3A1E46 for ; Tue, 4 May 2021 18:41:05 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 44DD55C018D for ; Tue, 4 May 2021 21:41:04 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Tue, 04 May 2021 21:41:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=XKFPkONm9A7ZL3avWakcOV3hOyfTp4K urADkqU25NIU=; b=I5cWrpCYU2g6LinVJZmro9kkAKZSeUnpY0U4Zdb3Cf27AGu te6FaN4fVVphXK91CPEuuJyH4XSlcpCLZkY950BDAbQNjn5koo2fWrebar9msTiG ReQEcNTydSNfMzUNjQG0fk/a3CeYKRm0wt0M2xVb0INgJr5hWdn9nXowM8+f1xtQ L6FaVOGDT2PkzqsGswyTE1cz4WcvlqGQUtCMQCv6vxfL1osrNYRpg3BrN6b7SXfg w2dGNkEjfUgVWEqXCBUl5RV+2iwgkaVrtvhXdNEzFz3nZc9VlJeZ/aBnLWoCU2P3 AEKKCI/bw4i9qgg3s8sq6jq5B0NV2HfKjDjXj6Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=XKFPkO Nm9A7ZL3avWakcOV3hOyfTp4KurADkqU25NIU=; b=BWusdIBQOr6Zta7KqHS+VW MtNRr9oWoAB7vSWVTdE6Q8iiP0qbTiORvxPX22NoMJOsk28kRF+hOZ+wtjh+1YO4 o1nCDmunJnDbmG9ldmHUetYNv9UsYFb8z0ynk7ZN6ra84ASwwIXIZE/Xg5rpqLbt +Tv3SrtbgvEdZzSisOyOzDyQMtv2rF23jGgytQuW0GHXq2chSulJf8E0hz4pRzUD rXV/ybAjp5rMWyTzaQa10C2+zOxfoXhZHG0WrQMo7UbIfwY1WWLNGIaWkEyey9yW 0P8kR5lnCOo1Yoz6xc5XTK5vtvRcQhkE5WIQBGT+EKRaSEjangp6iDdPrnrNGU2A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdefjedggeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id EC3C94E0178; Tue, 4 May 2021 21:41:03 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-442-g5daca166b9-fm-20210428.001-g5daca166 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> Date: Wed, 05 May 2021 11:40:44 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 01:41:11 -0000 On Wed, May 5, 2021, at 11:33, Eric Rescorla wrote: > I'm less sure than Brian that we need to significantly improve on > minutes quality, but if we have consensus on that, I agree that we > cannot rely on volunteers. Like Mike, I think that each body can develop their own procedures when it comes to recording minutes. However, related to this, it might be good to allow each body to request that the LLC provide some form of material support, either in the form of tools or clerical services. This might include meetecho and codimd (the current sort of support that the IETF receives) or it could be a person who takes minutes. I would hope that each can find a volunteer for the latter though. From nobody Wed May 5 01:01: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 656223A16CB for ; Wed, 5 May 2021 01:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.898 X-Spam-Level: X-Spam-Status: No, score=-11.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtGdm5DVYDnJ for ; Wed, 5 May 2021 01:00:53 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9D43A16C6 for ; Wed, 5 May 2021 01:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2481; q=dns/txt; s=iport; t=1620201653; x=1621411253; h=from:mime-version:subject:message-id:date:to; bh=UN/HNXtnrcpYLw83VI97bbBOdzfOGFLPtmzKhQyZRPE=; b=m2ZSP3nBy9NxNr9hwRCE9NqKBPUg0XDwsnyEkV2gEo8HyGZGk7ONO/9e BqTbW02pW9zud9ZZbaAw6vYPRqH5wdeSffQWm4lH6aoTkwUdK+CnKAxMW tkuiw4rbxm6zj/CCQN3tDsi0l+LlY/GRIcw2wUyYII0ctVYQt4y9ZfYM9 0=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0A5AAAeUJJglxbLJq1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UYEAQELAYMhVgEnEo15nUuIJQQHAQEBCgMBASgMBAEBhk4mNwYOAgQBAQEDA?= =?us-ascii?q?gMBAQEBAQUBAQECAQYEFAEBAQEBAQEBaIVQDYY7gScBCHeDJAGDBw+ZNo4We?= =?us-ascii?q?IE0gQGDXUCFMAoGgToBgVKFMocegguBFScchX0Cgi2DAIIrBIJGgRArIIEwQ?= =?us-ascii?q?p5cnRmDGoNFgUmEa5M1BRkJpSNIoGiTWgGEBgIEBgUCFoFqIoFbMxoIGxVlA?= =?us-ascii?q?YI/PRIZDo44g1eKXz8DZwIGCgEBAwmNDwEB?= IronPort-HdrOrdr: A9a23:E6CrSa4v4w0AupokagPXwCHXdLJzesId70hD6mlaTxtJfsuE0/ 2/hfhz73LJoRsYRX1Io7G9EYaaR3e0z/RIyK0cJ62rUgWjmGbAFu9fxK/jxzGlJCHk7O5a0s 5bH5RWM9H7AVhkgcuS2mDReOoI+sWN86yjmI7loEtFcAcCUcFdxjY8Lg6aF0FsLTM2ZqYRJd 67+tdNoSamdDAxaMm2b0N1OtTrlpnsiI/sZwIACloczDS2yRms6LL8DnGjr3Ujbw8= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,274,1613433600"; d="asc'?scan'208,217";a="35735345" 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; 05 May 2021 08:00:48 +0000 Received: from smtpclient.apple ([10.61.144.35]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 14580lSV011929 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 5 May 2021 08:00:48 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_E4167D5E-5E96-4AD1-B60B-FC3C27A667C5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: Date: Wed, 5 May 2021 10:00:47 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.35, [10.61.144.35] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: [Rfced-future] (Mostly) editorial changes offered by EKR X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 08:00:58 -0000 --Apple-Mail=_E4167D5E-5E96-4AD1-B60B-FC3C27A667C5 Content-Type: multipart/alternative; boundary="Apple-Mail=_C2059DEA-A034-4E9D-B433-3971EA8AE9A1" --Apple-Mail=_C2059DEA-A034-4E9D-B433-3971EA8AE9A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just so that people are aware, EKR has created a PR on Github for mostly = editorial changes (spaces/double words, etc) that can be found here = . = There is one substantial change in those comments that deserves = discussion, but is also probably not all that controversial, and I will = pull that out into a separate issue: when the RSAB starts its formal = review. Eliot --Apple-Mail=_C2059DEA-A034-4E9D-B433-3971EA8AE9A1 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Just so that people are aware, EKR has created a PR on Github for mostly editorial changes (spaces/double words, etc) that can be found here.  There is one substantial change in those comments that deserves discussion, but is also probably not all that controversial, and I will pull that out into a separate issue: when the RSAB starts its formal review.

Eliot
--Apple-Mail=_C2059DEA-A034-4E9D-B433-3971EA8AE9A1-- --Apple-Mail=_E4167D5E-5E96-4AD1-B60B-FC3C27A667C5 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCSUK8ACgkQh7ZrRtnS ejOTawf7Bw7haAP5OznnLpG6v8hAYUnx74ipSo9bp6Tl2TlUMGFBWB0PLqDCb7WN w4QTSdMcmKjrfG2LSFCkb96/khdQJ4BCcxETByzFbrRfki0kspPL24VskfzsUags vrB7MrOemUF9F1Afwcla1CVo5iIZSKpygEJfYAdvuHHMjnyZC8I4LYiUebCa5/t3 IGB5mYR6I7HYDYkI6cA1fYNy1mKw+dH98mlKAMyMTVyVuicmTjjqdGQ4IX1pTDCB amFKPz+828telUht9vreS/26Mkx9a5cndB1n0/uOjZ2EkUr2dEgebHTVISfhVlG3 ElEkkOVscdb3TlX4ZxNy3KJanoS3kg== =p0Tk -----END PGP SIGNATURE----- --Apple-Mail=_E4167D5E-5E96-4AD1-B60B-FC3C27A667C5-- From nobody Wed May 5 01:56: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 979D63A18C3 for ; Wed, 5 May 2021 01:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=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 UXl_6e-JRJ1s for ; Wed, 5 May 2021 01:56:32 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA2CB3A18BF for ; Wed, 5 May 2021 01:56:32 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id b3so744589plg.11 for ; Wed, 05 May 2021 01:56:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=o/KGbT6x6D4V3EvRVxcJ5Ogmwjc9YiUO7oox+cOosJ0=; b=WILuwrOeVIWFvFpji+eCT737Hspw+3nUFfqWybp5DsK43rMCZiHFXQWYori3r24041 G+gV56AKQW0tc1pHJa9DYPzsx7uWWvFvI0BEymLh+jurqkj+1L3D5oA/LjpbfcQ67JSM axVHRIHKOwxE1xeKMe9GdgiIEiaUjcwxvJgi8f9wN0gZgqPGTfx6PWLxR0kQYN8L6r3Z kmLz7n4x3kwJqT/KdkbmgiN0tdCHv2osfqR1Evq4JqHggngEdep4XhUJy3JF25ylrG9H 39M9yYB2aG9/yPFAuFbfNH/dPJ6LH5nhcAyNveZqfY75nZmF49ZID4g+Z90K1RnxKSR4 7BZQ== 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=o/KGbT6x6D4V3EvRVxcJ5Ogmwjc9YiUO7oox+cOosJ0=; b=dQsu/kKmwuZ3hR/sA8b1YEl83bGcxreYFfgO6d0CFANZ4T3nmBbSUSEeNe/LBrXsnX scZvjOgaqQ+guTPV3BPdeQq5jj24x856H3Isi7rQVkbPUEzyV/Eh4JwAzFnXsgaBXxXM h4dhpEZq1Y8i9pzOfTDwbuzOMB5k6hMRspLjsszu8lKNoxQ3er+4Pb8aayUcG4oCIBgA b1P5sCf0p2Qp/GjD95R76HlOrSbmRPKpbnZo8mQRKM6GMqpr0v2vJak186yzIq6h2qzV p/NElPo1VR2jL8Y357yCLkqpzKcfjlrB00yzhCpk3ZuN++X6LO9GjazbQBClHsU3rHE6 641g== X-Gm-Message-State: AOAM532UCrHLjv4zg2ycNAJ7IvP+3rBmeItpe5hzlAe3HZjjvjLb3oBz Craek24AFqtUF92Ji3202Jss3wO5buocnnz5 X-Google-Smtp-Source: ABdhPJyHsmCmFjZXmG4PRSb3bQ3v8xCGW2bK2t5OK64rkiJ/HWzIc+YoOExcfwyKqOA0XU2UHf65GQ== X-Received: by 2002:a17:902:6b02:b029:e9:8e2:d107 with SMTP id o2-20020a1709026b02b02900e908e2d107mr30519993plk.61.1620204992042; Wed, 05 May 2021 01:56:32 -0700 (PDT) Received: from [192.168.8.102] (122-56-211-117.mobile.spark.co.nz. [122.56.211.117]) by smtp.gmail.com with ESMTPSA id n203sm14764607pfd.31.2021.05.05.01.56.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 01:56:31 -0700 (PDT) To: Jay Daley , rfced-future@iab.org References: <5AF18B7B-3681-45BB-8D61-DAF0DCAB2732@ietf.org> From: Brian E Carpenter Message-ID: Date: Wed, 5 May 2021 20:56:25 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5AF18B7B-3681-45BB-8D61-DAF0DCAB2732@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Suggestions for "RSEA Ongoing Performance Evaluation" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 08:56:36 -0000 On 05-May-21 09:24, Jay Daley wrote: > I=E2=80=99ve reviewed 6.2 "RSEA Ongoing Performance Evaluation" of draf= t-saintandre-rfced-model and I wonder if it is possible for a draft recom= mendation from the IETF Executive Director to be presented to the RSAB, e= xcluding the RSEA, and an official view of the RSAB to be included in the=20 final recommendation to the LLC Board? >=20 > My concern here is that community feedback, while often of high quality= , may potentially be biased or incomplete and the RSAB is probably best p= laced to take a view on that. That's true. There's always a risk of a prominent individual being blamed=20 for issues outside their control, or for one noisy complainant being take= n more seriously than a majority of satisfied customers. The ED and the R= SAB are likely to have a more balanced perception. > Also, I think it would be useful to note why this recommendation has to=20 go to the LLC Board rather than just being handled by the IETF Executive = Director, otherwise this document may inadvertently set a precedent for o= ther contracts. >=20 > Finally, I assume the feedback, summary of feedback and the recommendat= ion are confidential? =20 I certainly hope so. But it might all be discoverable in case of dispute,=20 so needs to conform to appropriate HR practice.=20 Brian > If not then that should be clearly stated. >=20 > Jay >=20 From nobody Wed May 5 02:28: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 557E23A081D for ; Wed, 5 May 2021 02:28:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 Vu9O6fpJcW88 for ; Wed, 5 May 2021 02:27:58 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F363A083C for ; Wed, 5 May 2021 02:27:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2194; q=dns/txt; s=iport; t=1620206878; x=1621416478; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=YDdM64gkVIBp5fK0wWY07iurOyQCQ8Y/M/Ez1bEIx8k=; b=ZvS8A2qBU+S6Hfsp10G1bkp+ByVWYilaHr+P7RMh3RInZY8RehtpmLf1 Z/rgxca1q4ziPOX8rCMibatGB/vCgNtH02P9PNS8JXPwQEVD9mZJUng6h ycWM4+9GjugaUA8QzRGomxUj65MqvbteFFHlUb65cjddNMfoPQ3lneb1z E=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AFAAAVZJJglxbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGCBgEBAQEBAQsBgyFWAScSMYREiQSITCUDnHwEBwEBA?= =?us-ascii?q?QoDAQEdCwwEAQGEUAKBfSY3Bg4CBAEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBA?= =?us-ascii?q?QEBAQFohVANhkQBAQEDAQEBIUsLBQsLDAwqAgInFhoGExSCXQGCZiEPp1R6g?= =?us-ascii?q?TKBAYRhhG0KBoE6AYFSjA1DgguBFScMEIJfPoJgAYR4NoIrBIMqBFMgOzGBB?= =?us-ascii?q?1KQXBsSjQCLLpFrgxqDRYFJmCAFIqUjtQoBhAYCBAYFAhaBaiKBWzMaCBsVO?= =?us-ascii?q?yoBgj4+EhkOjjiIa4VLPwMvOAIGAQkBAQMJjQ8BAQ?= IronPort-HdrOrdr: A9a23:2/HnwqjpwYoJM4fMpG8IjEuYzHBQXlgji2hD6mlwRA09T+Wzna mV7Zcm/DXzjyscX2xlpMCYNMC7LU/02JZp7eAqXIuKcxLhvAKTRr1KzYyn+DH4Hj27y+g178 ddWoxzEsf5A1Q/rcuS2mSFOvIhxNXCz6yyn+fZyB5WIj1CUK1r4wdnBgvzKCQfLzVuPpY3GI GR4cBKvVObCBEqR/6mDXoIVfWrnbP2va/hCCR2ZSIP2U2rhTOs5KWSKWn94j4uFxVS3Lwl7W /J1yv+66nLiYDc9jbsk0nO8p9RhNztjuFmOfXJoM0UJjLw4zzYA7hcZw== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,274,1613433600"; d="asc'?scan'208";a="35736808" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 May 2021 09:27:52 +0000 Received: from smtpclient.apple ([10.61.144.32]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 1459RpKI032248 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 5 May 2021 09:27:52 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_01E6EF0E-9281-48AE-B4B2-D9FF53ADA1AD"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 5 May 2021 11:27:51 +0200 In-Reply-To: <5AF18B7B-3681-45BB-8D61-DAF0DCAB2732@ietf.org> Cc: rfced-future@iab.org To: Jay Daley References: <5AF18B7B-3681-45BB-8D61-DAF0DCAB2732@ietf.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.32, [10.61.144.32] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Suggestions for "RSEA Ongoing Performance Evaluation" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 09:28:03 -0000 --Apple-Mail=_01E6EF0E-9281-48AE-B4B2-D9FF53ADA1AD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Issue 55 for all of this. > On 4 May 2021, at 23:24, Jay Daley wrote: >=20 > I=E2=80=99ve reviewed 6.2 "RSEA Ongoing Performance Evaluation" of = draft-saintandre-rfced-model and I wonder if it is possible for a draft = recommendation from the IETF Executive Director to be presented to the = RSAB, excluding the RSEA, and an official view of the RSAB to be = included in the final recommendation to the LLC Board? >=20 > My concern here is that community feedback, while often of high = quality, may potentially be biased or incomplete and the RSAB is = probably best placed to take a view on that. >=20 > Also, I think it would be useful to note why this recommendation has = to go to the LLC Board rather than just being handled by the IETF = Executive Director, otherwise this document may inadvertently set a = precedent for other contracts. >=20 > Finally, I assume the feedback, summary of feedback and the = recommendation are confidential? If not then that should be clearly = stated. >=20 > Jay >=20 > -- > Jay Daley > IETF Executive Director > jay@ietf.org >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_01E6EF0E-9281-48AE-B4B2-D9FF53ADA1AD 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCSZRcACgkQh7ZrRtnS ejPR8Qf9HiVYdZf8uiqd5PHzu1Dvc5IU6nYDv8N5egyqyj32BIus7KggmZgiDPuW sZCsZO0wVRdcNG53UimXZE16dJ4qaZ4+fL8WFH3vhHDhw09uZU9rhfAAwGluwiBW 56YD0h8NHKWl/MOObhyvaBbxBE/029aCTQOa/cQf4hzH7p6VPrFWlOMOAw0y8+rV oM0Ds3uptcjtCqncu06HgQ29C7YxpZQOET+pMD2ytoehuDkvrs2neHJAb/FXOzS8 0zfqDQc/DlMHm/ZzgMyz371oG8WKgpJOXDURxatd5/Tm4uT70tsvpMtOx6fV99GZ l7YmIBdO++xqk8l4DULc8vS/wD6HEQ== =et77 -----END PGP SIGNATURE----- --Apple-Mail=_01E6EF0E-9281-48AE-B4B2-D9FF53ADA1AD-- From nobody Wed May 5 02:46: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 4D4A03A0A38 for ; Wed, 5 May 2021 02:45:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KO9XFOwHmSEG for ; Wed, 5 May 2021 02:45:55 -0700 (PDT) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 036CE3A0A35 for ; Wed, 5 May 2021 02:45:54 -0700 (PDT) Received: by mail-pf1-x42a.google.com with SMTP id q2so1526686pfh.13 for ; Wed, 05 May 2021 02:45:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=qyZARm5guaUxPGooyL4l375whFVZkSx23eiXFpRkyXs=; b=kemuZxcKeHpt0uvuflGvuBDZ8bPrzLtWlqBFO7E/0cbIg4Yxcah/da54p/Pz0GIGD0 s77fSVv3fE/VRm/oJvn6LpeioZDTacynLTMw/KAd35ndPz5M+GsvGgGstbrwsjtIvkF9 6nIKz/rp+rG9b7MmJyhUGSL/k+A16T8poborDU7ZDSkdPlFA66c6T4Oj6nAloHxuygFP wQGU5BTalFZrzNyBhJmh/gQsoCvqTC6HX+Vr+RAxBi3F7fZCjVl9/qQGQ3H61tAdbxAA SJvMYhsyEO82LZj+oT96twUKez4h0Bk5bzKOj8NL//6H/hQY6trt0FsgcIH6nWTnCHOD J12Q== 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=qyZARm5guaUxPGooyL4l375whFVZkSx23eiXFpRkyXs=; b=dZ+V1h5H6MFTusLvukug56KK+hx7tCPJ6+5OHZEUgkpvhOYMoOgFcY5RNA0g5NPyrq 5IfkBpfd1iWUv0/GhPLces1oGpiYNjMaT62aeirMrfZpnwa4wCXwDcfNn/4OwqlOpe+l cug0203JnlJDRuHDWAZicq0ZFCYjbrjUtsgXWku7UhlRV+DIHP60T0sCSIYTjidMAqK3 TL9YC0VpFgS33Mg9lY0sjx5j8s8zOQhOCV6/M0T0e2upR4a30RYJxLrmXa79dxiOnrjj 0seK0K+yysCtt6A4D0cxyqSbmtkMv5usV7OBwSqdStbvkyOasg4UFvmxCm1ZXtFVYeGd /EDw== X-Gm-Message-State: AOAM530YYRgjS2/SdKYlSW0l+gD/iDCND3wfvxLQbPU0r5wD0iimkp6n Lv0VEBBQhaNYKFXuO99RV3A= X-Google-Smtp-Source: ABdhPJxxIvaQmWVlIdcYZU6/dzCEL5WPeSw6LrDOueFAbY1Ptw4CfFyqOP4EFu2tqnQlxTtZKkUJ3w== X-Received: by 2002:a63:1465:: with SMTP id 37mr13431751pgu.113.1620207953556; Wed, 05 May 2021 02:45:53 -0700 (PDT) Received: from [192.168.8.102] (122-56-211-117.mobile.spark.co.nz. [122.56.211.117]) by smtp.gmail.com with ESMTPSA id 14sm15077682pfi.145.2021.05.05.02.45.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 02:45:52 -0700 (PDT) To: Eric Rescorla Cc: Michael StJohns , Eliot Lear , rfced-future@iab.org, Mirja Kuehlewind , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Russ Housley References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> From: Brian E Carpenter Message-ID: <10f2553c-0bfd-33e2-bb95-2fab370b96c6@gmail.com> Date: Wed, 5 May 2021 21:45:45 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 09:45:59 -0000 On 05-May-21 13:33, Eric Rescorla wrote: >=20 >=20 > On Tue, May 4, 2021 at 1:01 PM Brian E Carpenter > wrote: >=20 > On 05-May-21 03:36, Michael StJohns wrote: > > On 5/3/2021 10:05 PM, Brian E Carpenter wrote: > >>>>=C2=A0 =C2=A0 =C2=A0Further, the RSA is expected to ensure that=20 RSWG consensus is well > >>>>=C2=A0 =C2=A0 =C2=A0documented and communicated to the communit= y, the LLC, and the RPC. > >>>>=C2=A0 =C2=A0 =C2=A0This may include document authorship. > >>> Um... what?=C2=A0 This puts the RSA as a process facilitator fo= r the RSWG and > >>> gives them responsibilities to keep the record of the RSWG???=C2= =A0 That's > >>> new AFAICT.=C2=A0 The document authorship does not necessarily = imply the rest > >>> of this. > >> True. But given the lamentable and unpolished "minutes" that mos= t IETF > WGs > >> produce, which definitely don't satisfy RFC2418, I intended what=20 I wrote. > >> Obviously, that's open for discussion. > >> > > Um...=C2=A0 in what universe does "note taker and minute keeper" = equate > to "senior professional"?=C2=A0=C2=A0 There's also the fact that th= e note > taker in general is less able to participate in the discussion. >=20 > Yes. I didn't mean to specify that the RSA/E actually takes the not= es. But > somebody needs to make sure it gets done properly, and our experien= ce with > community volunteer WG chairs is that many of them don't get it don= e properly. > See any recent set of IETF Proceedings for examples. >=20 >=20 > I'm less sure than Brian that we need to significantly improve on minut= es quality, but if we have consensus on that, I agree=C2=A0 that we canno= t rely on volunteers. Admittedly, the final definitive word is not going to be the minutes, but=20 the approved documents. However, incomplete minutes lead to repeated disc= ussions of the same points. (That doesn't mean we need "he said/she said"=20 minutes. Just minutes that actually record the points agreed - even if on= ly by pointing to resolved issues in a tracker.) Brian >=20 > -Ekr >=20 >=20 > =C2=A0 =C2=A0Brian >=20 > > The fact that you're already projecting that the WG chairs will n= ot be able to run an adequate process does not to me suggest that we try = and fix that brokenness by laying trivial jobs on the RSE/A. > > > > Are we trying to sabotage the hiring process already? > > > > Later, Mike > > >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 From nobody Wed May 5 03:05: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 B34023A0BCB for ; Wed, 5 May 2021 03:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUPlPhPd7bdB for ; Wed, 5 May 2021 03:04:56 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FEB93A0BC9 for ; Wed, 5 May 2021 03:04:56 -0700 (PDT) Received: from p200300dee707b3000da85223f63540c6.dip0.t-ipconnect.de ([2003:de:e707:b300:da8:5223:f635:40c6]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1leEOX-0000z6-1s; Wed, 05 May 2021 12:04:41 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Mirja Kuehlewind In-Reply-To: <10f2553c-0bfd-33e2-bb95-2fab370b96c6@gmail.com> Date: Wed, 5 May 2021 12:04:39 +0200 Cc: Eric Rescorla , rfced-future@iab.org, Eliot Lear , Russ Housley , Michael StJohns , =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= Content-Transfer-Encoding: quoted-printable Message-Id: <5BB9BADD-EB2F-4A71-8B52-D4C47B0A7D6E@kuehlewind.net> References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> <10f2553c-0bfd-33e2-bb95-2fab370b96c6@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;1620209096;576badf4; X-HE-SMSGID: 1leEOX-0000z6-1s Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 10:05:02 -0000 See below. > On 5. May 2021, at 11:45, Brian E Carpenter = wrote: >=20 > On 05-May-21 13:33, Eric Rescorla wrote: >>=20 >>=20 >> On Tue, May 4, 2021 at 1:01 PM Brian E Carpenter = > = wrote: >>=20 >> On 05-May-21 03:36, Michael StJohns wrote: >>> On 5/3/2021 10:05 PM, Brian E Carpenter wrote: >>>>>> Further, the RSA is expected to ensure that=20 > RSWG consensus is well >>>>>> documented and communicated to the community, the LLC, and = the RPC. >>>>>> This may include document authorship. >>>>> Um... what? This puts the RSA as a process facilitator for the = RSWG and >>>>> gives them responsibilities to keep the record of the RSWG??? = That's >>>>> new AFAICT. The document authorship does not necessarily imply = the rest >>>>> of this. >>>> True. But given the lamentable and unpolished "minutes" that most = IETF >> WGs >>>> produce, which definitely don't satisfy RFC2418, I intended what=20 > I wrote. >>>> Obviously, that's open for discussion. >>>>=20 >>> Um... in what universe does "note taker and minute keeper" equate >> to "senior professional"? There's also the fact that the note >> taker in general is less able to participate in the discussion. >>=20 >> Yes. I didn't mean to specify that the RSA/E actually takes the = notes. But >> somebody needs to make sure it gets done properly, and our = experience with >> community volunteer WG chairs is that many of them don't get it = done properly. >> See any recent set of IETF Proceedings for examples. >>=20 >>=20 >> I'm less sure than Brian that we need to significantly improve on = minutes quality, but if we have consensus on that, I agree that we = cannot rely on volunteers. >=20 > Admittedly, the final definitive word is not going to be the minutes, = but=20 > the approved documents. However, incomplete minutes lead to repeated = discussions of the same points. (That doesn't mean we need "he said/she = said"=20 > minutes. Just minutes that actually record the points agreed - even if = only by pointing to resolved issues in a tracker.) I would say minutes are just a tool to ensure that the wg process is = clear and transparent, so definitely something for the chair to care = about. If we think professional/paid support for this group is important = that's something else to discuss but maybe we don=E2=80=99t need to = decide this now. However, in your proposed text you also write =E2=80=9Censure RSWG = consensus is [=E2=80=A6] communicated to the community=E2=80=9D. I = thought the RSWG is the way to communicate to/with the community. Or is = there anything else your had in mind? Mirja >=20 > Brian >=20 >>=20 >> -Ekr >>=20 >>=20 >> Brian >>=20 >>> The fact that you're already projecting that the WG chairs will not = be able to run an adequate process does not to me suggest that we try = and fix that brokenness by laying trivial jobs on the RSE/A. >>>=20 >>> Are we trying to sabotage the hiring process already? >>>=20 >>> Later, Mike >>>=20 >>=20 >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future = >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Wed May 5 07:58: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 A9CBA3A1067 for ; Wed, 5 May 2021 07:58:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jNKVLpRVS1qg for ; Wed, 5 May 2021 07:58:14 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E99113A1062 for ; Wed, 5 May 2021 07:58:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8455; q=dns/txt; s=iport; t=1620226694; x=1621436294; h=from:mime-version:subject:message-id:date:to; bh=yywZxY5Lc0hIXgYgrLEi7+benKoy4xOiVF8/KVUQRXk=; b=bsOBGrR6b6GOY21bycgaQ8HRQ9M2VrCBRfc4rUuPFYB9+GedrpCNWswU JFj8gUSGjVb3yxs7qHv/bMD9L0dBiL0CGJNUiore9Pno6iPIgSm5Lf5VO FYS332JMxJvsBEJ1K7rN3jo64DSaiVPWXIgW7200IqYvbmF5+SXX1Tv1R g=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BPAACmsZJglxbLJq1aGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAYIXgSOBf1YBJxKEdYkEiHOIAoxYiCUEBwEBAQoDAQEoDAQBAYZTJjgTA?= =?us-ascii?q?gQBAQEDAgMBAQEBAQUBAQECAQYEFAEBAQEBAQEBaIVQDYZufTYCP4MkAYMHD?= =?us-ascii?q?5l+jhZ6gTKBAYlQCgaBOoFThTIBhx2CC4EVJxyCXz6BBIFcAoItgko2gisEh?= =?us-ascii?q?AEgAk8CEi8cOApiHpB9jF+dGYMag0WBSYRrkzUFIoNUiw2WQo9FkWuTWgGEB?= =?us-ascii?q?gIEBgUCFoFrIYFbMxoIGxU7KgGCPz0SGQ6OKwsCCYNOil8/A2cCBgEJAQEDC?= =?us-ascii?q?Y0PAQE?= IronPort-HdrOrdr: A9a23:eayHRKrqNmYCR7KK7KsIygsaV5rCeYIsi2QD101hICF9WMqeis yogbAnxQb54Qx9ZFgMkc2NUZPgfVry7phwiLN6AZ6HUBP9sGWlaKFuhLGN/xTFGynzstFQzr 1hda8WMrHNJGN3h8r7/wW0euxIqLK62Zq1juTTxWoFd25XQpxnhj0YNi+rVml/RAxLHvMCZf mhz/sCgSa8cnIKacn+IX8JU4H41rj2vaOjRwIaDBg67wTLtxeU0frRFhiV2Qp2aUIs/Ysf X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,275,1613433600"; d="asc'?scan'208,217";a="35745208" 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; 05 May 2021 14:58:09 +0000 Received: from smtpclient.apple ([10.61.144.32]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 145Ew60l018746 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 5 May 2021 14:58:07 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_A595BCCF-6005-4FD5-A437-BAD38E071D14"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: <91C72E81-3CF8-40AF-9B59-89E4822A4B22@cisco.com> Date: Wed, 5 May 2021 16:58:06 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.32, [10.61.144.32] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] reminder: please post your issues on base text by 13 May X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 14:58:19 -0000 --Apple-Mail=_A595BCCF-6005-4FD5-A437-BAD38E071D14 Content-Type: multipart/alternative; boundary="Apple-Mail=_D5DE1801-A33F-4898-86B3-2B3E9B5E10F4" --Apple-Mail=_D5DE1801-A33F-4898-86B3-2B3E9B5E10F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As indicated in our minutes, this is when we said we wanted the first = tranche of issues posted. In particular, if you have a really big issue = against the base text and haven=E2=80=99t called it out, now is the = time. If you did post something, and I didn=E2=80=99t respond to you = with an issue number, please let me know (it=E2=80=99s possible I missed = a note). Here are the issues opened in the last month: #55 Suggestions for ongoing RS[EA] evaluation (Jay Daley) #54 When does the RSAB start its formal review? #53 Do new streams imply new RSAB members? #52 ultimate policy authority #51 Brian Carpenter comments #50 Can the RSAB do anything other than evaluate work from the WG? #49 RSEA response to feedback #48 Compisition of the search team #47 What is success? #46 Lars Eggert comments #45 When do the WG chairs call rough consensus and what happens next? #44 Anyone is welcome? #43 LLC and structure text #42 Adrian comments #41 How to select the RSWG chairs? #40 How to select the selection Committee? #39 LLC structure for new policies regarding RFC issues Discussion = Pending #38 Delegates for RSAB members #36 Appeals should be to the IAB not the ISOC BoT You can see the entire list here = . Eliot --Apple-Mail=_D5DE1801-A33F-4898-86B3-2B3E9B5E10F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As = indicated in our minutes, this is when we said we wanted the first = tranche of issues posted.  In particular, if you have a really big = issue against the base text and haven=E2=80=99t called it out, now is = the time.  If you did post something, and I didn=E2=80=99t respond = to you with an issue number, please let me know (it=E2=80=99s possible I = missed a note).  Here are the issues opened in the last month:

#55 Suggestions for ongoing RS[EA] = evaluation (Jay Daley)
#54 When does the RSAB start its formal = review?
#53 Do new streams imply new RSAB members?
#52 = ultimate policy authority
#51 Brian Carpenter = comments
#50 Can the RSAB do anything other than evaluate work from = the WG?
#49 RSEA response to feedback
#48 Compisition of the search = team
#47 What is success?
#46 Lars Eggert = comments
#45 When do the WG chairs call rough consensus and what = happens next?
#44 Anyone is welcome?
#43 LLC and structure = text
#42 Adrian comments
#41 How to select the RSWG = chairs?
#40 How to select the selection Committee?
#39 LLC = structure for new policies regarding RFC issues Discussion = Pending
#38 Delegates for RSAB members
#36 = Appeals should be to the IAB not the ISOC BoT

You can = see the entire list here.

Eliot
= --Apple-Mail=_D5DE1801-A33F-4898-86B3-2B3E9B5E10F4-- --Apple-Mail=_A595BCCF-6005-4FD5-A437-BAD38E071D14 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCSsn4ACgkQh7ZrRtnS ejMpmAgA0GcYQLoLppXdlp6TLfiKubc+w4xvvEaSLawkjCubPhPJ3SmHiTzNMM9q Wl4GMW9xUXV6A9xEwapHMWPVjze0dt8T+gcKlw4XSILMOEGmnBAbFh+7976Nz+If RjniAc+yXlSgqmBc8nIyzncKSa1Mq4Dg602v7+G2eXGgCDYWaollI1GmK8MEfY9u bbqe1MLzmRf4/zi4wnIC9uyFW4nfYO4e+0/eNtrWSdwrsDwFD7MaHIMHnqMGrGQi tF6AoMX6UtmPVtAVslOeSDt6RGkP7OuT6gTTMzIRuzlvXYt7m0OZh9HS+XunUXYu KKogD1ogTF5t5g+R/X6QHvwwVQBa9g== =1nOX -----END PGP SIGNATURE----- --Apple-Mail=_A595BCCF-6005-4FD5-A437-BAD38E071D14-- From nobody Wed May 5 13:32: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 4026D3A201E for ; Wed, 5 May 2021 13:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTwsdWMlB622 for ; Wed, 5 May 2021 13:32:15 -0700 (PDT) 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 F27A33A2010 for ; Wed, 5 May 2021 13:32:14 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id e15so2834678pfv.10 for ; Wed, 05 May 2021 13:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=IbgNycDrlBnp4gBoJ+OFQ83/aWCgmRZCFjodFDrsaFU=; b=rZUa3OOy5VT+Ut/kQrCPUTGdffvhZNvk7Hye03LEqYCPH8GEhILOlRtjSrq65m1oE7 e9p/YKYipy8DKtSXquVgBK9yvLtdPzqXs6j6ZU51aMrmcT2az0BG7VoasQiYuwV01b+5 WaQSYYPv9pTxF5Hf+/YDN6SKYNE/xSQLKfkcQkR3pMu3DXcZgPhYcwHnPfrpFjvJgtos BBI0lz4WOHP0D+UtQFt5BISmkdrY+KzbX2fbHfOHDryNPzrHjNHWmRR6PZtJF1q2v5vF U1mErnFrTtQGJo71IyCYSuNI2shjHu86ZV99Ne7duQxnEzfWejNttcPdgd+nO0Lnj5FM pjpA== 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=IbgNycDrlBnp4gBoJ+OFQ83/aWCgmRZCFjodFDrsaFU=; b=FjP4kqNJwQdMEaIaO02x/NgPTJfDcEvxQqgt39MJ6XsfVSy6QD71cY/fH3oseZgOOn lMlRa0zyrqtJ/Z+CDKQUu/EBtWRfsrBdWRzWFbT9ArTi9VFJ7gRqQV0oEGVyqVxHkcaf jOwImmM41TJQh2C6AMpQIMfoKzJC36GK6fixUpIKwRGBpz+RBfXad11fXJPL2TToNJbp 02q1AdNreSiiBkvghRmFo7AbDQVQYpn5SMmXXhUX18wjiPeeCm1sPD1hYEbCC7ST/ud7 Qo3ZVvR4n4fArNor+nSidBYeZMLlXkJ+deIHSbKESD3O7ytoVKZlqeW2VqCF57rRPtLA gY1g== X-Gm-Message-State: AOAM533NysSZ6o8o009nf2t3kC9ecQQHXrhPch61qe/6ZqXQvwpYHCIL 7YUNYvkG/YDLejA+zuHug8M= X-Google-Smtp-Source: ABdhPJxtZ24n9OgelWUDipndclP6qLB7ZHw4Ln1QJb1Ld+Spw+eE43JdtKXPKbuwXHUNhd98y9cVUQ== X-Received: by 2002:a62:31c4:0:b029:28d:1ad0:340c with SMTP id x187-20020a6231c40000b029028d1ad0340cmr772695pfx.35.1620246733198; Wed, 05 May 2021 13:32:13 -0700 (PDT) Received: from [192.168.8.102] (122-56-211-117.mobile.spark.co.nz. [122.56.211.117]) by smtp.gmail.com with ESMTPSA id x26sm101693pfm.134.2021.05.05.13.32.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 13:32:12 -0700 (PDT) To: Mirja Kuehlewind Cc: Eric Rescorla , rfced-future@iab.org, Eliot Lear , Russ Housley , Michael StJohns , =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= References: <4f644ce8-3fba-6a03-875a-c172bccd1eb7@nthpermutation.com> <5C16D27D-15FD-47EA-9507-39E3888714A3@vigilsec.com> <26677ddc-2557-b1ab-1889-8f8815fd0118@nthpermutation.com> <7EE2377B-9A04-4ADD-BA62-FD9A1EF6226E@kuehlewind.net> <982A13BE-708F-4174-94F1-910E5F174C24@cisco.com> <0a45438a-8f9a-f875-5379-9ea366af563a@gmail.com> <211f9f56-d646-606e-8a02-eb194af64f3c@gmail.com> <995ebf2e-c46e-3184-df39-aa2ccc45047e@nthpermutation.com> <10f2553c-0bfd-33e2-bb95-2fab370b96c6@gmail.com> <5BB9BADD-EB2F-4A71-8B52-D4C47B0A7D6E@kuehlewind.net> From: Brian E Carpenter Message-ID: <329ade04-9375-b63f-b61a-d6bf79c32d6b@gmail.com> Date: Thu, 6 May 2021 08:32:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5BB9BADD-EB2F-4A71-8B52-D4C47B0A7D6E@kuehlewind.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] draft-saintandre-rfced-model msj3 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 05 May 2021 20:32:19 -0000 Below... On 05-May-21 22:04, Mirja Kuehlewind wrote: > See below. >=20 >> On 5. May 2021, at 11:45, Brian E Carpenter wrote: >> >> On 05-May-21 13:33, Eric Rescorla wrote: >>> >>> >>> On Tue, May 4, 2021 at 1:01 PM Brian E Carpenter > wrote: >>> >>> On 05-May-21 03:36, Michael StJohns wrote: >>>> On 5/3/2021 10:05 PM, Brian E Carpenter wrote: >>>>>>> Further, the RSA is expected to ensure that=20 >> RSWG consensus is well >>>>>>> documented and communicated to the community, the LLC, and t= he RPC. >>>>>>> This may include document authorship. >>>>>> Um... what? This puts the RSA as a process facilitator for the RS= WG and >>>>>> gives them responsibilities to keep the record of the RSWG??? Tha= t's >>>>>> new AFAICT. The document authorship does not necessarily imply th= e rest >>>>>> of this. >>>>> True. But given the lamentable and unpolished "minutes" that most I= ETF >>> WGs >>>>> produce, which definitely don't satisfy RFC2418, I intended what=20 >> I wrote. >>>>> Obviously, that's open for discussion. >>>>> >>>> Um... in what universe does "note taker and minute keeper" equate >>> to "senior professional"? There's also the fact that the note >>> taker in general is less able to participate in the discussion. >>> >>> Yes. I didn't mean to specify that the RSA/E actually takes the no= tes. But >>> somebody needs to make sure it gets done properly, and our experie= nce with >>> community volunteer WG chairs is that many of them don't get it do= ne properly. >>> See any recent set of IETF Proceedings for examples. >>> >>> >>> I'm less sure than Brian that we need to significantly improve on min= utes quality, but if we have consensus on that, I agree that we cannot r= ely on volunteers. >> >> Admittedly, the final definitive word is not going to be the minutes, = but=20 >> the approved documents. However, incomplete minutes lead to repeated d= iscussions of the same points. (That doesn't mean we need "he said/she sa= id"=20 >> minutes. Just minutes that actually record the points agreed - even if=20 only by pointing to resolved issues in a tracker.) [Off topic: I recently updated my mail UA and it's been doing funny stuff=20 with line wrapping, sorry about the visual confusion.] =20 > I would say minutes are just a tool to ensure that the wg process is cl= ear and transparent, so definitely something for the chair to care about.=20 If we think professional/paid support for this group is important that's = something else to discuss but maybe we don=E2=80=99t need to decide this = now. I think we do need to state that this should be provided by the LLC if ne= eded. > However, in your proposed text you also write =E2=80=9Censure RSWG cons= ensus is [=E2=80=A6] communicated to the community=E2=80=9D. I thought th= e RSWG is the way to communicate to/with the community. Or is there anyth= ing else your had in mind? Well, it may seem obvious and unnecessary to mention, but I was thinking = about how decisions are announced to, e.g., RFC-interest; should there be=20 an RFC Editor blog, and questions like that. We want to reach thousands o= f people, not just the ones who choose to join the RSWG list. Who is goin= g to think about such things if the RSA/E doesn't? Brian >=20 > Mirja >=20 >=20 >=20 >> >> Brian >> >>> >>> -Ekr >>> >>> >>> Brian >>> >>>> The fact that you're already projecting that the WG chairs will not = be able to run an adequate process does not to me suggest that we try and=20 fix that brokenness by laying trivial jobs on the RSE/A. >>>> >>>> Are we trying to sabotage the hiring process already? >>>> >>>> Later, Mike >>>> >>> >>> --=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 Wed May 5 17:39:30 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7193E3A2859 for ; Wed, 5 May 2021 17:39:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mGEt4h4F_DTE for ; Wed, 5 May 2021 17:39:28 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 8237A3A2857 for ; Wed, 5 May 2021 17:39:27 -0700 (PDT) From: Jay Daley Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Message-Id: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> Date: Thu, 6 May 2021 12:39:23 +1200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: [Rfced-future] Issues with draft-saintandre-rfced-model raised in discussion with the RPC X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2021 00:39:29 -0000 I discussed draft-saintandre-rfced-model with the RPC and we identified = the following issues, which I have added to GitHub: Issue #56: The RSWG/RSAB process is clear for larger projects but the = RPC also need a path for discussion and agreement on smaller things that = do not require a consensus process. Previously the RPC would discuss = and agree these with the RSE, with the RSE taking the decision on what = meets the threshold for taking to the community. How are those agreed = now and who decides what does and does not need community = consensus/engagement? Issue #57: The RPC has a wide set of projects to deliver with limited = resources and decisions have to be made on priorities. Previously this = was negotiated between the RSE and RPC with the RSE having an = understanding of community priorities. How are the priorities set now? Issue #58: Will the RPC be able to continue to make smaller updates to = the online portion of the style guide and various lists as they do now? Issue #59: It=E2=80=99s not clear who mediates disputes between the RPC = and Authors? Issue #60: Disputes between the RPC and authors sometimes need = escalating and in the proposed process the stream manager appears to be = the escalation point. However, if the dispute is about something that = affects all the streams, such as RFC style/policies, then it appears = that this has to be escalated to the RSAB. Is that correct and will the = RSAB be able to respond in a timely manner? Issue #61: Traditionally, the RSE has acted as the eyes and ears of the = RPC, sharing insight and feedback about what they=E2=80=99re hearing = from the community. There are multiple times when the RSE brought = community requirements to the RPC that the RPC were unaware of. Is the = RPC now required to do that directly or is that the responsibility of = the RSWG/RSAB or do we assume that any requirements that are not brought = to the RSWG are to be left unmet? Issues #62: It is not clear who would communicate decisions about RPC = projects/priorities to the community. Jay --=20 Jay Daley IETF Executive Director jay@ietf.org From nobody Wed May 5 21:18: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 1F8CE3A2F87 for ; Wed, 5 May 2021 21:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF9mtGzMMpW8 for ; Wed, 5 May 2021 21:18:46 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D8E23A2F8C for ; Wed, 5 May 2021 21:18:46 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id y2so2728229plr.5 for ; Wed, 05 May 2021 21:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=FdT0IDG1atHmjuJO7dAqU7MG+5Dhr8uo+AikT1rST0Q=; b=Ol0saeHeQIoYhefe5rwWtn/BCdu0c6w9+2cvAxS1L+A5ynYu/Y5o3AGk3UmG5I5vXB vHcAIgqBJAFfaUzHuKFhkE84mTU1S07F7uC8spUG5Cw3Unyot2nsBnNRvUs5yoOxStxg KEJo6/ougV+ulmV+Cv5e4p9uT01c5AvMeHtFiToywhuKxpFmsvhuEVRM20oFDTp9Rb3u wq97fn9+MBkF7jbF7/+BB7p16aS3ZUG/ckclNFZZpbpvlfzhoiyZwWORLfb9ULaNi2Ep KyZphDZnsEkkDj0Sb8XCGeqWO9YKdpUQvid2FK9UJsjMoBhyKTxRXmjp2boUVyqT5xUp vcRw== 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=FdT0IDG1atHmjuJO7dAqU7MG+5Dhr8uo+AikT1rST0Q=; b=Tn31ofcbQkCNdYoFX39qAy0QEjr9Qvz4p3kOiW4xOOkSocVehUHcmcnIPzktcJqkcz JkFMRbWtTUmA8zEoCwG1iKFlWBgGgihcWQxDZDa6rk4042EiEHU0XbelPt4K8SSr7BTG 87RmvCPnRJYnsFilXG/f4SnBNYDWZZgWyAoDHTJc/h4537o8rKzerr8p+8fcA6KAHmDo S6bj+00Vz1NBgVWAXlW3qAtSEtkanDH6qRT/cvEOjGLfl264vy+Jv5PzpXvC0NpEJVXt eVyN0+wwGiFngDPo/RgNJlyW0X9HCK83zdfenlAsWJY4JuzwiL34R/NitGNi9SJi/ilQ NWBg== X-Gm-Message-State: AOAM530XcLwwykxQay3hl/nVtwBj64ChtQ9RzdFpG4ztlOJUXSbYW0Um ByxP0IX8dcaX/onuXncpBu6Dj4FLQnU= X-Google-Smtp-Source: ABdhPJzjDo6xpgafcv6uIJAt50zXaZNTz+R2eTTIMIs7lJ2jio4S2lgK2ZdfZbgpMEFFzVPgCjgJYg== X-Received: by 2002:a17:902:e84f:b029:ee:cd36:80e3 with SMTP id t15-20020a170902e84fb02900eecd3680e3mr2604956plg.70.1620274724838; Wed, 05 May 2021 21:18:44 -0700 (PDT) Received: from [192.168.8.102] (122-56-209-1.mobile.spark.co.nz. [122.56.209.1]) by smtp.gmail.com with ESMTPSA id n8sm693487pfu.111.2021.05.05.21.18.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 05 May 2021 21:18:44 -0700 (PDT) To: Jay Daley , rfced-future@iab.org References: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> From: Brian E Carpenter Message-ID: Date: Thu, 6 May 2021 16:18:39 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issues with draft-saintandre-rfced-model raised in discussion with the RPC X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2021 04:18:49 -0000 Thanks for that, a very useful dose of reality IMHO. Personally I'd write most of these into the role description for the RSAE= =2E Three specific comments in line below: On 06-May-21 12:39, Jay Daley wrote: > I discussed draft-saintandre-rfced-model with the RPC and we identified=20 the following issues, which I have added to GitHub: >=20 >=20 > Issue #56: The RSWG/RSAB process is clear for larger projects but the = RPC also need a path for discussion and agreement on smaller things that = do not require a consensus process. Previously the RPC would discuss and=20 agree these with the RSE, with the RSE taking the decision on what meets = the threshold for taking to the community. How are those agreed now and = who decides what does and does not need community consensus/engagement? >=20 > Issue #57: The RPC has a wide set of projects to deliver with limited = resources and decisions have to be made on priorities. Previously this w= as negotiated between the RSE and RPC with the RSE having an understandin= g of community priorities. How are the priorities set now? I think the decision path has to be the RSWG/RSAB, but this is a typical = area where I'd expect the RSAE to make proactive proposals and facilitate=20 the discussion. (Reasoning: priorities within limited resources really do=20 need to reflect what the community wants.) =20 > Issue #58: Will the RPC be able to continue to make smaller updates to=20 the online portion of the style guide and various lists as they do now? I certainly hope that the answer is yes. =20 > Issue #59: It=E2=80=99s not clear who mediates disputes between the RP= C and Authors? >=20 > Issue #60: Disputes between the RPC and authors sometimes need escalat= ing and in the proposed process the stream manager appears to be the esca= lation point. However, if the dispute is about something that affects al= l the streams, such as RFC style/policies, then it appears that this has = to be escalated to the RSAB. Is that correct and will the RSAB be able t= o respond in a timely manner? This is another area where I'd expect the RSAE to be proactive and facili= tate discussion. Brian C > Issue #61: Traditionally, the RSE has acted as the eyes and ears of th= e RPC, sharing insight and feedback about what they=E2=80=99re hearing fr= om the community. There are multiple times when the RSE brought communit= y requirements to the RPC that the RPC were unaware of. Is the RPC now r= equired to do that directly or is that the responsibility of the RSWG/RSA= B or do we assume that any requirements that are not brought to the RSWG = are to be left unmet? >=20 > Issues #62: It is not clear who would communicate decisions about RPC = projects/priorities to the community. >=20 >=20 > Jay >=20 From nobody Thu May 6 00:53: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 D0B7D3A169C for ; Thu, 6 May 2021 00:53:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 nwgjGm9LGVqj for ; Thu, 6 May 2021 00:53:19 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E658D3A169B for ; Thu, 6 May 2021 00:53:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3573; q=dns/txt; s=iport; t=1620287599; x=1621497199; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=SZCp8n6noxuvGNxnz5oFrg1MS5XqBHJ0F4PJAJoe1Oc=; b=E0cy6IUxkEtVk2epbcG6Z7QYmaz98JcOq5JbKB9DSmEQ32o5bClxSrpO CVl6AX6UVcn1CnGUm4MpEV3qx66wk6ctaSc5PIkfI8ITq1ISNnXYHO8ep iyzkOkOS5+/a6BT7sqDzxnSbnmxiDuuPBfvrwEWlRGJilvdYeIFT6SSZF s=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AHAAAHn5Ng/xbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGCBQIBAQEBAQsBgXUGgSZWAScSMYREiQSIcwObA4F8B?= =?us-ascii?q?AcBAQEKAwEBHQsMBAEBhFACggEmNgcOAgQBAQEDAgMBAQEBAQUBAQECAQYEc?= =?us-ascii?q?ROFUA2GRAEBAQMBAQEhSwsFCwsMDCoCAicWGgYTFIJdAYJmIQ+ndnqBMoEBh?= =?us-ascii?q?GOEcwoGgToBgVKMDEOCC4EVJxyCXz6CYAGBOINANoIrBIFlAYEOOlMgAi0MI?= =?us-ascii?q?BU8NgEFnmadHYMbg0mBSZghBSOlJrUMAYQHAgQGBQIWgVsCMYFZMxoIGxU7K?= =?us-ascii?q?gGCPj4SGQ6OVm0BA4dchUs/Ay84AgYBCQEBAwmKSYJGAQE?= IronPort-HdrOrdr: A9a23:MX8Lh6i9SicEbUG0swHJHqMNTHBQXt8ji2hC6mlwRA09TyVXrb HMoB1773PJYVkqOU3I9errBEDEexPhHOBOjLX5TI3MYOCOggLBR72Kr7GSpgEIcBeRygcy79 YDT0EHMqyVMbC/5vyKhjVR1L0bsb66zJw= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,277,1613433600"; d="asc'?scan'208";a="33336941" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 May 2021 07:53:16 +0000 Received: from smtpclient.apple ([10.61.144.32]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 1467rDqF025491 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 6 May 2021 07:53:14 GMT From: Eliot Lear Message-Id: <0FFEFF60-AA50-4A12-BE68-FC2B4FD110B8@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_D0DB312C-7261-4B97-81FD-33A0C9ADA421"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Thu, 6 May 2021 09:53:13 +0200 In-Reply-To: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> Cc: rfced-future@iab.org To: Jay Daley References: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.32, [10.61.144.32] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Issues with draft-saintandre-rfced-model raised in discussion with the RPC X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2021 07:53:25 -0000 --Apple-Mail=_D0DB312C-7261-4B97-81FD-33A0C9ADA421 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Jay, Thank you for these contributions. May I ask that people discuss them = in individual threads so as to make it easier for us to track progress? Eliot > On 6 May 2021, at 02:39, Jay Daley wrote: >=20 > I discussed draft-saintandre-rfced-model with the RPC and we = identified the following issues, which I have added to GitHub: >=20 >=20 > Issue #56: The RSWG/RSAB process is clear for larger projects but the = RPC also need a path for discussion and agreement on smaller things that = do not require a consensus process. Previously the RPC would discuss = and agree these with the RSE, with the RSE taking the decision on what = meets the threshold for taking to the community. How are those agreed = now and who decides what does and does not need community = consensus/engagement? >=20 > Issue #57: The RPC has a wide set of projects to deliver with limited = resources and decisions have to be made on priorities. Previously this = was negotiated between the RSE and RPC with the RSE having an = understanding of community priorities. How are the priorities set now? >=20 > Issue #58: Will the RPC be able to continue to make smaller updates = to the online portion of the style guide and various lists as they do = now? >=20 > Issue #59: It=E2=80=99s not clear who mediates disputes between the = RPC and Authors? >=20 > Issue #60: Disputes between the RPC and authors sometimes need = escalating and in the proposed process the stream manager appears to be = the escalation point. However, if the dispute is about something that = affects all the streams, such as RFC style/policies, then it appears = that this has to be escalated to the RSAB. Is that correct and will the = RSAB be able to respond in a timely manner? >=20 > Issue #61: Traditionally, the RSE has acted as the eyes and ears of = the RPC, sharing insight and feedback about what they=E2=80=99re hearing = from the community. There are multiple times when the RSE brought = community requirements to the RPC that the RPC were unaware of. Is the = RPC now required to do that directly or is that the responsibility of = the RSWG/RSAB or do we assume that any requirements that are not brought = to the RSWG are to be left unmet? >=20 > Issues #62: It is not clear who would communicate decisions about RPC = projects/priorities to the community. >=20 >=20 > Jay >=20 > -- > Jay Daley > IETF Executive Director > jay@ietf.org >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_D0DB312C-7261-4B97-81FD-33A0C9ADA421 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCToGkACgkQh7ZrRtnS ejM3dgf+J1QLVyNKB7TBmQeidnb5oqwamTUQ1lLvHS0inz7q4JaJ/pLMkqFmabf2 Mo+nzi9+g7/ph0jT82DwY9dmOxqouv7DC5a2MEv5gtsw3/RF0LOqrBCDY1EK0WXT D+dJKJbuYx7cEVMnY5BBwaVMGrvZSx8SDK/iVE+rqi3J4Qz9MpiYLWIRcY6t+Pev Drxh8pKaABnzyw42Youm16tP/xWYVm8WxWHIUWoomWcu75Kffxy7iB9Ji3xZA3cT 5hsZQ5Q06AWfGBesltkV2CvQRE9xhsVPcpLpCCZ7t1uMl73iPW1KEv+cL9NoNy7h O0vKeGOIEwUIvg7T9niYWyjEwPCGSA== =K8ge -----END PGP SIGNATURE----- --Apple-Mail=_D0DB312C-7261-4B97-81FD-33A0C9ADA421-- From nobody Thu May 6 01:13: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 1F22F3A175B for ; Thu, 6 May 2021 01:13:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.899 X-Spam-Level: X-Spam-Status: No, score=-11.899 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_MED=-2.3, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s1Y1xMCreQtC for ; Thu, 6 May 2021 01:12:55 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1CCF3A1759 for ; Thu, 6 May 2021 01:12:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2940; q=dns/txt; s=iport; t=1620288775; x=1621498375; h=from:mime-version:subject:message-id:date:to; bh=BCt1pRakNSIs+YIP1ZJCEikWKAZz18X4QrrGsKP2IAU=; b=PLDJiTgQ/wPDAQXosqkV5hiL8Je0ONE17ET6WJvxvwCE5/ZLx46T+od8 /IMZmFCYO8xpx0KctvNH5r4EVDhC1IZnYLBRHw2ZwFOY+yD3+jU6U5kGL X9DF1+OB0tGF6d0ZMG9UpJVyoT1c++8v5HQWE3IB3XzPLfo8LVYe8OVfr 8=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AHAADRo5NglxbLJq1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBggYCAQEBAQsBg3cBJxKEdYkEiHKdAgQHAQEBCgMBATQEAQGGU?= =?us-ascii?q?yY3Bg4CBAEBAQMCAwEBAQEBBQEBAQIBBgQUAQEBAQEBAQFohV2GRgQkWyI2A?= =?us-ascii?q?j9Hgl0BgmYhmWaOFnqBMoEBiVcQgToBgVKMT4ILgRUnHIIwbYUPgko2gisEg?= =?us-ascii?q?WUBgQhAOzgCO1IbAjYDYA+dep0dgxuDSYFJmCEFI6UmtQwBhAcCBAYFAhaBa?= =?us-ascii?q?iKBWzMaCBsVZQGCPz0SGQ6OOI42PwNnAgYBCQEBAwmNDwEB?= IronPort-HdrOrdr: A9a23:G0PhQqCwJfxn2/3lHem/55DYdb4zR+YMi2TDtnoddfU7SK2lfq yV9sjzqyWbtN9hYh0dcLm7UcHqfZq2z/FICOcqXYtKJDOW21dB6OpZnO7fK/qKIVydytJg X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,277,1613433600"; d="asc'?scan'208";a="35770644" 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; 06 May 2021 08:12:52 +0000 Received: from smtpclient.apple ([10.61.144.32]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 1468CqOr022243 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 May 2021 08:12:52 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_DD236F33-A630-4750-AFD9-FA8AE023E77E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: <9EC506B1-732B-46EA-A77B-0E233C544149@cisco.com> Date: Thu, 6 May 2021 10:12:51 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.32, [10.61.144.32] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Issue 56: Process for RPC work not requiring consensus X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2021 08:13:00 -0000 --Apple-Mail=_DD236F33-A630-4750-AFD9-FA8AE023E77E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi there, > Issue #56: The RSWG/RSAB process is clear for larger projects but the = RPC also need a path for discussion and agreement on smaller things that = do not require a consensus process. Previously the RPC would discuss = and agree these with the RSE, with the RSE taking the decision on what = meets the threshold for taking to the community. How are those agreed = now and who decides what does and does not need community = consensus/engagement? With regard to this issue, as well as 57, 58, and 59, these seem to = articulate a point that was raised in Issue 23 (=E2=80=9CWhat is = strategic?=E2=80=9D). What I propose to do is to close 23 in favor of = us using your pragmatic issues. But we should maintain the context of thinking around that issue. I = believe the intent of the WG at this point was for the overarching = policy and procedure to be set by the RFGWG, but for the implementation = of that policy to rest entirely with the RPC. While the RPC should be = free and even be encouraged to consult the RS[EA], the decision is with = the RPC. It is not a negotiation. This is my understanding of the = group view, based on previous discussions. While I don=E2=80=99t = believe we=E2=80=99ve discussed this explicitly, it seems reasonable for = the RPC to periodically report on those activities to the RFCWG. There will occasionally be ambiguities. Here, I believe the group=E2=80=99= s view is one of =E2=80=9Cbetter to ask forgiveness than permission=E2=80=9D= in those circumstances. That is- the RPC is empowered to act, but then = should report the ambiguity to the RFCWG, as the RFCWG process is = expected to be rather laborious. Again, consultation with the RS[EA] = encouraged. Is my understanding of people=E2=80=99s views here off? I believe the = text in draft-saintandre-rfced-model is consistent with this position, = but could do with a tad more elaboration along these lines. Eliot --Apple-Mail=_DD236F33-A630-4750-AFD9-FA8AE023E77E 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCTpQMACgkQh7ZrRtnS ejN8vwf9EwBaiqbkcbfNooeer8fN/b4qbgEl1GJ6HeTJCDHiqTHRZFRU8Yphi5YQ S/Z7oqhsHDePxe68muA5EDEkKbiF6kQQUwKlnRaecBNyyi5f6PkLgJQEO7PUZNpC hIHk1pVZlkiXKGA9QgGyQDR8uo2cD3bVOOcxqxvdKQTwhnGoHnJg5TtvFpNpAE0u /nSXgU2hTiNeWDZtl2YIKF8UY4UAXZi1G87I/v3qYc5GXbdAoERRu401GSSmnv0q iAbxvFkQ3ZquFJL2oBCIra1cJhTU2Smxsu0doY8T8XtwksJLI4x/euI6dvdM4R+6 3hWargqddFzh6LPGbdyErY6A97lEAA== =Git0 -----END PGP SIGNATURE----- --Apple-Mail=_DD236F33-A630-4750-AFD9-FA8AE023E77E-- From nobody Thu May 6 05:36: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 3BBC23A20BF for ; Thu, 6 May 2021 05:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.121 X-Spam-Level: X-Spam-Status: No, score=-2.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=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 8__Ie_8IcidD for ; Thu, 6 May 2021 05:36:17 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C80483A20BC for ; Thu, 6 May 2021 05:36:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4FbY3P0JbCz1nsSM; Thu, 6 May 2021 05:36:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1620304577; bh=dVCtOeoi0bCl/LAomyUugXocVCLTMwc+pKNz8nZh8/c=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MO2A0Q+LWzfRnHVL93ZzOdg3FV6iLVAhpjegE19Eh5/bR4QRA034CDUblWGly8Kux BvStRomSwjqe3LuZsd70YXGBEalO8FlLBCzbjLCFBIu60dGvyHoL9FUTxSumDsUWek bY9+G16y4OnMmqDGSWQuz8AewIKbMS6uakpGlFhg= X-Quarantine-ID: <8RYqvxjYOdyx> X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4FbY3N3jR8z1nsNM; Thu, 6 May 2021 05:36:16 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org References: <9EC506B1-732B-46EA-A77B-0E233C544149@cisco.com> From: "Joel M. Halpern" Message-ID: <917fa742-904d-9fae-ed92-5722c25b98b8@joelhalpern.com> Date: Thu, 6 May 2021 08:36:14 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <9EC506B1-732B-46EA-A77B-0E233C544149@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 56: Process for RPC work not requiring consensus X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2021 12:36:22 -0000 As I understand our discussion, what you describe below about the RPC just taking care of things is what some people had proposed or expected. Others (including myself) were quite concerned about the change in role of the RPC, and wondered if that was a good idea, and whether it would work for the RPC. From the questions they are asking, they have their doubts. Yours, Joel On 5/6/2021 4:12 AM, Eliot Lear wrote: > Hi there, > >> Issue #56: The RSWG/RSAB process is clear for larger projects but the RPC also need a path for discussion and agreement on smaller things that do not require a consensus process. Previously the RPC would discuss and agree these with the RSE, with the RSE taking the decision on what meets the threshold for taking to the community. How are those agreed now and who decides what does and does not need community consensus/engagement? > > > With regard to this issue, as well as 57, 58, and 59, these seem to articulate a point that was raised in Issue 23 (“What is strategic?”). What I propose to do is to close 23 in favor of us using your pragmatic issues. > > But we should maintain the context of thinking around that issue. I believe the intent of the WG at this point was for the overarching policy and procedure to be set by the RFGWG, but for the implementation of that policy to rest entirely with the RPC. While the RPC should be free and even be encouraged to consult the RS[EA], the decision is with the RPC. It is not a negotiation. This is my understanding of the group view, based on previous discussions. While I don’t believe we’ve discussed this explicitly, it seems reasonable for the RPC to periodically report on those activities to the RFCWG. > > There will occasionally be ambiguities. Here, I believe the group’s view is one of “better to ask forgiveness than permission” in those circumstances. That is- the RPC is empowered to act, but then should report the ambiguity to the RFCWG, as the RFCWG process is expected to be rather laborious. Again, consultation with the RS[EA] encouraged. > > Is my understanding of people’s views here off? I believe the text in draft-saintandre-rfced-model is consistent with this position, but could do with a tad more elaboration along these lines. > > Eliot > > From nobody Thu May 6 10:27:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CDC3A29F2 for ; Thu, 6 May 2021 10:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u315DL_96oag for ; Thu, 6 May 2021 10:27:03 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 284C03A29F1 for ; Thu, 6 May 2021 10:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1484; q=dns/txt; s=iport; t=1620322023; x=1621531623; h=from:mime-version:subject:message-id:date:to; bh=8qm+nERPzbCQPbKMwAVm+9ob/1RuJVRFrH3q/T9lp5k=; b=DVqB03GVf7QDioNeXEpWFjatPCA5JoTh+lVKOyoRnk7V0pMWhYvrIOP0 bCFWgd3Jk6/N6XIHcqSPTQFj/gzIUBwOO8yIjysoUHQDu7jdvreEJ5pmd my4cHl/KatQMm9eDyuzTtO49kwoAoaYPctqeRz5iJnt8XjsseIo4MNwzN k=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AbAAClJZRglxbLJq1aHAEBAQEBAQcBARIBAQQEAQFAg?= =?us-ascii?q?UUFAQELAYN3ATmNeaN4FIFoBAcBAQEKAwEBNAQBAYZWJjYHDgIEAQEBAwIDA?= =?us-ascii?q?QEBAQEFAQEBAgEGBBQBAQEBAQEBAWiFXYdrd4MkAYMHmgGOFniBNIEBiVUQg?= =?us-ascii?q?ToBgVKMT4ILgTwMEIMdgQSDBIEHgwCCKwSEIUagCJ0dgxsEg0WBSZghBSODQ?= =?us-ascii?q?hKLD5ZDhkuuQQGEBwIEBgUCFoFbDiOBWzMaCBsVOyoBgj89EhkOjjYCjjY/A?= =?us-ascii?q?2cCBgoBAQMJjQ8BAQ?= IronPort-HdrOrdr: A9a23:U9qM7q3Rp/UJ3mMY5gHgEQqjBKEkLtp133Aq2lEZdPU1SKGlfq +V/cjzuSWftN9uYh8dcKG7VJVoKEm0nfVICOIqUotKMjOHhILRFvAA0WMnqAeQfhEXMYVmpM VdT5Q= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,278,1613433600"; d="asc'?scan'208";a="35724832" 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; 06 May 2021 17:26:58 +0000 Received: from smtpclient.apple ([10.61.144.52]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 146HQwow008482 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 6 May 2021 17:26:58 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_8C7379A4-6542-4130-8EA3-4EB425D33E0E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: <120055FB-4542-444F-AAFB-5DE4023ACDFD@cisco.com> Date: Thu, 6 May 2021 19:26:57 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.52, [10.61.144.52] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] Next interim: 25 May 2021 @ 10:00am GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 06 May 2021 17:27:08 -0000 --Apple-Mail=_8C7379A4-6542-4130-8EA3-4EB425D33E0E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Colleagues, Based on the doodle, our next meeting will be at 10:00am GMT on the 25th = of May. The agenda will be to go through the issue list. Based on its length, I propose to add one more interim meeting in June, = before the IETF virtual meeting. My thinking is to space this as close = to a midpoint between the May and July meetings. This will be slightly = less than a month in between, which is a variance from what we agreed. = Therefore, please let me know if you have objections. Eliot --Apple-Mail=_8C7379A4-6542-4130-8EA3-4EB425D33E0E 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCUJuEACgkQh7ZrRtnS ejPpFAf/YWPAxM4xfrBqtUUNFVpDGsFHCvDtwiwxCdaU8KKbN8a/DDn++UzCircJ zV7G3oRdiKxX/eVRDqxNjJmnXISQ5XRpAYCrZgWVZPqkwF/5LA1g7maUVXhX2pJB ROAdjnTiE8+cI0lfUX4zaDgO68J91hrB829w9Xy6AdwZo1KUw5Swte0oxVuM8HSv y/oL5qgMD8KBRsoqDH4DQ4sSlBSgmYWmULJ3g0h4daHlfYSAeQ8o0vT6Lb/oGnI7 NtJWqWOHiYIbSMTO0nKOsFuK72Ii9JkwSKcWAHdzkPBH5yAoPpacOOUHCUZQmuFY UBfzIbGFVsrG6iDCbFHFgxeO3ycV9Q== =3nPg -----END PGP SIGNATURE----- --Apple-Mail=_8C7379A4-6542-4130-8EA3-4EB425D33E0E-- From nobody Thu May 6 11:41:53 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 017473A2C39; Thu, 6 May 2021 11:41:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IAB Executive Administrative Manager To: "IETF-Announce" Cc: rfced-future@iab.org X-Test-IDTracker: no X-IETF-IDTracker: 7.28.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <162032650887.17191.7252668918980729854@ietfa.amsl.com> Date: Thu, 06 May 2021 11:41:48 -0700 Archived-At: Subject: [Rfced-future] RFC Editor Future Development (rfcefdp) PROGRAM Virtual Meeting: 2021-05-25 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2021 18:41:49 -0000 The RFC Editor Future Development (rfcefdp) Program will hold a virtual interim meeting on 2021-05-25 from 12:00 to 14:00 Europe/Zurich (10:00 to 12:00 UTC). Agenda: Go through open issues. Webex link: https://cisco.webex.com/cisco/j.php?MTID=m9677245dc423cef39d14a7dfb183084c Information about remote participation: https://cisco.webex.com/cisco/j.php?MTID=m9677245dc423cef39d14a7dfb183084c From nobody Thu May 6 20:17: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 9164B3A1135 for ; Thu, 6 May 2021 20:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.82 X-Spam-Level: X-Spam-Status: No, score=-2.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_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=q05xRhah; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UK0QCIoU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZypPB5bJsUS2 for ; Thu, 6 May 2021 20:17:18 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 861043A1132 for ; Thu, 6 May 2021 20:17:18 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 935E35C0108; Thu, 6 May 2021 23:17:16 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Thu, 06 May 2021 23:17:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm2; bh=m iH33vrbBRphtMd051RS2C0dmvLg0KQLzss7ASOKKSA=; b=q05xRhahequjmAKg8 eky9EoSygGK05UEUQpsN21TVdlROx/qXb/gpiljixfH6DqxIVO6XWbNgVrwXx9OL qOfuUeUL0e3PFgpDv6YoLgtPuz8PRv8ZxzLR7IV+12B3jrEU0vweZwTOb8Ylj+/e +aNRj1DDvzPvyFQEO7iNmHeTkO7UCjDTARXCE8iRGh69f2SmUHfEPTssEcQVNRpx RSfFLN4omaMriGfjTGQlDzLkz0XTgoVfDhw8vB3FtflCAi8eEvvS4ld5HkTOqDnK ZfrycWaH7zP8FbdL/2lsXtDo4pV/kobABlSPlPYwquecg/Z/wqZ3bpLdVIu1yNRr vkReQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=miH33vrbBRphtMd051RS2C0dmvLg0KQLzss7ASOKK SA=; b=UK0QCIoUk18OoTjicV3DjjfsRGmFEWt4aewd9ZlFRuWSgdQxBS0qx4LDf 29Qo+Otkzd5GdxFn9gV6d/jfnpJ9UDbHOJCU2IKCgt0Bp9ungiSQfEW+Iu/8txyV hcS5IQ6T9sqVzv+DBV6Z20Icx+rCSFD4OMs6+UZdtL1e7c9lvwBCOXFADEGDQMcR giSnsZT2FmboyLEGfsG4ctaIWz9CsgiVFi3E5i5hiycvboF6tjNspX3XFuF+E+GE KWRrA0TfYxOCtw3KkBxFle7t16ArlYnBNGv41aD5tKidM+89qWzAQVYbn0pe6Oo0 N49xgKLdd8xV1QSq38IQmvU4eoYuQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdeguddgieefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucggtffrrghtth gvrhhnpeegudeuiedvleetleevieeiueeileeuhfeikeevveejheffleekveehvdfhuefg heenucffohhmrghinhepthhimhgvrghnuggurghtvgdrtghomhdpihgrsgdrohhrghdpmh hnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucevlhhushhtvghr ufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmnhhothesmhhnohhtrdhnvg ht X-ME-Proxy: Received: from smtpclient.apple (119-17-158-251.77119e.mel.static.aussiebb.net [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 6 May 2021 23:17:13 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) From: Mark Nottingham In-Reply-To: <120055FB-4542-444F-AAFB-5DE4023ACDFD@cisco.com> Date: Fri, 7 May 2021 13:17:08 +1000 Cc: rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <16450D18-D567-4C88-8D6C-B5ACFE5C0C2D@mnot.net> References: <120055FB-4542-444F-AAFB-5DE4023ACDFD@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3654.80.0.2.43) Archived-At: Subject: Re: [Rfced-future] Next interim: 25 May 2021 @ 10:00am GMT X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 07 May 2021 03:17:24 -0000 ... and for the convenience of those elsewhere: = https://www.timeanddate.com/worldclock/fixedtime.html?msg=3DRfced-future+I= nterim&iso=3D20210525T10&p1=3D1440&ah=3D2 Cheers, > On 7 May 2021, at 3:26 am, Eliot Lear = wrote: >=20 > Dear Colleagues, >=20 > Based on the doodle, our next meeting will be at 10:00am GMT on the = 25th of May. The agenda will be to go through the issue list. >=20 > Based on its length, I propose to add one more interim meeting in = June, before the IETF virtual meeting. My thinking is to space this as = close to a midpoint between the May and July meetings. This will be = slightly less than a month in between, which is a variance from what we = agreed. Therefore, please let me know if you have objections. >=20 > Eliot > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future -- Mark Nottingham https://www.mnot.net/ From nobody Sun May 9 11:07: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 BF70D3A18AC for ; Sun, 9 May 2021 11:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuM_MFLY9bl0 for ; Sun, 9 May 2021 11:07:36 -0700 (PDT) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0A983A18AB for ; Sun, 9 May 2021 11:07:35 -0700 (PDT) Received: by mail-io1-xd2b.google.com with SMTP id l21so12692635iob.1 for ; Sun, 09 May 2021 11:07:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=TUvHHmEqSd7TAEzhuz2QKUCdiyv41H5vbDtxwcYstBI=; b=L8wC/5f3DCO+1VU9iTjOUebGejPGZiKiMxftmV3emKQguGPUwX1JpvrmjH/yeTvjOD v/uYg7DT15Hg4rWIao+VKUD6PPE92GE+GTXzkcN9bjMacpYJWXw7l4+iw7A63VDMFg19 B27hJvQQO3CLVSBokh+rVpiztggZwCw/lMsYk= 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=TUvHHmEqSd7TAEzhuz2QKUCdiyv41H5vbDtxwcYstBI=; b=b+SrzGMG8NfJYN81ASbq372rwmub36Hhhj8G4SjixFkPOeGNsMJETdJ/nlzDdJphBM MJNK5lzBK8Cgg+aHKe+rbR0tDAGG+hay0KJPpO8Cdw3LRsgLF+PSgCrfkHeAsmunk0d6 u3tL8rwxH87d1unSegH173GBTMIDRDwUz7hXz5cvUSvtCw7NNXTfbJxhm7/GJk9NZWG/ sP+cFFNMGvgGy/Ltkj3L+0ah92PfnfoRmACwLNM6bSXl859jeNBWCFfqMey++S0spfTx AA7qyMxP/Oyy5KWrxHicp8QbOpenQhY4FgvE8m/UtnoX4hLiovxopHzr1gHX4T440wnU ce9w== X-Gm-Message-State: AOAM530DRv+K4IKtqN9CohbVMtLNekouQsS5oiK8304GGEAEatNkbXVo Y3fObeeSzTIbhr1hXte6KkvOAg== X-Google-Smtp-Source: ABdhPJx+nr4H+vh+HE5f0KBet7D4zMz04UIUXhcExFYdbUTEuyY/PpUddUNJlYsgSYo8T70zOh3CHA== X-Received: by 2002:a02:cbad:: with SMTP id v13mr18315536jap.28.1620583654281; Sun, 09 May 2021 11:07:34 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id s17sm6648975ilt.77.2021.05.09.11.07.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 11:07:33 -0700 (PDT) To: Eliot Lear , rfced-future@iab.org References: <9EC506B1-732B-46EA-A77B-0E233C544149@cisco.com> From: Peter Saint-Andre Message-ID: <5f91e317-16d0-a665-df13-e46cc8249bc6@mozilla.com> Date: Sun, 9 May 2021 12:07:32 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <9EC506B1-732B-46EA-A77B-0E233C544149@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 56: Process for RPC work not requiring consensus X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2021 18:07:38 -0000 On 5/6/21 2:12 AM, Eliot Lear wrote: > Hi there, > >> Issue #56: The RSWG/RSAB process is clear for larger projects but the RPC also need a path for discussion and agreement on smaller things that do not require a consensus process. Previously the RPC would discuss and agree these with the RSE, with the RSE taking the decision on what meets the threshold for taking to the community. How are those agreed now and who decides what does and does not need community consensus/engagement? > > > With regard to this issue, as well as 57, 58, and 59, these seem to articulate a point that was raised in Issue 23 (“What is strategic?”). What I propose to do is to close 23 in favor of us using your pragmatic issues. > > But we should maintain the context of thinking around that issue. I believe the intent of the WG at this point was for the overarching policy and procedure to be set by the RFGWG, but for the implementation of that policy to rest entirely with the RPC. While the RPC should be free and even be encouraged to consult the RS[EA], the decision is with the RPC. It is not a negotiation. This is my understanding of the group view, based on previous discussions. While I don’t believe we’ve discussed this explicitly, it seems reasonable for the RPC to periodically report on those activities to the RFCWG. > > There will occasionally be ambiguities. Here, I believe the group’s view is one of “better to ask forgiveness than permission” in those circumstances. That is- the RPC is empowered to act, but then should report the ambiguity to the RFCWG, as the RFCWG process is expected to be rather laborious. Again, consultation with the RS[EA] encouraged. In his reply to this message, Joel raises a concern about a change in the RPC's role. It would be good for Sandy perhaps to provide her perspective, but my recent experience working through open issues related to v3 of the XML vocabulary in collaboration with Sandy and Alice is that they often find it helpful to confer with someone (or a small team) regarding issues that crop up. These aren't large policy issues of the kind that we've envisioned working through in the RFCWG, but they benefit from informed and focused discussion. However, it's not clear to me whether the RFC Editor Model needs to define a formal structure for such discussions, since I think they could be defined by the RPC in an ad-hoc way (e.g., through an informal technical or editorial advisory team). > Is my understanding of people’s views here off? I believe the text in draft-saintandre-rfced-model is consistent with this position, but could do with a tad more elaboration along these lines. I wouldn't put much stock in the current text. :-) My intent is to update that document once we've reached something close to consensus via discussion on this list. Peter From nobody Sun May 9 11:14: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 9C3723A1902 for ; Sun, 9 May 2021 11:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QaG3H1gtv4gm for ; Sun, 9 May 2021 11:14:51 -0700 (PDT) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D1483A1901 for ; Sun, 9 May 2021 11:14:50 -0700 (PDT) Received: by mail-io1-xd2f.google.com with SMTP id z24so12697769ioj.7 for ; Sun, 09 May 2021 11:14:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Ebf+nyuVlaoJBYZR/umNAJIN5gloVY5kTxkvyEzPVEk=; b=DTebCUCTTqfCIXX2AAAyDUXykikWmjUdwZhhq/PG9fMENoGYV5XL0YUTtZokkg5NfZ 4Vqm6QvLUqRrGlxvD3mHuAIsmMUWeHgNJeVUlaRyzzqv1BSP4XzXFbfvi5rBUyO4TRxI h46iB7PldX7HkCIO7D5U3ZaSJdQU3pJlSj5BA= 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=Ebf+nyuVlaoJBYZR/umNAJIN5gloVY5kTxkvyEzPVEk=; b=JiS3NhzEQgW8ua1M9zNeXhRfv+42H4DwthyWwT2oCa/uIs0b0CKGPZNAAHqfOvI1pt N6AZvANuEvb8ayUg/476bD0+QixPoPw96NWk6JNhJ8g4c0S9gESKVaSxSnz/pk56XAa7 xW6gKrkXwAd4szRsVZEe1pzi7XCoTjgkIjWQUSZtiUNXEE2mja5ECwZLs4WRIPwAD/Fu KMLWwY2ayveZo7ubDhFN/WuGBMnBmH37TDEGBqYJwDHPx98uH+OU1LLTeWromv8b9Dzi hr8pRIZX6cgJlIGHDgxOBaCBzr40pUYcQclL4Jl1Ge3RreWRgI4EY6FsPwbWpPCNZ1Jy qj0A== X-Gm-Message-State: AOAM530AiOON+ZPJuITu8t4cRUkrc0btdaaPs+xalDgMCMyRdsnycM+D PQVvjhjmXI/Qphp0LlHtP+/IBqCFmY4Bcw== X-Google-Smtp-Source: ABdhPJzyus/HO/zAGY2lsTOuOL2i72F1O0vTPYsj2HMt85qjgcvbClWkxxTZSByizuJJAl6fVKM/2A== X-Received: by 2002:a5d:81c8:: with SMTP id t8mr15429171iol.19.1620584089624; Sun, 09 May 2021 11:14:49 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id n184sm4227273iod.0.2021.05.09.11.14.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 11:14:49 -0700 (PDT) To: Jay Daley , rfced-future@iab.org References: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> From: Peter Saint-Andre Message-ID: <0a7e96a1-cdb5-d7c3-366b-964fde6ebca5@mozilla.com> Date: Sun, 9 May 2021 12:14:47 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Rfced-future] Issue 59: Who mediates disputes between the RPC and authors? X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2021 18:14:53 -0000 Hi Jay, thanks for identifying these issues with the RPC. Where needed I'll start new threads (as Eliot already did for 56). On 5/5/21 6:39 PM, Jay Daley wrote: > Issue #59: It’s not clear who mediates disputes between the RPC and Authors? It seems to me that this might depend somewhat on the stream. In my experience, within the IETF stream this mediation role is often played by a document shepherd, WG chair, or Area Director. As I understand it, in the Independent stream the ISE could play this role. Etc. I suppose it might also depend on the nature of the dispute. Perhaps our RPC friends could describe the common dispute types and how they're resolved now (and have been resolved in the past) so that we can reason about this issue with greater clarity. Peter From nobody Sun May 9 11:29: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 E02BA3A19AB for ; Sun, 9 May 2021 11:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Opik6QLpCRV5 for ; Sun, 9 May 2021 11:29:56 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 0987E3A19AA for ; Sun, 9 May 2021 11:29:55 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id i7so5234667ioa.12 for ; Sun, 09 May 2021 11:29:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=20RZrXZ4XPCG+N4QV3MdjWWCM/jtVjyhhfYruFIyu14=; b=S1eiNi1m1WJi+UbomlPK1heYXBogfBnXOL35DlEeZyxZ291gIyT4ej5ifGv/TAqdaC pLnB4TL2Cn6sh1x8cduv3MbxWhcN6f4VFfxl22nXF3tcO1UP39vlpABi5u2yqBLDA5uh B7c8j03v3Kw9Dt+CecS9O4x9pWrkL0lATnpZ0= 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=20RZrXZ4XPCG+N4QV3MdjWWCM/jtVjyhhfYruFIyu14=; b=OZyTEkQSCV0VhBwKQNvgG04kWOjk4zOLcqmtrdAFBFpVK5YmfnObpTAyxLxmdPNShv QJRzH/eBgpm2rrRpo4Dk90GJcW/au91Q5SCjd9DjAMJv7mRWxuuFi3i0uE9oqE9FGZbM k9jYidsglLvTKMKc9K9qZ3Rqr+JWzpZQt3Qd/dgTP5OurJS/uP5QKUiJrtyH15tmm9vJ r6xPrImqwq6yFOwD4Ll1hFhLRp53ajaEv+lMSXxGCx+J+/KznS5R49f99aZ9bsK8OR12 StoZTyIXZ4/KbtzAWwBZIdZMUJicwJk8cJydYoS/mmg9siz1bY0alOJSUgdMlmumSe6p Tg8A== X-Gm-Message-State: AOAM532X+vnoNjCccN0CSAevwL6HCtHZX+WhuFzVEJEZdILlr63RttaH CZ5BmJQVVU9ed/SyRt57S+bVEoXqCWNiiA== X-Google-Smtp-Source: ABdhPJywfN9uf/9jwQSjzOFEDwfBtNLt3IylxShReGJhR7GfzErz8jnWkY5zjKNgIGXhKNQ4rcR1ow== X-Received: by 2002:a6b:cd08:: with SMTP id d8mr15608468iog.86.1620584994328; Sun, 09 May 2021 11:29:54 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id j17sm5552622ilk.55.2021.05.09.11.29.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 11:29:53 -0700 (PDT) To: Jay Daley , rfced-future@iab.org References: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> From: Peter Saint-Andre Message-ID: <06a0985f-9f96-1754-ed45-ce75ff9ee672@mozilla.com> Date: Sun, 9 May 2021 12:29:51 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Issue 60: Resolution of disputes between the RPC and authors with cross-stream implications X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2021 18:29:58 -0000 On 5/5/21 6:39 PM, Jay Daley wrote: > Issue #60: Disputes between the RPC and authors sometimes need escalating and in the proposed process the stream manager appears to be the escalation point. However, if the dispute is about something that affects all the streams, such as RFC style/policies, then it appears that this has to be escalated to the RSAB. Is that correct and will the RSAB be able to respond in a timely manner? Here again it would be good to understand broadly what kinds of disputes we envision. My sense is that whereas deeper policy issues would likely need to be taken up in the WG, for smaller issues that need a timely resolution the RSAB would be the best initial escalation point because all streams are represented there; however, after the issue is raised with the RSAB it seems to me that the RSAB could ask one or more of the RSAB members (which could be the RSA/E) to investigate and suggest a resolution. Peter From nobody Sun May 9 11:33:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EE43A19D9 for ; Sun, 9 May 2021 11:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q4phznlQZn5o for ; Sun, 9 May 2021 11:33:06 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A593A19D7 for ; Sun, 9 May 2021 11:33:05 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id a11so12724150ioo.0 for ; Sun, 09 May 2021 11:33:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=aL/oByauEJkpzp/xoEYXo8o2defmTCuMTDNJbubLjbU=; b=IixI97+Wo7N8MM5drXa7v9I9821GWgY3Hf2EZHw/COaux4PUJ8W89dS64kk31VW0Xc ZJuC+RD4MJDemPFXQvLSAqjliARI/bkJgVLwdE8F10NofinNZsE/TfkwZ4Hnu4lvMBgC AhX1j+Asge8hZ8serAbBnOTSLSZEmisxi3dN4= 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=aL/oByauEJkpzp/xoEYXo8o2defmTCuMTDNJbubLjbU=; b=nUyIUvGE98kuRHIH9n4v7eBPtUo4/ANTIf3pim7jWFDJgH9p3FyuLdBPMoVaiL1PhP gKs6hjDlJ1E/kqF6UpprTZSF1HqG83J3Ktoweoz3tn4hxDyVnqwMutFrSPQnX8xlB/+0 LX7FUJ8kXijBscAcoZPIYhHJeEYA9HXb0tBiVP7rZjLuo9+po8mB+V6gutI0ZG2KWo3w bCSTW/uTdgPSib3zX2PKYdCE5FmVn8XNH4I1tDALILEPAqNmE+kTRQq6fHAFxGl9G5lb ZUmFnMpaBiTNTPk8Z54ua/6SUc/NnfLeuN5OZBTiv6W5tuAHbwrNN8tawgn61DwH+/bo o6LA== X-Gm-Message-State: AOAM531Wujtl5gPTfUylZgUq5P0d0bP9hdVciaD+MDg6d8MriE1ay4ib gFD9JrFa2XWRrUUcQerujndzoYWqWWufSg== X-Google-Smtp-Source: ABdhPJxhcOh0BaDaIC1s9hfLGGLbisyPxilG8NmUWI5cgVyqxpYQAvh55pmcjgjvXcKaFNSCHlYY3A== X-Received: by 2002:a05:6638:2044:: with SMTP id t4mr18778254jaj.12.1620585184801; Sun, 09 May 2021 11:33:04 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id r3sm6519721ilt.37.2021.05.09.11.33.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 11:33:04 -0700 (PDT) To: Jay Daley , "rfced-future@iab.org" References: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> From: Peter Saint-Andre Message-ID: Date: Sun, 9 May 2021 12:33:03 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Rfced-future] Issue 58: Can the RPC continue to make smaller changes to the style guide X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2021 18:33:09 -0000 On 5/5/21 6:39 PM, Jay Daley wrote: > Issue #58: Will the RPC be able to continue to make smaller updates to the online portion of the style guide and various lists as they do now? I see no reason why not! (Here again, the RPC might want to have some kind of ad-hoc advisory team, perhaps including the RSA/E, to help guide such decisions.) Peter From nobody Sun May 9 12:03:26 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD183A1B75 for ; Sun, 9 May 2021 12:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dm1P3zJD3uW7 for ; Sun, 9 May 2021 12:03:15 -0700 (PDT) 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 DEE283A1B59 for ; Sun, 9 May 2021 12:03:14 -0700 (PDT) Received: by mail-io1-xd31.google.com with SMTP id r17so402324iot.4 for ; Sun, 09 May 2021 12:03:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Ho1WJ2zchRhazF5hdqknMYw8jRPOswDdczwxSlGPumo=; b=CYWa6/TAoAGSC34tstLfcGdydpZYSobsI7YaSV6qHepZeKFg/biQQfebkqil7Vqc9X XNFYeLHzYPKDuzhpeHiab0YVoYzljfrjy9NkDAxf4khrvIJZLPm7Y5Avdsg71ttCa9Ld 8cI1DY6HhlfSESXXPBY+GnRcnSMeILI+OMsFo= 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=Ho1WJ2zchRhazF5hdqknMYw8jRPOswDdczwxSlGPumo=; b=XtvsHplK5kffSweRygisBFdylDeeeGEwAat6IjRwadVzUJmVBaKf1v5iJiPlnawzTP QLJvhjEJ6/NrjXbyDWicam93giW4RrHbSTToMRxhC2Prux46yqqL/rONrti/PXrs+MfB PPpW+PP9HebqGMdTvQ2nGUTobCzNEr7usidrqx1X2goDAnQtRxu0EptMVOHNm0pQ+oQx JDNXetB4Jm5y4JIi/CjUREB13OhUBiH0rddyx/0qMRtJApwE6YQosMC1UL9xHHR1Qtk7 0NeufhTbLblsdGYEIFPyHSApA9B34q4qNVaSx0ahH9OYw6VDYgg7fNe4wtM1z3a0hNqW 9tdA== X-Gm-Message-State: AOAM533EB8uVAfoIHvP4BlcRYqk7/4qGT7kHsN7sPEuAnA5WzL93/ZOI AiCcmdPgSZnZ3tWDzu4MLvtOGg== X-Google-Smtp-Source: ABdhPJwqJLx12VrjOlz32P5HOQw3XB9znhBfLNTabZXTYLTg6bzLIWKYzWn6wyt6qb4zX9lG64P3rg== X-Received: by 2002:a02:308e:: with SMTP id q136mr18390483jaq.47.1620586993263; Sun, 09 May 2021 12:03:13 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id l15sm84459ilo.52.2021.05.09.12.03.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 12:03:12 -0700 (PDT) To: Jay Daley , rfced-future@iab.org References: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> From: Peter Saint-Andre Message-ID: Date: Sun, 9 May 2021 13:03:11 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Rfced-future] Issues 57, 61, 62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2021 19:03:25 -0000 Issues 57, 60, and 61 seem to be closely related... On 5/5/21 6:39 PM, Jay Daley wrote: > > Issue #57: The RPC has a wide set of projects to deliver with limited resources and decisions have to be made on priorities. Previously this was negotiated between the RSE and RPC with the RSE having an understanding of community priorities. How are the priorities set now? > > Issue #61: Traditionally, the RSE has acted as the eyes and ears of the RPC, sharing insight and feedback about what they’re hearing from the community. There are multiple times when the RSE brought community requirements to the RPC that the RPC were unaware of. Is the RPC now required to do that directly or is that the responsibility of the RSWG/RSAB or do we assume that any requirements that are not brought to the RSWG are to be left unmet? > > Issues #62: It is not clear who would communicate decisions about RPC projects/priorities to the community. My understanding from the discussions so far is that we've envisioned the RFC Series WG as the venue for formulating policies, not for specifying the goals and scope of particular projects or setting priorities among such projects. Thus this cluster of issues raises important questions. I see a few things here... First, senior contributors or managers within the RPC might need to become more involved in community discussions so that they can better understand community priorities. Naturally, if this is a change from current practice, the RPC will want to include such activities in its scope of work with the LLC. Second, as I mentioned in a recent message the RPC might to work with a small advisory group (formed from people who are also heavily involved in community discussions) so that it can confer on proposals for solving larger open issues (e.g., before sharing such proposals with the broader community). Such a group could, of course, also include the RSA/E. Or the RPC could just work directly with the RSA/E in such matters. Third, since ongoing operation of RFC publication is envisioned to be handled under arrangements between the LLC and the RPC, I would think that some matters of projects and priorities would be subject to, say, statements of work for particular projects that would be proposed by the RPC and approved by the LLC. Peter From nobody Sun May 9 12:10: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 036273A1B99 for ; Sun, 9 May 2021 12:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5HVd74d-wjY for ; Sun, 9 May 2021 12:09:56 -0700 (PDT) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (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 BDE983A1B9A for ; Sun, 9 May 2021 12:09:56 -0700 (PDT) Received: by mail-io1-xd35.google.com with SMTP id o21so12360943iow.13 for ; Sun, 09 May 2021 12:09:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=xRW0lUte+d6Ckeyn/hhUf83G/mPQTpYGnEzsk6tc0y8=; b=FpDHEPkvMFKJhE6hoJVIEjN/8w6tWJZm98It0PJI9CBygcjmCuFEnvWRpICAq+3qTV ABnitMwv6Ir1fAPyLICSWDrBpp0MNQg91V8Nb73b7ugqbJOQWAYzoGQzVlIiDaYJ47Cj xnopTI/k50nr7/Ez4YJPBro5GA0gUuaVtuOpM= 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=xRW0lUte+d6Ckeyn/hhUf83G/mPQTpYGnEzsk6tc0y8=; b=IqwMK1G8zNaqBQe5U4YeMZohW6Mp/wlHC+i2agt6PSoL3zdmCPFGbnLnpD5kXx38jH 3pwnr2gzXa3iHsj0QaTqsM92c8XtQboztrk/+r1nXCuxsX0zschz7R5cwAQdSHF19tIW kxnT928lTcccuKVJdNEH5nt5uN1qDiXwnoq9emfogAzX6SbSGpmeH8JCwSD5vQp6DBIi TUhBKYwaJUMV3d5Kldjs2u0JIqYaWugHOA1fvdtBbHStK3DJ50QrLt0Qi+4jpPoTNdha 4PG2lXCs+iLCA3KSziXOT8dtmXIwX/CxIqDL8vPvZThjAYW2iEIFTMC2eo+y9UxQHg3r wpfw== X-Gm-Message-State: AOAM530uaQP3duhvlUyGPC9wHqRoylGkE+O/2/tvUx9ZtcVNWABvxgiD Wh7+C8Pe7/tDYkiI0pfAjxZHHA== X-Google-Smtp-Source: ABdhPJyR6tF4dOmSYQd5TS/awrv00BbDTJwE7IDDn3XUouhJpXiU2jrdAoJunOAciD8q5g/UCVYNnA== X-Received: by 2002:a05:6602:2d8d:: with SMTP id k13mr15436669iow.121.1620587395285; Sun, 09 May 2021 12:09:55 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id c10sm6762874iln.20.2021.05.09.12.09.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 12:09:54 -0700 (PDT) To: Jay Daley , rfced-future@iab.org References: <5AF18B7B-3681-45BB-8D61-DAF0DCAB2732@ietf.org> From: Peter Saint-Andre Message-ID: <941b1ea6-8665-1fac-9b7e-1b2b35bb2bfa@mozilla.com> Date: Sun, 9 May 2021 13:09:52 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <5AF18B7B-3681-45BB-8D61-DAF0DCAB2732@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Suggestions for "RSEA Ongoing Performance Evaluation" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2021 19:09:58 -0000 Hi Jay, On 5/4/21 3:24 PM, Jay Daley wrote: > I’ve reviewed 6.2 "RSEA Ongoing Performance Evaluation" of draft-saintandre-rfced-model Once again, that was very drafty text. Nothing set in stone there. > and I wonder if it is possible for a draft recommendation from the IETF Executive Director to be presented to the RSAB, excluding the RSEA, and an official view of the RSAB to be included in the final recommendation to the LLC Board? > > My concern here is that community feedback, while often of high quality, may potentially be biased or incomplete and the RSAB is probably best placed to take a view on that. That seems reasonable. > Also, I think it would be useful to note why this recommendation has to go to the LLC Board rather than just being handled by the IETF Executive Director, otherwise this document may inadvertently set a precedent for other contracts. What is the LLC's preference? I agree that we don't want to set the wrong kind of precedent here. Having the ED handle the recommendation seems fine to me. > Finally, I assume the feedback, summary of feedback and the recommendation are confidential? If not then that should be clearly stated. Agreed. Peter From nobody Sun May 9 12:26: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 D5F183A1C44 for ; Sun, 9 May 2021 12:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.201 X-Spam-Level: X-Spam-Status: No, score=-0.201 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14AHpxEJgZeF for ; Sun, 9 May 2021 12:26:16 -0700 (PDT) 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 207A03A1C43 for ; Sun, 9 May 2021 12:26:15 -0700 (PDT) Received: by mail-il1-x129.google.com with SMTP id h6so12217178ila.7 for ; Sun, 09 May 2021 12:26:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kAZahZGp3l4MTlmrsEfUTM+xJtGRfl1PMT6Bh6SxUsk=; b=QLMnu+y5YpWodVTWFkS+6wpEMwXC1sAEl+HnjZujvFH/s0xkBvmwjPvEldpu0BSXkL jF5Fv8RtSrDIEtq+cNOSWNIDHPM84+8N/BKAdFjTgDwN6c5pwypPu+8tiOvF1AEOAVfJ nrQceurh3KAKQdsNkWwnPpi8tVO/jPvpMf9KU= 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=kAZahZGp3l4MTlmrsEfUTM+xJtGRfl1PMT6Bh6SxUsk=; b=Dhf/Vnps8MZP7s693qh1/9uKf96NFI4EMS4+1WpGnJ91RApR7pt3JRCrgRlwY7HtP/ 2ayv5dTJlgRYE2g7ZFMk+6kw8fNovAOnNUXMgrgZASpCi7eMgoImRvJ0vcCMWd/FY9NS EWIqPPRUv0OX194y2owuOIZw2hXQkZttWYrOphDEnWV76aBYz2xBTF1HbNE253KPTo7U A5Ltgo2C5vpR95lI8MWRqH3W/WHY3WShnefl6qKbLv0XInSFLy2qRQvWQkfHwMs+OLyP E5oEp8PhjU2qpy0LA8/UeR2Rkb9wAc5VBr80pstjE3UEMhEUAblcV2e++8KgcHppFUz8 2Vzg== X-Gm-Message-State: AOAM531txZ7eCQbAgwokk2eDi933Li21B/98Dgzgq9gb/Udf3O4TU+/+ xSxOoKnCXebPDuQUVdVgBI+vZwEx7g8KSA== X-Google-Smtp-Source: ABdhPJw41moCIMIoHMUEZc5ItDp+gogUVnye1OoE6xBB2jPRbxh/4AMvTHzq74eV24XtIQxVWqPClw== X-Received: by 2002:a05:6e02:13ca:: with SMTP id v10mr17305118ilj.191.1620588374685; Sun, 09 May 2021 12:26:14 -0700 (PDT) Received: from dragon.local (c-73-78-113-156.hsd1.co.comcast.net. [73.78.113.156]) by smtp.gmail.com with ESMTPSA id d2sm6952958ile.18.2021.05.09.12.26.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 12:26:14 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> From: Peter Saint-Andre Message-ID: <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> Date: Sun, 9 May 2021 13:26:12 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2021 19:26:19 -0000 On 5/2/21 10:43 PM, Martin Thomson wrote: > On Mon, May 3, 2021, at 13:17, Michael StJohns wrote: >> You're mistakenly conflating community consensus with RSWG consensus, >> and I submit those are nowhere close to the same thing. > > I don't think that it's a mistake, but a feature. Though I acknowledge the usual conditions (who can be bothered to turn up and comment) are challenging, deliberately deciding that the two reduce to the same in every way I can imagine. Do you have arguments in favour of the alternative paths that indicate valuable features? > > I realize that you are concerned about things getting stuck in committee. Providing the RSAB the tools to ignore that community is dramatically different than acknowledging that the rough consensus thing is imperfect and working within those constraints. I don't agree that by insisting that a Working Group reach consensus, we are creating a system that is overly prone to this obstruction attack. Yes, obstructionist behaviour is hard to deal with, but we know how if there is the will to do it. While I agree with all of the above, I do wonder if we would like some lightweight mechanism for dealing with smaller issues that don't require the full policy-making power of the WG and AB. As a point of comparison, the IESG and IAB don't unilaterally publish RFCs, but they do publish statements and provide direction on smaller issues. However, to my mind that would explicitly not include moving documents along absent consensus in the WG. Yes, there are failure modes where the WG is inactive (in which case we'd need to inject more energy) or unable to reach consensus (in which case we'd need to work harder to do so), but IMHO that doesn't mean we give the RSAB unilateral powers to work in a less consensual way. Peter From nobody Sun May 9 13:17: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 702D83A1E57 for ; Sun, 9 May 2021 13:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[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 NQHHbHAcZvPD; Sun, 9 May 2021 13:17:34 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 197673A1E52; Sun, 9 May 2021 13:17:33 -0700 (PDT) From: Jay Daley Message-Id: <59606BD3-A0E3-4731-BF0C-020147383E19@ietf.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_1BFC2485-531B-45FA-A1A2-48108DA095AB" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Date: Mon, 10 May 2021 08:17:30 +1200 In-Reply-To: <941b1ea6-8665-1fac-9b7e-1b2b35bb2bfa@mozilla.com> Cc: rfced-future@iab.org To: Peter Saint-Andre References: <5AF18B7B-3681-45BB-8D61-DAF0DCAB2732@ietf.org> <941b1ea6-8665-1fac-9b7e-1b2b35bb2bfa@mozilla.com> X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Suggestions for "RSEA Ongoing Performance Evaluation" X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 09 May 2021 20:17:40 -0000 --Apple-Mail=_1BFC2485-531B-45FA-A1A2-48108DA095AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 10/05/2021, at 7:09 AM, Peter Saint-Andre = wrote: >=20 > Hi Jay, >=20 > On 5/4/21 3:24 PM, Jay Daley wrote: >> I=E2=80=99ve reviewed 6.2 "RSEA Ongoing Performance Evaluation" of = draft-saintandre-rfced-model=20 >=20 > Once again, that was very drafty text. Nothing set in stone there. >=20 >> and I wonder if it is possible for a draft recommendation from the = IETF Executive Director to be presented to the RSAB, excluding the RSEA, = and an official view of the RSAB to be included in the final = recommendation to the LLC Board? >>=20 >> My concern here is that community feedback, while often of high = quality, may potentially be biased or incomplete and the RSAB is = probably best placed to take a view on that. >=20 > That seems reasonable. Let me know if you want suggested text. >=20 >> Also, I think it would be useful to note why this recommendation has = to go to the LLC Board rather than just being handled by the IETF = Executive Director, otherwise this document may inadvertently set a = precedent for other contracts. >=20 > What is the LLC's preference? I agree that we don't want to set the > wrong kind of precedent here. Having the ED handle the recommendation > seems fine to me. I will check in with the LLC Board. Jay >=20 >> Finally, I assume the feedback, summary of feedback and the = recommendation are confidential? If not then that should be clearly = stated. >=20 > Agreed. >=20 > Peter >=20 --=20 Jay Daley IETF Executive Director jay@ietf.org --Apple-Mail=_1BFC2485-531B-45FA-A1A2-48108DA095AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 10/05/2021, at 7:09 AM, Peter Saint-Andre <stpeter@mozilla.com>= wrote:

Hi Jay,

On 5/4/21 3:24 PM, Jay = Daley wrote:
I=E2=80=99= ve reviewed 6.2 "RSEA Ongoing Performance Evaluation" of = draft-saintandre-rfced-model

Once again, that was very drafty text. Nothing set in stone = there.

and I wonder if it is possible for a draft recommendation = from the IETF Executive Director to be presented to the RSAB, excluding = the RSEA, and an official view of the RSAB to be included in the final = recommendation to the LLC Board?

My concern = here is that community feedback, while often of high quality, may = potentially be biased or incomplete and the RSAB is probably best placed = to take a view on that.

That = seems reasonable.

Let me know if you want suggested text.


Also, I = think it would be useful to note why this recommendation has to go to = the LLC Board rather than just being handled by the IETF Executive = Director, otherwise this document may inadvertently set a precedent for = other contracts.

What is the = LLC's preference? I agree that we don't want to set the
wrong kind of precedent here. Having the ED handle the = recommendation
seems fine to me.

I = will check in with the LLC Board.

Jay


Finally, I assume the feedback, summary of = feedback and the recommendation are confidential?  If not then that = should be clearly stated.

Agreed.

Peter


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

= --Apple-Mail=_1BFC2485-531B-45FA-A1A2-48108DA095AB-- From nobody Sun May 9 17:06: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 E62F53A25C6 for ; Sun, 9 May 2021 17:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=ZTJilNWo; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dMXVX81r Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1bNoP-7KMww for ; Sun, 9 May 2021 17:06:21 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F82F3A25C4 for ; Sun, 9 May 2021 17:06:21 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id 7001114BA for ; Sun, 9 May 2021 20:06:15 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Sun, 09 May 2021 20:06:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=sECIH+hDEsqludoTEZhUHM3+XSODUut Rugx0fZ2cDtI=; b=ZTJilNWotbIGT5UsqkHuHnmNVhoYigquL4B6KOKYH80FJn/ EQyutjBFZzuwGOXqUWJl8iQ4fVYlJNX6w5FaNtTsv6fyFgp1RR6c4jUAE0Ao2sZY mEoTpVPPazyFSVMHQl41qB5q6OD6SIeW/WwJRK5EKoxT6oUxur2XGT01l7BlhX2U 72JiwLtqLb8ePi6NX5o/l4kMGzSCrFB4pL4Ubg4+kvSqfSF1VHZze/DlREq0Aqqh /5rYy2mN3M8ZnOeelcdISIwCwrBFqc2veC+EiwJqYX4Wc57ENjVz/TVe9Y0uPquM qjmFclyHZjTL0OqXXOj++wjH02Zfr6lgGx7e21A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=sECIH+ hDEsqludoTEZhUHM3+XSODUutRugx0fZ2cDtI=; b=dMXVX81rL/n3p+b7dyIA7S L1gdl6daiOzIEJFFA0q3IdDfOZNNw32MTnqjmSmx0fONI77nwvD8uqRR4OagX2yl kkjCHBjD0AmsQIwlkksfWiHw2xmaZV7RtgeDR8qut/e5yLfxTbLaNrxK+RcIbDt1 YgzzKpaAtEGrPd2EbofHZmeCLSuc93Au3/JmrXVk+NVzmMHqOG6cvSauQ9YtQYrw 2zb/joMHfY632WHdiMuG/HzMZOvIX24F42urKifLEzUy2ar+zEy83w1qlkE57Y2e 3wj7J9thPsHP6ySmo6IlV03AJXcSy11jOp44JPAOnqcNB0An0Nyl0HUexN3Aotzw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdegjedgvdejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7235D4E0172; Sun, 9 May 2021 20:06:14 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: <681d792b-3e04-4a50-982e-639863b2f92a@www.fastmail.com> In-Reply-To: <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> Date: Mon, 10 May 2021 10:05:57 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 00:06:27 -0000 On Mon, May 10, 2021, at 05:26, Peter Saint-Andre wrote: > While I agree with all of the above, I do wonder if we would like some > lightweight mechanism for dealing with smaller issues that don't require > the full policy-making power of the WG and AB. As a point of comparison, > the IESG and IAB don't unilaterally publish RFCs, but they do publish > statements and provide direction on smaller issues. I think that is entirely reasonable. I tend to think that the right approach is to carve out some space for the RPC to make these decisions for themselves, maybe with some systems for both support and accountability. Support might come - as it has done in the past - from an RSA(E). Accountability might come from documenting decisions. Yes, that comes with the micromanagement risk: decisions might be reviewed and revised. Given the weight of the process (a feature, not a bug), using the strategic direction to override day-to-day decisions is a poor choice. From nobody Sun May 9 17:12: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 A17203A25F7 for ; Sun, 9 May 2021 17:12:00 -0700 (PDT) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W47X4Lw40sCe for ; Sun, 9 May 2021 17:11:59 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 411303A25F5 for ; Sun, 9 May 2021 17:11:59 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id v4so1991612qtp.1 for ; Sun, 09 May 2021 17:11:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=8z+R+TVkS392rQ1Ge9Vol5j0wojahJm4cpO6tiDx4G0=; b=ijY0cjlRa6BkgERrw/OboHcF2vUzBOvZ//Kx6dswSdL+Gu4GS5fvq0zgH1GJs8MLaU 4U6OvdJ+Dl0rA3oYDJ9dYOwagwZOWJRjVTf5tVljAd2d3jk4LuPrLCUJtKDfyxIT2SU5 f8MS9zQQil2nR45nDNvCib/A5wbporac5dEYxUhoJ8RnKNcEk2g9NypFmRbRra6Z83i4 ZYgXgiYZD12uWLnZTlBwrGBiF8zQyObh1tCygEut1OPdX1CCE6NiOAOG7WOF9g9aet5n zr93Iyg+Nof0IeXsBgaNGbokIxU73eiJ6DVzGytV0XGtqnp8RutuHPsInd3Pd3XdOv7C n0HA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8z+R+TVkS392rQ1Ge9Vol5j0wojahJm4cpO6tiDx4G0=; b=WKKAEO9TutHu7gBSyb3TGwBSHWhiZEE0r8IH043RP3faTf5H19YLa9ftxR7PBcUyQr SZDPNVISx/wwXsfuINtIObzWTb7Aqw+iImuh38j8UbFVYq9vdPOqmjaXpwjlqMYyqKNY A/tF6E0bnOSGK0Cb7Qv+LWn6T+rOEBAzPAjMdQ9qR/Id5g/esUksHTddsm3lpp/nenS6 EapuJcHnNH2E+NHEoLYdE9PO7Mc1ahShCPTU6pZr0HPJCFer3xYHIgWJ/1e9rEj5jfGS zAEA1ki7Z0QE/yKEtTjYXOnFAXmV0VqyOTSrqjoZMg3ObufrIIPj5k2onEvX0v5u25Wz pt8A== X-Gm-Message-State: AOAM530ZCKQMHWHGlPWISGo5xdcXnvGbIhzQLYmID5TA51MEksCSHJyr zP9z/INRsy7+iVq14Yu3t+MkYA4PWEL4JJ61 X-Google-Smtp-Source: ABdhPJzNKhE9PB6kEDh6gP+0cwCIHB/GDqTlOAy5YcOEyiFMLa6UT62xnE7YV0PQQuP9ZzOz9QjSow== X-Received: by 2002:ac8:7d14:: with SMTP id g20mr1072650qtb.298.1620605516554; Sun, 09 May 2021 17:11:56 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id m22sm10700004qtu.43.2021.05.09.17.11.55 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 17:11:55 -0700 (PDT) To: rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> From: Michael StJohns Message-ID: Date: Sun, 9 May 2021 20:11:54 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 00:12:01 -0000 On 5/9/2021 3:26 PM, Peter Saint-Andre wrote: > As a point of comparison, > the IESG and IAB don't unilaterally publish RFCs, but they do publish > statements and provide direction on smaller issues. Hi Peter - Are you saying that the IAB and IESG never publish "public statements" and "provide direction" in the form of RFCs? Also, not quite sure what you meant by unilateral here.  I've seen both "here's what the IAB/IESG thinks" documents and "we've surveyed the community and here's what we think they think" documents.  Both are documents originated by the appropriate group unilaterally, and for that matter approved for publication unilaterally.  Yes, they take public comments, but the comments can't prevent publication. Color me confused. Mike From nobody Sun May 9 17:28: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 5DAFB3A2696 for ; Sun, 9 May 2021 17:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 33SygwdO7jKb for ; Sun, 9 May 2021 17:28:09 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 487193A2694 for ; Sun, 9 May 2021 17:28:09 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id a11so8271593plh.3 for ; Sun, 09 May 2021 17:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=rGOC7AcNjgIDpRHIt8ZgsSJYFbnd2daX84qSMlw1eKU=; b=Int+NapKQO5pKqqwpL5zWXhuX0JORoKPo412h05ohUJhT/PCWUYxjFqc9J26ir+Z9v 7QkM3Hd9eVECDQmMvv36dS1SnFnrfGukVXMatxmq29ndEelFS1skHXFi4aihSFhet7W0 9trwWTW0nzh1o25xcDudBhyjb8ok2S2QpKo7LTiGBK38FvtT4N5qjEzEh2te2bAs7pVG ecBOtyFo5Ec9PebW1DwFlikDkVXrYP+Bl3AV9/YVh2/xoUz4FuNigSpz5JPjxB5DRMAR VAwBkRYUzpXKimll2jJa8pJNcPziPnlPCczSbEQV5MGbwfTlyOesZ2/fyNzeEtdlCVTM NfXg== 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=rGOC7AcNjgIDpRHIt8ZgsSJYFbnd2daX84qSMlw1eKU=; b=Av3gfHMem5NCgLsznB1EyMY/UUhOET1esOcpztEeHd7qvVLvnD7Gey6KdN2GuLxwLy Ha4/zy5FKaSMCr9wrdNaYZ23tEr0QwZj00VeCVYJ+hDhQxaYaEM3WkAx58FT5QXCEm/t /RNrd46gabJVk0NFg4baxzHLSo6OJIggKhRTdCv/G3AwwiCOvCg5nN7Dv9+ngttEKxgz eyV1sVR8IWFf1EAqnY4tbEQsOUsIOfLeX+r98DNrJ0ryyVHyESvyJXq8Bmb4HJttUbXl bomuBNMX4tDws1qDwXRsyQIkrD4sccRsRwfyQSlrJabgHxf/sH5cvdrj0Zxwag/Nff1+ db3Q== X-Gm-Message-State: AOAM533UnJLNn/TaH3EmWVi/eL56emq8OBDVkx+u/CBt/gDuABpi6YDu 3nsz5XT+13I/LRy31epdXIIfVc6U3oA= X-Google-Smtp-Source: ABdhPJxXgDO/LofnGPLnXsmNPJfLvk6ghxHGNDjjiIwNZJqeOHXcE83Iucjrk/O4/47+CfLOfUyFKw== X-Received: by 2002:a17:90b:180c:: with SMTP id lw12mr23696955pjb.150.1620606487970; Sun, 09 May 2021 17:28:07 -0700 (PDT) Received: from [192.168.22.72] ([131.203.241.238]) by smtp.gmail.com with ESMTPSA id l10sm9541915pfc.125.2021.05.09.17.28.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 17:28:07 -0700 (PDT) To: Peter Saint-Andre , Eliot Lear , rfced-future@iab.org References: <9EC506B1-732B-46EA-A77B-0E233C544149@cisco.com> <5f91e317-16d0-a665-df13-e46cc8249bc6@mozilla.com> From: Brian E Carpenter Message-ID: <2dfd7a8e-f8ec-daa1-18e4-210ec82123d4@gmail.com> Date: Mon, 10 May 2021 12:28:03 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <5f91e317-16d0-a665-df13-e46cc8249bc6@mozilla.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 56: Process for RPC work not requiring consensus X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 00:28:12 -0000 On 10-May-21 06:07, Peter Saint-Andre wrote: > On 5/6/21 2:12 AM, Eliot Lear wrote: >> Hi there, >> >>> Issue #56: The RSWG/RSAB process is clear for larger projects but th= e RPC also need a path for discussion and agreement on smaller things tha= t do not require a consensus process. Previously the RPC would discuss a= nd agree these with the RSE, with the RSE taking the decision on what mee= ts the threshold for taking to the community. How are those agreed now a= nd who decides what does and does not need community consensus/engagement= ? >> >> >> With regard to this issue, as well as 57, 58, and 59, these seem to ar= ticulate a point that was raised in Issue 23 (=E2=80=9CWhat is strategic?= =E2=80=9D). What I propose to do is to close 23 in favor of us using you= r pragmatic issues. >> >> But we should maintain the context of thinking around that issue. I b= elieve the intent of the WG at this point was for the overarching policy = and procedure to be set by the RFGWG, but for the implementation of that = policy to rest entirely with the RPC. While the RPC should be free and e= ven be encouraged to consult the RS[EA], the decision is with the RPC. I= t is not a negotiation. This is my understanding of the group view, base= d on previous discussions. While I don=E2=80=99t believe we=E2=80=99ve d= iscussed this explicitly, it seems reasonable for the RPC to periodically=20 report on those activities to the RFCWG. >> >> There will occasionally be ambiguities. Here, I believe the group=E2=80= =99s view is one of =E2=80=9Cbetter to ask forgiveness than permission=E2= =80=9D in those circumstances. That is- the RPC is empowered to act, but=20 then should report the ambiguity to the RFCWG, as the RFCWG process is ex= pected to be rather laborious. Again, consultation with the RS[EA] encou= raged. >=20 > In his reply to this message, Joel raises a concern about a change in > the RPC's role. It would be good for Sandy perhaps to provide her > perspective, but my recent experience working through open issues > related to v3 of the XML vocabulary in collaboration with Sandy and > Alice is that they often find it helpful to confer with someone (or a > small team) regarding issues that crop up. These aren't large policy > issues of the kind that we've envisioned working through in the RFCWG, > but they benefit from informed and focused discussion. However, it's no= t > clear to me whether the RFC Editor Model needs to define a formal > structure for such discussions, since I think they could be defined by > the RPC in an ad-hoc way (e.g., through an informal technical or > editorial advisory team). I think the RPC is effectively asking "Who do we talk to when we can't decide on our own?" and to me the obvious answer is "The RSA/E". Do we need to say more? Brian >> Is my understanding of people=E2=80=99s views here off? I believe the=20 text in draft-saintandre-rfced-model is consistent with this position, bu= t could do with a tad more elaboration along these lines. >=20 > I wouldn't put much stock in the current text. :-) My intent is to > update that document once we've reached something close to consensus vi= a > discussion on this list. >=20 > Peter >=20 From nobody Sun May 9 17:30:47 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F983A26BA for ; Sun, 9 May 2021 17:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=MCZKOC0F; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=mxlfQ/yL Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cnu-wIQA4UpJ for ; Sun, 9 May 2021 17:30:40 -0700 (PDT) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4286A3A26B5 for ; Sun, 9 May 2021 17:30:40 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id E84A9155B for ; Sun, 9 May 2021 20:30:38 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Sun, 09 May 2021 20:30:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=uyXO0eA8nxVQ0MzRB+T8kALXrcrg3lE mSEeZyqUX1vo=; b=MCZKOC0Fv9EMvZgb/XX0hs2+82S4Jcxk4acy0l8iKkTI7UW inQJGhPJ34qWu35c4qAnW2pOCeDLb8oZcsB+ImKxBoHVx/RCObIeOxlpExG3e4bx K+E5qnLC/mTC+z+lfdxEgP1U9HQZVOM9DCtOSXaCIq43PAxfart7qChjuHNySYWe 1xoH7Po88/TWN6LRStDIJ2nmlV+PmEU4FiAn0vnjBmm8tFLsSh1gsYXkusQmQT2w qc0s4pdLeRuNZb3Iphyqr8XrgPIifFFexBhvrsrXcCV0rfgBvZsc+FV+hKwOM8f/ Zj5hd7kGatFK6zn35BW5QL8CJXYZJwTVDpm3Ubw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=uyXO0e A8nxVQ0MzRB+T8kALXrcrg3lEmSEeZyqUX1vo=; b=mxlfQ/yLmPB33CzhcK2DiS 6CydZyJ5UoQ9hVjbQbRtAKc8zKMwD/jkyFlkIGokFW/b19CEu3hDLZ2knLngrlFf au9p8YMD4JUaFyvQFeZyedi+8raXRxuiteYbnuGatj1tfy18VQEEQ02X+xbE5iUE S0l3TmQuduS1RDMP5PTJHmXxKUWMS2hMpC12ZHytdNUFUjXuNooI9Qu/3W59eVcZ v0fSmshnMw8lfeBCS58dhue7wk72jUd20rwcUIKMPE3NGVMhWwWR7BxJpNzXvHQ2 dqh8wI15JtxJZ5RrhlwjqGXXif3q+Lv+O8Xg/+N+MKXjG3aYqOAGeLzzjGg/DQUw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdegjedgfedvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeekteeuieektdekleefke evhfekffevvdevgfekgfeluefgvdejjeegffeigedtjeenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id ED9294E0172; Sun, 9 May 2021 20:30:37 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> Date: Mon, 10 May 2021 10:30:20 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 00:30:46 -0000 On Mon, May 10, 2021, at 10:11, Michael StJohns wrote: > Are you saying that the IAB and IESG never publish "public statements" > and "provide direction" in the form of RFCs? The IAB have their own procedures for publication that don't require community consensus. I don't think that that is a good model. The IETF is now bound by RFC 8789, which prevents unilateral publication by the IESG. I think that that is what Peter is talking about here. From nobody Sun May 9 17:34: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 32F223A26FF for ; Sun, 9 May 2021 17:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 v6b5ZK7dat09 for ; Sun, 9 May 2021 17:34:36 -0700 (PDT) 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 AD1CB3A26FD for ; Sun, 9 May 2021 17:34:36 -0700 (PDT) Received: by mail-pj1-x1031.google.com with SMTP id t2-20020a17090a0242b0290155433387beso7302052pje.1 for ; Sun, 09 May 2021 17:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=xZtTK+Jmzatkc45oeSBy8f8wUFYvE/26lfHCqi4g7Qw=; b=UqDd8Cy0isnI744GUFh20nSceKw+7UpSmfaAvnQflL+Ab9e7Rt/K581DCCHBRCuIhc 2oQ6fhbRxM4tWYvBv/lEWbHxztzxV9ZJoJ7aZr06RvuxnGcgaqscu9euZzFEKNd2s4JN /r7McPOxydj3OoBt+dLu4vjxAYLZ+UyfaWJj+VxHOIcAxC3eTS+aIbTh7c6WCD+X4IWZ 88jCXnF270gHeDSPD/2hHMs8b13YiVxZgelo0qfyl0Brc6H1ivyh9jb9b3VBmNNMAYSQ 8FncpiUznrobAIdBtc7gRH5y4LjMSfhC9kkFxnLfag+1cCMfdWdlQRrkkeDu3mBU0daU 1Bvg== 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=xZtTK+Jmzatkc45oeSBy8f8wUFYvE/26lfHCqi4g7Qw=; b=FNJf3CSfqIxXBW1Tej/Ge4NnV4Aanbwb5sB4+3JeP3DjIKDKBAqbpSajSLaoUn709O Hynr3ErECF/qPAhwZLIQO9Yljb7c29OgSTPESng4C1dF+EkjhadY59Je2rMCMbqXs2iN NUUPZCrUPADFgGwoxITUL5esDo0MzJuf+y/7mNrArnE3oG19Q82E9jRkxuGcjE5aVPVa pZKLPh5u/mzBYukttINK2KcZS4nEA88nQsR57YoLE+eEn6miRVixLX6NZh2Q+BlFI+gn mzGCXtwyGy749KP9tOwJ2to5WU45qTuUBn/VTEZQXZaE0Ak5V3k7n3matXsQ+Dq7a6vR yVzw== X-Gm-Message-State: AOAM532h0LoGQmm8ujK59p4mc/OK4ap/iRITl3bLsOMtWfAFzPJ0LVOc Tfm1xuoaTPd+zTiS+3Agj6bi67pg99g= X-Google-Smtp-Source: ABdhPJy7AA8z60zn7f8fYOnyVdMdSOLRqYl2flKQor2nuwdXaDXQdYkhCzoU0fO6XCfUhDMgwmlZfA== X-Received: by 2002:a17:90a:b294:: with SMTP id c20mr37380818pjr.236.1620606875518; Sun, 09 May 2021 17:34:35 -0700 (PDT) Received: from [192.168.22.72] ([131.203.241.238]) by smtp.gmail.com with ESMTPSA id r16sm6880036pgk.16.2021.05.09.17.34.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 17:34:34 -0700 (PDT) To: Peter Saint-Andre , Jay Daley , rfced-future@iab.org References: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> From: Brian E Carpenter Message-ID: <8e50fa2a-87ba-e4a1-7498-ee366bd34907@gmail.com> Date: Mon, 10 May 2021 12:34:31 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issues 57, 61, 62 X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 00:34:38 -0000 On 10-May-21 07:03, Peter Saint-Andre wrote: > Issues 57, 60, and 61 seem to be closely related... >=20 > On 5/5/21 6:39 PM, Jay Daley wrote: >> >> Issue #57: The RPC has a wide set of projects to deliver with limited=20 resources and decisions have to be made on priorities. Previously this w= as negotiated between the RSE and RPC with the RSE having an understandin= g of community priorities. How are the priorities set now? >> >> Issue #61: Traditionally, the RSE has acted as the eyes and ears of t= he RPC, sharing insight and feedback about what they=E2=80=99re hearing f= rom the community. There are multiple times when the RSE brought communi= ty requirements to the RPC that the RPC were unaware of. Is the RPC now = required to do that directly or is that the responsibility of the RSWG/RS= AB or do we assume that any requirements that are not brought to the RSWG=20 are to be left unmet? >> >> Issues #62: It is not clear who would communicate decisions about RPC=20 projects/priorities to the community. >=20 > My understanding from the discussions so far is that we've envisioned > the RFC Series WG as the venue for formulating policies, not for > specifying the goals and scope of particular projects or setting > priorities among such projects. Thus this cluster of issues raises > important questions. >=20 > I see a few things here... >=20 > First, senior contributors or managers within the RPC might need to > become more involved in community discussions so that they can better > understand community priorities. Naturally, if this is a change from > current practice, the RPC will want to include such activities in its > scope of work with the LLC. >=20 > Second, as I mentioned in a recent message the RPC might to work with a= > small advisory group (formed from people who are also heavily involved > in community discussions) so that it can confer on proposals for solvin= g > larger open issues (e.g., before sharing such proposals with the broade= r > community). Such a group could, of course, also include the RSA/E. Or > the RPC could just work directly with the RSA/E in such matters. >=20 > Third, since ongoing operation of RFC publication is envisioned to be > handled under arrangements between the LLC and the RPC, I would think > that some matters of projects and priorities would be subject to, say, > statements of work for particular projects that would be proposed by th= e > RPC and approved by the LLC. Alternatively, we could nudge the RSA/E role a bit closer to the old RSE role, and define that the RPC relies on the RSA/E as the intermediary= for all these points. Brian From nobody Sun May 9 17:40: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 CCFC93A2731 for ; Sun, 9 May 2021 17:39:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.2 X-Spam-Level: X-Spam-Status: No, score=-0.2 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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 LdUfqJIMr7UW for ; Sun, 9 May 2021 17:39:56 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3D4A3A2730 for ; Sun, 9 May 2021 17:39:55 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id b15so2101644plh.10 for ; Sun, 09 May 2021 17:39:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=kZHCZVi3FRmqjHnMwquplV1969L3esBQQI6vJirgE7Q=; b=U4PpmWyUZqh3BPWt7CY/huCtkjyBJd4PEEnWcYoq6lHDm3MN8puBL/xlXmmSKLVRB/ 3H7jylXyXx12oA3DaKd68DBWqzoOzDB6r+asLJbuQmVScv5wseRLFSVw60VztfKP4Vok mToCJLPnmuQKhPt+XrCscRwLypyZKJnfEgoTL+QQQJaWiE1FGZojyRZZ6kluPwwqVdZD 5XxBCb1Zr+HAECKMXLCA58OLTylPL0PH5l+VlfbLgdaAPS7l3MxOgaJbf2U35yqmD5oK iOJZJdjyiUEG0u/RehyLlqEbFmqUFABxc/ZhqOxYxm3zg3nqAqhifqe1dwXRtyPuzjlC D5ng== 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=kZHCZVi3FRmqjHnMwquplV1969L3esBQQI6vJirgE7Q=; b=Frglo2eYga1cS//Cqn3aRlrcBAidH0dJ0fMFJOG+6QqLVdswAR2kxX392v75Lt2+9h kfr5gHRY96WCBq8OfT0/IfJjVuMJOipUM4yYKGmZGAdDYjcWrZykORuuIXOMHYfGptlM mJJifbj+AkloPggY7GaD6lezENzOELQ0X81X3gmQNuMzVDpEAOjzPV7F5aNe/29PMcZ7 mPvRoPOLagJqDfiw5aNP9fOmJ5mWxE2RdeZpgg+eziPap46JHdSPcxoy00YJCzeb+E+e g+dTMVIiygTCcpPraUL7tiClinjZq+T7b1+E7Pl7MpW+HPHntifJkrxT4tNTuFRkaIdC H1cA== X-Gm-Message-State: AOAM530DntwSSW40Viqr6E92qf4SnDAWmrhSWkwtL3uXlqVI0YH3gKDa K5u4aUCvsxdNytgwzn6kRKrlL29OBEY= X-Google-Smtp-Source: ABdhPJw2mriJagLiouoMTzBSrKWSXCc7K+1iUyYXb1trLqJYzFI2pvJuxyWSkj3FT/nn8moaaewUMQ== X-Received: by 2002:a17:902:aa4c:b029:ee:ec17:89f with SMTP id c12-20020a170902aa4cb02900eeec17089fmr22127359plr.11.1620607194508; Sun, 09 May 2021 17:39:54 -0700 (PDT) Received: from [192.168.22.72] ([131.203.241.238]) by smtp.gmail.com with ESMTPSA id 5sm9673532pfi.43.2021.05.09.17.39.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 17:39:53 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> From: Brian E Carpenter Message-ID: Date: Mon, 10 May 2021 12:39:50 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 00:39:59 -0000 On 10-May-21 12:11, Michael StJohns wrote: > On 5/9/2021 3:26 PM, Peter Saint-Andre wrote: >> As a point of comparison, >> the IESG and IAB don't unilaterally publish RFCs, but they do publish >> statements and provide direction on smaller issues. >=20 > Hi Peter - >=20 > Are you saying that the IAB and IESG never publish "public statements" = > and "provide direction" in the form of RFCs? IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 as a canonical example: the IESG approved it as a BCP by standard process including IETF Last Call. The IAB co-signed it too, on its own authority. Brian >=20 > Also, not quite sure what you meant by unilateral here.=C2=A0 I've seen=20 both=20 > "here's what the IAB/IESG thinks" documents and "we've surveyed the=20 > community and here's what we think they think" documents.=C2=A0 Both ar= e=20 > documents originated by the appropriate group unilaterally, and for tha= t=20 > matter approved for publication unilaterally.=C2=A0 Yes, they take publ= ic=20 > comments, but the comments can't prevent publication. >=20 > Color me confused. >=20 > Mike >=20 >=20 From nobody Sun May 9 18:41: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 4D4933A2996 for ; Sun, 9 May 2021 18:41:53 -0700 (PDT) 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, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8QWBwaWBaSK for ; Sun, 9 May 2021 18:41:52 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F9B3A2995 for ; Sun, 9 May 2021 18:41:51 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id j19so10887235qtp.7 for ; Sun, 09 May 2021 18:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=1GalLb+a0jNBBhtfKuPTT8l8DQxsKhXynVtXo3C1Rug=; b=eGgigltXyDClm6bNagA7kOow+0uw42vh5o1aHyxqrtNRySvGz3Z78wwM6q1bj4hKzL 4/d9mE3kzTtqWbqRX0JCqWfyaNe2a9ifHtDKPObMuK5FyZzyhiCySAUJxb/rIn6/DJYY ndNCEZxVaPU2WUNRCIniLXFkLJS7tcvTGSfYOWThUVxivxxxbpw5LEKnbONVu8vORWBq cLPZL8980xJo5nteFWToSWcZUfUDMZiQQH+TW9Ek3Ev2wWtU6A8LaKZPpUDs2/sjGCGQ qAw/bi2LKGJUhhtSzYLPz6iFwaVnOUczO0RdWEsC3I4tUWwY5CWFy+460hG+eHMRf8+A 7ZlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=1GalLb+a0jNBBhtfKuPTT8l8DQxsKhXynVtXo3C1Rug=; b=Yi1OtsNH6TN3Y0pc1hb6WKUtF74HTmBBi9s442Z7jA2cOzLPRDmTCW7Hak5F+DPo2O 8JXk8qbon+WC/4ywrzbns0135IyD3iZxuJmsEsGYbTvsEUVvcKO8KfvAiljL0gBNM+fi Kkb6rpFs/Y7h3Pim77AtsvqhDBfNV3vXY4lJ4f4guPzJ8zq1OKGIKg6LGzjc1bM7xRD1 qdJFopXiVAigzv6vZqacsc2SFuD4tr2Pblq1uSsc4cD4IyA7v0yivSzQpCbP8VUCQooj +V58z+qBA/rUu2rLhDw1G9YY0QZemRlsBRJorDEcl5V2YZp9FtIx7JrBcX0zms+MTAIX um9A== X-Gm-Message-State: AOAM530JAk4PUDjg7GR87u3/inuiE4XtVPlxY7xa+tYIiR8HZzkpzPpq DCG+KoJB54aqiRZ/lYTLm1rm1EorsBO9Qhw9 X-Google-Smtp-Source: ABdhPJzkiP1eXSForj88Zm50nNzANQboL1QdD92k1gY0GGAIw+sBDzkXLqk6qnI/nxcpX+KehUhJpA== X-Received: by 2002:a05:622a:287:: with SMTP id z7mr15742726qtw.33.1620610909670; Sun, 09 May 2021 18:41:49 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id i24sm8157648qtm.72.2021.05.09.18.41.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 18:41:49 -0700 (PDT) To: Brian E Carpenter , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> From: Michael StJohns Message-ID: Date: Sun, 9 May 2021 21:41:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 01:41:53 -0000 On 5/9/2021 8:39 PM, Brian E Carpenter wrote: > IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 > as a canonical example: the IESG approved it as a BCP by standard > process including IETF Last Call. The IAB co-signed it too, on its > own authority. > > Brian A much better (and much more recent) counter example is draft-iesg-nomcom-eligibility-2020 which became RFC 8788. This was an IESG initiated document that solicited community input, but ultimately was published on the IESG's dime with their sole interpretation of community consensus. RFC6360.  RFC3932.  And RFC 3710 (the IESG charter). The point is that the IESG does this too.  And its not a bad thing, especially when we have 100 different opinions and we need a final answer sooner rather than later. I don't expect the RSAB to do a lot of internally originated documents, but I do expect there will be cases where a decision has to be made, and that there will be some immediacy necessary. Later, Mike From nobody Sun May 9 19:02: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 0A4643A2A33 for ; Sun, 9 May 2021 19:02:38 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Df3lSsiqHsbl for ; Sun, 9 May 2021 19:02:35 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB8A3A2A35 for ; Sun, 9 May 2021 19:02:35 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id z24so13340577ioi.3 for ; Sun, 09 May 2021 19:02:35 -0700 (PDT) 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=dSLRppm+BY+iX3JtTlE9ZExHZp3XuwFaUBD6qSj6y4c=; b=1EIJNOEw/gFkFAX/tlDc1NZ6nfa5Lr4cN24pE4ovUfVTSYSMlL126dcAGQoYj6Sliz wE34pxgfnB957HjlUEci6WpYjvUpTSFPZrF0UZYsrfV9ws424bHW9k39Ulp2roi7d0df GKzxV8KVd/IdDA0iwvwd7AsfjwmkrD0TCOBkDyk2Wv3TqmSnQ9DBStb0vhhS/lUgxTRn 5XaCdyHrTbIlaSMBRbMIogH5kGz02eLMK3fbX76QKrNpR+PSYLho/tf7+Du4MPm92rQ6 dPiy4tEdOivRc6oOmDiXFU/Kk/S4rSCOjLBz4CSjXMyBbpUPW6+IUDeZdT6afD9DkvQ6 Gerw== 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=dSLRppm+BY+iX3JtTlE9ZExHZp3XuwFaUBD6qSj6y4c=; b=OZmmBsn8GJzhSklDN3Muf78prdcliWcd3rtxjIzI57nkcKbh325N3kdLxSjhLxXhBS I3cpxMMNw1GD1aZfs1leIMPur1mAh/ZtYmPi5A9cwZnGU6wH2kpfL97o4BF2cuvzXQmS ajuCOuJKQW2SzmK856upEJHcM0qEyJ4Gr8XcTWkvzvCUknh08ZLQLwzdlxWVldSrzT8u rqWxgqwsxGOjIrk06D72DdXej4olRfiGIC4XOO6FquYQ9SkRPcRbww+3Nxz+LpKGzPBa M7cXAdD6n/382R665xi0F/kuPdxTXuUdAWp7RmHFBJscJreqUoFoo5Muh7GACSdXNNAb e9Wg== X-Gm-Message-State: AOAM532q5f4VUMIw5Sm7hD6n57jrwCnuBU9x+Ryv6j14n8WlPycC5zTE dkr08ryzuJfJoxoDaSGTJAKy05KyQZ7WvEhrPueeIw== X-Google-Smtp-Source: ABdhPJz768tcGQElMq7LUKC6EzeI4Wpl7ejGCCYozGCBuP4ee+UUlyd1M4wjkrk59gBLli+h6R5a4CR7BFy/kOBENCI= X-Received: by 2002:a5d:9b86:: with SMTP id r6mr1955854iom.43.1620612152667; Sun, 09 May 2021 19:02:32 -0700 (PDT) MIME-Version: 1.0 References: <724422DF-EB4D-46DD-A797-14BDE4121A73@ietf.org> <06a0985f-9f96-1754-ed45-ce75ff9ee672@mozilla.com> In-Reply-To: <06a0985f-9f96-1754-ed45-ce75ff9ee672@mozilla.com> From: Eric Rescorla Date: Sun, 9 May 2021 19:01:56 -0700 Message-ID: To: Peter Saint-Andre Cc: Jay Daley , rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000adcb8605c1f02b28" Archived-At: Subject: Re: [Rfced-future] Issue 60: Resolution of disputes between the RPC and authors with cross-stream implications X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 02:02:38 -0000 --000000000000adcb8605c1f02b28 Content-Type: text/plain; charset="UTF-8" On Sun, May 9, 2021 at 11:30 AM Peter Saint-Andre wrote: > On 5/5/21 6:39 PM, Jay Daley wrote: > > > Issue #60: Disputes between the RPC and authors sometimes need > escalating and in the proposed process the stream manager appears to be the > escalation point. However, if the dispute is about something that affects > all the streams, such as RFC style/policies, then it appears that this has > to be escalated to the RSAB. Is that correct and will the RSAB be able to > respond in a timely manner? > > Here again it would be good to understand broadly what kinds of disputes > we envision. My sense is that whereas deeper policy issues would likely > need to be taken up in the WG, for smaller issues that need a timely > resolution the RSAB would be the best initial escalation point because > all streams are represented there; however, after the issue is raised > with the RSAB it seems to me that the RSAB could ask one or more of the > RSAB members (which could be the RSA/E) to investigate and suggest a > resolution. > I'd also like to understand what kind of disputes are envisioned here. Like what's the last one that couldn't be,handled by the stream manager. --000000000000adcb8605c1f02b28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, May 9, 2021 at 11:30 AM Peter= Saint-Andre <stpeter@mozilla.com= > wrote:
= On 5/5/21 6:39 PM, Jay Daley wrote:

> Issue #60:=C2=A0 Disputes between the RPC and authors sometimes need e= scalating and in the proposed process the stream manager appears to be the = escalation point.=C2=A0 However, if the dispute is about something that aff= ects all the streams, such as RFC style/policies, then it appears that this= has to be escalated to the RSAB.=C2=A0 Is that correct and will the RSAB b= e able to respond in a timely manner?

Here again it would be good to understand broadly what kinds of disputes we envision. My sense is that whereas deeper policy issues would likely
need to be taken up in the WG, for smaller issues that need a timely
resolution the RSAB would be the best initial escalation point because
all streams are represented there; however, after the issue is raised
with the RSAB it seems to me that the RSAB could ask one or more of the
RSAB members (which could be the RSA/E) to investigate and suggest a
resolution.

I'd also like to unders= tand what kind of disputes are envisioned here. Like what's the last on= e that couldn't be,handled by the stream manager.
--000000000000adcb8605c1f02b28-- From nobody Sun May 9 19:32: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 4AE3C3A2B48 for ; Sun, 9 May 2021 19:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5YAzwn1Pcw_z for ; Sun, 9 May 2021 19:32:41 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 751773A2B47 for ; Sun, 9 May 2021 19:32:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4FdlT41KJvz1ntgK; Sun, 9 May 2021 19:32:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1620613960; bh=01wkF7fpkE9xj2uaviz53FmZ0SS6g0lc2u7Y1xOnXLw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=XGomwL5lM9Lx66ZU4Awu+vT5NgF9g6EJ2CobDQ8TjYFLhi49SMF9Wl9ZquWZhg4Zk 06chpLizWHRbjiS/ccHeo/6gsZ5xfH1AuRQF6PaO0Wh6RHnP1w+XXg28kvvwO0wURj 60mEFzubFUlHNu2OEPxO95wF0WYUnvLHvo19t590= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4FdlT34Nxzz1ntQR; Sun, 9 May 2021 19:32:38 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> From: "Joel M. Halpern" Message-ID: <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> Date: Sun, 9 May 2021 22:32:38 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.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] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 02:32:47 -0000 Mike, your analysis seems a bit flawed. Yes, the IESG approved those documents after community consultation, on the basis that the community had agreed. And yes, that judgement was made by the IESG. On the other hand, if the community members had thought the IESG conclusion was wrong, that was appealable to the IAB. That is very different from declaring that the RSAB can publish a document without community approval. And given the structure that is proposed, there seems much less reason for any process that bypasses the working group. I think everyone knows that I do not like the current approach. But I can live with it. And it seems to be the approach the community wants. Creating strawmen as obstacles does not seem helpful. Yours, Joel On 5/9/2021 9:41 PM, Michael StJohns wrote: > On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >> IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 >> as a canonical example: the IESG approved it as a BCP by standard >> process including IETF Last Call. The IAB co-signed it too, on its >> own authority. >> >>     Brian > > A much better (and much more recent) counter example is > draft-iesg-nomcom-eligibility-2020 which became RFC 8788. > > This was an IESG initiated document that solicited community input, but > ultimately was published on the IESG's dime with their sole > interpretation of community consensus. > > RFC6360.  RFC3932.  And RFC 3710 (the IESG charter). > > The point is that the IESG does this too.  And its not a bad thing, > especially when we have 100 different opinions and we need a final > answer sooner rather than later. > > I don't expect the RSAB to do a lot of internally originated documents, > but I do expect there will be cases where a decision has to be made, and > that there will be some immediacy necessary. > > Later, Mike > > > From nobody Sun May 9 19:58:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 408243A085C for ; Sun, 9 May 2021 19:58:42 -0700 (PDT) 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, 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 LHvmiMxddoNJ for ; Sun, 9 May 2021 19:58:37 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 08E623A0853 for ; Sun, 9 May 2021 19:58:36 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id c10so1165732qtx.10 for ; Sun, 09 May 2021 19:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=wIXwIiumOf+yfZGcVijd1vTxdLp84MjOdYvIYv6HkWU=; b=hO6j1Aie6TUtKLhkmr/cFQ9U52cAKGnROYU01EAOT7ambfM2rJW0zlobgfM/XGxTzA JAax3WiNcG5mUXBdtvI3UvybTjdnWaPLBtCKR5KV3WVfEmWelPyFMP//al/MRZSieBqh qvxUSvpIL/HVgY9/+hoOAkAP7OrLF6Ssk2XHBTm5+VBbiypB+dIlEG+7TZ66E9lq6ffc pMtsXTlr/K0g/vhPDVWYsK4y3M7zrvpXqa1RdZ3Gdk5/XWY3/ctqWSKLqHFUMVKrD0Rv L9E6ThjLN0MBaVaCxtbyL25dzxXnapalOdZVFX5rHwS4o7AcdrO2c2RJA58qrijFZtvg BSTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=wIXwIiumOf+yfZGcVijd1vTxdLp84MjOdYvIYv6HkWU=; b=FOW2jrH+F0+ldzTH2yMff5UDfuI+w5VC3lmRCO4LUnNtBKVFZT9qPUVtJHOSGGHatH xidaCMGYCLl91uQy87RjPWte0lSTGKn46Bwkh6h5P7bfxnEuR2BH7EghxLQZQLpro91r UhlDZv81qdAzLsnODNfyB++vEgRzxMQlB0XVc3RTfxOMUOYQcWavdz3mK1UzJCJ+QFki dIqz9LwbvKlriEEGBq++bvmza+GSqIbB6EHFMztfrfHl0WxcbcatRwMnt/fyopP/cbgY jnUPL8mW0hz35UILdtEuXXs6K38pzMZ0uR1nhYCJm0tl78+Oh2eR+gTZxVvdtCAqyC6Z jmqg== X-Gm-Message-State: AOAM532uaWkR5OBtpWvVnoB0g8I69xgARrAsXbD9WAnWHuEegUXLpFLB Tti7rHLwPbf1NKmcrQFHZXJH5szdOAnCpfhP X-Google-Smtp-Source: ABdhPJzZgCGTfc5wl7/c+JA0t6mZOqKkkSAOjM4l6YE8m3jiRUq4P9oYOidBLWULGfmJhDDtdiFeQA== X-Received: by 2002:a05:622a:2c9:: with SMTP id a9mr6075306qtx.38.1620615514392; Sun, 09 May 2021 19:58:34 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id i10sm9783567qko.68.2021.05.09.19.58.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 19:58:33 -0700 (PDT) To: "Joel M. Halpern" , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> From: Michael StJohns Message-ID: <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> Date: Sun, 9 May 2021 22:58:32 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 02:58:42 -0000 On 5/9/2021 10:32 PM, Joel M. Halpern wrote: > Mike, your analysis seems a bit flawed. > Yes, the IESG approved those documents after community consultation, > on the basis that the community had agreed. > And yes, that judgement was made by the IESG. > > On the other hand, if the community members had thought the IESG > conclusion was wrong, that was appealable to the IAB. The way I've always understood it is that process can be appealed with some possibility of a reversal, but a decision that follows the process, no matter whether some community members thought it was the wrong decision, is unlikely to be reversed. > > That is very different from declaring that the RSAB can publish a > document without community approval. See above.  AFAICT, there were folks in opposition to the Nomcom decision, but the community was heard.  I'm not saying that the community will not be heard, but I'm saying - similar to what the IESG did with documenting the Nomcom decision - that individual members or even a small subsection of the community should not have a veto over the publication of documents that the RSAB believes necessary for the operation of the streams. > And given the structure that is proposed, there seems much less reason > for any process that bypasses the working group. WGs by their nature are self-selected and generally consist of a small percentage of the overall community with strong opinions about the topics covered by the WG (with the active participants being even somewhat smaller).   When the scope is small enough - e.g. DNSOP for example - the community affected by the decisions will mostly mirror the community represented by the WG.  When the scope is large enough - e.g. Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of the WG represent the best results for the community of the whole.  In the Nomcom case, we were able to gather a reasonably large group of people (in the form of a WG)  of diverse views for a sufficient time (multiple times) to spend a very large amount of effort to craft and recraft the Nomcom process.  But that differs from this proposed WG in that the various Nomcom related WGs had well defined target outputs and a need to complete in a reasonably short period of time (by IETF standards at least). I'm trying to avoid us replacing the RSOC with the RSWG - but I can't see how we can get enough diversity of interest for an indefinite period of time to ensure that the RSWG continues to operate as a useful source of community involvement rather than a place for a small number of self-selected folk to have an overly large continuing impact on a process that's absolutely critical to the community's success.  Nor has any one been willing to address that specific point. Peter did say: > Yes, there are failure modes where the WG is inactive (in which case > we'd need to inject more energy) or unable to reach consensus (in which > case we'd need to work harder to do so), But I would ask who the "we'd" is in the above?  e.g. once this group dissolves in favor of the new structure, who has the responsibility of fixing things if the WG structure fails or devolves?  Are we going to be back here in 4 years?  Or does the RSAB go on its merry way and do what it needs to do?  If not, who reconstitutes the next RFCED-Futures group given that we will have taken the IAB out of the picture?  The RSAB? > > I think everyone knows that I do not like the current approach. But I > can live with it.  And it seems to be the approach the community wants. Or at least the 1/2 dozen or so people who have argued for the approach - not sure that's the community. > Creating strawmen as obstacles does not seem helpful. And thanks for that denigrating comment.   You might not like what I'm saying nor agree with them, but calling them strawmen implies that they are there simply to providing a blocking issue and they have no basis in reality and that I'm doing that simply to screw up what process there is. Mike > > Yours, > Joel > > On 5/9/2021 9:41 PM, Michael StJohns wrote: >> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>> IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 >>> as a canonical example: the IESG approved it as a BCP by standard >>> process including IETF Last Call. The IAB co-signed it too, on its >>> own authority. >>> >>>     Brian >> >> A much better (and much more recent) counter example is >> draft-iesg-nomcom-eligibility-2020 which became RFC 8788. >> >> This was an IESG initiated document that solicited community input, >> but ultimately was published on the IESG's dime with their sole >> interpretation of community consensus. >> >> RFC6360.  RFC3932.  And RFC 3710 (the IESG charter). >> >> The point is that the IESG does this too.  And its not a bad thing, >> especially when we have 100 different opinions and we need a final >> answer sooner rather than later. >> >> I don't expect the RSAB to do a lot of internally originated >> documents, but I do expect there will be cases where a decision has >> to be made, and that there will be some immediacy necessary. >> >> Later, Mike >> >> >> From nobody Sun May 9 20:01: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 055903A08E4; Sun, 9 May 2021 20:01:51 -0700 (PDT) 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=[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 V4uP_1POr-cw; Sun, 9 May 2021 20:01:46 -0700 (PDT) Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 663FC3A08DA; Sun, 9 May 2021 20:01:45 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) From: Jay Daley In-Reply-To: <2dfd7a8e-f8ec-daa1-18e4-210ec82123d4@gmail.com> Date: Mon, 10 May 2021 15:01:41 +1200 Cc: Peter Saint-Andre , Eliot Lear , rfced-future@iab.org Content-Transfer-Encoding: quoted-printable Message-Id: <2FB112F5-88EC-4538-A77E-BFBCCBAB232B@ietf.org> References: <2dfd7a8e-f8ec-daa1-18e4-210ec82123d4@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.3608.120.23.2.4) Archived-At: Subject: Re: [Rfced-future] Issue 56: Process for RPC work not requiring consensus X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 03:01:51 -0000 On 10/05/2021, at 12:28 PM, Brian E Carpenter = wrote: >=20 > =EF=BB=BFOn 10-May-21 06:07, Peter Saint-Andre wrote: >>> On 5/6/21 2:12 AM, Eliot Lear wrote: >>> Hi there, >>>=20 >>>> Issue #56: The RSWG/RSAB process is clear for larger projects but = the RPC also need a path for discussion and agreement on smaller things = that do not require a consensus process. Previously the RPC would = discuss and agree these with the RSE, with the RSE taking the decision = on what meets the threshold for taking to the community. How are those = agreed now and who decides what does and does not need community = consensus/engagement? >>>=20 >>>=20 >>> With regard to this issue, as well as 57, 58, and 59, these seem to = articulate a point that was raised in Issue 23 (=E2=80=9CWhat is = strategic?=E2=80=9D). What I propose to do is to close 23 in favor of = us using your pragmatic issues. >>>=20 >>> But we should maintain the context of thinking around that issue. I = believe the intent of the WG at this point was for the overarching = policy and procedure to be set by the RFGWG, but for the implementation = of that policy to rest entirely with the RPC. While the RPC should be = free and even be encouraged to consult the RS[EA], the decision is with = the RPC. It is not a negotiation. This is my understanding of the = group view, based on previous discussions. While I don=E2=80=99t = believe we=E2=80=99ve discussed this explicitly, it seems reasonable for = the RPC to periodically=20 > report on those activities to the RFCWG. >>>=20 >>> There will occasionally be ambiguities. Here, I believe the = group=E2=80=99s view is one of =E2=80=9Cbetter to ask forgiveness than = permission=E2=80=9D in those circumstances. That is- the RPC is = empowered to act, but=20 > then should report the ambiguity to the RFCWG, as the RFCWG process is = expected to be rather laborious. Again, consultation with the RS[EA] = encouraged. >>=20 >> In his reply to this message, Joel raises a concern about a change in >> the RPC's role. It would be good for Sandy perhaps to provide her >> perspective, but my recent experience working through open issues >> related to v3 of the XML vocabulary in collaboration with Sandy and >> Alice is that they often find it helpful to confer with someone (or a >> small team) regarding issues that crop up. These aren't large policy >> issues of the kind that we've envisioned working through in the = RFCWG, >> but they benefit from informed and focused discussion. However, it's = not >> clear to me whether the RFC Editor Model needs to define a formal >> structure for such discussions, since I think they could be defined = by >> the RPC in an ad-hoc way (e.g., through an informal technical or >> editorial advisory team). >=20 > I think the RPC is effectively asking "Who do we talk to when we can't > decide on our own?" and to me the obvious answer is "The RSA/E". Do we > need to say more? No that=E2=80=99s answering their question orthogonally. Under the = current model, the RSE has authority to decide what requires community = consultation and what doesn=E2=80=99t, which gives us a clean split = between decider (RSE) and implementer (RPC). The answer is about who = decides that now and if that is to be the RPC then it should be made = clear. If any guidelines are to be provided then the priority should be = principles to use when determining where to draw the line rather than = who to consult with. Jay --=20 Jay Daley IETF Executive Director >=20 > Brian >=20 >>> Is my understanding of people=E2=80=99s views here off? I believe = the=20 > text in draft-saintandre-rfced-model is consistent with this position, = but could do with a tad more elaboration along these lines. >>=20 >> I wouldn't put much stock in the current text. :-) My intent is to >> update that document once we've reached something close to consensus = via >> discussion on this list. >>=20 >> Peter >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Sun May 9 20: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 B7C8B3A0CFC for ; Sun, 9 May 2021 20:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.198 X-Spam-Level: X-Spam-Status: No, score=-0.198 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z1s5Sh_uWSRP for ; Sun, 9 May 2021 20:55:50 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5590B3A0CFA for ; Sun, 9 May 2021 20:55:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4FdnK15gm0z1ntgK; Sun, 9 May 2021 20:55:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1620618949; bh=ZYoBWRHVRKOMGiOCWw93e00Yr6v9ZQ5xXHIYYptl2pg=; h=Subject:To:References:From:Date:In-Reply-To:From; b=M96pM0jlwbCtHakp0cw0ZaH8pvUC7m3S2MmE38tkSP3BfCj6Nuo/RZOK3YdoZj+sK BschQ6B9g8DsAMWt9HuOXSpevKZHoPec95Vcl2wlvuaCvF9n7BnH97Xonx40AN1r8j Pb4x6oj9synzcc0N6G/bueeU7imOrviDyh9CKCY8= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4FdnK11m2Xz1nsxM; Sun, 9 May 2021 20:55:48 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> From: "Joel M. Halpern" Message-ID: Date: Sun, 9 May 2021 23:55:47 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 03:55:55 -0000 Buried in the below is an interesting and important point. Suppose that we work out a process, agree to it, and try it. And it fails. (For any number of possible meanings of "fail".) Who has the authority to decide something needs to be done? Who has the authority to make something happen. Under current rules, whether we like them or not, the authority for what we are doing comes from the IAB, via the RFCs that say it is the IABs job. It seems to me that Mike's point below about who has the ultimate authority is important. And at that point, I don't think "the community" is a viable answer. Yours, Joel PS: I am sorry you do not like my usage of strawman Mike. But the premise for your objection is sufficiently vague that I do not know what else to call it. If the only purpose of your description was to get to the "who has authority to fix things if they are broken", then as above, I agree that is an important question. I was completely unable to get to that issue from what you wrote. In particular, I could not connect that with your conclusion that the RSAB should be empowered to bypass the RSWG. On 5/9/2021 10:58 PM, Michael StJohns wrote: > On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >> Mike, your analysis seems a bit flawed. >> Yes, the IESG approved those documents after community consultation, >> on the basis that the community had agreed. >> And yes, that judgement was made by the IESG. >> >> On the other hand, if the community members had thought the IESG >> conclusion was wrong, that was appealable to the IAB. > > The way I've always understood it is that process can be appealed with > some possibility of a reversal, but a decision that follows the process, > no matter whether some community members thought it was the wrong > decision, is unlikely to be reversed. > >> >> That is very different from declaring that the RSAB can publish a >> document without community approval. > > See above.  AFAICT, there were folks in opposition to the Nomcom > decision, but the community was heard.  I'm not saying that the > community will not be heard, but I'm saying - similar to what the IESG > did with documenting the Nomcom decision - that individual members or > even a small subsection of the community should not have a veto over the > publication of documents that the RSAB believes necessary for the > operation of the streams. > > >> And given the structure that is proposed, there seems much less reason >> for any process that bypasses the working group. > > WGs by their nature are self-selected and generally consist of a small > percentage of the overall community with strong opinions about the > topics covered by the WG (with the active participants being even > somewhat smaller).   When the scope is small enough - e.g. DNSOP for > example - the community affected by the decisions will mostly mirror the > community represented by the WG.  When the scope is large enough - e.g. > Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of > the WG represent the best results for the community of the whole.  In > the Nomcom case, we were able to gather a reasonably large group of > people (in the form of a WG)  of diverse views for a sufficient time > (multiple times) to spend a very large amount of effort to craft and > recraft the Nomcom process.  But that differs from this proposed WG in > that the various Nomcom related WGs had well defined target outputs and > a need to complete in a reasonably short period of time (by IETF > standards at least). > > I'm trying to avoid us replacing the RSOC with the RSWG - but I can't > see how we can get enough diversity of interest for an indefinite period > of time to ensure that the RSWG continues to operate as a useful source > of community involvement rather than a place for a small number of > self-selected folk to have an overly large continuing impact on a > process that's absolutely critical to the community's success.  Nor has > any one been willing to address that specific point. > > Peter did say: > >> Yes, there are failure modes where the WG is inactive (in which case >> we'd need to inject more energy) or unable to reach consensus (in which >> case we'd need to work harder to do so), > But I would ask who the "we'd" is in the above?  e.g. once this group > dissolves in favor of the new structure, who has the responsibility of > fixing things if the WG structure fails or devolves?  Are we going to be > back here in 4 years?  Or does the RSAB go on its merry way and do what > it needs to do?  If not, who reconstitutes the next RFCED-Futures group > given that we will have taken the IAB out of the picture?  The RSAB? > >> >> I think everyone knows that I do not like the current approach. But I >> can live with it.  And it seems to be the approach the community wants. > Or at least the 1/2 dozen or so people who have argued for the approach > - not sure that's the community. >> Creating strawmen as obstacles does not seem helpful. > > And thanks for that denigrating comment.   You might not like what I'm > saying nor agree with them, but calling them strawmen implies that they > are there simply to providing a blocking issue and they have no basis in > reality and that I'm doing that simply to screw up what process there is. > > > Mike > > > >> >> Yours, >> Joel >> >> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>> IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 >>>> as a canonical example: the IESG approved it as a BCP by standard >>>> process including IETF Last Call. The IAB co-signed it too, on its >>>> own authority. >>>> >>>>     Brian >>> >>> A much better (and much more recent) counter example is >>> draft-iesg-nomcom-eligibility-2020 which became RFC 8788. >>> >>> This was an IESG initiated document that solicited community input, >>> but ultimately was published on the IESG's dime with their sole >>> interpretation of community consensus. >>> >>> RFC6360.  RFC3932.  And RFC 3710 (the IESG charter). >>> >>> The point is that the IESG does this too.  And its not a bad thing, >>> especially when we have 100 different opinions and we need a final >>> answer sooner rather than later. >>> >>> I don't expect the RSAB to do a lot of internally originated >>> documents, but I do expect there will be cases where a decision has >>> to be made, and that there will be some immediacy necessary. >>> >>> Later, Mike >>> >>> >>> > From nobody Sun May 9 22: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 8933B3A110C for ; Sun, 9 May 2021 22:06:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 fJ9vX7eCLf8J for ; Sun, 9 May 2021 22:06:00 -0700 (PDT) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91ED13A1108 for ; Sun, 9 May 2021 22:05:59 -0700 (PDT) Received: by mail-qt1-x82d.google.com with SMTP id y12so11102983qtx.11 for ; Sun, 09 May 2021 22:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=+eyUH+JuTMQSXBBU3HJZcrXHQlRlcuAY6JE8zeMRpeQ=; b=AnO6xBeYeLglyXrLjVbIdK7yxrOuvreec2Fwu2PpirEJLF8CNmyuq/7MY5zyyM/2uX FQkxWtcSad1OmVrZkcNjVYvERLafWmA6OOgKbvsuMIMQZRre3kYyVegSWcy6Gh0tiTeF kRPvtdMbJp7x8QU4vD8SrC4OxYzicffwN7CyfMYNdme66maFSCVco/kPNPZ6rt2x4AAc qaTbcs8TkJdqrLoG4dOizNBvbs5aDTTbjOkpDm1kVflE9uDhWsCp0asB2cxcuZ5JH5FD 0zRke7Ln/UiEU5fKfHSBrFwqftDE+vAy82aLs7pEfPLjR3jTeaN5PMPwRZ1tL6ofO351 Lw2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=+eyUH+JuTMQSXBBU3HJZcrXHQlRlcuAY6JE8zeMRpeQ=; b=g8Ok8nJ9RmoDdZt/wrFmHg2FdGsl5ZCmtk0N+zWHvpc7RouvyiUbHZwXDbAC+Y0P3F 9jf+OYfSjl6h6RovxgPvBJsvMd4dBQqUHAMaasHqmGCp88I/QsNa06VBjr1tjOKswOSC p7dnntj8BvJ51vPRoIljnbN+jF0voyRSgRAgFUF8IgfiaktoTuYxjZTXvu0cQMUp6Ygl wCj608Kcw1kPV8UicREh0hXQymqyUkaw/dhHIzL2bbj5yX5bpHQi3HznEjQ/X/JYj+Pc h/2+U0xQLXwEMv9RqIXfaugZ7YG9lqnLrQog/sVHREm/aEA1ns3S0v5OXWmHyqXf5Bbc dlOA== X-Gm-Message-State: AOAM531ysKSGmah7coCM/52KbAwCSYBqxLJ/p4Z1tt5AbwlVT7PzeUM9 ptIcx2xiQbDbw1kt2ZCg95/JJ7lO6iGtldvD X-Google-Smtp-Source: ABdhPJw1WGwqBiOg8+wa2pkmlcqwTTd1BUQzF2dITEUKfefx7Ed+Ep3G4rLxkdHGxVqnG6huuhQ7jA== X-Received: by 2002:ac8:7fc7:: with SMTP id b7mr21158628qtk.109.1620623156936; Sun, 09 May 2021 22:05:56 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id d11sm3401660qke.61.2021.05.09.22.05.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 22:05:56 -0700 (PDT) To: "Joel M. Halpern" , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> From: Michael StJohns Message-ID: <845c2898-60ed-42cb-0b13-b4e28f76d2bf@nthpermutation.com> Date: Mon, 10 May 2021 01:05:55 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 05:06:06 -0000 Trimming On 5/9/2021 11:55 PM, Joel M. Halpern wrote: > Buried in the below is an interesting and important point. > Suppose that we work out a process, agree to it, and try it.  And it > fails.   (For any number of possible meanings of "fail".) > > Who has the authority to decide something needs to be done?  Who has > the authority to make something happen.  Under current rules, whether > we like them or not, the authority for what we are doing comes from > the IAB, via the RFCs that say it is the IABs job. > > It seems to me that Mike's point below about who has the ultimate > authority is important.  And at that point, I don't think "the > community" is a viable answer. > > Yours, > Joel > > PS: I am sorry you do not like my usage of strawman Mike.  But the > premise for your objection is sufficiently vague that I do not know > what else to call it.  If the only purpose of your description was to > get to the "who has authority to fix things if they are broken", then > as above, I agree that is an important question.  I was completely > unable to get to that issue from what you wrote.  In particular, I > could not connect that with your conclusion that the RSAB should be > empowered to bypass the RSWG. Strange - I thought I'd made that point (that I believed that there was sufficient possibility that the RSWG would fail after a time, and that the RSAB might be left to go it alone) multiple times. Here's my reasoning on your last sentence - which I'm going to restate as: "The RSAB should be empowered to protect the process and publish documents which it believes are necessary to the reasonable and efficient operation of the RFC publication system in the event that the RSWG is either unwilling, or unable to complete those documents." 1) The RSAB is the approver of documents published within this stream.  (I *think* we've come to that conclusion, even if we haven't finalized the RSAB composition. 2) The minimum RSWG consists of the RSAB plus the two RSWG chairs.  The mailing list may be larger, but the actual active participants may be very close to that minimum set (at least after the initial burst of activity). 3) The RSAB members are considered equal participants in the RSWG to any other self-selected participant. 4) If there is an inability to derive consensus in the RSWG, and there are major decisions that need to be made, then the RSAB bears the responsibility for making them, but still must at least inform the community and ask for input before making such decisions. 5) If the RSWG consensus is against the RSAB position, then the RSAB should be able to appeal to the broader community citing "necessity" and explaining why the RSWG position may be flawed, but see (1). 6) 90% of what the RSAB does will not involve the publication of a document in the stream, and the RSWG will have no input in things that aren't related to that document publication. Every year, the US Congress has to pass various budget and appropriations bills which get signed by the president.  If they don't, the US government shuts down which it has done several times due to various deadlocks and disagreements from the two sides.   It would be a Good Thing (tm) if the RFC series did not have to shut down because of an inability to come to an agreement within the RSWG. I hope that helps explains my reasoning. Later, Mike From nobody Sun May 9 22:09: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 E27843A1126 for ; Sun, 9 May 2021 22:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cREu7ZxpgSj5 for ; Sun, 9 May 2021 22:09:06 -0700 (PDT) Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D40BC3A1123 for ; Sun, 9 May 2021 22:09:06 -0700 (PDT) Received: by mail-pl1-x62c.google.com with SMTP id 69so3926877plc.5 for ; Sun, 09 May 2021 22:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Df2I7jf6Rt4nT4X+Z3jd0O9dYH2cgeJ+bZivHR7voH4=; b=BwVbamUP+Gvs+TsZ8YQGXqtpskpXT4xT+3qa8hegaU2wDah7lLDKoXDqW6q8ROjaG/ hUSY7/8yGJs8RpL27V2Z/b6w/y1qa14OI6fbA2GsWdeyEWXC4SYfeYX6+EvvqcUi2cgZ EgPW0NTkRDjgPRVEPxNEVli1th1VwHamZMQsgT4wjEmDNXZEzVMeZgIEW7EV1wcWr0i0 oqzpYH0pDtdRusTTYQ0xsBewYoLmnVVBPSMt0c6NHXR9gtUro5U4vNtY7w3dPTNAgj6u AuFLLMYnPCVeur2B2pQczqjemmdCKJk/oo+H8Mpk9UhXywNqHOgTmnmG1ASBYpiMpv3E JLqw== 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=Df2I7jf6Rt4nT4X+Z3jd0O9dYH2cgeJ+bZivHR7voH4=; b=ke5K6gs0ayzQCnBi9RDjS2TiwgiytEPjNzBd2lTfLBMzj0enircPE2xiqa0d9lzR9X 5+/4/6rCO2iNQHX1YnPVAX9dda4yUi2raF1nrSt6n2ApoNfwIJudJm8ySA7HiUJrPsv2 5RlBWbM3eGKarpVKzdTPiXg/yX5YbBwGQA1Uz4MBpyuQJhEcMZC6tYOgZZpxzwoOz9Uf LHT0IDxrpMMKslAwfMFfXJ07+jlGSAQQ+yu2dgBUlmEU0aLE0+bWvFQk3KPvnROQkRwR LsaxP5oAOrKiXVnFCybe2BV2aynz7r7OWV20qPTgf2RZNGa+WomOGG8wFUkoo0jlfYsw 33DQ== X-Gm-Message-State: AOAM531GRqOoyhXaAdNw1l40qEm8937Xv7P5rWMdz7xZqlAXakUd+pMO huZtg8kDJx44xLIPurvIYM9URkP9/VVzMw== X-Google-Smtp-Source: ABdhPJzOYeC3t4L9nUX6doIxirwdk58/2Gtw94ZjlvGrISlh+AmEcx7JJnX25FjIOX/Mgb96h288YA== X-Received: by 2002:a17:902:b082:b029:ed:93dc:e6f9 with SMTP id p2-20020a170902b082b02900ed93dce6f9mr22289419plr.16.1620623344471; Sun, 09 May 2021 22:09:04 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id w81sm9901961pfc.106.2021.05.09.22.09.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 22:09:04 -0700 (PDT) To: Michael StJohns , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> From: Brian E Carpenter Message-ID: <7f514278-c055-b5cb-3dca-67f81ad492bd@gmail.com> Date: Mon, 10 May 2021 17:09:00 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 05:09:10 -0000 On 10-May-21 13:41, Michael StJohns wrote: > On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >> IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 >> as a canonical example: the IESG approved it as a BCP by standard >> process including IETF Last Call. The IAB co-signed it too, on its >> own authority. >> >> Brian >=20 > A much better (and much more recent) counter example is=20 > draft-iesg-nomcom-eligibility-2020 which became RFC 8788. >=20 > This was an IESG initiated document that solicited community input, but=20 > ultimately was published on the IESG's dime with their sole=20 > interpretation of community consensus. Yes, like *any* AD-sponsored draft BCP that didn't come from a WG, with a 4-week IETF Last Call, sent on 2020-04-02, closing 2020-04-30. > RFC6360.=C2=A0 RFC3932.=C2=A0 And RFC 3710 (the IESG charter). >=20 > The point is that the IESG does this too.=C2=A0 And its not a bad thing= ,=20 > especially when we have 100 different opinions and we need a final=20 > answer sooner rather than later. Agreed, but it doesn't side-step the IETF consensus process, which you seemed to be implying. Brian =20 > I don't expect the RSAB to do a lot of internally originated documents,=20 > but I do expect there will be cases where a decision has to be made, an= d=20 > that there will be some immediacy necessary. >=20 > Later, Mike >=20 >=20 >=20 > . >=20 From nobody Sun May 9 22:14: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 92E233A115E for ; Sun, 9 May 2021 22:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3gTntaYfEqGr for ; Sun, 9 May 2021 22:14:49 -0700 (PDT) Received: from mail-pl1-x632.google.com (mail-pl1-x632.google.com [IPv6:2607:f8b0:4864:20::632]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D2E3A115D for ; Sun, 9 May 2021 22:14:49 -0700 (PDT) Received: by mail-pl1-x632.google.com with SMTP id b21so8577486plz.0 for ; Sun, 09 May 2021 22:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=44ZdopC8M2ypsxcPH2eytsLL1ytOhwcnvQc8QtZM92c=; b=rltjMZFuyam0Lcl/+E7CO40pNAHfSe2Q8JiuWFYsud1R50IBPl3d44+yoABaCLzWjr 7vSZnSqvgWiqVTHl7zMeRNPR5FIjFRSvWRxhTc33/uiyDpBK3GVA0nIrBvbhx7beg+Ti TgMVHlm3qCGHyIDUj/RLHrbSQQriw8G/n5qLItMd5mXdm8hl56Kaj+lh2mB7kxQ9n1qj p6pUFzoKRIA/0B2Am2SsSbY8w9Uv93Mq22yXTHtL3e+RTr5FsmUUoDh5EGrjCEajF8OQ oR8oLAWpupMNPh5pHp3uBL8J5ajH+7yHJGpn8BjDGQAniXLwQR7i8ubE5SHwMZC3GCbd 2M1w== 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=44ZdopC8M2ypsxcPH2eytsLL1ytOhwcnvQc8QtZM92c=; b=VULXeIaCBONV4FtAVyJhSIin5DNv/5noYINZc7pOkPP9yUbABY22ZNfT3C46YX3c6i bsWUZVghamNmR9rVH3WpypvkiR2VyWI2Wx0s7w0MH511xKj3g/OnAaaD4W+bc+J7TF8A wTTT5roNMNRuY7qL6wzATpMnR2wonIL8NF5ur8Dg+u1WK6pOXeCoKwdU+Z+yGJOf4KUT YOYN8lIBrrY8oKM/S3EGz+D19MOauBXHVC6U1RPzkeqaFR338mC7EtxAojAXBsbvlcJ5 cbL4IWeps2T17XIrExB/45libyw7mLCplyLuExXvJMjH1lrhDZ4hhxonXTAZrGGXUSlG eYVg== X-Gm-Message-State: AOAM532v3rKLOyZ6wMk0KzH4VqwOfLGzHMjAise0jw3HMHjtZERpBp+L dIVMT8cendLkW7L+Mh12we9yuhzLbdLQpA== X-Google-Smtp-Source: ABdhPJypporAUR6P4VjuD6oNxfn8BFQ6W5FLziEcijEgqfaa6INd9sYtyG0k2v28+St02MLw48V+nw== X-Received: by 2002:a17:902:cec5:b029:ee:d673:8fd0 with SMTP id d5-20020a170902cec5b02900eed6738fd0mr22450994plg.59.1620623687671; Sun, 09 May 2021 22:14:47 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id f201sm9959182pfa.133.2021.05.09.22.14.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 22:14:47 -0700 (PDT) To: "Joel M. Halpern" , Michael StJohns , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> From: Brian E Carpenter Message-ID: <008e8a7f-ba99-43d1-6e10-711660961404@gmail.com> Date: Mon, 10 May 2021 17:14:43 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 05:14:55 -0000 On 10-May-21 15:55, Joel M. Halpern wrote: > Buried in the below is an interesting and important point. > Suppose that we work out a process, agree to it, and try it. And it=20 > fails. (For any number of possible meanings of "fail".) >=20 > Who has the authority to decide something needs to be done? Who has th= e=20 > authority to make something happen. Under current rules, whether we=20 > like them or not, the authority for what we are doing comes from the=20 > IAB, via the RFCs that say it is the IABs job. >=20 > It seems to me that Mike's point below about who has the ultimate=20 > authority is important. And at that point, I don't think "the=20 > community" is a viable answer. Yes, that seems like a correct analysis. And, if we succeed in clearly separating the operational and financial aspect and making that the LLC's responsibility, I'm inclined to reverse myself compared to some months ago and put the IAB in the chain of responsibility above the RSAB. Brian >=20 > Yours, > Joel >=20 > PS: I am sorry you do not like my usage of strawman Mike. But the=20 > premise for your objection is sufficiently vague that I do not know wha= t=20 > else to call it. If the only purpose of your description was to get to=20 > the "who has authority to fix things if they are broken", then as above= ,=20 > I agree that is an important question. I was completely unable to get = > to that issue from what you wrote. In particular, I could not connect = > that with your conclusion that the RSAB should be empowered to bypass=20 > the RSWG. >=20 > On 5/9/2021 10:58 PM, Michael StJohns wrote: >> On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >>> Mike, your analysis seems a bit flawed. >>> Yes, the IESG approved those documents after community consultation, = >>> on the basis that the community had agreed. >>> And yes, that judgement was made by the IESG. >>> >>> On the other hand, if the community members had thought the IESG=20 >>> conclusion was wrong, that was appealable to the IAB. >> >> The way I've always understood it is that process can be appealed with=20 >> some possibility of a reversal, but a decision that follows the proces= s,=20 >> no matter whether some community members thought it was the wrong=20 >> decision, is unlikely to be reversed. >> >>> >>> That is very different from declaring that the RSAB can publish a=20 >>> document without community approval. >> >> See above.=C2=A0 AFAICT, there were folks in opposition to the Nomcom = >> decision, but the community was heard.=C2=A0 I'm not saying that the=20 >> community will not be heard, but I'm saying - similar to what the IESG=20 >> did with documenting the Nomcom decision - that individual members or = >> even a small subsection of the community should not have a veto over t= he=20 >> publication of documents that the RSAB believes necessary for the=20 >> operation of the streams. >> >> >>> And given the structure that is proposed, there seems much less reaso= n=20 >>> for any process that bypasses the working group. >> >> WGs by their nature are self-selected and generally consist of a small=20 >> percentage of the overall community with strong opinions about the=20 >> topics covered by the WG (with the active participants being even=20 >> somewhat smaller).=C2=A0=C2=A0 When the scope is small enough - e.g. D= NSOP for=20 >> example - the community affected by the decisions will mostly mirror t= he=20 >> community represented by the WG.=C2=A0 When the scope is large enough = - e.g.=20 >> Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions = of=20 >> the WG represent the best results for the community of the whole.=C2=A0=20 In=20 >> the Nomcom case, we were able to gather a reasonably large group of=20 >> people (in the form of a WG)=C2=A0 of diverse views for a sufficient t= ime=20 >> (multiple times) to spend a very large amount of effort to craft and=20 >> recraft the Nomcom process.=C2=A0 But that differs from this proposed = WG in=20 >> that the various Nomcom related WGs had well defined target outputs an= d=20 >> a need to complete in a reasonably short period of time (by IETF=20 >> standards at least). >> >> I'm trying to avoid us replacing the RSOC with the RSWG - but I can't = >> see how we can get enough diversity of interest for an indefinite peri= od=20 >> of time to ensure that the RSWG continues to operate as a useful sourc= e=20 >> of community involvement rather than a place for a small number of=20 >> self-selected folk to have an overly large continuing impact on a=20 >> process that's absolutely critical to the community's success.=C2=A0 N= or has=20 >> any one been willing to address that specific point. >> >> Peter did say: >> >>> Yes, there are failure modes where the WG is inactive (in which case >>> we'd need to inject more energy) or unable to reach consensus (in whi= ch >>> case we'd need to work harder to do so), >> But I would ask who the "we'd" is in the above?=C2=A0 e.g. once this g= roup=20 >> dissolves in favor of the new structure, who has the responsibility of=20 >> fixing things if the WG structure fails or devolves?=C2=A0 Are we goin= g to be=20 >> back here in 4 years?=C2=A0 Or does the RSAB go on its merry way and d= o what=20 >> it needs to do?=C2=A0 If not, who reconstitutes the next RFCED-Futures=20 group=20 >> given that we will have taken the IAB out of the picture?=C2=A0 The RS= AB? >> >>> >>> I think everyone knows that I do not like the current approach. But I=20 >>> can live with it.=C2=A0 And it seems to be the approach the community=20 wants. >> Or at least the 1/2 dozen or so people who have argued for the approac= h=20 >> - not sure that's the community. >>> Creating strawmen as obstacles does not seem helpful. >> >> And thanks for that denigrating comment.=C2=A0=C2=A0 You might not lik= e what I'm=20 >> saying nor agree with them, but calling them strawmen implies that the= y=20 >> are there simply to providing a blocking issue and they have no basis = in=20 >> reality and that I'm doing that simply to screw up what process there = is. >> >> >> Mike >> >> >> >>> >>> Yours, >>> Joel >>> >>> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>>> IMHO, the IAB can and does do this but the IESG doesn't. Take RFC19= 84 >>>>> as a canonical example: the IESG approved it as a BCP by standard >>>>> process including IETF Last Call. The IAB co-signed it too, on its >>>>> own authority. >>>>> >>>>> =C2=A0=C2=A0=C2=A0 Brian >>>> >>>> A much better (and much more recent) counter example is=20 >>>> draft-iesg-nomcom-eligibility-2020 which became RFC 8788. >>>> >>>> This was an IESG initiated document that solicited community input, = >>>> but ultimately was published on the IESG's dime with their sole=20 >>>> interpretation of community consensus. >>>> >>>> RFC6360.=C2=A0 RFC3932.=C2=A0 And RFC 3710 (the IESG charter). >>>> >>>> The point is that the IESG does this too.=C2=A0 And its not a bad th= ing,=20 >>>> especially when we have 100 different opinions and we need a final=20 >>>> answer sooner rather than later. >>>> >>>> I don't expect the RSAB to do a lot of internally originated=20 >>>> documents, but I do expect there will be cases where a decision has = >>>> to be made, and that there will be some immediacy necessary. >>>> >>>> Later, Mike >>>> >>>> >>>> >> >=20 From nobody Sun May 9 22:23: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 D8C2F3A11AE for ; Sun, 9 May 2021 22:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3u75zoBP2J1n for ; Sun, 9 May 2021 22:23:32 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A474D3A11AD for ; Sun, 9 May 2021 22:23:32 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id v13so8542175ple.9 for ; Sun, 09 May 2021 22:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=XTqZCWkqH0EcfuCfduHKCstdujjpB5KwARtGeunrz7c=; b=L3981lbSKxc/mGZyV5yGUzbJ71IenOCy05ge/dv0ZE9xxnaXTMlBtKabYUepkJAx8l 7hZW2d1mkjHwZqnem3i7OzI22ykZdm8bgppYrKr6Y/aVtQXDB8sb08/EdAemrwugz3R/ aRZZV7puNe/7eRpG+ddU+09/ln+8TDobBpOB/JPL9eKYeqmVeh5w06a1tslGnJEFW7Yd i2b8YRYzAHu+AYRVJ9xcpe+/c9mvSp8+DAMB8X3teTf0ZZewHYNxlJR6MniOkYcaI8Ls hzw6y9CqtQIhdSY8ysnralCrPeObMjXPniixBdHkVwJ5G8UM0Bh7fvhAe54jH9PqaNu0 Wkxw== 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=XTqZCWkqH0EcfuCfduHKCstdujjpB5KwARtGeunrz7c=; b=mI4yHGHr4k0CFEUE2BVT6W7+2mJ0wxYIO1/+vJu1HbZOMdwFhf/SYLn0aPn2V5ubDu JH1wqDpigyRMIx5MWnzX92/gsdOMygB2nwrEBfjbKHOIizySgZ3K8xYVuKbs4yCuOe++ WHIkombASqCLGlHz85oHxTHaLmO2bFMQFekwYrA/7fI/t8s2e5rZWGgbddEnr4oyMVwx zprdbnS5aURtdP4kcqkHZmYLWOquvZc191sJUg7jGAHPLT9yT+Mzu37OVPurewDi8xQN GI5slKLLUZaeCoRNrtpVJ3wUKJFUsDsOIGkiCpv2lYW2id5sQ2rCOAqvxexMVNRHceBJ 2Gjw== X-Gm-Message-State: AOAM532PCc1smmluV/2tYR+gIsFGvRVzyg3x6fHwTL5p5KfXoXVMfOlt ijFUy6sr4lnBt5HzI5UytpkEywrw3Wlt7g== X-Google-Smtp-Source: ABdhPJz1vX4q/ZdhyvYGFHt5rLdo+Wy+xJ32FPdfSdFkwqKHPI+lmb9oRtd6gMgg1TVTAmauMZnyIQ== X-Received: by 2002:a17:90b:8cf:: with SMTP id ds15mr25458463pjb.110.1620624211421; Sun, 09 May 2021 22:23:31 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id oa3sm42397116pjb.1.2021.05.09.22.23.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 09 May 2021 22:23:30 -0700 (PDT) To: Jay Daley Cc: Peter Saint-Andre , Eliot Lear , rfced-future@iab.org References: <2dfd7a8e-f8ec-daa1-18e4-210ec82123d4@gmail.com> <2FB112F5-88EC-4538-A77E-BFBCCBAB232B@ietf.org> From: Brian E Carpenter Message-ID: <22f044c2-ed5d-23b6-1307-22168ed4aa55@gmail.com> Date: Mon, 10 May 2021 17:23:26 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <2FB112F5-88EC-4538-A77E-BFBCCBAB232B@ietf.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 56: Process for RPC work not requiring consensus X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 05:23:34 -0000 On 10-May-21 15:01, Jay Daley wrote: >=20 > On 10/05/2021, at 12:28 PM, Brian E Carpenter wrote: >> >> =EF=BB=BFOn 10-May-21 06:07, Peter Saint-Andre wrote: >>>> On 5/6/21 2:12 AM, Eliot Lear wrote: >>>> Hi there, >>>> >>>>> Issue #56: The RSWG/RSAB process is clear for larger projects but = the RPC also need a path for discussion and agreement on smaller things t= hat do not require a consensus process. Previously the RPC would discuss=20 and agree these with the RSE, with the RSE taking the decision on what me= ets the threshold for taking to the community. How are those agreed now = and who decides what does and does not need community consensus/engagemen= t? >>>> >>>> >>>> With regard to this issue, as well as 57, 58, and 59, these seem to = articulate a point that was raised in Issue 23 (=E2=80=9CWhat is strategi= c?=E2=80=9D). What I propose to do is to close 23 in favor of us using y= our pragmatic issues. >>>> >>>> But we should maintain the context of thinking around that issue. I=20 believe the intent of the WG at this point was for the overarching policy=20 and procedure to be set by the RFGWG, but for the implementation of that = policy to rest entirely with the RPC. While the RPC should be free and e= ven be encouraged to consult the RS[EA], the decision is with the RPC. I= t is not a negotiation. This is my understanding of the group view, base= d on previous discussions. While I don=E2=80=99t believe we=E2=80=99ve d= iscussed this explicitly, it seems reasonable for the RPC to periodically=20 >> report on those activities to the RFCWG. >>>> >>>> There will occasionally be ambiguities. Here, I believe the group=E2= =80=99s view is one of =E2=80=9Cbetter to ask forgiveness than permission= =E2=80=9D in those circumstances. That is- the RPC is empowered to act, = but=20 >> then should report the ambiguity to the RFCWG, as the RFCWG process is=20 expected to be rather laborious. Again, consultation with the RS[EA] enc= ouraged. >>> >>> In his reply to this message, Joel raises a concern about a change in= >>> the RPC's role. It would be good for Sandy perhaps to provide her >>> perspective, but my recent experience working through open issues >>> related to v3 of the XML vocabulary in collaboration with Sandy and >>> Alice is that they often find it helpful to confer with someone (or a= >>> small team) regarding issues that crop up. These aren't large policy >>> issues of the kind that we've envisioned working through in the RFCWG= , >>> but they benefit from informed and focused discussion. However, it's = not >>> clear to me whether the RFC Editor Model needs to define a formal >>> structure for such discussions, since I think they could be defined b= y >>> the RPC in an ad-hoc way (e.g., through an informal technical or >>> editorial advisory team). >> >> I think the RPC is effectively asking "Who do we talk to when we can't= >> decide on our own?" and to me the obvious answer is "The RSA/E". Do we= >> need to say more? >=20 > No that=E2=80=99s answering their question orthogonally. Under the cur= rent model, the RSE has authority to decide what requires community consu= ltation and what doesn=E2=80=99t, which gives us a clean split between de= cider (RSE) and implementer (RPC). The answer is about who decides that n= ow and if that is to be the RPC then it should be made clear. If any gui= delines are to be provided then the priority should be principles to use = when determining where to draw the line rather than who to consult with. I see. Personally I would be happy that the RPC makes such decisions (after consulting with the RSA/E) as long as there is a way to challenge it (which might just mean raising an issue in the RSWG). Brian =20 From nobody Mon May 10 00:55: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 52F903A0CE3 for ; Mon, 10 May 2021 00:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MoOXvLeE8F49 for ; Mon, 10 May 2021 00:55:08 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8ABF33A0CE5 for ; Mon, 10 May 2021 00:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6173; q=dns/txt; s=iport; t=1620633307; x=1621842907; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=QtBxik0ubuE/wTcXdjDo2IZbm9FJiG5tRNuAYYLmya8=; b=F1NQsDxDFRetaPqAti/RtOO6Zj2D3VjErVbOsY7omsu5oml6aqCt/qkl GBlse93mQE6m9h+yLimVaI0z3hc0hyxpZvLSpmBLrPptq8xfY4GrY3sF7 cTlt7oeGZm5743bYHXVYlCNi74HYquV8ASWg1NdFpP6Z8tbghBX0K8eHm U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BYAADu5Zhg/xbLJq1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBgheBI4F/VgE5MYRHiQSIdQOHf4xbiCcEBwEBAQoDAQE0CAQBA?= =?us-ascii?q?YRQAoIEJjgTAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEcROFUA2GRAEBAQMBI?= =?us-ascii?q?1YFCwsMDCoCAj0aBhMUgl0BgmYhD6dpeoEygQGDSgEDBYEQhQEKBoE6AYFSh?= =?us-ascii?q?TMBhlpDgguBFSccgl8+h1k2gisEgUt1bkMQIGVHnymdH4Meg0qBSZgmBSKlL?= =?us-ascii?q?IZUrkGECAIEBgUCFoFrI4FZMxoIGxVICBUBgj4+EhkOlyOFSz8DLzgCBgEJA?= =?us-ascii?q?QEDCY0PAQE?= IronPort-HdrOrdr: A9a23:OaWL/6wEiGc1gX6DiNSmKrPwKb1zdoMgy1knxilNoNJuA6+lfq GV8MjzuiWUtN98YhsdcJW7WJVoP0mwyXcF2+Ys1N6ZNWGMhILrFvAG0WKI+VPd8kPFh4xgPN 9bAsxD4BmaNykdsS48izPIdOod/A== X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,287,1613433600"; d="asc'?scan'208,217";a="33440184" 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; 10 May 2021 07:55:05 +0000 Received: from smtpclient.apple ([10.61.144.40]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 14A7t458024771 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 May 2021 07:55:05 GMT From: Eliot Lear Message-Id: <4C643311-7DB9-4E6A-8AC1-709B9D12595E@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A4D0447D-02F5-4084-88DA-611898133CD1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Mon, 10 May 2021 09:55:04 +0200 In-Reply-To: <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> Cc: "Joel M. Halpern" , rfced-future@iab.org To: Michael StJohns References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.40, [10.61.144.40] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 07:55:14 -0000 --Apple-Mail=_A4D0447D-02F5-4084-88DA-611898133CD1 Content-Type: multipart/alternative; boundary="Apple-Mail=_ACDD1274-BC3B-4600-B865-2BDE54A33AD0" --Apple-Mail=_ACDD1274-BC3B-4600-B865-2BDE54A33AD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hiya Mike Just looking at the IAB.. > On 10 May 2021, at 04:58, Michael StJohns = wrote: >=20 >> On the other hand, if the community members had thought the IESG = conclusion was wrong, that was appealable to the IAB. >=20 > The way I've always understood it is that process can be appealed with = some possibility of a reversal, but a decision that follows the process, = no matter whether some community members thought it was the wrong = decision, is unlikely to be reversed. Strictly by the numbers that would be the case. In nearly all cases, = the IAB has upheld IESG decisions.[1] The most notable exception I can = recall was Rob Elz=E2=80=99s appeal over moving an IPv6 spec to draft = standard; and the basis for that decision was not a lack of consensus, = but rather considerations involving the requirements for draft standard = at the time. If you look at ACTUAL ACTIVE participants in our process, we =E2=80=9Csuff= er" from the law of small numbers both in terms of total number of = appeals and reversals. Is that a good thing or bad thing? You decide. Eliot [1] https://www.iab.org/appeals/ [2] = https://www.iab.org/appeals/2003-2/iab-response-to-appeal-against-iesg-act= ion-raised-by-mr-r-elz-appeal-text-february-2003/ --Apple-Mail=_ACDD1274-BC3B-4600-B865-2BDE54A33AD0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hiya = Mike

Just looking at = the IAB..

On 10 May 2021, at 04:58, Michael StJohns = <msj@nthpermutation.com> wrote:

On = the other hand, if the community members had thought the IESG conclusion = was wrong, that was appealable to the IAB.

The way I've always understood = it is that process can be appealed with some possibility of a reversal, = but a decision that follows the process, no matter whether some = community members thought it was the wrong decision, is unlikely to be = reversed.

Strictly by the numbers that would be the case.  In = nearly all cases, the IAB has upheld IESG decisions.[1]  The most = notable exception I can recall was Rob Elz=E2=80=99s appeal over moving = an IPv6 spec to draft standard; and the basis for that decision was not a lack of consensus, but rather considerations = involving the requirements for draft standard at the time.

If you look at ACTUAL = ACTIVE participants in our process, we =E2=80=9Csuffer" from the law of = small numbers both in terms of total number of appeals and reversals. =  Is that a good thing or bad thing?  You decide.

Eliot

[1] https://www.iab.org/appeals/
[2] https://www.iab.org/appeals/2003-2/iab-response-to-appeal-again= st-iesg-action-raised-by-mr-r-elz-appeal-text-february-2003/
= --Apple-Mail=_ACDD1274-BC3B-4600-B865-2BDE54A33AD0-- --Apple-Mail=_A4D0447D-02F5-4084-88DA-611898133CD1 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCY5tgACgkQh7ZrRtnS ejPFeggAxMZVawkAgmQYNRXzetp5xqourbsqoEu3vNgBljXBvKHJUvikbgDF1xLW 1jx4SbG5UaFCV809g55VHTgLweQetbRjSwhi3NnXoxDdHJx0bs9OyBdlJ5HjD8IJ 9Z1MxCKUo7pChJlRL7fki61j6VD1uhMonJHdwygsYWVKejh+6w+G9iNQuMwj5ZbD 0MpTsNCxEq3PQoMS9UTC330lTffhxp5QMKWQM48mOIw0GzJCh+aH2JGHldXZ3jMt XcfE9zwtakVETL0UcXw4RSTbGu2uAIL9/UY0724+En+Fro88f/8+nRsn983jSExt F7xZ10jIOhJtTTVLjpSpou0OxraN7Q== =RTC4 -----END PGP SIGNATURE----- --Apple-Mail=_A4D0447D-02F5-4084-88DA-611898133CD1-- From nobody Mon May 10 02:16: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 A05AB3A1168 for ; Mon, 10 May 2021 02:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.294 X-Spam-Level: X-Spam-Status: No, score=-10.294 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id faqX0emjxPFt for ; Mon, 10 May 2021 02:16:33 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EA43A1167 for ; Mon, 10 May 2021 02:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18456; q=dns/txt; s=iport; t=1620638193; x=1621847793; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=Fd3DZ3uYV0x7DJc2T6Hoe04M/IPbKjAMow3bxZkcGTQ=; b=DLtyH+FCzIt8hy0USXvw2cjc+2Mj2+a1Z4TZKKY+/TNQZvfBIVIeDGk7 szzX7uOiExnOoc+tbfGWRe+08q1Vje9Rxg+k+GR0vUONaoJKSj2yPhu5q OOShFDWkY33ip59XlHljJZaNil8oJOaZepmpP3b9M09OLZOEtiqm32sBr M=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AVAABA+ZhglxbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGCF4F2gSxWATkxhEeJBIh2A4EMjiuFI4gnBAcBAQEKA?= =?us-ascii?q?wEBJQEKDAQBAYRQAoIEJjgTAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBA?= =?us-ascii?q?QEBAQEBaIVQDYZEAQEBAwEBASFLCwULFwwjBwICJxYaBhMUgl0BgmYhD6d8e?= =?us-ascii?q?oEygQGEY4UECgaBOgGBUoUzAYVgekOCC4EVJxyBXy8bB22CYAGEeDaCKwSBV?= =?us-ascii?q?RBbHQkOECYBAw0QFREQIDsgCkcRU0SQR406nAqBFYMeg0qBSZUlgwEFIqUsh?= =?us-ascii?q?lSsKYEzAWSECAIEBgUCFoFrIYFbMxoIGxU7KgGCPj4SGQ6OKw0JFYhNhUs/A?= =?us-ascii?q?y84AgYBCQEBAwmMMl0BAQ?= IronPort-HdrOrdr: A9a23:h/cIjaokbLvHm+TlL3eELDsaV5oueYIsimQD101hICG9vPbo9P xG/c526faaslcssR0b8+xofZPhfZqjz/NICPgqUotKNTOO0ACVxcNZnO7fKlbbdREWmNQtt5 uIC5IObOEZyTNB/KDHCM7SKadG/OW6 X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,287,1613433600"; d="asc'?scan'208,217";a="35816035" 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; 10 May 2021 09:16:30 +0000 Received: from smtpclient.apple ([10.61.144.40]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 14A9GTr3012761 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 10 May 2021 09:16:30 GMT From: Eliot Lear Message-Id: <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_6CC33112-EAE1-432A-BB44-F3BE4B998F90"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Mon, 10 May 2021 11:16:28 +0200 In-Reply-To: Cc: Michael StJohns , rfced-future@iab.org To: "Joel M. Halpern" References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.40, [10.61.144.40] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 10 May 2021 09:16:39 -0000 --Apple-Mail=_6CC33112-EAE1-432A-BB44-F3BE4B998F90 Content-Type: multipart/alternative; boundary="Apple-Mail=_F9EDE2C0-AD77-4DFD-B190-9F493776941C" --Apple-Mail=_F9EDE2C0-AD77-4DFD-B190-9F493776941C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Joel, Yes, this is a good point, but I want to restate it slightly, and I=E2=80=99= ve opened Issue 63 to do so: Who has the final authority to make evolve the processes that we are = defining here? Can we enumerate possible answers? Does it continue to rest with the IAB? Could it rest with the community as represented by the RFCWG and = confirmed by the RSAB? Is it the IETF community as confirmed by the IESG? Is it the IETF community as confirmed by the IAB? Other? Eliot > On 10 May 2021, at 05:55, Joel M. Halpern wrote: >=20 > Buried in the below is an interesting and important point. > Suppose that we work out a process, agree to it, and try it. And it = fails. (For any number of possible meanings of "fail".) >=20 > Who has the authority to decide something needs to be done? Who has = the authority to make something happen. Under current rules, whether we = like them or not, the authority for what we are doing comes from the = IAB, via the RFCs that say it is the IABs job. >=20 > It seems to me that Mike's point below about who has the ultimate = authority is important. And at that point, I don't think "the = community" is a viable answer. >=20 > Yours, > Joel >=20 > PS: I am sorry you do not like my usage of strawman Mike. But the = premise for your objection is sufficiently vague that I do not know what = else to call it. If the only purpose of your description was to get to = the "who has authority to fix things if they are broken", then as above, = I agree that is an important question. I was completely unable to get = to that issue from what you wrote. In particular, I could not connect = that with your conclusion that the RSAB should be empowered to bypass = the RSWG. >=20 > On 5/9/2021 10:58 PM, Michael StJohns wrote: >> On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >>> Mike, your analysis seems a bit flawed. >>> Yes, the IESG approved those documents after community consultation, = on the basis that the community had agreed. >>> And yes, that judgement was made by the IESG. >>>=20 >>> On the other hand, if the community members had thought the IESG = conclusion was wrong, that was appealable to the IAB. >> The way I've always understood it is that process can be appealed = with some possibility of a reversal, but a decision that follows the = process, no matter whether some community members thought it was the = wrong decision, is unlikely to be reversed. >>>=20 >>> That is very different from declaring that the RSAB can publish a = document without community approval. >> See above. AFAICT, there were folks in opposition to the Nomcom = decision, but the community was heard. I'm not saying that the = community will not be heard, but I'm saying - similar to what the IESG = did with documenting the Nomcom decision - that individual members or = even a small subsection of the community should not have a veto over the = publication of documents that the RSAB believes necessary for the = operation of the streams. >>> And given the structure that is proposed, there seems much less = reason for any process that bypasses the working group. >> WGs by their nature are self-selected and generally consist of a = small percentage of the overall community with strong opinions about the = topics covered by the WG (with the active participants being even = somewhat smaller). When the scope is small enough - e.g. DNSOP for = example - the community affected by the decisions will mostly mirror the = community represented by the WG. When the scope is large enough - e.g. = Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of = the WG represent the best results for the community of the whole. In = the Nomcom case, we were able to gather a reasonably large group of = people (in the form of a WG) of diverse views for a sufficient time = (multiple times) to spend a very large amount of effort to craft and = recraft the Nomcom process. But that differs from this proposed WG in = that the various Nomcom related WGs had well defined target outputs and = a need to complete in a reasonably short period of time (by IETF = standards at least). >> I'm trying to avoid us replacing the RSOC with the RSWG - but I can't = see how we can get enough diversity of interest for an indefinite period = of time to ensure that the RSWG continues to operate as a useful source = of community involvement rather than a place for a small number of = self-selected folk to have an overly large continuing impact on a = process that's absolutely critical to the community's success. Nor has = any one been willing to address that specific point. >> Peter did say: >>> Yes, there are failure modes where the WG is inactive (in which case >>> we'd need to inject more energy) or unable to reach consensus (in = which >>> case we'd need to work harder to do so), >> But I would ask who the "we'd" is in the above? e.g. once this group = dissolves in favor of the new structure, who has the responsibility of = fixing things if the WG structure fails or devolves? Are we going to be = back here in 4 years? Or does the RSAB go on its merry way and do what = it needs to do? If not, who reconstitutes the next RFCED-Futures group = given that we will have taken the IAB out of the picture? The RSAB? >>>=20 >>> I think everyone knows that I do not like the current approach. But = I can live with it. And it seems to be the approach the community = wants. >> Or at least the 1/2 dozen or so people who have argued for the = approach - not sure that's the community. >>> Creating strawmen as obstacles does not seem helpful. >> And thanks for that denigrating comment. You might not like what = I'm saying nor agree with them, but calling them strawmen implies that = they are there simply to providing a blocking issue and they have no = basis in reality and that I'm doing that simply to screw up what process = there is. >> Mike >>>=20 >>> Yours, >>> Joel >>>=20 >>> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>>> IMHO, the IAB can and does do this but the IESG doesn't. Take = RFC1984 >>>>> as a canonical example: the IESG approved it as a BCP by standard >>>>> process including IETF Last Call. The IAB co-signed it too, on its >>>>> own authority. >>>>>=20 >>>>> Brian >>>>=20 >>>> A much better (and much more recent) counter example is = draft-iesg-nomcom-eligibility-2020 which became RFC 8788. >>>>=20 >>>> This was an IESG initiated document that solicited community input, = but ultimately was published on the IESG's dime with their sole = interpretation of community consensus. >>>>=20 >>>> RFC6360. RFC3932. And RFC 3710 (the IESG charter). >>>>=20 >>>> The point is that the IESG does this too. And its not a bad thing, = especially when we have 100 different opinions and we need a final = answer sooner rather than later. >>>>=20 >>>> I don't expect the RSAB to do a lot of internally originated = documents, but I do expect there will be cases where a decision has to = be made, and that there will be some immediacy necessary. >>>>=20 >>>> Later, Mike >>>>=20 >>>>=20 >>>>=20 >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_F9EDE2C0-AD77-4DFD-B190-9F493776941C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Joel,

Yes, this is a = good point, but I want to restate it slightly, and I=E2=80=99ve opened = Issue 63 to do so:

Who has the final authority to make evolve the processes that = we are defining here?  Can we enumerate possible answers?
  • Does it continue to rest with = the IAB?  
  • Could it rest with the community as = represented by the RFCWG and confirmed by the RSAB?  
  • Is it the IETF community as confirmed by the IESG?
  • Is it the IETF community as confirmed by the IAB?
  • Other?
Eliot

On 10 May 2021, at 05:55, Joel M. Halpern <jmh@joelhalpern.com>= wrote:

Buried in the below is an interesting and important point.
Suppose that we work out a process, agree to it, and try it. =  And it fails.   (For any number of possible meanings of = "fail".)

Who has the authority to decide = something needs to be done?  Who has the authority to make = something happen.  Under current rules, whether we like them or = not, the authority for what we are doing comes from the IAB, via the = RFCs that say it is the IABs job.

It seems = to me that Mike's point below about who has the ultimate authority is = important.  And at that point, I don't think "the community" is a = viable answer.

Yours,
Joel

PS: I am sorry you do not like my usage of = strawman Mike.  But the premise for your objection is sufficiently = vague that I do not know what else to call it.  If the only purpose = of your description was to get to the "who has authority to fix things = if they are broken", then as above, I agree that is an important = question.  I was completely unable to get to that issue from what = you wrote.  In particular, I could not connect that with your = conclusion that the RSAB should be empowered to bypass the RSWG.

On 5/9/2021 10:58 PM, Michael StJohns = wrote:
On 5/9/2021 = 10:32 PM, Joel M. Halpern wrote:
Mike, your analysis seems a bit flawed.
Yes, = the IESG approved those documents after community consultation, on the = basis that the community had agreed.
And yes, that = judgement was made by the IESG.

On the = other hand, if the community members had thought the IESG conclusion was = wrong, that was appealable to the IAB.
The = way I've always understood it is that process can be appealed with some = possibility of a reversal, but a decision that follows the process, no = matter whether some community members thought it was the wrong decision, = is unlikely to be reversed.

That is very different from declaring that the = RSAB can publish a document without community approval.
See above.  AFAICT, there were folks in = opposition to the Nomcom decision, but the community was heard.  = I'm not saying that the community will not be heard, but I'm saying - = similar to what the IESG did with documenting the Nomcom decision - that = individual members or even a small subsection of the community should = not have a veto over the publication of documents that the RSAB believes = necessary for the operation of the streams.
And given the structure that is proposed, there = seems much less reason for any process that bypasses the working = group.
WGs by their nature are self-selected = and generally consist of a small percentage of the overall community = with strong opinions about the topics covered by the WG (with the active = participants being even somewhat smaller).   When the scope is = small enough - e.g. DNSOP for example - the community affected by the = decisions will mostly mirror the community represented by the WG.  = When the scope is large enough - e.g. Nomcom, RFC ED, etc - you have a = hard time ensuring that the opinions of the WG represent the best = results for the community of the whole.  In the Nomcom case, we = were able to gather a reasonably large group of people (in the form of a = WG)  of diverse views for a sufficient time (multiple times) to = spend a very large amount of effort to craft and recraft the Nomcom = process.  But that differs from this proposed WG in that the = various Nomcom related WGs had well defined target outputs and a need to = complete in a reasonably short period of time (by IETF standards at = least).
I'm trying to avoid us replacing the RSOC with the = RSWG - but I can't see how we can get enough diversity of interest for = an indefinite period of time to ensure that the RSWG continues to = operate as a useful source of community involvement rather than a place = for a small number of self-selected folk to have an overly large = continuing impact on a process that's absolutely critical to the = community's success.  Nor has any one been willing to address that = specific point.
Peter did say:
Yes, there are failure modes where the WG is = inactive (in which case
we'd need to inject more energy) = or unable to reach consensus (in which
case we'd need to = work harder to do so),
But I would ask who = the "we'd" is in the above?  e.g. once this group dissolves in = favor of the new structure, who has the responsibility of fixing things = if the WG structure fails or devolves?  Are we going to be back = here in 4 years?  Or does the RSAB go on its merry way and do what = it needs to do?  If not, who reconstitutes the next RFCED-Futures = group given that we will have taken the IAB out of the picture?  = The RSAB?

I think everyone knows that I do not like the current = approach. But I can live with it.  And it seems to be the approach = the community wants.
Or at least the 1/2 = dozen or so people who have argued for the approach - not sure that's = the community.
Creating= strawmen as obstacles does not seem helpful.
And thanks for that denigrating = comment.   You might not like what I'm saying nor agree with = them, but calling them strawmen implies that they are there simply to = providing a blocking issue and they have no basis in reality and that = I'm doing that simply to screw up what process there is.
Mike

Yours,
Joel

On = 5/9/2021 9:41 PM, Michael StJohns wrote:
On 5/9/2021 8:39 PM, Brian E Carpenter = wrote:
IMHO, the IAB = can and does do this but the IESG doesn't. Take RFC1984
as = a canonical example: the IESG approved it as a BCP by standard
process including IETF Last Call. The IAB co-signed it too, = on its
own authority.

    Brian

A much better (and much more recent) counter example is = draft-iesg-nomcom-eligibility-2020 which became RFC 8788.

This was an IESG initiated document that = solicited community input, but ultimately was published on the IESG's = dime with their sole interpretation of community consensus.

RFC6360.  RFC3932.  And RFC 3710 = (the IESG charter).

The point is that the = IESG does this too.  And its not a bad thing, especially when we = have 100 different opinions and we need a final answer sooner rather = than later.

I don't expect the RSAB to do a = lot of internally originated documents, but I do expect there will be = cases where a decision has to be made, and that there will be some = immediacy necessary.

Later, Mike




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

= --Apple-Mail=_F9EDE2C0-AD77-4DFD-B190-9F493776941C-- --Apple-Mail=_6CC33112-EAE1-432A-BB44-F3BE4B998F90 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCY+e0ACgkQh7ZrRtnS ejPfQQf+JTNUQKgNssZSdO2ik/MHKTmk3mzZEuaTbZU9o30e9CjXSnP7KKIQrKZr kYyXSDMtKqgStFYL4AV0WA5K6yjXsTxpQ/yPWkrn11ql2vRbVFPLfIEdKI3RbI8X IdXZ6Sxu5QsQnVE1LLJ4AEOMXdyuR72bINO1h7nEMmABsIbjpw08sQ/clEo+ybAw hXqX4UnAtE57roNzC2Fvk6Es8PALq13t8DCj+ut5hqmOMIaIW2rJ6h4O4xDnJtcC kBy8yyOAVUlebrfxNiTgkKUECobZAaAOgozwolTNbDqN2lgfr46o5A3UGa6/m/qv f0X0wCw2kB7iFiNOafnl9/k/s4JZIg== =i0pa -----END PGP SIGNATURE----- --Apple-Mail=_6CC33112-EAE1-432A-BB44-F3BE4B998F90-- From nobody Mon May 10 19:09:54 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221543A33B6 for ; Mon, 10 May 2021 19:09:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eydz1-xc4CJR for ; Mon, 10 May 2021 19:09:47 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E9EF3A33B3 for ; Mon, 10 May 2021 19:09:47 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id y32so14650697pga.11 for ; Mon, 10 May 2021 19:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=zEQfT1BPasZV6gsvmh8O6jNR2vZqEbPTotvw+j+Pxvg=; b=lMADHUgFccJX0lIw4nGFlOAfdGn6owW+EVCKiYVXlqrIZrT/cQhE66Pa511A93qMec 2j7STNXzHR67+ZlWHuPrKLN2Zt1yhd3TowCVVZdwRN8pglU/9RLKrQv5BD1xEAQHqjll Z5quD2lvNCj016ZcaSDfl1VpRJOYAQRKPCPFjDIdeGg46Z/6B2MUxrhxkvna/g3GT7Ol S7cShZc6q6hqVuxtg4xvVWNHNMeKLPOjtJlORWme/T3txFgWnJUf3wr+lYQICsJ/iNDL fwBM/7DQQhY5/8aXznhgNAWSFfBCd4RkPXlZlZsY1Q0AqZR75uEVjjtPD83RQJsKz+/g ezlg== 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=zEQfT1BPasZV6gsvmh8O6jNR2vZqEbPTotvw+j+Pxvg=; b=nKhosdwLgDAk/Jv+J+qB7hdXQ2E5FAEvS+F3myeTGe3UVTOiTMj9VoRkX0Txff+TDr A980tXwWCJA/osVAinrHlw8lX5NlfcMv6AFk8qDKDyz/4eDKcSDq7qZPnh3IZIYEGG2h T9gHmk2l+f82r9ToEPRmq9Toq2g3F4Cbb0/Gc5+dDBCXvaAvaQkuc7/jFMi4h14hSnhE 076ef0cGXOsZxj27Y9sVTwHT3xSnPGWBEDTJYRogpdd6dXymjr1vLw4sqAOd3Y73T6HW yOJMsgUJ2kgC1glk/+mR0W5b/XJIr09A9zp36YrIKSL1ddlHgD5aWpokqrBTsrJsSVCg XwOw== X-Gm-Message-State: AOAM533OKPAbDopOFNjZmlgc7SM60LJi2tq7ld6r0wtVfSblgJjAzwsA IhyLld/r/WFY9xDosyumk6c= X-Google-Smtp-Source: ABdhPJzZezXcC6zTHjd6zI21bMBt8tTDhac9yutqBc+97HIY2IVQOuiW9z0T3GI9DV0k+uU658DnEQ== X-Received: by 2002:a63:d80f:: with SMTP id b15mr14310401pgh.388.1620698986047; Mon, 10 May 2021 19:09:46 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id e27sm8395393pfm.144.2021.05.10.19.09.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 10 May 2021 19:09:45 -0700 (PDT) To: Eliot Lear , "Joel M. Halpern" Cc: rfced-future@iab.org, Michael StJohns References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> From: Brian E Carpenter Message-ID: Date: Tue, 11 May 2021 14:09:41 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2021 02:09:53 -0000 On 10-May-21 21:16, Eliot Lear wrote: > Hi Joel, >=20 > Yes, this is a good point, but I want to restate it slightly, and I=E2=80= =99ve opened Issue 63 to do so: >=20 > Who has the final authority to make evolve the processes that we are de= fining here? =C2=A0Can we enumerate possible answers? >=20 > * Does it continue to rest with the IAB? As I said on the thread for another issue, my current feeling is that the IAB should be in the appeal chain after the RSAB. (If we continue that line of thought, we'd ask the ISOC Board to be the end point, as it is for IETF process issues.) > * Could it rest with the community as represented by the RFCWG and co= nfirmed by the RSAB?=20 As long as there is an appeal chain as above. > * Is it the IETF community as confirmed by the IESG? No. It's wider than the IETF. That's why this will not be an IETF WG. From a higher level viewpoint, I think the RSAB is a peer group of the IESG and the IRSG. (It's almost as if we were setting up the RFC Task Force.) > * Is it the IETF community as confirmed by the IAB? Ditto. > * Other? I don't think so. Regards Brian >=20 > Eliot >=20 >> On 10 May 2021, at 05:55, Joel M. Halpern > wrote: >> >> Buried in the below is an interesting and important point. >> Suppose that we work out a process, agree to it, and try it. =C2=A0And=20 it fails. =C2=A0=C2=A0(For any number of possible meanings of "fail".) >> >> Who has the authority to decide something needs to be done? =C2=A0Who = has the authority to make something happen. =C2=A0Under current rules, wh= ether we like them or not, the authority for what we are doing comes from=20 the IAB, via the RFCs that say it is the IABs job. >> >> It seems to me that Mike's point below about who has the ultimate auth= ority is important. =C2=A0And at that point, I don't think "the community= " is a viable answer. >> >> Yours, >> Joel >> >> PS: I am sorry you do not like my usage of strawman Mike. =C2=A0But th= e premise for your objection is sufficiently vague that I do not know wha= t else to call it. =C2=A0If the only purpose of your description was to g= et to the "who has authority to fix things if they are broken", then as a= bove, I agree that is an important question. =C2=A0I was completely unabl= e to get to that issue from what you wrote. =C2=A0In particular, I could = not connect that with your conclusion that the RSAB should be empowered t= o bypass the RSWG. >> >> On 5/9/2021 10:58 PM, Michael StJohns wrote: >>> On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >>>> Mike, your analysis seems a bit flawed. >>>> Yes, the IESG approved those documents after community consultation,=20 on the basis that the community had agreed. >>>> And yes, that judgement was made by the IESG. >>>> >>>> On the other hand, if the community members had thought the IESG con= clusion was wrong, that was appealable to the IAB. >>> The way I've always understood it is that process can be appealed wit= h some possibility of a reversal, but a decision that follows the process= , no matter whether some community members thought it was the wrong decis= ion, is unlikely to be reversed. >>>> >>>> That is very different from declaring that the RSAB can publish a do= cument without community approval. >>> See above.=C2=A0 AFAICT, there were folks in opposition to the Nomcom=20 decision, but the community was heard.=C2=A0 I'm not saying that the comm= unity will not be heard, but I'm saying - similar to what the IESG did wi= th documenting the Nomcom decision - that individual members or even a sm= all subsection of the community should not have a veto over the publicati= on of documents that the RSAB believes necessary for the operation of the=20 streams. >>>> And given the structure that is proposed, there seems much less reas= on for any process that bypasses the working group. >>> WGs by their nature are self-selected and generally consist of a smal= l percentage of the overall community with strong opinions about the topi= cs covered by the WG (with the active participants being even somewhat sm= aller).=C2=A0=C2=A0 When the scope is small enough - e.g. DNSOP for examp= le - the community affected by the decisions will mostly mirror the commu= nity represented by the WG.=C2=A0 When the scope is large enough - e.g. N= omcom, RFC ED, etc - you have a hard time ensuring that the opinions of t= he WG represent the best results for the community of the whole.=C2=A0 In=20 the Nomcom case, we were able to gather a reasonably large group of peopl= e (in the form of a WG)=C2=A0 of diverse views for a sufficient time (mul= tiple times) to spend a very large amount of effort to craft and recraft = the Nomcom process.=C2=A0 But that differs from this proposed WG in that = the various Nomcom related WGs had well defined target outputs and a need=20 to complete in a reasonably short period of time (by IETF standards at >>> least). >>> I'm trying to avoid us replacing the RSOC with the RSWG - but I can't=20 see how we can get enough diversity of interest for an indefinite period = of time to ensure that the RSWG continues to operate as a useful source o= f community involvement rather than a place for a small number of self-se= lected folk to have an overly large continuing impact on a process that's=20 absolutely critical to the community's success.=C2=A0 Nor has any one bee= n willing to address that specific point. >>> Peter did say: >>>> Yes, there are failure modes where the WG is inactive (in which case= >>>> we'd need to inject more energy) or unable to reach consensus (in wh= ich >>>> case we'd need to work harder to do so), >>> But I would ask who the "we'd" is in the above?=C2=A0 e.g. once this = group dissolves in favor of the new structure, who has the responsibility=20 of fixing things if the WG structure fails or devolves?=C2=A0 Are we goin= g to be back here in 4 years?=C2=A0 Or does the RSAB go on its merry way = and do what it needs to do?=C2=A0 If not, who reconstitutes the next RFCE= D-Futures group given that we will have taken the IAB out of the picture?= =C2=A0 The RSAB? >>>> >>>> I think everyone knows that I do not like the current approach. But = I can live with it.=C2=A0 And it seems to be the approach the community w= ants. >>> Or at least the 1/2 dozen or so people who have argued for the approa= ch - not sure that's the community. >>>> Creating strawmen as obstacles does not seem helpful. >>> And thanks for that denigrating comment.=C2=A0=C2=A0 You might not li= ke what I'm saying nor agree with them, but calling them strawmen implies=20 that they are there simply to providing a blocking issue and they have no=20 basis in reality and that I'm doing that simply to screw up what process = there is. >>> Mike >>>> >>>> Yours, >>>> Joel >>>> >>>> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>>>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>>>> IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1= 984 >>>>>> as a canonical example: the IESG approved it as a BCP by standard >>>>>> process including IETF Last Call. The IAB co-signed it too, on its= >>>>>> own authority. >>>>>> >>>>>> =C2=A0=C2=A0=C2=A0 Brian >>>>> >>>>> A much better (and much more recent) counter example is draft-iesg-= nomcom-eligibility-2020 which became RFC 8788. >>>>> >>>>> This was an IESG initiated document that solicited community input,=20 but ultimately was published on the IESG's dime with their sole interpret= ation of community consensus. >>>>> >>>>> RFC6360.=C2=A0 RFC3932.=C2=A0 And RFC 3710 (the IESG charter). >>>>> >>>>> The point is that the IESG does this too.=C2=A0 And its not a bad t= hing, especially when we have 100 different opinions and we need a final = answer sooner rather than later. >>>>> >>>>> I don't expect the RSAB to do a lot of internally originated docume= nts, but I do expect there will be cases where a decision has to be made,=20 and that there will be some immediacy necessary. >>>>> >>>>> Later, Mike >>>>> >>>>> >>>>> >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Tue May 11 13:33: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 36E753A2584 for ; Tue, 11 May 2021 13:33:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 vowPgNv4JNgS for ; Tue, 11 May 2021 13:33:34 -0700 (PDT) Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1863A2580 for ; Tue, 11 May 2021 13:33:34 -0700 (PDT) Received: by mail-il1-x12e.google.com with SMTP id j20so18280940ilo.10 for ; Tue, 11 May 2021 13:33:34 -0700 (PDT) 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=ccDYL/DNcSuFlv2dOqoPTOe9tKa7qDtdzlnlu0PYpu4=; b=wcAijVpbi8dBJdRIeY5AeBt68ZmlFiWayklh5fVUTb/lDGt7u0DcaMXEds0xxihVVK cGuv9wW35vZQQujv9jc28rGQ+6mc72DyrD6Hj4BPcY4ZFp7JmFdY3D3zxNFwfRPVMvtS 8q1nVPorZkh2K5GnUQX/+kgjiw70KI7flVSNQ1v/Els+nq2VwNe0rTnf/9oAt25kQpoD 1k4fo2USxSQ8p3bRvenP40Faql1uZO6f+S7RxPJRwEhYHXjXNY7x2cokAbwTIF6FisSF LYzUP+KsIn4JYcoVWo3xTGtltvRDJ0q/Q1NIA00B4GGFMC2ZgJaeFTIIqcO+gxE5opCu N9uA== 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=ccDYL/DNcSuFlv2dOqoPTOe9tKa7qDtdzlnlu0PYpu4=; b=I2jI4yYwrFlktdvGdioqdYqw1PlBxlmX/wC8AdI1T/gQdAZurOdDYG4ZumU7pg2+vU WI9tyFg6hvxWs+7UU9qgggKGf/eK5eDgIZyptlz9AvvBCm6mRodhBF0F8/jsdBDXdxdw rGz1Ge8X8HkLJJDUkEi/jcxqC3CSp2W0kL/CDnbTq9NdrX2RsLTwhs+U2WIU7pqI2pPJ yrdRLKc8NpF6h/teME2OT//pTM+M6g4a0O2tibzm/bweYPxwoMyzwmuswz55+08Apxe7 gesaTdtJDiZeOD6QwwWOWuTe0dRYGWxl61hW9Nn1jQTXI+Fm8hkT/kEJWjtmQ0IyNkgn QG5Q== X-Gm-Message-State: AOAM532RXj6w+12I6ORznqHCniT+I76z9s0Z0X6JzA/qnpYTPAtjQmbg 0mo67Y3pU7X4oxRUNEhqUmMvVGeOt2FcSAo2e9Bz0DNqX/H958J8 X-Google-Smtp-Source: ABdhPJzVSYpJVVBt7w2NbUj+MDwesoJggWrnF72CxBXbTe6PpxGNMw5M1IwUQt9fYcQLfRIZSmSKiEFN+6gZVtZiU2U= X-Received: by 2002:a92:cd8a:: with SMTP id r10mr28306570ilb.282.1620765212827; Tue, 11 May 2021 13:33:32 -0700 (PDT) MIME-Version: 1.0 From: Eric Rescorla Date: Tue, 11 May 2021 13:32:57 -0700 Message-ID: To: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000c67f5105c213cee3" Archived-At: Subject: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 20:33:38 -0000 --000000000000c67f5105c213cee3 Content-Type: text/plain; charset="UTF-8" Hi folks, Please feel free to tell me if we closed on this and I missed it, but I don't think we've quite figured out how to handle complaints about process failures in either the RSAB or the RSWG. In the IETF, as we all know, you can appeal to the AD or the IESG, and the IAB if you don't like the answer for the IESG. I think I'm persuaded by the argument from Joel and (I think) MT that the recourse for the RSAB is to complain to the stream management bodies (i.e., the IESG and IAB) and have the representatives replaced, rather than have a formal appeal. However, I think we need some mechanism for dealing with process failures in the RSWG. This is somewhat complicated by the proposed chair structure where the two chairs are appointed by different groups. However, if we take Lars's proposal for the IETF Chair and the IAB, then I think the IAB should be the appeal body (this is consistent with other suggestions for them having ultimate responsibity). This also works well b/c the IETF Chair is on the IAB. -Ekr --000000000000c67f5105c213cee3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

Please feel free to tell me if we closed = on this and I missed it, but
I don't think we've quite figured o= ut how to handle complaints about
process failures in either the RSAB or= the RSWG. In the IETF, as we
all know, you can appeal to the AD or the = IESG, and the IAB if you
don't like the answer for the IESG.

= I think I'm persuaded by the argument from Joel and (I think) MT thatthe recourse for the RSAB is to complain to the stream management
bodi= es (i.e., the IESG and IAB) and have the representatives replaced,
rathe= r than have a formal appeal. However, I think we need some
mechanism for= dealing with process failures in the RSWG. This is
somewhat complicated= by the proposed chair structure where the
two chairs are appointed by d= ifferent groups. However, if we take
Lars's proposal for the IETF Ch= air and the IAB, then I think the
IAB should be the appeal body (this is= consistent with other suggestions
for them having ultimate responsibity= ). This also works well b/c
the IETF Chair is on the IAB.

-Ekr
--000000000000c67f5105c213cee3-- From nobody Tue May 11 13:49: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 EC23D3A25FD for ; Tue, 11 May 2021 13:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYFXDeM5BkWl for ; Tue, 11 May 2021 13:49:09 -0700 (PDT) Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 3506E3A25FB for ; Tue, 11 May 2021 13:49:09 -0700 (PDT) Received: by mail-oo1-xc2c.google.com with SMTP id v13-20020a4aa40d0000b02902052145a469so2856446ool.3 for ; Tue, 11 May 2021 13:49:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8XoC/ioz9oceB7xEzRiohmvsp7PTNdmYJHgzPRVhay8=; b=hoJNY1VVDZTpgKlHyshAR+Mf5CFAWg1yf4aaAc2WIZAyAZj9cPx+PsE7sMeSJPxyu9 olfbyTG+cI1jC/WV6i1eIgipAjgvKCPHpYNNI0D67dl+M4XCsySExKvaEOg4RboqYsug 6Ji9xyV7FePtdYKippSpZX0Mp/5T6Yc7DDNfuakZsUG8FqR/iP2Nks0kTlkzWf5sfgpa 3D6e8Tqxf+oMrFo+h/6opPmily41lvXiZm/xSukC/FBDOQLQsFdP2BjesfAx5c/IF3hJ fEqj0LfL14Wob3HsBBPBq3+fkqKf0ytAENBXmGEPkhPZSWwjNWMVVFCDWCCWKJl/JYtZ BZXw== 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=8XoC/ioz9oceB7xEzRiohmvsp7PTNdmYJHgzPRVhay8=; b=RwccXcstq372Vnz2WBxN/KTR+nCqX5o5P3ygPLAxKDwa6RPSXusSxXNgEiu7QbPJL6 QoJNv3Jpb6dfMe+bQlRhNCBcAlJx259IGxczB8HrACs/XyutMj3d1U+eWmEKPx1vN2Lq FuizuIjAMDJur207eGjWXpC8IlbI0O+igvE0qnV8I8iG4rh9/y6SEQnyhwGzwNlLb5TQ 4BmGjX+vWnFX7cfqgSuxajkCf8KioJr0+1NAtdoJ5wIYGhNBe0LOBYXAwRGneXpUftCc dYQk7LK3+1IkxJcxM9JcHLtUOqn2YuXYTvvTr58HihLw9/THZGojLqsopXn8aM+7gpTH aGdQ== X-Gm-Message-State: AOAM5314OpACO3D8mfVV25nJJbr/ODIl9Z7BNM1q+c/gCDpoBzos923a nyyMs/gT4syEFoXAddXO4MkQlTdOSOBZYKr+CNMYlyZk4cw= X-Google-Smtp-Source: ABdhPJwK+EfPSnHw/v9eFsMOGI64uAFBHe8qXiwJdEKh0gzGo380RJYbVlT9znOm+WFgUCV0mLq4C77oODceAkIZRK4= X-Received: by 2002:a4a:3e13:: with SMTP id t19mr25130678oot.46.1620766147182; Tue, 11 May 2021 13:49:07 -0700 (PDT) MIME-Version: 1.0 References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <845c2898-60ed-42cb-0b13-b4e28f76d2bf@nthpermutation.com> In-Reply-To: <845c2898-60ed-42cb-0b13-b4e28f76d2bf@nthpermutation.com> From: Wes Hardaker Date: Tue, 11 May 2021 13:48:31 -0700 Message-ID: To: Michael StJohns Cc: "Joel M. Halpern" , rfced-future@iab.org Content-Type: multipart/alternative; boundary="00000000000077948505c2140624" Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2021 20:49:14 -0000 --00000000000077948505c2140624 Content-Type: text/plain; charset="UTF-8" > > > > 2) The minimum RSWG consists of the RSAB plus the two RSWG chairs. The > mailing list may be larger, but the actual active participants may be > very close to that minimum set (at least after the initial burst of > activity). > I found this assumption interesting (not knowing if it's right or wrong). We have more than 6 people active in this group, eg. I wonder if a formal WG like the RSWG will result in the minimum necessary people working in it, or whether it will attract and keep the attention of people that care about the entire series and its change over time. Your assumption is that interest in contributing will cease at some point, which means most of the people on this list will be sufficiently pleased that a good process is in place that worry about the series can drop away (more likely dropping to just a "monitoring" role). -- Wes Hardaker USC/ISI --00000000000077948505c2140624 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


2) The minimum RSWG consists of the RSAB plus the two RSWG chairs.=C2=A0 Th= e
mailing list may be larger, but the actual active participants may be
very close to that minimum set (at least after the initial burst of
activity).

I found this assumption inte= resting (not knowing if it's right or wrong).=C2=A0 We have more than 6= people active in this group,=C2=A0eg.=C2=A0 I wonder if a formal WG like t= he RSWG will result in the minimum necessary people working in it, or wheth= er it will attract and keep the attention of people that care about the ent= ire series and its change over time.=C2=A0 Your assumption is that interest= in contributing will cease at some point, which means most of the people o= n this list will be sufficiently pleased that a good process is in place th= at worry about the series can drop away (more likely dropping to just a &qu= ot;monitoring" role).
--
Wes Hardaker
USC/ISI
--00000000000077948505c2140624-- From nobody Tue May 11 14:17: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 F228F3A26E3 for ; Tue, 11 May 2021 14:17:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PIrBlv-BBydu for ; Tue, 11 May 2021 14:17:03 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 564453A26E2 for ; Tue, 11 May 2021 14:17:03 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id v191so16975323pfc.8 for ; Tue, 11 May 2021 14:17:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=PoAs/+2hnNA4w7d3yEGXJoPuBMXJipznJEDCARGiwRM=; b=FpvO+4J38WOjna2ABpSTtTQhtNriUC/LTgiLUAj6+yismKy4mSf2ylQ1c2r6mOSv6h Osh5Xiv1/USHyN6IbKdgwB2wJO6XbETSZHZ/1LQLlsb5FVimRExduROD4NBJI8bN+JiI gwNpz78giVAv7/nnWSZGMiwOTKtjqdhJ5Jk0JYmNJ7HxQNZxpGxfq/fQHblYAFtsn1cq 7GuNh+8moic6fR7iajGILxJTWDXxVWfLtQi/lolOHtLyklg8LSyHdTBciS66ovDo/Kus Jtp/BuYFsrnysO4epm5BRDmJ6xZt/tCvz21It6REzsXfAC470a896HbwHIxYYOsJeFHb 6nWw== 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=PoAs/+2hnNA4w7d3yEGXJoPuBMXJipznJEDCARGiwRM=; b=uK9yk4zMuECoKvUzb/Cc7ryHubbETv8IkN1bBrCGoOa+6KhJUogyoYe/E/g3RNoqIB TyQ/hYDFk0bU6Mrl6b8d/Fh9COI7J3hSl3odR8WZMfPmVQXDsvoMg2fkw9y9GYhcf0zK Xv5ju5cRpxQFWZruF5xoChvmkLj88xM8SnGqr2qERMz5bqBdIy0rSeF1wxSDLxuVC2vM CKrv0Cot4u8IZslc52IDjkB3E2/jVpshWfrTBx6Iy03zSRi/RiKELC5DuMBHQxRdSc0c 7KAlIp2BsJayCWiwXPrbNwcWZzeA7ujOuT25D2CM1xfKy8N+xKUviaK4vDMf3P+pwITn S+rA== X-Gm-Message-State: AOAM532ULftrzunS+js0+OTL1jxHYbgSvCF0SK7VbHpC4wDNaeJs9CAT gBL+BnisWX5i6sYDOKn+qoJLPOxGOsbgyA== X-Google-Smtp-Source: ABdhPJz3x/j7ozd+OTWwutLAguygwA+sZcZL4P+Xoldi4/aVHCyVcwCy70GrhbPxo3Dsz4dlR0dp8Q== X-Received: by 2002:a62:7648:0:b029:28e:db2a:9f14 with SMTP id r69-20020a6276480000b029028edb2a9f14mr32919890pfc.6.1620767821165; Tue, 11 May 2021 14:17:01 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id c4sm14010642pfn.48.2021.05.11.14.16.58 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 May 2021 14:17:00 -0700 (PDT) To: rfced-future@iab.org References: From: Brian E Carpenter Message-ID: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> Date: Wed, 12 May 2021 09:16:58 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 21:17:08 -0000 On 12-May-21 08:32, Eric Rescorla wrote: > Hi folks, > > Please feel free to tell me if we closed on this and I missed it, but > I don't think we've quite figured out how to handle complaints about > process failures in either the RSAB or the RSWG. In the IETF, as we > all know, you can appeal to the AD or the IESG, and the IAB if you > don't like the answer for the IESG. > > I think I'm persuaded by the argument from Joel and (I think) MT that > the recourse for the RSAB is to complain to the stream management > bodies (i.e., the IESG and IAB) and have the representatives replaced, > rather than have a formal appeal. However, I think we need some > mechanism for dealing with process failures in the RSWG. This is > somewhat complicated by the proposed chair structure where the > two chairs are appointed by different groups. However, if we take > Lars's proposal for the IETF Chair and the IAB, then I think the > IAB should be the appeal body (this is consistent with other suggestions > for them having ultimate responsibity). This also works well b/c > the IETF Chair is on the IAB. I agree (and I've said this on a couple of threads already). Given the precedent in the IETF appeals structure, and remembering where our money comes from, I think we should also ask the ISOC Board to be the final appeal stop, with the same scope as for the IETF case. Cut, paste and patch from https://www.rfc-editor.org/rfc/rfc2026.html#section-6.5.3 Brian From nobody Tue May 11 14:31: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 8AADB3A274B for ; Tue, 11 May 2021 14:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 F7f5Q13awdGf for ; Tue, 11 May 2021 14:31:28 -0700 (PDT) Received: from mail-io1-xd33.google.com (mail-io1-xd33.google.com [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9033A2767 for ; Tue, 11 May 2021 14:31:28 -0700 (PDT) Received: by mail-io1-xd33.google.com with SMTP id k25so19609025iob.6 for ; Tue, 11 May 2021 14:31:28 -0700 (PDT) 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=sA5/JKlJyfs94smAevmNTwrNqoMrYvGP3C22x4nhFXo=; b=k7HLaer7ShDlqc+UETeY9NhUWkP9KX4Ms9L+EGXAz/3BBzXEMQfcf+dXGbyu+GyMet sfpLc0v974O7eOCItLF3ZQMztcMwrfXT7vc2OO1p9mqLwvj34BbdujZ4ywygOY1bJ/51 IQVGB3VToHSHYKp5PfyfnkyFXevDlM3n1s7vzPWOHVfBQw7Sa/3t5bNK54TK0NzePJad ndWa7MoNSeTlmsoZnqsKhb7H53L9x23eUG1UGmOIhFLHLiIRHGaK5oCDEdJ+lLHtwoSQ sQ1wUaQjSVyBDlF7rfLgc+3OVYls2P7n9HwfRaALMSEKZNV8u571LkA5bAgNl7fKeR46 Zzgg== 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=sA5/JKlJyfs94smAevmNTwrNqoMrYvGP3C22x4nhFXo=; b=gy62x+RF1VXUUV421GxSUJrWXet0Wcp8gRbVatmxxlrlpNmu/tHfZbDfKa3Bg4zql/ +RqFaPt8RAUG/C9NcqnuUQQksVArkTlTjGIcJaXLOssJM61M7+Li72mZ2elHYSg4OLPA erDrovag1B6/b+mkcL49RPOBiwq46mUb4ztTuJcLxB553xNnOY4Q8mBqh649Mqy3NhCh 3NpXaQ6Zw07IphuT3YE7lnZiekFNxo8t/f7x22Kt94SeoRXKxxSMkCobz6d4O7DXbkby HKgvmB1WREna1w3EznR77B5UTeerrlYqd3/PrsJXXzq1in94zgFDZvt6qnuMHoKDQ0cZ 4yUQ== X-Gm-Message-State: AOAM532mT9kDDUPfcTUfvgfBFj7zijeHWRUZyQsJeZvzOWHGO7YhLwr5 WG+yOjR1/ROHhgMRU2FHFYPFUSx6uEtCNjtyk/DUQQ== X-Google-Smtp-Source: ABdhPJyX+Nk0tt1IPmhnO3EYFdnQ5tcfH95QGVTPC1ft3WiVAOKMH7C837Unh1gMgtojMqzgvxOG+ORn5ui9tCEOkGk= X-Received: by 2002:a5d:8b01:: with SMTP id k1mr22925440ion.127.1620768686835; Tue, 11 May 2021 14:31:26 -0700 (PDT) MIME-Version: 1.0 References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> In-Reply-To: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> From: Eric Rescorla Date: Tue, 11 May 2021 14:30:50 -0700 Message-ID: To: Brian E Carpenter Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="000000000000d79e8505c2149d85" Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 21:31:42 -0000 --000000000000d79e8505c2149d85 Content-Type: text/plain; charset="UTF-8" On Tue, May 11, 2021 at 2:17 PM Brian E Carpenter < brian.e.carpenter@gmail.com> wrote: > On 12-May-21 08:32, Eric Rescorla wrote: > > Hi folks, > > > > Please feel free to tell me if we closed on this and I missed it, but > > I don't think we've quite figured out how to handle complaints about > > process failures in either the RSAB or the RSWG. In the IETF, as we > > all know, you can appeal to the AD or the IESG, and the IAB if you > > don't like the answer for the IESG. > > > > I think I'm persuaded by the argument from Joel and (I think) MT that > > the recourse for the RSAB is to complain to the stream management > > bodies (i.e., the IESG and IAB) and have the representatives replaced, > > rather than have a formal appeal. However, I think we need some > > mechanism for dealing with process failures in the RSWG. This is > > somewhat complicated by the proposed chair structure where the > > two chairs are appointed by different groups. However, if we take > > Lars's proposal for the IETF Chair and the IAB, then I think the > > IAB should be the appeal body (this is consistent with other suggestions > > for them having ultimate responsibity). This also works well b/c > > the IETF Chair is on the IAB. > > I agree (and I've said this on a couple of threads already). Given > the precedent in the IETF appeals structure, and remembering where > our money comes from, I think we should also ask the ISOC Board to > be the final appeal stop, with the same scope as for the IETF case. > Cut, paste and patch from > https://www.rfc-editor.org/rfc/rfc2026.html#section-6.5.3 > I concur. -Ekr Brian > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --000000000000d79e8505c2149d85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 11, 2021 at 2:17 PM Brian= E Carpenter <brian.e.car= penter@gmail.com> wrote:
On 12-May-21 08:32, Eric Rescorla wrote:
> Hi folks,
>
> Please feel free to tell me if we closed on this and I missed it, but<= br> > I don't think we've quite figured out how to handle complaints= about
> process failures in either the RSAB or the RSWG. In the IETF, as we > all know, you can appeal to the AD or the IESG, and the IAB if you
> don't like the answer for the IESG.
>
> I think I'm persuaded by the argument from Joel and (I think) MT t= hat
> the recourse for the RSAB is to complain to the stream management
> bodies (i.e., the IESG and IAB) and have the representatives replaced,=
> rather than have a formal appeal. However, I think we need some
> mechanism for dealing with process failures in the RSWG. This is
> somewhat complicated by the proposed chair structure where the
> two chairs are appointed by different groups. However, if we take
> Lars's proposal for the IETF Chair and the IAB, then I think the > IAB should be the appeal body (this is consistent with other suggestio= ns
> for them having ultimate responsibity). This also works well b/c
> the IETF Chair is on the IAB.

I agree (and I've said this on a couple of threads already). Given
the precedent in the IETF appeals structure, and remembering where
our money comes from, I think we should also ask the ISOC Board to
be the final appeal stop, with the same scope as for the IETF case.
Cut, paste and patch from
https://www.rfc-editor.org/rfc/rfc2026.ht= ml#section-6.5.3

I concur.

-Ekr

=C2=A0 =C2=A0Brian

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--000000000000d79e8505c2149d85-- From nobody Tue May 11 15: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 CB6F53A2913 for ; Tue, 11 May 2021 15:23:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t5DhOeJBAjsc for ; Tue, 11 May 2021 15:23:08 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 1147A3A28E7 for ; Tue, 11 May 2021 15:23:07 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id y12so15873308qtx.11 for ; Tue, 11 May 2021 15:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=79H6UK/T6yNnPYPtm9aRUy5QE8u0gmgF95R4Ok4Q+W4=; b=uEze++Vi3Lr8ts3+v02ohsB+VCSwVXP6s4KiwIrK3hFAhSmTQnX5ZNa9PFaqbT1M+i R3VTK2sJOdJrmzqTTMquawA/733cGv2NDPCnz0sotneoEPPmqj4zZC8hgcYvo24HQGrl InkTzA0e5ajHu/vOUO61N9bHBIsXbPojD8YF9ik3Prcb0YBM0/KNGGXKhKoQfkha85G2 0IKcwfNKueJgxPbQD+nB0TJLPdMAf0a4WrFWAW/RS4QFjXzbcfwjaSc3i5fbXHKF1HuH CPSDngVpi7gInrqObrK0BmukhCpVV8J+UB7AODlNCbzAjSHeeWo2hgZcC8vAuaAIDn26 oK+Q== 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=79H6UK/T6yNnPYPtm9aRUy5QE8u0gmgF95R4Ok4Q+W4=; b=a6GWkMIGCF66nC9RuDQ35D8TsIuOT3Eg37qsteufdfupgDVaGVmw7qzqgjXxlIPbN5 tf//kOFUKe+EwgLS2faNz/NOgrcbwIb2RTq10fueezIH4r7nw3spLTSMPSerQsejaXDX SM61rlhd3mUUBm/OH2lpPMD0n2x3hRjYmzv0nrzOaWGrVdBhBXOd6sn0lqK+3ZOZKP5Y P5UYcOsV3q6e38M+Y3o1SbHhG8BoitaRbtQ5/93kaa1iYAx7DIUkv8z/i+A4KOaQxqsG skj9dt9Np2t7ffdNKkRHviBu0hr8HYsbKbbpzZZoVp32iIVJOI7mX8G0A45Fv+cKxOb6 9c3g== X-Gm-Message-State: AOAM531ja9vBT9uuttFr1zbgQ50LAUDDxLXQij2E21tJnC96fjeZ+vsG 8MKyqy+VdbSIasVtPe2DSYH56ekQ6UOUx6Fy X-Google-Smtp-Source: ABdhPJzrImZ59Ux1IQ1jYIWrdzan6a7ldcJUeuzb7mMcxSJZTn2PZ93Ri8O+A/kAlmBfx0Q0jkajJQ== X-Received: by 2002:ac8:7658:: with SMTP id i24mr30575691qtr.368.1620771785786; Tue, 11 May 2021 15:23:05 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id x142sm5887711qkb.136.2021.05.11.15.23.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 May 2021 15:23:04 -0700 (PDT) To: Wes Hardaker Cc: "Joel M. Halpern" , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <845c2898-60ed-42cb-0b13-b4e28f76d2bf@nthpermutation.com> From: Michael StJohns Message-ID: <94bb65d3-8d8e-0b25-69b0-70ba5e691d68@nthpermutation.com> Date: Tue, 11 May 2021 18:23:02 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------FE925E479A5944BB0D611599" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2021 22:23:19 -0000 This is a multi-part message in MIME format. --------------FE925E479A5944BB0D611599 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/11/2021 4:48 PM, Wes Hardaker wrote: > > > > 2) The minimum RSWG consists of the RSAB plus the two RSWG > chairs.  The > mailing list may be larger, but the actual active participants may be > very close to that minimum set (at least after the initial burst of > activity). > > > I found this assumption interesting (not knowing if it's right or > wrong).  We have more than 6 people active in this group, eg.  I > wonder if a formal WG like the RSWG will result in the minimum > necessary people working in it, or whether it will attract and keep > the attention of people that care about the entire series and its > change over time. Your assumption is that interest in contributing > will cease at some point, which means most of the people on this list > will be sufficiently pleased that a good process is in place that > worry about the series can drop away (more likely dropping to just a > "monitoring" role). > -- > Wes Hardaker > USC/ISI Two things:  "The minimum RSWG consists of the RSAB plus the two RSWG chairs" is a statement of fact, not an assumption.  That's the minimum set of identifiable folk that will make up the RSWG. The assumption part is that the minimum size and actual size will tend to be approximately equal especially when you have no identifiable activity in progress with the RSWG - e.g. no documents, no plans for such documents, no need for such documents, etc. A typical WG has a work plan and a sunset clause of some sort. (Yes, I know that we have some groups which infinitely recharter, but bear with me).  This group has neither.  It's expected to exist indefinitely, and in no scenario I can think of will they always have something to do. I expect, after an early burst of activity to ratify the discussions and decisions of this group, the RSWG will be left twiddling its thumbs waiting for the next "strategic" decision that will require their input.   One of a few things might happen:  The RSWG might decide to expand its remit and start writing documents that reach into the tactical - most of which I hope the RSAB will reject;  The RSWG membership might fade away due to lack of anything to do; or I might be wrong and there will be sufficient continuous need for RSWG documents that sufficient folk will remain engaged (and have sufficient pull with their employers to be able to offer document creation services for something that probably won't put money in their employer's coffers). I believe the "fade away" is the most likely result, which begs the question of what happens when and if the next "strategic" decision point comes along.  Peter said "we'd" do something at that point, begging the question for me of who "we" is? By the way, as I count it, we've got something less than a dozen active voices on this list.    And the current number for the RSAB plus RSWG chairs is actually 7 not six.  So, not a big reach to get to equivalent levels, especially if we add a few nomcom selected members of the RSAB. Later, Mike --------------FE925E479A5944BB0D611599 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/11/2021 4:48 PM, Wes Hardaker wrote:


2) The minimum RSWG consists of the RSAB plus the two RSWG chairs.  The
mailing list may be larger, but the actual active participants may be
very close to that minimum set (at least after the initial burst of
activity).

I found this assumption interesting (not knowing if it's right or wrong).  We have more than 6 people active in this group, eg.  I wonder if a formal WG like the RSWG will result in the minimum necessary people working in it, or whether it will attract and keep the attention of people that care about the entire series and its change over time.  Your assumption is that interest in contributing will cease at some point, which means most of the people on this list will be sufficiently pleased that a good process is in place that worry about the series can drop away (more likely dropping to just a "monitoring" role).
--
Wes Hardaker
USC/ISI

Two things:  "The minimum RSWG consists of the RSAB plus the two RSWG chairs" is a statement of fact, not an assumption.  That's the minimum set of identifiable folk that will make up the RSWG.  The assumption part is that the minimum size and actual size will tend to be approximately equal especially when you have no identifiable activity in progress with the RSWG - e.g. no documents, no plans for such documents, no need for such documents, etc.


A typical WG has a work plan and a sunset clause of some sort.  (Yes, I know that we have some groups which infinitely recharter, but bear with me).  This group has neither.  It's expected to exist indefinitely, and in no scenario I can think of will they always have something to do.

I expect, after an early burst of activity to ratify the discussions and decisions of this group, the RSWG will be left twiddling its thumbs waiting for the next "strategic" decision that will require their input.   One of a few things might happen:  The RSWG might decide to expand its remit and start writing documents that reach into the tactical - most of which I hope the RSAB will reject;  The RSWG membership might fade away due to lack of anything to do; or I might be wrong and there will be sufficient continuous need for RSWG documents that sufficient folk will remain engaged (and have sufficient pull with their employers to be able to offer document creation services for something that probably won't put money in their employer's coffers).

I believe the "fade away" is the most likely result, which begs the question of what happens when and if the next "strategic" decision point comes along.  Peter said "we'd" do something at that point, begging the question for me of who "we" is?

By the way, as I count it, we've got something less than a dozen active voices on this list.    And the current number for the RSAB plus RSWG chairs is actually 7 not six.  So, not a big reach to get to equivalent levels, especially if we add a few nomcom selected members of the RSAB.

Later, Mike


--------------FE925E479A5944BB0D611599-- From nobody Tue May 11 15: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 050763A291E for ; Tue, 11 May 2021 15:37:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yl1OIXmXx51g for ; Tue, 11 May 2021 15:37:13 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45E6B3A291D for ; Tue, 11 May 2021 15:37:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4Fft8S47DGz1nts2; Tue, 11 May 2021 15:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1620772632; bh=xOVaby618x1DmQQrhiqVu+8qpvyAhE0Kgwi0oJsXN9o=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=HysReduGSQREAwmampH7Tu7YPgDLvSjdylCcUn5nPlua1Pn4LNQwho8g9H8oTFv6D Cq+zb1QCunUZuDIFtSz56To7/+mAD4dQGbPF7xeqHmrX2YSGvrZCI1e3IDv2xTSxSd +YUAAIM1Ve1QHrm5pWzH1LxqTIoUpcneciUVwKz0= X-Quarantine-ID: X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 4Fft8R60h6z1nsC8; Tue, 11 May 2021 15:37:11 -0700 (PDT) To: Michael StJohns Cc: "Joel M. Halpern" , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <845c2898-60ed-42cb-0b13-b4e28f76d2bf@nthpermutation.com> <94bb65d3-8d8e-0b25-69b0-70ba5e691d68@nthpermutation.com> From: Joel Halpern Direct Message-ID: <354b722f-4424-8763-2abd-3ab076d7b780@joelhalpern.com> Date: Tue, 11 May 2021 18:37:11 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <94bb65d3-8d8e-0b25-69b0-70ba5e691d68@nthpermutation.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 11 May 2021 22:37:19 -0000 I presume that quite a number of folks will remain subscribed the the RSWG email list, and will engage when there is something on which to engage. I may be being too much of an optimist. Having said that, I am missing the relationship between this description of the problem and the proposed solution. The big risk I see with the problem (if it comes to pass) is precisely that it will result in the RSAB being able to foist whatever it wants on the larger community as the RSWG recommendation. I don't see that as a reason to give them the authority to do so even if the RSWG is engaging (but happens to disagree with the RSAB). And I think this is quite separate from the question of who has the auhtority to say "it isn't work". I don't particularly like Brian's proposed answer of "the IAB". But since I can't come up with a better answer, I guess I can live with that. Yours, Joel On 5/11/2021 6:23 PM, Michael StJohns wrote: > On 5/11/2021 4:48 PM, Wes Hardaker wrote: >> >> >> >> 2) The minimum RSWG consists of the RSAB plus the two RSWG >> chairs.  The >> mailing list may be larger, but the actual active participants may be >> very close to that minimum set (at least after the initial burst of >> activity). >> >> >> I found this assumption interesting (not knowing if it's right or >> wrong).  We have more than 6 people active in this group, eg.  I >> wonder if a formal WG like the RSWG will result in the minimum >> necessary people working in it, or whether it will attract and keep >> the attention of people that care about the entire series and its >> change over time. Your assumption is that interest in contributing >> will cease at some point, which means most of the people on this list >> will be sufficiently pleased that a good process is in place that >> worry about the series can drop away (more likely dropping to just a >> "monitoring" role). >> -- >> Wes Hardaker >> USC/ISI > > Two things:  "The minimum RSWG consists of the RSAB plus the two RSWG > chairs" is a statement of fact, not an assumption.  That's the minimum > set of identifiable folk that will make up the RSWG. The assumption part > is that the minimum size and actual size will tend to be approximately > equal especially when you have no identifiable activity in progress with > the RSWG - e.g. no documents, no plans for such documents, no need for > such documents, etc. > > > A typical WG has a work plan and a sunset clause of some sort. (Yes, I > know that we have some groups which infinitely recharter, but bear with > me).  This group has neither.  It's expected to exist indefinitely, and > in no scenario I can think of will they always have something to do. > > I expect, after an early burst of activity to ratify the discussions and > decisions of this group, the RSWG will be left twiddling its thumbs > waiting for the next "strategic" decision that will require their > input.   One of a few things might happen:  The RSWG might decide to > expand its remit and start writing documents that reach into the > tactical - most of which I hope the RSAB will reject;  The RSWG > membership might fade away due to lack of anything to do; or I might be > wrong and there will be sufficient continuous need for RSWG documents > that sufficient folk will remain engaged (and have sufficient pull with > their employers to be able to offer document creation services for > something that probably won't put money in their employer's coffers). > > I believe the "fade away" is the most likely result, which begs the > question of what happens when and if the next "strategic" decision point > comes along.  Peter said "we'd" do something at that point, begging the > question for me of who "we" is? > > By the way, as I count it, we've got something less than a dozen active > voices on this list.    And the current number for the RSAB plus RSWG > chairs is actually 7 not six.  So, not a big reach to get to equivalent > levels, especially if we add a few nomcom selected members of the RSAB. > > Later, Mike > > From nobody Tue May 11 17:15: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 BD3193A2BF6 for ; Tue, 11 May 2021 17:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 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, 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 7zzV2cstGH_Q for ; Tue, 11 May 2021 17:15:50 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300121.outbound.protection.outlook.com [40.107.130.121]) (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 323293A2BF5 for ; Tue, 11 May 2021 17:15:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TSJnr46CWr36z+316WMyYvRV0CdZauXmilSZB3yb716zj/85AagZ3haXbF6NjKAiUHLlUJtGStyB5sL0XfDeczMgFvIllFa9oZ0aI/zBmDEUNTpa052SqeoY6ZZxuez4RkD2rY+a5T8um1JYq1KwRHE2z/79Hzi+kYi9UJDhIt+CV1ZTHz0LMTln5bYgrHppSxzJ5s9emaW8OAz1nVDK11xNJwGSM0Mx0pczFBM2GM/9vw7RFYPNjWg9PgjxB7dadt4S7aTGOBmHwl4/eFzfNMjoQfltloMZB4w8pWBseaPItISbfFvaknhkjc7+f3o7ziecqVBl/EfZw6YCoDpG0g== 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=Nz0+DXDVO9LvwqD+ryatZH4xMgN5Nv4Wngt5QlxGq2g=; b=Ckwd9d+LdFwGw8bRsdafV7VgLb0p1lRu7pPomGGrykJ1MoqacOxxyz7f6sLtRS7Yi6Ugqthv6ry60kAmKSAnzo11qBfqj5pweObhpJBr4v1aeG0He3fEG1beGdUzawzNnaoHUzORyiHn0mBiQDqpBQMe0gDgishHnqhnLkob8du3fQU+QB3rMsAqsjC19NpFSjtVFkZ5iUz+OgAhzisOp8WNGKOQqNTcCQVn+rua0fYFqAY1WuA7btl1tcm7nAt0H2P3sYRz7TkHM3MrxSf79I2WD8nW/LkMxlqNOcb31t94VGP/R/I86E0DS/0HzwzeNuaa217WhtOoDjwtkzv7Zw== 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=Nz0+DXDVO9LvwqD+ryatZH4xMgN5Nv4Wngt5QlxGq2g=; b=hmXYjoEko1Lpv3jakzNme5zy2hcCAdU+UH3DGv4/f1C7FhWot6W5bRJ066+fSmsNSrsTPvQZWHxsE5+2Xk6ZmefsmgX83IjDJCallX/8m6QKbPePVj6qkfS09Y14zIObBks5hQGmrPTb/J8I3yxPY3k1+s661N1A+DstfJ1lcog= Authentication-Results: nthpermutation.com; dkim=none (message not signed) header.d=none;nthpermutation.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB3754.jpnprd01.prod.outlook.com (2603:1096:404:dd::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25; Wed, 12 May 2021 00:15:41 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511%5]) with mapi id 15.20.4108.031; Wed, 12 May 2021 00:15:41 +0000 To: Brian E Carpenter , Eliot Lear , "Joel M. Halpern" Cc: rfced-future@iab.org, Michael StJohns References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> Date: Wed, 12 May 2021 09:15:40 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [114.185.21.49] X-ClientProxiedBy: TYAPR01CA0079.jpnprd01.prod.outlook.com (2603:1096:404:2c::19) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.5] (114.185.21.49) by TYAPR01CA0079.jpnprd01.prod.outlook.com (2603:1096:404:2c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Wed, 12 May 2021 00:15:41 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 93606ddd-1609-47f2-7a79-08d914db13d1 X-MS-TrafficTypeDiagnostic: TY2PR01MB3754: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: YjDm2T/u/4s2sviRX89IsS2JMVq7Z3dTSY8itQqkbXnQLcFme31woW/wzCf2sdJpAYl6COVV1A1yiS8/vDlJJ0gEt4zJ2mSWSEptpEgFg7HYpnADbZZO5Kjn2a2M7RNVV2PxWurDhP0zamlqPAh/v471sDmS9ULHtI7SdvNJnPrDbkDa2HyJuIflbEFn0BIW/G3fwoU9ST+CQg6f+yq4KKKQLgBtLmdJ+o118EWCgN4/SPN28U4LH4yN6HIgHiJoqQu48E/DbwPlFursz7TfPa0T4yP9zeOvGePFE5ZLgxBkOpRYNubyACM22ZzJGkQgNONwGpA+a4WyrKt+s5MxfOpz0f10+5iYmBZGXyC72ZlU6PH7DPuNITufFHl6wnXWSh91vv6gdy4N1SS1YN3SETMtBaHS4forkJfSYUgOxP8S7KudF0GeVIkiSe+ZBP5IeDAYUnjGluRUh44AFtewNsEIh5b91a5sLlZyAfTpyXDeLIl0Moey3hrnSAmiCbDUf6mR/CScQ68S04J6ZiXzO5hRO6gE9vjFbNxrS+dH0c0kTAiH/Q+wPdAOQD4z06UFppSDCEg/rwDBAxAUe7qcKiHPZtgEMCY3B9oBEaHTc3KLtgke/X8FXlGiqAzrIha3rotYLYQ9dWW0qvoNTAw9swfpriloXFjcq+Rs35HB1rbHQZgYfz3BoiVhEKLXZebclnKJNUJooVcnMVL+mtSYfeSaEEwAI4PA8xIfda36urilvlg32qYHZe8sprHhfvHcTvZ5NSahkDt4mX8IQ9RNjC7ms5lnhIa14MdKzupPTCk= 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:(39830400003)(396003)(346002)(366004)(136003)(376002)(478600001)(38100700002)(38350700002)(2616005)(5660300002)(956004)(31696002)(53546011)(966005)(316002)(8936002)(8676002)(86362001)(26005)(16576012)(66556008)(110136005)(66946007)(66476007)(4326008)(2906002)(52116002)(186003)(16526019)(66574015)(31686004)(83380400001)(786003)(6486002)(36916002)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?MVF4bzhnSThkRWlreWkzTkNQd2xkRk92akt0d044TlJpWnFDc3lUM29RamNB?= =?utf-8?B?SjlYc0pTUHU5RXBCOFNkVHpXd1JzbWM0QStPS2RCWGJiTFlwb3dBenBVQUQ1?= =?utf-8?B?QTk0RzBydzRLdU5OZlY4bGtEeGpST1V4bTZScUQ2YUZBMDZJWGZ0OGZZVGFo?= =?utf-8?B?ZlUvMERTZHdCTG9LTjlUdUtQbWFZOFk1RG1iNEd1YllvQWJ3QWliaDgyZ1lD?= =?utf-8?B?cnQ0eVRzTy84VWdubWEwdG04ZmF1OWd5cDRLd3FFa3hld0Y2Zzl5UVN0SEdm?= =?utf-8?B?VGdCb0ZSeU90c1JuZXBRaEIrYklwRVBtUGdLMjh4c3FOZzN6YzdoMllOU0Jy?= =?utf-8?B?UkxqN3AzRUxjM0MxMEpSY3E4VFEyNWpBbmpJTHRoNlNvaEtIelk3NzRNWCs3?= =?utf-8?B?NTV6VUFOclk4TVk4czhEeTQrZncrNlFZT21sT1pwcno5bW5PemNYRWFmekZq?= =?utf-8?B?SU1XY0pyeklpZ3ZKVEF6aHhXMXFuclhqRG9Bdmw4cUYraWNDeXJHY3dieFVW?= =?utf-8?B?eVhyelA1OFZzcTNjWndXUE84SHlBRGpobWFLK2JPR2FjRkdGRGFLUytvSlJK?= =?utf-8?B?aXdKTURLVHZpNWJXdTI0VjJoZ0VoNWJ6SVpWLzZsZk4yeEZmMElvbVBzdjJQ?= =?utf-8?B?Z2NtdHpsQkh4N05IaUFXeVJNRTd4ekpFMWtBRHplSVBWUXRUenlkd3lkYSsw?= =?utf-8?B?Si9NaGFYb01teklKRlRGM1VpOW1ZbSt4UEhFcm4zZUtxdkxrN083SHd6UEd5?= =?utf-8?B?V2JzYlRNclNWRGpSZm84U21SbEQydEVleW9nZ3hoU1BaSlRhMXNnTnhPQ3JM?= =?utf-8?B?S3paWVNaejJWY0QxbEJiMjl1dVVMN0c0dTZ0YjA2QmZlRlIwWXRDU2hWTnhr?= =?utf-8?B?RkN1dnA1L2lnbEJHbU1idDM4Vm5sVW5KTkhPZHJtS0ZGMDBFOEZZS21nNlVR?= =?utf-8?B?S1J1b3pvSmhYdG5hU2pPUWI5VFltY3hXQ2hEWlh4WFVkUldlcEZqUWQzamp3?= =?utf-8?B?RW1EL1pFK0IzRFFXMlF5YXUvZTl0Y1ZmT2RDczJLbk5Ebzh4YmVtM2cwOWdy?= =?utf-8?B?K3hqUkloVDJCbnowS2o5cGp2V0VTQzRsTmhZd2huOG43ZVplcVhGdjZVOXlv?= =?utf-8?B?cExudE16U2hKMWt5VHpnUldvTGtRdkRMRzVlMVNNM3FBb3h1aGNOQ3V3L21D?= =?utf-8?B?dkVtYVhmNmZJVU9scVUzN0lVc09XUVRDVGpxNVdpUVdxR1hseVlOOWV6cmlr?= =?utf-8?B?dExjTEtzdi9XREdyanQzbVV5SExtUVlzYVFReDJqRjlZQ2E5TS9iU2MxT3Q1?= =?utf-8?B?Znl0b0tDUVlPM3M5ZG1IWHJUcXI4QkwybVVJbFpXY0oxdDh2aVoxMk4wbC9o?= =?utf-8?B?VThrVU1rUnpPSFNTZmxWcnQzbnZHWVg5M2JCbTBSeWxwV3lCeXI0UTE5MnlU?= =?utf-8?B?NDFQOVFseGpxUkVLa2s2VUludVhJRktLUHYwcHJNU3JoZWh0MW1vNDhORHk5?= =?utf-8?B?M2ZiVHRWbnUrRlVCMktUMFFPTnJPMTN3MjVsQ3JQaE1IQXI0QXQxY3hJWXZU?= =?utf-8?B?bkxuWlJIU0tscWJKRnpxY0NiOERQLzY5YWVVV0FYUUNSNkJaR0xvYythN2JR?= =?utf-8?B?eml2STNPaG81TzlRNkdhc0tKYmhtckN2L3pHTUM1R2xjTlNTU25WYkk3djNq?= =?utf-8?B?d3JzN0tlVDRxRGJlSmN5QytPK2RTZHlBMVNFV3ZCajJ1YlM1aEQ0bEhaUGhi?= =?utf-8?Q?L7CqFphF4/rO5vSB6ZXHbiIBJ9UprnTUDTzIN33?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 93606ddd-1609-47f2-7a79-08d914db13d1 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2021 00:15:41.4296 (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: MfIbR/qI4xsniALf6S4U+RmjKyzQap+t3AYqbFAOd+yA3IMAlkIz72kuERozxPCE9P9l0RrFaGtgT/Z6BRJCfg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB3754 Archived-At: Subject: Re: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 May 2021 00:15:56 -0000 Hello Brian, everybody, On 2021-05-11 11:09, Brian E Carpenter wrote: > On 10-May-21 21:16, Eliot Lear wrote: >> Hi Joel, >> >> Yes, this is a good point, but I want to restate it slightly, and I’ve opened Issue 63 to do so: >> >> Who has the final authority to make evolve the processes that we are defining here?  Can we enumerate possible answers? >> >> * Does it continue to rest with the IAB? > > As I said on the thread for another issue, my current feeling is > that the IAB should be in the appeal chain after the RSAB. (If we > continue that line of thought, we'd ask the ISOC Board to be the > end point, as it is for IETF process issues.) I think we have to be careful to distinguish the following two things: 1) The formal appeal process. For this, I'm okay with what    Brian proposes just above. Some other arrangements may also be okay. 2) The authority to evolve the process. This may rest (formally)    with the same organizations as the appeal process, or it may not.    If we look at the current instance (i.e. the work of this very    group), I'm not exactly sure about how it worked, but I don't    remember any kind of appeal being involved. What I remember    is having a lot of community discussion/pressure involved, based    on a general feeling that something went wrong. Regards,   Martin. >> * Could it rest with the community as represented by the RFCWG and confirmed by the RSAB? > > As long as there is an appeal chain as above. > >> * Is it the IETF community as confirmed by the IESG? > > No. It's wider than the IETF. That's why this will not > be an IETF WG. From a higher level viewpoint, I think > the RSAB is a peer group of the IESG and the IRSG. > (It's almost as if we were setting up the RFC Task Force.) > >> * Is it the IETF community as confirmed by the IAB? > > Ditto. > >> * Other? > > I don't think so. > > Regards > Brian > > >> >> Eliot >> >>> On 10 May 2021, at 05:55, Joel M. Halpern > wrote: >>> >>> Buried in the below is an interesting and important point. >>> Suppose that we work out a process, agree to it, and try it.  And > it fails.   (For any number of possible meanings of "fail".) >>> >>> Who has the authority to decide something needs to be done?  Who has the authority to make something happen.  Under current rules, whether we like them or not, the authority for what we are doing comes from > the IAB, via the RFCs that say it is the IABs job. >>> >>> It seems to me that Mike's point below about who has the ultimate authority is important.  And at that point, I don't think "the community" is a viable answer. >>> >>> Yours, >>> Joel >>> >>> PS: I am sorry you do not like my usage of strawman Mike.  But the premise for your objection is sufficiently vague that I do not know what else to call it.  If the only purpose of your description was to get to the "who has authority to fix things if they are broken", then as above, I agree that is an important question.  I was completely unable to get to that issue from what you wrote.  In particular, I could not connect that with your conclusion that the RSAB should be empowered to bypass the RSWG. >>> >>> On 5/9/2021 10:58 PM, Michael StJohns wrote: >>>> On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >>>>> Mike, your analysis seems a bit flawed. >>>>> Yes, the IESG approved those documents after community consultation, > on the basis that the community had agreed. >>>>> And yes, that judgement was made by the IESG. >>>>> >>>>> On the other hand, if the community members had thought the IESG conclusion was wrong, that was appealable to the IAB. >>>> The way I've always understood it is that process can be appealed with some possibility of a reversal, but a decision that follows the process, no matter whether some community members thought it was the wrong decision, is unlikely to be reversed. >>>>> >>>>> That is very different from declaring that the RSAB can publish a document without community approval. >>>> See above.  AFAICT, there were folks in opposition to the Nomcom > decision, but the community was heard.  I'm not saying that the community will not be heard, but I'm saying - similar to what the IESG did with documenting the Nomcom decision - that individual members or even a small subsection of the community should not have a veto over the publication of documents that the RSAB believes necessary for the operation of the > streams. >>>>> And given the structure that is proposed, there seems much less reason for any process that bypasses the working group. >>>> WGs by their nature are self-selected and generally consist of a small percentage of the overall community with strong opinions about the topics covered by the WG (with the active participants being even somewhat smaller).   When the scope is small enough - e.g. DNSOP for example - the community affected by the decisions will mostly mirror the community represented by the WG.  When the scope is large enough - e.g. Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of the WG represent the best results for the community of the whole.  In > the Nomcom case, we were able to gather a reasonably large group of people (in the form of a WG)  of diverse views for a sufficient time (multiple times) to spend a very large amount of effort to craft and recraft the Nomcom process.  But that differs from this proposed WG in that the various Nomcom related WGs had well defined target outputs and a need > to complete in a reasonably short period of time (by IETF standards at >>>> least). >>>> I'm trying to avoid us replacing the RSOC with the RSWG - but I can't > see how we can get enough diversity of interest for an indefinite period of time to ensure that the RSWG continues to operate as a useful source of community involvement rather than a place for a small number of self-selected folk to have an overly large continuing impact on a process that's > absolutely critical to the community's success.  Nor has any one been willing to address that specific point. >>>> Peter did say: >>>>> Yes, there are failure modes where the WG is inactive (in which case >>>>> we'd need to inject more energy) or unable to reach consensus (in which >>>>> case we'd need to work harder to do so), >>>> But I would ask who the "we'd" is in the above?  e.g. once this group dissolves in favor of the new structure, who has the responsibility > of fixing things if the WG structure fails or devolves?  Are we going to be back here in 4 years?  Or does the RSAB go on its merry way and do what it needs to do?  If not, who reconstitutes the next RFCED-Futures group given that we will have taken the IAB out of the picture?  The RSAB? >>>>> >>>>> I think everyone knows that I do not like the current approach. But I can live with it.  And it seems to be the approach the community wants. >>>> Or at least the 1/2 dozen or so people who have argued for the approach - not sure that's the community. >>>>> Creating strawmen as obstacles does not seem helpful. >>>> And thanks for that denigrating comment.   You might not like what I'm saying nor agree with them, but calling them strawmen implies > that they are there simply to providing a blocking issue and they have no > basis in reality and that I'm doing that simply to screw up what process there is. >>>> Mike >>>>> >>>>> Yours, >>>>> Joel >>>>> >>>>> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>>>>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>>>>> IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 >>>>>>> as a canonical example: the IESG approved it as a BCP by standard >>>>>>> process including IETF Last Call. The IAB co-signed it too, on its >>>>>>> own authority. >>>>>>> >>>>>>>     Brian >>>>>> >>>>>> A much better (and much more recent) counter example is draft-iesg-nomcom-eligibility-2020 which became RFC 8788. >>>>>> >>>>>> This was an IESG initiated document that solicited community input, > but ultimately was published on the IESG's dime with their sole interpretation of community consensus. >>>>>> >>>>>> RFC6360.  RFC3932.  And RFC 3710 (the IESG charter). >>>>>> >>>>>> The point is that the IESG does this too.  And its not a bad thing, especially when we have 100 different opinions and we need a final answer sooner rather than later. >>>>>> >>>>>> I don't expect the RSAB to do a lot of internally originated documents, but I do expect there will be cases where a decision has to be made, > and that there will be some immediacy necessary. >>>>>> >>>>>> Later, Mike >>>>>> >>>>>> >>>>>> >>> >>> -- >>> Rfced-future mailing list >>> Rfced-future@iab.org >>> https://www.iab.org/mailman/listinfo/rfced-future >> >> > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Tue May 11 18:08:38 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54BB3A2D74 for ; Tue, 11 May 2021 18:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9ty5avRWEHL for ; Tue, 11 May 2021 18:08:31 -0700 (PDT) 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 083F53A2D72 for ; Tue, 11 May 2021 18:08:30 -0700 (PDT) Received: by mail-pj1-x1034.google.com with SMTP id gq14-20020a17090b104eb029015be008ab0fso657563pjb.1 for ; Tue, 11 May 2021 18:08:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=U3ZqFuCn2GQ25IP1qMXCiKc4Aqj3r/t/u4tLIbldWhw=; b=fYBraslj5t7uWDZU07GslxKT+C1prjojIxzUM++geJ58hjWwmhBl8BdaYc8rSkuGV6 2nmkTPmx0kZNICLTRmw6CByAFiY9qqcFwfBxFCz7FFsU+U0/CdbOVaxuelKQyUttHZ6Z nRegoPapp8LFpPptEOBNRXy4aMLSZYMe87XaHopmIQ9cahGAA3mZ2FJgP4XC/I9H8cH+ n6VYJGNPS81GgTL71b0Mhs4qqNWaK4h9SFaIxOGQPNvUDHIrJrDWXnFHwJCFtJyI/ErS XzLo3qOFZI+wNWVCpldJfxS3g1hokmGrJrBlYslcC6H7Ni+BvgQeDmmTDK5+pY/Y9wFZ IxZw== 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=U3ZqFuCn2GQ25IP1qMXCiKc4Aqj3r/t/u4tLIbldWhw=; b=rCz2GA40/rmmGGZfOCR/1oBS414qt2RtkRg+sP2R/d33KfkjHFRaD+JFSpcjLsEADs vbkbGDEbflluPKlAIc9Q2/ArJbHWNefCWhKnyrtU+ydx3sxLhWY33rCFTbK3qe8cBEHW 2X3m2lR8d2+840YwE3IS5abTXRaNLrRwZkN6IVl16solEnE2TL7hzGKswEfR8V60c0xe M53yVObZZnix8t0KXx7JkwfIGGN35948xZC280yrSisIsCsnnlLm6fwZ1S7dbzTgxVoM sJ6qK0epaS2y13G5qD1QfP8k7Zddm0FZ6WEfYhnQTSi0Ml6yXZS5rtHxhp1wYo0KQgno xoag== X-Gm-Message-State: AOAM533y9nOkqZdVMaXczEK0A40nSaixxiDY/qVWvyT4LJ1rq+PSnZfX Pq3AfgU3ubtatJvp4HQGSjc= X-Google-Smtp-Source: ABdhPJyUm51aayLhUMxkhSmSgQkiD+9adRSJgNIQY4nBNEuZOQGFEO6rLtblNLYdfPUcYRwXH7mwWQ== X-Received: by 2002:a17:902:d501:b029:ed:1847:1617 with SMTP id b1-20020a170902d501b02900ed18471617mr32861224plg.29.1620781709765; Tue, 11 May 2021 18:08:29 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id s184sm14902099pgc.29.2021.05.11.18.08.26 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 11 May 2021 18:08:29 -0700 (PDT) To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Eliot Lear , "Joel M. Halpern" Cc: rfced-future@iab.org, Michael StJohns References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> From: Brian E Carpenter Message-ID: Date: Wed, 12 May 2021 13:08:23 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <33ef1b85-97da-f4e1-0d13-a61cd80546c2@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] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 May 2021 01:08:36 -0000 On 12-May-21 12:15, Martin J. D=C3=BCrst wrote: > Hello Brian, everybody, >=20 > On 2021-05-11 11:09, Brian E Carpenter wrote: >> On 10-May-21 21:16, Eliot Lear wrote: >>> Hi Joel, >>> >>> Yes, this is a good point, but I want to restate it slightly, and I=E2= =80=99ve opened Issue 63 to do so: >>> >>> Who has the final authority to make evolve the processes that we are = defining here? =C2=A0Can we enumerate possible answers? >>> >>> * Does it continue to rest with the IAB? >> >> As I said on the thread for another issue, my current feeling is >> that the IAB should be in the appeal chain after the RSAB. (If we >> continue that line of thought, we'd ask the ISOC Board to be the >> end point, as it is for IETF process issues.) >=20 > I think we have to be careful to distinguish the following two things: >=20 > 1) The formal appeal process. For this, I'm okay with what > =C2=A0 =C2=A0Brian proposes just above. Some other arrangements may al= so be okay. >=20 > 2) The authority to evolve the process. This may rest (formally) > =C2=A0 =C2=A0with the same organizations as the appeal process, or it = may not. > =C2=A0 =C2=A0If we look at the current instance (i.e. the work of this=20 very > =C2=A0 =C2=A0group), I'm not exactly sure about how it worked, but I d= on't > =C2=A0 =C2=A0remember any kind of appeal being involved. What I rememb= er > =C2=A0 =C2=A0is having a lot of community discussion/pressure involved= , based > =C2=A0 =C2=A0on a general feeling that something went wrong. I'd say: the same authority for both. Otherwise we could be accused of manufacturing bureaucracy. The past situation effectively gave final authority to the IAB and the only recourse was a recall. I don't think anybody was happy with that. Brian >=20 > Regards, =C2=A0 Martin. >=20 >>> * Could it rest with the community as represented by the RFCWG and=20 confirmed by the RSAB? >> >> As long as there is an appeal chain as above. >> >>> * Is it the IETF community as confirmed by the IESG? >> >> No. It's wider than the IETF. That's why this will not >> be an IETF WG. From a higher level viewpoint, I think >> the RSAB is a peer group of the IESG and the IRSG. >> (It's almost as if we were setting up the RFC Task Force.) >> >>> * Is it the IETF community as confirmed by the IAB? >> >> Ditto. >> >>> * Other? >> >> I don't think so. >> >> Regards >> Brian >> >> >>> >>> Eliot >>> >>>> On 10 May 2021, at 05:55, Joel M. Halpern > wrote: >>>> >>>> Buried in the below is an interesting and important point. >>>> Suppose that we work out a process, agree to it, and try it. =C2=A0A= nd >> it fails. =C2=A0=C2=A0(For any number of possible meanings of "fail".)= >>>> >>>> Who has the authority to decide something needs to be done? =C2=A0Wh= o has the authority to make something happen. =C2=A0Under current rules, = whether we like them or not, the authority for what we are doing comes fr= om >> the IAB, via the RFCs that say it is the IABs job. >>>> >>>> It seems to me that Mike's point below about who has the ultimate au= thority is important. =C2=A0And at that point, I don't think "the communi= ty" is a viable answer. >>>> >>>> Yours, >>>> Joel >>>> >>>> PS: I am sorry you do not like my usage of strawman Mike. =C2=A0But = the premise for your objection is sufficiently vague that I do not know w= hat else to call it. =C2=A0If the only purpose of your description was to=20 get to the "who has authority to fix things if they are broken", then as = above, I agree that is an important question. =C2=A0I was completely unab= le to get to that issue from what you wrote. =C2=A0In particular, I could=20 not connect that with your conclusion that the RSAB should be empowered t= o bypass the RSWG. >>>> >>>> On 5/9/2021 10:58 PM, Michael StJohns wrote: >>>>> On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >>>>>> Mike, your analysis seems a bit flawed. >>>>>> Yes, the IESG approved those documents after community consultatio= n, >> on the basis that the community had agreed. >>>>>> And yes, that judgement was made by the IESG. >>>>>> >>>>>> On the other hand, if the community members had thought the IESG c= onclusion was wrong, that was appealable to the IAB. >>>>> The way I've always understood it is that process can be appealed w= ith some possibility of a reversal, but a decision that follows the proce= ss, no matter whether some community members thought it was the wrong dec= ision, is unlikely to be reversed. >>>>>> >>>>>> That is very different from declaring that the RSAB can publish a = document without community approval. >>>>> See above.=C2=A0 AFAICT, there were folks in opposition to the Nomc= om >> decision, but the community was heard.=C2=A0 I'm not saying that the c= ommunity will not be heard, but I'm saying - similar to what the IESG did=20 with documenting the Nomcom decision - that individual members or even a = small subsection of the community should not have a veto over the publica= tion of documents that the RSAB believes necessary for the operation of t= he >> streams. >>>>>> And given the structure that is proposed, there seems much less re= ason for any process that bypasses the working group. >>>>> WGs by their nature are self-selected and generally consist of a sm= all percentage of the overall community with strong opinions about the to= pics covered by the WG (with the active participants being even somewhat = smaller).=C2=A0=C2=A0 When the scope is small enough - e.g. DNSOP for exa= mple - the community affected by the decisions will mostly mirror the com= munity represented by the WG.=C2=A0 When the scope is large enough - e.g.=20 Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of = the WG represent the best results for the community of the whole.=C2=A0 I= n >> the Nomcom case, we were able to gather a reasonably large group of pe= ople (in the form of a WG)=C2=A0 of diverse views for a sufficient time (= multiple times) to spend a very large amount of effort to craft and recra= ft the Nomcom process.=C2=A0 But that differs from this proposed WG in th= at the various Nomcom related WGs had well defined target outputs and a n= eed >> to complete in a reasonably short period of time (by IETF standards at= >>>>> least). >>>>> I'm trying to avoid us replacing the RSOC with the RSWG - but I can= 't >> see how we can get enough diversity of interest for an indefinite peri= od of time to ensure that the RSWG continues to operate as a useful sourc= e of community involvement rather than a place for a small number of self= -selected folk to have an overly large continuing impact on a process tha= t's >> absolutely critical to the community's success.=C2=A0 Nor has any one = been willing to address that specific point. >>>>> Peter did say: >>>>>> Yes, there are failure modes where the WG is inactive (in which ca= se >>>>>> we'd need to inject more energy) or unable to reach consensus (in = which >>>>>> case we'd need to work harder to do so), >>>>> But I would ask who the "we'd" is in the above?=C2=A0 e.g. once thi= s group dissolves in favor of the new structure, who has the responsibili= ty >> of fixing things if the WG structure fails or devolves?=C2=A0 Are we g= oing to be back here in 4 years?=C2=A0 Or does the RSAB go on its merry w= ay and do what it needs to do?=C2=A0 If not, who reconstitutes the next R= FCED-Futures group given that we will have taken the IAB out of the pictu= re?=C2=A0 The RSAB? >>>>>> >>>>>> I think everyone knows that I do not like the current approach. Bu= t I can live with it.=C2=A0 And it seems to be the approach the community=20 wants. >>>>> Or at least the 1/2 dozen or so people who have argued for the appr= oach - not sure that's the community. >>>>>> Creating strawmen as obstacles does not seem helpful. >>>>> And thanks for that denigrating comment.=C2=A0=C2=A0 You might not = like what I'm saying nor agree with them, but calling them strawmen impli= es >> that they are there simply to providing a blocking issue and they have=20 no >> basis in reality and that I'm doing that simply to screw up what proce= ss there is. >>>>> Mike >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>>>>>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>>>>>> IMHO, the IAB can and does do this but the IESG doesn't. Take RF= C1984 >>>>>>>> as a canonical example: the IESG approved it as a BCP by standar= d >>>>>>>> process including IETF Last Call. The IAB co-signed it too, on i= ts >>>>>>>> own authority. >>>>>>>> >>>>>>>> =C2=A0=C2=A0=C2=A0 Brian >>>>>>> >>>>>>> A much better (and much more recent) counter example is draft-ies= g-nomcom-eligibility-2020 which became RFC 8788. >>>>>>> >>>>>>> This was an IESG initiated document that solicited community inpu= t, >> but ultimately was published on the IESG's dime with their sole interp= retation of community consensus. >>>>>>> >>>>>>> RFC6360.=C2=A0 RFC3932.=C2=A0 And RFC 3710 (the IESG charter). >>>>>>> >>>>>>> The point is that the IESG does this too.=C2=A0 And its not a bad=20 thing, especially when we have 100 different opinions and we need a final=20 answer sooner rather than later. >>>>>>> >>>>>>> I don't expect the RSAB to do a lot of internally originated docu= ments, but I do expect there will be cases where a decision has to be mad= e, >> and that there will be some immediacy necessary. >>>>>>> >>>>>>> Later, Mike >>>>>>> >>>>>>> >>>>>>> >>>> >>>> --=20 >>>> Rfced-future mailing list >>>> Rfced-future@iab.org >>>> https://www.iab.org/mailman/listinfo/rfced-future >>> >>> >> >=20 From nobody Wed May 12 00:18: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 896543A37FA for ; Wed, 12 May 2021 00:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiUX38E0dlLF for ; Wed, 12 May 2021 00:18:04 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E393A37F8 for ; Wed, 12 May 2021 00:18:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9065; q=dns/txt; s=iport; t=1620803884; x=1622013484; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=idV6sv1ezg5SYi2c3TYP3aTkvob6goSkbxnL4ra7p5U=; b=CyFgMlsqmZb2Wg9rWVAeb5+d+L+LKWScEsNpf4g422zIE0ciNztxp0TL WfBNnksu56shfN4Z4AeGxTd7MAJ/m68xVE7mUg8eIn0t/OteUcs9diD2e RWCMIFIJUcPcSL9RLZk+nEXsFVzAOV3AkeSVRCcdBa7mq1ixDwKvhh4kZ Q=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AiAAAHgJtglxbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQFAgVeDIlYBJxIxjUuIViUDijWKJognBAcBAQEKAwEBJ?= =?us-ascii?q?QEKDAQBAYRPAoF1JjgTAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBA?= =?us-ascii?q?QEBaIVQDYZEAQEBAwEBAWwLBQsLDAIKJwchBhYJEQYTgnEBglUDDiEPp2h4g?= =?us-ascii?q?TSBAYRjgnENghcKBoE6AYFShTSBFYVHQ4INgRUnDBCCXz6CICsXAQOCFIMXg?= =?us-ascii?q?isEgWVbFXsZFgJbGFmSFoJ6iiCLL5EWW4Meg0qBSZJlhUUFIoNXixKWSqRVk?= =?us-ascii?q?EgBhAgCBAYFAhaBayGBWzMaCBsVOyoBgj4+EhkOjisNCYhihUs/Ay8CAQE0A?= =?us-ascii?q?gYKAQEDCY0QAQE?= IronPort-HdrOrdr: A9a23:RrB0gqP+rj9qVcBcTsSjsMiBIKoaSvp037Dk7TETdfU1SKClfq +V/cjzuSWftN9VYhEdcK67VZVoMEmyyXcd2+B4VotKHjOW3VdAR7sN0WKN+UyDJ8SHzJ846U +lGJIObuEZyjNB/KHH3DU= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,293,1613433600"; d="asc'?scan'208,217";a="35939643" 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; 12 May 2021 07:18:01 +0000 Received: from smtpclient.apple ([10.61.144.15]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 14C7I1Ft021878 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 May 2021 07:18:01 GMT From: Eliot Lear Message-Id: <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_FB2C0424-F2FA-46E3-8CD2-3E9C31F4C48A"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 12 May 2021 09:18:00 +0200 In-Reply-To: Cc: Brian E Carpenter , rfced-future@iab.org To: Eric Rescorla References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.15, [10.61.144.15] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 07:18:11 -0000 --Apple-Mail=_FB2C0424-F2FA-46E3-8CD2-3E9C31F4C48A Content-Type: multipart/alternative; boundary="Apple-Mail=_252BA956-5ADD-4CE6-9734-FC7440DC2C87" --Apple-Mail=_252BA956-5ADD-4CE6-9734-FC7440DC2C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Just so that your humble co-chair understands what is being proposed, I = think I am understanding several points: 1. The recourse to a bad RSAB decision is not a formal appeal but argue = to constituent bodies to replace their members. 2. The co-chairs for the RFCWG should be appointed by the IAB and the = IETF Chair (respectively). 3. Appeals of chair decisions go to the IAB, and then to ISOC per 2026 = 6.5.3. If this is the proposal, are there people who disagree with it? Eliot > On 11 May 2021, at 23:30, Eric Rescorla wrote: >=20 >=20 >=20 > On Tue, May 11, 2021 at 2:17 PM Brian E Carpenter = > = wrote: > On 12-May-21 08:32, Eric Rescorla wrote: > > Hi folks, > > > > Please feel free to tell me if we closed on this and I missed it, = but > > I don't think we've quite figured out how to handle complaints about > > process failures in either the RSAB or the RSWG. In the IETF, as we > > all know, you can appeal to the AD or the IESG, and the IAB if you > > don't like the answer for the IESG. > > > > I think I'm persuaded by the argument from Joel and (I think) MT = that > > the recourse for the RSAB is to complain to the stream management > > bodies (i.e., the IESG and IAB) and have the representatives = replaced, > > rather than have a formal appeal. However, I think we need some > > mechanism for dealing with process failures in the RSWG. This is > > somewhat complicated by the proposed chair structure where the > > two chairs are appointed by different groups. However, if we take > > Lars's proposal for the IETF Chair and the IAB, then I think the > > IAB should be the appeal body (this is consistent with other = suggestions > > for them having ultimate responsibity). This also works well b/c > > the IETF Chair is on the IAB. >=20 > I agree (and I've said this on a couple of threads already). Given > the precedent in the IETF appeals structure, and remembering where > our money comes from, I think we should also ask the ISOC Board to > be the final appeal stop, with the same scope as for the IETF case. > Cut, paste and patch from > https://www.rfc-editor.org/rfc/rfc2026.html#section-6.5.3 = >=20 > I concur. >=20 > -Ekr >=20 > Brian >=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=_252BA956-5ADD-4CE6-9734-FC7440DC2C87 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Just = so that your humble co-chair understands what is being proposed, I think = I am understanding several points:

1.  The recourse to a bad RSAB = decision is not a formal appeal but argue to = constituent bodies to replace their members.
2. =  The co-chairs for the RFCWG should be appointed by the IAB and the = IETF Chair (respectively).
3.  Appeals of = chair decisions go to the IAB, and then to ISOC per 2026 = 6.5.3.

If this = is the proposal, are there people who disagree with it?

Eliot


On 11 May 2021, at 23:30, Eric = Rescorla <ekr@rtfm.com> wrote:



On Tue, May 11, 2021 at 2:17 PM Brian E = Carpenter <brian.e.carpenter@gmail.com> wrote:
On 12-May-21 08:32, Eric Rescorla = wrote:
> Hi folks,
>
> Please feel free to tell me if we closed on this and I missed it, = but
> I don't think we've quite figured out how to handle complaints = about
> process failures in either the RSAB or the RSWG. In the IETF, as = we
> all know, you can appeal to the AD or the IESG, and the IAB if = you
> don't like the answer for the IESG.
>
> I think I'm persuaded by the argument from Joel and (I think) MT = that
> the recourse for the RSAB is to complain to the stream = management
> bodies (i.e., the IESG and IAB) and have the representatives = replaced,
> rather than have a formal appeal. However, I think we need some
> mechanism for dealing with process failures in the RSWG. This is
> somewhat complicated by the proposed chair structure where the
> two chairs are appointed by different groups. However, if we = take
> Lars's proposal for the IETF Chair and the IAB, then I think the
> IAB should be the appeal body (this is consistent with other = suggestions
> for them having ultimate responsibity). This also works well b/c
> the IETF Chair is on the IAB.

I agree (and I've said this on a couple of threads already). Given
the precedent in the IETF appeals structure, and remembering where
our money comes from, I think we should also ask the ISOC Board to
be the final appeal stop, with the same scope as for the IETF case.
Cut, paste and patch from
https://www.rfc-editor.org/rfc/rfc2026.html#section-6.5.3 =

I concur.

-Ekr

   Brian

--
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=_252BA956-5ADD-4CE6-9734-FC7440DC2C87-- --Apple-Mail=_FB2C0424-F2FA-46E3-8CD2-3E9C31F4C48A 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCbgSgACgkQh7ZrRtnS ejNUzQf+NrByaFfH3GY4pnVjsizm4x/d4c+oltuHr2HI0JF92qkMuE80xYqRHgFN 4IiBDcdR+o0T5GipasZFILJbAL9h6N/iglpz0BI0S/uJ2MocuQt8kU3wdF0DzpB0 TI9O0gC9b2B5l3S6tQCVssHSyICUXAkrK8YYkFAmD1l7Bux1hnsc5RCR+NWv1lfD UQFUGrUUd2I56yEXSgjtKbuy5rG+PFqLrZHtuOZga4nRIAhBHVgfYgemHF6Qh77q CMwc5hLK8d8dJd7XxqnhVq0pEUFRJtFsF397JhchX9VozbPAiEG7nTyhYRzsvbF2 qSfwjB9Nq1XTWOusg3TkHgjnXil4+g== =nyvs -----END PGP SIGNATURE----- --Apple-Mail=_FB2C0424-F2FA-46E3-8CD2-3E9C31F4C48A-- From nobody Wed May 12 00:40: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 ED0D53A3886 for ; Wed, 12 May 2021 00:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31DzUjCvO-oP for ; Wed, 12 May 2021 00:39:57 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C4883A3885 for ; Wed, 12 May 2021 00:39:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5751; q=dns/txt; s=iport; t=1620805197; x=1622014797; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=8on1Lqykz0ZqwhOjPqWMnkh6CqT+MfaBQCqfxJQXL7M=; b=I0j6vTwRHj08oicxSOQy98gqEDrIlZEB+zB5Wb9G1U2N1S81ZcuYvSkk z9FetCs1QRuDMdqNxm+ecq+bhPgKBCpcs/nrgSG8oxF64JHVvBeITLGd8 0FJDC/2VZNQie5idUZwrbrrRJle0BIMnYfY7mG60VaOOnKX7gruhVNgZ6 8=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AYAADAhZtglxbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGCF4N4AScShHiJBIhYJZReiCcEBwEBAQoDAQE8BAEBh?= =?us-ascii?q?E8CgXUmOBMCBAEBAQEDAgMBAQEBBQEBBQEBAQIBBgQUAQEBAQEBAQFohV2GR?= =?us-ascii?q?QYjVhALBAg2AgI9GgYngl0BgwenfHqBMoEBhGOFFRCBOgGBUoU0AYZbQ4INg?= =?us-ascii?q?RUnDBCCXz6EHIM/NoIrBIFlW24dVgJvOxGBCA+LbYUBAY0ZnSCDHoNKgUmRb?= =?us-ascii?q?IY+BSKlM4ZVrkmECAIEBgUCFoFrIYFbMxoIGxVlAYI/PRIZDo44jjY/A2cCB?= =?us-ascii?q?gEJAQEDCYpKgWdfAQE?= IronPort-HdrOrdr: A9a23:TEycRK6LpUPbyDkzYAPXwM3XdLJyesId70hD6qm+c203TiX4ra yTdZsgtCMc5Ax6ZJhko7C90de7LE80hKQb3WB5B97LNzUO+lHYSb2KhrGN/9SPIVydygck79 YFT0C7Y+eAa2STSq3BkW6FL+o= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,293,1613433600"; d="asc'?scan'208,217";a="35940561" 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; 12 May 2021 07:39:55 +0000 Received: from smtpclient.apple ([10.61.144.15]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 14C7dsKl024329 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 May 2021 07:39:55 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_47267B4C-637C-4309-A9FA-C61CDD20A551"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 12 May 2021 09:39:53 +0200 In-Reply-To: <94bb65d3-8d8e-0b25-69b0-70ba5e691d68@nthpermutation.com> Cc: Wes Hardaker , rfced-future@iab.org, "Joel M. Halpern" To: Michael StJohns References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <845c2898-60ed-42cb-0b13-b4e28f76d2bf@nthpermutation.com> <94bb65d3-8d8e-0b25-69b0-70ba5e691d68@nthpermutation.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.15, [10.61.144.15] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 50 [draft-saintandre-rfced-model - msj2] X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 May 2021 07:40:02 -0000 --Apple-Mail=_47267B4C-637C-4309-A9FA-C61CDD20A551 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E3D638D-6B49-40C0-8E1C-757E2B407B32" --Apple-Mail=_6E3D638D-6B49-40C0-8E1C-757E2B407B32 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Mike, I believe your point ties to two different issues that are now open: How do we measure success (or conversely failure)? Who has the right to make process changes (i.e, who is the =E2=80=9Cwe=E2=80= =9D in the preceding question)? It is not clear to me that the first question needs answering in what we = are documenting now. It could be that different people have different = views as to what success means, and that we need not spend time to try = and come to a single view. Moreover, it may simply be impossible to do, = if people have widely varying visions of the future. This group can = decide for itself, of course, whether that is the case. It is absolutely clear to me that before we are finished we have to = answer the second question. I don=E2=80=99t think one is saying = something controversial to say that what we deliver to the community = must be capable of evolving based on evolving community needs. We = simply need to understand the mechanics of what that means. Rather than think of this in terms of absolute failure, let=E2=80=99s = also consider process tweaks, which it seems to me are far more likely. = How might those be handled? And here are some hypotheticals to work off = of: Suppose there is a proposal to term limit RSAB members. What is the = process to handle that proposal? Can the RFCWG handle that? Suppose the RPC has raised issues with processes that are causing = production problems, but the RFCWG refuses to act? Is it a matter of = non-participation? As you pointed out, there is still a minimal group of = people who have to pay attention. Perhaps it=E2=80=99s because they = don=E2=80=99t agree that the matter deserves attention. Is that a = failure? Eliot --Apple-Mail=_6E3D638D-6B49-40C0-8E1C-757E2B407B32 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Mike,

I believe your = point ties to two different issues that are now open:

  • How do we measure success (or = conversely failure)?
  • Who has the right to make = process changes (i.e, who is the =E2=80=9Cwe=E2=80=9D in the preceding = question)?

It is not clear to me that the first question needs answering = in what we are documenting now.  It could be that different people = have different views as to what success means, and that we need not = spend time to try and come to a single view.  Moreover, it may = simply be impossible to do, if people have widely varying visions of the = future.  This group can decide for itself, of course, whether that = is the case.

It = is absolutely clear to me that before we are finished we have to answer = the second question. I don=E2=80=99t think one is saying something = controversial to say that what we deliver to the community must be capable of evolving based on evolving = community needs.  We simply need to understand the mechanics of = what that means.

Rather than think of this in terms of absolute failure, = let=E2=80=99s also consider process tweaks, which it seems to me are far = more likely.  How might those be handled?  And here are some = hypotheticals to work off of:

Suppose there is a proposal to term = limit RSAB members.  What is the process to handle that proposal? =  Can the RFCWG handle that?

Suppose the RPC has raised issues with = processes that are causing production problems, but the RFCWG refuses to = act?  Is it a matter of non-participation? As you pointed out, = there is still a minimal group of people who have to pay attention. =  Perhaps it=E2=80=99s because they don=E2=80=99t agree that the = matter deserves attention.  Is that a failure?

Eliot

= --Apple-Mail=_6E3D638D-6B49-40C0-8E1C-757E2B407B32-- --Apple-Mail=_47267B4C-637C-4309-A9FA-C61CDD20A551 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCbhkkACgkQh7ZrRtnS ejOLkwgAt0SdBPuaKzyoPcj0roGxBZsd3UOuU898see9GrGgG29HcT06Jlyd7fDu hyDFUn28ZOnAJxgKQx9xH466wwF5WGZxLa3CqYEHCX9q+3mTVDcbB+jCEKGUx81M AKUfFTjEf/tLQIcaVGHEcxiZMg9hnQV39zqqz3Oou8EMURFCl50qhrOEDRoU/WzG lJ8xbIVM/TSz2dclqyeND8IsMLiwuAIS/KHjvEX9gX3huE8CwbNDch8kdya9DONl 9ZcDjky0iMQcmt1145ivcjnF8+X14EriqltFMDwFKaUDawmFjRFsf7YTuSFTgwCm oQeou9eVlfTu4vhai4dS2OA2DZD4Ag== =jGaU -----END PGP SIGNATURE----- --Apple-Mail=_47267B4C-637C-4309-A9FA-C61CDD20A551-- From nobody Wed May 12 00:43: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 5D2C43A389A for ; Wed, 12 May 2021 00:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t-LT-T9Pbdg for ; Wed, 12 May 2021 00:43:40 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8EDF3A3896 for ; Wed, 12 May 2021 00:43:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=29378; q=dns/txt; s=iport; t=1620805420; x=1622015020; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=CEM1cv73Ymd80mS2n6eGcoMfcaMufrJeOT0Jsoh5D8M=; b=Eu7iNBYp5phS0am+QtcWD1H/00dxngNqSCGCgT9QdrmxEdDmh3ySWnbw mNtn3+R/KmmzpfBc83RYle6o++qVDFpi34U74HXjRsND3d1Pcif/Tl1nF YpTJaJG3GPvnJfifBy1nOTct346xfqhinag6FA5g2MZguqd8gFoRxKETJ w=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AgAAD4hptglxbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGCF4F2gSxWAScSMYRHiQSIfgOBDIkphQONSgQHAQEBC?= =?us-ascii?q?gMBASUBCgwEAQGETwKBdSY4EwIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBA?= =?us-ascii?q?QEBAQEBAWiFUA2GRAEBAQMBAQEbBksLBQsLDAwgAwQDAgIhBhYJEQYTFIJdA?= =?us-ascii?q?YJVAw4hD6dieoEygQGEY4JvDYIXCgaBOgGBUoQZU0gBhWF6Q4INgRUnHIFfL?= =?us-ascii?q?xsHLz6CIEIBgheCYTaCKwSBVRBbHQkOECYBAw0QFREQIAINLCAKRxElLkSQT?= =?us-ascii?q?I08iy+QXDpbgx6DSoFJkmWCRIMBBSKlM4ZVngCOMIEwBAFkhAgCBAYFAhaBa?= =?us-ascii?q?yGBWzMaCBsVOyoBgj4+EhkOjisNCRWITYVLPwMvAjYCBgEJAQEDCYwyXgEB?= IronPort-HdrOrdr: A9a23:SjSUnKlcRTpW6ljOT3a9695rCVbpDfIp3DAbv31ZSRFFG/FwWf re/8jztCWZtN9/YhAdcLy7UpVoBEm9yXcK2+Qs1MaZMzUO0VHAROpfBMnZsljd8kbFmNK1u5 0QEZSWcOeAaWSTSa3BkW+F+xFK+qjhzJyV X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,293,1613433600"; d="asc'?scan'208,217";a="35880254" 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; 12 May 2021 07:43:20 +0000 Received: from smtpclient.apple ([10.61.144.15]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 14C7hJJo026221 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 12 May 2021 07:43:20 GMT From: Eliot Lear Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_FB506F23-23F7-4336-9EA0-00F219CB23A5"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Wed, 12 May 2021 09:43:19 +0200 In-Reply-To: Cc: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= , "Joel M. Halpern" , rfced-future@iab.org, Michael StJohns To: Brian E Carpenter References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.15, [10.61.144.15] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 May 2021 07:43:45 -0000 --Apple-Mail=_FB506F23-23F7-4336-9EA0-00F219CB23A5 Content-Type: multipart/alternative; boundary="Apple-Mail=_4B8334CE-D8F0-4083-A698-61376FDF5574" --Apple-Mail=_4B8334CE-D8F0-4083-A698-61376FDF5574 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Brian and Martin, I want to add one cautionary note about appeals and use of the IAB. The = IAB as a body may be conflicted on an issue. Suppose the proposal is to = eliminate the IAB stream, and require them to use the IETF stream, and = the chairs simply refuse to call for consensus on the question. What = happens? Eliot > On 12 May 2021, at 03:08, Brian E Carpenter = wrote: >=20 > On 12-May-21 12:15, Martin J. D=C3=BCrst wrote: >> Hello Brian, everybody, >>=20 >> On 2021-05-11 11:09, Brian E Carpenter wrote: >>> On 10-May-21 21:16, Eliot Lear wrote: >>>> Hi Joel, >>>>=20 >>>> Yes, this is a good point, but I want to restate it slightly, and = I=E2=80=99ve opened Issue 63 to do so: >>>>=20 >>>> Who has the final authority to make evolve the processes that we = are defining here? Can we enumerate possible answers? >>>>=20 >>>> * Does it continue to rest with the IAB? >>>=20 >>> As I said on the thread for another issue, my current feeling is >>> that the IAB should be in the appeal chain after the RSAB. (If we >>> continue that line of thought, we'd ask the ISOC Board to be the >>> end point, as it is for IETF process issues.) >>=20 >> I think we have to be careful to distinguish the following two = things: >>=20 >> 1) The formal appeal process. For this, I'm okay with what >> Brian proposes just above. Some other arrangements may also be = okay. >>=20 >> 2) The authority to evolve the process. This may rest (formally) >> with the same organizations as the appeal process, or it may not. >> If we look at the current instance (i.e. the work of this > very >> group), I'm not exactly sure about how it worked, but I don't >> remember any kind of appeal being involved. What I remember >> is having a lot of community discussion/pressure involved, based >> on a general feeling that something went wrong. >=20 > I'd say: the same authority for both. Otherwise we could be accused > of manufacturing bureaucracy. >=20 > The past situation effectively gave final authority to the IAB and the > only recourse was a recall. I don't think anybody was happy with that. >=20 > Brian >=20 >>=20 >> Regards, Martin. >>=20 >>>> * Could it rest with the community as represented by the RFCWG = and > confirmed by the RSAB? >>>=20 >>> As long as there is an appeal chain as above. >>>=20 >>>> * Is it the IETF community as confirmed by the IESG? >>>=20 >>> No. It's wider than the IETF. That's why this will not >>> be an IETF WG. =46rom a higher level viewpoint, I think >>> the RSAB is a peer group of the IESG and the IRSG. >>> (It's almost as if we were setting up the RFC Task Force.) >>>=20 >>>> * Is it the IETF community as confirmed by the IAB? >>>=20 >>> Ditto. >>>=20 >>>> * Other? >>>=20 >>> I don't think so. >>>=20 >>> Regards >>> Brian >>>=20 >>>=20 >>>>=20 >>>> Eliot >>>>=20 >>>>> On 10 May 2021, at 05:55, Joel M. Halpern > wrote: >>>>>=20 >>>>> Buried in the below is an interesting and important point. >>>>> Suppose that we work out a process, agree to it, and try it. And >>> it fails. (For any number of possible meanings of "fail".) >>>>>=20 >>>>> Who has the authority to decide something needs to be done? Who = has the authority to make something happen. Under current rules, = whether we like them or not, the authority for what we are doing comes = from >>> the IAB, via the RFCs that say it is the IABs job. >>>>>=20 >>>>> It seems to me that Mike's point below about who has the ultimate = authority is important. And at that point, I don't think "the = community" is a viable answer. >>>>>=20 >>>>> Yours, >>>>> Joel >>>>>=20 >>>>> PS: I am sorry you do not like my usage of strawman Mike. But the = premise for your objection is sufficiently vague that I do not know what = else to call it. If the only purpose of your description was to > get to the "who has authority to fix things if they are broken", then = as above, I agree that is an important question. I was completely = unable to get to that issue from what you wrote. In particular, I could > not connect that with your conclusion that the RSAB should be = empowered to bypass the RSWG. >>>>>=20 >>>>> On 5/9/2021 10:58 PM, Michael StJohns wrote: >>>>>> On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >>>>>>> Mike, your analysis seems a bit flawed. >>>>>>> Yes, the IESG approved those documents after community = consultation, >>> on the basis that the community had agreed. >>>>>>> And yes, that judgement was made by the IESG. >>>>>>>=20 >>>>>>> On the other hand, if the community members had thought the IESG = conclusion was wrong, that was appealable to the IAB. >>>>>> The way I've always understood it is that process can be appealed = with some possibility of a reversal, but a decision that follows the = process, no matter whether some community members thought it was the = wrong decision, is unlikely to be reversed. >>>>>>>=20 >>>>>>> That is very different from declaring that the RSAB can publish = a document without community approval. >>>>>> See above. AFAICT, there were folks in opposition to the Nomcom >>> decision, but the community was heard. I'm not saying that the = community will not be heard, but I'm saying - similar to what the IESG = did > with documenting the Nomcom decision - that individual members or even = a small subsection of the community should not have a veto over the = publication of documents that the RSAB believes necessary for the = operation of the >>> streams. >>>>>>> And given the structure that is proposed, there seems much less = reason for any process that bypasses the working group. >>>>>> WGs by their nature are self-selected and generally consist of a = small percentage of the overall community with strong opinions about the = topics covered by the WG (with the active participants being even = somewhat smaller). When the scope is small enough - e.g. DNSOP for = example - the community affected by the decisions will mostly mirror the = community represented by the WG. When the scope is large enough - e.g. > Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions = of the WG represent the best results for the community of the whole. In >>> the Nomcom case, we were able to gather a reasonably large group of = people (in the form of a WG) of diverse views for a sufficient time = (multiple times) to spend a very large amount of effort to craft and = recraft the Nomcom process. But that differs from this proposed WG in = that the various Nomcom related WGs had well defined target outputs and = a need >>> to complete in a reasonably short period of time (by IETF standards = at >>>>>> least). >>>>>> I'm trying to avoid us replacing the RSOC with the RSWG - but I = can't >>> see how we can get enough diversity of interest for an indefinite = period of time to ensure that the RSWG continues to operate as a useful = source of community involvement rather than a place for a small number = of self-selected folk to have an overly large continuing impact on a = process that's >>> absolutely critical to the community's success. Nor has any one = been willing to address that specific point. >>>>>> Peter did say: >>>>>>> Yes, there are failure modes where the WG is inactive (in which = case >>>>>>> we'd need to inject more energy) or unable to reach consensus = (in which >>>>>>> case we'd need to work harder to do so), >>>>>> But I would ask who the "we'd" is in the above? e.g. once this = group dissolves in favor of the new structure, who has the = responsibility >>> of fixing things if the WG structure fails or devolves? Are we = going to be back here in 4 years? Or does the RSAB go on its merry way = and do what it needs to do? If not, who reconstitutes the next = RFCED-Futures group given that we will have taken the IAB out of the = picture? The RSAB? >>>>>>>=20 >>>>>>> I think everyone knows that I do not like the current approach. = But I can live with it. And it seems to be the approach the community > wants. >>>>>> Or at least the 1/2 dozen or so people who have argued for the = approach - not sure that's the community. >>>>>>> Creating strawmen as obstacles does not seem helpful. >>>>>> And thanks for that denigrating comment. You might not like = what I'm saying nor agree with them, but calling them strawmen implies >>> that they are there simply to providing a blocking issue and they = have > no >>> basis in reality and that I'm doing that simply to screw up what = process there is. >>>>>> Mike >>>>>>>=20 >>>>>>> Yours, >>>>>>> Joel >>>>>>>=20 >>>>>>> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>>>>>>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>>>>>>> IMHO, the IAB can and does do this but the IESG doesn't. Take = RFC1984 >>>>>>>>> as a canonical example: the IESG approved it as a BCP by = standard >>>>>>>>> process including IETF Last Call. The IAB co-signed it too, on = its >>>>>>>>> own authority. >>>>>>>>>=20 >>>>>>>>> Brian >>>>>>>>=20 >>>>>>>> A much better (and much more recent) counter example is = draft-iesg-nomcom-eligibility-2020 which became RFC 8788. >>>>>>>>=20 >>>>>>>> This was an IESG initiated document that solicited community = input, >>> but ultimately was published on the IESG's dime with their sole = interpretation of community consensus. >>>>>>>>=20 >>>>>>>> RFC6360. RFC3932. And RFC 3710 (the IESG charter). >>>>>>>>=20 >>>>>>>> The point is that the IESG does this too. And its not a bad > thing, especially when we have 100 different opinions and we need a = final > answer sooner rather than later. >>>>>>>>=20 >>>>>>>> I don't expect the RSAB to do a lot of internally originated = documents, but I do expect there will be cases where a decision has to = be made, >>> and that there will be some immediacy necessary. >>>>>>>>=20 >>>>>>>> Later, Mike >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>=20 >>>>> -- >>>>> Rfced-future mailing list >>>>> Rfced-future@iab.org >>>>> https://www.iab.org/mailman/listinfo/rfced-future >>>>=20 >>>>=20 >>>=20 >>=20 >=20 > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future --Apple-Mail=_4B8334CE-D8F0-4083-A698-61376FDF5574 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Brian and Martin,

I = want to add one cautionary note about appeals and use of the IAB. =  The IAB as a body may be conflicted on an = issue.  Suppose the proposal is to eliminate the IAB stream, and = require them to use the IETF stream, and the chairs simply refuse to = call for consensus on the question.  What happens?

Eliot

On 12 May 2021, at 03:08, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On = 12-May-21 12:15, Martin J. D=C3=BCrst wrote:
Hello Brian, everybody,

On 2021-05-11 11:09, Brian E Carpenter wrote:
On 10-May-21 21:16, = Eliot Lear wrote:
Hi = Joel,

Yes, this is a good point, but I want = to restate it slightly, and I=E2=80=99ve opened Issue 63 to do so:

Who has the final authority to make evolve the = processes that we are defining here?  Can we enumerate possible = answers?

  * Does it continue to = rest with the IAB?

As I said = on the thread for another issue, my current feeling is
that = the IAB should be in the appeal chain after the RSAB. (If we
continue that line of thought, we'd ask the ISOC Board to be = the
end point, as it is for IETF process issues.)

I think we have to be careful to = distinguish the following two things:

1) = The formal appeal process. For this, I'm okay with what
=    Brian proposes just above. Some other arrangements may also = be okay.

2) The authority to evolve the = process. This may rest (formally)
   with the = same organizations as the appeal process, or it may not.
=    If we look at the current instance (i.e. the work of this =
very
   group), I'm not exactly sure about how it = worked, but I don't
   remember any kind of = appeal being involved. What I remember
   is = having a lot of community discussion/pressure involved, based
   on a general feeling that something went = wrong.

I'd say: the same = authority for both. Otherwise we could be accused
of = manufacturing bureaucracy.

The past = situation effectively gave final authority to the IAB and the
only recourse was a recall. I don't think anybody was happy = with that.

   Brian


Regards,   Martin.

  * Could it rest with the community as = represented by the RFCWG and
confirmed by the = RSAB?

As long as there is an appeal = chain as above.

  * Is it the IETF community as confirmed by the = IESG?

No. It's wider than the = IETF. That's why this will not
be an IETF WG. =46rom a = higher level viewpoint, I think
the RSAB is a peer group = of the IESG and the IRSG.
(It's almost as if we were = setting up the RFC Task Force.)

  * Is it the IETF community as = confirmed by the IAB?

Ditto.

=   * Other?

I don't = think so.

Regards
=    Brian



Eliot

On 10 May = 2021, at 05:55, Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wrote:
Buried in the below is an interesting and important = point.
Suppose that we work out a process, agree to it, = and try it.  And
it fails. =   (For any number of possible meanings of "fail".)

Who has the authority to decide something = needs to be done?  Who has the authority to make something happen. =  Under current rules, whether we like them or not, the authority = for what we are doing comes from
the IAB, via the RFCs that say it = is the IABs job.

It seems = to me that Mike's point below about who has the ultimate authority is = important.  And at that point, I don't think "the community" is a = viable answer.

Yours,
Joel

PS: I am sorry you do not like my usage of = strawman Mike.  But the premise for your objection is sufficiently = vague that I do not know what else to call it.  If the only purpose = of your description was to
get to = the "who has authority to fix things if they are broken", then as above, = I agree that is an important question.  I was completely unable to = get to that issue from what you wrote.  In particular, I could
not connect that with your conclusion that the RSAB should be = empowered to bypass the RSWG.

On = 5/9/2021 10:58 PM, Michael StJohns wrote:
On 5/9/2021 10:32 PM, Joel M. Halpern wrote:
Mike, your analysis = seems a bit flawed.
Yes, the IESG approved those documents = after community consultation,
on the = basis that the community had agreed.
And yes, = that judgement was made by the IESG.

On the = other hand, if the community members had thought the IESG conclusion was = wrong, that was appealable to the IAB.
The = way I've always understood it is that process can be appealed with some = possibility of a reversal, but a decision that follows the process, no = matter whether some community members thought it was the wrong decision, = is unlikely to be reversed.

That is very different from declaring that the = RSAB can publish a document without community approval.
See above.  AFAICT, there were folks in = opposition to the Nomcom
decision, but the = community was heard.  I'm not saying that the community will not be = heard, but I'm saying - similar to what the IESG did
with documenting the Nomcom = decision - that individual members or even a small subsection of the = community should not have a veto over the publication of documents that = the RSAB believes necessary for the operation of the
streams.
And given the structure = that is proposed, there seems much less reason for any process that = bypasses the working group.
WGs by their = nature are self-selected and generally consist of a small percentage of = the overall community with strong opinions about the topics covered by = the WG (with the active participants being even somewhat = smaller).   When the scope is small enough - e.g. DNSOP for = example - the community affected by the decisions will mostly mirror the = community represented by the WG.  When the scope is large enough - = e.g.
Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions = of the WG represent the best results for the community of the = whole.  In
the Nomcom case, we were = able to gather a reasonably large group of people (in the form of a = WG)  of diverse views for a sufficient time (multiple times) to = spend a very large amount of effort to craft and recraft the Nomcom = process.  But that differs from this proposed WG in that the = various Nomcom related WGs had well defined target outputs and a need
to complete in a reasonably short period of time (by IETF = standards at
least).
I'm trying to avoid us replacing the = RSOC with the RSWG - but I can't
see how we can get = enough diversity of interest for an indefinite period of time to ensure = that the RSWG continues to operate as a useful source of community = involvement rather than a place for a small number of self-selected folk = to have an overly large continuing impact on a process that's
absolutely critical to the community's success.  Nor has = any one been willing to address that specific point.
Peter did say:
Yes, there are failure = modes where the WG is inactive (in which case
we'd need to = inject more energy) or unable to reach consensus (in which
case we'd need to work harder to do so),
But I would ask who the "we'd" is in the = above?  e.g. once this group dissolves in favor of the new = structure, who has the responsibility
of fixing things if = the WG structure fails or devolves?  Are we going to be back here = in 4 years?  Or does the RSAB go on its merry way and do what it = needs to do?  If not, who reconstitutes the next RFCED-Futures = group given that we will have taken the IAB out of the picture?  = The RSAB?

I think everyone knows that I do = not like the current approach. But I can live with it.  And it = seems to be the approach the community
wants.
Or at least the 1/2 dozen or so people who have argued for = the approach - not sure that's the community.
Creating strawmen as obstacles does not seem = helpful.
And thanks for that denigrating = comment.   You might not like what I'm saying nor agree with = them, but calling them strawmen implies
that they are there = simply to providing a blocking issue and they have
no
basis in = reality and that I'm doing that simply to screw up what process there = is.
Mike

Yours,
Joel

On 5/9/2021 9:41 PM, = Michael StJohns wrote:
On 5/9/2021 8:39 PM, Brian E Carpenter wrote:
IMHO, the IAB can and = does do this but the IESG doesn't. Take RFC1984
as a = canonical example: the IESG approved it as a BCP by standard
process including IETF Last Call. The IAB co-signed it too, = on its
own authority.

=     Brian

A = much better (and much more recent) counter example is = draft-iesg-nomcom-eligibility-2020 which became RFC 8788.

This was an IESG initiated document that = solicited community input,
but ultimately was published on the IESG's dime with their sole = interpretation of community consensus.

RFC6360.  RFC3932.  = And RFC 3710 (the IESG charter).

The point = is that the IESG does this too.  And its not a bad
thing, especially when we have 100 different = opinions and we need a final
answer sooner rather than = later.

I don't expect the RSAB to do a lot of internally originated = documents, but I do expect there will be cases where a decision has to = be made,
and that there will be some immediacy necessary.

Later, = Mike




--
Rfced-future mailing list
Rfced-future@iab.org = <mailto: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=_4B8334CE-D8F0-4083-A698-61376FDF5574-- --Apple-Mail=_FB506F23-23F7-4336-9EA0-00F219CB23A5 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCbhxcACgkQh7ZrRtnS ejPFXAf+M8F9CK3ZfAdO06ddYv5nSaVJ8SFLS0Z0DoKwQWPvst/WPkrF+a5iFlhf agoegHQxVcnvMmP5xd423khNDVALgFvB4Nr4toNimHITLZmClhMRgYdx1N6ny0tX hxzQndB6r3jo9UzrZUGuBb0xaiffyA7XeuoSDoHqlkbpzQwqMrbmNHtjymOPN67c b5zxAbRCAo6vjmQUUWatZyO3FyCQTUeqnZGB/Cw24eUCgMv3dHEjqy0rdDYvSWVg sMjRqmw3XNUEZUnLJlucsaO3MQ9o3Oplmu1YjYIxv75ghgb7GZ+aYMmJ5scOAIiA JhoybYDTsugC1NQKmeRYZCxrxGyJaA== =u8rA -----END PGP SIGNATURE----- --Apple-Mail=_FB506F23-23F7-4336-9EA0-00F219CB23A5-- From nobody Wed May 12 01:10: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 46E103A3968 for ; Wed, 12 May 2021 01:10:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ReGTHckyhgVH for ; Wed, 12 May 2021 01:10:41 -0700 (PDT) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-eopbgr1300111.outbound.protection.outlook.com [40.107.130.111]) (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 01E113A3970 for ; Wed, 12 May 2021 01:10:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rejdbcmf+wST1rheaXgclAp/36dJq+0wgU8KgpjN9DgdU4B4g+RWqzq/+zoMcvrKiiCPWFHIVfPy+2BCtv0K/zHYxr4mzsb7M3kF2ktYRdfh01GKQJ9iuBjJhjxLfS/CyhKtwX3JU+DA4mBm1bNqiHguTQTW8POfZzpb+9hFmpqRhYfa+dwgDYJoa8z/V+48YE6Nu3x5BaIF4+HnokQ4B2Bn0JVAogMM77ZEouQepbrxGmFCUWxaRoedQwaLqDYmIjXbnxRbFFrtw5h6QNMzpnPI9pc0rLHdfKHGdsB7fe7A3VmpR8LBkJ+BvKwBw/HODGOt6iUbrdGi3zJBwOtybg== 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=omPGbfIGKI7JlhtRKma8bvOcIpFwinAyF4P/78+gFL8=; b=RIGTzhQ4hdDL5Er+M5K/98SgRMHqTuiPw4NsO+vK8aQI9no9H1vTjsaduhFQC24st3vuyk13ZJpYa9kssmQsyfSS5mqDUot2mP6RIsYtBpVgTrcWZu//8pQIIZgD/t6e6Cj86NnXGxpuyTWg58nL8dwzcFT0myUBmSMrZdvSDwbimPKjo7xBvUDmRyH94RCrg7lCXRt5hIu9tx0tqVksmB60nnJMlh3UPbnjEGhpANfUzFM2ahcVsNs6YTdG3y+m5nbxp2hcoiGd5k9qTokZ1cPhMWPEURK3Fx8+rO6FI3YfNPEf6a4pWiw49S3bKNKMmTAA3M6Z0VE1/ZxTk7MrMQ== 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=omPGbfIGKI7JlhtRKma8bvOcIpFwinAyF4P/78+gFL8=; b=s/UViJEqDIc+F0qrj6BWFqX4IB6acLSgah+QGQvNURnYVXxlG9FCvcvFZLYF4E43n5yTkpn9yVhTp+AhTOHkE/eqsZzV1K8362rKIZUID9LY98EWuU/knD6ErCRR0rEN6qJ5uhR/Sre9ziA0l6LIXBDFCP3WdBF+ip21zDhqjBk= 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 TY2PR01MB2922.jpnprd01.prod.outlook.com (2603:1096:404:72::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25; Wed, 12 May 2021 08:10:31 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511%5]) with mapi id 15.20.4108.031; Wed, 12 May 2021 08:10:31 +0000 To: Eliot Lear , Eric Rescorla Cc: rfced-future@iab.org References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Wed, 12 May 2021 17:10:30 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 In-Reply-To: <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.39] X-ClientProxiedBy: TYCPR01CA0086.jpnprd01.prod.outlook.com (2603:1096:405:3::26) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [133.2.210.39] (133.2.210.39) by TYCPR01CA0086.jpnprd01.prod.outlook.com (2603:1096:405:3::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Wed, 12 May 2021 08:10:30 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 09976c26-2ea0-4952-6491-08d9151d6905 X-MS-TrafficTypeDiagnostic: TY2PR01MB2922: 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: BQ/+gRspIOMwQ6eeA4lFZs69t/TuGfzNOARMacjHmclQbWgjkbUHh/73regDrLx7HNObT4ScdJqVcfP2jAH3yZl+/rdZ9t8749aE78eKfU4zqorMn7Q1hv/SYHyQGIiLufJrMfZhqPrrNFqlVbqXqENvCrzuGAWKwN0ChGahOuRSVleBXciUws/z08beH3cza/XHQgTzw7sQ8S6eZ0ioHsGNeGTyjDnW/H8ujfqJWVRo0aISI+Zoj1dtCZD/y/SuqY5mtwSxV9WiSNztRcz+rEBUng3NgnCYhrB+r4KwqYNBcu7K3l5u5v8Z8hhsH4wPmvy6SwcicvAFcaDWTT6hOAmXewUmBXHWLPM6PZZSg01x77adX+Aa27Pj/JP1op4vZWA/HxBbTSjsL4efJT67qgyWTT5+KRvv/2DGMmsAjB3qamKGnkv+4aN9mYgTiNFubf9mm+nWLui7m+9P0mK164SPJp64H3U/Dco1eaepUk4eT78q186EE3sdc+D8IPsbLkwMQdSG5YivNCnTP9jO486YnL0sF4CIMTujSjtacStbfpzJka1M9QJKr5JSwmqVxNIz/TH22uXhSo+hFGjzqgmObF12ql3oTyA7pu+4CHd2rMzOefink5/k9oQvWlza/fuVlpdCUeD8tz+9OrVCG3w31KnL0+y2wmNQ5hapRgZM1O6WPg+pJr4GYceoEC7LkdSkpbLFAyM7XYrEHwR8l3r0l2DFZn7z8tRL8MXU+9bzA5U9T7wJ/fh6VynU78e9eiAohYN1C0n8Xy0be5abwlEsqcf7gqBB9Dr0WDOds0K2MepsmYu6nhSb2sWbmsHnndwMa3P4OWWiVTp/O+u0HA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(136003)(396003)(346002)(39830400003)(6486002)(4326008)(38350700002)(786003)(478600001)(16576012)(110136005)(66574015)(316002)(38100700002)(86362001)(53546011)(186003)(36916002)(5660300002)(52116002)(26005)(83380400001)(31696002)(8676002)(956004)(2616005)(31686004)(66946007)(66556008)(6706004)(2906002)(966005)(16526019)(66476007)(8936002)(3940600001)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?RXlhT242U0EzZnhzTXdvZU9leVFmTVFIOTJHRXdKb2VrZ3VxZXkzcFpCOExv?= =?utf-8?B?RWRRZGk1RWx2RlFGYUgxMHZYQ3VGbEhZeFJHMFhsc09sendrRExhb1N1eEZ4?= =?utf-8?B?NzVHRTg2YmlYUS9kV1RpRWRWQ0YzUkNha3pydmdTVzA2SWNSK3hlQzhhdVFE?= =?utf-8?B?STJkODFxVk04L0kwelcwTUtGVjJYMVV2Ny9tUjI3N01GMG40SEc3OStpemJ3?= =?utf-8?B?b0wvNHJqOWFXNTRBV1p4Qk41UkZMMnVzdUM2enNyWS9Cc2toczFheTBreEVD?= =?utf-8?B?bmdXYzVQbXpsNFlUU1BMS09RRk4yYmVHejlMbDdsMklrZFpiK2p2WU8wVENa?= =?utf-8?B?ZkRtNm1ydVR0aU9LMFhRaUNqR2JLR1pzR2ZtRENOS04vMGdpQmJJQWRSZ3hh?= =?utf-8?B?bGJ2ZkU2M05seEdUNkNHcUp5aFBPdU91WnR2SjZpSEkxWWVBUGVlQ1dRaWY5?= =?utf-8?B?cEk4eUhlcUFPY2JnRUkrV2VLclFtOUlaWTN0dFB0SExpaDFDQ0xtcm8vYksz?= =?utf-8?B?MWQ3VVdMZGJIeTB1bXJ6N0pHOFgwazliZ1A2R29HaUtIK0QrYjZMNzFLT1VV?= =?utf-8?B?RWh6aStpRGlhMGNock0xMlZzMUdPRUJ0UFdtMUZveWVjeHBaQjNPWDVPQmZz?= =?utf-8?B?Y214Q1VNU0Nya3hjdXYrOXFUc1M0Y3EwNVlDSVBDRGx5Mjl1MUtpQmF2ZkJp?= =?utf-8?B?ZmN4TGZnSmVqVzhxT1JseHRla2JWZW5MVUtkc1g2b3I2NkczTFdsU1JsNko0?= =?utf-8?B?d3BIUkhqV01zY0ltRG56VC9LZGFza25aVEMzcStuUHBuZDFuaHRjQkU2Q2h6?= =?utf-8?B?aS8yN2FFY1owNDJyZ2c5aVZCdXNUOWNKTksrelg5dnNHTTZHZjlxVEdOZmlr?= =?utf-8?B?b1NDY0Nvc1Z4d0pGWFBTbUsxVlBSVUg0YmtST3BGbDdHQ2h4SHpRNzZjd25I?= =?utf-8?B?b1Z1WFlzVjAwcEc1OVpaNjErTm9PcUg1M0hOdXNBNzJ6aUd1V3VwR29YZnRn?= =?utf-8?B?WmVrdlh6b2xkcnEwMFZneXBKR3lDUFlBR1o0Mk9wbEtDOG44T3o0RCs1Q0hS?= =?utf-8?B?L29UY2JwOXowZFo4YVd3WWhqNTIwTnZTbzFENkJaYVhHV2FrS3pKV1I2Z0ZK?= =?utf-8?B?WE9hdFdCQUdmclpmL2piQmtXZmdERUp3cllYVGlndHRGazBhTDBLdkVJTC94?= =?utf-8?B?TzA2KzB4c052NDdHSWwvVTA5bVQzTUJYbWd2cTljWkQxMXRYWldVd1JxOHR1?= =?utf-8?B?aVdTdjBSVEpwLzkzeE84YVJnS0dRWlZ4WGtjbGViWXdudTNTeFhIYlk3ZWRU?= =?utf-8?B?bkFGaHZNYjBVT2pQNXoxVjZ2Wi9pQ2xnSzJQMkZ5WnNpUGxlbm5ROVIzQ3E5?= =?utf-8?B?YmE1ZmtUSXlRVWZxc3lWblM0a3NCWktGUS9sVTcvRWZTbzc2WEYxamdOOE5a?= =?utf-8?B?UXBHaGphbHFoOUFhbURNZnY2Zk1SNGU5VUplSHU2bUhnOFc1UlRCVXJNUXpo?= =?utf-8?B?bUVhSVlJRzVnbEl6QjJnbitUdWY1bFJxOUZFQk9qSk9tdU9xck1weDJoTWZ1?= =?utf-8?B?UGJkOFdYYUIyK0FoeTduUVd0OTd6Z3RuVGZDZHBaS1R6dE5WWk5JMU1pR3Jn?= =?utf-8?B?RmFQTXg2ZTdpMjhvQ0dNN1Zsc1pCb3J5bW9TQ3hLSEZDSW8rWDJqME0vRHpj?= =?utf-8?B?N05CSE1FOERZU3M0UjIrSVhjd1VlZzhMMUl6L0I4SmYrejNrK3NTaUN2N1A0?= =?utf-8?Q?NnCJ1/be+zy97WrvSdfgnfnXBHrwqCxW+T3mRxp?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 09976c26-2ea0-4952-6491-08d9151d6905 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2021 08:10:31.1285 (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: tuhlM7aK+RHytwTdS8jrLwhs4/kdXRoPjiYoGDPkQsluWnQUKSce+DgbbmpOqYqeSyiP8IL+R5+18ABvPEHUrg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB2922 Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 08:10:47 -0000 Hello Eliot, On 2021-05-12 16:18, Eliot Lear wrote: > Just so that your humble co-chair understands what is being proposed, I think I am understanding several points: > > 1. The recourse to a bad RSAB decision is not a formal appeal but argue to constituent bodies to replace their members. That was not my understanding, and I hope it wasn't Brian's. The recourse to an "average" bad RSAB decision should be an appeal, similar to e.g. a bad decision by an IETF WG chair or an AD,... As a recourse to an extraordinarily bad RSAB decision, and some potential other happenings (i.e. not RSAB only), i.e. something that exposes deep structural problems, such as the happenings that led to the current redesign process, the IAB should take the lead and see what needs doing. (of course we hope that our current work will reduce the chances of such a need) To replace the members of the RSAB may not be easy, as many of them participate ex officio. Regards,   Martin. > 2. The co-chairs for the RFCWG should be appointed by the IAB and the IETF Chair (respectively). > 3. Appeals of chair decisions go to the IAB, and then to ISOC per 2026 6.5.3. > > If this is the proposal, are there people who disagree with it? > > Eliot > > >> On 11 May 2021, at 23:30, Eric Rescorla wrote: >> >> >> >> On Tue, May 11, 2021 at 2:17 PM Brian E Carpenter > wrote: >> On 12-May-21 08:32, Eric Rescorla wrote: >>> Hi folks, >>> >>> Please feel free to tell me if we closed on this and I missed it, but >>> I don't think we've quite figured out how to handle complaints about >>> process failures in either the RSAB or the RSWG. In the IETF, as we >>> all know, you can appeal to the AD or the IESG, and the IAB if you >>> don't like the answer for the IESG. >>> >>> I think I'm persuaded by the argument from Joel and (I think) MT that >>> the recourse for the RSAB is to complain to the stream management >>> bodies (i.e., the IESG and IAB) and have the representatives replaced, >>> rather than have a formal appeal. However, I think we need some >>> mechanism for dealing with process failures in the RSWG. This is >>> somewhat complicated by the proposed chair structure where the >>> two chairs are appointed by different groups. However, if we take >>> Lars's proposal for the IETF Chair and the IAB, then I think the >>> IAB should be the appeal body (this is consistent with other suggestions >>> for them having ultimate responsibity). This also works well b/c >>> the IETF Chair is on the IAB. >> >> I agree (and I've said this on a couple of threads already). Given >> the precedent in the IETF appeals structure, and remembering where >> our money comes from, I think we should also ask the ISOC Board to >> be the final appeal stop, with the same scope as for the IETF case. >> Cut, paste and patch from >> https://www.rfc-editor.org/rfc/rfc2026.html#section-6.5.3 >> >> I concur. >> >> -Ekr >> >> Brian >> >> -- >> 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 > > > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Wed May 12 03:04: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 89B3A3A3C16 for ; Wed, 12 May 2021 03:03:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ZaoghKuq78EB for ; Wed, 12 May 2021 03:03:52 -0700 (PDT) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-eopbgr1310105.outbound.protection.outlook.com [40.107.131.105]) (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 03FD13A3C15 for ; Wed, 12 May 2021 03:03:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SF4VttFkvdWcDgOCAKLFvOvG7FHkfli88UXGSLnAl5PCYUj0ZaFL705HmIrc5fvmk0wR4maCIzCCKfKFNlzFQz9sN0xvqqcIwY2Wu/T1alrz14JOTQG1oooOV/Me0/WRj9CJS1fWTkJAH5b2mrfMW+tRcpW9ubehZbzQqQ62XbjGYaiA//BQ9O/qWb6mv9+CFZQF+dBCSPBkfEGGKep8zB3UqXW38hkM/3TctDKJjutbHwy8IyWjVPRTHro3FY6JiEbt3NswxBlBdEDua75B8QVpG7Y1b/NjAkNTfYsKtO7LeL71NIqfMrRyyORmyAvWi16iH0kSQhcpcqaOPpnXCQ== 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=pf3kd91CUsvgmQympRVa7VF5bGN6/uMpJhVeKva45CA=; b=FPgSH6dzVDqBoutqw66eZ4rob1inL2CCFXHek6iHlktyezUX6ahVY+dmlga1bgERksdHCW3BU15U+jvGZlRIMdykrwb+9E7lmdkPVj4Me4RFiyXbY7fQEQ/iC8toFZRq7lNQAy1u2wgmZpUMaPZr4gcGFC6UdHCqbVuq3ESHMxf6QSCXjLPMoxhpETUV1TSU9firV2gyz0vMmAnB0Re9/6PnT7aSQ9iEF3FQsctJqJHcO8OYDBR7pWZmub9TiuWtjk4RHudOXWn9L4vsitsERyS3v6s6EDQKR1u76vts1emQHHIcMGJr5LUs6SRNYUeY/fx5oeaQqqWyHymHca5j/w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=it.aoyama.ac.jp; dmarc=pass action=none header.from=it.aoyama.ac.jp; dkim=pass header.d=it.aoyama.ac.jp; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector2-itaoyama-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pf3kd91CUsvgmQympRVa7VF5bGN6/uMpJhVeKva45CA=; b=jIbWbjKOvrNqSeorF2L5NXREVd7pqBWyayXetLFHXfnsAueCK+eV0CftTaKOEY5EQ0DzEg0zYY6oEU24bP0SSTpKk+Pr9Y4c5p5/NMACcSPwZS6EKG7lpIfyqsDxY1UDgSxD7w/00H6LdVEmgAKwgbQb6et+kgK3k7Tj19yUG4g= Authentication-Results: nthpermutation.com; dkim=none (message not signed) header.d=none;nthpermutation.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) by TY2PR01MB3850.jpnprd01.prod.outlook.com (2603:1096:404:d0::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25; Wed, 12 May 2021 10:03:46 +0000 Received: from TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511]) by TYAPR01MB5689.jpnprd01.prod.outlook.com ([fe80::7c68:2926:ee00:a511%5]) with mapi id 15.20.4108.031; Wed, 12 May 2021 10:03:46 +0000 To: Eliot Lear , Brian E Carpenter Cc: "Joel M. Halpern" , rfced-future@iab.org, Michael StJohns References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> From: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <4ee6dfc6-c50b-71f3-20f7-81b2ded39103@it.aoyama.ac.jp> Date: Wed, 12 May 2021 19:03:44 +0900 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.39] X-ClientProxiedBy: TY2PR06CA0003.apcprd06.prod.outlook.com (2603:1096:404:42::15) To TYAPR01MB5689.jpnprd01.prod.outlook.com (2603:1096:404:8053::7) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [133.2.210.39] (133.2.210.39) by TY2PR06CA0003.apcprd06.prod.outlook.com (2603:1096:404:42::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4108.25 via Frontend Transport; Wed, 12 May 2021 10:03:44 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 791e6218-31ee-4c1e-074a-08d9152d3aa0 X-MS-TrafficTypeDiagnostic: TY2PR01MB3850: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: XWxjEFyymZT0W1AIBoxsTvHmtA1BfM+dPexGp/tpwwDc6xwydBa622ZVbD7jRJ5J0OTdxVEk+vMYfWCopMi1iFQHAQPZSr7MQQp9HZKy7p+a+/mDioQQgiN90SRr24vAIAy+/p/ijwfmPmNQtxmqt/5iCn54veLwkDhg5RMdCcib5icOgrCZTqYrYjqsyPv5ydiZ0REVnyjJkJZWuQ8dm8jOTWE1qk11xo415sE5wSzB82aiCSicvOvYhcxZeYhkU27H0rPUKro9glTHBIHRoRxWuSYUj61lArciODwy+rMRsEAYKmPL8iT9YihUvChvXR2+YM/yO3h88JB0CNKsFULNbAxgFXWnCKCiUnw+z6kvnAIxCNPOwUolVIaeo2tmzZiKO0+C9CjsJOZrTD7328sfHA1EGNZt5GcuL3g9ynkYZZLrvbV3viyQ9uVicMNM+AhQ53ehMyBKQS29G/3POgyj4QtcQ9iBkRRmqUiorHyErR+ZQFJIcu1sjy0qhB83NRoZx0IyE/iYszzExu1XcIYDy3UxJWdEsRrevZisktTqS0m5FmBNsFQK1H2Pq0Q73bbDDgjCxc0pi/dm1985QyOEpWCr2Dq1NJta44xYqdKZxt2oRAitbNAeFIT459odVSaMiPs6TUxSpYR8xgs4ZyvSBQQVrwB9dzH132GPqpA/nNqpKQUvdTmwD9clBuLc7pVEe2846yIrKw7abEWbyaelNgcQWbBPCUWvB4KF5L/GZxdGB/izouuXwlX1sEpHHVW6+Yv1QnCQfT+dzepGVakIgwmn830je6izM/B3RnWMcgbG24A9Fe8my0GSCdc1RUcsZy1IDxZzQN/rmSxIwQ== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:TYAPR01MB5689.jpnprd01.prod.outlook.com; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(39830400003)(376002)(366004)(2906002)(786003)(110136005)(316002)(31696002)(38350700002)(6706004)(16576012)(54906003)(8676002)(66946007)(8936002)(26005)(38100700002)(66556008)(31686004)(66476007)(2616005)(66574015)(956004)(16526019)(30864003)(966005)(83380400001)(6486002)(186003)(86362001)(52116002)(53546011)(5660300002)(478600001)(36916002)(4326008)(3940600001)(43740500002)(45980500001); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?VEpmcktEWEZFTUlISEJGamo0NXZuWTNvSk1QbFpRbHhwZWY3TktNN01BS1N4?= =?utf-8?B?bnl4THZFTkQrMmNySUN1UURuWHpyUGVzc2ZMR1MrVzVwc2kvMnkwZWdMUStI?= =?utf-8?B?elZMNGlwUTZZL0NQcXF1SjRIOXpVNnlYYjN3dDVIeTA1a09nTnk0dlhDTFZv?= =?utf-8?B?YlFFZFB5amwwdmpsbW5uem0rdFNoZTNwMHVsdUp6QU5uSnlkNXRQcWJUN0Mz?= =?utf-8?B?T1N1aEVwMU5NYXVCeXZrK1FDWVg3ZGhiWXgxM28zMGUzVENyOFJUVDlJWEhw?= =?utf-8?B?bld1bjF4R1FoOEhPSFZ5Ky9zdFVRWVlNMlpwWi9aRS9rR2hiMlF1OVJsYXZM?= =?utf-8?B?RHlZUDUyS0RIMllXaEtCQTE1WXZPVDQ2RExjRm42LzJ3SjY4aUZVS3FkdUNT?= =?utf-8?B?N0R2cFhPek8zYTZXS0RFZ2tFdkJiQlRuWDVZQ2VUQWhzUEZHSFNuaWJERy9N?= =?utf-8?B?bWZlM3VCcExjVGZHSGJmODF6UUlGaS9UUzZrV0lCTzJiUnZacE5MdjNXemNa?= =?utf-8?B?cnRQWVBkc2ZLR1ZSVGpUbFc4SUNHU1BpTXdhdndERDRSVmZJUm9RQzVkQWNQ?= =?utf-8?B?aGJGaVlaVnEvaHRRR0xRSDNoNlJZYVBYUmIyTlVRNWhzZHFhYmxnQi9vc2ZD?= =?utf-8?B?alFzR2NVZXZUb2hiTlFycWgyTHRzWkIwRExEMXA4V0JuODhhOVJrWFdacVpX?= =?utf-8?B?SWdxRlBFOWFIT3lPWHVQT1RxdlJvWklTMVJyTjd0emNSdlg5SThRZWZ4V2sw?= =?utf-8?B?Ym5uV1VaTXpjVHRReWJiT3Z6QVdHYnUxTS9ITWFuVUxSVkFBd0xmYUFjNEF2?= =?utf-8?B?RVFQcTU4OVlxdXFpN29lQW81VXBuWEZBVStTZmN0czJib1Foa05naTNZQzhF?= =?utf-8?B?cXA5L0VIMXBscm5Ub3BKaHVLTFh3NEVVQXZROFdWbTBnUnM2UG16eGs1OXd6?= =?utf-8?B?NHd5VThGS21ZbVBSbUZEWTUyUDV5anZoYlpNWXQyU3g0a3VFNnpHWTBSSDhH?= =?utf-8?B?NlFYcG9CUXk4VjkwWGpHcDJKK0RuTjY0SGl1cUpJUjFobjg3RFNwSkl2UE5G?= =?utf-8?B?QzNKZ2FwSTNUSThiVW1TdE9RZmhtQ0VYc09xSURVVkJMOG5OQ25CRDB4YWV4?= =?utf-8?B?V2xQMThtQ2lIVHh4Vis1Q1ptdSs1VEFjeHJPK05LUy9laVZDYTVoVVMxU2Ji?= =?utf-8?B?dWFPVTdMbkNoc1l2azJHUDhqRGtjWHBNbDRpVzRmYSt1MHdweUVtbE1tOE1W?= =?utf-8?B?RFhBOVpZMnZZTzkwL3IvUmJCZFg4cmd2aG1iK3lFZXpQUElraGVLNzRlLzJR?= =?utf-8?B?ajlkdmZFVnd1TWJReklZVDczVTltZkJFVDYyQzFtZ052TmVKc3crbVdERHIw?= =?utf-8?B?UVo2d2t0UzI3Y3JSWEpNT05Bc2hWUHo3WjQ4OWNJSUd6NUtpWDF3Q2IwWnRh?= =?utf-8?B?NTNhNU9PazVLbGY1aUJLWm1LTTBqZ1l0VVI0WldhUE1iQjdQYUFEdzBYb0xt?= =?utf-8?B?ZFliaUFLRFk2Q0p3TU5wY0Y3eXRMY3B0eWhnSE1FdHp4ZGMvNk91eFF6bzdR?= =?utf-8?B?amZYRmNhQnI4QmpUMmhJUkxTUGFNTjNwZW9jVkVyZjAxempuY1VXR1RqSnBr?= =?utf-8?B?OU0ydHdweFAyVEovc1JxUzhRc0kzeTlkdE1mVjMzSWRCZW1hbUdDbVAxN0xX?= =?utf-8?B?SVpPWFpqYlZvN0pXOGI1SWpFR2pSbkx2WkVHZjZEOEJsZ2paVVZ3QVVSenpU?= =?utf-8?Q?InXE1SS0vq+LPnqIr0GfQGXqzhSvMSjlfzLokk4?= X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-Network-Message-Id: 791e6218-31ee-4c1e-074a-08d9152d3aa0 X-MS-Exchange-CrossTenant-AuthSource: TYAPR01MB5689.jpnprd01.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 May 2021 10:03:46.2044 (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: 0INOsN5r9YTxLZ8Ai2UpBREm2x3wjtCeFJlgV1DTQFY8LOxuqQZG7OkLrpeaWXiLR3jSgnw+Qo/V2fMV92fLXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY2PR01MB3850 Archived-At: Subject: Re: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 May 2021 10:03:58 -0000 Hello Eliot, On 2021-05-12 16:43, Eliot Lear wrote: > Hi Brian and Martin, > > I want to add one cautionary note about appeals and use of the IAB. The IAB as a body may be conflicted on an issue. Suppose the proposal is to eliminate the IAB stream, and require them to use the IETF stream, and the chairs simply refuse to call for consensus on the question. What happens? In some sense, that's a good example. (Also, the other examples in your previous mail were very good.) But eliminating the IAB stream would mean changing the role of the IAB itself, so if the RFC WG and the RSAB thought that was their job, that would in my view be like the tail waging the dog. So if this came out of the blue, the IAB would be justified to reject it. If on the other hand, the problem was with the IAB (let's say a situation similar to the Kobe incident), then we could assume an overall strong consensus to change the role of the IAB in the first place, and the RFC WG and the RSAB would essentially just do the paperwork on their side. At that point, that IAB wouldn't be in a position to oppose such changes, and their responsibility for RFCs overall might be taken away too. (I really hope these are all eventualities that never materialize.) Regards,   Martin. > Eliot > >> On 12 May 2021, at 03:08, Brian E Carpenter wrote: >> >> On 12-May-21 12:15, Martin J. Dürst wrote: >>> Hello Brian, everybody, >>> >>> On 2021-05-11 11:09, Brian E Carpenter wrote: >>>> On 10-May-21 21:16, Eliot Lear wrote: >>>>> Hi Joel, >>>>> >>>>> Yes, this is a good point, but I want to restate it slightly, and I’ve opened Issue 63 to do so: >>>>> >>>>> Who has the final authority to make evolve the processes that we are defining here? Can we enumerate possible answers? >>>>> >>>>> * Does it continue to rest with the IAB? >>>> >>>> As I said on the thread for another issue, my current feeling is >>>> that the IAB should be in the appeal chain after the RSAB. (If we >>>> continue that line of thought, we'd ask the ISOC Board to be the >>>> end point, as it is for IETF process issues.) >>> >>> I think we have to be careful to distinguish the following two things: >>> >>> 1) The formal appeal process. For this, I'm okay with what >>> Brian proposes just above. Some other arrangements may also be okay. >>> >>> 2) The authority to evolve the process. This may rest (formally) >>> with the same organizations as the appeal process, or it may not. >>> If we look at the current instance (i.e. the work of this >> very >>> group), I'm not exactly sure about how it worked, but I don't >>> remember any kind of appeal being involved. What I remember >>> is having a lot of community discussion/pressure involved, based >>> on a general feeling that something went wrong. >> >> I'd say: the same authority for both. Otherwise we could be accused >> of manufacturing bureaucracy. >> >> The past situation effectively gave final authority to the IAB and the >> only recourse was a recall. I don't think anybody was happy with that. >> >> Brian >> >>> >>> Regards, Martin. >>> >>>>> * Could it rest with the community as represented by the RFCWG and >> confirmed by the RSAB? >>>> >>>> As long as there is an appeal chain as above. >>>> >>>>> * Is it the IETF community as confirmed by the IESG? >>>> >>>> No. It's wider than the IETF. That's why this will not >>>> be an IETF WG. From a higher level viewpoint, I think >>>> the RSAB is a peer group of the IESG and the IRSG. >>>> (It's almost as if we were setting up the RFC Task Force.) >>>> >>>>> * Is it the IETF community as confirmed by the IAB? >>>> >>>> Ditto. >>>> >>>>> * Other? >>>> >>>> I don't think so. >>>> >>>> Regards >>>> Brian >>>> >>>> >>>>> >>>>> Eliot >>>>> >>>>>> On 10 May 2021, at 05:55, Joel M. Halpern > wrote: >>>>>> >>>>>> Buried in the below is an interesting and important point. >>>>>> Suppose that we work out a process, agree to it, and try it. And >>>> it fails. (For any number of possible meanings of "fail".) >>>>>> >>>>>> Who has the authority to decide something needs to be done? Who has the authority to make something happen. Under current rules, whether we like them or not, the authority for what we are doing comes from >>>> the IAB, via the RFCs that say it is the IABs job. >>>>>> >>>>>> It seems to me that Mike's point below about who has the ultimate authority is important. And at that point, I don't think "the community" is a viable answer. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> PS: I am sorry you do not like my usage of strawman Mike. But the premise for your objection is sufficiently vague that I do not know what else to call it. If the only purpose of your description was to >> get to the "who has authority to fix things if they are broken", then as above, I agree that is an important question. I was completely unable to get to that issue from what you wrote. In particular, I could >> not connect that with your conclusion that the RSAB should be empowered to bypass the RSWG. >>>>>> >>>>>> On 5/9/2021 10:58 PM, Michael StJohns wrote: >>>>>>> On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >>>>>>>> Mike, your analysis seems a bit flawed. >>>>>>>> Yes, the IESG approved those documents after community consultation, >>>> on the basis that the community had agreed. >>>>>>>> And yes, that judgement was made by the IESG. >>>>>>>> >>>>>>>> On the other hand, if the community members had thought the IESG conclusion was wrong, that was appealable to the IAB. >>>>>>> The way I've always understood it is that process can be appealed with some possibility of a reversal, but a decision that follows the process, no matter whether some community members thought it was the wrong decision, is unlikely to be reversed. >>>>>>>> >>>>>>>> That is very different from declaring that the RSAB can publish a document without community approval. >>>>>>> See above. AFAICT, there were folks in opposition to the Nomcom >>>> decision, but the community was heard. I'm not saying that the community will not be heard, but I'm saying - similar to what the IESG did >> with documenting the Nomcom decision - that individual members or even a small subsection of the community should not have a veto over the publication of documents that the RSAB believes necessary for the operation of the >>>> streams. >>>>>>>> And given the structure that is proposed, there seems much less reason for any process that bypasses the working group. >>>>>>> WGs by their nature are self-selected and generally consist of a small percentage of the overall community with strong opinions about the topics covered by the WG (with the active participants being even somewhat smaller). When the scope is small enough - e.g. DNSOP for example - the community affected by the decisions will mostly mirror the community represented by the WG. When the scope is large enough - e.g. >> Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of the WG represent the best results for the community of the whole. In >>>> the Nomcom case, we were able to gather a reasonably large group of people (in the form of a WG) of diverse views for a sufficient time (multiple times) to spend a very large amount of effort to craft and recraft the Nomcom process. But that differs from this proposed WG in that the various Nomcom related WGs had well defined target outputs and a need >>>> to complete in a reasonably short period of time (by IETF standards at >>>>>>> least). >>>>>>> I'm trying to avoid us replacing the RSOC with the RSWG - but I can't >>>> see how we can get enough diversity of interest for an indefinite period of time to ensure that the RSWG continues to operate as a useful source of community involvement rather than a place for a small number of self-selected folk to have an overly large continuing impact on a process that's >>>> absolutely critical to the community's success. Nor has any one been willing to address that specific point. >>>>>>> Peter did say: >>>>>>>> Yes, there are failure modes where the WG is inactive (in which case >>>>>>>> we'd need to inject more energy) or unable to reach consensus (in which >>>>>>>> case we'd need to work harder to do so), >>>>>>> But I would ask who the "we'd" is in the above? e.g. once this group dissolves in favor of the new structure, who has the responsibility >>>> of fixing things if the WG structure fails or devolves? Are we going to be back here in 4 years? Or does the RSAB go on its merry way and do what it needs to do? If not, who reconstitutes the next RFCED-Futures group given that we will have taken the IAB out of the picture? The RSAB? >>>>>>>> >>>>>>>> I think everyone knows that I do not like the current approach. But I can live with it. And it seems to be the approach the community >> wants. >>>>>>> Or at least the 1/2 dozen or so people who have argued for the approach - not sure that's the community. >>>>>>>> Creating strawmen as obstacles does not seem helpful. >>>>>>> And thanks for that denigrating comment. You might not like what I'm saying nor agree with them, but calling them strawmen implies >>>> that they are there simply to providing a blocking issue and they have >> no >>>> basis in reality and that I'm doing that simply to screw up what process there is. >>>>>>> Mike >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>>>>>>>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>>>>>>>> IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 >>>>>>>>>> as a canonical example: the IESG approved it as a BCP by standard >>>>>>>>>> process including IETF Last Call. The IAB co-signed it too, on its >>>>>>>>>> own authority. >>>>>>>>>> >>>>>>>>>> Brian >>>>>>>>> >>>>>>>>> A much better (and much more recent) counter example is draft-iesg-nomcom-eligibility-2020 which became RFC 8788. >>>>>>>>> >>>>>>>>> This was an IESG initiated document that solicited community input, >>>> but ultimately was published on the IESG's dime with their sole interpretation of community consensus. >>>>>>>>> >>>>>>>>> RFC6360. RFC3932. And RFC 3710 (the IESG charter). >>>>>>>>> >>>>>>>>> The point is that the IESG does this too. And its not a bad >> thing, especially when we have 100 different opinions and we need a final >> answer sooner rather than later. >>>>>>>>> >>>>>>>>> I don't expect the RSAB to do a lot of internally originated documents, but I do expect there will be cases where a decision has to be made, >>>> and that there will be some immediacy necessary. >>>>>>>>> >>>>>>>>> Later, Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> -- >>>>>> 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 > > -- Prof. Dr.sc. Martin J. Dürst Department of Intelligent Information Technology College of Science and Engineering Aoyama Gakuin University Fuchinobe 5-1-10, Chuo-ku, Sagamihara 252-5258 Japan From nobody Wed May 12 08:27: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 0C3103A0B51 for ; Wed, 12 May 2021 08:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVUpBDg7Ey7M for ; Wed, 12 May 2021 08:27:37 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A66B3A0B4F for ; Wed, 12 May 2021 08:27:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1651; q=dns/txt; s=iport; t=1620833257; x=1622042857; h=from:mime-version:subject:message-id:date:to; bh=Ge6c9UKSG4kHPeVH8yirPXT++vsR76hK5gTVIGHqe+0=; b=msUzvkPauRYLFvZurbAEnB/GaNnZymdjYx8DrO6FFsW0RlAY/j33f3oW kjoWouit+QJjETVBzJFcdWcoXtovXSaxNrTctbO84PjPFRdPy+z/vEyHe 2uef1KOg2y4/+scLg1D03KqeU1n3gEsnZt5HT729WWqpcy9eXNaXQC+ki o=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AMAQAx85tglxbLJq1aHAEBAQEBAQcBARIBAQQEAQGCF?= =?us-ascii?q?4N4AScShHiJBKQegWgEBwEBAQoDAQE8BAEBhkYmOBMCBAEBAQEDAgMBAQEBB?= =?us-ascii?q?QEBBQEBAQIBBgQUAQEBAQEBAQFohV2GbksyNgI/gyQBgweaQY4XeoEygQGJd?= =?us-ascii?q?RCBOoFTjFOCDYE8HIcmgQeCSjaCLQSEIQKBUYEfnW6dIIMfg0qBSZgtBSKDW?= =?us-ascii?q?IsSlkqGVa5MAYQIAgQGBQIWgWshgVszGggbFTsqAYI/PRIZDo44jjY/A2cCB?= =?us-ascii?q?gEJAQEDCY0QAQE?= IronPort-HdrOrdr: A9a23:WRY3o657ak+P01rxmAPXwNvXdLJyesId70hD6qkRc3Fom6Oj9v xG8M5w6faLslgssQAb9exoUZPoKRjhHPVOjrX5U43DYOCfghrKEGmnhrGSpgEJ3EbFh4xg6Z s= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,293,1613433600"; d="asc'?scan'208";a="35952863" 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; 12 May 2021 15:27:32 +0000 Received: from smtpclient.apple ([10.61.144.15]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 14CFRWf2024102 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 12 May 2021 15:27:32 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_D9723B40-4BD0-4686-AB6A-40F21A02F23E"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: Date: Wed, 12 May 2021 17:27:31 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.15, [10.61.144.15] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: [Rfced-future] A brief reminder- please bring issue conversations to the mailing list X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 15:27:42 -0000 --Apple-Mail=_D9723B40-4BD0-4686-AB6A-40F21A02F23E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear colleagues, As you all know, this group is trying to forge a consensus from many = different perspectives. To facilitate that the chairs would like to = remind you that comments about issues should be made on list, and not in = the issue tracker. There is a procedural reason for this=E2=80=93 we = haven=E2=80=99t agreed to use the tracker for discussions =E2=80=93 and = there is a substantive issue: if it seems you are finding common ground = in the tracker, you may be sadly disappointed when the issue is raised = on the list. And that in turn may set the effort back. Thank you. We now return you to your regularly scheduled = Wednesday/Thursday. Eliot --Apple-Mail=_D9723B40-4BD0-4686-AB6A-40F21A02F23E 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCb8+MACgkQh7ZrRtnS ejMKQwf9FXWT4ZB9jCZ+iI/D16MhSmT0KmxsD8QO3I4h1Dq2yJ0ny1mCQuheN6oY ylZ9cXK3LC6d4oITSzyFw2EaTMm03GtH/zTiic49ex7DWZ67Ef9sQWdJI85WbAFq 0eYB6Q7ZhuNYQzlVfJzwWdJGo1mfDhWRwNuK1+WAu1APWWMLQm+FtEKhRZUJITzt 6a2Vr8C0eEB+C7Udxfw1SkJKv7HPQrCOVYZC39xeFFjHpfzVAlaExgKuMT9scdEI wgtGCzQSVSRpeh7CRQ8T6yUiUO14JQUBiAwBDmi6nTO+aS/o7e51JHXyewu18jrv 832wWK/OpooJl3k+eoH1eRYy4u7Q6w== =+lrn -----END PGP SIGNATURE----- --Apple-Mail=_D9723B40-4BD0-4686-AB6A-40F21A02F23E-- From nobody Wed May 12 09:27:10 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 003B33A0ECC for ; Wed, 12 May 2021 09:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=isi-edu.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcDDvOD1dslg for ; Wed, 12 May 2021 09:27:04 -0700 (PDT) Received: from mail-oo1-xc2c.google.com (mail-oo1-xc2c.google.com [IPv6:2607:f8b0:4864:20::c2c]) (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 DF1D13A0ECE for ; Wed, 12 May 2021 09:27:03 -0700 (PDT) Received: by mail-oo1-xc2c.google.com with SMTP id p6-20020a4adc060000b02901f9a8fc324fso5071449oov.10 for ; Wed, 12 May 2021 09:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isi-edu.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pWVFfM4IabdyPbNFA93q4rzbNl2hn4mddOptxfZWBSo=; b=KPKFQw+d5NdxGEOyCIEMy8AC5bMQlVeGTGQ4NSb8bhVWJXFmkgq3C96t9hthmDjLmN RB5mb0OHOPC797YJEvFz/GyxmhDzY8PjRKqy41IEkdrM6xlw3vf1lN/rVWKxqRsuDQgu QMdTvwzhlB9aUFPrp3r95vs/nawVgqEI80HNQ4EdnLiPUVThZXH2uWZZ6NdMegiCdJ2r pT8Cl7Kv+fNnD6cN0fvEH4vSk84Dz1IUOPoaMjGsRr45/KTOFFpL0/poBbcFMWMkRcG4 fNi4oNOkgZ0VnGC7sk1CtwxZjF42OCySzcsq0/koEWMhyo+WvPfx1eNxBnY5+H9rWsRu n3QA== 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=pWVFfM4IabdyPbNFA93q4rzbNl2hn4mddOptxfZWBSo=; b=A0EQcx2ZRZbbGXRiHvaQfj/TBlzv4cE5Ycg4FkebtEdTTrmA+MB/lKKbPHzhgN0zIs D1mhViVM9aPB53dbtDIrfxMBEbP233baKwkUufN/b8n+44GLysmDQuHSqLYbMrCu1t5m eDu2SE8wRD4a8s0zOWb4Zlzt+qiYCaTrIShURxsUeyAb+Uh+QOoVCXzLpx4fzK+3XT95 auAsK1IxlYUc/gmtpUXUG+ATDZpVVTT5NCqEplSWSivh4nPBIRdCRMy7xcQWW5DDRDdq b/+NpucUCFXTTQBoAKGswShbxoLMPbHxAn1vd7aJYBy/aQO/us5rsTpAVL6Z9nObmHkS hNtQ== X-Gm-Message-State: AOAM530N9PM7Yup4BhnumnX/cwGFN1F33KUPQpr4ZOQX55dGKmFdPiI6 sdTSOk6TgDcSuoJPSwWoFBk1dF4EKBoN6rjgXFWbEQ== X-Google-Smtp-Source: ABdhPJxptYyYVL73s3GgAtTKgdMs8etYfLJtRGhlA+QTEw3nqwm/zUGgQB27bY06UzBhV2o2JuJ/o/xfRbTxD9CU9Ng= X-Received: by 2002:a4a:3e13:: with SMTP id t19mr28727413oot.46.1620836821995; Wed, 12 May 2021 09:27:01 -0700 (PDT) MIME-Version: 1.0 References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> In-Reply-To: From: Wes Hardaker Date: Wed, 12 May 2021 09:26:26 -0700 Message-ID: To: Eliot Lear Cc: Brian E Carpenter , rfced-future@iab.org, =?UTF-8?Q?Martin_J=2E_D=C3=BCrst?= , "Joel M. Halpern" , Michael StJohns Content-Type: multipart/alternative; boundary="00000000000003a3d705c2247bbe" Archived-At: Subject: Re: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 12 May 2021 16:27:09 -0000 --00000000000003a3d705c2247bbe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Maybe one way to tackle this problem: What are the characteristics of an appeals body you (collectively) want? That might help narrow the search down or at least allow for better comparisons when no body fits all the checkboxes. On Wed, May 12, 2021 at 12:44 AM Eliot Lear wrote: > Hi Brian and Martin, > > I want to add one cautionary note about appeals and use of the IAB. The > IAB *as a body* may be conflicted on an issue. Suppose the proposal is > to eliminate the IAB stream, and require them to use the IETF stream, and > the chairs simply refuse to call for consensus on the question. What > happens? > > Eliot > > On 12 May 2021, at 03:08, Brian E Carpenter > wrote: > > On 12-May-21 12:15, Martin J. D=C3=BCrst wrote: > > Hello Brian, everybody, > > On 2021-05-11 11:09, Brian E Carpenter wrote: > > On 10-May-21 21:16, Eliot Lear wrote: > > Hi Joel, > > Yes, this is a good point, but I want to restate it slightly, and I=E2=80= =99ve > opened Issue 63 to do so: > > Who has the final authority to make evolve the processes that we are > defining here? Can we enumerate possible answers? > > * Does it continue to rest with the IAB? > > > As I said on the thread for another issue, my current feeling is > that the IAB should be in the appeal chain after the RSAB. (If we > continue that line of thought, we'd ask the ISOC Board to be the > end point, as it is for IETF process issues.) > > > I think we have to be careful to distinguish the following two things: > > 1) The formal appeal process. For this, I'm okay with what > Brian proposes just above. Some other arrangements may also be okay. > > 2) The authority to evolve the process. This may rest (formally) > with the same organizations as the appeal process, or it may not. > If we look at the current instance (i.e. the work of this > > very > > group), I'm not exactly sure about how it worked, but I don't > remember any kind of appeal being involved. What I remember > is having a lot of community discussion/pressure involved, based > on a general feeling that something went wrong. > > > I'd say: the same authority for both. Otherwise we could be accused > of manufacturing bureaucracy. > > The past situation effectively gave final authority to the IAB and the > only recourse was a recall. I don't think anybody was happy with that. > > Brian > > > Regards, Martin. > > * Could it rest with the community as represented by the RFCWG and > > confirmed by the RSAB? > > > As long as there is an appeal chain as above. > > * Is it the IETF community as confirmed by the IESG? > > > No. It's wider than the IETF. That's why this will not > be an IETF WG. From a higher level viewpoint, I think > the RSAB is a peer group of the IESG and the IRSG. > (It's almost as if we were setting up the RFC Task Force.) > > * Is it the IETF community as confirmed by the IAB? > > > Ditto. > > * Other? > > > I don't think so. > > Regards > Brian > > > > Eliot > > On 10 May 2021, at 05:55, Joel M. Halpern mailto:jmh@joelhalpern.com >> wrote: > > Buried in the below is an interesting and important point. > Suppose that we work out a process, agree to it, and try it. And > > it fails. (For any number of possible meanings of "fail".) > > > Who has the authority to decide something needs to be done? Who has the > authority to make something happen. Under current rules, whether we like > them or not, the authority for what we are doing comes from > > the IAB, via the RFCs that say it is the IABs job. > > > It seems to me that Mike's point below about who has the ultimate > authority is important. And at that point, I don't think "the community" > is a viable answer. > > Yours, > Joel > > PS: I am sorry you do not like my usage of strawman Mike. But the premis= e > for your objection is sufficiently vague that I do not know what else to > call it. If the only purpose of your description was to > > get to the "who has authority to fix things if they are broken", then as > above, I agree that is an important question. I was completely unable to > get to that issue from what you wrote. In particular, I could > not connect that with your conclusion that the RSAB should be empowered t= o > bypass the RSWG. > > > On 5/9/2021 10:58 PM, Michael StJohns wrote: > > On 5/9/2021 10:32 PM, Joel M. Halpern wrote: > > Mike, your analysis seems a bit flawed. > Yes, the IESG approved those documents after community consultation, > > on the basis that the community had agreed. > > And yes, that judgement was made by the IESG. > > On the other hand, if the community members had thought the IESG > conclusion was wrong, that was appealable to the IAB. > > The way I've always understood it is that process can be appealed with > some possibility of a reversal, but a decision that follows the process, = no > matter whether some community members thought it was the wrong decision, = is > unlikely to be reversed. > > > That is very different from declaring that the RSAB can publish a documen= t > without community approval. > > See above. AFAICT, there were folks in opposition to the Nomcom > > decision, but the community was heard. I'm not saying that the community > will not be heard, but I'm saying - similar to what the IESG did > > with documenting the Nomcom decision - that individual members or even a > small subsection of the community should not have a veto over the > publication of documents that the RSAB believes necessary for the operati= on > of the > > streams. > > And given the structure that is proposed, there seems much less reason fo= r > any process that bypasses the working group. > > WGs by their nature are self-selected and generally consist of a small > percentage of the overall community with strong opinions about the topics > covered by the WG (with the active participants being even somewhat > smaller). When the scope is small enough - e.g. DNSOP for example - the > community affected by the decisions will mostly mirror the community > represented by the WG. When the scope is large enough - e.g. > > Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of > the WG represent the best results for the community of the whole. In > > the Nomcom case, we were able to gather a reasonably large group of peopl= e > (in the form of a WG) of diverse views for a sufficient time (multiple > times) to spend a very large amount of effort to craft and recraft the > Nomcom process. But that differs from this proposed WG in that the vario= us > Nomcom related WGs had well defined target outputs and a need > to complete in a reasonably short period of time (by IETF standards at > > least). > I'm trying to avoid us replacing the RSOC with the RSWG - but I can't > > see how we can get enough diversity of interest for an indefinite period > of time to ensure that the RSWG continues to operate as a useful source o= f > community involvement rather than a place for a small number of > self-selected folk to have an overly large continuing impact on a process > that's > absolutely critical to the community's success. Nor has any one been > willing to address that specific point. > > Peter did say: > > Yes, there are failure modes where the WG is inactive (in which case > we'd need to inject more energy) or unable to reach consensus (in which > case we'd need to work harder to do so), > > But I would ask who the "we'd" is in the above? e.g. once this group > dissolves in favor of the new structure, who has the responsibility > > of fixing things if the WG structure fails or devolves? Are we going to > be back here in 4 years? Or does the RSAB go on its merry way and do wha= t > it needs to do? If not, who reconstitutes the next RFCED-Futures group > given that we will have taken the IAB out of the picture? The RSAB? > > > I think everyone knows that I do not like the current approach. But I can > live with it. And it seems to be the approach the community > > wants. > > Or at least the 1/2 dozen or so people who have argued for the approach - > not sure that's the community. > > Creating strawmen as obstacles does not seem helpful. > > And thanks for that denigrating comment. You might not like what I'm > saying nor agree with them, but calling them strawmen implies > > that they are there simply to providing a blocking issue and they have > > no > > basis in reality and that I'm doing that simply to screw up what process > there is. > > Mike > > > Yours, > Joel > > On 5/9/2021 9:41 PM, Michael StJohns wrote: > > On 5/9/2021 8:39 PM, Brian E Carpenter wrote: > > IMHO, the IAB can and does do this but the IESG doesn't. Take RFC1984 > as a canonical example: the IESG approved it as a BCP by standard > process including IETF Last Call. The IAB co-signed it too, on its > own authority. > > Brian > > > A much better (and much more recent) counter example is > draft-iesg-nomcom-eligibility-2020 which became RFC 8788. > > This was an IESG initiated document that solicited community input, > > but ultimately was published on the IESG's dime with their sole > interpretation of community consensus. > > > RFC6360. RFC3932. And RFC 3710 (the IESG charter). > > The point is that the IESG does this too. And its not a bad > > thing, especially when we have 100 different opinions and we need a final > answer sooner rather than later. > > > I don't expect the RSAB to do a lot of internally originated documents, > but I do expect there will be cases where a decision has to be made, > > and that there will be some immediacy necessary. > > > Later, Mike > > > > > -- > 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 > --=20 Wes Hardaker USC/ISI --00000000000003a3d705c2247bbe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe one way to tackle this problem:

W= hat are the characteristics of an appeals body you (collectively) want?=C2= =A0 That might help narrow the search down or at least allow for better com= parisons when no body fits all the checkboxes.

On Wed, May 12, 2021 at= 12:44 AM Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:
Hi B= rian and Martin,

I want to add one cautionary note about= appeals and use of the IAB.=C2=A0 The IAB as a body=C2=A0may be con= flicted on an issue.=C2=A0 Suppose the proposal is to eliminate the IAB str= eam, and require them to use the IETF stream, and the chairs simply refuse = to call for consensus on the question.=C2=A0 What happens?

Eliot

On 12 May 2021, a= t 03:08, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

On 12-May-21 12:15, Martin J. D=C3=BCrst wrote:
Hello Brian, everybody,

On 2021-05-11 11:09, Brian E Carpe= nter wrote:
On 10-May-21 21:16, Eliot Lear wro= te:
Hi Joel,

Yes, this is a good point,= but I want to restate it slightly, and I=E2=80=99ve opened Issue 63 to do = so:

Who has the final authority to make evolve the processes that we= are defining here?=C2=A0 Can we enumerate possible answers?

=C2=A0= =C2=A0* Does it continue to rest with the IAB?

As I sai= d on the thread for another issue, my current feeling is
that the IAB sh= ould be in the appeal chain after the RSAB. (If we
continue that line of= thought, we'd ask the ISOC Board to be the
end point, as it is for = IETF process issues.)

I think we have to be careful to = distinguish the following two things:

1) The formal appeal process. = For this, I'm okay with what
=C2=A0 =C2=A0Brian proposes just above= . Some other arrangements may also be okay.

2) The authority to evol= ve the process. This may rest (formally)
=C2=A0 =C2=A0with the same org= anizations as the appeal process, or it may not.
=C2=A0 =C2=A0If we loo= k at the current instance (i.e. the work of this
very
<= blockquote type=3D"cite"> =C2=A0 =C2=A0group), I'm not exactly sure abo= ut how it worked, but I don't
=C2=A0 =C2=A0remember any kind of app= eal being involved. What I remember
=C2=A0 =C2=A0is having a lot of com= munity discussion/pressure involved, based
=C2=A0 =C2=A0on a general fe= eling that something went wrong.

I'd say: the same = authority for both. Otherwise we could be accused
of manufacturing burea= ucracy.

The past situation effectively gave final authority to the I= AB and the
only recourse was a recall. I don't think anybody was hap= py with that.

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


Regards, =C2=A0 Martin.

=C2=A0=C2=A0* Could it rest with the community as represen= ted by the RFCWG and
confirmed b= y the RSAB?

As l= ong as there is an appeal chain as above.

= =C2=A0=C2=A0* Is it the IETF community as confirmed by the IESG?

No. It's wider than the IETF. That's why this will notbe an IETF WG. From a higher level viewpoint, I think
the RSAB is a pe= er group of the IESG and the IRSG.
(It's almost as if we were settin= g up the RFC Task Force.)

=C2=A0=C2=A0* I= s it the IETF community as confirmed by the IAB?

Ditto.=

=C2=A0=C2=A0* Other?
I don't think so.

Regards
=C2=A0=C2=A0=C2=A0Brian


Eliot

On 1= 0 May 2021, at 05:55, Joel M. Halpern <jmh@joelhalpern.com <mailto:jmh@joelhalpern.com>> wr= ote:

Buried in the below is an interesting and important point.
S= uppose that we work out a process, agree to it, and try it.=C2=A0 And
it fails. =C2=A0=C2=A0(For any number of possible m= eanings of "fail".)

Who has the authority to decide something needs to be done?= =C2=A0 Who has the authority to make something happen.=C2=A0 Under current = rules, whether we like them or not, the authority for what we are doing com= es from
the IAB, via the RFCs that say it is t= he IABs job.

It = seems to me that Mike's point below about who has the ultimate authorit= y is important.=C2=A0 And at that point, I don't think "the commun= ity" is a viable answer.

Yours,
Joel

PS: I am sorry y= ou do not like my usage of strawman Mike.=C2=A0 But the premise for your ob= jection is sufficiently vague that I do not know what else to call it.=C2= =A0 If the only purpose of your description was to
get to the "who has authority to fix t= hings if they are broken", then as above, I agree that is an important= question.=C2=A0 I was completely unable to get to that issue from what you= wrote.=C2=A0 In particular, I could
not connect that with your conclus= ion that the RSAB should be empowered to bypass the RSWG.

On 5/9/2021 10:58 PM, Michael StJohns wrote:
On 5/9/2021 10:32 PM, Joel M. Halpern wrote:
Mike, your analysis seems a bit flawed.
Yes, the IESG a= pproved those documents after community consultation,
on the basis that the community had agree= d.
And yes, that judgement was made by the= IESG.

On the other hand, if the community members had thought the I= ESG conclusion was wrong, that was appealable to the IAB.
T= he way I've always understood it is that process can be appealed with s= ome possibility of a reversal, but a decision that follows the process, no = matter whether some community members thought it was the wrong decision, is= unlikely to be reversed.

That is very dif= ferent from declaring that the RSAB can publish a document without communit= y approval.
See above.=C2=A0 AFAICT, there were folks in op= position to the Nomcom
decision, = but the community was heard.=C2=A0 I'm not saying that the community wi= ll not be heard, but I'm saying - similar to what the IESG did
with documenting the Nomcom decision - that individua= l members or even a small subsection of the community should not have a vet= o over the publication of documents that the RSAB believes necessary for th= e operation of the
s= treams.
And given the structure that is pro= posed, there seems much less reason for any process that bypasses the worki= ng group.
WGs by their nature are self-selected and general= ly consist of a small percentage of the overall community with strong opini= ons about the topics covered by the WG (with the active participants being = even somewhat smaller).=C2=A0=C2=A0 When the scope is small enough - e.g. D= NSOP for example - the community affected by the decisions will mostly mirr= or the community represented by the WG.=C2=A0 When the scope is large enoug= h - e.g.
Nomcom, RFC ED, etc - you have a hard time ensuring that the opinions of= the WG represent the best results for the community of the whole.=C2=A0 In=
the Nomcom case, we= were able to gather a reasonably large group of people (in the form of a W= G)=C2=A0 of diverse views for a sufficient time (multiple times) to spend a= very large amount of effort to craft and recraft the Nomcom process.=C2=A0= But that differs from this proposed WG in that the various Nomcom related = WGs had well defined target outputs and a need
to complete in a reasonab= ly short period of time (by IETF standards at
=
least).
I'm tryi= ng to avoid us replacing the RSOC with the RSWG - but I can't
see how we can get enough diversity of int= erest for an indefinite period of time to ensure that the RSWG continues to= operate as a useful source of community involvement rather than a place fo= r a small number of self-selected folk to have an overly large continuing i= mpact on a process that's
absolutely critical to the community's= success.=C2=A0 Nor has any one been willing to address that specific point= .
Peter did say:
Yes, there are failur= e modes where the WG is inactive (in which case
we'd need to inject = more energy) or unable to reach consensus (in which
case we'd need t= o work harder to do so),
But I would ask who the "we&#= 39;d" is in the above?=C2=A0 e.g. once this group dissolves in favor o= f the new structure, who has the responsibility
of fixing things if the WG structure fails or devolves?=C2= =A0 Are we going to be back here in 4 years?=C2=A0 Or does the RSAB go on i= ts merry way and do what it needs to do?=C2=A0 If not, who reconstitutes th= e next RFCED-Futures group given that we will have taken the IAB out of the= picture?=C2=A0 The RSAB?

I think every= one knows that I do not like the current approach. But I can live with it.= =C2=A0 And it seems to be the approach the community
wants.
Or at least the 1/2 dozen= or so people who have argued for the approach - not sure that's the co= mmunity.
Creating strawmen as obstacles does n= ot seem helpful.
And thanks for that denigrating comment.= =C2=A0=C2=A0 You might not like what I'm saying nor agree with them, bu= t calling them strawmen implies
t= hat they are there simply to providing a blocking issue and they have
<= /blockquote>
no
basis in reality and that I'm doing that simply to screw up w= hat process there is.
Mike

Yours,Joel

On 5/9/2021 9:41 PM, Michael StJohns wrote:
On 5/9/2021 8:39 PM, Brian E Carpenter wrote:
IMHO, the IAB can and does do this but the IESG doesn't. Tak= e RFC1984
as a canonical example: the IESG approved it as a BCP by stand= ard
process including IETF Last Call. The IAB co-signed it too, on itsown authority.

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

A muc= h better (and much more recent) counter example is draft-iesg-nomcom-eligib= ility-2020 which became RFC 8788.

This was an IESG initiated documen= t that solicited community input,
but ultimately was published on the IESG's d= ime with their sole interpretation of community consensus.

RFC6360.=C2=A0 RFC3932.=C2=A0= And RFC 3710 (the IESG charter).

The point is that the IESG does th= is too.=C2=A0 And its not a bad
=
thing, especially when = we have 100 different opinions and we need a final
answer sooner rather= than later.

I don't expect the = RSAB to do a lot of internally originated documents, but I do expect there = will be cases where a decision has to be made,
and that there will be some immedia= cy necessary.
Later, Mike




-- <= br>Rfced-future mailing list
Rfced-future@iab.org <mailto:Rfced-future@iab.org>
ht= tps://www.iab.org/mailman/listinfo/rfced-future




--
Rfced-future mai= ling list
Rfce= d-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


--
Wes Hardaker
USC/ISI
<= /div>
--00000000000003a3d705c2247bbe-- From nobody Wed May 12 15:20: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 B58C33A1667 for ; Wed, 12 May 2021 15:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, 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 j57rkZtQnt4x for ; Wed, 12 May 2021 15:19:58 -0700 (PDT) Received: from mail-pl1-x631.google.com (mail-pl1-x631.google.com [IPv6:2607:f8b0:4864:20::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 697DB3A2785 for ; Wed, 12 May 2021 14:54:13 -0700 (PDT) Received: by mail-pl1-x631.google.com with SMTP id b15so7093892plh.10 for ; Wed, 12 May 2021 14:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=GIivNeI0i4z0+RH0EVCilj6MriptQ7dm+0NGQEHjvAU=; b=ohD6fbl9M9ZS3g5qnjylW/gnECdKMgSuGnYbFcTe1Ur2dLiG8opKp9D0SD1Kd69y9c Sut7sMpX4OY8YfwITcS3/rR0h1v7U6TMwf7Diq2p1sADQ6qnCQ71XaiUccq4nksNXmHD XZLl5wiMkQQwzjlNyutsd/zqryfoBEJ/7pBwdgiyrbnCqa4RDzWATbuxW/2C4jRvQH4Y bHhdcxvvd/LeTtx/Spx4eiTpE/MtYP+R+OGpAjG6Ry0UjxWCS10xVeBbjvV19hvoFEe6 cRSPYL5yKlkwF+3salFUNZbSYoU7ynLGtUrj+hkvvCcHmIgQubKKQsPK8Fkel13SDulV qcEA== 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=GIivNeI0i4z0+RH0EVCilj6MriptQ7dm+0NGQEHjvAU=; b=LcBI1suBrID7Aj29i1uJ4ZHxoM1snz3b8VzQvO2u7fgU+n4i7oO4iFf+pMm2P7hHua zsSfiWJ8hiZMJKhMC7cYnCf9taEA/+vD4LSTWp8InL76tAh6v5YeUZSiQk508TS2oOtc v7Z9QeSL3qIj5dsUNhniYU9oObEXw2Z3TtT0QTNtn+VG4MJINpFq1Uuk5fwx5nfOnmU4 XgjJwI+TmDOPaDpv3u/glc3q8RNPB+hxl9B0JkMGxVjOSLMhxyAtNisXDNUMqxiiBHM1 mLQ30qzkHa1fnvD16AtFfaVv26rNSka4Yopq3d4n20SqXCtsTdPr/4th6i1+KjS8aYOb vJsQ== X-Gm-Message-State: AOAM530fECvi/tU3p8VSKHAOE2ZlDWTxLHEluWSfhYNVWj09EAa3mw9C yu36OCeuVyIbk+n6y5h/Z+ESxDTamxYTlQ== X-Google-Smtp-Source: ABdhPJxB/9NwMfDpJLhNczxohixCrzKzL8gvcBn8NxzA0dlO6AHQuex7XdB1o11U4VVikpQv83uB8Q== X-Received: by 2002:a17:902:d501:b029:ed:1847:1617 with SMTP id b1-20020a170902d501b02900ed18471617mr37521589plg.29.1620856452412; Wed, 12 May 2021 14:54:12 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id i17sm613498pfd.84.2021.05.12.14.54.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 May 2021 14:54:11 -0700 (PDT) To: =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , Eliot Lear , Eric Rescorla Cc: rfced-future@iab.org References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> From: Brian E Carpenter Message-ID: Date: Thu, 13 May 2021 09:54:06 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 22:20:04 -0000 On 12-May-21 20:10, Martin J. D=C3=BCrst wrote: > Hello Eliot, >=20 > On 2021-05-12 16:18, Eliot Lear wrote: >> Just so that your humble co-chair understands what is being proposed, = I think I am understanding several points: >> >> 1. The recourse to a bad RSAB decision is not a formal appeal but arg= ue to constituent bodies to replace their members. s/recourse/first recourse/ surely? The *final* recourse is definitely an = appeal. Brian >=20 > That was not my understanding, and I hope it wasn't Brian's. The=20 > recourse to an "average" bad RSAB decision should be an appeal, similar=20 > to e.g. a bad decision by an IETF WG chair or an AD,... >=20 > As a recourse to an extraordinarily bad RSAB decision, and some=20 > potential other happenings (i.e. not RSAB only), i.e. something that=20 > exposes deep structural problems, such as the happenings that led to th= e=20 > current redesign process, the IAB should take the lead and see what=20 > needs doing. (of course we hope that our current work will reduce the=20 > chances of such a need) >=20 > To replace the members of the RSAB may not be easy, as many of them=20 > participate ex officio. >=20 > Regards, =C2=A0 Martin. >=20 >=20 >> 2. The co-chairs for the RFCWG should be appointed by the IAB and the=20 IETF Chair (respectively). >> 3. Appeals of chair decisions go to the IAB, and then to ISOC per 202= 6 6.5.3. >> >> If this is the proposal, are there people who disagree with it? >> >> Eliot >> >> >>> On 11 May 2021, at 23:30, Eric Rescorla wrote: >>> >>> >>> >>> On Tue, May 11, 2021 at 2:17 PM Brian E Carpenter > wrote: >>> On 12-May-21 08:32, Eric Rescorla wrote: >>>> Hi folks, >>>> >>>> Please feel free to tell me if we closed on this and I missed it, bu= t >>>> I don't think we've quite figured out how to handle complaints about= >>>> process failures in either the RSAB or the RSWG. In the IETF, as we >>>> all know, you can appeal to the AD or the IESG, and the IAB if you >>>> don't like the answer for the IESG. >>>> >>>> I think I'm persuaded by the argument from Joel and (I think) MT tha= t >>>> the recourse for the RSAB is to complain to the stream management >>>> bodies (i.e., the IESG and IAB) and have the representatives replace= d, >>>> rather than have a formal appeal. However, I think we need some >>>> mechanism for dealing with process failures in the RSWG. This is >>>> somewhat complicated by the proposed chair structure where the >>>> two chairs are appointed by different groups. However, if we take >>>> Lars's proposal for the IETF Chair and the IAB, then I think the >>>> IAB should be the appeal body (this is consistent with other suggest= ions >>>> for them having ultimate responsibity). This also works well b/c >>>> the IETF Chair is on the IAB. >>> >>> I agree (and I've said this on a couple of threads already). Given >>> the precedent in the IETF appeals structure, and remembering where >>> our money comes from, I think we should also ask the ISOC Board to >>> be the final appeal stop, with the same scope as for the IETF case. >>> Cut, paste and patch from >>> https://www.rfc-editor.org/rfc/rfc2026.html#section-6.5.3 >>> >>> I concur. >>> >>> -Ekr >>> >>> Brian >>> >>> -- >>> 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 From nobody Wed May 12 15:33:19 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626183A1785 for ; Wed, 12 May 2021 15:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=AnqdGy3p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=sxTE66xP Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eve9UDY3vTeg for ; Wed, 12 May 2021 15:33:05 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1756E3A16D2 for ; Wed, 12 May 2021 15:29:19 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 44C5A5C0134 for ; Wed, 12 May 2021 18:29:17 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 12 May 2021 18:29:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=OqOjB qR1CnwH0N1cqNGVvt8HsBPH+icq2P3Vk6hLz0Q=; b=AnqdGy3pet8hKjzNgeLZZ h5EXBh7zFUx7m+hZh09VqLVNiSsv2AxXQSsEhi3XfsN4IJvyF4JN3/fVT1mTEHXG YKiOi2qnopetBcbK9HGvvErSsVaG37XR/9AdE0QSX7P1qkoYv8v6ZiuA1T8jJHRG t2VWJEYb9viDfaQ96WP8YM+N8wKpbJb/zUIkrGJWxsOCAUlxLEWeXCqChIoef7aQ 8MzHjaC8J3X9BAtiTE0fwFxHoBqqabPzKiqyAUoVh9VUO0Bi+GnRpF8ruoNJKql9 uXVzVe7riRHeBdY+aC/G+E23D9DzTnuJePlCVK7mWaxV6lVDT/VXftG6NiVhyurH Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=OqOjBqR1CnwH0N1cqNGVvt8HsBPH+icq2P3Vk6hLz 0Q=; b=sxTE66xP4Ag2PU8S+tPOIhJcjQ8MJkWlrcFomzMum3U0QZun24iNkw4Ly mQejj2Y/ZaQ4RmM1Jx/kq607NFFsiGHLck+cUE/rxcXXHW15rE/tCHN2Lu8SRn0V J62pNJxMbO88e94iQnYyDtWzNznFk0D6Xh62LFpkc4WhM9esgZg+/AXE5+vVqVm6 O2eHTIRLq88mqoBMZTrYqlKmeP8kYShG+rnzw1atK187UOgSzky2b3QQXYQgtOhl rUXiDygLrzFQPpmF6ybCHsaod+Y0fdkSvOdbj5dBvOilbLM/LiBtjpEO2Adac0mf kZDJ1/HVV7V68Ha1PgbFwTX7IpDDA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdehfedgtdelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtgfesth hqredtreerjeenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecuggftrfgrthhtvghrnhepgfejueduieffledtge elheejvdettdejudduhefggeefgfekgfeuieetgefftddtnecuvehluhhsthgvrhfuihii vgeptdenucfrrghrrghmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnh gvth X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id CCAF54E00C8; Wed, 12 May 2021 18:29:16 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> Date: Thu, 13 May 2021 08:28:58 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 May 2021 22:33:18 -0000 On Wed, May 12, 2021, at 18:10, Martin J. D=C3=BCrst wrote: > That was not my understanding, and I hope it wasn't Brian's. The=20 > recourse to an "average" bad RSAB decision should be an appeal, simila= r=20 > to e.g. a bad decision by an IETF WG chair or an AD,... I think that the word we use here (appeal or not) is not as important as= the process. My understanding was that the proposed response to a (believed) bad RSAB= decision was to ask the appointing bod(y/ies) to discipline the individ= ual(s) involved and request that they either change their position or be= replaced. That is not *strictly* an appeal in the sense we understand,= but it would have many of the same characteristics. =20 > To replace the members of the RSAB may not be easy, as many of them=20= > participate ex officio. This is true of ISE and (maybe) the IRTF chair, but they each have their= own replacement path if it comes to that. The others would be replacea= ble should it come to that. From nobody Wed May 12 16:10: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 B14AF3A18E5 for ; Wed, 12 May 2021 16:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=XRyO/P/D; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DnYZtxDl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIK7qd44ZaEC for ; Wed, 12 May 2021 16:10:24 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF3D93A18DD for ; Wed, 12 May 2021 16:10:24 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E45F85C00F0 for ; Wed, 12 May 2021 19:10:20 -0400 (EDT) Received: from imap10 ([10.202.2.60]) by compute1.internal (MEProxy); Wed, 12 May 2021 19:10:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=Z9Kpxc4Gm6aZOWRAjo1WwXBLkqpyPhx ly1VHyHZ0upQ=; b=XRyO/P/DCVH1fU41KmKa7vWuwOHtEtW/Z+5Q1TS25P38Oxk kZ/+PAXd7YZk1KR0Oisd3r4/NfNhtpR6oSQOgVwiUDbXc3TiQPpFWs8mcX4tfRjB VLIL/EZkIIAmQvwmpiQefqE4pegzXPByZVt83hPwF3Z1TtGx9EpbssmpMbAh15Gn mS7ku8a5Vvswkxbqa4tZYV0mXVUkG5fc/HnkVxku7e97RBR/Ma2B80OFCwq5OZkr T2pPPyeNH+tkfzlR3j8pn30x+jnI4WQS8PYXjsAru0N8ip4/nPTQAfF4D1YkAwcu iuvrRPMSOUP5QxH0MKbW4ruzqkr1EAUz4jtqLtQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=Z9Kpxc 4Gm6aZOWRAjo1WwXBLkqpyPhxly1VHyHZ0upQ=; b=DnYZtxDlmUt1SQpzDCo8yB CCfuUeS+ftMk43DJjxqSZ8KIRju0JnOWbKC4eqkA344HpyLOcuCG3ypL2AYHpa8R rBDXGGcHi9W64q49FrWAE48kKFPn3XozDnoelQvVJ+xih2DS9dBIJd6fnjpFhi15 qHT0tI7MRG9mARVCxFSXeiGiRuQmDlYqRL+HE+fVJwup1+QRyLe+/PR/plq8VPv4 NYvjdlOhgkrzu902n3DIBSu+Z2o1slQ7qw6HFIzuA2NPZojoIf0DMxwNJt3ogAtZ 2sPSYpUXJhDcN7gjBR7HFJ6/957pAkj66W7C7mu/6jbbzR7DP+xGnvgFWODci/gw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdehfedgudejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeehfeetudduudehtdekhf dvhfetleffudejgeejffehffevkeduiefgueevkeefleenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 8B1CA4E00C8; Wed, 12 May 2021 19:10:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.5.0-alpha0-448-gae190416c7-fm-20210505.004-gae190416 Mime-Version: 1.0 Message-Id: <31494092-d573-4ffd-bbb6-c5e3287bc554@www.fastmail.com> In-Reply-To: References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> Date: Thu, 13 May 2021 09:10:02 +1000 From: "Martin Thomson" To: rfced-future@iab.org Content-Type: text/plain Archived-At: Subject: Re: [Rfced-future] =?utf-8?q?Issue_63=3A_Who_has_final_authority_to_?= =?utf-8?q?make_changes=3F_=28Re=3A_Issue_50_=5Bdraft-saintandre-rfced-mod?= =?utf-8?q?el_-_msj2=5D=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, 12 May 2021 23:10:30 -0000 On Wed, May 12, 2021, at 17:43, Eliot Lear wrote: > I want to add one cautionary note about appeals and use of the IAB. > The IAB *as a body* may be conflicted on an issue. Suppose the > proposal is to eliminate the IAB stream, and require them to use the > IETF stream, and the chairs simply refuse to call for consensus on the > question. What happens? I think that we need to understand the constraints on what appeals are assessed on. I think we need to constrain the IAB in terms of what power they can exercise in an appeal. My position would be that appeals need to focus on whether the process was followed. That's a narrow scope. In that case, if the decision to eliminate the IAB stream followed the process, the IAB might not have grounds to uphold an appeal. From nobody Wed May 12 20:29: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 EC9DD3A225C for ; Wed, 12 May 2021 20:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIsGXOj1wBPw for ; Wed, 12 May 2021 20:29:38 -0700 (PDT) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E953A225A for ; Wed, 12 May 2021 20:29:37 -0700 (PDT) Received: by mail-pf1-x431.google.com with SMTP id i13so20562972pfu.2 for ; Wed, 12 May 2021 20:29:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=vhdCI3c9eKapXGs+v9atxq74/xwnOaYwW6Q/rziFjQQ=; b=KEdssNQMYuDh97o4cDWet+2MDujt7yFrqqAa4NEtkvN0bANyQN6Z/hCKp6uhKCwTxc E8CZ6oMMiFX0H16qo2ufPD9tDs9x/3Eq8OsLtV8O+J2uSzOUU539wWf9+oTwPALqI+pp sMB0iWhkQRrXZBykrWSzrfM6useInJBM5NTQ3n9jbUWmEDtiQPBXSJa+yRcDI3RiXrHu ZZp4eiEfVfL0MnVFRJIXYc/FrzBD8ulT1FBJn3ffFSszjKs0AIa2dOTTFFzWrl2SVLIt qIdurXHAqrwrdkGDWKMRu68MUJ7djkAnmS2hzyj+VlJ4G3kir8JqqjBGwxz8jKES5jZI qs6w== 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=vhdCI3c9eKapXGs+v9atxq74/xwnOaYwW6Q/rziFjQQ=; b=MZ22nARvHxc5NjIZwlr1h8lFKkPNHv0mySov8RSPCBnYTP6LJVfZGUwQA1w4rq1VyO NNnO9BEFl3BfRWU5BmjWY+FfR0WHvmyX7XZe1rvgoEvmlP14qjqHm3G4e3689EsaD+bS RJc+MLntf+hGFZ7jt/LUwaJvJsSdtW4vziJO73Veg/0iL2PjYo2yCw8QWMt4RLnSpLDD 9G4v5OmLwGMk5fP8z1eyoIvybkSJ468DcatgtPcwL9IvUIfqZ1GjD6+jmzkh3wc7iaIO b6vY5AwFMcygc+ErjRf0GzRmg/MY4j7mTrlgj4l9uVou3fcfR26WRBwp4hBAD1u9d7EK GTEg== X-Gm-Message-State: AOAM533/W97jACH5biT1Gbzt7FF7lOMMERE1fLd7GPkQBkBbEIPrLADm E3l3DkL/Uvxgje9xr+rYwWQ= X-Google-Smtp-Source: ABdhPJxz/BONsQmF/YrpLzVBUprrg0KEsXTuTS8ng2kPzoHruW7EG3lChmr05g/gVTyg65+QAlbhAg== X-Received: by 2002:a17:90a:7f81:: with SMTP id m1mr2131702pjl.23.1620876576371; Wed, 12 May 2021 20:29:36 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id 15sm953714pjf.57.2021.05.12.20.29.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 May 2021 20:29:35 -0700 (PDT) To: Wes Hardaker , Eliot Lear Cc: rfced-future@iab.org, =?UTF-8?Q?Martin_J=2e_D=c3=bcrst?= , "Joel M. Halpern" , Michael StJohns References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> From: Brian E Carpenter Message-ID: <98086d08-81ef-3eba-6f21-7992fd524be7@gmail.com> Date: Thu, 13 May 2021 15:29:30 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 May 2021 03:29:43 -0000 On 13-May-21 04:26, Wes Hardaker wrote: > Maybe one way to tackle this problem: >=20 > What are the characteristics of an appeals body you (collectively) want= ?=C2=A0 That might help narrow the search down or at least allow for bett= er comparisons when no body fits all the checkboxes. I think the problem case is where the IAB itself is in dispute with the R= SAB, so clearly cannot adjudicate. That is a case where the appeal would = need to be handled directly by the ISOC Board, isn't it? Brian >=20 > On Wed, May 12, 2021 at 12:44 AM Eliot Lear > wrote: >=20 > Hi Brian and Martin, >=20 > I want to add one cautionary note about appeals and use of the IAB.= =C2=A0 The IAB *as a body*=C2=A0may be conflicted on an issue.=C2=A0 Supp= ose the proposal is to eliminate the IAB stream, and require them to use = the IETF stream, and the chairs simply refuse to call for consensus on th= e question.=C2=A0 What happens? >=20 > Eliot >=20 >> On 12 May 2021, at 03:08, Brian E Carpenter > wrote: >> >> On 12-May-21 12:15, Martin J. D=C3=BCrst wrote: >>> Hello Brian, everybody, >>> >>> On 2021-05-11 11:09, Brian E Carpenter wrote: >>>> On 10-May-21 21:16, Eliot Lear wrote: >>>>> Hi Joel, >>>>> >>>>> Yes, this is a good point, but I want to restate it slightly, a= nd I=E2=80=99ve opened Issue 63 to do so: >>>>> >>>>> Who has the final authority to make evolve the processes that w= e are defining here?=C2=A0 Can we enumerate possible answers? >>>>> >>>>> =C2=A0=C2=A0* Does it continue to rest with the IAB? >>>> >>>> As I said on the thread for another issue, my current feeling is= >>>> that the IAB should be in the appeal chain after the RSAB. (If w= e >>>> continue that line of thought, we'd ask the ISOC Board to be the= >>>> end point, as it is for IETF process issues.) >>> >>> I think we have to be careful to distinguish the following two th= ings: >>> >>> 1) The formal appeal process. For this, I'm okay with what >>> =C2=A0 =C2=A0Brian proposes just above. Some other arrangements m= ay also be okay. >>> >>> 2) The authority to evolve the process. This may rest (formally) >>> =C2=A0 =C2=A0with the same organizations as the appeal process, o= r it may not. >>> =C2=A0 =C2=A0If we look at the current instance (i.e. the work of=20 this >> very >>> =C2=A0 =C2=A0group), I'm not exactly sure about how it worked, bu= t I don't >>> =C2=A0 =C2=A0remember any kind of appeal being involved. What I r= emember >>> =C2=A0 =C2=A0is having a lot of community discussion/pressure inv= olved, based >>> =C2=A0 =C2=A0on a general feeling that something went wrong. >> >> I'd say: the same authority for both. Otherwise we could be accuse= d >> of manufacturing bureaucracy. >> >> The past situation effectively gave final authority to the IAB and=20 the >> only recourse was a recall. I don't think anybody was happy with t= hat. >> >> =C2=A0=C2=A0=C2=A0Brian >> >>> >>> Regards, =C2=A0 Martin. >>> >>>>> =C2=A0=C2=A0* Could it rest with the community as represented b= y the RFCWG and >> confirmed by the RSAB? >>>> >>>> As long as there is an appeal chain as above. >>>> >>>>> =C2=A0=C2=A0* Is it the IETF community as confirmed by the IESG= ? >>>> >>>> No. It's wider than the IETF. That's why this will not >>>> be an IETF WG. From a higher level viewpoint, I think >>>> the RSAB is a peer group of the IESG and the IRSG. >>>> (It's almost as if we were setting up the RFC Task Force.) >>>> >>>>> =C2=A0=C2=A0* Is it the IETF community as confirmed by the IAB?= >>>> >>>> Ditto. >>>> >>>>> =C2=A0=C2=A0* Other? >>>> >>>> I don't think so. >>>> >>>> Regards >>>> =C2=A0=C2=A0=C2=A0Brian >>>> >>>> >>>>> >>>>> Eliot >>>>> >>>>>> On 10 May 2021, at 05:55, Joel M. Halpern >> wrote: >>>>>> >>>>>> Buried in the below is an interesting and important point. >>>>>> Suppose that we work out a process, agree to it, and try it.=C2= =A0 And >>>> it fails. =C2=A0=C2=A0(For any number of possible meanings of "f= ail".) >>>>>> >>>>>> Who has the authority to decide something needs to be done?=C2= =A0 Who has the authority to make something happen.=C2=A0 Under current r= ules, whether we like them or not, the authority for what we are doing co= mes from >>>> the IAB, via the RFCs that say it is the IABs job. >>>>>> >>>>>> It seems to me that Mike's point below about who has the ultim= ate authority is important.=C2=A0 And at that point, I don't think "the c= ommunity" is a viable answer. >>>>>> >>>>>> Yours, >>>>>> Joel >>>>>> >>>>>> PS: I am sorry you do not like my usage of strawman Mike.=C2=A0=20 But the premise for your objection is sufficiently vague that I do not kn= ow what else to call it.=C2=A0 If the only purpose of your description wa= s to >> get to the "who has authority to fix things if they are broken", t= hen as above, I agree that is an important question.=C2=A0 I was complete= ly unable to get to that issue from what you wrote.=C2=A0 In particular, = I could >> not connect that with your conclusion that the RSAB should be empo= wered to bypass the RSWG. >>>>>> >>>>>> On 5/9/2021 10:58 PM, Michael StJohns wrote: >>>>>>> On 5/9/2021 10:32 PM, Joel M. Halpern wrote: >>>>>>>> Mike, your analysis seems a bit flawed. >>>>>>>> Yes, the IESG approved those documents after community consu= ltation, >>>> on the basis that the community had agreed. >>>>>>>> And yes, that judgement was made by the IESG. >>>>>>>> >>>>>>>> On the other hand, if the community members had thought the = IESG conclusion was wrong, that was appealable to the IAB. >>>>>>> The way I've always understood it is that process can be appe= aled with some possibility of a reversal, but a decision that follows the=20 process, no matter whether some community members thought it was the wron= g decision, is unlikely to be reversed. >>>>>>>> >>>>>>>> That is very different from declaring that the RSAB can publ= ish a document without community approval. >>>>>>> See above.=C2=A0 AFAICT, there were folks in opposition to th= e Nomcom >>>> decision, but the community was heard.=C2=A0 I'm not saying that=20 the community will not be heard, but I'm saying - similar to what the IES= G did >> with documenting the Nomcom decision - that individual members or = even a small subsection of the community should not have a veto over the = publication of documents that the RSAB believes necessary for the operati= on of the >>>> streams. >>>>>>>> And given the structure that is proposed, there seems much l= ess reason for any process that bypasses the working group. >>>>>>> WGs by their nature are self-selected and generally consist o= f a small percentage of the overall community with strong opinions about = the topics covered by the WG (with the active participants being even som= ewhat smaller).=C2=A0=C2=A0 When the scope is small enough - e.g. DNSOP f= or example - the community affected by the decisions will mostly mirror t= he community represented by the WG.=C2=A0 When the scope is large enough = - e.g. >> Nomcom, RFC ED, etc - you have a hard time ensuring that the opini= ons of the WG represent the best results for the community of the whole.=C2= =A0 In >>>> the Nomcom case, we were able to gather a reasonably large group=20 of people (in the form of a WG)=C2=A0 of diverse views for a sufficient t= ime (multiple times) to spend a very large amount of effort to craft and = recraft the Nomcom process.=C2=A0 But that differs from this proposed WG = in that the various Nomcom related WGs had well defined target outputs an= d a need >>>> to complete in a reasonably short period of time (by IETF standa= rds at >>>>>>> least). >>>>>>> I'm trying to avoid us replacing the RSOC with the RSWG - but=20 I can't >>>> see how we can get enough diversity of interest for an indefinit= e period of time to ensure that the RSWG continues to operate as a useful=20 source of community involvement rather than a place for a small number of=20 self-selected folk to have an overly large continuing impact on a process=20 that's >>>> absolutely critical to the community's success.=C2=A0 Nor has an= y one been willing to address that specific point. >>>>>>> Peter did say: >>>>>>>> Yes, there are failure modes where the WG is inactive (in wh= ich case >>>>>>>> we'd need to inject more energy) or unable to reach consensu= s (in which >>>>>>>> case we'd need to work harder to do so), >>>>>>> But I would ask who the "we'd" is in the above?=C2=A0 e.g. on= ce this group dissolves in favor of the new structure, who has the respon= sibility >>>> of fixing things if the WG structure fails or devolves?=C2=A0 Ar= e we going to be back here in 4 years?=C2=A0 Or does the RSAB go on its m= erry way and do what it needs to do?=C2=A0 If not, who reconstitutes the = next RFCED-Futures group given that we will have taken the IAB out of the=20 picture?=C2=A0 The RSAB? >>>>>>>> >>>>>>>> I think everyone knows that I do not like the current approa= ch. But I can live with it.=C2=A0 And it seems to be the approach the com= munity >> wants. >>>>>>> Or at least the 1/2 dozen or so people who have argued for th= e approach - not sure that's the community. >>>>>>>> Creating strawmen as obstacles does not seem helpful. >>>>>>> And thanks for that denigrating comment.=C2=A0=C2=A0 You migh= t not like what I'm saying nor agree with them, but calling them strawmen=20 implies >>>> that they are there simply to providing a blocking issue and the= y have >> no >>>> basis in reality and that I'm doing that simply to screw up what=20 process there is. >>>>>>> Mike >>>>>>>> >>>>>>>> Yours, >>>>>>>> Joel >>>>>>>> >>>>>>>> On 5/9/2021 9:41 PM, Michael StJohns wrote: >>>>>>>>> On 5/9/2021 8:39 PM, Brian E Carpenter wrote: >>>>>>>>>> IMHO, the IAB can and does do this but the IESG doesn't. T= ake RFC1984 >>>>>>>>>> as a canonical example: the IESG approved it as a BCP by s= tandard >>>>>>>>>> process including IETF Last Call. The IAB co-signed it too= , on its >>>>>>>>>> own authority. >>>>>>>>>> >>>>>>>>>> =C2=A0=C2=A0=C2=A0 Brian >>>>>>>>> >>>>>>>>> A much better (and much more recent) counter example is dra= ft-iesg-nomcom-eligibility-2020 which became RFC 8788. >>>>>>>>> >>>>>>>>> This was an IESG initiated document that solicited communit= y input, >>>> but ultimately was published on the IESG's dime with their sole = interpretation of community consensus. >>>>>>>>> >>>>>>>>> RFC6360.=C2=A0 RFC3932.=C2=A0 And RFC 3710 (the IESG charte= r). >>>>>>>>> >>>>>>>>> The point is that the IESG does this too.=C2=A0 And its not=20 a bad >> thing, especially when we have 100 different opinions and we need = a final >> answer sooner rather than later. >>>>>>>>> >>>>>>>>> I don't expect the RSAB to do a lot of internally originate= d documents, but I do expect there will be cases where a decision has to = be made, >>>> and that there will be some immediacy necessary. >>>>>>>>> >>>>>>>>> Later, Mike >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>> >>>>>> --=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 >=20 >=20 >=20 > --=20 > Wes Hardaker > USC/ISI From nobody Wed May 12 20:36: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 88A553A229D for ; Wed, 12 May 2021 20:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iv7Y-5bBPmqV for ; Wed, 12 May 2021 20:36:23 -0700 (PDT) Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40D3F3A229A for ; Wed, 12 May 2021 20:36:23 -0700 (PDT) Received: by mail-pg1-x530.google.com with SMTP id s22so20027458pgk.6 for ; Wed, 12 May 2021 20:36:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=3bT67nwNp7/A93XD8DzjreC1DYqUMwIIOtK2h8mi6Rs=; b=FHT4f4UXTAcR2hyy41nC3UlvU3iVlCWks5g5rVb9mGHn5OjKog6EjMK/Xg9zmSsb1I rEm7CHBxJefZUh2NAav6P+rWEi/eKALJoB0il4u8QWHcNMREQXhMca8UuPJAU4OyM29d K6L8jFLlWKIOMYawC2/Dgjx7W2itjhQZWok0s+0dJjuM4yh0oBI0HXguOonHbGIEIAvO CpJodLoZdCw5isPBAtKLOYeM2GMCrt1FAVtNYrzfcJxEsYLt8XWRL0LgCrwYGf/IyMOn 915vLpK5zYX2libOdXofmkD0mnKRQDK60vZqHOQo6/AbikoD44EcbUPQy4WOyBwdn8yx faaw== 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=3bT67nwNp7/A93XD8DzjreC1DYqUMwIIOtK2h8mi6Rs=; b=iC46sMwI2IIPRwM6a7l1f+I06v4gYZMWNc2C2h0mzRaFXi1i9sO3rt0G5+kZ2Liwa+ z1YoslHG+Tzh/hWDLv4YuHe+gOrdWRrPbz9V9BMp8unQQzS7ActkOVDZfNB5xX75Grnp rbU0yy2zsyxIIqdlUZiKvwGUvtOEvUt58FXc4JaiL7wH/4L7R0g058G8FYXUUSn53IBz kwk6tg9LducXCHpJmufOfMhRkqSlF/MsCCpS3by4RSvZd7e9PrQ6LL505MosOuyR894m uxbT0s8aqMPrDK615q9TpkJ6xG4+0uHdammeGRQUHjEadQGzmqk3iWzlJP9spaI7FxXd w1/g== X-Gm-Message-State: AOAM533NAMtTCqFtyTDYomNH6xbB/XlFQIh0KhgKKLpVjNFATSWWCWt1 bzOLtir4CgG8e4DSDCADIdxiT5C4UmC4iA== X-Google-Smtp-Source: ABdhPJzLSsMUi2j1EjMQCKowd4E++TVdOFc75ClgFD/d/Cc5zDjz47XV7sGkTtO3oYtqUC7Vd3+Wyw== X-Received: by 2002:a17:90b:3852:: with SMTP id nl18mr2192360pjb.119.1620876981914; Wed, 12 May 2021 20:36:21 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id n6sm1012725pgq.72.2021.05.12.20.36.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 May 2021 20:36:21 -0700 (PDT) To: Martin Thomson , rfced-future@iab.org References: <97D20413-BE23-436D-9337-7AE362E40D6E@cisco.com> <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> <31494092-d573-4ffd-bbb6-c5e3287bc554@www.fastmail.com> From: Brian E Carpenter Message-ID: Date: Thu, 13 May 2021 15:36:16 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <31494092-d573-4ffd-bbb6-c5e3287bc554@www.fastmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 May 2021 03:36:26 -0000 On 13-May-21 11:10, Martin Thomson wrote: > On Wed, May 12, 2021, at 17:43, Eliot Lear wrote: >> I want to add one cautionary note about appeals and use of the IAB. >> The IAB *as a body* may be conflicted on an issue. Suppose the >> proposal is to eliminate the IAB stream, and require them to use the >> IETF stream, and the chairs simply refuse to call for consensus on the >> question. What happens? > > I think that we need to understand the constraints on what appeals are assessed on. I think we need to constrain the IAB in terms of what power they can exercise in an appeal. Yes. > My position would be that appeals need to focus on whether the process was followed. That's a narrow scope. Or that the RSAB has exceeded its mandate? But basically, I agree, and that is analogous to RFC2026 section 6.5.2. > In that case, if the decision to eliminate the IAB stream followed the process, the IAB might not have grounds to uphold an appeal. In any case, that would be a conflict of interest, so the IAB should be bypassed. Brian From nobody Wed May 12 22:25: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 0D1FD3A272E for ; Wed, 12 May 2021 22:25:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.59 X-Spam-Level: X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 52kkfG5e7ijN for ; Wed, 12 May 2021 22:25:23 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A251A3A272C for ; Wed, 12 May 2021 22:25:22 -0700 (PDT) Received: from xse454.mail2web.com ([66.113.197.200] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from ) id 1lh3qT-000wcO-F0 for rfced-future@iab.org; Thu, 13 May 2021 07:25:15 +0200 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 4Fgg8l0ngZz2GVg for ; Wed, 12 May 2021 22:25:11 -0700 (PDT) Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1lh3qQ-0006Fn-VY for rfced-future@iab.org; Wed, 12 May 2021 22:25:11 -0700 Received: (qmail 9775 invoked from network); 13 May 2021 05:25:10 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 13 May 2021 05:25:09 -0000 To: rfced-future@iab.org References: <1ea0527f-f555-34fb-c29a-b639a6a149e9@gmail.com> <1b040f66-d54e-cdd6-1b0f-ac1c53d460b8@nthpermutation.com> <7e4bc501-d41e-4c3d-8048-75d025a86e9b@www.fastmail.com> <1902b7b1-3c41-02e2-03b2-eb2249ee01c7@mozilla.com> <0dc9407e-5c2b-c5eb-aefe-28a720f42101@joelhalpern.com> <43fc57e1-716f-f511-dc79-3e409677d507@nthpermutation.com> <865D5DE4-93F7-4F90-87D9-116ECF1D856B@cisco.com> <33ef1b85-97da-f4e1-0d13-a61cd80546c2@it.aoyama.ac.jp> <98086d08-81ef-3eba-6f21-7992fd524be7@gmail.com> From: Christian Huitema Message-ID: <561cced8-c208-b696-9ad8-cd02a0cc1108@huitema.net> Date: Wed, 12 May 2021 19:25:08 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <98086d08-81ef-3eba-6f21-7992fd524be7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.200 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.197.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5yXEnUqtuiszqcStXlDoE9S53HEEk0VSrq03gtFxbC/KkGQ aQDjXl6Yli3uADV+qkJizSh2f1rWsE3ZhyRR3OEySxIRXVMlFuiz/acFNeeXtxN2fFxZWB9eYgpR BRu3UlDHMLIJYRi1cXH9Dbm+IxLVqUP2p1GBgb8PkO7npCoXenGFd932lfz+R/06O3Iy4akhy/LP m2rFgOGYwKKX1POmkVWClPVvbW5lVyQanRxw5hTHswbbB/ha+ZWrSAi8SkwqWAikMcSxTAWn8RCv ieGEqjG/gXZAaRh1X6LVetRf2ZYIiHqfCgG4wrA3w4/kQTYKxDHA9JN9J4k4XZq11JQkMemT4rxn nByU11Ftkqf3f/PF3GUV+KdBBqrnCX8j0Gi8Ksk+aedMfNWSnJswrtlNtZo3HPHi5Q+jjsF5dcBx ehWYzrkgsp4/Fysgb2cPV4IH0+lPwKr4i5mAANUcVraZYOaeuiH/yEdZH8S1+TgcJBOjh0vPxcQO jKKOrYIQYpwamUdylUIKhf3z2GAHxH7Iiihnln5nLwsYugixy853dgjI4WE+pjPnfrWRF8b8VMfW OvdZB8We2kfr4RzkOghGb3UQT3xbkHqpqmyCe4PiKVv0wNAmy0z4NCWU5AbBg6tDVPQ6fMev1BMP vQ9qu4cW0z6bhalFEM/pjPCQA+BAliVd3My7nBWddD1Gfr3eaYa3h1ESmlc3/lS5x7qxkdlaIp1W j3KmqiHZdu6/ZKKSU0P/7Mt02VKsomodmEPxBNVRXxKF5tPxTxfD0dMN+t5Z1iexsSqF5wqj1hzL iAkUndYq/lrmOIggGSbFQcaLnZSN9/YGRrhMRGhIOTxMW00yF8F1u0YDQf8cLP9taeSLFY0fPBnF 89BphpBNlUg+TzHwBTL1+6vDOMemz/4I88NDcmnEJ4r7C+SwLRamrhQTd3PrpJpP5ewAjeqkzRNl ucyd+NO2McmveAr4ch9F7rE89jihx+Za/cV70jOJzN2r4A== X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Rfced-future] Issue 63: Who has final authority to make changes? (Re: Issue 50 [draft-saintandre-rfced-model - msj2]) X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 13 May 2021 05:25:25 -0000 On 5/12/2021 5:29 PM, Brian E Carpenter wrote: > On 13-May-21 04:26, Wes Hardaker wrote: >> Maybe one way to tackle this problem: >> >> What are the characteristics of an appeals body you (collectively) wan= t?=C2=A0 That might help narrow the search down or at least allow for bet= ter comparisons when no body fits all the checkboxes. > I think the problem case is where the IAB itself is in dispute with the= RSAB, so clearly cannot adjudicate. That is a case where the appeal woul= d need to be handled directly by the ISOC Board, isn't it? I think it is always possible to manufacture extreme scenarios in which=20 any kind of conflict may arise. But this supposes a conflict between the = IAB and the stream managers of the IAB stream, IRTF stream, and IETF=20 stream. If it comes to that, something exceptional will have to be done. = Otherwise, having the IAB as the appeal body is just fine. -- Christian Huitema From nobody Thu May 13 04:04: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 3667C3A0945 for ; Thu, 13 May 2021 04:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.05 X-Spam-Level: X-Spam-Status: No, score=-1.05 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.846, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LUqsmOzvycHC for ; Thu, 13 May 2021 04:04:40 -0700 (PDT) Received: from mta7.iomartmail.com (mta7.iomartmail.com [62.128.193.157]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4DA13A0940 for ; Thu, 13 May 2021 04:04:38 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta7.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14DB4ZYC019576; Thu, 13 May 2021 12:04:35 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5366E22032; Thu, 13 May 2021 12:04:35 +0100 (BST) Received: from asmtp2.iomartmail.com (unknown [10.12.10.249]) by vs3.iomartmail.com (Postfix) with ESMTPS id 4846322046; Thu, 13 May 2021 12:04:35 +0100 (BST) Received: from LAPTOPK7AS653V (65.151.51.84.dyn.plus.net [84.51.151.65] (may be forged)) (authenticated bits=0) by asmtp2.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14DB4YZS026784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 13 May 2021 12:04:34 +0100 Reply-To: From: "Adrian Farrel" To: "'Martin Thomson'" , References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> In-Reply-To: Date: Thu, 13 May 2021 12:04:34 +0100 Organization: Old Dog Consulting Message-ID: <09a301d747e7$c2494c40$46dbe4c0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Content-Language: en-gb Thread-Index: AQHFqotqcEaTle1dfbHugNIVionfwQH+bPSzAi5E3fICEIpcfgLtcna5AT5bM3eqsTF/QA== X-Originating-IP: 84.51.151.65 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-26154.007 X-TM-AS-Result: No--5.382-10.0-31-10 X-imss-scan-details: No--5.382-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26154.007 X-TMASE-Result: 10--5.382200-10.000000 X-TMASE-MatchedRID: 6otD/cJAac3xIbpQ8BhdbMikxLAkSHclAajW+EL+laO2duf1KYOL/E4u QY89a+2+FRlxiF1eFJtEPW3jy3MEP/5OZuw9GE0v8eSmTJSmEv2lGCIMbr7g/qY3y6dPFN/1DRo QfvLsXSi+85UGmb9Mdt3s8j1C8j2F9+5WkBOeNwf0hv/rD7WVZJoiESsm3R0svT9/feR/0aXjAs u+V4KeavthQfg5F5CFl3Y0chXsnzkEpls8F6ktspU7Bltw5qVL9+PHtghP8GIgVZAf8m502K/RA F79ZqtvNghK9RDXtmRILii+i2grWTZQQocM3TDMKwi7MItzaY2S0Ed+8sr8mpsoi2XrUn/JjcFm PipjlBsMyrfP9j+C1SAHAopEd76v33wWzjr4hW2kWi4MISfkN38uwC203KcX0QXjjfV823CZrbM 1EaQWXg== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 11:04:44 -0000 I agree with Martin (put up more flags!). For those who are NomCom appointed, they are "replaceable" through = NomCom, recallable, and appealable for their actions. For those who are appointed in other ways, requests can be made to = discipline/replace them. Since the requests will be to NomCom appointed = people, failure to act will be appealable, etc. A -----Original Message----- From: Rfced-future On Behalf Of Martin = Thomson Sent: 12 May 2021 23:29 To: rfced-future@iab.org Subject: Re: [Rfced-future] Appeals, etc. On Wed, May 12, 2021, at 18:10, Martin J. D=C3=BCrst wrote: > That was not my understanding, and I hope it wasn't Brian's. The=20 > recourse to an "average" bad RSAB decision should be an appeal, = similar=20 > to e.g. a bad decision by an IETF WG chair or an AD,... I think that the word we use here (appeal or not) is not as important as = the process. My understanding was that the proposed response to a (believed) bad RSAB = decision was to ask the appointing bod(y/ies) to discipline the = individual(s) involved and request that they either change their = position or be replaced. That is not *strictly* an appeal in the sense = we understand, but it would have many of the same characteristics. =20 > To replace the members of the RSAB may not be easy, as many of them=20 > participate ex officio. This is true of ISE and (maybe) the IRTF chair, but they each have their = own replacement path if it comes to that. The others would be = replaceable should it come to that. --=20 Rfced-future mailing list Rfced-future@iab.org https://www.iab.org/mailman/listinfo/rfced-future From nobody Thu May 13 10:43:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F37C63A171F for ; Thu, 13 May 2021 10:43:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpN1GjX0q5Uc for ; Thu, 13 May 2021 10:43:28 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 817043A171E for ; Thu, 13 May 2021 10:43:28 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id c20so15307604qkm.3 for ; Thu, 13 May 2021 10:43:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=irnwTWnuqS/Q27OxhD9dDLJPBQAZcMO3CzneTkc0MMY=; b=snmUX1I67bbqHRpnqPHoy5U1BmPXh/K29/6Hu43w5GxLFYbSgdlXQxXURaNL09k45a SZ5Pre5BqBkYWA6dl69f183jiNOa1dyxeeQbNDytH4x3r9Xykf0tJISDJ4ey7hpZ+Jc4 nzDLQtyMWoIbMCTmbjj0PI6z02OlzU1EOg4m3p7EPsoHUDmJpxMXDL70YAwmTZ6UwfmY bJoDXnkJ9n18isRpbB94j+FfaJLizcBtTSg6WJUvqMiFG+khRmJg6I2MLIdq1xoN5cRj MJmEYq//7UHSltVwASGI0wbPYlJWcr0YNLbjiyC1B4x60oImbBbO0YM9POA0OeSnNM1m NhUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=irnwTWnuqS/Q27OxhD9dDLJPBQAZcMO3CzneTkc0MMY=; b=bhL3hh114yv8No4q2szbAR/vL+P4/6eEjXYikUnNgLgH8MEZx7vEGntpsyVPPwD6Pa 4PGXbsIp1MtadVBnFhlB9F5AJY9mCu8xcu0x+upMsDSv38ldnZyU+anx+z0ev1mlQuRs jiADS8Jbpc8srihpOOYumWGSppeCQH7j9KxYRcZp7Vf8gejOVYWSGoi2XvD9wuT663Sx xUBdI9bPMOz3BzExhxCyHjPvTq7PYvuDv7O4ohpzK6wyg4sZGqVjqeyYe5U0679lshei VlkFilH/9yp4AUS+/z5bgf+NCfQH3eiPx0Hv2Zo/scKJZ3Qifd3SktxR8HUrh4msE+Un gPKg== X-Gm-Message-State: AOAM531WoTA5EiA0A6DLuvrNCdYqVmuPfOiypl91aVy9vZnNeiZvhFKO WPky6McKr3jrrw5Q7WtAn1BdRCuEMehCBmjB X-Google-Smtp-Source: ABdhPJwh9a4Yj58bQodx6zRze9WHBhyw2BG5DlGvAihvKNTjUMe+VK3S995umJhSGslofuK0+3mqmA== X-Received: by 2002:ae9:f30a:: with SMTP id p10mr39791890qkg.53.1620927805958; Thu, 13 May 2021 10:43:25 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id y12sm2851280qkf.5.2021.05.13.10.43.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 May 2021 10:43:25 -0700 (PDT) To: rfced-future@iab.org References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> <09a301d747e7$c2494c40$46dbe4c0$@olddog.co.uk> From: Michael StJohns Message-ID: <95dd5c3a-b620-16ae-e34b-fcc220603abb@nthpermutation.com> Date: Thu, 13 May 2021 13:43:22 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <09a301d747e7$c2494c40$46dbe4c0$@olddog.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 17:43:33 -0000 Tagging here because this is the last in the chain so far: Let's say the RSWG says YES (for some document), and the RSAB says NO, the RSWG (actually it has to be a person, not the RSWG) appeals to the IAB and the IAB says YES. Can the RSAB now appeal to the ISOC board? They are not just the deciders, but unlike the IESG, they have an actual interest in the proceedings.  If they can't appeal, why not? Let's drop the IAB from the chain.  It makes little sense to have them there especially given that directly or indirectly they are responsible for 3 of the 4 ex officio members which I would think would lead to all manner of conflicts of interest and a need for at least some recusals. Later, Mike On 5/13/2021 7:04 AM, Adrian Farrel wrote: > I agree with Martin (put up more flags!). > > For those who are NomCom appointed, they are "replaceable" through NomCom, recallable, and appealable for their actions. > > For those who are appointed in other ways, requests can be made to discipline/replace them. Since the requests will be to NomCom appointed people, failure to act will be appealable, etc. I don't believe that failure to remove someone (or for that matter the act of appointing someone) comes under the list of appealable actions.  If it had, I would have probably opened an appeal against the IAB for not removing the RSOC a while back. Just saying.   As I said elsewhere, you can appeal the process, not the result.  If the process is followed, but you don't like the result, then ....    In any event, I think this would be a Bad Idea (tm). Yes, you can recall someone - but if the IAB declines to remove you, the IRTF chair for not replacing the IRTF stream manager or its own member, do you recall the entire body? *sigh* > > A > > -----Original Message----- > From: Rfced-future On Behalf Of Martin Thomson > Sent: 12 May 2021 23:29 > To: rfced-future@iab.org > Subject: Re: [Rfced-future] Appeals, etc. > > On Wed, May 12, 2021, at 18:10, Martin J. Dürst wrote: >> That was not my understanding, and I hope it wasn't Brian's. The >> recourse to an "average" bad RSAB decision should be an appeal, similar >> to e.g. a bad decision by an IETF WG chair or an AD,... > I think that the word we use here (appeal or not) is not as important as the process. > > My understanding was that the proposed response to a (believed) bad RSAB decision was to ask the appointing bod(y/ies) to discipline the individual(s) involved and request that they either change their position or be replaced. That is not *strictly* an appeal in the sense we understand, but it would have many of the same characteristics. > >> To replace the members of the RSAB may not be easy, as many of them >> participate ex officio. > This is true of ISE and (maybe) the IRTF chair, but they each have their own replacement path if it comes to that. The others would be replaceable should it come to that. > From nobody Thu May 13 12:44: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 871EF3A0E0F for ; Thu, 13 May 2021 12:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aUWE_yAO80lJ for ; Thu, 13 May 2021 12:44:36 -0700 (PDT) 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 4927C3A0DC1 for ; Thu, 13 May 2021 12:44:36 -0700 (PDT) Received: by mail-io1-xd36.google.com with SMTP id i7so18575775ioa.12 for ; Thu, 13 May 2021 12:44:36 -0700 (PDT) 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=hxihxTKxhblGKJHIqEEVmT+6p47Di7dJrejDMlqZQlM=; b=VQqYxRPwiMJNDJhjzBEdUSgvb/G+pxS6y0EbZbMy/I7HyCN12yo4D3y5Y9oVHw9g/u 6uZSzuXUYrhp/LhysiF+l03iJP4ImkSxKesh0bOkhRF/n4hw/uOgHY0ds1dZj6KI87qy kwyM5ImwqV6hMnZyPOKUO83BT54YOdP5dI6h1NaF6TvrQwVm6Rr8u686ROr4tpTXLHce hDzdaUqUbqF/jpSwNFBJvmX11G8nV6qY3Nao/tWhHU/aFEjBKluUtROcGUsaO88x4yPU pJzxOfaUQN8lWtYVk87OOkwS/58Fa2S+8Z8X4U9PlOjAyc1exQ2OUou1muMFCdM6RczI kv1w== 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=hxihxTKxhblGKJHIqEEVmT+6p47Di7dJrejDMlqZQlM=; b=G8jewqBUCsi+8b3dvB1oWZnPq1nFRdiWgPyYIwmYvB2ATTQGI3b6I4Td3sfzVJjLHL 2KWDDcrmwh4rOTqNF/Z50kDLzVo9uu5njfm4TUspFnOVYQqgJt1TXRpkkX1u3zkU5qXC 3jrzphAG5vmupLruYccvi0v21FAYxSLgp8XlpS0ogTd31duw6ZQmGxLpyGGIeIMka9An zU7uEQxMRZWj34TN5X+OK+8677JrHVE4VhKeStuvD4HlSQ8D26oDRJG4482ymjg8JR5F L3iNC5FIz7IExTB5nrj843M059kZNQJ1mFYvaN5bTybRN1tGhLO88eszw9EZDpb7EzQu 1gNg== X-Gm-Message-State: AOAM532Ixn+YXRd83+5HKcmGKEHv4+E+mQOwWgytzsYJ5PKZOhmJNVx3 mYxQcU93rVogvsFeYGb11UDhxEC2+BUFB6cXcVxOZQ== X-Google-Smtp-Source: ABdhPJwb0hSx+HincdnHE7ly3f4cZGHrucQDi3k+IGoKXDhwP4L0QF7BdBTN9WdVqnM1C4t/U6iijkCXbbxzWbuJXM8= X-Received: by 2002:a5d:8b85:: with SMTP id p5mr5225217iol.43.1620935075118; Thu, 13 May 2021 12:44:35 -0700 (PDT) MIME-Version: 1.0 References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> <09a301d747e7$c2494c40$46dbe4c0$@olddog.co.uk> <95dd5c3a-b620-16ae-e34b-fcc220603abb@nthpermutation.com> In-Reply-To: <95dd5c3a-b620-16ae-e34b-fcc220603abb@nthpermutation.com> From: Eric Rescorla Date: Thu, 13 May 2021 12:43:59 -0700 Message-ID: To: Michael StJohns Cc: rfced-future@iab.org Content-Type: multipart/alternative; boundary="0000000000005b578d05c23b5bda" Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 19:44:42 -0000 --0000000000005b578d05c23b5bda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, May 13, 2021 at 10:43 AM Michael StJohns wrote: > Tagging here because this is the last in the chain so far: > > Let's say the RSWG says YES (for some document), and the RSAB says NO, > the RSWG (actually it has to be a person, not the RSWG) appeals to the > IAB and the IAB says YES. Can the RSAB now appeal to the ISOC board? > Well, we should probably first establish how appeals work. For instance, ca= n the IAB approve a document or can they just send it back to the RSAB for reconsideration with some instruction about following the process? As an analogy, the IAB cannot approve documents on appeal. Let's drop the IAB from the chain. It makes little sense to have them > there especially given that directly or indirectly they are responsible > for 3 of the 4 ex officio members which I would think would lead to all > manner of conflicts of interest and a need for at least some recusals. > I don't think this is the right answer. The most likely case (as now) is that they have 1/4 members on the IAB (the IESG Chair), so this seems manageable= , especially as the alternative is having the ISOC board handle first level appeals, which seems not amazing given how far detached they are from the main work of the RFC Series. -Ekr Later, Mike > > > On 5/13/2021 7:04 AM, Adrian Farrel wrote: > > I agree with Martin (put up more flags!). > > > > For those who are NomCom appointed, they are "replaceable" through > NomCom, recallable, and appealable for their actions. > > > > For those who are appointed in other ways, requests can be made to > discipline/replace them. Since the requests will be to NomCom appointed > people, failure to act will be appealable, etc. > > I don't believe that failure to remove someone (or for that matter the > act of appointing someone) comes under the list of appealable actions. > If it had, I would have probably opened an appeal against the IAB for > not removing the RSOC a while back. Just saying. As I said elsewhere, > you can appeal the process, not the result. If the process is followed, > but you don't like the result, then .... In any event, I think this > would be a Bad Idea (tm). > > Yes, you can recall someone - but if the IAB declines to remove you, the > IRTF chair for not replacing the IRTF stream manager or its own member, > do you recall the entire body? > > *sigh* > > > > > > > A > > > > -----Original Message----- > > From: Rfced-future On Behalf Of Martin > Thomson > > Sent: 12 May 2021 23:29 > > To: rfced-future@iab.org > > Subject: Re: [Rfced-future] Appeals, etc. > > > > On Wed, May 12, 2021, at 18:10, Martin J. D=C3=BCrst wrote: > >> That was not my understanding, and I hope it wasn't Brian's. The > >> recourse to an "average" bad RSAB decision should be an appeal, simila= r > >> to e.g. a bad decision by an IETF WG chair or an AD,... > > I think that the word we use here (appeal or not) is not as important a= s > the process. > > > > My understanding was that the proposed response to a (believed) bad RSA= B > decision was to ask the appointing bod(y/ies) to discipline the > individual(s) involved and request that they either change their position > or be replaced. That is not *strictly* an appeal in the sense we > understand, but it would have many of the same characteristics. > > > >> To replace the members of the RSAB may not be easy, as many of them > >> participate ex officio. > > This is true of ISE and (maybe) the IRTF chair, but they each have thei= r > own replacement path if it comes to that. The others would be replaceabl= e > should it come to that. > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > --0000000000005b578d05c23b5bda Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, May 13, 2021 at 10:43 AM Mich= ael StJohns <msj@nthpermutatio= n.com> wrote:
Tagging here because this is the last in the chain so far:

Let's say the RSWG says YES (for some document), and the RSAB says NO, =
the RSWG (actually it has to be a person, not the RSWG) appeals to the
IAB and the IAB says YES. Can the RSAB now appeal to the ISOC board?

Well, we should probably first establish how= appeals work. For instance, can
the IAB approve a document or ca= n they just send it back to the RSAB for
reconsideration with som= e instruction about following the process? As an
analogy, th= e IAB cannot approve documents on appeal.


Let's drop the IAB from the chain.=C2=A0 It makes little sense to have = them
there especially given that directly or indirectly they are responsible for 3 of the 4 ex officio members which I would think would lead to all manner of conflicts of interest and a need for at least some recusals.
<= /blockquote>

I don't think this is the right answer.= The most likely case (as now) is that
they have 1/4 members on t= he IAB (the IESG Chair), so this seems manageable,
especially as = the alternative is having the ISOC board handle first level appeals,
<= div>which seems not amazing given how far detached they are from the main
work of the RFC Series.

-Ekr

Later, Mike


On 5/13/2021 7:04 AM, Adrian Farrel wrote:
> I agree with Martin (put up more flags!).
>
> For those who are NomCom appointed, they are "replaceable" t= hrough NomCom, recallable, and appealable for their actions.
>
> For those who are appointed in other ways, requests can be made to dis= cipline/replace them. Since the requests will be to NomCom appointed people= , failure to act will be appealable, etc.

I don't believe that failure to remove someone (or for that matter the =
act of appointing someone) comes under the list of appealable actions.=C2= =A0
If it had, I would have probably opened an appeal against the IAB for
not removing the RSOC a while back. Just saying.=C2=A0=C2=A0 As I said else= where,
you can appeal the process, not the result.=C2=A0 If the process is followe= d,
but you don't like the result, then ....=C2=A0=C2=A0=C2=A0 In any event= , I think this
would be a Bad Idea (tm).

Yes, you can recall someone - but if the IAB declines to remove you, the IRTF chair for not replacing the IRTF stream manager or its own member, do you recall the entire body?

*sigh*



>
> A
>
> -----Original Message-----
> From: Rfced-future <rfced-future-bounces@iab.org> On Behalf Of Martin= Thomson
> Sent: 12 May 2021 23:29
> To: rfced-fu= ture@iab.org
> Subject: Re: [Rfced-future] Appeals, etc.
>
> On Wed, May 12, 2021, at 18:10, Martin J. D=C3=BCrst wrote:
>> That was not my understanding, and I hope it wasn't Brian'= s. The
>> recourse to an "average" bad RSAB decision should be an = appeal, similar
>> to e.g. a bad decision by an IETF WG chair or an AD,...
> I think that the word we use here (appeal or not) is not as important = as the process.
>
> My understanding was that the proposed response to a (believed) bad RS= AB decision was to ask the appointing bod(y/ies) to discipline the individu= al(s) involved and request that they either change their position or be rep= laced.=C2=A0 That is not *strictly* an appeal in the sense we understand, b= ut it would have many of the same characteristics.
>=C2=A0 =C2=A0
>> To replace the members of the RSAB may not be easy, as many of the= m
>> participate ex officio.
> This is true of ISE and (maybe) the IRTF chair, but they each have the= ir own replacement path if it comes to that.=C2=A0 The others would be repl= aceable should it come to that.
>

--
Rfced-future mailing list
Rfced-future@iab.= org
https://www.iab.org/mailman/listinfo/rfced-future
--0000000000005b578d05c23b5bda-- From nobody Thu May 13 13:40: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 663363A1100 for ; Thu, 13 May 2021 13:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7v_Aq-pSWs-i for ; Thu, 13 May 2021 13:39:56 -0700 (PDT) Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D83CB3A10F2 for ; Thu, 13 May 2021 13:39:56 -0700 (PDT) Received: by mail-pl1-x62b.google.com with SMTP id 69so10399111plc.5 for ; Thu, 13 May 2021 13:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5onVTDygscLdwcM4fvBC+qEj6ftXRuDMYiSMfS9RkGc=; b=YTIUeUYclX0QYhDE0sRbHvilI1xmm4tPtGXw1LoqsOMF5brpHBq95yGJBHg0HB5wvN Pem0J4J2UzeEpsw9WGI0wgAmBem48a7DWYGgLNATx+TSRhYIqevVQ3KeVq+8nyMvyjbM T/17DE2qZxznAvbUyRHrRo8Eg52WXRVLrXt3wMywNew+0CrxolrwiDKCA648iypCBdVK 2FEXFI84P8gzQ5e0EsBGo5Zxsn9Bom/broa3lZ/FBzGuV8pUl8XjH6Rrlf5GGChWwEdd 1O2y01J1kw5pqR4A/JmYwthcb1rmzEKYrZ9ULUykviW1p5F478deTEy9xZ/FvhWxtLAY KEiw== 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=5onVTDygscLdwcM4fvBC+qEj6ftXRuDMYiSMfS9RkGc=; b=E9tEZutwT5uX8Q9DLCHLq0a1wCZQFpe4XjaqAcFr3G2YNB2dhJtLHt5QEvTY1fcQAm xD7s4L5pW5PFrJkRKhQRNgMP7N0L1EBZtzW8beCTflDTO456JrWr2YkSyaqeV9ApfCXh K4eKMGHrs4zWNbKAfhWG+9Pyd+T056DC/3oiY50No5DwyX2ZM2Aql8x5fR+h51UbELjZ Zkb+C871AxdmKS12OHl8Akz1OjOnS+zgqLtI6RDTH61ZCFtSd5IriYh61K1WGXWKEj6K JWPwja8v/rfbeYulQCGmE63B1TibkJz9urbrjd/XqMvb199r7MSpJdvBIgOEqYJ0y2OP OseA== X-Gm-Message-State: AOAM533qIR6PJFPcZ/nzEoYSO/W8kprBk44iLVyrCohhzGrJ4OW2pTER GVaBnypLp4od043NeYAG8tdesDBH3NQspg== X-Google-Smtp-Source: ABdhPJyPnNK7YuTjQMEzec+qkAzcZqrDApNUerj1fiCzm/tYnhWZZRqIZ9d+2cVnZNXgkD5E/YHukg== X-Received: by 2002:a17:902:7201:b029:ef:74be:294d with SMTP id ba1-20020a1709027201b02900ef74be294dmr12583026plb.71.1620938394910; Thu, 13 May 2021 13:39:54 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id u12sm2566450pfh.122.2021.05.13.13.39.53 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 13 May 2021 13:39:54 -0700 (PDT) To: rfced-future@iab.org References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> <09a301d747e7$c2494c40$46dbe4c0$@olddog.co.uk> <95dd5c3a-b620-16ae-e34b-fcc220603abb@nthpermutation.com> From: Brian E Carpenter Message-ID: <80c86220-7ac1-81f4-2e8e-47d42d4f0beb@gmail.com> Date: Fri, 14 May 2021 08:39:51 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 20:40:02 -0000 On 14-May-21 07:43, Eric Rescorla wrote: >=20 >=20 > On Thu, May 13, 2021 at 10:43 AM Michael StJohns > wrote: >=20 > Tagging here because this is the last in the chain so far: >=20 > Let's say the RSWG says YES (for some document), and the RSAB says = NO, > the RSWG (actually it has to be a person, not the RSWG) appeals to = the > IAB and the IAB says YES. Can the RSAB now appeal to the ISOC board= ? >=20 >=20 > Well, we should probably first establish how appeals work. For instance= , can > the IAB approve a document or can they just send it back to the RSAB fo= r > reconsideration with some instruction about following the process? As a= n > analogy, the IAB cannot approve documents on appeal. >=20 >=20 > Let's drop the IAB from the chain.=C2=A0 It makes little sense to h= ave them > there especially given that directly or indirectly they are respons= ible > for 3 of the 4 ex officio members which I would think would lead to=20 all > manner of conflicts of interest and a need for at least some recusa= ls. >=20 >=20 > I don't think this is the right answer. The most likely case (as now) i= s that > they have 1/4 members on the IAB (the IESG Chair), so this seems manage= able, > especially as the alternative is having the ISOC board handle first lev= el appeals, > which seems not amazing given how far detached they are from the main > work of the RFC Series. I agree with Ekr. The IAB is big enough that a few recusals don't matter.=20 Also, I regard it as highly likely that the ISOC Board will agree to be the cou= rt of final resort but rather unlikely that they would agree to be the primary court. Brian >=20 > -Ekr >=20 > Later, Mike >=20 >=20 > On 5/13/2021 7:04 AM, Adrian Farrel wrote: > > I agree with Martin (put up more flags!). > > > > For those who are NomCom appointed, they are "replaceable" throug= h NomCom, recallable, and appealable for their actions. > > > > For those who are appointed in other ways, requests can be made t= o discipline/replace them. Since the requests will be to NomCom appointed=20 people, failure to act will be appealable, etc. >=20 > I don't believe that failure to remove someone (or for that matter = the > act of appointing someone) comes under the list of appealable actio= ns.=C2=A0 > If it had, I would have probably opened an appeal against the IAB f= or > not removing the RSOC a while back. Just saying.=C2=A0=C2=A0 As I s= aid elsewhere, > you can appeal the process, not the result.=C2=A0 If the process is=20 followed, > but you don't like the result, then ....=C2=A0=C2=A0=C2=A0 In any e= vent, I think this > would be a Bad Idea (tm). >=20 > Yes, you can recall someone - but if the IAB declines to remove you= , the > IRTF chair for not replacing the IRTF stream manager or its own mem= ber, > do you recall the entire body? >=20 > *sigh* >=20 >=20 >=20 > > > > A > > > > -----Original Message----- > > From: Rfced-future > On Behalf Of Martin Thomson > > Sent: 12 May 2021 23:29 > > To: rfced-future@iab.org > > Subject: Re: [Rfced-future] Appeals, etc. > > > > On Wed, May 12, 2021, at 18:10, Martin J. D=C3=BCrst wrote: > >> That was not my understanding, and I hope it wasn't Brian's. The= > >> recourse to an "average" bad RSAB decision should be an appeal, = similar > >> to e.g. a bad decision by an IETF WG chair or an AD,... > > I think that the word we use here (appeal or not) is not as impor= tant as the process. > > > > My understanding was that the proposed response to a (believed) b= ad RSAB decision was to ask the appointing bod(y/ies) to discipline the i= ndividual(s) involved and request that they either change their position = or be replaced.=C2=A0 That is not *strictly* an appeal in the sense we un= derstand, but it would have many of the same characteristics. > >=C2=A0 =C2=A0 > >> To replace the members of the RSAB may not be easy, as many of t= hem > >> participate ex officio. > > This is true of ISE and (maybe) the IRTF chair, but they each hav= e their own replacement path if it comes to that.=C2=A0 The others would = be replaceable should it come to that. > > >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future >=20 >=20 From nobody Thu May 13 14:44: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 60A303A1537 for ; Thu, 13 May 2021 14:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 YuZwv6kVHFH5 for ; Thu, 13 May 2021 14:44:34 -0700 (PDT) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7FF53A1534 for ; Thu, 13 May 2021 14:44:33 -0700 (PDT) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1lhJ8C-000Lfm-8b; Thu, 13 May 2021 17:44:32 -0400 Date: Thu, 13 May 2021 17:44:25 -0400 From: John C Klensin To: Brian E Carpenter , rfced-future@iab.org Message-ID: <31530E54F51220CD1993817C@PSB> In-Reply-To: <80c86220-7ac1-81f4-2e8e-47d42d4f0beb@gmail.com> References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> <09a301d747e7$c2494c40$46dbe4c0$@olddog.co.uk> <95dd5c3a-b620-16ae-e34b-fcc220603abb@nthpermutation.com> <80c86220-7ac1-81f4-2e8e-47d42d4f0beb@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] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 May 2021 21:44:37 -0000 --On Friday, May 14, 2021 08:39 +1200 Brian E Carpenter wrote: >> I don't think this is the right answer. The most likely case >> (as now) is that they have 1/4 members on the IAB (the IESG >> Chair), so this seems manageable, especially as the >> alternative is having the ISOC board handle first level >> appeals, which seems not amazing given how far detached they >> are from the main work of the RFC Series. > > I agree with Ekr. The IAB is big enough that a few recusals > don't matter. Also, > I regard it as highly likely that the ISOC Board will agree to > be the court of final resort but rather unlikely that they > would agree to be the primary court. In addition, the idea of the ISOC Board as the final step in an appeals process arose at a time when ISOC and the IETF were very tightly bound today, when ISOC's man goal and function was providing a legal home for the IETF (and, btw, the IETF was far less into making rules to try to cover every detail). As the two bodies have evolved along different paths over the years, that has become less true: ISOC has many functions and activities that do not involve the IETF (or just barely do) and, with the establishment of the LLC, at least one reason for the direct connection no longer exists. The ISOC BoT has been successful as the final appeal point (and then under only one condition) because we have never, to my knowledge, actually asked them to exercise that authority. Given that appeals to them are allowed only when there are claims the procedures --not an individual decision consistent with those procedures-- and that, at least as I read RFC 2026 (again, we have no actual experience), they can rewrite the procedures themselves if they conclude they insufficient to protect openness and fairness, I think I can safely predict that, should there be such an appeal tomorrow and was followed by a finding of unfairness and either a procedural rewrite or a demand for one, there would be a meltdown on a scale that would make the one that brought this Program into being loot like a minor aberration. Probably it is safe to make them the point of final appeal if we are relying on the experience of the last quarter century and assume that they will never be called upon. But, if we assume appeals in this case, appeals that might include more substance-specific issues rather than ones of whether procedures match broader principles, then we are expanding the risk that they would be called upon. Be careful what you wish for. best, john From nobody Fri May 14 10:47:43 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A745C3A3A72 for ; Fri, 14 May 2021 10:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, 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 S2p35o2q9DAu for ; Fri, 14 May 2021 10:47:35 -0700 (PDT) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 AC02F3A3A6F for ; Fri, 14 May 2021 10:47:35 -0700 (PDT) Received: by mail-qk1-x72c.google.com with SMTP id i67so29484640qkc.4 for ; Fri, 14 May 2021 10:47:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=Nc1aVbo76C7xro+Z5FOCTo7GhAeX8bBXFoFSU/UKAps=; b=tJGDRsMtFPQWZma4icYvTsni6Ur30G1Pra7ZZUDo+K4mfnfDsxxCIGequqIq8gigOu yIRafIa0CicviGqT/pu5zYDL1hrfEdyQmucKrgyRDbrV6T2HeQPtiBS+4esJx17mHAA3 5LOMvDtIF8wwwMFqvvKAlEJqBOwBcKPBQ9fkwlRlbp1DpwOYzzH6bV0HEmmoQyTuy3hH E3ClXRlrNzg44U8raFcACIA/EcCeaFLuIu87K85XexjfSiZmWtzKg1vZbtmBZxX5gWmz s8yYbYkXj4QJ/jrLkcBVl1l2AjTAZaxdHw6yJPszofS9Fb1DuH/ZcOxy0Bz2pb7FV/bz lBPg== 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=Nc1aVbo76C7xro+Z5FOCTo7GhAeX8bBXFoFSU/UKAps=; b=hOJFmh8qWPWAB5Vj0EVP5Mm2+7YIWJjgoD8CxtKnP4pVWBkCaj59iL/VD0OAu8+FfC Vf4e/t4Ph8QPjK+uCa9yr9bZEygpBHv/zriwPSOR6wUcu0PZyQX/4iiMClmpRY3Q07+C S0TGulXvgQBmIjSnQg4nmjjEDPrKPHq1hkySKqWI0EN6cRs8Grh2neYhHlqnk1RkPE6V RQ3WNxOs1Vpjpt62Tm0bs0Y7ZXcZaxsPUiASjsDDzMx3DfVxhYg5cTtLxY8SOCGbgI18 hHuigN4h7XggQeEWOLEA6trhiDdOqYYwJ2DUUOuykirByvRyIwz0FFfJ9S4AOi5x4bCc KVPA== X-Gm-Message-State: AOAM5327Qcv0q5CFY7YGCChAxDu8d0PnLLwIh305g409boLZCMvdrOzy e/2DyFx8yLPfgKW2UePz55eSZdefrpAHdHM1 X-Google-Smtp-Source: ABdhPJx+ZMv8A2TPfDq7BTlLEH2czAVEvBQSUoLe3E5s7sQ0BPlMf0kCweC7QETAdFvafxDxFgg5Kw== X-Received: by 2002:a37:c444:: with SMTP id h4mr41071359qkm.206.1621014453327; Fri, 14 May 2021 10:47:33 -0700 (PDT) Received: from [192.168.1.23] (pool-108-51-200-187.washdc.fios.verizon.net. [108.51.200.187]) by smtp.gmail.com with ESMTPSA id l65sm5196648qke.7.2021.05.14.10.47.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 May 2021 10:47:32 -0700 (PDT) To: Eric Rescorla Cc: rfced-future@iab.org References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> <09a301d747e7$c2494c40$46dbe4c0$@olddog.co.uk> <95dd5c3a-b620-16ae-e34b-fcc220603abb@nthpermutation.com> From: Michael StJohns Message-ID: <4eda8350-95c2-fa44-93b0-a8f2ed5a8539@nthpermutation.com> Date: Fri, 14 May 2021 13:47:30 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BC6D95D0872E53CB3A5FD86C" Content-Language: en-US Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 May 2021 17:47:41 -0000 This is a multi-part message in MIME format. --------------BC6D95D0872E53CB3A5FD86C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 5/13/2021 3:43 PM, Eric Rescorla wrote: > > > On Thu, May 13, 2021 at 10:43 AM Michael StJohns > > wrote: > > Tagging here because this is the last in the chain so far: > > Let's say the RSWG says YES (for some document), and the RSAB says > NO, > the RSWG (actually it has to be a person, not the RSWG) appeals to > the > IAB and the IAB says YES. Can the RSAB now appeal to the ISOC board? > > > Well, we should probably first establish how appeals work. For > instance, can > the IAB approve a document or can they just send it back to the RSAB for > reconsideration with some instruction about following the process? As an > analogy, the IAB cannot approve documents on appeal. Following that thread, we should stop talking about who and work on what might be appealed before getting back to who.  I'm not actually sure there is any reason to have an appeal chain for that matter. > > > Let's drop the IAB from the chain.  It makes little sense to have > them > there especially given that directly or indirectly they are > responsible > for 3 of the 4 ex officio members which I would think would lead > to all > manner of conflicts of interest and a need for at least some recusals. > > > I don't think this is the right answer. The most likely case (as now) > is that > they have 1/4 members on the IAB (the IESG Chair), so this seems > manageable, > especially as the alternative is having the ISOC board handle first > level appeals, > which seems not amazing given how far detached they are from the main > work of the RFC Series. See above, and previous notes in this chain.  Specifically, the discussion point that the appointing body bring a "misbehaving RSAB member" to heel as a first step before an appeal.  AIRC, appointments and replacements are a whole-IAB activity, which I would think might then be in conflict with being an impartial decider for whatever appeal follows. So - if the IAB is in the appeal chain, then that's the only lever it should have on a particular decision, not both being in the appeals chain and able to twiddle with the RSAB members. Mike > > -Ekr > > Later, Mike > > > On 5/13/2021 7:04 AM, Adrian Farrel wrote: > > I agree with Martin (put up more flags!). > > > > For those who are NomCom appointed, they are "replaceable" > through NomCom, recallable, and appealable for their actions. > > > > For those who are appointed in other ways, requests can be made > to discipline/replace them. Since the requests will be to NomCom > appointed people, failure to act will be appealable, etc. > > I don't believe that failure to remove someone (or for that matter > the > act of appointing someone) comes under the list of appealable > actions. > If it had, I would have probably opened an appeal against the IAB for > not removing the RSOC a while back. Just saying.   As I said > elsewhere, > you can appeal the process, not the result.  If the process is > followed, > but you don't like the result, then ....    In any event, I think > this > would be a Bad Idea (tm). > > Yes, you can recall someone - but if the IAB declines to remove > you, the > IRTF chair for not replacing the IRTF stream manager or its own > member, > do you recall the entire body? > > *sigh* > > > > > > > A > > > > -----Original Message----- > > From: Rfced-future > On Behalf Of Martin Thomson > > Sent: 12 May 2021 23:29 > > To: rfced-future@iab.org > > Subject: Re: [Rfced-future] Appeals, etc. > > > > On Wed, May 12, 2021, at 18:10, Martin J. Dürst wrote: > >> That was not my understanding, and I hope it wasn't Brian's. The > >> recourse to an "average" bad RSAB decision should be an appeal, > similar > >> to e.g. a bad decision by an IETF WG chair or an AD,... > > I think that the word we use here (appeal or not) is not as > important as the process. > > > > My understanding was that the proposed response to a (believed) > bad RSAB decision was to ask the appointing bod(y/ies) to > discipline the individual(s) involved and request that they either > change their position or be replaced.  That is not *strictly* an > appeal in the sense we understand, but it would have many of the > same characteristics. > > > >> To replace the members of the RSAB may not be easy, as many of them > >> participate ex officio. > > This is true of ISE and (maybe) the IRTF chair, but they each > have their own replacement path if it comes to that.  The others > would be replaceable should it come to that. > > > > -- > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future > > --------------BC6D95D0872E53CB3A5FD86C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 5/13/2021 3:43 PM, Eric Rescorla wrote:


On Thu, May 13, 2021 at 10:43 AM Michael StJohns <msj@nthpermutation.com> wrote:
Tagging here because this is the last in the chain so far:

Let's say the RSWG says YES (for some document), and the RSAB says NO,
the RSWG (actually it has to be a person, not the RSWG) appeals to the
IAB and the IAB says YES. Can the RSAB now appeal to the ISOC board?

Well, we should probably first establish how appeals work. For instance, can
the IAB approve a document or can they just send it back to the RSAB for
reconsideration with some instruction about following the process? As an
analogy, the IAB cannot approve documents on appeal.


Following that thread, we should stop talking about who and work on what might be appealed before getting back to who.  I'm not actually sure there is any reason to have an appeal chain for that matter.



Let's drop the IAB from the chain.  It makes little sense to have them
there especially given that directly or indirectly they are responsible
for 3 of the 4 ex officio members which I would think would lead to all
manner of conflicts of interest and a need for at least some recusals.

I don't think this is the right answer. The most likely case (as now) is that
they have 1/4 members on the IAB (the IESG Chair), so this seems manageable,
especially as the alternative is having the ISOC board handle first level appeals,
which seems not amazing given how far detached they are from the main
work of the RFC Series.


See above, and previous notes in this chain.  Specifically, the discussion point that the appointing body bring a "misbehaving RSAB member" to heel as a first step before an appeal.  AIRC, appointments and replacements are a whole-IAB activity, which I would think might then be in conflict with being an impartial decider for whatever appeal follows.

So - if the IAB is in the appeal chain, then that's the only lever it should have on a particular decision, not both being in the appeals chain and able to twiddle with the RSAB members.

Mike


-Ekr

Later, Mike


On 5/13/2021 7:04 AM, Adrian Farrel wrote:
> I agree with Martin (put up more flags!).
>
> For those who are NomCom appointed, they are "replaceable" through NomCom, recallable, and appealable for their actions.
>
> For those who are appointed in other ways, requests can be made to discipline/replace them. Since the requests will be to NomCom appointed people, failure to act will be appealable, etc.

I don't believe that failure to remove someone (or for that matter the
act of appointing someone) comes under the list of appealable actions. 
If it had, I would have probably opened an appeal against the IAB for
not removing the RSOC a while back. Just saying.   As I said elsewhere,
you can appeal the process, not the result.  If the process is followed,
but you don't like the result, then ....    In any event, I think this
would be a Bad Idea (tm).

Yes, you can recall someone - but if the IAB declines to remove you, the
IRTF chair for not replacing the IRTF stream manager or its own member,
do you recall the entire body?

*sigh*



>
> A
>
> -----Original Message-----
> From: Rfced-future <rfced-future-bounces@iab.org> On Behalf Of Martin Thomson
> Sent: 12 May 2021 23:29
> To: rfced-future@iab.org
> Subject: Re: [Rfced-future] Appeals, etc.
>
> On Wed, May 12, 2021, at 18:10, Martin J. Dürst wrote:
>> That was not my understanding, and I hope it wasn't Brian's. The
>> recourse to an "average" bad RSAB decision should be an appeal, similar
>> to e.g. a bad decision by an IETF WG chair or an AD,...
> I think that the word we use here (appeal or not) is not as important as the process.
>
> My understanding was that the proposed response to a (believed) bad RSAB decision was to ask the appointing bod(y/ies) to discipline the individual(s) involved and request that they either change their position or be replaced.  That is not *strictly* an appeal in the sense we understand, but it would have many of the same characteristics.
>   
>> To replace the members of the RSAB may not be easy, as many of them
>> participate ex officio.
> This is true of ISE and (maybe) the IRTF chair, but they each have their own replacement path if it comes to that.  The others would be replaceable should it come to that.
>

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


--------------BC6D95D0872E53CB3A5FD86C-- From nobody Fri May 14 21:29: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 3754C3A1644 for ; Fri, 14 May 2021 21:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sq3TOwio_xJT for ; Fri, 14 May 2021 21:28:58 -0700 (PDT) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (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 532833A1643 for ; Fri, 14 May 2021 21:28:58 -0700 (PDT) Received: by mail-pl1-x635.google.com with SMTP id s20so350821plr.13 for ; Fri, 14 May 2021 21:28:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=R4t/YkqXMKUE+X+U12AAdLLOhI5lOwkkF/72cRIJYsI=; b=VBR14mBLBSEZaqWEeml7NB/qYtA6458w0orsQrzA1QP2Q39RNEEDTo9uKXwrg+5sTe Ai35Krztd2Z2Utp2BSfdArB9L4ZZUIkTzTZ05w517sYdEko9yc8sR2yZU3VLVSakobZA L7HL3UeT5WWibPwkMBOHRdD2q6+GCqWCxOPIfZU1i2lvPBf0z/W9NdzzEt8xvbTRGJsg scfy7mutgxYsbUGk6r5ud7TF+X+YkLy7GJSCn/oItEsBhBzBr92CTYbS7bT+oJTSmecx Y2lBYnJaxNn6x+BgncKFt342w5n9SSN/T2YrSK9maufal3Pu60t+HcS0EruHv+fIvyu0 /hGQ== 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=R4t/YkqXMKUE+X+U12AAdLLOhI5lOwkkF/72cRIJYsI=; b=oC7ZcMM1gvMTDzt7njabOwHAgOv3l8rqPWW9tlgguS+7pbkTiaxWIMRoavXgHy/h+4 MCM8AQXGQyKbnJ2zZ3aRo0dcwV53CasPipGfU5BjcAQ593/DtZudwBPdSPN+u52393Oq RLdbW89P2rt4wGwQBfDxWJb8WkMpdk4dE8HP5/afetmW94uS2YD7OAGbjrVSFIK7qhIb CKFqIzDbiumj/tK7H/IyS/YHNqFIMJuVW4Ef5mHtu4eBHvAY3q1cEUjMhIlTAfY5pF54 gs9f4ZMfrlv8mvrUgtG8tuZ74AyzopN9Xk9Et0bUBjxNVMVQtAbOdlzTsDgFvXYttNV4 4fXg== X-Gm-Message-State: AOAM531+Y2OkCxdOR42m1v6JDAveQdZ5h/ont7E7XIYOkh5mt2asc+yp oTGe4e/1y/LhywcrJ5m3h7Kfrh+8oWiPAw== X-Google-Smtp-Source: ABdhPJxt99hAGBTrfdoOqJ8CkStqNN+6+9xg/UicgS+uUsIQc/jb+/9HMtWXrFQkHMVaZXCqTwYfQw== X-Received: by 2002:a17:90a:ca05:: with SMTP id x5mr23607893pjt.16.1621052937167; Fri, 14 May 2021 21:28:57 -0700 (PDT) Received: from ?IPv6:2406:e003:100d:901:80b2:5c79:2266:e431? ([2406:e003:100d:901:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id v2sm5264650pfv.97.2021.05.14.21.28.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 14 May 2021 21:28:56 -0700 (PDT) To: Michael StJohns , Eric Rescorla Cc: rfced-future@iab.org References: <462e2466-36f9-8dd2-b769-9cf81c5aa9e0@gmail.com> <406BCB24-47BC-4394-9675-B9BE3D775650@cisco.com> <09a301d747e7$c2494c40$46dbe4c0$@olddog.co.uk> <95dd5c3a-b620-16ae-e34b-fcc220603abb@nthpermutation.com> <4eda8350-95c2-fa44-93b0-a8f2ed5a8539@nthpermutation.com> From: Brian E Carpenter Message-ID: <11a95c29-e881-692e-09d8-447f9fcab6cf@gmail.com> Date: Sat, 15 May 2021 16:28:52 +1200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <4eda8350-95c2-fa44-93b0-a8f2ed5a8539@nthpermutation.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Rfced-future] Appeals, etc. X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: RFC Editor Future Development Program List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 May 2021 04:29:03 -0000 On 15-May-21 05:47, Michael StJohns wrote: > On 5/13/2021 3:43 PM, Eric Rescorla wrote: >> >> >> On Thu, May 13, 2021 at 10:43 AM Michael StJohns > wrote: >> >> Tagging here because this is the last in the chain so far: >> >> Let's say the RSWG says YES (for some document), and the RSAB says=20 NO, >> the RSWG (actually it has to be a person, not the RSWG) appeals to=20 the >> IAB and the IAB says YES. Can the RSAB now appeal to the ISOC boar= d? >> >> >> Well, we should probably first establish how appeals work. For instanc= e, can >> the IAB approve a document or can they just send it back to the RSAB f= or >> reconsideration with some instruction about following the process? As = an >> analogy, the IAB cannot approve documents on appeal. >=20 >=20 > Following that thread, we should stop talking about who and work on wha= t might be appealed before getting back to who.=C2=A0 I'm not actually su= re there is any reason to have an appeal chain for that matter. I'm sure we need checks and balances, and we have running code proof that=20 the recall mechanism is very hard to trigger and is definitely not for ev= eryday disputes. So it seems to me a given that we need an appeal mechani= sm that is much easier to use than a recall, even without knowing what th= e typical dispute might be about. IMHO we have text at https://datatracker.ietf.org/doc/html/rfc2026#sectio= n-6.5 that our document editor can adapt; it describes what sort of issue= s might arise at WG level, IESG level (~=3D RSAB level) and above. I thin= k the analogy is quite strong. Brian >=20 >> >> >> Let's drop the IAB from the chain.=C2=A0 It makes little sense to = have them >> there especially given that directly or indirectly they are respon= sible >> for 3 of the 4 ex officio members which I would think would lead t= o all >> manner of conflicts of interest and a need for at least some recus= als. >> >> >> I don't think this is the right answer. The most likely case (as now) = is that >> they have 1/4 members on the IAB (the IESG Chair), so this seems manag= eable, >> especially as the alternative is having the ISOC board handle first le= vel appeals, >> which seems not amazing given how far detached they are from the main >> work of the RFC Series. >=20 >=20 > See above, and previous notes in this chain.=C2=A0 Specifically, the di= scussion point that the appointing body bring a "misbehaving RSAB member"=20 to heel as a first step before an appeal.=C2=A0 AIRC, appointments and re= placements are a whole-IAB activity, which I would think might then be in=20 conflict with being an impartial decider for whatever appeal follows. >=20 > So - if the IAB is in the appeal chain, then that's the only lever it s= hould have on a particular decision, not both being in the appeals chain = and able to twiddle with the RSAB members. >=20 > Mike >=20 >> >> -Ekr >> >> Later, Mike >> >> >> On 5/13/2021 7:04 AM, Adrian Farrel wrote: >> > I agree with Martin (put up more flags!). >> > >> > For those who are NomCom appointed, they are "replaceable" throu= gh NomCom, recallable, and appealable for their actions. >> > >> > For those who are appointed in other ways, requests can be made = to discipline/replace them. Since the requests will be to NomCom appointe= d people, failure to act will be appealable, etc. >> >> I don't believe that failure to remove someone (or for that matter=20 the >> act of appointing someone) comes under the list of appealable acti= ons.=C2=A0 >> If it had, I would have probably opened an appeal against the IAB = for >> not removing the RSOC a while back. Just saying.=C2=A0=C2=A0 As I = said elsewhere, >> you can appeal the process, not the result.=C2=A0 If the process i= s followed, >> but you don't like the result, then ....=C2=A0=C2=A0=C2=A0 In any = event, I think this >> would be a Bad Idea (tm). >> >> Yes, you can recall someone - but if the IAB declines to remove yo= u, the >> IRTF chair for not replacing the IRTF stream manager or its own me= mber, >> do you recall the entire body? >> >> *sigh* >> >> >> >> > >> > A >> > >> > -----Original Message----- >> > From: Rfced-future > On Behalf Of Martin Thomson >> > Sent: 12 May 2021 23:29 >> > To: rfced-future@iab.org >> > Subject: Re: [Rfced-future] Appeals, etc. >> > >> > On Wed, May 12, 2021, at 18:10, Martin J. D=C3=BCrst wrote: >> >> That was not my understanding, and I hope it wasn't Brian's. Th= e >> >> recourse to an "average" bad RSAB decision should be an appeal,=20 similar >> >> to e.g. a bad decision by an IETF WG chair or an AD,... >> > I think that the word we use here (appeal or not) is not as impo= rtant as the process. >> > >> > My understanding was that the proposed response to a (believed) = bad RSAB decision was to ask the appointing bod(y/ies) to discipline the = individual(s) involved and request that they either change their position=20 or be replaced.=C2=A0 That is not *strictly* an appeal in the sense we un= derstand, but it would have many of the same characteristics. >> >=C2=A0 =C2=A0 >> >> To replace the members of the RSAB may not be easy, as many of = them >> >> participate ex officio. >> > This is true of ISE and (maybe) the IRTF chair, but they each ha= ve their own replacement path if it comes to that.=C2=A0 The others would=20 be replaceable should it come to that. >> > >> >> --=20 >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future >> >=20 >=20 From nobody Tue May 18 01:44:42 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7573A12D2 for ; Tue, 18 May 2021 01:44:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfUAJCjiYOX5 for ; Tue, 18 May 2021 01:44:35 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91F03A12D0 for ; Tue, 18 May 2021 01:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5105; q=dns/txt; s=iport; t=1621327474; x=1622537074; h=from:mime-version:subject:message-id:date:to; bh=+w146yfL8TPLbQRivIFIwCMiHEqnX1FwcbW5O0ombiQ=; b=U1RjIGmuTNmjcqTFSuRT8EyRJRw4tXa6Mea+CglHFxAH0lm4tYRcn10x CLCI02f7esGEgv6iG0Y1WwhBEVB8iOdonff9gnuzL/h8j5+zX74YOqiSZ 8OIPIql9VvThzP0kNj73VRIiTm+8XoTqNBS/ghBPkVuBG6/TXpYC+1oM5 o=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0A5AACYfaNglxbLJq1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?gQBAQsBgyFWAScShHiJBIhRJZRsiCgEBwEBAQoDAQExEAQBAYZGJjcGDgIEA?= =?us-ascii?q?QEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFUA2GRgQkWxoINgI/g?= =?us-ascii?q?yQBgmYhD5kkjhd6gTKBAYlaCgaBOgGBUoU0AYcegg2BFScMEIMdgmEEgiuCS?= =?us-ascii?q?jaCLQSBZQ9MBmRHECCBLBJtkVGMap0ogyCDS4FJmDEFI6U9tSwBhAsCBAYFA?= =?us-ascii?q?haBaiKBWzMaCBsVZQGCPz0SGQ6OOIhrhUs/A2cCBgEJAQEDCY0QAQE?= IronPort-HdrOrdr: A9a23:KOfhtK3ZsMmEeWlb8C7hZgqjBKEkLtp133Aq2lEZdPU1SKGlfq +V/cjzuSWftN9uYh8dcKG7VJVoKEm0nfVICOIqUotKMjOHhILRFvAA0WMnqAeQfhEXMYVmpM VdT5Q= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,309,1613433600"; d="asc'?scan'208,217";a="36103770" 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; 18 May 2021 08:44:32 +0000 Received: from smtpclient.apple ([10.61.144.50]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 14I8iVlt029415 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 May 2021 08:44:32 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_56F0399C-95FE-4BEA-9D59-7694AB8373B4"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: <5F7EBB6D-2D12-4CB3-9640-ABD91E94A2E3@cisco.com> Date: Tue, 18 May 2021 10:44:31 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.50, [10.61.144.50] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: [Rfced-future] Issue 6: Streams have content control X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 May 2021 08:44:40 -0000 --Apple-Mail=_56F0399C-95FE-4BEA-9D59-7694AB8373B4 Content-Type: multipart/alternative; boundary="Apple-Mail=_92A9E9B8-7C4A-4565-B7FE-7D4B4614A976" --Apple-Mail=_92A9E9B8-7C4A-4565-B7FE-7D4B4614A976 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Last summer we had agreed that this was to be the case. However, Martin = raised the following point as part of issue housecleaning on this: > Streams can have editorial policies of their own as long as they = aren't in conflict with those of the series. >=20 > That's different than what I understand by content control, which is = deciding what is published. Which I think we all agree remains, = provided that the content that a stream decides to publish is not in = conflict with editorial policies of the series as a whole. >=20 > I will note that the series itself has very loose editorial policies. = It doesn't even choose between British and American English. Tightening = those would be possible through the process we are designing. The = terminology debate is probably not where I would start, but it is one = possible option. Whatever the change though, the potential for conflict = between stream and series policies is a good example of a valid reason = that the RSAB might reject what the RSWG produces. First, do people agree with Martin on this? It=E2=80=99s a bit more = nuanced than what we had previously agreed. This begs two questions: What are the definitive editorial policies today? Are we thinking = https://www.rfc-editor.org/styleguide/? = Are we saying that the RPC makes the final call on whether a document is = consistent with whatever policies are in place? Thanks, Eliot --Apple-Mail=_92A9E9B8-7C4A-4565-B7FE-7D4B4614A976 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Last = summer we had agreed that this was to be the case.  However, Martin = raised the following point as part of issue housecleaning on this:

Streams can have editorial policies of their own as long as = they aren't in conflict with those of the series.

That's different than what I understand by content control, = which is deciding what is published.  Which I think we all agree = remains, provided that the content that a stream decides to publish is = not in conflict with editorial policies of the series as a whole.

I will note that the series itself has very = loose editorial policies.  It doesn't even choose between British = and American English.  Tightening those would be possible through = the process we are designing.  The terminology debate is probably = not where I would start, but it is one possible option.  Whatever = the change though, the potential for conflict between stream and series = policies is a good example of a valid reason that the RSAB might reject = what the RSWG produces.

First, do people agree with Martin on this?  It=E2=80=99s = a bit more nuanced than what we had previously agreed.

This begs two = questions:

  • What are the definitive editorial = policies today?  Are we thinking https://www.rfc-editor.org/styleguide/?
  • Are we saying that the RPC makes the final call on whether a = document is consistent with whatever policies are in = place?

Thanks,

Eliot
= --Apple-Mail=_92A9E9B8-7C4A-4565-B7FE-7D4B4614A976-- --Apple-Mail=_56F0399C-95FE-4BEA-9D59-7694AB8373B4 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCjfm8ACgkQh7ZrRtnS ejPzaAgAuMOm1IL/Vzdj29/Eo4whszIKagN5sSAvIo5hNihiCv/yfl2Yy/cHLAdG DFEL0eUV3QmdikMxK6h/dPmAv4UlFzVixrbtanUCTrFCFFEWhq+gSa+vpJrYTkhn w908imnIMp7dp98o/ihGsEN6QbePILSs7lOd5hnfA2LelKYwf16hCYDLwJc4Czps yS04zuIT0A5whfN9R9xeaEHQly8heAFVu74SmBcB0SPhhalgd8D9hMDkD3Q9XFC4 n8kGd15BpvYLEM5ViWC8HNqaFgssvlFb9mMaYHnASEVeFwdsgbkKsifUwDPfxrd6 XIxAj5ohBwki9mLCgZc5ywkZEiAjMA== =eEPU -----END PGP SIGNATURE----- --Apple-Mail=_56F0399C-95FE-4BEA-9D59-7694AB8373B4-- From nobody Tue May 18 01:57: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 436843A1386 for ; Tue, 18 May 2021 01:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0CLl4Cxc4ipI for ; Tue, 18 May 2021 01:57:33 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68FEC3A1383 for ; Tue, 18 May 2021 01:57:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5192; q=dns/txt; s=iport; t=1621328253; x=1622537853; h=from:mime-version:subject:message-id:date:to; bh=8PjKjZ/dB3EaGwQ9ZzV2/IUd4jB10wUwOJAwGmWyL+E=; b=TwVFGLfwIBeJVVTeDr4r3cO4cuaVdu1S2lVmiNFui7+chWo0NXQL4WYC dsGicX6IiqJXjfF6JIwfbWVwJ8bDUfe6rMezGKs+AEe3DiY/wuD2fBQaT 0WwdwYdMT4BfqprCTPiopERLtxLXIzchfvlB4SOouNrpJg1k/1MuXMD+T 0=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AcAADVgKNglxbLJq1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?QUBAQsBgSKCVQEnEoR4iQSIUYgvjGKGLIF8BAcBAQEKAwEBQQQBAYZGJjYHD?= =?us-ascii?q?gIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBBQBAQEBAQEBAWiFIwY0hm5FMAg2A?= =?us-ascii?q?j+DJAGDB5ktjhd6gTKBAYlXEIE6AYFShTQBhx6CDYEVJwwQgx2FEIJKNoItB?= =?us-ascii?q?IQhUXqfG4szkXWDIINLgUmYMQUjpT20TGABhAsCBAYFAhaBWwYrgVszGggbF?= =?us-ascii?q?WUBgj89EhkOhxeHIY42PwNnAgYBCQEBAwmNEAEB?= IronPort-HdrOrdr: A9a23:wSNxa6j3nF29qr7XnzqgwVsAkHBQXskji2hC6mlwRA09TyX4ra 2TdZsgtCMc5Ax6ZJhfo7690di7LU80nKQdieIs1NyZMzUO1lHJEGgb1/qA/9UlcBeOk9K0Es xbAspDNOE= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,309,1613433600"; d="asc'?scan'208,217";a="36043725" 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; 18 May 2021 08:57:31 +0000 Received: from smtpclient.apple ([10.61.144.50]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 14I8vTMa031765 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Tue, 18 May 2021 08:57:30 GMT From: Eliot Lear Content-Type: multipart/signed; boundary="Apple-Mail=_F8814185-3359-4A46-8D55-6F113F06F804"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Message-Id: <637251CE-DFC9-4109-8A4F-C34A0CDF844F@cisco.com> Date: Tue, 18 May 2021 10:57:28 +0200 To: rfced-future@iab.org X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.50, [10.61.144.50] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: [Rfced-future] Issue 9: Strategy body meetings are public X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 May 2021 08:57:38 -0000 --Apple-Mail=_F8814185-3359-4A46-8D55-6F113F06F804 Content-Type: multipart/alternative; boundary="Apple-Mail=_F2C15117-C252-4468-976F-F3034FE9DABB" --Apple-Mail=_F2C15117-C252-4468-976F-F3034FE9DABB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We have consensus that on how the RFCWG will operate. The RSAB text = makes clear that minutes are to be taken, and recordings made, if there = are, say, video conferences. To be consistent with our earlier decision = (we didn=E2=80=99t have two bodies at the time), I propose a small tweak = to the text: OLD: THE RSAB shall keep a public record of its proceedings, including minutes of all meetings and a record of all decisions. NEW: THE RSAB shall keep a public record of its proceedings, including minutes of all meetings and a record of all decisions. The public SHALL be invited to observe any RSAB meetings or conferences. We can leave it to the RSAB as to whether they make those meetings more = interactive, as circumstances warrant. Does this make sense? Eliot --Apple-Mail=_F2C15117-C252-4468-976F-F3034FE9DABB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = have consensus that on how the RFCWG will operate.  The RSAB text = makes clear that minutes are to be taken, and recordings made, if there = are, say, video conferences.  To be consistent with our earlier = decision (we didn=E2=80=99t have two bodies at the time), I propose a = small tweak to the text:

OLD:

  =  THE RSAB shall keep a public record of its = proceedings, 
   including minutes of all meetings and a record = of all
  =  decisions.

NEW:

   THE RSAB shall keep = a public record of its proceedings, 
  =  including minutes of all meetings and a record of all
  =  decisions.  The public SHALL be invited to observe
   any = RSAB meetings or conferences.

We can leave it to the RSAB as = to whether they make those meetings more interactive, as circumstances = warrant.

Does = this make sense?

Eliot
= --Apple-Mail=_F2C15117-C252-4468-976F-F3034FE9DABB-- --Apple-Mail=_F8814185-3359-4A46-8D55-6F113F06F804 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCjgXgACgkQh7ZrRtnS ejPY4gf9GfVGPEuLU6qeY+o5ORxzxkVxDp8aMCIqLgQzXG5jR5jnFpzqnkLKmPwt 8O3g7c0wqZQhShQ1UxakiaK86o2zuR3oiEx2r2G6gl5B/dkZmqlnecn2bJefb97p S8mQ09Bo2/NYXny5O8g15XaZNFoh9Sb2fq+371v+kJRn5ApUXxh4wAgw4Q8qJmZF ZIwSL5sM4Pu2tZc6183GUopvofQPz11rU1dOnRUImryqxNuJKuAFcnO3boaR5xtM hApJljJ7so7mr+uSig8t8F0xSeLva59v9zaDCa5G7yB0DVm3/gfUZ0dXBh9QLoyd yJQ7JAPVaDsxasTajCizPGTVtmvZ2g== =TZgp -----END PGP SIGNATURE----- --Apple-Mail=_F8814185-3359-4A46-8D55-6F113F06F804-- From nobody Tue May 18 02:00:00 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2F2C3A13A2 for ; Tue, 18 May 2021 01:59:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 VC8RElWkZepP for ; Tue, 18 May 2021 01:59:53 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17F4E3A139C for ; Tue, 18 May 2021 01:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4444; q=dns/txt; s=iport; t=1621328393; x=1622537993; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=C9/r4r6d/V3V/zJG+AlQE+M8irvqeWjprMCEjptZKMg=; b=RBoD0WdKQzmWmKp/yTH9eRsnmmhLD1FNlGJJ+DLVLjiB31Uq5SkJT7w5 wwbFC+w+0w8T57jliaD0J9rrG/zhq+ykOJdhwdC9C6A7MvNOJQ0tVibnZ 1mgFuZ7Yr6sPfT34uiX/UpT2k68CblFPGwTFKZVvleNn8plRn84eRnKYf o=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0BYAAAEgaNg/xbLJq1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBQIFXgyJWAScSMY1LiHmUaYgoBAcBAQEKAwEBNQwEAQGETwKBd?= =?us-ascii?q?SY4EwIEAQEBAQMCAwEBAQEFAQEFAQEBAgEGBHEThVANhkQBAQEDAXkFCwsEC?= =?us-ascii?q?AwuPRoGE4JxAYJmIQ+nNXiBNIEBg19ARIR0CgaBOgGBUoU0hlxDgg2BFSccg?= =?us-ascii?q?l8+gmECAoUrgi0EgkaBECsgAYEvQp50nSiDIINLgUmEbpNDBSOlPaE8k3ABh?= =?us-ascii?q?AsCBAYFAhaBayOBWTMaCBsVZQGCPj4SGQ6SD4pfPwMvAjYCBgoBAQMJjRABA?= =?us-ascii?q?Q?= IronPort-HdrOrdr: A9a23:8DUqxa3N8kD0hyVbd+AOkQqjBLckLtp133Aq2lEZdPWaSL36qy nOppgmPHDP6Qr5NEtLpTnEAsm9qA3nmKKdkLN/AV7KZmCP01dAbrsSiLcKqAePJ8SRzJ8+6U 4ZSdkbNDU1ZmIK6/oTJ2KDYrEd/OU= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,309,1613433600"; d="asc'?scan'208,217";a="33670593" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 May 2021 08:59:50 +0000 Received: from smtpclient.apple ([10.61.144.50]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 14I8xona000790 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 May 2021 08:59:50 GMT From: Eliot Lear Message-Id: <6F223103-B6E5-452E-A001-EE5D84453D94@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_4B89019D-3E8E-42EE-9A3F-4DFA82B170E8"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 18 May 2021 10:59:49 +0200 In-Reply-To: Cc: rfced-future@iab.org To: Eliot Lear References: X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.50, [10.61.144.50] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] (Mostly) editorial changes offered by EKR X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 May 2021 08:59:59 -0000 --Apple-Mail=_4B89019D-3E8E-42EE-9A3F-4DFA82B170E8 Content-Type: multipart/alternative; boundary="Apple-Mail=_DAE62776-C69A-42F6-A7AA-BE77E4178BE6" --Apple-Mail=_DAE62776-C69A-42F6-A7AA-BE77E4178BE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Having discussed this further, I propose that the PR issued by EKR be = accepted as editorial. It can be viewed here = . Eliot > On 5 May 2021, at 10:00, Eliot Lear = wrote: >=20 > Signed PGP part > Just so that people are aware, EKR has created a PR on Github for = mostly editorial changes (spaces/double words, etc) that can be found = here = . = There is one substantial change in those comments that deserves = discussion, but is also probably not all that controversial, and I will = pull that out into a separate issue: when the RSAB starts its formal = review. >=20 > Eliot >=20 >=20 --Apple-Mail=_DAE62776-C69A-42F6-A7AA-BE77E4178BE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Having discussed this further, I propose that the PR issued = by EKR be accepted as editorial.  It can be viewed here.

Eliot

On 5 May 2021, at 10:00, Eliot = Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

Signed PGP part
Just so that people are aware, EKR has = created a PR on Github for mostly editorial changes (spaces/double = words, etc) that can be found here.  There is one substantial change in those = comments that deserves discussion, but is also probably not all that = controversial, and I will pull that out into a separate issue: when the = RSAB starts its formal review.

Eliot


= --Apple-Mail=_1D8F40F8-7C98-49CE-80EE-12810281F004-- From nobody Tue May 18 06:52: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 876003A12FA for ; Tue, 18 May 2021 06:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.846, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYvK-0jHcU5M for ; Tue, 18 May 2021 06:52:33 -0700 (PDT) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C923A1320 for ; Tue, 18 May 2021 06:52:32 -0700 (PDT) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14IDqPkr023717; Tue, 18 May 2021 14:52:25 +0100 Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 506D22203A; Tue, 18 May 2021 14:52:25 +0100 (BST) Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs3.iomartmail.com (Postfix) with ESMTPS id 3B70722032; Tue, 18 May 2021 14:52:25 +0100 (BST) Received: from LAPTOPK7AS653V (65.151.51.84.dyn.plus.net [84.51.151.65] (may be forged)) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id 14IDqNTO031936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 May 2021 14:52:24 +0100 Reply-To: From: "Adrian Farrel" To: "'Lars Eggert'" , "'Eliot Lear'" Cc: References: <637251CE-DFC9-4109-8A4F-C34A0CDF844F@cisco.com> <11485AD1-3252-47F7-8488-03DD841DA2C8@eggert.org> In-Reply-To: <11485AD1-3252-47F7-8488-03DD841DA2C8@eggert.org> Date: Tue, 18 May 2021 14:52:23 +0100 Organization: Old Dog Consulting Message-ID: <02f601d74bed$082fc640$188f52c0$@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: AQHKafwIsIYOM9mOEfOVwrb4slE5DwG5EMj/qvU8JQA= Content-Language: en-gb X-Originating-IP: 84.51.151.65 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-26164.007 X-TM-AS-Result: No--8.005-10.0-31-10 X-imss-scan-details: No--8.005-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-26164.007 X-TMASE-Result: 10--8.004500-10.000000 X-TMASE-MatchedRID: 8+bhjh9TQnHkQwDXuLnCoXFPUrVDm6jt+IfriO3cV8TOLXT85JI8l4zL yEgWJmpBJfOkgEMHscnW0Kd3t3/K3MxZDcAd5scKikdH3EQaETVKZf/QVAQP2CgMxnfFXjiIJg6 dxhIIpOb5gOAdLkh+J3HTX4zZKdSuVQGwZDL4UPFS3bjXqhv3iB35gqXq1LNlgn6pqeAeoD04+U ghLaiOGW5HQ7JbVbbNdzQS2DDCgkLJjkQZkjYCjjjNGpWCIvfT69aS+7/zbj+qvcIF1TcLYFCPJ IOYgAZ//sd3UP5QimMDE68T0M4Uj4uJ2hD2zvQiJNzc11O35nrtZ7AKSfxWjXepM/I+teqco8WM kQWv6iXh7z8MHC5cZ3QdJ7XfU86e4kYXbobxJbLyU/oX+tpNmK1tW6W4Lb8Amiedgmvq3tCbFgK YdRxf8BQW3g/SiMipfDqAyjn+WeefPxyRyYpT4Q== X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: Re: [Rfced-future] Issue 9: Strategy body meetings are public X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 May 2021 13:52:38 -0000 Yeah to Lars. I'm also enjoying the thought of sending an invitation to "the public" = =F0=9F=98=8A How about. The RSAB SHALL announce plans and agendas for their meetings on the RFC = Editor website and by email to the WG at least a week before such = meetings. The meetings SHALL be open for public attendance and the RSAB = MAY consider allowing open participation. If the RSAB needs to discuss = something confidential in Executive Session, that part of the meeting = SHALL be private to the RSAB, but MUST be noted on the agenda, and MUST = be present in the minutes with as much detail as the confidentiality = requirements permit. A -----Original Message----- From: Rfced-future On Behalf Of Lars = Eggert Sent: 18 May 2021 10:14 To: Eliot Lear Cc: rfced-future@iab.org Subject: Re: [Rfced-future] Issue 9: Strategy body meetings are public Hi, On 2021-5-18, at 11:57, Eliot Lear = wrote: > The public SHALL be invited to observe > any RSAB meetings or conferences. depending on how some things that are still up in the air get decided, = there may be rare cases were the RSAB needs to have discussions that = would require confidentiality. Would this SHALL eliminate that option? Lars From nobody Tue May 18 08:32: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 AC7D73A1702 for ; Tue, 18 May 2021 08:32:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 wZ9Xd59BAZ_O for ; Tue, 18 May 2021 08:32:38 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 362A33A1700 for ; Tue, 18 May 2021 08:32:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2514; q=dns/txt; s=iport; t=1621351958; x=1622561558; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=9ik3k31ZiTulIglQIWszwgd2bs3RC4xilQswlar2VDU=; b=EkapgvUNj3Ke5Cfn83dMGXeQb4xx6Nvj9lYcRp8XoLoEKyDQ6of+Hv6S vdsIAov8LVcRLKPsVfqhUogd7ho1uqIA4brChItJC/q01lP+oCjOcAUh7 32ioOxlpQPnfC+dfkFmEQ5n21VA9DRYY79+7NT5jeEHAo5ME4w8Hh/V+m U=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AWAADT3aNglxbLJq1aGQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RIBAQEBAQEBAQEBAQGCF4N4AScSMYRHiQSIdgObLIFoBAcBAQEKAwEBQQQBA?= =?us-ascii?q?YRPAoF1JjgTAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBAQEBaIVdh?= =?us-ascii?q?kQBAQEDASNFEQUHBAkCDAUEAQEBKgICPRIIBhOCcQGCZiGMcZsPeoEygQGEZ?= =?us-ascii?q?IR0EIE6AYFSixZ6Q4INgRUnHIJfPoJhBIEpARIBgzg2gi0EhCFGCyAHajCRH?= =?us-ascii?q?CaNFZ0pgyCDS4FJmDUFI4NaixOWUbUyAYQLAgQGBQIWgWsha3AzGggbFWUBg?= =?us-ascii?q?j4+EhkOjjiONj8DLwI2AgYBCQEBAwmNEAEB?= IronPort-HdrOrdr: A9a23:lRxspaCVWqm3GQvlHemp55DYdb4zR+YMi2TDGXoBKiC9E/b1qy nAppUmPHPP4gr5HUtBpTn/AsS9qALnmqKdiLN5VdyftUvdyQ6VxepZg7cKrQeQeREWjtQtsZ uJt8NFebvN5Z8Qt7ec3DWF X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,310,1613433600"; d="asc'?scan'208";a="36055023" 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; 18 May 2021 15:32:22 +0000 Received: from smtpclient.apple ([10.61.144.57]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 14IFWMu7011936 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 May 2021 15:32:22 GMT From: Eliot Lear Message-Id: <2CA4B0A8-CF18-4F63-B2EA-ECCA97190DA3@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_ABA4BB00-16D8-42EF-8A8D-5E43E135D714"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 18 May 2021 17:32:21 +0200 In-Reply-To: <02f601d74bed$082fc640$188f52c0$@olddog.co.uk> Cc: Lars Eggert , rfced-future@iab.org To: Adrian Farrel References: <637251CE-DFC9-4109-8A4F-C34A0CDF844F@cisco.com> <11485AD1-3252-47F7-8488-03DD841DA2C8@eggert.org> <02f601d74bed$082fc640$188f52c0$@olddog.co.uk> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.57, [10.61.144.57] X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 9: Strategy body meetings are public X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 May 2021 15:32:44 -0000 --Apple-Mail=_ABA4BB00-16D8-42EF-8A8D-5E43E135D714 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Is this text acceptable to others? Please comment. > On 18 May 2021, at 15:52, Adrian Farrel wrote: >=20 > Yeah to Lars. >=20 > I'm also enjoying the thought of sending an invitation to "the public" = =F0=9F=98=8A >=20 > How about. >=20 > The RSAB SHALL announce plans and agendas for their meetings on the = RFC Editor website and by email to the WG at least a week before such = meetings. The meetings SHALL be open for public attendance and the RSAB = MAY consider allowing open participation. If the RSAB needs to discuss = something confidential in Executive Session, that part of the meeting = SHALL be private to the RSAB, but MUST be noted on the agenda, and MUST = be present in the minutes with as much detail as the confidentiality = requirements permit. >=20 > A > -----Original Message----- > From: Rfced-future On Behalf Of Lars = Eggert > Sent: 18 May 2021 10:14 > To: Eliot Lear > Cc: rfced-future@iab.org > Subject: Re: [Rfced-future] Issue 9: Strategy body meetings are public >=20 > Hi, >=20 > On 2021-5-18, at 11:57, Eliot Lear = wrote: >> The public SHALL be invited to observe >> any RSAB meetings or conferences. >=20 >=20 > depending on how some things that are still up in the air get decided, = there may be rare cases were the RSAB needs to have discussions that = would require confidentiality. Would this SHALL eliminate that option? >=20 > Lars >=20 --Apple-Mail=_ABA4BB00-16D8-42EF-8A8D-5E43E135D714 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----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmCj3gUACgkQh7ZrRtnS ejMzgAf+IgfX7Lnkc97XmLWBb/NZbFhnUAIjR3iIFMqT6mk5fr8Tr04D08j0ZtiY tJcLbm8Eo7250Q6PKPvS1YCrmTHkBsUYC86T9B5vGbrfm17egAEbox/XOiq0RFCn 6k0fMaF1qjaCPMyP/GPY5f6QebujbEhTonL0nQxixA+0NzA/Pdg0Z/gYrd+LUcA0 mdmhqv178bk6zTIYWsMAT63NyoUrLqSAXM53Gw4cdVCp5NLsBIlI/0MX4bsdVupc PkZHLhrVAedScu+bXgyNgyx+0hoqXhklIG8cHRXBiRqz7sFpQW/ZC822GHgKqdVR B25ILMSQF9MI47KDigmxchsMOtlkeg== =MrF3 -----END PGP SIGNATURE----- --Apple-Mail=_ABA4BB00-16D8-42EF-8A8D-5E43E135D714-- From nobody Tue May 18 08:36: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 783203A1719 for ; Tue, 18 May 2021 08:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.796 X-Spam-Level: X-Spam-Status: No, score=-2.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 AUvyhPub_sqp for ; Tue, 18 May 2021 08:36:15 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E4D3A1744 for ; Tue, 18 May 2021 08:36:15 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 14IFTYqI010863; Tue, 18 May 2021 16:36:10 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=klTxLGlmJKWbOG0REGD+LM7aJAiWajYKPQNPCrSUDxs=; b=KKoGmTieW7uZiNIWIjdlaEXPa6y6wlOQdZh1NWgMAgGqNB8RKLTowmJE3gcZj57tngSS v/J31iEPj3wQ5byflk9fD4vY2z5gLvvI2eEOqert6g36g1r4yhuy8A7KvAYbqggVRkCx b7a8BPU1uBOA8GDxHt0iIHB1y2QRyNxRmsR3RAMApm8T8tJV3DI9IyZCXY6IhBt8tYpe tQRXMDJrHTpeug80Sv6wRt0e/0pYSVEHrUyMTJXAWew4sZctegIJiXYMRoWzbqpx0ADk IFeXf+F48v58pJUIDJPnPLDGucuyPmYRK1UNazsJP07r1ZuBqknskR7XjOun//TFpVhZ rw== Received: from prod-mail-ppoint6 (prod-mail-ppoint6.akamai.com [184.51.33.61] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 38m2pm4yk9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 18 May 2021 16:36:09 +0100 Received: from pps.filterd (prod-mail-ppoint6.akamai.com [127.0.0.1]) by prod-mail-ppoint6.akamai.com (8.16.1.2/8.16.1.2) with SMTP id 14IFYiQG015532; Tue, 18 May 2021 11:36:09 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint6.akamai.com with ESMTP id 38j9n08kvu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 18 May 2021 11:36:09 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 May 2021 11:36:08 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 18 May 2021 11:36:08 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1497.012; Tue, 18 May 2021 11:36:08 -0400 From: "Salz, Rich" To: Eliot Lear , Adrian Farrel CC: "rfced-future@iab.org" , Lars Eggert Thread-Topic: [Rfced-future] Issue 9: Strategy body meetings are public Thread-Index: AQHXS8PepnArNqFgrUeuZ5dlYgjy3KrpN7IAgABN4oCAABvugP//vgEA Date: Tue, 18 May 2021 15:36:08 +0000 Message-ID: <95B0060F-AD19-40F2-837C-69ADA69AE8A3@akamai.com> References: <637251CE-DFC9-4109-8A4F-C34A0CDF844F@cisco.com> <11485AD1-3252-47F7-8488-03DD841DA2C8@eggert.org> <02f601d74bed$082fc640$188f52c0$@olddog.co.uk> <2CA4B0A8-CF18-4F63-B2EA-ECCA97190DA3@cisco.com> In-Reply-To: <2CA4B0A8-CF18-4F63-B2EA-ECCA97190DA3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.49.21050901 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: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-18_07:2021-05-18, 2021-05-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 phishscore=0 mlxlogscore=958 adultscore=0 bulkscore=0 mlxscore=0 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105180111 X-Proofpoint-GUID: ggAcJBod-TNL_3L_tGzzCSfdfStuGQfj X-Proofpoint-ORIG-GUID: ggAcJBod-TNL_3L_tGzzCSfdfStuGQfj X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-18_07:2021-05-18, 2021-05-18 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 mlxscore=0 malwarescore=0 clxscore=1011 mlxlogscore=904 impostorscore=0 lowpriorityscore=0 spamscore=0 phishscore=0 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105180111 X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.61) smtp.mailfrom=rsalz@akamai.com smtp.helo=prod-mail-ppoint6 Archived-At: Subject: Re: [Rfced-future] Issue 9: Strategy body meetings are public X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 May 2021 15:36:31 -0000 PiAgICBJcyB0aGlzIHRleHQgYWNjZXB0YWJsZSB0byBvdGhlcnM/ICBQbGVhc2UgY29tbWVudC4N Cg0KU3VyZS4NCg0KDQo= From nobody Tue May 18 09:09:34 2021 Return-Path: X-Original-To: rfced-future@ietfa.amsl.com Delivered-To: rfced-future@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C267C3A186A for ; Tue, 18 May 2021 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eggert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJ0VXjjd6TZx for ; Tue, 18 May 2021 09:09:27 -0700 (PDT) Received: from mail.eggert.org (mail.eggert.org [91.190.195.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9BAC3A1868 for ; Tue, 18 May 2021 09:09:27 -0700 (PDT) Received: from smtpclient.apple (unknown [212.68.24.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.eggert.org (Postfix) with ESMTPSA id 0E132600C7E; Tue, 18 May 2021 19:09:20 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=eggert.org; s=dkim; t=1621354160; bh=25J6x/3/vYbRzqzAg6hmbnPAlsv3HgF9Fs+qnu7BtL4=; h=From:Subject:Date:References:Cc:In-Reply-To:To; b=J6RGyoGs88XUYESBJc1quy3HLvi0AqpmU4gtxYmm/HyC6Erv+dMspUli0rhkVEHO4 54zUN2KIDF0fkyq6JRN9egGWuWlNckohMq4RuUVnV1I5N6ONkbaYPeu2IeOxTMB3CA lVLw/6dnBP6dwaoWlMVtFMzpw/DMXV5rysNe2D9s= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Lars Eggert Mime-Version: 1.0 (1.0) Date: Tue, 18 May 2021 19:09:19 +0300 Message-Id: References: <2CA4B0A8-CF18-4F63-B2EA-ECCA97190DA3@cisco.com> Cc: Adrian Farrel , rfced-future@iab.org In-Reply-To: <2CA4B0A8-CF18-4F63-B2EA-ECCA97190DA3@cisco.com> To: Eliot Lear X-MailScanner-ID: 0E132600C7E.A382C X-MailScanner: Found to be clean X-MailScanner-From: lars@eggert.org Archived-At: Subject: Re: [Rfced-future] Issue 9: Strategy body meetings are public X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 May 2021 16:09:33 -0000 WFM --=20 Sent from a mobile device; please excuse typos. > On May 18, 2021, at 18:32, Eliot Lear w= rote: >=20 > =EF=BB=BFIs this text acceptable to others? Please comment. >=20 >> On 18 May 2021, at 15:52, Adrian Farrel wrote: >>=20 >> Yeah to Lars. >>=20 >> I'm also enjoying the thought of sending an invitation to "the public" =F0= =9F=98=8A >>=20 >> How about. >>=20 >> The RSAB SHALL announce plans and agendas for their meetings on the RFC E= ditor website and by email to the WG at least a week before such meetings. T= he meetings SHALL be open for public attendance and the RSAB MAY consider al= lowing open participation. If the RSAB needs to discuss something confidenti= al in Executive Session, that part of the meeting SHALL be private to the RS= AB, but MUST be noted on the agenda, and MUST be present in the minutes with= as much detail as the confidentiality requirements permit. >>=20 >> A >> -----Original Message----- >> From: Rfced-future On Behalf Of Lars Egger= t >> Sent: 18 May 2021 10:14 >> To: Eliot Lear >> Cc: rfced-future@iab.org >> Subject: Re: [Rfced-future] Issue 9: Strategy body meetings are public >>=20 >> Hi, >>=20 >>> On 2021-5-18, at 11:57, Eliot Lear w= rote: >>> The public SHALL be invited to observe >>> any RSAB meetings or conferences. >>=20 >>=20 >> depending on how some things that are still up in the air get decided, th= ere may be rare cases were the RSAB needs to have discussions that would req= uire confidentiality. Would this SHALL eliminate that option? >>=20 >> Lars >>=20 >=20 > --=20 > Rfced-future mailing list > Rfced-future@iab.org > https://www.iab.org/mailman/listinfo/rfced-future From nobody Tue May 18 11:52: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 A4D8D3A1D2D for ; Tue, 18 May 2021 11:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.295 X-Spam-Level: X-Spam-Status: No, score=-10.295 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=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 BYcjVCUtSrm5 for ; Tue, 18 May 2021 11:52:42 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5183A1D30 for ; Tue, 18 May 2021 11:52:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6636; q=dns/txt; s=iport; t=1621363962; x=1622573562; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=fVZZ59NXScunV+RGNki//0AjHkMhpA4jDFw8ho16LAw=; b=HSjdvruWCCUFVFkWBdFhH6YlpWRxUSPBdZ6CaNWsINkBwfrDQWJcfrc0 V0q4gQD8CGjypUwOYnkSrJ4yUMd+BKZGVEtLp+5Bg5yaoBYxbzW12v36b wRgsKxHqRb4RM89x6funigrwIFN9UeQD4CfWuU24TLEd8bisJNwwekMWK A=; X-Files: signature.asc : 488 X-IPAS-Result: =?us-ascii?q?A0AHAAC1C6RglxbLJq1aGgEBAQEBAQEBAQEDAQEBARIBA?= =?us-ascii?q?QEBAgIBAQEBggYCAQEBAQsBgyFWAScSMYRHiQSIUCUDlGyIKAQHAQEBCgMBA?= =?us-ascii?q?TEQBAEBhE8CgXUmNwYOAgQBAQEBAwIDAQEBAQUBAQUBAQECAQYEFAEBAQEBA?= =?us-ascii?q?QEBaIVQDYZEAQEBAwEjVgULCwwMKgICPRoGE4JxAYJmIQ+oP3qBMoEBhGSEd?= =?us-ascii?q?QoGgToBgVKFNAGGW0OCDYEVJwwQgl8+gmEEhHU2gi0EgWUPTAZkRxAggSwSb?= =?us-ascii?q?ZFTjGudKYMgg0uBSZg1BSOlPrUyAYQLAgQGBQIWgWoigVszGggbFWUBgj4+E?= =?us-ascii?q?hkOjjiIa4VLPwMvAjYCBgEJAQEDCY0QAQE?= IronPort-HdrOrdr: A9a23:wwcmmaPj5e4N9MBcTsSjsMiBIKoaSvp037Dk7TETdfU1SKClfq +V/cjzuSWftN9VYhEdcK67VZVoMEmyyXcd2+B4VotKHjOW3VdAR7sN0WKN+UyDJ8SHzJ846U +lGJIObuEZyjNB/KHH3DU= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.82,310,1613433600"; d="asc'?scan'208,217";a="36118987" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 18 May 2021 18:52:39 +0000 Received: from smtpclient.apple ([10.61.144.57]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 14IIqdAC032043 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 18 May 2021 18:52:39 GMT From: Eliot Lear Message-Id: <86781875-86C2-4A03-A382-5E6940BCA943@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_15CAEF02-3B98-4FB9-BC59-68F3CE3FE5F7"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.80.0.2.43\)) Date: Tue, 18 May 2021 20:52:38 +0200 In-Reply-To: <5F7EBB6D-2D12-4CB3-9640-ABD91E94A2E3@cisco.com> Cc: rfced-future@iab.org To: Eliot Lear References: <5F7EBB6D-2D12-4CB3-9640-ABD91E94A2E3@cisco.com> X-Mailer: Apple Mail (2.3654.80.0.2.43) X-Outbound-SMTP-Client: 10.61.144.57, [10.61.144.57] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Rfced-future] Issue 6: Streams have content control X-BeenThere: rfced-future@iab.org X-Mailman-Version: 2.1.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, 18 May 2021 18:52:47 -0000 --Apple-Mail=_15CAEF02-3B98-4FB9-BC59-68F3CE3FE5F7 Content-Type: multipart/alternative; boundary="Apple-Mail=_AD0E69C4-9837-45D9-99B4-8E27E5B311E0" --Apple-Mail=_AD0E69C4-9837-45D9-99B4-8E27E5B311E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Just a clarification: this was Martin Thomson. > On 18 May 2021, at 10:44, Eliot Lear = wrote: >=20 > Signed PGP part > Last summer we had agreed that this was to be the case. However, = Martin raised the following point as part of issue housecleaning on = this: >=20 >> Streams can have editorial policies of their own as long as they = aren't in conflict with those of the series. >>=20 >> That's different than what I understand by content control, which is = deciding what is published. Which I think we all agree remains, = provided that the content that a stream decides to publish is not in = conflict with editorial policies of the series as a whole. >>=20 >> I will note that the series itself has very loose editorial policies. = It doesn't even choose between British and American English. = Tightening those would be possible through the process we are designing. = The terminology debate is probably not where I would start, but it is = one possible option. Whatever the change though, the potential for = conflict between stream and series policies is a good example of a valid = reason that the RSAB might reject what the RSWG produces. >=20 > First, do people agree with Martin on this? It=E2=80=99s a bit more = nuanced than what we had previously agreed. >=20 > This begs two questions: >=20 > What are the definitive editorial policies today? Are we thinking = https://www.rfc-editor.org/styleguide/? = > Are we saying that the RPC makes the final call on whether a document = is consistent with whatever policies are in place? >=20 > Thanks, >=20 > Eliot >=20 >=20 --Apple-Mail=_AD0E69C4-9837-45D9-99B4-8E27E5B311E0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Just = a clarification: this was Martin Thomson.

On 18 = May 2021, at 10:44, Eliot Lear <lear=3D40cisco.com@dmarc.ietf.org> wrote:

Signed PGP part
Last summer we had agreed that this was to be the case. =  However, Martin raised the following point as part of issue = housecleaning on this:

Streams can have = editorial policies of their own as long as they aren't in conflict with = those of the series.

That's different than = what I understand by content control, which is deciding what is = published.  Which I think we all agree remains, provided that the = content that a stream decides to publish is not in conflict with = editorial policies of the series as a whole.

I will note that the series itself has very loose editorial = policies.  It doesn't even choose between British and American = English.  Tightening those would be possible through the process we = are designing.  The terminology debate is probably not where I = would start, but it is one possible option.  Whatever the change = though, the potential for conflict between stream and series policies is = a good example of a valid reason that the RSAB might reject what the = RSWG produces.

First, do people agree with Martin on this?  It=E2=80=99s = a bit more nuanced than what we had previously agreed.

This begs two = questions:

  • What are the definitive editorial = policies today?  Are we thinking https://www.rfc-editor.org/styleguide/?
  • Are we saying that the RPC makes the final call on whether a = document is consistent with whatever policies are in = place?

Thanks,

Eliot