Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07)

Mirja Kuehlewind <ietf@kuehlewind.net> Mon, 03 January 2022 13:44 UTC

Return-Path: <ietf@kuehlewind.net>
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 478CC3A07A2; Mon, 3 Jan 2022 05:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 X-I3A8zRHpZi; Mon, 3 Jan 2022 05:44:06 -0800 (PST)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (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 E081C3A07A0; Mon, 3 Jan 2022 05:44:05 -0800 (PST)
Received: from p200300dee733e700114c3388f1dd340c.dip0.t-ipconnect.de ([2003:de:e733:e700:114c:3388:f1dd:340c]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1n4Nd2-00013Q-Hv; Mon, 03 Jan 2022 14:44:00 +0100
From: Mirja Kuehlewind <ietf@kuehlewind.net>
Message-Id: <A1A5EDBA-7598-4E74-ACEE-B7A39A8010F5@kuehlewind.net>
Content-Type: multipart/alternative; boundary="Apple-Mail=_BD9A5F71-5AE0-46CF-8265-3E8804368538"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Mon, 03 Jan 2022 14:43:59 +0100
In-Reply-To: <7D28CA5F-594B-4212-9155-86669654A504@ietf.org>
Cc: rfced-future@iab.org, Eliot Lear <lear@lear.ch>, Michael StJohns <msj@nthpermutation.com>
To: Jay Daley <exec-director@ietf.org>, John C Klensin <john-ietf@jck.com>
References: <F0016CA1725A561034951054@PSB> <7D28CA5F-594B-4212-9155-86669654A504@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1641217446;60c8c9ca;
X-HE-SMSGID: 1n4Nd2-00013Q-Hv
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfced-future/j3XX_-Fj-Cm09ezjP4TUb96Cds4>
Subject: Re: [Rfced-future] Filling the RSCE position (was: Re: Comments on -07)
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, 03 Jan 2022 13:44:11 -0000

Not sure I can add much to this discussion which has not been said before but as I hope this might help, here is my view. 

This is the text in draft:

"The IETF LLC will form a selection committee, including members from the community, that will be responsible for making a recommendation to the IETF LLC for the RSCE role.”

I think the important point of this text is that not the selection committee makes the final decision but the LLC Board which is a group of community selected volunteers. Yes, usually the LLC will likely follow the recommendation from the selection committee but they also have to provide proposer justifications to the LLC. The role of the search committee really is to support the LLC Board with additional expertise and it’s the LLC Board that knows best which additional expertise is needed. As such I think I’m okay with what is written in the draft currently.

However, I would also like to note that th text says the LCC Board forms the selection committee and not the ED. While these are internals on how the LLC Board manages itself, I would assume that’s rather a job for the LLC Board chair with approval of the whole (community-selected) board than the ED. This issue was discussed and confirmed (changing responsibility from the ED to the whole LLC board in GitHub issue #40).

If the ED would be the sole one to select the committee I would be more concerned because I think it’s easy (and often happens naturally) to select people with a certain bias if selected by only one person. But that’s not the process as specified to my understanding.

I guess we could add a few more words about who/which group of people should be considered to be on the committee but not sure that is really needed or very helpful. I raised issue #111 asking about the textual difference of the RSCE selection committee vs. the RPC selection committee. For we RPC selection committee we explicitly say that the ED is part of this committee and the stream approving bodies are consulted. It was confirmed to me that this difference was on purpose. 

I also hope that the LLC Board would anyway consult with the RSAB in such matters. So I’m have no concern with the additional text proposed by Eliot. However, I hope that the LLC Board would also consult about other (finical) topics that are relevant or the RFC series and the RPC with the RSAB. Not sure if we really need to say more about this explicitly.

Mirja



> On 29. Dec 2021, at 20:50, Jay Daley <exec-director@ietf.org> wrote:
> 
> John
> 
> I agree, the current model does make the ED the sole arbiter of who meets the criteria to be on the appointment committee and I can see why you might have concerns that this could be misused.  I have no objection to any checking mechanism for this, such as your proposed check with the RSAB but please note, that would likely delay the appointment of the RSCE by ~3 months because this process cannot then start until the RSAB is seated.  I also btw, have no objection to the committee being chosen entirely separately from me.  The one thing I would ask if we go that path is that we document, as briefly as possible, the knowledge those people are expected to have.
> 
> My plan, as previously noted, was to come to this list with a proposed committee and get feedback that way, as I am obliged to do by section 4.4 or RFC8711 (which is phrased much stronger than an aspiration, but that’s a conversation for another time). Of course, as you have explained,  if this is not specified in the process then there is a possibility that another ED might not do that.
> 
> Even if we don’t put any of those safeguards in place, I will continue to find this appointment process disproportionate given that the processes for appointing the RPC, Secretariat, and Tools Team PM, all of which probably have more impact than this new role, are nowhere near as deeply specified.  
> 
> Jay
> 
> (PS. This is likely to be my last post until Jan 24th as I start my summer vacation later today).
> 
> 
> -- 
> Jay Daley
> IETF Executive Director 
> exec-director@ietf.org
> 
>> On 30/12/2021, at 6:04 AM, John C Klensin <john-ietf@jck.com> wrote:
>> 
>> 
>> 
>> --On Wednesday, December 29, 2021 15:06 +1300 Jay Daley
>> <exec-director@ietf.org> wrote:
>> 
>>> Briefly, this has become one or two orders of magnitude more
>>> complex than is required for this role (remembering that the
>>> role as written is very different from the previous role).
>>> The overriding priority for committee members should be that
>>> they understand this new role and will therefore find someone
>>> who fits this role rather than the previous role.  I've
>>> regularly pushed back on having ex-officio appointments to the
>>> selection committee because, from what I've seen so far, the
>>> number of people who properly understand this new role is
>>> actually quite limited in number. Picking a random IAB/IESG
>>> person who isn't one of those means the committee has to
>>> work much harder to bring them to speed. 
>> 
>> Jay,
>> 
>> Setting aside Stephen's reaction (and my similar one), whatever
>> nostalgia I may feel for the old way of doing things and, hence,
>> the old RSE role, had nothing to do with my comments.  I think I
>> understand the new role.  It is clear from the above that my
>> understanding is almost certainly different from yours.  I got a
>> hint of the differences from your "de facto" note, but this note
>> from you makes the difference much more clear.
>> 
>> The more important comment above is about people who "properly
>> understand this new role".   While I agree that is important,
>> the above, combined with your proposed sole control of the
>> selection committee and other aspects of the hiring process,
>> would appear to set you up as the sole arbiter of "proper
>> understanding" as well as of the entire hiring and selection
>> process.  I'd have a problem with that sole arbiter role even if
>> I was confident that our understanding agreed.  
>> 
>> I also note that I dud not say anything about an ex-officio
>> appointment to the selection committee.  I don't remember anyone
>> else suggesting that either.  I think that makes "Picking a
>> random IAB/IESG person..." entirely a red herring.
>> 
>> I think the new role is going to be much harder than the old one
>> because it requires, not only bringing a high level of expertise
>> to the table, but of educating and persuading people about the
>> implications of opinions formed on the basis of that expertise
>> rather than being able to simply acting with authority when they
>> think the time is right for that.  We've removed the implicit
>> requirement for management experience from the role but not the
>> requirements for in-depth expertise and understanding.  Assuming
>> the personalities are right, that education and persuasion role
>> will be easier for someone with more experience and knowledge to
>> draw upon than for a more junior person whose input might be
>> less persuasive.  I'm expecting someone in that role who is
>> capable of offering real advice based on their observations of
>> what is going on, and doing so proactively, not just someone who
>> is going to sit around waiting for questions or being presented
>> with things and nodding approvingly. 
>> 
>> We haven't clearly defined that role or the requirements in the
>> document other than to say "an expert in technical publishing"
>> and "senior technical publishing professional who will apply
>> their deep knowledge of technical publishing processes to the
>> RFC Series" but even those are fairly high requirements.  At
>> least as I read them, they set a far higher bar than your de
>> facto list.  The role would change significantly if the document
>> said that the RSCE was expected to speak only when spoken to and
>> to answer questions only if they are asked by, e.g., the RSAB,
>> RSWG, or ED but I can't find such text.  Based, among other
>> things, on experience doing some consulting for an important
>> technical publisher and interacting with them over decisions
>> similar to those the RFC Series has faced and will face and on
>> experience with the RFC Series that had more to do with strategy
>> than about roles and how they were defined (RFC 4846, 4897,
>> etc., notwithstanding) and participation in the last search
>> process (relevant not because I think the roles are the same but
>> because those qualifications for expertise and deep knowledge
>> are a subset of the criteria the last time around), I think the
>> position is going to be very hard to fill.  Based on that same
>> experience and perspective I think that, if a selection is made
>> on the basis of nothing more than your de facto criteria and
>> ability to work well with you, we are not going to end up with
>> the person in that role that many (at least) of us believe the
>> phrases quoted above require.
>> 
>> Speaking only for myself, if we are not going to put someone in
>> that position who has enough experience and perspective to exert
>> real influence --not just answer technical publication questions
>> that I'm confident the RPC could handle, at least if they are
>> not micromanaged (but might or might not want to), we should
>> reduce the complexity of the new model by just getting rid of
>> the RSCE position. 
>> 
>> Now, I don't know what you are picturing and it is probably time
>> that you be much more explicit about it.   But, unless you can
>> explain your "proper" understanding of the role --not just
>> identify what you call de facto requirements and then
>> hand-wave-- and there is consensus (at least rough) about that,
>> I think we have three choices (the third of which I hope no one
>> likes):
>> 
>> (1) We review our collective expectations of the position and
>> write enough of a description and set of qualifications into the
>> document to provide much of the content of a job posting or RFP
>> without leaving you or your successors as sole arbiters of what
>> the position is about.
>> 
>> (2) We provide some (mandatory) mechanism for input into, or
>> review of, the selection committee membership to make sure that
>> diverse perspectives are represented by competent people who are
>> willing to work together.  Eliot sees some issues with my
>> version and I see some issues with his but I don't see much
>> point in further discussion of those differences unless we can
>> get the selection process away from the idea of you (with or
>> without discussion within the LLC) being sole arbiter (subject
>> only to your interpretation of the few words in the document) of
>> what the position is about and what sort of qualifications are
>> needed in someone who is selected.
>> 
>> See "obnoxious postscript" below for (3).
>> 
>>> I fully understand the depth of trauma some felt about the
>>> previous role and that the scars are still fresh, but this is
>>> a very different role and we don't need to overthink it. 
>> 
>> Whether I think you understand that or have the experience to
>> make the judgment is probably irrelevant as is your claim on the
>> subject.  It is a very different role.  Maybe I haven't been
>> watching closely enough but, at least in the last few months,
>> I've seen no signs of anyone who does not understand that and
>> think it is very different.   And that is what I've said
>> multiple times: another thing that made the old role possible to
>> fill by relying on tradition is that the tradition and
>> precedents were there and clear to those most involved,
>> something that is not the case for this new and very different
>> role.  
>> 
>> To use an example so deliberately exaggerated that I hope no one
>> will think it is a proposal or serious suggestion, one way to
>> avoid trying to carefully define it would be to appoint Donald
>> Duck to the role for a moderately short term, watch the ways in
>> which his performance is or is not successful, and then revise
>> our expectations and then either eliminate the position (because
>> his failures didn't make any difference) or write a job
>> description based on what we had learned by the end of that
>> period.  While I don't think anyone you would be likely to
>> recruit and hire (with or without a selection committee you
>> control) would perform nearly as badly as I would expect from
>> said duck, appointing someone unqualified (however accidentally)
>> and then learning from the experience is not an experiment I
>> would choose to perform if we can avoid it.
>> 
>> best,
>>  john
>> 
>> Obnoxious postscript:
>> 
>> There is another way of looking at this, one I mentioned some
>> time ago in the context of an "ultimate authority" discussion
>> and that, IIR, no one found helpful.  Let me try again, both to
>> make a strawman counterproposal and to put my suggestion in a
>> different light.  The note quoted above reinforces the relevance
>> of mentioning it.  As this system has evolved and in the last
>> analysis, the LLC is in charge of almost everything.  They
>> control the budget for anything that involves either work or
>> money.  They contract for, evaluate, manage, and control the
>> RPC.  While I would not expect it to ever happen, they could
>> even deny publication for a particular document, approved by
>> some stream, by forbidding the RPC to invest any resources in
>> it.  If the RSWG and RSAB propose a policy change, they can say
>> "too expensive", "no budget", or "not something we are willing
>> to manage" and there is no appeal.  They control the RSCE
>> selection, hiring, and evaluation processes and, if it suits
>> their needs, convenience, or management style, could easily (and
>> perhaps inadvertently) reduce that position to something very
>> low-level with no influence on anything except to advise them
>> when they decide they want advice.  For those reasons, if there
>> is a difference of opinion about what some provision of the
>> "Model" document or other community-written specifications mean
>> (not limited to the understanding of the RSCE role) and the
>> community does not persuade them to change their view, their
>> opinion will ultimately prevail.  While they engage in
>> consultations and other ways to measure community opinions and
>> their own performance, they ultimately make the final decisions
>> and are ultimately accountable to no one other than themselves
>> (with the possible exception of the ISOC Board and the only
>> option there, if it exists at all, would be very drastic).
>> 
>> We are, of course, protected from a grim version of that picture
>> by the moral and ethical obligations that the LLC Board and
>> Staff, especially the Executive Director, feel to the community
>> and community consensus but those obligations are, to use ekr's
>> term, aspirational, not anything that is legally binding or
>> enforceable.
>> 
>> Given that description, which I believe summarizes the actual
>> reality, perhaps what we should do with this Program is to
>> declare success, thank Peter and the Co-chairs for their
>> efforts, drop this fairly complicated "Model" document
>> (including the RSWG and RSAB ideas), and replace it with an
>> extremely short one that reaffirms the Streams, their
>> relationships, and their independence of each other in terms of
>> what is to be published.  It would then say that the policies of
>> the RFC Series and production of documents are ultimately
>> administrative and financial matters to be managed, contracted
>> or hired for as needed, and generally decided upon, by the LLC,
>> encouraging them to engage in consultations with the community
>> or selected subsets of it as they deem appropriate.
>> 
>> I don't believe we should do that but it raises questions that
>> may be worth thinking about.  And, again thinking about ekr's
>> comments and the reality that almost nothing in the document is
>> actionable (other than giving people new and different titles or
>> affiliations) without LLC decisions; decisions that the LLC has,
>> in principle, the option of not making. Given that, maybe we
>> should be engaging, not in relitigating issues that made sense
>> under the assumption that this Program had authority and could
>> define an RSWG, RSAB, and other roles and put them in charge but
>> recognizing that there is no "in charge" other than the LLC.  If
>> those roles are ultimately meaningless except to give
>> non-binding advice to the LLC, perhaps the whole arrangement is
>> much too complicated are likely to be far too expensive of the
>> time of those involved, especially those who might otherwise be
>> working on agendas more directly connected to the development of
>> Internet technology. 
>> 
>> I did say "obnoxious", didn't I?
>> 
>> 
>> 
>> 
>> 
>> -- 
>> Rfced-future mailing list
>> Rfced-future@iab.org
>> https://www.iab.org/mailman/listinfo/rfced-future
>> 
> 
> -- 
> Rfced-future mailing list
> Rfced-future@iab.org
> https://www.iab.org/mailman/listinfo/rfced-future