[rfc-i] The proper role of an RSE

Dave CROCKER dhc at dcrocker.net
Wed Jan 5 04:46:35 PST 2011


Folks,

I hear reports that the IAB will be focusing on the question of the RSE today 
and thought it worth lodging a simple statement of support for the proposal that 
is on the table.

But unlike most folk in our community, I cannot stop with such a brief, direct 
statement.

So, some elaboration...

For any interesting topic, a variety of reasonable solutions can be developed. 
For any reasonable solution to an interesting topic, there will always be much 
that can reasonably be debated, tweaked or replaced.  The current proposal is no 
exception.

I think the current proposal has three core characteristics that are essential:


1. Incremental change to a model that has functioned well for 4 decades.

    Major change to the organization or management of a critical service always 
carries major, unintended -- and usually undesirable -- side-effects. (For 
reference, that's so well established in in management and organizational 
behavior circles that it is a cliche.)  When there is a compelling reason for 
major change, the side-effects might be justified.  I have not heard any 
compelling reasons put forward to justify major changes to RFC Editor 
management, and the current proposal correctly stays with the established model.


2. An RSE who serves as a central point of responsibility and authority for 
/integrated/ management of the RFC Editor.

    The job of the RSE is considerably more than that of a senior technical 
editor or of a supervisor.  Management is not the same as supervision.  The RFC 
Editor has a complex set of document sources, a complex set of document 
consumers, a continuing need for enhancement and revision to its operation, and 
periodic issues that require policy and design skills that go far beyond 
competent editing.  They require skills at anticipating and responding to 
long-term issues, rather than repetitive performance of immediate tasks. In 
addition, these activities cannot be combined with direct operations or the 
direct operations activities will suffer.  So, different skills and different 
focus are needed.

3.  Revision to the oversight function that adapts to current pragmatics.

    The IAB should not be expected to provide close oversight to the RSE; it has 
neither the time nor -- from what I have heard and seen -- the interest in the 
effort that would take.  And while the IAOC is essential to particular 
activities of the RFC Editor, it's role in the IETF does not seem to be to be a 
good fit to have primary responsibility of oversight for the strategic work of 
the RSE.  A small, specialized body of folks from our community can provide that 
oversight best, IMO.  (Some of what I'm describing differs from the specifics of 
Glenn's proposal.  But as I said, a good proposal can always be tweaked... But 
while I believe the variance I'm suggesting would be an improvement to the 
proposal, I do not think it as essential as items 1 and 2, above.)

My view of the need for an RSE who has overall responsibility for the entire RFC 
Editor is not a desire to return to an earlier, golden age.  The times, the 
people and the community are all quite different.  (Hence the need for the 
oversight committee.)  Rather, the requirement comes from a basic, conservative 
model of management appropriate to any critical operational service.  I don't 
think that we are clever or diligent enough to make a radically different model 
work, nor do I think there are any benefits in such change.

To the extent that there are claims that we've recently been operating under a 
radically different model, I'll note that while the daily work has indeed been 
performed well, the longer-term work of the RFC Editor has not, since no one had 
responsibility to worry about it...

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net


More information about the rfc-interest mailing list