[要約] RFC 2360は、インターネット標準の作成者向けのガイドラインであり、標準の作成方法と文書化の手法について説明しています。このRFCの目的は、標準の品質と一貫性を向上させ、インターネットの発展に貢献することです。
Network Working Group G. Scott, Editor
Request for Comments: 2360 Defense Information Systems Agency
BCP: 22 June 1998
Category: Best Current Practice
Guide for Internet Standards Writers
インターネット標準作家のためのガイド
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティのためのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
Abstract
概要
This document is a guide for Internet standard writers. It defines those characteristics that make standards coherent, unambiguous, and easy to interpret. In addition, it singles out usage believed to have led to unclear specifications, resulting in non-interoperable interpretations in the past. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors".
このドキュメントは、インターネット標準ライター向けのガイドです。これは、標準を一貫性があり、明確で、解釈しやすくする特性を定義します。さらに、仕様が不明確になり、過去に相互運用できない解釈が発生したと考えられる使用方法を特定します。これらのガイドラインは、RFC 2223「RFC Authorsへの指示」で使用されます。
Table of Contents
目次
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 2
2 General Guidelines . . . . . . . . . . . . . . . . . . . . . 2
2.1 Discussion of Security . . . . . . . . . . . . . . . . . . . 3
2.2 Protocol Description . . . . . . . . . . . . . . . . . . . 4
2.3 Target Audience . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Level of Detail . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Change Logs . . . . . . . . . . . . . . . . . . . . . . . . 6
2.6 Protocol Versions . . . . . . . . . . . . . . . . . . . . . 6
2.7 Decision History . . . . . . . . . . . . . . . . . . . . . 6
2.8 Response to Out of Specification Behavior . . . . . . . . . 6
2.9 The Liberal/Conservative Rule . . . . . . . . . . . . . . . 7
2.10 Handling of Protocol Options . . . . . . . . . . . . . . . 8
2.11 Indicating Requirement Levels . . . . . . . . . . . . . . . 9
2.12 Notational Conventions . . . . . . . . . . . . . . . . . . . 9
2.13 IANA Considerations . . . . . . . . . . . . . . . . . . . 10
2.14 Network Management Considerations . . . . . . . . . . . . 10
2.15 Scalability Considerations . . . . . . . . . . . . . . . . 10
2.16 Network Stability . . . . . . . . . . . . . . . . . . . . 11
2.17 Internationalization . . . . . . . . . . . . . . . . . . . 11
2.18 Glossary . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Specific Guidelines . . . . . . . . . . . . . . . . . . . 12
3.1 Packet Diagrams . . . . . . . . . . . . . . . . . . . . . 12
3.2 Summary Tables . . . . . . . . . . . . . . . . . . . . . 13
3.3 State Machine Descriptions . . . . . . . . . . . . . . . . 13
4 Document Checklist . . . . . . . . . . . . . . . . . . . . 15
5 Security Considerations . . . . . . . . . . . . . . . . . 16
6 References . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18
8 Editor's Address . . . . . . . . . . . . . . . . . . . . . 18
9 Appendix . . . . . . . . . . . . . . . . . . . . . . . . . 19
10 Full Copyright Statement . . . . . . . . . . . . . . . . . 20
1 Introduction
1はじめに
This document is a guide for Internet standard writers. It offers guidelines on how to write a standards-track document with clarity, precision, and completeness. These guidelines are based on both prior successful and unsuccessful IETF specification experiences. These guidelines are to be used with RFC 2223, "Instructions to RFC Authors", or its update. Note that some guidelines may not apply in certain situations.
このドキュメントは、インターネット標準ライター向けのガイドです。明確さ、正確さ、完全性を備えた標準化過程のドキュメントを作成する方法に関するガイドラインを提供します。これらのガイドラインは、成功したIETF仕様と失敗したIETF仕様の両方の経験に基づいています。これらのガイドラインは、RFC 2223「RFC Authorsへの指示」またはその更新で使用されます。一部のガイドラインは特定の状況では適用されない場合があることに注意してください。
The goal is to increase the possibility that multiple implementations of a protocol will interoperate. Writing specifications to these guidelines will not guarantee interoperability. However, a recognized barrier to the creation of interoperable protocol implementations is unclear specifications.
目標は、プロトコルの複数の実装が相互運用する可能性を高めることです。これらのガイドラインに仕様を書き込んでも、相互運用性は保証されません。ただし、相互運用可能なプロトコル実装の作成に対する認識された障壁は、不明確な仕様です。
Many will benefit from having well-written protocol specifications. Implementers will have a better chance to conform to the protocol specification. Protocol testers can use the specification to derive unambiguous testable statements. Purchasers and users of the protocol will have a better understanding of its capabilities.
多くの人は、よく書かれたプロトコル仕様を持つことから利益を得ます。実装者は、プロトコル仕様に準拠する可能性が高くなります。プロトコルテスターは、仕様を使用して、明確なテスト可能なステートメントを導出できます。プロトコルの購入者とユーザーは、その機能をよりよく理解できます。
For further information on the process for standardizing protocols and procedures please refer to BCP 9/RFC 2026, "The Internet Standards Process -- Revision 3". In addition, some considerations for protocol design are given in RFC 1958, "Architectural Principles of the Internet".
プロトコルと手順を標準化するプロセスの詳細については、BCP 9 / RFC 2026、「インターネット標準プロセス-リビジョン3」を参照してください。さらに、プロトコル設計に関するいくつかの考慮事項は、RFC 1958「Architectural Principles of the Internet」に記載されています。
2 General Guidelines
2一般的なガイドライン
It is important that multiple readers and implementers of a standard have the same understanding of a document. To this end, information should be orderly and detailed. The following are general guidelines intended to help in the production of such a document. The IESG may require that all or some of the following sections appear in a standards track document.
規格の複数の読者と実装者がドキュメントを同じように理解することが重要です。このためには、情報を整然と詳細に記述する必要があります。以下は、そのようなドキュメントの作成に役立つことを目的とした一般的なガイドラインです。 IESGでは、次のセクションのすべてまたは一部を標準化過程のドキュメントに記載する必要がある場合があります。
If the Internet is to achieve its full potential in commercial, governmental, and personal affairs, it must assure users that their information transfers are free from tampering or compromise. Well-written security sections in standards-track documents can help promote the confidence level required. Above all, new protocols and practices must not worsen overall Internet security.
インターネットが商業的、政府的、および個人的な問題でその潜在能力を最大限に発揮するためのものである場合、ユーザーの情報転送が改ざんまたは妥協のないことを保証する必要があります。標準化過程のドキュメントのセキュリティセクションが適切に記述されていれば、必要な信頼レベルを高めることができます。何よりも、新しいプロトコルとプラクティスがインターネットセキュリティ全体を悪化させてはなりません。
A significant threat to the Internet comes from those individuals who are motivated and capable of exploiting circumstances, events, or vulnerabilities of the system to cause harm. In addition, deliberate or inadvertent user behavior may expose the system to attack or exploitation. The harm could range from disrupting or denying network service, to damaging user systems. Additionally, information disclosure could provide the means to attack another system, or reveal patterns of behavior that could be used to harm an individual, organization, or network. This is a particular concern with standards that define a portion of the Management Information Base (MIB).
インターネットに対する重大な脅威は、モチベーションがあり、システムの状況、イベント、または脆弱性を悪用して害を及ぼすことができる個人からのものです。さらに、故意または不注意によるユーザーの行動により、システムが攻撃または悪用される可能性があります。被害は、ネットワークサービスの中断または拒否から、ユーザーシステムの損傷までさまざまです。さらに、情報開示は別のシステムを攻撃する手段を提供したり、個人、組織、またはネットワークに害を及ぼすために使用される可能性のある動作のパターンを明らかにしたりする可能性があります。これは、管理情報ベース（MIB）の一部を定義する標準に関する特定の懸念事項です。
Standards authors must accept that the protocol they specify will be subject to attack. They are responsible for determining what attacks are possible, and for detailing the nature of the attacks in the document. Otherwise, they must convincingly argue that attack is not realistic in a specific environment, and restrict the use of the protocol to that environment.
標準の作成者は、彼らが指定するプロトコルが攻撃を受ける可能性があることを受け入れる必要があります。彼らは、どのような攻撃が可能かを判断し、文書内の攻撃の性質を詳しく説明する責任があります。それ以外の場合、攻撃者は特定の環境では攻撃は現実的ではないと主張し、プロトコルの使用をその環境に制限する必要があります。
After the document has exhaustively identified the security risks the protocol is exposed to, the authors must formulate and detail a defense against those attacks. They must discuss the applicable countermeasures employed, or the risk the user is accepting by using the protocol. The countermeasures may be provided by a protocol mechanism or by reliance on external mechanisms. Authors should be knowledgeable of existing security mechanisms, and reuse them if practical. When a cryptographic algorithm is used, the protocol should be written to permit its substitution with another algorithm in the future. Finally, the authors should discuss implementation hints or guidelines, e.g., how to deal with untrustworthy data or peer systems.
ドキュメントがプロトコルがさらされているセキュリティリスクを徹底的に特定した後、作成者はそれらの攻撃に対する防御策を策定して詳細に説明する必要があります。採用されている適用可能な対策、またはユーザーがプロトコルを使用して受け入れるリスクについて話し合う必要があります。対策は、プロトコルメカニズムまたは外部メカニズムへの依存によって提供されます。作成者は、既存のセキュリティメカニズムに精通していて、実用的な場合はそれらを再利用する必要があります。暗号化アルゴリズムを使用する場合は、プロトコルを記述して、将来別のアルゴリズムに置き換えることができるようにする必要があります。最後に、作成者は実装のヒントやガイドライン、たとえば信頼できないデータやピアシステムを処理する方法について話し合う必要があります。
Security measures will have an impact within the environment that they are used. Perhaps users will now be constrained on what they can do in the Internet, or will experience degradation in the speed of service. The effects the security measures have on the protocol's use and performance should be discussed.
セキュリティ対策は、それらが使用される環境内で影響を及ぼします。おそらく、ユーザーはインターネットで何ができるかに制約を受けるか、サービスの速度が低下するでしょう。セキュリティ対策がプロトコルの使用とパフォーマンスに及ぼす影響を検討する必要があります。
The discussion of security can be concentrated in the Security Considerations section of the document, or throughout the document where it is relevant to particular parts of the specification. An advantage of the second approach is that it ensures security is an integral part of the protocol's development, rather than something that is a follow-on or secondary effort. If security is discussed throughout the document, the Security Considerations section must summarize and refer to the appropriate specification sections. This will insure that the protocol's security measures are emphasized to implementer and user both.
セキュリティの説明は、ドキュメントの「セキュリティに関する考慮事項」セクション、または仕様の特定の部分に関連するドキュメント全体に集中できます。 2番目のアプローチの利点は、後続または二次的な作業ではなく、セキュリティがプロトコルの開発に不可欠な部分であることを保証することです。ドキュメント全体でセキュリティについて説明する場合は、「セキュリティに関する考慮事項」セクションで適切な仕様セクションを要約して参照する必要があります。これにより、プロトコルのセキュリティ対策が実装者とユーザーの両方に強調されることが保証されます。
Within the Security Considerations section, a discussion of the path not taken may be appropriate. There may be several security mechanisms that were not selected for a variety of reasons: cost or difficulty of implementation, or ineffectiveness for a given network environment. By listing the mechanisms they did not use and the reasons, editors can demonstrate that the protocol's WG gave security the necessary thought. In addition, this gives the protocol's users the information they need to consider whether one of the non-selected mechanisms would be better suited to their particular requirements.
「セキュリティに関する考慮事項」セクションでは、実行されない方法について説明するのが適切な場合があります。さまざまな理由で選択されなかったいくつかのセキュリティメカニズムが存在する可能性があります。実装のコストや難しさ、特定のネットワーク環境の非効率性などです。編集者は、使用しなかったメカニズムとその理由をリストすることにより、プロトコルのWGがセキュリティに必要な考えを与えたことを実証できます。さらに、これにより、プロトコルのユーザーは、選択されていないメカニズムの1つが特定の要件により適しているかどうかを検討する必要がある情報をユーザーに提供します。
A document giving further guidance on security topics is in development. Authors should obtain a copy of the completed RFC to help them prepare the security portion of the standard.
セキュリティトピックに関する詳細なガイダンスを提供するドキュメントが開発中です。著者は、標準のセキュリティ部分を準備するのに役立つように、完成したRFCのコピーを入手する必要があります。
Finally, it is no longer acceptable that Security Considerations sections consist solely of statements to the effect that security was not considered in preparing the standard.
最後に、セキュリティに関する考慮事項のセクションが、標準の作成時にセキュリティが考慮されなかった旨の記述のみで構成されることはもはや認められません。
Some examples of Security Considerations sections are found in STD 33/RFC 1350, STD 51/RFC 1662, and STD 53/RFC 1939. RFC 2316, "Report of the IAB Security Architecture Workshop", provides additional information in this topic area.
「セキュリティに関する考慮事項」セクションのいくつかの例は、STD 33 / RFC 1350、STD 51 / RFC 1662、およびSTD 53 / RFC 1939にあります。RFC2316「Report of the IAB Security Architecture Workshop」では、このトピックエリアに追加情報を提供しています。
Standards track documents must include a description of the protocol. This description must address the protocol's purpose, intended functions, services it provides, and, the arena, circumstances, or any special considerations of the protocol's use.
標準追跡ドキュメントには、プロトコルの説明を含める必要があります。この説明は、プロトコルの目的、意図された機能、プロトコルが提供するサービス、およびアリーナ、状況、またはプロトコルの使用に関する特別な考慮事項に対処する必要があります。
The authors of a protocol specification will have a great deal of knowledge as to the reason for the protocol. However, the reader is more likely to have general networking knowledge and experience, rather than expertise in a particular protocol. An explanation of it's purpose and use will give the reader a reference point for understanding the protocol, and where it fits in the Internet. The STD 54/RFC 2328 was recommended to the STDGUIDE working group as providing a good example of this in its "Protocol Overview" section.
プロトコル仕様の作成者は、プロトコルの理由に関して多くの知識を持っています。ただし、読者は特定のプロトコルの専門知識ではなく、一般的なネットワークの知識と経験を持っている可能性が高くなります。その目的と使用法の説明は、プロトコルを理解するための参照ポイントと、それがインターネットに適合する場所を読者に提供します。 STD 54 / RFC 2328は、「プロトコルの概要」セクションでこの良い例を提供するため、STDGUIDEワーキンググループに推奨されました。
The protocol's general description must also provide information on the relationship between the different parties to the protocol. This can be done by showing typical packet sequences.
プロトコルの一般的な説明では、プロトコルのさまざまな関係者間の関係に関する情報も提供する必要があります。これは、典型的なパケットシーケンスを表示することで実行できます。
This also applies to the algorithms used by a protocol. A detailed description of the algorithms or citation of readily available references that give such a description is necessary.
これは、プロトコルで使用されるアルゴリズムにも適用されます。アルゴリズムの詳細な説明、またはそのような説明を提供するすぐに入手できる参考文献の引用が必要です。
RFCs have been written with many different purposes, ranging from the technical to the administrative. Those written as standards should clearly identify the intended audience, for example, designers, implementers, testers, help desk personnel, educators, end users, or others. If there are multiple audiences being addressed in the document, the section for each audience needs to be identified. The goal is to help the reader discover and focus on what they have turned to the document for, and avoid what they may find confusing, diverting, or extraneous.
RFCは、技術から管理まで、さまざまな目的で作成されています。標準として書かれたものは、意図する対象者、たとえば設計者、実装者、テスター、ヘルプデスク担当者、教育者、エンドユーザーなどを明確に識別する必要があります。ドキュメントで複数のオーディエンスが扱われている場合、各オーディエンスのセクションを識別する必要があります。目標は、読者がドキュメントの目的を見つけてそれに焦点を合わせ、混乱、転換、または無関係なものを回避できるようにすることです。
The author should consider what level of descriptive detail best conveys the protocol's intent. Concise text has several advantages. It makes the document easier to read. Such text reduces the chance for conflict between different portions of the specification. The reader can readily identify the required protocol mechanisms in the standard. In addition, it makes it easier to identify the requirements for protocol implementation. A disadvantage of concise descriptions is that a reader may not fully comprehend the reasoning behind the protocol, and thus make assumptions that will lead to implementation errors.
著者は、プロトコルの意図を最もよく表す詳細レベルを検討する必要があります。簡潔なテキストにはいくつかの利点があります。文書を読みやすくします。そのようなテキストは、仕様の異なる部分の間の競合の可能性を減らします。読者は、標準で必要なプロトコルメカニズムを簡単に識別できます。さらに、プロトコル実装の要件を特定しやすくなります。簡潔な説明の不利な点は、読者がプロトコルの背後にある理由を完全に理解していない可能性があり、したがって、実装エラーにつながると仮定することです。
Longer descriptions may be necessary to explain purpose, background, rationale, implementation experience, or to provide tutorial information. This helps the reader understand the protocol. Yet, several dangers exist with lengthy text. Finding the protocol requirements in the text is difficult or confusing. The same mechanism may have multiple descriptions, which leads to misinterpretation or conflict. Finally, it is more difficult to comprehend, a consideration as English is not the native language of the many worldwide readers of IETF standards.
目的、背景、理論的根拠、実装経験を説明するため、またはチュートリアル情報を提供するために、より長い説明が必要になる場合があります。これは、読者がプロトコルを理解するのに役立ちます。しかし、長いテキストにはいくつかの危険があります。テキストでプロトコル要件を見つけることは困難または混乱します。同じメカニズムに複数の説明が含まれている可能性があり、それが誤った解釈または競合につながります。最後に、英語はIETF標準の世界中の多くの読者の母国語ではないため、理解するのはより困難です。
One approach is to divide the standard into sections: one describing the protocol concisely, while another section consists of explanatory text. The STD 3/RFC 1122/RFC 1123 and STD 54/RFC 2328 provides examples of this method.
1つのアプローチは、標準をセクションに分割することです。1つはプロトコルを簡潔に説明し、もう1つは説明文で構成します。 STD 3 / RFC 1122 / RFC 1123およびSTD 54 / RFC 2328は、この方法の例を提供します。
As a document moves along the standards track, from Proposed to Draft or Draft to Full, or cycles in level, it will undergo changes due to better understanding of the protocol or implementation experience. To help implementers track the changes being made a log showing what has changed from the previous version of the specification is required (see Appendix).
ドキュメントが標準トラックに沿って移動するにつれて、[提案済み]から[ドラフト]または[ドラフト]から[フル]に、またはレベルが循環するにつれて、プロトコルまたは実装エクスペリエンスの理解が深まるため、ドキュメントは変更されます。実装者が行われた変更を追跡できるようにするには、以前のバージョンの仕様から何が変更されたかを示すログが必要です（付録を参照）。
Often the standard is specifying a new version of an existing protocol. In such a case, the authors should detail the differences between the previous version and the new version. This should include the rationale for the changes, for example, implementation experience, changes in technology, responding to user demand, etc.
多くの場合、標準は既存のプロトコルの新しいバージョンを指定しています。このような場合、作成者は以前のバージョンと新しいバージョンの違いを詳しく説明する必要があります。これには、変更の根拠、たとえば、実装の経験、テクノロジーの変更、ユーザーの要求への対応などが含まれます。
In standards development, reaching consensus requires making difficult choices. These choices are made through working group discussions or from implementation experience. By including the basis for a contentious decision, the author can prevent future revisiting of these disagreements when the original parties have moved on. In addition, the knowledge of the "why" is as useful to an implementer as the description of "how". For example, the alternative not taken may have been simpler to implement, so including the reasons behind the choice may prevent future implementers from taking nonstandard shortcuts.
標準の開発では、合意に達するには難しい選択をする必要があります。これらの選択は、ワーキンググループのディスカッションまたは実装の経験から行われます。論争の的となる決定の根拠を含めることにより、元の当事者が先に進んだときに、著者はこれらの不一致の将来の再訪を防ぐことができます。さらに、「なぜ」の知識は、「方法」の説明と同じくらい、実装者にとって有用です。たとえば、採用されなかった代替案は実装が簡単だった可能性があるため、選択の背後にある理由を含めると、将来の実装者が非標準のショートカットを取得できなくなる可能性があります。
A detail description of the actions taken in case of behavior that is deviant from or exceeds the specification is useful. This is an area where implementers often differ in opinion as to the appropriate response. By specifying a common response, the standard author can reduce the risk that different implementations will come in to conflict.
仕様から逸脱している、または仕様を超える動作が発生した場合に実行されるアクションの詳細な説明が役立ちます。これは、適切な対応に関して実装者の意見がしばしば異なる分野です。共通の応答を指定することにより、標準の作成者は、異なる実装が競合するリスクを軽減できます。
The standard should describe responses to behavior explicitly forbidden or out of the boundaries defined by the specification. Two possible approaches to such cases are discarding, or invoking error-handling mechanisms. If discarding is chosen, detailing the disposition may be necessary. For instance, treat dropped frames as if they were never received, or reset an existing connection or adjacency state.
この規格は、明示的に禁止されている、または仕様で定義されている範囲外の動作に対する応答を記述している必要があります。このような場合に考えられる2つのアプローチは、エラー処理メカニズムを破棄するか呼び出すことです。破棄を選択した場合、処分の詳細が必要になる場合があります。たとえば、ドロップされたフレームを受信されなかったかのように扱うか、既存の接続または隣接状態をリセットします。
The specification should describe actions taken when a critical resource or a performance-scaling limit is exceeded. This is necessary for cases where a risk of network degradation or operational failure exists. In such cases, a consistent behavior between implementations is necessary.
仕様では、重要なリソースまたはパフォーマンススケーリングの制限を超えたときに実行されるアクションについて説明する必要があります。これは、ネットワークの劣化や動作障害のリスクが存在する場合に必要です。このような場合、実装間で一貫した動作が必要です。
A rule, first stated in STD 5/RFC 791, recognized as having benefits in implementation robustness and interoperability is:
STD 5 / RFC 791で最初に述べられたルールは、実装の堅牢性と相互運用性に利点があると認識されています。
"Be liberal in what you accept, and conservative in what you send".
「あなたが受け入れるものに寛大であり、あなたが送るものに保守的である」。
Or establish restrictions on what a protocol transmits, but be able to deal with every conceivable error received. Caution is urged in applying this approach in standards track protocols. It has in the past lead to conflicts between vendors when interoperability fails. The sender accuses the receiver of failing to be liberal enough, and the receiver accuses the sender of not being conservative enough. Therefore, the author is obligated to provide extensive detail on send and receive behavior.
または、プロトコルが送信するものに制限を設定しますが、受信した考えられるすべてのエラーに対処できます。このアプローチを標準化手順プロトコルに適用する場合は注意が必要です。過去には、相互運用性が失敗したときにベンダー間の競合が発生していました。送信者は受信者を十分に寛大に失敗したと非難し、受信者は送信者が十分に保守的でないと非難します。したがって、送信者と受信者の動作に関する詳細を提供する義務があります。
To avoid any confusion between the two, recommend that standard authors specify send and receive behavior separately. The description of reception will require the most detailing. For implementations are expected to continue operating regardless of error received. Therefore, the actions taken to achieve that result, need to be laid out in the protocol specification. Standard authors should concern themselves on achieving a level of cooperation that limits network disruption, not just how to survive on the network. The appearance of undefined information or conditions must not cause a network or host failure. This requires specification on how to attempt acceptance of most of the packets. Two approaches are available, either using as much of the packet's content as possible, or invoking error procedures. The author should specify a dividing line on when to take which approach.
2つの間の混乱を避けるために、標準の作成者が送信と受信の動作を個別に指定することをお勧めします。レセプションの説明には、最も詳細な情報が必要です。実装では、受信したエラーに関係なく動作を継続することが期待されます。したがって、その結果を達成するために取られたアクションは、プロトコル仕様で説明される必要があります。標準的な作成者は、ネットワーク上でどのように生き残るかだけでなく、ネットワークの混乱を制限するレベルの協力を達成することに関心を持つべきです。未定義の情報または条件が表示されても、ネットワークまたはホストの障害が発生してはなりません。これには、ほとんどのパケットの受け入れを試行する方法の指定が必要です。パケットのコンテンツをできるだけ多く使用するか、エラー手順を呼び出すかの2つのアプローチが利用できます。著者は、どのアプローチを取るかについての境界線を指定する必要があります。
A case for consideration is that of a routing protocol, where acceptance of flawed information can cause network failure. For protocols such as this, the specification should identify packets that could have different interpretations and mandate that they be rejected completely or the nature of the attempt to recover some information from them. For example, routing updates that contain more data than the tuple count shows. The protocol authors should consider whether some trailing data can be accepted as additional routes, or to reject the entire packet as suspect because it is non-conformant.
検討すべきケースはルーティングプロトコルのケースで、欠陥のある情報を受け入れるとネットワーク障害が発生する可能性があります。このようなプロトコルの場合、仕様では、解釈が異なる可能性のあるパケットを特定し、完全に拒否するか、パケットから情報を復元する試みの性質を義務付ける必要があります。たとえば、タプルカウントが示すよりも多くのデータを含むルーティング更新。プロトコルの作成者は、一部の後続データを追加のルートとして受け入れることができるかどうか、またはパケットが適合していないためにパケット全体を疑わしいものとして拒否するかどうかを検討する必要があります。
Specifications with many optional features increase the complexity of the implementation and the chance of non-interoperable implementations. The danger is that different implementations may specify some combination of options that are unable to interoperate with each other.
多くのオプション機能を備えた仕様は、実装の複雑さと相互運用不可能な実装の可能性を高めます。危険は、異なる実装が、相互運用できないオプションの組み合わせを指定する可能性があることです。
As the document moves along the standard track, implementation experience shall determine the need for each option. Implementation shall show whether the option should be a mandatory part of the protocol or remain an option. If an option is not implemented as the document advances, it must be removed from the protocol before it reaches draft standard status.
ドキュメントが標準トラックに沿って移動するとき、実装の経験によって各オプションの必要性が決まります。実装は、オプションがプロトコルの必須部分であるか、オプションのままであるかを示します。文書が進むにつれてオプションが実装されない場合は、ドラフト標準ステータスに達する前にプロトコルから削除する必要があります。
Therefore, options shall only be present in a protocol to address a real requirement. For example, options can support future extensibility of the protocol, a particular market, e.g., the financial industry, or a specific network environment, e.g., a network constrained by limited bandwidth. They shall not be included as a means to "buy-off" a minority opinion. Omission of the optional item shall have no interoperability consequences for the implementation that does so.
したがって、オプションは、実際の要件に対処するためのプロトコルにのみ存在します。たとえば、オプションは、プロトコルの将来の拡張性、特定の市場（金融業界など）、または特定のネットワーク環境（限られた帯域幅によって制約されるネットワークなど）をサポートできます。それらは少数意見を「買収」する手段として含まれてはならない。オプション項目の省略は、そうする実装に対して相互運用性の結果をもたらしてはなりません。
One possible approach is to document protocol options in a separate specification. This keeps the main protocol specification clean and makes it clear that the options are not required to implement the protocol. Regardless of whether they appear within the specification or in a separate document, the text shall discuss the full implications of either using the option or not, and the case for choosing either course. As part of this, the author needs to consider and describe how the options are used alongside other protocols. The text must also specify the default conditions of all options. For security checking options the default condition is on or enabled.
可能なアプローチの1つは、プロトコルオプションを別の仕様に文書化することです。これにより、メインのプロトコル仕様がクリーンに保たれ、プロトコルの実装にオプションが不要であることを明確にします。仕様内にあるのか別のドキュメント内にあるのかに関係なく、テキストでは、オプションを使用するかどうかの完全な意味、およびいずれかのコースを選択する場合について説明します。この一環として、作成者は、オプションが他のプロトコルと一緒にどのように使用されるかを検討して説明する必要があります。テキストでは、すべてのオプションのデフォルト条件も指定する必要があります。セキュリティチェックオプションの場合、デフォルトの条件はオンまたは有効です。
There are occasions when mutually exclusive options appear within the protocol. That is, the implementation of an optional feature precludes the implementation of the other optional feature. For clarity, the author needs to state when to implement one or the other, what the effect of choosing one over the other is, and what problems the implementer or user may face. The choice of one or the other options shall have no interoperability consequences between multiple implementations.
プロトコル内に相互に排他的なオプションが現れる場合があります。つまり、オプション機能を実装すると、他のオプション機能を実装できなくなります。明確にするために、作成者は、どちらか一方を実装するタイミング、どちらを選択するかによる影響、および実装者またはユーザーが直面する可能性のある問題について述べる必要があります。 1つまたは他のオプションを選択しても、複数の実装間で相互運用性の影響はありません。
The BCP 14/RFC 2119, "Key words for use in RFCs to Indicate Requirement Level", defines several words that are necessary for writing a standards track document. Editors of standards track documents must not deviate from the definitions provided as they are intended to identify interoperability requirements or limit potentially harmful behavior. The capitalization of these words is the accepted norm, and can help in identifying an unintentional or unreasonable requirement. These words have been used in several RFCs the first instances being STD 3/RFC 1122/RFC 1123.
BCP 14 / RFC 2119の「要件レベルを示すためにRFCで使用するキーワード」は、標準化されたトラックドキュメントの作成に必要ないくつかの単語を定義しています。標準追跡ドキュメントの編集者は、相互運用性の要件を特定したり、潜在的に有害な動作を制限したりすることを目的としているため、提供されている定義から逸脱してはなりません。これらの単語の大文字の使用は容認された標準であり、意図的でないまたは不合理な要件を識別するのに役立ちます。これらの単語はいくつかのRFCで使用されており、最初のインスタンスはSTD 3 / RFC 1122 / RFC 1123です。
Formal syntax notations can be used to define complicated protocol concepts or data types, and to specify values of these data types. This permits the protocol to be written without concern on how the implementation is constructed, or how the data type is represented during transfer. The specification is simplified because it can be presented as "axioms" that will be proven by implementation.
形式的な構文表記法を使用して、複雑なプロトコルの概念やデータ型を定義し、これらのデータ型の値を指定できます。これにより、実装がどのように構築されるか、または転送中にデータ型がどのように表されるかを気にすることなく、プロトコルを記述できます。仕様は、実装によって証明される「公理」として提示できるため、簡略化されています。
The formal specification of the syntax used should be referenced in the text of the standard. Any extensions, subsets, alterations, or exceptions to that formal syntax should be defined within the standard.
使用される構文の正式な仕様は、標準の本文で参照する必要があります。その正式な構文の拡張、サブセット、変更、または例外は、規格内で定義する必要があります。
The STD 11/RFC 822 provides an example of this. In RFC 822 (Section 2 and Appendix D) the Backus-Naur Form (BNF) meta-language was extended to make its representation smaller and easier to understand. Another example is STD 16/RFC 1155 (Section 3.2) where a subset of the Abstract Syntax Notation One (ASN.1) is defined.
STD 11 / RFC 822はこの例を提供します。 RFC 822（セクション2および付録D）では、Backus-Naur Form（BNF）メタ言語が拡張されて、その表現がより小さく理解しやすくなりました。別の例は、STD 16 / RFC 1155（セクション3.2）で、抽象構文記法1（ASN.1）のサブセットが定義されています。
The author of a standards track protocol needs to consider several things before they use a formal syntax notation. Is the formal specification language being used parseable by an existing machine? If no parser exists, is there enough information provided in the specification to permit the building of a parser? If not, it is likely the reader will not have enough information to decide what the notation means. In addition, the author should remember machine parseable syntax is often unreadable by humans, and can make the specification excessive in length. Therefore, syntax notations cannot take the place of a clearly written protocol description.
標準追跡プロトコルの作成者は、正式な構文表記を使用する前にいくつかのことを考慮する必要があります。使用されている形式仕様言語は既存のマシンで解析可能ですか？パーサーが存在しない場合、パーサーの作成を許可するのに十分な情報が仕様に提供されていますか？そうでない場合は、表記法が何を意味するかを決定するのに十分な情報が読者にない可能性があります。さらに、作成者は、機械で解析可能な構文は人間が読めないことが多く、仕様が長すぎることを覚えておく必要があります。したがって、構文表記は、明確に書かれたプロトコルの説明の代わりにはなりません。
The common use of the Internet standard track protocols by the Internet community requires that unique values be assigned to parameter fields. An IETF WG does not have the authority to assign these values for the protocol it developed. The Internet Assigned Numbers Authority (IANA) is the central authority for the assignment of unique parameter values for Internet protocols. The authors of a developing protocol need to coordinate with the IANA the rules and procedures to manage the number space. This coordination needs to be completed prior to submitting the Internet Draft to the standards track.
インターネットコミュニティによるインターネット標準トラックプロトコルの一般的な使用では、パラメータフィールドに一意の値を割り当てる必要があります。 IETF WGには、開発したプロトコルにこれらの値を割り当てる権限がありません。 Internet Assigned Numbers Authority（IANA）は、インターネットプロトコルに一意のパラメーター値を割り当てるための中心的な機関です。開発中のプロトコルの作成者は、番号空間を管理するためのルールと手順をIANAと調整する必要があります。この調整は、インターネットドラフトを標準化コースに提出する前に完了する必要があります。
A document is in preparation that discusses issues related to identifier assignment policy and guidelines on specific text to task IANA with its administration. Standard authors should obtain a copy of it when it is finalized as an RFC.
ID割り当てポリシーに関連する問題と、IANAの管理に関するタスクIANAへの特定のテキストに関するガイドラインを説明するドキュメントが準備中です。標準の作成者は、RFCとして確定するときに、そのコピーを入手する必要があります。
For further information on parameter assignment and current assignments, authors can reference STD 2, RFC 1700, "Assigned Numbers" (http://www.iana.org).
パラメータの割り当てと現在の割り当ての詳細については、作成者はSTD 2、RFC 1700、「Assigned Numbers」（http://www.iana.org）を参照できます。
When relevant, each standard needs to discuss how to manage the protocol being specified. This management process should be compatible with the current IETF Standard management protocol. In addition, a MIB must be defined within the standard or in a companion document. The MIB must be compatible with current Structure of Management Information (SMI) and parseable using a tool such as SMICng. Where management or a MIB is not necessary this section of the standard should explain the reason it is not relevant to the protocol.
関連する場合、各標準は、指定されているプロトコルを管理する方法を議論する必要があります。この管理プロセスは、現在のIETF標準管理プロトコルと互換性がある必要があります。さらに、MIBは標準内または関連ドキュメント内で定義する必要があります。 MIBは、現在の管理情報構造（SMI）と互換性があり、SMICngなどのツールを使用して解析できる必要があります。管理やMIBが不要な場合、規格のこのセクションでは、プロトコルに関連しない理由を説明する必要があります。
The standard should establish the limitations on the scale of use, e.g., tens of millions of sessions, gigabits per second, etc., and establish limits on the resources used, e.g., round trip time, computing resources, etc. This is important because it establishes the ability of the network to accommodate the number of users and the complexity of their relations. The STD 53/RFC 1939 has an example of such a section. If this is not applicable to the protocol, an explanation of why not should be included.
この規格では、使用規模に制限（たとえば、数千万セッション、ギガビット/秒など）を設定し、使用されるリソース（往復時間、コンピューティングリソースなど）に制限を設定する必要があります。これは、これは、ユーザーの数とユーザーの関係の複雑さに対応するネットワークの機能を確立します。 STD 53 / RFC 1939には、このようなセクションの例があります。これがプロトコルに該当しない場合は、その理由の説明を含める必要があります。
A standard should discuss the relationship between network topology and convergence behavior. As part of this, any topology that would be troublesome for the protocol should be identified. Additionally, the specification should address any possible destabilizing events, and means by which the protocol resists or recovers from them. The purpose is to insure that the network will stabilize, in a timely fashion, after a change, and that a combination of errors or events will not plunge the network into chaos. The STD 34/RFC 1058, as an example, has sections which discuss how that protocol handles the affects of changing topology.
標準では、ネットワークトポロジと収束動作の関係について説明する必要があります。この一環として、プロトコルにとって問題となるトポロジを特定する必要があります。さらに、この仕様は、起こり得る不安定化イベント、およびプロトコルがそれらに抵抗または回復する手段に対処する必要があります。目的は、変更後にネットワークがタイムリーに安定し、エラーまたはイベントの組み合わせによってネットワークが混乱しないようにすることです。 STD 34 / RFC 1058には、例として、そのプロトコルがトポロジーの変更の影響をどのように処理するかを説明するセクションがあります。
The obvious case this would apply to is a routing protocol. However, an application protocol could also have dynamic behavior that would affect the network. For example, a messaging protocol could suddenly dump a large number of messages onto the network. Therefore, editors of an application protocol will have to consider possible impacts to network stability and convergence behavior.
これが当てはまる明らかなケースはルーティングプロトコルです。ただし、アプリケーションプロトコルには、ネットワークに影響を与える動的な動作も含まれます。たとえば、メッセージングプロトコルが突然大量のメッセージをネットワークにダンプする可能性があります。したがって、アプリケーションプロトコルの編集者は、ネットワークの安定性と収束動作への影響の可能性を考慮する必要があります。
At one time the Internet had a geographic boundary and was English only. The Internet now extends internationally. Therefore, data is interchanged in a variety of languages and character sets. In order to meet the requirements of an international Internet, a standard must conform to the policies stated in BCP 18/RFC 2277, "IETF Policy on Character Sets and Languages".
かつてインターネットには地理的な境界があり、英語のみでした。現在、インターネットは国際的に広がっています。したがって、データはさまざまな言語と文字セットで交換されます。国際インターネットの要件を満たすために、標準はBCP 18 / RFC 2277、「文字セットと言語に関するIETFポリシー」に記載されているポリシーに準拠する必要があります。
Every standards track RFC should have a glossary, as words can have many meanings. By defining any new words introduced, the author can avoid confusing or misleading the implementers. The definition should appear on the word's first appearance within the text of the protocol specification, and in a separate glossary section.
単語には多くの意味がある可能性があるため、すべての標準トラックRFCには用語集が必要です。導入された新しい単語を定義することにより、作成者は実装者の混乱や誤解を避けることができます。定義は、プロトコル仕様のテキスト内の単語の最初の出現と、別の用語集セクションに表示されます。
It is likely that definition of the protocol will rely on many words frequently used in IETF documents. All authors must be knowledgeable of the common accepted definitions of these frequently used words. FYI 18/RFC 1983, "Internet Users' Glossary", provides definitions that are specific to the Internet. Any deviation from these definitions by authors is strongly discouraged. If circumstances require deviation, an author should state that he is altering the commonly accepted definition, and provide rationale as to the necessity of doing so. The altered definition must be included in the Glossary section.
プロトコルの定義は、IETF文書で頻繁に使用される多くの単語に依存する可能性があります。すべての著者は、これらの頻繁に使用される単語の一般に受け入れられている定義について知識がなければなりません。 FYI 18 / RFC 1983、「Internet Users 'Glossary」は、インターネットに固有の定義を提供します。著者によるこれらの定義からの逸脱は、強くお勧めしません。状況が逸脱を必要とする場合、著者は、一般に受け入れられている定義を変更していることを述べ、そうする必要性についての理論的根拠を提供する必要があります。変更された定義は、用語集のセクションに含まれている必要があります。
If the author uses the word as commonly defined, she does not have to include the definition in the glossary. As a minimum, FYI 18/RFC 1983 should be referenced as a source.
著者が一般的に定義されている単語を使用する場合、彼女は用語集に定義を含める必要はありません。最低でも、FYI 18 / RFC 1983をソースとして参照する必要があります。
3 Specific Guidelines
3特定のガイドライン
The following are guidelines on how to present specific technical information in standards.
以下は、標準で特定の技術情報を提示する方法に関するガイドラインです。
Most link, network, and transport layer protocols have packet descriptions. Packet diagrams included in the standard are very helpful to the reader. The preferred form for packet diagrams is a sequence of long words in network byte order, with each word horizontal on the page and bit numbering at the top:
ほとんどのリンク、ネットワーク、およびトランスポート層プロトコルには、パケットの説明があります。標準に含まれるパケット図は、読者にとって非常に役立ちます。パケットダイアグラムの推奨形式は、ネットワークバイトオーダーの長いワードのシーケンスで、各ワードはページ上で水平で、ビット番号が上部にあります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| Prio. | Flow Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In cases where a packet is strongly byte-aligned rather than word-aligned (e.g., when byte-boundary variable-length fields are used), display packet diagrams in a byte-wide format. The author can use different height boxes for short and long words, and broken boxes for variable-length fields:
パケットがワード境界ではなくバイト境界に強く配置されている場合（バイト境界の可変長フィールドが使用されている場合など）は、パケットダイアグラムをバイト幅の形式で表示します。著者は、短い単語と長い単語に異なる高さのボックスを使用でき、可変長フィールドに壊れたボックスを使用できます。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Length N |
+-+-+-+-+-+-+-+-+
| |
+ Address +
...
+ (N bytes) +
| |
+-+-+-+-+-+-+-+-+
| |
+ 2-byte field +
| |
+-+-+-+-+-+-+-+-+
The specifications of some protocols are particularly lengthy, sometimes covering a hundred pages or more. In such cases, the inclusion of a summary table can reduce the risk of conformance failure by an implementation through oversight. A summary table itemizes what in a protocol is mandatory, optional, or prohibited. Summary tables do not guarantee conformance, but serve to assist an implementer in checking that they have addressed all protocol features.
一部のプロトコルの仕様は特に長く、100ページ以上をカバーする場合があります。このような場合、サマリーテーブルを含めることで、監視による実装による適合障害のリスクを減らすことができます。要約表は、プロトコルの中で何が必須、オプション、または禁止されているかを示しています。要約テーブルは適合を保証するものではありませんが、実装者がすべてのプロトコル機能に対処したことを確認する際に実装者を支援するのに役立ちます。
The summary table will consist of, as a minimum, four (4) columns: Protocol Feature, Section Reference, Status, and References/Footnotes. The author may add columns if they further explain or clarify the protocol.
要約表は、最低でも4つの列（プロトコル機能、セクション参照、ステータス、参照/脚注）で構成されます。プロトコルをさらに説明または明確化する場合、作成者は列を追加できます。
In the Protocol Feature column, list the protocol's characteristics, for example, a command word. We recommend grouping series of related transactions under descriptive headers, for example, RECEPTION.
[プロトコル機能]列に、プロトコルの特性（コマンドワードなど）をリストします。 RECEPTIONなどの説明的なヘッダーの下で、関連する一連のトランザクションをグループ化することをお勧めします。
Section reference directs the implementer to the section, paragraph, or page that describes the protocol feature in detail.
セクション参照は、プロトコル機能を詳細に説明するセクション、段落、またはページに実装者を誘導します。
Status indicates whether the feature is mandatory, optional, or prohibited. The author can use either a separate column for each possibility, or a single column with appropriate codes. These codes need to be defined at the start of the summary table to avoid confusion. Possible status codes:
ステータスは、機能が必須、オプション、禁止のいずれであるかを示します。著者は、可能性ごとに個別の列を使用することも、適切なコードを含む単一の列を使用することもできます。これらのコードは、混乱を避けるために、サマリーテーブルの最初に定義する必要があります。可能なステータスコード：
M - must or mandatory MN - must not O - optional S - should SN - should not X - prohibited
M-必須または必須MN-不可O-オプションS-SN-不可X-禁止
In the References/Footnotes column authors can point to other RFCs that are necessary to consider in implementing this protocol feature, or any footnotes necessary to explain the implementation further.
References / Footnotes列で、作成者は、このプロトコル機能の実装で検討する必要がある他のRFC、または実装をさらに説明するために必要な脚注を指すことができます。
The STD 3/RFC 1122/RFC 1123 provides examples of summary tables.
STD 3 / RFC 1122 / RFC 1123は、サマリーテーブルの例を示しています。
A convenient method of presenting a protocol's behavior is as a state-machine model. That is, a protocol can be described by a series of states resulting from a command, operation, or transaction. State-machine models define the variables and constants that establish a state, the events that cause state transitions and the actions that result from those transitions. Through these models, an understanding of the protocol's dynamic operation as sequence of state transitions that occur for any given event is possible. State transitions can be detailed by diagrams, tables, or time lines.
プロトコルの動作を提示する便利な方法は、状態機械モデルとしてです。つまり、プロトコルは、コマンド、操作、またはトランザクションから生じる一連の状態によって記述できます。状態機械モデルは、状態を確立する変数と定数、状態遷移を引き起こすイベント、およびそれらの遷移から生じるアクションを定義します。これらのモデルを通じて、特定のイベントで発生する一連の状態遷移としてのプロトコルの動的な動作を理解することが可能です。状態遷移は、図、表、または時系列で詳細に説明できます。
Note that state-machine models are never to take the place of detailed text description of the specification. They are adjuncts to the text. The protocol specification shall always take precedence in the case of a conflict.
ステートマシンモデルは、仕様の詳細なテキストの説明に取って代わるものではありません。彼らはテキストの付属物です。競合が発生した場合、プロトコル仕様が常に優先されます。
When using a state transition diagram, show each possible protocol state as a box connected by state transition arcs. The author should label each arc with the event that causes the transition, and, in parentheses, any actions taken during the transition. The STD 5/RFC 1112 provides an example of such a diagram. As ASCII text is the preferred storage format for RFCs, only simple diagrams are possible. Tables can summarize more complex or extensive state transitions.
状態遷移図を使用する場合、可能なプロトコルの各状態を、状態遷移弧で接続されたボックスとして表示します。作成者は、各アークに、遷移を引き起こすイベント、および括弧内に、遷移中に行われたアクションのラベルを付ける必要があります。 STD 5 / RFC 1112は、このような図の例を示しています。 ASCIIテキストはRFCの優先ストレージ形式であるため、可能なのは単純な図のみです。テーブルは、より複雑なまたは広範な状態遷移を要約できます。
In a state transition table, the different events are listed vertically and the different states are listed horizontally. The form, action/new state, represents state transitions and actions. Commas separate multiple actions, and succeeding lines are used as required. The authors should present multiple actions in the order they must be executed, if relevant. Letters that follow the state indicate an explanatory footnote. The dash ('-') indicates an illegal transition. The STD 51/RFC 1661 provides an example of such a state transition table. The initial columns and rows of that table follow as an example:
状態遷移表では、さまざまなイベントが縦にリストされ、さまざまな状態が横にリストされます。フォームaction / new stateは、状態遷移とアクションを表します。コンマは複数のアクションを分離し、後続の行は必要に応じて使用されます。著者は、必要に応じて、実行する必要がある順序で複数のアクションを提示する必要があります。州に続く文字は、説明的な脚注を示します。ダッシュ（ '-'）は、不正な遷移を示します。 STD 51 / RFC 1661は、そのような状態遷移テーブルの例を提供します。例として、そのテーブルの最初の列と行を次に示します。
| State
| 0 1 2 3 4 5
Events| Initial Starting Closed Stopped Closing Stopping
------+-----------------------------------------------------------
Up | 2 irc,scr/6 - - - -
Down | - - 0 tls/1 0 1
Open | tls/1 1 irc,scr/6 3r 5r 5r
Close| 0 tlf/0 2 2 4 4
|
TO+ | - - - - str/4 str/5
TO- | - - - - tlf/2 tlf/3
The STD 18/RFC 904 also presents state transitions in table format. However, it lists transitions in the form n/a, where n is the next state and a represents the action. The method in RFC 1661 is preferred as new state logically follows action. In addition, RFC 904's Appendix C models transitions as the Cartesian product of two state machines. This is a more complex representation that may be difficult to comprehend for those readers that are unfamiliar with the format. We recommend that authors present tables as defined in the previous paragraph.
ＳＴＤ１８ ／ ＲＦＣ９０４はまた、表形式で状態遷移を提示する。ただし、遷移はn / aの形式でリストされます。nは次の状態で、aはアクションを表します。新しい状態は論理的にアクションに従うため、RFC 1661の方法が推奨されます。さらに、RFC 904の付録Cは、2つの状態機械のデカルト積として遷移をモデル化します。これはより複雑な表現であり、形式に慣れていない読者には理解が難しい場合があります。著者は、前の段落で定義された表を提示することをお勧めします。
A final method of representing state changes is by a time line. The two sides of the time line represent the machines involved in the exchange. The author lists the states the machines enter as time progresses (downward) along the outside of time line. Within the time line, show the actions that cause the state transitions. An example:
状態変化を表す最後の方法は、タイムラインによるものです。タイムラインの両側は、交換に関係するマシンを表しています。著者は、タイムラインの外側に沿って時間の経過に伴って（下向きに）マシンが入る状態をリストします。タイムライン内で、状態遷移を引き起こすアクションを示します。例：
client server
クライアントサーバー
| |
| | LISTEN
SYN_SENT |----------------------- |
| \ syn j |
| ----------------->| SYN_RCVD
| |
| ------------------|
| syn k, ack j+1 / |
ESTABLISHED |<---------------------- |
| |
4 Document Checklist
4文書チェックリスト
The following is a checklist based on the above guidelines that can be applied to a document:
以下は、ドキュメントに適用できる上記のガイドラインに基づくチェックリストです。
o Does it identify the security risks? Are countermeasures for each
potential attack provided? Are the effects of the security
measures on the operating environment detailed?
o Does it explain the purpose of the protocol or procedure? Are the
intended functions and services addressed? Does it describe how it
relates to existing protocols?
o Does it consider scaling and stability issues?
o Have procedures for assigning numbers been coordinated with IANA?
o Does it discuss how to manage the protocol being specified? Is a
MIB defined?
o Is a target audience defined?
o Does it reference or explain the algorithms used in the protocol?
o Does it give packet diagrams in recommended form, if applicable?
o Is there a change log?
o Does it describe differences from previous versions, if
applicable?
o Does it separate explanatory portions of the document from
requirements?
o Does it give examples of protocol operation?
o Does it specify behavior in the face of incorrect operation by
other implementations?
o Does it delineate which packets should be accepted for processing
and which should be ignored?
o If multiple descriptions of a requirement are given, does it
identify one as binding?
o How many optional features does it specify? Does it separate them
into option classes?
o Have all combinations of options or option classes been examined
for incompatibility?
o Does it explain the rationale and use of options?
o Have all mandatory and optional requirements be identified and
documented by the accepted key words that define Internet
requirement levels?
o Does it conform to the current internationalization policies of
the IETF?
o Are the recommended meanings for common Internet terms used?
o If not, are new or altered definitions for terms given in a
glossary?
5 Security Considerations
5セキュリティに関する考慮事項
This document does not define a protocol or procedure that could be subject to an attack. It establishes guidelines for the information that should be included in RFCs that are to be submitted to the standards track. In the area of security, IETF standards authors are called on to define clearly the threats faced by the protocol and the way the protocol does or does not provide security assurances to the user.
このドキュメントでは、攻撃を受ける可能性のあるプロトコルや手順を定義していません。標準化トラックに提出されるRFCに含める必要がある情報のガイドラインを確立します。セキュリティの分野では、IETF標準の作成者は、プロトコルが直面する脅威と、プロトコルがユーザーにセキュリティを保証する方法と提供しない方法を明確に定義するよう求められています。
6 References
6参考文献
[RFC 791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791 September 1981.
[RFC 791] Postel、J。、「インターネットプロトコル（IP）」、STD 5、RFC 791、1981年9月。
[RFC 904] Mills, D., "Exterior Gateway Protocol formal specification", RFC 904, April 1984.
[RFC 904] Mills、D。、「Exterior Gateway Protocol formal specification」、RFC 904、1984年4月。
[RFC 1058] Hedrick, C., "Routing Information Protocol", STD 34, RFC 1058, June 1988.
[RFC 1058] Hedrick、C。、「Routing Information Protocol」、STD 34、RFC 1058、1988年6月。
[RFC 1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[RFC 1112] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[RFC 1122] Braden, R., "Requirements for Internet Hosts -- Communication Layers", STD 3, RFC 1122, October 1989.
[RFC 1122] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。
[RFC 1123] Braden, R., "Requirements for Internet hosts -- Application and Support", STD 3, RFC 1123, October 1989.
[RFC 1123] Braden、R。、「インターネットホストの要件-アプリケーションとサポート」、STD 3、RFC 1123、1989年10月。
[RFC 1311] Postel, J., "Introduction to the STD Notes", RFC 1311, March 1992.
[RFC 1311] Postel、J。、「STDノートの概要」、RFC 1311、1992年3月。
[RFC 1350] Sollins, K., "The TFTP Protocol (Revision 2)", STD 33, RFC 1350, July 1992.
[RFC 1350] Sollins、K。、「The TFTP Protocol（Revision 2）」、STD 33、RFC 1350、1992年7月。
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC 1661] Simpson、W。、「The Point-to-Point Protocol（PPP）」、STD 51、RFC 1661、1994年7月。
[RFC 1662] Simpson, W., "PPP in HLDC-like Framing", STD 51, RFC 1662, July 1994.
[RFC 1662] Simpson、W。、「PPP in HLDC-like Framing」、STD 51、RFC 1662、1994年7月。
[RFC 1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994. (http://www.iana.org)
[RFC 1700] Reynolds、J。、およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。（http://www.iana.org）
[RFC 1939] Meyers, J., and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.
[RFC 1939] Meyers、J。、およびM. Rose、「Post Office Protocol-Version 3」、STD 53、RFC 1939、May 1996。
[RFC 1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC 1958] Carpenter、B。、「Architectural Principles of the Internet」、RFC 1958、1996年6月。
[RFC 1983] Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983, August 1996.
[RFC 1983] Malkin、G。、「Internet Users 'Glossary」、FYI 18、RFC 1983、1996年8月。
[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996.
[RFC 2026] Bradner、S。、「The Internet Standards Process-Revision 3」、RFC 2026、1996年10月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[RFC 2119] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC 2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC 2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC 2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", RFC 2223, October 1997.
[RFC 2223] Postel、J。およびJ. Reynolds、「RFC Authorsへの指示」、RFC 2223、1997年10月。
[RFC 2277] Alvestrand, H., "IETF Policy on Character Sets and Language", RFC 2277, January 1998.
[RFC 2277] Alvestrand H。、「IETF Policy on Character Sets and Language」、RFC 2277、1998年1月。
[RFC 2316] Bellovin, S., "Report of the IAB Security Architecture Workshop", RFC 2316, April 1998.
[RFC 2316] Bellovin、S。、「Report of the IAB Security Architecture Workshop」、RFC 2316、1998年4月。
7 Acknowledgments
7謝辞
Peter Desnoyers and Art Mellor began the work on this document. Others that contributed were:
Peter DesnoyersとArt Mellorがこのドキュメントの作業を開始しました。貢献した他の人は：
Bernard Aboba Harald T. Alvestrand Fred Baker Scott Bradner Brian Carpenter Robert Elz Dirk Fieldhouse Dale Francisco Gary Malkin Neal McBurnett Thomas Narten Craig Partridge Vern Paxson Mike O'Dell Henning Schulzrinne Kurt Starsinic James Watt
バーナードアボバハラルドT.アルヴェストランドフレッドベイカースコットブラドナーブライアンカーペンターロバートエルズダークフィールドハウスデールフランシスコゲイリーマルキンニールマクバーネットトーマスナーテンクレイグパートリッジヴェルパクソンマイクオデルヘニングシュルズリンネカートスタージニックジェームズワット
8 Editor's Address
8編集者のアドレス
Gregor D. Scott Director, Defense Information Systems Agency ATTN: JIEO-JEBBC Ft. Monmouth, NJ 07703-5613 USA
グレゴールD.スコット国防情報システム局長ATTN：JIEO-JEBBC Ft。モンマス、ニュージャージー州07703-5613米国
Phone: (732) 427-6856 Fax: (732) 532-0853 EMail: scottg@ftm.disa.mil
電話：（732）427-6856ファックス：（732）532-0853メール：scottg@ftm.disa.mil
9 Appendix
9付録
CHANGES FROM DRAFT -06
ドラフト-06からの変更点
The following changes were made following IESG review:
IESGレビューに続いて、次の変更が行われました。
References to RFC 1543 were changed to RFC 2223 that obsoleted it.
RFC 1543への参照は、廃止されたRFC 2223に変更されました。
In section 2.1, "export control" was dropped as a valid reason for not selecting a security mechanism. In addition, ambiguous or conflicting sentences were removed.
セクション2.1では、セキュリティメカニズムを選択しない正当な理由として、「エクスポート制御」が削除されました。さらに、あいまいまたは矛盾する文が削除されました。
In section 2.1 reference made to RFC 2315 as an additional source of information.
セクション2.1では、追加の情報源としてRFC 2315を参照しています。
Section 2.5 was changed to highlight the Change Log's purpose as assistance to implementers.
セクション2.5は、実装者への支援としての変更ログの目的を強調するために変更されました。
The IANA Considerations section (2.13) was rewritten to highlight that the IANA guidelines document is work in progress but should be used when it becomes available.
IANAの考慮事項セクション（2.13）は、IANAガイドラインドキュメントが作成中であるが、利用可能になったときに使用する必要があることを強調するために書き直されました。
Section 3.4 Character Sets was deleted and replaced by section 2.17 Internationalization.
セクション3.4文字セットは削除され、セクション2.17国際化に置き換えられました。
Spelling and grammar corrections were made.
スペルと文法の修正が行われた。
CHANGES FROM DRAFT -05
下書きからの変更-05
A sentence pointing to a pending document that further addresses IANA considerations was added to section 2.13. The current draft of that document is draft-iesg-iana-considerations-02.txt. A clause stating that the IANA established the assignment policies was removed since it appeared to conflict with the intent of the referenced ID. Placeholders for the BCP and RFC number have been added to the text and reference section.
IANAの考慮事項にさらに取り組む保留中のドキュメントを指す文がセクション2.13に追加されました。そのドキュメントの現在のドラフトは、draft-iesg-iana-considerations-02.txtです。 IANAが割り当てポリシーを確立したことを示す条項は、参照されたIDの意図と矛盾するように思われたため削除されました。 BCPおよびRFC番号のプレースホルダーがテキストと参照セクションに追加されました。
A new section (2.5) requiring change logs as documents progress along the standards track was added.
ドキュメントが標準トラックに沿って進行するときに変更ログを要求する新しいセクション（2.5）が追加されました。
References to RFC 2044 were changed to RFC 2279 that obsoleted it.
RFC 2044への参照は、廃止されたRFC 2279に変更されました。
Spelling and grammar corrections were made.
スペルと文法の修正が行われた。
CHANGES FROM DRAFT -04
ドラフト-04からの変更点
A paragraph pointing to a pending document that further addresses security was updated.
セキュリティにさらに取り組む保留中のドキュメントを指す段落が更新されました。
10 Full Copyright Statement
10完全な著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントとその翻訳はコピーして他のユーザーに提供することができ、コメントまたはその他の方法で説明したり、その実装を支援する二次的著作物は、いかなる種類の制限なしに、全体または一部を準備、コピー、公開、および配布することができますただし、上記の著作権表示とこの段落は、そのようなすべてのコピーと派生物に含まれています。ただし、このドキュメント自体は、著作権に関する通知を削除したり、インターネットソサエティや他のインターネット組織への参照を削除したりするなど、いかなる方法でも変更できません。ただし、インターネット標準を開発する目的で必要な場合は除きます。インターネット標準のプロセスに従うか、または必要に応じて、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記で付与された制限付きのアクセス許可は永続的であり、インターネットソサエティまたはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。