diff options
Diffstat (limited to 'doc/rfc/rfc8728.txt')
| -rw-r--r-- | doc/rfc/rfc8728.txt | 985 |
1 files changed, 985 insertions, 0 deletions
diff --git a/doc/rfc/rfc8728.txt b/doc/rfc/rfc8728.txt new file mode 100644 index 0000000..216fe84 --- /dev/null +++ b/doc/rfc/rfc8728.txt @@ -0,0 +1,985 @@ + + + + +Internet Architecture Board (IAB) O. Kolkman, Ed. +Request for Comments: 8728 Internet Society +Obsoletes: 6635 J. Halpern, Ed. +Category: Informational Ericsson +ISSN: 2070-1721 R. Hinden, Ed. + Check Point Software + February 2020 + + + RFC Editor Model (Version 2) + +Abstract + + The RFC Editor model described in this document divides the + responsibilities for the RFC Series into three functions: the RFC + Series Editor, the RFC Production Center, and the RFC Publisher. + Internet Architecture Board (IAB) oversight via the RFC Series + Oversight Committee (RSOC) is described, as is the relationship + between the IETF Administration Limited Liability Company and the + RSOC. This document reflects the experience gained with "RFC Editor + Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to + replace all references to the IETF Administrative Support Activity + (IASA) and related structures with those defined by the IASA 2.0 + Model. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. It represents the consensus of the + Internet Architecture Board (IAB). Documents approved for + publication by the IAB are not candidates for any level of Internet + Standard; see Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + https://www.rfc-editor.org/info/rfc8728. + +Copyright Notice + + Copyright (c) 2020 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://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. + +Table of Contents + + 1. Introduction + 1.1. The RFC Editor Function + 2. RFC Editor Model + 2.1. RFC Series Editor + 2.1.1. Strategic Leadership and Management of the Publication + and Production Functions + 2.1.2. Representation of the RFC Series + 2.1.2.1. Representation to the IETF + 2.1.2.2. External Representation + 2.1.3. Development of RFC Production and Publication + 2.1.4. Development of the RFC Series + 2.1.5. Workload + 2.1.6. Qualifications + 2.1.7. Conflict of Interest + 2.2. RFC Production Center + 2.3. RFC Publisher + 3. Committees + 3.1. RFC Series Oversight Committee (RSOC) + 3.1.1. RSOC Composition + 4. Administrative Implementation + 4.1. Vendor Selection for the Production and Publisher Functions + 4.2. Budget + 4.3. Disagreements among Entities Related to the RFC Editor + 4.4. Issues with Contractual Impact + 5. IANA Considerations + 6. Security Considerations + 7. References + 7.1. Normative References + 7.2. Informative References + IAB Members at the Time of Approval + Acknowledgments + Authors' Addresses + +1. Introduction + + This document reflects the experience gained with "RFC Editor Model + (Version 1)", documented in [RFC5620], and updates the RFC Editor + Model (Version 2) to be aligned with the new IASA 2.0 Model [RFC8711] + that creates the IETF Administration Limited Liability Company (IETF + LLC) managed by a board of directors (IETF LLC Board). As part of + the IASA 2.0 Model, the IETF Administrative Oversight Committee + (IAOC) is eliminated, and its oversight and advising functions + transferred to the new IETF LLC. This document obsoletes [RFC6635] + to replace all references to the IASA and related structures with + those defined by the IASA 2.0 Model. + + The IAB, on behalf of the Internet technical community, is concerned + with ensuring the continuity of the RFC Series, orderly RFC Editor + succession, RFC quality, and RFC document accessibility. The IAB is + also sensitive to the concerns of the IETF LLC about providing the + necessary services in a cost-effective and efficient manner. + + The previous RFC Editor model [RFC5620] was first approved by the IAB + in October 2008, and our understanding of the model has evolved with + our experience since. During the implementation of version 1 of the + model [RFC5620], it was quickly realized that the role of the RFC + Series Editor (RSE) and the oversight responsibilities needed to be + structured differently. In order to gain experience with "running + code", a transitional RSE was hired who analyzed the managerial + environment and provided recommendations. This was followed by the + appointment of an acting RSE, who ably managed the series while work + was undertaken to select and hire a permanent RSE. This version of + the model is based on the recommendations of both temporary RFC + Series Editors and the extensive discussion in the IETF community, on + the rfc-interest list, and within the IAB. + + This document, and the resulting structures, will be modified as + needed through normal procedures. The RSE, and the IAB, through the + RFC Series Oversight Committee (see Section 3.1), will continue to + monitor discussions within the community about potential adjustments + to the RFC Editor model and recognize that the process described in + this document may need to be adjusted to align with any changes that + result from such discussions; hence, the version number in the title. + + The IAB maintains its responsibilities as defined in [RFC2850]. + +1.1. The RFC Editor Function + + The RFC Series is described in [RFC8729]. Its Section 3.1 defines + "RFC Editor": + + | Originally, there was a single person acting as editor of the RFC + | Series (the RFC Editor). The task has grown, and the work now + | requires the organized activity of several experts, so there are + | RFC Editors, or an RFC Editor organization. In time, there may be + | multiple organizations working together to undertake the work + | required by the RFC Series. For simplicity's sake, and without + | attempting to predict how the role might be subdivided among them, + | this document refers to this collection of experts and + | organizations as the "RFC Editor". + | + | The RFC Editor is an expert technical editor and series editor, + | acting to support the mission of the RFC Series. As such, the RFC + | Editor is the implementer handling the editorial management of the + | RFC Series, in accordance with the defined processes. In + | addition, the RFC Editor is expected to be the expert and prime + | mover in discussions about policies for editing, publishing, and + | archiving RFCs. + + RFC 8729 does not explore the internal organization of the RFC + Editor. However, RFC 8729 envisions changes in the RFC Editor + organizational structure. There have been several iterations on + efforts to improve and clarify this structure. These have been led + by the IAB, in consultation with the community and many leadership + bodies within the community. This first resulted in the publication + of [RFC5620] and then in further discussions leading to the + publication of [RFC6635]. Some of the details on this evolution can + be found below. In undertaking this evolution, the IAB considered + changes that increase flexibility and operational support options, + provide for the orderly succession of the RFC Editor, and ensure the + continuity of the RFC Series, while maintaining RFC quality, + maintaining timely processing, ensuring document accessibility, + reducing costs, and increasing cost transparency. The model set + forth below describes the internal organization of the RFC Editor, + while remaining consistent with RFC 8729. + + Note that RFC 8729 uses the term "RFC Editor function" or "RFC + Editor" as the collective set of responsibilities for which this memo + provides a model for internal organization. This memo defines the + term "RFC Series Editor" or "Series Editor" for one of the + organizational components. + +2. RFC Editor Model + + The RFC Editor model divides the responsibilities for the RFC Series + into the following components: + + * RFC Series Editor (RSE) + + * RFC Production Center + + * RFC Publisher + + The structure and relationship of the components of the RFC Series + production and process is schematically represented by Figure 1. The + picture does not depict oversight and escalation relations. It does + include the streams and their managers (which are not part of the RFC + Series Editor, the RFC Production Center, or Publisher facilities) in + order to more fully show the context in which the RFC Series Editor + operates. + + +-------------+ + | | + +--------------+ IAB <----------+ + | | | | + | |=============| | + | | | | + | | RSOC <----------+ + | | | | + | +-------+-----+ +----+----+ + | | | | + | +...........|.........+ |Community| + | . | . | at | + | . +-------V-----+ . | Large | + | . | | . | | + | . | RFC | . +----+----+ + | . | Series | . | + | . | Editor <----------+ + | . | | . + | . +-+---------+-+ . + | . | | . + +-------------+ +-----V-------+ . +--V--+ +--V--+ . +-----+ + | | | | . | | | | . | | + | Independent | | Independent | . | RFC | | | . | E | + | Authors +--> Submission +-----> | | | . | n | + | | | Editor | . | P | | | . | d | + | | | | . | r | | RFC | . | | + +-------------+ +-------------+ . | o | | | . | U | + +-------------+ +-------------+ . | d | | P | . | s | + | | | | . | u | | u | . | e | + | IAB +--> IAB +-----> c | | b | . | r | + | | | | . | t | | l | . | s | + +-------------+ +-------------+ . | i +---> i +--------> | + +-------------+ +-------------+ . | o | | s | . | & | + | | | | . | n | | h | . | | + | IRTF +--> IRSG +---->| | | e | . | R | + | | | | . | C | | r | . | e | + +-------------+ +-------------+ . | e | | | . | a | + +-------------+ +-------------+ . | n | | | . | d | + | | | | . | t | | | . | e | + | IETF +--> IESG +-----> e | | | . | r | + | | | | . | r | | | . | s | + +-------------+ +-------------+ . +-----+ +-----+ . +-----+ + . . + +..... RFC Editor ....+ + + Figure 1: Structure of RFC Series Production and Process + + In this model, documents are produced and approved through multiple + document streams. The stream manager for each stream is responsible + for the content of that stream. The four streams that now exist are + described in [RFC8729]. The RFC Editor function is responsible for + the packaging and distribution of the documents. As such, documents + from these streams are edited and processed by the Production Center + and published by the Publisher. The RFC Series Editor will exercise + strategic leadership and management over the activities of the RFC + Publisher and the RFC Production Center (both of which can be seen as + back-office functions) and will be the entity that: + + * Represents the RFC Series and the RFC Editor function within the + IETF and externally. + + * Leads the community in the design of improvements to the RFC + Series. + + * Is responsible for planning and seeing to the execution of + improvements in the RFC Editor production and access processes. + + * Is responsible for the content of the rfc-editor.org web site, + which is operated and maintained by the RFC Publisher. + + * Is responsible for developing consensus versions of vision and + policy documents. These documents will be reviewed by the RFC + Series Oversight Committee (Section 3.1) and subject to its + approval before final publication. + + These responsibilities are defined below, although the specific work + items under them are a matter for the actual employment contract and + its Statement of Work (SOW). + + The IAB maintain its chartered responsibility as defined in + [RFC2850]. More details on the oversight by the IAB via the RFC + Series Oversight Committee (RSOC) can be found in Section 3.1. For + example, the RSE does not have the direct authority to hire or fire + RFC Editor contractors or personnel. + +2.1. RFC Series Editor + + The RFC Series Editor is the individual with overall responsibility + for the quality, continuity, and evolution of the RFC Series. + + The RSE is appointed by the IAB, but formally hired by the IETF LLC. + The IAB delegates the direct oversight over the RSE to the RSOC, + which it appoints. + + The RSE is expected to cooperate closely with the IETF LLC and the + stream managers. + +2.1.1. Strategic Leadership and Management of the Publication and + Production Functions + + With respect to the RFC Publisher and Production Center functions, + the RSE provides input to the IETF LLC budget, SOWs, and manages + vendor selection processes. The RSE performs annual reviews of the + RFC Production Center and Publisher function, which are then provided + to the RSOC, the IETF LLC, and the community. Normally, private + financial details would not be included in a public version unless + the IETF LLC concludes it is necessary to make such information + public. + + The RSE is responsible for the performance of the RFC Production + Center and Publisher. The RSE is responsible for issues that go + beyond the RFC Production Center or Publisher functions, such as + cross-stream coordination of priorities. Issues that require changes + to the budget or contracts shall be brought to the attention of the + IETF LLC by the RSE. + + The RSE is also responsible for creating documentation and structures + that will allow for continuity of the RFC Series in the face of + changes in contracts and personnel. + + Vendor selection for the RFC Production Center and Publisher + functions is done in cooperation with the streams and under final + authority of the IETF LLC. Details on this process can be found in + Section 4.1. + +2.1.2. Representation of the RFC Series + + The RSE is the primary representative of the RFC Series. This + representation is important both internally, relative to the IETF, + and externally. + +2.1.2.1. Representation to the IETF + + The RSE is the primary point of contact to the IETF on matters + relating to the RFC Series in general, or policy matters relating to + specific documents. Issues of practical details in the processing of + specific documents are generally worked through directly with the RFC + Production Center staff. + + This includes providing suitable reports to the community at large, + providing email contact for policy questions and inputs, and enabling + and participating in suitable on-line forums for discussion of issues + related to the RFC Series. + + Due to the history and nature of the interaction between the RSE and + the IETF, certain principles, described in the following subsections, + must be understood and adhered to by the RSE in his or her + interactions with the community. These apply to the representation + function, as well as to the leadership the RSE provides for + production and series development. + +2.1.2.1.1. Volunteerism + + The vast majority of Internet technical community work is led, + initiated, and done by community volunteers, including oversight, + policy making, and direct production of, for example, many software + tools. The RSE, while not a volunteer, is dependent upon these + volunteer participants. Also, the spirit of the community is heavily + focused on and draws from these volunteers. As such, the RSE needs + to support the vitality and effectiveness of volunteer participation. + +2.1.2.1.2. Policy Authority + + All decisions are to be made in the overall interest of the broader + Internet community. The RSE is responsible for identifying + materially concerned interest groups within the Internet community + and reaching out to them. Those interest groups include at least the + IETF community, the IRTF community, the network research community, + and the network operations community. Other interest groups might + also be materially interested. + + The RSE must consult with the community on policy issues. The RSE + works with the community to achieve policy that meets the overall + quality, continuity, and evolution goals the RSE is charged with + meeting. As described in Section 3.1, the RSE reports the results of + such interactions to the RSOC, including a description of the + outreach efforts and the specific recommendations on policy. This + enables the RSOC to provide the oversight the IAB is required to + apply, as well as to confirm that the Internet community has been + properly consulted and considered in making policy. + +2.1.2.2. External Representation + + From time to time, individuals or organizations external to the IETF + need a contact person to talk to about the RFC Series. The RSE, or + the RSE's designate, serves this role. + + Over time, the RSE should determine what, if any, means should be + employed to increase end-user awareness of the series, to reinforce + the stature of the series, and to provide the contact point for + outside parties seeking information on the series or the Editor. + +2.1.3. Development of RFC Production and Publication + + Closely related to providing strategic leadership and management to + the RFC Production Center and Publisher functions is the need to + develop and improve those functions. The RSE is responsible for + ensuring that such ongoing development takes place. + + This effort must include the dimensions of document quality, + timeliness of production, and accessibility of results. It must also + specifically take into account issues raised by the IETF community, + including all the streams feeding into the RFC Editor function. + +2.1.4. Development of the RFC Series + + In order to develop the RFC Series, the RSE is expected to develop a + relationship with the Internet technical community. The Editor is + expected to engage with the Internet technical community in a process + of articulating and refining a vision for the series and its + continuous evolution. The RSE is also expected to engage other users + of the RFC Series, in particular, the consumers of these documents, + such as those people who use them to specify products, write code, + test behaviors, or other related activities. + + Concretely: + + The RSE is responsible for the coordination of discussion on + series evolution among the series' stream participants and the + broader Internet technical community. + + In time, the RSE is expected to develop and refine a vision for + the RFC Series, including examining: + + - The RFC Series, as it continues to evolve. The RSE is expected + to take a broad view and look for the best ways to evolve the + series for the benefit of the entire Internet community. As + such, the RSE may even consider evolution beyond the historical + 'by engineers for engineers' emphasis; and + + - Its publication-technical environment, by looking at whether it + should be slowly changing in terms of publishing and archiving + techniques -- particularly to better serve the communities that + produce and depend on the RFC Series. For example, all of + those communities have been slowly changing to include a + significant population of multi-lingual individuals or non- + native speakers of English. Another example is that some of + these constituencies also have shifted to include significant + groups whose primary focus is on the constraints and + consequences of network engineering, rather than a primary + interest in the engineering issues themselves. + + For this type of responsibility, the RSE cooperates closely with the + community, and operates under oversight of the RSOC: thus, + ultimately, under oversight of the IAB. + +2.1.5. Workload + + On average, the job is expected to take half of a full-time + equivalent position (FTE, thus approximately 20 hrs per week), with + the workload per week nearing full time during IETF weeks. In + addition, the job is expected to take more than 20 hours per week in + the first few months of the engagement and when involved in special + projects. + +2.1.6. Qualifications + + The RFC Series Editor is a senior technology professional. The + following qualifications are desired: + + 1. Strategic leadership and management experience fulfilling the + requirements outlined in this document, the many aspects of this + role, and the coordination of the overall RFC Editor process. + + 2. Good understanding of the English language and technical + terminology related to the Internet. + + 3. Good communication skills. + + 4. Experience with editorial processes. + + 5. Ability to develop strong understanding of the IETF and RFC + process. + + 6. Independent worker. + + 7. Willingness to, and availability for, travel. + + 8. The ability to work effectively in a multi-actor and matrixed + environment with divided authority and responsibility similar to + that described in this document. + + 9. Experience with and ability to participate in, and manage, + activities by email and teleconferences, not just face-to-face + interactions. + + 10. Demonstrated experience in strategic planning and the management + of entire operations. + + 11. Experience as an RFC author. + +2.1.7. Conflict of Interest + + The RSE is expected to avoid even the appearance of conflict of + interest or judgment in performing these roles. To ensure this, the + RSE will be subject to a conflict of interest policy established by + the IETF LLC. + +2.2. RFC Production Center + + The RFC Production Center function is performed by a paid contractor, + and the contractor's responsibilities include the following: + + 1. Editing inputs from all RFC streams to comply with the RFC Style + Manual, under the direction of the RSE; + + 2. Creating records of edits performed on documents; + + 3. Identifying where editorial changes might have technical impact + and seeking necessary clarification; + + 4. Engaging in dialog with authors, document shepherds, IANA, and/ + or stream-dependent contacts when clarification is needed; + + 5. Creating records of dialog with document authors; + + 6. Requesting advice from the RFC Series Editor as needed; + + 7. Providing 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 function initiated by the IAB or IETF + LLC; + + 9. Coordinating with IANA to ensure correct documentation of IANA- + performed protocol registry actions; + + 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 documents that are ready for publication to the RFC + Publisher; + + 13. Forwarding records of edits and author dialog to the RFC + Publisher so these can be preserved; + + 14. Liaising with the streams as needed. + + All these activities will be done under the general direction, but + not day-to-day management, of the RSE and need some level of + coordination with various submission streams and the RSE. + + The RFC Production Center contractor is to be selected through an + IETF LLC Request for Proposal (RFP) process as described in + Section 4.1. + +2.3. RFC Publisher + + The RFC Publisher responsibilities include the following: + + 1. Announcing and providing on-line access to RFCs. + + 2. Providing an 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 will be done under the general direction, but + not day-to-day management, of the RSE and need some level of + coordination with various submission streams and the RSE. + + The RFC Publisher contractor is to be selected through an IETF LLC + RFP process as described in Section 4.1. + +3. Committees + +3.1. RFC Series Oversight Committee (RSOC) + + The IAB is responsible for the oversight of the RFC Series and acts + as a body for final conflict resolution, including the process + described in Section 4.3. + + In order to provide continuity over periods longer than the NomCom + appointment cycle [RFC8713] and assure that oversight includes + suitable subject matter expertise, the IAB will establish a group + that implements oversight for the IAB, the RFC Series Oversight + Committee (RSOC). + + The RSOC will act with authority delegated from the IAB: in general, + it will be the RSOC that will approve consensus policy and vision + documents as developed by the RSE in collaboration with the + community. While it is expected that the IAB will exercise due + diligence in its supervision of the RSOC, the RSOC should be allowed + the latitude to do its job without undue interference from the IAB. + Therefore, it is expected that the IAB will accord RSOC reports and + recommendations the benefit of the doubt. + + For all decisions that affect the RSE individually (e.g., hiring and + firing), the RSOC prepares recommendations for the IAB. The final + recommendation to the IETF LLC is the responsibility of the IAB, + after discussion with RSOC on the recommendations. For instance the + RSOC would do the following: + + * perform annual reviews of the RSE and report the result of these + reviews to the IAB. + + * manage RSE candidate selection and advise the IAB on candidate + appointment (in other words, select the RSE subject to IAB + approval). + + RSOC members are expected to recognize potential conflicts of + interest and behave accordingly. + + For the actual recruitment and selection of the RSE, the RSOC will + propose a budget for the search process. It will work with the IETF + LLC to refine that budget and develop remuneration criteria and an + employment agreement or contracting plans, as appropriate. + + The RSOC will be responsible for ensuring that the RFC Series is run + in a transparent and accountable manner. + + The RSOC shall develop and publish its own rules of order. + + The initial RSOC was charged with designing and executing a + solicitation, search, and selection process for the first actual (not + transitional or "acting") RSE appointment. That process involved + iteration on this and related documents and evaluation of various + strategies and options. During the creation of what became + [RFC6635], it was expected that the RSOC would describe the process + it ultimately selected to the community. The RSOC did involve the + community in interim considerations when that was likely to be of + value. Following completion of the selection process, the RSOC will + determine the best way to share information learned and experience + gained with the community and determine how to best preserve that + information for future use. + +3.1.1. RSOC Composition + + The RSOC will operate under the authority of the IAB, with the IAB + retaining final responsibility. The IAB will delegate authority and + responsibility to the RSOC as appropriate and as RSOC and RSE + relationships evolve. The RSOC will include people who are not + current IAB members. Currently, this is aligned with the IAB program + structure. The IAB will designate the membership of the RSOC with + the following goals: preserving effective stability; keeping it small + enough to be effective, and keeping it large enough to provide + general Internet community expertise, specific IETF expertise, + publication expertise, and stream expertise. Members serve at the + pleasure of the IAB and are expected to bring a balance between + short- and long-term perspectives. Specific input about, and + recommendations of, members will be sought from the streams, the IETF + LLC, and the RSE. + + In addition to the members from outside of the IAB appointed to the + RSOC, IAB members may participate as full members of the RSOC. Under + most circumstances, there will be a specific individual IAB member + appointed by the IAB as the program lead, who will be a full member + of the RSOC. This member's role is distinct from any RSOC-internal + organizational roles, such as would be created by the RSOC choosing + to appoint a chair from among its members. Other IAB members may + choose to be full members of the RSOC, with the consent of the IAB. + This consent is primarily concerned with avoiding overpopulating the + RSOC and providing it with relatively stable membership, which will + work best if it is not too large a committee. + + The IETF LLC will appoint an individual to serve as its liaison to + the RSOC. The RSE and the IETF LLC Liaison will serve as non-voting + ex officio members of the RSOC. Either or both can be excluded from + its discussions if necessary. + +4. Administrative Implementation + + The exact implementation of the administrative and contractual + activities described here are a responsibility of the IETF + Administration Limited Liability Company [RFC8711] in cooperation + with the RFC Series Editor. The authority structure is described in + Figure 2. + + +----------------+ +----------------+ + | | | | + | IAB | | IETF LLC | + | | | | + +==========+-----+ +-+--------------+ + | | . + | RSOC | . + | | . + +----+-----+ . + | . + | . + | ................... + | . . + +--------V---V----+ . + | | . + | RFC | . + | Series | . + | Editor | . + | | . + +--------+--------+ . + | . + | ................. + | . . + +--+----------------+ . + | . | . + | . | . + +---V-----V--+ +--V----V---+ + | RFC | | RFC | + | Production | | Publisher | + | Center | | | + +------------+ +-----------+ + + Legend: + + ------- IAB RFC Series Oversight + ....... IETF LLC Contract/Budget Oversight + + Figure 2: Authority Structure of the RFC Series + +4.1. Vendor Selection for the Production and Publisher Functions + + As stated earlier, vendor selection is done in cooperation with the + streams and under the final authority of the IETF LLC. + + The RSE owns and develops the work definition (the SOW) and + participates in the IETF LLC vendor selection process. The work + definition is created within the IETF LLC budget and takes into + account the stream managers and community input. + + The process to select and contract for an RFC Production Center, RFC + Publisher, and other RFC-related services, is as follows: + + * The IETF LLC establishes the contract process, including the steps + necessary to issue an RFP when necessary, the timing, and the + contracting procedures. + + * The IETF LLC establishes the Selection Committee, which will + consist of the RSE, the IETF LLC Executive Director, and other + members selected by the RSOC and the IETF LLC. The Committee + shall be chaired by the RSE. + + * 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 reached, the matter shall be + referred to the Selection Committee for further action. + + * The Selection Committee may select an RFC Publisher either through + the IETF LLC RFP process or, at the Committee's option, the + Committee may select the IETF Secretariat to provide RFC Publisher + services, subject to negotiations in accordance with the IETF LLC + procedures. + +4.2. Budget + + The expenses discussed in this document are not new expenses. They + have been and remain part of the IETF Administration Limited + Liability Company [RFC8711] budget. + + The RFC Series portion of the IETF LLC budget shall include funding + to support the RSE, RFC Production Center, RFC Publisher, and the + Independent Stream. + + The IETF LLC has the responsibility to approve the total RFC Editor + budget (and the authority to deny it). The RSE must work within the + IETF LLC budgetary process. + + The RSE is responsible for managing the RFC Editor function to + operate within those budgets. If production needs change, the RSE is + responsible for working with the Production Center, and where + appropriate, other RFC Editor component institutions, relevant + streams, and/or the RSOC to determine what the correct response + should be. If they agree that a budgetary change is needed, that + decision needs to be taken to the IETF LLC. + +4.3. Disagreements among Entities Related to the RFC Editor + + The RFC Series Editor and the RFC Production Center and Publisher + facilities work with the various streams to produce RFCs. + Disagreements may arise between these entities during the execution + of the RFC Editor operations. In particular, different streams may + disagree with each other, or disagree with the RFC Editor function. + Potentially, even the RSOC or the IETF LLC could find themselves in + disagreement with some aspect of the RFC Editor operations. Note + that disagreements between an author and the RFC Production Center + are not cross-entity issues, and they are to be resolved by the RSE, + in accordance with the rest of this document. + + If such cross-entity disagreements arise, the community would + generally hope that they can be resolved politely and directly. + However, this is not always possible. At that point, any relevant + party would first formally request a review and reconsideration of + the decision. If the party still disagrees after the + reconsideration, that party may ask the RSE to decide or, especially + if the RSE is involved, the party may ask the IAB Chair (for a + technical or procedural matter) to mediate or appoint a mediator to + aid in the discussions, although he or she not is obligated to do so. + All parties should work informally and in good faith to reach a + mutually agreeable conclusion. As noted below, any such issues that + involve contractual matters must be brought to the attention of the + IETF LLC. If the IAB Chair is asked to assist in resolving the + matter, the Chair may ask for advice or seek assistance from anyone + the Chair deems helpful. The Chair may also alert any appropriate + individuals or organizations to the existence of the issue. + + If such a conclusion is not possible through the above less formal + processes, then the matter must be registered with the RFC Series + Oversight Committee. The RSOC may choose to offer advice to the RSE + or more general advice to the parties involved and may ask the RSE to + defer a decision until it formulates its advice. However, if a + timely decision cannot be reached through discussion, mediation, and + mutual agreement, the RSE is expected to make whatever decisions are + needed to ensure the smooth operation of the RFC Editor function; + those decisions are final. + + The RSE may make final decisions unilaterally only to assure the + functioning of the process, and only while there is an evaluation of + current policies to determine whether they are appropriately + implemented in the decision or need adjustment. In particular, it + should be noted that final decisions about the technical content of + individual documents are the exclusive responsibility of the stream + approvers from which those documents originate, as shown in the + illustration in Figure 1. + + If informal agreements cannot be reached, then formal RSOC review and + decision making may be required. If so, the RSE must present the + issues involved to the community so that the community is aware of + the situation. The RSE will then report the issue to the RSOC for + formal resolution by the RSOC with confirmation by the IAB in its + oversight capacity. + + IAB and community discussion of any patterns of disputes are expected + to inform future changes to RFC Series policies, including possible + updates to this document. + +4.4. Issues with Contractual Impact + + If a disagreement or decision has immediate or future contractual + consequences, it falls under [RFC8711]. If this happens, the RSE + must identify the issue and provide advice to the IETF LLC. + Additionally, if the RSOC has also developed advice, it should + forward that advice to the IETF LLC. + + The IETF LLC must notify the RSOC and IAB regarding the action it + concludes is required to resolve the issue based on its applicable + procedures and provisions in the relevant contracts. + +5. IANA Considerations + + This document defines several functions within the overall RFC Editor + structure, and it places the responsibility for coordination of + registry value assignments with the RFC Production Center. The IETF + LLC will facilitate the establishment of the relationship between the + RFC Production Center 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. + +6. Security Considerations + + The same security considerations as those in [RFC8729] 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 + 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, originals + that are not machine readable) need to be secured against any kind of + data storage failure. + + The IETF LLC should take these security considerations into account + during the implementation and enforcement of the RFC Editor component + contracts. + +7. References + +7.1. Normative References + + [RFC2850] Internet Architecture Board and B. Carpenter, Ed., + "Charter of the Internet Architecture Board (IAB)", + BCP 39, RFC 2850, DOI 10.17487/RFC2850, May 2000, + <https://www.rfc-editor.org/info/rfc2850>. + + [RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor + Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June + 2012, <https://www.rfc-editor.org/info/rfc6635>. + + [RFC8711] Haberman, B., Hall, J., and J. Livingood, "Structure of + the IETF Administrative Support Activity, Version 2.0", + BCP 101, RFC 8711, DOI 10.17487/RFC8711, February 2020, + <https://www.rfc-editor.org/info/rfc8711>. + + [RFC8729] Housley, R., Ed. and L. Daigle, Ed., "The RFC Series and + RFC Editor", RFC 8729, DOI 10.17487/RFC8729, February + 2020, <https://www.rfc-editor.org/info/rfc8729>. + +7.2. Informative References + + [RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", + RFC 5620, DOI 10.17487/RFC5620, August 2009, + <https://www.rfc-editor.org/info/rfc5620>. + + [RFC8713] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, + Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, + Confirmation, and Recall Process: Operation of the IETF + Nominating and Recall Committees", BCP 10, RFC 8713, + DOI 10.17487/RFC8713, February 2020, + <https://www.rfc-editor.org/info/rfc8713>. + +IAB Members at the Time of Approval + + Internet Architecture Board Members at the time this document was + approved for publication were: + + Jari Arkko + Alissa Cooper + Stephen Farrell + Wes Hardaker + Ted Hardie + Christian Huitema + Zhenbin Li + Erik Nordmark + Mark Nottingham + Melinda Shore + Jeff Tantsura + Martin Thomson + Brian Trammell + +Acknowledgments + + The RFC Editor model was conceived and discussed in hallways and on + mailing lists. The first iteration of the text on which this + document is based was first written by Leslie Daigle, Russ Housley, + and Ray Pelletier. In addition to the members of the IAOC and IAB in + conjunction with those roles, major and minor contributions were made + by (in alphabetical order): Bob Braden, Brian Carpenter, Sandy + Ginoza, Joel M. Halpern, Alfred Hoenes, Paul Hoffman, John Klensin, + Subramanian Moonesamy, Alice Russo, and Jim Schaad. + + The IAOC members at the time RFC 6635 was approved were (in + alphabetical order): Bernard Aboba (ex officio), Eric Burger, Dave + Crocker, Marshall Eubanks, Bob Hinden, Russ Housley (ex officio), Ole + Jacobsen, Ray Pelletier (non-voting), and Lynn St. Amour (ex + officio). + + The IAB members at the time the initial RFC Editor model (Version 1, + RFC 5620) was approved were (in alphabetical order): Loa Andersson, + Gonzalo Camarillo, Stuart Cheshire, Russ Housley, Olaf Kolkman, + Gregory Lebovitz, Barry Leiba, Kurtis Lindqvist, Andrew Malis, Danny + McPherson, David Oran, Dave Thaler, and Lixia Zhang. In addition, + the IAB included two ex officio members: Dow Street, who was serving + as the IAB Executive Director, and Aaron Falk, who was serving as the + IRTF Chair. + + The IAB members at the time RFC 6635 was approved were (in + alphabetical order): Bernard Aboba, Ross Callon, Alissa Cooper, + Spencer Dawkins, Joel Halpern, Russ Housley, David Kessens, Olaf + Kolkman, Danny McPherson, Jon Peterson, Andrei Robachevsky, Dave + Thaler, and Hannes Tschofenig. In addition, at the time of approval + of RFC 6635, the IAB included two ex officio members: Mary Barnes who + was serving as the IAB Executive Director, and Lars Eggert, who was + serving as the IRTF Chair. + + Bob Hinden served as document editor for this RFC to align it with + the IASA 2.0 structure. + +Authors' Addresses + + Olaf Kolkman (editor) + Internet Society + + Email: kolkman@isoc.org + + + Joel M. Halpern (editor) + Ericsson + + Email: joel.halpern@ericsson.com + + + Robert M. Hinden (editor) + Check Point Software + 959 Skyway Road + San Carlos, CA 94070 + United States of America + + Email: bob.hinden@gmail.com |