[Rfced-future] Program Last Call Results and Next Steps

Eliot Lear <lear@lear.ch> Mon, 31 January 2022 11:22 UTC

Return-Path: <lear@lear.ch>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A85A3A2D16 for <rfced-future@ietfa.amsl.com>; Mon, 31 Jan 2022 03:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lear.ch
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LHOueUNBy5u for <rfced-future@ietfa.amsl.com>; Mon, 31 Jan 2022 03:22:48 -0800 (PST)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7B433A2D12 for <rfced-future@iab.org>; Mon, 31 Jan 2022 03:22:45 -0800 (PST)
Received: from [IPV6:2001:420:c0c0:1011::3] ([IPv6:2001:420:c0c0:1011:0:0:0:3]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 20VBMcML351390 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Mon, 31 Jan 2022 12:22:39 +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=1643628160; bh=1riRk/7+KnTeY14XED5Y1whHrVo+601U4nu/kFnyEB8=; h=Date:From:To:Cc:Subject:From; b=IA1FUt1GYudrl7Qdk8QdhE30yrxCzqim0k3EbGwG9XwVdy1HH558mlRYhRAa3FLHB 3PGYI8jfppfLOXH3jeosAYMUWd7z9SucZQ+s8LulJbbSl0A3wj5eCUemARpwt+xHI6 9MyprPheuB0BzpI8G4PXBmMu/s4T/L6tL1iaOOdg=
Message-ID: <7bfd8aa8-e28f-5596-fa66-114317b7a414@lear.ch>
Date: Mon, 31 Jan 2022 12:22:35 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.1
Content-Language: en-US
From: Eliot Lear <lear@lear.ch>
To: "rfced-future@iab.org" <rfced-future@iab.org>
Cc: Brian Rosen <br@brianrosen.net>, Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------8J0PkMPCwB55s0ec3UjdXkpQ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/2apwshCW7XSfd8CYacHYmYrzlGA>
Subject: [Rfced-future] Program Last Call Results and Next Steps
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 31 Jan 2022 11:22:53 -0000

Dear all,

Program last call has now closed.

We received one set of editorial comments from Brian Carpenter.  I want 
to detail the proposed changes here, and their disposition for the next 
draft, which we are asking Peter to post now.  Once posted, we will 
forward that draft to the IAB for further processing.

> "3.1.1.2. Participation
> ...This includes participants in the IETF and IRTF, IAB and IESG 
> members, individuals who use RFCs in procurement decisions, authors of 
> RFCs and Internet-Drafts, developers of tools used to author RFCs, 
> scholarly researchers, and so on."
>
> I notice that implementers of code or hardware based on RFCs are not 
> listed. That seems like a significant omission. 

Peter has expanded the list for consultation as follows:

> This includes but is not limited to participants in the IETF and
>
> IRTF, members of the IAB and IESG, developers of software or hardware
>
> systems that implement RFCs, authors of RFCs and Internet-Drafts,
>
> developers of tools used to author or edit RFCs, individuals who
>
> use RFCs in procurement decisions, scholarly researchers, and
>
> representatives of standards development organizations other than
>
> the IETF and IRTF. The IETF LLC Board members, staff and contractors
>
> (especially representatives of the RFC Production Center), and the
>
> IETF Executive Director are invited to participate as community
>
> members in the RSWG to the extent permitted by any relevant IETF LLC
>
> policies. Members of the RSAB are also expected to participate
>
> actively.

This text represents a move of some text from later in the draft, but 
the normative constructs have not changed.

>
> The explanation might or might not be actionable."
>
> I think that sentence might or might not be actionable. In other 
> words, it's a no-op. 

This is text that we have discussed: the implication intended here is 
that the proposal taken as a whole may be so flawed that no textual 
change would correct it.  For example: “All future RFCs SHALL only be 
published in Klingon".

Peter has proposed the following change:

> Nevertheless, the RSWG might not be able to
>
> come to consensus on modifications that will address the RSAB member's
>
> concern.
>
A missing parenthesis as noted, and a spelling error was corrected.  An 
internal reference {#} was added.  Some spacing was modified.

These represent the entirety of proposed changes to the text.

Eliot