From 8a739d49df0fef123a08d5673a223a1cd0062798 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 16 Mar 2022 09:39:11 -0600 Subject: [PATCH] consistency check, expansion of acronyms, more acknowledgements --- draft-iab-rfcefdp-rfced-model.md | 66 ++++++++++++++++++-------------- 1 file changed, 37 insertions(+), 29 deletions(-) diff --git a/draft-iab-rfcefdp-rfced-model.md b/draft-iab-rfcefdp-rfced-model.md index a9a9e32..52a57b7 100644 --- a/draft-iab-rfcefdp-rfced-model.md +++ b/draft-iab-rfcefdp-rfced-model.md @@ -91,8 +91,10 @@ The overall framework for the RFC Series and the RFC Editor Function is described in {{RFC8729}} and is updated by this document, which defines version 3 of the RFC Editor Model. Under this version, various responsibilities of the RFC Editor -Function are performed alone or in combination by the RSWG, -RSAB, RPC, RFC Series Consulting Editor (RSCE), and IETF LLC, +Function are performed alone or in combination by the RFC Series +Working Group (RSWG), RFC Series Advisory Board (RSAB), RFC +Production Center (RPC), RFC Series Consulting Editor (RSCE), and +IETF Administration Limited Liability Company (IETF LLC) {{RFC8711}}, which collectively comprise the RFC Editor Function. The intent is to ensure sustainable maintenance and support of the RFC Series based on the principles of expert implementation, clear management @@ -104,7 +106,7 @@ by defining boilerplate text for the Editorial Stream. This document updates {{RFC8729}} by replacing the RFC Editor role with the RSWG, RSAB, and RSCE. This document updates {{RFC8730}} by removing the dependency on certain policies specified by the -IAB and RSE. More detailed information about changes from +IAB and RFC Series Editor (RSE). More detailed information about changes from version 2 of the Model can be found under {{changes}}. # Overview of the Model @@ -118,7 +120,7 @@ Group (RSWG) is an open working group independent of the IETF that generates policy proposals. Second, the RFC Series Approval Board (RSAB) is an appointed body that approves such proposals for publication in the Editorial Stream. The RSAB includes representatives of the -streams {{RFC8728}} as well as an expert in technical publishing, +streams {{RFC8729}} as well as an expert in technical publishing, the RFC Series Consulting Editor (RSCE). 2. Policy implementation through publication of RFCs in all of the @@ -159,7 +161,7 @@ Policies governing the RFC Series as a whole are defined through the following high-level process: 1. Proposals must be submitted to, adopted by, and discussed within the RFC -Series Working Group (RSWG), +Series Working Group (RSWG). 2. Proposals must pass a last call for comments in the working group and a community call for comments (see {{cfc}}). @@ -222,7 +224,7 @@ proposals to the RSAB. #### Mode of Operation -The intent is that the RSWG shall operate in a way similar to working +The intent is that the RSWG shall operate in a way similar to that of working groups in the IETF. Therefore, all RSWG meetings and discussion venues shall be open to all interested individuals, and all RSWG contributions shall be subject to intellectual @@ -270,8 +272,8 @@ and balances" on the output of the RSWG. The only policy-making role of the RSAB is to review policy proposals generated by the RSWG; it shall have no independent authority to formulate policy on its own. It is expected that the RSAB will respect the rough consensus of the -RSWG wherever possible, without ceding its responsibility to provide -their review of RSWG proposals as further described under {{workflow}}. +RSWG wherever possible, without ceding its responsibility to +review RSWG proposals as further described under {{workflow}}. #### Members @@ -316,7 +318,7 @@ formally collaborate or coordinate. #### Appointment and Removal of Voting Members The appointing bodies, i.e., the stream approving bodies (IESG, IAB, -IRTF chair, ISE), shall determine their own processes for +IRTF chair, and ISE), shall determine their own processes for appointing RSAB members (note that processes related to the RSCE are described under {{rsce}}). Each appointing body shall have the power to remove its appointed RSAB member at its discretion at any time. @@ -326,8 +328,8 @@ necessary on a temporary basis. In the case that the IRTF chair or ISE is incapacitated or otherwise unable to appoint another person to serve as a delegate, -the IAB (as the appointing body for the IRTF chair and ISE -respectively) shall act as the temporary appointing body for those +the IAB (as the appointing body for the IRTF chair and ISE) +shall act as the temporary appointing body for those streams and shall appoint a temporary member of the RSAB until the IAB has appointed an IRTF chair or ISE, who can then act as an RSAB member or appoint a delegate through normal processes. @@ -444,7 +446,7 @@ related to the RFC Series: 4. At some point, if the RSWG chairs believe there may be rough consensus for the proposal to advance, they will issue a last call - for comment within the working group. + for comments within the working group. 5. After a comment period of suitable length, the RSWG chairs will determine whether rough consensus for the proposal exists (taking @@ -461,14 +463,14 @@ related to the RFC Series: call for comments, the RSAB may return the draft to the RSWG to consider those comments and make revisions to address the feedback received. In parallel with the community call for comments, the RSAB - shall also consider the proposal. + itself shall also consider the proposal. 7. If the scope of the revisions made in the previous step is substantial, an additional community call for comments should be issued by the RSAB, and the feedback received should be considered by the RSWG. 8. Once the RSWG chairs confirm that concerns received during the - community call(s) for comment have been addressed, they shall + community call(s) for comments have been addressed, they shall inform the RSAB that the document is ready for balloting by the RSAB. @@ -494,14 +496,14 @@ related to the RFC Series: to the overall Series, including harm to the long-term health and viability of the Series. * The RSAB member believes, based on the results of the community - call(s) for comment {{cfc}}, that rough consensus to advance + call(s) for comments {{cfc}}, that rough consensus to advance the proposal is lacking. Because RSAB members are expected to participate in the discussions within the RSWG and to raise any concerns and issues during those discussions, most CONCERN positions should not come as a surprise to the RSWG. Notwithstanding, late CONCERN positions are always possible - if issues are identified during RSAB review or the community call for comments. + if issues are identified during RSAB review or the community call(s) for comments. 10. If a CONCERN exists, discussion will take place within the RSWG. Again, all RSAB members are expected to participate. If substantial @@ -528,7 +530,7 @@ related to the RFC Series: ### Community Calls for Comment {#cfc} The RSAB is responsible for initiating and managing community calls -for comment on proposals that have gained consensus within the RSWG. +for comments on proposals that have gained consensus within the RSWG. The RSAB should actively seek a wide range of input. The RSAB seeks such input by, at a minimum, sending a notice to the "rfc-interest" email list or to its successor or future equivalent. RSAB members @@ -549,11 +551,11 @@ establish contacts in such communities, assisted in particular by the RSCE. The RSAB should maintain a public list of communities that are -contacted during calls for comment. +contacted during calls for comments. A notice of a community call for comments contains the following: -* A subject line beginning with 'Call for Comment:' +* A subject line beginning with 'Call for Comments:' * A clear, concise summary of the proposal @@ -619,8 +621,8 @@ responsibility with respect to boilerplates: needs * The RSAB, which approves that the boilerplate is not in conflict with the boilerplate used in the other streams -* The RPC, which approves that the language of the boilerplate conforms - to the RFC Style Guide +* The RPC, which approves that the language of the boilerplate is consistent + with the RFC Style Guide * The IETF Trust, which approves that the boilerplate correctly states the Trust's position regarding rights and ownership @@ -640,7 +642,8 @@ A few general considerations apply: * The RPC is advised by the RSCE and RSAB, and has a duty to consult with them under specific circumstances, such as those - relating to disagreements between authors and the RPC. + relating to disagreements between authors and the RPC as + described under {{disagreements}}. * The RPC is overseen by the IETF LLC to ensure that it performs in accordance with contracts in place. @@ -670,7 +673,7 @@ 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 by policies specified in the Editorial Stream, in existing RFCs +required to implement policies specified in the Editorial Stream, in existing RFCs which apply to the RPC and which 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 @@ -679,11 +682,11 @@ 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 LLC Executive Director, or a point of +by the IETF LLC Board, the IETF LLC 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 its charter. +outlined in its charter {{RFC8711}}. ## Working Practices {#practices} @@ -739,7 +742,7 @@ at the time of writing include the following: 9. Identifying topics and issues that they encounter while processing documents or carrying out other responsibilities on this list for - which they lack sufficient expertise and identifying and conferring + 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. @@ -836,7 +839,7 @@ definition is created within the IETF LLC budget and takes into account the RPC responsibilities (as described under {{rpc}}), the needs of the streams, and community input. -The process to select and contract for an RFC Production Center +The process to select and contract for the RFC Production Center and other RFC-related services is as follows: * The IETF LLC establishes the contract process, including the steps @@ -1129,11 +1132,11 @@ RFC Series (Section 2.1.4 of {{RFC8728}}), operational oversight documents (Section 4.2 of {{RFC8729}}), and development and maintenance of Series-wide guidelines and rules (Section 4.4 of {{RFC8729}}). Among other things this changes the dependency on -the RSE included in Section 2.2 of {{RFC8730}} with regard to +the RFC Series Editor (RSE) included in Section 2.2 of {{RFC8730}} with regard to "coordinating work and conforming to general RFC Series policies as specified by the IAB and RSE." In addition, various details regarding these responsibilities have been modified to accord with -the new framework defined in this document. +the framework defined in this document. ## RFC Series Editor @@ -1257,11 +1260,14 @@ Russ Housley, Christian Huitema, Ole Jacobsen, Sheng Jiang, +Benjamin Kaduk, John Klensin, +Murray Kucherawy, Mirja Kuehlewind, Ted Lemon, John Levine, Lucy Lynch, +Jean Mahoney, Andrew Malis, Larry Masinter, S. Moonesamy, @@ -1271,11 +1277,13 @@ Tommy Pauly, Colin Perkins, Julian Reschke, Eric Rescorla, +Alvaro Retana, Adam Roach, Dan Romascanu, Alice Russo, Doug Royer, Rich Salz, +John Scudder, Stig Venaas, Tim Wicinski, and Nico Williams.