Network Working Group G. Kowack, Ed.
Internet-Draft Riveronce
Expires: April 29, 2011 October 26, 2010
RFC Editor Model Version 2
draft-kowack-rfc-editor-model-v2-00
Abstract
The RFC Editor publishes the Internet's archival series of technical
and informational documents. RFC 5620 defines RFC Editor Model
Version 1, whose implementation began in January 2010. Model 1
divides RFC Editor activities into a number of components, including
the RFC Series Editor (RSE). During 2010, a "Transitional RFC Series
Editor" performed and evaluated the RSE role. Based on direct
experience, extensive discussions with the community, and research,
the TRSE provides this updated version of RFC 5620. This draft
revises the RSE job description, and makes recommendations for the
search and selection process for a permanent RSE. This memo also
clarifies RFC Editor and RSE activities using established approaches
of management and oversight of a publication service, tailored for
the style of the Internet technical community. Careful attention is
paid to ensuring stable operations. This document observes that RSE
responsibilities demand a very high level of editorial and managerial
expertise.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 29, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Kowack Expires April 29, 2011 [Page 1]
Internet-Draft RFC Editor Model (Version 2) October 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Executive Summary: Refinements to the RFC Editor Model . . . . 4
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. RFC Editor Model . . . . . . . . . . . . . . . . . . . . . . . 10
4. RFC Series Editor . . . . . . . . . . . . . . . . . . . . . . 12
4.1. RSE Executive-Level Management . . . . . . . . . . . . . . 13
4.2. RSE General Responsibilities . . . . . . . . . . . . . . . 20
4.3. RFC Series Editor Specific Responsibilities . . . . . . . 26
4.4. RSE Professional Qualifications . . . . . . . . . . . . . 29
4.5. RSE Term of Office . . . . . . . . . . . . . . . . . . . . 30
5. Independent Submission Editor . . . . . . . . . . . . . . . . 30
5.1. Independent Submission Editor General Responsibilities . . 30
5.2. ISE Professional Qualifications . . . . . . . . . . . . . 31
5.3. ISE Term of Office . . . . . . . . . . . . . . . . . . . . 32
5.4. Independent Submission Stream Editorial Board . . . . . . 32
6. RFC Production Center . . . . . . . . . . . . . . . . . . . . 32
7. RFC Publisher . . . . . . . . . . . . . . . . . . . . . . . . 33
8. Committees . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. RFC Series Advisory Group (RSAG) . . . . . . . . . . . . . 34
9. Resolution of Disagreements . . . . . . . . . . . . . . . . . 36
9.1. Disagreements between RFC Editor Components and Model
Participants . . . . . . . . . . . . . . . . . . . . . . . 36
9.2. RSE Review of Inter-Stream Conflicts . . . . . . . . . . . 37
10. Re-Establishing an RFC Editor Stream Capability . . . . . . . 37
11. Future Considerations . . . . . . . . . . . . . . . . . . . . 38
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13. Security Considerations . . . . . . . . . . . . . . . . . . . 38
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 39
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
15.1. Normative References . . . . . . . . . . . . . . . . . . . 39
15.2. Informative References . . . . . . . . . . . . . . . . . . 39
Appendix A. 2010-11 RSE Search and Selection Process . . . . . . 39
A.1. Overview and Criteria . . . . . . . . . . . . . . . . . . 39
A.2. Structure . . . . . . . . . . . . . . . . . . . . . . . . 40
A.3. Stream Appointments . . . . . . . . . . . . . . . . . . . 40
A.4. RSAG Appointees . . . . . . . . . . . . . . . . . . . . . 40
Kowack Expires April 29, 2011 [Page 2]
Internet-Draft RFC Editor Model (Version 2) October 2010
A.5. SSC Regular Member Qualifications . . . . . . . . . . . . 41
A.6. Additional Qualifications for Streams Appointees . . . . . 41
A.7. Additional Qualifications for RSAG Appointees . . . . . . 41
A.8. Non-Voting Members . . . . . . . . . . . . . . . . . . . . 42
A.9. SSC Assistants and Additional Expert Advisors . . . . . . 42
A.10. SSC Approval of Job Description . . . . . . . . . . . . . 42
A.11. Financial and Legal Preparations . . . . . . . . . . . . . 42
A.12. SSC Alignment with RSE Job Description . . . . . . . . . . 43
A.13. SSC Call for Candidates . . . . . . . . . . . . . . . . . 43
A.14. Applications and Short List . . . . . . . . . . . . . . . 43
A.15. Confidentiality . . . . . . . . . . . . . . . . . . . . . 44
A.16. Best and Final . . . . . . . . . . . . . . . . . . . . . . 44
A.17. IAB Process Review . . . . . . . . . . . . . . . . . . . . 44
A.18. IAOC / SSC Joint Negotiation . . . . . . . . . . . . . . . 45
A.19. SSC DRAFT SCHEDULE . . . . . . . . . . . . . . . . . . . . 45
A.20. No Suitable Candidate . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 46
Kowack Expires April 29, 2011 [Page 3]
Internet-Draft RFC Editor Model (Version 2) October 2010
1. Executive Summary: Refinements to the RFC Editor Model
The RFC Series is the Internet technical community's official medium,
through which it communicates with itself and the rest of the world.
The RFC Editor is the community-defined and -supported function that
accepts documents from different streams, makes textual edits for
clarity and formal correctness as prescribed in the RFC Series Style
Manual, and publishes and archives those documents as RFCs for free
access by everyone.
RFC 5620 first defined the components and processes of the present-
day RFC Editor (Model Version 1), including the RFC Series Editor
(RSE) as its leading component. However, the attempt to hire a new
RSE proved difficult and resulted in retention of a Transitional RSE,
or TRSE. The TRSE was asked to perform the RSE functions described
in RFC 5620, to determine if those descriptions matched what was
needed and, if necessary, recommend changes to the role of the RSE
and refinements to the RFC Editor model based on his experience. The
central observation of the TRSE is that:
the RSE role demands the expertise and experience of a senior manager
and subject matter expert in technical writing, technical publishing,
and technical series development.
This observation drives the clarifications and changes recommended
here to RFC Editor Model Version 1. Although modest, these changes
are fundamental to the future success of the RFC Editor's service to
the Internet community. The first clarification is:
the overall leadership and management of RFC Editor functions must be
by the RFC Series Editor - the editorial and publications subject
matter and management expert.
However, this general leadership must be tempered by two
considerations.
o The Internet technical community has requirements, processes, and
traditions that must be followed by the RSE and across the entire
RFC Editor function
o The line between the responsibilities of the RSE and of the IETF
Administration and Oversight Committee (IAOC) must be clarified.
The new model combines RFC Editor leadership as it would be practiced
in a typical not-for-profit organization with the following Internet
community-driven practices:
Kowack Expires April 29, 2011 [Page 4]
Internet-Draft RFC Editor Model (Version 2) October 2010
o seek community input appropriately and widely,
o encourage volunteer initiative and contribution, and
o practice supervision according to specified procedures.
This model recommends collaboration between the RSE and the IAOC
analogous to the partnership between line management and finance as
practiced in most modern corporations:.
o The RSE is responsible for regular editorial activities
management, including long-term editorial planning.
o The IAOC retains its leadership of legal and financial matters.
The RSE reports to the IAB for general matters. The IAB retains its
responsibility for ensuring proper RSE policy formation and
adherence.
Additional recommendations for changes to model provided in RFC 5620
include:
o The independence of the Independent Submission Stream and
Independent Submission Editor (ISE) is reiterated.
o The role of the RSE Advisory Group (RSAG) is marginally expanded
to ensure the RSE follows community will and to provide counsel to
the IAB when the RSE is either unavailable or the subject of a
discussion.
This memo also clarifies the RSE's responsibility for maintaining
Series quality. The updated model divides Series continuity, a key
element of the RSE role, into editorial and operational continuity.
To accomplish the former, the RSE is to maintain and develop the RFC
Series Style Manual. To ensure the latter, the RSE is to develop and
maintain the RFC Series Procedures Manual. To return the RFC Editor
to its historical level of independence, this memo recommends
creation of an RFC Editor stream.
Finally, an updated RSE search and selection process is proposed.
This process is rooted in community participation, qualified
participants and expert advisors, and follows carefully described
procedures and elements to ensure a successful hire.
An unexpected consequence of the TRSE effort is that most of the
changes proposed for the updated model return the RFC Editor to the
style and perspective used during the first 40 years of its life,
although adapted to today's structure and operation of the technical
Kowack Expires April 29, 2011 [Page 5]
Internet-Draft RFC Editor Model (Version 2) October 2010
community. This memo concludes that this time-proven arrangement is
the best way, to serve the requirements of the Internet technical
community.
2. Background
The RFC Series is the Internet technical community's official medium,
through which it communicates with itself and the rest of the world.
6,000 RFCs since 1969 comprise one of the most extensive and
influential technical series in history. Without openly available
RFCs, the Internet could not have been built, could not operate, and
could not continue its remarkable advance. The RFC Editor is the
community-defined and -supported function that accepts draft
documents from the community, makes textual edits for clarity and
formal correctness, and publishes and archives those documents as
RFCs freely accessible by everyone.
RFC 5620 first defined the components and processes of the present-
day RFC Editor, including the RFC Series Editor, its leading
component. This document clarifies the role of the RFC Series Editor
and other RFC Editor components. The origin of these changes go back
to the very start of the series.
The role of RFC Editor dates back to the publication of RFC 1 in
April 1969. One of the longest standing institutions in the Internet
community, the RFC Editor thus predates the IETF (the producer of
Internet Standards) by nearly two decades.
Initially, the role of the RFC editor was played by a single
technical expert who,like other community members and leaders in
those days, was supported by outside funding. The RFC Editor
initiated and participated in the highest level of policy debates,
and made unilateral decisions of great significance to the community
including, until the mid-1990s, decisions about RFC technical
content.
The high degree of autonomy of the RFC editor reflected the culture
of the technical community in those days, when a new and rapidly
changing environment relied heavily upon individual initiative.
Moreover, Jon Postel, the first RFC Editor, had a genius for giving
power to the community and creating new forms of community
participation and contribution. There was little or no perceived
need for careful resolution, in advance, of issues surrounding roles
and authority. The relative informality of that era was widely
accepted and allowed the community to be free of the collective
overhead of financial administration.
Kowack Expires April 29, 2011 [Page 6]
Internet-Draft RFC Editor Model (Version 2) October 2010
The RFC Editor wore multiple hats, even counting only those related
to editorial work. These included acting as an editor, manager of an
editorial service, manager of a technical series, manager of
intellectual property and of an archive, maker of RFC Editor policy,
and leader in policy implementation. Informal processes were widely
accepted as sufficient for managing these multiple complex roles.
By the mid-1990s, the Internet's transition from being a primarily
research-oriented facility was coming to an end. Research funding
for the RFC Editor would not much longer be available. In
cooperation with the community, the Internet Society began to fund
the RFC Editor directly. The RFC Editor was in a new position, its
support now coming directly from the community it served. The
demands on the RFC Editor were increasing as the community produced
more documents -- and desired more timely editorial processing of
those documents.
With the addition of editorial staff, the RFC Editor grew from a
single editor into a team; a division of labor began, and management
overhead increased. While all the functions of the RFC Editor
remained the responsibility of one individual during this period, the
RFC Editor had progressively less authority to make technical changes
to submitted drafts. The other institutions of the Internet
technical community were also evolving, becoming more deliberately
structured and formal. These changes were partly a natural
consequence of organizational maturation and growth. They were also
motivated, as stated in RFC 4844, by these considerations:
"...the Internet engineering and research community as a whole has
grown and come to require more openness and accountability in all
organizations supporting it. More than ever, this community needs an
RFC Series that is supported (operationally and in terms of its
principles) such that there is a balance of:
o expert implementation;
o clear management and direction -- for operations and evolution
across the whole RFC Series (whether originating in the IETF or
not); and
o appropriate community input into and review of activities."
The community reached a consensus, documented in RFC 4844, on a more
rigorous framework for the RFC series and the "RFC Editor function"
(a term RFC 4844 introduced, to clarify that it could be performed by
one or more persons). In doing so, it took steps to pry apart and
further define various responsibilities. That included definition of
the RFC streams, which to the present day comprise:
Kowack Expires April 29, 2011 [Page 7]
Internet-Draft RFC Editor Model (Version 2) October 2010
o IETF Document Stream,
o IAB Document Stream,
o IRTF Document Stream, and
o Independent Submission Stream.
RFC 4844, however, intentionally made no attempt to explore the
internal organization of the RFC Editor. That task fell to RFC 5620,
published in August 2009. RFC 5620 defined or clarified the roles of
the four major components of the RFC Editor: the RFC Series Editor,
the Independent Submissions Editor, and the RFC Production Center and
the RFC Publisher. RFC 5620 separated these in part to permit
flexible implementation (separately or by combinations of
contractors). During this same period, the IAB chose to move
editorial and archiving services from the University of Southern
California's Information Sciences Institute to the winner of an open,
competitive RFP bid.
The IEFT Administrative Oversight Committee (IAOC) established two
new agreements: one for the independent submissions editor, the other
for a single organization to provide a production center and
publication services. The production center houses all the RFC
editorial staff and their internal manager; the publisher is a server
on which all RFCs and drafts are published, archived, and made
available to all. The RFC Editor began to operate under the new
model in January 2010, and continues to do so today.
A simultaneous and extensive effort to locate an RFC Series Editor
did not yield an appointment. Concerned with series continuity, the
IAB created a temporary position, the Transitional RFC Series Editor
(TRSE). The TRSE was to do the job of the RFC Series Editor and
maintain series continuity through 2010. Based on direct experience,
the TRSE was to determine RSE requirements and propose an updated job
description, and corresponding RFC 5620 revisions. This document,
Version 2 of the RFC Series Editor Model, results from that effort.
For the RSE job description to result in a successful engagement, it
must satisfy several challenges. First, it must reflect the inherent
complexity of the RSE role. As defined in 5620, the RSE works on
four levels:
o with the community, to obtain their perspectives on policy and
policy requirements,
o with community leaders to investigate and determine policies and
implementations,
Kowack Expires April 29, 2011 [Page 8]
Internet-Draft RFC Editor Model (Version 2) October 2010
o with staff and contractor management for provision of specified
services, and
o as the executive-level manager of the RFC Series.
Second, many RSE work items are specific to this role and this
community. The job must satisfy the editorial, publication,
distribution, and promotional needs of the series. The RSE job
description must carefully define the RSE's relationship to other
community entities. This is one of the few times there will be a
community-supported job with extensive involvement in policy
development and, in some cases, in policy setting (e.g., certain
components of the Style Manual). That involvement, and the overall
conduct of the Editor, must be consistent with community requirements
and values.
Third, any job needs to be sensibly structured. The description must
be clear and unambiguous. Each individual task must be reasonable
and do-able, and the entire set of tasks must make sense in
combination. Responsibility and authority must align. The job
requirements must be broadly consistent with the skills and
experience level of a single appointee.
Finally, to serve the community, the Series Editor must have the
freedom to be professional while under contract to the IAOC and
subject to review by the IAB -- neither of which can be expected to
include individuals with the same level of editorial background or
expertise. The Series Editor must be able to balance his/her own
initiative and decision-making with the right amount of community
dialog, in the right way, at the right times.
These, then, are the considerations that the TRSE believes central to
success in attracting, hiring, and retaining a qualified candidate.
The revised model addresses these considerations by clarifying RSE
responsibilities and relationships and by describing accepted
community consultation practices.
Many of the updates here are straightforward descriptions of how the
Transitional RFC Series Editor executed the role during 2010. Where
possible, this version retains the text and arrangement of the
original RFC 5620. This version is consistent with RFC 4844 (as was
RFC 5620).
The IAB intends publication of this second version to complete the
current cycle of RFC editor model development. A newly appointed RFC
Series Editor should be able to begin work under a job description
that is complete, well structured, and reasonable, one that will
Kowack Expires April 29, 2011 [Page 9]
Internet-Draft RFC Editor Model (Version 2) October 2010
allow the vast majority of the new RSE's time and energy to be
devoted to doing the job rather than to coping with structural or
other changes. Of course such changes, small or large, may be
required as the position evolves. The RSE and RSAG, along with the
IAB, must continue to monitor the efficacy of the RSE model and
respond to changing circumstances As always, the IAB invites the and
community to provide observations and suggestions.
3. RFC Editor Model
The RFC Editor model divides the responsibilities for the RFC Series
into the following components:
o RFC Series Editor ('RSE') and RFC Series Advisory Group (RSAG),
o Independent Submission Editor ('ISE') and Independent Submission
Editorial Board (ISEB),
o RFC Production Center (RPC), and
o RFC Publisher (RFC Pub).
The RFC Series production process under this structure is
schematically represented by the figure below. All major components
are present. The figure only roughly depicts oversight relations.
Kowack Expires April 29, 2011 [Page 10]
Internet-Draft RFC Editor Model (Version 2) October 2010
+---------+ +---------+
| | | |
| IAB | | IAOC |
| | | |
+-----+---+ +--+------+
+......RFC Editor.....................|.........|........+
. | | .
. +-------------+ +----------+ +--V---------V--+ .
. | | | | | | .
. | Independent | | RFC | | RFC | .
. | Stream | | Series <..> Series | .
. | Editorial | | Advisory | | Editor | .
. | Board | | Group | | | .
. +-----------+-+ +----------+ +-+--------+----+ .
............+ | | | .
. | | | .
+-----------+ . +-V-----------+ +----V--+ +-V-------+ . +-----+
| Community | . | Independent | | RFC | | | . | |
| at +---> Submission +---> | | RFC | . | E |
| Large | . | Editor | | P | | | . | n |
+-----------+ . +-------------+ | r | | P | . | d |
+.................+ | o +-->| u +-----> |
+-----------+ +-------------+ . | d | | b | . | U |
| | | | . | u | | l | . | s |
| IAB +---> IAB +---> c | | i | . | e |
| | | | . | t | | s | . | r |
+-----------+ +-------------+ . | i | | h | . | s |
+-----------+ +-------------+ . | o | | e | . | & |
| | | | . | n | | r | . | R |
| IRTF +---> IRSG +---> | | | . | e |
| | | | . | C | | | . | a |
+-----------+ +-------------+ . | e | | | . | d |
+-----------+ +-------------+ . | n | | | . | e |
| | | | . | t | | | . | r |
| IETF +---> IESG +---> e | | | . | s |
| | | | . | r | | | . | |
+-----------+ +-------------+ . +-------+ +---------+ . +-----+
. .
+..........................+
Ordinary RFC Series production and process
In the model, drafts are separately produced and approved through one
of the streams; they are then submitted to the RFC Editor. The four
current streams are described in [2]. Under the model, the streams,
themselves parts of the community, are the direct "production side
customers" of the RFC Editor. Those include draft authors and
editors, various committees unique to each stream, and the stream
Kowack Expires April 29, 2011 [Page 11]
Internet-Draft RFC Editor Model (Version 2) October 2010
approvers. These actors singly and collectively receive editorial
service from the RFC Editor. Those include the RFC Production Center
accepting submitted drafts, providing editorial feedback and
guidance, making format and editorial changes, and producing numbered
RFCs archived and freely available to all via the Publisher. Readers
and other users of RFCs (e.g., mirror sites), and users of Publisher
services such as search, are referred to here as RFC Editor
"consumption-side customers."
Final decisions about the technical content of individual documents
are the exclusive responsibility of corresponding stream approvers.
Cases will arise in which editorial staff recommend a text change
(for example, to correct grammar) but the author perceives a change
in technical meaning. When this occurs, editorial staff should
review the text and advise the author (about, for instance, how the
text is likely be read by typical readers of English). But the
stream approver will always have final say.
The model allows for implementation of RFC Editor components and
their functions under separate or joint contractual arrangements.
Bidders may make proposals that include one or more contractors.
Much of the reporting structure is subject to change over time and
will depend on plans and the manner in which contracts are awarded.
Details of the implementation are the responsibility of the RFC
Series Editor and the IAOC, including when and how the reporting
structure can be changed (see Section 4.1.5).
However, to preclude conflicts of interest and to support balanced
and independent management, the RSE must not be from the same
organization as any of the other components of the RFC Editor, unless
the IAB acts to override this provision in a specific instance, which
it will do only after reviewing the matter with RSAG.
4. RFC Series Editor
The RFC Series Editor (variously 'RSE' or 'Series Editor') is an
executive-level manager and subject matter expert in technical
writing, publishing, and series development. The Series Editor is
responsible for the entire RFC Editor and all its components,
functions, and staff, separately and in combination -- including the
RFC Publisher and the RFC Production Center. The RSE is the only
component of the RFC Editor with this scope and authority. The
Independent Submission Editor, Independent Submission Stream, and
Independent Submission Stream Editorial Board, however, function
independently of the RFC Series Editor. The RSE obtains advice and
analysis from the RFC Series Advisory Group, or RSAG.
Kowack Expires April 29, 2011 [Page 12]
Internet-Draft RFC Editor Model (Version 2) October 2010
The RFC Series Editor is an individual who has direct reports
including contractors and managers. The RSE may have assistants.
The RSE appointee is a specific individual, not an organization or an
alternate. Under exceptional circumstances when the RSE is
unavailable, a temporary substitute may be made, but only with prior
approval of the IAB, and only after the IAB has consulted the RSAG.
Section 4.1, immediately below, defines the role of the Series
Editor. It describes where and how RSE management practices must
follow internet community practices and requirements.
4.1. RSE Executive-Level Management
Performing the RSE role requires the expertise and experience of a
senior managerial professional in technical writing, publications and
series development. The position has extensive content and RFC-
Editor-wide scope, and is expected to entail a multi-year term of
office (see section 3.6). The RSE will initiate and lead many
discussions, make many day-to-day decisions, and set editorial
policies. This individual cannot help but have tremendous influence.
The approach here is to grant the RSE explicit formal authority to
match the requirements of the job (and, where appropriate, its
implicit influence). That authority is tempered by a context of
customary practices that ensure the RSE acts in the interest of the
community.
In RFC Editor Model Version 1, the community outlined the role of,
and delegated various authorities to, the RFC Series Editor. The RSE
was to exercise "executive-level management over many of the
activities of the RFC Publisher and the RFC Production Center...".
However, RFC 5620 did not attempt to define "executive-level
management" nor explain how that might change as the RFC Editor Model
evolved.
This document defines RSE "executive level management" beginning with
regular professional practices in typical not-for-profit
organizations, including:
o directing day-to-day operations,
o reviewing processes, structures, and performance, and making
changes,
o analyzing customer requirements and strategic opportunities,
o developing long-term goals and plans, including budgeting,
Kowack Expires April 29, 2011 [Page 13]
Internet-Draft RFC Editor Model (Version 2) October 2010
o interacting with and supporting peers and colleagues,
o reporting upwards and to constituents, and
o representing their function in the marketplace.
However, leadership in the Internet community is not practiced as in
many other organizations. In particular, as the community's
perception of a decision's importance increases, the greater is the
need for community review and discussion, in order to reach community
consensus. More than in other organizations, some decisions will
require broad community participation during their development.
In such cases, what counts is the RSE's ability to inspire, support
and distill community discussion. To be successful, the RSE must be
free to do, or facilitate, the following:
o make broad analyses of the scene,
o discover items in need of change or repair,
o determine possible fixes,
o collect and present all pertinent information,
o initiate and organize community discussion,
o help the community reach a consensus, and then
o implement the decision.
Performing this role is leveraged by the RSE's having a "bully
pulpit" - an excellent platform from which to speak. The RSE must be
able to speak to an issue, making arguments on their own merits; but
the RSE cannot expect to be successful simply by "asserting
authority". The process described here will afford the RSE
opportunities to make major contributions and have significant
impact. The RSE's relatively unusual (in our community) incoming
publications expertise, knowledge gained from day-to-day RSE work
experience, and time in grade will give this individual considerable
leverage. To be able to exercise the sort of consensus-building
leadership envisioned for this role, the RSE must not be blocked from
investigating any subject within the scope of the RSE job
description, or from using professional techniques of the RSE's
choosing.
As the RSE and RFC Editor staff apply their specialized knowledge,
they will develop unique perspectives and insights. They must be
Kowack Expires April 29, 2011 [Page 14]
Internet-Draft RFC Editor Model (Version 2) October 2010
free, and encouraged, to shape those insights into their own unique
vision for the RFC Series. Only through this process will they be
able to make a full contribution to the community and continue to
develop, and realize the full potential of the RFC Series. Freedom
to practice their profession is also fundamental to attracting top
rank candidates and to retaining a qualified, motivated, senior
publications management professional.
Section 4.1.1 to Section 4.1.6 discuss six areas in which community
principles and processes modify conventional management practices or
are of particular importance. The RSE must:
o seek appropriate community discussion and input,
o obtain opinion from across the entire community,
o encourage and support volunteer initiative and contribution,
o supervise according to specified procedures,
o cooperate with the IAOC, and
o report to the IAB for general matters and to the IAOC for RSE
contract requirements while following community direction.
4.1.1. Seek appropriate community discussion and input
Determining the long-term direction and evaluating overall
performance of the RFC Editor is the privilege of the Internet
community. In principle, the community could at any time require as
much discussion, or prior approval, as they wish on any matter.
However, the community elected to create the RSE position with
certain responsibilities and authorities. The community will get the
best results if the RSE is trusted to identify when to act
independently and when to seek community discussion and review prior
to acting.
To support community consideration of RFC Editor issues, the RSE will
ensure the RFC Editor will:
o use open and transparent processes,
o make regular reports,
o encourage and participate in discussions with the community across
a wide range of RFC Editor related subjects, and
Kowack Expires April 29, 2011 [Page 15]
Internet-Draft RFC Editor Model (Version 2) October 2010
o follow community consensus.
The RSE must be liberal in what is reported, whether or not specific
items appear to require community discussion or consensus (except, of
course, when standard personnel practices require discretion).
The RSE is responsible for balancing decision-making independence
with prior discussion and approval by the community. Within scope,
the RSE is free to make decisions, determining case-by-case how much
prior discussion is appropriate. Nevertheless, the RSE is
responsible for gaining the community's acceptance of those decisions
and must be prepared to act accordingly if acceptance is not
obtained. The RSE should not act, or appear to act, in an abrupt or
unilateral manner.
The RSE must also remain open to and seek input from the community as
to whether they are achieving the right balance of independence and
input on individual decisions and in aggregate. The RSE is expected
to seek the guidance and counsel of the RSAG in these matters. RSAG
members will maintain their own dialog with community members to
ensure the RSE is aware of community thought, to assist the RSE in
distinguishing between useful and frivolous input, and to help the
RSE refine his approach to this process.
Subjects for which prior community notice or discussion must always
occur include those that:
o directly and significantly affect community activities (e.g., a
change in the Procedures Manual where RFC Editor staff interact
with the streams),
o change long-standing practices that have customarily required
community discussion or consensus (though of course these
practices may change over time),
o are significant and irreversible, and
o significantly impact the look and feel of the series, or how the
series can be used.
Subjects for which discussion does not need to occur include those in
which:
o the Series Editor has been previously authorized to set policy
(e.g., in parts of the Style Manual),
o a decision is based on another authority's mandate (e.g.,
personnel confidentiality practices, IETF Trust requirements),
Kowack Expires April 29, 2011 [Page 16]
Internet-Draft RFC Editor Model (Version 2) October 2010
o the matter is strictly one of internal management within the RFC
Editor,
o a decision has been previously made on RFC Editor policy in
agreement with the community (i.e., the RSE is able to say "this
has already been agreed") or a schedule of discussions has been
agreed but certain dates have not arrived, and
o the differences among outcomes are too slight to justify
consultation (in practice this will apply to relatively minor
issues).
The community must aim to provide input on RFC Editor performance in
a concerted and constructive way. This is especially true regarding
individual performance of RFC Editor staff. The RSE must ensure that
the community can easily provide such input, maintaining appropriate
confidentiality (e.g., for personnel issues).
On occasion, the community may fail to respond to repeated calls for
comment, or their responses may be incomplete. In such cases
(optionally after seeking advice from the RSAG), the RSE is free to
make a decision. As always, the RSE should report such decisions,
and seek community input as to whether these decisions might need to
be revisited in the future.
Another example of a boundary of community participation in decisions
concerns the Style Manual. The Manual could consist of two major
sections. The first would contain rules of usage and layout that RFC
Editor staff must follow when producing RFCs. This part would be as
small as practical. The second part would consist of guidance and
examples of usage, grammar, punctuation and such for authors of
drafts. The first part depends upon editorial and publications
expertise; the RFC Editor would determine its content. The second
part would be created with direct community participation, to ensure
its usefulness.
4.1.2. Obtain opinion from across the entire community
The RSE must seek and obtain input from across the entire community.
As the RSE and staff gain new insights and a broad vision for the
Series and the RFC Editor, they must communicate this in reports to
encourage input from and discussion with every part of the community.
Internet technical community entities and leaders often do not
exercise 'leadership' or represent constituencies as one finds in
conventional organizations. Rather, they have expertise,
responsibility, and authority to work within specific areas. For
every significant decision they must seek community opinion, engage
Kowack Expires April 29, 2011 [Page 17]
Internet-Draft RFC Editor Model (Version 2) October 2010
in discussion, and give the community opportunity to review and
comment. When working with these entities, the RSE must not give
them primacy over community consensus, nor give undue weight to
particular entities.
The RSE is free to participate in debates with the same degree of
knowledge, initiative, insight as employed anywhere in the community,
including other senior leadership positions.
4.1.3. Encourage volunteer initiative and contribution
Volunteers have always done the work in the community. They have
shown exceptional initiative and industry. The vast majority of
things get done because an individual or group takes action, often
without prior official 'approval'; frequently there is no structure
in place to even grant approval in the first place. The RSE must
work with and encourage volunteer initiative. In addition, in order
to maintain community participation, the RSE should convert volunteer
activities into staff activities only if doing so is required to get
the job done, and when the job is important enough to warrant
allocating resources. Although the RSE may be responsible for
specific items, it is not necessary for the RSE to be the one who
does them, only that they get done. This requires that the RSE (a)
not obstruct community initiatives, (b) engage the community when an
area that requires their participation does not yet appear to have
active attention, and (c) support the community in determining
requirements, including quality requirements.
The community has a long practice of engaging volunteers from its
different entities in such a way that participation and authority
have been distributed and expanded, rather than collected and
concentrated. The RSE must continue this practice, which has been
one of our great strengths.
4.1.4. Supervise according to specified procedures
The closeness of RSE supervision of RFC Editor components and staff
depends upon the degree to which the job is defined (often through
community process), and includes direct community participation
Current operations of the RFC Production Center illustrate one end of
this spectrum. The PC performs a well-defined function and works
closely with the streams. RFC Production Center activities are
specified by contract, the Procedures Manual, and the Style Manual.
The RSE will manage this sort of component using conventional
contract management practices in line with these processes. The RSE
will not supervise this component closely; contractor internal
management will do that. Rather, the RSE will provide direction and
Kowack Expires April 29, 2011 [Page 18]
Internet-Draft RFC Editor Model (Version 2) October 2010
guidance where agreed procedures are unclear or where Production
Center performance is not within specification. Contractor
management may request direction, or the RSE may initiate direction.
The RSE may require changes to formal procedures and implementation
by the contractor. The RSE will inform the community and request
reviews at least to the extent that procedural changes affect or are
of interest to the community.
At the other end of this spectrum are, for example, direct reports or
assistants to the RSE. How analysts or assistants perform their work
will not typically be of interest to the community and this work is
not typically structured around formal processes. The RSE should
supervise this sort of staff as closely as the she believes
necessary.
4.1.5. Follow IAOC-RSE cooperation practices
If the RSE anticipates procedural or other changes with contractual,
legal, or financial consequences, they must seek the counsel of and
action by the IAOC. Similarly, the IAOC must request RSE
participation and counsel where administrative, financial or legal
matters require managerial changes. Thus, the IAOC continues to
exercise its responsibility and authority for financial and legal
matters as in RFC Editor Model Version 1. The IAOC and RSE are
expected to resolve most issues without involving the IAB. But when
they are unable to reach agreement, IAB guidance must be sought.
Both short and long-term issues are to be handled in the same manner.
Long-term issues include long-term planning activities, revised and
new plans, contracts and other agreements, and requests for proposals
(RFPs). The RSE and IAOC will jointly evaluate bids and make
recommendations for awards. As above, the RSE will act as the
subject matter expert for editor-related services, and will seek
input from and represent content issues to the community. The IAOC
as above, will take lead on financial, contract, and legal issues.
The IAB, as above, will be the final arbiter when the RSE and IAOC
cannot agree.
The internal and external reporting structure of the RFC Editor may
not be changed without the approval of the RSE and the IAOC. This
includes contract-mandated changes. As with other such decisions,
the RSE and IOAC must bring disagreements to the IAB for review and
resolution.
Questions relating to contractor or individual performance may be
raised by either the RSE or IOAC, including recommendations to
terminate the contract of an individual or contractor. The RSE and
IAOC must each respond to a concern or proposal of the other. If
Kowack Expires April 29, 2011 [Page 19]
Internet-Draft RFC Editor Model (Version 2) October 2010
they cannot agree on a remedy after extensive review and discussion,
they must bring the issue to the IAB.
Although the RSE is not required to make regular reports specifically
to the IAOC, they must keep the IAOC informed of events with
anticipated administrative, legal, or contractual consequences. The
RSE must support IAOC planning cycles and general administrative
requirements. The IAOC must similarly keep the RSE informed of
anticipated administrative, legal, or contract issues that may effect
the RFC Editor.
4.1.6. Report to IAB in general, IAOC for RSE
The RSE listens to, takes input from, and makes reports to the
community, as described above.
The RSE reports to the IAB as necessary to support the IAB's role in
ensuring proper management of the RFC Editor. This includes regular
written reports, which will be publicized.
The RSE reports to the IAOC specifically regarding the RSE's work
contract. If the IAOC has concerns about RSE contractual
performance, they should first bring them to the RSE. If they cannot
agree on a resolution, the matter must be taken to the IAB for
consultation.
RSE reporting to the IAOC for matters directly related to the RSE's
contract is distinct from, and must not be confused with, cooperation
between the RSE and IAOC regarding general and financial management
of the RFC Editor, as described in Section 4.1.5. Both the RSE and
the IAOC must not allow the reporting relationship to influence the
cooperative relationship, and vice versa.
The RSE must keep the IAOC informed so they may fulfill their
obligations regarding legal and financial oversight of the RSE
contract. If there is a disagreement in this area, the IAOC and RSE
must bring that to the attention of the IAB, which will have the
final word on the subject.
The IAOC cannot on its own remove the RSE from office. If there is a
persistent concern about RSE contractual performance, it must be
reviewed by the IAB. The IAB must in turn consult with the RSAG.
4.2. RSE General Responsibilities
The RFC Series Editor is responsible for, and has authority in, the
following areas
Kowack Expires April 29, 2011 [Page 20]
Internet-Draft RFC Editor Model (Version 2) October 2010
4.2.1. Maintain Series Continuity
There are many issues associated with RFC Series continuity,
including the look and feel of the series, indexing methods, policies
for and accessibility of the publications, archiving and publication
policies, IPR and copyright issues, errata policies and procedures,
and publication format policies. Series continuity comprises
editorial continuity and operational continuity.
Editorial continuity is the maintenance and development of the
editorial character of the Series (e.g., look and feel) in a way that
preserves the constancy of the series. Constancy means that changes
will be made only when there is good reason to do so; when changes
are required (e.g., in the format of RFCs)), they will be done in a
deliberate, evolutionary way that respects the long-standing
editorial practices of the series. Changes will be made with input
from editorial staff, and will be available for review by and input
from the community. The more substantive, broad, or abrupt a
proposed change, the more important it will be to solicit agreement
from the community before making the change.
The RFC Series Style Manual is the primary vehicle for maintaining
constancy in, and making changes to, editorial continuity. The RSE
will prepare and maintain an RFC Style Manual to describe clearly the
grammar, style, usage, typography, punctuation, and spelling
standards that will guide the drafting and editing of RFCs, so that
all publications will appear in clear, concise technical prose. The
primary audiences for the Style Manual are authors, editors, the
stream managers, the RFC Production Center, and the RFC Publisher.
Implementation of many continuity-related decisions within the Style
Manual will reside with the RFC production and publishing functions,
as directed by the RSE.
Operational Continuity. Over the long run, editorial staff must
produce RFCs from drafts at least at the same rate the streams submit
drafts. Operational continuity is maintaining and planning for
consistent, regular output from RFC Editor staff including
contractors. This includes all related editorial staff support
activities, including feedback and advice for authors and streams,
regular reports, liaison activities, and attendance at meetings.
If there is a disruption of editorial services, the RFC Series Editor
and the IAOC are responsible for promptly acquiring and directing new
resources to maintain RFC output. New teams of editors or additional
contractors may be needed. The RSE must keep the RFC Editor
Procedures Manual and Style Manual up to date to provide sufficient
direction to alternate editors, per above. The RSE must maintain
sound understanding of those processes in order to direct new
Kowack Expires April 29, 2011 [Page 21]
Internet-Draft RFC Editor Model (Version 2) October 2010
resources when required. We refer to maintaining editorial output
during a disruption as "exceptional continuity".
As in all matters when planning for or maintenance of operational
continuity has legal or contractual consequences, the RSE will
communicate and coordinate with the IAOC.
4.2.2. Maintain and Develop RFC Series Quality
RFC Series quality is the collective responsibility of the Internet
technical community. The RFC Series Editor shares responsibility for
editorial quality with the other members of the RFC Editor. The
streams each have responsibility for technical and content quality in
their respective areas.
The RSE's quality responsibilities include editorial quality
delivered through published RFCs, editorial service (or process)
quality provided to the streams, and quality of access,
accessibility, and access services for users. The RSE must develop
and maintain output measurement techniques and statistics collection
in order to monitor and improve service (production) quality. The
RSE is also responsible for advancing the overall quality of the
series, in cooperation with the community and its entities,
especially the streams.
4.2.2.1. Quality
Editorial quality management comprises changes made by RFC Editor
staff as drafts are refined into published RFCs. Editorial quality
must meet the requirements of three groups:
o authoritative community entities (e.g., the IETF Trust regarding
IP notices),
o authors and streams ("producer-side service quality"), and
o re-distributors and users of RFCs ("consumption-side quality")
The RFC Series Editor must maintain and develop editorial quality
that satisfies and balances requirements of all three groups. During
2010, it was determined that the community has almost no knowledge of
the demographics of RFCs end-users, of how they use RFCs, or end-user
requirements. The RSE should seek to learn more about RFC end-use
and end-users to inform quality-related decisions, discussed
immediately below in Section 4.2.2.2. Work to date suggests that the
end-user community may include the following groups:
Kowack Expires April 29, 2011 [Page 22]
Internet-Draft RFC Editor Model (Version 2) October 2010
o RFC implementers. This group intersects with working group
participants. The latter is an unknown proportion of the former,
o network operators (of RFC implementations),
o academics, researchers and students,
o marketers, and requirements writers,
o policy-makers, and
o re-distributors (e.g., mirror site operators) and publishers.
The RSE should improve collective understanding of the demographics
of RFC use and its implications for RFC quality. The RSE should seek
community participation in this effort, especially stream members.
The RSE should discuss findings with the community and streams to
determine any impact on editorial goals and practices.
4.2.2.2. RFC Editor production and service quality
There are the three principal RFC Editor services, each with specific
quality requirements:
o processing of drafts into RFCs and support for authors and the
streams, provided by the RFC Editor,
o access-related services provided via the RFC Publisher, and
o general writing guidance and training for authors and others in
the streams.
Draft processing and support ("production-side support") .
Presently, the RFC Editor provides only one level of editing and
support, which is minimal and does not vary according to the needs of
particular drafts. The RSE will continue to develop practices in
this area to respond to changing general needs and specific draft-
editing requirements. In the latter case, the RSE will investigate
whether a "red flag" service is appropriate. Such a service,
available on authors' request, would give special attention to drafts
thought to be particularly complex, extensive, or to have an
especially critical audience. The RSE will determine whether there
are resource consequences to planned changes to editorial practices.
Access-related services. Access-related services include web site
services such as search and indexing tools. The RSE should continue
to develop these services. As stated above, most implementation will
be by contractors and volunteers.
Kowack Expires April 29, 2011 [Page 23]
Internet-Draft RFC Editor Model (Version 2) October 2010
Stream and author guidance and training During 2010, the RSE received
repeated requests for general technical writing training, especially
for non-native speakers of English. The RSE should investigate this
area and look for opportunities to reduce authors' costs (largely in
time), improve the quality of drafts submitted, and reduce RFC Editor
processing time and costs.
4.2.2.3. Performance Measures and Statistics
As executive-level manager, the RSE will direct development of
carefully-targeted RFC Editor performance measures, including
statistics, their graphical representation, and publication on the
RFC Editor web site and elsewhere. Creating meaningful production
statistics is complex, subtle, and error-prone. Even simple and
obvious statistics can mislead observers and motivate suboptimal
editing and production. The RSE will improve measures to illuminate
productivity and minimize distortion. The RSE will aid the community
in understanding the meaning and limitations of published statistics.
The RSE will use performance measures as input to planning with the
IAOC and to inform contracts, contract revisions, and requests for
proposals.
4.2.2.4. RFC Editor and RSE professional expertise
The RSE will maintain RFC Editor professional expertise in two areas.
The RSE will ensure that staff and contractors maintain minimum
standards of, and steadily improve, professional skills and
knowledge. Staff professional advancement is the responsibility of
the RSE. Contractor professional development is the responsibility
of the contractor, as directed by the RSE by inclusion in contracts.
The RSE is responsible for maintaining and developing his own
expertise as needed to support the requirements and processes
described in this document. This includes developing intimate
knowledge of editorial practices and procedures to protect the
community from service disruption, developing editorial services and
the Series overall, and advising the community and staff.
4.2.2.5. Survey Overall Series Quality
[RFC5620] section 3.1 states that the RFC Editor is to exercise
"executive-level management over the implementation of policies,
process, and procedures established to ensure the quality and
consistency of the RFC Series." The RSE will at least once every
three years survey overall Series quality to verify that the Series
is meeting the needs of the community at large, production side
customers (streams), consumption side customers (end users), and
Kowack Expires April 29, 2011 [Page 24]
Internet-Draft RFC Editor Model (Version 2) October 2010
others. This evaluation will include analyses of long-term quality
trends and measures. The RSE will seek the streams' participation.
The RSE will publish a report, preferably jointly with the streams,
including recommendations for improvements.
4.2.3. Represent the RFC Series to the Community
The RSE will represent the RFC Editor, the Series, and its long-term
development, to the community. This includes keeping the community
informed of ongoing activities and progress against plans, analyses
and observations, exceptional items, and long-term plans.
Accordingly, the RSE will participate in RFC Editor on-line
facilities such as web sites, and editor-oriented mail lists and
discussion media. The RSE is responsible for ensuring that every
inquiry or complaint about the Series receives a timely and
appropriate response.
4.2.4. Represent and promote the RFC Series to the outside world
The RSE will represent and promote the Series to the outside world.
Promotion concerns:
1. Identifying and communicating with those who would benefit from
the RFC Series, and showing them where and how to access the
series. Promotion complements accessibility. This includes
ensuring the RFC Series is accessible via conventional means,
such as electronic card catalogs, and ISSN numbers, which must be
kept current.
2. Improving broad awareness of the role of, and contributions by,
the technical community widely, and in targeted communities.
Increasing the stature of the Series reinforces other community
initiatives.
Promotion can rapidly become very costly in both time (especially
management opportunity cost) and money. The RSE's priority is to do
at least rudimentary promotion that is economical and readily
accomplished. The RSE should undertake extensive promotions only
after discussion with the community. Explanations of costs and
specific, targeted benefits should always accompany recommendations
for promotional efforts.
Over the long run, the RSE should survey comparable organizations and
series to see how they promote themselves and what that suggests for
RFC Series promotion.
Kowack Expires April 29, 2011 [Page 25]
Internet-Draft RFC Editor Model (Version 2) October 2010
4.2.5. Identify and lead community discussion
In collaboration with the RFC Series Advisory Group (RSAG), the RSE
will identify and lead community discussion of important issues and
opportunities facing the RFC Series. The RSAG may formally request
that the RSE to investigate areas it believes have not been
sufficiently addressed.
4.3. RFC Series Editor Specific Responsibilities
In addition to the processes, requirements, and activities above, the
RSE is responsible for the following specific items. Some major
items described above are repeated here.
4.3.1. General Planning, Prioritization, and Reporting
Many of the responsibilities and tasks in this document are open-
ended. The RSE cannot accomplish all these tasks at the same time
with any reasonable level of resources. The RSE must manage the
extent of tasks, and their prioritization and execution. The RSE
must clearly communicate plans and expectations to the community and
other entities.
1. Within 6 months of the RSE's appointment, or a date agreed with
the IAB, the RSE will publish an initial work plan and road map.
The RSE will indicate which initiatives and activities will be
focused on over the remainder of the first calendar year,
including their own activities and those of other RFC Editor
Components. These plans will distinguish between ongoing
operational duties and focused initiatives. In developing this
initial plan, the RSE will have had the assistance of the RSAG.
2. By 5 December each year thereafter, the RSE will publish a plan
and road map for the upcoming calendar year.
3. By 1 February each year, the RSE will publish an Annual Report of
the RFC Editor. This will include a review against the preceding
year's plans and highlight lessons learned that are reflected in
the new calendar year plan and road map. Summary statistics will
be included. The RSE may ask RFC Editor components to produce
relevant reports on request. The RSAG will review and comment on
the RSE's draft before the final annual report is published.
The RSE will issue a monthly report for delivery to the IAB and
publication to the community.
Kowack Expires April 29, 2011 [Page 26]
Internet-Draft RFC Editor Model (Version 2) October 2010
4.3.2. RFC Series Continuity
The RSE will take all steps necessary to maintain the editorial and
operational continuity and consistency of the Series consistent with
the procedures described elsewhere in this document.
The RSE will maintain the Style and Procedures Manuals in support of
consistency and proper RFC Editor operations. The Procedures Manual
will include a description of tasks performed by the RSE.
The RSE will publish a long-term schedule for regular (by default
annual) updates to and reviews of, each document. This does not
preclude occasional or as-required incremental updates to these
documents.
4.3.3. Reviews
The RSE may conduct reviews of any process or component of the RFC
Editor at any time. The RSE will conduct annual assessments of the
RFC process and of all components of the RFC Editor (ISE and Stream,
RFC Production Center and RFC Publisher). Reviews will incorporate
feedback from the RSAG and will include input from the community.
Reviews will be presented to the IAB and be available to the
community.
Reviews of the ISE will follow procedures that respect the
independence of the ISE and Independent Submission Stream. In
particular, the RSE will request a member of the RSAG to
independently create and chair an Independent Submission Stream and
Editor review committee. The committee will consist of 5 regular
members, at least three of whom will come from the RSAG; two may come
from the community, appointed by the chair after an open call to the
community. The RSE and the chair of the IS review committee will
jointly develop a review process and outline, which will then be
independently completed by the review committee.
Comprehensive annual reviews may prove costly and unnecessary.
Accordingly, the RSE may elect, after discussion with the IAB, RSAG,
and IAOC, to alternate limited and comprehensive reviews on two or
three-year cycles.
The RSE will participate, on request, in IAB-initiated external
reviews of the RFC Editor and/or any of its components, and will
support and coordinate with the IAB and/or IAOC as required.
Kowack Expires April 29, 2011 [Page 27]
Internet-Draft RFC Editor Model (Version 2) October 2010
4.3.4. Regular RFC Editor Operations and RFC Series Oversight
The RSE will manage day-to-day operational issues that have not
previously been delegated (i.e., to contractors), including:
1. managing issues as they arise from the streams (production side
customers), community, entities, and from within the RFC Editor
components,
2. resolving resource allocation questions, including balancing
stream requests for priority handling of drafts,
3. organizing, structuring, and leading regular and special RFC
Editor meetings,
4. participating in author document reviews,
5. developing and maintaining FAQs for RFC publication, and
6. administering and participating (directly or via delegates) in
various (e.g., rfc-interest) RFC Editor-related mailing lists.
4.3.5. Ongoing Developmental Issues
The RSE will:
1. work with the stream managers in maintaining policies for an RFC
errata process,
2. develop policies for the types of indexes that the RFC series
will support by default and the metadata that may be required to
support those indexes, and
3. approve tools for the validation of syntax of documents
containing formal languages.
4.3.6. Liaison, Coordination, and Collaboration
The RSE will:
1. provide all necessary points of contact and services to support
policy inputs and questions (from, for example, the community or
other entities),
2. take part in formal meetings, telechats, and other communications
among entities (e.g., IESG and IAB), as well as general meetings
such as the IETF, or retreats, as required. The RSE will make
reports as required,
Kowack Expires April 29, 2011 [Page 28]
Internet-Draft RFC Editor Model (Version 2) October 2010
3. conduct coordination meetings (including, e.g., telechats) with
the streams (production-side customers) and components of the RFC
Editor,
4. liaise and work with the IAB so that the IAB may be confident
there has been sufficient community review before significant
policies or policy changes are adopted, and
5. participate, on request, in IAB-initiated external reviews of the
RFC Editor and/or any of its components, coordinating with the
IAB and/or IAOC as required.
4.3.7. Process and Document Evolution and Innovations
The RSE will consider innovations to improve efficiency,
coordination, transparency, and quality. The RSE will continuously
monitor the RFC production process for possible improvements, and
propose and evaluate experiments as input to RSE recommendations.
The RSE will also, as appropriate, support process experiments
proposed by the Internet community.
4.3.8. Organize and Structure Performance Measures
The RSE is responsible for requesting appropriate contractor reports,
including statistics. Contractors will allocate sufficient resources
to satisfy reporting activities and to respond to requests for
changes.
4.4. RSE Professional Qualifications
The RFC Series Editor provides general and editorial leadership of
the RFC Editor, and meets the following qualifications unless noted
otherwise:
1. Experience as a senior manager and subject matter expert in
technical writing, technical publications, and technical series
development. Executive management experience must be
commensurate with the requirements outlined elsewhere in this
document and the many aspects of the RSE role, including the
tasks of coordinating the overall RFC Editor process,
2. Experience with complex organizations with substantial group
processes. The RSE must be skilled at participating in group
processes, managing and getting value from them. The RSE must
understand and appreciate delegation. Experience with and
understanding of the IETF and RFC process is desirable.
Kowack Expires April 29, 2011 [Page 29]
Internet-Draft RFC Editor Model (Version 2) October 2010
3. Good understanding of the English language and technical
terminology related to the Internet,
4. Excellent skill communication and, especially, listening,
5. Independent worker, and
6. Experience as an RFC author is desirable.
4.5. RSE Term of Office
The default RSE term of office is five years with no restrictions on
renewals, and with provision for shorter actual contracts and
intermediate reviews. Individual contract periods may be shorter due
to practical issues. Specific contract duration will be determined
by the IAOC with participation by the RSE Search and Selection
Committee, per their defined participation in the hiring process, and
with the agreement of the IAB. Terms of office for the RSE, ISE, and
RFC Production Center must be adjusted to avoid concurrent
transitions.
5. Independent Submission Editor
5.1. Independent Submission Editor General Responsibilities
The Independent Submission Editor (ISE) provides general and
editorial leadership of the Independent Submissions Stream. The ISE
is an individual who may have assistants and who is responsible for:
1. Maintaining technical quality of the Independent Submission
stream.
2. Reviewing, approving, and processing Independent Submissions.
3. Forwarding to the Production Center the Internet-Drafts that have
been accepted for publication as RFCs in the Independent
Submission Stream.
4. Reviewing and approving RFC errata in Independent Submissions.
5. Coordinating work and conforming to general RFC Series policies
as specified by the IAB and RSE.
6. Providing statistics and documentation as requested by the RSE.
7. Providing sufficient resources (i.e., ISE time) to support RFC
Series Editor reviews of the Independent Submissions Stream, and
Kowack Expires April 29, 2011 [Page 30]
Internet-Draft RFC Editor Model (Version 2) October 2010
external reviews of the RFC Editor initiated by the IAB or IAOC.
8. Being available when possible to participate in escalation
procedures and RFC Editor focused internal reviews.
5.2. ISE Professional Qualifications
The Independent Submission Editor is a senior position for which the
following qualifications are desired:
1. Technical competence, i.e., broad technical experience and
perspective across the whole range of Internet technologies and
applications, and specifically, the ability to work effectively
with portions of that spectrum in which no personal expertise
exists.
2. Thorough familiarity with the RFC series.
3. An ability to define and constitute advisory and document review
arrangements. If those arrangements include an Editorial Board
similar to the current one or some equivalent arrangement, assess
the technical competence of potential Editorial Board members.
4. Good standing in the technical community, in and beyond the IETF.
5. Demonstrated editorial skills, good command of the English
language, and demonstrated history of being able to work
effectively with technical documents and materials created by
others.
6. The ability to work effectively in a multi-actor environment with
divided authority and responsibility similar to that described in
this document.
The Independent Submission Editor may seek support from an advisory
board Section 5.2qu and may form a team to perform the activities
needed to fulfill his responsibilities.
The individual with the listed qualifications will be selected by the
IAB after input is collected from the community. An approach similar
to the one used by the IAB to select an IAOC member every other year
(as described in Appendix A) should be used. While the ISE itself is
considered a volunteer function, the IAB considers maintaining the
Independent Submission stream within the RFC Series part of the IAB's
supported activities, and will include the expenses made for the
support of the ISE in its IASA-supported budget.
Kowack Expires April 29, 2011 [Page 31]
Internet-Draft RFC Editor Model (Version 2) October 2010
5.3. ISE Term of Office
The default ISE term of office is five years with no restrictions on
renewals, and with provision for shorter actual contracts and
intermediate reviews. Individual contract periods may be shorter due
to practical issues. Terms of office for the RSE, ISE, and RFC
Production Center should be staggered to avoid terminating
concurrently.
5.4. Independent Submission Stream Editorial Board
The Independent Stream Editor is supported by an Editorial Board for
the review of Independent Submission stream documents. This
volunteer Editorial Board currently exists, and its members serve, at
the pleasure of the ISE. The existence of this board is simply noted
within this model; additional discussion is out of scope for this
document.
6. RFC Production Center
RFC Production is performed by a paid contractor, and the contractor
responsibilities include, under the direction of the RSE:
1. Editing inputs from all RFC streams to comply with the RFC Style
Manual,
2. Creating records of edits performed on documents;
3. Identifying where editorial changes might have technical impact
and seeking necessary clarification,
4. Engaging in dialogue with authors, document shepherds, IANA,
and/or stream-dependent contacts when clarification is needed,
5. Creating records of dialogue with document authors,
6. Requesting advice from the RFC Series Editor as needed,
7. Offering suggestions to the RFC Series Editor as needed,
8. Providing sufficient resources to support reviews of RFC
Publisher performance by the RFC Series Editor and external
reviews of the RFC Editor initiated by the IAB or IAOC,
9. Coordinating with IANA to perform protocol parameter registry
actions,
Kowack Expires April 29, 2011 [Page 32]
Internet-Draft RFC Editor Model (Version 2) October 2010
10. Assigning RFC numbers,
11. Establishing publication readiness of each document through
communication with the authors, document shepherds, IANA and/or
stream-dependent contacts, and, if needed, with the RFC Series
Editor,
12. Forwarding ready-to-publish documents to the RFC Publisher,
13. Forwarding records of edits and author dialogue to the RFC
Publisher so these can be preserved, and
14. Liaising with various streams as requested by the RSE.
The RFC Production Center contractor should be selected by the RSE
and IAOC through an open RFP process. The RSE and IAOC will seek
bidders who, among other things, are able to provide a professional,
quality, timely, and cost- effective service against the established
style and production guidelines. Contract terms, including length of
contract, extensions and renewals, shall be as defined in an RFP.
The opportunity to bid shall be broadly available.
7. RFC Publisher
The RFC Publisher comprises the managed computing resources where
RFCs and related information are archived, publicized, and that
support open access. Included are the management services required
to support and maintain that capability. The term "RFC Publisher"
does not follow common usage; it does not in any way refer to the
senior manager in a publishing organization.
RFC Publisher responsibilities include:
1. Announcing and providing on-line access to RFCs.
2. Providing on-line system to submit RFC Errata.
3. Providing on-line access to approved RFC Errata.
4. Providing backups.
5. Providing storage and preservation of records.
6. Authenticating RFCs for legal proceedings.
All these activities are under general supervision of the RSE, who
will provide an appropriate level of coordination with the streams
Kowack Expires April 29, 2011 [Page 33]
Internet-Draft RFC Editor Model (Version 2) October 2010
and other entities as required
The publisher is inherently a far simpler service to implement and
manage than any other component of the RFC Editor. Experience gained
during 2010 shows that combining the publisher with another
subcontract (in this case the IETF Secretariat contract) can be
effective and can reduce management overhead. Separate publisher
implementation could increase overhead costs.
8. Committees
8.1. RFC Series Advisory Group (RSAG)
8.1.1. Charter
The RSAG provides expert, informed guidance (chiefly) to the RSE in
matters affecting the RFC Series' operation and development. That
includes providing long-term perspective in support of consistency
and constancy of the RFC Series interpretation over time. Such
matters include, but are not limited to, issues in operation of and
planning for RFC model components, and consideration of additional
RFC streams, to give a sense of the range of topics covered.
The RSAG serves four functions:
1. advising the RSE, upon request, on matters related to operation
and direction of the Series,
2. supporting the RSE's connection to and alignment with the
community through informal community discussions, and by
discussion with the RSE about their observations regarding
community opinion and RSE engagement with the community,
3. participating, and providing leadership, in RSE analysis and
review committees on request of the RSE, and
4. providing counsel to the IAB or IAOC in situations where the RSE
cannot be available.
The group provides guidance to the RSE, who as required will address
operational issues or opportunities with other components of the RFC
Editor. In cases where these issues have contractual or financial
effects, the RSE works cooperatively with the IAOC, as described
elsewhere in this document. The RSAG also serves to advise the RSE
on long-term, large-scale developments for the RFC Series. This
informs the proposals the RSE takes to the community for discussion,
and to the IAOC as proposals for implementation.
Kowack Expires April 29, 2011 [Page 34]
Internet-Draft RFC Editor Model (Version 2) October 2010
The RSAG will assist the RSE in identifying and leading community
discussion of important issues and opportunities facing the RFC
Series. In this way, the RSAG ensures the RSE is aware of community
opinion and requirements. In turn, the RSE must keep the RSAG
sufficiently informed of major issues and plans so that the RSAG may
interact with the community knowledgeably; and so that in cases where
the community, the IAB, or the IAOC require (as described above), the
RSAG will be able to provide their informed counsel.
The RSAG is chartered by the IAB. As such, the RSAG operates
independently of the IAB to fulfill that charter. The IAB retains
its oversight role and is responsible for ensuring that the community
has adequate discussion of important topics.
8.1.2. Membership
RSAG full (non-liaison) members are all at-large members; they do not
represent a particular RFC stream or any organizations. The RSE is a
member, and unless she chooses otherwise, RSAG chair. Full members
serve staggered, 3-year terms, with no limit on renewals. There is
no hard upward limit on the number of full RSAG members, but it is
anticipated that it will remain roughly around the "low teens" to
facilitate committee management and ease of discussion.
The RSE selects members for their experience and interest in the RFC
Series as well as in editing and publishing. Outside (non community
members) editorial and publishing experts may be members, especially
well-known leaders in technical writing and publications. Outside
experts must not be more than a minority of full members. In
particular, there is no requirement or expectation that RSAG members
will be IAB members. The Series Editor proposes RSAG members in
consultation with sitting RSAG members; the IAB then confirms and
formally appoints those members.
In addition to full members, each RFC stream approver will appoint a
liaison to the RSAG to provide context specific to their stream. The
liaisons need not be members of the stream approval bodies.
Initially, there will be no IAOC or IAB liaison for their oversight
role; however, as experience is gained, the IAOC, IAB, or RSAG may
request such liaisons.
Unless explicitly indicated otherwise, only full RSAG members will
provide direct counsel to the IAB or IAOC.
The RSAG does not select or appoint the RSE, or any other component
of the RFC Editor model, although it is an important resource for
informing any selection process.
Kowack Expires April 29, 2011 [Page 35]
Internet-Draft RFC Editor Model (Version 2) October 2010
The full members will serve at the pleasure of the IAB -- appointed
by the IAB, and if necessary, removed by the IAB, which will only be
done for reasons of professional misconduct or long-term non-
participation. The IAB must confer with the RSE and the full members
before removing a member.
During the term of the Transitional RFC Series Editor, the RSAG has
been on interim status. Once appointed, the new RSE will ask
standing members to indicate their staggering preferences; the RSE
will then determine and publicize terms of appointment, and declare
the RSAG to be on permanent status.
9. Resolution of Disagreements
9.1. Disagreements between RFC Editor Components and Model Participants
If during the execution of their activities, a disagreement arises
over an implementation decision made by one of the components in the
model, any relevant party should first request a review and
reconsideration of the decision with the other party or parties, and
inform the RSE that this activity is underway. All parties should
work informally and in good faith to reach a mutually agreeable
conclusion. If the parties resolve the issue, they should inform the
RSE of the resolution and specify any procedural or other changes
that it may entail.
If one party still disagrees after the reconsideration, that party
should ask the RSE to undertake a formal review. The RSE must inform
and engage the RSAG in their advisory capacity, and may call for a
review committee including members of the RSAG. The RSE and RSAG
should seek to reach rough consensus on the resolution of the matter.
If there is a technical or procedural matter that concerns the IAB,
or an administrative, legal, or financial issue that concerns the
IAOC, the RSE may request the guidance or participation of either or
both of those bodies. If the disagreement directly involves the RSE,
the RSE may ask the IAB to mediate or appoint a mediator to aid in
the discussions, although the IAB is not obliged to do so. The RSAG
should be used in this capacity unless there is good reason it should
not (such as if the RSAG itself is a party to the disagreement).
If a timely decision cannot be reached through discussion, mediation,
and mutual agreement, the Series Editor is expected to make whatever
decisions are needed to ensure the smooth functioning of the RFC
Editor function. Such decisions must follow proper community-
oriented practices as described in Section 4.
Kowack Expires April 29, 2011 [Page 36]
Internet-Draft RFC Editor Model (Version 2) October 2010
RSE decisions of this type are limited to the functioning of the RFC
Editor processes and evaluation of whether current policies are being
implemented appropriately or need adjustment. As described in
Section 4, final decisions about the technical content of individual
documents are the exclusive responsibility of the stream approvers
for those documents.
If a disagreement or decision has immediate or anticipated future
contractual consequences, the Series Editor must identify the issue
to the IAOC and, if the RSAG has provided related advice, the RSE
should forward that to the IAOC.
9.2. RSE Review of Inter-Stream Conflicts
Streams are encouraged to resolve conflicts on their own. Any stream
approver may request RSE review of an inter-stream conflict at any
time. Review by the RSE must include assembling a review committee
of four disinterested RSAG members plus the RSE, who will chair the
committee.
RSE recommendations must be consistent with existing RFC-documented
policy, insofar as documented policy covers the issue. RSE
recommendations may not use informal (that is non-RFC) statements of
practices such as those found in stream-internal documentation (such
as web pages).
10. Re-Establishing an RFC Editor Stream Capability
Before publication of RFC 4844, the RFC Editor could produce RFC
Editor -related documents whenever the RSE thought them necessary,
without approval from other entities. By formally dividing new
document production into four distinct partitions, RFC 4844
eliminated this capability. Today, if the RSE wishes to publish an
RFC, it must be approved by one of the streams. None is suitable;
each could impose process or content requirements on the RSE, which
could reduce the RFC Editor's independence. This might be especially
so if the draft in question has impact on one or more of the streams.
Adding new processes to permit RFC Editor publications to each stream
would be complex and time-consuming, and would not clearly result in
a satisfactory process. The Independent Submissions Stream, being a
general-purpose stream under the RFC Editor, might appear suitable.
However, if an RFC Editor draft were politically significant, some
parties might put pressure on the Independent Submissions Editor- and
on the RSE - which could jeopardize Independent Stream autonomy.
The RSE must take all steps necessary to create an "RFC Editor
Stream" as soon as practical. The RFC Editor Stream charter is to
Kowack Expires April 29, 2011 [Page 37]
Internet-Draft RFC Editor Model (Version 2) October 2010
produce Informational RFCs pertaining to the RFC Series in general,
to the operation, practices, and performance of the RFC Editor, and
to editorial subjects of interest to the community, including authors
and draft editors from the streams. The Series Editor will be the
stream approver. The RSE may accept and publish in-topic documents
from outside the RFC Editor. The full members of the RSAG will
comprise the (strictly) advisory editorial board of the RFC Editor
stream. The RSE, in cooperation with the RSAG, will define a
document approval process for this stream, to be presented to the
community for review and feedback.
Section 5, [RFC4844], discourages the creation of new streams. In
order to be economical about adding this stream, the RFC Editor
Stream could be the designated as the future repository of archived
(and discontinued) series. In this case, it might be useful to begin
the concept of the 'sub-stream', under which different 'adopted'
archived series might reside.
11. Future Considerations
In time, it may be necessary to provide oversight for the RFC Editor
that is more active, focused and expert than is possible under the
IAB. In that case, it may be useful to divide the RSAG into two
groups. One could continue to provide guidance, the other could
undertake the responsibilities and activities currently performed by
the IAB.
12. IANA Considerations
This document defines several functions within the overall RFC Editor
structure, and it places the day-to-day coordination of registry
value assignments with the RFC Production Center under the direction
of the RSE. The IAOC will continue to facilitate the establishment
of the relationship between the RFC Editor and IANA.
This document does not create a new registry nor does it register any
values in existing registries, and no IANA action is required.
13. Security Considerations
The same security considerations as those in RFC 4844 apply. The
processes for the publication of documents must prevent the
introduction of unapproved changes. Since the RFC Editor maintains
the index of publications, sufficient security must be in place to
prevent these published documents from being changed by external
Kowack Expires April 29, 2011 [Page 38]
Internet-Draft RFC Editor Model (Version 2) October 2010
parties. The archive of RFC documents, any source documents needed
to recreate the RFC documents, and any associated original documents
(such as lists of errata, tools, and, for some early items, non-
machine-readable originals) need to be secured against failure of the
storage medium and other similar disasters.
The RSE and IAOC should take these security considerations into
account during the implementation of this RFC Editor model.
14. Acknowledgments
[ed., TBD]
15. References
15.1. Normative References
[RFC4844] Daigle, L. and IAB, "", 4844 RFC, July 2007.
[RFC5620] Kolkman, O. and IAB, "RFC Series Editor Model (Version
1)", RFC 5620, August 2009.
15.2. Informative References
[RFC4333] Huston, G. and G. Wijen, "The IETF Administrative
Oversight Committee (IAOC) Member Selection Guidelines and
Process", RFC 4333, December 2005.
Appendix A. 2010-11 RSE Search and Selection Process
This appendix describes the structures and processes for finding and
selecting the first long-term RFC Series Editor, specifically during
late 2010 and early 2011.
A.1. Overview and Criteria
Five community members will serve on a seven-member RSE Search and
Selection (SSC) committee. The design of this committee aims to
satisfy several key requirements. To ensure a representative range
of points of view, the committee will be populated from different
parts of the community. Committee members will have expertise in
community processes, and there will be advisors from relevant
professions. The SSC selection process will ensure that members will
have the requisite background and skill for their mission. The
process is defined to reduce confusion or risk of process failure.
Kowack Expires April 29, 2011 [Page 39]
Internet-Draft RFC Editor Model (Version 2) October 2010
Finally, the committee is intentionally small to permit quicker
action and easier exchange of information.
A.2. Structure
The seven-member SSC will consist of five regular (voting) members:
o two regular members appointed by the stream approvers,
o two regular members appointed by RSAG regular members (that is,
liaisons will not participate in the RSAG selection process),
o one regular member appointed by [ed., TBD].
plus two non-voting advisors:
o a volunteer Human Resources (HR) professional from the computing
or networking industry, and
o the Transitional RFC Series Editor
All SSC members will be at-large members; each is to represent the
community, not the group that appointed them. The committee will
select a chair among the regular members. The SSC may appoint
assistants as required. Decisions will be by rough consensus unless
the committee chooses other processes.
A.3. Stream Appointments
The IETF stream approver, the IESG, will appoint one SSC member by a
process of its choosing. The other three stream approvers (IAB,
IRSG, and ISE) will collectively appoint the other member by a
process of their own choosing. To ensure broad support for
appointments, each stream appointee must be approved by the other
stream approvers; that is, the IESG approver must approve the member
proposed by the IAB, IRSG, and ISE approvers, and vice versa).
Streams appointees may, but need not, be current participants in the
streams or current stream leaders. To promote broad participation,
current stream chairs are not eligible for appointment to the SSC.
Each stream approver should widely survey members of their streams
when making their selection.
A.4. RSAG Appointees
The two RSAG appointees may be from the RSAG or from the greater
community. One of the two appointees may be a highly respected
leader from the technical publications world without previous direct
Kowack Expires April 29, 2011 [Page 40]
Internet-Draft RFC Editor Model (Version 2) October 2010
participation in the community. The RSAG should seek community
comment on their prospective candidate(s).
A.5. SSC Regular Member Qualifications
All SSC regular members must have:
o broad experience and wide respect within the community,
o experience interviewing and evaluating prospective hires and with
interviewing,,
o significant experience with editorial practices, and
o skill at analyzing and resolving complex issues as members of
teams.
A.6. Additional Qualifications for Streams Appointees
The streams appointees must have solid knowledge of stream editorial
requirements and typical RFC Editor interactions from within at least
one stream.
A.7. Additional Qualifications for RSAG Appointees
The RSAG appointees must have extensive knowledge of editorial
practices in general and specifically of the processes of the RFC
Editor and the duties and challenges of the RSE. This criterion may
be ignored if one of the RSAG appointees is a leader in technical
publishing, per above.
The vast majority of RSE candidates will come from technical
publishing, a profession different from that of most members of the
community. Community members generally do not have extensive
experience in search and hiring. To ensure that qualified candidates
apply, the SSC will use the services of a professional search firm.
A search professional may act as SSC HR advisor, or the SSC may
require a separate HR advisor.
The RSE and IAOC will locate a professional search firm in
cooperation with the IAB. The SSC will have final approval of the
search professional. The RSE will support the IAOC in determining
budget requirements. The IAOC and IAB will seek financial support
for a search firm.
Kowack Expires April 29, 2011 [Page 41]
Internet-Draft RFC Editor Model (Version 2) October 2010
A.8. Non-Voting Members
In cooperation with the IAB, the TRSE will make a community call for
a volunteer HR professional to serve on the SSC. The SSC have final
approval for any such selection. If they a suitable candidate is not
found, an HR professional will be sought with the assistance of ISOC
staff; support will be sought from ISOC.
The TRSE will advise the SSC on the RSE job description and the
search and selection process, and on other topics on request. The
TRSE will draft calls for candidates before the first meeting of the
SSC and will be available to write or modify documents on request.
The HR professional will provide guidance on hiring law and on
standard HR processes, and practices.
A.9. SSC Assistants and Additional Expert Advisors
The SSC may engage volunteer help as needed from across the community
and elsewhere. The SSC will publish names of volunteers and their
roles. The SSC may also seek compensated expert help if required and
unavailable on a volunteer basis. Names and roles of experts will be
made public unless not possible due to confidentiality requirements.
A.10. SSC Approval of Job Description
The SSC will have final approval over job description postings, but
may not diverge from RFC 5620bis.
A.11. Financial and Legal Preparations
Before the public call for RSE candidates, in cooperation with the
IAB and the IAOC the TRSE will locate a suitable compensation
specialist to be hired by the IAOC. The specialist will work with
the TRSE to determine RSE compensation and related matters. In
cooperation with the IAB, the TRSE will support the IAOC in
determining a budget line item. The goal of the TRSE and IAOC is to
have this information in place before the first meeting of the SSC.
The SSC will review these items as soon as they are available and
have right of approval of the budget items. SSC approval is
required, also, to ensure that SSC are able to fulfill their mission.
The TRSE will publish RSE compensation information to the community
once it is available.
There will be a budget for the SSC. Besides including the search
firm and compensation specialist fees, the SSC and IAOC will agree on
an advertising budget, and other items as required by the SSC.
Kowack Expires April 29, 2011 [Page 42]
Internet-Draft RFC Editor Model (Version 2) October 2010
The SSC will review the IAOC's RSE contractual terms with the IAOC to
ensure that the process is effective and to maintain alignment
between candidate and community requirements from start to finish.
The committee may request changes to contract terms to reduce
unnecessary barriers to unconventional candidates of otherwise high
quality suited to this unusual position.
A.12. SSC Alignment with RSE Job Description
Hiring is a complex activity and no candidate will be a perfect fit.
However, the committee may not diverge from the job description and
5620bis.
A.13. SSC Call for Candidates
The call for candidates will describe the application process. It
will be distributed worldwide, including at least:
o across the community, and
o beyond the community:
o technical publications offices at universities and research
institutes,
o technical publishers, including journals,
o technical publications offices in technology companies,
o government technical publications offices, and
o other standards bodies, to be defined.
The SSC will determine where to post notices, including mail lists
and popular job posting web sites. The SSC is encouraged to use the
personal networks of the community to "get the word out" but also
cautioned to avoid language and postings that could encourage
unqualified applicants.
A.14. Applications and Short List
The SSC will be responsible, with the support of the RSE and the HR
professional, for the search and hiring process. The SSC will use
interviews, reference checks, and other means to select a short list
of no more than 10 candidates.
Kowack Expires April 29, 2011 [Page 43]
Internet-Draft RFC Editor Model (Version 2) October 2010
A.15. Confidentiality
Aspects of the hiring process must be confidential, out of respect
for candidates' needs, and by law. Nevertheless, the SSC will make
every effort to communicate progress to the community. It is likely
that community discussion of candidates will have to be limited to
individuals or small groups. Members of the SSC and volunteers who
participate in these reviews will be privy to confidential material
and must agree to respect confidentiality.
A.16. Best and Final
The SSC will select a final candidate, or, at their discretion, two
or three finalists. Before the SSC selects an RSE, the candidate(s)
will meet with community leaders and primary colleagues of the RSE,
including:
o IAB Chair,
o IAOC Chair and IAD,
o IETF chair,
o IRSG chair,
o Independent Submissions Editor, and
o Production Center Director.
These interviews are for thoroughness, and to give each candidate an
opportunity to meet the people with whom the RSE must work most
closely -- a critical step for anyone considering the position.
Interviews will be primarily by phone, but for a single preferred
candidate may be face-to-face, if necessary. Interview results will
be an important input to the SSC's decision. But these meetings do
not imply that participants have final approval or veto power over
the SSC's selection.
A.17. IAB Process Review
The SSC will send notice of their selection to the IAB. Notice will
include the candidate's qualifications with respect to the RSE job
description, and a review of the process. The IAB will review the
search and selection process for completeness and compliance. If the
IAB does not find any exceptions to process, it must approve the
candidate. The IAB may not change the selection of the committee.
If the IAB finds process exceptions, it must not step in and manage
the search and selection process. It must publish a report to the
Kowack Expires April 29, 2011 [Page 44]
Internet-Draft RFC Editor Model (Version 2) October 2010
community about what those exceptions are and call for new search and
selection activity with new process requirements.
A.18. IAOC / SSC Joint Negotiation
The SSC chair will shepherd the selected applicant through the final
contracting process. The IAOC will negotiate the contract with the
selected candidate in close consultation with the SSC chair. A start
date for the new RSE will be agreed during negotiations. Once a
contract is in place between the IAOC/SSC and the candidate, the IAB
will be notified and, following standard practice, the contract will
be forwarded to the Internet Society for signature. The SSC and IAOC
will support the IAB in drafting a public announcement. This will
complete the RSE selection process.
A.19. SSC DRAFT SCHEDULE
The committee will announce a final schedule soon after they are
appointed, starting with this draft schedule:
o 5620bis and Job Description agreed by community (target date TBD)
o Calls for SSC members (target date TBD)
o Announcement of SSC members (target date TBD)
o First SSC meeting (target date TBD)
o Financials and legal terms agreed (target date TBD)
o Final "Call for Candidates" text completed (target 9 November)
o SSC Call for Candidates (target 11 November at Beijing IETF)
o Close of Application Period (date TBD) [Ed., Holiday lag?]
o Vetting of "short list" of < 10 candidates (target date TBD)
o Determination of Best and Final List (target date TBD)
o Announcement of new RSE (target date TBD)
A.20. No Suitable Candidate
The SSC has the option to make no selection if they conclude that no
suitable candidate has been found. In this case, they will explain
this in their report and describe possible remedies. It will then be
up to the IAB to determine (1) how to provide for continuity of the
Kowack Expires April 29, 2011 [Page 45]
Internet-Draft RFC Editor Model (Version 2) October 2010
series for another fixed interim period, (2) what went wrong with the
job description or the search and selection process, and (3) what
sort of new process should be undertaken.
Author's Address
Glenn Kowack (editor)
Riveronce
Email: glenn@riveronce.com
Kowack Expires April 29, 2011 [Page 46]