Subject: [Rfced-future] Hires/contracts/selects/nominates/appoints

From: "Adrian Farrel" <[email-masked]>
Date: Wed, 24 Jun 2020 23:36:54 +0100

Hi Brian,

> 2. Who hires/contracts the RSE?
> Also seems like we can likely wrap this up quickly on-list.  I sense the current
> direction is the LLC.  Brian offered some options.  If you think it should be
> some entity other than the LLC, please speak up.

I tried before but maybe got lost in the noise.

I think the question as phrased has ambiguities.

Hires != Contracts

I have no issue with the LLC holding the contract and even doing any necessary contract negotiation.

But:
- who writes the job spec and sets out the fundamentals of the contract?
- who reviews the applications?
- who short-lists?
- who interviews?
- who comes up with a preferred candidate?
- who ratifies that candidate?

All of that MIGHT [RFC6919] be covered by the term "Hires" in which case (and meaning no offence to the LLC) I don't think the LLC has the necessary experience to perform the task.

Cheers,
Adrian

---

From: Brian Rosen <[email-masked]>
Date: Wed, 24 Jun 2020 18:49:10 -0400

In the additional questions:
C. Who recruits/interviews/selects/appoints the RSE?

> On Jun 24, 2020, at 6:36 PM, Adrian Farrel <[email-masked]> wrote:
> 
> Hi Brian,
>

---

From: Jay Daley <[email-masked]>
Date: Thu, 25 Jun 2020 10:56:07 +1200

> On 25/06/2020, at 10:49 AM, Brian Rosen <[email-masked]> wrote:
> 

This is currently specified in RFC 8728 section 3.1

Just a reminder that there is no documented statement that explains why that existing process needs to be replaced.

Jay

> -- 
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
> 

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jun 2020 14:20:38 +1200

On 25-Jun-20 10:56, Jay Daley wrote:
> 
> 
>> On 25/06/2020, at 10:49 AM, Brian Rosen <[email-masked] <mailto:[email-masked]>> wrote:
>>

Well, just to be clear, my firm assumption is the RSOC will be abolished as result of our endeavours here. If not, we might as well give up now.

More later, I'm in a rush right now.

    Brian

> 
>>
>>> On Jun 24, 2020, at 6:36 PM, Adrian Farrel <[email-masked] <mailto:[email-masked]>> wrote:
>>>
>>> Hi Brian,
>>>
>> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Jun 2020 20:00:04 -0700

On Wed, Jun 24, 2020 at 7:20 PM Brian E Carpenter <
[email-masked]> wrote:

> > Just a reminder that there is no documented statement that explains why
> that existing process needs to be replaced.
>
> Well, just to be clear, my firm assumption is the RSOC will be abolished
> as result of our endeavours here. If not, we might as well give up now.
>

That seems like a pretty big assumption. I mean, that might be the outcome,
but there's nothing in the charter that pre-decides that.

-Ekr

---

From: Doug Royer <[email-masked]>
Date: Wed, 24 Jun 2020 21:16:52 -0600

> More later, I'm in a rush right now.

A very clear goal.

-- 
Doug Royer - (http://DougRoyer.US) [email-masked] 714-989-6135

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 25 Jun 2020 17:14:20 +1200

> Well, just to be clear, my firm assumption is the RSOC will be abolished as result of our endeavours here. If not, we might as well give up now.

Let me expand on that. Also, please understand that I am not criticising the RSOC members, any more than we criticised the IAOC members for the way the IAOC got locked into micro-management. Both those committees were set up with the best intentions, but I'm afraid they were set up to fail. One of the reasons is that as I already said once today, engineers are bad at overseeing non-engineering tasks and have a tendency to get bogged down in details. We've made a serious effort to avoid that problem in the LLC/LLC Board setup, and we need to do the same for the RFC Series. As far as I can see, having the LLC in charge of performance-based contracts for RFC production and publishing services takes away all that side of things from the RSOC, and that's a good thing. So (whatever RFC 8728 says) a large part of the RSOC's job has simply gone away.

What remains is the part that visibly went dramatically wrong and led to Heather's resignation, i.e. selection and "oversight" of the RSE.

RFC8728 says:
 
> 3.1.  RFC Series Oversight Committee (RSOC)
> 
>    The IAB is responsible for the oversight of the RFC Series...

I believe this statement (copied from RFC6635) has caused us tremendous trouble. It's not at all what the IAB charter (BCP39, aka RFC2850) says:

>    The IAB must approve the appointment of an organization to
>    act as RFC Editor and the general policy followed by the RFC Editor.

That's all that is sanctioned by a BCP and it doesn't say "oversight". In delegating responsibility to the RSOC, the IAB also annexed some territory: "oversight of the RFC Series". That's a big deal and it is (IMHO) the crux of the matter. I think the events of the last year or so show that we need to walk this back. One way is to simply remove all reference to the RFC Series from the IAB charter, and therefore abolish the RSOC. Then constitute a separate Editorial Board for the RFC Series, along the lines that Mike proposed, answering to the community.

Alternatively, walk back the IAB to its chartered role, but reduced to allow for the fact that contracting for the production and publishing services is now LLC business. Something like:

>    The IAB must approve the appointment of a person to
>    act as RFC Series Editor and the general policy followed by the RFC Series Editor.

By the nature of things, that also leads to abolishing the RSOC.

Personally, I much prefer a new, independent Board because I'd like to see the IAB able to focus exclusively on, er, Internet Architecture.

In any case the statement in the IAB charter cannot be taken too seriously any more. It was drafted to take account of current reality in early 2000.

I certainly expect this group to propose *major* changes to RFC8728 and a relatively minor change to the IAB Charter.

Regards
    Brian C

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Jun 2020 09:58:37 +0100

Just cos it is in an RFC doesn't mean it can't be changed.

Our charter is:
| This program is intended to foster discussion and consensus on
| potential changes to the RFC Editor model.  Discussion of changes
| to how the RFC Editor function is managed, staffed, and overseen
| are all within scope.  After the group has come to rough consensus,
| it will document its output in one or more RFCs.

I read that as meaning that discussing this point is within scope.

The lack of a "documented statement" explaining why change is necessary is a
good observation. Change for the sake of change can lead to risky outcomes.
On the other hand, exploring the current process and its results and
stresses could lead us to determine that there is a need for change.

We might end up with a statement that "the process for selecting and hiring
the RSE is as described in Section 3.1 of RFC 8728." But we might now. As
has been pointed out (plenty) if what we do results in the RSOC going away
or changing considerably, then that section of that RFC will not hold.

But in any case, and to reiterate, what we are doing is looking at the
process and responsibilities. Saying that they are already documented in an
existing RFC is useful historical information, but does not dictate our
discussions of the future, nor preform our consensus.

Thanks,
Adrian

---

From: Jay Daley <[email-masked]>
Date: Thu, 25 Jun 2020 23:23:18 +1200

> On 25/06/2020, at 8:58 PM, Adrian Farrel <[email-masked]> wrote:
> 
> 
>> 

I hope it is clear that’s not what I meant. And in case my pushing of this point is giving the impression that I favour the status quo, I should be clear that I have no view one way or the other. 

What I was trying to say is that a lot of work has gone into answering some of these questions already documented as community consensus and I would suggest that means that a clear reason needs to be given as to why a change is needed. Even now the only explanation I’ve heard as to why a structural change is needed is because there is a view that that any community body charged with oversight will inevitably get too far into the details and interfere with the autonomy of the role, which I find a particularly weak argument. In fact there’s nothing I’ve heard about the history to date, which is what is driving all of this, that could not be equally explained by a breakdown between people, as by a breakdown of the structure. 

Jay

-- 
Jay Daley
IETF Executive Director

---

From: Eliot Lear <[email-masked]>
Date: Thu, 25 Jun 2020 13:45:31 +0200

Hi Jay,

> On 25 Jun 2020, at 13:23, Jay Daley <[email-masked]> wrote:
> 
> 
> What I was trying to say is that a lot of work has gone into answering some of these questions already documented as community consensus and I would suggest that means that a clear reason needs to be given as to why a change is needed.

---

From: Eliot Lear <[email-masked]>
Date: Thu, 25 Jun 2020 13:55:12 +0200

[second try]

> What I was trying to say is that a lot of work has gone into answering some of these questions already documented as community consensus and I would suggest that means that a clear reason needs to…

I firmly believe this group should articulate the reasons for is decisions.  However, I do not think that necessarily means that we have to address the previous consensus.  We can do that, but we needn’t.

But more on this in a bit.

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 25 Jun 2020 13:08:53 +0100

> I hope it is clear that’s not what I meant.

Well, it wasn't to me. But I accept what you say below.

> And in case my pushing of this point is giving the impression that I 
> favour the status quo, I should be clear that I have no view one way
> or the other. 

Fair enough.

> What I was trying to say is that a lot of work has gone into answering
> some of these questions already documented as community consensus

It is true that a lot of work and discussion went into this in the past. But while RFC 8728 was worked on by a WG it is only an editorial update of RFC 6635 and does not have IETF consensus. Furthermore, RFC 6635 (published in 2012) is an IAB document and does not have IETF consensus. And RFC 5620 (published in 2009) that was replaced by RFC 6635 was also an IAB document and did not have IETF consensus.

So, yes, a lot of work was done and that certainly attempted to bring the community along with the decisions. But, no, none of this is documented as community consensus.

> and I would suggest that means that a clear reason needs to be given
> as to why a change is needed.

I agree. We should understand both why we need to make a change and what the desired outcomes are.

> Even now the only explanation I’ve heard
> as to why a structural change is needed is because there is a view that
> that any community body charged with oversight will inevitably get too
> far into the details and interfere with the autonomy of the role, which
> I find a particularly weak argument. 

It is possible (although maybe hard to believe) that people are trying to be delicate. Certainly, no one wants to point fingers. But let's phrase it this way...

We screwed up. The fact that an RSE that the community thought was doing a fine job, felt that the only recourse left was to resign, is a massive failing. I would argue that the processes in place should not have let things get to that situation: they should have detected the conflicts sooner, voiced them properly, established whether there was a failure of delivery, of recruitment, of management, or of agreement with strategy, and they should have worked for resolution.

It is unclear whether a structural change is needed so that doesn't happen again. But I see nothing that suggests it would not happen again without change. Whether the change is minor (such as watch the watchmen [pardon the gender specificity]), more significant (like how the watchmen are appointed), or more fundamental (like a change in structure) can be debated.

> In fact there’s nothing I’ve heard about the history to date, which
> is what is driving all of this, that could not be equally explained by
> a breakdown between people, as by a breakdown of the structure. 

That last point bothers me. It is possible that you and I are hearing different versions of history: history is very subjective and we learn it from our echo chambers. But please don't misread the level of distress in some quarters of the community about how we got here and why we even need this program. (On the flip side, I would cheerfully concede that the bulk of the community simply want accessible RFCs published in a readable format in a timely manner.)

Best,
Adrian

---

From: Jay Daley <[email-masked]>
Date: Fri, 26 Jun 2020 07:39:13 +1200

> On 26/06/2020, at 12:08 AM, Adrian Farrel <[email-masked]> wrote:
> 

Ah, my mistake - thank you for explaining that.

> We screwed up. The fact that an RSE that the community thought was doing a fine job, felt that the only recourse left was to resign, is a massive failing. I would argue that the processes in place…

That is a great problem statement.

> That last point bothers me. It is possible that you and I are hearing different versions of history: history is very subjective and we learn it from our echo chambers. But please don't misread the…

I don’t mean to belittle the concerns that people have about what has happened, only separate out the distress from the facts, which I think your problem statement above has done very well.

Jay

-- 
Jay Daley
IETF Executive Director
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Thu, 25 Jun 2020 12:25:57 -0700

Dear Mr Daley,
At 04:23 AM 25-06-2020, Jay Daley wrote:
>What I was trying to say is that a lot of work has gone into 
>answering some of these questions already documented as community 
>consensus and I would suggest that means that a clear reason needs 
>to be given as to why a change is needed. Even now the only 
>explanation I've heard as to why a structural change is needed is 
>because there is a view that that any community body charged with 
>oversight will inevitably get too far into the details and interfere 
>with the autonomy of the role, which I find a particularly weak 
>argument. In fact there's nothing I've heard about the history to 
>date, which is what is driving all of this, that could not be 
>equally explained by a breakdown between people, as by a breakdown 
>of the structure.

I'll disclose that I am a member of the ISEB.

I took at the RFC which was published for informational 
purposes.  The document included a change to describe the 
relationship between the IETF Administration Limited Liability 
Company (IETFALLC) and the RFC Series Oversight Committee (RSOC).  It 
is not a community consensus document.

There is also the following: "For this type of responsibility, the 
RSE cooperates closely with the community, and operates under 
oversight of the RSOC: thus, ultimately, under oversight of the IAB."

The IAB/RSOC/IETFALLC were unable to ensure the stability of the RFC 
Editor function.  The IAB ended up being held accountable for 
that.  Based on the past mailing list discussions, I would say that 
the persons who commented were not receptive to the comments from the RSOC.

During an IETF meeting, the description of the model (or structure) 
was that of a complex system or device whose internal workings are 
hidden or not readily understood.  I was a bit surprised to hear that 
there wasn't any formal Stream coordination.

Does the RSE discuss with the RSOC or the IAB to clarify a significant issue?

Is it that useful to have that number of entities for the RFC Editor?

Regards,
S. Moonesamy