[要約] 要約：RFC 8700は、RFCの50年の歴史を振り返り、その重要性と影響を示すものです。 目的：RFC 8700の目的は、RFCの長い歴史を通じての成果と貢献を強調し、インターネットの発展におけるRFCの役割を認識することです。
Internet Architecture Board (IAB) H. Flanagan, Ed.
Request for Comments: 8700 RFC Editor
Updates: 2555, 5540 December 2019
Category: Informational
ISSN: 2070-1721
Fifty Years of RFCs
RFCの50年
Abstract
概要
This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates the perspectives offered in RFCs 2555 and 5540.
このRFCは、RFCシリーズの50周年を迎えます。これには、主要な変曲点に関与した個人からの遡及資料と、現在の状況のレビューの両方が含まれます。最後に、シリーズの今後50年間の可能性について考えます。このドキュメントは、RFC 2555および5540で提供されているパースペクティブを更新します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供するために価値があると見なした情報を表しています。これは、インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。 IABによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8700.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8700で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction
2. Key Moments in RFC History
3. Perspectives
3.1. The Origins of RFCs - by Stephen D. Crocker
3.2. The RFC Management and Editing Team - by Vint Cerf
3.3. Formalizing the RFC Editor Model - by Leslie Daigle
3.4. The Continuation, or Creation, of a Stream - by Nevil
Brownlee
3.5. A View from inside the RFC Editor - by Sandy Ginoza
4. The Next Fifty Years of RFCs
4.1. Preservation
4.2. Evolution of the RFC Format
4.3. Stream Structure
5. Conclusion
6. IANA Considerations
7. Security Considerations
8. Informative References
IAB Members at the Time of Approval
Acknowledgements
Contributors
Author's Address
The RFC Series began in April 1969 with the publication of "Host Software" by Steve Crocker. The early RFCs were, in fact, requests for comments on ideas and proposals; the goal was to start conversations rather than to create an archival record of a standard or best practice. This goal changed over time, as the formality of the publication process evolved and the community consuming the material grew. Today, over 8500 RFCs have been published, ranging across best practice guidance, experimental protocols, informational material, and, of course, Internet standards. Material is accepted for publication through the IETF, the IAB, the IRTF, and the Independent Submissions streams, each of which have clear processes on how drafts are submitted and potentially approved for publication as an RFC. Ultimately, the goal of the RFC Series is to provide a canonical source for the material published by the RFC Editor and to support the preservation of that material in perpetuity.
RFCシリーズは、1969年4月にSteve Crockerによる「ホストソフトウェア」の発行から始まりました。初期のRFCは、実際には、アイデアや提案に関するコメントの要求でした。目標は、標準またはベストプラクティスのアーカイブレコードを作成するのではなく、会話を始めることでした。この目標は、出版プロセスの形式が進化し、資料を消費するコミュニティが成長するにつれて、時間とともに変化しました。今日、8500を超えるRFCが公開され、ベストプラクティスガイダンス、実験プロトコル、情報資料、そしてもちろんインターネット標準にまで及んでいます。資料は、IETF、IAB、IRTF、および独立提出のストリームを通じて公開が受け入れられます。それぞれのストリームには、ドラフトの提出方法に関する明確なプロセスがあり、RFCとしての公開が承認される可能性があります。最終的に、RFCシリーズの目標は、RFCエディターによって公開された資料の標準的なソースを提供し、その資料の永続的な保持をサポートすることです。
The RFC Editor as a role came a few years after the first RFC was published. The actual date the term "RFC Editor" was first used is unknown, but it was formalized by [RFC0902] in July 1984; Jon Postel, the first RFC Editor, defined the role by his actions and later by defining the initial processes surrounding the publication of RFCs. What is certain is that the goal of the RFC Editor is to produce documents that are readable, clear, consistent, and reasonably uniform, and that the archival record of what has been published is maintained.
RFC Editorは、最初のRFCが公開されてから数年後に役割として登場しました。 「RFC Editor」という用語が最初に使用された実際の日付は不明ですが、1984年7月に[RFC0902]によって正式に定義されました。最初のRFC編集者であるJon Postelは彼の行動によって役割を定義し、後でRFCの発行を取り巻く初期プロセスを定義することによって役割を定義しました。確かなことは、RFCエディターの目的は、読みやすく、明確で、一貫性があり、適度に均一なドキュメントを作成することであり、公開されたもののアーカイブレコードが維持されることです。
Change does come to the Series, albeit slowly. First, we saw the distribution method change from postal mail to FTP and then to email. RFCs could not be distributed electronically in the beginning, as the means to do that distribution would not be defined until years after the first RFC was "published". Not all early RFCs were even created electronically; some were written out by hand or on a typewriter. Eventually, the process for creating RFCs became more structured; authors were provided guidance on how to write an RFC. The editorial effort went from Steve Crocker to a more official model with a designated editor, Jon Postel, and later to a team of five to seven individuals. The actual editing and publishing work split from the service for registration of protocol code points. The whole RFC Editor structure was reviewed [RFC4844], refined [RFC5620], and refined again [RFC6635]. And, in the last few years, the process to change the format of the RFC documents themselves has started [RFC7990].
ゆっくりではありますが、変化はシリーズにもたらされます。まず、配布方法が郵便からFTPに変更され、次に電子メールに変更されることがわかりました。 RFCを最初に電子的に配布することはできませんでした。その配布を行う手段は、最初のRFCが「公開されて」から数年が経過するまで定義されなかったためです。初期のRFCがすべて電子的に作成されたわけでもありません。一部は手書きまたはタイプライターで書き出されました。最終的に、RFCを作成するプロセスはより構造化されました。著者には、RFCの記述方法に関するガイダンスが提供されました。編集作業は、スティーブクロッカーから指定編集者のジョンポステルのより公式なモデルに、さらには5〜7人のチームに行われました。プロトコルコードポイントの登録のためのサービスから分割された実際の編集および公開作業。 RFCエディタの構造全体がレビューされ[RFC4844]、洗練された[RFC5620]、そして再び洗練された[RFC6635]。そして、ここ数年の間に、RFC文書自体のフォーマットを変更するプロセスが始まりました[RFC7990]。
This is evolution; and the Series will continue to be adapted in order to meet the needs and expectations of the implementers, operators, historians, and community of authors that uses the RFC Series. These changes will always be balanced against the core mission of the Series: to maintain a strong, stable, archival record of technical specifications, protocols, and other information relevant to the Advanced Research Projects Agency Network (ARPANET) and Internet networking communities.
これは進化です。また、RFCシリーズを使用する実装者、オペレーター、歴史家、および作成者のコミュニティのニーズと期待に応えるために、シリーズは引き続き適応されます。これらの変更は、常にシリーズのコアミッションとバランスをとります。技術仕様、プロトコル、およびAdvanced Research Projects Agency Network（ARPANET）とインターネットネットワーキングコミュニティに関連するその他の情報の強力で安定したアーカイブレコードを維持することです。
There is more to the history of the RFC Series than can be covered in this document. Readers interested in earlier perspectives may find the following RFCs of particular interest. These RFCs focus on the enormous contributions of Jon Postel, Czar of Socket Numbers [RFC0433] and first RFC Editor:
RFCシリーズの歴史には、このドキュメントでカバーできる以上のものがあります。以前の視点に関心のある読者は、特に興味深い以下のRFCを見つけることができます。これらのRFCは、Jon Postel、Czar of Socket Numbers [RFC0433]、および最初のRFC Editorの多大な貢献に焦点を当てています。
* [RFC2441]"Working with Jon, Tribute delivered at UCLA, October 30, 1998"
* [RFC2441]「ジョンとの協力、トリビュートは1998年10月30日、UCLAで配信されました」
* [RFC2555]"30 Years of RFCs"
* [RFC2555]「RFCの30年」
* [RFC5540]"40 Years of RFCs"
* [RFC5540]「RFCの40年」
In this document, the history of the Series is viewed through the eyes of several individuals who have been a part of shaping it. Narratives of this nature offer a limited perspective on events; there are almost certainly other viewpoints, memories, and perspectives on events that are equally valid and would reflect a different history. So, while these retrospectives are enormously valuable and provide an insight to events of the day, they are just one lens on the history of the RFC Series.
このドキュメントでは、シリーズの歴史を、その形成に参加した数人の個人の目を通して見ています。この性質の物語は、イベントについて限られた視点を提供します。ほぼ確実に、等しく有効であり、異なる歴史を反映する、イベントに関する他の視点、記憶、および視点があります。したがって、これらの回顧は非常に貴重であり、その日の出来事に対する洞察を提供しますが、それらはRFCシリーズの歴史の1つのレンズにすぎません。
Steve Crocker, author of [RFC0001], offers his thoughts on how and why the Series began. Leslie Daigle, a major influence in the development of the RFC Editor model, offers her thoughts on the change of the RFC Editor to a stronger, contracted function. Nevil Brownlee, Independent Submissions Editor from 2010 through February 2018, shares his view on the clarification of the Independent Stream (IS) and its transition upon the retirement of Bob Braden from the position. As the current RFC Series Editor, I will put my thoughts in on the most recent changes in formalizing the digital preservation of the Series, the process to modernize the format while respecting the need for stability, and my thoughts on the next fifty years of RFCs.
[RFC0001]の作者であるスティーブクロッカーは、シリーズがどのように、そしてなぜ始まったのかについての考えを述べています。 RFC Editorモデルの開発に大きな影響を与えたLeslie Daigleは、RFC Editorをより強力で縮小された機能に変更することについての彼女の考えを提供しています。 2010年から2018年2月までの独立した投稿の編集者であるNevil Brownleeは、独立したストリーム（IS）の明確化と、そのポジションからのBob Bradenの退職後の移行についての彼の見解を共有しています。私は現在のRFCシリーズエディターとして、シリーズのデジタル保存の形式化における最新の変更点、安定性の必要性を尊重しながらフォーマットを近代化するプロセス、および今後50年間のRFCに関する私の考えを取り上げます。
This document updates the perspectives offered in [RFC2555] and [RFC5540].
このドキュメントは、[RFC2555]と[RFC5540]で提供されるパースペクティブを更新します。
+--------------------+----------+-----------------------------------+
| Marker | Date | Event |
+====================+==========+===================================+
| [RFC0001] | April | First RFC published |
| | 1969 | |
+--------------------+----------+-----------------------------------+
| [RFC0114] | April | First distribution of RFCs |
| | 1971 | over the network |
+--------------------+----------+-----------------------------------+
| [RFC0433] | December | First mention of the Czar of |
| | 1972 | Socket Numbers and the |
| | | proposal for a formal |
| | | registry |
+--------------------+----------+-----------------------------------+
| [RFC0690] | June | Relationship starts between |
| | 1975 | the Information Sciences |
| | | Institute (ISI) and the RFC |
| | | Editor (judging by Jon |
| | | Postel's affiliation change) |
+--------------------+----------+-----------------------------------+
| [RFC0748] | April | First April 1st RFC |
| | 1977 | published |
+--------------------+----------+-----------------------------------+
| [IETF1] | January | First Internet Engineering |
| | 1986 | Task Force (IETF) meeting |
+--------------------+----------+-----------------------------------+
| [IAB-19880712] | July | IAB approved the creation of |
| | 1988 | an Internet-Draft series |
+--------------------+----------+-----------------------------------+
| [RFC1122][RFC1123] | December | First major effort to review |
| | 1988 | key specifications and write |
| | | applicability statements |
+--------------------+----------+-----------------------------------+
| [RFC1083] | October | Three-stage standards |
| | 1989 | process first defined |
+--------------------+----------+-----------------------------------+
| [RFC1150] | March | FYI sub-series started |
| | 1990 | |
+--------------------+----------+-----------------------------------+
| [RFC1311] | March | STD sub-series started |
| | 1992 | |
+--------------------+----------+-----------------------------------+
| [RFC1818] | August | BCP sub-series started |
| | 1995 | |
+--------------------+----------+-----------------------------------+
| [RFC-ONLINE] | approx. | RFC Online Project to |
| | 1998 | restore early RFCs that were |
| | | "lost" started |
+--------------------+----------+-----------------------------------+
| [RFC2441] | 15 | Jon Postel's death |
| | October | |
| | 1998 | |
+--------------------+----------+-----------------------------------+
| [RFC4844] | July | RFC Series administrative |
| | 2007 | structure documented |
+--------------------+----------+-----------------------------------+
| [RFC4846] | July | Independent Submission |
| | 2007 | document stream is |
| | | formalized |
+--------------------+----------+-----------------------------------+
| [RFC5620] | August | RFC Editor organization |
| | 2009 | officially established as |
| | | RFC Series Editor, |
| | | Independent Submission |
| | | Editor, RFC Production |
| | | Center, and RFC Publisher |
+--------------------+----------+-----------------------------------+
| [ISI-to-AMS] | October | Transition of RFC Production |
| | 2009 | Center and RFC Publisher |
| | | starts from Information |
| | | Sciences Institute (ISI) to |
| | | Association Management |
| | | Solutions (AMS) |
+--------------------+----------+-----------------------------------+
| [RFC5540] | January | Bob Braden retires from RFC |
| | 2010 | Editor |
+--------------------+----------+-----------------------------------+
| [RFC5743] | December | Internet Research Task Force |
| | 2009 | document stream formalized |
+--------------------+----------+-----------------------------------+
| [RFC-ONLINE] | approx. | RFC Online Project to |
| | 2010 | restore early RFCs that were |
| | | "lost" finished |
+--------------------+----------+-----------------------------------+
| [RFC6360] | August | FYI sub-series ended |
| | 2011 | |
+--------------------+----------+-----------------------------------+
| [RFC6410] | October | Two-stage standards process |
| | 2011 | formalized |
+--------------------+----------+-----------------------------------+
| [RFC6635] | June | Updated responsibilities of |
| | 2012 | RFC Series allocated to RFC |
| | | Series Editor, RFC |
| | | Production Center, and RFC |
| | | Publisher |
+--------------------+----------+-----------------------------------+
| [RFC6949] | May 2013 | RFC format change project |
| | | started |
+--------------------+----------+-----------------------------------+
| [RFC8153] | April | RFCs no longer printed to |
| | 2017 | paper upon publication |
+--------------------+----------+-----------------------------------+
Table 1: Key Moments in RFC History
表1：RFC履歴の主要な瞬間
(This is a revision of material included more than 30 years ago in [RFC1000].)
（これは30年以上前に[RFC1000]に含まれていた資料の改訂版です。）
The Internet community now includes millions of nodes and billions of users. It owes its beginning to the ARPANET, which was once but a gleam in the eyes of J. C. R. Licklider, Bob Taylor, and Larry Roberts of the Advanced Research Projects Agency (ARPA). While much of the development proceeded according to plan, the initial design of the protocols and the creation of the RFCs was largely accidental.
現在、インターネットコミュニティには数百万のノードと数十億のユーザーが含まれています。それは、ARPANETに始まりました。これはかつてJ. C. R. Licklider、Bob Taylor、およびAdvanced Research Projects Agency（ARPA）のLarry Robertsの目には輝いていました。開発の大部分は計画どおりに進行しましたが、プロトコルの初期設計とRFCの作成はほとんど偶然でした。
The procurement of the ARPANET was initiated in the summer of 1968; remember Vietnam, flower children, etc.? There had been prior experiments at various ARPA sites to link together computer systems, but this was the first version to explore packet switching as a core part of the communication strategy. ("ARPA" didn't become "DARPA" (Defense Advanced Research Projects Agency) until 1972. It briefly changed back to ARPA in 1993 and then back again to DARPA.) The government's Request for Quotations (RFQ) called for four packet-switching devices, called Interface Message Processors ("IMPs"), to be delivered to four sites in the western part of the United States: University of California, Los Angeles (UCLA); SRI International (Stanford Research Institute) in Menlo Park, CA; University of California, Santa Barbara (UCSB); and the University of Utah in Salt Lake City. These sites were running a Scientific Data Systems (SDS) Sigma 7, an SDS 940, an IBM 360/75, and a DEC PDP-10, respectively. These machines not only had different operating systems, but even details like character sets and byte sizes varied. Other sites would have further variations.
ARPANETの調達は1968年の夏に開始されました。ベトナム、フラワーチルドレンなどを覚えていますか？さまざまなARPAサイトで以前にコンピュータシステムをリンクする実験が行われていましたが、これは通信戦略の中核としてパケットスイッチングを調査した最初のバージョンでした。 （「ARPA」は1972年まで「DARPA」（国防高等研究計画局）になりませんでした。1993年に簡単にARPAに戻り、その後再びDARPAに戻りました。）政府の見積依頼（RFQ）は4パケットを要求しました。インターフェースメッセージプロセッサ（「IMP」）と呼ばれるスイッチングデバイス。米国西部の4つのサイトに配信されます。カリフォルニア大学ロサンゼルス校（UCLA）。カリフォルニア州メンロパークにあるSRIインターナショナル（スタンフォード研究所）。カリフォルニア大学サンタバーバラ校（UCSB）;ソルトレイクシティのユタ大学。これらのサイトは、それぞれScientific Data Systems（SDS）Sigma 7、SDS 940、IBM 360/75、およびDEC PDP-10を実行していました。これらのマシンでは、オペレーティングシステムが異なるだけでなく、文字セットやバイトサイズなどの詳細もさまざまでした。他のサイトにはさらにバリエーションがあります。
The focus was on the basic movement of data. The precise use of the ARPANET was not spelled out in advance, thus requiring the research community to take some initiative. To stimulate this process, a meeting was called in August 1968 with representatives from the selected sites, chaired by Elmer Shapiro from SRI. Based on Shapiro's notes from that meeting, the attendees were Dave Hopper and Jeff Rulifson from SRI; Glen Culler and Gordon Buck from Santa Barbara; R. Stephenson, C. Stephen Carr, and W. Boam from Utah; Vint Cerf and me from UCLA; and a few others from potential future sites.
焦点はデータの基本的な動きにありました。 ARPANETの正確な使用法は事前に明記されていなかったため、研究コミュニティが主導権を握る必要がありました。このプロセスを刺激するために、SRIのElmer Shapiroが議長を務める選定されたサイトの代表者との会議が1968年8月に召集されました。その会議からのShapiroのメモに基づいて、出席者はSRIのDave HopperとJeff Rulifsonでした。サンタバーバラ出身のGlen CullerとGordon Buck。ユタ州出身のR.スティーブンソン、C。スティーブンカー、W。ボアム。ヴィント・サーフとUCLAの私。潜在的な将来のサイトからのいくつかの他のもの。
That first meeting was seminal. We had lots of questions. How would IMPs and "hosts" (I think that was the first time I was exposed to that term) be connected? What would hosts say to each other? What applications would be supported? The only concrete answers were remote login as a replacement for dial-up, telephone-based interactive terminal access, and file transfer, but we knew the vision had to be larger. We found ourselves imagining all kinds of possibilities: interactive graphics, cooperating processes, automatic database query, electronic mail, etc., but no one knew where to begin. We weren't sure whether there was really room to think hard about these problems; surely someone senior and in charge, likely from the East, would be along by and by to bring the word. But we did come to one conclusion: we ought to meet again. Over the next several months, we met at each of our sites, thereby setting the precedent for regular face-to-face meetings. We also instantly felt the irony. This new network was supposed to make it possible to work together at a distance, and the first thing we did was schedule a significant amount of travel.
その最初の会議は独創的でした。多くの質問がありました。 IMPと「ホスト」（その用語に出会ったのはこれが初めてだったと思います）はどのように関連付けられますか？ホストはお互いに何を言うでしょうか？どのようなアプリケーションがサポートされますか？唯一の具体的な答えは、ダイヤルアップ、電話ベースのインタラクティブなターミナルアクセス、およびファイル転送の代わりとしてのリモートログインでしたが、ビジョンをより大きくする必要があることはわかっていました。インタラクティブなグラフィックス、連携プロセス、自動データベースクエリ、電子メールなど、あらゆる可能性を想像していましたが、どこから始めればよいか誰も知りませんでした。これらの問題について真剣に考える余地があるかどうかはわかりませんでした。きっと東から来たと思われる先輩と責任者が、そばにいて、その言葉を伝えに来るでしょう。しかし、私たちは1つの結論に達しました。もう一度会うべきです。次の数か月間で、私たちは各サイトで会合を持ち、それによって定期的な対面式会議の先例を築きました。皮肉にも瞬時に感じました。この新しいネットワークは、離れた場所での共同作業を可能にするはずでした。最初に行ったのは、かなりの量の旅行をスケジュールすることでした。
Over the next several months, a small, fairly consistent set of graduate students and staff members from the first four sites met. We used the term Network Working Group (NWG) to designate ourselves. This was the same term Elmer Shapiro had used when he convened our first meeting, although it had been used until that point to refer to the principal investigators and ARPA personnel: senior people who had been planning the network. Our group was junior and disjointed from the prior group, except, of course, that each of us worked for one of the principal investigators.
次の数か月間で、最初の4つのサイトの大学院生とスタッフメンバーの小規模でかなり一貫したセットが集まりました。私たちは、ネットワークワーキンググループ（NWG）という用語を使用して自分自身を指定しました。これは、エルマーシャピロが最初の会議を招集したときに使用した用語と同じでしたが、それまでは主任研究者とARPA担当者、つまりネットワークを計画していた高齢者に言及するために使用されていました。私たちのグループはジュニアであり、前のグループから切り離されていました。
The first few meetings were quite tenuous, primarily because we weren't sure how narrow or expansive our goals should be. We had no official charter or leadership, and it remained unclear, at least to me, whether someone or some group would show up with the official authority and responsibility to take over the problems we were dealing with. Without clear definition of what the host-IMP interface would look like, or even a precise definition of what functions the IMP would provide, we focused on broader ideas. We envisioned the possibility of application-specific protocols, with code downloaded to user sites, and we took a crack at designing a language to support this. The first version was known as DEL, for "Decode-Encode Language" and a later version was called NIL, for "Network Interchange Language".
最初の数回のミーティングは非常に微妙でした。これは主に、目標がどれほど狭いか、または広範であるかがわからなかったためです。私たちには公式な憲章やリーダーシップはありませんでした。少なくとも私にとっては、誰かが、あるいは当局が、私たちが扱っていた問題を引き継ぐための公式の権限と責任を持って現れるかどうかは、はっきりしていません。 host-IMPインターフェースがどのように見えるかを明確に定義することも、IMPが提供する機能を正確に定義することもせずに、より広範なアイデアに焦点を当てました。ユーザーサイトにコードをダウンロードして、アプリケーション固有のプロトコルの可能性を想定し、これをサポートする言語の設計に一歩踏み込みました。最初のバージョンは「Decode-Encode Language」の略でDELと呼ばれ、それ以降のバージョンは「Network Interchange Language」の略でNILと呼ばれていました。
In late 1968, Bolt Beranek and Newman (BBN) in Cambridge, MA won the contract for the IMPs and began work in January 1969. A few of us flew to Boston in the middle of February to meet the BBN crew. The BBN folks, led by Frank Heart, included Bob Kahn, Severo Ornstein, Ben Barker, Will Crowther, Bernie Cosell, and Dave Walden. They were organized, professional, and focused. Their first concern was how to meet their contract schedule of delivering the first IMP to UCLA at the beginning of September and how to get bits to flow quickly and reliably. The details of the host-IMP interface were not yet firm; the specification came a few months later as BBN Report 1822. In particular, BBN didn't take over our protocol design process, nor did any other source of authority appear. Thus, we doggedly continued debating and designing the protocols.
1968年後半、マサチューセッツ州ケンブリッジのボルトベラネックアンドニューマン（BBN）はIMPの契約を獲得し、1969年1月に作業を開始しました。フランク・ハートが率いるBBNの人々は、ボブ・カーン、セベロ・オーンシュタイン、ベン・バーカー、ウィル・クロウザー、バーニー・コーセル、そしてデイブ・ウォルデンを含みました。彼らは組織化され、専門的で、焦点を絞っていました。彼らの最初の関心事は、9月の初めに最初のIMPをUCLAに配信するという契約スケジュールをどのように満たすか、そしてビットを迅速かつ確実にフローさせる方法でした。 host-IMPインターフェースの詳細はまだ確定されていません。その仕様は、数か月後にBBNレポート1822として登場しました。特に、BBNはプロトコル設計プロセスを引き継いだわけではなく、他のいかなる権限の源泉も現れませんでした。したがって、私たちはプロトコルの議論と設計を根気よく続けました。
A month later, our small NWG met in Utah. As the meeting came toward an end, it became clear to us that we should start writing down our discussions. We had accumulated a few notes on the design of DEL and other matters, and we decided to put them together in a set of notes. We assigned writing chores to each of us, and I took on the additional task of organizing the notes. Though I initiated the RFCs, my role was far less than an editor. Each of the RFCs were numbered in sequence. The only rule I imposed was the note had to be complete before I assigned a number because I wanted to minimize the number of holes in the sequence.
1か月後、私たちの小さなNWGはユタ州で会合しました。会議が終わりに近づくにつれ、議論を書き留める必要があることが明らかになりました。 DELのデザインやその他の事項についていくつかのメモを蓄積していたので、それらを1組のメモにまとめることにしました。私たちは私たち一人一人に筆記用の雑用を割り当て、私はメモを整理する追加のタスクを引き受けました。私はRFCを開始しましたが、私の役割は編集者よりはるかに少なかったです。各RFCには順番に番号が付けられました。私が課した唯一のルールは、シーケンスの穴の数を最小限にしたかったので、番号を割り当てる前にメモを完成させる必要があるということでした。
I tried a couple of times to write a note on how the notes would be organized, but I found myself full of trepidation. Would these notes look as if we were asserting authority we didn't have? Would we unintentionally offend whomever the official protocol designers were? Finally, unable to sleep, I wrote a few humble words. The basic ground rules were that anyone could say anything and that nothing was official. And to emphasize the point, I used Bill Duvall's suggestion and labeled the notes "Request for Comments". I never dreamed these notes would eventually be distributed through the very medium we were discussing in these notes: talk about Sorcerer's Apprentice! (See [APPRENTICE].)
私は数回メモを整理する方法についてメモを書くことを試みましたが、私は不安に満ちていました。これらのメモは、私たちが持っていない権限を主張しているかのように見えますか？公式のプロトコル設計者が誰であろうと、私たちは意図せずに気分を害しますか？最後に、眠ることができなかったので、いくつかの謙虚な言葉を書きました。基本的な基本ルールは、誰でも何でも言うことができ、何も公式ではないということでした。そして要点を強調するために、私はビルデュバルの提案を使用し、メモに「Request for Comments」というラベルを付けました。これらのノートが、私たちがこれらのノートで議論しているまさにその媒体を通して配布されるとは夢にも思わなかった：魔術師の弟子について話せ！ （[APPRENTICE]を参照してください。）
After BBN distributed the specification for the IMP hardware and software interface to the initial ARPANET sites, our attention shifted to low-level matters. The ambitious ideas for automatic downloading of code evaporated. It would be several years before ideas like mobile code, remote procedure calls, ActiveX, JAVA, and Representational State Transfer (RESTful) interfaces appeared.
BBNがIMPハードウェアおよびソフトウェアインターフェイスの仕様を最初のARPANETサイトに配布した後、私たちの関心は低レベルの問題に移りました。コードの自動ダウンロードの野心的なアイデアは消え去りました。モバイルコード、リモートプロシージャコール、ActiveX、JAVA、Representational State Transfer（RESTful）インターフェイスなどのアイデアが登場するまでには数年かかります。
Over the spring and summer of that year, we grappled with the detailed problems of protocol design. Although we had a vision of the vast potential for intercomputer communication, designing usable protocols was another matter. We knew a custom hardware interface and a custom software addition in the operating system was going to be required for anything we designed, and we anticipated these would pose some difficulty at each of the sites. We looked for existing abstractions to use. It would have been convenient if we could have made the network simply look like a regular device, e.g., a tape drive, but we knew that wouldn't do. The essence of this network was peer-to-peer cooperation among the machines and the processes running inside them, not a central machine controlling dependent devices. We settled on a virtual bit stream layer as the basic building block for the protocols; but even back then, we knew that some applications like voice might need to avoid that layer of software. (Why a virtual bit stream instead of a virtual byte stream? Because each computer had its own notion of how many bits were in a byte. 8-bit bytes didn't become standard until a few years later.)
その年の春から夏にかけて、プロトコル設計の詳細な問題に取り組みました。コンピュータ間の通信には大きな可能性があるというビジョンがありましたが、使用可能なプロトコルの設計も別の問題でした。私たちは、カスタムハードウェアインターフェイスとオペレーティングシステムへのカスタムソフトウェアの追加が私たちが設計したものすべてに必要になることを知っていて、これらは各サイトでいくつかの困難をもたらすと予想しました。使用する既存の抽象化を探しました。ネットワークを通常のデバイス（テープドライブなど）のように見せることができれば便利でしたが、それができないことはわかっていました。このネットワークの本質は、依存関係にあるデバイスを制御する中央のマシンではなく、マシンとその内部で実行されているプロセス間のピアツーピアの連携でした。プロトコルの基本的なビルディングブロックとして、仮想ビットストリームレイヤーを選択しました。しかし、当時のように、音声などの一部のアプリケーションでは、そのソフトウェアレイヤーを回避する必要がある場合があることはわかっていました。 （なぜ、仮想バイトストリームではなく仮想ビットストリームなのですか？各コンピュータには、1バイトに含まれるビット数について独自の概念があるためです。8ビットバイトは、数年後まで標準になりませんでした。）
Over the next two years, we developed, exchanged, and implemented ideas. I took a leave from UCLA in June 1971 to spend time working at ARPA. Jon Postel took over the care and feeding of the RFCs, evolving the process and adding collaborators over the next twenty-seven years.
次の2年間で、アイデアを開発、交換、および実装しました。 1971年6月にUCLAを休んで、ARPAでの勤務に時間を費やしました。 Jon PostelはRFCの管理と提供を引き継ぎ、プロセスを進化させ、今後27年間で共同編集者を追加しました。
The rapid growth of the network and the working group also led to a large pile of RFCs. When the 100th RFC was in sight, Peggy Karp at the MIT Research Establishment (MITRE) took on the task of indexing them. That seemed like a large task then, and we could have hardly anticipated seeing more than 1000 RFCs several years later and the evolution toward Internet-Drafts yet later.
ネットワークとワーキンググループの急速な成長により、RFCの山も大きくなりました。 100番目のRFCが見えたとき、MIT Research Establishment（MITRE）のPeggy Karpがそれらのインデックス作成を担当しました。それはそのとき大きな仕事のように思われ、数年後に1000を超えるRFCが見られ、インターネットドラフトへの進化がさらに遅くなることはほとんど予想できませんでした。
When we first started working on the protocols, the network did not exist. Except for our occasional face-to-face meetings, RFCs were our only means of communication. In [RFC0003], I set the bar as low as possible:
最初にプロトコルの作業を始めたとき、ネットワークは存在していませんでした。臨時の面談を除いて、RFCは唯一のコミュニケーション手段でした。 [RFC0003]では、バーを可能な限り低く設定しました。
| The content of a NWG note may be any thought, suggestion, etc.
| related to the HOST software or other aspect of the network.
| Notes are encouraged to be timely rather than polished.
| Philosophical positions without examples or other specifics,
| specific suggestions or implementation techniques without
| introductory or background explication, and explicit questions
| without any attempted answers are all acceptable. The minimum
| length for a NWG note is one sentence.
|
| These standards (or lack of them) are stated explicitly for two
| reasons. First, there is a tendency to view a written
| statement as ipso facto authoritative, and we hope to promote
| the exchange and discussion of considerably less than
| authoritative ideas. Second, there is a natural hesitancy to
| publish something unpolished, and we hope to ease this
| inhibition.
Making the RFCs informal was not only a way of encouraging participation; it was also important in making the communication effective. One of the early participants said he was having trouble writing and sending an RFC because his institution wanted to subject them to publication review. These are not "publications", I declared, and the problem went away. Another small detail, handled instinctively and without debate, was the distribution model. Each institution was required to send a copy directly to each of the other handful of participating institutions. Each institution handled internal copies and distribution itself. Submission to a central point for redistribution was not required so as to minimize delays. SRI's Network Information Center, however, did maintain a central repository of everything and provided an invaluable record.
RFCを非公式にすることは、参加を促すだけの方法ではありませんでした。コミュニケーションを効果的にすることも重要でした。初期の参加者の1人は、RFCの作成と送信に問題があったと語っています。彼の機関は、RFCに公開レビューを依頼したかったからです。これらは「出版物」ではないと私は宣言し、問題はなくなりました。直感的にそして議論なしに扱われたもう1つの小さな詳細は、分散モデルでした。各機関は、コピーを他の少数の参加機関のそれぞれに直接送信する必要がありました。各機関は内部のコピーと配布自体を処理しました。遅延を最小限に抑えるために、再配布のための中央ポイントへの提出は必要ありませんでした。しかし、SRIのネットワークインフォメーションセンターは、すべての中央リポジトリを維持し、非常に貴重な記録を提供しました。
We didn't intentionally set out to challenge the existing standards organizations, but our natural mode of operation yielded some striking results. The RFCs are open in two important respects: anyone can write one for free and anyone can get them for free. At the time, virtually everyone in the ARPANET community was sponsored by the government, so there was little competition and no need to use documents as a way of raising money. Of course, as soon as we had email working on the ARPANET, we distributed RFCs electronically. When the ARPANET became just a portion of the Internet, this distribution process became worldwide. The effect of this openness is often overlooked; even now, students and young professionals all over the world have been able to download RFCs, learn about the technology within, and in turn, build the most amazing software. (They are also a fantastic resource for historians.)
私たちは、既存の標準化団体に意図的に挑戦することを意図していませんでしたが、私たちの自然な運用方法は、いくつかの印象的な結果をもたらしました。 RFCは2つの重要な点でオープンです。誰でも無料で作成でき、誰でも無料で入手できます。当時、ARPANETコミュニティのほぼ全員が政府の支援を受けていたため、競争はほとんどなく、資金調達の手段として文書を使用する必要はありませんでした。もちろん、電子メールがARPANETで機能するようになり次第、RFCを電子的に配布しました。 ARPANETがインターネットの一部になったとき、この配布プロセスは世界中に広まりました。この開放性の影響は見過ごされがちです。今でも、世界中の学生や若い専門家がRFCをダウンロードし、内部のテクノロジーについて学び、そして最も素晴らしいソフトウェアを構築することができました。 （これらは歴史家にとっても素晴らしいリソースです。）
Where will it end? The ARPANET begat the Internet, and the underlying technology transitioned from the original host-host protocol to TCP/IP. But, the superstructure of protocol layers, community-driven protocol design, and RFCs continued. Through the changes in physical-layer technology, resulting in speed increases from thousands to billions of bits per second, and similarly from thousands to billions of users, this superstructure, including the RFCs, has continued to serve the community. All of the computers have changed, as have all of the transmission lines, but the RFCs march on. Maybe I'll write a few words for RFC 10,000.
それはどこで終わりますか？ ARPANETはインターネットを生み、基盤となるテクノロジーは元のホスト-ホストプロトコルからTCP / IPに移行しました。しかし、プロトコル層の上部構造、コミュニティ主導のプロトコル設計、およびRFCは継続しました。物理層テクノロジーの変化により、毎秒数千から数十億ビット、そして数千から数十億のユーザーにスピードが向上することにより、RFCを含むこの上部構造は、コミュニティに貢献し続けています。すべてのコンピュータが変更され、すべての伝送ラインも変更されましたが、RFCは前進しています。たぶん、RFC 10,000について少し説明します。
Quite obviously, the circumstances have changed. Email and other media are most often used for the immediate exchange of inchoate thoughts. Internet-Drafts are the means for exchanging substantial, albeit sometimes speculative, content, while RFCs are reserved for fully polished, reviewed, edited, and approved specifications. Comments to RFCs are not requested, although usage-related discussions and other commentary on mailing lists often take place nonetheless. Rather than bemoan the change, I take it as a remarkable example of adaptation. RFCs continue to serve the protocol development community. Indeed, they are the bedrock of a very vibrant and productive process that has fueled and guided the Internet revolution.
明らかに、状況は変わりました。電子メールやその他のメディアは、細心の注意をすぐに交換するために最もよく使用されます。 RFCは完全に洗練され、レビューされ、編集され、承認された仕様のために予約されていますが、インターネットドラフトは、時には投機的ではありますが、実質的なコンテンツを交換するための手段です。 RFCへのコメントは要求されませんが、それでも、メーリングリストに関する使用法関連のディスカッションやその他のコメントは頻繁に行われます。私は変化を嘆くのではなく、それを適応の顕著な例と考えています。 RFCは引き続きプロトコル開発コミュニティに貢献しています。確かに、それらはインターネット革命を促進し、導いてきた非常に活気に満ちた生産的なプロセスの基盤です。
As Steve Crocker mentions in Section 3.1, Jon Postel assumed the role of RFC manager in 1971 when Steve left UCLA for ARPA. Jon took on this role in addition to his subsequent "numbers Czar" responsibilities. Initially, his focus was largely on assigning RFC numbers to aspiring writers, but with time, and as the standardization of the ARPANET and Internet protocols continued apace, he began to serve in an editorial capacity. Moreover, as an accomplished software engineer, he had opinions about technical content in addition to writing style and did not hesitate to exercise editorial discretion as would-be published authors presented their offerings for his scrutiny. As the load increased, he recruited additional "volunteer" talent, most notably Joyce K. Reynolds, a fellow researcher at USC/ISI. Over the ensuing years, he also drafted Robert (Bob) Braden onto the team, and when Jon unexpectedly passed away in October 1998 (see [RFC2468]), Joyce and Bob undertook carrying on with the RFC work in his stead, adding Sandy Ginoza to the team. During the period when Jon and Joyce worked closely together, Joyce would challenge me to tell which edits had been made by Jon and which by her. I found this impossible, so aligned were they in their editorial sensibilities. Sadly, three of these tireless Internauts have passed on, and we have only the product of their joint work and Sandy Ginoza's and others' corporate memory by which to recall history.
Steve Crockerがセクション3.1で言及しているように、ジョンポステルは、スティーブがARPAのためにUCLAを去った1971年にRFCマネージャーの役割を引き受けました。ジョンは、その後の「ナンバーツァー」の責任に加えて、この役割を引き受けました。当初、彼の焦点は主に意欲的な作家にRFC番号を割り当てることでしたが、時間の経過とともに、ARPANETとインターネットプロトコルの標準化が急速に進むにつれて、彼は編集者としての役割を果たすようになりました。さらに、熟練したソフトウェアエンジニアとして、執筆スタイルに加えて技術的な内容についての意見もあり、出版される著者が彼の精査のために提供物を提示したため、編集の裁量権を行使することを躊躇しませんでした。負荷が増加するにつれて、彼は追加の「ボランティア」才能、特にUSC / ISIの仲間の研究者であるジョイスK.レイノルズを募集しました。その後数年間、ロバート（ボブ）ブレーデンをチームに起草し、ジョンが1998年10月に突然亡くなったとき（[RFC2468]を参照）、ジョイスとボブは代わりにサンディギノザを追加してRFC作業を引き受けました。チームに。ジョンとジョイスが緊密に協力していた期間中、ジョイスは私に、どの編集がジョンによって行われ、どの編集が彼女によって行われたかを知るように要求しました。私はこれが不可能だと思ったので、彼らの編集感度が一致していました。悲しいことに、これらの疲れのない3人の宇宙飛行士が亡くなり、私たちは彼らの共同作業の成果と、歴史を思い出すためのサンディジーノザや他の企業の記憶だけを持っています。
I was the chair of the Internet Architecture Board, the board responsible for the general oversight of the RFC Series, at a particular inflection point in the evolution of all Internet technology institutions. To understand what we did, and why we had to, let me first paint a broader picture of the arc of these institutions.
私は、すべてのインターネット技術機関の進化における特定の変曲点で、RFCシリーズの全般的な監督を担当するインターネットアーキテクチャボードの議長を務めました。私たちが何をし、なぜしなければならないのかを理解するために、最初にこれらの機関の弧のより広い絵を描きましょう。
Like many others who were in decision-making roles in the mid '00s, I wasn't present when the Internet was born. The lore passed down to me was that, out of the group of talented researchers that developed the core specifications and established the direction of the Internet, different individuals stepped up to take on roles necessary to keep the process of specification development organized and open. As the work of specification expanded, those individuals were generally supported by organizations that carried on in the same spirit. This was mostly Jon Postel, managing the allocation and assignment of names and numbers, as well as working as the editor of RFCs, but there were also individuals and institutions supporting the IETF's Secretariat function. By the late 20th century, even this model was wearing thin; the support functions were growing, and organizations didn't have the ability to donate even more resources to run them. In some cases (IANA), there was significant industry and international dependence on the function and its neutrality.
00年代半ばに意思決定の役割を担っていた他の多くの人々と同様に、インターネットが生まれたときも私はその場にいませんでした。私に伝えられた伝承は、コア仕様を開発し、インターネットの方向性を確立した才能のある研究者のグループから、仕様開発のプロセスを体系化し、オープンに保つために必要な役割を引き受けるためにさまざまな個人がステップアップしたということでした。仕様の仕事が拡大するにつれ、それらの個人は一般に、同じ精神で引き継がれた組織によってサポートされました。これは主にジョン・ポステルで、名前と番号の割り当てと割り当てを管理し、RFCの編集者として働いていましたが、IETFの事務局機能をサポートする個人や機関もありました。 20世紀後半までに、このモデルでさえ薄く着ていました。サポート機能は増大しており、組織はそれを実行するためにさらに多くのリソースを寄付することができませんでした。場合によっては（IANA）、機能とその中立性への業界と国際的な依存が大きかった。
The IETF, too, had grown in size, stature, and commercial reliance. This system of institutional pieces "flying in formation" was not providing the kind of contractual regularity or integrated development that the IETF needed. People who hadn't been there as the institutions developed, including IETF decision makers, didn't innately understand why things "had to be the way they were" and were frustrated when trying to get individual systems updated for new requirements as well as better integrated across the spectrum of activities.
IETFも、サイズ、身長、および商業的依存度が高まっていました。この制度的要素の「形成」は、IETFが必要とするような契約上の規則性や統合開発を提供していませんでした。 IETFの意思決定者を含め、教育機関が開発したときにそこにいなかった人々は、なぜ「本来の姿」でなければならなかったのかを本質的に理解していなかったため、個々のシステムを新しい要件に合わせて更新しようとしても不満を感じていました。活動のスペクトル全体に統合されています。
Internet engineering had expanded beyond the point of being supportable by a loosely coupled set of organizations of people who had been there since the beginning and knew each other well. New forms of governance were needed along with a rationalized funding model. The IANA function was absorbed into a purpose-built international not-for-profit organization. The IETF stepped up to manage its own organizational destiny, creating the IETF Administrative Support Activity (IASA), and the Secretariat became one of its contracted functions.
インターネットエンジニアリングは、最初からそこにいて、お互いをよく知っていた疎結合の一連の人々によってサポートされるという点を超えて拡大していました。合理化された資金調達モデルとともに、新しい形態のガバナンスが必要でした。 IANA機能は、専用の国際非営利組織に吸収されました。 IETFは独自の組織の運命を管理するためにステップアップし、IETF管理サポート活動（IASA）を作成し、事務局はその契約された機能の1つになりました。
This left the RFC Editor function as an independent effort supported by the Internet Society.
これにより、RFCエディタ機能は、インターネットソサエティによってサポートされる独立した取り組みとして残されました。
That independent nature was necessary for the historic role of the RFC Series in considering all technical contributions. But, at that inflection point in the Series' history, it needed a new governance and funding model, just as the other organizations supporting Internet technical specification had. Also, the IETF leadership had some concerns it felt needed to be addressed in its own technical publication stream. While the RFC Series had been established before there was an IETF, and had historically continued to have documents in it that didn't originate from the IETF, the IETF was its largest and most organized contributor. There was no particular organization of independent contributors. Equally, the funding for the RFC Editor was at that point coming from the Internet Society in the guise of "support for the IETF". For people who hadn't been involved with the institution from the outset, it was pretty easy to perceive the RFC Series uniquely as the IETF's publication series. So, the challenge was to identify and address the IETF's issues, along with governance and funding, without sacrificing the fundamental nature of the RFC Series as a broader-than-IETF publication series.
その独立した性質は、すべての技術的貢献を検討する際のRFCシリーズの歴史的な役割に必要でした。しかし、シリーズの歴史におけるその変曲点では、インターネットの技術仕様をサポートする他の組織と同じように、新しいガバナンスと資金調達モデルが必要でした。また、IETFのリーダーシップには、独自のテクニカルパブリケーションストリームで対処する必要があると思われる懸念がありました。 RFCシリーズはIETFが登場する前に確立され、歴史的にIETFに由来しないドキュメントが含まれ続けていましたが、IETFはその最大かつ最も組織化された寄稿者でした。独立した貢献者の特別な組織はありませんでした。同様に、RFCエディターへの資金提供は、その時点で「IETFのサポート」を装ってインターネットソサエティから提供されていました。最初から機関に関与していない人にとって、RFCシリーズをIETFの出版シリーズとして独自に認識することは非常に簡単でした。したがって、課題は、RFCシリーズの基本的な性質をIETFよりも広い公開シリーズとして犠牲にすることなく、ガバナンスと資金調達とともにIETFの問題を特定して対処することでした。
To give a sense of the kind of tensions that were prevalent, let me share that the one phrase that stuck in my mind from those discussions was "push to publish". There were those in IETF leadership who felt that it would significantly reduce costs and improve timeliness if an RFC could be published by, literally, pushing a button on a web interface the moment it was approved by the IESG. It would also, they argued, remove the specification issues being introduced by copy editors that were hired as occasional workers to help with improving publication rates but who weren't necessarily up to speed on terms of art in technical specifications. (There were some pretty egregious examples of copy editors introducing changes that significantly changed the technical meaning of the text that I forbear from citing here; let's just say it wasn't strictly a problem of Internet engineers getting uptight about their cheese being moved.) While "push to publish" would have addressed those issues, it would not have addressed the loss of clarity from the many significant text improvements copy editors successfully introduced, or the fact that not all RFCs are approved by the IESG.
ある種の緊張を感じさせるために、それらの議論から私の心に残った1つのフレーズが「プッシュして公開する」であったことを共有しましょう。 IESGによって承認された瞬間にWebインターフェイスのボタンを押すことでRFCを文字どおりに発行できれば、大幅にコストを削減し、適時性を向上できるとIETFのリーダーシップの人々がいました。彼らはまた、出版率の向上を手伝うために臨時の労働者として雇われたが、技術仕様の技術の点で必ずしもスピードアップしていなかったコピー編集者によって導入された仕様の問題を取り除くと主張しました。 （私がここで引用することから差し控えたテキストの技術的意味を大幅に変更した変更を導入したコピーエディターのかなり悪質な例がいくつかありました。ただ、インターネットエンジニアがチーズの移動について緊張していることは厳密には問題ではなかったとしましょう。） 「プッシュトゥパブリッシュ」はこれらの問題に対処しますが、コピーエディターが成功裏に導入した多くの重要なテキストの改善による明確さの損失、またはすべてのRFCがIESGによって承認されているわけではないという事実には対処しませんでした。
Institutionally, it was clear that the target was to have the RFC Editor function governance within the reach of the Internet technical community (as opposed to any particular private organization) without tying it specifically to the IETF. That was reasonably achievable by ensuring that the resultant pieces were established under the oversight of the IAB (which is, itself, independent of the IETF even as it is supported by the IASA organization).
制度的には、IETFに特に結び付けることなく、（特定の民間組織ではなく）インターネット技術コミュニティの範囲内でRFCエディター機能のガバナンスを実現することが目標であることが明確でした。これは、結果の作品がIABの監督下で確立されたことを確認することによって合理的に達成可能でした（つまり、IASA組織によってサポートされているにもかかわらず、IETFから独立しています）。
The IETF worked on a document outlining functional requirements for its technical specification publication. This could have been useful for establishing its own series, but it also was helpful in establishing awareness of the challenges in document publishing (it always looks easy when you haven't thought about it) and also in laying the groundwork for dialogue with the RFC Editor. The requirements document was published as [RFC4714] as an Informational RFC that stands today to provide guidance in the editing processes surrounding IETF publications.
IETFは、技術仕様書発行の機能要件を概説する文書に取り組みました。これは独自のシリーズを確立するのに役立ちましたが、ドキュメント発行における課題の認識を確立するのにも役立ちました（それについて考えていなかった場合は常に簡単に見えます）、またRFCとの対話の基礎を築くのにも役立ちました。編集者。要件ドキュメントは、IETF出版物を取り巻く編集プロセスのガイダンスを提供するために今日立っている情報RFCとして[RFC4714]として公開されました。
There was still, however, a certain lack of clarity about responsibilities for making decisions and changes in the RFC Series itself. To that end, I and the IAB worked with the various involved parties to produce [RFC4844]. That document captured the RFC Series mission (for a purpose greater than IETF technical specification publication) as well as the roles and responsibilities of the parties involved. The RFC Editor is responsible for ensuring the implementation of the mission. The IAB continues to have oversight responsibilities, including policy oversight, which it could act on by changing the person (organization) in the role of RFC Editor. At the same time, operational oversight was migrated to the IASA support function of the IETF (and IAB).
ただし、RFCシリーズ自体の決定と変更を行う責任については、まだ明確さが欠けていました。そのために、私とIABはさまざまな関係者と協力して[RFC4844]を作成しました。その文書には、RFCシリーズの使命（IETF技術仕様の発行よりも大きな目的）と、関係者の役割と責任が含まれています。 RFCエディターは、ミッションの実装を確実にする責任があります。 IABには、ポリシーの監視を含む監視の責任があり、RFCエディターの役割で人（組織）を変更することにより、IABはそれに対処できます。同時に、運用監視はIETF（およびIAB）のIASAサポート機能に移行されました。
The discussions, and the resulting publication of [RFC4844], allowed greater visibility into and commitment to the RFC Series as a general Internet publication. It also meant that subsequent adjustments could be made as requirements evolved; the responsible parties are clearly identified.
[RFC4844]の議論とその結果の出版物は、一般的なインターネット出版物としてのRFCシリーズへのより大きな可視性とコミットメントを可能にしました。また、要件が進化するにつれて、その後の調整を行うことができることも意味しました。責任者は明確に識別されます。
Arguably starting in 2006 with [RFC4714], the IAB and the IETF community spent some time in the mid-'00s evolving the structure of the RFC Series. This work included defining how those groups that published into the RFC Series (initially including the IETF, the IAB [RFC4845], and the Independent Submissions Stream [RFC4846], and later growing to include the IRTF [RFC5743]) would handle approving documents to be published as RFCs. In 2009, the IAB published "RFC Editor Model (Version 1)" [RFC5620]. In this model, a new role was created within the RFC Editor: the RFC Series Editor (RSE). This individual would oversee RFC publishing and development while leaving the process for approving documents for publication outside his or her mandate. While, arguably, this was a role long filled by people like Jon Postel, Bob Braden, and Joyce Reynolds, [RFC5620] saw the role of RFC Series Editor defined in such a way as to distinctly separate it from that of the Independent Submissions Editor (ISE).
間違いなく2006年に[RFC4714]から始まり、IABとIETFコミュニティは、RFCシリーズの構造を進化させるために、'00年代半ばにある程度の時間を費やしました。この作業には、RFCシリーズに公開されたグループ（最初はIETF、IAB [RFC4845]、およびIndependent Submissions Stream [RFC4846]を含み、後にIRTF [RFC5743]を含めるように拡大）がどのようにドキュメントを承認するかを定義することが含まれます。 RFCとして公開されます。 2009年、IABは「RFC Editor Model（Version 1）」[RFC5620]を公開しました。このモデルでは、RFCエディター内に新しい役割、RFCシリーズエディター（RSE）が作成されました。この担当者は、RFCの発行と開発を監督し、文書の承認プロセスを委任されたままにします。間違いなく、これはジョンポステル、ボブブレーデン、ジョイスレイノルズなどの人々が長い間果たしてきた役割でしたが、[RFC5620]は、RFCシリーズエディターの役割を、独立した投稿エディターの役割とは明確に区別するように定義しました。 （ISE）。
Before 2009, the RFC Editor could accept "Independent" submissions from individuals and, if they were judged significant, publish them as RFCs; the Independent Stream was set up to continue that function. From February 2010 through February 2018, I was the ISE. After reading [RFC4846], I went on to develop the Independent Stream (IS).
2009年より前は、RFCエディタは個人からの「独立した」提出を受け入れ、それらが重要であると判断された場合、RFCとして公開することができました。独立ストリームは、その機能を継続するために設定されました。 2010年2月から2018年2月まで、私はISEでした。 [RFC4846]を読んだ後、私は独立ストリーム（IS）を開発しました。
First, I spent several days at the RFC Production Center at the Information Sciences Institute (ISI) in Marina Del Ray with the RFC Editor (Bob Braden), Sandy Ginoza, and Alice Hagens so as to learn how RFCs were actually edited and published. All RFCs reach the Production Center as Internet-Drafts; they are copy edited until the edited version can be approved by its authors (AUTH48). At any stage, authors can check their draft's status via the RFC Editor website.
最初に、RFCが実際に編集および公開される方法を学ぶために、RFCエディター（Bob Braden）、Sandy Ginoza、およびAlice Hagensと一緒に、マリナデルレイにある情報科学研究所（ISI）のRFC Production Centerに数日間滞在しました。すべてのRFCはインターネットドラフトとしてProduction Centerに到達します。編集されたバージョンが作成者（AUTH48）によって承認されるまで、それらはコピー編集されます。作成者は、RFCエディタのWebサイトを介して、いつでもドラフトのステータスを確認できます。
For the Independent Submissions, Bob kept a journal (a simple ASCII file) of his interactions with authors for every draft, indexed by the draft name. Bob also entered the Independent drafts into the RFC Editor database so that authors could track their draft's status. After my few days with his team at ISI, he handed that journal (covering about 30 drafts) over to me and said, "Now it's over to you!"
インディペンデントサブミッションの場合、ボブはドラフト名で索引付けされたすべてのドラフトについて、著者とのやり取りのジャーナル（単純なASCIIファイル）を保持しました。また、ボブはRFCエディターデータベースに独立したドラフトを入力し、作成者がドラフトのステータスを追跡できるようにしました。 ISIでの彼のチームとの私の数日間の後、彼はそのジャーナル（約30のドラフトをカバー）を私に渡して、「それであなたに終わりました！」と言った。
I began by following in Bob's footsteps, maintaining a journal and tracking each draft's status in the RFC Editor database. My first consideration was that every serious Internet-Draft submitted needed several careful reviews. At that time, if the ISE knew of suitable reviewers, he or she could simply ask them. Otherwise, if the draft related to an IETF or IRTF Working Group, the ISE could ask Working Group Chairs or Area Directors to suggest reviewers. The Independent Submissions Editorial Board (Ed Board) was another place the ISE could request reviewers from. My experience with reviewers was that most of those I approached were happy to help.
ボブの足跡をたどって、ジャーナルを維持し、RFCエディターデータベースで各ドラフトのステータスを追跡することから始めました。私が最初に検討したのは、提出されたすべての真剣なインターネットドラフトがいくつかの慎重なレビューを必要とすることでした。その時点で、ISEが適切なレビュアーを知っていれば、彼または彼女は単に彼らに尋ねることができました。それ以外の場合、草案がIETFまたはIRTFワーキンググループに関連する場合、ISEはワーキンググループチェアまたはエリアディレクターにレビュアーの提案を依頼することができます。独立投稿編集委員会（編集委員会）は、ISEがレビュー担当者に要求できるもう1つの場所でした。私のレビュアーとの経験は、私がアプローチしたほとんどの人が喜んで助けてくれたということでした。
Most drafts were straightforward, but there were some that needed extra attention. Often, a draft requested IANA code points, and for that, IANA was always quick to offer help and support. Code points in some IANA registries require Expert Review [RFC8126]; sometimes the interactions with Expert Reviewers took quite a long time! Again, sometimes a draft seemed to fit better in the IETF Stream; for these, I would suggest that the draft authors try to find an Area Director to sponsor their work as an individual submission to the IETF Stream.
ほとんどのドラフトは単純明快でしたが、特別な注意が必要なものもありました。多くの場合、草案はIANAコードポイントを要求しました。そのため、IANAは常に迅速な支援とサポートを提供しました。一部のIANAレジストリのコードポイントには、エキスパートレビューが必要です[RFC8126]。エキスパートレビュー担当者とのやり取りにかなり時間がかかったことがあります。繰り返しになりますが、ドラフトはIETFストリームによりよく適合するように見えました。これらについては、草稿の作者が、IETFストリームへの個別の提出物として彼らの仕事を後援するエリアディレクターを探すことをお勧めします。
After my first few years as ISE, the IETF Tools Team developed the Datatracker [DATATRACKER] to show draft status and perform all the "housekeeping" tasks for all of the streams. At that stage, I switched to using the Datatracker rather than the RFC Editor database.
ISEとしての最初の数年間の後、IETFツールチームは、データトラッカー[DATATRACKER]を開発して、ドラフトステータスを表示し、すべてのストリームのすべての「ハウスキーピング」タスクを実行しました。その段階で、私はRFC EditorデータベースではなくDatatrackerを使用するように切り替えました。
Once a draft has been reviewed and the authors have revised it in dialogue with their reviewers, the ISE must submit that draft to the IESG for an "IESG Review" [RFC5742]. Overall, each IS draft benefited from discussions (which were usually simple) with my Ed Board and the IESG. A (very) few were somewhat controversial; for those, I was able to work with the IESG to negotiate a suitable "IESG Statement" and/or an "ISE Statement" to make it clear why the ISE published the draft.
ドラフトがレビューされ、著者がレビュー担当者との対話でそれを改訂したら、ISEはその草案を「IESGレビュー」のためにIESGに提出する必要があります[RFC5742]。全体として、各ISドラフトは、私のEd BoardとIESGとの（通常は簡単な）議論の恩恵を受けました。 （非常に）少数はやや物議を醸していました。それらについては、ISEGと協力して、ISEがドラフトを公開した理由を明確にするために、適切な「IESGステートメント」または「ISEステートメント」を交渉することができました。
One rather special part of the Independent Stream is the April 1st RFCs. These are humorous RFCs that have no formal review and approval process. The authors must send them directly to the ISE or the RFC Editor. Only a few of them can be published each year, and each is reviewed by the ISE and the RSE. Bob Braden's criteria for April 1st drafts were:
Independent Streamのかなり特別な部分は、4月1日のRFCです。これらは、正式なレビューと承認プロセスのないユーモラスなRFCです。著者はそれらを直接ISEまたはRFCエディタに送信する必要があります。毎年公開できるのはほんの数冊で、それぞれがISEおよびRSEによってレビューされます。 4月1日のドラフトに対するボブブレーデンの基準は次のとおりです。
* They must relate to the Internet (like all drafts).
* それらはインターネットに関連している必要があります（すべての下書きのように）。
* Their readers should reach the end of page two before realizing it is an April 1st RFC.
* 彼らの読者はそれが4月1日のRFCであることを理解する前に2ページの終わりに到達するべきです。
* They must actually be funny!
* 彼らは実際に面白いはずです！
April 1st RFCs have a large following, and feedback from the Internet community on April 1st of each year has been enthusiastic and quick!
4月1日のRFCには多くの支持者がおり、毎年4月1日のインターネットコミュニティからのフィードバックは熱心で迅速でした。
159 RFCs were published in the Independent Stream during my eight years as ISE. Over those eight years, I worked with most of their authors and often met with them at IETF meetings. For me, that was a very rewarding experience, so I thank all those that contributed. During those eight years, I also worked with most of the IESG members, who all also gave me a lot of helpful interaction. Lastly, I've always enjoyed working with the RSE and all the staff of the RFC Production Center. The IETF (as a whole) is very fortunate to have such an effective team of talented professional staff.
159のRFCがISEとしての8年間にIndependent Streamで公開されました。この8年間、私は彼らのほとんどの著者と協力し、IETFミーティングで彼らと会うことがよくありました。私にとって、それは非常にやりがいのある経験でしたので、貢献してくれたすべての人に感謝します。この8年間、私はIESGメンバーのほとんどとも協力しました。それらのメンバーはすべて、私にも多くの有益なやり取りをしてくれました。最後に、RSEとRFC Production Centerのすべてのスタッフとの作業をいつも楽しんでいます。 IETFは（全体として）有能な専門スタッフのそのような効果的なチームを持つことは非常に幸運です。
When I joined ISI, shortly after Jon Postel passed away, the RFC Editor model as we know it today (as defined in [RFC5620] and as obsoleted by [RFC6548] and [RFC6635]) did not exist. The RFC Editor functioned as one unit: there was no RSE, Production Center, Publisher, or Independent Submissions Editor. All of these roles were performed by the "RFC Editor", which was comprised of four individuals: Bob Braden, Joyce Reynolds, a part-time student programmer, and me.
私がISIに参加したとき、ジョンポステルが亡くなった直後、今日知っている（[RFC5620]で定義され、[RFC6548]と[RFC6635]で廃止された）RFCエディターモデルは存在しませんでした。 RFCエディターは1つのユニットとして機能しました。RSE、Production Center、Publisher、またはIndependent Submissions Editorはありませんでした。これらの役割はすべて、「RFCエディター」によって実行されました。この編集者は、ボブブレーデン、パートタイムの学生プログラマーであるジョイスレイノルズ、そして私で構成されています。
Bob provided high-level guidance and reviewed Independent Submissions. While Bob was a researcher in "Div 7" (Networking) at ISI, ostensibly, the percentage of time he had for the RFC Editor was 10%, but he invested much more time to keep the Series running. He pitched in where he could, especially when processing times were getting longer; at one point, he even NROFFed a couple of RFCs-to-be.
ボブは高レベルのガイダンスを提供し、独立した提出物をレビューしました。 ISIの "Div 7"（ネットワーキング）の研究者であったボブは、見かけ上、RFCエディターに費やした時間の割合は10％でしたが、シリーズの稼働を維持するためにより多くの時間を費やしました。特に処理時間が長くなると、彼はできる場所に売り込みました。ある時点で、彼はいくつかのRFCをNROFFすることさえしました。
Joyce was a full-time ISI employee. However, while continuing to ensure RFCs were published, she was also serving as a User Services Area Director and a keynote speaker about the Internet, and she was also temporarily on loan to IANA for 50% of her time while IANA was getting established after separating from ISI. The student programmer performed programming tasks as requested and was, at the time, responsible for parsing MIBs.
ジョイスはフルタイムのISI従業員でした。ただし、RFCが確実に公開されるようにする一方で、ユーザーサービスエリアディレクターおよびインターネットに関する基調講演者も務め、分離後IANAが設立されるまでの間、50％一時的にIANAに貸与しました。 ISIから。学生プログラマーは、要求に応じてプログラミングタスクを実行し、当時はMIBの解析を担当していました。
I was a full-time staffer and had to quickly learn the ropes so RFCs would continue to be published. My primary tasks were to manage the publication queue, format and prepare documents for Joyce's review, carry out AUTH48 once Joyce completed her review, and publish, index, and archive the RFCs (both soft and hard copies).
私はフルタイムのスタッフであり、RFCが引き続き公開されるように、そのロープをすばやく学習する必要がありました。私の主なタスクは、発行キューの管理、Joyceのレビュー用のドキュメントのフォーマットと準備、Joyceがレビューを完了した後にAUTH48を実行し、RFC（ソフトコピーとハードコピーの両方）を発行、インデックス付け、アーカイブすることでした。
The workload increased significantly over the next few years. As the workload increased, the RFC Editor reacted and slowly grew their staff over time. To understand the team growth, let's first take a look at the publication rates throughout history. The table below shows average annual publication rates during 5-year periods.
ワークロードは、今後数年間で大幅に増加しました。ワークロードが増加すると、RFCエディターは反応し、時間の経過とともにスタッフが徐々に増加しました。チームの成長を理解するために、まず歴史全体の出版率を見てみましょう。以下の表は、5年間の平均年間発行率を示しています。
+-------------+--------------------+
| Years | Avg. Pubs per Year |
+=============+====================+
| 1969 - 1972 | 80 |
+-------------+--------------------+
| 1973 - 1977 | 55 |
+-------------+--------------------+
| 1978 - 1982 | 20 |
+-------------+--------------------+
| 1983 - 1987 | 39 |
+-------------+--------------------+
| 1988 - 1992 | 69 |
+-------------+--------------------+
| 1993 - 1997 | 171 |
+-------------+--------------------+
| 1998 - 2002 | 237 |
+-------------+--------------------+
| 2003 - 2007 | 325 |
+-------------+--------------------+
| 2008 - 2012 | 333 |
+-------------+--------------------+
| 2013 - 2017 | 295 |
+-------------+--------------------+
Table 2: Annual Publication Rates
表2：年間発行率
There were significant jumps in the publication rates in the '90s and onward, with the number of publications almost doubling between 1993 and 2007. The annual submission count surpassed the 300 mark for the first time in 2004 and reached an all-time high of 385 in 2011. The submission rate did not drop below 300 until 2016 (284).
1990年代以降、出版数は大幅に増加し、1993年から2007年にかけて出版数はほぼ倍増しました。年間投稿数は2004年に初めて300を超え、史上最高の385に達しました。提出率は2016年まで300を下回らなかった（284）。
As the submissions grew, the RFC Editor experienced growing pains.
Processing times began to increase as the existing staff was unable
to keep up with the expanding queue size. In an attempt to reduce
the training hump and to avoid permanently hiring staff in case the
submission burst was a fluke, ISI brought on temporary copy editors;
this way, the staff could easily be resized as needed. However, as
Leslie noted, this didn't work very well. The effects of the
experiment would be lasting, as this led to a form of the process we
have now, where the RFC Editor asks more questions during AUTH/AUTH48
and technical changes require approval from the relevant Area
Directors or stream managers, depending on the document stream.
These changes added to the workload and extended publication times;
many often now jokingly refer to AUTH48 as the authors' "48 days",
"48 weeks", etc.
In addition to the increase in document submissions, we engaged in tools testing and went through several editorial process changes. Because of the lesson learned with temporary copy editors, our team grew to be more permanent. While we added other editors in between, two additions are of particular interest, as they experienced much of the RFC Editor's growing pains, helped work us out of a backlogged state, shaped the RFC Editor function, and are still with the team today: Alice Russo joined the team in 2005 and Megan Ferguson joined us in 2007.
提出書類の増加に加えて、ツールのテストを行い、いくつかの編集プロセスの変更を行いました。一時的なコピーエディターで学んだ教訓により、私たちのチームはより永続的になりました。間に他のエディターを追加しましたが、RFCエディターの増大する苦痛の多くを経験し、バックログ状態を解消し、RFCエディター機能を形成し、現在もチームに残っているため、2つの追加が特に興味深いです：アリスRussoは2005年にチームに参加し、Megan Fergusonは2007年にチームに参加しました。
With the understanding that the record-breaking number of submissions was not an anomaly, we made significant upgrades to the infrastructure of the RFC Editor function to facilitate document tracking and reporting. For example, the illustrious "black binder" (an actual 3-ring binder used to track RFC number assignment), a manually edited HTML file for the queue page, and a Rube Goldberg set of text files and scripts that created queue statistics, all were eventually replaced; an errata system was proposed and implemented; and XML became a newly accepted source file.
過去最高の提出数は異常ではないことを理解したうえで、ドキュメントの追跡とレポートを容易にするために、RFCエディター機能のインフラストラクチャに大幅なアップグレードを行いました。たとえば、輝かしい "ブラックバインダー"（RFC番号の割り当てを追跡するために使用される実際の3リングバインダー）、キューページの手動で編集されたHTMLファイル、およびキュー統計を作成するテキストファイルとスクリプトのRube Goldbergセット、すべて最終的に交換されました。正誤表システムが提案および実装されました。そしてXMLは新しく受け入れられたソースファイルになりました。
In 2009, [RFC5620] was published, introducing the initial version of the RFC Editor model we have now. While it was published in 2009, it did not go into effect until 2010, when the RFC Editor project as I knew it was disbanded and divvied up into four pieces: RFC Series Editor (RSE), Independent Submissions Editor (ISE), RFC Production Center (RPC), and the Publisher function. In addition, the RFC Series Advisory Group (RSAG) was created to "provide expert, informed guidance (chiefly, to the RSE) in matters affecting the RFC Series operation and development" [RSAG].
2009年に[RFC5620]が公開され、現在使用しているRFC Editorモデルの初期バージョンが紹介されました。それは2009年に公開されましたが、RFCエディタープロジェクトが解体され、RFCシリーズエディター（RSE）、独立サブミッションエディター（ISE）、RFCプロダクションに分割された2010年まで有効になりませんでした。センター（RPC）、およびパブリッシャー機能。さらに、RFCシリーズアドバイザリグループ（RSAG）は、「RFCシリーズの運用と開発に影響する問題について、専門家、情報に基づくガイダンス（主に、RSE）を提供する」ために作成されました[RSAG]。
In 2010, the RPC and Publisher contracts were awarded to Association Management Solutions (AMS). There, we started with three existing team members (Alice Russo, Megan Ferguson, and me), and we were pleased to be joined by Lynne Bartholomew and Rebecca VanRheenen, new colleagues to anchor us in the AMS office.
2010年に、RPCとパブリッシャーの契約がAssociation Management Solutions（AMS）に授与されました。そこで、私たちは3人の既存のチームメンバー（Alice Russo、Megan Ferguson、および私）から始め、Lynne BartholomewとRebecca VanRheenenが加わって、AMSオフィスに私たちを固定しました。
I was wary of this model and was especially worried about the hole Bob Braden's departure would create. Luckily for us, Bob Braden provided wise counsel and insight during the transition (and beyond). He gave the staff transitioning to AMS particularly helpful parting words, "keep the RFCs coming", and that is what we did.
私はこのモデルに用心深く、特にボブ・ブレーデンの離脱がもたらすであろう穴について心配していました。幸運なことに、ボブ・ブレーデンは移行中（およびそれ以降）に賢明な助言と洞察を提供してくれました。彼は、AMSに移行するスタッフに、「RFCを今後も維持する」という特に役立つ別れの言葉を与えました。それが私たちのやったことです。
AMS embraced the RFC Series and helped us quickly get set up on new servers. The RFC Production Center and Publisher were now part of the AMS family and it was all hands on deck to make sure the transition went smoothly to minimize the impact on document processing.
AMSはRFCシリーズを採用し、新しいサーバーをすばやくセットアップするのに役立ちました。 RFC Production CenterとPublisherは現在AMSファミリの一部であり、ドキュメント処理への影響を最小限に抑えるために移行がスムーズに行われることを確認するためのすべての実践的な作業でした。
Our focus during transition was to 1) keep the trains running; that is, we wanted to get ourselves up and running with minimal down time, and 2) work with the Transitional RSE (a role that concluded before the transition ended), the ISE (Nevil Brownlee), RSAG, and the IETF Administrative Director (IAD) to better understand and implement the newly defined RFC Editor model.
移行中の私たちの焦点は、1）列車を走らせ続けることでした。つまり、最小限のダウンタイムで稼働できるようにし、2）移行RSE（移行が終了する前に完了した役割）、ISE（Nevil Brownlee）、RSAG、およびIETF管理ディレクター（ IAD）は、新しく定義されたRFCエディターモデルをよりよく理解して実装します。
Though some portions of the transition were challenging and lasted longer than expected, the Acting RSE (Olaf Kolkman) officially handed the reins over to the new RSE (Heather Flanagan) in 2012. She had to jump in, learn the RFC Editor and IETF culture, and work through a backlog of issues that had been left unattended.
移行の一部はやりがいがあり、予想よりも長く続きましたが、RSEの代理人（Olaf Kolkman）は、2012年に正式に手綱を新しいRSE（Heather Flanagan）に引き渡しました。彼女は飛び込んで、RFCエディターとIETFカルチャーを学ぶ必要がありました、そして放置されていた問題のバックログを処理します。
Two of the backlogged issues were so old that they were ones someone had asked me about at my first IETF meeting: When was the RFC Editor going to allow non-ASCII characters in RFCs? When would the RFC Editor adopt a more modern publication format?
バックログされた問題のうち2つは非常に古く、最初のIETFミーティングで誰かが私に尋ねた問題でした。RFCエディターがRFCで非ASCII文字を許可するのはいつですか？ RFCエディターはいつより新しい出版形式を採用しますか？
At that time, while we understood the desire to move toward supporting a broader range of character sets and having more-modern outputs, we also routinely received emails from individuals requesting that we send them plaintext files (instead of pointing them to the website) because their Internet access was limited. We also regularly received complaints from users of <https://www.rfc-editor.org> whenever something on the site didn't work correctly with their older browsers. In short, we could not advance without leaving a large number of users behind.
当時、より幅広い文字セットをサポートし、よりモダンな出力にしたいという欲求を理解していましたが、個人から（ウェブサイトを指すのではなく）プレーンテキストファイルを送信するようリクエストするメールも定期的に受け取りました。彼らのインターネットアクセスは制限されていました。 <https://www.rfc-editor.org>のユーザーからも、古いブラウザーでサイトの何かが正しく機能しない場合は、定期的に苦情を受け取りました。つまり、多くのユーザーを置き去りにしないと前進できませんでした。
However, we now find ourselves on the precipice of change. The next few years promise to be exciting for the RFC Series as we transition from publishing plaintext, ASCII-only files to publishing multiple file formats (XML, HTML, PDF/A-3, and TXT) that allow both non-ASCII characters and SVG art.
しかし、私たちは今、変化の絶壁に身を置いています。プレーンテキストのASCIIのみのファイルの公開から、非ASCII文字とSVGアート。
Interestingly enough, I find that the RFC Editor has been in an almost constant state of change since I joined the team, even though the goal of the RFC Editor remains the same: to produce archival quality RFCs in a timely manner that are easily accessible for future generations.
興味深いことに、RFCエディターの目的は同じですが、チームに参加して以来、RFCエディターはほぼ常に変化しています。アーカイブ品質のRFCをタイムリーに作成し、将来の世代。
As Steve Crocker mentioned, the Series began with goals of communication over formality and openness over structure. As the Internet has grown and become a pervasive, global construct, we still aim for openness and communication, but recognize that for protocols and other information to support interoperability, there must be points of stability to build from. Everyone, from small-time app developers to multi-billion dollar companies, is on the same footing. Anyone should be able to look back at a point in time and understand what was done and why.
スティーブ・クロッカーが述べたように、シリーズは形式上のコミュニケーションと構造上のオープン性の目標から始まりました。インターネットが成長し、広範でグローバルな構造になっている今でも、オープン性とコミュニケーションを目指していますが、相互運用性をサポートするプロトコルやその他の情報には、構築するための安定点が必要であることを認識しています。小規模なアプリ開発者から数十億ドル規模の企業まで、誰もが同じ立場にいます。誰でも、ある時点を振り返り、何が行われたのか、その理由を理解できるはずです。
While the informality has given way to increased structure, the openness and solid foundation that the Series provides must continue. With that in mind, what does the future hold for the next fifty years of RFCs?
非公式性が構造の拡大に道を譲りましたが、シリーズが提供する開放性と強固な基盤は継続する必要があります。それを念頭に置いて、RFCの次の50年間の未来はどうなるでしょうか。
The RFC Editor exists to edit, publish, and maintain an archive of documents published in the RFC Series. A proper digital archive, however, is more than just saving RFCs to disk and making sure the disks are backed up; the field of digital preservation has grown and transformed into an industry in and of itself. "Digital Preservation Considerations for the RFC Series" [RFC8153] reviews what a digital archive means today and describes ways to support the archive into the future. It also recommends ways for the RFC Editor to take advantage of those organizations that specialize in this field.
RFC Editorは、RFCシリーズで公開されたドキュメントのアーカイブを編集、公開、および維持するために存在します。ただし、適切なデジタルアーカイブは、RFCをディスクに保存して、ディスクがバックアップされていることを確認するだけのものではありません。デジタル保存の分野は成長し、それ自体が産業に変化しました。 「RFCシリーズのデジタル保存に関する考慮事項」[RFC8153]は、今日のデジタルアーカイブの意味をレビューし、アーカイブを将来にわたってサポートする方法を説明しています。また、RFCエディタがこの分野に特化した組織を利用する方法を推奨しています。
The future of digital preservation, as far as the RFC Series is concerned, will mean both finding new partners that can absorb and archive RFCs into a public, maintained digital archive and reviewing the RFC format to ensure that the published documents are archivable according to whatever the industry best practice is over time.
RFCシリーズに関する限り、デジタル保存の未来は、RFCを吸収して公開デジタルアーカイブにアーカイブできる新しいパートナーを見つけることと、RFC形式をレビューして、公開されたドキュメントが何に従ってでもアーカイブ可能であることを確認することの両方を意味します。業界のベストプラクティスは時間の経過とともにあります。
RFCs have been digital documents since very early in the days of the Series. While not always published in US-ASCII, that format has been the canonical format for decades. The fact that this format has lasted through so much evolution and change is remarkable.
RFCは、シリーズのごく初期の頃からデジタルドキュメントでした。常にUS-ASCIIで公開されているわけではありませんが、そのフォーマットは何十年もの間標準的なフォーマットでした。このフォーマットが非常に多くの進化と変更を続けてきたという事実は注目に値します。
Unfortunately, the US-ASCII format does not extend enough to meet the expectations and requirements of many users today. The entire field of online document presentation, consumption, and preservation has, in some cases, only been invented years after the first RFC was published. While it can be (and has been) argued that those newer fields and their tools have not had a chance to stand the test of time, the RFC Series Editor (in consultation with the community) started a concerted effort in 2012 to bring the RFC Series into alignment with a new array of possibilities for preservation and display.
残念ながら、US-ASCII形式は、今日の多くのユーザーの期待と要件を満たすには十分に拡張されていません。オンラインドキュメントの表示、消費、および保存の分野全体が、最初のRFCが公開されてから数年後に発明された場合もあります。これらの新しいフィールドとそのツールは時の試練に耐える機会がなかったと主張することはできます（されてきました）が、RFCシリーズエディター（コミュニティとの協議により）は、RFCを導入するための協調的な取り組みを2012年に開始しました保存と表示の新しい可能性の配列に合わせてシリーズ化します。
Information on the RFC format project and the initial reasoning and requirements for the changes underway can be found in [RFC7990]. With the advent of these changes, the door has been opened to consider further changes in the future as the specifications for archiving digital material evolves, and as the expectation of web development advances.
RFC形式のプロジェクトに関する情報と、進行中の変更の初期の理由および要件は、[RFC7990]にあります。これらの変更の出現により、デジタルマテリアルのアーカイブの仕様が進化し、Web開発への期待が高まるにつれて、将来のさらなる変更を検討するための扉が開かれました。
In the eyes of many, particularly within the IETF, the RFC Series is synonymous with the IETF. While the Series itself predates the IETF by eighteen years, over time, the IETF has become the source of the majority of documents submitted for publication to the RFC Editor. The policies developed for IETF Stream drafts tend to apply across all four document streams, and publication-related tools tend to focus on the IETF as the primary audience for their use. It is difficult for people to see how, or even why, there is a distinction between the Series and the IETF.
多くの人の目には、特にIETF内では、RFCシリーズはIETFと同義です。シリーズ自体はIETFより18年前に登場しましたが、時間の経過とともに、IETFはRFC Editorに公開するために提出されたドキュメントの大部分の情報源になりました。 IETFストリームドラフト用に作成されたポリシーは、4つのドキュメントストリームすべてに適用される傾向があり、出版関連のツールは、IETFを主要な対象ユーザーとして使用する傾向があります。このシリーズとIETFの違いは、どうしてか、あるいはなぜそうなのかを人々が理解することは困難です。
We are in the midst of that question now more than ever. What is the future of the Series? If people cannot tell where the IETF ends and the Series starts, should we consider this an artificial distinction and declare them to be the same entity?
今、私たちはその問題の真っ最中です。シリーズの将来は何ですか？ IETFがどこで終わり、シリーズが始まるかが分からない場合、これを人為的な違いと見なして、同じエンティティであると宣言する必要がありますか？
Ultimately, this will be something the community decides, and conversations are underway to consider the ramifications of possible changes.
最終的には、これはコミュニティが決定することとなり、起こり得る変更の影響を検討するための会話が進行中です。
As the Internet evolves, expectations and possibilities evolve, too. Over the next fifty years, the Series will continue to demonstrate a balance between the need to stay true to the original mission of publication and preservation, while also staying relevant to the needs of the authors and consumers of RFCs. The tension in balancing those needs rests on the RFC Editor and the community to resolve. We will not run short of challenges.
インターネットが進化するにつれて、期待と可能性も進化します。今後50年間、シリーズは、公開と保存という本来の使命に忠実であり続ける必要性と、RFCの作成者および消費者のニーズとの関連性を維持することの間のバランスを示し続けます。これらのニーズのバランスをとる際の緊張は、解決するRFCエディタとコミュニティにかかっています。私たちは挑戦が不足することはありません。
This document has no IANA actions.
このドキュメントにはIANAアクションはありません。
This document has no security considerations.
このドキュメントにはセキュリティに関する考慮事項はありません。
[APPRENTICE] Wikipedia, "The Sorcerer's Apprentice", December 2019, <https://en.wikipedia.org/w/index.php?title=The_Sorcerer%2 7s_Apprentice&oldid=925824658>.
[APPRENTICE] Wikipedia、「The Sorcerer's Apprentice」、2019年12月<https://en.wikipedia.org/w/index.php?title=The_Sorcerer%2 7s_Apprentice＆oldid = 925824658>。
[DATATRACKER] Internet Engineering Task Force, "IETF Datatracker", <https://datatracker.ietf.org>.
[DATATRACKER]インターネット技術特別調査委員会、「IETF Datatracker」、<https://datatracker.ietf.org>。
[IAB-19880712] IAB, "IAB Minutes 1988-07-12", July 1988, <https://www.iab.org/documents/minutes/minutes-1988/iab-minutes-1988-07-12/>.
[IAB-19880712] IAB、「IAB Minutes 1988-07-12」、1988年7月、<https://www.iab.org/documents/minutes/minutes-1988/iab-minutes-1988-07-12/> 。
[IETF1] The MITRE Corporation, "Proceedings of the 16-17 January 1986 DARPA Gateway Algorithms and Data Structures Task Force", IETF 1, January 1986, <https://www.ietf.org/old/2009/proceedings/prior29/ IETF01.pdf>.
[IETF1] MITER Corporation、「1986年1月16〜17日のDARPAゲートウェイアルゴリズムとデータ構造タスクフォースの議事録」、IETF 1、1986年1月、<https://www.ietf.org/old/2009/proceedings/prior29 / IETF01.pdf>。
[ISI-to-AMS] IETF Administrative Support Activity (IASA), "RFC Production Center Agreement between Association Management Solutions, LLC and The Internet Society", October 2009, <https://iaoc.ietf.org/documents/AMS-RPC-Public-Final-2009.pdf>.
[ISI-to-AMS] IETF管理サポートアクティビティ（IASA）、「Association Management Solutions、LLCとThe Internet Societyの間のRFC Production Center契約」、2009年10月、<https://iaoc.ietf.org/documents/AMS- RPC-Public-Final-2009.pdf>。
[RFC-ONLINE] RFC Editor, "History of RFC Online Project", 2000, <https://www.rfc-editor.org/rfc-online-2000.html>.
[RFC-ONLINE] RFC Editor、 "History of RFC Online Project"、2000、<https://www.rfc-editor.org/rfc-online-2000.html>。
[RFC0001] Crocker, S., "Host Software", RFC 1, DOI 10.17487/RFC0001, April 1969, <https://www.rfc-editor.org/info/rfc1>.
[RFC0001] Crocker、S。、「Host Software」、RFC 1、DOI 10.17487 / RFC0001、1969年4月、<https://www.rfc-editor.org/info/rfc1>。
[RFC0003] Crocker, S., "Documentation conventions", RFC 3, DOI 10.17487/RFC0003, April 1969, <https://www.rfc-editor.org/info/rfc3>.
[RFC0003] Crocker、S。、「Documentation Conventions」、RFC 3、DOI 10.17487 / RFC0003、1969年4月、<https://www.rfc-editor.org/info/rfc3>。
[RFC0114] Bhushan, A., "File Transfer Protocol", RFC 114, DOI 10.17487/RFC0114, April 1971, <https://www.rfc-editor.org/info/rfc114>.
[RFC0114] Bhushan、A。、「ファイル転送プロトコル」、RFC 114、DOI 10.17487 / RFC0114、1971年4月、<https://www.rfc-editor.org/info/rfc114>。
[RFC0433] Postel, J., "Socket number list", RFC 433, DOI 10.17487/RFC0433, December 1972, <https://www.rfc-editor.org/info/rfc433>.
[RFC0433] Postel、J。、「ソケット番号リスト」、RFC 433、DOI 10.17487 / RFC0433、1972年12月、<https://www.rfc-editor.org/info/rfc433>。
[RFC0690] Postel, J., "Comments on the proposed Host/IMP Protocol changes", RFC 690, DOI 10.17487/RFC0690, June 1975, <https://www.rfc-editor.org/info/rfc690>.
[RFC0690] Postel、J。、「提案されたホスト/ IMPプロトコルの変更に関するコメント」、RFC 690、DOI 10.17487 / RFC0690、1975年6月、<https://www.rfc-editor.org/info/rfc690>。
[RFC0748] Crispin, M., "Telnet randomly-lose option", RFC 748, DOI 10.17487/RFC0748, April 1978, <https://www.rfc-editor.org/info/rfc748>.
[RFC0748] Crispin、M。、「Telnet randomly-lose option」、RFC 748、DOI 10.17487 / RFC0748、1978年4月、<https://www.rfc-editor.org/info/rfc748>。
[RFC0902] Reynolds, J. and J. Postel, "ARPA Internet Protocol policy", RFC 902, DOI 10.17487/RFC0902, July 1984, <https://www.rfc-editor.org/info/rfc902>.
[RFC0902] Reynolds、J。およびJ. Postel、「ARPAインターネットプロトコルポリシー」、RFC 902、DOI 10.17487 / RFC0902、1984年7月、<https://www.rfc-editor.org/info/rfc902>。
[RFC1000] Reynolds, J. and J. Postel, "Request For Comments reference guide", RFC 1000, DOI 10.17487/RFC1000, August 1987, <https://www.rfc-editor.org/info/rfc1000>.
[RFC1000] Reynolds、J。およびJ. Postel、「Request For Commentsリファレンスガイド」、RFC 1000、DOI 10.17487 / RFC1000、1987年8月、<https://www.rfc-editor.org/info/rfc1000>。
[RFC1083] Defense Advanced Research Projects Agency and Internet Activities Board, "IAB official protocol standards", RFC 1083, DOI 10.17487/RFC1083, December 1988, <https://www.rfc-editor.org/info/rfc1083>.
[RFC1083]国防高等研究計画局およびインターネット活動委員会、「IAB公式プロトコル標準」、RFC 1083、DOI 10.17487 / RFC1083、1988年12月、<https://www.rfc-editor.org/info/rfc1083>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R。、編、「インターネットホストの要件-通信層」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https://www.rfc-editor.org/info/ rfc1122>。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1123] Braden、R。、編、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<https://www.rfc-editor.org/info / rfc1123>。
[RFC1150] Malkin, G. and J. Reynolds, "FYI on FYI: Introduction to the FYI Notes", RFC 1150, DOI 10.17487/RFC1150, March 1990, <https://www.rfc-editor.org/info/rfc1150>.
[RFC1150] Malkin、G。およびJ. Reynolds、「FYI on FYI：Introduction to the FYI Notes」、RFC 1150、DOI 10.17487 / RFC1150、1990年3月、<https://www.rfc-editor.org/info/ rfc1150>。
[RFC1311] Postel, J., "Introduction to the STD Notes", RFC 1311, DOI 10.17487/RFC1311, March 1992, <https://www.rfc-editor.org/info/rfc1311>.
[RFC1311] Postel、J。、「STDノートの概要」、RFC 1311、DOI 10.17487 / RFC1311、1992年3月、<https://www.rfc-editor.org/info/rfc1311>。
[RFC1818] Postel, J., Li, T., and Y. Rekhter, "Best Current Practices", RFC 1818, DOI 10.17487/RFC1818, August 1995, <https://www.rfc-editor.org/info/rfc1818>.
[RFC1818] Postel、J.、Li、T。、およびY. Rekhter、「Best Current Practices」、RFC 1818、DOI 10.17487 / RFC1818、1995年8月、<https://www.rfc-editor.org/info/ rfc1818>。
[RFC2441] Cohen, D., "Working with Jon, Tribute delivered at UCLA, October 30, 1998", RFC 2441, DOI 10.17487/RFC2441, November 1998, <https://www.rfc-editor.org/info/rfc2441>.
[RFC2441]コーエン、D。、「ジョンとの協力、1998年10月30日、UCLAで配信されたトリビュート」、RFC 2441、DOI 10.17487 / RFC2441、1998年11月、<https://www.rfc-editor.org/info/ rfc2441>。
[RFC2468] Cerf, V., "I REMEMBER IANA", RFC 2468, DOI 10.17487/RFC2468, October 1998, <https://www.rfc-editor.org/info/rfc2468>.
[RFC2468] Cerf、V。、「I REMEMBER IANA」、RFC 2468、DOI 10.17487 / RFC2468、1998年10月、<https://www.rfc-editor.org/info/rfc2468>。
[RFC2555] Editor, RFC. and et. al., "30 Years of RFCs", RFC 2555, DOI 10.17487/RFC2555, April 1999, <https://www.rfc-editor.org/info/rfc2555>.
[RFC2555] RFC、編集者。そして、その他、「30年のRFC」、RFC 2555、DOI 10.17487 / RFC2555、1999年4月、<https://www.rfc-editor.org/info/rfc2555>。
[RFC4714] Mankin, A. and S. Hayes, "Requirements for IETF Technical Publication Service", RFC 4714, DOI 10.17487/RFC4714, October 2006, <https://www.rfc-editor.org/info/rfc4714>.
[RFC4714] Mankin、A。およびS. Hayes、「Requirements for IETF Technical Publication Service」、RFC 4714、DOI 10.17487 / RFC4714、2006年10月、<https://www.rfc-editor.org/info/rfc4714>。
[RFC4844] Daigle, L., Ed. and Internet Architecture Board, "The RFC Series and RFC Editor", RFC 4844, DOI 10.17487/RFC4844, July 2007, <https://www.rfc-editor.org/info/rfc4844>.
[RFC4844]ダイグル、L、エド。インターネットアーキテクチャボード、「RFCシリーズとRFCエディタ」、RFC 4844、DOI 10.17487 / RFC4844、2007年7月、<https://www.rfc-editor.org/info/rfc4844>。
[RFC4845] Daigle, L., Ed. and Internet Architecture Board, "Process for Publication of IAB RFCs", RFC 4845, DOI 10.17487/RFC4845, July 2007, <https://www.rfc-editor.org/info/rfc4845>.
[RFC4845] Daigle、L.、Ed。およびインターネットアーキテクチャボード、「Process for Publication of IAB RFCs」、RFC 4845、DOI 10.17487 / RFC4845、2007年7月、<https://www.rfc-editor.org/info/rfc4845>。
[RFC4846] Klensin, J., Ed. and D. Thaler, Ed., "Independent Submissions to the RFC Editor", RFC 4846, DOI 10.17487/RFC4846, July 2007, <https://www.rfc-editor.org/info/rfc4846>.
[RFC4846]クレンシン、J。、エド。 D.ターラー編、「RFCエディターへの独立した提出」、RFC 4846、DOI 10.17487 / RFC4846、2007年7月、<https://www.rfc-editor.org/info/rfc4846>。
[RFC5540] Editor, RFC., "40 Years of RFCs", RFC 5540, DOI 10.17487/RFC5540, April 2009, <https://www.rfc-editor.org/info/rfc5540>.
[RFC5540]編集者、RFC、「40 Years of RFCs」、RFC 5540、DOI 10.17487 / RFC5540、2009年4月、<https://www.rfc-editor.org/info/rfc5540>。
[RFC5620] Kolkman, O., Ed. and IAB, "RFC Editor Model (Version 1)", RFC 5620, DOI 10.17487/RFC5620, August 2009, <https://www.rfc-editor.org/info/rfc5620>.
[RFC5620]コルクマン、O。、エド。 IAB、「RFC Editor Model（Version 1）」、RFC 5620、DOI 10.17487 / RFC5620、2009年8月、<https://www.rfc-editor.org/info/rfc5620>。
[RFC5742] Alvestrand, H. and R. Housley, "IESG Procedures for Handling of Independent and IRTF Stream Submissions", BCP 92, RFC 5742, DOI 10.17487/RFC5742, December 2009, <https://www.rfc-editor.org/info/rfc5742>.
[RFC5742] Alvestrand、H。およびR. Housley、「独立およびIRTFストリーム送信の処理のためのIESG手順」、BCP 92、RFC 5742、DOI 10.17487 / RFC5742、2009年12月、<https：//www.rfc-editor。 org / info / rfc5742>。
[RFC5743] Falk, A., "Definition of an Internet Research Task Force (IRTF) Document Stream", RFC 5743, DOI 10.17487/RFC5743, December 2009, <https://www.rfc-editor.org/info/rfc5743>.
[RFC5743] Falk、A。、「Definition of an Internet Research Task Force（IRTF）Document Stream」、RFC 5743、DOI 10.17487 / RFC5743、2009年12月、<https://www.rfc-editor.org/info/rfc5743 >。
[RFC6360] Housley, R., "Conclusion of FYI RFC Sub-Series", RFC 6360, DOI 10.17487/RFC6360, August 2011, <https://www.rfc-editor.org/info/rfc6360>.
[RFC6360] Housley、R。、「FYI RFCサブシリーズの結論」、RFC 6360、DOI 10.17487 / RFC6360、2011年8月、<https://www.rfc-editor.org/info/rfc6360>。
[RFC6410] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards Track to Two Maturity Levels", BCP 9, RFC 6410, DOI 10.17487/RFC6410, October 2011, <https://www.rfc-editor.org/info/rfc6410>.
[RFC6410] Housley、R.、Crocker、D。、およびE. Burger、「標準トラックを2つの成熟度レベルに削減」、BCP 9、RFC 6410、DOI 10.17487 / RFC6410、2011年10月、<https：// www。 rfc-editor.org/info/rfc6410>。
[RFC6548] Brownlee, N., Ed. and IAB, "Independent Submission Editor Model", RFC 6548, DOI 10.17487/RFC6548, June 2012, <https://www.rfc-editor.org/info/rfc6548>.
[RFC6548]ブラウンリー、N。、エド。 IAB、「Independent Submission Editor Model」、RFC 6548、DOI 10.17487 / RFC6548、2012年6月、<https://www.rfc-editor.org/info/rfc6548>。
[RFC6635] Kolkman, O., Ed., Halpern, J., Ed., and IAB, "RFC Editor Model (Version 2)", RFC 6635, DOI 10.17487/RFC6635, June 2012, <https://www.rfc-editor.org/info/rfc6635>.
[RFC6635] Kolkman、O。、編、Halpern、J。、編、IAB、「RFC Editor Model（Version 2）」、RFC 6635、DOI 10.17487 / RFC6635、2012年6月、<https：// www。 rfc-editor.org/info/rfc6635>。
[RFC6949] Flanagan, H. and N. Brownlee, "RFC Series Format Requirements and Future Development", RFC 6949, DOI 10.17487/RFC6949, May 2013, <https://www.rfc-editor.org/info/rfc6949>.
[RFC6949] Flanagan、H。およびN. Brownlee、「RFCシリーズフォーマットの要件と将来の開発」、RFC 6949、DOI 10.17487 / RFC6949、2013年5月、<https://www.rfc-editor.org/info/rfc6949> 。
[RFC7990] Flanagan, H., "RFC Format Framework", RFC 7990, DOI 10.17487/RFC7990, December 2016, <https://www.rfc-editor.org/info/rfc7990>.
[RFC7990] Flanagan、H。、「RFC Format Framework」、RFC 7990、DOI 10.17487 / RFC7990、2016年12月、<https://www.rfc-editor.org/info/rfc7990>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[RFC8153] Flanagan, H., "Digital Preservation Considerations for the RFC Series", RFC 8153, DOI 10.17487/RFC8153, April 2017, <https://www.rfc-editor.org/info/rfc8153>.
[RFC8153] Flanagan、H。、「RFCシリーズのデジタル保存に関する考慮事項」、RFC 8153、DOI 10.17487 / RFC8153、2017年4月、<https://www.rfc-editor.org/info/rfc8153>。
[RSAG] RFC Editor, "RFC Series Advisory Group", <https://www.rfc-editor.org/about/rsag/>.
[RSAG] RFC Editor、「RFC Series Advisory Group」、<https://www.rfc-editor.org/about/rsag/>。
IAB Members at the Time of Approval
承認時のIABメンバー
Jari Arkko Alissa Cooper Stephen Farrell Wes Hardaker Ted Hardie Christian Huitema Zhenbin Li Erik Nordmark Mark Nottingham Melinda Shore Jeff Tantsura Martin Thomson Brian Trammell
ジャリアルコアリッサクーパースティーブンファレルウェスハーダーカーテッドハーディークリスチャンウイテマジェンビンリーエリックノードマークマークノッティンガムメリンダショアジェフタンツラマーティントムソンブライアントラメル
Acknowledgements
謝辞
Many thanks to John Klensin for his feedback and insights on the history of the Series, as someone who directly engaged and influenced many of the key individuals involved in developing the RFC Series.
RFCシリーズの開発に関与する主要な個人の多くに直接関与し影響を与えた人物として、シリーズの歴史に関する彼のフィードバックと洞察を提供してくれたJohn Klensinに感謝します。
Additional thanks to members of the RFC Series Advisory group and the Independent Submissions Editorial Board, in particular, Scott Bradner, Brian Carpenter, and Adrian Farrel, for their early reviews and input into the sequence of key moments in the history of the Series.
RFCシリーズアドバイザリーグループのメンバーと独立投稿編集委員会、特にスコットブラドナー、ブライアンカーペンター、エイドリアンファレルの初期レビューと、シリーズの歴史における一連の主要な瞬間への入力に感謝します。
Contributors
貢献者
Many thanks to Steve Crocker, Vint Cerf, Leslie Daigle, Nevil Brownlee, and Sandy Ginoza for their perspectives on the Series and their ongoing support.
シリーズの展望と継続的なサポートについて、Steve Crocker、Vint Cerf、Leslie Daigle、Nevil Brownlee、Sandy Ginozaに感謝します。
Author's Address
著者のアドレス
Heather Flanagan (editor) RFC Editor
Heather Flanagan（editor）RFC Editor
Email: rse@rfc-editor.org
URI: https://orcid.org/0000-0002-2647-2220