[要約] RFC 9413は、長期的なプロトコルの相互運用性を実現するために、アクティブなプロトコルメンテナンスを説明しています。仕様と実装を進化させることで、時間とともに曖昧さを減らし、健全なエコシステムを作り出すことが可能です。
Internet Architecture Board (IAB) M. Thomson
Request for Comments: 9413
Category: Informational D. Schinazi
ISSN: 2070-1721 June 2023
The main goal of the networking standards process is to enable the long-term interoperability of protocols. This document describes active protocol maintenance, a means to accomplish that goal. By evolving specifications and implementations, it is possible to reduce ambiguity over time and create a healthy ecosystem.
ネットワーク標準プロセスの主な目標は、プロトコルの長期的な相互運用性を有効にすることです。このドキュメントは、その目標を達成する手段であるアクティブなプロトコルのメンテナンスについて説明しています。仕様と実装を進化させることにより、時間の経過とともにあいまいさを減らし、健全なエコシステムを作成することが可能です。
The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. However, it has been interpreted in a variety of ways. While some interpretations help ensure the health of the Internet, others can negatively affect interoperability over time. When a protocol is actively maintained, protocol designers and implementers can avoid these pitfalls.
しばしば「あなたが送るものに保守的であり、あなたが受け入れるものにリベラルである」と表現された堅牢性の原則は、インターネットプロトコルの設計と実装を長い間導いてきました。ただし、さまざまな方法で解釈されています。いくつかの解釈はインターネットの健康を確保するのに役立ちますが、他の解釈は時間の経過とともに相互運用性に悪影響を与える可能性があります。プロトコルが積極的に維持されると、プロトコル設計者と実装者はこれらの落とし穴を回避できます。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. It represents the consensus of the Internet Architecture Board (IAB). Documents approved for publication by the IAB are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが恒久的な記録を提供する価値があると判断した情報を表しています。インターネットアーキテクチャボード（IAB）のコンセンサスを表しています。IABによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。RFC 7841のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9413.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9413で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
1. Introduction
2. Protocol Robustness
2.1. Fallibility of Specifications
2.2. Extensibility
2.3. Flexible Protocols
3. Applicability
4. Harmful Consequences of Tolerating the Unexpected
4.1. Protocol Decay
4.2. Ecosystem Effects
5. Active Protocol Maintenance
5.1. Virtuous Intolerance
5.2. Exclusion
6. Security Considerations
7. IANA Considerations
8. Informative References
IAB Members at the Time of Approval
Acknowledgments
Authors' Addresses
There is good evidence to suggest that many important protocols are routinely maintained beyond their inception. In particular, a sizable proportion of IETF activity is dedicated to the stewardship of existing protocols. This document first discusses hazards in applying the robustness principle too broadly (see Section 2) and offers an alternative strategy for handling interoperability problems in deployments (see Section 5).
多くの重要なプロトコルが開始を超えて日常的に維持されていることを示唆する良い証拠があります。特に、IETFアクティビティのかなりの割合は、既存のプロトコルの管理に専念しています。このドキュメントでは、まず、堅牢性の原則を広く適用しすぎる危険性について説明し（セクション2を参照）、展開における相互運用性の問題を処理するための代替戦略を提供します（セクション5を参照）。
Ideally, protocol implementations can be actively maintained so that unexpected conditions are proactively identified and resolved. Some deployments might still need to apply short-term mitigations for deployments that cannot be easily updated, but such cases need not be permanent. This is discussed further in Section 5.
理想的には、プロトコルの実装を積極的に維持できるため、予期しない条件が積極的に特定され解決されます。一部の展開は、簡単に更新できない展開に短期緩和を適用する必要がある場合がありますが、そのようなケースは永続的である必要はありません。これについては、セクション5でさらに説明します。
The robustness principle has been hugely influential in shaping the design of the Internet. As stated in the IAB document "Architectural Principles of the Internet" [RFC1958], the robustness principle advises to:
堅牢性の原則は、インターネットの設計を形作ることに大きな影響を与えています。IABドキュメント「インターネットの建築原理」[RFC1958]に記載されているように、堅牢性の原則は次のとおりです。
Be strict when sending and tolerant when receiving. Implementations must follow specifications precisely when sending to the network, and tolerate faulty input from the network. When in doubt, discard faulty input silently, without returning an error message unless this is required by the specification.
送信時に厳格になり、受信するときは寛容になります。実装は、ネットワークに送信するときに正確に仕様に従い、ネットワークからの誤った入力を許容する必要があります。疑わしい場合は、仕様で要求されない限り、エラーメッセージを返すことなく、故障した入力を静かに捨ててください。
This simple statement captures a significant concept in the design of interoperable systems. Many consider the application of the robustness principle to be instrumental in the success of the Internet as well as the design of interoperable protocols in general.
この単純なステートメントは、相互運用可能なシステムの設計において重要な概念を捉えています。多くの人は、堅牢性の原則の適用は、インターネットの成功と、一般的な相互運用可能なプロトコルの設計に役立つと考えています。
There are three main aspects to the robustness principle:
堅牢性の原則には3つの主な側面があります。
Robustness to software defects:
ソフトウェアの欠陥への堅牢性：
No software is perfect, and failures can lead to unexpected behavior. Well-designed software strives to be resilient to such issues, whether they occur in the local software or in software that it communicates with. In particular, it is critical for software to gracefully recover from these issues without aborting unrelated processing.
完璧なソフトウェアはなく、障害は予期しない動作につながる可能性があります。適切に設計されたソフトウェアは、ローカルソフトウェアや通信するソフトウェアで発生するかどうかにかかわらず、そのような問題に回復力があるように努めています。特に、ソフトウェアが無関係な処理を中止せずにこれらの問題から優雅に回復することが重要です。
Robustness to attacks:
攻撃への堅牢性：
Since not all actors on the Internet are benevolent, networking software needs to be resilient to input that is intentionally crafted to cause unexpected consequences. For example, software must ensure that invalid input doesn't allow the sender to access data, change data, or perform actions that it would otherwise not be allowed to.
インターネット上のすべての関係者が慈悲深いわけではないため、ネットワーキングソフトウェアは、予期しない結果を引き起こすために意図的に作成された入力に対して回復力がある必要があります。たとえば、ソフトウェアは、無効な入力で、送信者がデータにアクセスしたり、データを変更したり、許可されていないアクションを実行したりしないようにする必要があります。
Robustness to the unexpected:
予想外の堅牢性：
It can be possible for an implementation to receive inputs that the specification did not prepare it for. This scenario excludes those cases where a the specification explicitly defines how a faulty message is handled. Instead, this refers to cases where handling is not defined or where there is some ambiguity in the specification. In this case, some interpretations of the robustness principle advocate that the implementation tolerate the faulty input and silently discard it. Some interpretations even suggest that a faulty or ambiguous message be processed according to the inferred intent of the sender.
実装では、仕様が準備されていない入力を受け取ることができます。このシナリオでは、仕様が故障したメッセージの処理方法を明示的に定義するケースを除外します。代わりに、これは、取り扱いが定義されていない場合や、仕様に曖昧さがある場合を指します。この場合、堅牢性の原則のいくつかの解釈は、実装が故障した入力を許容し、それを静かに破棄することを主張しています。いくつかの解釈は、送信者の推測された意図に従って不良または曖昧なメッセージが処理されることさえ示唆しています。
The facets of the robustness principle that protect against defects or attacks are understood to be necessary guiding principles for the design and implementation of networked systems. However, an interpretation that advocates for tolerating unexpected inputs is no longer considered best practice in all scenarios.
欠陥または攻撃から保護する堅牢性の原則の側面は、ネットワークシステムの設計と実装に必要な指針となると理解されています。ただし、予期しない入力を許容することを提唱する解釈は、すべてのシナリオでベストプラクティスとは考えられなくなりました。
Time and experience show that negative consequences to interoperability accumulate over time if implementations silently accept faulty input. This problem originates from an implicit assumption that it is not possible to effect change in a system the size of the Internet. When one assumes that changes to existing implementations are not presently feasible, tolerating flaws feels inevitable.
時間と経験は、実装が誤った入力を静かに受け入れると、相互運用性への負の結果が時間とともに蓄積することを示しています。この問題は、インターネットのサイズのシステムで変化をもたらすことができないという暗黙の仮定から生じています。既存の実装の変更が現在実行可能ではないと仮定すると、欠陥を許容することは避けられないと感じます。
Many problems that this third aspect of the robustness principle was intended to solve can instead be better addressed by active maintenance. Active protocol maintenance is where a community of protocol designers, implementers, and deployers work together to continuously improve and evolve protocol specifications alongside implementations and deployments of those protocols. A community that takes an active role in the maintenance of protocols will no longer need to rely on the robustness principle to avoid interoperability issues.
堅牢性の原則のこの3番目の側面が解決することを意図していた多くの問題は、代わりにアクティブなメンテナンスによってより適切に対処できる可能性があります。アクティブなプロトコルメンテナンスは、プロトコル設計者、実装者、および展開者のコミュニティが協力して、これらのプロトコルの実装と展開とともに、プロトコル仕様を継続的に改善および進化させる場所です。プロトコルのメンテナンスに積極的な役割を果たすコミュニティは、相互運用性の問題を回避するために堅牢性の原則に依存する必要がなくなります。
The context from which the robustness principle was developed provides valuable insights into its intent and purpose. The earliest form of the principle in the RFC Series (the Internet Protocol specification [RFC0760]) is preceded by a sentence that reveals a motivation for the principle:
堅牢性の原則が開発されたコンテキストは、その意図と目的に対する貴重な洞察を提供します。RFCシリーズ（インターネットプロトコル仕様[RFC0760]）の原則の最古の形式の前に、原則の動機を明らかにする文があります。
While the goal of this specification is to be explicit about the protocol there is the possibility of differing interpretations. In general, an implementation should be conservative in its sending behavior, and liberal in its receiving behavior.
この仕様の目標は、プロトコルについて明示的であることですが、異なる解釈の可能性があります。一般に、実装は送信行動において保守的であり、受信行動においてリベラルでなければなりません。
This formulation of the principle expressly recognizes the possibility that the specification could be imperfect. This contextualizes the principle in an important way.
この原則の定式化は、仕様が不完全である可能性を明示的に認識しています。これは、重要な方法で原則を文脈化します。
Imperfect specifications are unavoidable, largely because it is more important to proceed to implementation and deployment than it is to perfect a specification. A protocol benefits greatly from experience with its use. A deployed protocol is immeasurably more useful than a perfect protocol specification. This is particularly true in early phases of system design, to which the robustness principle is best suited.
不完全な仕様は避けられません。主に、仕様を完成させるよりも実装と展開に進むことがより重要であるためです。プロトコルは、その使用の経験から大きな恩恵を受けます。展開されたプロトコルは、完璧なプロトコル仕様よりも計り知れないほど便利です。これは、システム設計の初期段階で特に当てはまります。これには、堅牢性の原理が最適です。
As demonstrated by the IAB document "What Makes for a Successful Protocol?" [RFC5218], success or failure of a protocol depends far more on factors like usefulness than on technical excellence. Timely publication of protocol specifications, even with the potential for flaws, likely contributed significantly to the eventual success of the Internet.
IABドキュメント「プロトコルを成功させるものは何ですか？」[RFC5218]、プロトコルの成功または失敗は、技術的な卓越性よりも有用性などの要因にはるかに依存します。プロトコル仕様のタイムリーな公開は、欠陥の可能性がある場合でも、インターネットの最終的な成功に大きく貢献した可能性があります。
This premise that specifications will be imperfect is correct. However, ignoring faulty or ambiguous input is almost always the incorrect solution to the problem.
仕様が不完全であるというこの前提は正しいです。ただし、誤ったまたは曖昧な入力を無視することは、ほとんどの場合、問題に対する誤った解決策です。
Good extensibility [EXT] can make it easier to respond to new use cases or changes in the environment in which the protocol is deployed.
良好な拡張性[ext]により、プロトコルが展開されている環境の新しいユースケースまたは変更に簡単に対応できます。
The ability to extend a protocol is sometimes mistaken for an application of the robustness principle. After all, if one party wants to start using a new feature before another party is prepared to receive it, it might be assumed that the receiving party is being tolerant of new types of input.
プロトコルを拡張する機能は、堅牢性の原理の適用と間違われることがあります。結局のところ、ある当事者が別の当事者がそれを受け取る準備をする前に新機能の使用を開始したい場合、受信当事者は新しいタイプの入力に寛容であると想定されるかもしれません。
A well-designed extensibility mechanism establishes clear rules for the handling of elements like new messages or parameters. This depends on specifying the handling of malformed or illegal inputs so that implementations behave consistently in all cases that might affect interoperation. New messages or parameters thereby become entirely expected. If extension mechanisms and error handling are designed and implemented correctly, new protocol features can be deployed with confidence in the understanding of the effect they have on existing implementations.
適切に設計された拡張性メカニズムは、新しいメッセージやパラメーターなどの要素の処理に関する明確なルールを確立します。これは、相互操作に影響を与える可能性のあるすべての場合に実装が一貫して動作するように、奇形または違法な入力の処理を指定することに依存します。これにより、新しいメッセージまたはパラメーターが完全に期待されます。拡張メカニズムとエラー処理が正しく設計および実装されている場合、既存の実装に対する効果の理解に自信を持って新しいプロトコル機能を展開できます。
In contrast, relying on implementations to consistently handle unexpected input is not a good strategy for extensibility. Using undocumented or accidental features of a protocol as the basis of an extensibility mechanism can be extremely difficult, as is demonstrated by the case study in Appendix A.3 of [EXT]. It is better and easier to design a protocol for extensibility initially than to retrofit the capability (see also [EDNS0]).
対照的に、予期しない入力を一貫して処理するための実装に依存することは、拡張性の良い戦略ではありません。拡張性メカニズムの基礎としてプロトコルの文書化されていないまたは偶発的な特徴を使用することは、[ext]の付録3のケーススタディで示されているように、非常に困難です。機能を改装するよりも、最初は拡張性のためにプロトコルを設計する方が良いとなります（[EDNS0も参照））。
A protocol could be designed to permit a narrow set of valid inputs, or it could be designed to treat a wide range of inputs as valid.
プロトコルは、有効な入力の狭いセットを許可するように設計することも、幅広い入力を有効なものとして扱うように設計することもできます。
A more flexible protocol is more complex to specify and implement; variations, especially those that are not commonly used, can create potential interoperability hazards. In the absence of strong reasons to be flexible, a simpler protocol is more likely to successfully interoperate.
より柔軟なプロトコルは、指定と実装をより複雑です。バリエーション、特に一般的に使用されていない変動は、潜在的な相互運用性の危険を引き起こす可能性があります。柔軟性がある強い理由がない場合、よりシンプルなプロトコルは相互操作に成功する可能性が高くなります。
Where input is provided by users, allowing flexibility might serve to make the protocol more accessible, especially for non-expert users. HTML authoring [HTML] is an example of this sort of design.
ユーザーが入力が提供される場合、特に非専門家ユーザーにとって、柔軟性を可能にするプロトコルをよりアクセスしやすくするのに役立つ可能性があります。HTML Authering [HTML]は、この種のデザインの例です。
In protocols where there are many participants that might generate messages based on data from other participants, some flexibility might contribute to resilience of the system. A routing protocol is a good example of where this might be necessary.
他の参加者からのデータに基づいてメッセージを生成する可能性のある多くの参加者がいるプロトコルでは、ある程度の柔軟性がシステムの回復力に寄与する可能性があります。ルーティングプロトコルは、これが必要になる可能性のある良い例です。
In BGP [BGP], a peer generates UPDATE messages based on messages it receives from other peers. Peers can copy attributes without validation, potentially propagating invalid values. RFC 4271 [BGP] mandated a session reset for invalid UPDATE messages, a requirement that was not widely implemented. In many deployments, peers would treat a malformed UPDATE in less stringent ways, such as by treating the affected route as having been withdrawn. Ultimately, RFC 7606 [BGP-REH] documented this practice and provided precise rules, including mandatory actions for different error conditions.
BGP [BGP]では、ピアは他のピアから受信するメッセージに基づいて更新メッセージを生成します。ピアは、検証なしで属性をコピーし、無効な値を伝播する可能性があります。RFC 4271 [BGP]は、無効な更新メッセージのセッションリセットを義務付けました。これは、広く実装されていない要件です。多くの展開では、ピアは、影響を受けたルートを撤回したものとして扱うなど、あまり厳しくない方法で奇形の更新を扱います。最終的に、RFC 7606 [BGP-REG]はこのプラクティスを文書化し、異なるエラー条件に対する必須のアクションを含む正確なルールを提供しました。
A protocol can explicitly allow for a range of valid expressions of the same semantics, with precise definitions for error handling. This is distinct from a protocol that relies on the application of the robustness principle. With the former, interoperation depends on specifications that capture all relevant details, whereas interoperation in the latter depends more extensively on implementations making compatible decisions, as noted in Section 4.2.
プロトコルは、エラー処理のための正確な定義を使用して、同じセマンティクスの一連の有効な表現を明示的に可能にすることができます。これは、堅牢性の原理の適用に依存するプロトコルとは異なります。前者の場合、相互操作はすべての関連する詳細をキャプチャする仕様に依存しますが、後者の相互操作は、セクション4.2に記載されているように、互換性のある決定をより広く依存します。
The guidance in this document is intended for protocols that are deployed to the Internet. There are some situations in which this guidance might not apply to a protocol due to conditions on its implementation or deployment.
このドキュメントのガイダンスは、インターネットに展開されるプロトコルを対象としています。このガイダンスが、その実装または展開の条件により、プロトコルに適用されない場合があります。
In particular, this guidance depends on an ability to update and deploy implementations. Being able to rapidly update implementations that are deployed to the Internet helps manage security risks, but in reality, some software deployments have lifecycles that make software updates either rare or altogether impossible.
特に、このガイダンスは、実装を更新および展開する機能に依存します。インターネットに展開されている実装を迅速に更新できることは、セキュリティのリスクを管理するのに役立ちますが、実際には、ソフトウェアの展開には、ソフトウェアの更新をまれまたは完全に不可能にするライフサイクルがあります。
Where implementations are not updated, there is no opportunity to apply the practices that this document recommends. In particular, some practices -- such as those described in Section 5.1 -- only exist to support the development of protocol maintenance and evolution. Employing this guidance is therefore only applicable where there is the possibility of improving deployments through timely updates of their implementations.
実装が更新されない場合、このドキュメントが推奨するプラクティスを適用する機会はありません。特に、セクション5.1に記載されているようないくつかのプラクティスは、プロトコルの維持と進化の開発をサポートするためにのみ存在します。したがって、このガイダンスを採用することは、実装のタイムリーな更新を通じて展開を改善する可能性がある場合にのみ適用可能です。
Problems in other implementations can create an unavoidable need to temporarily tolerate unexpected inputs. However, this course of action carries risks.
他の実装の問題は、予期しない入力を一時的に許容するために避けられないニーズを作成する可能性があります。ただし、この一連の行動にはリスクがあります。
Tolerating unexpected input might be an expedient tool for systems in early phases of deployment, which was the case for the early Internet. Being lenient in this way defers the effort of dealing with interoperability problems and prioritizes progress. However, this deferral can amplify the ultimate cost of handling interoperability problems.
予期しない入力を許容することは、展開の初期段階でのシステムの便利なツールである可能性があります。これは、初期のインターネットの場合でした。この方法で寛大であることは、相互運用性の問題に対処する努力を守り、進捗を優先します。ただし、この延期は、相互運用性の問題を処理する最終的なコストを増幅する可能性があります。
Divergent implementations of a specification emerge over time. When variations occur in the interpretation or expression of semantic components, implementations cease to be perfectly interoperable.
仕様の多様な実装は、時間とともに現れます。セマンティックコンポーネントの解釈または表現でバリエーションが発生する場合、実装は完全に相互運用可能になります。
Implementation bugs are often identified as the cause of variation, though it is often a combination of factors. Using a protocol in ways that were not anticipated in the original design or ambiguities and errors in the specification are often contributing factors. Disagreements on the interpretation of specifications should be expected over the lifetime of a protocol.
実装バグは、多くの場合、変動の原因として識別されますが、多くの場合、要因の組み合わせです。オリジナルの設計や仕様のあいまいさとエラーで予想されていない方法でプロトコルを使用することは、多くの場合、要因となります。仕様の解釈に関する意見の相違は、プロトコルの寿命にわたって予想されるべきです。
Even with the best intentions to maintain protocol correctness, the pressure to interoperate can be significant. No implementation can hope to avoid having to trade correctness for interoperability indefinitely.
プロトコルの正確性を維持するための最善の意図があっても、相互運用する圧力は重要である可能性があります。実装は、相互運用性の正しさを無期限に取引することを避けることを望むことはできません。
An implementation that reacts to variations in the manner recommended in the robustness principle enters a pathological feedback cycle. Over time:
堅牢性の原理で推奨される方法の変動に反応する実装は、病理学的フィードバックサイクルに入ります。時間とともに：
* Implementations progressively add logic to constrain how data is transmitted or to permit variations in what is received.
* 実装は徐々にロジックを追加して、データの送信方法を制約するか、受信したもののバリエーションを許可します。
* Errors in implementations or confusion about semantics are permitted or ignored.
* 実装のエラーまたはセマンティクスに関する混乱は許可または無視されます。
* These errors can become entrenched, forcing other implementations to be tolerant of those errors.
* これらのエラーは定着する可能性があり、他の実装がこれらのエラーに耐性を強制することができます。
A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of tolerating the unexpected and a product of a natural reluctance to avoid fatal error conditions. Ensuring interoperability in this environment is often referred to as aiming to be "bug-for-bug compatible".
欠陥は、事実上の基準として定着することがあります。異常な動作を再現するには、プロトコルの実装が必要であるか、相互運用できません。これは、致命的なエラーの状態を避けるために予期しないことを容認し、自然な不本意の産物を容認した結果です。この環境での相互運用性を確保することは、多くの場合、「バグ対互換性」を目的とするものと呼ばれます。
For example, in TLS [TLS], extensions use a tag-length-value format and can be added to messages in any order. However, some server implementations terminated connections if they encountered a TLS ClientHello message that ends with an empty extension. To maintain interoperability with these servers, which were widely deployed, client implementations were required to be aware of this bug and ensure that a ClientHello message ends in a non-empty extension.
たとえば、TLS [TLS]では、拡張機能はタグ長価値形式を使用し、任意の順序でメッセージに追加できます。ただし、一部のサーバーの実装は、空の拡張機能で終了するTLS ClientHelloメッセージに遭遇した場合、接続を終了しました。広く展開されたこれらのサーバーとの相互運用性を維持するために、クライアントの実装はこのバグを認識し、クライアントヘロメッセージが空でない拡張機能で終了することを確認する必要がありました。
Overapplication of the robustness principle therefore encourages a chain reaction that can create interoperability problems over time. In particular, tolerating unexpected behavior is particularly deleterious for early implementations of new protocols, as quirks in early implementations can affect all subsequent deployments.
したがって、堅牢性の過剰適用は、時間の経過とともに相互運用性の問題を引き起こす可能性のある連鎖反応を促進します。特に、予期しない動作への容認は、新しいプロトコルの早期実装にとって特に有害です。これは、早期実装の癖がその後のすべての展開に影響を与える可能性があるためです。
From observing widely deployed protocols, it appears there are two stable points on the spectrum between being strict versus permissive in the presence of protocol errors:
広く展開されているプロトコルを観察することから、プロトコルエラーの存在下では厳密であり対象であることとの間に、スペクトルに2つの安定したポイントがあるように見えます。
* If implementations predominantly enforce strict compliance with specifications, newer implementations will experience failures if they do not comply with protocol requirements. Newer implementations need to fix compliance issues in order to be successfully deployed. This ensures that most deployments are compliant over time.
* 実装が主に仕様の厳格なコンプライアンスを実施する場合、プロトコル要件に準拠していない場合、新しい実装は障害が発生します。新しい実装は、正常に展開するためにコンプライアンスの問題を修正する必要があります。これにより、ほとんどの展開が時間とともに準拠することが保証されます。
* Conversely, if non-compliance is tolerated by existing implementations, non-compliant implementations can be deployed successfully. Newer implementations then have a strong incentive to tolerate any existing non-compliance in order to be successfully deployed. This ensures that most deployments are tolerant of the same non-compliant behavior.
* 逆に、既存の実装によって非違反が許容される場合、非準拠の実装を正常に展開できます。新しい実装には、既存の非遵守を正常に展開するために容認する強力なインセンティブがあります。これにより、ほとんどの展開が同じ非準拠の動作に対して寛容になることが保証されます。
This happens because interoperability requirements for protocol implementations are set by other deployments. Specifications and test suites -- where they exist -- can guide the initial development of implementations. Ultimately, the need to interoperate with deployed implementations is a de facto conformance test suite that can supersede any formal protocol definition.
これは、プロトコル実装の相互運用性要件が他の展開によって設定されているために発生します。仕様とテストスイート（存在する場所）は、実装の初期開発を導くことができます。最終的に、展開された実装と相互運用する必要性は、正式なプロトコル定義に取って代わる可能性のある事実上の適合テストスイートです。
For widely used protocols, the massive scale of the Internet makes large-scale interoperability testing infeasible for all but a privileged few. The cost of building a new implementation using reverse engineering increases as the number of implementations and bugs increases. Worse, the set of tweaks necessary for wide interoperability can be difficult to discover. In the worst case, a new implementer might have to choose between deployments that have diverged so far as to no longer be interoperable.
広く使用されているプロトコルの場合、インターネットの大規模なスケールにより、特権的な少数を除くすべての人が大規模な相互運用性テストを実行できます。リバースエンジニアリングを使用して新しい実装を構築するコストは、実装とバグの数が増えると増加します。さらに悪いことに、幅広い相互運用性に必要な調整のセットを発見するのは難しい場合があります。最悪の場合、新しい実装者は、もはや相互運用できなくなった展開を選択する必要がある場合があります。
Consequently, new implementations might be forced into niche uses, where the problems arising from interoperability issues can be more closely managed. However, restricting new implementations into limited deployments risks causing forks in the protocol. If implementations do not interoperate, little prevents those implementations from diverging more over time.
その結果、新しい実装がニッチな使用に強制される可能性があります。この場合、相互運用性の問題から生じる問題をより緊密に管理できます。ただし、新しい実装を限られた展開に制限すると、プロトコルのフォークが発生するリスクがあります。実装が相互運用しない場合、それらの実装が時間とともにより分岐することをほとんど防ぐことはほとんどありません。
This has a negative impact on the ecosystem of a protocol. New implementations are key to the continued viability of a protocol. New protocol implementations are also more likely to be developed for new and diverse use cases and are often the origin of features and capabilities that can be of benefit to existing users.
これは、プロトコルのエコシステムに悪影響を及ぼします。新しい実装は、プロトコルの継続的な実行可能性の鍵です。また、新しいプロトコルの実装は、新しく多様なユースケースのために開発される可能性が高く、多くの場合、既存のユーザーにとって有益な機能と機能の起源です。
The need to work around interoperability problems also reduces the ability of established implementations to change. An accumulation of mitigations for interoperability issues makes implementations more difficult to maintain and can constrain extensibility (see also the IAB document "Long-Term Viability of Protocol Extension Mechanisms" [RFC9170]).
相互運用性の問題を回避する必要性は、確立された実装の変更能力も低下させます。相互運用性の問題に対する緩和の蓄積により、実装は維持がより困難になり、拡張性を制約することができます（IABドキュメント「プロトコル拡張メカニズムの長期実行可能性」[RFC9170]も参照）。
Sometimes, what appear to be interoperability problems are symptomatic of issues in protocol design. A community that is willing to make changes to the protocol, by revising or extending specifications and then deploying those changes, makes the protocol better. Tolerating unexpected input instead conceals problems, making it harder, if not impossible, to fix them later.
時々、相互運用性の問題と思われるのは、プロトコル設計の問題の症状です。仕様を修正または拡張し、それらの変更を展開することにより、プロトコルを喜んで変更することをいとわないコミュニティは、プロトコルを改善します。予期しない入力を容認する代わりに、問題を隠し、後で修正することは不可能ではないにしても難しくなります。
The robustness principle can be highly effective in safeguarding against flaws in the implementation of a protocol by peers. Especially when a specification remains unchanged for an extended period of time, the incentive to be tolerant of errors accumulates over time. Indeed, when faced with divergent interpretations of an immutable specification, the only way for an implementation to remain interoperable is to be tolerant of differences in interpretation and implementation errors. However, when official specifications fail to be updated, then deployed implementations -- including their quirks -- often become a substitute standard.
堅牢性の原則は、ピアによるプロトコルの実装における欠陥に対する保護に非常に効果的です。特に、仕様が長期間変化しない場合、エラーに耐えるインセンティブは時間とともに蓄積されます。確かに、不変の仕様の多様な解釈に直面した場合、実装が相互運用可能なままでいる唯一の方法は、解釈と実装エラーの違いに寛容であることです。ただし、公式の仕様が更新されない場合、その後の実装を展開した実装は、多くの場合、代替基準になります。
Tolerating unexpected inputs from another implementation might seem logical, even necessary. However, that conclusion relies on an assumption that existing specifications and implementations cannot change. Applying the robustness principle in this way disproportionately values short-term gains over the negative effects on future implementations and the protocol as a whole.
別の実装からの予期しない入力を容認することは、論理的であり、必要でさえあるように思えるかもしれません。ただし、その結論は、既存の仕様と実装が変更できないという仮定に依存しています。このようにして堅牢性の原則を適用すると、将来の実装とプロトコル全体に対するマイナスの影響に対する短期的な利益を不釣り合いに評価します。
For a protocol to have sustained viability, it is necessary for both specifications and implementations to be responsive to changes, in addition to handling new and old problems that might arise over time. For example, when an implementer discovers a scenario where a specification defines some input as faulty but does not define how to handle that input, the implementer can provide significant value to the ecosystem by reporting the issue and helping to evolve the specification.
プロトコルが実行可能性を維持するには、時間の経過とともに発生する可能性のある新しい問題や古い問題の処理に加えて、仕様と実装の両方が変更に対応する必要があります。たとえば、実装者が仕様が何らかの入力を故障と定義するが、その入力を処理する方法を定義しないシナリオを発見すると、実装者は問題を報告し、仕様の進化を支援することにより、エコシステムに大きな価値を提供できます。
When a discrepancy is found between a specification and its implementation, a maintenance discussion inside the standards process allows reaching consensus on how best to evolve the specification. Subsequently, updating implementations to match evolved specifications ensures that implementations are consistently interoperable and removes needless barriers for new implementations. Maintenance also enables continued improvement of the protocol. New use cases are an indicator that the protocol could be successful [RFC5218].
仕様とその実装の間に矛盾が見つかった場合、標準プロセス内でのメンテナンスディスカッションにより、仕様をどのように進化させるかについてのコンセンサスに到達することができます。その後、進化した仕様に合わせて実装を更新することにより、実装が一貫して相互運用可能であり、新しい実装の不必要な障壁を削除することが保証されます。メンテナンスにより、プロトコルの継続的な改善が可能になります。新しいユースケースは、プロトコルが成功する可能性があることを示す指標です[RFC5218]。
Protocol designers are strongly encouraged to continue to maintain and evolve protocol specifications beyond their initial inception and definition. This might require the development of revised specifications, extensions, or other supporting material that evolves in concert with implementations. Involvement of those who implement and deploy the protocol is a critical part of this process, as they provide input on their experience with how the protocol is used.
プロトコルデザイナーは、プロトコルの仕様を初期の開始と定義を超えて維持および進化させ続けることを強くお勧めします。これには、改訂された仕様、拡張、または実装に合わせて進化するその他のサポート資料の開発が必要になる場合があります。プロトコルを実装および展開する人々の関与は、プロトコルの使用方法に関する経験に関する入力を提供するため、このプロセスの重要な部分です。
Most interoperability problems do not require revision of protocols or protocol specifications, as software defects can happen even when the specification is unambiguous. For instance, the most effective means of dealing with a defective implementation in a peer could be to contact the developer responsible. It is far more efficient in the long term to fix one isolated bug than it is to deal with the consequences of workarounds.
ほとんどの相互運用性の問題は、仕様が明確であってもソフトウェアの欠陥が発生する可能性があるため、プロトコルまたはプロトコル仕様の改訂を必要としません。たとえば、ピアでの欠陥のある実装に対処する最も効果的な手段は、責任者に連絡することです。回避策の結果に対処するよりも、1つの孤立したバグを修正することは、長期的にははるかに効率的です。
Early implementations of protocols have a stronger obligation to closely follow specifications, as their behavior will affect all subsequent implementations. In addition to specifications, later implementations will be guided by what existing deployments accept. Tolerance of errors in early deployments is most likely to result in problems. Protocol specifications might need more frequent revision during early deployments to capture feedback from early rounds of deployment.
プロトコルの早期実装には、その動作がその後のすべての実装に影響を与えるため、仕様に密接に従うという強い義務があります。仕様に加えて、後の実装は、既存の展開が受け入れるものによって導かれます。早期展開におけるエラーの耐性は、問題を引き起こす可能性が最も高くなります。プロトコル仕様は、早期展開中に早期展開中にフィードバックをキャプチャするために、より頻繁に改訂する必要がある場合があります。
Neglect can quickly produce the negative consequences this document describes. Restoring the protocol to a state where it can be maintained involves first discovering the properties of the protocol as it is deployed rather than the protocol as it was originally documented. This can be difficult and time-consuming, particularly if the protocol has a diverse set of implementations. Such a process was undertaken for HTTP [HTTP] after a period of minimal maintenance. Restoring HTTP specifications to relevance took significant effort.
ネグレクトは、このドキュメントが説明する否定的な結果をすぐに生み出すことができます。プロトコルを維持できる状態に復元するには、プロトコルが最初に文書化されたように、プロトコルが展開するプロトコルのプロパティを最初に発見することが含まれます。特にプロトコルに多様な実装セットがある場合、これは困難で時間がかかります。このようなプロセスは、最小限のメンテナンスの後にHTTP [HTTP]に対して行われました。HTTP仕様を関連性に復元するには、多大な努力が必要でした。
Maintenance is most effective if it is responsive, which is greatly affected by how rapidly protocol changes can be deployed. For protocol deployments that operate on longer time scales, temporary workarounds following the spirit of the robustness principle might be necessary. For this, improvements in software update mechanisms ensure that the cost of reacting to changes is much lower than it was in the past. Alternatively, if specifications can be updated more readily than deployments, details of the workaround can be documented, including the desired form of the protocols once the need for workarounds no longer exists and plans for removing the workaround.
メンテナンスは、応答性が高い場合に最も効果的です。これは、プロトコルの変更を迅速に展開できることによって大きな影響を受けます。より長い時間スケールで動作するプロトコルの展開には、堅牢性のスピリットに従って一時的な回避策が必要になる場合があります。このため、ソフトウェア更新メカニズムの改善により、変化に反応するコストが過去よりもはるかに低くなることが保証されます。あるいは、仕様を展開よりも容易に更新できる場合、回避策の必要性がなくなった後のプロトコルの望ましい形式や、回避策を削除する計画を含め、回避策の詳細を文書化できます。
A well-specified protocol includes rules for consistent handling of aberrant conditions. This increases the chances that implementations will have consistent and interoperable handling of unusual conditions.
適切に指定されたプロトコルには、異常な条件の一貫した処理に関するルールが含まれています。これにより、実装が異常な条件の一貫した相互運用可能な取り扱いを行う可能性が高まります。
Choosing to generate fatal errors for unspecified conditions instead of attempting error recovery can ensure that faults receive attention. This intolerance can be harnessed to reduce occurrences of aberrant implementations.
エラー回復を試みる代わりに、不特定の条件の致命的なエラーを生成することを選択すると、障害が注意を払うことを保証することができます。この不耐性は、異常な実装の発生を減らすために活用できます。
Intolerance toward violations of specification improves feedback for new implementations in particular. When a new implementation encounters a peer that is intolerant of an error, it receives strong feedback that allows the problem to be discovered quickly.
仕様の違反に対する不寛容は、特に新しい実装のフィードバックを改善します。新しい実装がエラーに耐えられないピアに遭遇すると、問題を迅速に発見できる強力なフィードバックを受け取ります。
To be effective, intolerant implementations need to be sufficiently widely deployed so that they are encountered by new implementations with high probability. This could depend on multiple implementations deploying strict checks.
効果的であるためには、不寛容な実装を十分に広く展開する必要があり、高い確率で新しい実装で遭遇するようにする必要があります。これは、厳格なチェックを展開する複数の実装に依存する可能性があります。
Interoperability problems also need to be made known to those in a position to address them. In particular, systems with human operators, such as user-facing clients, are ideally suited to surfacing errors. Other systems might need to use less direct means of making errors known.
相互運用性の問題は、それらに対処する立場にある人にも知られる必要があります。特に、ユーザー向けのクライアントなど、人間のオペレーターを持つシステムは、サーフェシングエラーに理想的に適しています。他のシステムは、エラーを既知にするためのより少ない直接的な手段を使用する必要がある場合があります。
This does not mean that intolerance of errors in early deployments of protocols has the effect of preventing interoperability. On the contrary, when existing implementations follow clearly specified error handling, new implementations or features can be introduced more readily, as the effect on existing implementations can be easily predicted; see also Section 2.2.
これは、プロトコルの早期展開におけるエラーの不耐性が相互運用性を防ぐ効果があることを意味するものではありません。それどころか、既存の実装が明確に指定されたエラー処理に従う場合、既存の実装への影響を簡単に予測できるため、新しい実装または機能をより簡単に導入できます。セクション2.2も参照してください。
Any intolerance also needs to be strongly supported by specifications; otherwise, they encourage fracturing of the protocol community or proliferation of workarounds. See Section 5.2.
不寛容は、仕様によって強くサポートされる必要があります。それ以外の場合、プロトコルコミュニティの破壊または回避策の拡散を奨励しています。セクション5.2を参照してください。
Intolerance can be used to motivate compliance with any protocol requirement. For instance, the INADEQUATE_SECURITY error code and associated requirements in HTTP/2 [HTTP/2] resulted in improvements in the security of the deployed base.
不耐性を使用して、プロトコル要件のコンプライアンスを動機付けることができます。たとえば、HTTP/2 [HTTP/2]のInadequate_Securityエラーコードと関連する要件により、展開されたベースのセキュリティが改善されました。
A notification for a fatal error is best sent as explicit error messages to the entity that made the error. Error messages benefit from being able to carry arbitrary information that might help the implementer of the sender of the faulty input understand and fix the issue in their software. QUIC error frames [QUIC] are an example of a fatal error mechanism that helped implementers improve software quality throughout the protocol lifecycle. Similarly, the use of Extended DNS Errors [EDE] has been effective in providing better descriptions of DNS resolution errors to clients.
致命的なエラーの通知は、エラーを作成したエンティティに明示的なエラーメッセージとして送信するのが最適です。エラーメッセージは、故障した入力の送信者の実装者がソフトウェアの問題を理解して修正するのに役立つ任意の情報を携帯できることから利益を得ることができます。QUICエラーフレーム[QUIC]は、プロトコルライフサイクル全体でソフトウェアの品質を向上させるのに役立つ致命的なエラーメカニズムの例です。同様に、拡張されたDNSエラー[EDE]の使用は、クライアントにDNS解像度エラーのより良い説明を提供するのに効果的です。
Stateless protocol endpoints might generate denial-of-service attacks if they send an error message in response to every message that is received from an unauthenticated sender. These implementations might need to silently discard these messages.
ステートレスプロトコルのエンドポイントは、認定されていない送信者から受信されたすべてのメッセージに応じてエラーメッセージを送信すると、サービス拒否攻撃を生成する可能性があります。これらの実装は、これらのメッセージを静かに破棄する必要がある場合があります。
Any protocol participant that is affected by changes arising from maintenance might be excluded if they are unwilling or unable to implement or deploy changes that are made to the protocol.
メンテナンスから生じる変更の影響を受けるプロトコル参加者は、プロトコルに行われた変更を実装または展開したくない、または展開できない場合、除外される場合があります。
Deliberate exclusion of problematic implementations is an important tool that can ensure that the interoperability of a protocol remains viable. While backward-compatible changes are always preferable to incompatible ones, it is not always possible to produce a design that protects the ability of all current and future protocol participants to interoperate.
問題のある実装の意図的な除外は、プロトコルの相互運用性が実行可能であることを保証できる重要なツールです。互換性のない変化よりも、後方互換性のある変更は常に望ましいものですが、現在および将来のすべてのプロトコル参加者が相互運用する能力を保護する設計を作成することは常に可能ではありません。
Accidentally excluding unexpected participants is not usually a good outcome. When developing and deploying changes, it is best to first understand the extent to which the change affects existing deployments. This ensures that any exclusion that occurs is intentional.
予期しない参加者を誤って除外することは、通常、良い結果ではありません。変更を開発および展開するとき、最初に変更が既存の展開に影響する程度を理解することが最善です。これにより、発生する除外が意図的であることが保証されます。
In some cases, existing deployments might need to change in order to avoid being excluded. Though it might be preferable to avoid forcing deployments to change, this might be considered necessary. To avoid unnecessarily excluding deployments that might take time to change, developing a migration plan can be prudent.
場合によっては、除外されないように既存の展開が変更する必要がある場合があります。展開を強制しないようにすることは望ましいかもしれませんが、これは必要と見なされるかもしれません。変更に時間がかかる可能性のある展開を不必要に除外することを避けるために、移行計画の開発は賢明です。
Exclusion is a direct goal when choosing to be intolerant of errors (see Section 5.1). Exclusionary actions are employed with the deliberate intent of protecting future interoperability.
除外は、エラーに不寛容であることを選択する場合の直接的な目標です（セクション5.1を参照）。除外行動は、将来の相互運用性を保護する意図的な意図で採用されます。
Excluding implementations or deployments can lead to a fracturing of the protocol system that could be more harmful than any divergence that might arise from tolerating the unexpected. The IAB document "Uncoordinated Protocol Development Considered Harmful" [RFC5704] describes how conflict or competition in the maintenance of protocols can lead to similar problems.
実装または展開を除くと、プロトコルシステムの破壊につながる可能性があります。これは、予期しないことを許容することから生じる可能性のある他の発散よりも有害である可能性があります。IABドキュメント「有害と見なされる非調整プロトコル開発」[RFC5704]は、プロトコルの維持における競合または競争が同様の問題につながる方法を説明しています。
Careless implementations, lax interpretations of specifications, and uncoordinated extrapolation of requirements to cover gaps in specification can result in security problems. Hiding the consequences of protocol variations encourages the hiding of issues, which can conceal bugs and make them difficult to discover.
不注意な実装、仕様の緩い解釈、および仕様のギャップをカバーするための要件の非協調的な外挿は、セキュリティの問題を引き起こす可能性があります。プロトコルのバリエーションの結果を隠すことは、問題の隠れを促進し、バグを隠して発見するのが難しくなる可能性があります。
The consequences of the problems described in this document are especially acute for any protocol where security depends on agreement about semantics of protocol elements. For instance, weak primitives [MD5] and obsolete mechanisms [SSL3] are good examples of the use of unsafe security practices where forcing exclusion (Section 5.2) can be desirable.
このドキュメントで説明されている問題の結果は、セキュリティがプロトコル要素のセマンティクスに関する一致に依存するプロトコルにとって特に深刻です。たとえば、弱いプリミティブ[MD5]および時代遅れのメカニズム[SSL3]は、強制除外（セクション5.2）が望ましい安全でないセキュリティ慣行の使用の良い例です。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
[BGP] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
<https://www.rfc-editor.org/info/rfc4271>.
[BGP-REH] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
<https://www.rfc-editor.org/info/rfc7606>.
[EDE] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D.
Lawrence, "Extended DNS Errors", RFC 8914,
DOI 10.17487/RFC8914, October 2020,
<https://www.rfc-editor.org/info/rfc8914>.
[EDNS0] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
for DNS (EDNS(0))", STD 75, RFC 6891,
DOI 10.17487/RFC6891, April 2013,
<https://www.rfc-editor.org/info/rfc6891>.
[EXT] Carpenter, B., Aboba, B., Ed., and S. Cheshire, "Design
Considerations for Protocol Extensions", RFC 6709,
DOI 10.17487/RFC6709, September 2012,
<https://www.rfc-editor.org/info/rfc6709>.
[HTML] WHATWG, "HTML - Living Standard",
<https://html.spec.whatwg.org/>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[HTTP/2] Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
DOI 10.17487/RFC9113, June 2022,
<https://www.rfc-editor.org/info/rfc9113>.
[MD5] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011,
<https://www.rfc-editor.org/info/rfc6151>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760,
DOI 10.17487/RFC0760, January 1980,
<https://www.rfc-editor.org/info/rfc760>.
[RFC1958] Carpenter, B., Ed., "Architectural Principles of the
Internet", RFC 1958, DOI 10.17487/RFC1958, June 1996,
<https://www.rfc-editor.org/info/rfc1958>.
[RFC3117] Rose, M., "On the Design of Application Protocols",
RFC 3117, DOI 10.17487/RFC3117, November 2001,
<https://www.rfc-editor.org/info/rfc3117>.
[RFC5218] Thaler, D. and B. Aboba, "What Makes for a Successful
Protocol?", RFC 5218, DOI 10.17487/RFC5218, July 2008,
<https://www.rfc-editor.org/info/rfc5218>.
[RFC5704] Bryant, S., Ed., Morrow, M., Ed., and IAB, "Uncoordinated
Protocol Development Considered Harmful", RFC 5704,
DOI 10.17487/RFC5704, November 2009,
<https://www.rfc-editor.org/info/rfc5704>.
[RFC9170] Thomson, M. and T. Pauly, "Long-Term Viability of Protocol
Extension Mechanisms", RFC 9170, DOI 10.17487/RFC9170,
December 2021, <https://www.rfc-editor.org/info/rfc9170>.
[SSL3] Barnes, R., Thomson, M., Pironti, A., and A. Langley,
"Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
DOI 10.17487/RFC7568, June 2015,
<https://www.rfc-editor.org/info/rfc7568>.
[TLS] 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>.
Internet Architecture Board members at the time this document was approved for publication were:
インターネットアーキテクチャ委員会メンバーこの文書が公開されたときに承認された時点は次のとおりです。
Jari Arkko
ジャリ・アークコ
Deborah Brungard
デボラ・ブランガード
Lars Eggert
ラース・エガート
Wes Hardaker
ウェス・ハーダーカー
Cullen Jennings
カレン・ジェニングス
Mallory Knodel
マロリーノーデル
Mirja Kühlewind
MirjaKühlewind
Zhenbin Li
Zhenbin Li
Tommy Pauly
トミーポーリー
David Schinazi
デビッド・シナジ
Russ White
ラス・ホワイト
Qin Wu
Qin Wu
Jiankang Yao
Jiankang Yao
The document had broad but not unanimous approval within the IAB, reflecting that while the guidance is valid, concerns were expressed in the IETF community about how broadly it applies in all situations.
このドキュメントは、IAB内で広範な全会一致の承認を得ていましたが、ガイダンスは有効ですが、IETFコミュニティでは、すべての状況でどの程度広く適用されるかについて懸念が表明されています。
Constructive feedback on this document has been provided by a surprising number of people including, but not limited to, the following: Bernard Aboba, Brian Carpenter, Stuart Cheshire, Joel Halpern, Wes Hardaker, Russ Housley, Cullen Jennings, Mallory Knodel, Mirja Kühlewind, Mark Nottingham, Eric Rescorla, Henning Schulzrinne, Job Snijders, Robert Sparks, Dave Thaler, Brian Trammell, and Anne van Kesteren. Some of the properties of protocols described in Section 4.1 were observed by Marshall Rose in Section 4.5 of [RFC3117].
この文書に関する建設的なフィードバックは、以下を含むがこれらに限定されない驚くべき数の人々によって提供されています。、マーク・ノッティンガム、エリック・レスコルラ、ヘニング・シュルツリン、ジョブ・スナイダース、ロバート・スパークス、デイブ・タラー、ブライアン・トラメル、アン・ヴァン・ケスターン。セクション4.1で説明したプロトコルの特性の一部は、[RFC3117]のセクション4.5でマーシャルローズによって観察されました。
Martin Thomson
Email: mt@lowentropy.net
David Schinazi
Email: dschinazi.ietf@gmail.com