[rfc-i] RSE and RAOC: IAB state, developing consensus, and strawman.

Olaf Kolkman olaf at NLnetLabs.nl
Fri Jan 21 15:34:06 PST 2011

This is a long mail, sent in my role as IAB chair and moderator.

There are a number of aspects that define the discussion space at this
moment: A, B and C. Further detailed below. It seems that we can call
closure to A as a rough consensus is appearing.  B should be seen as a
request to explore if there is consensus to be found along the lines
described below. For C the IAB has no internal consensus yet and we
have not been able to find consensus in the community. Yet issue C is
the central to this reorganization.

A) Policy, Community, and Committee

The discussion about policy development and the role of the RSE vs
that of an RAOC has been an important aspect of the discussion.

That discussion appears to be driven by the need to guarantee
sufficient community control over the RFC series policies. (In this
context policy should be read as any important issue for which
community review/feedback is required.)

Everybody participating in that discussion seems to agree that there
is a role for the RSE to do a lot of the actual policy development
handiwork and that the oversight responsibility needs to be performed
by people that have an understanding of the issues and a stake in the

It appears that a rough consensus is developing about the role of the

- It is a group organized by the IAB. (This group works closely with
  the IAB, we currently use the name program, but directorate,
  project, or task force could be other labels for this beast).

- The committee is responsible for assessing whether due process has
  been followed in developing policies and to assess whether consensus
  has correctly been called.

- The RSE is responsible for facilitating RFC policy development and
  discussions (Policy proposals are not the exclusive territory: of
  the RSE anybody from the community can make proposals.)

- The committee has members that have direct interest (e.g.  members
  that represent the streams) but also expert members (publication,
  managerial, financial, or other relevant expertise). There is still
  the question about how normative the description of members should

- The RAOC is also responsible for overseeing the boundary where RSE
  operational decisions stop being operational and begin being policy

- The RAOC is not responsible for operational matters.

It is important that the RSE can operate autonomously and does not
have to go back to the community for every single detail. In practice
the RSE will need to work with the RAOC to define the type of
decisions for which community feedback is needed. The RAOC will have
to work with the IAB to define how much of the IAB's responsibilities
are asserted by the committee. The interaction, relations and
responsibilities between the RAOC and the RSE and the RAOC and the IAB
will be subject to evolution.

B) Operational responsibility and the IASA.

The RSE is responsible for the day to day operational coordination
between the RFC functions (production, publication, streams etc) while
the IASA is responsible for the contracts they be developing in close
cooperation with the RSE.

The IAB has interpreted Glenn's current proposal and subsequent
discussion to zoom into a model with the following key properties

- IASA remains responsible for budgets and contracts
- the RSE provides input to budgets, statements of work, candidate
  selection processes. Cooperation between RSE and IASA is assumed
  with the IAB as mediator/final authority. The RSE performs annual
  reviews which are then provided to IASA.
- The RAOC, performs annual reviews of the RSE 
- the RSE has operational responsibilities and manages
  priorities. When the RSE needs to take extra-budgetary or out-of
  contract measures those actions must to be coordinated with IASA.

The IAB believes a rough consensus around this approach exists and
wants to test that assertion by asking your feedback.

C) The roles of an RSE

The discussion about the role of the RSE is one that we have cast in
terms of a scale. That is to say, the role of the RSE is not a
black/white type of definition.

At the left of the scale we place a type of editor that has a strong
background in the IETF engineering community. A person that knows
about RFC production, understands the processes and conventions in the
larger Internet community environment. The role concentrates towards
managing priorities and peculiarities between the different streams.

At the right side we place a type of editor that has a strong
background in technical publishing, possibly in the field of technical
standards publication. Somebody who understands how to develop a
technical series, has experience with the editorial issues that come
with the development of a style guide for a technical document
series. Somebody that understands the issues that come with
maintaining a reasonable level of comprehensiveness in documents
written by non-native English speakers. Or, understands the issues
that come with translation from English (by native and non-native
speakers of English) into other languages. The role concentrates
towards managing stream agnostic issues.

Within the IAB there is a general consensus that a mature RSE that
would ideally perform the job roughly in the middle of these two
extremes. There is also a general IAB consensus that looking for an
IETF person with significant publication experience, or a person with
publication background with significant IETF experience will get us
nowhere. In fact, wanting the best of both worlds is what got us in
the situation. (While it does not get us closer to a solution it would
be good to know whether these 2 IAB consensus positions resonate with
the community. think the IAB is making a fundamental mistake it would
be good to let us know.)

So while it is clear that we should be focusing our search to a person
that is either to the right or to the left of the spectrum we have not
developed a consensus on which role that should be. (Glenn's
recommendation's are strongly leaning to the right hand side of the

The right vs left discussion easily slips into a debate on the RFC
Series as an IETF brand or the RFC Series as a more or less
stand-alone entity in the larger Internet community. That discussion
has taken place a number of times over the last years and those
discussions have concluded with maintaining that the series' nature is
more towards being a stand-alone entity in the larger Internet
community. That discussion is out of scope.

On the other hand, the IAB has no explicitly documented strategy for
the development of the RFC series that could help us to answer the
question of a right vs left type role for the RSE (RFC4844 is very
explicit in building a framework but never elaborates on 'where the
series should be in 20 years', it doesn't address the 'editorial
vision' so to say).

The above summarizes the IAB discussion so far.

In order to get this resolved I want to put forward a straw-man.  My
goal is whether we can answer the left-right question and move forward
while dodging a time consuming agenda.

The strawman is close to Glenn's recommendation except that it defines
a few concrete goals for the first RSE.

We seek a person on the right hand side of the spectrum i.e.  somebody
with technical publication background.

The first assignment, documented in the SOW, is to develop a vision
for the RFC series that takes into account that:

- the series is an evolving technical specification series,
  historically by engineers for engineers;
- the landscape is slowly changing in terms of publication and
  archiving techniques;
- the community that depends on RFCs (in production and consumption)
  is slowly changing into a multi-lingual non-native English

That vision is developed in close cooperation with the community.

Another key task the SOW is to create documentation and structures
that allows continuity for the production house function;

(there are probably a few more considerations).

The first RSE is _not_ interim, and is tasked with bringing
Publication experience to the community. This is significantly
different than the role we envisioned for the TSRE, who was tasked to
focus on management analysis. 

Within the current model there is a lot of room for cooperation with
the community through the RAOC. The RAOC should take the
responsibility to work with the RSE to make sure the vision is
developed in cooperation with the community.

The benefit of this model is that an experienced Publication person
can most probably bring clarity on the technical aspects that are
needed to be in place for long term production continuity. Such a
person would also be able to bring a number of publication aspects to
the table that are relevant for the series that the community has thus
far not considered.

When a left side person would be hired the same responsibilities could
be in the SOW, but it is more likely that the focus may be less on
developing an Editorial vision and more on the pragmatics of
developing the style manual and the processes for cross-stream
coordination. Obviously our mileage may vary.

What is important is that we allow this system (RSE+RAOC) to develop
towards the middle of the scale. If we can make that happen in a few years
(which is realistically the timescale on which an editor from right or
left would develop). I believe that the current model has sufficient
checks to prevent an RSE to go rogue so there is little to lose.

The effect on the line-item on the IAOC budget for a right vs left
person is hard to assess. Both come with 'hidden costs' in terms of
volunteer cycles and continuity risks. I wouldn't want to speculate
at this point.

I appreciate your thoughts on this.

--Olaf Kolkman
 IAB chair and moderator.

PS: there is no need to crosspost to the IAB list for replies. The discussion on
RFC-interest is being tracked.


Olaf M. Kolkman                        NLnet Labs
                                       Science Park 140, 
http://www.nlnetlabs.nl/               1098 XG Amsterdam

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2210 bytes
Desc: not available
URL: <http://www.rfc-editor.org/pipermail/rfc-interest/attachments/20110122/01b30334/attachment-0001.p7s>

More information about the rfc-interest mailing list