4. Policy Implementation
This section preserves the RFC text for the RFC Editor Model, including RSWG, RSAB, RPC, RSCE, IETF LLC, Editorial Stream, appeals, policy implementation, and historical RFC Series properties.
Original RFC Text
4. Policy Implementation
4.1. Roles and Processes
Publication of RFCs is handled by the RFC Production Center (RPC).
A few general considerations apply:
* The general roles and responsibilities of the RPC are defined by
RFCs published in the Editorial Stream (i.e., not directly by the
RSWG, RSAB, or RSCE), by existing RFCs that apply to the RPC and
have not yet been superseded by Editorial Stream RFCs, and by the
requisite contracts.
* The RPC is advised by the RSCE and RSAB, and it has a duty to
consult with them under specific circumstances, such as those
relating to disagreements between authors and the RPC as described
in Section 4.4.
* The RPC is overseen by the IETF LLC to ensure that it performs in
accordance with contracts in place.
All matters of budget, timetable, and impact on its performance
targets are between the RPC and IETF LLC.
The RPC shall regularly provide reports to the IETF LLC, RSAB, RSWG,
and broader community regarding its activities and any key risks or
issues affecting it.
In the event that the RPC is required to make a decision without
consultation that would normally deserve consultation, or makes a
decision against the advice of the RSAB, the RPC must notify the
RSAB.
This document does not specify the exact relationship between the
IETF LLC and the RPC; for example, the work of the RPC could be
performed by a separate corporate entity under contract to the IETF
LLC, it could be performed by employees of the IETF LLC, or the IETF
LLC could engage with independent contractors for some or all aspects
of such work. The exact relationship is a matter for the IETF LLC to
determine.
The IETF LLC is responsible for the method and management of the
engagement of the RPC. Therefore, the IETF LLC has authority over
negotiating performance targets for the RPC and also has
responsibility for ensuring that those targets are met. Such
performance targets are set based on the RPC's publication load and
additional efforts required to implement policies specified in
Editorial Stream RFCs, in existing RFCs that apply to the RPC and
have not yet been superseded by Editorial Stream RFCs, and in the
requisite contracts. The IETF LLC may consult with the community
regarding these targets. The IETF LLC is empowered to appoint a
manager or to convene a committee to complete these activities.
If individuals or groups within the community have concerns about the
performance of the RPC, they can request that the matter be
investigated by the IETF LLC Board, the IETF Executive Director, or a
point of contact designated by the IETF LLC Board. Even if the IETF
LLC opts to delegate this activity, concerns should be raised with
the IETF LLC. The IETF LLC is ultimately answerable to the community
via the mechanisms outlined in [RFC8711].
4.2. Working Practices
In the absence of a high-level policy documented in an RFC or in the
interest of specifying the detail of its implementation of such
policies, the RPC can document working practices regarding the
editorial preparation, final publication, and dissemination of RFCs.
Examples include:
* Maintenance of a style guide that defines editorial standards for
RFCs; specifically, the RFC Style Guide consists of [RFC7322] and
the other documents and resources listed at [STYLEGUIDE].
* Instructions regarding the file formats that are accepted as input
to the editing and publication process.
* Guidelines regarding the final structure and layout of published
documents. In the context of the XML vocabulary [RFC7991], such
guidelines could include clarifications regarding the preferred
XML elements and attributes used to capture the semantic content
of RFCs.
4.3. RPC Responsibilities
The core responsibility of the RPC is the implementation of RFC
Series policies through publication of RFCs (including the dimensions
of document quality, timeliness of publication, and accessibility of
results), while taking into account issues raised by the community
through the RSWG and by the stream approving bodies. More
specifically, the RPC's responsibilities at the time of writing
include the following:
1. Editing documents originating from all RFC streams to ensure
that they are consistent with the editorial standards specified
in the RFC Style Guide.
2. Creating and preserving records of edits performed on documents.
3. Identifying where editorial changes might have technical impact
and seeking necessary clarification.
4. Establishing the publication readiness of each document through
communication with the authors, IANA, or stream-specific
contacts, supplemented if needed by the RSAB and RSCE.
5. Creating and preserving records of dialogue with document
authors.
6. Requesting advice from the RSAB and RSCE as needed.
7. Providing suggestions to the RSAB and RSCE as needed.
8. Participating within the RSWG in the creation of new Editorial
Stream RFCs that impact the RPC, specifically with respect to
any challenges the RPC might foresee with regard to
implementation of proposed policies.
9. Identifying topics and issues while processing documents or
carrying out other responsibilities on this list for which they
lack sufficient expertise, and identifying and conferring with
relevant experts as needed.
10. Providing reports to the community on its performance and plans.
11. Consulting with the community on its plans.
12. Negotiating its specific plans and resources with the IETF LLC.
13. Providing sufficient resources to support reviews of RPC
performance by the IETF LLC.
14. Coordinating with IANA to ensure that RFCs accurately document
registration processes and assigned values for IANA registries.
15. Assigning RFC numbers.
16. Liaising with stream approving bodies and other representatives
of the streams as needed.
17. Publishing RFCs, which includes:
* posting copies to the RFC Editor site both individually and
in collections
* depositing copies with external archives
* creating catalogs and catalog entries
* announcing the publication to interested parties
18. Providing online access to RFCs.
19. Providing an online system to facilitate the submission,
management, and display of errata to RFCs.
20. Maintaining the RFC Editor website.
21. Providing for the backup of RFCs.
22. Ensuring the storage and preservation of records.
23. Authenticating RFCs for legal proceedings.
(The text in the next two paragraphs is added by Section 1.2.1.)
The RPC is responsible for the development of tools and processes
used to implement Editorial Stream policies, in the absence of an RFC
with specific requirements. The RPC is responsible for detailed
technical specifications, for example, specific details of text or
graphical formats or XML grammar. The RPC may designate a team of
volunteers and/or employees who implement these operational
decisions. The RPC is expected to solicit input from experts and
community members when making implementation decisions. The RPC is
required to document implementation decisions in a publicly available
place, preferably with rationale.
If the RPC has questions about how to interpret policy in Editorial
Stream documents, they should ask the RSAB for guidance in
interpreting that policy per the process described in Section 4.4.
4.4. Resolution of Disagreements between Authors and the RPC
During the process of editorial preparation and publication,
disagreements can arise between the authors of an RFC-to-be and the
RPC. Where an existing policy clearly applies, typically such
disagreements are handled in a straightforward manner through direct
consultation between the authors and the RPC, sometimes in
collaboration with stream-specific contacts.
However, if it is unclear whether an existing policy applies or if it
is unclear how to interpret an existing policy, the parties may need
to consult with additional individuals or bodies (e.g., RSAB, IESG,
IRSG, or stream approving bodies) to help achieve a resolution. The
following points are intended to provide more specific guidance.
* If there is a conflict with a policy for a particular stream, to
help achieve a resolution, the RPC should consult with the
relevant stream approving body (such as the IESG or IRSG) and
other representatives of the relevant stream as appropriate.
* If there is a conflict with a cross-stream policy, the RPC should
consult with the RSAB to achieve a resolution.
* The disagreement might raise a new issue that is not covered by an
existing policy or that cannot be resolved through consultation
between the RPC and other relevant individuals and bodies, as
described above. In this case, the RSAB is responsible for (a)
resolving the disagreement in a timely manner if necessary so that
the relevant stream document(s) can be published before a new
policy is defined and (b) bringing the issue to the RSWG so that a
new policy can be defined.
(The text in the next paragraph is added by Section 1.2.2.)
If the RPC is responsible for interpreting policy decisions at both
the document and editorial process tooling level, conflicts on either
level will involve interpretation of written policy (or the
acknowledgment that policy does not exist to cover a given
situation). In any case, the conflict resolution will now use the
same path of appeal: to the RSAB.
4.5. Point of Contact
From time to time, individuals or organizations external to the IETF
and the broader RFC Series community may have questions about the RFC
Series. Such inquiries should be directed to the rfc-editor@rfc-
editor.org (mailto:[email protected]) email alias or to its
successor or future equivalent and then handled by the appropriate
bodies (e.g., RSAB and RPC) or individuals (e.g., RSWG Chairs and
RSCE).
4.6. Administrative Implementation
The exact implementation of the administrative and contractual
activities described here are a responsibility of the IETF LLC. This
section provides general guidance regarding several aspects of such
activities.
4.6.1. Vendor Selection for the RPC
Vendor selection is done in cooperation with the streams and under
the final authority of the IETF LLC.
The IETF LLC develops the work definition (the Statement of Work) for
the RPC and manages the vendor-selection process. The work
definition is created within the IETF LLC budget and takes into
account the RPC responsibilities (as described in Section 4.3), the
needs of the streams, and community input.
The process to select and contract for the RPC and other RFC-related
services is as follows:
* The IETF LLC establishes the contract process, including the steps
necessary to issue a Request for Proposal (RFP) when necessary,
the timing, and the contracting procedures.
* The IETF LLC establishes a selection committee, which will consist
of the IETF Executive Director and other members selected by the
IETF LLC in consultation with the stream approving bodies. The
committee shall select a chair from among its members.
* The selection committee selects the vendor, subject to the
successful negotiation of a contract approved by the IETF LLC. In
the event that a contract cannot be signed, the matter shall be
referred to the selection committee for further action.
4.6.2. Budget
Most expenses discussed in this document are not new expenses. They
have been and remain part of the IETF LLC budget.
The RFC Series portion of the IETF LLC budget shall include funding
to support the RSCE, the RFC Production Center, and the Independent
Stream.
The IETF LLC has the responsibility to approve the total RFC Editor
budget (and the authority to deny it). All relevant parties must
work within the IETF LLC budgetary process.