{"@attributes":{"version":"3","category":"info","consensus":"true","docName":"draft-ietf-iasa2-rfc4844-bis-05","indexInclude":"true","ipr":"trust200902","number":"8729","obsoletes":"4844","prepTime":"2020-02-26T18:04:03","scripts":"Common,Latin","sortRefs":"true","submissionType":"IAB","symRefs":"true","tocDepth":"4","tocInclude":"true"},"link":[{"@attributes":{"href":"https:\/\/datatracker.ietf.org\/doc\/draft-ietf-iasa2-rfc4844-bis-05","rel":"prev"}},{"@attributes":{"href":"https:\/\/dx.doi.org\/10.17487\/rfc8729","rel":"alternate"}},{"@attributes":{"href":"urn:issn:2070-1721","rel":"alternate"}}],"front":{"title":"The RFC Series and RFC Editor","seriesInfo":{"@attributes":{"name":"RFC","value":"8729","stream":"IAB"}},"author":[{"@attributes":{"fullname":"Russ Housley","initials":"R.","surname":"Housley","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}},"address":{"email":"housley@vigilsec.com"}},{"@attributes":{"fullname":"Leslie L. Daigle","initials":"L.","surname":"Daigle","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}},"address":{"email":"ldaigle@thinkingcat.com"}}],"date":{"@attributes":{"month":"02","year":"2020"}},"keyword":["IASA","IASA2","technical publisher"],"abstract":{"@attributes":{"pn":"section-abstract"},"t":"\nThis document describes the framework for an RFC Series and an RFC Editor\nfunction that incorporate the principles of organized community\ninvolvement and accountability that has become necessary as the Internet\ntechnical community has grown, thereby enabling the RFC Series to\ncontinue to fulfill its mandate. This document obsoletes RFC 4844. \n"},"boilerplate":{"section":[{"@attributes":{"anchor":"status-of-memo","numbered":"false","removeInRFC":"false","toc":"exclude","pn":"section-boilerplate.1"},"name":"Status of This Memo","t":["\n            This document is not an Internet Standards Track specification; it is\n            published for informational purposes.  \n        ","\n            This document is a product of the Internet Architecture Board\n            (IAB) and represents information that the IAB has deemed valuable\n            to provide for permanent record.  It represents the consensus of the Internet\n            Architecture Board (IAB).  Documents approved for publication\n            by the IAB are not candidates for any level of Internet Standard; see\n            Section 2 of RFC 7841.\n        ","\n            Information about the current status of this document, any\n            errata, and how to provide feedback on it may be obtained at\n            .\n        "]},{"@attributes":{"anchor":"copyright","numbered":"false","removeInRFC":"false","toc":"exclude","pn":"section-boilerplate.2"},"name":"Copyright Notice","t":["\n            Copyright (c) 2020 IETF Trust and the persons identified as the\n            document authors. All rights reserved.\n        ","\n            This document is subject to BCP 78 and the IETF Trust's Legal\n            Provisions Relating to IETF Documents\n            () in effect on the date of\n            publication of this document. Please review these documents\n            carefully, as they describe your rights and restrictions with\n            respect to this document.\n        "]}]},"toc":{"section":{"@attributes":{"anchor":"toc","numbered":"false","removeInRFC":"false","toc":"exclude","pn":"section-toc.1"},"name":"Table of Contents","ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1"},"li":[{"@attributes":{"pn":"section-toc.1-1.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.1.1"},"xref":[{"@attributes":{"derivedContent":"1","format":"counter","sectionFormat":"of","target":"section-1"}},"Introduction"]}},{"@attributes":{"pn":"section-toc.1-1.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.2.1"},"xref":[{"@attributes":{"derivedContent":"2","format":"counter","sectionFormat":"of","target":"section-2"}},"RFC Series Mission"]}},{"@attributes":{"pn":"section-toc.1-1.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.3.1"},"xref":[{"@attributes":{"derivedContent":"3","format":"counter","sectionFormat":"of","target":"section-3"}},"Roles and Responsibilities"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.3.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.3.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.3.2.1.1"},"xref":[{"@attributes":{"derivedContent":"3.1","format":"counter","sectionFormat":"of","target":"section-3.1"}},"RFC Editor"]}},{"@attributes":{"pn":"section-toc.1-1.3.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.3.2.2.1"},"xref":[{"@attributes":{"derivedContent":"3.2","format":"counter","sectionFormat":"of","target":"section-3.2"}},"IAB"]}},{"@attributes":{"pn":"section-toc.1-1.3.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.3.2.3.1"},"xref":[{"@attributes":{"derivedContent":"3.3","format":"counter","sectionFormat":"of","target":"section-3.3"}},"Operational Oversight"]}},{"@attributes":{"pn":"section-toc.1-1.3.2.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.3.2.4.1"},"xref":[{"@attributes":{"derivedContent":"3.4","format":"counter","sectionFormat":"of","target":"section-3.4"}},"Policy Oversight"]}}]}},{"@attributes":{"pn":"section-toc.1-1.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.1"},"xref":[{"@attributes":{"derivedContent":"4","format":"counter","sectionFormat":"of","target":"section-4"}},"Framework"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.4.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.4.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.1.1"},"xref":[{"@attributes":{"derivedContent":"4.1","format":"counter","sectionFormat":"of","target":"section-4.1"}},"Document Approval"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.4.2.1.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.4.2.1.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.1.2.1.1"},"xref":[{"@attributes":{"derivedContent":"4.1.1","format":"counter","sectionFormat":"of","target":"section-4.1.1"}},"Definition"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.1.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.1.2.2.1"},"xref":[{"@attributes":{"derivedContent":"4.1.2","format":"counter","sectionFormat":"of","target":"section-4.1.2"}},"Operational Implementation"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.1.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.1.2.3.1"},"xref":[{"@attributes":{"derivedContent":"4.1.3","format":"counter","sectionFormat":"of","target":"section-4.1.3"}},"Process Change"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.1.2.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.1.2.4.1"},"xref":[{"@attributes":{"derivedContent":"4.1.4","format":"counter","sectionFormat":"of","target":"section-4.1.4"}},"Existing Approval Process Documents"]}}]}},{"@attributes":{"pn":"section-toc.1-1.4.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.2.1"},"xref":[{"@attributes":{"derivedContent":"4.2","format":"counter","sectionFormat":"of","target":"section-4.2"}},"Editing, Processing, and Publication of Documents"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.4.2.2.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.4.2.2.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.2.2.1.1"},"xref":[{"@attributes":{"derivedContent":"4.2.1","format":"counter","sectionFormat":"of","target":"section-4.2.1"}},"Definition"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.2.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.2.2.2.1"},"xref":[{"@attributes":{"derivedContent":"4.2.2","format":"counter","sectionFormat":"of","target":"section-4.2.2"}},"Operational Implementation"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.2.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.2.2.3.1"},"xref":[{"@attributes":{"derivedContent":"4.2.3","format":"counter","sectionFormat":"of","target":"section-4.2.3"}},"Process Change"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.2.2.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.2.2.4.1"},"xref":[{"@attributes":{"derivedContent":"4.2.4","format":"counter","sectionFormat":"of","target":"section-4.2.4"}},"Existing Process Documents"]}}]}},{"@attributes":{"pn":"section-toc.1-1.4.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.3.1"},"xref":[{"@attributes":{"derivedContent":"4.3","format":"counter","sectionFormat":"of","target":"section-4.3"}},"Archiving, Indexing, and Accessibility"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.4.2.3.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.4.2.3.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.3.2.1.1"},"xref":[{"@attributes":{"derivedContent":"4.3.1","format":"counter","sectionFormat":"of","target":"section-4.3.1"}},"Definition"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.3.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.3.2.2.1"},"xref":[{"@attributes":{"derivedContent":"4.3.2","format":"counter","sectionFormat":"of","target":"section-4.3.2"}},"Operational Implementation"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.3.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.3.2.3.1"},"xref":[{"@attributes":{"derivedContent":"4.3.3","format":"counter","sectionFormat":"of","target":"section-4.3.3"}},"Process Change"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.3.2.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.3.2.4.1"},"xref":[{"@attributes":{"derivedContent":"4.3.4","format":"counter","sectionFormat":"of","target":"section-4.3.4"}},"Existing Process Documents"]}}]}},{"@attributes":{"pn":"section-toc.1-1.4.2.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.4.1"},"xref":[{"@attributes":{"derivedContent":"4.4","format":"counter","sectionFormat":"of","target":"section-4.4"}},"Series-Wide Guidelines and Rules"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.4.2.4.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.4.2.4.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.4.2.1.1"},"xref":[{"@attributes":{"derivedContent":"4.4.1","format":"counter","sectionFormat":"of","target":"section-4.4.1"}},"Definition"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.4.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.4.2.2.1"},"xref":[{"@attributes":{"derivedContent":"4.4.2","format":"counter","sectionFormat":"of","target":"section-4.4.2"}},"Operational Implementation"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.4.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.4.2.3.1"},"xref":[{"@attributes":{"derivedContent":"4.4.3","format":"counter","sectionFormat":"of","target":"section-4.4.3"}},"Process Change"]}},{"@attributes":{"pn":"section-toc.1-1.4.2.4.2.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.4.2.4.2.4.1"},"xref":[{"@attributes":{"derivedContent":"4.4.4","format":"counter","sectionFormat":"of","target":"section-4.4.4"}},"Existing Process Documents"]}}]}}]}},{"@attributes":{"pn":"section-toc.1-1.5"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.1"},"xref":[{"@attributes":{"derivedContent":"5","format":"counter","sectionFormat":"of","target":"section-5"}},"RFC Streams"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.5.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.5.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.1.1"},"xref":[{"@attributes":{"derivedContent":"5.1","format":"counter","sectionFormat":"of","target":"section-5.1"}},"RFC Approval Processes"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.5.2.1.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.5.2.1.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.1.2.1.1"},"xref":[{"@attributes":{"derivedContent":"5.1.1","format":"counter","sectionFormat":"of","target":"section-5.1.1"}},"IETF Document Stream"]}},{"@attributes":{"pn":"section-toc.1-1.5.2.1.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.1.2.2.1"},"xref":[{"@attributes":{"derivedContent":"5.1.2","format":"counter","sectionFormat":"of","target":"section-5.1.2"}},"IAB Document Stream"]}},{"@attributes":{"pn":"section-toc.1-1.5.2.1.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.1.2.3.1"},"xref":[{"@attributes":{"derivedContent":"5.1.3","format":"counter","sectionFormat":"of","target":"section-5.1.3"}},"IRTF Document Stream"]}},{"@attributes":{"pn":"section-toc.1-1.5.2.1.2.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.1.2.4.1"},"xref":[{"@attributes":{"derivedContent":"5.1.4","format":"counter","sectionFormat":"of","target":"section-5.1.4"}},"Independent Submission Stream"]}}]}},{"@attributes":{"pn":"section-toc.1-1.5.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.2.1"},"xref":[{"@attributes":{"derivedContent":"5.2","format":"counter","sectionFormat":"of","target":"section-5.2"}},"RFC Technical Publication Requirements"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.5.2.2.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.5.2.2.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.2.2.1.1"},"xref":[{"@attributes":{"derivedContent":"5.2.1","format":"counter","sectionFormat":"of","target":"section-5.2.1"}},"IETF Documents"]}},{"@attributes":{"pn":"section-toc.1-1.5.2.2.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.2.2.2.1"},"xref":[{"@attributes":{"derivedContent":"5.2.2","format":"counter","sectionFormat":"of","target":"section-5.2.2"}},"IAB Documents"]}},{"@attributes":{"pn":"section-toc.1-1.5.2.2.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.2.2.3.1"},"xref":[{"@attributes":{"derivedContent":"5.2.3","format":"counter","sectionFormat":"of","target":"section-5.2.3"}},"IRTF Documents"]}},{"@attributes":{"pn":"section-toc.1-1.5.2.2.2.4"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.5.2.2.2.4.1"},"xref":[{"@attributes":{"derivedContent":"5.2.4","format":"counter","sectionFormat":"of","target":"section-5.2.4"}},"Independent Submissions"]}}]}}]}},{"@attributes":{"pn":"section-toc.1-1.6"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.6.1"},"xref":[{"@attributes":{"derivedContent":"6","format":"counter","sectionFormat":"of","target":"section-6"}},"Security Considerations"]}},{"@attributes":{"pn":"section-toc.1-1.7"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.7.1"},"xref":[{"@attributes":{"derivedContent":"7","format":"counter","sectionFormat":"of","target":"section-7"}},"Changes Since RFC 4844"]}},{"@attributes":{"pn":"section-toc.1-1.8"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.8.1"},"xref":[{"@attributes":{"derivedContent":"8","format":"counter","sectionFormat":"of","target":"section-8"}},"Informative References"]}},{"@attributes":{"pn":"section-toc.1-1.9"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.9.1"},"xref":[{"@attributes":{"derivedContent":"Appendix A","format":"default","sectionFormat":"of","target":"section-appendix.a"}},"A Retrospective of IAB Charters and RFC Editor"]},"ul":{"@attributes":{"bare":"true","empty":"true","indent":"2","spacing":"compact","pn":"section-toc.1-1.9.2"},"li":[{"@attributes":{"pn":"section-toc.1-1.9.2.1"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.9.2.1.1"},"xref":[{"@attributes":{"derivedContent":"A.1","format":"counter","sectionFormat":"of","target":"section-a.1"}},"1992"]}},{"@attributes":{"pn":"section-toc.1-1.9.2.2"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.9.2.2.1"},"xref":[{"@attributes":{"derivedContent":"A.2","format":"counter","sectionFormat":"of","target":"section-a.2"}},"1994"]}},{"@attributes":{"pn":"section-toc.1-1.9.2.3"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.9.2.3.1"},"xref":[{"@attributes":{"derivedContent":"A.3","format":"counter","sectionFormat":"of","target":"section-a.3"}},"2000"]}}]}},{"@attributes":{"pn":"section-toc.1-1.10"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.10.1"},"xref":[{"@attributes":{"derivedContent":"","format":"none","sectionFormat":"of","target":"section-appendix.b"}},"IAB Members at the Time of Approval"]}},{"@attributes":{"pn":"section-toc.1-1.11"},"t":{"@attributes":{"keepWithNext":"true","pn":"section-toc.1-1.11.1"},"xref":[{"@attributes":{"derivedContent":"","format":"none","sectionFormat":"of","target":"section-appendix.c"}},"Authors' Addresses"]}}]}}}},"middle":{"section":[{"@attributes":{"anchor":"intro","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-1"},"name":"Introduction","t":["\nThe first Request for Comments (RFC) document was published in April\nof 1969 as part of the effort to design and build\nwhat we now know of as the Internet.  Since then, the RFC Series\nhas been the archival series dedicated to documenting\nInternet technical specifications, including both general\ncontributions from the Internet research and engineering\ncommunity as well as standards documents.\n","\nAs described in the history of the first 30 years of RFCs\n(), the RFC Series was created for the purpose\nof capturing the research and engineering thought that underlie\nthe design of (what we now know of as) the Internet.   As the\nInternet Engineering Task Force (IETF) was formalized to carry out\nthe discussion and documentation of Internet standards, IETF documents\nhave become a large part (but not the entirety) of the RFC Series.  \n","\nAs the IETF has grown up and celebrated its own 30 years of \nhistory, its requirements for archival publication of its output\nhave changed and become more rigorous.  Perhaps most significantly,\nthe IETF must be able to define (based on its own open consensus\ndiscussion processes and leadership directions) and implement\nadjustments to its publication processes.\n","\nAt the same time, the Internet engineering and research community\nas a whole has grown and come to require more openness and accountability\nin all organizations supporting it.  More than ever, this community\nneeds an RFC Series that is supported (operationally and in terms of\nits principles) such that there is a balance of:\n","\nIn the past, there has been confusion and therefore sometimes tension over \nwhere and how to address RFC issues that are particular to\ncontributing groups (e.g., the IETF, the Internet Architecture Board\n(IAB), or independent individuals).  It was not always clear where there should\nbe community involvement versus RFC Editor control; depending on the\nissue, there might be more or less involvement from the IAB, the\nInternet Engineering Steering Group (IESG), or the\ncommunity at large.  There are similar issues with handling RFC\nSeries-wide issues -- where to discuss and resolve them in a way that\nis balanced across the whole series.\n","\nFor example, there have been discussions about Intellectual Property\nRights (IPR) for IETF-generated documents, but it's not clear when or\nhow to abstract the portions of those discussions that are relevant\nto the rest of the RFC Series.  Discussions of labeling (of\nRFCs in general, IETF documents in particular, or some combination\nthereof) generally must be applied to the whole RFC Series or\nnot at all.  Without an agreed-on framework for managing the RFC Series, it is \ndifficult to have those discussions in a non-polarized fashion -- \neither the IETF dictating the reality of the rest of the RFC Series, or the \nRFC Series imposing undue restrictions on documents from the IETF.  \n","\nAs part of its charter (see ), the IAB has \na responsibility for the RFC Editor.  Acknowledging the IETF's needs\nand the general Internet engineering and research community's evolving\nneeds, the IAB supports a future for the RFC Series that\ncontinues to meet its original mandate of providing the archival\nseries for the technical research and engineering documentation that\ndescribes the Internet.  \n","\nWith this document, the IAB provides the framework for the RFC Series and\nan RFC Editor function with the specific purpose of ensuring that the RFC\nSeries is maintained and supported in ways that are consistent with the\nstated purpose of the RFC Series and the realities of today's Internet\nresearch and engineering community.  The framework describes the existing\n\"streams\" of RFCs, draws a roadmap of existing process documents already\ndefining the implementation, and provides clear direction of how to\nevolve this framework and its supporting pieces through discussion and\nfuture document revision.\n","\nSpecifically, this document provides a brief charter for the RFC Series,\ndescribes the role of the RFC Editor, the IAB, and the IETF\nAdministrative Support Activity (IASA) in a framework for managing the\nRFC Series, and discusses the streams of input to the RFC Series from the\nvarious constituencies it serves.\n"],"ul":{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-1-5"},"li":["\n    expert implementation;\n    ","\n    clear management and direction -- for operations and evolution across\n    the whole RFC Series (whether originating in the IETF or not); and \n    ","\n    appropriate community input into and review of activities.\n    "]}},{"@attributes":{"anchor":"charter","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-2"},"name":"RFC Series Mission","t":["\nThe RFC Series is the archival series dedicated to documenting Internet \ntechnical specifications, including general\ncontributions from the Internet research and engineering\ncommunity as well as standards documents.\n","\nRFCs are available free of charge to anyone via the Internet. \n"]},{"@attributes":{"anchor":"roles","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-3"},"name":"Roles and Responsibilities","t":"\nAs this document sets out the framework for supporting the\nRFC Series mission, this section reviews the updated roles and \nresponsibilities of the entities that have had, and will have, \ninvolvement in continued support of the mission.\n","section":[{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-3.1"},"name":"RFC Editor","t":["\nOriginally, there was a single person acting as editor of the RFC\nSeries (the RFC Editor).  The task has grown, and the work now \nrequires the organized activity of several experts, so there are\nRFC Editors, or an RFC Editor organization.  In time, there may be\nmultiple organizations working together to undertake the work required\nby the RFC Series.  For simplicity's sake, and without attempting\nto predict how the role might be subdivided among them, this document \nrefers to this collection of experts and organizations as the \"RFC Editor\".\n","\nThe RFC Editor is an expert technical editor and series editor, acting to \nsupport the mission of the RFC Series.  As such, the RFC Editor\nis the implementer handling the editorial management of the RFC \nSeries, in accordance with the defined processes.  In addition, the\nRFC Editor is expected to be the expert and prime mover in discussions\nabout policies for editing, publishing, and archiving RFCs.\n"]},{"@attributes":{"anchor":"iab","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-3.2"},"name":"IAB","t":["\nIn this model, the role of the IAB is to ensure that the RFC Series\nmission is being appropriately fulfilled for the whole community for\nwhich it was created.  The IAB does not, organizationally, have\ncomprehensive publishing or editorial expertise.  Therefore, the role of\nthe IAB is focused on ensuring that principles are met, the appropriate\nbodies and communities are duly informed and consulted, and the RFC\nEditor has what it needs in order to execute on the material that is in\ntheir mandate.\n","\nIt is the responsibility of the IAB to approve the\nappointment of the RFC Editor and to approve the general\npolicy followed by the RFC Editor.\n"]},{"@attributes":{"anchor":"ops","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-3.3"},"name":"Operational Oversight","t":["\nThe IETF Administration Limited Liability Company (IETF LLC), as part\nof the IETF Administrative Support Activity (IASA), is responsible\nfor administrative and financial matters for the IETF, the IAB, and\nthe Internet Research Task Force (IRTF)\n.  The IASA is tasked with\nproviding the funding for the RFC Editor.  The IASA, through the\nIETF Executive Director, provides contractual and financial oversight\nof the RFC Editor.  Additionally, as described in \n, the RFC Series Oversight\nCommittee (RSOC), acting with authority delegated from the IAB, is\nresponsible for ensuring that the RFC Series is run in a transparent\nand accountable manner, including design and execution of the\nRFC Series Editor selection process.\n","\nThe IETF Executive Director works with the IAB to identify suitable\npersons or entities to fulfill the mandate of the RFC Production\nCenter and the RFC Publisher roles as defined in\n.\n","\nThe IETF Executive Director establishes appropriate\ncontractual agreements with the selected persons or entities\nto carry out the work that will satisfy the technical publication requirements\ndefined for the various RFC input streams (see ).\nThe IETF Executive Director may define additional operational requirements\nand policies for management purposes to meet the requirements defined\nby the various communities.    \n","\nThe IETF Administration LLC Board approves a budget for operation of\nthe RFC Editor activity, and the IETF Executive Director establishes and\nmanages the necessary operational agreements for the RFC Editor activity.\n"]},{"@attributes":{"anchor":"policyoversight","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-3.4"},"name":"Policy Oversight","t":"\nThe IAB monitors the effectiveness of the policies in force and\ntheir implementation to ensure that the RFC Editor activity\nmeets the editorial management and document publication needs\nas referenced in this document.  In the event of serious non-conformance,  \nthe IAB, either on its own initiative or at the request of the IETF\nAdministration LLC Board, may require the IETF Executive Director to vary\nor terminate and renegotiate the arrangements for the RFC Editor activity. \n"}]},{"@attributes":{"anchor":"framework","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4"},"name":"Framework","t":["\nWith the RFC Series mission outlined above, this document describes a\nframework for supporting \n","\nbased on\n","\nfor which there are \n","\nGenerally speaking, the RFC Editor is responsible for the \noperational implementation of the RFC Series.  As outlined\nin , the IETF Executive Director provides\nthe oversight of this operational role.\n","\nThe process and definition documents are detailed below, including\nresponsibility for the individual process documents (maintenance and\nupdate).  The RFC Editor works with the appropriate community to ensure\nthat the process documents reflect current requirements.  The IAB is\ncharged with the role of verifying that appropriate community input has\nbeen sought and that any changes appropriately account for community\nrequirements.\n","\nThere are three categories of activity, and a fourth category of series-wide \nrules and guidelines, described for implementing the RFC Series to support \nits mission:\n"],"ul":[{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-4-2"},"li":"\n    the operational implementation of the RFC Series, \n    "},{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-4-4"},"li":"\n    public process and definition documents, \n    "},{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-4-6"},"li":"\n    clear responsibilities and mechanisms for update and change.\n    "},{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-4-10"},"li":["\n    Approval of documents.\n    ","\n    Editing, processing, and publication of documents.\n    ","\n    Archiving and indexing the documents and making them accessible.\n    ","\n    Series rules and guidelines.\n    "]}],"section":[{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.1"},"name":"Document Approval","t":"\nThe RFC Series mission implicitly requires that documents be\nreviewed and approved for acceptance into the series.  \n","section":[{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.1.1"},"name":"Definition","t":{"@attributes":{"pn":"section-4.1.1-1"},"xref":[{"@attributes":{"target":"approval","format":"default","sectionFormat":"of","derivedContent":"Section 5.1"}},{"@attributes":{"target":"approval","format":"default","sectionFormat":"of","derivedContent":"Section 5.1"}}]}},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.1.2"},"name":"Operational Implementation","t":"\nEach stream has its own documented approval process.  The RFC Editor is\nresponsible for the approval of documents in one of the streams\n(Independent Submission stream, see )\nand works with the other approving bodies to ensure smooth passage of\napproved documents into the next phases, ultimately to publication and\narchiving as an RFC.\n"},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.1.3"},"name":"Process Change","t":["\nFrom time to time, it may be necessary to change the approval processes\nfor any given stream, or even add or remove streams.  This may occur\nwhen the RFC Editor, the IAB, the body responsible for a given stream of \ndocuments, or the community determines that there are issues to be\nresolved in general for RFC approval or for per-stream approval processes.\n","\nIn this framework, the general approach is that the IAB will work with\nthe RFC Editor and other parties to get community input, and it will verify\nthat any changes appropriately account for community requirements. \n"]},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.1.4"},"name":"Existing Approval Process Documents","t":"\nThe existing documents describing the approval processes for each \nstream are detailed in .\n"}]},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.2"},"name":"Editing, Processing, and Publication of Documents","t":"\nProducing and maintaining a coherent, well-edited document series \nrequires specialized skills and subject matter expertise.  This is\nthe domain of the RFC Editor.  Nevertheless, the community served\nby the RFC Series and the communities served by the individual\nstreams of RFCs have requirements that help define the nature of the\nseries.\n","section":[{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.2.1"},"name":"Definition","t":["\nGeneral and stream-specific requirements for the RFC Series are documented\nin community-approved documents (catalogued in \nbelow).\n","\nAny specific interfaces, numbers, or concrete values required to make the\nrequirements operational are the subject of agreements between\nthe IASA and the RFC Editor (e.g., contracts, statements of work, service\nlevel agreements, etc).\n"]},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.2.2"},"name":"Operational Implementation","t":"\nThe RFC Editor is responsible for ensuring that editing, processing, and\npublication of RFCs are carried out in a way that is consistent with the\nrequirements laid out in the appropriate documents.  The RFC Editor works\nwith the IASA to provide regular reporting and feedback on these operations.\n"},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.2.3"},"name":"Process Change","t":["\nFrom time to time, it may be necessary to change the requirements\nfor any given stream, or the RFC Series in general.  This may occur\nwhen the RFC Editor, the IAB, the approval body for a given stream of \ndocuments, or the community determines that there are issues to be\nresolved in general for RFCs or for per-stream requirements.\n","\nIn this model, the general approach is that the IAB will work with the\nRFC Editor to get community input, and it will approve changes by\nvalidating appropriate consideration of community requirements.\n"]},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.2.4"},"name":"Existing Process Documents","t":"\nDocuments describing existing requirements for the streams are\ndetailed in .\n"}]},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.3"},"name":"Archiving, Indexing, and Accessibility","t":"\nThe activities of archiving, indexing, and making accessible the RFC\nSeries can be informed by specific subject matter expertise in general\ndocument series editing.  It is also important that they are informed by\nrequirements from the whole community.  As long as the RFC Series is to\nremain coherent, there should be uniform archiving and indexing of RFCs\nacross all streams and a common method of accessing the resulting\ndocuments.\n","section":[{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.3.1"},"name":"Definition","t":["\nIn principle, there should be a community consensus document describing\nthe archiving, indexing, and accessibility requirements for the RFC\nSeries.  In practice, we continue with the archive as built by the\ncapable RFC Editors since the series' inception.\n","\nAny specific concrete requirements for the archive, index, and\naccessibility operations are the subject of agreements between the IASA\nand the RFC Editor (e.g., contracts, statements of work, service level\nagreements, etc).\n"]},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.3.2"},"name":"Operational Implementation","t":"\nThe RFC Editor is responsible for ensuring that the RFC archive and index\nare maintained appropriately and that the resulting documents are made\navailable to anybody wishing to access them via the Internet.  The RFC\nEditor works with the IASA for regular reporting and feedback.\n"},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.3.3"},"name":"Process Change","t":"\nShould there be a community move to propose changes to the requirements\nfor the RFC archive and index or accessibility, the IAB will work with \nthe RFC Editor to get community input, and it will approve changes \nby validating appropriate consideration of community requirements.\n"},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.3.4"},"name":"Existing Process Documents","t":"\nThere are no applicable process documents.\n"}]},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.4"},"name":"Series-Wide Guidelines and Rules","t":"\nThe RFC Series style and content can be shaped by subject matter\nexpertise in document series editing.  They are also informed by\nrequirements by the using community.  As long as the RFC Series is to\nremain coherent, there should be uniform style and content for RFCs\nacross all streams.  This includes, but is not limited to, acceptable\nlanguage, use of references, and copyright rules.\n","section":[{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.4.1"},"name":"Definition","t":"\nIn principle, there should be a community consensus document (or set of\ndocuments) describing the content requirements for the RFC Series.  In\npractice, some do exist, though some need reviewing and more may be\nneeded over time.\n"},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.4.2"},"name":"Operational Implementation","t":"\nThe RFC Editor is responsible for ensuring that the RFC Series guidelines\nare upheld within the RFC Series. \n"},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.4.3"},"name":"Process Change","t":"\nWhen additions or changes are needed to series-wide definitions,\nthe IAB will work with the RFC Editor and stream stakeholders\nto get community input and review.  The IAB will approve changes by\nvalidating appropriate consideration of community requirements.  \n"},{"@attributes":{"numbered":"true","toc":"include","removeInRFC":"false","pn":"section-4.4.4"},"name":"Existing Process Documents","t":"\nExisting series-wide rules and guidelines documents include:\n","ul":{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-4.4.4-2"},"li":["\n    RFC Style Guide\n    , \n    ","\n    The Use of Non-ASCII Characters in RFCs\n    ,\n    ","\n    Copyright and intellectual property rules\n    ,\n    ","\n    Normative references\n    \n              ,\n    .\n    "]}}]}]},{"@attributes":{"anchor":"streams","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5"},"name":"RFC Streams","t":["\nVarious contributors provide input to the RFC Series.  These\ncontributors come from several different communities, each\nwith its own defined process for approving documents that\nwill be published by the RFC Editor.  This is nothing new;\nhowever, over time the various communities and document\nrequirements have grown and separated.  In order to promote\nharmony in discussing the collective set of requirements,\nit is useful to recognize each in their own space -- and they\nare referred to here as \"streams\".  \n","\nNote that by identifying separate streams, there is no intention\nof dividing them or undermining their management as one series.  Rather,\nthe opposite is true -- by clarifying the constituent parts, \nit is easier to make them work together without the friction that\nsometimes arises when discussing various requirements.\n","\nThe subsections below identify the streams that exist today. \nThere is no immediate expectation of new streams being created,\nand it is preferable that new streams NOT be created.  Creation of\nstreams and all policies surrounding general changes to the\nRFC Series are discussed above in .\n"],"section":[{"@attributes":{"anchor":"approval","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.1"},"name":"RFC Approval Processes","t":["\nProcesses for approval of documents (or requirements) for each stream are\ndefined by the community that defines the stream.  The IAB is charged\nwith the role of verifying that appropriate community input has been\nsought and that the changes are consistent with the RFC Series mission\nand this overall framework.\n","\nThe RFC Editor is expected to publish all documents passed to it\nafter appropriate review and approval in one of the identified\nstreams.\n"],"section":[{"@attributes":{"anchor":"ietf-approval","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.1.1"},"name":"IETF Document Stream","t":["\nThe IETF document stream includes IETF WG documents as well as\n\"individual submissions\" sponsored by an IESG area director.  Any\ndocument being published as part of the IETF standards process\nmust follow this stream -- no other stream can approve\nStandards-Track RFCs or Best Current Practice (BCP) RFCs.\n","\nApproval of documents in the IETF stream is defined by \n","\nChanges to the approval process for this stream are made by\nupdating the IETF standards process documents. \n"],"ul":{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-5.1.1-3"},"li":["\n    the IETF standards process\n     (and its successors).\n    ","\n    the IESG process for sponsoring individual submissions\n    .\n    "]}},{"@attributes":{"anchor":"iab-approval","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.1.2"},"name":"IAB Document Stream","t":["\nThe IAB defines the processes by which it approves documents in its\nstream.  Consistent with the above, any documents that the IAB wishes to\npublish as part of the IETF Standards Track (Standards or BCPs) are\nsubject to the approval processes referred to in .\n","\nThe review and approval process for documents in the IAB\nstream is described in \n"],"ul":{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-5.1.2-3"},"li":"\n    the IAB process for review and approval of its documents\n    .\n    "}},{"@attributes":{"anchor":"irtf-approval","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.1.3"},"name":"IRTF Document Stream","t":["\nThe IRTF is chartered as an activity of the IAB.  With the approval\nof the IAB, the IRTF may publish and update a process for\npublication of its own, non-IETF Standards-Track, documents.\n","\nThe review and approval process for documents in the IRTF stream\nis described in\n"],"ul":{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-5.1.3-3"},"li":"\n    IRTF Research Group RFCs\n    .\n    "}},{"@attributes":{"anchor":"independent-approval","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.1.4"},"name":"Independent Submission Stream","t":["\nThe RFC Series has always served a broader Internet technical \ncommunity than the IETF.  The \"Independent Submission\" stream is\ndefined to provide review and (possible) approval of documents\nthat are outside the scope of the streams identified above.  \n","\nGenerally speaking, approval of documents in this stream falls\nunder the purview of the RFC Editor, and the RFC Editor seeks\ninput to its review from the IESG. \n","\nThe process for reviewing and approving documents in the Independent\nSubmission stream is defined by\n"],"ul":{"@attributes":{"spacing":"normal","bare":"false","empty":"false","pn":"section-5.1.4-4"},"li":["\n    Procedures for Rights Handling in the RFC Independent Submission Stream\n    ,\n    ","\n    Independent Submission Editor Model\n    ,\n    ","\n    Independent Submissions to the RFC Editor\n    ,\n    ","\n    The IESG and RFC Editor Documents: Procedures\n    .\n    "]}}]},{"@attributes":{"anchor":"reqs","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.2"},"name":"RFC Technical Publication Requirements","t":["\nThe Internet engineering and research community has not only grown,\nit has become more diverse, and sometimes more demanding.  The IETF,\nas a standards-developing organization, has publication requirements\nthat extend beyond those of an academic journal.  The IAB does not\nhave the same interdependence with IANA assignments as the IETF\nstream does.  Therefore, there is the need to both codify the\npublishing requirements of each stream, and endeavor to harmonize\nthem to the extent that is reasonable.\n","\nTherefore, it is expected that the community of effort behind\neach document stream will outline their technical publication \nrequirements.\n"," \nAs part of the RFC Editor oversight, the IAB must agree that the\nrequirements are consistent with and implementable as part of the\nRFC Editor activity.\n"],"section":[{"@attributes":{"anchor":"ietf-req","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.2.1"},"name":"IETF Documents","t":"\nThe requirements for this stream  are defined in .\n"},{"@attributes":{"anchor":"iab-req","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.2.2"},"name":"IAB Documents","t":["\nAlthough they were developed for the IETF standards process, the IAB has\nidentified applicable requirements in  for its\nstream.  In addition, procedures related to IPR for the IAB stream are\ncaptured in .\n","\nIf the IAB elects to define other requirements, they should deviate\nminimally from those (in an effort to keep the collective technical\npublication requirements reasonably managed by one technical publisher).\n"]},{"@attributes":{"anchor":"irtf-req","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.2.3"},"name":"IRTF Documents","t":["\nThe IRTF has identified applicable requirements in \nfor its stream.\n","\nIf the IRTF elects to define other requirements, they should deviate\nminimally from those (in an effort to keep the collective technical\npublication requirements reasonably managed by one technical publisher).\n"]},{"@attributes":{"anchor":"independent-req","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-5.2.4"},"name":"Independent Submissions","t":["\nProcedures and processes for the Independent Stream are described in\n and .\n","\nAlthough they were developed for the IETF standards process, the RFC\nEditor has identified applicable requirements in \nfor the Independent Submissions stream.  In addition, procedures related\nto IPR for the independent submissions stream are captured in\n.\n","\nIf the RFC Editor elects to define other requirements, they should deviate\nminimally from those (in an effort to keep the collective technical\npublication requirements reasonably managed by one technical publisher).\n"]}]}]},{"@attributes":{"anchor":"security","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-6"},"name":"Security Considerations","t":"\nThe processes for the publication of documents must prevent the\nintroduction of unapproved changes.  Since the RFC Editor maintains the\nindex of publications, sufficient security must be in place to prevent\nthese published documents from being changed by external parties.  The\narchive of RFC documents, any source documents needed to recreate the RFC\ndocuments, and any associated original documents (such as lists of\nerrata, tools, and, for some early items, non-machine readable originals)\nneed to be secured against failure of the storage medium and other\nsimilar disasters.\n"},{"@attributes":{"anchor":"changes","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-7"},"name":"Changes Since RFC 4844","t":["\nSections , ,\nand  \nhave been updated to align with the restructuring of the\nIETF Administrative Support Activity (IASA).  Under the new structure, the\nIETF LLC performs the tasks related to IASA that were previously assigned to\nthe IETF Administrative Director and to the Internet Society.\n","\nMany references were updated to point to the most recent documents.\n","\nMinor editorial changes were made to reflect 10 years of using the framework\nprovided in RFC 4884.  For example, RFC 4844 said, \"... this document sets out\na revised framework  ...\", and it is now more appropriate to say, \"... this\ndocument sets out the framework ...\".\n"]}]},"back":{"references":{"@attributes":{"pn":"section-8"},"name":"Informative References","reference":[{"@attributes":{"anchor":"RFC1358","target":"https:\/\/www.rfc-editor.org\/info\/rfc1358","quoteTitle":"true","derivedAnchor":"RFC1358"},"front":{"title":"Charter of the Internet Architecture Board (IAB)","author":{"@attributes":{"initials":"L.","surname":"Chapin","fullname":"L. Chapin"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},"date":{"@attributes":{"year":"1992","month":"August"}},"abstract":{"t":"The Internet Architecture Board (IAB) shall be constituted and shall operate as a technical advisory group of the Internet Society.  This memo provides information for the Internet community.  It does not specify an Internet standard."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"1358"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC1358"}}]},{"@attributes":{"anchor":"RFC1601","target":"https:\/\/www.rfc-editor.org\/info\/rfc1601","quoteTitle":"true","derivedAnchor":"RFC1601"},"front":{"title":"Charter of the Internet Architecture Board (IAB)","author":{"@attributes":{"initials":"C.","surname":"Huitema","fullname":"C. Huitema"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},"date":{"@attributes":{"year":"1994","month":"March"}},"abstract":{"t":"This memo documents the composition, selection, roles, and organization of the Internet Architecture Board and its subsidiary organizations. This memo provides information for the Internet community.  This memo does not specify an Internet standard of any kind."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"1601"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC1601"}}]},{"@attributes":{"anchor":"RFC2026","target":"https:\/\/www.rfc-editor.org\/info\/rfc2026","quoteTitle":"true","derivedAnchor":"RFC2026"},"front":{"title":"The Internet Standards Process -- Revision 3","author":{"@attributes":{"initials":"S.","surname":"Bradner","fullname":"S. Bradner"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},"date":{"@attributes":{"year":"1996","month":"October"}},"abstract":{"t":"This memo documents the process used by the Internet community for the standardization of protocols and procedures.  It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements."}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"9"}},{"@attributes":{"name":"RFC","value":"2026"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC2026"}}]},{"@attributes":{"anchor":"RFC2555","target":"https:\/\/www.rfc-editor.org\/info\/rfc2555","quoteTitle":"true","derivedAnchor":"RFC2555"},"front":{"title":"30 Years of RFCs","author":[{"@attributes":{"initials":"RFC","surname":"Editor","fullname":"RFC Editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"et","surname":"al.","fullname":"et al."},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"1999","month":"April"}},"abstract":{"t":"The rest of this document contains a brief recollection from the present RFC Editor Joyce K. Reynolds, followed by recollections from three pioneers: Steve Crocker who wrote RFC 1, Vint Cerf whose long-range vision continues to guide us, and Jake Feinler who played a key role in the middle years of the RFC series. This memo provides information for the Internet community."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"2555"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC2555"}}]},{"@attributes":{"anchor":"RFC2850","target":"https:\/\/www.rfc-editor.org\/info\/rfc2850","quoteTitle":"true","derivedAnchor":"RFC2850"},"front":{"title":"Charter of the Internet Architecture Board (IAB)","author":[{"organization":"Internet Architecture Board"},{"@attributes":{"initials":"B.","surname":"Carpenter","fullname":"B. Carpenter","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2000","month":"May"}},"abstract":{"t":"This memo documents the composition, selection, roles, and organization of the Internet Architecture Board.  It replaces RFC 1601.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements."}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"39"}},{"@attributes":{"name":"RFC","value":"2850"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC2850"}}]},{"@attributes":{"anchor":"RFC3967","target":"https:\/\/www.rfc-editor.org\/info\/rfc3967","quoteTitle":"true","derivedAnchor":"RFC3967"},"front":{"title":"Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level","author":[{"@attributes":{"initials":"R.","surname":"Bush","fullname":"R. Bush"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"T.","surname":"Narten","fullname":"T. Narten"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2004","month":"December"}},"abstract":{"t":"IETF procedures generally require that a standards track RFC may not have a normative reference to another standards track document at a lower maturity level or to a non standards track specification (other than specifications from other standards bodies).  For example, a standards track document may not have a normative reference to an informational RFC.  Exceptions to this rule are sometimes needed as the IETF uses informational RFCs to describe non-IETF standards or IETF-specific modes of use of such standards.  This document clarifies and updates the procedure used in these circumstances.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements."}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"97"}},{"@attributes":{"name":"RFC","value":"3967"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC3967"}}]},{"@attributes":{"anchor":"RFC4714","target":"https:\/\/www.rfc-editor.org\/info\/rfc4714","quoteTitle":"true","derivedAnchor":"RFC4714"},"front":{"title":"Requirements for IETF Technical Publication Service","author":[{"@attributes":{"initials":"A.","surname":"Mankin","fullname":"A. Mankin"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"S.","surname":"Hayes","fullname":"S. Hayes"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2006","month":"October"}},"abstract":{"t":"The work of the IETF is to discuss, develop, and disseminate technical specifications to support the Internet's operation. Technical publication is the process by which that output is disseminated to the community at large.  As such, it is important to understand the requirements on the publication process.  This memo provides information for the Internet community."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"4714"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC4714"}}]},{"@attributes":{"anchor":"RFC4845","target":"https:\/\/www.rfc-editor.org\/info\/rfc4845","quoteTitle":"true","derivedAnchor":"RFC4845"},"front":{"title":"Process for Publication of IAB RFCs","author":[{"@attributes":{"initials":"L.","surname":"Daigle","fullname":"L. Daigle","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"organization":"Internet Architecture Board"}],"date":{"@attributes":{"year":"2007","month":"July"}},"abstract":{"t":"From time to time, the Internet Architecture Board (IAB) publishes documents as Requests for Comments (RFCs).  This document defines the process by which those documents are produced, reviewed, and published in the RFC Series.  This memo provides information for the Internet community."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"4845"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC4845"}}]},{"@attributes":{"anchor":"RFC4846","target":"https:\/\/www.rfc-editor.org\/info\/rfc4846","quoteTitle":"true","derivedAnchor":"RFC4846"},"front":{"title":"Independent Submissions to the RFC Editor","author":[{"@attributes":{"initials":"J.","surname":"Klensin","fullname":"J. Klensin","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"D.","surname":"Thaler","fullname":"D. Thaler","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2007","month":"July"}},"abstract":{"t":"There is a long-standing tradition in the Internet community, predating the Internet Engineering Task Force (IETF) by many years, of use of the RFC Series to publish materials that are not rooted in the IETF standards process and its review and approval mechanisms. These documents, known as \"Independent Submissions\", serve a number of important functions for the Internet community, both inside and outside of the community of active IETF participants.  This document discusses the Independent Submission model and some reasons why it is important.  It then describes editorial and processing norms that can be used for Independent Submissions as the community goes forward into new relationships between the IETF community and its primary technical publisher.  This memo provides information for the Internet community."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"4846"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC4846"}}]},{"@attributes":{"anchor":"RFC4897","target":"https:\/\/www.rfc-editor.org\/info\/rfc4897","quoteTitle":"true","derivedAnchor":"RFC4897"},"front":{"title":"Handling Normative References to Standards-Track Documents","author":[{"@attributes":{"initials":"J.","surname":"Klensin","fullname":"J. Klensin"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"S.","surname":"Hartman","fullname":"S. Hartman"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2007","month":"June"}},"abstract":{"t":"The Internet Engineering Task Force (IETF) and Request for Comments (RFC) Editor have a long-standing rule that a document at a given maturity level cannot be published until all of the documents that it references as normative are at that maturity level or higher.  This rule has sometimes resulted in very long publication delays for documents and some claims that it was a major obstruction to advancing documents in maturity level.  The IETF agreed on a way to bypass this rule with RFC 3967.  This document describes a simpler procedure for downward references to Standards-Track and Best Current Practice (BCP) documents, namely \"note and move on\".  The procedure in RFC 3967 still applies for downward references to other classes of documents.  In both cases, annotations should be added to such References.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements."}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"97"}},{"@attributes":{"name":"RFC","value":"4897"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC4897"}}]},{"@attributes":{"anchor":"RFC5378","target":"https:\/\/www.rfc-editor.org\/info\/rfc5378","quoteTitle":"true","derivedAnchor":"RFC5378"},"front":{"title":"Rights Contributors Provide to the IETF Trust","author":[{"@attributes":{"initials":"S.","surname":"Bradner","fullname":"S. Bradner","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"J.","surname":"Contreras","fullname":"J. Contreras","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2008","month":"November"}},"abstract":{"t":"The IETF policies about rights in Contributions to the IETF are designed to ensure that such Contributions can be made available to the IETF and Internet communities while permitting the authors to retain as many rights as possible.  This memo details the IETF policies on rights in Contributions to the IETF.  It also describes the objectives that the policies are designed to meet.  This memo obsoletes RFCs 3978 and 4748 and, with BCP 79 and RFC 5377, replaces Section 10 of RFC 2026.  This document  specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements."}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"78"}},{"@attributes":{"name":"RFC","value":"5378"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC5378"}}]},{"@attributes":{"anchor":"RFC5742","target":"https:\/\/www.rfc-editor.org\/info\/rfc5742","quoteTitle":"true","derivedAnchor":"RFC5742"},"front":{"title":"IESG Procedures for Handling of Independent and IRTF Stream Submissions","author":[{"@attributes":{"initials":"H.","surname":"Alvestrand","fullname":"H. Alvestrand"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"R.","surname":"Housley","fullname":"R. Housley"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2009","month":"December"}},"abstract":{"t":["This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams. ","This document updates procedures described in RFC 2026 and RFC 3710.   This memo documents an Internet Best Current Practice."]}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"92"}},{"@attributes":{"name":"RFC","value":"5742"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC5742"}}]},{"@attributes":{"anchor":"RFC5743","target":"https:\/\/www.rfc-editor.org\/info\/rfc5743","quoteTitle":"true","derivedAnchor":"RFC5743"},"front":{"title":"Definition of an Internet Research Task Force (IRTF) Document Stream","author":{"@attributes":{"initials":"A.","surname":"Falk","fullname":"A. Falk"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},"date":{"@attributes":{"year":"2009","month":"December"}},"abstract":{"t":"This memo defines the publication stream for RFCs from the Internet Research Task Force.  Most documents undergoing this process will come from IRTF Research Groups, and it is expected that they will be published as Informational or Experimental RFCs by the RFC Editor.   This document is not an Internet Standards Track specification; it is published for informational purposes."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"5743"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC5743"}}]},{"@attributes":{"anchor":"RFC5744","target":"https:\/\/www.rfc-editor.org\/info\/rfc5744","quoteTitle":"true","derivedAnchor":"RFC5744"},"front":{"title":"Procedures for Rights Handling in the RFC Independent Submission Stream","author":[{"@attributes":{"initials":"R.","surname":"Braden","fullname":"R. Braden"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"J.","surname":"Halpern","fullname":"J. Halpern"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2009","month":"December"}},"abstract":{"t":"This document specifies the procedures by which authors of RFC Independent Submission documents grant the community \"incoming\" rights for copying and using the text.  It also specifies the \"outgoing\" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result.  This memo provides information for the Internet community."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"5744"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC5744"}}]},{"@attributes":{"anchor":"RFC5745","target":"https:\/\/www.rfc-editor.org\/info\/rfc5745","quoteTitle":"true","derivedAnchor":"RFC5745"},"front":{"title":"Procedures for Rights Handling in the RFC IAB Stream","author":[{"@attributes":{"initials":"A.","surname":"Malis","fullname":"A. Malis","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"organization":"IAB"}],"date":{"@attributes":{"year":"2009","month":"December"}},"abstract":{"t":"This document specifies the procedures by which authors of RFC IAB stream documents grant the community \"incoming\" rights for copying and using the text.  It also specifies the \"outgoing\" rights the community grants to readers and users of those documents, and it requests that the IETF Trust manage the outgoing rights to effect this result.  This memo provides information for the Internet  community."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"5745"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC5745"}}]},{"@attributes":{"anchor":"RFC7322","target":"https:\/\/www.rfc-editor.org\/info\/rfc7322","quoteTitle":"true","derivedAnchor":"RFC7322"},"front":{"title":"RFC Style Guide","author":[{"@attributes":{"initials":"H.","surname":"Flanagan","fullname":"H. Flanagan"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"S.","surname":"Ginoza","fullname":"S. Ginoza"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2014","month":"September"}},"abstract":{"t":"This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series.  It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC.  Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide.  This document obsoletes RFC 2223, \"Instructions to RFC Authors\"."}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"7322"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC7322"}}]},{"@attributes":{"anchor":"RFC7997","target":"https:\/\/www.rfc-editor.org\/info\/rfc7997","quoteTitle":"true","derivedAnchor":"RFC7997"},"front":{"title":"The Use of Non-ASCII Characters in RFCs","author":{"@attributes":{"initials":"H.","surname":"Flanagan","fullname":"H. Flanagan","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},"date":{"@attributes":{"year":"2016","month":"December"}},"abstract":{"t":["In order to support the internationalization of protocols and a more diverse Internet community, the RFC Series must evolve to allow for the use of non-ASCII characters in RFCs.  While English remains the required language of the Series, the encoding of future RFCs will be in UTF-8, allowing for a broader range of characters than typically used in the English language.  This document describes the RFC Editor requirements and gives guidance regarding the use of non-ASCII characters in RFCs.","This document updates RFC 7322.  Please view this document in PDF form to see the full text."]}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"7997"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC7997"}}]},{"@attributes":{"anchor":"RFC8067","target":"https:\/\/www.rfc-editor.org\/info\/rfc8067","quoteTitle":"true","derivedAnchor":"RFC8067"},"front":{"title":"Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level","author":{"@attributes":{"initials":"B.","surname":"Leiba","fullname":"B. Leiba"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},"date":{"@attributes":{"year":"2017","month":"January"}},"abstract":{"t":"RFC 3967 specifies a process for allowing normative references to documents at lower maturity levels (\"downrefs\"), which involves calling out the downref explicitly in the Last Call notice.  That requirement has proven to be unnecessarily strict, and this document updates RFC 3967, allowing the IESG more flexibility in accepting downrefs in Standards Track documents."}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"97"}},{"@attributes":{"name":"RFC","value":"8067"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC8067"}}]},{"@attributes":{"anchor":"RFC8711","target":"https:\/\/www.rfc-editor.org\/info\/rfc8711","quoteTitle":"true","derivedAnchor":"RFC8711"},"front":{"title":"Structure of the IETF Administrative Support Activity, Version 2.0","author":[{"@attributes":{"initials":"B.","surname":"Haberman"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"J.","surname":"Hall"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"J.","surname":"Livingood"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"year":"2020","month":"February"}}},"seriesInfo":[{"@attributes":{"name":"BCP","value":"101"}},{"@attributes":{"name":"RFC","value":"8711"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC8711"}}]},{"@attributes":{"anchor":"RFC8728","target":"https:\/\/www.rfc-editor.org\/info\/rfc8728","quoteTitle":"true","derivedAnchor":"RFC8728"},"front":{"title":"RFC Editor Model (Version 2)","author":[{"@attributes":{"initials":"O","surname":"Kolkman","fullname":"Olaf Kolkman","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"J","surname":"Halpern","fullname":"Joel Halpern","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"R","surname":"Hinden","fullname":"Robert Hinden","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"month":"February","year":"2020"}}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"8728"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC8728"}}]},{"@attributes":{"anchor":"RFC8730","target":"https:\/\/www.rfc-editor.org\/info\/rfc8730","quoteTitle":"true","derivedAnchor":"RFC8730"},"front":{"title":"Independent Submission Editor Model","author":[{"@attributes":{"initials":"N","surname":"Brownlee","fullname":"Nevil Brownlee","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}},{"@attributes":{"initials":"R","surname":"Hinden","fullname":"Robert Hinden","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}}}],"date":{"@attributes":{"month":"February","year":"2020"}}},"seriesInfo":[{"@attributes":{"name":"RFC","value":"8730"}},{"@attributes":{"name":"DOI","value":"10.17487\/RFC8730"}}]},{"@attributes":{"anchor":"SPONSOR","target":"http:\/\/www.ietf.org\/iesg\/statement\/ad-sponsoring-docs.html","quoteTitle":"true","derivedAnchor":"SPONSOR"},"front":{"title":"Guidance on Area Director Sponsoring of Documents","author":{"organization":"IESG"},"date":{"@attributes":{"month":"March","year":"2007"}}},"refcontent":"IESG Statement"}]},"section":[{"@attributes":{"anchor":"iabcharterhistory","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-appendix.a"},"name":"A Retrospective of IAB Charters and RFC Editor","t":["\nWith this document, the IAB's role with respect to the RFC Series\nand the RFC Editor is being adjusted to work more directly with the\nRFC Editor and provide oversight to ensure the RFC Series mission\nprinciples and communities' input are addressed appropriately.\n","\nThis section provides an overview of the role of the IAB with respect\nto the RFC Editor as it has been presented in IAB Charter RFCs dating\nback to 1992.  The point of this section is that the IAB's role has\nhistorically been substantive -- whether it is supposed to be directly\nresponsible for the RFC Series' editorial management\n(circa 1992, ), or appointment of\nthe RFC Editor organization and approval of general policy\n(circa 2000, ).\n"],"section":[{"@attributes":{"anchor":"circa1992","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-a.1"},"name":"1992","t":{"@attributes":{"pn":"section-a.1-1"},"xref":{"@attributes":{"target":"RFC1358","format":"default","sectionFormat":"of","derivedContent":"RFC1358"}}},"blockquote":{"@attributes":{"pn":"section-a.1-2"},"artwork":"\n[The IAB's] responsibilities shall include:\n[...]\n    (2)  The editorial management and publication of the Request\n         for Comments (RFC) document series, which constitutes the\n         archival publication series for Internet Standards and\n         related contributions by the Internet research and\n         engineering community.\n"}},{"@attributes":{"anchor":"circa1994","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-a.2"},"name":"1994","t":[{"@attributes":{"pn":"section-a.2-1"},"xref":{"@attributes":{"target":"RFC1601","format":"default","sectionFormat":"of","derivedContent":"RFC1601"}}},"\nWhich it elaborates as:\n"],"blockquote":[{"@attributes":{"pn":"section-a.2-2"},"artwork":"\n[The IAB's] responsibilities under this charter include:\n\n(d) RFC Series and IANA\n\n   The IAB is responsible for editorial management and publication \n   of the Request for Comments (RFC) document series, and for\n   administration of the various Internet assigned numbers.\n"},{"@attributes":{"pn":"section-a.2-4"},"artwork":"\n 2.4 RFC Series and Assigned Numbers\n\n    The RFC Series constitutes the archival publication channel\n    for Internet Standards and for other contributions by the\n    Internet research and engineering community.  The IAB \n    shall select an RFC Editor, who shall be responsible for \n    the editorial management and publication of the RFC Series.\n"}]},{"@attributes":{"anchor":"circa2000","numbered":"true","toc":"include","removeInRFC":"false","pn":"section-a.3"},"name":"2000","t":"\nThe most recent IAB Charter  says:\n","blockquote":{"@attributes":{"pn":"section-a.3-2"},"artwork":"\n(d) RFC Series and IANA\n\nThe RFC Editor executes editorial management and publication of\nthe IETF \"Request for Comment\" (RFC) document series, which is\nthe permanent document repository of the IETF.  The RFC Series\nconstitutes the archival publication channel for Internet \nStandards and for other contributions by the Internet research \nand engineering community.  RFCs are available free of charge to\nanyone via the Internet.  The IAB must approve the appointment \nof an organization to act as RFC Editor and the general policy\nfollowed by the RFC Editor."}}]},{"@attributes":{"numbered":"false","toc":"include","removeInRFC":"false","pn":"section-appendix.b"},"name":"IAB Members at the Time of Approval","t":["\nThe IAB members at the time of approval of RFC 4844 were:\n","\nThe IAB members at the time of approval of this document were:\n"],"ul":[{"@attributes":{"empty":"true","spacing":"compact","bare":"false","pn":"section-appendix.b-2"},"li":[{"@attributes":{"pn":"section-appendix.b-2.1"},"t":{"@attributes":{"pn":"section-appendix.b-2.1.1"},"contact":{"@attributes":{"fullname":"Bernard Aboba"}}}},{"@attributes":{"pn":"section-appendix.b-2.2"},"t":{"@attributes":{"pn":"section-appendix.b-2.2.1"},"contact":{"@attributes":{"fullname":"Loa Andersson"}}}},{"@attributes":{"pn":"section-appendix.b-2.3"},"t":{"@attributes":{"pn":"section-appendix.b-2.3.1"},"contact":{"@attributes":{"fullname":"Brian Carpenter"}}}},{"@attributes":{"pn":"section-appendix.b-2.4"},"t":{"@attributes":{"pn":"section-appendix.b-2.4.1"},"contact":{"@attributes":{"fullname":"Leslie Daigle"}}}},{"@attributes":{"pn":"section-appendix.b-2.5"},"t":{"@attributes":{"pn":"section-appendix.b-2.5.1"},"contact":{"@attributes":{"fullname":"Elwyn Davies"}}}},{"@attributes":{"pn":"section-appendix.b-2.6"},"t":{"@attributes":{"pn":"section-appendix.b-2.6.1"},"contact":{"@attributes":{"fullname":"Kevin Fall"}}}},{"@attributes":{"pn":"section-appendix.b-2.7"},"t":{"@attributes":{"pn":"section-appendix.b-2.7.1"},"contact":{"@attributes":{"fullname":"Olaf Kolkman"}}}},{"@attributes":{"pn":"section-appendix.b-2.8"},"t":{"@attributes":{"pn":"section-appendix.b-2.8.1"},"contact":{"@attributes":{"fullname":"Kurtis Lindqvist"}}}},{"@attributes":{"pn":"section-appendix.b-2.9"},"t":{"@attributes":{"pn":"section-appendix.b-2.9.1"},"contact":{"@attributes":{"fullname":"David Meyer"}}}},{"@attributes":{"pn":"section-appendix.b-2.10"},"t":{"@attributes":{"pn":"section-appendix.b-2.10.1"},"contact":{"@attributes":{"fullname":"David Oran"}}}},{"@attributes":{"pn":"section-appendix.b-2.11"},"t":{"@attributes":{"pn":"section-appendix.b-2.11.1"},"contact":{"@attributes":{"fullname":"Eric Rescorla"}}}},{"@attributes":{"pn":"section-appendix.b-2.12"},"t":{"@attributes":{"pn":"section-appendix.b-2.12.1"},"contact":{"@attributes":{"fullname":"Dave Thaler"}}}},{"@attributes":{"pn":"section-appendix.b-2.13"},"t":{"@attributes":{"pn":"section-appendix.b-2.13.1"},"contact":{"@attributes":{"fullname":"Lixia Zhang"}}}}]},{"@attributes":{"empty":"true","spacing":"compact","bare":"false","pn":"section-appendix.b-4"},"li":[{"@attributes":{"pn":"section-appendix.b-4.1"},"t":{"@attributes":{"pn":"section-appendix.b-4.1.1"},"contact":{"@attributes":{"fullname":"Jari Arkko"}}}},{"@attributes":{"pn":"section-appendix.b-4.2"},"t":{"@attributes":{"pn":"section-appendix.b-4.2.1"},"contact":{"@attributes":{"fullname":"Alissa Cooper"}}}},{"@attributes":{"pn":"section-appendix.b-4.3"},"t":{"@attributes":{"pn":"section-appendix.b-4.3.1"},"contact":{"@attributes":{"fullname":"Stephen Farrell"}}}},{"@attributes":{"pn":"section-appendix.b-4.4"},"t":{"@attributes":{"pn":"section-appendix.b-4.4.1"},"contact":{"@attributes":{"fullname":"Wes Hardaker"}}}},{"@attributes":{"pn":"section-appendix.b-4.5"},"t":{"@attributes":{"pn":"section-appendix.b-4.5.1"},"contact":{"@attributes":{"fullname":"Ted Hardie"}}}},{"@attributes":{"pn":"section-appendix.b-4.6"},"t":{"@attributes":{"pn":"section-appendix.b-4.6.1"},"contact":{"@attributes":{"fullname":"Christian Huitema"}}}},{"@attributes":{"pn":"section-appendix.b-4.7"},"t":{"@attributes":{"pn":"section-appendix.b-4.7.1"},"contact":{"@attributes":{"fullname":"Zhenbin Li"}}}},{"@attributes":{"pn":"section-appendix.b-4.8"},"t":{"@attributes":{"pn":"section-appendix.b-4.8.1"},"contact":{"@attributes":{"fullname":"Erik Nordmark"}}}},{"@attributes":{"pn":"section-appendix.b-4.9"},"t":{"@attributes":{"pn":"section-appendix.b-4.9.1"},"contact":{"@attributes":{"fullname":"Mark Nottingham"}}}},{"@attributes":{"pn":"section-appendix.b-4.10"},"t":{"@attributes":{"pn":"section-appendix.b-4.10.1"},"contact":{"@attributes":{"fullname":"Melinda Shore"}}}},{"@attributes":{"pn":"section-appendix.b-4.11"},"t":{"@attributes":{"pn":"section-appendix.b-4.11.1"},"contact":{"@attributes":{"fullname":"Jeff Tantsura"}}}},{"@attributes":{"pn":"section-appendix.b-4.12"},"t":{"@attributes":{"pn":"section-appendix.b-4.12.1"},"contact":{"@attributes":{"fullname":"Martin Thomson"}}}},{"@attributes":{"pn":"section-appendix.b-4.13"},"t":{"@attributes":{"pn":"section-appendix.b-4.13.1"},"contact":{"@attributes":{"fullname":"Brian Trammell"}}}}]}]},{"@attributes":{"anchor":"authors-addresses","numbered":"false","removeInRFC":"false","toc":"include","pn":"section-appendix.c"},"name":"Authors' Addresses","author":[{"@attributes":{"fullname":"Russ Housley","initials":"R.","surname":"Housley","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}},"address":{"email":"housley@vigilsec.com"}},{"@attributes":{"fullname":"Leslie L. Daigle","initials":"L.","surname":"Daigle","role":"editor"},"organization":{"@attributes":{"showOnFrontPage":"true"}},"address":{"email":"ldaigle@thinkingcat.com"}}]}]}}