idnits 2.17.00 (12 Aug 2021) /tmp/idnits32963/draft-rsalz-2028bis-07.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 issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (14 March 2022) is 61 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ??? R. Salz 3 Internet-Draft Akamai Technologies 4 Obsoletes: 2028 (if approved) 14 March 2022 5 Intended status: Best Current Practice 6 Expires: 15 September 2022 8 Entities Involved in the IETF Standards Process 9 draft-rsalz-2028bis-07 11 Abstract 13 This document describes the individuals and organizations involved in 14 the IETF standards process, as described in IETF BCP 9. It includes 15 brief descriptions of the entities involved, and the role they play 16 in the standards process. 18 The IETF and its structure have undergone many changes since 1996, 19 when RFC 2028 was published. This document reflects the changed 20 organizational structure of the IETF and obsoletes RFC 2028. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Discussion of this document takes place on the GENDISPATCH mailing 27 list (gendispatch@ietf.org)], which is archived at 28 https://mailarchive.ietf.org/arch/browse/gendispatch/. 30 Source for this draft and an issue tracker can be found at 31 https://github.com/richsalz/draft-ietf-rfc2028bis. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 15 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.2. Changes since RFC 2028 . . . . . . . . . . . . . . . . . 3 69 2. Key Individuals in the Process . . . . . . . . . . . . . . . 3 70 2.1. The Document Editor or Author . . . . . . . . . . . . . . 3 71 2.2. The Working Group Chair . . . . . . . . . . . . . . . . . 4 72 2.3. The Area Director . . . . . . . . . . . . . . . . . . . . 4 73 3. Key Organizations in the Process . . . . . . . . . . . . . . 4 74 3.1. Internet Engineering Task Force (IETF) . . . . . . . . . 5 75 3.2. Working Groups (WGs) . . . . . . . . . . . . . . . . . . 5 76 3.3. Internet Engineering Steering Group (IESG) . . . . . . . 6 77 3.4. Internet Architecture Board (IAB) . . . . . . . . . . . . 6 78 3.5. The RFC Production Center (RPC) . . . . . . . . . . . . . 7 79 3.6. Internet Assigned Numbers Authority (IANA) . . . . . . . 7 80 3.7. Internet Research Task Force (IRTF) . . . . . . . . . . . 7 81 3.8. The IETF Trust . . . . . . . . . . . . . . . . . . . . . 8 82 3.9. IETF Administration LLC (IETF LLC) . . . . . . . . . . . 8 83 3.10. IETF Secretariat . . . . . . . . . . . . . . . . . . . . 9 84 3.11. Internet Society (ISOC) . . . . . . . . . . . . . . . . . 9 85 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 86 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 87 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 88 7. Informative References . . . . . . . . . . . . . . . . . . . 9 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 The process used by the IETF community for the standardization of 94 protocols and procedures is described in [IETFPROCS]. That document 95 defines the stages in the standardization process, the requirements 96 for moving a document between stages, and the types of documents used 97 during this process. This document identifies some of the key 98 individual roles and organizations in that process. 100 1.1. Terminology 102 This document refers to individual roles in the singular, such as "a 103 Document Editor." In reality, many roles are filled by more than one 104 person at the same time. For clarity, this document does not use 105 phrases like "Chair (or co-chair)." 107 1.2. Changes since RFC 2028 109 The following changes have been made, in no particular order: 111 * Added the role of Responsible Area Director (AD) and re-ordered 112 Section 2 to follow the typical workflow. 114 * Added the IETF Administration LLC and the IETF Trust to Section 3. 116 * Changed RFC Editor to RFC Production Center, to reflect the 117 changes made by [RFCEDMODEL]. 119 * Added Section 6 and Section 1.1 and cleaned up some wording 120 throughout the document. 122 2. Key Individuals in the Process 124 This section describes the individual roles involved in the process. 125 It attempts to list the roles in the order in which they are involved 126 in the process, without otherwise expressing significance. 128 2.1. The Document Editor or Author 130 Most Working Groups (WGs) focus their efforts on one or more 131 documents that capture their work results. The Working Group Chair 132 designates one or more people to serve as the Editor(s) for a 133 particular document. They are responsible for ensuring that the 134 contents of the document accurately reflect the decisions that have 135 been made by the Working Group. 137 When a document is composed and edited mainly by one or more 138 individuals, they may be referred to as Document Authors. The 139 distinction is not significant for the standards process. This 140 document uses the term Document Editor. 142 When a Document Editor is a Chair of the same Working Group, another 143 Chair should manage the process around the document. If another 144 Chair is not available, the WG and AD must monitor the process 145 especially carefully to ensure that the resulting documents 146 accurately reflect the consensus of the Working Group and that all 147 processes are followed. This is the collective obligation of all 148 parties involved in the document. 150 2.2. The Working Group Chair 152 Each Working Group is headed by a Chair who has the responsibility 153 for facilitating the group's activities, presiding over the group's 154 meetings, and ensuring that the commitments of the group with respect 155 to its role in the Internet standards process are met. In 156 particular, the WG Chair is the formal point of contact between the 157 WG and the Internet Engineering Steering Group (IESG), via the AD of 158 the area to which the WG belongs. 160 The details on the selection and responsibilities of a Working Group 161 Chair can be found in [WGPROCS]. 163 2.3. The Area Director 165 Each Working Group is assigned a single responsible Area Director 166 (AD). The AD can assist the WG chair in assessing consensus and 167 executing process. The AD also reviews documents after the WG has 168 approved them and, when satisfied, the AD coordinates the IESG review 169 and IETF last call of of the document. 171 An AD can also sponsor a draft directly, but this is not very common. 172 When this is done, a Working Group is not involved. 174 Except for the General Area, IETF Areas traditionally have multiple 175 Area Directors. 177 3. Key Organizations in the Process 179 The following organizations and organizational roles are involved in 180 the Internet standards process. 182 3.1. Internet Engineering Task Force (IETF) 184 The IETF is an open international community of network designers, 185 operators, implementors, researchers, and other interested parties 186 who are concerned with the evolution of the Internet architecture and 187 the smooth operation of the Internet. It is the principal body 188 engaged in the development of new Internet Standard specifications 189 and related documents. 191 3.2. Working Groups (WGs) 193 The technical work of the IETF is done in its Working Groups, which 194 are organized by topics into several Areas 195 (https://www.ietf.org/topics/areas/), each one under the coordination 196 of an Area Director. Working Groups typically have a narrow focus 197 and a lifetime bounded by completion of specific tasks as defined in 198 their charter and milestones. Some Working Groups are long-lived 199 intended to conduct ongoing maintenance on IETF protocol(s). There 200 are also "dispatch" Working Groups whose role is to assess where new 201 work in the IETF should be done, not directly produce standards. 203 For all purposes relevant to the Internet Standards development 204 process, membership in the IETF and its Working Groups is defined to 205 be established solely and entirely by individuals who participate in 206 IETF and Working Group activities. These individuals do not formally 207 represent any organizations they may be affiliated with, although 208 affiliations are often used for identification. 210 Anyone with the time and interest to do so is entitled and urged to 211 participate actively in one or more Working Groups and to attend IETF 212 meetings, which are usually held three times a year [MEETINGS]. A WG 213 may also schedule interim meetings (virtual, in-person, or hybrid). 214 These are scheduled and announced to the entire WG. Active Working 215 Group participation is possible without attending any in-person 216 meetings. 218 Participants in the IETF and its Working Groups must disclose any 219 relevant current or pending intellectual property rights that are 220 reasonably and personally known to the participant if they 221 participate in discussions about a specific technology. The full 222 intellectual property policy is defined in [IPRRIGHTS1] and 223 [IPRRIGHTS2]. 225 New Working Groups are established by the IESG and almost always have 226 a specific and explicit charter. The charter can be modified as the 227 Working Group progresses. The guidelines and procedures for the 228 formation and operation of Working Groups are described in detail in 229 [WGPROCS]. 231 A Working Group is managed by a Working Group Chair, as described in 232 Section 2.2. Documents produced by the group have an Editor, as 233 described in Section 2.1. Further details of Working Group operation 234 can be found in [WGPROCS]. 236 Working Groups ideally display a spirit of cooperation as well as a 237 high degree of technical maturity; IETF participants recognize that 238 the greatest benefit for all members of the Internet community 239 results from cooperative development of technically excellent 240 protocols and services. 242 3.3. Internet Engineering Steering Group (IESG) 244 The IESG is responsible for the management of the IETF technical 245 activities. It administers the Internet Standards process according 246 to the rules and procedures defined in [IETFPROCS]. The IESG is 247 responsible for the actions associated with the progression of 248 documents along the "IETF stream," including the initial approval of 249 new Working Groups, any subsequent rechartering, and the final 250 approval of documents. The IESG is composed of the Area Directors 251 and the IETF Chair, who also chairs the IESG and is the Area Director 252 for the General Area. The Chair of the Internet Architecture Board 253 (IAB) is an ex-officio member of the IESG. Various other bodies have 254 liaisons with the IESG. 256 All members of the IESG are nominated by a Nominations Committee 257 (colloquially, NomCom), and are confirmed by the IAB. See [NOMCOM] 258 for a detailed description of the NomCom procedures. Other matters 259 concerning its organization and operation are described in the IESG 260 charter [IESG]. 262 3.4. Internet Architecture Board (IAB) 264 The IAB provides oversight of the architecture of the Internet and 265 its protocols. The IAB approves IESG candidates put forward by the 266 NomCom. It also reviews all proposed WG charters. 268 The IAB provides oversight of the standards process and serves as an 269 appeal board for related complaints about improper execution 270 [IETFPROCS]. In general, it acts as a source of advice about 271 technical, architectural, procedural, and policy matters pertaining 272 to the Internet and its enabling technologies. 274 The members of the IAB are nominated by the NomCom, and are confirmed 275 by the Board of the Internet Society (ISOC). The IETF Chair is also 276 a member of the IAB, and the Chair of the Internet Research Task 277 Force (IRTF) is an ex-officio member. Other matters concerning the 278 IAB's organization and operation are described in the IAB charter 279 [IAB]. 281 3.5. The RFC Production Center (RPC) 283 Publication of RFCs is handled by the RFC Production Center (RPC), 284 including editorial preparation and publication. RFC policy is 285 defined by the RFC Series Working Group (RSWG), an open group 286 (similar to IETF Working Groups), and approved by the RFC Advisory 287 Board (RSAB), which has appointed members. The RFC Series Consulting 288 Editor (RSCE) is a position funded by the IETF LLC, with 289 responsibilities to consult with all parties, and be a member of the 290 RSAB. 292 Full details on the roles and responsibilities of the RPC are 293 specified in [RFCEDMODEL], in particular Section 4. 295 3.6. Internet Assigned Numbers Authority (IANA) 297 Many protocol specifications include parameters that must be uniquely 298 assigned. Examples of this include port numbers, option identifiers 299 within a protocol, and so on. The Internet Assigned Numbers 300 Authority (IANA) is responsible for assigning values to these 301 protocol parameters, maintained in parameter registries. These 302 registries are maintained online (https://www.iana.org/protocols). 303 Assignments are coordinated by writing an "IANA Considerations" 304 section for a given document, as descrribed in [IANADOCS]. The 305 IETF's relationship with IANA is defined by formal agreements, 306 including [IANAMOU]. 308 IANA also is responsible for operating and maintaining several 309 aspects of the DNS (https://www.iana.org/domains) and coordinating of 310 IP address assignments (https://www.iana.org/numbers). 312 3.7. Internet Research Task Force (IRTF) 314 The IRTF focuses on longer-term research issues related to the 315 Internet as a parallel organization to the IETF, which focuses on the 316 shorter-term issues of engineering, operations, and specification of 317 standards. 319 The IRTF consists of a number of Research Groups (RGs) chartered to 320 research various aspects related to the broader Internet. The 321 products of these RGs are typically research results that are often 322 published in scholarly conferences and journals, but can also be 323 published as RFCs on the IRTF's RFC stream. RGs also sometimes 324 develop experimental protocols or technologies, some of which may be 325 suitable for possible standardization in IETF. Similarly, IETF 326 working groups sometimes ask RGs for advice or other input. 327 Contributions from RGs, however, in general carry no more weight in 328 the IETF than other community input, and go through the same 329 standards setting process as any other proposal. 331 The IRTF is managed by the IRTF Chair in consultation with the 332 Internet Research Steering Group (IRSG). The IRSG membership 333 includes the IRTF Chair, the Chairs of the various RG and possibly 334 other individuals ("members at large") from the community. Details 335 of the organization and operation of the IRTF, the ISRG, and its RGs 336 may be found in [IRTF], [IABIRTF], [IRTFPRIMER], and [IRTFCHAIR]. 338 3.8. The IETF Trust 340 The IETF Trust is the legal owner of intellectual property for the 341 IETF, IRTF, and IAB. This includes their trademarks, the copyrights 342 to RFCs and to works of the IETF such as the IETF web site, and 343 copyright licenses for IETF contributions including Internet Drafts. 344 The principles for the copyright licenses granted to and from the 345 Trust are described in [IPRRIGHTS1] and [COPYRIGHT], and the licenses 346 themselves are in the Trust Legal Provisions 347 (https://trustee.ietf.org/documents/trust-legal-provisions/). 349 The Trust also currently owns IANA's domain names and trademarks 350 through an agreement with the IANA clients. 352 The Trustees that govern the Trust are selected from the IETF 353 community, as described in [TRUSTEES] and the rationale given in 354 [TRUSTRAT]. 356 3.9. IETF Administration LLC (IETF LLC) 358 The IETF Administration Limited Liability Corporation (colloquially, 359 the IETF LLC) provides the corporate legal home for the IETF, the 360 IAB, and the IRTF. 362 The IETF LLC is responsible for supporting the ongoing operations of 363 the IETF, managing its finances and budget, and raising money. It 364 regularly reports to the community. The LLC is the legal entity that 365 signs contracts for the IETF Secretariat, meeting hotels, tools 366 development contractors, among many others. The LLC also responds to 367 legal requests; these are often subpoenas in patent lawsuits. 369 Selection of the LLC Board of Directors is defined in [NOMCOM]. 371 The IETF Executive Director handles the IETF's daily tasks and 372 management, and is overseen by the LLC Board of Directors. 374 [ISOCIETF], Section 6 describes the legal relationship between the 375 IETF LLC and the Internet Society. 377 3.10. IETF Secretariat 379 The administrative functions necessary to support the activities of 380 the IETF and its various related boards and organizations are 381 performed by a Secretariat contracted by the IETF LLC. The IETF 382 Secretariat handles much of the logistics of running the in-person 383 meetings, and is responsible for maintaining the formal public record 384 of the Internet standards process [IETFPROCS]. 386 3.11. Internet Society (ISOC) 388 ISOC plays an important role in the standards process. In addition 389 to being the legal entity that hosts the IETF LLC, ISOC appoints the 390 NomCom Chair, confirms IAB candidates selected by the NomCom, and 391 acts as the final authority in the appeals process. This is 392 described in [ISOCIETF]. 394 The way in which the the ISOC leadership is selected, and other 395 matters concerning the operation of the Internet Society, are 396 described in [ISOC]. 398 4. Security Considerations 400 This document introduces no new security considerations. 402 5. IANA Considerations 404 This document has no IANA actions. 406 6. Acknowledgements 408 We are grateful to the authors of [RFC2028], Richard Hovey and Scott 409 Bradner. 411 Barry Lieba, Colin Perkins, Eric Auerswald, John Levine, and Lars 412 Eggert provided useful feedback and corrections to this document. 414 7. Informative References 416 [COPYRIGHT] 417 Halpern, J., Ed., "Advice to the Trustees of the IETF 418 Trust on Rights to Be Granted in IETF Documents", 419 RFC 8721, DOI 10.17487/RFC8721, February 2020, 420 . 422 [IAB] Internet Architecture Board and B. Carpenter, Ed., 423 "Charter of the Internet Architecture Board (IAB)", 424 BCP 39, RFC 2850, May 2000. 426 428 [IABIRTF] Floyd, S., Ed., Paxson, V., Ed., Falk, A., Ed., and IAB, 429 "IAB Thoughts on the Role of the Internet Research Task 430 Force (IRTF)", RFC 4440, DOI 10.17487/RFC4440, March 2006, 431 . 433 [IANADOCS] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 434 Writing an IANA Considerations Section in RFCs", BCP 26, 435 RFC 8126, June 2017. 437 439 [IANAMOU] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 440 Understanding Concerning the Technical Work of the 441 Internet Assigned Numbers Authority", RFC 2860, 442 DOI 10.17487/RFC2860, June 2000, 443 . 445 [IESG] Alvestrand, H., "An IESG charter", RFC 3710, 446 DOI 10.17487/RFC3710, February 2004, 447 . 449 [IETFPROCS] 450 Bradner, S., "The Internet Standards Process -- Revision 451 3", BCP 9, RFC 2026, October 1996. 453 Dusseault, L. and R. Sparks, "Guidance on Interoperation 454 and Implementation Reports for Advancement to Draft 455 Standard", BCP 9, RFC 5657, September 2009. 457 Housley, R., Crocker, D., and E. Burger, "Reducing the 458 Standards Track to Two Maturity Levels", BCP 9, RFC 6410, 459 October 2011. 461 Resnick, P., "Retirement of the "Internet Official 462 Protocol Standards" Summary Document", BCP 9, RFC 7100, 463 December 2013. 465 Kolkman, O., Bradner, S., and S. Turner, "Characterization 466 of Proposed Standards", BCP 9, RFC 7127, January 2014. 468 Dawkins, S., "Increasing the Number of Area Directors in 469 an IETF Area", BCP 9, RFC 7475, March 2015. 471 Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream 472 Documents Require IETF Rough Consensus", BCP 9, RFC 8789, 473 June 2020. 475 477 [IPRRIGHTS1] 478 Bradner, S., Ed. and J. Contreras, Ed., "Rights 479 Contributors Provide to the IETF Trust", BCP 78, RFC 5378, 480 November 2008. 482 484 [IPRRIGHTS2] 485 Bradner, S. and J. Contreras, "Intellectual Property 486 Rights in IETF Technology", BCP 79, RFC 8179, May 2017. 488 490 [IRTF] Weinrib, A. and J. Postel, "IRTF Research Group Guidelines 491 and Procedures", BCP 8, RFC 2014, DOI 10.17487/RFC2014, 492 October 1996, . 494 [IRTFCHAIR] 495 Eggert, L., "The Role of the IRTF Chair", RFC 7827, 496 DOI 10.17487/RFC7827, March 2016, 497 . 499 [IRTFPRIMER] 500 Dawkins, S., Ed., "An IRTF Primer for IETF Participants", 501 RFC 7418, DOI 10.17487/RFC7418, December 2014, 502 . 504 [ISOC] "Amended and restated By-Laws of the Internet Society", 505 March 2021, . 508 [ISOCIETF] Camarillo, G. and J. Livingood, "The IETF-ISOC 509 Relationship", RFC 8712, DOI 10.17487/RFC8712, February 510 2020, . 512 [MEETINGS] Krishnan, S., "High-Level Guidance for the Meeting Policy 513 of the IETF", BCP 226, RFC 8719, DOI 10.17487/RFC8719, 514 February 2020, . 516 [NOMCOM] Kucherawy, M., Ed., Hinden, R., Ed., and J. Livingood, 517 Ed., "IAB, IESG, IETF Trust, and IETF LLC Selection, 518 Confirmation, and Recall Process: Operation of the IETF 519 Nominating and Recall Committees", BCP 10, RFC 8713, 520 February 2020. 522 Leiba, B., "Eligibility for the 2020-2021 Nominating 523 Committee", BCP 10, RFC 8788, May 2020. 525 527 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 528 the IETF Standards Process", BCP 11, RFC 2028, 529 DOI 10.17487/RFC2028, October 1996, 530 . 532 [RFCEDMODEL] 533 "RFC Editor Model (Version 3)", n.d., 534 . 537 [TRUSTEES] Arkko, J. and T. Hardie, "Update to the Process for 538 Selection of Trustees for the IETF Trust", BCP 101, 539 RFC 8714, DOI 10.17487/RFC8714, February 2020, 540 . 542 [TRUSTRAT] Arkko, J., "IETF Administrative Support Activity 2.0: 543 Update to the Process for Selection of Trustees for the 544 IETF Trust", RFC 8715, DOI 10.17487/RFC8715, February 545 2020, . 547 [WGPROCS] Bradner, S., "IETF Working Group Guidelines and 548 Procedures", BCP 25, RFC 2418, September 1998. 550 Wasserman, M., "Updates to RFC 2418 Regarding the 551 Management of IETF Mailing Lists", BCP 25, RFC 3934, 552 October 2004. 554 Resnick, P. and A. Farrel, "IETF Anti-Harassment 555 Procedures", BCP 25, RFC 7776, March 2016. 557 Resnick, P. and A. Farrel, "Update to the IETF Anti- 558 Harassment Procedures for the Replacement of the IETF 559 Administrative Oversight Committee (IAOC) with the IETF 560 Administration LLC", BCP 25, RFC 8716, February 2020. 562 564 Author's Address 566 Rich Salz 567 Akamai Technologies 568 Email: rsalz@akamai.com