Re: [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)

Rebecca VanRheenen <rvanrheenen@amsl.com> Tue, 21 June 2022 15:08 UTC

Return-Path: <rvanrheenen@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 3F976C157B47; Tue, 21 Jun 2022 08:08:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable 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 sQiELd-4vS4Z; Tue, 21 Jun 2022 08:08:38 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (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 01978C157B41; Tue, 21 Jun 2022 08:08:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id D4C29425A37D; Tue, 21 Jun 2022 08:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FZqgl1cdW1zO; Tue, 21 Jun 2022 08:08:37 -0700 (PDT)
Received: from [IPv6:2601:641:300:5fb0:cd89:651b:1158:9cec] (unknown [IPv6:2601:641:300:5fb0:cd89:651b:1158:9cec]) by c8a.amsl.com (Postfix) with ESMTPSA id 8ECCA425A37C; Tue, 21 Jun 2022 08:08:37 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Rebecca VanRheenen <rvanrheenen@amsl.com>
In-Reply-To: <e5f12085-a1e2-19a6-cd92-1bccf889902c@gmail.com>
Date: Tue, 21 Jun 2022 08:08:36 -0700
Cc: RFC Editor <rfc-editor@rfc-editor.org>, iab@ietf.org, auth48archive@rfc-editor.org, Eliot Lear <lear@lear.ch>, Lars Eggert <lars@eggert.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1680CDD7-4ECD-4025-A4C1-3D2E18DB803C@amsl.com>
References: <20220618052657.5B652C88D8@rfcpa.amsl.com> <7841f7c1-40e6-cdab-2108-ea58a5350b9e@stpeter.im> <e5f12085-a1e2-19a6-cd92-1bccf889902c@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Peter Saint-Andre <stpeter@stpeter.im>, Brian Rosen <br@brianrosen.net>, "Salz, Rich" <rsalz@akamai.com>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/p6kXlfNZgXRS10uEkg-iPpNMS8Q>
Subject: Re: [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: Tue, 21 Jun 2022 15:08:42 -0000

Peter and Brian,

Thank you for addressing the cluster-wide questions. We will update the documents in the cluster accordingly.

Brian, thank you also for letting us know that you did not receive 1) the original email with the cluster questions and 2) the initial AUTH48 message for RFC-to-be 9283. This has happened for several other authors as well, and we are looking into the problem. If you encounter this again, please report it to support@ietf.org.

Thank you,
RFC Editor/rv



> On Jun 18, 2022, at 1:49 PM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> 1) I concur with Peter.
> 
> 2) I did not receive the original message, nor did I receive the AUTH48 message for RFC-to-be 9283.
> 
> This is a weird bug. A few weeks ago I similarly did not receive an errata confirmation message. For some reason, whatever magic at the rfc-editor site generates automatic messages no longer works for my address. Who would be the right contact for finding and fixing this?
> 
> (I will fish that AUTH48 message out of the archive and reply to it.)
> 
> Regards
>   Brian Carpenter
> 
> On 19-Jun-22 06:08, Peter Saint-Andre wrote:
>> On 6/17/22 11:26 PM, rfc-editor@rfc-editor.org wrote:
>> <snip/>
>>> 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").
>> Let's use lowercase "function" as in the older RFCs.
>>> 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.
>> Agreed.
>>> 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].
>> All of that text is from Section 3.1, which is entitled "The IETF
>> Trust"; thus I think context makes the meaning clear. However, in the
>> second and third paragraphs it might be slightly better to change "the
>> Trust" to "the IETF Trust" (on the principle of using the full name on
>> first use in a paragraph).
>>> 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
>> That seems fine because the context of the sentence makes the meaning clear.
>>>     ...
>>>     It is left to the Trust to
>>>     specify exactly how this shall be clearly indicated in each document.
>> This is from Section 6.1, which is entitled "Procedures Request of the
>> IETF Trust"; thus I think contenxt again makes the meaning clear, but as
>> above changing this one instance to "IETF Trust" would be fine with me.
>> Peter
>