Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62

Jay Daley <jay@ietf.org> Thu, 24 June 2021 01:11 UTC

Return-Path: <jay@ietf.org>
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 BAF273A192C for <rfced-future@ietfa.amsl.com>; Wed, 23 Jun 2021 18:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 v14JorvbhHwH; Wed, 23 Jun 2021 18:11:33 -0700 (PDT)
Received: from smtpclient.apple (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 5E47C3A1929; Wed, 23 Jun 2021 18:11:32 -0700 (PDT)
From: Jay Daley <jay@ietf.org>
Message-Id: <E3D8B2D9-8F79-4B78-8525-EDBA8AD2CD77@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_F62A0339-7505-4A8D-ACA6-999DF5B611D0"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Thu, 24 Jun 2021 13:11:29 +1200
In-Reply-To: <d0fc01a2-4bad-b24a-a620-6c7193fe6fca@gmail.com>
Cc: Eliot Lear <lear@lear.ch>, rfced-future@iab.org
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <04B7BD6D-612C-410B-BD71-07680CE2D4AB@ietf.org> <39f83475-e0bb-5ca7-ecfe-d6756a581fb5@gmail.com> <3ad917f6-d965-cbf2-0217-38c7e01e9340@lear.ch> <d0fc01a2-4bad-b24a-a620-6c7193fe6fca@gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/es6g1BegeG2OavIVSelPb7aI9Ps>
Subject: Re: [Rfced-future] Suggested text for issues #56, #57, #61, #62
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: Thu, 24 Jun 2021 01:11:38 -0000


> On 24/06/2021, at 9:30 AM, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
> 
> On 23-Jun-21 19:51, Eliot Lear wrote:
>> 
>> On 23.06.21 05:06, Brian E Carpenter wrote:
>>> I may have missed it, but I don't there's a github issue for finalizing the role and title of the RSEA. That's where I would like to hang this comment.
>> 
>> There are several, one of which we just are in the process of closing.  
>> The title one I have deferred discussing for the moment.  We also have 
>> the agreed text from Issue 12:
> 
> Fair enough (but see below) but in my defence, the title of that issue didn't seem like it covered the role definition.
> 
>> 
>>> This person will be a senior professional with deep knowledge of 
>>> technical publishing.
>>> 
>>> The RSE will operate by providing expert advice to the RSAWG, and if 
>>> requested, to the RPC, on any relevant matters. 
> 
> Yes, we agreed on that, but I think we missed the question of who will be 
> tasked with communicating RSWG and/or RSAB decisions and advice to the RPC. So there's an open issue either here in #12 or in Jay's proposed texts. I'd be inclined to fill it here, something like:
> 
> The RSEA will communicate relevant RSWG and RSAB decisions and advice to the RPC.
> 
> (The alternative would be to task the RSWG and RSAB chairs with this, but 
> if we're hiring an expert, that would seem like the normal person to do it.)

For me this is a backward step.  We appear to have agreed in principle that the RPC is stepping up and engaging much more directly with the community (though we’re still discussing if that’s primarily through the RSAB/RSWG or more directly) and we appear to have agreed that the RSEA is not the manager of the RPC.  Under those conditions, breaking the direct connection between the RSAB/RSWG and the RPC by inserting the RSEA into the chain seems retrograde and reopens multiple questions about the nature of the relationship between the RSEA and the RPC that are otherwise moot.

Jay


> 
>   Brian
> 
>>> The value this 
>>> individual provides is an understanding of the process of technical 
>>> publishing. They expected to learn how the process is applied in the 
>>> RFC series. They will be asked to produce regular reviews of the 
>>> process and identify problems and opportunities for improvement. There 
> 
>>> are also opportunities to spontaneously learn of these problems, 
>>> likely the result of interactions with day-to-day operations. The 
>>> person may be requested to draft documents
>>> 
>>> For example, the RSE might be consulted about proposed changes to the 
>>> style guide, RFC formatting in general, web presence, copyright 
>>> matters, or archiving policy, or might of their own initiative suggest 
> 
>>> such changes to the RSAWG.
>>> 
>>> The RSE is expected to attend all RSAWG meetings, and to have an 
>>> ongoing working relationship with the RPC and tooling team.
>>> 
>> https://github.com/intarchboard/program-rfced-future/blob/master/Issue12-RSE-role.md
>> 
>> This text needs to make its way into the draft.  That is not to say this 
>> text can't improve, but this was what we agreed.
>> 
>> Eliot
>> 
>> 
> 

-- 
Jay Daley
IETF Executive Director
jay@ietf.org