idnits 2.17.1 draft-kowack-rfc-editor-model-v2-motivations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([I-D.v2-overview], [RFC5620]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 20, 2010) is 4874 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.v2-overview' ** Obsolete normative reference: RFC 5620 (Obsoleted by RFC 6548, RFC 6635) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Kowack 3 Internet-Draft Riveronce 4 Expires: June 23, 2011 December 20, 2010 6 Motivations for Recommendations 7 draft-kowack-rfc-editor-model-v2-motivations-00 9 Abstract 11 This memo provides the background and motivations for the 12 recommendations made in draft-kowack-rfc-editor-model-v2-overview-00. 13 It represents the perspectives resulting from an individual 14 managerial and analytical effort of nearly one year's duration. It 15 contains a summary of the factors considered to be essential to the 16 job of RFC Series Editor (RSE). This includes a summary of the work 17 done as part of the RFC Editor, the differences between [RFC5620]and 18 the [I-D.v2-overview] recommendations, a discussion of development 19 work that should be done, and an assessment of the time needed to 20 perform the RSE job. There is also a section listing and responding 21 to questions surrounding the recommendations. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on June 23, 2011. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Key Observations and Drivers of Design Choices . . . . . . . . 5 59 3. What Does the RFC Editor Do? . . . . . . . . . . . . . . . . . 8 60 3.1. Editing Work is Performed by Production Center Staff . . . 8 61 3.2. How is the RFC Editor Managed? . . . . . . . . . . . . . . 9 62 3.2.1. Coordination and Meetings . . . . . . . . . . . . . . 9 63 3.3. Why the RFC Editor and Series Still Need a Manager . . . . 10 64 3.3.1. Scale, Complexity, Formality, and Duration Make 65 Management Inevitable . . . . . . . . . . . . . . . . 11 66 3.3.2. The Community's Way of Doing Business Has its Own 67 Overhead . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.4. What Does the RFC Series Editor Do? . . . . . . . . . . . 12 69 3.4.1. Addressing questions and problems from within the 70 RFC Editor . . . . . . . . . . . . . . . . . . . . . . 13 71 3.4.2. RSE Activity Example: Ensuring and Improving 72 Access to RFCs . . . . . . . . . . . . . . . . . . . . 14 73 3.4.3. RFC Editor Escalation Procedure . . . . . . . . . . . 16 74 4. Differences between V2-Overview and RFC 5620 . . . . . . . . . 18 75 4.1. General and Design Strategy Differences . . . . . . . . . 19 76 4.2. Specific Differences . . . . . . . . . . . . . . . . . . . 20 77 4.2.1. Series Editor Authority and Supervisory Duties . . . . 20 78 4.2.2. RFC Editor Oversight Committee and RSAG . . . . . . . 21 79 4.2.3. Decommissioned RFC Series Advisory Group . . . . . . . 22 80 4.2.4. The IAOC and IAD . . . . . . . . . . . . . . . . . . . 23 81 4.2.5. The Series Editor and General Management Issues . . . 23 82 5. RFC Editor and Series Development Work . . . . . . . . . . . . 23 83 5.1. Update, Improve, and Reorganize the Style Manual . . . . . 24 84 5.2. Develop and Publish a Procedures Manual . . . . . . . . . 25 85 5.3. Improvements to the RFC Editor Web Pages . . . . . . . . . 25 86 5.4. Investigate Enhanced Training for RFC Authors . . . . . . 25 87 5.5. Investigate Providing Support for RFCs in Additional 88 Languages . . . . . . . . . . . . . . . . . . . . . . . . 26 89 5.6. Consider Supporting RFC Clusters and Enhanced RFC 90 Annotation . . . . . . . . . . . . . . . . . . . . . . . . 26 91 5.7. Investigate Reinforcing the Status of the Series as 92 Academic Publications . . . . . . . . . . . . . . . . . . 26 93 5.8. Investigate Formal Persistent Names or Identifiers for 94 RFCs . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 95 5.9. Lead Discussion on Universal Access and the ASCII 96 Format of Normative Versions of RFCs . . . . . . . . . . . 27 97 6. RSE Time Requirements . . . . . . . . . . . . . . . . . . . . 27 98 6.1. General Recommendations . . . . . . . . . . . . . . . . . 27 99 6.2. Current Level of Effort . . . . . . . . . . . . . . . . . 28 100 6.3. Additional responsibilities under V2-Overview . . . . . . 29 101 6.4. Which Levels of Appointment Make Practical Sense? . . . . 30 102 6.5. Orientation Time Requirements . . . . . . . . . . . . . . 31 104 7. Key Questions and Answers . . . . . . . . . . . . . . . . . . 31 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 106 9. Security Considerations . . . . . . . . . . . . . . . . . . . 34 107 10. Normative References . . . . . . . . . . . . . . . . . . . . . 34 108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 35 110 1. Introduction 112 As Transitional RFC Series Editor (TRSE), I performed the job of RFC 113 Series Editor (RSE or "Series Editor") throughout 2010. While 114 actively engaged in the role, I was to analyze work requirements, 115 engage in community discussion, and recommend changes as necessary to 116 [RFC5620]. (Note to the reader: I use 'community' to refer to anyone 117 who participates in, or uses the output of, the technical, 118 organizational, and other discussions associated with the I* 119 entities.) A specific problem was also to be addressed: the defined 120 RSE position must attract qualified candidates. Those 121 recommendations are summarized in [I-D.v2-overview]. This memo 122 provides the background and motivations for the recommendations. It 123 pays particular attention to the role of the Series Editor and how 124 [I-D.v2-overview] differs from [RFC5620]. This document is not a 125 community document. Rather, it contains the perspectives resulting 126 from an individual managerial and analytical effort of nearly one 127 year's duration. 129 If the community wants an RFC Editor that is responsive and 130 productive, then the IAB must appoint an RFC Series Editor who has 131 management and development skills and who is given authority 132 across the entire Editor."> I observe that a segment of the 133 community wishes to minimize the role of the Series Editor, 134 envisioning the job as merely a senior editor. My experience this 135 year demonstrates that this will limit the ability of the RFC 136 Editor to deal with its backlog of development requirements and 137 its ability to adapt to emerging community issues. The scale, 138 complexity, and richness of the subject matter of the Editor 139 create regular demands for management and coordination. 141 2. Key Observations and Drivers of Design Choices 143 The key observations behind, and drivers of the design for 144 [I-D.v2-overview] are: 146 The RFC Editor must work, and be structured to work, in the 147 community's interest. 149 The RFC Editor (or 'Editor') must not allow anyone to have 150 inappropriate influence over, or 'capture' the Editor - using 151 it in his own interests. This includes the Series Editor, 152 staff, contractors, unauthorized I* entities, individuals, or 153 groups. For all substantive issues, the community must clearly 154 be in charge. 156 Issues addressed by the Series Editor consistently demand a high 157 degree of publications-related knowledge and analytical skills not 158 common in our community. 160 Because RFCs do not change once they are published, prospective 161 innovations must be thought out in advance very carefully and 162 with special attention to unexpected consequences, putting a 163 premium on expertise and prior experience. During 2010, I did 164 not see issues that were rudimentary or only required text 165 editorial skills. Rather, each issue required deliberate 166 review and analysis to uncover its character and extent, often 167 including RFC Editor staff, RSAG members, and community 168 members. These required sophisticated management and service 169 design skills, not merely editing skills. 171 There is a substantial body of important RFC Editor and Series 172 development work waiting to be done. 174 A priority is protection against RFC Editor service 175 interruptions. Included are improvements in documentation of 176 editorial practices and processes, Series access, guidance for 177 authors, and the RFC Editor web site. Support for end-user 178 ease of understanding what RFCs are required to implement 179 specific services, persistent name technology, and others, have 180 been cited by community members. 182 A balance must be maintained between (i) demands of RFC 183 production, and (ii) RFC Editor and Series development. 185 During 2010, RFC production worked well - confirming that part 186 of the model - in part because it allows editorial staff to 187 focus on production. Staff must participate in Editor and 188 Series development, which must be balanced with production 189 work. This balance can be assured only by having an 190 experienced, knowledgeable, manager with explicit 191 responsibility for the performance of the entire Editor. 193 As defined in RFC 5620, RFC Editor management structure is complex 194 and unclear. 196 The Series Editor is responsible for resolving policy issues 197 and providing "executive level management" of their 198 implementation, but does not have authority to assign 199 resources. Today, this gap is filled by the IAD and IAOC, 200 which are not structured for the requisite publications 201 expertise or focus. There is also a regular oversight meeting 202 during and between IETF meetings, called by the IAD, and 203 attended by the IAOC chair, the streams, AMS staff and 204 management, and the Series Editor. The IAB, to which the RSE 205 reports, has a very heavy workload, multiple competing 206 priorities, and is not structured for publications expertise. 207 Clarifying authority and responsibility is required to attract 208 a qualified Series Editor. 210 The major design choices in [I-D.v2-overview], and thus the 211 recommended changes to [RFC5620] are: 213 o Balancing operation and development of the RFC Editor and the 214 Series requires leadership by a single professional who has 215 authority over each part of the RFC Editor (with production 216 delegated to contractors), the separate development of each, 217 operation of the RFC Editor as a whole, and for overall 218 development of the RFC Editor and the Series. 220 o Community interests will be best supported if there is one person 221 responsible to the community for all RFC Editor issues, and to 222 whom the community can point if the RFC Editor is not acting in 223 the community's interest. This person must have no other 224 interests. 226 o The RFC Series Editor role requires an experienced manager with 227 expertise in technical writing, technical publishing, and 228 technical series development. 230 o To ensure the fact and visibility of working in the community 231 interest, and to support the Series Editor, [I-D.v2-overview] adds 232 an RFC Editor Oversight Committee, whose members will be drawn 233 from the community and have prior experience in publications. The 234 now-redundant RFC Series Advisory Group would be disbanded, 235 although a slow transition is recommended to maintain 236 institutional memory. 238 The proposed Series Editor role is conceptually equivalent to the 239 head of a publications department in a technical organization. 241 The community has not yet converged on a common view of the span of 242 authority and responsibility of the Series Editor, the type and level 243 of expertise required, or the structure of RFC Editor oversight. 244 Through a description of the work of the RFC Series Editor as 245 performed during 2010 and related observations, this memo seeks to 246 motivate necessary changes to the Series Editor, including attracting 247 suitable, qualified candidates. 249 3. What Does the RFC Editor Do? 251 The following is based on my experience as TRSE during 2010. I call 252 out those cases where the role differs from RFC Editor Model (Version 253 1) described in [RFC5620], based on how the role presented itself to 254 me, and as a consequence how I now believe it needs to be organized. 256 RFC Editor output is produced through two functions: the RFC 257 Production Center (or RPC), and RFC Publisher (the 'Publisher'). Per 258 [RFC5620], the Series Editor provides "Executive-Level management". 259 During 2010, In order to observe how the model is currently working, 260 I intervened as little as possible in RPC or Publisher activities. 262 Here is a review of some aspects of performance that I observed: 264 Day-to-Day, the RFC Editor Model works well for basic RFC 265 production and publication. 267 During 2010, RFC production has been steady. There is general 268 satisfaction with the rate and quality of output, with the 269 service provided by the editorial staff, and with their 270 responsiveness. Staff of the Production Center and Publisher 271 staff understand their jobs and are focused; I did not observe 272 anything blocking their performance. 274 Day-to-Day, the streams model works well. 276 The participants in and leadership of each of the streams 277 appear to understand the scope of their subject areas. I have 278 not observed any problems, nor heard any substantive concerns, 279 about how each should use the services of the Editor. All 280 discussions of inter-stream conflicts were satisfactorily 281 resolved by the concerned parties, following documented 282 procedures 284 I observe that, following many years of experience and refinement, 285 the RFC Editor is highly organized for steady-state RFC production 286 and publication using a single, narrow service and editorial model. 287 However, this is not the entire range of required RFC Editor 288 services, as I will describe in following sections. 290 3.1. Editing Work is Performed by Production Center Staff 292 The RFC Production Center (RPC) center is provided by AMS under 293 contract. It performs regular RFC Editor document production. AMS 294 also provides the RFC Publisher service. 296 Following generally-accepted editorial style and procedures, much of 297 which is lore learned by editorial staff over many years, editors 298 receive approved documents from the streams; they make textual 299 changes for correctness and clarity, and formal changes, such as 300 formatting and adding specific boilerplate text; they engage IANA as 301 necessary. 303 The Production Center has its own director, an AMS staff member. She 304 manages the day-to-day activity of the editorial staff, including 305 document assignments and customer interaction. She also works as an 306 individual contributor alongside the other editorial staff, and is 307 the senior and most experienced editor. The Production Center 308 publishes regular production reports, comprised primarily of 309 statistics. 311 The staff of the Production Center are the Editor's most frequent 312 point of contact with stream participants and approvers. They 313 provide the vast majority of production-oriented services. In excess 314 of 90% of drafts come from the IETF stream. Furthermore, the 315 Production Center director acts as liaison to the IESG, to whom she 316 submits regular reports; these are available on the RFC Editor web 317 site. Consequently, the majority of document-oriented interaction 318 and support is between the Production Center and one of the four 319 streams. 321 As with other service organizations dominated by a single user or 322 customer, it can be inherently challenging to provide balanced 323 service and support to all of the other customers. During the TRSE 324 period, I did not observe any problems or complaints in balancing 325 Editor resource allocation across the streams. Beyond that, however, 326 there is a substantial backlog in non-production services and 327 capabilities that have not been adequately addressed or implemented, 328 nor integrated into a long-term plan with specific priorities; nor 329 has their content and value been sufficiently represented to the 330 community. I address these in Section 5. 332 3.2. How is the RFC Editor Managed? 334 3.2.1. Coordination and Meetings 336 A weekly teleconference of all RFC Editor staff is attended regularly 337 by the: 339 o Series Editor, 341 o Production Center staff and director, 343 o AMS management, 344 o AMS technical staff, and 346 o Independent Submissions Editor (ISE). 348 During the RFC Editor meeting, ongoing issues and monthly output are 349 reviewed and discussed. Topics frequently include issues for which 350 current policy is insufficient. These often turn to review and 351 analysis of past and current practices, including their origins and 352 varying application over the years. 354 Attendees are presently based in different locations throughout the 355 continental US, plus the Independent Submissions Editor in New 356 Zealand. I have not observed any problems arising from the remote 357 distribution of staff. To the contrary, everyone appears diligent at 358 keeping this from becoming an issue. 360 The RSE is RFC Editor liaison to the IAB, for whom he prepares 361 regular reports. During 2010, the RSE attended IESG meetings, as a 362 visitor sitting in for orientation while TRSE. 364 During IETF meetings, the IETF Administrative Director (IAD) also 365 calls a regular RFC Editor lunch comprised of the IETF Administrative 366 Oversight Committee (IAOC) chair, stream approver chairs, the RPC 367 director and invited staff, AMS management, and the RSE. These 368 participants review and discuss overall RFC Editor activity as well 369 as stream observations. This is the one regular meeting at which 370 most of the leadership cited in the Model meet face to face. There 371 is also an RFC Editor teleconference between IETFs, also called and 372 led by the IAD, during which RFC Editor issues are reviewed. This is 373 consistent with [RFC5620], although not explicitly called for. 375 Senior RPC staff, the ISE, and RSE, are available to community 376 members during IETF meetings. 378 The RSAG is unstructured and, except for a regular "Tuesday lunch" 379 during IETFs, has no regularly scheduled meetings, nor structured 380 reports. Per 5620, the RSAG is available on request of the RSE to 381 answer questions, provide advice, and to help formulate 382 recommendations to the IAB when necessary. 384 3.3. Why the RFC Editor and Series Still Need a Manager 386 Throughout its entire history, the Editor and the Series have been 387 led by a single manager, beginning with Jon Postel and then Joyce 388 Reynolds and Bob Braden. The current success of the Editor and the 389 Series is due significantly to this historical fact. 391 3.3.1. Scale, Complexity, Formality, and Duration Make Management 392 Inevitable 394 Successful organizations invariably grow along multiple dimensions. 395 They get larger and more complex, accumulate practices and precedents 396 for decision-making, and become more sophisticated at their work and 397 their understanding of their environment. They have correspondingly 398 richer and more complex interactions with other entities that are 399 evolving similarly. Good organizations strive to keep their 400 structure and practices simple, and to avoid creating unnecessary 401 bureaucracy. However, scale and duration have implicit overheads 402 that cannot be ignored. All these things are true of the I* and the 403 RFC Editor. 405 As organizations grow and as complexity increases, ad hoc 406 coordination becomes less and less effective, and the cost of failing 407 to coordinate matters increases. In the Editor, when a policy issue 408 arises it presents a practical problem: a decision needs to be made 409 but extensive discussion and coordination is nearly always required. 410 Resolution is not necessarily obvious or straightforward, and there 411 may be broad implications. Making concerted decisions is especially 412 important because the community wants I* entities to be responsive - 413 to their comments, questions, requests for information, and requests 414 for changes or corrections to problems. Someone needs to be sure 415 these processes are managed well, and brought to timely conclusions. 417 The I* has grown sufficiently large and complex that issues which 418 appear to be simple are often very subtle, and their resolution may 419 have far-reaching conclusions sensitive to the particulars of the 420 decision. For the RFC Editor, someone has to own that effort. The 421 point person must vet it past experts, bring it to the community, 422 anticipate the consequences of the different options, and be 423 insightful at finding a suitable outcome when the right choice may be 424 far from obvious. 426 We need to acknowledge that such activities cannot be managed in an 427 ad hoc way, nor should they be assigned to staff that have regular 428 production duties - the split interest would mean serving both 429 purposes poorly. 431 There is another oft-neglected point. Explicit assignments of 432 responsibility let everyone know who is responsible. If responsible 433 parties are good at their jobs and are transparent about their work, 434 everyone knows how the decisions are being made. This markedly 435 reduces the overheads suffered by suspicion-prone (meaning just about 436 all) organizations. If, on the contrary, responsible parties are not 437 formally and publicly appointed, then others will surely step in when 438 they think they are needed, often with the best of intentions, but 439 will too often make decisions that align more with their particular 440 perspectives than with the long-term interests of the broader 441 community. 443 3.3.2. The Community's Way of Doing Business Has its Own Overhead 445 Every organization has its own style for doing business, including 446 the I* entities. The I*'s preference for open participation and 447 extensive discussion ensures that all major changes require 448 significant effort by a representative of the RFC Editor. 450 This has two broad consequences. First, many initiatives should be 451 carefully considered and developed before they are taken to the 452 community. Not doing so can waste valuable time and cause 453 unnecessary contention while the actual issue is still being 454 clarified. Nevertheless, community review will often require a 455 substantial amount of attention and calendar time to make progress. 456 This is the environment in which the RFC Editor finds itself, and it 457 may account for some of the historical debate about its purposes and 458 processes. The second is that, serving the community in this 459 environment requires a dedicated, focused expert who has no other 460 interests, who can devote the time (including months or years of 461 developing perspectives) and energy to make this process work. 463 3.4. What Does the RFC Series Editor Do? 465 Per [RFC5620], the primary job of the RSE is to lead development of 466 new policy when current policy is insufficient. RFC activity in this 467 area may originate from within the RFC Editor, the community, other 468 I-star entities, or from the Series Editor's own work. The Series 469 Editor does this work in conjunction with the Editor, the RSAG (or 470 the REOC in the future), and the community, and involves the IAB as 471 necessary to ensure compliance with community interest and 472 appropriate processes. 474 The Series Editor provides guidance when the layer below - the 475 Production Center staff or the Publisher - encounters a situation 476 that is not clearly covered by existing policies or practices. RFC 477 5620 calls for the Series Editor to carry such issues to the RSAG and 478 the community for discussion and resolution. However, [RFC5620] is 479 silent about the authority of the Series Editor over RPC and the 480 Publisher when small issues arise day to day, or when the Series 481 Editor must make resource allocation decisions. 483 Per [RFC5620], and as practiced this year, the Series Editor does not 484 participate in day-to-day production and publication activities, or 485 any other regular production activities. The RSE, like any other 486 manager, does not do the work of the layer that reports to him 487 (although the analogy is limited; under [RFC5620], the RPC does not 488 report to the RSE). The RSE is not and should not act as a "team 489 leader", a supervisor who is also a regular individual contributor 490 working alongside other team members. 492 During 2010, as RSE I participated in the following, also consistent 493 with [RFC5620]: 495 o requests for policy clarification and decisions from the 496 Production Center, 498 o questions from, and discussion with, the community and beyond, 500 o regular weekly meetings of the RFC Editor, per above, 502 o various general meetings, including three IETFs (Anaheim, 503 Maastricht, and Beijing), and 505 o liaison and reporting to the IAB, including participating in 506 regular teleconferences and occasional retreats. 508 I also responded to an author complaint by initiating an escalation 509 procedure. However, [RFC5620] does not clearly authorize the RSE to 510 do so. 512 The RSE activities I describe here are exclusive of my TRSE 513 activities. The latter consisted of research, surveying the 514 community, preparing and delivering various interim presentations and 515 reports, and the production and discussions of my final 516 recommendations. 518 Immediately below, I describe in more detail Editor-originated policy 519 discussions of issues that arose from the community and beyond, and 520 from my experience performing an escalation procedure. 522 3.4.1. Addressing questions and problems from within the RFC Editor 524 When RFC Editor staff comes upon an issue not addressed by current 525 editorial policy, that issue becomes an agenda item at the next RFC 526 Editor meeting. It is impressive how complex these issues can be, 527 how often they touch upon many different dimensions of Editor work 528 and the Series, how intricate and extensive their implications can be 529 for Editor practices and the Series, and how much investigation it 530 can take to pry loose all the issues. If we are unable to resolve a 531 question swiftly, as RSE I bring it to the RSAG 533 During this period, typically several issues typically arose each 534 month from within the RFC Editor. All required significant 535 discussion. We usually asked the following sorts of questions: 537 o What exactly is the issue? 539 o Is the issue reasonable, and is there a genuine need for 540 resolution? 542 o Is it already covered by existing editorial policy, or will it 543 require an editorial policy addition or reduction, or other 544 permanent change, or a one-time exception to policy? 546 o What implications might this have for how the relevant stream, and 547 the other streams, will use the Series in the future? 549 o Is the policy in question tightly linked, or derived from, some 550 other policy? If so, who are the relevant authorities (e.g., a 551 stream) and how should that be handled? 553 o Is this an isolated case that can be resolved by the Editor, or is 554 it significant enough, or does it have serious enough 555 consequences, to require discussion by the community or the IAB? 557 o What sort of effect might the proposed change have on readers and 558 end-users? 560 o What short and long-term effects might it have on the Series? 562 The important questions often concerned impact on RFC Editor 563 processes and the Series, and the Series' long-term character. 564 During 2010 we were not presented with issues primarily having to do 565 with technical writing. Nor did we see issues with significant 566 computer-scientific content related to protocols - that is, issues 567 outside the scope of the Editor. I provide here an example of issues 568 presented to and discussed within the Editor, after which I review my 569 experience in leading an "escalation procedure". 571 3.4.2. RSE Activity Example: Ensuring and Improving Access to RFCs 573 Early this year, we received a request from a company doing business 574 with the US Government. Among other things, they wanted to know how 575 to fill out a required form on the sources of IETF standards, 576 including the publisher of RFCs. The RPC sought guidance because 577 there was no previous policy about who is the publisher of RFCs. 578 After brief discussion we realized there was no obvious answer. I 579 took that issue to the RSAG. 581 This also triggered a discussion about the RFC Series' ISSN 582 (International Standard Series Number). ISSNs are often used to 583 search for periodicals and disambiguate references. During 2008, the 584 IETF Trust obtained an ISSN for the Series from the ISSN 585 International Centre. However, we weren't sure whether the ISSN was 586 still valid (or what the policy was for expiration), or whether we'd 587 already answered questions therein about who is the publisher of 588 RFCs. We checked and confirmed that our ISSN was still valid. 590 We were unable to find any reference to our ISSN over the web, nor 591 through any of the major electronic card catalogs. No one had 592 apparently been assigned responsibility for following through after 593 obtaining the ISSN. I contacted old colleagues at one of the largest 594 universities libraries in the world, and had them add the Series ISSN 595 to their card catalog. Nearly all major libraries cross-reference 596 their catalogs, so our ISSN can now be found all over the world. 598 I mention this to provide a distinct example of loose ends around the 599 management of the availability of the Series. If someone out in the 600 world uses the same sorts of tools that the community does, and looks 601 at things the way the community does, then there is a good chance 602 they will be able to find the Series, get to the web site, and 603 continue from there. But, for someone not like us, for instance an 604 academic, it may be a different story entirely. And access is an 605 identified priority for the Editor and the Series. 607 These examples may appear small, but they sum to significantly 608 reduced Series availability. They also illustrate how the Editor, 609 outside of document production, depends upon someone's just happening 610 to notice an issue - that someone typically being a random volunteer 611 willing to take initiative. 613 This is not a criticism of anyone involved in these issues. In the 614 past, there has been such a narrow focus on production, probably 615 necessarily so, that this sort of broader management was not given 616 the necessary priority. The best remedy will be to task someone with 617 general assignments (e.g., "ensure access"), to develop a big 618 picture, seek out all the relevant parts, and then be given the 619 authority and resources to drive those issues to completion. 621 The RFC Editor is uniquely positioned within the I*: it is a major 622 formal vehicle through which the world obtains the work of the 623 community. It is vital that this Editor ensures availability to the 624 entire world, especially when many people may not use the same access 625 techniques, as does the community. 627 A related subject is that we have not posted convenient examples for 628 how RFCs should be referred to in other documents. This lack of 629 guidance increases the chance that references will be inaccurate or 630 ambiguous. Work has already been done on increasing the vitality, 631 breadth of use, influence, and stature of the Series by demonstrating 632 that RFCs are as rigorously reviewed as publications in conventional 633 academic journals. Early in January 2010, RSAG members Brian 634 Carpenter and Craig Partridge published "Internet requests for 635 comments (RFCs) as scholarly publications" in ACM SIGCOMM Computer 636 Communication Review. 638 Apprised of these developments, I called for the formation of an "RSE 639 Committee" on Citations. A member of the RFC Series Advisory Group 640 (RSAG) led this committee whose membership came from the community (a 641 general call was made for members on the rfc-interest list.) They 642 were asked to: 644 o determine the right ISSN entry format for the RFC series and 645 ensure it is accessible in the global database of library 646 electronic card catalogs (WorldCat), 648 o determine how documents in the RFC series should cite other RFCs, 650 o recommend how RFCs should be cited using the ACM, IEEE and MLA 651 reference formats, and 653 o recommend how RFCs should be represented in Bibtex. 655 This assignment conveniently combined issues of the ISSN and library 656 user access issues with those of reference examples. 658 The committee has been working on these related issues during 2010 659 and I expect to see their recommendations shortly. Those will be 660 vetted by the RSAG and posted for discussion and review by the 661 community. 663 The Series Editor's choice of this new, experimental model for 664 addressing Editor issues demonstrates how the RSE can have 665 significant positive influence, by crafting ways to investigate and 666 develop issues. In the future, this should be done with the advice 667 and consent of the RFC Editor Oversight Committee. 669 An important part of the managerial expertise required of the RSE is 670 not just to know how to investigate issues and drive them to 671 conclusion, but to know how best to harness the interest of the 672 community in the process. Doing this well will improve overall 673 outcomes by insuring their alignment with community interest. 675 3.4.3. RFC Editor Escalation Procedure 677 During 2010, I received only one significant complaint about 678 editorial performance. How this was handled is useful input into 679 understanding the sort of managerial activities that will 680 occasionally, and unavoidably, be required. 682 The complaint was from the author of a document while it was being 683 edited. After extensive discussions with the author and the RPC 684 staff member and director I was unable to satisfy the author and 685 initiated an escalation procedure. Since there was no procedure 686 specified for dealing with such cases, I notified the RSAG and the 687 IAB, kept them apprised of my activities, and frequently requested 688 feedback as the process unfolded. 690 I reviewed RPC editorial practices and performance with the voluntary 691 support of the Independent Submission Editor (ISE). RPC management 692 was highly responsive and supportive. I communicated my observations 693 to the author. 695 Neither the specifics of the complaint nor the outcome are 696 significant. What is significant, however, is that this case 697 illustrates a general limitation of [RFC5620], which does not clearly 698 assign (to the Series Editor or to anyone else) authority for 699 initiating or managing such a procedure. Nor does it do so more 700 broadly by, for example, assigning authority for day-to-day oversight 701 of the RFC Editor. The most obvious candidates for this 702 responsibility would be the IAD and IAOC due to their contractual 703 oversight role, or to the Series Editor. I found that this task 704 required a high degree of editorial background, and knowledge of 705 current practices and the immediate circumstances of the RFC Editor. 706 Furthermore, as I requested time and attention from RPC staff, it 707 became clear that there would be noticeable impact on the rate of 708 RFCs output by the Editor. However, [RFC5620] does not give the RSE 709 authority or responsibility for Editor output, which could cause him 710 to pay insufficient attention to any impact on productivity. 711 Finally, although the RPC director was exceptionally supportive, this 712 might not have been the case. The RSE needs sufficient authority to 713 insist upon support, in case future RPC management is not as 714 enlightened. 716 I also observed that the procedure, as performed, required far more 717 than simple expertise in technical writing. Issues that came to 718 light included: 720 o Should we have more than one level of editorial service, to 721 include, for example, elevated priority or assignment of more 722 experienced editors in the case of especially complex documents or 723 those with problematic audiences? 725 o If there are to be different levels of service, or if there are 726 more frequent complaints, how much time and effort should be 727 invested in either, and how should those be prioritized against 728 production of other RFCs? 730 o Where is the dividing line, between authors of drafts and 731 editorial staff, for responsibility for editing quality? 733 o Should the RFC Editor ever recommend that an author seek the 734 assistance of an outside editor, prior to submission; and if so, 735 based upon what criteria? 737 o How should escalation procedures be performed in the future? 739 Responding to questions of this sort with appropriate procedures 740 requires an understanding of technical writing practices, experience 741 managing the editing of publications, and sensitivity to the long- 742 term implications of any intervention for the character and quality 743 of the series. Experts should guide the resolution of these sorts of 744 issues. Furthermore, insofar as it is possible, leadership should be 745 continuous (that is, fixed to a role and not assigned on a case-by- 746 case basis) to provide institutional memory in case there are 747 repeated reviews. 749 I observe a gap in [RFC5620] between day-to-day production by the 750 RPC, and the policy development and execution authority of the RSE. 751 I recommend that this gap be filled by the RSE, the only person who 752 will have the requisite editorial and managerial expertise. The RSE 753 should be responsible for, and have authority over, Editor output. I 754 also observe that day-to-day oversight by the Editor requires a level 755 of experience beyond that of the IAD and the IAOC. 757 Finally, there is an issue of community and I* responsibility to 758 professional staff. If we are going to evaluate staff, that 759 evaluation must be led by our most qualified people. This not only 760 includes critical analysis of work performance and subsequent 761 recommendations and implementing of remedies. It also includes 762 defending our professionals' performance when they are doing their 763 work well under contentious or politically charged circumstances. 764 Doing anything less is organizationally irresponsible and risks 765 unfair treatment of our contractors' staff. Only a knowledgeable, 766 continuously involved, authorized professional manager and supervisor 767 can reasonably satisfy this requirement. 769 4. Differences between V2-Overview and RFC 5620 770 4.1. General and Design Strategy Differences 772 [RFC5620] aims to ensure community control by dividing responsibility 773 for the RFC Editor into multiple functions, allowing each to be 774 contracted or appointed separately: the Production Center, Publisher, 775 Series Editor and RSAG, and the Independent Submissions Editor and 776 Independent Submissions Editorial Board. This division permits each 777 part to focus on its mission. It also permits the community to more 778 clearly see the performance of each part, which facilitates 779 performance review. Indeed, this breaking out of the Production 780 Center and Publisher has been highly successful. 782 [RFC5620] does an excellent job of establishing part-by-part focus on 783 each Editor component, but its "divided responsibility" strategy, 784 carried all the way up to the oversight of RFC Editor operations, 785 does not establish any corresponding integration of managing the 786 operation of the Editor. 788 The IAOC and IAD continue their historical authority for management 789 of the contracts, and the IAB for arms-length oversight. This is 790 appropriate for those specific responsibilities. However, as defined 791 in [RFC5620], the Series Editor has authority only for what is left 792 over: exploring and discussing issues as they arise from the 793 community or within the Editor. Unfortunately the result is a 794 minimal and apparently unappealing job. 796 Though not obvious from a first reading of [RFC5620], my experience 797 of day-to-day operation of the RFC Editor and performance of the 798 Series Editor role exposed a critical flaw: no one entity or person 799 is assigned responsibility for bringing together all the different 800 inputs from the Editor, plus input from the community and beyond, and 801 making them all work together under the very serious demands of 802 document production. This is required so that the RFC Editor as a 803 whole operates smoothly and efficiently. 805 This lack of defined overall management authority also contributed to 806 the failure to find a satisfactory candidate. 808 [RFC5620] distributes authority for the Editor across two committees 809 and two managers. This division is problematic. Committees are 810 widely understood to be excellent at ensuring that multiple interests 811 are addressed, but not at integrating inputs into a single, focused 812 plan, nor for driving insights when developing such plans. 813 Committees also, often with the best of intentions, suffer from 814 having divided interests. Being comprised of members from disparate 815 entities or parts of the community, they may, even unknowingly, have 816 divided interests. This applies to the management structure in 817 [RFC5620]. Without some one person assigned responsibility for 818 overall management and development of the Editor, the community has a 819 very difficult, perhaps impossible job, of knowing who is responsible 820 for what is being done, and whom to talk to when there is 821 dissatisfaction. 823 Furthermore, [RFC5620] explicitly chooses not to define a reporting 824 structure for the RFC Editor. Instead, it treats the reporting 825 structure as an implementation detail, to be established or changed 826 by the IAOC on a case-by-case basis. There are three issues 827 associated with this approach. First, the duration and intensity of 828 community debate indicates that this issue needs to be resolved by 829 the community as a basic design decision of the Editor. Second, 830 reporting structure is fundamental to defining the RSE role, 831 including qualifications and level of experience. Finally, it is 832 extremely unlikely, as has already been demonstrated, that a 833 motivated, qualified profession would accept that the reporting 834 structure is to be determined in the future. [I-D.v2-overview] 835 brings this decision to the fore for community consideration. It 836 also makes future changes to the reporting structure substantive, 837 permitting changes only with the approval of the IAB. 839 V2 Overview makes the Series Editor responsible to the community for 840 the overall performance and operation of the RFC Editor. In this way 841 the community will always know who is responsible for the Editor and 842 the Series, and that the Series Editor has no other interest. 844 4.2. Specific Differences 846 4.2.1. Series Editor Authority and Supervisory Duties 848 Under [RFC5620], the responsibilities of the Series Editor are 849 limited and insufficient. The Series Editor is responsible for 850 addressing shortfalls in policy by taking them to the RSAG and the 851 community for discussion and community resolution and, as required, 852 confirmation by the IAB. The RSE is also responsible for 853 'implementation', without explaining what this means and without 854 empowering the RSE to achieve implementation. That is, [RFC5620] 855 does not state that the RSE has authority to direct the resources of 856 the Editor (the Production Center and Publisher) in any 857 implementation. It is likely that in many cases the Production 858 Center would temporarily need to reduce their rate of document output 859 in order to implement a new policy, and would need to be directed to 860 take such actions. The RSE should be able to provide directions to 861 do so after discussion and review by the streams and the REOC. 862 However, under [RFC5620] the RSE would need to seek permission from 863 the contract administrators, the IAOC or IAD. This is problematic. 864 First, understanding the impact of any change on RFC production is 865 best done by someone who has intimate knowledge of the production 866 process, and to ensure community alignment; this should be done by 867 under Series Editor leadership with the Production Center director. 868 Second, putting control in the hands of the IAOC (or IAD) is 869 problematic in that the IAOC and IAD are not structured for such 870 publications expertise, and have multiple responsibilities that could 871 conceivably compete with their attention to this subject. Finally, 872 not having this sort of responsibility, and instead having to go 873 through "contracts administration" (which is how it could be 874 perceived) each time there was a sub-contract level change, would be 875 unnecessary overhead, and very likely unacceptable to any qualified 876 RSE candidate. 878 Supervision should be the responsibility of the most knowledgeable 879 and experienced manager available. If there is to be an RSE, why not 880 assign a direct supervisory role to the position, rather than put 881 supervision in the hands of staff that are less knowledgeable (w/r/t 882 editing and publications)? The same argument applies to reviews of 883 performance. The RSE should lead reviews of the performance of the 884 contractors, while the IAOC should lead annual reviews of Editor 885 performance overall. 887 Nothing here is an argument against oversight, which this memo 888 maintains is required. RFC Editor oversight must be focused, must 889 have a suitable level of understanding or experience in publication, 890 and must support the RSE via an "advise and consent" model. 892 The sorts of issues managed by the RFC Editor are different from 893 those of the IAD and IAOC. The IAD and IAOC regularly agree to new 894 contracts with significant financial exposure for the overall 895 organization. The RSE will only rarely (perhaps once every few 896 years) be involved in teamwork regarding major financial commitments 897 (for example, when RFC Production Center and Publisher contracts are 898 renewed or re-bid). Most of the time, the RSE will be involved 899 primarily in many small daily and weekly decisions regarding 900 editorial and publication work and policies. Such decisions will 901 only occasionally have contractual consequences. In this case, it is 902 not necessary to have the same degree of executive involvement by the 903 REOC, as is the case with the IAOC. 905 4.2.2. RFC Editor Oversight Committee and RSAG 907 Under 5620, the IAB provides oversight for the RFC Editor both in 908 terms of chartered responsibility and regular reporting. However, 909 the IAB is involved in a great many priority issues that compete with 910 the RFC Editor, and cannot give a great deal of time or attention to 911 the RFC Editor. Furthermore, the skill set required of IAB members 912 conflicts with the skill set required of those who would directly 913 oversee the RFC Editor and RSE. 915 Under [RFC5620], the RSAG is an informal advisory body with no 916 authority for oversight of the Series or the RSE. Having oversight 917 authority would be awkward at best, since it is the Series Editor who 918 nominates RSAG members. 920 V2 Overview calls for the formation of an RFC Editor Oversight 921 Committee (REOC), that follows an "advise and consent" model to 922 support the Series Editor and ensure alignment with community 923 interests. This committee is structured to focus strictly on RFC 924 Editor issues, and should be populated with members with significant 925 interest, experience and expertise in the area of technical editing, 926 publishing, and the Series itself. This is not a re-labeling of the 927 RSAG. The REOC is selected differently (by the IAB, not the RSE), 928 has a different mission (oversight, not strictly advice), and real 929 authority (consent, which may be denied). 931 The role of the REOC is significantly different from that of the 932 IAOC, in spite of having a similar name. The IAOC is directly 933 involved in contractual, legal, and financial matters at the 934 administrative level, and at least 3 times a year has to investigate, 935 plan, and make major financial commitments for IETF meetings. The 936 RSE and REOC will only be involved in such matters every few years, 937 as the contracts for the RPC and Publisher renew. Even then, the RSE 938 and REOC will be involved primarily as publications subject matter 939 experts and not as financial administrators or contracts specialists. 940 Rather, the RSE and REOC will focus on the large number of policy and 941 operational issues, and their complex interactions and relative 942 priorities that are of interest to the Editor and thus to the 943 community. 945 This motivates the "advise and consent" REOC model, in place of 946 having the RSE reporting to a management committee. The RSE should 947 have far more publications and editorial expertise than the 948 collective of the REOC, have much more intimate knowledge of all the 949 day-to-day issues, and should thus be able to take a more leading 950 role - all the while with the consent of the REOC. This approach 951 will ensure alignment with community interest while encouraging 952 initiative and innovation. 954 The IAB will retain its chartered responsibility for the RFC Editor, 955 and will be consulted by the REOC on substantive policy questions. 956 Thus the IAB will be relieved from involvement in day-to-day 957 questions by delegating much of its oversight role to the REOC. 959 4.2.3. Decommissioned RFC Series Advisory Group 961 In [RFC5620], RFC Series Advisory Group (RSAG) members are nominated 962 by the RSE and approved by the IAB. The RSAG has few formal duties. 964 V2 Overview decommissions the RSAG to avoid redundancy with the REOC 965 and thus reduce committee overhead. For transparency, 966 [I-D.v2-overview] states that the Series Editor may have advisors, 967 and that their names should be publicized. There is nevertheless a 968 need for continuity and maintenance of institutional memory within 969 the RFC Editor. The RSAG members should be asked to remain on board 970 at least until the REOC is fully oriented and up to speed. This is 971 consistent with the text in V2 Overview that states that the RSE may 972 have informal advisors. (Since that text is not strictly necessary, 973 it may be removed from V2 Overview depending on community input.) 975 Although not a major design flaw, it is notable that [RFC5620] takes 976 a contradictory approach to the RSAG. RSAG has no real authority, 977 being largely an informal team of advisors nominated by the RSE. 978 Membership under such terms does not typically require approval, 979 although [RFC5620] mandates IAB approval of RSAG nominees. 980 [I-D.v2-overview] corrects this situation by disbanding the RSAG, 981 giving the REOC significant authority, and mandating IAB authority 982 for selecting REOC members. 984 4.2.4. The IAOC and IAD 986 [I-D.v2-overview] does not call for any change in the chartered 987 responsibilities of the IAOC. It does explicitly propose to have the 988 RSE (as the resident editorial and publications expert) join the IAOC 989 when it is reviewing contractor performance, re-issuing of contracts, 990 preparing requests for proposals, and reviewing bids. 992 4.2.5. The Series Editor and General Management Issues 994 V2 Overview gives the Series Editor exclusive direct management over 995 its facilities by assigning him responsibility for overall 996 performance of the Editor. All current regular meetings should be 997 reviewed, and possibly put under RSE management, to avoid any 998 confusion about where Editor directions are coming from. 1000 5. RFC Editor and Series Development Work 1002 The following steps to improve the series and its accessibility are 1003 based on input from community members and on my own experience and 1004 analysis. Unless otherwise stated, these are areas requiring 1005 eventual attention, not a list of efforts that the RSE should 1006 necessarily engage in immediately. Each will require leadership by 1007 the Series Editor to ensure responsiveness, knowledgeable discussion 1008 within the community, and reasonable progress towards a consensus 1009 solution. Leadership is also necessary to ensure correct 1010 prioritization of this type of work, and that all changes work well 1011 together. 1013 Because the work of the community is done almost entirely by 1014 volunteers, the Series Editor should be careful not to interfere with 1015 or replace volunteer activities. Very often the Series Editor will 1016 not actually direct various activities but rather will make sure that 1017 critical issues are being addressed and that participants are aware 1018 of the big picture. 1020 5.1. Update, Improve, and Reorganize the Style Manual 1022 The RFC Style Manual (or 'Guide') is a lightly organized collection 1023 of seven web pages on the RFC Editor site. Those include several 1024 different documents (one of which is an expired Internet Draft); 1025 various parts are redundant; and there is limited information to 1026 guide the novice's use of and interpretation of the Manual. One 1027 community member mentioned that various parts of the RFC style were a 1028 major input to the style guide of his own corporation (a major 1029 software developer). His colleagues need to be able to refer to the 1030 RFC Style Manual, which they say they cannot do in its present state. 1031 Fixing this problem will increase the consistency and stature of the 1032 Series. 1034 The Style Manual as it stands is insufficient to direct substitute 1035 editors in case of an unexpected break in service. The Manual should 1036 be reorganized, consolidated, and updated as necessary. This should 1037 include a part-by-part review for currency and accuracy. 1039 Community members have suggested the Manual be divided into two 1040 sections: a small, slowly evolving core of 'musts' to be enforced by 1041 Editor staff. This core should be kept as minimal and 1042 straightforward as possible. It should be augmented by a larger, 1043 more quickly developing set of guidelines for authors, possibly in a 1044 separate document. The core information should be published as an 1045 RFC, while more frequently changing sections (e.g., the abbreviations 1046 list) could be left to (or incrementally updated as) web pages. 1048 The Editor does not presently recommend any general style manuals 1049 (e.g., The (University of) Chicago Manual of Style) to guide authors 1050 above and beyond the RFC Editor Style Manual. The Editor should do 1051 so, but, to ensure that the Series does not become stylistically 1052 narrow, might better suggest several widely accepted style manuals 1053 that authors might refer to than require their adherence to one 1054 particular manual. 1056 The above are rough suggestions. General and detailed decisions 1057 should be left up to the incoming Series Editor with support from the 1058 Editor staff, REOC members, and in concert with the community. The 1059 new Series Editor should consider establishing a standing committee 1060 comprising knowledgeable people from each of these groups. I see no 1061 reason why there cannot be far more direct participation by the 1062 community in this effort than in the past. 1064 5.2. Develop and Publish a Procedures Manual 1066 There is no one place (particularly, not among the RFC Editor web 1067 pages) where one can find a definitive description of the processes 1068 followed by the Editor, and how the Editor interacts with the 1069 Streams. As previously identified, the Procedures Manual, along with 1070 the Style Manual, is the core device for ensuring quick guidance of 1071 alternate editors in case of an unexpected interruption in service. 1072 As with the Style Manual, a comprehensive effort should be undertaken 1073 to collect all relevant policies in one place, once again involving 1074 staff, committees and knowledgeable community members. 1076 Particular attention should be paid to documenting procedures at the 1077 correct level of detail. Many procedures fall near the boundary 1078 between common sense, editorial lore, and a need for formal 1079 documentation. The Procedures Manual should be designed to permit 1080 incremental addition over the years; all participants should guard 1081 against adding more detail than is necessary. 1083 5.3. Improvements to the RFC Editor Web Pages 1085 Community members frequently assert that the RFC Editor web site is 1086 rudimentary, has an old-style look and feel, and needs to be 1087 reorganized for clarity. The web site is a key entry point for 1088 access to the Series, and especially to facilitate new authors' 1089 understanding of how to write an Internet draft on the way to 1090 publishing an RFC. Given the community's increasingly international 1091 membership, adding support for languages other than English may in 1092 time be appropriate. 1094 The Series Editor should consult with the Oversight Committee and the 1095 community to explore how the site might be improved, and formulate a 1096 plan for doing so depending upon acquisition of resources including 1097 volunteers. 1099 5.4. Investigate Enhanced Training for RFC Authors 1101 The Editor provides an orientation for draft writers during the IETF 1102 week that focuses on draft- and RFC-specific issues. Enlarging this 1103 orientation to provide general guidance for how to write technical 1104 documents could we an efficient was to assist both authors and 1105 production center staff. I am not suggesting that the Series Editor 1106 personally provide this training, which requires very specific 1107 skills. Rather, the RSE should join with the streams to identify if 1108 there are efficiencies to be gained by one or more types of such 1109 training, and to determine if a plan should be developed for 1110 obtaining that training, which can be very expensive to produce. 1111 Contracting with an outside training organization is one option. 1113 5.5. Investigate Providing Support for RFCs in Additional Languages 1115 Our community is constantly becoming more international. Some 1116 suggest we may be asked, for example, to improve the ease of 1117 participation by non-native English speakers by providing pointers to 1118 unofficial translations of RFCs. We may eventually wish to certify 1119 such translations as being within certain quality criteria. The RFC 1120 Editor's responsibilities may grow to include ensuring that such 1121 requests by community participants (or RFC end-users) are handled 1122 expeditiously. If work begins in this area, it should be done in 1123 concert with other internationalization efforts, such as support for 1124 non-English languages in the RFC Editor web site, as mentioned above. 1126 5.6. Consider Supporting RFC Clusters and Enhanced RFC Annotation 1128 At present, if one wishes to know the relationships between various 1129 RFCs, one has to read the metadata and 'walk' from RFC to RFC. Also, 1130 despite the enormous body of knowledge in the community, there is no 1131 commonly available facility that describes: 1133 o clusters of RFCs and their relationships (a 'cluster' is any 1134 collection of RFC that are of interest to someone who has 1135 collected information on them), 1137 o annotations of RFCs, (these could include, for example, notes 1138 provided by readers of RFCs indicating their experience as they 1139 implemented a particular service; annotations could be graded for 1140 usefulness, using a reader-entered ranking system), 1142 o service descriptors (anyone wishing to implement transport, for 1143 example, could use descriptors to locate, readily and 1144 unambiguously, all current RFCs required to implement that 1145 technology). 1147 Volunteer work in this area is already under way. The Series Editor 1148 should informally encourage and support these efforts and investigate 1149 whether more significant support should be given. 1151 5.7. Investigate Reinforcing the Status of the Series as Academic 1152 Publications 1154 How to increase the standing of the RFCs and the Series in the 1155 academic world is already under discussion. This process may be 1156 valuable to continue. 1158 5.8. Investigate Formal Persistent Names or Identifiers for RFCs 1160 I am told that Digital Object Identifiers (DOIs) have become common 1161 in academic publishing, and that citations more and more often 1162 require DOIs. We do not presently have any plans to provide URIs 1163 (Uniform Resource Identifiers) or DOIs for RFCs. The RSE should 1164 begin a process to determine whether there is a need for such 1165 facilities, and if so what sort of process should be followed to 1166 determine what needs to be done and how to do it. 1168 5.9. Lead Discussion on Universal Access and the ASCII Format of 1169 Normative Versions of RFCs 1171 A significant number of community members have noted that discussion 1172 about the ASCII format goes through cycles of intensity. The Series 1173 Editor will need to participate in these discussions and attempt to 1174 make them productive. One of the identified problems is the limit of 1175 ASCII art. Community members tell me that they cannot produce 1176 complex mathematical notation using ASCII, which they claim keeps 1177 them from publishing certain RFCs (if this is so, then our 1178 universality-oriented policy is keeping some RFCs from being created 1179 in the first place). Another concern is the impossibility of 1180 representing author names that require non-ASCII character sets. The 1181 Series Editor and Oversight Committee should survey community 1182 thinking on the subject, decide whether and when a comprehensive 1183 review should take place, and specify the process(es) that review 1184 should follow, while keeping in mind the need for long-term 1185 accessibility of archival documents. 1187 6. RSE Time Requirements 1189 6.1. General Recommendations 1191 A one-third-time appointment is the absolute minimum for the Series 1192 Editor position for the appointee to provide ongoing leadership and 1193 to represent the Editor and the Series on an ongoing basis. 1195 Additional time is required to discuss, analyze, prioritize, 1196 communicate, and guide through to implementation the regular flow of 1197 development issues that come to the Editor (exclusive of ongoing 1198 document production). Still more time is required to participate in 1199 exceptional events, such as community controversies or debates, 1200 customer complaints that could result in escalation procedures, or 1201 time-consuming external demands. Altogether, these tasks add a 1202 minimum of roughly 20%-time, to bring the position to a minimum half- 1203 time appointment. 1205 An appointment beyond half-time would be reasonable but is not 1206 strictly required. Above that level depends upon the desire by the 1207 community for faster or additional Series and Editor development. 1209 These observations are based on the work level analysis below, and 1210 are consistent with my sense of the character and scale of the work 1211 as I experienced it. 1213 6.2. Current Level of Effort 1215 Currently, and consistent with [RFC5620], the RSE regularly 1216 participates in (exclusive of TRSE work): 1218 o various regular meetings (IETF, IAB, etc), 1220 o ad hoc community interaction face to face, via email, face to 1221 face, phone, etc., 1223 o frequent interaction with the production center and the RSAG, 1224 including investigation of practices and policy issues, and 1226 o research, analysis of, and planning of various initiatives and 1227 their implementation. 1229 These are activities are structurally required or follow from 1230 continuing community interest. Below are rough estimates for some of 1231 these activities. For convenience I assume 12 four-week months a 1232 year, and represent a week as 2% of a year, and a month as 8.5% of a 1233 year (both rounded down slightly). These are well within the 1234 accuracy of these sorts of observations. 1236 Regular meetings: 1238 IETF meetings: 1240 3 per year, 1 week per meeting, plus an equal amount of 1241 preparation and follow-up time. 1.5 months per year, or 12% 1242 time. 1244 RFC Editor weekly meetings: 1246 1 hour each, plus 1 hour of prep and/or follow-up. 8 hours 1247 per month (12 days / year), or 6% time. 1249 IAB bi-monthly meetings: 1251 2 hours each, plus 2 hours report preparation time, bi- 1252 monthly. 8 hours / month (12 days / year), or 6% time. 1254 Total time, regular meetings: 1256 approximately 25%-time requirement. 1258 See Section 6.3, below, for how these values correspond to the 1259 anticipated workload cited in [I-D.v2-overview]. 1261 General Representation and Communication: 1263 E-mail, rfc-interest list, phone conversations, etc: 1265 4 hours/week (24 days/year), or 12 % time. 1267 The span of communications, including email traffic, on which 1268 the Series Editor needs to be current, requires a considerable 1269 time investment. The RFC Editor is a place where many 1270 different activities of the community meet. Recent discussions 1271 about the standards process are an example. The RFC Series 1272 Editor needs to follow such discussions to maintain general 1273 community context, to anticipate impact on the Editor or the 1274 Series, and to represent his observations. Preparing for 1275 participation in email threads requires a significant amount of 1276 time. 1278 Total time, regular meetings and general communications: 1280 this is slightly more than a 1/3 time appointment (37%, 1281 which is 25% plus 12%). This is within the range of 1282 accuracy of the 1/3 time appointment recommendation above. 1284 6.3. Additional responsibilities under V2-Overview 1286 Under [I-D.v2-overview], time previously required for interaction 1287 with the IAB and RSAG will be replaced by interaction with the REOC. 1289 I anticipate that the REOC will eventually meet monthly for one to 1290 two hours, but initially, every two weeks. There will also be 1291 somewhat more frequent discussions between the RSE and individual 1292 REOC members, which I anticipate will depend upon the level of Editor 1293 and Series development work. Overall, I expect that the time devoted 1294 to upwards reporting will increase slightly compared to past 1295 practice. 1297 Major Planning Cycles, Annual and Multi-Year: 1299 In addition to ongoing work there will be annual reviews of 1300 Editor performance. Also, every few years there will be major 1301 investments of time devoted to reviews of long-term performance 1302 of contractors, and constructing new requests for proposals. 1304 Annual reviews of RFC Editor and Publisher: 1306 1 week, or 2% time. 1308 This activity slightly increases the average yearly commitment 1309 of the Series Editor, but does not alter my one-third-time 1310 recommendation. 1312 End-of-Contract review of performance of Production Center and 1313 Publisher: 1315 This item includes joint work with the IAD and IAOC on major 1316 reviews, revisions to contracts, creation of new requests for 1317 proposals (RFPs), preparation for and participation in bidders 1318 conferences, and reviews of bids. 1320 End of Contract Reviews: 1322 4 weeks (although in case of very large changes, time 1323 requirements could be much greater). 8% time. 1325 Because the new contract activities occur so irregularly, I do 1326 not explicitly include them in the annual baseline. They are 1327 better considered as part of project work. 1329 6.4. Which Levels of Appointment Make Practical Sense? 1331 Practically speaking, just two work level ranges are sensible and 1332 would be acceptable to a professional: full-time; or a defined level 1333 up to and including 50 or 60%. 1335 Increasing the level much above 50% but not up to 100% could be 1336 problematic. Few people find themselves able to limit themselves to, 1337 for instance, an 80% job; at some point there is a strong tendency 1338 for such a position to become full-time. It is commonplace in our 1339 industry, and in publishing, for "full-time" professionals to far 1340 exceed 40 hours per week. This indicates that once the job's minimum 1341 time requirements begin to exceed ~60% of a nominal 40-hour work 1342 week, the community will get much more value for money from a full- 1343 time employee. 1345 6.5. Orientation Time Requirements 1347 Learning the Series Editor job will be very time-consuming, depending 1348 upon the level of orientation and support provided and the 1349 appointees' prior knowledge of the environment. My experience 1350 suggests that a relative novice will require approximately 6 months 1351 to get up to speed; even someone quite familiar with our environment 1352 will take at least several months. I strongly recommend development 1353 of an orientation plan, to include multiple orientation meetings 1354 (working sessions well beyond getting-to-know-you meetings), walks 1355 through all key RFCs, and extensive review of all other relevant 1356 documents and processes. 1358 7. Key Questions and Answers 1360 Over the years, the RFC Editor has had progressively narrower scope 1361 and authority. After removing any influence over the technical 1362 content of RFCs, splitting out the Independent Submissions Editor 1363 role, and moving the technical editors into a separate organization, 1364 why is an RSE necessary at all? 1366 [RFC5620], documenting an earlier consensus, mandates an RSE role. 1367 My experience in the position has documented (above) significant 1368 outstanding management and development issues. Many of these 1369 cannot be ignored and, if not managed explicitly, could end up 1370 being done in an ad hoc fashion, and quite possibly badly. I 1371 present reasons, above and below, why a committee is unlikely to 1372 do the job effectively. 1374 Can't the Production Center Director do the job? 1376 In spite of the excellence of the entire RFC Production Center 1377 staff at technical writing, and their understanding of the current 1378 state of Editor practice, they have not had prior experience at 1379 the sort of work I describe. Furthermore, assigning the RSE role 1380 to Production Center management could create a problematic 1381 division of their attention and eventually either the planning or 1382 the production would suffer. Asking a single person to fill both 1383 positions will make it more difficult for the community to observe 1384 and assess how matters are being prioritized. Finally, a very 1385 significant part of the incoming RSE role will be to review all 1386 the editorial and other practices of the Editor to develop a real 1387 and complete Style Manual and a real and complete Procedures 1388 Manual; someone other than the production staff must do this. 1389 Otherwise, the community can have no confidence that the process 1390 will provide insurance against breaks in editorial service. Said 1391 differently, Production Staff cannot be expected to review 1392 themselves, which would be a conflict of interest. And, as 1393 described below, the necessary review requires more, and more 1394 continuous, attention and focus than can be expected of those 1395 volunteers who oversee the RSE. 1397 I emphasize that these are structural observations and in no way 1398 any criticism of staff or AMS. All have performed professionally 1399 and diligently during my tenure. 1401 Can't a Community Committee do the Job? 1403 A committee is simply not a good vehicle for discerning and 1404 pursuing strategic needs, particularly if the committee has other 1405 duties or is made up of members with varied interest. A committee 1406 can provide support, guidance and oversight, but cannot do the 1407 primary thing this job requires: focus on uncovering Editor issues 1408 and driving them to conclusion, in combination, and in a way that 1409 improves the long-term performance of the RFC Editor. That means 1410 making sense of the entire Editor, its operations, policies and 1411 relationship to staff, the community and other community entities. 1412 This includes establishing means to ensure no interruption of 1413 service. Lessons from management, and past experience in the 1414 community, argue that a single professional responsible for making 1415 this happen, and for being accountable for it happening, is 1416 necessary. 1418 Should the RSE come from the community or should an outsider do the 1419 job? 1421 Someone from the community may be able to do the job, but only if 1422 qualified as defined above and in [I-D.v2-overview]. However, 1423 significant publications management experience and expertise in 1424 not widely found in the community. Furthermore, there is a great 1425 opportunity for the community to find an experienced outsider who 1426 will drive new thinking and debate. This is far less likely with 1427 someone from the community. 1429 Keep in mind that the REOC and IAB, and an anticipated, 1430 predictable degree of community participation, will provide a very 1431 rich and steady flow of community input on all issues. 1433 After the reductions in the RSE role mentioned above, is there 1434 anything left to attract an experienced publications professional? 1436 There can be, if the job is appropriately structured, and properly 1437 supported by the REOC, IAB, and the community. The RFC Series is 1438 one of the most important technical collections in history. Many 1439 qualified professionals would leap at the chance to lead the 1440 community in improving the Series and the operation of the Editor. 1441 They would also love to learn how and why this amazing Series and 1442 innovative community work; this is a real career builder. 1443 However, the incoming RSE must understand that their job is to 1444 lead the community in discovering, defining, prioritizing, and 1445 agreeing on changes, improvements and innovations, and then 1446 implementing them. (This, in spite of the confusing terminology 1447 of the Editor: the RFC Editor is actually a publisher, the RFC 1448 Publisher is actually an archive and access server, and the RFC 1449 Series Editor is actually the head of a publications department in 1450 which there are four 'editors' not appointed by the Series Editor 1451 -- the four stream approvers.) In years past, this might not have 1452 been attractive to a publication professional, which would have 1453 expected far more control. However, in significant part thanks to 1454 the Internet, the world of publications has changed. An example 1455 of this is Wikipedia, whose leadership provides an environment for 1456 a community of writers and editors, establishes rules, and lets 1457 the world of contributors do the rest. However, the role is still 1458 somewhat thin compared to the degree of autonomy usually granted 1459 to professionals leading this scale of series and sort of effort. 1460 Hence, his having authority over the Production Center and 1461 Publisher is all the more important; not giving the RSE this 1462 authority could preclude attracting strong candidates. 1464 Can a Volunteer to the Job? 1466 Of course it is possible, if the community can find someone 1467 qualified and willing to do the job. However, that appears 1468 unlikely, for structural reasons. In our community, those who 1469 occupy senior positions that require a substantial fraction of 1470 their time, such as membership in the IAB or IESG, require 1471 substantial support from their employers; this is effectively 1472 'seconding' an employee to the volunteer job. Employers do this 1473 because of the strategic value and stature it brings their 1474 organizations. This value is often related to the strategic 1475 insights and influence that follow from the roles, and such value 1476 depends on the Community work the 'seconded' professional does 1477 being strategic to the employer. This does not generally apply to 1478 editing. Finding an organization in the publications world that 1479 would support a 'seconding' is unlikely. Conclusion: Seeking 1480 volunteers, may be a time and energy-consuming dead-end. It could 1481 be done on a limited basis before reverting to seeking a paid 1482 professional. 1484 There is another issue. This job is complex, difficult, rich with 1485 personalities and opinions. Paying someone to do it may be 1486 required for him to insure continuity under the challenges and 1487 pressures that will invariably occur. 1489 What keeps the Series Editor from having undue influence or 1490 'capturing' the community and making them dependent upon him? 1492 First, a major goal of the RSE is to ensure that no one in the 1493 Editor, or outside the Editor, can have undue influence, and that 1494 includes him. When writing the documents that ensure quick 1495 provision of alternate editing resources, he must also document 1496 his part in those processes and decisions. The REOC should remain 1497 diligent about this his supporting this requirement, and they have 1498 tools at their disposal to be sure they can do so. First, the RSE 1499 will not have any control of his own over Editor resources; my 1500 recommendations require that he not come from any of the other 1501 contractors of Editor services. Second, they should have enough 1502 expertise to review the RSE's work to ensure it is complete. 1503 Third, the recommendations stipulate a 3-year term of office; long 1504 enough to learn the job and get good at it, but not long enough to 1505 insert himself irreversibly into various relationships, and short 1506 enough that the clock will run out on its own in a reasonable 1507 amount of time. Finally, the RSE is a planning and oversight job. 1508 Except for brief intervals when the RSE is critically important to 1509 development of some activity, they should not be important to any 1510 real-time events during which they could 'squeeze' the community. 1511 Professionals being very good at their jobs, and providing great 1512 value to the community, has nothing to do with 'capture'. Using 1513 that, or other values, to gain improper results of any form in 1514 defiance of community will, does. 1516 8. IANA Considerations 1518 None. 1520 9. Security Considerations 1522 None. 1524 10. Normative References 1526 [I-D.v2-overview] 1527 Kowack, G., Ed., "RFC Editor Model Version 2", 1528 I-D draft-kowack-rfc-editor-model-v2-overview-00, 1529 November 2010. 1531 [RFC5620] Kolkman, O. and IAB, "RFC Series Editor Model (Version 1532 1)", RFC 5620, August 2009. 1534 Author's Address 1536 Glenn Kowack 1537 Riveronce 1539 Email: glenn@riveronce.com