[要約] RFC 8963は、2018年に制作されたRFCのサンプルの評価に関する文書です。この文書の目的は、RFCの品質、適用性、および進化を理解することにあります。利用場面としては、RFCの作成プロセスの改善、技術文書の標準化への貢献、及び将来のRFCの方向性を案内するために参照されます。
Independent Submission C. Huitema
Request for Comments: 8963 Private Octopus Inc.
Category: Informational January 2021
ISSN: 2070-1721
Evaluation of a Sample of RFCs Produced in 2018
2018年に生産されたRFCのサンプルの評価
Abstract
概要
This document presents the author's effort to understand the delays involved in publishing an idea in the IETF or through the Independent Stream, from the first individual draft to the publication of the RFC. We analyze a set of randomly chosen RFCs approved in 2018, looking for history and delays. We also use two randomly chosen sets of RFCs published in 2008 and 1998 for comparing delays seen in 2018 to those observed 10 or 20 years ago. The average RFC in the 2018 sample was produced in 3 years and 4 months, of which 2 years and 10 months were spent in the working group, 3 to 4 months for IETF consensus and IESG review, and 3 to 4 months in RFC production. The main variation in RFC production delays comes from the AUTH48 phase.
この文書は、最初の個々のドラフトからRFCの出版まで、IETFまたは独立したストリームを通して、IETFまたは独立したストリームを通じての遅延を理解するための著者の努力を提示します。2018年に承認されたランダムに選択されたRFCのセットを分析し、歴史と遅延を探しています。また、2008年と1998年に発行された2つのランダムに選択されたRFCのセットが2018年に見られる遅延を10または20年前に観察されたものに比較しています。2018年サンプルの平均RFCは3歳から4ヶ月で産生され、そのうち2歳から10ヶ月が作業群、IETFコンセンサスおよびIESGレビューのための3~4ヶ月、そしてRFC産生の3~4ヶ月で費やされました。RFC製造遅延の主なばらつきは、AUTH48フェーズから来ています。
We also measure the number of citations of the chosen RFC using Semantic Scholar, and compare citation counts with what we know about deployment. We show that citation counts indicate academic interest, but correlate only loosely with deployment or usage of the specifications. Counting web references could complement that.
また、意味学者を使用して選択されたRFCの引用数を測定し、引用数を展開について知っているものと比較します。引用数が学術的な関心を示しているが、仕様の展開または使用法でのみ緩くのみ相関することを示しています。Web参照をカウントすることはそれを補完する可能性があります。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。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/rfc8963.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8963で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
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.
この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。
Table of Contents
目次
1. Introduction
2. Methodology
2.1. Defining the Important Milestones
2.2. Selecting a Random Sample of RFCs
2.3. Conventions Used in This Document
3. Analysis of 20 Selected RFCs
3.1. RFC 8411
3.2. RFC 8456
3.3. RFC 8446
3.4. RFC 8355
3.5. RFC 8441
3.6. RFC 8324
3.7. RFC 8377
3.8. RFC 8498
3.9. RFC 8479
3.10. RFC 8453
3.11. RFC 8429
3.12. RFC 8312
3.13. RFC 8492
3.14. RFC 8378
3.15. RFC 8361
3.16. RFC 8472
3.17. RFC 8471
3.18. RFC 8466
3.19. RFC 8362
3.20. RFC 8468
4. Analysis of Process and Delays
4.1. Delays from First Draft to RFC
4.2. Working Group Processing Time
4.3. Preparation and Publication Delays
4.4. Copy Editing
4.5. Independent Stream
5. Citation Counts
5.1. Citation Numbers
5.2. Comparison to 1998 and 2008
5.3. Citations versus Deployments
5.4. Citations versus Web References
6. Observations and Next Steps
7. Security Considerations
8. IANA Considerations
9. Informative References
Acknowledgements
Author's Address
As stated on the organization's web site, "The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet." The specifications produced by the IETF are published in the RFC series, along with documents from the IAB, IRTF, and Independent streams (as per RFC 8729). In this memo, the author attempts to understand the delays involved in publishing an idea in the IETF or through the Independent Stream, from the first individual draft to the publication of the RFC. This is an individual effort, and the author's conclusions presented here are personal. There was no attempt to seek IETF consensus.
組織のWebサイトで述べられているように、IETFは、インターネットアーキテクチャの進化とインターネットの円滑な操作に関わるネットワークデザイナー、事業者、ベンダー、および研究者の大規模なオープンインターナショナルコミュニティです。」IETFによって生成された仕様は、IAB、IRTF、および独立したストリームからの文書とともにRFCシリーズに公開されています（RFC 8729に従って）。このメモでは、著者は、最初の個々のドラフトからRFCの出版まで、IETFまたは独立したストリームのアイデアを公開するのに関わる遅延を理解しようとしています。これは個々の努力であり、ここで提示された著者の結論は個人的です。IETFコンセンサスを探す試みはありませんでした。
The IETF keeps records of documents and process actions in the IETF Datatracker [TRKR]. The IETF Datatracker provides information about RFCs and drafts, from which we can infer statistics about the production system. We can measure how long it takes to drive a proposition from initial draft to final publication, and how these delays can be split between working group discussions, IETF reviews, IESG assessment, RFC Editor delays and final reviews by the authors -- or, for Independent Stream RFCs, draft production, reviews by the Independent Submissions Editor, conflict reviews, RFC Editor delays and final reviews. Tracker data is available for all RFCs, not just IETF Stream RFCs.
IETFは、IETF DataTracker [TRKR]でドキュメントとプロセスアクションを記録します。IETF DataTrackerはRFCとドラフトに関する情報を提供しています。そこから、生産システムに関する統計を推測できます。初期草案から最終出版物への命題を運転するのにかかる時間を測定することができます。独立したストリームRFC、ドラフト生産、競合レビュー、RFCエディタの遅延と最終レビューによるレビュー。Trackerデータは、IETFストリームRFCだけでなく、すべてのRFCで利用可能です。
Just measuring production delays may be misleading. If the IETF or the other streams simply rubber-stamped draft proposals and published them, the delays would be short but the quality and impact might suffer. We hope that most of the RFCs that are published are useful, but we need a way to measure that usefulness. We try to do that by measuring the number of references of the published RFCs in Semantic Scholar [SSCH], and also by asking the authors of each RFC in the sample whether the protocols and technologies defined in the RFCs were implemented and used on the Internet. The citations measured by the Semantic Scholar include citations in other RFCs and in Internet-Drafts. We also measure the number of references on the web, which provides some results but would be hard to automate.
生産遅延を測定するだけでは誤解を招く可能性があります。IETFまたは他のストリームが単にゴム印の提案を描き、それらを公開した場合、遅延は短くなりますが、品質と影響は苦しむ可能性があります。公開されているほとんどのRFCが役に立つことを願っていますが、その有用性を測定する方法が必要です。Semantic Scholar [SSCH]での発行されたRFCの参照数を測定し、RFCで定義されたプロトコルとテクノロジがインターネット上で実行されているかどうかをサンプルにサンプルに尋ねることによってそれを実行しようとします。。セマンティック学者によって測定された引用は、他のRFCの引用とインターネットドラフトを含みます。また、何らかの結果を提供するが自動化するのが難しいことになるWeb上の参照数も測定します。
In order to limit the resources required for this study, we selected at random 20 RFCs published in 2018, as explained in Section 2.2. The statistical sampling picked both IETF Stream and Independent Stream documents. For comparison purposes, we also selected at random 20 RFCs published in 1998 and 20 published in 2008. Limiting the sample to 20 out of 209 RFCs published in 2018 allows for in-depth analysis of each RFC, but readers should be reminded that the this is a small sample. The sample is too small to apply general statistical techniques and quantify specific ratios, and discussions of correlation techniques would be inappropriate. Instead, the purpose is to identify trends, spot issues, and document future work.
この研究に必要なリソースを制限するために、2.2項で説明したように、2018年に発行されたランダム20 RFCで選択しました。統計的サンプリングは、IETFストリームと独立したストリーム文書の両方を選びました。比較の目的で、私たちは1998年と20の209年に発行されたランダム20 RFCでも選択されています。サンプルを209年のうち209のうち209のうち209のRFCは各RFCの詳細な分析を可能にしますが、読者はこれを思い出させる必要があります。小さなサンプルです。サンプルは小さすぎて一般的な統計的技術を適用し、特定の比率を定量化し、相関技術の議論は不適切であろう。代わりに、目的はトレンド、スポットの問題、および将来の仕事を識別することです。
The information gathered for every RFC in the sample is presented in Section 3. In Section 4, we analyze the production process and the sources of delays, comparing the 2018 sample to the selected samples for 1998 and 2018. In Section 5.1, we present citation counts for the RFCs in the samples, and analyze whether citation counts could be used to evaluate the quality of RFCs.
サンプル内のすべてのRFCについて収集された情報はセクション3に示されています。第4章では、1998年と2018年の選択されたサンプルと2018年と2018年の選択されたサンプルとの比較を比較して、生産プロセスと遅延源を分析します。セクション5.1では、引用を紹介サンプル内のRFCをカウントし、引用数を使用してRFCの品質を評価できるかどうかを分析します。
The measurement of delays could be automated by processing dates and events recorded in the Datatracker. The measurement of published RFCs could be complemented by statistics on abandoned drafts, which would measure the efficiency of the IETF triaging process. More instrumentation would help understanding how large delays happen during working group processes. These potential next steps are developed in Section 6.
DATACKERに記録されている日付やイベントを処理することによって遅延の測定を自動化することができます。公開されたRFCの測定は、放棄されたドラフトに関する統計によって補完される可能性があり、これはIETF三重化プロセスの効率を測定するであろう。ワーキンググループプロセス中にどのように大きな遅延が起こるかを理解するのに役立ちます。これらの電位次のステップはセクション6で開発されています。
The study reported here started with a simple idea: take a sample of RFCs, and perform an in-depth analysis of the path from the first presentation of the idea to its publication, while also trying to access the success of the resulting specification. This requires defining the key milestones that we want to track, and drawing a random sample using an unbiased process.
ここで報告された研究は簡単なアイデアで始まりました：RFCのサンプルを取り、その考えの最初のプレゼンテーションからその出版物へのパスの詳細な分析を実行しながら、結果の仕様の成功にアクセスしようとしています。これには、トラックしたいキーマイルストーンを定義し、不偏プロセスを使用してランダムなサンプルを描画する必要があります。
The IETF Datatracker records a list of events for each document processed by IETF working groups. This has a high granularity, and also a high variability. Most documents start life as an individual draft, are adopted by a working group, undergo a Working Group Last Call, are submitted to the IESG, undergo an IETF Last Call and an IESG review, get eventually approved by the IESG, and are processed for publication by the RFC Editor, but there are exceptions. Some documents are first submitted to one working group and then moved to another. Some documents are published through the Independent Stream, and are submitted to the Independent Submissions Editor instead of the IESG.
IETF DataTrackerは、IETFワーキンググループによって処理された各文書のイベントのリストを記録します。これは粒度が高い、そしてまた高い変動性を有する。ほとんどのドキュメントは個々のドラフトとして生活を始めて、ワーキンググループが採用されている、ワークグループの最後のコールを受ける、IESGに提出され、IETFの最後のコールとIESGレビューを受け、最終的にIESGによって処理されます。RFCエディタによる出版物件がありますが、例外があります。一部のドキュメントは最初に1つのワーキンググループに送信され、次に別のワーキンググループに移動されます。一部のドキュメントは独立したストリームを通じて公開されており、IESGの代わりに独立した送信エディタに送信されます。
In order to simplify tabulation, we break the period from the submission of the first draft to the publication of the RFC into three big components:
集計を簡素化するために、最初のドラフトの提出から3つの大きなコンポーネントへのRFCの出版までの期間を破ります。
* The working group processing time, from the first draft to the start of the IETF last call;
* ワーキンググループの処理時間は、最初のドラフトからIETFの最後の呼び出しの開始まで。
* The IETF processing time, which lasts from the beginning of the IETF last call to the approval by the IESG, including the reviews by various directorates;
* IETFの処理時間。さまざまなディレクトリによるレビューを含むIESGの承認へのIETFの先頭から最後に続く。
* The RFC production, from approval by the IESG to publication, including the AUTH48 reviews.
* RFC制作は、AUTH48のレビューを含むIESGによる承認から出版物の承認を受けます。
For submissions to the Independent Stream, we don't have a working group. We consider instead the progression of the individual draft until the adoption by the Independent Submissions Editor (ISE) as the equivalent of the "Working Group" period, and the delay from adoption by the ISE until submission to the RFC Editor as the equivalent of the IETF processing time.
独立したストリームへの送信のために、私たちはワーキンググループを持っていません。代わりに、独立した提出エディタ（ISE）による個々のドラフトの進行が「ワーキンググループ」期間（ISE）と同等のものとして、RFCエディタへの採用からRFCエディタへの採用までの遅延を検討します。IETF処理時間
We measure the starting point of the process using the date of submission of the first draft listed on that RFC page in the IETF Datatracker. In most cases, this first draft is an individual draft that then resubmitted as a working group draft, or maybe resubmitted with a new name as the draft was searching for a home in an IETF working group, or before deciding for submission on the Independent Stream.
IETF DataTrackerのそのRFCページに記載されている最初のドラフトの送信日を使用して、プロセスの開始点を測定します。ほとんどの場合、この最初のドラフトは、ワーキンググループのドラフトとして再送信されている、またはドラフトがIETFワーキンググループ内のホームを検索しているため、または独立したストリームでの送信のために決定する前に、新しい名前で再送信される個別のドラフトです。。
The IETF Datatracker entries for RFCs and drafts do not _always_ list working group events like Working Group Last Call. The only intermediate event that we list between the first draft and the submission to the IESG is the working group adoption, for which we use the date of submission of version 00 of the draft eventually published as RFC. We also use that date (of submission of version 00) for drafts submitted to the Independent Stream.
RFCとドラフトのIETFデータマッキングエントリは、ワーキンググループの最後の呼び出しなどのワーキンググループイベントを一覧表示しません。最初の草案とIESGへの提出の間に私たちが一覧表示する唯一の中間イベントは、最終的にRFCとして公開されたドラフトのバージョン00の提出日を使用しています。独立したストリームに提出されたドラフトのその日（バージョン00の提出）も使用します。
Basic production mechanisms could be evaluated by processing data from the IETF Datatracker, but subjective data requires manual assessment of results, which can be time-consuming. Since our resources are limited, we will only perform this analysis for a small sample of RFCs, selected at random from the list of RFCs approved in 2018. Specifically, we will pick 20 RFC numbers at random between:
基本生産メカニズムは、IETFデータマッキャーからのデータを処理することによって評価できますが、主観的なデータでは結果の手動評価が必要です。これは時間がかかる可能性があります。当社のリソースは限られているので、2018年に承認されたRFCのリストからランダムに選択されたRFCの小さなサンプルについてのみこの分析を実行します。具体的には、：
* RFC 8307, published in January 2018, and
* 2018年1月に発行されたRFC 8307、そして
* RFC 8511, published December 2018.
* 2018年12月に発行されたRFC 8511。
The list of 20 selected RFCs is: RFC 8411, RFC 8456, RFC 8446, RFC 8355, RFC 8441, RFC 8324, RFC 8377, RFC 8498, RFC 8479, RFC 8453, RFC 8429, RFC 8312, RFC 8492 , RFC 8378, RFC 8361, RFC 8472, RFC 8471, RFC 8466, RFC 8362, and RFC 8468.
選択したRFCのリストは、RFC 8411、RFC 8456、RFC 8446、RFC 8441、RFC 8355、RFC 8377、RFC 8498、RFC 8479、RFC 8453、RFC 8429、RFC 8312、RFC 8492、RFC 8378、RFC 8361、RFC 8472、RFC 8471、RFC 8466、RFC 8362、およびRFC 8468。
When evaluating delays and impact, we will compare the year 2018 to 2008 and 1998, 10 and 20 years ago. To drive this comparison, we pick 20 RFCs at random among those published in 2008, and another 20 among those published in 1998.
遅延と影響を評価するときは、2018年から2008年と1998年、10年前に比較します。この比較を推進するために、2008年に発行されたものの中で、ランダムに20のRFCを選択し、1998年に発行されたものの中でさらに20。
The list of the 20 randomly selected RFCs from 2008 is: RFC 5227, RFC 5174, RFC 5172, RFC 5354, RFC 5195, RFC 5236, RFC 5348, RFC 5281, RFC 5186, RFC 5326, RFC 5277, RFC 5373, RFC 5404, RFC 5329, RFC 5283, RFC 5358, RFC 5142, RFC 5271, RFC 5349, and RFC 5301.
2008年からのランダムに選択されたRFCのリストは、RFC 5227、RFC 5174、RFC 5172、RFC 5195、RFC 5195、RFC 5236、RFC 5348、RFC 5281、RFC 5186、RFC 5373、RFC 5404、RFC 5329、RFC 5283、RFC 5358、RFC 5142、RFC 5271、RFC 5349、RFC 5301。
The list of the 20 randomly selected RFCs from 1998 is: RFC 2431, RFC 2381, RFC 2387, RFC 2348, RFC 2391, RFC 2267, RFC 2312, RFC 2448, RFC 2374, RFC 2398, RFC 2283, RFC 2382, RFC 2289, RFC 2282, RFC 2404, RFC 2449, RFC 2317, RFC 2394, RFC 2297, and RFC 2323.
1998年からのランダムに選択されたRFCのリストは、RFC 2431、RFC 2381、RFC 2387、RFC 2391、RFC 2267、RFC 2312、RFC 2448、RFC 2374、RFC 2398、RFC 2283、RFC 2289、RFC 2289、RFC 2282、RFC 2404、RFC 2449、RFC 2317、RFC 2394、RFC 2297、およびRFC 2323。
The following abbreviations are used in the tables:
以下の略語がテーブルで使用されています。
BCP Best Current Practice Exp Experimental Info Informational PS Proposed Standard DS Draft Standard [This maturity level was retired by RFC 6410.]
BCP BEST現在の練習EXP実験情報情報PS提案された標準DSドラフト基準[この満期レベルはRFC 6410によって引退されました。]
In addition, Status is as defined in RFC 2026, and Stream is as defined in RFC 8729.
さらに、ステータスはRFC 2026で定義されており、ストリームはRFC 8729で定義されているとおりです。
We review each of the RFCs listed in Section 2.2 for the year 2018, trying both to answer the known questions and to gather insight for further analyses. In many cases, the analysis of the data is complemented by direct feedback from the RFC authors.
私たちは、2018年の2.2号にリストされている各RFCを見直し、既知の質問に答えて、さらなる分析のための洞察を集めることを目的としています。多くの場合、データの分析はRFC著者からの直接フィードバックによって補完されます。
"IANA Registration for the Cryptographic Algorithm Object Identifier Range" [RFC8411]:
「暗号化アルゴリズムオブジェクト識別子範囲のIANA登録」[RFC8411]：
Status (Length): Informational (5 pages) Overview: 4 individual drafts First draft: 2017-05-08 Last Call start: 2017-10-09 IESG eval. start: 2017-12-28 IESG approved: 2018-02-26 (draft 03) AUTH48 start: 2018-04-20 AUTH48 complete: 2018-07-17 Published: 2018-08-06 IANA action: create table
ステータス（長さ）：情報（5ページ）概要：4個人のドラフトファーストドラフト：2017-05-08最後のコールスタート：2017-10-09 IESG EVAL。スタート：2017-12-28 IESG承認済み：2018-02-26（ドラフト03）AUTH48スタート：2018-04-20 AUTH48 COMPLETE：2018-07-17公開：2018-08-06 IANAアクション：テーブルの作成
This RFC was published from the individual draft, which was not resubmitted as a working group draft.
このRFCは個々のドラフトから公開され、これはワーキンググループのドラフトとして再送信されていません。
The draft underwent minor copy editing before publication.
ドラフトは出版前にマイナーコピー編集を受けました。
Some but not all of the long delay in AUTH48 is due to clustering with [RFC8410]. MISSREF state concluded on 2018-05-09 and the document re-entered AUTH48 at once. AUTH48 lasted over two months after that. (For state definitions, see <https://www.rfc-editor.org/about/queue/#state_def>.)
AUTH48の長い遅延のすべてが[RFC8410]のクラスタリングによるものもあります。Missrefの州は2018-05-09で終了し、文書はAUTH48に一度に再入力しました。AUTH48その後2ヶ月以上続いた。（状態定義の場合は、<https://www.rfc-editor.org/about/queue/#state_def>を参照してください。）
The time after AUTH48 and before publication (3 weeks) partly overlaps with travel for IETF 102 and is partly due to coordinating the cluster.
AUTH48以降の時間（3週間）は、IETF 102のための移動と一部の移動と重なり、部分的にはクラスタの調整によるものです。
"Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance" [RFC8456]:
"ソフトウェア定義ネットワーキング（SDN）コントローラのパフォーマンスのベンチマーク方法論" [RFC8456]：
Status (Length): Informational (64 pages) Overview: 2 individual drafts; 9 WG drafts First draft: 2015-03-23 WG adoption: 2015-10-18 Last Call start: 2018-01-19 IESG eval. start: 2018-02-27 IESG approved: 2018-05-25 AUTH48 start: 2018-08-31 AUTH48 complete: 2018-10-16 Published: 2018-10-30
ステータス（長さ）：情報（64ページ）の概要：2個の個々のドラフト。9 WGドラフトファーストドラフト：2015-03-23 WG採用：2015-10-18最後のコールスタート：2018-01-19 IESG eval。開始：2018-02-27 IESG承認済み：2018-05-25 AUTH 48スタート：2018-08-31 AUTH 48完成品：2018-10-16公開：2018-10-30
The draft underwent extensive copy editing, covering use of articles, syntax, and word choice. The changes are enough to cause pagination differences. The "diff" tool marks pretty much every page as changed. Some diagrams see change in protocol elements like message names.
ドラフトは、記事、構文、および単語の選択を網羅した広範なコピー編集を受けました。変化は、ページ付けの違いを引き起こすのに十分です。「差分」ツールは、変更されたページごとにほとんどすべてのページをマークします。いくつかの図は、メッセージ名のようなプロトコル要素の変更を参照してください。
According to the author, the experience of producing this document mirrors a typical one in the Benchmarking Methodologies Working Group (BMWG). There were multiple authors in multiple time zones, which slowed down the AUTH48 process somewhat, although the AUTH48 delay of 46 days is only a bit longer than the average draft.
著者によると、この文書を生産する経験は、ベンチマーク方法論ワーキンググループ（BMWG）に典型的なものを照射します。46日のAUT48の遅延は平均ドラフトより少し長いのであるが、複数のタイムゾーンに複数の著者がいました。
The RFC was part of cluster with [RFC8455].
RFCは[RFC8455]のクラスターの一部でした。
BMWG publishes Informational RFCs centered around benchmarking, and the methodologies in RFC 8456 have been implemented in benchmarking products.
BMWGはベンチマークを中心とした情報RFCを公開し、RFC 8456の方法論はベンチマーク製品に実装されています。
"The Transport Layer Security (TLS) Protocol Version 1.3" [RFC8446], as the title indicates, defines the new version of the TLS protocol. From the IETF Datatracker, we extract the following:
「Transport Layer Security（TLS）プロトコルバージョン1.3」[RFC8446]は、TILSプロトコルの新しいバージョンを定義します。IETF DataTrackerから、次のように抽出します。
Status (Length): Proposed Standard (160 pages) Overview: 29 WG drafts First draft: 2014-04-17 Last Call start: 2018-02-15 IESG eval. start: 2018-03-02 IESG approved: 2018-03-21 (draft 28) AUTH48 start: 2018-06-14 AUTH48 complete: 2018-08-10 Published: 2018-08-10
ステータス（長さ）：提案された標準（160ページ）の概要：29 WGドラフトファーストドラフト：2014-04-17最後のコールスタート：2018-02-15 IESG eval。開始：2018-03-02 IESG承認済み：2018-03-21（ドラフト28）AUTH48スタート：2018-06-14 AUTH48 COMPLETE：2018-08-10公開：2018-08-10
This draft started as a WG effort.
このドラフトはWGの努力として始まりました。
The RFC was a major effort in the IETF. Working group participants developed and tested several implementations. Researchers analyzed the specifications and performed formal verifications. Deployment tests outlined issues that caused extra work when the specification was almost ready. This complexity largely explains the time spent in the working group.
RFCはIETFに大きな努力でした。ワーキンググループ参加者はいくつかの実装を開発してテストしました。研究者らは仕様を分析し、正式な検証を行った。展開テストは、仕様がほぼ準備が整ったときに追加の作業を引き起こした問題を概説しました。この複雑さは、ワーキンググループに費やされた時間をほとんど説明しています。
Comparing the final draft to the published version, we find relatively light copy editing. It includes explaining acronyms on first use, clarifying some definitions standardizing punctuation and capitalization, and spelling out some numbers in text. This generally fall in the category of "style", although some of the clarifications go into message definitions. However, that simple analysis does not explain why the AUTH48 phase took almost two months.
Final Draftを公開バージョンと比較すると、比較的軽いコピー編集があります。それは最初の使用時に頭字語を説明すること、句読点と資本化を標準化するいくつかの定義を明確にし、いくつかの数字をテキストにスペルを付けます。これは一般に「スタイル」のカテゴリに入りますが、明確化のいくつかはメッセージ定義に入ります。しかしながら、その単純な分析は、AUTH48フェーズがほぼ2ヶ月かかった理由を説明しない。
This document's AUTH48 process was part of the "GitHub experiment", which tried to use GitHub pull requests to track the AUTH48 changes and review comments. The RFC Production Center (RPC) staff had to learn using GitHub for that process, and this required more work than the usual RFC. The author and AD thoroughly reviewed each proposed edit, accepting some and rejecting some. The concern there was that any change in a complex specification might affect a protocol that was extensively reviewed in the working group, but of course these reviews added time to the AUTH48 delays.
このドキュメントのauth48プロセスは、gith48の変更を追跡し、コメントを確認するためにGithub Pull要求を使用しようとしました。RFC生産センター（RPC）のスタッフはそのプロセスのためにGitHubを使って学ぶ必要があり、これは通常のRFCよりも多くの作業を必要としました。著者と広告は、提案された編集を徹底的に見直し、いくつかを受け入れて拒否します。懸念は、複雑な仕様の変更は、ワーキンググループで広く検討されたプロトコルに影響を与える可能性がありますが、もちろん、これらのレビューにAUTH48の遅延までの時間が付加されている可能性がありました。
There are 21 implementations listed in the Wiki of the TLS 1.3 project [TLS13IMP]. It has been deployed on major browsers, and is already used in a large fraction of TLS connections.
TLS 1.3プロジェクト[TLS13IMP]のWikiには21の実装がリストされています。それは主要ブラウザに展開されており、すでに大部分のTLS接続で使用されています。
"Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks" [RFC8355] is an Informational RFC. It originated from an informational use-case draft; it was mostly used for the BOF creating the WG, and then to drive initial work and evolutions from the WG.
「ネットワーク（Spring）ネットワークにおけるソースパケットルーティングの回復力の使用例」[RFC8355]は情報RFCです。それは情報ユースケースドラフトから発生しました。それはほとんどWGを作成し、次にWGから最初の作業と進化を推進するために、それからほとんど使用されました。
Status (Length): Informational (13 pages) Overview: 2 individual drafts; 13 WG drafts First draft: 2014-01-31 WG adoption: 2014-05-13 Last Call start: 2017-04-20 IESG eval. start: 2017-05-04 (draft 09) IESG approved: 2017-12-19 (draft 12) AUTH48 start: 2018-03-12 AUTH48 complete: 2018-03-27 Published: 2018-03-28
ステータス（長さ）：情報（13ページ）の概要：2個の個々のドラフト。13 WGドラフトファーストドラフト：2014-01-31 WG採用：2014-05-13最後のコールスタート：2017-04-20 IESG EVAL。開始：2017-05-04（ドラフト09）IESG承認済み：2017-12-19（ドラフト12）AUTH48スタート：2018-03-12 AUTH48 COMPLETE：2018-03-27公開：2018-03-28
Minor set of copy edits, mostly for style.
マイナーなコピー編集のセット、主にスタイルのため。
No implementation of the RFC itself, but the technology behind it (such as Segment Routing Architecture [RFC8402] and TI-LFA [TI-LFA]) is widely implemented and deployment is ongoing.
RFC自体の実装はありませんが、その背後にある技術（Segment Routing Architecture [RFC8402]やTI-LFA [TI-LFA]など）が広く実装されており、展開が進行中です。
According to participants in the discussion, the process of adoption of the source packet routing standards was very contentious. The establishment of consensus at both the working group level and the IETF level was difficult and time-consuming.
議論の参加者によると、ソースパケットルーティング基準を採用するプロセスは非常に一般的でした。ワーキンググループレベルとIETFレベルの両方でコンセンサスの確立は困難で時間がかかりました。
"Bootstrapping WebSockets with HTTP/2" [RFC8441]
"HTTP / 2を使ったWebSocketsのブートストラップ] [RFC8441]
Status (Length): Proposed Standard (8 pages) Overview: 3 individual drafts; 8 WG drafts; Updates RFC 6455 First draft: 2017-10-15 WG adoption: 2017-12-19 Last Call start: 2018-05-07 (draft 05) IESG eval. start: 2018-05-29 (draft 06) IESG approved: 2018-06-18 (draft 07) AUTH48 start: 2018-08-13 AUTH48 complete: 2018-09-15 Published: 2018-09-18 IANA action: table entries
ステータス（長さ）：提案された標準（8ページ）の概要：3個のドラフト。8 WGドラフト;アップデートRFC 6455ファーストドラフト：2017-10-15 WG採用：2017-12-19最後のコールスタート：2018-05-07（ドラフト05）IESG EVAL。開始：2018-05-29（ドラフト06）IESG承認：2018-06-18（ドラフト07）AUTH48スタート：2018-08-13 AUTH48 COMPLETE：2018-09-15公開：2018-09-18 IANA ACTION：TABLEエントリ
This RFC defines the support of WebSockets in HTTP/2, which is different from the mechanism defined for HTTP/1.1 in [RFC6455]. The process was relatively straightforward, involving the usual type of discussions, some on details and some on important points.
このRFCはHTTP / 2内のWebSocketのサポートを定義します。これは[RFC6455]のHTTP / 1.1に定義されているメカニズムとは異なります。このプロセスは、通常の種類の議論、詳細、およびいくつかの重要なポイントについては、比較的簡単でした。
Comparing the final draft and published RFC shows a minor set of copy edits, mostly for style. However, the author recalls a painful process. The RFC includes many charts and graphs that were very difficult to format correctly in the author's production process that involved conversions from markdown to XML, and then from XML to text. The author had to get substantial help from the RFC Editor.
最後のドラフトと公開されたRFCの比較は、主にスタイルのためのマイナーなコピー編集のセットを示しています。しかし、著者は痛みを伴うプロセスを思い出します。RFCには、マークダウンからXMLへの変換、次にXMLからテキストへの変換を含む作者の製造プロセスで正しくフォーマットすることが非常に困難である多くのチャートとグラフが含まれています。作者はRFCエディタから実質的な助けを受ける必要がありました。
There are several implementations, including Firefox and Chrome, making RFC 8441 a very successful specification.
FirefoxとChromeなど、RFC 8441を含むいくつかの実装があります。
"DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?" [RFC8324]. This is an opinion piece on DNS development, published on the Independent Stream.
"DNSプライバシー、承認、特別な用途、エンコード、文字、マッチング、およびルート構造：別の外観の時間？"[RFC8324]。これは、独立したストリームで公開されたDNS開発に関する意見作品です。
Status (Length): Informational (29 pages) Overview: 5 individual drafts; Independent Stream First draft: 2017-06-02 ISE review start: 2017-07-10 (draft 03) IETF conflict review start: 2017-10-29 Approved: 2017-12-18 (draft 04) AUTH48 start: 2018-01-29 (draft 05) AUTH48 complete: 2018-02-26 Published: 2018-02-27
ステータス（長さ）：情報（29ページ）の概要：5個の個々のドラフト。Independent Streamファーストドラフト：2017-06-02 ISEレビュー開始：2017-07-10（ドラフト03）IETF競合レビュー開始：2017-10-29承認：2017-12-18（ドラフト04）AUTH48スタート：2018-01-29（ドラフト05）AUTH48 COMPLETE：2018-02-26公開：2018-02-27
This RFC took only 9 months from first draft to publication, which is the shortest in the 2018 sample set. In part, this is because the text was privately circulated and reviewed by the ISE's selected experts before the first draft was published. The nature of the document is another reason for the short delay. It is an opinion piece and does not require the same type of consensus building and reviews as a protocol specification.
このRFCは、2018年のサンプルセットの最短である最初のドラフトから出版までわずか9ヶ月かかりました。一部では、これは、最初のドラフトが公開される前に、テキストが個人的に循環され、ISEの選択された専門家によって見直されたためです。文書の性質は短い遅延のもう一つの理由です。それは意見作品であり、同じタイプのコンセンサスビルディングとレビューをプロトコル仕様として必要としません。
Comparing the final draft and the published version shows only minor copy edits, mostly for style. According to the author, this is because he knows how to write in RFC style with the result that his documents often need a minimum of editing. He also makes sure that the document on which the RFC Production Center starts working already has changes discussed and approved during Last Call and IESG review incorporated, rather than expecting the Production Center to operate off of notes about changes to be made.
最後のドラフトと公開されているバージョンの比較には、ほとんどのスタイルのためのマイナーコピー編集のみが表示されます。著者によると、これは彼がRFCスタイルで書く方法を知っているため、彼の文書は最低限の編集を必要とすることが多い結果です。また、RFC生産センターが既に働いている文書は、製造センターが変更されるべき注意事項から運営されることを期待するのではなく、最後のコールとIESG Reviewが組み込まれています。
"Transparent Interconnection of Lots of Links (TRILL): Multi-Topology" [RFC8377]
"ロットの透明な相互接続（トリル）：マルチトポロジー" [RFC8377]
Status (Length): Proposed Standard (20 pages) Overview: 3 individual drafts; 7 WG drafts; Updates RFCs 6325 and 7177 First draft: 2013-09-03 WG adoption: 2015-09-01 Last Call start: 2018-02-19 (draft 05) IESG eval. start: 2018-03-06 (draft 05) IESG approved: 2018-03-12 (draft 06) AUTH48 start: 2018-04-20 (draft 06) AUTH48 complete: 2018-07-31 Published: 2018-07-31 IANA action: table entries
ステータス（長さ）：提案された標準（20ページ）の概要：3個の個々のドラフト。7 WGドラフト;RFCS 6325および7177ファーストドラフト：2013-09-03 WG採用：2015-09-01最後のコールスタート：2018-02-19（ドラフト05）IESG EVAL。開始：2018-03-06（ドラフト05）IESG承認済み：2018-03-12（ドラフト06）AUTH48スタート：2018-04-20（ドラフト06）AUTH48完成品：2018-07-31公開：2018-07-31IANA対応：テーブルエントリ
Minor set of copy edits, mostly for style, also clarity.
マイナーなコピー編集のセット、主にスタイルのために、また明確にします。
"A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)" [RFC8498].
「セッション開始プロトコル（SIP）」[RFC8498]の「発信コール転送（CDIV）セッションケースのPサービスユーザヘッダフィールドパラメータ。
Status (Length): Informational (15 pages) Overview: 5 individual drafts; 9 WG drafts First draft: 2016-03-21 WG adoption: 2017-05-15 Last Call start: 2018-10-12 (draft 05) IESG eval. start: 2018-11-28 (draft 07) IESG approved: 2018-12-11 (draft 08) AUTH48 start: 2019-01-28 AUTH48 complete: 2019-02-13 Published: 2019-02-14 IANA action: table rows added.
ステータス（長さ）：情報（15ページ）の概要：5個の個々のドラフト。9 WGドラフトファーストドラフト：2016-03-21 WG採用：2017-05-15最後のコール開始：2018-10-12（ドラフト05）IESG eval。開始：2018-11-28（ドラフト07）IESG承認済み：2018-12-11（ドラフト08）AUTH48スタート：2019-01-28 AUTH48 Comserti：2019-02-13公開：2019-02-14 IANAアクション：テーブル行が追加されました。
Copy edits for style, but also clarification of ambiguous sentences.
スタイルのための編集をコピーするだけでなく、あいまいな文の明確化。
"Storing Validation Parameters in PKCS#8" [RFC8479]
「PKCS＃8の検証パラメータの保存[RFC8479]
Status (Length): Informational (8 pages) Overview: 5 individual drafts; Independent Stream First draft: 2017-08-08 ISE review start: 2018-12-10 (draft 00) IETF conflict review start: 2018-03-29 Approved: 2018-08-20 (draft 03) AUTH48 start: 2018-09-20 (draft 04) AUTH48 complete: 2018-09-25 Published: 2018-09-26
ステータス（長さ）：情報（8ページ）の概要：5個の個々のドラフト。Independent Streamファーストドラフト：2017-08-08 ISEレビュー開始：2018-12-10（00）IETF紛争レビュー開始：2018-03-29承認：2018-08-20（ドラフト03）AUTH48開始：2018-09-20（ドラフト04）AUTH48完成品：2018-09-25公開：2018-09-26
The goal of the draft was to document what the gnutls implementation was using for storing provably generated RSA keys. This is a short RFC that was published relatively quickly, although discussion between the author, the Independent Submissions Editor, and the IESG lasted several months. In the initial conflict review, the IESG asked the ISE to not publish this document before IETF working groups had an opportunity to pick up the work. The author met that requirement by a presentation to the SECDISPATCH WG during IETF 102. Since no WG was interested in picking up the work, the document progressed on the Independent Stream.
下書きの目的は、実績のあるRSAキーを保存するためにGNUTLS実装が使用していたものを文書化することでした。これは比較的迅速に公開された短いRFCですが、著者、独立した投稿エディタ、およびIESGは数ヶ月続きました。初期の競合レビューでは、IESGはIETFワーキンググループがその作業を拾う機会がある前に、ISEがこの文書を公開しないように依頼しました。著者は、IETF 102の間にSecDispatch WGへのプレゼンテーションによるその要件を満たしました。
Very minor set of copy edits, moving some references from normative to informative.
単一のコピー編集のセット、規範的な言及から有益なものへの参照を移動します。
The author is not aware of other implementations than gnutls relying on this RFC.
作者は、このRFCに頼るGNUTLSよりも他の実装を認識していません。
"Framework for Abstraction and Control of TE Networks (ACTN)" [RFC8453]
「TEネットワーク（ACTN）の抽象化と制御のためのフレームワーク[RFC8453]
Status (Length): Informational (42 pages) Overview: 3 individual drafts; 16 WG drafts First draft: 2015-06-15 WG adoption: 2016-07-15 Out of WG: 2018-01-26 (draft 11) Expert review requested: 2018-02-13 Last Call start: 2018-04-16 (draft 13) IESG eval. start: 2018-05-16 (draft 14) IESG approved: 2018-06-01 (draft 15) AUTH48 start: 2018-08-13 AUTH48 complete: 2018-08-20 Published: 2018-08-23 IANA action: table rows added.
ステータス（長さ）：情報（42ページ）の概要：3個の個々のドラフト。16 WGドラフトファーストドラフト：2015-06-15 WG採用：2016-07-15 OUT OUT：2018-01-26（ドラフト11）エキスパートレビュー要求：2018-02-13最後のコールスタート：2018-04-16（ドラフト13）IESG eval。開始：2018-05-16（ドラフト14）IESG承認済み：2018-06-01（ドラフト15）AUTH48スタート：2018-08-13 AUTH48 COMPLETE：2018-08-20公開：2018-08-23 IANAアクション：テーブル行が追加されました。
Minor copy editing.
マイナーコピー編集
"Deprecate Triple-DES (3DES) and RC4 in Kerberos" [RFC8429]
「KerberosでのトリプルDES（3DES）とRC4を廃止する」[RFC8429]
Status (Length): BCP (10 pages) Overview: 6 WG drafts First draft: 2017-05-01 Last Call start: 2017-07-16 (draft 03) IESG eval. start: 2017-08-18 (draft 04) IESG approved: 2018-05-25 (draft 05) AUTH48 start: 2018-07-24 AUTH48 complete: 2018-10-31 Published: 2018-10-31 IANA action: table rows added.
ステータス（長さ）：BCP（10ページ）概要：6 WGドラフトファーストドラフト：2017-05-01最終呼び出し開始：2017-07-16（ドラフト03）IESG EVAL。開始：2017-08-18（ドラフト04）IESG承認済み：2018-05-25（ドラフト05）AUTH48スタート：2018-07-24 AUTH48完了：2018-10-31公開：2018-10-31 IANAアクション：テーブル行が追加されました。
This draft started as a working group effort.
このドラフトはワーキンググループの努力として始まりました。
This RFC recommends deprecating two encryption algorithms that are now considered obsolete and possibly broken. The document was sent back to the WG after the first Last Call, edited, and then there was a second Last Call. The delay from first draft to Working Group Last Call was relatively short, but the number may be misleading. The initial draft was a replacement of a similar draft in the KITTEN Working Group, which stagnated for some time before the CURDLE Working Group took up the work. The deprecation of RC4 was somewhat contentious, but the WG had already debated this prior to the production of this draft, and the draft was not delayed by this debate.
このRFCは、現在時代遅れであると見なされる2つの暗号化アルゴリズムを廃止することをお勧めします。最初の最後の呼び出しの後に文書はWGに送り返され、編集された後、2番目の呼び出しがありました。最初のドラフトからワーキンググループの最後の呼び出しまでの遅延は比較的短かったが、数は誤解を招く可能性がある。初期のドラフトは、カールワーキンググループが仕事を踏み出した、キットワーキンググループでも同様のドラフトを置き換えました。RC4の減価償却はやや議論的でしたが、WGはこのドラフトの制作の前にすでにこれを議論しており、草稿はこの議論によって遅れていませんでした。
Most of the 280 days between IETF LC and IESG approval were because the IESG had to talk about whether this document should obsolete RFC 4757 or move it to Historic status, and no one was really actively pushing that discussion for a while.
IETF LCとIESGの承認の間の280日の大部分は、この文書がRFC 4757を廃止すべきか、または歴史的な地位に移動するべきかどうかについて話をしなければならなかったためで、いずれにしばらくの間積極的にその議論を推進していなかったためです。
The 99 days in AUTH48 are mostly because one of the authors was a sitting AD, and those duties ended up taking precedence over reviewing this document.
AUTH48の99日は主に著者の1人が座席広告であり、これらの職務はこの文書の見直しよりも優先されました。
Minor copy editing, for style.
スタイルのためのマイナーコピー編集。
The implementation of the draft would be the actual removal of support for 3DES and RC4 in major implementations. This is happening, but very slowly.
ドラフトの実装は、主な実装における3DESとRC4のサポートの実際の削除です。これは起こっていますが、とてもゆっくりとしています。
"CUBIC for Fast Long-Distance Networks" [RFC8312]
「高速距離ネットワーク用立方体」[RFC8312]
Status (Length): Informational (18 pages) Overview: 2 individual drafts; 8 WG drafts First draft: 2014-09-01 WG adoption: 2015-06-08 Last Call start: 2017-09-18 (draft 06) IESG eval. start: 2017-10-04 IESG approved: 2017-11-14 (draft 07) AUTH48 start: 2018-01-08 AUTH48 complete: 2018-02-07 Published: 2018-02-07 IANA action: table rows added.
ステータス（長さ）：情報（18ページ）の概要：2個のドラフト。第1回ドラフト初のドラフト：2014-09-01 WG採用：2015-06-08最後のコールスタート：2017-09-18（ドラフト06）IESG eval。スタート：2017-10-04 IESG承認済み：2017-11-14（ドラフト07）AUTH48 START：2018-01-08 AUTH 48 Complete：2018-02-07公開：2018-02-07 IANA Action：テーブル行が追加されました。
Minor copy editing, for style.
スタイルのためのマイナーコピー編集。
The TCP congestion control algorithm Cubic was first defined in 2005, was implemented in Linux soon after, and was implemented in major OSes after that. After some debates from 2015 to 2015, the TCPM Working Group adopted the draft, with a goal of documenting Cubic in the RFC Series. According to the authors, this was not a high-priority effort, as Cubic was already implemented in multiple OSes and documented in research papers. At some point, only one of the authors was actively working on the draft. This may explain why another two years was spent progressing the draft after adoption by the WG.
TCP輻輳制御アルゴリズムCubicは2005年に最初に定義され、その後すぐにLinuxで実装され、その後主要OSで実装されました。2015年から2015年までの議論の後、TCPMワーキンググループはドラフトを採用し、RFCシリーズの立方体を文書化することを目的として。著者によると、これは、立方体がすでに複数のOSで実装され、研究論文に文書化されていたため、優先順位の高い努力ではありませんでした。ある時点で、著者のうちの1つだけが積極的にドラフトに取り組んでいました。これにより、WGによる採用後に草案の進展に費やされた理由を説明するかもしれません。
The RFC publication may or may not have triggered further implementations. On the other hand, several OSes picked up bug fixes from the draft and the RFC.
RFCの出版物は、さらなる実装を引き起こした場合、または発生していない可能性があります。一方、いくつかのOSはドラフトとRFCからバグ修正を拾いました。
"Secure Password Ciphersuites for Transport Layer Security (TLS)" [RFC8492]
"トランスポート層セキュリティのための安全なパスワード暗号（TLS）" [RFC8492]
Status (Length): Informational (40 pages) Overview: 10 individual drafts; 8 WG drafts; Independent Stream First draft: 2012-09-07 Targeted to ISE: 2016-08-05 ISE review start: 2017-05-10 (draft 01) IETF conflict review start: 2017-09-04 Approved: 2017-10-29 (draft 02) AUTH48 start: 2018-10-19 (draft 05) AUTH48 complete: 2019-02-19 Published: 2019-02-21 IANA action: table rows added.
ステータス（長さ）：情報（40ページ）の概要：10個の個々のドラフト。8 WGドラフト;Independent Stream First Draft：2012-09-07 ISEのターゲット：2016-08-05 ISEレビュー開始：2017-05-10（ドラフト01）IETF競合レビュー開始：2017-09-04承認：2017-10-29（ドラフト02）AUTH48スタート：2018-10-19（ドラフト05）AUTH48完了：2019-02-19公開：2019-02-21 IANAアクション：テーブル行が追加されました。
This RFC has a complex history. The first individual draft was submitted to the TLS Working Group on September 7, 2012. It progressed there, and was adopted by the WG after 3 revisions. There were then 8 revisions in the TLS WG, until the WG decided to not progress it. The draft was parked in 2013 by the WG chairs after failing to get consensus in WG Last Call. The AD finally pulled the plug in 2016, and the draft was then resubmitted to the ISE.
このRFCには複雑な歴史があります。最初の個々のドラフトは2012年9月7日にTLSワーキンググループに提出されました。WGが進歩しないことを決定するまで、TLS WGに8つの修正がありました。ドラフトは2013年にWGの最後の呼び出しでコンセンサスを取得できなかった後、WGの椅子によって駐車されました。ADは最後に2016年にプラグを引っ張り、その後、草案はISEに再登録されました。
At that point, the author was busy and was treating this RFC with a low priority because, in his words, it would not be a "real RFC". There were problems with the draft that only came up late. In particular, it had to wait for a change in registry policy that only came about with the publication of TLS 1.3, which caused the draft to be published after RFC 8446, and also required adding references to TLS 1.3. The author also got a very late comment while in AUTH48 that caused some rewriting. Finally, there was some IANA issue with the extension registry where a similar extension was added by someone else. The draft was changed to just use it.
その時点で、著者は忙しかった、このRFCを最優先事項で扱っていましたが、彼の言葉では「実際のRFC」ではないでしょう。遅くなったのはドラフトに問題がありました。特に、TLS 1.3のパブリケーションと共にのみ来たレジストリポリシーの変更を待たなければなりませんでした。これは、RFC 8446の後にドラフトを公開し、TLS 1.3への参照を追加する必要がありました。著者は、auth48にある間に非常に遅いコメントを得ました。最後に、同様のエクステンションが他の人によって追加された拡張レジストリに関するIANA問題がありました。ドラフトはそれを使用するために変更されました。
Changes in AUTH48 include adding a reference to TLS 1.3, copy editing for style, some added requirements, added paragraphs, and changes in algorithms specification.
AUTH48の変更には、TLS 1.3への参照、スタイルのコピー編集、追加の要件、追加の要件、追加された段落、およびアルゴリズム仕様の変更が含まれます。
"Signal-Free Locator/ID Separation Protocol (LISP) Multicast" [RFC8378] is an Experimental RFC, defining how to implement Multicast in the LISP architecture.
「シグナルフリーロケータ/ ID分離プロトコル（LISP）マルチキャスト」[RFC8378]は実験的なRFCで、LISPアーキテクチャにマルチキャストを実装する方法を定義しています。
Status (Length): Experimental (21 pages) Overview: 5 individual drafts; 10 WG drafts First draft: 2014-02-28 WG adoption: 2015-12-21 Last Call start: 2018-02-13 (draft 07) IESG eval. start: 2018-02-28 (draft 08) IESG approved: 2018-03-12 (draft 09) AUTH48 start: 2018-04-23 AUTH48 complete: 2018-05-02 Published: 2018-05-02
ステータス（長さ）：実験（21ページ）概要：5個の個々のドラフト。Last Call Start：2015-02-21最後のコール開始：2018-02-13（ドラフト07）IESG eval。開始：2018-02-28（ドラフト08）IESG承認済み：2018-03-12（ドラフト09）AUTH48スタート：2018-04-23 AUTH48 COMPLETE：2018-05-02公開：2018-05-02
Preparing the RFC took more than 4 years. According to the authors, they were not aggressively pushing it and just let the working group process decide to pace it. They also did implementations during that time.
RFCの準備は4年以上かかりました。著者によると、彼らはそれを積極的に押し上げず、ワーキンググループプロセスをそれをペースにすることにしました。彼らはまたその間に実装をしました。
Minor copy editing, for style.
スタイルのためのマイナーコピー編集。
The RFC was implemented by lispers.net and Cisco, and it was used in doing IPv6 multicast over IPv4 unicast/multicast at the Olympics in PyeungChang. The plan is to work on a Proposed Standard once the experiment concludes.
RFCはLispers.netとCiscoによって実装され、PyeungchangのオリンピックでIPv4ユニキャスト/マルチキャストを介してIPv6マルチキャストを行うのに使用されました。実験が終了すると、計画は提案された標準に取り組むことです。
"Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic" [RFC8361]
「たくさんのリンク（トリル）の透明な相互接続：アクティブアクティブブロードキャスト、不明ユニキャスト、マルチキャスト（BUM）トラフィックのための集中型レプリケーション "[RFC8361]
Status (Length): Proposed Standard (17 pages) Overview: 3 individual drafts; 14 WG drafts First draft: 2013-11-12 WG adoption: 2014-12-16 Last Call start: 2017-11-28 (draft 10) IESG eval. start: 2017-12-18 (draft 11) IESG approved: 2018-01-29 (draft 13) AUTH48 start: 2018-03-09 AUTH48 complete: 2018-04-09 Published: 2018-04-12
ステータス（長さ）：提案された標準（17ページ）の概要：3個の個々のドラフト。14 Wgドラフトファーストドラフト：2013-11-12 WG採用：2014-12-16最後のコール開始：2017-11-28（ドラフト10）IESG eval。開始：2017-12-18（ドラフト11）IESG承認済み：2018-01-29（ドラフト13）AUTH48スタート：2018-03-09 AUTH48 COMPLETE：2018-04-09公開：2018-04-12
According to the authors, the long delays in producing this RFC were due to a slow uptake of the technology in the industry.
著者によると、このRFCの生産の長い遅れは、業界における技術のゆっくりとした吸収によるものでした。
Minor copy editing, for style.
スタイルのためのマイナーコピー編集。
There was at least one partial implementation.
少なくとも1つの部分的な実装がありました。
"Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation" [RFC8472]
「トークンバインディングプロトコルネゴシエーションのためのトランスポートレイヤセキュリティ（TLS）拡張」[RFC8472]
Status (Length): Proposed Standard (8 pages) Overview: 1 individual draft; 15 WG drafts First draft: 2015-05-29 WG adoption: 2015-09-11 Last Call start: 2017-11-13 (draft 10) IESG eval. start: 2018-03-19 IESG approved: 2018-07-20 (draft 14) AUTH48 start: 2018-09-17 AUTH48 complete: 2018-09-25 Published: 2018-10-08
ステータス（長さ）：提案された標準（8ページ）の概要：1個人のドラフト。15 WGドラフトファーストドラフト：2015-05-29 WG採用：2015-09-11最後のコールスタート：2017-11-13（ドラフト10）IESG eval。スタート：2018-03-19 IESG承認済み：2018-07-20（ドラフト14）AUTH48スタート：2018-09-17 AUTH48 COMPLETE：2018-09-25公開：2018-10-08
This is a pretty simple document, but it took over 3 years from individual draft to RFC. According to the authors,the biggest setbacks occurred at the start: it took a while to find a home for this draft. It was presented in the TLS WG (because it's a TLS extension) and UTA WG (because it has to do with applications using TLS). Then the ADs determined that a new WG was needed, so the authors had to work through the WG creation process, including running a BOF.
これはかなり簡単な文書ですが、個々のドラフトからRFCまで3年以上かかりました。著者によると、最初の後退は開始時に発生しました。このドラフトの家を見つけるためにしばらく時間がかかりました。TLS WG（TLS拡張機能）とUTA WG（TLSを使用しているアプリケーションと関係があるため）に表示されました。その後、広告は新しいWGが必要だと判断したため、著者はBOFの実行を含むWG作成プロセスを通じて処理しなければなりませんでした。
Minor copy editing, for style, with the addition of a reference to TLS 1.3.
TLS 1.3への参照を追加すると、スタイルのためのマイナーコピー編集。
Perhaps partially due to the delays, some of the implementers lost interest in supporting this RFC.
おそらく部分的に遅延のために、いくつかの実装者はこのRFCをサポートするのに関心を失いました。
"The Token Binding Protocol Version 1.0" [RFC8471]
「トークンバインディングプロトコルバージョン1.0」[RFC8471]
Status (Length): Proposed Standard (18 pages) Overview: 1 individual draft; 19 WG drafts First draft: 2014-10-13 WG adoption: 2015-03-15 Last Call start: 2017-11-13 (draft 16) IESG eval. start: 2018-03-19 IESG approved: 2018-07-20 (draft 19) AUTH48 start: 2018-09-17 AUTH48 complete: 2018-09-25 Published: 2018-10-08
ステータス（長さ）：提案された標準（18ページ）の概要：1個人のドラフト。19 WGドラフトファーストドラフト：2014-10-13 WG採用：2015-03-15最後のコールスタート：2017-11-13（ドラフト16）IESG eval。スタート：2018-03-19 IESG承認済み：2018-07-20（ドラフト19）AUTH48スタート：2018-09-17 AUTH48 COMPLETE：2018-09-25公開：2018-10-08
This document presents a Token Binding Protocol for TLS. We can notice a period of 5 months before adoption of the draft by the WG. That explains in part the overall time of almost 4 years from first draft to publication.
この文書はTLSのトークンバインディングプロトコルを示しています。WGによるドラフトの採用の5ヶ月の期間に気づくことができます。それは、最初のドラフトから出版までほぼ4年の全体的な時間を一部説明しています。
Minor copy editing, for style.
スタイルのためのマイナーコピー編集。
The web references indicate adoption in multiple development projects.
Web参照は、複数の開発プロジェクトにおける採用を示しています。
"A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery" [RFC8466]
「レイヤ2仮想プライベートネットワーク（L2VPN）サービス配信のYangデータモデル」[RFC8466]
Status (Length): Proposed Standard (158 pages) Overview: 5 individual drafts; 11 WG drafts First draft: 2016-09-01 WG adoption: 2017-02-26 Last Call start: 2018-02-21 (draft 07) IESG eval. start: 2018-03-14 (draft 08) IESG approved: 2018-06-25 (draft 10) AUTH48 start: 2018-09-17 AUTH48 complete: 2018-10-09 Published: 2018-10-12
ステータス（長さ）：提案された標準（158ページ）の概要：5個の個々のドラフト。11 WGドラフトファーストドラフト：2016-09-01 WG採用：2017-02-26最後のコールスタート：2018-02-21（ドラフト07）IESG eval。スタート：2018-03-14（ドラフト08）IESG承認済み：2018-06-25（ドラフト10）AUTH48スタート：2018-09-17 AUTH48 COMPLETE：2018-10-09公開：2018-10-12
Copy editing for style and clarity, with also corrections to the YANG model.
Yangモデルへの修正でスタイルと明快さのための編集をコピーします。
"OSPFv3 Link State Advertisement (LSA) Extensibility" [RFC8362] is a major extension to the OSPF protocol. It makes OSPFv3 fully extensible.
"OSPFv3リンク状態広告（LSA）拡張性" [RFC8362]は、OSPFプロトコルへの主な拡張です。OSPFv3を完全に拡張できます。
Status (Length): Proposed Standard (33 pages) Overview: 4 individual drafts; 24 WG drafts First draft: 2013-02-17 WG adoption: 2013-10-15 Last Call start: 2017-12-19 (draft 19) IESG eval. start: 2018-01-18 (draft 20) IESG approved: 2018-01-29 (draft 23) AUTH48 start: 2018-03-19 AUTH48 complete: 2018-03-30 Published: 2018-04-03
ステータス（長さ）：提案された標準（33ページ）の概要：4個のドラフト。24 WG DRAFTSファーストドラフト：2013-02-17 WG採用：2013-10-15最後のコールスタート：2017-12-19（ドラフト19）IESG eval。開始：2018-01-18（ドラフト20）IESG承認済み：2018-01-29（ドラフト23）AUTH48スタート：2018-03-19 AUTH48 COMPLETE：2018-03-30公開：2018-04-03
The specification was first submitted as an individual draft in the IPv6 WG, then moved to the OSPF WG. The long delay of producing this RFC is due to the complexity of the problem, and the need to wait for implementations. It is a very important change to OSPF that makes OSPFv3 fully extensible. Since it was a non-backward compatible change, the developers started out with some very complex migration scenarios but ended up with either legacy or extended OSPFv3 LSAs within an OSPFv3 routing domain. The initial attempts to have a hybrid mode of operation with both legacy and extended LSAs also delayed implementation due to the complexity.
仕様は最初にIPv6 WGの個々のドラフトとして提出され、次にOSPF WGに移動しました。このRFCを生成するという長い遅れは、問題の複雑さ、および実装を待つ必要があるためです。OSPFv3を完全に拡張できるようにするOSPFへの非常に重要な変更です。後方の互換性のある変更であるため、開発者はいくつかの非常に複雑な移行シナリオで始まりましたが、OSPFv3ルーティングドメイン内のレガシーまたは拡張OSPFv3 LSAのいずれかで終了しました。初期の試みは、レガシーと拡張LSAの両方を用いてハイブリッド動作モードを有することも、複雑さのために実装を遅らせた。
Copy editing for style and clarity.
スタイルと明確さのための編集をコピーします。
This specification either was or will be implemented by all the router vendors.
この仕様はすべてのルータベンダによって実行されるか、実装されます。
"IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework" [RFC8468].
"IPv4、IPv6、およびIPv4-IPv6の共存：IP Performance Metrics（IPPM）フレームワークの更新" [RFC8468]。
Status (Length): Informational (15 pages) Overview: 3 individual drafts; 7 WG drafts First draft: 2015-08-06 WG adoption: 2016-07-04 Last Call start: 2018-04-11 (draft 04) IESG eval. start: 2018-05-24 (draft 05) IESG approved: 2018-07-10 (draft 06) AUTH48 start: 2018-09-13 AUTH48 complete: 2018-11-05 Published: 2018-11-14
ステータス（長さ）：情報（15ページ）の概要：3個のドラフト。7 WGドラフトファーストドラフト：2015-08-06 WG採用：2016-07-04最後のコールスタート：2018-04-11（ドラフト04）IESG EVAL。スタート：2018-05-24（ドラフト05）IESG承認済み：2018-07-10（ドラフト06）AUTH48スタート：2018-09-13 AUTH48 COMPLETE：2018-11-05公開：2018-11-14
RFC 8468 was somehow special in that there was not a technical reason or interest that triggered it, but rather a formal requirement. While writing RFC 7312, the IP Performance Metrics (IPPM) Working Group realized that RFC 2330, the IP Performance Metrics Framework supported IPv4 only and explicitly excluded support for IPv6. Nevertheless, people used the metrics that were defined on top of RFC 2330 (and, therefore, IPv4 only) for IPv6, too. Although the IPPM WG agreed that the work was needed, the interest of IPPM attendees in progressing (and reading/reviewing) the IPv6 draft was limited. Resolving the IPv6 technical part was straightforward, but subsequently some people asked for a broader scope (topics like header compression, 6LoWPAN, etc.), and it took some time to figure out and later on convince people that these topics are out of scope. The group also had to resolve contentious topics, for example, how to measure the processing of IPv6 extension headers, which is sometimes nonstandard.
RFC 8468はどういうわけか、それを引き起こした技術的な理由や関心がなく、むしろ正式な要件ではありませんでした。 RFC 7312を書き込む間、IP Performance Metrics（IPPM）ワーキンググループは、IPF4のIPv4のみをサポートし、IPv6のサポートをサポートしていることを参照しています。それにもかかわらず、人々は、RFC 2330の上に定義されたメトリック（したがって、IPv4のみ）をIPv6の場合も使用しました。 IPPM WGは、その作品が必要であることに合意したが、IPPM参加者の進行中のIPPM参加者の利益（および概説）は限られていた。 IPv6技術部品を解決することは簡単でしたが、その後、一部の人々がより広範な範囲（ヘッダー圧縮、6lowpanなどのトピック）を求められています。グループはまた、議論のあるトピックを解決しなければなりませんでした。たとえば、IPv6拡張ヘッダーの処理方法を測定する必要がありました。これは時々非標準です。
The time in AUTH48 state for this document was longer than average. According to the authors, the main reasons include:
この文書のauth48の状態の時刻は平均より長かった。著者によると、主な理由は次のとおりです。
* Workload and travel caused by busy work periods of all coauthors
* すべてのCoAuthorsの忙しい仕事期間による作業負荷と旅行
* Time zone difference between coauthors and editor (at least US, Europe, and India, not considering travel)
* CoAuthorsとEditorの間の時間帯の違い（少なくとも米国、ヨーロッパ、およびインド、旅行を考慮しない）
* RFC Production Center proposed and committed some unacceptable modifications that needed to be reverted
* RFC生産センターは、元に戻す必要があるいくつかの許容できない変更を提案し、命じた
* Lengthy discussions on a new document title (required high effort and took a long time, in particular reaching consensus between coauthors and editor was time-consuming and involved the AD)
* 新しい文書タイトルに関する長いディスカッション（必要とされる高努力が必要で、特にCoAuthorsと編集者の間の合意に達していることは時間がかかり、広告を含んでいました）
* RFC Production Center correctly identified some nits (obsoleted personal websites of coauthors) and coauthors attempting to fix them.
* RFC生産センターは、それらを修正しようとしている一部のNITS（廃止された個人ウェブサイト）とCoAuthorsを正しく特定しました。
The differences between the final draft and the published RFC show copy editing for style and clarity, but do not account for the back and forth between authors and editors mentioned by the authors.
最後のドラフトと公開されているRFCの違いは、スタイルと明確さのためのコピー編集を示していますが、著者によって言及されている著者と編集者の間の前後を考慮していません。
We examine the 20 RFCs in the sample, measuring various characteristics such as delay and citation counts, in an attempt to identify patterns in the IETF processes.
私達はサンプル内の20のRFCを調べ、IETFプロセスのパターンを識別しようとする試みにおいて、遅延および引用数などのさまざまな特性を測定します。
We look at the distribution of delays between the submission of the first draft and the publication of the RFC, using the three milestones defined in Section 2.1: processing time in the working group, IETF processing time, and RFC production time. The following table shows the number of days in each phase for the 20 RFCs in the sample:
ワーキンググループの処理時間、IETF処理時間、およびRFC製造時刻、およびRFC製造時刻、およびRFCのプロセス時間を使用して、最初のドラフトの提出とRFCの出版の出版の際の遅延の分布を調べます。次の表は、サンプル内の20 RFCの各フェーズの日数を示しています。
+======+============+=======+=========+======+======+======+
| RFC | Status | Pages | Overall | WG | IETF | Edit |
+======+============+=======+=========+======+======+======+
| 8411 | Info | 5 | 455 | 154 | 140 | 161 |
+------+------------+-------+---------+------+------+------+
| 8456 | Info | 64 | 1317 | 1033 | 126 | 158 |
+------+------------+-------+---------+------+------+------+
| 8446 | PS | 160 | 1576 | 1400 | 34 | 142 |
+------+------------+-------+---------+------+------+------+
| 8355 | Info | 13 | 1517 | 1175 | 243 | 99 |
+------+------------+-------+---------+------+------+------+
| 8441 | PS | 8 | 327 | 204 | 31 | 92 |
+------+------------+-------+---------+------+------+------+
| 8324 | Info (ISE) | 29 | 270 | 38 | 161 | 71 |
+------+------------+-------+---------+------+------+------+
| 8377 | PS | 8 | 1792 | 1630 | 21 | 141 |
+------+------------+-------+---------+------+------+------+
| 8498 | Info | 15 | 1059 | 935 | 59 | 65 |
+------+------------+-------+---------+------+------+------+
| 8479 | Info (ISE) | 8 | 414 | 233 | 144 | 37 |
+------+------------+-------+---------+------+------+------+
| 8453 | Info | 42 | 1165 | 1036 | 46 | 83 |
+------+------------+-------+---------+------+------+------+
| 8429 | BCP | 10 | 548 | 76 | 313 | 159 |
+------+------------+-------+---------+------+------+------+
| 8312 | Info | 18 | 1214 | 1113 | 16 | 85 |
+------+------------+-------+---------+------+------+------+
| 8492 | Info (ISE) | 40 | 2358 | 1706 | 172 | 480 |
+------+------------+-------+---------+------+------+------+
| 8378 | Exp | 21 | 1524 | 1446 | 27 | 51 |
+------+------------+-------+---------+------+------+------+
| 8361 | PS | 17 | 1612 | 1477 | 62 | 73 |
+------+------------+-------+---------+------+------+------+
| 8472 | PS | 8 | 1228 | 899 | 249 | 80 |
+------+------------+-------+---------+------+------+------+
| 8471 | PS | 18 | 1228 | 899 | 249 | 80 |
+------+------------+-------+---------+------+------+------+
| 8466 | PS | 158 | 771 | 538 | 124 | 109 |
+------+------------+-------+---------+------+------+------+
| 8362 | PS | 33 | 1871 | 1766 | 41 | 64 |
+------+------------+-------+---------+------+------+------+
| 8468 | Info | 15 | 1196 | 979 | 90 | 127 |
+------+------------+-------+---------+------+------+------+
| average | 35 | 1172 | 948 | 117 | 118 |
+-------------------+-------+---------+------+------+------+
| average (not ISE) | 36 | 1200 | 999 | 110 | 104 |
+-------------------+-------+---------+------+------+------+
Table 1
表1
The average delay from first draft to publication is about 3 years and 3 months, but this varies widely. Excluding the RFCs from the Independent Stream, the average delay from start to finish is 3 years and 4 months, of which on average 2 years and 9 months are spent getting consensus in the working group, and 3 to 4 months each for IETF consensus and for RFC production.
最初のドラフトから出版までの平均遅延は約3年から3ヶ月ですが、これは大きく異なります。独立したストリームからのRFCを除くと、開始から終了までの平均遅延は3年と4ヶ月で、そのうちの平均2年と9ヶ月はワーキンググループ内の合意に費やされ、それぞれIETFの合意のためにそれぞれ3~4ヶ月RFC制作のために。
The longest delay is found for [RFC8492], 6.5 years from start to finish. This is however a very special case -- a draft that was prepared for the TLS Working Group and failed to reach consensus. After that, it was resubmitted to the ISE, and incurred atypical production delays.
最長の遅延は[RFC8492]、開始から終了までの6.5年に見られます。しかし、これは非常に特別な場合です.TLSワーキンググループに準備され、コンセンサスに達することができなかったドラフトです。その後、ISEに再登録され、非定型生産遅延が発生しました。
On average, we see that 80% of the delay is incurred in WG processing, 10% in IETF review, and 10% for edition and publication.
平均して、遅延の80％がWG加工、IETFレビューの10％、版と出版物の10％で発生したことがわかります。
For IETF Stream RFCs, it appears that the delays for Informational documents are slightly shorter than those for protocol specifications, maybe six months shorter on average. However, there are lots of differences between individual documents. The delays range from less than a year to more than 5 years for protocol specifications, and from a year and 3 months to a bit more than 4 years for Informational documents.
IETFストリームRFCSの場合、情報文書の遅延はプロトコル仕様書の遅延がわずかに短く、平均6ヶ月が短くなります。ただし、個々の文書の間にはたくさんの違いがあります。遅延は、プロトコル仕様のための1年未満から5年以上、そして情報文書のために4年以上前から4年以上までの範囲です。
We can compare the delays in the 2018 samples to those observed 10 years ago and 20 years before:
2018サンプルの遅延を10年前と20年前に観察されたものに比較することができます。
+============+============+=======+=======+
| RFC (2008) | Status | Pages | Delay |
+============+============+=======+=======+
| 5326 | Exp | 54 | 1584 |
+------------+------------+-------+-------+
| 5348 | PS | 58 | 823 |
+------------+------------+-------+-------+
| 5281 | Info | 51 | 1308 |
+------------+------------+-------+-------+
| 5354 | Exp | 23 | 2315 |
+------------+------------+-------+-------+
| 5227 | PS | 21 | 2434 |
+------------+------------+-------+-------+
| 5329 | PS | 12 | 1980 |
+------------+------------+-------+-------+
| 5277 | PS | 35 | 912 |
+------------+------------+-------+-------+
| 5236 | Info (ISE) | 26 | 1947 |
+------------+------------+-------+-------+
| 5358 | BCP | 7 | 884 |
+------------+------------+-------+-------+
| 5271 | Info | 22 | 1066 |
+------------+------------+-------+-------+
| 5195 | PS | 10 | 974 |
+------------+------------+-------+-------+
| 5283 | PS | 12 | 1096 |
+------------+------------+-------+-------+
| 5186 | Info | 6 | 2253 |
+------------+------------+-------+-------+
| 5142 | PS | 13 | 1005 |
+------------+------------+-------+-------+
| 5373 | PS | 24 | 1249 |
+------------+------------+-------+-------+
| 5404 | PS | 27 | 214 |
+------------+------------+-------+-------+
| 5172 | PS | 7 | 305 |
+------------+------------+-------+-------+
| 5349 | Info | 10 | 1096 |
+------------+------------+-------+-------+
| 5301 | PS | 6 | 396 |
+------------+------------+-------+-------+
| 5174 | Info | 8 | 427 |
+------------+------------+-------+-------+
Table 2
表2.
+============+============+=======+=========+
| RFC (1998) | Status | Pages | Delay |
+============+============+=======+=========+
| 2289 | PS | 25 | 396 |
+------------+------------+-------+---------+
| 2267 | Info | 10 | unknown |
+------------+------------+-------+---------+
| 2317 | BCP | 10 | 485 |
+------------+------------+-------+---------+
| 2404 | PS | 7 | 488 |
+------------+------------+-------+---------+
| 2374 | PS | 12 | 289 |
+------------+------------+-------+---------+
| 2449 | PS | 19 | 273 |
+------------+------------+-------+---------+
| 2283 | PS | 9 | 153 |
+------------+------------+-------+---------+
| 2394 | Info | 6 | 365 |
+------------+------------+-------+---------+
| 2348 | DS | 5 | 699 |
+------------+------------+-------+---------+
| 2382 | Info | 30 | 396 |
+------------+------------+-------+---------+
| 2297 | Info (ISE) | 109 | 28 |
+------------+------------+-------+---------+
| 2381 | PS | 43 | 699 |
+------------+------------+-------+---------+
| 2312 | Info | 20 | 365 |
+------------+------------+-------+---------+
| 2387 | PS | 10 | 122 |
+------------+------------+-------+---------+
| 2398 | Info | 15 | 396 |
+------------+------------+-------+---------+
| 2391 | PS | 10 | 122 |
+------------+------------+-------+---------+
| 2431 | PS | 10 | 457 |
+------------+------------+-------+---------+
| 2282 | Info | 14 | 215 |
+------------+------------+-------+---------+
| 2323 | Info (ISE) | 5 | unknown |
+------------+------------+-------+---------+
| 2448 | Info (ISE) | 7 | 92 |
+------------+------------+-------+---------+
Table 3
表3.
We can compare the median delay, and the delays observed by the fastest and slowest quartiles in the three years:
3年間で最速かつ最も遅い四分類の中央値を比較することができます。
+======+=============+========+=============+
| Year | Fastest 25% | Median | Slowest 25% |
+======+=============+========+=============+
| 2018 | 715 | 1221 | 1537 |
+------+-------------+--------+-------------+
| 2008 | 869 | 1081 | 1675 |
+------+-------------+--------+-------------+
| 1998 | 169 | 365 | 442 |
+------+-------------+--------+-------------+
Table 4
表4.
The IETF takes three to four times more to produce an RFC in 2018 than it did in 1998, but about the same time as it did in 2008. We can get a rough estimate of how this translates in terms of "level of attention" per RFC by comparing the number of participants in the IETF meetings of 2018, 2008, and 1998 [IETFCOUNT] to the number of RFCs published these years [RFCYEAR].
IETFは1998年に2018年にRFCを生産するのに3~4倍以上かかりますが、2008年にほぼ同時に「注意レベル」という点でどのように翻訳するかについての大まかな見積もりを得ることができます。2018年、2008年、および1998年の参加者の数を、これらの年に発行されたRFCの数への参加者の数を比較することで、[RFCYER]。
+======+=========+========+========+======+=========+============+
| Year | Number | Spring | Summer | Fall | Average | Attendees/ |
| | of RFCs | P. | P. | P. | P. | RFC |
+======+=========+========+========+======+=========+============+
| 2018 | 208 | 1235 | 1078 | 879 | 1064 | 5.1 |
+------+---------+--------+--------+------+---------+------------+
| 2008 | 290 | 1128 | 1181 | 962 | 1090 | 3.8 |
+------+---------+--------+--------+------+---------+------------+
| 1998 | 234 | 1775 | 2106 | 1705 | 1862 | 8.0 |
+------+---------+--------+--------+------+---------+------------+
Table 5
表5.
The last column in the table provides the ratio of average number of participants to the number of RFCs published. If the IETF were a centralized organization, and if all participants and documents were equivalent, this ratio would be the number of participants dedicated to produce an RFC on a given year. This is of course a completely abstract figure because none of the hypotheses above are true, but it still gives a vague indication of the "level of attention" applied to documents. We see that this ratio has increased from 2008 to 2018, as the number of participants was about the same for these two years but the number of published RFCs decreased. However, this ratio was much higher in 1998. The IETF had many more participants, and there were probably many more eyes available to review any given draft. If we applied the ratios of 1998, the IETF would be producing 119 documents in 2018 instead of 208.
表の最後の列は、公開されているRFCの数に対する参加者の平均数の比率を提供します。IETFが集中組織であり、すべての参加者と文書が同等であれば、この比率は特定の年にRFCを作成することに専念している参加者の数です。上記の仮説のどれもも当てはまりませんが、それでも文書に適用される「注意レベル」の曖昧な指標を依然として与えるので、これは完全に抽象的な図です。参加者の数はこれら2年間ほぼ同じであるため、この比率は2008年から2018年に増加したことがわかりましたが、公開されたRFCの数は減少しました。しかし、この比率は1998年にはるかに高かった。IETFはもっと多くの参加者を持っていました、そしておそらく特定のドラフトを見直すために多くの目がありました。1998年の比率を適用した場合、IETFは208の代わりに2018年に119の文書を作成します。
The largest part of the delays is spent in the working groups, before the draft is submitted to the IESG for IETF review. As mentioned in Section 2.1, the only intermediate milestone that we can extract from the IETF Datatracker is the date at which the document was adopted by the working group, or targeted for independent submission. The breakdown of the delays for the documents in our sample is:
遅延の最大部分は、草案がIESGのIESGに提出される前に、作業グループに費やされます。セクション2.1で述べたように、IETF DataTrackerから抽出できる唯一の中間マイルストーンは、文書がワーキンググループによって採用された日付、または独立した送信を目標とした日付です。サンプル内の文書の遅延の内訳は次のとおりです。
+======+============+======+================+================+
| RFC | Status | WG | Until adoption | After adoption |
+======+============+======+================+================+
| 8411 | Info | 154 | 0 | 154 |
+------+------------+------+----------------+----------------+
| 8456 | Info | 1033 | 209 | 824 |
+------+------------+------+----------------+----------------+
| 8446 | PS | 1400 | 0 | 1400 |
+------+------------+------+----------------+----------------+
| 8355 | Info | 1175 | 102 | 1073 |
+------+------------+------+----------------+----------------+
| 8441 | PS | 204 | 65 | 139 |
+------+------------+------+----------------+----------------+
| 8324 | Info (ISE) | 38 | 0 | 38 |
+------+------------+------+----------------+----------------+
| 8377 | PS | 1630 | 728 | 902 |
+------+------------+------+----------------+----------------+
| 8498 | Info | 935 | 420 | 515 |
+------+------------+------+----------------+----------------+
| 8479 | Info (ISE) | 233 | 0 | 233 |
+------+------------+------+----------------+----------------+
| 8453 | Info | 1036 | 396 | 640 |
+------+------------+------+----------------+----------------+
| 8429 | BCP | 76 | 0 | 76 |
+------+------------+------+----------------+----------------+
| 8312 | Info | 1113 | 280 | 833 |
+------+------------+------+----------------+----------------+
| 8492 | Info (ISE) | 1706 | 1428 | 278 |
+------+------------+------+----------------+----------------+
| 8378 | Exp | 1446 | 661 | 785 |
+------+------------+------+----------------+----------------+
| 8361 | PS | 1477 | 399 | 1078 |
+------+------------+------+----------------+----------------+
| 8472 | PS | 899 | 105 | 794 |
+------+------------+------+----------------+----------------+
| 8471 | PS | 1127 | 153 | 794 |
+------+------------+------+----------------+----------------+
| 8466 | PS | 538 | 178 | 360 |
+------+------------+------+----------------+----------------+
| 8362 | PS | 1766 | 240 | 1526 |
+------+------------+------+----------------+----------------+
| 8468 | Info | 979 | 333 | 646 |
+------+------------+------+----------------+----------------+
| Average | 948 | 285 | 663 |
+-------------------+------+----------------+----------------+
Table 6
表6.
The time before working group adoption averages to a bit more than 9 months, compared to 1 year and almost 10 months for processing time after adoption. We see that RFC 8492 stands out, with long delays spent attempting publication through a working group before submission to the Independent Submissions Editor. If we remove RFC 8492 from the list, the average time until adoption drops to just over 7 months, and becomes just 25% of the total processing time in the WG.
ワーキンググループの採用前の時間は、1年以上、採用後の処理時間のための10ヶ月ほぼ10ヶ月の間で、9ヶ月を超える時間です。RFC 8492が際立っているのは、独立した投稿エディタへの提出前にワーキンググループを介して出版を試みることを遅らせています。リストからRFC 8492を取り外すと、採用までの平均時間は7ヶ月かかり、WGの全処理時間のわずか25％になります。
There are a few documents that started immediately as working group efforts, or were immediately targeted for publication in the Independent Stream. Those documents tend to see short processing times, with the exception of RFC 8446 on which the TLS Working Group spent a long time working.
ワーキンググループの努力としてすぐに開始された、あるいは直ちに独立したストリームでの出版物をターゲットにした文書がいくつかあります。これらの文書は、TLSワーキンググループが長い時間を費やしたRFC 8446を除いて、処理時間が短くなる傾向があります。
The preparation and publication delays include three components:
準備遅延と出版物の遅延には、3つの成分が含まれます。
* the delay from submission to the RFC Editor to beginning of AUTH48, during which the document is prepared (referred to as "RFC edit" below);
* 申請書からRFCエディタへのRFCエディタからRFCエディタへの遅延、その中に文書が作成されます（下記の「RFC編集」と呼ばれます）。
* the AUTH48 delay, during which authors review and eventually approve the changes proposed by the editors (referred to as "AUTH48" below);
* AUTH48の遅延、その間に執筆者が編集者が提案し、最終的に編集者によって提案された変更を承認します（下記の「AUTH48」と呼ばれます）。
* the publication delay, from final agreement by authors and editors to actual publication (referred to as "RFC Pub" below).
* 出版物遅延は、著者および編集者による実際の出版物（以下の「RFC PUB」と呼ばれる）からの最終契約からの遅延。
The breakdown of the publication delays for each RFC is shown in the following table.
各RFCの出版遅延の内訳を次の表に示します。
+=======+========+=======+==========+========+=========+=========+
| RFC | Status | Pages | RFC edit | AUTH48 | RFC Pub | Edit |
| | | | | | | (total) |
+=======+========+=======+==========+========+=========+=========+
| 8411 | Info | 5 | 53 | 88 | 20 | 161 |
+-------+--------+-------+----------+--------+---------+---------+
| 8456 | Info | 64 | 98 | 46 | 14 | 158 |
+-------+--------+-------+----------+--------+---------+---------+
| 8446 | PS | 160 | 85 | 57 | 0 | 142 |
+-------+--------+-------+----------+--------+---------+---------+
| 8355 | Info | 13 | 83 | 15 | 1 | 99 |
+-------+--------+-------+----------+--------+---------+---------+
| 8441 | PS | 8 | 56 | 33 | 3 | 92 |
+-------+--------+-------+----------+--------+---------+---------+
| 8324 | Info | 29 | 42 | 28 | 1 | 71 |
| | (ISE) | | | | | |
+-------+--------+-------+----------+--------+---------+---------+
| 8377 | PS | 8 | 39 | 102 | 0 | 141 |
+-------+--------+-------+----------+--------+---------+---------+
| 8498 | Info | 15 | 48 | 16 | 1 | 65 |
+-------+--------+-------+----------+--------+---------+---------+
| 8479 | Info | 8 | 31 | 5 | 1 | 37 |
| | (ISE) | | | | | |
+-------+--------+-------+----------+--------+---------+---------+
| 8453 | Info | 42 | 73 | 7 | 3 | 83 |
+-------+--------+-------+----------+--------+---------+---------+
| 8429 | BCP | 10 | 60 | 99 | 0 | 159 |
+-------+--------+-------+----------+--------+---------+---------+
| 8312 | Info | 18 | 55 | 28 | 2 | 85 |
+-------+--------+-------+----------+--------+---------+---------+
| 8492 | Info | 40 | 355 | 123 | 2 | 480 |
| | (ISE) | | | | | |
+-------+--------+-------+----------+--------+---------+---------+
| 8378 | Exp | 21 | 42 | 9 | 0 | 51 |
+-------+--------+-------+----------+--------+---------+---------+
| 8361 | PS | 17 | 39 | 31 | 3 | 73 |
+-------+--------+-------+----------+--------+---------+---------+
| 8472 | PS | 8 | 59 | 8 | 13 | 80 |
+-------+--------+-------+----------+--------+---------+---------+
| 8471 | PS | 18 | 59 | 8 | 13 | 80 |
+-------+--------+-------+----------+--------+---------+---------+
| 8466 | PS | 158 | 84 | 22 | 3 | 109 |
+-------+--------+-------+----------+--------+---------+---------+
| 8362 | PS | 33 | 49 | 11 | 4 | 64 |
+-------+--------+-------+----------+--------+---------+---------+
| 8468 | Info | 15 | 65 | 53 | 9 | 127 |
+-------+--------+-------+----------+--------+---------+---------+
| Average | | 74 | 39 | 5 | 118 |
+----------------+-------+----------+--------+---------+---------+
| Average | | 59 | 35 | 5 | 99 |
| (without 8492) | | | | | |
+----------------+-------+----------+--------+---------+---------+
Table 7
表7.
On average, the total delay appears to be about four months, but the average is skewed by the extreme values encountered for [RFC8492]. If we exclude that RFC from the computations, the average delay drops to a just a bit more than 3 months: about 2 months for the preparation, a bit more than one month for the AUTH48 phase, and 5 days for the publishing.
平均して、総遅延は約4ヶ月であるように見えますが、平均は[RFC8492]で遭遇した極値の値によって歪められています。そのRFCを計算から除外すると、平均遅延は3ヶ月以上のほんの少し降下しています。
Of course, these delays vary from RFC to RFC. To try explain the causes of the delay, we compute the correlation factor between the observed delays and several plausible explanation factors:
もちろん、これらの遅延はRFCからRFCまで異なります。遅延の原因を説明するために、観測された遅延といくつかのもらしい説明要因との間の相関係数を計算します。
* the number of pages in the document,
* 文書内のページ数、
* the amount of copy editing, as discussed in Section 4.4,
* セクション4.4で説明したように、コピー編集の量
* whether or not IANA actions were required,
* IANAの行動が必要かどうか
* the number of authors,
* 著者の数、
* the number of draft revisions,
* ドラフトリビジョンの数、
* the working group delay.
* ワーキンググループの遅延
We find the following values:
以下の値を見つけます。
+===================+==========+========+=============+
| Correlation | RFC edit | AUTH48 | Edit(total) |
+===================+==========+========+=============+
| Number of pages | 0.50 | -0.04 | 0.21 |
+-------------------+----------+--------+-------------+
| Copy-Edit | 0.42 | 0.24 | 0.45 |
+-------------------+----------+--------+-------------+
| IANA | -0.14 | -0.21 | 0.12 |
+-------------------+----------+--------+-------------+
| Number of authors | 0.39 | -0.07 | 0.18 |
+-------------------+----------+--------+-------------+
| Number of drafts | 0.18 | -0.33 | -0.19 |
+-------------------+----------+--------+-------------+
| WG delay | 0.03 | -0.16 | -0.15 |
+-------------------+----------+--------+-------------+
Table 8
表8.
We see some plausible explanations for the production delay. It will be somewhat longer for longer documents or for documents that require a lot of copy editing (see Section 4.4). Somewhat surprisingly, it also tends to increase with the number of authors. It does not appear significantly correlated with the presence or absence of IANA action.
製造遅延についてもっともらしい説明がいくつかわかります。より長い文書や、多くのコピー編集を必要とする文書のためにやや長くなるでしょう（セクション4.4を参照）。やや驚くべきことに、それはまた著者の数と共に増加する傾向があります。IANA作用の有無と有意に相関しているようには見えません。
The analysis of RFC 8324 in Section 3.6 explains its short editing delays by the experience of the author. This makes sense: if a document needs less editing, the editing delays would be shorter. This is partially confirmed by the relation between the amount of copy editing and the publication delay.
セクション3.6のRFC 8324の分析は、著者の経験によるその短い編集遅延について説明しています。これは意味があります。文書に編集が少なくなると、編集遅延は短くなります。これは、コピー編集量と掲載遅延の関係によって部分的に確認されています。
We see fewer plausible explanations for the AUTH48 delays. These delays vary much more than the preparation delay, with a standard deviation of 20 days for AUTH48 versus 10 days for the preparation delay. In theory, AUTH48 is just a final verification: the authors receive the document prepared by the RFC production center, and just have to give their approval, or maybe request a last minute correction. The name indicates that this is expected to last just two days, but in average it lasts more than a month.
AUTH48の遅延については、より正確な説明が少なくなります。これらの遅延は、調製遅延のための標準偏差が、準備遅延のための20日の標準偏差よりもはるかに多く変化します。理論的には、auth48は単なる最終検証です。名前は、これが2日間続くと予想されることを示しますが、平均してそれは1か月以上続くことを示しています。
We often hypothesize that the number of authors influences the AUTH48 delay, or that authors who have spent a long time working on the document in the working group somehow get demotivated and spend even longer to answer questions during AUTH48. This may happen sometimes, but our statistics don't show that - if anything, the numerical results point in the opposite direction.
私たちは、著者の数がAUT48の遅延に影響を与えること、または作業グループの文書に取り組んで長い時間を過ごした作者が、どういうわけか分解し、aut48の間に質問に答えるために長い時間を過ごすことを仮定します。これは時々起こるかもしれませんが、私たちの統計はそれを示していません - 何でも、数値結果は反対方向を示しています。
After asking the authors of the RFCs in the sample why the AUTH48 phase took a long time, we got three explanations:
AUTH48フェーズが長い時間をかけた理由をサンプルにサンプルに尋ねた後、3つの説明を得ました。
1. Some RFCs have multiple authors in multiple time zones. This slows down the coordination required for approving changes.
1. 一部のRFCには複数のタイムゾーンに複数の作者があります。これにより、変更を承認するために必要な調整が遅くなります。
2. Some authors found some of the proposed changes unnecessary or undesirable, and asked that they be reversed. This required long exchanges between authors and editors.
2. 何人かの著者は、提案された変更のいくつかを不要または望ましくないものであり、彼らが逆にするように依頼した。これは著者と編集者の間の長い交換を必要としました。
3. Some authors were not giving high priority to AUTH48 responses.
3. いくつかの著者はAUTH48の回答を優先していませんでした。
As mentioned above, we were not able to verify these hypotheses by looking at the data. The author's experience with this document suggests another potential delay for the Independent Stream RFC: processing delay by the Independent Submissions Editor, discussed in Section 4.5.
上述のように、データを見ることによってこれらの仮説を検証することはできませんでした。この文書に関する著者の経験は、独立したストリームRFCの別の潜在的な遅延を示唆しています。セクション4.5で説明した独立した投稿エディタによる処理遅延
We can assess the amount of copy editing applied to each published RFC by comparing the text of the draft approved for publication and the text of the RFC. We do expect differences in the "boilerplate" and in the IANA section, but we will also see differences due to copy editing. Assessing the amount of copy editing is subjective, and we do it using a scale of 1 to 4:
公開済みのRFCに適用されたコピー編集の量を、出版承認済みのドラフトのテキストとRFCのテキストを比較することによって評価できます。「ボイラープレート」とIANAセクションの違いが期待できますが、コピー編集による違いもあります。コピー編集の額を評価することは主観的であり、1から4のスケールを使用してそれを行います。
1: Minor editing
1：マイナー編集
2: Editing for style, such as capitalization, hyphens, "that" versus "which", and expanding all acronyms at least once.
2：資本化、ハイフン、「それはどの」と「どちらかを少なくとも1回以上膨らませる」などのスタイルの編集を編集します。
3: Editing for clarity in addition to style, such as rewriting ambiguous sentences and clarifying use of internal references. For YANG models, that may include model corrections suggested by the verifier.
3：曖昧な文の書き換えや内部参照の使用の明確化など、スタイルに加えて明確にするための編集。Yangモデルの場合、検証者によって提案されたモデル補正を含めることができます。
4: Extensive editing.
4：広範な編集。
The following table shows that about half of the RFCs required editing for style, and the other half at least some editing for clarity.
次の表は、RFCの約半分がスタイルの編集を必要とし、他の半分の半分の半分を明確にするための編集を示しています。
+======+============+===========+
| RFC | Status | Copy Edit |
+======+============+===========+
| 8411 | Info | 2 |
+------+------------+-----------+
| 8456 | Info | 4 |
+------+------------+-----------+
| 8446 | PS | 3 |
+------+------------+-----------+
| 8355 | Info | 2 |
+------+------------+-----------+
| 8441 | PS | 2 |
+------+------------+-----------+
| 8324 | Info (ISE) | 2 |
+------+------------+-----------+
| 8377 | PS | 3 |
+------+------------+-----------+
| 8498 | Info | 3 |
+------+------------+-----------+
| 8479 | Info (ISE) | 1 |
+------+------------+-----------+
| 8453 | Info | 2 |
+------+------------+-----------+
| 8429 | BCP | 2 |
+------+------------+-----------+
| 8312 | Info | 2 |
+------+------------+-----------+
| 8492 | Info (ISE) | 3 |
+------+------------+-----------+
| 8378 | Exp | 2 |
+------+------------+-----------+
| 8361 | PS | 2 |
+------+------------+-----------+
| 8472 | PS | 2 |
+------+------------+-----------+
| 8471 | PS | 2 |
+------+------------+-----------+
| 8466 | PS | 3 |
+------+------------+-----------+
| 8362 | PS | 3 |
+------+------------+-----------+
| 8468 | Info | 3 |
+------+------------+-----------+
Table 9
表9.
This method of assessment does not take into account the number of changes proposed by the editors and eventually rejected by the authors, since these changes are not present in either the final draft or the published RFC. It might be possible to get an evaluation of these "phantom changes" from the RFC Production Center.
この評価方法は、これらの変更が最終草案または公開されたRFCのどちらにも存在しないため、編集者によって提案された変更の数を考慮に入れていません。RFC製造センターからこれらの「ファントム変化」の評価を得ることが可能かもしれません。
Out of 20 randomly selected RFCs, 3 were published through the Independent Stream. One is an independent opinion, another a description of a non-IETF protocol format, and the third was [RFC8492], which is a special case. Apart from this special case, the publication delays were significantly shorter for the Independent Stream than for the IETF Stream.
20のうち20のランダムに選択されたRFCS、3は独立したストリームを通して公開された。1つは独立した意見であり、もう1つは非IETFプロトコル形式の説明であり、3番目のものは[RFC8492]で、これは特別な場合です。この特別な場合とは別に、出版物の遅延はIETFストリームよりも独立した流れでは著しく短かった。
The authors of these 3 RFCs are regular IETF contributors. This observation motivated a secondary analysis of all the RFCs published in the Independent Stream in 2018. There are 14 such RFCs: 8507, 8494, 8493, 8492, 8483, 8479, 8433, 8409, 8374, 8369, 8367, 8351, 8328, and 8324. (RFCs 8367 and 8369 were published on 1 April 2018.) The majority of the documents were published by regular IETF participants, but two of them were not. One describes "The BagIt File Packaging Format (V1.0)" [RFC8493], and the other the "Yeti DNS Testbed" [RFC8483]. They document a data format and a system developed outside the IETF and illustrate the outreach function of the Independent Stream. In both cases, the authors include one experienced IETF participant, who presumably helped outsiders navigate the publication process.
これらの3つのRFCの著者は通常のIETFの貢献者です。この観測は、2018年に独立したストリームに掲載されているすべてのRFCの二次分析をやる気にしました。このようなRFCは14507,8494,8493,8492,8483,8479,8433,8409,8374,8369,8367,8351,8328、（RFCS 8367と8369は2018年4月1日に発行されました。）文書の大部分は通常のIETF参加者によって公開されましたが、それらのうちの2つはそうではありませんでした。「バジットファイルの包装形式（v1.0）」[RFC8493]、もう1つは「静止DNS TestBed」[RFC8483]について説明します。彼らはデータフォーマットとIETFの外部で開発されたシステムを文書化し、独立したストリームのアウトリーチ機能を説明しています。どちらの場合も、著者は経験豊富なIETF参加者を含みます。
The present document experienced some publication delays due to the Independent Submissions Editor. The ISE is a bottleneck and is a volunteer resource. Although the ISE as a lone person operating as a volunteer is still roughly adequate resource for the job, the delivery will necessarily be best effort with delays caused by spikes in ISE load, work commitments, and other life events. These delays may not be fundamentally critical to RFC delivery, but they are capable of introducing a significant percentage delay into what might otherwise be a smooth process.
現在の文書は、独立した投稿エディタのためにいくつかの出版物遅延を経験しました。ISEはボトルネックであり、ボランティアリソースです。ボランティアとして営業している孤独な人としてのISEは、依然として仕事のための大まかな適切な資源ですが、納入は必然的に伊勢負荷、仕事の約束、およびその他の生活のイベントのスパイクによって引き起こされる遅延が最も良いでしょう。これらの遅延はRFCの配達には根本的に重要ではないかもしれませんが、そうでなければ円滑なプロセスであるかもしれないものにかなりのパーセンテージ遅延を導入することができます。
In this exploration, we want to examine whether citation counts
provide a meaningful assessment of the popularity of RFCs. We obtain
the citation counts through the Semantic Scholar API, using queries
of the form: <https://api.semanticscholar.org/v1/paper/10.17487/
rfc8446?include_unknown_references=true>
In these queries, the RFC is uniquely identified by its DOI reference, which is composed of the RFC Series prefix 10.17487 and the RFC identifier. The queries return a series of properties, including a list of citations for the RFC. Based on that list of citations, we compute three numbers:
これらのクエリでは、RFCはDOI参照によって一意に識別されます。これは、RFCシリーズプレフィックス10.17487とRFC識別子で構成されています。クエリは、RFCの引用リストを含む一連のプロパティを返します。その引用リストに基づいて、3つの数字を計算します。
* The total number of citations
* 引用の総数
* The number of citations in the year of publication and the year after that
* 出版年の引用数とその後の年
* For the RFC published in 1998 or 2008 that we use for comparison, the number of citations in the years 2018 and 2019.
* 1998年または2008年に発行されたRFCは、比較のために使用していること、2018年と2019年の引用数。
All the numbers were retrieved on October 6, 2019.
2019年10月6日にすべての番号が取得されました。
As measured on October 6, 2019, the citation counts for the RFC in our sample set were:
2019年10月6日、サンプルセットのRFCの引用数は次のとおりです。
+============+============+=======+===========+
| RFC (2018) | Status | Total | 2018-2019 |
+============+============+=======+===========+
| 8411 | Info | 1 | 0 |
+------------+------------+-------+-----------+
| 8456 | Info | 1 | 1 |
+------------+------------+-------+-----------+
| 8446 | PS | 418 | 204 |
+------------+------------+-------+-----------+
| 8355 | Info | 3 | 3 |
+------------+------------+-------+-----------+
| 8441 | PS | 1 | 1 |
+------------+------------+-------+-----------+
| 8324 | Info (ISE) | 0 | 0 |
+------------+------------+-------+-----------+
| 8377 | PS | 0 | 0 |
+------------+------------+-------+-----------+
| 8498 | Info | 0 | 0 |
+------------+------------+-------+-----------+
| 8479 | Info (ISE) | 0 | 0 |
+------------+------------+-------+-----------+
| 8453 | Info | 3 | 3 |
+------------+------------+-------+-----------+
| 8429 | BCP | 0 | 0 |
+------------+------------+-------+-----------+
| 8312 | Info | 25 | 16 |
+------------+------------+-------+-----------+
| 8492 | Info (ISE) | 4 | 4 |
+------------+------------+-------+-----------+
| 8378 | Exp | 1 | 1 |
+------------+------------+-------+-----------+
| 8361 | PS | 0 | 0 |
+------------+------------+-------+-----------+
| 8472 | PS | 1 | 1 |
+------------+------------+-------+-----------+
| 8471 | PS | 1 | 1 |
+------------+------------+-------+-----------+
| 8466 | PS | 0 | 0 |
+------------+------------+-------+-----------+
| 8362 | PS | 1 | 1 |
+------------+------------+-------+-----------+
| 8468 | Info | 1 | 1 |
+------------+------------+-------+-----------+
Table 10
表10.
The results indicate that [RFC8446] is by far the most cited of the 20 RFC in our sample. This is not surprising, since TLS is a key Internet Protocol. The TLS 1.3 protocol was also the subject of extensive studies by researchers, and thus was mentioned in a number of published papers. Surprisingly, the Semantic Scholar mentions a number of citations that predate the publication date. These are probably citations of the various draft versions of the protocol.
結果は、[RFC8446]が私たちのサンプルの20 RFCの最大で最も引用されていることを示しています。TLSは重要なインターネットプロトコルであるため、これは驚くべきことではありません。TLS 1.3プロトコルはまた、研究者による広範な研究の対象であり、したがって多くの公開された論文で言及された。驚くべきことに、意味学者は出版日を述べる数の引用をいくつか述べています。これらはおそらくプロトコルのさまざまなドラフトバージョンの引用です。
The next most cited RFC in the sample is [RFC8312] which describes the Cubic congestion control algorithm for TCP. That protocol was also the target of a large number of academic publications. The other RFCs in the sample only have a small number of citations.
サンプル内の次の最も引用されているRFCは、TCPのための立方体輻輳制御アルゴリズムを記述する[RFC8312]です。そのプロトコルはまた、多数の学術出版物の標的でした。サンプル内の他のRFCは単数の引用のみを持ちます。
There is probably a small bias when measuring citations at a fixed date. An RFC published in January 2018 would have more time to accrue citations than one published in December. That may be true to some extent, as the second most cited RFC in the set was published in January. However, the effect has to be limited. The most cited RFC was published in August, and the second most cited was published in 2019. (That RFC got an RFC number in 2018, but publication was slowed by long AUTH48 delays.)
固定日の引用を測定するときはおそらく小さいバイアスがあります。2018年1月に発行されたRFCは、12月に発行されたものよりも引用を生じさせるのに時間があります。1月に1月に2番目に引用されているRFCが発行されたため、ある程度本当かもしれません。しかしながら、その効果は限定されなければならない。最も引用されているRFCは8月に発行され、2019年に最も引用されていた2番目の議決が掲載されていました。
In order to get a baseline, we can look at the number of references for the RFCs published in 2008 and 1998. However, we need to take time into account. Documents published a long time ago are expected to have accrued more references. We try to address this by looking at three counts for each document: the overall number of references over the document's lifetime, the number of references obtained in the year following publication, and the number of references observed since 2018:
ベースラインを取得するために、2008年と1998年に発行されたRFCの参照数を見ることができます。ただし、考慮になる必要があります。昔の前に公開された文書は、より多くの参照を受けたことが期待されています。文書の存続期間の全体的な参照数、出版後の参考文献の数、および2018年以降に観察された参考文献の数を全体的に見てください。
+============+============+=======+===========+===========+
| RFC (2008) | Status | Total | 2008-2009 | 2018-2019 |
+============+============+=======+===========+===========+
| 5326 | Exp | 138 | 14 | 15 |
+------------+------------+-------+-----------+-----------+
| 5348 | PS | 14 | 3 | 0 |
+------------+------------+-------+-----------+-----------+
| 5281 | Info | 69 | 15 | 7 |
+------------+------------+-------+-----------+-----------+
| 5354 | Exp | 17 | 13 | 0 |
+------------+------------+-------+-----------+-----------+
| 5227 | PS | 19 | 1 | 2 |
+------------+------------+-------+-----------+-----------+
| 5329 | PS | 24 | 6 | 1 |
+------------+------------+-------+-----------+-----------+
| 5277 | PS | 32 | 3 | 2 |
+------------+------------+-------+-----------+-----------+
| 5236 | Info (ISE) | 25 | 5 | 4 |
+------------+------------+-------+-----------+-----------+
| 5358 | BCP | 21 | 2 | 0 |
+------------+------------+-------+-----------+-----------+
| 5271 | Info | 7 | 2 | 0 |
+------------+------------+-------+-----------+-----------+
| 5195 | PS | 7 | 4 | 2 |
+------------+------------+-------+-----------+-----------+
| 5283 | PS | 8 | 1 | 0 |
+------------+------------+-------+-----------+-----------+
| 5186 | Info | 14 | 4 | 2 |
+------------+------------+-------+-----------+-----------+
| 5142 | PS | 8 | 4 | 0 |
+------------+------------+-------+-----------+-----------+
| 5373 | PS | 5 | 2 | 0 |
+------------+------------+-------+-----------+-----------+
| 5404 | PS | 1 | 1 | 0 |
+------------+------------+-------+-----------+-----------+
| 5172 | PS | 2 | 0 | 0 |
+------------+------------+-------+-----------+-----------+
| 5349 | Info | 8 | 0 | 2 |
+------------+------------+-------+-----------+-----------+
| 5301 | PS | 5 | 1 | 0 |
+------------+------------+-------+-----------+-----------+
| 5174 | Info | 0 | 0 | 0 |
+------------+------------+-------+-----------+-----------+
Table 11
表11.
+============+============+=======+===========+===========+
| RFC (1998) | Status | Total | 1998-1999 | 2018-2019 |
+============+============+=======+===========+===========+
| 2289 | PS | 2 | 0 | 1 |
+------------+------------+-------+-----------+-----------+
| 2267 | Info | 982 | 5 | 61 |
+------------+------------+-------+-----------+-----------+
| 2317 | BCP | 9 | 1 | 2 |
+------------+------------+-------+-----------+-----------+
| 2404 | PS | 137 | 6 | 1 |
+------------+------------+-------+-----------+-----------+
| 2374 | PS | 42 | 4 | 0 |
+------------+------------+-------+-----------+-----------+
| 2449 | PS | 7 | 2 | 0 |
+------------+------------+-------+-----------+-----------+
| 2283 | PS | 17 | 3 | 2 |
+------------+------------+-------+-----------+-----------+
| 2394 | Info | 13 | 2 | 1 |
+------------+------------+-------+-----------+-----------+
| 2348 | DS | 5 | 0 | 0 |
+------------+------------+-------+-----------+-----------+
| 2382 | Info | 17 | 12 | 0 |
+------------+------------+-------+-----------+-----------+
| 2297 | Info (ISE) | 36 | 11 | 0 |
+------------+------------+-------+-----------+-----------+
| 2381 | PS | 39 | 12 | 0 |
+------------+------------+-------+-----------+-----------+
| 2312 | Info | 14 | 3 | 0 |
+------------+------------+-------+-----------+-----------+
| 2387 | PS | 4 | 1 | 0 |
+------------+------------+-------+-----------+-----------+
| 2398 | Info | 17 | 0 | 1 |
+------------+------------+-------+-----------+-----------+
| 2391 | PS | 31 | 3 | 0 |
+------------+------------+-------+-----------+-----------+
| 2431 | PS | 3 | 0 | 0 |
+------------+------------+-------+-----------+-----------+
| 2282 | Info | 8 | 0 | 0 |
+------------+------------+-------+-----------+-----------+
| 2323 | Info (ISE) | 1 | 0 | 0 |
+------------+------------+-------+-----------+-----------+
| 2448 | Info (ISE) | 0 | 0 | 0 |
+------------+------------+-------+-----------+-----------+
Table 12
表12.
We can compare the median number of citations and the numbers of citations for the least and most popular quartiles in the three years:
3年間で最も人気のある四分類の中央値の中央値と引用数を比較することができます。
+============================+===========+========+============+
| References | Lower 25% | Median | Higher 25% |
+============================+===========+========+============+
| RFC (2018) | 0 | 1 | 3 |
+----------------------------+-----------+--------+------------+
| RFC (2008) | 6.5 | 11 | 21.75 |
+----------------------------+-----------+--------+------------+
| RFC (2008), until 2009 | 1 | 2.5 | 4.5 |
+----------------------------+-----------+--------+------------+
| RFC (2008), 2018 and after | 0 | 0 | 2 |
+----------------------------+-----------+--------+------------+
| RFC (1998) | 4.75 | 13.5 | 32.25 |
+----------------------------+-----------+--------+------------+
| RFC (1998), until 1999 | 0 | 2 | 4.25 |
+----------------------------+-----------+--------+------------+
| RFC (1998), 2018 and after | 0 | 0 | 1 |
+----------------------------+-----------+--------+------------+
Table 13
表13.
The total numbers show new documents with fewer citations than the older ones. This can be explained to some degree by the passage of time. If we restrict the analysis to the number of citations accrued in the year of publishing and the year after that, we still see about the same distribution for the three samples.
総数は、古いものよりも引用が少ない新しい文書を表示します。これは時間の経過によってある程度説明することができる。発行年度およびその後の年の引用数に分析を制限すると、3つのサンプルのための同じ分布についてまだ見ています。
We also see that the number of references to RFCs fades over time. Only the most popular of the RFC produced in 1998 are still cited in 2019.
また、RFCへの参照数は時間の経過とともに消えていることもわかります。1998年に生産されたRFCの最も一般的な人気は、2019年に挙げられています。
The following table shows side by side the number of citations as measured in Section 5.1 and the estimation of deployment as indicated in Section 3.
次の表は、セクション5.1で測定された引用数とセクション3に示されるような展開の推定値を並べて示しています。
+============+============+===========+============+
| RFC (2018) | Status | Citations | Deployment |
+============+============+===========+============+
| 8411 | Info | 1 | medium |
+------------+------------+-----------+------------+
| 8456 | Info | 1 | medium |
+------------+------------+-----------+------------+
| 8446 | PS | 418 | high |
+------------+------------+-----------+------------+
| 8355 | Info | 3 | medium |
+------------+------------+-----------+------------+
| 8441 | PS | 1 | high |
+------------+------------+-----------+------------+
| 8324 | Info (ISE) | 0 | N/A |
+------------+------------+-----------+------------+
| 8377 | PS | 0 | unknown |
+------------+------------+-----------+------------+
| 8498 | Info | 0 | unknown |
+------------+------------+-----------+------------+
| 8479 | Info (ISE) | 0 | one |
+------------+------------+-----------+------------+
| 8453 | Info | 3 | unknown |
+------------+------------+-----------+------------+
| 8429 | BCP | 0 | some |
+------------+------------+-----------+------------+
| 8312 | Info | 25 | high |
+------------+------------+-----------+------------+
| 8492 | Info (ISE) | 4 | one |
+------------+------------+-----------+------------+
| 8378 | Exp | 1 | some |
+------------+------------+-----------+------------+
| 8361 | PS | 0 | one |
+------------+------------+-----------+------------+
| 8472 | PS | 1 | medium |
+------------+------------+-----------+------------+
| 8471 | PS | 1 | medium |
+------------+------------+-----------+------------+
| 8466 | PS | 0 | unknown |
+------------+------------+-----------+------------+
| 8362 | PS | 1 | medium |
+------------+------------+-----------+------------+
| 8468 | Info | 1 | some |
+------------+------------+-----------+------------+
Table 14
表14.
From looking at these results, it is fairly obvious that citation counts cannot be used as proxies for the "value" of an RFC. In our sample, the two RFCs that have high citation counts were both widely deployed, and can certainly be described as successful, but we also see many RFCs that saw significant deployment without garnering a high level of citations.
これらの結果を見ることから、引用数をRFCの「値」のプロキシとして使用できないことはかなり明らかです。私たちのサンプルでは、高い引用数を持つ2つのRFCは両方とも広く展開されていて、確かに成功したものとして説明することができますが、高レベルの引用をもたらさずに有意な展開を見た多くのRFCも見られます。
Citation counts are driven by academic interest, but are only loosely correlated with actual deployment. We saw that [RFC8446] was widely cited in part because the standardization process involved many researchers, and that the high citation count of [RFC8312] is largely due to the academic interest in evaluating congestion control protocols. If we look at previous years, the most cited RFC in the 2008 sample is [RFC5326], an experimental RFC defining security extensions to an experimental delay tolerant transport protocol. This protocol does not carry a significant proportion of Internet traffic, but has been the object of a fair number of academic studies.
引用数は学術的な関心によって推進されていますが、実際の展開とのみ緩やかに相関しています。標準化プロセスは多くの研究者を含んでいたため、標準化プロセスが多くの研究者を含んでいたため、rfc8446が一部引用されていました、そして、RFC8312の高い引用数は大きく輻輳制御プロトコルの評価のための学術的な関心によるものです。過去数年を見れば、2008年のサンプルで最も引用されているRFCは[RFC5326]で、実験的遅延耐性トランスポートプロトコルへのセキュリティ拡張を定義する実験的なRFCです。このプロトコルは、かなりの割合のインターネット交通を持ちませんが、公正な数の学術研究の目的でした。
The citation process tends to privilege the first expression of a concept. We see that with the most cited RFC in the 1998 set is [RFC2267], an informational RFC defining Network Ingress Filtering that was obsoleted in May 2000 by [RFC2827]. It is still cited frequently in 2018 and 2019, regardless of its formal status in the RFC Series. We see the same effect at work with [RFC8441], which garners very few citations although it updates [RFC6455] that has a large number of citations. The same goes for [RFC8468], which is sparsely cited while the [RFC2330] is widely cited. Just counting citations will not indicate whether developers still use an old specification or have adopted the revised RFC.
引用プロセスは、概念の最初の表現を特権化する傾向があります。1998年のセットで最も引用されているRFCでは、[RFC2827]によって廃止されたネットワーク入力フィルタリングを定義した情報RFCは[RFC2267]です。RFCシリーズの正式な状態に関係なく、2018年と2019年にはまだ頻繁に引用されています。CITATIONを更新するけれども、「RFC8441」と同じ効果があります。[RFC2330]が広く引用されている間にまばられる[RFC8468]の場合も同じです。引用を数えるだけで、開発者がまだ古い仕様を使用しているか、改訂されたRFCを採用しているかどうかを示すことはありません。
Web references might be another indicator of the popularity of an RFC. In order to evaluate these references, we list here the number of results returned by searches on Google and Bing, looking for the search term "RFCnnnn" (e.g., "RFC8411"), and copying the number of results returned by the search engines. The table below presents the results of these searches, performed on April 4, 2020.
Web参照は、RFCの人気の別の指標です。これらの参照を評価するために、ここではGoogleとBingの検索によって返された結果の数をリストし、検索語「RFCNNNN」（例えば「RFC8411」）を探し、検索エンジンによって返された結果の数をコピーします。以下の表は、2020年4月4日に行われたこれらの検索の結果を示しています。
+============+============+===========+========+=======+
| RFC (2018) | Status | Citations | Google | Bing |
+============+============+===========+========+=======+
| 8411 | Info | 1 | 301 | 94 |
+------------+------------+-----------+--------+-------+
| 8456 | Info | 1 | 266 | 8456 |
+------------+------------+-----------+--------+-------+
| 8446 | PS | 418 | 25900 | 47800 |
+------------+------------+-----------+--------+-------+
| 8355 | Info | 3 | 521 | 114 |
+------------+------------+-----------+--------+-------+
| 8441 | PS | 1 | 2430 | 59500 |
+------------+------------+-----------+--------+-------+
| 8324 | Info (ISE) | 0 | 393 | 138 |
+------------+------------+-----------+--------+-------+
| 8377 | PS | 0 | 264 | 10900 |
+------------+------------+-----------+--------+-------+
| 8498 | Info | 0 | 335 | 10100 |
+------------+------------+-----------+--------+-------+
| 8479 | Info (ISE) | 0 | 564 | 11000 |
+------------+------------+-----------+--------+-------+
| 8453 | Info | 3 | 817 | 11400 |
+------------+------------+-----------+--------+-------+
| 8429 | BCP | 0 | 391 | 41600 |
+------------+------------+-----------+--------+-------+
| 8312 | Info | 25 | 1620 | 2820 |
+------------+------------+-----------+--------+-------+
| 8492 | Info (ISE) | 4 | 323 | 9400 |
+------------+------------+-----------+--------+-------+
| 8378 | Exp | 1 | 418 | 11600 |
+------------+------------+-----------+--------+-------+
| 8361 | PS | 0 | 499 | 92 |
+------------+------------+-----------+--------+-------+
| 8472 | PS | 1 | 496 | 169 |
+------------+------------+-----------+--------+-------+
| 8471 | PS | 1 | 1510 | 11600 |
+------------+------------+-----------+--------+-------+
| 8466 | PS | 0 | 766 | 173 |
+------------+------------+-----------+--------+-------+
| 8362 | PS | 1 | 67 | 147 |
+------------+------------+-----------+--------+-------+
| 8468 | Info | 1 | 453 | 127 |
+------------+------------+-----------+--------+-------+
Table 15
表15.
The result counts from Bing are sometimes surprising. Why would RFC 8441 gather 59,500 web references? Looking at the results in detail, we find a mix of data. Some of them are logs of development projects implementing Web Sockets, which is exactly what we are looking for, but others appear spurious. For example, a shop selling rugby jerseys is listed because its phone number ends with "8441". Other pages were listed because street numbers or product numbers matched the RFC number. The same type of collision may explain the large reference counts on Bing for RFCs 8377, 8498, 8479, 8453, 8429, 8378, and 8471. The result counts on Bing do not appear to provide a good metric.
Bingからの結果は驚くべきことがあります。RFC 8441が59,500のWeb参照を収集するのはなぜですか？結果を詳しく見ると、データの組み合わせがあります。それらのいくつかは、Webソケットを実装する開発プロジェクトのログです。たとえば、Rugby Jerseを販売しているショップは、その電話番号が「8441」で終わります。街路番号や製品番号がRFC番号に一致したため、他のページが一覧表示されました。同じ種類の衝突は、RFCS 8377,8498,8479,8453,8429,8378、および8471のBING上の大きな参照カウントを説明してもよい。BINGの結果カウントは良好なメトリックを提供するようには見えない。
On Google, all RFCs garner at least a 250 references, largely because the whole RFC catalog is replicated on a large number of web servers. Deviations from that baseline are largely correlated with the number of citations in the Semantic Scholar, with a couple of exception: RFC 8441 and RFC 8471 garner more references than the low citation counts would predict. Looking at the results, we find many references in development databases explaining how these protocols are implemented in various code bases and open source projects. This means that counting Google results would give some indication about an RFC's popularity, complementing the citation counts.
Googleでは、RFCカタログ全体が多数のWebサーバーで複製されるため、すべてのRFCSを少なくとも250の参照を起こします。そのベースラインからの偏差は、Semantic Scholarの引用数とほぼ相関しており、例外がいくつかありました。結果を見ると、これらのプロトコルがさまざまなコードベースおよびオープンソースプロジェクトでどのように実装されているかを説明する開発データベースに多くの参照があります。これは、Googleの結果を数えることで、引用数を補完するRFCの人気に関するいくつかの表示があることを意味します。
There are some practical problems in using the counts of Google results. Google searches are personalized, the results depend on the source of the queries, and the counts may vary as well. The search results depend on the search algorithm, and there is no guarantee that counts will not change when the algorithm changes. On the other hand, the results do indicate that some of the RFCs in our sample are being used by developers or in deployments.
Googleの結果のカウントを使用するには、実用的な問題がいくつかあります。Google検索はパーソナライズされ、結果はクエリのソースによって異なり、カウントも変わります。検索結果は検索アルゴリズムによって異なり、アルゴリズムが変更されたときにカウントが変わらないという保証はありません。一方、結果は、サンプル内のRFCの一部が開発者または展開で使用されていることを示しています。
The author's goal was to get a personal understanding of the "chain of production" of the RFCs, and in particular to look at the various causes of delays in the process. As shown in Section 4, the average RFC was produced in 3 years and 4 months, which is similar to what was found in the 2008 sample, but more than three times larger than the delays for the 1998 sample.
著者の目標は、RFCの「生産チェーン」を個人的に理解し、特にプロセスの遅延のさまざまな原因を調べることでした。第4部に示すように、平均RFCは3年と4ヶ月で生産され、これは2008年のサンプルで見つかったものと似ていますが、1998年のサンプルの遅延よりも3倍以上。
The working group process appears to be the main source of delays. Efforts to diminish delays should probably focus there, instead of on the IETF and IESG reviews or the RFC production. For the RFC production phase, most of the variability originates in the AUTH48 process, which is influenced by a variety of factors such as number of authors or level of engagement of these authors.
作業グループプロセスは遅延の主な原因となるようです。IETFおよびIESGのレビューまたはRFC制作の代わりに、遅延を減らすための努力は、おそらくそこに焦点を合わせるべきです。RFC生産段階では、ほとんどの変動性はAUT48プロセスに起因しており、これは著者の数やこれらの作者の係合のレベルなどのさまざまな要因によって影響されます。
Most of the delay is spent in the working group, but the IETF Datatracker does not hold much information about what happens inside the working groups. For example, events like Working Group Last Calls were not recorded in the history of the selected drafts available in the Datatracker. Such information would have been interesting. Of course, requiring that information would create an administrative burden, so there is clearly a trade-off between requiring more work from working group chairs and providing better data for process analysis. (It appears that this information can be available in the Datatracker for more recent drafts, if the WG chairs use the Datatracker properly.)
ほとんどの遅延はワーキンググループに費やされますが、IETF DataTrackerはワーキンググループの中で何が起こるのかについての多くの情報を保持していません。たとえば、ワーキンググループの最後の呼び出しのようなイベントは、DataTrackerで利用可能な選択されたドラフトの履歴には記録されませんでした。そのような情報は興味深いでしょう。もちろん、その情報が管理上の負担を生み出すことを要求するので、作業グループの椅子からより多くの作業を必要とし、プロセス分析のためのより良いデータを提供することの間のトレードオフが明確にあります。（この情報は、WGチェアがDataTrackerを正しく使用している場合は、より最近のドラフトのためにDataTrackerで利用できるようになるようです。）
The Independent Stream operates as expected. The majority of the authors of the Independent Stream RFCs appear to be in IETF insiders, but there is significant amount of engagement by outside parties.
独立したストリームは予想どおりに動作します。独立したStream RFCの著者の大部分はIETFインサイダーにあるように見えますが、外部の締約国による関与が大幅にあります。
The analysis of citations in Section 5.1 shows that citation numbers are a very poor indication of the "value" of an RFC. Citation numbers measure the engagement of academic researchers with specific topics, but have little correlation with the level of adoption and deployment of a specific RFC. The result counts of Google searches do capture references outside academia, such as logs of development projects. This might be informative, but it is not clear that the counts would not change over time due to algorithm changes or personalization.
セクション5.1の引用の分析は、引用数がRFCの「値」の非常に悪い表示であることを示しています。引用数は、学術研究者の具体的なトピックとの関与を測定しますが、特定のRFCの採用と展開とはほとんど相関がありません。Google検索の結果カウントは、開発プロジェクトのログなど、学界外での参照を取得します。これは有益なものかもしれませんが、アルゴリズムの変更やパーソナライズにより、数が経時的に変化しないことは明らかではありません。
This document analyses a small sample of RFCs "in depth". This allowed gathering of detailed feedback on the process and the deployments. On the other hand, much of the data on delays is available from the IETF Datatracker. It may be worth considering adding an automated reporting of delay metrics in the IETF Datatracker.
この文書はRFCの小さなサンプル「深さ」を分析します。これにより、プロセスと展開に関する詳細なフィードバックの収集が可能になりました。一方、遅延に関するデータの大部分はIETF DataTrackerから入手できます。IETF DataTrackerの遅延メトリックの自動レポートを追加することを検討する価値があるかもしれません。
This document only considers the RFCs that were published in a given year. This approach can be criticized as introducing a form of "survivor bias". There are many drafts proposed to the IETF, and only a fraction of them end up being published as RFCs. On one hand, this is expected, because part of the process is to triage between ideas that can gather consensus and those that don't. On the other hand, we don't know whether that triage is too drastic and has discouraged progress on good ideas.
この文書は、特定の年に公開されたRFCを検討します。このアプローチは、「生存者バイアス」の形を導入すると批判することができます。IETFに提案されたドラフトはたくさんあり、それらのほんの一部だけがRFCとして公開されています。一方では、このプロセスの一部は、コンセンサスとそうでないものとの間のアイデアの間のトリアージであるため、これは予想されます。その一方で、そのトリアージが急すぎて良いアイデアで進歩を難しくしたのかはわかりません。
One way to evaluate the triage process would be to look at publication attempts that were abandoned -- for example, drafts that expired without progressing or being replaced. The sampling methodology could also be used for that purpose. Pick maybe 20 drafts at random, among those abandoned in a target year, and investigate why they were abandoned. Was it because better solutions emerged in the working group? Or maybe because the authors discovered a flaw in their proposal? Or was it because some factional struggle blocked a good idea? Was the idea pursued in a different venue? Hopefully, someone will try this kind of investigation.
トリアージプロセスを評価する1つの方法は、放棄された出版試行を検討することです - たとえば、進行中または交換されずに期限切れになったドラフト。サンプリング方法論もその目的に使用できます。ターゲット年に放棄されたもののうち、ランダムに20ドラフトを選んで、それらが放棄された理由を調査します。より良いソリューションがワーキンググループに登場したためでしたか？あるいは、著者らは彼らの提案の欠陥を発見したからですか？それともいくつかの派閥の闘争が良い考えをブロックしたためでしたか？アイデアは別の会場で追求されましたか？うまくいけば、誰かがこのような調査を試みます。
This document does not specify any protocol.
この文書はプロトコルを指定しません。
We might want to analyze whether security issues were discovered after publication of specific standards.
特定の標準の発行後にセキュリティの問題が発見されたかどうかを分析したいと思うかもしれません。
This document has no IANA actions.
この文書にはIANAの行動がありません。
Preliminary analysis does not indicate that IANA is causing any particular delay in the RFC publication process.
予備分析は、IANAがRFC出版プロセスの特定の遅延を引き起こしていることを示していません。
[IETFCOUNT] IETF, "Past IETF Meetings", <https://www.ietf.org/how/meetings/past/>.
[IETFCOUNT] IETF、「過去のIETFミーティング」、<https：//www.ietf.org/how/meetings/past/>。
[RFC2267] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", RFC 2267, DOI 10.17487/RFC2267, January 1998, <https://www.rfc-editor.org/info/rfc2267>.
[RFC2267] Ferguson、P.およびD. Senie、「ネットワーク入力フィルタリング：IP送信元アドレスのなりすましを採用するサービス拒否攻撃の破損」、RFC 2267、DOI 10.17487 / RFC2267、1998年1月、<https：//www.rfc-editor.org/info/rfc2267>。
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.
[RFC2330] Paxson、V.、Almes、G.、MAHDAVI、J.、およびM Mathis、「IPパフォーマンスメトリックのためのフレームワーク」、RFC 2330、DOI 10.17487 / RFC2330、1998年5月、<https：//www.rfc-editor.org/info/rfc2330>。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC2827] Ferguson、P.およびD. Senie、「ネットワーク入力フィルタリング：IP送信元アドレスのなりすましを採用するサービス拒否の拒否」、BCP 38、RFC 2827、DOI 10.17487 / RFC2827、2000年5月、<https：// www.rfc-editor.org / info / rfc2827>。
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider Transmission Protocol - Specification", RFC 5326, DOI 10.17487/RFC5326, September 2008, <https://www.rfc-editor.org/info/rfc5326>.
[RFC5326] RAMADAS、M.、BURLEIGH、S。FERRELL、「LICKLIDER伝送プロトコル - 仕様」、RFC 5326、DOI 10.17487 / RFC5326、2008年9月、<https：//www.rfc-editor.org/情報/ RFC5326>。
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 6455, DOI 10.17487/RFC6455, December 2011, <https://www.rfc-editor.org/info/rfc6455>.
[RFC6455] Fette、I.およびA.Melnikov、「WebSocketプロトコル」、RFC 6455、DOI 10.17487 / RFC6455、2011年12月、<https：//www.rfc-editor.org/info/rfc6455>。
[RFC8312] Rhee, I., Xu, L., Ha, S., Zimmermann, A., Eggert, L., and R. Scheffenegger, "CUBIC for Fast Long-Distance Networks", RFC 8312, DOI 10.17487/RFC8312, February 2018, <https://www.rfc-editor.org/info/rfc8312>.
[RFC8312] Rhee、I.、Xu、L.、HA、S・、Zimmermann、A.、Heghert、L.、およびR.ScheffeNgger、RFC 8312、DOI 10.17487 / RFC83122018年2月、<https：//www.rfc-editor.org/info/rfc8312>。
[RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look?", RFC 8324, DOI 10.17487/RFC8324, February 2018, <https://www.rfc-editor.org/info/rfc8324>.
[RFC8324] Klensin、J.、 "DNSのプライバシー、承認、特別な用途、エンコード、文字、マッチング、およびルート構造：他の外観のための時間：2018年2月、2018年2月、<https：//www.rfc-editor.org/info/rfc8324>。
[RFC8355] Filsfils, C., Ed., Previdi, S., Ed., Decraene, B., and R. Shakir, "Resiliency Use Cases in Source Packet Routing in Networking (SPRING) Networks", RFC 8355, DOI 10.17487/RFC8355, March 2018, <https://www.rfc-editor.org/info/rfc8355>.
[RFC8355] Filsfils、C、ED。、PREVIDI、S、ED。、Decraene、B.、およびR. Shakir、「ネットワーキング（Spring）ネットワークにおけるソースパケットルーティングにおける回復力使用例」、RFC 8355、DOI 10.17487/ RFC8355、2018年3月、<https：//www.rfc-editor.org/info/rfc8355>。
[RFC8361] Hao, W., Li, Y., Durrani, M., Gupta, S., and A. Qu, "Transparent Interconnection of Lots of Links (TRILL): Centralized Replication for Active-Active Broadcast, Unknown Unicast, and Multicast (BUM) Traffic", RFC 8361, DOI 10.17487/RFC8361, April 2018, <https://www.rfc-editor.org/info/rfc8361>.
[RFC8361]ハオ、W.、Li、Y.、Durrani、M.、Gupta、S.、A. Qu、「ロットの透明な相互接続（トリル）：能動的な放送の集中複製、不明なユニキャスト、およびマルチキャスト（BUM）トラフィック "、RFC 8361、DOI 10.17487 / RFC8361、2018年4月、<https://www.rfc-editor.org/info/rfc8361>。
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and F. Baker, "OSPFv3 Link State Advertisement (LSA) Extensibility", RFC 8362, DOI 10.17487/RFC8362, April 2018, <https://www.rfc-editor.org/info/rfc8362>.
[RFC8362]リンデム、A.、Roy、A.、Goethals、D.、Reddy Vallem、V.、F. Baker、 "OSPFv3リンク州広告（LSA）拡張性"、RFC 8362、DOI 10.17487 / RFC8362、2018年4月<https://www.rfc-editor.org/info/rfc8362>。
[RFC8377] Eastlake 3rd, D., Zhang, M., and A. Banerjee, "Transparent Interconnection of Lots of Links (TRILL): Multi-Topology", RFC 8377, DOI 10.17487/RFC8377, July 2018, <https://www.rfc-editor.org/info/rfc8377>.
[RFC8377]イーストレイク3RD、D.、Zhang、M.、およびA. Banerjee、「ロットの透明な相互接続（トリル）：マルチトポロジー」、RFC 8377、DOI 10.17487 / RFC8377、2018年7月、<https：//www.rfc-editor.org/info/rfc8377>。
[RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, May 2018, <https://www.rfc-editor.org/info/rfc8378>.
[RFC8378] Moreno、V.およびD. Farinacci、「シグナルフリーロケーター/ ID分離プロトコル（LISP）マルチキャスト」、RFC 8378、DOI 10.17487 / RFC8378、2018年5月、<https：//www.rfc-editor.org/ info / rfc8378>。
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8402] Filsfils、C、Ed。、Previdi、S.、Ed。、Ginsberg、L.、Decraene、B.、Litkowski、S.、およびR. Shakir、「セグメントルーティングアーキテクチャ」、RFC 8402、DOI 10.17487/ RFC8402、2018年7月、<https://www.rfc-editor.org/info/rfc8402>。
[RFC8410] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519, and X448 for Use in the Internet X.509 Public Key Infrastructure", RFC 8410, DOI 10.17487/RFC8410, August 2018, <https://www.rfc-editor.org/info/rfc8410>.
[RFC8410] Josefsson、S.およびJ.Schaad、「Internet X.509公開鍵基盤で使用するためのED25519、ED448、X25519、およびX448のアルゴリズム識別子」、RFC 8410、DOI 10.17487 / RFC8410、2018年8月、<HTTPS//www.rfc-editor.org/info/rfc8410>。
[RFC8411] Schaad, J. and R. Andrews, "IANA Registration for the Cryptographic Algorithm Object Identifier Range", RFC 8411, DOI 10.17487/RFC8411, August 2018, <https://www.rfc-editor.org/info/rfc8411>.
[RFC8411] Schaad、J.およびR. Andrews、「暗号化アルゴリズムのオブジェクト識別子の識別範囲のIANA登録」、2018年8月、2018年8月、<https://www.rfc-editor.org/info/RFC8411>。
[RFC8429] Kaduk, B. and M. Short, "Deprecate Triple-DES (3DES) and RC4 in Kerberos", BCP 218, RFC 8429, DOI 10.17487/RFC8429, October 2018, <https://www.rfc-editor.org/info/rfc8429>.
[RFC8429] Kaduk、B.およびM. Short、 "Kerberosの脱水口廃棄）、BCP 218、RFC 8429、DOI 10.17487 / RFC8429、2018年10月、<https：//www.rfc-編集者.ORG / INFO / RFC8429>。
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", RFC 8441, DOI 10.17487/RFC8441, September 2018, <https://www.rfc-editor.org/info/rfc8441>.
[RFC8441] McManus、P.、「HTTP / 2のBootstraping WebSockets、RFC 8441、DOI 10.17487 / RFC8441、2018年9月、<https：//www.rfc-editor.org/info/rfc8441>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for Abstraction and Control of TE Networks (ACTN)", RFC 8453, DOI 10.17487/RFC8453, August 2018, <https://www.rfc-editor.org/info/rfc8453>.
[RFC8453] Ceccarelli、D.、ED。そして、「TEネットワーク（ACTN）の抽象化と管理のためのフレームワーク（ACTN）」、RFC 8453、DOI 10.17487 / RFC8453、2018年8月、<https：//www.rfc-editor.org/info/rfc8453>。
[RFC8455] Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Terminology for Benchmarking Software-Defined Networking (SDN) Controller Performance", RFC 8455, DOI 10.17487/RFC8455, October 2018, <https://www.rfc-editor.org/info/rfc8455>.
[RFC8455] Bhuvaneswaran、V.、Basil、A.、A.、Tassinari、M。、Manral、V.、およびS. Banks、「ベンチマークソフトウェア定義ネットワーク（SDN）コントローラのパフォーマンスのための用語」、RFC 8455、DOI 10.17487 / RFC84552018年10月、<https://www.rfc-editor.org/info/rfc8455>。
[RFC8456] Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Benchmarking Methodology for Software-Defined Networking (SDN) Controller Performance", RFC 8456, DOI 10.17487/RFC8456, October 2018, <https://www.rfc-editor.org/info/rfc8456>.
[RFC8456] Bhuvaneswaran、V.、Basil、A。、Tassinari、M.、Manral、V.、およびS. Banks、「ソフトウェア定義ネットワーキング（SDN）コントローラのパフォーマンスのためのベンチマーク方法」、RFC 8456、DOI 10.17487 / RFC84562018年10月、<https://www.rfc-editor.org/info/rfc8456>。
[RFC8466] Wen, B., Fioccola, G., Ed., Xie, C., and L. Jalil, "A YANG Data Model for Layer 2 Virtual Private Network (L2VPN) Service Delivery", RFC 8466, DOI 10.17487/RFC8466, October 2018, <https://www.rfc-editor.org/info/rfc8466>.
[RFC8466]ウェン、B.、Fioccola、G.、ED。、XIE、C、およびL.Jalil、「レイヤ2仮想プライベートネットワーク（L2VPN）サービス配信のためのYangデータモデル、RFC 8466、DOI 10.17487 /RFC8466、2018年10月、<https：//www.rfc-editor.org/info/rfc8466>。
[RFC8468] Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework", RFC 8468, DOI 10.17487/RFC8468, November 2018, <https://www.rfc-editor.org/info/rfc8468>.
[RFC8468]モートン、A。、Fabini、J.、Elkins、N.、Ackermann、M.、V.HEGDE、「IPv4、IPv6、およびIPv4-IPv6共存：IPパフォーマンスメトリック（IPPM）フレームワークの更新」、RFC 8468、DOI 10.17487 / RFC8468、2018年11月、<https：//www.rfc-editor.org/info/rfc8468>。
[RFC8471] Popov, A., Ed., Nystroem, M., Balfanz, D., and J. Hodges, "The Token Binding Protocol Version 1.0", RFC 8471, DOI 10.17487/RFC8471, October 2018, <https://www.rfc-editor.org/info/rfc8471>.
[RFC8471]ポップフ、A.、ED。、NYSTROEM、M.、Balfanz、D.、およびJ.Hodges、「トークンバインディングプロトコルバージョン1.0」、RFC 8471、DOI 10.17487 / RFC8471、2018年10月、<https：//www.rfc-editor.org/info/rfc8471>。
[RFC8472] Popov, A., Ed., Nystroem, M., and D. Balfanz, "Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation", RFC 8472, DOI 10.17487/RFC8472, October 2018, <https://www.rfc-editor.org/info/rfc8472>.
[RFC8472]ポップフ、A.、ED。、NYSTROEM、M.、およびD.Balfanz、「トークンバインディングプロトコルネゴシエーションのためのトランスポート層セキュリティ（TLS）拡張」、RFC 8472、DOI 10.17487 / RFC8472、2018年10月、<https：//www.rfc-editor.org/info/rfc8472>。
[RFC8479] Mavrogiannopoulos, N., "Storing Validation Parameters in PKCS#8", RFC 8479, DOI 10.17487/RFC8479, September 2018, <https://www.rfc-editor.org/info/rfc8479>.
[RFC8479] MavrogianNopoulos、N.、「PKCS＃8」、RFC 8479、DOI 10.17487 / RFC8479、2018年9月、<https://www.rfc-editor.org/info/rfc8479>。
[RFC8483] Song, L., Ed., Liu, D., Vixie, P., Kato, A., and S. Kerr, "Yeti DNS Testbed", RFC 8483, DOI 10.17487/RFC8483, October 2018, <https://www.rfc-editor.org/info/rfc8483>.
[RFC8483]ソング、L.、ED。、LIU、D.、Vixie、P.、Kato、A.、およびS.Kerr、 "iti DNS Testbed"、RFC 8483、DOI 10.17487 / RFC8483、2018年10月、<HTTPS：//www.rfc-editor.org/info/rfc8483>。
[RFC8492] Harkins, D., Ed., "Secure Password Ciphersuites for Transport Layer Security (TLS)", RFC 8492, DOI 10.17487/RFC8492, February 2019, <https://www.rfc-editor.org/info/rfc8492>.
[RFC8492] Harkins、D.、ED。、「トランスポート層セキュリティのための安全なパスワード暗号（TLS）」、RFC 8492、DOI 10.17487 / RFC8492、2019年2月、<https：//www.rfc-editor.org/info/RFC8492>。
[RFC8493] Kunze, J., Littman, J., Madden, E., Scancella, J., and C. Adams, "The BagIt File Packaging Format (V1.0)", RFC 8493, DOI 10.17487/RFC8493, October 2018, <https://www.rfc-editor.org/info/rfc8493>.
[RFC8493] Kunze、J.、Littman、J.、Madden、E.、Scancella、J.、およびC.ADAMS、「バギットファイル包装形式（V1.0）」、RFC 8493、DOI 10.17487 / RFC8493、10月2018年、<https：//www.rfc-editor.org/info/rfc8493>。
[RFC8498] Mohali, M., "A P-Served-User Header Field Parameter for an Originating Call Diversion (CDIV) Session Case in the Session Initiation Protocol (SIP)", RFC 8498, DOI 10.17487/RFC8498, February 2019, <https://www.rfc-editor.org/info/rfc8498>.
[RFC8498] Mohali、M。、「セッション開始プロトコル（SIP）」、RFC 8498、DOI 10.17487 / RFC8498、2019年2月、<https://www.rfc-editor.org/info/rfc8498>。
[RFCYEAR] RFC Editor, "Number of RFC Published per YEAR", <https://www.rfc-editor.org/rfcs-per-year/>.
[RFCYER] RFCエディタ、「年間公開されたRFCの数」、<https：//www.rfc-editor.org/rfcs-per-year/>。
[SSCH] Allen Institute for AI, "Semantic Scholar | AI-Powered Research Tool", <https://www.semanticscholar.org/>.
[SSCH] Allen AI、「Semantic Scholar | AI-Powered Research Tool」、<https：//www.semanticscholol.org/>。
[TI-LFA] Litkowski, S., Bashandy, A., Filsfils, C., Decraene, B., and D. Voyer, "Topology Independent Fast Reroute using Segment Routing", Work in Progress, Internet-Draft, draft-ietf-rtgwg-segment-routing-ti-lfa-05, 15 November 2020, <https://tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-05>.
[TI-LFA] Litkowski、S.、Bashandy、A.、Filsfils、C.、Decraene、B.、およびD.航海、「トポロジ独立高速Reroute」、進行中、インターネットドラフト、ドラフトIETF-RTGWG-SEGMENT-ROUTING-TI-LFA-05,15月15日、<https：//tools.ietf.org/html/draft-ietf-rtgwg-segment-routing-ti-lfa-05>。
[TLS13IMP] TLS WG, "TLS 1.3 Implementations", commit dcb7890, 14 October 2019, <https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md>.
[TLS13IMP] TLS WG、「TLS 1.3実装」、2019年10月14日、<https：//github.com/tlswg/tlswg-wiki/blob/master/implementations.md>。
[TRKR] IETF, "IETF Datatracker", <https://datatracker.ietf.org/>.
[TRKR] IETF、「IETF DataTracker」、<https：//datatracker.ietf.org/>。
Acknowledgements
謝辞
Many thanks to the authors of the selected RFCs who were willing to provide feedback on the process: Michael Ackermann, Zafar Ali, Sarah Banks, Bruno Decraene, Lars Eggert, Nalini Elkins, Joachim Fabini, Dino Farinacci, Clarence Filsfils, Sujay Gupta, Dan Harkins, Vinayak Hegde, Benjamin Kaduk, John Klensin, Acee Lindem, Nikos Mavrogiannopoulos, Patrick McManus, Victor Moreno, Al Morton, Andrei Popov, Eric Rescorla, Michiko Short, Bhuvaneswaran Vengainathan, Lao Weiguo, and Li Yizhou. Many thanks to Adrian Farrel for his useful advice, to Stephen Farrell and Colin Perkins for their guidance on the use of citations, and to Dave Crocker for a comprehensive review. Thanks also to Alice Russo and the RFC Editor team for their work improving this document and checking the accuracy of the data.
プロセスについてフィードバックを提供しても構わないと思っていた選択されたRFCの著者たちのおかげで、Michael Ackermann、Zafar Ali、Sarah Banks、Bruno Decraene、Lars Eggert、Nalini Elkins、Joachim Fabini、Dino Farinacci、Clarence Filsfils、Sujay Gupta、DanHarkins、Vinayak Hegde、Benjamin Kaduk、John Klensin、Acee Lindem、Nikos MavrogianNopoulos、Patrick Mavrogiannopoulos、Patrick Mcmanus、Al Morton、Andrei Popov、Eric Rescorla、Bhuvaneswaran Vengainathan、Lao Weiguo、Li Yizhou。彼の有用なアドバイスのためのアドリアン・ファレルに感謝し、引用の利用に関するガイダンスのために、そして包括的なレビューのためにCrockerをDave Daveにするために、RussoとRFCエディタチームとRFCエディタチームもこの文書を改善し、データの正確さを確認してくれてありがとう。
Author's Address
著者の住所
Christian Huitema Private Octopus Inc. 427 Golfcourse Rd Friday Harbor, WA 98250 United States of America
Christian Huitema Private Octopus Inc. 427 Golfcourse RD Friday Harbour、WA 98250アメリカ合衆国
Email: huitema@huitema.net