On Mon, Feb 28, 2022, 6:24 PM Benjamin Kaduk <kaduk@mit.= edu> wrote:

On Tue, Mar 01, = 2022 at 12:17:24AM +0100, Carsten Bormann wrote:
> > A full review should not be necessary.
>
> I wish that were true...

IMO a full review is necessary,

My opinion is different.=C2=A0 If I followed yo= ur approach, a lot of documents would have been delayed and probably abando= ned.=C2=A0 I've been involved as author/editor for a number of multi-hu= ndred-page documents.=C2=A0 The results were not perfect but the documents = were improvements over the documents they replaced and that is enough for m= e.

not least to ensure that the document<= br> remains self-consistent and that any changes applied during editing are
uniformly applied to all relevant parts of the document, not just in the subset of places that the editor noticed.

The changes made/proposed at editi= ng are made by someone that is not an author, is not part of the working gr= oup and should be rejected if they raise potential difficulties such as you= are worried about.=C2=A0=C2=A0

I cannot see how a large set of co-ordinated changes such as you = are worried about can be made by someone who is not an author.

=C2=A0 =C2=A0 -=C2=A0 if a split inf= initive is corrected, then the correction can be approved without a further= search for similar instances.=C2=A0 Each case is a separate judgement call= .

=C2=A0 =C2=A0- similarly with corrections of comma= s.

=C2=A0 =C2=A0- if a large set of co-ordinated cha= nges is proposed, whose nature would require a full rerevew, they should be= rejected, as politely as possible.=C2=A0 If that is not possible for some = reason, the working group should have the opportunity to weigh in, but that= option should be very rarely used.

This is analogous to a situation that arises when doing code review.
If you change an API's semantics,

"If it hurts when you do that, don&#= 39;t do that".

You = should not be changing an APIs' semantics as part of a code review.=C2= =A0 Those

Semantics should be agreed to before codin= g starts.

you had better go around and ch= eck
all the callers of that API to see if they need adjustments, not just the callers of the API that your test suite happens to exercise.=C2=A0

Sound like a = nightmare to me, since such adstments might require further adjustments.

With
specifications we do not have the rigid rules of function names to identify=
the places to check, and the safe thing to do is read the whole document with any changes that were made fresh in mind.

The safe thing is to limit ch= anges after consensus to those that do not require such extensive review by= the authors who may, as someone pointed out, have lost the necessary conte= xt.

-Ben

--000000000000dedcb605d94f43be-- From nobody Thu Mar 3 06:06:15 2022 Return-Path: X-Original-To: admin-discuss@ietfa.amsl.com Delivered-To: admin-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CEF3A0ABB; Thu, 3 Mar 2022 06:06:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-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 8rogWflveZrR; Thu, 3 Mar 2022 06:06:09 -0800 (PST) Received: from gabriel-smtp.zfn.uni-bremen.de (gabriel-smtp.zfn.uni-bremen.de [134.102.50.15]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CCBA3A09D0; Thu, 3 Mar 2022 06:06:08 -0800 (PST) Received: from [192.168.217.118] (p5089ad4f.dip0.t-ipconnect.de [80.137.173.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-smtp.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4K8Xp62BdYzDCjf; Thu, 3 Mar 2022 15:06:06 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) From: Carsten Bormann In-Reply-To: Date: Thu, 3 Mar 2022 15:06:05 +0100 Cc: Benjamin Kaduk , Michael Richardson , admin-discuss@ietf.org, IETF , RFC Interest , Working Group Chairs X-Mao-Original-Outgoing-Id: 668009165.654315-8b227c8ffa464080ee0b63c3b4566f4b Content-Transfer-Encoding: quoted-printable Message-Id: <5745B01F-A817-4047-888D-BE1251A4D4AA@tzi.org> References: <28081.1646063116@localhost> <30A5489A-BD18-49CF-AB34-2E9B6E759B8C@tzi.org> <20220228232436.GF12881@kduck.mit.edu> To: David Noveck X-Mailer: Apple Mail (2.3608.120.23.2.7) Archived-At: Subject: Re: [admin-discuss] [rfc-i] Time to say "NO!!" to AUTH4200 (Re: AUTH48 checking the different formats (Re: Public archival of AUTH48 communications)) X-BeenThere: admin-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for IETF LLC administrative issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2022 14:06:13 -0000 >> > > A full review should not be necessary.=20 >> >=20 >> > I wish that were true... >>=20 >> IMO a full review is necessary, >>=20 > My opinion is different. If I followed your approach, a lot of = documents would have been delayed and probably abandoned. =20 The crucial observation is that different authors have different = priorities here. That is very much OK. The responsible AD is part of the process to check that it doesn=E2=80=99t= derail too much. > I've been involved as author/editor for a number of multi-hundred-page = documents. The results were not perfect but the documents were = improvements over the documents they replaced and that is enough for me. The perfect is the enemy of the good=E2=80=A6 > should Did I talk about process confabulation yet today? I think we are still responsible for the outcomes, even if not everybody = else keeps every SHOULD (or MUST). But that doesn=E2=80=99t mean the result MUST be perfect. Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Mar 3 12:02:40 2022 Return-Path: X-Original-To: admin-discuss@ietfa.amsl.com Delivered-To: admin-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D45F53A11F6; Thu, 3 Mar 2022 12:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9X9ke80C9sv8; Thu, 3 Mar 2022 12:01:58 -0800 (PST) Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58BA53A1236; Thu, 3 Mar 2022 12:01:58 -0800 (PST) Received: by mail-pj1-x1036.google.com with SMTP id ge19-20020a17090b0e1300b001bcca16e2e7so8758507pjb.3; Thu, 03 Mar 2022 12:01:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VuwHmAYU1B/Oi3VcpOupxumbRE+ZzgaOO96Ldw27Ntc=; b=D4MVfnDo+srtdrsdL5waCVC3nqqyEIEEjCL1VHEJ+qRskHpInCghYie64GrQpS4BbD EerIngS92QzfgjD8NX/bxA2bo8hi0uUyXFumKRb9nXg7079fCYQlC72vAinv3KMQs1EP 10m8i5v9QHhmzYeZhooG+RCnP5cKxjBJv/o3liv9tTd56jbXWn0Qi1doQgYXRVU2NqmQ FAerUDRIJLeeBj/CfElBkJzCJHRkKkujJhig4vhQHcq9eK4qA9OEaScJMi8JKXYyrUVd DBqpC1p5xL5NUgc7u051/1GI3i/RnHIzankEB6E4zMxIbT+j53zb7ttJDiaSZrThUKnJ N3ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VuwHmAYU1B/Oi3VcpOupxumbRE+ZzgaOO96Ldw27Ntc=; b=20vK6NnzvBRG2DLGq6o4nkCDyU+ynIxFGVGfnq0EKdphliSLWLmdMA/QWuGM0kmA4Q 4G9FrUOCtWXIykRxv9J6ex0AW738Gr/hLdWZcmRmhbCKojBdfda0fUi2sVBBMLUDpcRU zTV+nIUGJafaIqnili05/VMWzR6h0nLMX9dwZ1DlDf5ItlPs/Z/gvuQcZMjN05CY3gZW duIwOE69emf56wQTh0PJBqgbPoQlv2lRjOqN0jOylwOXViAjVLS+VvR/tjINHXqqayyE b9wn3eiF0sqMaerGlYK/y2atErAGMwFSVjx4z5vCVWZUGD8fg+fv5c2difqIpokWxR8W Q/Lg== X-Gm-Message-State: AOAM533nHUX/35LktJFBZjbqNTJVGicEXS6jjTunKHrVwdGvS2U6RtsD 7jE7JrwQyMLlhWqdmHsb+v0olGluFVMb/w== X-Google-Smtp-Source: ABdhPJyKaX/KGIF9ShxdoICHmA9fbA85vwVH9CcnbQgc27YH9EV9bmUZQUS7tSo0zSqgYJfkdm49PQ== X-Received: by 2002:a17:90a:e7c3:b0:1bf:d25:3dd4 with SMTP id kb3-20020a17090ae7c300b001bf0d253dd4mr5070047pjb.158.1646337717179; Thu, 03 Mar 2022 12:01:57 -0800 (PST) Received: from ?IPv6:2406:e003:1005:b501:80b2:5c79:2266:e431? ([2406:e003:1005:b501:80b2:5c79:2266:e431]) by smtp.gmail.com with ESMTPSA id d25-20020a637359000000b0037843afb785sm2793828pgn.25.2022.03.03.12.01.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 03 Mar 2022 12:01:56 -0800 (PST) To: David Noveck , Benjamin Kaduk Cc: Working Group Chairs , admin-discuss@ietf.org, IETF , RFC Interest References: <28081.1646063116@localhost> <30A5489A-BD18-49CF-AB34-2E9B6E759B8C@tzi.org> <20220228232436.GF12881@kduck.mit.edu> From: Brian E Carpenter Message-ID: <4dc84eee-0402-e72c-3fad-d7fdf4516033@gmail.com> Date: Fri, 4 Mar 2022 09:01:52 +1300 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [admin-discuss] [rfc-i] Time to say "NO!!" to AUTH4200 (Re: AUTH48 checking the different formats (Re: Public archival of AUTH48 communications)) X-BeenThere: admin-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for IETF LLC administrative issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2022 20:02:11 -0000 David, On 04-Mar-22 01:08, David Noveck wrote: ... > The safe thing is to limit changes after consensus to those that do not require such extensive review by the authors who may, as someone pointed out, have lost the necessary context. This is a bit of a strawman, but it is entirely possible that an editor could resolve an ambiguous sentence in a way that effectively changes the meaning of the whole document; for example, changing a terminology definition that is used throughout the text. We can't avoid this by issuing meaningless instructions to the editor like "don't change anything that matters". How we resolve it today is by the editor writing to the authors at AUTH48 time in terms like: 4) Only someone who understands the whole scenario can determine whether the second version is a clarification or a change of intent. Whatever the tooling for AUTH48, this sort of edit must be reviewed by a subject matter expert. Brian From nobody Thu Mar 3 16:52:21 2022 Return-Path: X-Original-To: admin-discuss@ietf.org Delivered-To: admin-discuss@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7663A0877 for ; Thu, 3 Mar 2022 16:52:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Administration LLC Board of Directors Chair To: X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: admin-discuss@ietf.org Message-ID: <164635513007.28312.10318559257155277580@ietfa.amsl.com> Date: Thu, 03 Mar 2022 16:52:10 -0800 Archived-At: Subject: [admin-discuss] LLC Board Meeting Details - 10 March 2022 X-BeenThere: admin-discuss@ietf.org X-Mailman-Version: 2.1.29 List-Id: Discussion list for IETF LLC administrative issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2022 00:52:19 -0000 IETF LLC Board of Directors meetings are conducted via web/teleconference. Members of the community are welcome to attend certain portions of these meetings as observers. Regular meetings are divided into four sections: 1. Open (to Observers) 2. Board + Support Staff Only 3. Board + Executive Director Only 4. Executive Session (Board-Only) The next meeting will be held on Thursday, 10 March 2022 at 12:00 PT (20:00 UTC). WebEx and Dial-in information is at the bottom of this message and also at . The agenda for the meeting can be found on the same page. A calendar of upcoming public meetings can be downloaded or subscribed to at: https://calendar.google.com/calendar/ical/ietf.org_vmffrv4hq14aqpedenuv5v42hs%40group.calendar.google.com/public/basic.ics ------------------------------------------------------- JOIN WEBEX MEETING https://ietf.webex.com/ietf/j.php?MTID=m35801209ab72d83e21872323bda20c08 Meeting number (access code): 2420 020 9230 Meeting password: 1234 JOIN BY PHONE 1-650-479-3208 Call-in toll number (US/Canada) Access code: 2420 020 9230 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. From nobody Thu Mar 3 18:37:52 2022 Return-Path: X-Original-To: admin-discuss@ietfa.amsl.com Delivered-To: admin-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52B603A0C9D; Thu, 3 Mar 2022 18:37:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-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 dseGmZoRqhbH; Thu, 3 Mar 2022 18:37:48 -0800 (PST) Received: from bsa2.jck.com (ns.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C74493A0B5F; Thu, 3 Mar 2022 18:37:47 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nPxpA-000Eyc-FK; Thu, 03 Mar 2022 21:37:44 -0500 Date: Thu, 03 Mar 2022 21:37:38 -0500 From: John C Klensin To: Brian E Carpenter , David Noveck , Benjamin Kaduk cc: Working Group Chairs , admin-discuss@ietf.org, RFC Interest , IETF Message-ID: <787B2692B486DA6743B288BC@PSB> In-Reply-To: <4dc84eee-0402-e72c-3fad-d7fdf4516033@gmail.com> References: <28081.1646063116@localhost> <30A5489A-BD18-49CF-AB34-2E9B6E759B8C@tzi.org> <20220228232436.GF12881@kduck.mit.edu> <4dc84eee-0402-e72c-3fad-d7fdf4516033@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: [admin-discuss] [rfc-i] Time to say "NO!!" to AUTH4200 (Re: AUTH48 checking the different formats (Re: Public archival of AUTH48 communications)) X-BeenThere: admin-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for IETF LLC administrative issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2022 02:37:51 -0000 --On Friday, March 4, 2022 09:01 +1300 Brian E Carpenter wrote: > David, > On 04-Mar-22 01:08, David Noveck wrote: > ... >> The safe thing is to limit changes after consensus to those >> that do not require such extensive review by the authors who >> may, as someone pointed out, have lost the necessary context. > > This is a bit of a strawman, but it is entirely possible that > an editor could resolve an ambiguous sentence in a way that > effectively changes the meaning of the whole document; for > example, changing a terminology definition that is used > throughout the text. Your supposed strawman is eventually what brought us to pre-publication review of documents that, through a few stages of review, brought us to AUTH48. And problems about authors either tuning out or taking advantage of questionable changes to substitute their preferences for approving-body consensus. In other words "been there, tried that, and it did not work out well". Probably worth mentioning that those checks were first put in place at a time when the editing team had considerably more expertise and depth about the subject matter of RFCs than today's RPC and any we are likely to see in the future. Even they could got get decisions about what did or did not change meaning right 100% of the time. > We can't avoid this by issuing meaningless instructions to the > editor like "don't change anything that matters". How we > resolve it today is by the editor writing to the authors at > AUTH48 time in terms like: >... If the editor even notices that a change might be substantive. The current RPC team gets that right almost all of the time, but final review by subject matter experts is still important (if nothing else, to keep this a team effort and avoid pressure on the RPC for absolute accuracy and universal knowledge. john From nobody Mon Mar 7 01:41:09 2022 Return-Path: X-Original-To: admin-discuss@ietfa.amsl.com Delivered-To: admin-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 012733A0EF2; Mon, 7 Mar 2022 01:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VF7cfRc_bTge; Mon, 7 Mar 2022 01:40:25 -0800 (PST) Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB52B3A0E31; Mon, 7 Mar 2022 01:40:15 -0800 (PST) Received: from [192.168.0.227] (77-58-144-232.dclient.hispeed.ch [77.58.144.232]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 2279eCYr420060 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 7 Mar 2022 10:40:12 +0100 Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1646646013; bh=vUMUpM3yHVcOyRcSlFuhmVlHlW7SocUZQ+mZ+IaxwxY=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=nQLEb3Z8nxqmhUgcJ9Co77WLdHRw12jfAvn1RzyY6gbwuH0cIfmkdQEwbSvahb6RZ 8KAvngp5t5TDLG4gK7vHaqjKgkQaD2hOe5v5bxmoQ3zQqS3fqV2QnCHAPk2QQCESdP OwSE23A51cs8ogY1X+jEuHFsrtBsn2/AEYPpSfeY= Message-ID: <3f01ea8c-38df-a965-82ca-94a1c699acc0@lear.ch> Date: Mon, 7 Mar 2022 10:40:12 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: iesg@ietf.org Cc: wgchairs@ietf.org, admin-discuss@ietf.org, ietf@ietf.org References: <164574145917.13799.12710132950530774405@ietfa.amsl.com> From: Eliot Lear In-Reply-To: <164574145917.13799.12710132950530774405@ietfa.amsl.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------jBmLvI7t0mSLMU6RCb1dARat" Archived-At: Subject: [admin-discuss] On transparency of the road not taken (Re: Public archival of AUTH48 communications) X-BeenThere: admin-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for IETF LLC administrative issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 09:40:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------jBmLvI7t0mSLMU6RCb1dARat Content-Type: multipart/mixed; boundary="------------lQ5xfxTX28Ca5aSeE3qUrjiK"; protected-headers="v1" From: Eliot Lear To: iesg@ietf.org Cc: wgchairs@ietf.org, admin-discuss@ietf.org, ietf@ietf.org Message-ID: <3f01ea8c-38df-a965-82ca-94a1c699acc0@lear.ch> Subject: On transparency of the road not taken (Re: Public archival of AUTH48 communications) References: <164574145917.13799.12710132950530774405@ietfa.amsl.com> In-Reply-To: <164574145917.13799.12710132950530774405@ietfa.amsl.com> --------------lQ5xfxTX28Ca5aSeE3qUrjiK Content-Type: multipart/alternative; boundary="------------OGdehY9RuYp6Ch0PwgbymR7H" --------------OGdehY9RuYp6Ch0PwgbymR7H Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGkgRnJhbmNlc2NhLA0KDQpXZSBoYXZlIGRpc2N1c3NlZCB0cmFuc3BhcmVuY3kgaW4gQVVU SDQ4LCB0aGUgcG9pbnQgYXQgd2hpY2ggYSBkcmFmdCBpcyANCmFib3V0IHRvIGJlIHB1Ymxp c2hlZC7CoCBJIHdvbmRlciBpZiB3ZSBjb3VsZCBhbHNvIGNvbnNpZGVyIHRoZSBwb2ludCBh dCANCndoaWNoIGl0IGlzIGRlY2lkZWQgKm5vdCogdG8gcHVibGlzaCBhIGRyYWZ0LsKgIERv Y3VtZW50aW5nIHRoYXQgZGVjaXNpb24gDQpwcm9jZXNzIGlzIGltcG9ydGFudCAoYSkgd2hl biB0aGUgb3JnYW5pemF0aW9uIGhhcyBzcGVudCBhIGxvdCBvZiB0aW1lIA0Kb24gaXQgb3Ig KGIpIHdoZW4gdGhlcmUgaXMgc29tZSByZWFzb25hYmxlIGV4cGVjdGF0aW9uIHRoYXQgdGhl IG1hdHRlciANCm1pZ2h0IGFyaXNlIGFnYWluLiBUaGlzIGNhbiBoZWxwIHVzIHByZXNlcnZl IGluc3RpdHV0aW9uYWwgbWVtb3J5IA0Kd2l0aG91dCByZXF1aXJpbmcgcGVvcGxlIHRvIHNp ZnQgdGhyb3VnaCBodW5kcmVkcyBvciB0aG91c2FuZHMgb2YgZW1haWwgDQptZXNzYWdlcy4N Cg0KVHdvIGV4YW1wbGVzIHRoYXQgY29tZSB0byBtaW5kIGFyZSB0aGUgd29yayBhcm91bmQg TkVXVFJLIHRoYXQgbmV2ZXIgZ290IA0KcHVzaGVkIHRocm91Z2ggKHRoaXMgZ29lcyBiYWNr IHRvIDIwMDYpIGFuZCBjb21lcyB1cCBmcm9tIHRpbWUgdG8gdGltZSwgDQphbmQgdGhlIHdv cmsgb2Ygc3Vuc2V0NCwgYWJvdXQgd2hpY2ggc29tZW9uZSBqdXN0IHF1ZXJpZWQgbWUuDQoN CklmIGEgZHJhZnQgaGFzIGJlZW4gYWRvcHRlZCBieSBhIHdvcmtpbmcgZ3JvdXAgYnV0IGhh c24ndCBwcm9jZWVkZWQgdG8gDQpwdWJsaWNhdGlvbiwgdGhlbiBJIHdvdWxkIGFyZ3VlIHRo YXQgdGhlIElFVEYgc2hvdWxkIHRha2UgdGhlIHRpbWUgdG8gDQplc3RhYmxpc2ggYSB0b21i c3RvbmUgb2Ygc29tZSBmb3JtIHRoYXQgZXhwbGFpbnMgd2hhdCBoYXBwZW5lZCwgDQpyZWNv cmRpbmcgcGVvcGxlJ3Mgdmlld3MsIHByZWZlcmFibHkgc3VjY2luY3RseS7CoCBJIGltYWdp bmUgdGhpcyBkb2Vzbid0IA0KaGFwcGVuIHRvbyBvZnRlbiAoSSd2ZSBjaXRlZCB0d28gZXhh bXBsZXMgdGhhdCBnbyBiYWNrIDE2IHllYXJzKSwgYW5kIEkgDQpjYW4gdGhpbmsgb2YgdHdv IG90aGVyIGNhc2VzIHRoYXQgZ28gYmFjayBldmVuIGZ1cnRoZXIuDQoNCklmIGEgZHJhZnQg d2FzIG5vdCBhZG9wdGVkIGFuZCBwZW9wbGUgd291bGQgc3RpbGwgbGlrZSB0byBleHBsYWlu IHRoZSANCnNpdHVhdGlvbiwgdGhlbiB0aGF0IGlzIHNvbWV0aGluZyB0aGF0IG1pZ2h0IGJl IGEgdmFsdWFibGUgaW5kZXBlbmRlbnQgDQpzdWJtaXNzaW9uLCBhc3N1bWluZyBvdGhlciBh cHByb2FjaGVzIGhhdmVuJ3QgYmVlbiBkZXZlbG9wZWQuDQoNCkkgYW0gbm90IHN1Z2dlc3Rp bmcgYSB0cmVhdGlzZSBpbiBlaXRoZXIgY2FzZSwgbm9yIGEgcmFudCBhYm91dCBob3cgDQp0 aGluZ3Mgd2VudCAid3JvbmciLCBidXQgYSBzaW1wbGUgc3VtbWFyeSBvZiB0aGUgZGlzY3Vz c2lvbnMgdG8gZXhwbGFpbiANCndoYXQgd2UgbGVhcm5lZCB0aGF0IGxlZCB0byB0aGUgZGVj aXNpb24gdG8gbm90IHB1Ymxpc2guDQoNClRob3VnaHRzPw0KDQpFbGlvdA0KDQpPbiAyNC4w Mi4yMiAyMzoyNCwgVGhlIElFU0cgd3JvdGU6DQo+IFRoZSBJRVRGIHByaWRlcyBpdHNlbGYg b24gaXRzIG9wZW4gcHJvY2VzcyBhbmQgdHJhbnNwYXJlbnQNCj4gY29tbXVuaWNhdGlvbiwg d2l0aCBvbmUgb2Ygb3VyIGNvcmUgcHJpbmNpcGxlcyBiZWluZyBvdXIgY29tbWl0bWVudCB0 bw0KPiBtYWtpbmcgYWxsIG1hdGVyaWFscyByZWxhdGVkIHRvIG91ciBzdGFuZGFyZHMgcHJv Y2VzcyBhbmQgb3RoZXINCj4gYWN0aXZpdGllcyBwdWJsaWNseSBhdmFpbGFibGUuDQo+DQo+ IEZvciBhIGRvY3VtZW50IHVuZGVyZ29pbmcgcHVibGljYXRpb24gd2l0aGluIHRoZSBJRVRG IFN0cmVhbSwgbW9zdCBvZg0KPiBpdHMgaGlzdG9yeSBjYW4gYmUgdHJhY2VkIGJ5IGV4cGxv cmluZyB0aGUgbWFpbCBhcmNoaXZlIC0gZnJvbSB0aGUgZmlyc3QNCj4gc3VibWlzc2lvbiwg dG8gTGFzdCBDYWxsIGNvbW1lbnRzLCB0byBJRVNHIGV2YWx1YXRpb24uIEhvd2V2ZXIsIG9u Y2UgdGhlDQo+IGRvY3VtZW50IGVudGVycyB0aGUgUkZDIEVkaXRvciBxdWV1ZSwgdGhlIGNv bW11bmljYXRpb24gYmV0d2VlbiBhdXRob3JzDQo+IGFuZCBSRkMgUHJvZHVjdGlvbiBDZW50 ZXIgKFJQQykgaXMgb25seSB2aXNpYmxlIHRvIGEgc3BlY2lmaWMgc2V0IG9mDQo+IHBlb3Bs ZTogUkZDIGVkaXRvcnMsIGF1dGhvcnMsIHRoZSByZXNwb25zaWJsZSBBRHMgYW5kIFdHIGNo YWlycyAod2hlbg0KPiBhcHBsaWNhYmxlKS4NCj4NCj4gSW4gb3JkZXIgdG8gaW5jcmVhc2Ug dHJhbnNwYXJlbmN5IGR1cmluZyB0aGUgZmluYWwgc3RhZ2VzIG9mIGRvY3VtZW50DQo+IGVk aXRpbmcsIHRoZSBJRVNHLCBJQUIsIElTRSwgSVJTRywgVGVtcG9yYXJ5IFJGQyBTZXJpZXMg UHJvamVjdCBNYW5hZ2VyLA0KPiBSUEMsIGFuZCBUb29scyB0ZWFtIGFyZSBjb25zaWRlcmlu ZyBhbGxvd2luZyBhbnlvbmUgdG8gc2VhcmNoIGFuZCByZWFkDQo+IEFVVEg0OCBjb252ZXJz YXRpb25zIGFib3V0IHNwZWNpZmljIGRvY3VtZW50cyAob3IgY2x1c3RlcnMgb2YNCj4gZG9j dW1lbnRzKS4gSXQgaXMgbm90IGEgZ29hbCB0byBhY3RpdmVseSBpbnZvbHZlIG1vcmUgcGVv cGxlIGluIHRoZQ0KPiBjb252ZXJzYXRpb24gYmV0d2VlbiBhdXRob3JzIGFuZCBSRkMgZWRp dG9ycy4NCj4NCj4gT3VyIHByb3Bvc2FsOiB0byBzZXQgdXAgYSBwdWJsaWMgbWFpbGluZyBs aXN0IG9mIEFVVEg0OCBjb252ZXJzYXRpb25zLA0KPiBmb3IgYXJjaGl2YWwgcHVycG9zZXMg b25seSwgaS5lLiwgcmVhZC1vbmx5LiBUaGUgUkZDIGVkaXRvcnMsIHdoZW4NCj4gaW5pdGlh dGluZyB0aGUgY29udmVyc2F0aW9uIHdpdGggdGhlIGF1dGhvcnMgd2lsbCBDQyB0aGlzIG1h aWxpbmcgbGlzdC4NCj4gQWxsIGZ1cnRoZXIgcmVzcG9uc2VzIHVzdWFsbHkgbWFpbnRhaW4g dGhlIENDIGFkZHJlc3NlcywgYW5kIGFzIGENCj4gY29uc2VxdWVuY2Ugd2lsbCBiZSBhcmNo aXZlZCBpbiB0aGUgbWFpbGluZyBsaXN0IGFyY2hpdmUuDQo+DQo+IEFsbCBBVVRINDggZGlz Y3Vzc2lvbnMgb2YgYWxsIGRvY3VtZW50cyB3aWxsIGJlIGFyY2hpdmVkIG9uIHRoZSBzYW1l DQo+IG1haWxpbmcgbGlzdC4gU2VhcmNoZXMgYW5kIGZpbHRlcmluZyB3aWxsIGJlIGF2YWls YWJsZSBiYXNlZCBvbiB0aGUNCj4gbWFpbHPigJkgY29udGVudCBhbmQgbWV0YWRhdGEsIGlu Y2x1ZGluZyBkcmFmdCBuYW1lLCBSRkMtdG8tYmUgbnVtYmVyLA0KPiBjbHVzdGVyIG51bWJl ciwgc2VuZGVyLCBhbmQgZGF0ZS4NCj4NCj4gT3B0IG91dDogdGhlIGF1dGhvcnMgYW5kIFJG QyBlZGl0b3JzIGFyZSBhYmxlIHRvIG9wdCBvdXQgZnJvbSBhcmNoaXZhbCwNCj4gYnkgcmVt b3ZpbmcgdGhlIG1haWxpbmcgbGlzdCBmcm9tIHRoZSBDQy4gQWx0aG91Z2ggd2UgZG9u4oCZ dCBlbnZpc2lvbg0KPiB0aGF0IHRoaXMgd2lsbCBiZSBuZWNlc3Nhcnkgb2Z0ZW4sIHRoZXJl IG1heSBiZSBjYXNlcyB3aGVyZSBzZW5zaXRpdmUNCj4gaW5mb3JtYXRpb24gbmVlZHMgdG8g YmUgc2hhcmVkLg0KPg0KPiBUaGUgaW5pdGlhbCBBVVRINDggbWFpbCBmcm9tIHRoZSBSRkMg RWRpdG9yIHdpbGwgYWxzbyBpbmNsdWRlIHRleHQgYWJvdXQNCj4gcHVibGljIGFyY2hpdmFs LCB0byBtYWtlIHN1cmUgYXV0aG9ycyBhcmUgYXdhcmUuIFdpdGggdGhpcyBhbm5vdW5jZW1l bnQsDQo+IHRoZSBJRVNHIHdhbnRzIHRvIGluZm9ybSB0aGUgY29tbXVuaXR5IGFuZCByZWFk IGZlZWRiYWNrIGJlZm9yZSB3ZSBzZXQNCj4gYW55dGhpbmcgdXAuIFBsZWFzZSBzZW5kIGFu eSBjb21tZW50IHRvaWVzZ0BpZXRmLm9yZyAgb3IgcmVwbHkgdG8gdGhpcw0KPiB0aHJlYWQg YnkgMjQgTWFyY2ggMjAyMi4NCj4NCj4gRnJhbmNlc2NhIFBhbG9tYmluaSBmb3IgdGhlIElF U0cNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gSUVURi1Bbm5vdW5jZSBtYWlsaW5nIGxpc3QNCj4gSUVURi1Bbm5vdW5jZUBpZXRm Lm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5u b3VuY2UNCj4NCg== --------------OGdehY9RuYp6Ch0PwgbymR7H Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi Francesca,

We have discussed transparency in AUTH48, the point at which a draft is about to be published.=C2=A0 I wonder if we could also consider the point at which it is decided not to publish a draft.=C2=A0 Documenting that decision process is important (a) whe= n the organization has spent a lot of time on it or (b) when there is some reasonable expectation that the matter might arise again.=C2= =A0 This can help us preserve institutional memory without requiring people to sift through hundreds or thousands of email messages.
=

Two examples that come to mind are the work around NEWTRK that never got pushed through (this goes back to 2006) and comes up from time to time, and the work of sunset4, about which someone just queried me.

If a draft has been adopted by a working group but hasn't proceeded to publication, then I would argue that the IETF should take the time to establish a tombstone of some form that explains what happened, recording people's views, preferably succinctly.=C2=A0= I imagine this doesn't happen too often (I've cited two examples that go back 16 years), and I can think of two other cases that go back even further.

If a draft was not adopted and people would still like to explain the situation, then that is something that might be a valuable independent submission, assuming other approaches haven't been developed.

I am not suggesting a treatise in either case, nor a rant about how things went "wrong", but a simple summary of the discussions to explain what we learned that led to the decision to not publish.

Thoughts?

Eliot

On 24.02.22 23:24, The IESG wrote:
=

The IETF prides itself on it=
s open process and transparent=20
communication, with one of our core principles being our commitment to=20
making all materials related to our standards process and other=20
activities publicly available.=20

For a document undergoing publication within the IETF Stream, most of=20
its history can be traced by exploring the mail archive - from the first =

submission, to Last Call comments, to IESG evaluation. However, once the =

document enters the RFC Editor queue, the communication between authors=20
and RFC Production Center (RPC) is only visible to a specific set of=20
people: RFC editors, authors, the responsible ADs and WG chairs (when=20
applicable).=20

In order to increase transparency during the final stages of document=20
editing, the IESG, IAB, ISE, IRSG, Temporary RFC Series Project Manager, =

RPC, and Tools team are considering allowing anyone to search and read=20
AUTH48 conversations about specific documents (or clusters of=20
documents). It is not a goal to actively involve more people in the=20
conversation between authors and RFC editors.

Our proposal: to set up a public mailing list of AUTH48 conversations,=20
for archival purposes only, i.e., read-only. The RFC editors, when=20
initiating the conversation with the authors will CC this mailing list.=20
All further responses usually maintain the CC addresses, and as a=20
consequence will be archived in the mailing list archive.=20

All AUTH48 discussions of all documents will be archived on the same=20
mailing list. Searches and filtering will be available based on the=20
mails=E2=80=99 content and metadata, including draft name, RFC-to-be numb=
er,=20
cluster number, sender, and date.

Opt out: the authors and RFC editors are able to opt out from archival,=20
by removing the mailing list from the CC. Although we don=E2=80=99t envis=
ion=20
that this will be necessary often, there may be cases where sensitive=20
information needs to be shared.

The initial AUTH48 mail from the RFC Editor will also include text about =

public archival, to make sure authors are aware. With this announcement, =

the IESG wants to inform the community and read feedback before we set=20
anything up. Please send any comment to iesg@ietf.org or reply to this=20
thread by 24 March 2022.

Francesca Palombini for the IESG

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

--------------OGdehY9RuYp6Ch0PwgbymR7H-- --------------lQ5xfxTX28Ca5aSeE3qUrjiK-- --------------jBmLvI7t0mSLMU6RCb1dARat Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAmIl0vwFAwAAAAAACgkQh7ZrRtnSejNq Kwf/fh3ZGXZqKZkgjG0GEIqsyyxMN9aKG5FeC4Z5JYHvNLgBgMlLM5LlRuM79u0dikuBHVqziHOn aNQezVh5NlMbNOp6kfMtPtP25V0EMgUkt8IIOKykSoCoX/3gZ/4KDeiCc6x4gCVxLPVtNAOit0af r4+WtfVTN8pbj2nDnY2xb+gOYKPWDjIvF5CB6V+ObecmsyQ/v/yN6CApFJmhljNO58wSmVV2QIj5 9u7qCbu5dXgEt63+sKHUe8BC+sCtD1/41NTkUZLSifae+rhXK7RdumrJXTUQy/Xk/CHqK8SeoSWf Q2okJCyip6jZ9td0efiCYK8BsocyYJkXpwlPaTbHxQ== =6yPt -----END PGP SIGNATURE----- --------------jBmLvI7t0mSLMU6RCb1dARat-- From nobody Mon Mar 7 10:42:29 2022 Return-Path: X-Original-To: admin-discuss@ietfa.amsl.com Delivered-To: admin-discuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A68313A1329; Mon, 7 Mar 2022 10:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 8IAbU1wVTdXH; Mon, 7 Mar 2022 10:41:56 -0800 (PST) Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AAF33A1B1F; Mon, 7 Mar 2022 10:40:06 -0800 (PST) Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from ) id 1nRIH6-000PHb-W2; Mon, 07 Mar 2022 13:40:04 -0500 Date: Mon, 07 Mar 2022 13:39:58 -0500 From: John C Klensin To: Eliot Lear , iesg@ietf.org cc: wgchairs@ietf.org, admin-discuss@ietf.org, ietf@ietf.org Message-ID: <3AD8BAD0FE9B2F9C0700B0D6@PSB> In-Reply-To: <3f01ea8c-38df-a965-82ca-94a1c699acc0@lear.ch> References: <164574145917.13799.12710132950530774405@ietfa.amsl.com> <3f01ea8c-38df-a965-82ca-94a1c699acc0@lear.ch> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SA-Exim-Connect-IP: 198.252.137.10 X-SA-Exim-Mail-From: john-ietf@jck.com X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false Archived-At: Subject: Re: [admin-discuss] On transparency of the road not taken (Re: Public archival of AUTH48 communications) X-BeenThere: admin-discuss@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for IETF LLC administrative issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2022 18:42:09 -0000 Eliot, The devil is, as usual, in the details, but I agree with the general idea. Three additions to your comments: (1) Some of those "path not taken" or rejected documents have ended up as Independent Submissions and published. Especially when an IETF WG picked a different solution to the same or a similar problem, the approval process for those Independent Submissions has been more or less insistent that revised versions of those road-not-taken documents contain a careful critical analysis of the two approaches and the differences between them. (2) Using the NEWTRK documents as an example, I think it would be accurate to say that many of those who had participated in the work found the IESG's explanation of what was done and why to be completely unsatisfactory. Were we to go down the path you suggest, there should be some theory about how to resolve such situations even if it were only that the IESG posts a draft summary/tombstone but its text were subject to appeal. However, one of the lessons from that episode was that there were no appeals from the IESG decision at least in part because the animosity level was high enough that no one wanted to raise temperatures further. (3) Would you expect such a tombstone mechanism / process to apply to Independent Submissions as well? I can see strong arguments both ways. best, john --On Monday, March 7, 2022 10:40 +0100 Eliot Lear wrote: > Hi Francesca, >=20 > We have discussed transparency in AUTH48, the point at which a > draft is about to be published.=C2=A0 I wonder if we could = also > consider the point at which it is decided *not* to publish a > draft.=C2=A0 Documenting that decision process is important = (a) > when the organization has spent a lot of time on it or (b) > when there is some reasonable expectation that the matter > might arise again. This can help us preserve institutional > memory without requiring people to sift through hundreds or > thousands of email messages. >=20 > Two examples that come to mind are the work around NEWTRK that > never got pushed through (this goes back to 2006) and comes up > from time to time, and the work of sunset4, about which > someone just queried me. >=20 > If a draft has been adopted by a working group but hasn't > proceeded to publication, then I would argue that the IETF > should take the time to establish a tombstone of some form > that explains what happened, recording people's views, > preferably succinctly.=C2=A0 I imagine this doesn't happen too > often (I've cited two examples that go back 16 years), and I > can think of two other cases that go back even further. >=20 > If a draft was not adopted and people would still like to > explain the situation, then that is something that might be a > valuable independent submission, assuming other approaches > haven't been developed. >=20 > I am not suggesting a treatise in either case, nor a rant > about how things went "wrong", but a simple summary of the > discussions to explain what we learned that led to the > decision to not publish. >=20 > Thoughts? >=20 > Eliot >=20 > On 24.02.22 23:24, The IESG wrote: >> The IETF prides itself on its open process and transparent >> communication, with one of our core principles being our >> commitment to making all materials related to our standards >> process and other activities publicly available. >>=20 >> For a document undergoing publication within the IETF Stream, >> most of its history can be traced by exploring the mail >> archive - from the first submission, to Last Call comments, >> to IESG evaluation. However, once the document enters the RFC >> Editor queue, the communication between authors and RFC >> Production Center (RPC) is only visible to a specific set of >> people: RFC editors, authors, the responsible ADs and WG >> chairs (when applicable). >>=20 >> In order to increase transparency during the final stages of >> document editing, the IESG, IAB, ISE, IRSG, Temporary RFC >> Series Project Manager, RPC, and Tools team are considering >> allowing anyone to search and read AUTH48 conversations about >> specific documents (or clusters of documents). It is not a >> goal to actively involve more people in the conversation >> between authors and RFC editors. >>=20 >> Our proposal: to set up a public mailing list of AUTH48 >> conversations, for archival purposes only, i.e., read-only. >> The RFC editors, when initiating the conversation with the >> authors will CC this mailing list. All further responses >> usually maintain the CC addresses, and as a consequence will >> be archived in the mailing list archive. >>=20 >> All AUTH48 discussions of all documents will be archived on >> the same mailing list. Searches and filtering will be >> available based on the mails' content and metadata, >> including draft name, RFC-to-be number, cluster number, >> sender, and date. >>=20 >> Opt out: the authors and RFC editors are able to opt out from >> archival, by removing the mailing list from the CC. Although >> we don't envision that this will be necessary often, there >> may be cases where sensitive information needs to be shared. >>=20 >> The initial AUTH48 mail from the RFC Editor will also include >> text about public archival, to make sure authors are aware. >> With this announcement, the IESG wants to inform the >> community and read feedback before we set anything up. Please >> send any comment toiesg@ietf.org or reply to this thread by >> 24 March 2022. >>=20 >> Francesca Palombini for the IESG >>=20 >> _______________________________________________ >> IETF-Announce mailing list >> IETF-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/ietf-announce >>=20