Re: [auth48] AUTH48: RFC-to-be 9280 <draft-iab-rfcefdp-rfced-model-13> for your review

Eliot Lear <lear@lear.ch> Thu, 23 June 2022 19:43 UTC

Return-Path: <lear@lear.ch>
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 CD99EC15A728; Thu, 23 Jun 2022 12:43:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.773
X-Spam-Level:
X-Spam-Status: No, score=-2.773 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, NICE_REPLY_A=-1.876, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 qqbwmEJD4ujS; Thu, 23 Jun 2022 12:43:45 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (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 D399CC159496; Thu, 23 Jun 2022 12:42:59 -0700 (PDT)
Received: from [IPV6:2001:420:c0c0:1002::187] ([IPv6:2001:420:c0c0:1002:0:0:0:187]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 25NJgkbH1435033 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Thu, 23 Jun 2022 21:42:47 +0200
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=1656013371; bh=Qmow5hS8gvEVu3l5wN1Sell4VLPQhfkmEYp1QQut2C4=; h=Date:To:Cc:References:From:Subject:In-Reply-To:From; b=ScDvO36gIWn2VVQqlwcUUTOKVYgrPF8AuFQMUxYwniqE3vf+izGyumYAobkIEwXdG 6oHmIKrw1LgMDCeOvwPmQVbCOmdTzXSJoV6crwVNI2XD/4lNJNRA0eCSIKTAaUWmyw MHlHw9py1VSfnXmuZarTIyvoz4BqbvYUomX+Sk1E=
Message-ID: <8d22fc5a-0b33-af85-4456-5d1ce8df33e0@lear.ch>
Date: Thu, 23 Jun 2022 21:42:43 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
Content-Language: en-US
To: Peter Saint-Andre <stpeter@stpeter.im>, Rebecca VanRheenen <rvanrheenen@amsl.com>
Cc: RFC Editor <rfc-editor@rfc-editor.org>, Brian Rosen <br@brianrosen.net>, iab@ietf.org, auth48archive@rfc-editor.org, Colin Perkins <csp@csperkins.org>
References: <20220618035859.D4FE015FF6A@rfcpa.amsl.com> <10597e60-58aa-41bb-cfaa-6a88c9843759@stpeter.im> <BA94ED3E-C9F7-4331-A1C6-6AB9E0D8283D@amsl.com> <7f890736-efd0-1e6b-670b-cb64a75785e4@stpeter.im> <83987AE0-5F7F-45AA-98A5-2EBE2DD22E4E@amsl.com> <e2924146-94b0-2294-0990-74e876f86f8b@stpeter.im> <E1C61C97-6D45-41E1-AFC9-2CC65A8EBA84@amsl.com> <59e1bf26-f313-00a7-801d-3a87e40e56a3@stpeter.im>
From: Eliot Lear <lear@lear.ch>
In-Reply-To: <59e1bf26-f313-00a7-801d-3a87e40e56a3@stpeter.im>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------enq8wYiySzDdYhGtRfDoBADh"
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/zjHV8SZqc0pwfaX56E_rBFTohl0>
Subject: Re: [auth48] AUTH48: RFC-to-be 9280 <draft-iab-rfcefdp-rfced-model-13> for your review
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: Thu, 23 Jun 2022 19:43:49 -0000

Hi Peter,

On 23.06.22 20:33, Peter Saint-Andre wrote:
> Hi Rebecca,
>
> Thanks for your work on this important document.
>
> Here are a few proposed edits. I would like the Program chairs and the 
> IAB to make sure they are comfortable with these changes before you 
> make these edits.
>
> SECTION 3.1.1.2
>
> OLD
>    software or hardware systems that implement RFCs, authors of RFCs and
>    Internet-Drafts, developers of tools used to author or edit RFCs,
>
> NEW
>    software or hardware systems that implement RFCs, authors of RFCs and
>    Internet-Drafts, developers of tools used to author or edit RFCs and
>    Internet-Drafts,
>
> RATIONALE: I don't think it was deliberate for us to leave out 
> developers of tools used to author Internet-Drafts, however there *is* 
> a difference (many tools are used to author Internet-Drafts but a 
> smaller set of tools is used by the RPC to edit RFCs for publication).

This is not intended to be an exhaustive list, so the change to me is a 
wash, one way or another.


>
> SECTION 3.1.2.3
>
> The following two sentences are in potential conflict:
>
> 3.1.2.3
>
>    The appointing bodies, i.e., the stream approving bodies (IESG, IAB,
>    IRTF Chair, and ISE), shall determine their own processes for
>    appointing RSAB members (note that processes related to the RSCE are
>    described in Section 5).
>
> 4.4
>
>    *  If there is a conflict with a policy for a particular stream, to
>       help achieve a resolution, the RPC should consult with the
>       relevant stream approving body (such as the IESG or IRSG) and
>       other representatives of the relevant stream as appropriate.
>
> In 3.1.2.3, the IRTF Chair is described as a stream approving body 
> (!), whereas in 4.4 the IRSG is described as a stream approving body. 
> I suggest that we remove mention of stream approving bodies in 3.1.2.3 
> and make the following change.
>
> OLD
>
>    The appointing bodies, i.e., the stream approving bodies (IESG, IAB,
>    IRTF Chair, and ISE), shall determine their own processes for
>    appointing RSAB members (note that processes related to the RSCE are
>    described in Section 5).
>
> NEW
>
>    The appointing bodies (i.e., IESG, IAB, IRTF Chair, and ISE), shall
>    determine their own processes for appointing RSAB members (note that
>    processes related to the RSCE are described in Section 5).


I think it's better just to make a change to section 4.4 as follows:

>    * If there is a conflict with a policy for a particular stream, to
>       help achieve a resolution, the RPC should consult with
>       representatives of the relevant streams as appropriate. 

Eliot