RFC1264 日本語訳
1264 Internet Engineering Task Force Internet Routing ProtocolStandardization Criteria. R.M. Hinden. October 1991. (Format: TXT=17016 bytes) (Obsoleted by RFC4794) (Status: HISTORIC)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Hinden
Request for Comments: 1264 BBN
October 1991
Hindenがコメントのために要求するワーキンググループR.をネットワークでつないでください: 1264 BBN1991年10月
Internet Engineering Task Force
Internet Routing Protocol Standardization Criteria
インターネット・エンジニアリング・タスク・フォースインターネットルーティング・プロトコル標準化評価基準
Status of this Memo
このMemoの状態
This informational RFC presents procedures for creating and documenting Internet standards on routing protocols. These procedures have been established by the Internet Activities Board (IAB) in consultation with the Internet Engineering Steering Group (IESG). Distribution of this memo is unlimited.
この情報のRFCはルーティング・プロトコルのインターネット標準を作成して、記録するための手順を提示します。 これらの手順はインターネットActivities Board(IAB)によってインターネットEngineering Steering Group(IESG)との相談に確立されました。 このメモの分配は無制限です。
1.0 Introduction
1.0 序論
The IAB and the IESG have evolved a three-stage Internet standardization process. This process is explained in the "IAB Official Protocol Standards", published as an RFC several times a year (the current version is RFC 1250).
IABとIESGは3ステージのインターネット標準化過程を発展しました。 このプロセスは1年間RFCとして何度か発行された「IABの公式のプロトコル標準」で説明されます(最新版はRFC1250です)。
In brief, the three stages of Internet standardization are Proposed (which requires a well written, openly reviewed specification), Draft (which requires Proposed status, multiple implementations and some operational experience), and full Internet Standard (which requires Draft status and more extensive operational experience). The IAB and IESG are currently developing a more detailed explanation of the process, which will be available as an RFC.
要するに、インターネット標準化の3つのステージが、Proposed(上手に書かれて、オープンに見直された仕様を必要とする)と、Draft(Proposed状態、複数の実装、および何らかの運用経験を必要とする)と、完全なインターネットStandard(Draft状態と、より大規模な運用経験を必要とする)です。 IABとIESGは現在、プロセスの、より詳細な説明を開発しています。(プロセスはRFCとして利用可能になるでしょう)。
The purpose of this document is to provide more specific guidance for the advancement of routing protocols. All levels of the standardization process are covered.
このドキュメントの目的はルーティング・プロトコルの振興のための、より特定の指導を提供することです。 標準化過程のすべてのレベルがカバーされています。
There are currently two types of routing protocol in the Internet. These are Interior Gateway Protocols (IGP) sometimes called Intra- Domain Routing Protocols and Exterior Gateway Protocols (EGP) sometimes called Inter-Domain Routing Protocols. This document uses the terms IGP and EGP.
ルーティング・プロトコルの2つのタイプが現在、インターネットにあります。 これらは、時々Intraドメインルート設定プロトコルと呼ばれるInteriorゲートウェイプロトコル(IGP)と時々Inter-ドメインルート設定プロトコルと呼ばれるExteriorゲートウェイプロトコル(EGP)です。 このドキュメントは用語のIGPとEGPを使用します。
2.0 Motivation
2.0 動機
The motivation for these requirements two-fold. The first is to reduce the risk that there will be serious technical problems with a routing protocol after it reaches Draft Standard. The second is to insure that the new routing protocol will support the continued growth of the Internet.
これらの要件に関する動機、二面です。 1番目はある危険を減少させるために、それの後のルーティング・プロトコルの重大な技術的問題がDraft Standardに達するということです。 2番目は新しいルーティング・プロトコルがインターネットの継続成長をサポートするのを保障することです。
Hinden [Page 1] RFC 1264 Routing Protocol Criteria October 1991
プロトコル評価基準1991年10月に掘るHinden[1ページ]RFC1264
Routing protocols are complex, widely distributed, real-time algorithms. They are difficult to implement and to test. Even though a protocol may work in one environment with one implementation, that does not ensure that it will work in a different environment with multiple vendors. A routing protocol may work well within a range of topologies and number of networks and routers, but may fail when an unforeseen limit is reached. The result is that even with considerable operational experience, it is hard to guarantee that the protocol is mature enough for widespread deployment.
ルーティング・プロトコルは複雑で、広く分配されて、リアルタイムのアルゴリズムです。それらは実装して、テストするのは難しいです。 プロトコルは1つの実装で1つの環境で働くかもしれませんが、それは、それが複数のベンダーと共に異なった環境で働くのを確実にしません。 ルーティング・プロトコルは、さまざまなtopologiesと数のネットワークとルータの中でうまくいきますが、予期しない限界に達しているとき、失敗するかもしれません。 結果はかなりの運用経験があっても、広範囲の展開において、プロトコルが十分熟しているのを保証しにくいということです。
The Internet is currently growing at an exponential rate. Routing protocols and the management of internet addressing are key elements in the successful operation the Internet. It is important that new routing protocols be designed to support this rapid growth.
インターネットは現在、ネズミ算式の増加率で発展しています。 インターネットアドレシングのプロトコルと管理を発送して、うまくいっている操作における主要な要素はインターネットですか? 新しいルーティング・プロトコルがこの急速な成長をサポートするように設計されているのは、重要です。
3.0 General Requirements
3.0 一般要件
1) Documents specifying the Protocol and its Usage. This may be
one or more documents. The specifications for the routing
protocol must be well written such that independent,
interoperable implementations can be developed solely based on
the specification. For example, it should be possible to
develop an interoperable implementation without consulting the
original developers of the routing protocol.
1) プロトコルを指定するドキュメントとそのUsage。 これは1通以上のドキュメントであるかもしれません。 唯一仕様に基づいて独立していて、共同利用できる実装を開発できるように上手にルーティング・プロトコルのための仕様を書かなければなりません。 例えば、ルーティング・プロトコルのオリジナルの開発者に相談しないで共同利用できる実装を開発するのは可能であるべきです。
2) A Management Information Base (MIB) must be written for the
protocol. Routing protocols, like all other internet protocols,
need a MIB defined so they can be remotely managed.
2) プロトコルのために、Management Information基地(MIB)を書かなければなりません。 他のすべてのインターネットプロトコルのように、ルーティング・プロトコルは、それらに離れて対処できるようにMIBを定義する必要があります。
3) A security architecture of the protocol must be defined. The
security architecture must include mechanisms for authenticating
routing messages and may include other forms of protection.
3) プロトコルのセキュリティー体系を定義しなければなりません。 セキュリティー体系は、ルーティング・メッセージを認証するためのメカニズムを含まなければならなくて、他の形式の保護を含むかもしれません。
4) Generally, a number of interoperable implementations must
exist. At least two must be written independently.
4) 一般に、多くの共同利用できる実装が存在しなければなりません。 独自に少なくとも2を書かなければなりません。
5) There must be evidence that all features of the protocol have
been tested, running between at least two implementations. This
must include that all of the security features have been
demonstrated to operate, and that the mechanisms defined in the
protocol actually provide the intended protection.
5) 少なくとも2つの実装の間で稼働していて、プロトコルのすべての特徴がテストされたという証拠があるに違いありません。 セキュリティ機能のすべてが操作するために示されて、メカニズムが実際にプロトコルで定義したこの必須インクルードは意図している保護を提供します。
6) There must be operational experience with the routing
protocol. The level of operational experience required is
dependent on which level of standardization is requested. All
significant features of the protocol must be exercised. In the
case of an Interior Gateway Protocol (IGP), both interior and
6) ルーティング・プロトコルには運用経験があるに違いありません。 必要である運用経験のレベルはどのレベルの標準化が要求されているかに依存しています。 プロトコルに関するすべての著しい特徴を運動させなければなりません。 そしてInteriorゲートウェイプロトコル(IGP)の場合でともに内部。
Hinden [Page 2] RFC 1264 Routing Protocol Criteria October 1991
プロトコル評価基準1991年10月に掘るHinden[2ページ]RFC1264
exterior routes must be carried (unless another mechanism is
provided for the exterior routes). In the case of a Exterior
Gateway Protocol (EGP), it must carry the full complement of
exterior routes.
外のルートを運ばなければなりません(別のメカニズムが外のルートに提供されない場合)。 Exteriorゲートウェイプロトコル(EGP)の場合では、それは外のルートの総定員を運ばなければなりません。
7) Two reports must be submitted to the IESG via the Routing Area
Director. The first report must document how requirements 1)
through 6) of this document have been satisfied. It must
include:
7) ルート設定Areaディレクターを通して2つのレポートをIESGに提出しなければなりません。 最初のレポートはどうこの6通のドキュメント)を通した要件1)を満たしてあるかを記録しなければなりません。 それは以下を含まなければなりません。
- Implementation experience.
- 実装経験。
- Reference to the MIB for the protocol.
- MIBのプロトコルの参照。
- Description of the authentication mechanisms in the protocol.
- プロトコルにおける、認証機構の記述。
- List of implementations including origin of code.
- コードの発生源を含む実装のリスト。
- Test scenarios and test results showing that all features of the
protocols have been tested.
- プロトコルのすべての特徴がテストされたのを示すシナリオと試験の成績をテストしてください。
- Description of operational experience. This must include
topology, environment, time and duration, implementations
involved, and overall results and conclusions gained from the
operational experience.
- 運用経験の記述。 これは運用経験から獲得されたトポロジー、環境、時間、持続時間、かかわる実装、総合的な結果、および結論を含まなければなりません。
The second report must summarize the key features of the protocol and analyze how the protocol will perform and scale in the Internet. The intent of this requirement is to understand the boundary conditions of the routing protocol. The new routing protocol must be compared with the existing routing protocols (e.g., RIP, EGP, etc.) as appropriate. The report should answer several questions:
2番目のレポートは、プロトコルに関する重要な特色をまとめて、プロトコルがどうインターネットを実行して、計量するかを分析しなければなりません。 この要件の意図はルーティング・プロトコルの境界状態を理解することです。 既存のルーティング・プロトコル(例えば、RIP、EGPなど)が適切な状態で新しいルーティング・プロトコルを比較しなければなりません。 レポートはいくつかの質問に答えるべきです:
- What are the key features and algorithms of the protocol?
- プロトコルの重要な特色とアルゴリズムは何ですか?
- How much link bandwidth, router memory and router CPU cycles
does the protocol consume under normal conditions?
- プロトコルは正常な状況ではどのくらいのリンク帯域幅、ルータメモリ、およびルータCPUサイクルを費やしますか?
- For these metrics, how does the usage scale as the routing
environment grows? This should include topologies at least an
order of magnitude larger than the current environment.
- これらの測定基準のために、ルーティング環境が成長するとき、用法はどのように比例しますか? これは現在の環境より少なくとも1桁大きいtopologiesを含むべきです。
- What are the limits of the protocol for these metrics? (I.e.,
when will the routing protocol break?)
- これらの測定基準のためのプロトコルの限界はどのくらいですか? (ルーティング・プロトコルはいつすなわち、壊れるでしょうか?)
- For what environments is the protocol well suited, and for what
is it not suitable?
- プロトコルはどんな環境によく合っているか、そして、それは何に適していませんか?
Hinden [Page 3] RFC 1264 Routing Protocol Criteria October 1991
プロトコル評価基準1991年10月に掘るHinden[3ページ]RFC1264
The IESG will forward to the IAB its recommendation for advancement of the new routing protocol based on its evaluation of protocol specifications and these reports.
IESGはプロトコル仕様とこれらのレポートの評価に基づく新しいルーティング・プロトコルの振興のための推薦をIABに送るでしょう。
4.0 Requirements for Proposed Standard
4.0 提案された標準のための要件
1) Documents specifying the Protocol and its Usage. The
specification for the routing protocol must be well written such
that independent, interoperable implementations can be developed
solely based on the specification. For example, it should be
possible to develop an interoperable implementation without
consulting the original developers of the routing protocol.
1) プロトコルを指定するドキュメントとそのUsage。 唯一仕様に基づいて独立していて、共同利用できる実装を開発できるように上手にルーティング・プロトコルのための仕様を書かなければなりません。 例えば、ルーティング・プロトコルのオリジナルの開発者に相談しないで共同利用できる実装を開発するのは可能であるべきです。
2) A Management Information Base (MIB) must be written for the
protocol. The MIB does not need to submitted for Proposed
Standard at the same time as the routing protocol, but must be
at least an Internet Draft.
2) プロトコルのために、Management Information基地(MIB)を書かなければなりません。 ルーティング・プロトコルと同時にProposed Standardのために提出していた状態でそうする必要はありませんが、MIBは少なくともインターネットDraftであるに違いありません。
3) The security architecture of the protocol must be set forth
explicitly. The security architecture must include mechanisms for
authenticating routing messages and may include other forms of
protection.
3) 明らかにプロトコルのセキュリティー体系について詳しく説明しなければなりません。 セキュリティー体系は、ルーティング・メッセージを認証するためのメカニズムを含まなければならなくて、他の形式の保護を含むかもしれません。
4) One or more implementations must exist.
4) 1つ以上の実装が存在しなければなりません。
5) There must be evidence that the major features of the protocol
have been tested.
5) プロトコルの主要な特徴がテストされたという証拠があるに違いありません。
6) No operational experience is required for the routing protocol
at this stage in the standardization process.
6) 運用経験は全く現在のところ、ルーティング・プロトコルに標準化過程で必要ではありません。
7) A report must be submitted to the IESG via the Routing Area
Director. The report must document the key features of the
protocol and describe how requirements 1) through 5) have been
satisfied. It must include:
7) ルート設定Areaディレクターを通してIESGにレポートを提出しなければなりません。 レポートは、プロトコルに関する重要な特色を記録して、どう5)を通した要件1)を満たしてあるかを説明しなければなりません。 それは以下を含まなければなりません。
- What are the key features and algorithms of the protocol?
- プロトコルの重要な特色とアルゴリズムは何ですか?
- For what environments is the protocol well suited, and for what
is it not suitable?
- プロトコルはどんな環境によく合っているか、そして、それは何に適していませんか?
- Description of the authentication mechanisms in the protocol.
- プロトコルにおける、認証機構の記述。
- Reference to the MIB for the protocol.
- MIBのプロトコルの参照。
- Implementation experience.
- 実装経験。
- List of implementations including origin of code.
- コードの発生源を含む実装のリスト。
Hinden [Page 4] RFC 1264 Routing Protocol Criteria October 1991
プロトコル評価基準1991年10月に掘るHinden[4ページ]RFC1264
- Test scenarios and test results showing that the major features
of the protocols have been tested.
- プロトコルの主要な特徴がテストされたのを示すシナリオと試験の成績をテストしてください。
The IESG will forward to the IAB its recommendation for advancement of the new routing protocol to Proposed Standard based on its evaluation of protocol specifications and this reports.
IESGはプロトコル仕様の評価に基づくProposed Standardへの新しいルーティング・プロトコルの振興のための推薦をIABに送るでしょう、そして、これは報告します。
5.0 Requirements for Draft Standard
5.0 草稿規格のための要件
1) Revisions to the Protocol and Usage documents showing changes and
clarifications made based on experience gained in the time
between when the protocol was made a Proposed Standard and it
being submitted for Draft Standard. The revised documents should
include a section summarizing the changes made.
1) 変化と明確化がプロトコルが作られた時の間の時間行われた経験に基づいてProposed StandardとそれをしたDraft Standardのために提出されるプロトコルとUsageドキュメント表示への改正。 改訂されたドキュメントは行われた変更をまとめるセクションを含んでいるはずです。
2) The Management Information Base (MIB) must be at the Proposed
Standard level of standardization.
2) Management Information基地(MIB)が標準化のProposed Standardレベルにあるに違いありません。
3) Two or more interoperable implementations must exist. At least
two must be written independently.
3) 2つ以上の共同利用できる実装が存在しなければなりません。 独自に少なくとも2を書かなければなりません。
4) There must be evidence that all features of the protocol have
been tested, running between at least two implementations. This
must include that all of the security features have been
demonstrated to operate, and that the mechanisms defined in the
protocol actually provide the intended protection.
4) 少なくとも2つの実装の間で稼働していて、プロトコルのすべての特徴がテストされたという証拠があるに違いありません。 セキュリティ機能のすべてが操作するために示されて、メカニズムが実際にプロトコルで定義したこの必須インクルードは意図している保護を提供します。
5) There must be significant operational experience. This must
include running in a moderate number routers configured in a
moderately complex topology, and must be part of the operational
Internet. All significant features of the protocol must be
exercised. In the case of an Interior Gateway Protocol (IGP),
both interior and exterior routes must be carried (unless another
mechanism is provided for the exterior routes). In the case of
a Exterior Gateway Protocol (EGP), it must carry the full
complement of exterior routes.
5) 重要な運用経験があるに違いありません。 これは、ルータが適度に複雑なトポロジーで構成した適度の数へ駆け込むのを含まなければならなくて、操作上のインターネットの一部であるに違いありません。 プロトコルに関するすべての著しい特徴を運動させなければなりません。 Interiorゲートウェイプロトコル(IGP)の場合では、内部の、そして、外の両方のルートを運ばなければなりません(別のメカニズムが外のルートに提供されない場合)。 Exteriorゲートウェイプロトコル(EGP)の場合では、それは外のルートの総定員を運ばなければなりません。
6) Two reports must be submitted to the IESG via the Routing Area
Director. The first report must document how requirements 1)
through 5) of this document have been satisfied. It must include:
6) ルート設定Areaディレクターを通して2つのレポートをIESGに提出しなければなりません。 最初のレポートはどうこの5通のドキュメント)を通した要件1)を満たしてあるかを記録しなければなりません。 それは以下を含まなければなりません。
- Reference to the MIB for the protocol.
- MIBのプロトコルの参照。
- Description of the authentication mechanisms in the protocol.
- プロトコルにおける、認証機構の記述。
- List of implementations including origin of code.
- コードの発生源を含む実装のリスト。
- Implementation experience.
- 実装経験。
Hinden [Page 5] RFC 1264 Routing Protocol Criteria October 1991
プロトコル評価基準1991年10月に掘るHinden[5ページ]RFC1264
- Test scenarios and test results showing that all features of the
protocols have been tested.
- プロトコルのすべての特徴がテストされたのを示すシナリオと試験の成績をテストしてください。
- Description of operational experience. This must include
topology, environment, time and duration, implementations
involved, and overall results and conclusions gained from the
operational experience.
- 運用経験の記述。 これは運用経験から獲得されたトポロジー、環境、時間、持続時間、かかわる実装、総合的な結果、および結論を含まなければなりません。
The second report must summarize the key features of the protocol and analyze how the protocol will perform and scale in the Internet. The intent of this requirement is to understand the boundary conditions of the routing protocol. The new routing protocol must be compared with the existing routing protocols (e.g., RIP, EGP, etc.) as appropriate. The report should answer several questions:
2番目のレポートは、プロトコルに関する重要な特色をまとめて、プロトコルがどうインターネットを実行して、計量するかを分析しなければなりません。 この要件の意図はルーティング・プロトコルの境界状態を理解することです。 既存のルーティング・プロトコル(例えば、RIP、EGPなど)が適切な状態で新しいルーティング・プロトコルを比較しなければなりません。 レポートはいくつかの質問に答えるべきです:
- What are the key features and algorithms of the protocol?
- プロトコルの重要な特色とアルゴリズムは何ですか?
- How much link bandwidth, router memory and router CPU cycles
does the protocol consume under normal conditions?
- プロトコルは正常な状況ではどのくらいのリンク帯域幅、ルータメモリ、およびルータCPUサイクルを費やしますか?
- For these metrics, how does the usage scale as the routing
environment grows? This should include topologies at least an
order of magnitude larger than the current environment.
- これらの測定基準のために、ルーティング環境が成長するとき、用法はどのように比例しますか? これは現在の環境より少なくとも1桁大きいtopologiesを含むべきです。
- What are the limits of the protocol for these metrics? (I.e.,
when will the routing protocol break?)
- これらの測定基準のためのプロトコルの限界はどのくらいですか? (ルーティング・プロトコルはいつすなわち、壊れるでしょうか?)
- For what environments is the protocol well suited, and for what
is it not suitable?
- プロトコルはどんな環境によく合っているか、そして、それは何に適していませんか?
The IESG will forward to the IAB its recommendation for advancement of the new routing protocol to Draft Standard based on its evaluation of protocol specifications and these reports.
IESGはプロトコル仕様とこれらのレポートの評価に基づくDraft Standardへの新しいルーティング・プロトコルの振興のための推薦をIABに送るでしょう。
6.0 Requirements for Standard
6.0 規格のための要件
1) Revisions to the Protocol and Usage documents showing changes and
clarifications made based on experience gained in the time between
when the protocol was made a Draft Standard and it being submitted
for Standard. The changes should be to clarify the protocol
or provide guidance in its implementation. No significant changes
can be made to the protocol at this stage. The revised documents
should include a section summarizing the changes made.
1) 変化と明確化がプロトコルが作られた時の間の時間行われた経験に基づいてDraft StandardとそれをしたStandardのために提出されるプロトコルとUsageドキュメント表示への改正。 変化は、プロトコルをはっきりさせるはずであるか、または指導を実装に提供することになっているはずです。 現在のところ、著しい変化を全くプロトコルにすることができません。 改訂されたドキュメントは行われた変更をまとめるセクションを含んでいるはずです。
2) The Management Information Base (MIB) must be submitted for
Standard at the same time as the routing protocol.
2) ルーティング・プロトコルと同時にStandardのために、Management Information基地(MIB)を提出しなければなりません。
3) Three or more interoperable implementations must exist. At least
3) 3つ以上の共同利用できる実装が存在しなければなりません。 少なくとも
Hinden [Page 6] RFC 1264 Routing Protocol Criteria October 1991
プロトコル評価基準1991年10月に掘るHinden[6ページ]RFC1264
two must be written independently.
独自に2を書かなければなりません。
4) There must be evidence that all features of the protocol have been
tested, running between at least two independently written
implementations. This must include that all of the security
features have been demonstrated to operate, and that the mechanisms
defined in the protocol actually provide the intended protection.
4) プロトコルのすべての特徴がテストされたという証拠があるに違いありません、少なくとも2つの独自に書かれた実装の間で稼働していて。 セキュリティ機能のすべてが操作するために示されて、メカニズムが実際にプロトコルで定義したこの必須インクルードは意図している保護を提供します。
5) There must be significant operational experience. This must
include running in a large number routers configured in a complex
topology, and must be part of the operational Internet. The
operational experience must include multi-vendor operation. All
significant features of the protocol must be exercised. In the
case of an Interior Gateway Protocol (IGP), both interior and
exterior routes must be carried (unless another mechanism is
provided for the exterior routes). In the case of a Exterior
Gateway Protocol (EGP), it must carry the full complement of
exterior routes.
5) 重要な運用経験があるに違いありません。 これは、複雑なトポロジーで構成された多くルータへ駆け込むのを含まなければならなくて、操作上のインターネットの一部であるに違いありません。 運用経験はマルチベンダ操作を含まなければなりません。 プロトコルに関するすべての著しい特徴を運動させなければなりません。 Interiorゲートウェイプロトコル(IGP)の場合では、内部の、そして、外の両方のルートを運ばなければなりません(別のメカニズムが外のルートに提供されない場合)。 Exteriorゲートウェイプロトコル(EGP)の場合では、それは外のルートの総定員を運ばなければなりません。
6) Two reports must be submitted to the IESG via the Routing Area
Director. The first report must document how requirements 1)
through 5) of this document have been satisfied. It must include:
6) ルート設定Areaディレクターを通して2つのレポートをIESGに提出しなければなりません。 最初のレポートはどうこの5通のドキュメント)を通した要件1)を満たしてあるかを記録しなければなりません。 それは以下を含まなければなりません。
- Reference to the MIB for the protocol.
- MIBのプロトコルの参照。
- Description of the authentication mechanisms in the protocol.
- プロトコルにおける、認証機構の記述。
- List of implementations including origin of code.
- コードの発生源を含む実装のリスト。
- Implementation experience.
- 実装経験。
- Test scenarios and test results showing that all features of the
protocols have been tested.
- プロトコルのすべての特徴がテストされたのを示すシナリオと試験の成績をテストしてください。
- Description of operational experience. This must include
topology, environment, time and duration, implementations
involved, and overall results and conclusions gained from the
operational experience.
- 運用経験の記述。 これは運用経験から獲得されたトポロジー、環境、時間、持続時間、かかわる実装、総合的な結果、および結論を含まなければなりません。
The second report should be a revision to the report prepared when the protocol was submitted for Draft Standard. It must describe the additional knowledge and understanding gained in the time between when the protocol was made a Draft standard and when it was submitted for Standard.
2番目のレポートはDraft Standardのためにプロトコルを提出したとき作成するレポートへの改正であるべきです。 Draft規格といつStandardのためにそれを提出したかという理解は、それが追加知識について説明しなければならなくて、プロトコルが作られた時の間の時間、獲得されました。
The IESG will forward to the IAB its recommendation for advancement of the new routing protocol to Standard based on its evaluation of protocol specifications and these reports.
IESGはプロトコル仕様とこれらのレポートの評価に基づくStandardへの新しいルーティング・プロトコルの振興のための推薦をIABに送るでしょう。
Hinden [Page 7] RFC 1264 Routing Protocol Criteria October 1991
プロトコル評価基準1991年10月に掘るHinden[7ページ]RFC1264
Security Considerations
セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Author's Address
作者のアドレス
Robert M. Hinden Bolt Beranek and Newman, Inc. 50 Moulton Street Cambridge, MA 02138
モールトン・通りケンブリッジ、ニューマンInc.50MA ロバートM.HindenボルトBeranekと02138
Phone: (617) 873-3757
以下に電話をしてください。 (617) 873-3757
EMail: hinden@bbn.com
メール: hinden@bbn.com
Hinden [Page 8]
Hinden[8ページ]
一覧
スポンサーリンク
