[rfc-i] RSOC name
sbanks at encrypted.net
Mon Aug 12 08:14:29 PDT 2019
I'd like to share a few thoughts on this thread. I acknowledge that I am RSOC chair and that experience colours my feedback, but I'm speaking as a community member, and not for the RSOC here. (this also doesn't mean the RSOC agrees (or disagrees) - just that I wanted to share my thoughts ahead of a discussion with the RSOC).
The nomenclature of oversight aside for a moment, in my time on the RSOC, until recently, things have been incredibly low key. The relationship between RSOC and RSE was good, and that's in part due to the relationship we had in place. The RSE checked in with the RSOC regularly, and was very transparent with work items, areas of focus, efforts under way, and other work/heads up on other projects she had going on. When I first joined the RSOC, because things were so low key, I'd actually asked Heather "why do we have an RSOC"? Her answer was that the RSOC is a succession plan; that when things are going well, it can seem like we don't have a lot to grapple with, and that's a good thing. But should something happen to her, we'd be left standing to help transition the next RSE in. Indeed, if you read RFC6635, the RFC seems to agree very much with Heather's sentiment. I've come to embrace that sentiment, and in particular, value that there was a group of folks who were intended to carry on the tribal and institutional knowledge that would outlast the NOMCOM period of appointments.
So what does oversight mean to me? Within the context of RFC6635, I believe it is our job to support the RSE, support the community's needs, and support the notion that we'll have a continuity of tribal knowledge. The current text of RFC6635 requires 1 overtly managerial task - to perform a performance review of the RSE. The RSOC is supposed to be comprised of individuals with suitable subject matter expertise. We are supposed to approve policy documents that the RSE generates, prepare hiring and firing recommendations to the IAB (including the candidate selection, etc), resolve conflicts of interest, ensure that the RFC Series is run in a transparent and accountable manner, and public our rules of order. All of those items again, point to an RSOC that supports the RSE and helps her/him get the job done. Our job is NOT to micromanage the RSE or the RPC; in fact the RPC is implicitly outside of the purview of the RSOC, unless there are conflicts or contractual problems that arise.
I'll also point out that in my time on the RSOC, until very recently, this has all run very smoothly. We didn't have a problem with the "oversight"; I don't think the RSE did either, and there was no negative feedback from the community. In fact, there was scant feedback at all around anything RSOC/RSE related, short of "we want more chocolate at the RPC table during IETF meetings" :) For me, I'm not convinced that the problem lies entirely within RFC6635 and how it's described today; I'd also point to Heather's first email and how she described her concerns.
All of that said, it doesn't mean we can't evolve, iterate, or change. The direct versus dotted line approach of management described in RFC6635 is a perfect candidate for discussion, in my opinion. The way recommendations are made for hiring/firing/contract selection via the RSOC -> IAB in light of the LLC transition is another candidate for discussion. Whether or not the RSE is a contractor or an employee is another discussion, and to that end, the language around the performance review in the RFC should also be amended. These are starting points for conversation, not the full list. I do believe that the function of the RSOC has been useful, both in the initial goals of serving as a body of knowledge that spans longer than the nomcom churn and looking at the RFC series as a whole, but also the value I believe both we and the RSE found in having a group that the RSE could lean on, set and review goals, report progress, and make amendments with. In that sense, if oversight was defined this way, then there is value in the notion of oversight. Perhaps a way forward would be to more clearly define what's expected when providing oversight.
> On Aug 11, 2019, at 10:45 AM, S Moonesamy <sm+ietf at elandsys.com> wrote:
> Hi Donald,
> [I am sending the reply to the rfc-interest mailing list]
> At 04:15 PM 7/29/2019, Donald Eastlake wrote:
>> I don't think the IAB project model fits very well for the RFC Series
>> and that it should have different governance for which I have some
>> ideas. But I wanted to talk about something else: the power of
>> The key word in RFC Series Oversight Committee is "Oversight". What do
>> people think when they hear "oversight"? They think that a large part
>> the job of whoever has "oversight" is to review and criticize. No
>> doubt the fine print clarifies things but every time someone thinks
>> about or volunteers for or is appointed to the RSOC, it rings the
>> "oversight" gong. Of course there are plenty of worse words than
>> "oversight". I suppose it could have been called the RFC Series
>> Management Committee or something...
> About eight years, there was a thread about the RFC Editor model. Olaf pointed out that the changes which were being proposed would move the RSE away from executive management. I have not verified whether that ended up being what people agreed to.
> I agree with the point which you made about "oversight". The other side of the power is accountability, i.e. the Oversight Committee would be accountable for its decisions. It is not the case here because of the way the committee appointments are made.
>> What if everything else we the same, but it had been called the RFC
>> Series Support Committee? And everytime someone thought about or
>> volunteer for or was appointed to the committee they were reminded
>> that this is about supporting the RFC Series?
> It could be useful to have a reminder about the duties of the members of the committee.
> S. Moonesamy
> rfc-interest mailing list
> rfc-interest at rfc-editor.org
More information about the rfc-interest