RFC2329 日本語訳
2329 OSPF Standardization Report. J. Moy. April 1998. (Format: TXT=15130 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Moy Request for Comments: 2329 Ascend Communications, Inc. Category: Informational April 1998
Moyがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 2329はコミュニケーションInc.カテゴリを昇ります: 情報の1998年4月
OSPF Standardization Report
OSPF標準化レポート
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This memo documents how the requirements for advancing a routing
protocol to Full Standard, set out in [Ref2], have been met for
OSPFv2.
このメモはOSPFv2のためにどう[Ref2]を始められたFull Standardにルーティング・プロトコルを唱えるための必要条件を満たしてあるかを記録します。
Please send comments to ospf@gated.cornell.edu.
コメントを ospf@gated.cornell.edu に送ってください。
Table of Contents
目次
1 Introduction ........................................... 2
2 Modifications since Draft Standard status .............. 3
2.1 Point-to-MultiPoint interface .......................... 4
2.2 Cryptographic Authentication ........................... 5
3 Updated implementation and deployment experience ....... 5
4 Protocol Security ...................................... 7
References ............................................. 8
Security Considerations ................................ 8
Author's Address ....................................... 8
Full Copyright Statement ............................... 9
1つの序論… Draft Standard状態以来の2 2の変更… 3 2.1 ポイントからMultiPointは連結します… 4 2.2 暗号の認証… 5 3は実装と展開経験をアップデートしました… 5 4はセキュリティについて議定書の中で述べます… 7つの参照箇所… 8 セキュリティ問題… 8作者のアドレス… 8 完全な著作権宣言文… 9
Moy Informational [Page 1] RFC 2329 OSPF Standardization Report April 1998
[1ページ]RFC2329OSPF標準化レポート1998年4月の情報のMoy
1. Introduction
1. 序論
OSPFv2, herein abbreviated simply as OSPF, is an IPv4 routing
protocol documented in [Ref8]. OSPF is a link-state routing
protocol. It is designed to be run internal to a single Autonomous
System. Each OSPF router maintains an identical database describing
the Autonomous System's topology. From this database, a routing
table is calculated by constructing a shortest-path tree. OSPF
features include the following:
単にOSPFがここに簡略化されたOSPFv2は[Ref8]に記録されたIPv4ルーティング・プロトコルです。 OSPFはLinkState方式プロトコルです。 それは、独身のAutonomous Systemに内部で実行されるように設計されています。 それぞれのOSPFルータはAutonomous Systemのトポロジーについて説明する同じデータベースを維持します。 このデータベースから、経路指定テーブルは、最短パス木を組み立てることによって、計算されます。 OSPFの特徴は以下を含んでいます:
o OSPF responds quickly to topology changes, expending a minimum
of network bandwidth in the process.
o 最小プロセスのネットワーク回線容量を費やして、OSPFはすばやくトポロジー変化に応じます。
o Support for CIDR addressing.
o CIDRには、アドレシングをサポートしてください。
o OSPF routing exchanges can be authenticated, providing routing
security.
o ルーティングセキュリティを提供して、OSPFルーティング交換を認証できます。
o Equal-cost multipath.
o 等価コストマルチパス。
o An area routing capability is provided, enabling an Autonomous
system to be split into a two level hierarchy to further reduce
the amount of routing protocol traffic.
o 領域ルーティング能力を提供します、Autonomousシステムがルーティング・プロトコルトラフィックの量をさらに減少させるために2の平らな階層構造に分けられるのを可能にして。
o OSPF allows import of external routing information into the
Autonomous System, including a tagging feature that can be
exploited to exchange extra information at the AS boundary (see
[Ref7]).
o OSPFは外部のルーティング情報の輸入をAutonomous Systemに許します、AS境界でその他の情報を交換するのに利用できるタグ付けの特徴を含んでいて([Ref7]を見てください)。
An analysis of OSPF together with a more detailed description of
OSPF features was originally provided in [Ref6], as a part of
promoting OSPF to Draft Standard status. The analysis of OSPF
remains unchanged. Two additional major features have been developed
for OSPF since the protocol achieved Draft Standard status: the
Point-to-MultiPoint interface and Cryptographic Authentication.
These features are described in Sections 2.1 and 2.2 respectively of
this memo.
元々OSPFの特徴の、より詳細な記述に伴うOSPFの分析を[Ref6]に提供しました、Draft Standard状態にOSPFを促進する一部として。 OSPFの分析は変わりがありません。 プロトコルがDraft Standard状態を獲得して以来、2つの追加主要な特徴がOSPFのために発生しています: PointからMultiPointへのインタフェースとCryptographic Authentication。 これらの特徴はセクション2.1と2.2でこのメモについてそれぞれ説明されます。
The OSPF MIB is documented in [Ref4]. It is currently at Draft
Standard status.
OSPF MIBは[Ref4]に記録されます。 それは現在、Draft Standard状態にあります。
Moy Informational [Page 2] RFC 2329 OSPF Standardization Report April 1998
[2ページ]RFC2329OSPF標準化レポート1998年4月の情報のMoy
2. Modifications since Draft Standard status
2. Draft Standard状態以来の変更
OSPF became a Draft Standard with the release of RFC 1583 [Ref3].
Implementations of the new specification in [Ref8] are backward-
compatible with RFC 1583. The differences between the two documents
are described in the Appendix Gs of [Ref1] and [Ref8]. These
differences are listed briefly below. Two major features were also
added, the Point-to-MultiPoint interface and Cryptographic
Authentication, which are described in separate sections.
RFC1583[Ref3]のリリースに応じて、OSPFはDraft Standardになりました。 [Ref8]の新しい仕様の実装はRFC1583と互換性があった状態で後方です。 2通のドキュメントの違いは[Ref1]と[Ref8]のAppendix Gsで説明されます。 これらの違いは簡潔に以下に記載されています。 2つの主要な特徴が、また、加えられてPointからMultiPointへのインタフェースとCryptographic Authenticationでした。(そのCryptographic Authenticationは別々のセクションで説明されます)。
o Configuration requirements for OSPF area address ranges have
been relaxed to allow greater flexibility in area assignment.
See Section G.3 of [Ref1] for details.
o OSPF領域のアドレスの範囲のための構成必要条件は、領域代入における、より大きい柔軟性を許容するためにリラックスしました。 詳細に関して[Ref1]のセクションG.3を見てください。
o The OSPF flooding algorithm was modified to a) improve database
convergence in networks with low speed links b) resolve a
problem where unnecessary LSA retransmissions could occur as a
result of differing clock granularities, c) remove race
conditions between the flooding of MaxAge LSAs and the Database
Exchange process, d) clarify the use of the MinLSArrival
constant, and e) rate-limit the response to less recent LSAs
received via flooding. See Sections G.4 and G.5 of [Ref1] and
Section G.1 of [Ref8] for details.
o OSPF氾濫アルゴリズムは変更されて、a)に、ネットワークにおけるデータベース集合が向上しているということでした。低速リンクb)で、不要なLSA retransmissionsが起こるかもしれなくて、その結果異なるのにおいて、時計粒状、c)がMaxAge LSAsの氾濫とDatabase Exchangeプロセスの間に競合条件を移す、問題、d)がMinLSArrival定数、およびそれほど最近でないLSAsへの応答が氾濫を通して受け取ったe)レート限界の使用をはっきりさせると決議してください。 詳細に関して[Ref1]のセクションのG.4とG.5と[Ref8]のセクションG.1を見てください。
o To resolve the long-standing confusion regarding representation
of point-to-point links in OSPF, the specification now
optionally allows advertisement of a stub link to a point-to-
point link's subnet, ala RIP. See Section G.6 of [Ref1].
o OSPFのポイントツーポイント接続の表現に関して長年の混乱を決議するために、仕様は現在、任意にポイントからポイントへのリンクのサブネット(ala RIP)へのスタッブリンクの広告を許します。 [Ref1]のセクションG.6を見てください。
o Several problems involving advertising the same external route
from multiple areas were found and fixed, as described in
Section G.7 of [Ref1] and Section G.2 of [Ref8]. Without the
fixes, persistent routing loops could form in certain such
configurations. Note that one of the fixes was not backward-
compatible, in that mixing routers implementing the fixes with
those implementing just RFC 1583 could cause loops not present
in an RFC 1583-only configuration. This caused an
RFC1583Compatibility global configuration parameter to be added,
as described in Section C.1 of [Ref1].
o 複数の領域から同じ外部経路の広告を出すことを伴うことにおけるいくつかの問題が、見つけられて、修正されました、[Ref1]のセクションG.7と[Ref8]のセクションG.2で説明されるように。 フィックスがなければ、永続的なルーティング輪はあるそのような構成を形成するかもしれません。 フィックスの1つがフィックスを実装するルータをそれらに混ぜることにおいてそれで互換性があった状態で後方でなかったというまさしくRFCが1583であると実装するメモは1583年だけのRFC構成における現在でない輪を引き起こす場合がありました。 これで、[Ref1]のセクションC.1で説明されるようにRFC1583Compatibilityのグローバルな設定パラメータを加えました。
Moy Informational [Page 3] RFC 2329 OSPF Standardization Report April 1998
[3ページ]RFC2329OSPF標準化レポート1998年4月の情報のMoy
o In order to deal with high delay links, retransmissions of
initial Database Description packets no longer reset an OSPF
adjacency.
o 高い遅れリンクに対処するために、初期のDatabase記述パケットの「再-トランスミッション」はもうOSPF隣接番組をリセットしませんでした。
o In order to detect link MTU mismatches, which can cause problems
both in IP forwarding and in the OSPF routing protocol itself,
MTU was added to OSPF's Database Description packets.
Neighboring routers refuse to bring up an OSPF adjacency unless
they agree on their common link's MTU.
o リンクMTUミスマッチ(IP推進とOSPFルーティング・プロトコル自体で問題を起こすことができる)を検出するために、MTUはOSPFのDatabase記述パケットに加えられました。 彼らがそれらの普通リンクのMTUに同意しないなら、隣接しているルータは、OSPF隣接番組を持って来るのを拒否します。
o The TOS routing option was deleted from OSPF. However, for
backward compatibility the formats of OSPF's various LSAs remain
unchanged, maintaining the ability to specify TOS metrics in
router-LSAs, summary-LSAs, ASBR-summary-LSAs, and AS-external-
LSAs.
o TOSルーティングオプションはOSPFから削除されました。 しかしながら、後方の互換性のために、OSPFの様々なLSAsの形式は変わりがありません、ルータ-LSAsでのTOS測定基準を指定する能力を維持して、概要-LSAs、LSAsですASBRの要約のLSAs、およびAS外部の。
o OSPF's routing table lookup algorithm was changed to reflect
current practice. The "best match" routing table entry is now
always selected to be the one providing the most specific
(longest) match. See Section G.4 of [Ref8] for details.
o 現在の習慣を反映するためにOSPFの経路指定テーブルルックアップアルゴリズムを変えました。 「最も良いマッチ」経路指定テーブルエントリーは現在、提供する中でマッチ最も特定である(最も長い)ものであることがいつも選択されます。 詳細に関して[Ref8]のセクションG.4を見てください。
2.1. Point-to-MultiPoint interface
2.1. ポイントからMultiPointへのインタフェース
The Point-to-MultiPoint interface was added as an alternative to OSPF's NBMA interface when running OSPF over non-broadcast subnets. Unlike the NBMA interface, Point-to-MultiPoint does not require full mesh connectivity over the non-broadcast subnet. Point-to-MultiPoint is less efficient than NBMA, but is easier to configure (in fact, it can be self-configuring) and is more robust than NBMA, tolerating all failures within the non- broadcast subnet. For more information on the Point-to- MultiPoint interface, see Section G.2 of [Ref1].
非放送サブネットの上にOSPFを実行するとき、PointからMultiPointへのインタフェースはOSPFのNBMAインタフェースに代わる手段として加えられました。 NBMAインタフェースと異なって、PointからMultiPointは非放送サブネットに関して完全なメッシュの接続性を必要としません。 ポイントからMultiPointは、より効率的ではありませんが、構成するのが(事実上、それは自己に構成されることができます)より簡単であり、NBMAよりNBMAより強健です、非放送しているサブネットの中にすべての失敗を許容して。 PointからMultiPointへのインタフェースの詳しい情報に関しては、[Ref1]のセクションG.2を見てください。
There are at least six independent implementations of the Point-to-MultiPoint interface. Interoperability has been demonstrated between at least two pairs of implementations: between 3com and Bay Networks, and between cisco and Cascade.
PointからMultiPointへのインタフェースの少なくとも6つの独立している実装があります。 相互運用性は少なくとも2組の実装の間に示されました: 3comとベイネットワークスと、コクチマスとCascadeの間で。
Moy Informational [Page 4] RFC 2329 OSPF Standardization Report April 1998
[4ページ]RFC2329OSPF標準化レポート1998年4月の情報のMoy
2.2. Cryptographic Authentication
2.2. 暗号の認証
Non-trivial authentication was added to OSPF with the development of the Cryptographic Authentication type. This authentication type uses any keyed message digest algorithm, with explicit instructions included for the use of MD5. For more information on OSPF authentication, see Section 4.
重要な認証はCryptographic Authenticationタイプの進化によってOSPFに加えられました。 この認証タイプはMD5の使用のために含まれている明白な指示と共にどんな合わせられたメッセージダイジェストアルゴリズムも使用します。 OSPF認証の詳しい情報に関しては、セクション4を見てください。
There are at least three independent implementations of the OSPF Cryptographic authentication type. Interoperability has been demonstrated between the implementations from cisco and Cascade.
OSPF Cryptographic認証タイプの少なくとも3つの独立している実装があります。 相互運用性は実装の間にコクチマスとCascadeから示されました。
3. Updated implementation and deployment experience
3. アップデートされた実装と展開経験
When OSPF was promoted to Draft Standard Status, a report was issued
documenting current implementation and deployment experience (see
[Ref6]). That report is now quite dated. In an attempt to get more
current data, a questionnaire was sent to OSPF mailing list in
January 1996. Twelve responses were received, from 11 router vendors
and 1 manufacturer of test equipment. These responses represented 6
independent implementations. A tabulation of the results are
presented below.
OSPFをDraft Standard Statusに促進したとき、現在の実装と展開経験を記録しながら、レポートを発行しました([Ref6]を見てください)。 そのレポートは現在、かなり日付を入れられます。 より現在のデータを得る試みでは、1996年1月にOSPFメーリングリストにアンケートを送りました。 テスト設備の11のルータベンダーと1つのメーカーから12の応答を受けました。 これらの応答は6つの独立している実装を表しました。 以下で結果の図表作成を贈ります。
Table 1 indicates the implementation, interoperability and
deployment of the major OSPF functions. The number in each column
represents the number of responses in the affirmative.
テーブル1は主要なOSPF機能の実装、相互運用性、および展開を示します。 各桁の数は肯定における、応答の数を表します。
Moy Informational [Page 5] RFC 2329 OSPF Standardization Report April 1998
[5ページ]RFC2329OSPF標準化レポート1998年4月の情報のMoy
Imple- Inter- Feature mented operated Deployed _______________________________________________________ OSPF areas 10 10 10 Stub areas 10 10 9 Virtual links 10 9 8 Equal-cost multipath 10 7 8 NBMA support 9 8 7 CIDR addressing 8 5 6 OSPF MIB 8 5 5 Cryptographic auth. 3 2 1 Point-to-Multipoint ifc. 6 3 4
Imple相互Feature mentedはDeployedを操作しました。_______________________________________________________ OSPF領域10 10 10のStub地域10 10 9Virtualは10 9 8Equal-費用多重通路10 7 8NBMAサポート9 8 7CIDRアドレシング8 5 6OSPF MIB8 5 5Cryptographic authをリンクします。 3 2 1ポイントから多点へのifc。 6 3 4
Table 1: Implementation of OSPF features
テーブル1: OSPFの特徴の実装
Table 2 indicates the size of the OSPF routing domains that vendors
have tested. For each size parameter, the number of responders and
the range of responses (minimum, mode, mean and maximum) are listed.
テーブル2はベンダーがテストしたOSPF経路ドメインのサイズを示します。 各サイズ・パラメータに関しては、応答者の数と応答の範囲(最小限、モード、平均、および最大)は記載されています。
Parameter Responses Min Mode Mean Max
_________________________________________________________________
Max routers in domain 7 30 240 460 1600
Max routers in single area 7 20 240 380 1600
Max areas in domain 7 1 10 16 60
Max AS-external-LSAs 9 50 10K 10K 30K
パラメタ応答分のモードの意地悪なマックス_________________________________________________________________ 240 460の1600マックスルータが中で1600のマックス領域コネドメイン7 1 10 16 60マックスASの外部のLSAs9 50 10K10 240 380K30の領域7 20K選抜する人ドメイン7 30におけるマックスルータ
Table 2: OSPF domain sizes tested
テーブル2: OSPFドメインサイズはテストされました。
Table 3 indicates the size of the OSPF routing domains that vendors
have deployed in real networks. For each size parameter, the number
of responders and the range of responses (minimum, mode, mean and
maximum) are listed.
テーブル3はベンダーが本当のネットワークで配布したOSPF経路ドメインのサイズを示します。 各サイズ・パラメータに関しては、応答者の数と応答の範囲(最小限、モード、平均、および最大)は記載されています。
Moy Informational [Page 6] RFC 2329 OSPF Standardization Report April 1998
[6ページ]RFC2329OSPF標準化レポート1998年4月の情報のMoy
Parameter Responses Min Mode Mean Max
_________________________________________________________________
Max routers in domain 8 20 350 510 1000
Max routers in single area 8 20 100 160 350
Max areas in domain 7 1 15 23 60
Max AS-external-LSAs 6 50 1K 2K 5K
パラメタ応答分のモードの意地悪なマックス_________________________________________________________________ 350 510の1000マックスルータが中で1K2 100 160 350のマックス領域コネドメイン7 1 15 23 60マックスASの外部のLSAs6 50K5の領域8 20K選抜する人ドメイン8 20におけるマックスルータ
Table 3: OSPF domain sizes deployed
テーブル3: OSPFドメインサイズは展開しました。
In an attempt to ascertain the extent to which OSPF is currently
deployed, vendors were also asked in January 1998 to provide
deployment estimates. Four vendors of OSPF routers responded, with a
total estimate of 182,000 OSPF routers in service, organized into
4300 separate OSPF routing domains.
また、OSPFが現在配布される範囲を確かめる試みでは、1998年1月に、ベンダーが展開見積りを提供するように頼まれました。 18万2000のOSPFルータの見積総額が使用中の状態で反応するOSPFルータの4つのベンダーが4300の別々のOSPF経路ドメインに結団されました。
4. Protocol Security
4. プロトコルセキュリティ
All OSPF protocol exchanges are authenticated. OSPF supports
multiple types of authentication; the type of authentication in use
can be configured on a per network segment basis. One of OSPF's
authentication types, namely the Cryptographic authentication
option, is believed to be secure against passive attacks and provide
significant protection against active attacks. When using the
Cryptographic authentication option, each router appends a "message
digest" to its transmitted OSPF packets. Receivers then use the
shared secret key and received digest to verify that each received
OSPF packet is authentic.
すべてのOSPFプロトコル交換が認証されます。 OSPFは複数のタイプの認証をサポートします。 ネットワークセグメント基礎あたりのaで使用中の認証のタイプを構成できます。 受け身の攻撃に対して安全であり、OSPFの認証タイプのひとり(すなわち、Cryptographic認証オプション)が活発な攻撃に対して重要な保護を提供すると信じられています。 Cryptographic認証オプションを使用するとき、各ルータは「メッセージダイジェスト」を伝えられたOSPFパケットに追加します。 そして、受信機は、それぞれの容認されたOSPFパケットが正統であることを確かめるのに共有秘密キーの主要で受け取られていているダイジェストを使用します。
The quality of the security provided by the Cryptographic
authentication option depends completely on the strength of the
message digest algorithm (MD5 is currently the only message digest
algorithm specified), the strength of the key being used, and the
correct implementation of the security mechanism in all
communicating OSPF implementations. It also requires that all
parties maintain the secrecy of the shared secret key.
Cryptographic認証オプションで提供されたセキュリティの品質はOSPF実装をすべて伝える際に完全メッセージダイジェストアルゴリズム(現在、MD5は指定された唯一のメッセージダイジェストアルゴリズムである)の強さ、使用されるキーの強さ、およびセキュリティー対策の正しい実装に依存します。 また、それは、すべてのパーティーが共有された秘密鍵の秘密保持を維持するのを必要とします。
None of the OSPF authentication types provide confidentiality. Nor
do they protect against traffic analysis. Key management is also not
addressed by the OSPF specification.
OSPF認証タイプのだれも秘密性を提供しません。 また、彼らはトラヒック分析から守りません。 また、OSPF仕様でかぎ管理は演説されません。
Moy Informational [Page 7] RFC 2329 OSPF Standardization Report April 1998
[7ページ]RFC2329OSPF標準化レポート1998年4月の情報のMoy
For more information, see Sections 8.1, 8.2, and Appendix D of
[Ref1].
詳しくは、セクション8.1、8.2、および[Ref1]のAppendix Dを見てください。
References
参照
[Ref1] Moy, J., "OSPF Version 2", RFC 2178, July 1997.
[Ref1]Moy、J.、「OSPF、バージョン2インチ、RFC2178、1997インチ年7月。
[Ref2] Hinden, B., "Internet Routing Protocol Standardization
Criteria", RFC 1264, October 1991.
[Ref2] Hinden、B.、「インターネットルーティング・プロトコル標準化評価基準」、RFC1264、1991年10月。
[Ref3] Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[Ref3]Moy、J.、「OSPF、バージョン2インチ、RFC1583、1994インチ年3月。
[Ref4] Baker, F., and R. Coltun, "OSPF Version 2 Management
Information Base", RFC 1850, November 1995.
[Ref4] ベイカー、F.とR.Coltun、「OSPFバージョン2管理情報ベース」、RFC1850、1995年11月。
[Ref5] Moy, J., "OSPF Protocol Analysis", RFC 1245, August 1991.
[Ref5] Moy、J.、「OSPFプロトコル分析」、RFC1245、1991年8月。
[Ref6] Moy, J., "Experience with the OSPF Protocol", RFC 1246,
August 1991.
[Ref6] Moy、J.、「OSPFプロトコルの経験」、RFC1246、1991年8月。
[Ref7] Varadhan, K., Hares S., and Y. Rekhter, "BGP4/IDRP for IP--
-OSPF Interaction", RFC 1745, December 1994.
[Ref7]Varadhan、K.、野兎のS.、そして、Y.Rekhter、「IPのためのBGP4/IDRP--、-OSPF相互作用、」、RFC1745、12月1994日
[Ref8] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[Ref8]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
Security Considerations
セキュリティ問題
Security considerations are addressed in Section 4 of this memo.
セキュリティ問題はこのメモのセクション4で扱われます。
Author's Address
作者のアドレス
John Moy
Ascend Communications, Inc.
1 Robbins Road
Westford, MA 01886
ジョンMoyはInc.1ロビンス・Roadウェストフォード、Communications MA 01886を昇ります。
Phone: 978-952-1367
Fax: 978-392-2075
EMail: jmoy@casc.com
以下に電話をしてください。 978-952-1367 Fax: 978-392-2075 メールしてください: jmoy@casc.com
Moy Informational [Page 8] RFC 2329 OSPF Standardization Report April 1998
[8ページ]RFC2329OSPF標準化レポート1998年4月の情報のMoy
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Moy Informational [Page 9]
Moy情報です。[9ページ]
一覧
スポンサーリンク
