[rfc-i] RFC Series Editor -- Job Description

Dave CROCKER dhc2 at dcrocker.net
Tue Nov 30 12:10:10 PST 2010


Based on the draft(s) and various discussions on and off the list, I think it 
might help to view the RSE job as in terms of how it would be described to a 
potential candidate.  This requires characterizing duties in terms of 
responsibilities, authorities, constraints and accountabilities.

I circulated the previous version of this to a few folk who claimed that it did 
not look entirely silly, so I've revised it to try to reflect the latest 
discussions and offer it herewith.

When comments concern details of the description, it will help to include 
alternative phrasing.  That is, where possible, please try to treat this as a 
specification editing exercise...

    - - - - - - - - - -

RFC Series Editor -- Job Description

      [[  This is intended to explain the job to prospective candidates.  ]]
      [[  It is not a complete description of the RFC Editor service.     ]]

The Internet community has published a freely-available, online series of
technical memos, known as Requests for Comments (RFCs), since 1969.  RFCs range
widely in their coverage, from minutes of technical meetings, to formally
approved Internet standards, to documentation of technical paths not taken, to
humor.  RFCs are edited, published and archived by the RFC Editor service.
Approximately 6000 documents are in the RFC archive, with a flow of
approximately 30 new documents per month.

The RFC Series Editor (RSE) is the primary point of contact and has overall
responsibility for the RFC Editor service, covering the entire range of its
activities and including pursuit of enhancements to it.  In this role, the RSE
must assess and be responsive to the needs of RFC authors and users (readers and
others), as well as supervise the on-going efforts of the Production staff who
prepare documents, and Publisher staff who archive documents and make them
available online.  The RSE ensures adequate service performance according to
typical operations measurements, such as quality, reliability and efficiency,
and handles problem escalations, as well as pursuing changes to improve
performance, as needed.

The RSE reports to a member of the Internet Architecture Board (IAB).  An RFC
Oversight Committee (RFCOC) provides formal, on-going review, guidance and
assistance to the RSE.  Major decisions are pursued through advice-and-consent
with the RFCOC and require IAB approval; they might also require assessment of
broad-based community support.  The RSE may choose to recruit informal
assistance from community experts, as needed.

The contents of RFCs originate in one of several editorial Streams, such as
the Internet Engineering Task Force (IETF) Stream and an Independent Stream.
Each Stream is primarily responsible for the content of its RFCs and has review
processes in place to ensure the quality of that.  The RSE works closely with
the Streams, to ensure that RFC Editor policies and procedures are responsive to
the needs of the Streams and that the Streams are conforming to these policies
and procedures.

In the case of cross-stream disagreements, the RSE arbitrates the first-level
of resolution effort.  The RSE's decisions may be appealed to the IAB.

Activities of the RFC Editor, functional activities within the RFC Editor, and
the requirements for documents submitted to the RFC Editor are each described
in related style, policies and procedures manuals.  Their content is developed
by the RSE, with advice and consent of the RFCOC, as well as input from the Streams.

The RSE identifies and documents the different constituencies that consume
RFCs, such as product developers, other standards groups, and library
services.  The RSE works with them to ensure their familiarity with the
details of the Series and that RFC Editor services are responsive to the needs
of these consumers.  This includes specifying enhancements to the RFC Editor
online services and possible enhancement to the form or style of RFCs.

Initial engagement for the job of RFC Series Editor will be for two years.

    - - - - - - - - - -


   Dave Crocker
   Brandenburg InternetWorking

More information about the rfc-interest mailing list