RFC3269 日本語訳

Network Working Group                                         R. Kermode
Request for Comments: 3269                                      Motorola
Category: Informational                                      L. Vicisano
                                                                   Cisco
                                                              April 2002

コメントを求めるワーキンググループR.カーモードの要求をネットワークでつないでください: 3269年のモトローラカテゴリ: 情報のL.Vicisanoコクチマス2002年4月

Author Guidelines for Reliable Multicast Transport (RMT) Building Blocks
                  and Protocol Instantiation documents

ドキュメントをBlocksとプロトコルInstantiationに造るReliable Multicast Transport(RMT)の作者Guidelines

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

Abstract

要約

   This document provides general guidelines to assist the authors of
   Reliable Multicast Transport (RMT) building block and protocol
   instantiation definitions.  The purpose of these guidelines is to
   ensure that any building block and protocol instantiation definitions
   produced contain sufficient information to fully explain their
   operation and use.  In addition these guidelines provide directions
   to specify modular and clearly defined RMT building blocks and
   protocol instantiations that can be refined and augmented to safely
   create new protocols for use in new scenarios for which any existing
   protocols were not designed.

このドキュメントは、Reliable Multicast Transport(RMT)ブロックとプロトコル具体化定義の作者を補助するために一般的ガイドラインを提供します。 これらのガイドラインの目的は彼らの操作と使用について完全に説明するために定義が作成したどんなブロックとプロトコル具体化も十分な情報を含むのを保証することです。 さらに、これらのガイドラインは、モジュールの、そして、明確に定義されたRMTブロックとどんな既存のプロトコルも設計されなかった新しいシナリオにおける使用のために安全に新しいプロトコルを作成するために精製して、増大させることができるプロトコル具体化を指定するために方向を提供します。

Table of Contents

目次

   1 Introduction ...................................................  2
   1.1 Terminology ..................................................  3
   2 The Guidelines .................................................  3
   2.1 Building Block Document Guidelines ...........................  3
   2.1.1 Rationale ..................................................  3
   2.1.2 Functionality ..............................................  4
   2.1.3 Applicability Statement ....................................  4
   2.1.4 Packet-Header Fields .......................................  4
   2.1.5 Requirements from other Building Blocks ....................  5
   2.1.6 Security Considerations ....................................  5
   2.1.7 Codepoint Considerations ...................................  6
   2.1.8 Summary Checklist ..........................................  6
   2.2 Protocol Instantiation Document Guidelines ...................  7

1つの序論… 2 1.1用語… 3 2、ガイドライン… 3 2.1 ブロックドキュメントガイドライン… 3 2.1 .1原理… 3 2.1 .2の機能性… 4 2.1 .3 適用性声明… 4 2.1 .4 パケットのヘッダー分野… 4 2.1 他のビルBlocksからの.5の要件… 5 2.1 .6 セキュリティ問題… 5 2.1 .7 Codepoint問題… 6 2.1 .8概要チェックリスト… 6 2.2 具体化ドキュメントガイドラインについて議定書の中で述べてください… 7

Kermode & Vicisano           Informational                      [Page 1]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[1ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

   2.2.1 Applicability Statement ....................................  7
   2.2.2 Architecture Definition ....................................  7
   2.2.3 Conformance Statement ......................................  8
   2.2.4 Functionality Definition ...................................  8
   2.2.5 Packet Formats .............................................  9
   2.2.6 Summary Checklist ..........................................  9
   3 IANA Considerations ............................................  9
   4 Acknowledgements ............................................... 10
   5 References ..................................................... 10
   6 Authors' Addresses ............................................. 11
   7 Full Copyright Statement ....................................... 12

2.2.1 適用性証明… 7 2.2 .2 アーキテクチャ定義… 7 2.2 .3 順応声明… 8 2.2 .4 機能性定義… 8 2.2 .5 パケット形式… 9 2.2 .6概要チェックリスト… 9 3のIANA問題… 9 4の承認… 10 5つの参照箇所… 10 6人の作者のアドレス… 11 7 完全な著作権宣言文… 12

1.  Introduction

1. 序論

   Reliable Multicast Transport (RMT) protocols can be constructed in a
   variety of ways, some of which will work better for certain
   situations than others.  It is believed that the requirements space
   for reliable multicast transport is sufficiently diverse that no one
   protocol can meet all the requirements [RFC2887].  However, it is
   also believed that there is sufficient commonality between the
   various approaches that it should be possible to define a number of
   building blocks [RFC3048] from which the various RMT protocols can be
   constructed.

さまざまな方法で信頼できるMulticast Transport(RMT)プロトコルを構成できます。その或るものは確かに他のものより良い状況を扱うでしょう。 いいえ1、プロトコルがすべての必要条件[RFC2887]を満たすことができるのは要件スペースが信頼できるマルチキャスト輸送のために十分多様であると信じられています。 しかしながら、また、様々なRMTプロトコルを構成できる多くのブロック[RFC3048]を定義するのが可能であるべきであることは様々なアプローチの間には、十分な共通点があると信じられています。

   One key benefit of this approach is that the same building block can
   be used multiple times in different protocol instantiations.  Another
   key benefit is that building blocks may be upgraded as experience and
   understanding is gained.  For this operation to be possible the
   building block needs to be clearly defined in terms of what it does,
   how it interacts with other building blocks, and how it fits into the
   overall architecture of a protocol instantiation.  This description
   should also be sufficiently detailed so that those wishing to improve
   upon a particular building block or protocol instantiation can do so
   with a full understanding of the design decisions and tradeoffs that
   were made earlier.

このアプローチの1つの主要な恩恵が中古の倍数が異なったプロトコル具体化の回であったかもしれないならそんなに同じブロックです。 別の主要な利益は経験と理解を獲得するのに従ってブロックがアップグレードするかもしれないということです。 この操作が可能であるように、ブロックは、何をするか、そして、どのように他のブロックと対話するか、そして、それがどのようにプロトコル具体化の総合的なアーキテクチャに収まるかに関して明確に定義される必要があります。 また、この記述も、したがって、特定のブロックかプロトコル具体化を改良したがっている人が、より早くされたデザイン決定と見返りの十分な理解を処理できるくらい十分詳細であるべきです。

   The building block approach also presents some dangers that must be
   well understood in order to avoid potential specification flaws.

また、部分構造合成法は潜在的仕様欠点を避けるためによく理解しなければならないいくつかの危険を提示します。

   The most important danger is related to inappropriate usage of
   building blocks.  Although efforts should be made in order to produce
   a modular and reusable specification of building blocks, for
   practical reasons this goal is not always fully achievable.  This
   results in the specification of building blocks whose applicability
   is context dependent, which in turn creates the potential for the
   risk of co-dependence incompatibilities between building blocks.  An
   example of such an incompatibility would be situation where the

最も重要な危険はブロックの不適当な使用法に関連します。 取り組みはブロックのモジュールの、そして、再利用できる仕様を作り出すために作られているべきですが、実際的な理由で、この目標は完全にいつも達成可能であるというわけではありません。 これは適用性が文脈に依存しているブロックの仕様をもたらします。(順番に、それは、ブロックの間の共依存非互換性のリスクの可能性を作成します)。 そのような不一致に関する例は状況がどこであったかでそうするでしょう。

Kermode & Vicisano           Informational                      [Page 2]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[2ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

   combinations of building blocks A and B works, the combination of
   building blocks B and C works, however the combination of building
   blocks A, B, and C does not work.

しかしながら、ブロックAとB作品の組み合わせ、ブロックBとC作品の組み合わせ、ブロックAの組み合わせ、B、およびCは働いていません。

   In order to avoid misusage of and incompatibilities between building
   blocks, any external dependency must be highlighted in the building
   block specification.  Furthermore, the specification must contain a
   precise applicability statement for the building block.  Conversely,
   any protocol instantiation specification must state how any building
   block being used in it meets the protocol instantiation's
   applicability requirements.  These guidelines are not intended to
   replace the common practice of Internet specification writing, but to
   augment them in a manner that better fits the RMT framework.

ブロックの間の誤用と非互換性を避けるために、ブロック仕様でどんな外部の依存も強調しなければなりません。 その上、仕様はブロックのための正確な適用性証明を含まなければなりません。 逆に、どんなプロトコル具体化仕様もそれで使用されるどんなブロックもどうプロトコル具体化の適用性必要条件を満たすかを述べなければなりません。 インターネット仕様書くことの一般的な習慣を取り替えることを意図するのではなく、これらのガイドラインは、RMTフレームワークに合うほうがよい方法でそれらを増大させるために意図します。

1.1.  Terminology

1.1. 用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

2.  The Guidelines

2. ガイドライン

   This document provides guidelines for authors of the two main kinds
   of RMT documents; building block documents and protocol instantiation
   documents.  The guidelines for each are as follows.

このドキュメントは主な2種類のRMTドキュメントの作者にガイドラインを提供します。 ブロックドキュメントとプロトコル具体化ドキュメント。 それぞれのためのガイドラインは以下の通りです。

2.1.  Building Block Document Guidelines

2.1. ブロックドキュメントガイドライン

   All RMT Building block documents MUST contain sections that cover the
   following.

すべてのRMTビルブロックドキュメントが以下をカバーするセクションを含まなければなりません。

2.1.1.  Rationale

2.1.1. 原理

   Individual building blocks SHOULD be reusable within multiple
   protocols and MUST provide functionality not present within other
   building blocks.  If a building block is currently used in a single
   protocol instantiation, then it MUST specify some functionality that
   is likely to be reused in another (future) protocol instantiation.

個々のブロックSHOULDは複数のプロトコルの中で再利用できて、他のブロックの中の現在でない機能性を提供しなければなりません。 ブロックが現在ただ一つのプロトコル具体化に使用されるなら、それは何らかの別の(将来)のプロトコル具体化で再利用されそうな機能性を指定しなければなりません。

   The rationale section of a building block document must clearly
   define why the particular level of granularity for the functional
   decomposition resulted in that building block being chosen.  If the
   granularity is too small it is highly likely that the building blocks
   will be trivial, and therefore require excessive additional effort to
   realize a working protocol.  Conversely, if the level of granularity
   is too large, building blocks will only be usable within a single
   protocol instantiation.  The rationale section MUST show that the
   level of granularity is appropriate so that neither problem occurs.

ブロックドキュメントの原理部は、機能的な分解のための特定のレベルの粒状がなぜ選ばれているそのブロックをもたらしたかを明確に定義しなければなりません。 粒状が小さ過ぎるなら、ブロックは、些細であり、したがって、働くプロトコルがわかるために過度の追加取り組みを非常に必要としそうでしょう。 逆に、粒状のレベルが大き過ぎる場合にだけ、ブロックはただ一つのプロトコル具体化の中で使用可能になるでしょう。 原理部は、粒状のレベルが適切であるのでどちらの問題も起こらないのを示さなければなりません。

Kermode & Vicisano           Informational                      [Page 3]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[3ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

2.1.2.  Functionality

2.1.2. 機能性

   The functionality section within a building block document MUST
   describe all algorithms and functions contained within the building
   block.  In addition, the external interfaces for accessing these
   algorithms and functions MUST be fully specified so that the building
   block can be combined with other building blocks and any additional
   functionality specified within a protocol instantiation document to
   realize a working protocol.

ブロックドキュメントの中の機能性部はブロックの中に含まれたすべてのアルゴリズムと機能について説明しなければなりません。 さらに、働くプロトコルがわかるためにプロトコル具体化ドキュメントの中に指定される他のブロックとどんな追加機能性にもブロックを合併できるようにこれらのアルゴリズムと機能にアクセスするための外部のインタフェースを完全に指定しなければなりません。

2.1.3.  Applicability Statement

2.1.3. 適用性証明

   One of the most important sections of a building block document will
   be the Applicability Statement.  The purpose of this section is to
   provide sufficient details about the intended use of the building
   block so that potential authors of protocol instantiations will be
   able to use the building block in conformance to its applicability
   constraints.  Also the Applicability Statement section will enable
   future building block document authors to quickly determine whether
   or not their particular need can be met with an existing building
   block.  For this to be possible the Applicability Statement MUST
   describe:

ブロックドキュメントの最も重要なセクションの1つはApplicability Statementになるでしょう。 このセクションの目的はプロトコル具体化の潜在的作者が順応に適用性規制にブロックを使用できるようにブロックの意図している使用に関する十分な詳細を明らかにすることです。 また、Applicability Statement部は、将来のブロックのドキュメント作者が、既存のブロックと共に彼らの特別の需要を満たすことができるかどうかとすぐに決心しているのを可能にするでしょう。 これが可能であるように、Applicability Statementは以下について説明しなければなりません。

   o  Intended scenarios for the building block's use.

o ブロックの使用のための意図しているシナリオ。

   o  The building block's known failure modes, why they occur, and how
      they can be detected.

o ブロックは故障モードと、それらが起こるなぜと、どうそれらを検出できるかを知っていました。

   o  A list of environmental considerations that includes but is not
      limited to whether the building block requires multi-source
      multicast or can be used in single-source only multicast networks,
      satellite networks, asymmetric networks, and wireless networks.

o ブロックがマルチソースマルチキャストを必要とするかどうかに制限しないか、または単独のソースだけマルチキャストネットワーク、衛星ネットワーク、非対称のネットワーク、およびワイヤレス・ネットワークに使用できるのを除いて、それが含む環境整備のリスト。

   o  A list of potential areas of conflict or incompatibilities with
      other building blocks.

o 他のブロックがある闘争か非互換性の潜在的領域のリスト。

2.1.4.  Packet-Header Fields

2.1.4. パケットのヘッダー分野

   If a building block implements a functionality whose realization
   requires an exchange of protocol messages between multiple agents,
   then the building block specification MUST state what kind of
   information is required and how the exchanged occurs.  This includes
   detailed description of the data format and various communication
   requirements, such as timing constraints, and network requirements
   (e.g., multicast vs. unicast delivery).

ブロックが実現が複数のエージェントの間のプロトコルメッセージの交換を必要とする機能性を実装するなら、ブロック仕様はどういう情報が必要であるか、そして、交換がどのように起こるかを述べなければなりません。 これはデータの形式と様々なコミュニケーション要件の詳述を含んでいます、タイミング規制や、ネットワーク要件(例えば、マルチキャスト対ユニキャスト配送)などのように。

Kermode & Vicisano           Informational                      [Page 4]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[4ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

   Typically the data format specification is at the level of "generic
   header fields" without a full bit-level header specification.
   Generic header fields MAY specify additional requirements, such as
   representation precision or preferred position within the packet
   header (this last constraint might be dictated by efficiency
   concerns).

通常、データの形式仕様が完全なビットレベルヘッダー仕様なしで「ジェネリックヘッダーフィールド」のレベルにあります。 ジェネリックヘッダーフィールドは追加要件を指定するかもしれません、パケットのヘッダーの中の表現精度や掲載指定位置のように(この最後の規制は効率関心によって書き取られるかもしれません)。

   A building block specification MAY specify "abstract messages" that
   carry particular information for exclusive use within the building
   block, however, more frequently, it will rely on the protocol
   messages specified in the protocol instantiation to carry the
   information it needs.

ブロック仕様はブロックの中で専用に特定の情報を運ぶ「抽象的なメッセージ」を指定するかもしれなくて、より頻繁に、しかしながら、それはそれが必要とする情報を運ぶためにプロトコル具体化で指定されたプロトコルメッセージを当てにするでしょう。

   The building block that provides Generic Router Assist functionality
   is an exception to the rule stated above.  For efficiency reasons,
   this building block may fully specify header fields and positions of
   these fields within the packet-header.

機能性をGeneric Router Assistに供給するブロックは上に述べられた規則への例外です。 効率理由として、このブロックはパケットのヘッダーの中でこれらの分野のヘッダーフィールドと位置を完全に指定するかもしれません。

2.1.5.  Requirements from other Building Blocks

2.1.5. 他のビルBlocksからの要件

   Each building block will specify a well defined piece of
   functionality that is common to multiple protocol instantiations.
   However, this does not mean that building block definitions will be
   generated in isolation from other building blocks.  For example, a
   congestion control building block will have specific requirements
   regarding loss notification from either a NACK or ACK building block.
   The "Requirements from other Building Blocks" section is included to
   capture these requirements so that the authors of related building
   blocks can determine what functionality they need to provide in order
   to use a particular building block.

各ブロックはよく定義された片の複数のプロトコル具体化に共通の機能性を指定するでしょう。 しかしながら、これは、ブロック定義が分離して他のブロックから生成されることを意味しません。 例えば、混雑制御建家には、ナックかACKブロックのどちらかからの損失通知に関する決められた一定の要求があるでしょう。 「他のビルBlocksからの要件」セクションは、関連するブロックの作者が、それらが、特定のブロックを使用するためにどんな機能性を提供する必要であるかを決心できるようにこれらの要件を得るために含まれています。

   Specifically, the "Requirements from other Building Blocks section"
   MUST provide a complete and exhaustive enumeration of all the
   requirements that will be made upon other building blocks in order
   for the building block being specified to operate in its intended
   manner.  Requirements that SHOULD be enumerated include but are not
   limited to:

明確に、「他のビルBlocks部分からの要件」は指定されるブロックにおいて、整然としている他のブロックで意図している方法で作動させられるすべての要件の完全で徹底的な列挙を提供しなければなりません。 以下に含んでいますが、SHOULDが数え上げられるという要件は限られていません。

   o  Event generation for and responses to other building blocks.

o 他のブロックへのイベント発生と応答。

   o  Message ordering relative to messages from other building blocks.

o 他のブロックからのメッセージに比例して注文されるメッセージ。

2.1.6.  Security Considerations

2.1.6. セキュリティ問題

   Protocol instantiations have the ultimate responsibility of
   addressing security requirements, in conformance to RFC 2357.
   Security considerations may not be applicable to generic building
   blocks other than a specific "security" building block.  Some

プロトコル具体化には、セキュリティが順応で要件であるとRFC2357に扱う最終責任があります。 セキュリティ問題は特定の「セキュリティ」ブロック以外のジェネリックブロックに適切でないかもしれません。 いくつか

Kermode & Vicisano           Informational                      [Page 5]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[5ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

   building blocks, however, may raise special security issues, either
   due to the nature of communication required by the building block or
   due to the intended usage of the building block in a protocol
   instantiation.  When special security issues are present in a
   building block, its specification MUST address them explicitly.

ブロックによって必要とされたコミュニケーションの本質のためかブロックの意図している使用法のため、しかしながら、ブロックはプロトコル具体化で特別担保問題を提起するかもしれません。 特別担保問題がブロックで存在しているとき、仕様は明らかにそれらを扱わなければなりません。

   An example of this might be a building block that involves exchange
   of data that is particularly sensitive to security attacks.

この例は特にセキュリティー攻撃に機密のデータの交換にかかわるブロックであるかもしれません。

2.1.7.  Codepoint Considerations

2.1.7. Codepoint問題

   Certain Building Blocks will specify general frameworks for
   describing functionality while leaving the detail open for
   implementation specific algorithms.  One example of such a building
   block is the Forward Error Correction (FEC) building block which
   describes the framing aspects for FEC message fragments but not the
   algorithms used to generate the redundant data.

あるビルBlocksは詳細を実装の特定のアルゴリズムにおいて開いた状態でおいている間、機能性について説明するのに一般的なフレームワークを指定するでしょう。そのようなブロックに関する1つの例がアルゴリズムではなく、冗長データを生成するのに使用されるFECメッセージ断片のために縁どり局面について説明するForward Error Correction(FEC)ブロックです。

2.1.8.  Summary Checklist

2.1.8. 概要チェックリスト

   Rationale
      _  Provide justification for the building block's existence
      _  Provide rationale for the building block's granularity

ブロックの粒状のためのブロックの存在_Provide原理のための原理_Provide正当化

   Functionality
      _  Functionality contained within the building block
      _  External interfaces

ブロック_Externalインタフェースの中に含まれた機能性_Functionality

   Applicability Statement
      _  Intended usage
      _  Failure modes (including means of detection if known)
      _  Environmental considerations
      _  Incompatibilities / Conflicts with other building blocks

他のブロックとの適用性Statement_Intended用法_Failureモード(知られているなら検出の手段を含んでいて)_Environmental問題_Incompatibilities/闘争

   Packet Header Fields
      _  Specification of logical packet-header fields (*)
      _  Abstract messages specifications (*)

論理的なパケットのヘッダーのパケットHeaderフィールズ_Specificationは(*)_の抽象的なメッセージ仕様をさばきます。(*)

   Requirements from other building blocks;
      _  Mandatory needs from other building blocks

他のブロックからの要件。 _ 他のブロックからの義務的な必要性

   Security Considerations
      _  Specify as much as possible (with respect to procedures,
         algorithms and data encoding), without affecting the general
         applicability of the building block.

セキュリティConsiderations_Specify、できるだけ(手順、アルゴリズム、およびzデータの符号化に関して)、ブロックの一般的な適用性に影響しないで。

   (*) May not be applicable to some building blocks.

(*)はいくつかのブロックに適切でないかもしれません。

Kermode & Vicisano           Informational                      [Page 6]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[6ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

2.2.  Protocol Instantiation Document Guidelines

2.2. プロトコル具体化ドキュメントガイドライン

   Protocol Instantiation documents have one purpose: to specify how one
   can combine multiple building blocks to construct a new fully
   specified working protocol.  To that end RMT Protocol Instantiation
   documents MUST contain the following four sections.

プロトコルInstantiationドキュメントには、1つの目的があります: 1つが新しい完全に指定された働くプロトコルを構成するためにどう複数のブロックを合併できるかを指定するために。 そのためにRMTプロトコルInstantiationドキュメントは以下の4つのセクションを含まなければなりません。

2.2.1.  Applicability Statement

2.2.1. 適用性証明

   The applicability statement's purpose is to frame the design space in
   which the fully realized protocol will operate and to thereby enable
   subsequent would-be RMT protocol designers to determine whether or
   not an existing protocol already meets their needs.  For this to be
   possible the applicability statement MUST adhere to the following
   guidelines:

適用性証明の目的は、完全に実感されたプロトコルが作動するデザインスペースを縁どって、その結果、その後のひとりよがりのRMTプロトコルデザイナーが、既存のプロトコルが既に彼らの需要を満たすかどうかと決心しているのを可能にすることです。 これが可能であるように、適用性証明は以下のガイドラインを固く守らなければなりません:

   1) The target application space for which the protocol is intended
      MUST be clearly identified.  For example; is the protocol to be
      used for real-time delivery, or non-real time file transfer?

1) 明確に、プロトコルが意図する目標アプリケーションスペースを特定しなければなりません。 例えば。 リアルタイムの配送、または非リアルタイムのファイル転送にプロトコルは使用されることになっていますか?

   2) The target scale, in terms of maximum number of receivers per
      session, for which the protocol is intended MUST be clearly
      specified.  If the protocol has an architectural limitation
      resulting from the optimization of another feature, such as per
      packet acknowledgment, this SHOULD be included.

2) 最大数の受信機に関する1セッションあたりの目標スケールに、明確に指定しなければなりません。(プロトコルはセッションのために意図します)。 プロトコルに最適化から生じる建築制限があるなら、パケット承認などの別の特徴、このSHOULDでは、含められてください。

   3) The applicability statement MUST identify the intended
      environments for the protocol's use AND list any environments in
      which the protocol should not be used.  Example environments that
      should be considered include asymmetric networks, wireless
      networks, and satellite networks.

3) 適用性証明は、プロトコルの使用のために意図している環境を特定して、プロトコルが使用されるべきでないどんな環境も記載しなければなりません。 考えられるべきである例の環境は非対称のネットワーク、ワイヤレス・ネットワーク、および衛星ネットワークを含んでいます。

   4) Finally, all protocols have inherent weaknesses that stem from the
      optimization for a specific feature.  These weaknesses can
      manifest in spectacular failure modes when certain conditions
      occur.  When known, these conditions and the nature of how the
      subsequent failure can be detected MUST be included in the
      applicability statement.

4) 最終的に、すべてのプロトコルには、特定の特徴のための最適化による固有の弱点があります。 ある状態が現れると、これらの弱点は壮観な失敗でモードを表すことができます。 知られていると、適用性証明にどうその後の失敗を検出できるかに関するこれらの状態と自然を含まなければなりません。

2.2.2.  Architecture Definition

2.2.2. アーキテクチャ定義

   Protocol Instantiations define how to combine one or more building
   blocks to create a working protocol.  The Architecture Definition
   lays out the framework for how this take place.  For this framework
   to be complete, it MUST contain the following information:

プロトコルInstantiationsは働くプロトコルを作成するために1つ以上のブロックを合併する方法を定義します。 Architecture Definitionは、これがどう行われるかためにフレームワークを広げます。 このフレームワークが完全であるように、以下の情報を含まなければなりません:

Kermode & Vicisano           Informational                      [Page 7]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[7ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

   1) An overview of the major facets of the protocol's operation.

1) プロトコルの操作の主要な一面の概要。

   2) Full enumeration and overview of which Building Blocks are used
      with explicit references to their documents that define them.

2) ビルBlocksがそれらを定義するそれらのドキュメントの明白な参照で使用される完全な列挙と概要。

   3) An overview of how the aforementioned building blocks are to be
      joined.

3) 前述のブロックがどう加わられることになっているかに関する概要。

   4) A discussion of the design tradeoffs made in the selection of the
      chosen architecture.

4) デザイン見返りの議論は選ぶことの選択でアーキテクチャを作りました。

2.2.3.  Conformance Statement

2.2.3. 順応声明

   The conformance statement below MUST be included and adhered to:

以下での順応声明を含まれていて、固く守らなければなりません:

      "This Protocol Instantiation document, in conjunction with the
      following Building Block documents identified in [list of relevant
      building block references] completely specifies a working reliable
      multicast transport protocol that conforms to the requirements
      described in RFC 2357."

「InstantiationがBlockドキュメントが特定した以下のビルに関連して記録するこのプロトコルは[関連ブロック参照のリスト]でRFC2357で説明された要件に従う働く信頼できるマルチキャストトランスポート・プロトコルを完全に指定します。」

   Protocol instantiation document authors are specifically reminded
   that RFC 2357 requires that any RMT protocol put forward for
   standardization with the IETF is required to protect the network in
   as much as is possible.  This does not mean that RMT protocols will
   be held to a higher standard than unicast transport protocols, merely
   that they should be designed to perform at least as well as unicast
   transport protocols when it comes to the possibility of protocol
   failure.

プロトコル具体化ドキュメント作者はRFC2357が、IETFとの標準化がネットワークを保護するのに必要であるので提唱されたどんなRMTプロトコルも可能であることを必要とするのを明確に思い出させられています。 これは、RMTプロトコルがユニキャストトランスポート・プロトコルより高い規格として保持されて、単に、それらがプロトコル失敗の可能性のこととなると、少なくともユニキャストトランスポート・プロトコルと同様に働くように設計されるべきであることを意味しません。

2.2.4.  Functionality Definition

2.2.4. 機能性定義

   Building Block documents will be incomplete in that they will specify
   an abstract framework of a building block's functionality.  Complete
   algorithmic specifications for each building block along with any
   additional functionality MUST be provided within the Protocol
   Instantiation document's functionality definition.  Furthermore, this
   description must show that each building block is used in accordance
   with its respective applicability statement.  Finally the
   functionality description must provide a description of the abstract
   programming interface for interfacing the protocol instantiation with
   the applications that will use it.

ブロックの機能性の抽象的なフレームワークを指定するので、ビルBlockドキュメントは不完全になるでしょう。 プロトコルInstantiationドキュメントの機能性定義の中でどんな追加機能性に伴う各ブロックのための完全なアルゴリズムの仕様も提供しなければなりません。 その上、この記述は、それぞれの適用性証明によると、各ブロックが使用されるのを示さなければなりません。 最終的に機能性記述はそれを使用するアプリケーションにプロトコル具体化を接続するのに抽象的なプログラミングインターフェースの記述を提供しなければなりません。

Kermode & Vicisano           Informational                      [Page 8]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[8ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

2.2.5.  Packet Formats

2.2.5. パケット・フォーマット

   Once all the functionality has been fully defined, the Protocol
   Instantiation document must define the packet formats that will be
   used by the protocol.  Each message part and the rules for their
   concatenation MUST be specified for both IPv4 [RFC791] and IPv6
   [RFC2460].  Support for IPSEC [RFC2401] MUST be explicitly shown.

すべての機能性がいったん完全に定義されると、プロトコルInstantiationドキュメントはプロトコルによって使用されるパケット・フォーマットを定義しなければなりません。 IPv4[RFC791]とIPv6[RFC2460]の両方にそれぞれのメッセージ部分と彼らの連結のための規則を指定しなければなりません。 明らかにIPSEC[RFC2401]のサポートを示さなければなりません。

   In recognition of the fact that protocols will evolve and that IP
   protocol numbers are a scarce resource, protocol instantiations MUST
   initially define packet formats for use over UDP [RFC768].  Whether
   or not a particular Reliable Multicast Transport protocol
   instantiation becomes sufficiently popular to warrant its own
   protocol number is an issue which will be deferred until such time
   that the protocol has been sufficiently widely deployed and
   understood.

プロトコルが発展して、IPプロトコル番号が不十分なリソースであるという事実の認識では、プロトコル具体化は初めは、UDP[RFC768]の上の使用のためにパケット・フォーマットを定義しなければなりません。 特定のReliable Multicast Transportプロトコル具体化がそれ自身のプロトコル番号を保証できるくらいポピュラーになるかどうかが、プロトコルが十分広く配布されて、理解されているくらいの時間まで延期される問題です。

2.2.6.  Summary Checklist

2.2.6. 概要チェックリスト

   Applicability Statement
      _  Target application space
      _  Target scale
      _  Intended environment
      _  Weaknesses and known failure modes

適用性Statement_Targetアプリケーションスペース_Targetスケール_Intended環境_Weaknessesと知られている故障モード

   Architecture Definition
      _  Operational overview
      _  Building blocks used
      _  Details on how building blocks are joined

アーキテクチャDefinition_Operational概要_ビルブロックは_ブロックがどう加わられるかのDetailsを使用しました。

   Conformance Statement
      _  Inclusion of mandatory paragraph

義務的なパラグラフの順応Statement_Inclusion

   Functionality Definition
      _  Building block algorithmic specification
      _  Addition functionality specification
      _  Compliance with building block applicability statements
      _  Abstract program interface

ブロック適用性証明_要約プログラムインタフェースがある機能性Definition_ビルブロックアルゴリズムの仕様_Additionの機能性仕様_Compliance

   Packet Formats
      _  IPv4 message parts
      _  IPv6 message parts
      _  IPSEC support
      _  Message ordering

パケットFormats_IPv4メッセージ部品_IPv6メッセージ部品_IPSECサポート_Message注文

3.  IANA Considerations

3. IANA問題

   There are no explicit IANA considerations for this document.

このドキュメントのためのどんな明白なIANA問題もありません。

Kermode & Vicisano           Informational                      [Page 9]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[9ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

4.  Acknowledgements

4. 承認

   This document represents an overview of the mandatory elements
   required for the specification of building blocks and protocol
   instantiations within the RMT working group.  The requirements
   presented are a summarization of discussions held between the RMT
   Working Group chairs and the participants in the IRTF Reliable
   Multicast Research Group.  Although the name of these participants
   are too numerous to list here, the Working Group chairs would like to
   thank everyone who has participated in these discussions for their
   contributions.

このドキュメントはブロックとプロトコル具体化の仕様にRMTワーキンググループの中で必要であった義務的な要素の概要を表します。 提示された要件はRMT作業部会いすとIRTF Reliable Multicast Research Groupの関係者で行われる議論の総括です。 これらの関係者の名前はここに記載できないくらい非常に多いのですが、作業部会いすは彼らの貢献のためにこれらの議論に参加した皆に感謝したがっています。

5.  References

5. 参照

   [RFC768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
             August 1980.

[RFC768] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。

   [RFC791]  Postel, J., "Darpa Internet Protocol Specification", STD 5,
             RFC 791, September 1981.

[RFC791] ポステル、J.、「Darpaインターネットプロトコル仕様」、STD5、RFC791、1981年9月。

   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
             (IPv6) Specification", RFC2460, December 1998.

[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日

   [RFC2887] Handley, M., Floyd, S., Whetten, B., Kermode, R., Vicisano,
             L. and M. Luby, "The Reliable Multicast Design Space for
             Bulk Data Transfer", RFC 2887, August 2000.

[RFC2887] ハンドレーとM.とフロイドとS.とWhettenとB.とカーモードとR.とVicisanoとL.とM.Luby、「バルク・データ転送のための信頼できるマルチキャストデザインスペース」、RFC2887、2000年8月。

   [RFC3048] Whetten, B., Vicisano, L., Kermode, R., Handley, M., Floyd,
             S. and M. Luby, "Reliable Multicast Transport Building
             Blocks for One-to-Many Bulk-Data Transfer", RFC 3048,
             January 2001.

[RFC3048] WhettenとB.とVicisanoとL.とカーモードとR.とハンドレーとM.とフロイドとS.とM.Luby、「多くへの1のための信頼できるマルチキャスト輸送ブロックバルク・データ転送」、RFC3048、2001年1月。

Kermode & Vicisano           Informational                     [Page 10]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[10ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

6.  Authors' Addresses

6. 作者のアドレス

   Roger Kermode
   Motorola Australian Research Centre
   Locked Bag 5028
   Botany  NSW  1455,
   Australia.

ロジャーカーモードモトローラのオーストラリアの研究センター鍵をかけた袋5028植物学NSW1455、オーストラリア。

   EMail: Roger.Kermode@motorola.com

メール: Roger.Kermode@motorola.com

   Lorenzo Vicisano
   Cisco Systems,
   170 West Tasman Dr.
   San Jose, CA 95134, USA

サンノゼ、170の西タスマン博士カリフォルニア 95134、ロレンツォVicisanoシスコシステムズ(米国)

   EMail: lorenzo@cisco.com

メール: lorenzo@cisco.com

Kermode & Vicisano           Informational                     [Page 11]

RFC 3269                 RMT Author Guidelines                April 2002

カーモードとVicisanoの情報[11ページ]のRFC3269RMTは2002年4月にガイドラインを書きます。

7.  Full Copyright Statement

7. 完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(2002)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Kermode & Vicisano           Informational                     [Page 12]

カーモードとVicisano情報です。[12ページ]