[auth48] [Cluster456] AUTH48 Questions: RFCs 9280 - 9283 (draft-iab-rfcefdp-rfced-model, draft-rsalz-2028bis, draft-rosen-rfcefdp-update-2026, draft-carpenter-rfced-iab-charter)

rfc-editor@rfc-editor.org Sat, 18 June 2022 05:27 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9904C15AAFC; Fri, 17 Jun 2022 22:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Level:
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhwIvjFIcBAH; Fri, 17 Jun 2022 22:26:57 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0DABC15AAD5; Fri, 17 Jun 2022 22:26:57 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id 5B652C88D8; Fri, 17 Jun 2022 22:26:57 -0700 (PDT)
To: stpeter@stpeter.im, rsalz@akamai.com, br@brianrosen.net, brian.e.carpenter@gmail.com
From: rfc-editor@rfc-editor.org
Cc: rfc-editor@rfc-editor.org, iab@ietf.org, auth48archive@rfc-editor.org, rsalz@akamai.com, Eliot Lear <lear@lear.ch>, Lars Eggert <lars@eggert.org>
Content-type: text/plain; charset="UTF-8"
Message-Id: <20220618052657.5B652C88D8@rfcpa.amsl.com>
Date: Fri, 17 Jun 2022 22:26:57 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/w6aNAq6CvXoP9xyeBCAOrCzDAfs>
Subject: [auth48] [Cluster456] AUTH48 Questions: RFCs 9280 - 9283 (draft-iab-rfcefdp-rfced-model, draft-rsalz-2028bis, draft-rosen-rfcefdp-update-2026, draft-carpenter-rfced-iab-charter)
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Sat, 18 Jun 2022 05:27:01 -0000

Authors,

While reviewing this cluster of documents*, please reply to the questions
below regarding consistency across the cluster. These questions are in
addition to the document-specific questions sent for each RFC-to-be. Please note that we erred on the side of asking more questions for this cluster, as we know much of the text was carefully crafted.  

Your replies will likely impact two or more of the documents in the cluster, so
please discuss and then let us know how to proceed. Note that you have the option of 
updating the edited XML files yourself, if you prefer. We will wait to hear from you 
before continuing with the publication process.

* Currently in AUTH48 state:

http://www.rfc-editor.org/authors/rfc9280.txt 
http://www.rfc-editor.org/authors/rfc9281.txt 
http://www.rfc-editor.org/authors/rfc9282.txt 
http://www.rfc-editor.org/authors/rfc9283.txt

You may track the progress of all documents in this cluster through AUTH48 at:
https://www.rfc-editor.org/auth48/C456


1) In this cluster, we used the following forms of the terms below for
consistency with current usage in the RFC Series.

RFC Series

RFC Editor Model

Last Call

IAB Charter - per draft-carpenter-rfced-iab-charter-09  

IESG Charter - for consistency with "IAB Charter" 
 
stream - lowercased form in general text (e.g., "representatives of the streams")

Stream - capitalized form in proper name of stream (i.e., IETF Stream, IAB
Stream, IRTF Stream, Independent Stream, and Editorial Stream)

chair - lowercased form in general text (e.g., "responsibilities of a working group chair")
   
Chair - capitalized form in name of title (e.g., "IRTF Chair", "RSWG Chair")


2) We see the following forms in this cluster:

RFC Editor Function - draft-iab-rfcefdp-rfced-model-13
RFC Editor function - draft-carpenter-rfced-iab-charter-09

Is one form preferred? Note that RFCs 8728, 8729, and 8730 use "RFC Editor
function" (lowercase "function").


3) We see the following expansions for LLC in the cluster in the context
of "IETF LLC":

Limited Liability Company - draft-iab-rfcefdp-rfced-model-13
Limited Liability Corporation - draft-rsalz-2028bis-07

We have updated to "Limited Liability Company" as that is what we see in past
RFCs (e.g., 8728, 8729, and 8730) and in documents such as
https://www.ietf.org/media/documents/IETF-LLC-Agreement.pdf.
      

4) Should instances of "the Trust" read "the IETF Trust"? Or will this existing text be clear for readers?

Original (draft-rsalz-2028bis-07):
   The principles for the copyright licenses granted to and from the
   Trust are described in [IPRRIGHTS1] and [COPYRIGHT], and the licenses
   themselves are in the Trust Legal Provisions
   (https://trustee.ietf.org/documents/trust-legal-provisions/).
   ...
   The Trust also currently owns IANA's domain names and trademarks
   through an agreement with the IANA clients.
   ...
   The Trustees that govern the Trust are selected from the IETF
   community, as described in [TRUSTEES] and the rationale given in
   [TRUSTRAT].

Original (draft-iab-rfcefdp-rfced-model-13):
   *  The IETF Trust, which approves that the boilerplate correctly
      states the Trust's position regarding rights and ownership
   ...      
   It is left to the Trust to
   specify exactly how this shall be clearly indicated in each document.      
            

Thank you,
RFC Editor