RFC5130 日本語訳
5130 A Policy Control Mechanism in IS-IS Using Administrative Tags. S.Previdi, M. Shand, Ed., C. Martin. February 2008. (Format: TXT=16284 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Previdi
Request for Comments: 5130 M. Shand, Ed.
Category: Standards Track Cisco Systems
C. Martin
iPath Services
February 2008
Previdiがコメントのために要求するワーキンググループS.をネットワークでつないでください: 5130 エドM.シャンド、カテゴリ: 標準化過程シスコシステムズC.マーチンiPathサービス2008年2月
A Policy Control Mechanism in IS-IS Using Administrative Tags
中の方針制御機構、-、管理タグを使用すること。
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document describes an extension to the IS-IS protocol to add operational capabilities that allow for ease of management and control over IP prefix distribution within an IS-IS domain. This document enhances the IS-IS protocol by extending the information that an Intermediate System (IS) router can place in Link State Protocol (LSP) Data Units for policy use. This extension will provide operators with a mechanism to control IP prefix distribution throughout multi-level IS-IS domains.
このドキュメントが拡大について説明する、-、管理の容易さを考慮する運用能力を加えるために議定書の中で述べて、IP接頭語分配の上で制御する、-、ドメイン このドキュメントが高める、-、Intermediate System(ある)ルータが方針使用のためにLink州プロトコル(LSP)データUnitsに置くことができる情報を広げるのによるプロトコル。 この拡大がマルチレベル中でIP接頭語分配を制御するためにメカニズムをオペレータに提供する、-、ドメイン。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . . 2
3. Sub-TLV Additions . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. 32-bit Administrative Tag Sub-TLV 1 . . . . . . . . . . . . 3
3.2. 64-bit Administrative Tag Sub-TLV 2 . . . . . . . . . . . . 3
4. Ordering of Tags . . . . . . . . . . . . . . . . . . . . . . . 3
5. Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6. Operations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
9. Manageability Considerations . . . . . . . . . . . . . . . . . 5
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 6
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
12.1. Normative References . . . . . . . . . . . . . . . . . . . 6
12.2. Informative References . . . . . . . . . . . . . . . . . . 6
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 コンベンションは本書では.2 3を使用しました。 サブTLV追加. . . . . . . . . . . . . . . . . . . . . . . 2 3.1。 32ビットの管理タグサブTLV1.33.2。 64ビットの管理タグサブTLV2.3 4。 タグ. . . . . . . . . . . . . . . . . . . . . . . 3 5を注文します。 承諾. . . . . . . . . . . . . . . . . . . . . . . . . . 4 6。 操作. . . . . . . . . . . . . . . . . . . . . . . . . . 4 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 8。 IANA問題. . . . . . . . . . . . . . . . . . . . . . 5 9。 管理可能性問題. . . . . . . . . . . . . . . . . 5 10。 承認. . . . . . . . . . . . . . . . . . . . . . . 6 11。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 6 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 6 12.1。 引用規格. . . . . . . . . . . . . . . . . . . 6 12.2。 有益な参照. . . . . . . . . . . . . . . . . . 6
Previdi, et al. Standards Track [Page 1] RFC 5130 IS-IS Admin Tags February 2008
Previdi、他 規格がRFC5130を追跡する、[1ページ]-、アドミンは2008年2月にタグ付けをします。
1. Introduction
1. 序論
As defined in [RFC1195] and extended in [RFC3784], the IS-IS protocol [ISO10589] may be used to distribute IPv4 prefix reachability information throughout an IS-IS domain. In addition, thanks to extensions made in [RFC5120] and [ISIS-IPv6], IS-IS may be used to distribute IPv6 reachability information.
[RFC1195]で定義されて、[RFC3784]で広げられるように-、プロトコル[ISO10589]がIPv4接頭語可到達性情報を分配するのにおいて使用されているかもしれない、-、ドメイン さらに、[RFC5120]と[イシス-IPv6]でされた拡大ありがとうございます、-、IPv6可到達性情報を分配するのに使用されるかもしれません。
The IPv4 prefix information is encoded as TLV type 128 and 130 in [RFC1195], with additional information carried in TLV 135 as specified in [RFC3784] and TLV 235 as defined in [RFC5120]. In particular, the extended IP Reachability TLV (TLV 135) contains support for a larger metric space, an up/down bit to indicate redistribution between different levels in the hierarchy, an IP prefix, and one or more sub-TLVs that can be used to carry specific information about the prefix. TLV 235 is a derivative of TLV 135, with the addition of Multi-Topology membership information [RFC5120]. The IPv6 prefix information is encoded as TLV 236 in [ISIS-IPv6], and TLV 237 in [RFC5120].
TLVが128と130をタイプするとき[RFC1195]、IPv4接頭語情報はコード化されます、追加情報が[RFC3784]の指定されるとしてのTLV135と[RFC5120]で定義されるTLV235で運ばれている状態で。 特に、拡張IP Reachability TLV(TLV135)は接頭語に関する特殊情報を運ぶのに使用できるより大きい距離空間のサポート、階層構造で異なったレベルの間の再分配を示すために噛み付かれた上/下である、IP接頭語、および1サブTLVsを含んでいます。 TLV235はMulti-トポロジー会員資格情報[RFC5120]の添加があるTLV135の派生物です。 IPv6接頭語情報は[イシス-IPv6]のTLV236、および[RFC5120]のTLV237としてコード化されます。
This document defines 2 new sub-TLVs for TLV 135, TLV 235, TLV 236 and TLV 237 that may be used to carry administrative information about an IP prefix.
このドキュメントはIP接頭語に関する管理情報を運ぶのに使用されるかもしれないTLV135、TLV235、TLV236、およびTLV237のために2新しいサブTLVsを定義します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
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 BCP 14, [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[RFC2119]で説明されるように本書では解釈されることであるべきです。
3. Sub-TLV Additions
3. サブTLV追加
This document creates 2 new "Administrative Tag" sub-TLVs to be added to TLV 135, TLV 235, TLV 236 and TLV 237. These TLVs specify one or more 32- or 64-bit unsigned integers that may be associated with an IP prefix. Example uses of these tags include carrying BGP standard (or extended) communities and controlling redistribution between levels and areas, different routing protocols, or multiple instances of IS-IS running on the same router.
このドキュメントは、TLV135、TLV235、TLV236、およびTLV237に加えられるために2新しい「管理タグ」サブTLVsを作成します。 これらのTLVsはIP接頭語に関連するかもしれない1つ以上の32か64ビットの符号のない整数を指定します。 これらのタグの例の用途がBGPの一般的な(または、広げられる)共同体を運んで、レベルと領域の間の再分配、異なったルーティング・プロトコル、または複数の例を制御するのを含んでいる、-、同じルータで動きます。
The methods for which their use is employed is beyond the scope of this document and left to the implementer and/or operator.
彼らの使用が採用している方法は、implementer、そして/または、オペレータにこのドキュメントの範囲を超えていて、任せました。
The encoding of the sub-TLV(s) is discussed in the following subsections.
以下の小区分でサブTLV(s)のコード化について議論します。
Previdi, et al. Standards Track [Page 2] RFC 5130 IS-IS Admin Tags February 2008
Previdi、他 規格がRFC5130を追跡する、[2ページ]-、アドミンは2008年2月にタグ付けをします。
3.1. 32-bit Administrative Tag Sub-TLV 1
3.1. 32ビットの管理タグサブTLV1
The Administrative Tag SHALL be encoded as one or more 4-octet unsigned integers using Sub-TLV 1 in TLV 135 [RFC3784], TLV 235 [RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. The Administrative Tag Sub-TLV has following structure:
Administrative Tag SHALL、1つ以上の4八重奏の符号のない整数として、TLV135[RFC3784]、TLV235[RFC5120]、TLV236[イシス-IPv6]、およびTLV237[RFC5120]でSub-TLV1を使用することで、コード化されてください。 Administrative Tag Sub-TLVには、次の構造があります:
o 1 octet of type (value: 1)
o タイプの1つの八重奏(値: 1)
o 1 octet of length (value: multiple of 4)
o 長さの1つの八重奏(値: 4の倍数)
o one or more instances of 4 octets of administrative tag
o 管理タグの4つの八重奏の1つ以上の例
On receipt, an implementation MAY consider only one encoded tag, in which case, the first encoded tag MUST be considered and any additional tags ignored. A tag value of zero is reserved and SHOULD be treated as "no tag".
領収書の上では、実現は1個のコード化されたタグだけを考えるかもしれません、その場合、と最初のコード化されたタグを考えなければならなくて、どんな追加タグも無視しました。 ゼロのタグ値は予約されていて、SHOULDは「タグがありません」として扱われます。
3.2. 64-bit Administrative Tag Sub-TLV 2
3.2. 64ビットの管理タグサブTLV2
The Administrative Tag SHALL be encoded as one or more 8-octet unsigned integers using Sub-TLV 2 in TLV 135 [RFC3784], TLV 235 [RFC5120], TLV 236 [ISIS-IPv6], and TLV 237 [RFC5120]. The 64-bit Administrative Tag Sub-TLV has following structure:
Administrative Tag SHALL、1つ以上の8八重奏の符号のない整数として、TLV135[RFC3784]、TLV235[RFC5120]、TLV236[イシス-IPv6]、およびTLV237[RFC5120]でSub-TLV2を使用することで、コード化されてください。 構造に従うAdministrative Tag Sub-TLVが持っている64ビット:
o 1 octet of type (value: 2)
o タイプの1つの八重奏(値: 2)
o 1 octet of length (value: multiple of 8)
o 長さの1つの八重奏(値: 8の倍数)
o one or more instances of 8 octets of administrative tag
o 管理タグの8つの八重奏の1つ以上の例
On receipt, an implementation MAY consider only one encoded tag; in which case, the first encoded tag MUST be considered and any additional tags ignored. A tag value of zero is reserved and SHOULD be treated as "no tag".
領収書の上では、実現は1個のコード化されたタグだけを考えるかもしれません。 その場合、最初のコード化されたタグは考えなければならなくて、どんな追加タグも無視されています。 ゼロのタグ値は予約されていて、SHOULDは「タグがありません」として扱われます。
4. Ordering of Tags
4. タグの注文
The semantics of the tag order are implementation-dependent. That is, there is no implied meaning to the ordering of the tags that indicates a certain operation or set of operations need be performed based on the order of the tags. Each tag SHOULD be treated as an autonomous identifier that MAY be used in policy to perform a policy action. Whether or not tag A precedes or succeeds tag B SHOULD not change the meaning of the tag set. However, when propagating TLVs that contain multiple tags between levels, an implementation SHOULD
タグオーダーの意味論は実現依存しています。 すなわち、ある操作か1セットの操作がタグの注文に基づいて実行されなければならないのを示すタグの注文へのどんな暗示している意味もありません。 それぞれが政策的措置を実行するのに方針で使用されるかもしれない自治の識別子として扱われた状態でSHOULDにタグ付けをします。 タグAがタグBを先行するか、または引き継ぐことにかかわらず、SHOULDはタグセットの意味を変えません。 しかしながら、伝播するとき、倍数を含むTLVsがレベル、実現の間でSHOULDにタグ付けをします。
Previdi, et al. Standards Track [Page 3] RFC 5130 IS-IS Admin Tags February 2008
Previdi、他 規格がRFC5130を追跡する、[3ページ]-、アドミンは2008年2月にタグ付けをします。
preserve the ordering such that the first tag remains the first tag, so that implementations that only recognize a single tag will have a consistent view across levels.
最初のタグが最初のタグのままで残るように、注文を保存してください、単一のタグを認識するだけである実現がレベルの向こう側に一貫した視点を持つように。
Each IS that receives an LSP with TLV(s) 135 and/or 235 and/or 236 and/or 237, that have associated sub-TLV(s) 1 and/or 2, MAY operate on the tag values as warranted by the implementation. If an implementation needs to change tag values, for example, when propagating TLVs between levels at an area boundary, then the TLV(s) SHOULD be copied to the newly generated Level-1 or Level-2 LSP. At that point, the contents of the sub-TLV(s) MAY change as dictated by the policy action. In the event that no change is required, the sub- TLV(s) SHOULD be copied in order into the new LSP, such that ordering is preserved.
TLV(s)135、235、236、そして/または、237と共にLSPを受けて、関連サブTLV(s)1、そして/または、2、5月に実現で保証されるようにタグ値を作動させるそれぞれは、あります。 実現が、タグ値、エリアの境界におけるレベルの間のTLVsを伝播するときの例えば次にTLV(s) SHOULDを変える必要があるなら、新たに発生したLevel-1かLevel-2 LSPにコピーされてください。 その時、サブTLV(s)5月の内容は政策的措置で書き取られるように変化します。 変化は全く必要ではありません、サブTLV(s) SHOULD。新しいLSPに整然とした状態でコピーされてください、注文が保存されるように。
5. Compliance
5. 承諾
A compliant IS-IS implementation MUST be able to assign one tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. It MUST be able to interpret a single tag present in the sub-TLV, or the first tag where there is more than one tag present in the sub-TLV.
A対応する、-、実現は以下のTLVsのどれかのどんなIP接頭語への1個のタグも割り当てることができなければなりません: TLV135、TLV235、TLV236、TLV237。 それはサブTLVの現在の単一のタグ、またはサブTLVの現在の1個以上のタグがある最初のタグを解釈できなければなりません。
A compliant IS-IS implementation MAY be able to assign more than one tag to any IP prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237. It MAY be able to interpret the second and subsequent tags where more than one tag is present in the sub-TLV.
A対応する、-、実現は以下のTLVsのどれかのどんなIP接頭語への1個以上のタグも割り当てることができるかもしれません: TLV135、TLV235、TLV236、TLV237。 それはサブTLVで1個以上のタグが存在している2番目の、そして、その後のタグを解釈できるかもしれません。
When propagating TLVs between levels, a compliant IS-IS implementation MAY be able to rewrite or remove one or more tags associated with a prefix in any of the following TLVs: TLV 135, TLV 235, TLV 236, TLV 237.
レベル、aの間で言いなりになっているTLVsを伝播する、-、実現は、以下のTLVsのどれかの接頭語に関連している1個以上のタグを書き直すか、または取り除くことができるかもしれません: TLV135、TLV235、TLV236、TLV237。
6. Operations
6. 操作
An administrator associates an Administrative Tag value with some interesting property. When IS-IS advertises reachability for some IP prefix that has that property, it adds the Administrative Tag to the IP reachability information TLV for that prefix, and the tag "sticks" to the prefix as it is flooded throughout the routing domain.
管理者はAdministrative Tag値を何らかの興味深い特性に関連づけます。 いつ、-、その特性を持っている何らかのIP接頭語、その接頭語のためのIP可到達性情報TLVにAdministrative Tagを加えて、それがあらゆる点で水につかっているのでタグが経路ドメインを接頭語に「張り付ける」ので、可到達性の広告を出すか。
Consider the network in Figure 1. We wish to "leak" L1 prefixes [RFC2966] with some property, A, from L2 to the L1 router R1. Without policy groups, there is no way for R2 to know property A prefixes from property B prefixes.
図1のネットワークを考えてください。 何らかの特性、Aと共にL1接頭語[RFC2966]をL2からL1ルータR1まで「漏らしたいと思います」。 方針グループがなければ、R2が特性のB接頭語から特性のA接頭語を知る方法が全くありません。
Previdi, et al. Standards Track [Page 4] RFC 5130 IS-IS Admin Tags February 2008
Previdi、他 規格がRFC5130を追跡する、[4ページ]-、アドミンは2008年2月にタグ付けをします。
R2--------R3--------R4
L2 / \
- - - /- - - - - - - - - - - - - -
L1 / \
R1----1.1.1.0/24 (A) R5
|
|
1.1.2.0/24 (B)
R2--------R3--------R4 L2/\--、--、--、/、-、--、--、--、--、--、--、--、--、--、--、--、--、--、L1/\R1----1.1.1.0/24(A)R5| | 1.1.2.0/24 (B)
Figure 1: Example of usage
図1: 用法に関する例
We associate Administrative Tag 100 with property A, and have R5 attach that value to the IP extended reachability information TLV for prefix 1.1.2.0/24. R2 has a policy in place to "match prefixes with Administrative Tag 100, and leak to L1".
私たちは、接頭語1.1.2のためのIP拡張可到達性情報TLVに.0/24にAdministrative Tag100を特性Aに関連づけて、R5にその値を付けさせます。 R2は、「Administrative Tag100に接頭語を合わせて、L1"に漏れる」ように適所に方針を持っています。
The previous example is rather simplistic; it seems that it would be just as easy for R2 simply to match the prefix 1.1.2.0/24. However, if there are a large number of routers that need to apply some policy according to property A and a large number of "A" prefixes, this mechanism can be quite helpful.
前の例はかなり安易です。 R2が単に.0/24に接頭語1.1.2に合っているのが、ちょうど同じくらい簡単であるように思えます。 しかしながら、接頭語の特性Aと多くに従って何らかの方針を適用する必要がある多くのルータがあれば、このメカニズムはかなり役立っている場合があります。
Implementations that support only a single tag and those that support multiple tags may coexist in the same IS-IS domain. An implementation supporting multiple tags SHOULD therefore assign any tag that is required to be interpreted by all systems as the first tag in any set of multiple tags.
単一のタグだけを支える実現とサポート複数のタグが共存するかもしれないそれら、同じである、-、ドメイン したがってSHOULDがどんなタグも割り当てる複数のタグを支える実現が複数のタグのどんなセットでも最初のタグとしてすべてのシステムで解釈されるのが必要です。
7. Security Considerations
7. セキュリティ問題
This document raises no new security issues for IS-IS, as any annotations to IP prefixes should not pass outside the administrative control of the network operator of the IS-IS domain. Such an allowance would violate the spirit of Interior Gateway Protocols in general and IS-IS in particular.
このドキュメントがどんな新しい安全保障問題も提起しない、-、IPへの接頭語がネットワーク・オペレータの運営管理コントロールの外を通るべきでないどんな注釈、も-、ドメイン そして、そのような小遣いが一般に、Interiorゲートウェイプロトコルの精神に違反するだろう、-、特に。
8. IANA Considerations
8. IANA問題
IANA has assigned "1" as the type code of the 32-bit Administrative Tag Sub-TLV and "2" as the type code of the 64-bit Administrative Tag Sub-TLV.
IANAが割り当てた、「32ビットの管理タグサブTLVのタイプコードとしての1インチと「64ビットの管理タグサブTLVのタイプコードとしての2インチ。」
9. Manageability Considerations
9. 管理可能性問題
These extensions have been designed, developed, and deployed for many years and do not have any new impact on management and operation of the IS-IS protocol via this standardization process.
これらの拡大が設計されて、開発させていて、何年も配備して、どんな新しい影響力も管理と操作に持っていない、-、この標準化過程で、議定書を作ってください。
Previdi, et al. Standards Track [Page 5] RFC 5130 IS-IS Admin Tags February 2008
Previdi、他 規格がRFC5130を追跡する、[5ページ]-、アドミンは2008年2月にタグ付けをします。
10. Acknowledgements
10. 承認
The authors would like to thank Henk Smit for clarifying the best place to describe this new information, Tony Li and Tony Przygienda for useful comments on this document, and Danny McPherson for some much needed formatting assistance.
作者は、このドキュメントの役に立つコメントのためにこの新情報、トニー・李、およびトニーPrzygiendaについて説明して、何らかの多くのためにダニーMcPhersonについて説明する最も良い場所が、支援をフォーマットする必要だったのをはっきりさせるためのヘンク・スミットに感謝したがっています。
11. Contributors
11. 貢献者
Brad Neal contributed portions of this document.
ブラッド・ニールはこのドキュメントの一部を寄付しました。
12. References
12. 参照
12.1. Normative References
12.1. 引用規格
[ISO10589] International Organization for Standardization,
"Intermediate system to Intermediate system intra-domain
routing information exchange protocol for use in
conjunction with the protocol for providing the
connectionless-mode Network Service (ISO 8473)", ISO/
IEC 10589:2002, Second Edition, Nov 2002.
[ISO10589]国際標準化機構、「プロトコルに関連したコネクションレスなモードNetwork Serviceを提供する使用のためのIntermediateシステムイントラドメインルーティング情報交換プロトコルへの中間システム、(ISO8473)、」、ISO/IEC10589:2002、Second Edition(2002年11月)
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, December 1990.
[RFC1195]Callon、R.、「使用、TCP/IPと二元的な環境におけるルーティングのためのOSI IS存在、」、RFC1195、12月1990日
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
12.2. Informative References
12.2. 有益な参照
[ISIS-IPv6] Hopps, C., "Routing IPv6 with IS-IS", Work in Progress,
October 2007.
ホップス、[イシス-IPv6]C.、「IPv6を発送する、-、」、10月2007、進行中で、働いてください。
[RFC2966] Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix
Distribution with Two-Level IS-IS", RFC 2966,
October 2000.
[RFC2966] 李、T.、Przygienda、T.、およびH.スミット、「2レベルとのドメイン全体の接頭語分配、-、」、RFC2966、10月2000日
[RFC3784] Smit, H. and T. Li, "Intermediate System to Intermediate
System (IS-IS) Extensions for Traffic Engineering (TE)",
RFC 3784, June 2004.
[RFC3784] スミット、H.、およびT.李、「中間システムへの中間システム、(-、)、交通工学(Te)のための拡大、」、RFC3784(2004年6月)
[RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi
Topology (MT) Routing in IS-IS", RFC 5120,
February 2008.
[RFC5120] Przygienda、T.、シン、N.、およびN.Sheth、「Mイシス:」 「中のマルチトポロジー(MT)ルート設定、-、」、RFC5120、2月2008日
Previdi, et al. Standards Track [Page 6] RFC 5130 IS-IS Admin Tags February 2008
Previdi、他 規格がRFC5130を追跡する、[6ページ]-、アドミンは2008年2月にタグ付けをします。
Authors' Addresses
作者のアドレス
Stefano Previdi Cisco Systems Via Del Serafico, 200 00142 Rome, Italy
デルSerafico、200 00142ローマ(イタリア)経由でステファーノPrevidiシスコシステムズ
EMail: sprevidi@cisco.com
メール: sprevidi@cisco.com
Mike Shand (editor) Cisco Systems 250, Longwater Avenue. Reading, Berks RG2 6GB UK
マイクシャンド(エディタ)シスコシステムズ250、Longwaterアベニュー。 読書、ばかRG2 6GBイギリス
Phone: +44 208 824 8690 EMail: mshand@cisco.com
以下に電話をしてください。 +44 8690年の208 824メール: mshand@cisco.com
Christian Martin iPath Services
クリスチャンのマーチンiPath Services
EMail: chris@ipath.net
メール: chris@ipath.net
Previdi, et al. Standards Track [Page 7] RFC 5130 IS-IS Admin Tags February 2008
Previdi、他 規格がRFC5130を追跡する、[7ページ]-、アドミンは2008年2月にタグ付けをします。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Previdi, et al. Standards Track [Page 8]
Previdi、他 標準化過程[8ページ]
一覧
スポンサーリンク
