RFC4608 日本語訳

Network Working Group                                           D. Meyer
Request for Comments: 4608                                    R. Rockell
BCP: 120                                                     G. Shepherd
Category: Best Current Practice                              August 2006

コメントを求めるワーキンググループD.マイヤー要求をネットワークでつないでください: 4608R.Rockell BCP: 120 G. カテゴリを見張ってください: 最も良い現在の練習2006年8月

        Source-Specific Protocol Independent Multicast in 232/8

232/8におけるソース特有のプロトコル独立しているマルチキャスト

Status of This Memo

このメモの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   IP Multicast group addresses in the 232/8 (232.0.0.0 to
   232.255.255.255) range are designated as source-specific multicast
   destination addresses and are reserved for use by source-specific
   multicast applications and protocols.  This document defines
   operational recommendations to ensure source-specific behavior within
   the 232/8 range.

IP Multicastが232/8におけるアドレスを分類する、(232.0 .0 232.255.255.255)範囲への.0は、ソース特有のマルチキャスト送付先アドレスとして指定されて、使用のためにソース特有のマルチキャストアプリケーションとプロトコルによって予約されます。 このドキュメントは232/8範囲の中でソース特異的行動を確実にするという操作上の推薦を定義します。

Table of Contents

目次

   1. Introduction ....................................................2
      1.1. BCP, Experimental Protocols, and Normative References ......2
   2. Operational practices in 232/8 ..................................4
      2.1. Preventing Local Sources from Sending to Shared Tree .......4
      2.2. Preventing Remote Sources from Being Learned/Joined
           via MSDP ...................................................4
      2.3. Preventing Receivers from Joining the Shared Tree ..........4
      2.4. Preventing RPs as Candidates for 232/8 .....................5
   3. Acknowledgements ................................................5
   4. Security Considerations .........................................5
   5. References ......................................................6
      5.1. Normative References .......................................6
      5.2. Informative References .....................................6

1. 序論…2 1.1. BCP、実験プロトコル、および引用規格…2 2. 232/8における操作上の習慣…4 2.1. 地元筋が共有された木に発信するのを防ぎます…4 2.2. MSDPを通してBeing Learned/接合されるのからRemote Sourcesを防ぎます…4 2.3. 受信機が共有された木に合流するのを防ぎます…4 2.4. 232/8の候補としてRPsを防ぎます…5 3. 承認…5 4. セキュリティ問題…5 5. 参照…6 5.1. 標準の参照…6 5.2. 有益な参照…6

Meyer, et al.            Best Current Practice                  [Page 1]

RFC 4608              Source-Specific PIM in 232/8           August 2006

マイヤー、他 232/2006年8月8日の最も良い現在の習慣[1ページ]RFC4608のソース特有のPIM

1.  Introduction

1. 序論

   Current Protocol Independent Multicast - Sparse Mode (PIM-SM)
   [RFC4601] relies on the shared Rendezvous Point (RP) tree to learn
   about active sources for a group and to support group-generic (Any
   Source Multicast or ASM) data distribution.  The IP Multicast group
   address range 232/8 has been designated for Source-Specific Multicast
   [RFC3569] applications and protocols [IANA] and SHOULD support
   source-only trees only, precluding the requirement of an RP and a
   shared tree; active sources in the 232/8 range will be discovered out
   of band.  PIM Sparse Mode Designated Routers (DR) with local
   membership are capable of joining the shortest path tree for the
   source directly using SSM functionality of PIM-SM.

現在のプロトコル無党派Multicast--まばらなMode(PIM-SM)[RFC4601]は、活発なソースに関してグループとサポートグループジェネリック(どんなSource MulticastやASMも)情報配給に学ぶために共有されたRendezvous Point(RP)木を当てにします。 IP Multicastグループアドレスの範囲232/8はSource特有のMulticast[RFC3569]アプリケーション、プロトコル[IANA]、およびSHOULDサポートソースだけ木だけのために指定されました、RPと共有された木の要件を排除して。 232/8範囲の活発なソースはバンドから発見されるでしょう。 直接PIM-SMのSSMの機能性を使用することで地方の会員資格があるPIM Sparse Mode Designated Routers(DR)は最短パス木にソースで加わることができます。

   Operational best common practices in the 232/8 group address range
   are necessary to ensure shortest path source-only trees across
   multiple domains in the Internet [RFC3569], and to prevent data from
   sources sending to groups in the 232/8 range from arriving via shared
   trees.  This avoids unwanted data arrival and allows several sources
   to use the same group address without conflict at the receivers.

操作上の232/8グループアドレスの範囲で最も良い一般的な習慣が、インターネット[RFC3569]の複数のドメインの向こう側に最短パスソースだけ木を保証して、232/8範囲のグループに発信するソースからのデータが共有された木を通して到着するのを防ぐのに必要です。 これは、求められていないデータ到着を避けて、いくつかのソースが受信機で闘争なしで同じグループアドレスを使用するのを許容します。

   The operational practices SHOULD:

操作上の習慣SHOULD:

      o  Prevent local sources from sending to shared tree

o 地元筋が共有された木に発信するのを防いでください。

      o  Prevent receivers from joining the shared tree

o 受信機が共有された木に合流するのを防いでください。

      o  Prevent RPs as candidates for 232/8

o 232/8の候補としてRPsを防いでください。

      o  Prevent remote sources from being learned/joined via Multicast
         Source Discovery Protocol (MSDP) [RFC3618]

o Multicast Sourceディスカバリープロトコル(MSDP)で、リモートソースが学習されるか、または加わられるのを防いでください。[RFC3618]

1.1.  BCP, Experimental Protocols, and Normative References

1.1. BCP、実験プロトコル、および引用規格

   This document describes the best current practice for a widely
   deployed Experimental protocol, MSDP.  There is no plan to advance
   MSDP's status (for example, to Proposed Standard).  The reasons for
   this include:

MSDP、このドキュメントは広く配備されたExperimentalプロトコルのために最も良い現在の習慣について説明します。 MSDPの状態(例えばProposed Standardに)を進める計画が全くありません。 この理由は:

      o  MSDP was originally envisioned as a temporary protocol to be
         supplanted by whatever the Inter-Domain Multicast Routing
         (IDMR) working group produced as an inter-domain protocol.
         However, the IDMR WG (or subsequently, the Border Gateway
         Multicast Protocol (BGMP) WG) never produced a protocol that
         could be deployed to replace MSDP.

o MSDPは、元々、Inter-ドメインMulticastルート設定(IDMR)ワーキンググループが相互ドメインプロトコルとして生産したことなら何でもによって取って代わられるために一時的なプロトコルとして思い描かれました。 しかしながら、IDMR WG(または、次にBorderゲートウェイMulticastプロトコル(BGMP)WG)はMSDPを取り替えるために配備できたプロトコルを決して、作成しませんでした。

Meyer, et al.            Best Current Practice                  [Page 2]

RFC 4608              Source-Specific PIM in 232/8           August 2006

マイヤー、他 232/2006年8月8日の最も良い現在の習慣[2ページ]RFC4608のソース特有のPIM

      o  One of the primary reasons given for MSDP to be classified as
         Experimental was that the MSDP Working Group came up with
         modifications to the protocol that the WG thought made it
         better but that implementors didn't see any reasons to deploy.
         Without these modifications (e.g., UDP or GRE encapsulation),
         MSDP can have negative consequences to initial packets in
         datagram streams.

o MSDPがExperimentalとして分類させられた第一の理由の1つは作業部会がWGが考えたプロトコルへの変更と共に来させたMSDPがそれをより良くしましたが、作成者が展開する理由が全くわからなかったということでした。 これらの変更(例えば、UDPかGREカプセル化)がなければ、MSDPはデータグラムストリームでパケットに頭文字をつける否定的結果を持つことができます。

      o  Scalability: Although we don't know what the hard limits might
         be, readvertising everything you know every 60 seconds clearly
         limits the amount of state you can advertise.

o スケーラビリティ: 私たちは、困難な限界がどのくらいであるだろうかを知りませんが、「再-広告を出」して、あなたが60秒毎に明確に知っているすべてがあなたが広告を出すことができる状態の量を制限します。

      o  MSDP reached nearly ubiquitous deployment as the de facto
         standard inter-domain multicast protocol in the IPv4 Internet.

o MSDPはデファクトスタンダード相互ドメインマルチキャストプロトコルとしてIPv4インターネットでほとんど遍在している展開に達しました。

      o  No consensus could be reached regarding the reworking of MSDP
         to address the many concerns of various constituencies within
         the IETF.  As a result, a decision was taken to document what
         is (ubiquitously) deployed and to move that document to
         Experimental.  Although advancement of MSDP to Proposed
         Standard was considered, for the reasons mentioned above, it
         was immediately discarded.

o コンセンサスに、全くIETFの中に様々な選挙民の多くの関心を記述するためにMSDPを作りなおすのに関して達することができませんでした。 その結果、(遍在して)配備されることを記録して、そのドキュメントをExperimentalに動かすために決定を取りました。 Proposed StandardへのMSDPの前進は前記のように理由で考えられましたが、それはすぐに、捨てられました。

      o  The advent of protocols such as source-specific multicast and
         bi-directional PIM, as well as embedded RP techniques for IPv6,
         have further reduced consensus that a replacement protocol for
         MSDP for the IPv4 Internet is required.

o ソース特有のマルチキャストや双方向のPIMなどのプロトコルの到来、およびIPv6のための埋め込まれたRPのテクニックはIPv4インターネットへのMSDPのための交換プロトコルが必要であるというコンセンサスをさらに、減少させました。

   The RFC Editor's policy regarding references is that they be split
   into two categories known as "normative" and "informative".
   Normative references specify those documents that must be read for
   one to understand or implement the technology in an RFC (or whose
   technology must be present for the technology in the new RFC to work)
   [RFCED].  In order to understand this document, one must also
   understand both the PIM [RFC4601] and MSDP [RFC3618] documents.  As a
   result, references to these documents are normative.

参照に関するRFC Editorの方針はそれらが「標準」で「有益である」として知られている2つのカテゴリに分けられるということです。 引用規格は、人が分かるようにそれを読み込まなければならないそれらのドキュメントを指定するか、またはRFC(だれの技術は働く新しいRFCの技術のために存在していなければならないか)[RFCED]の技術を実行します。 また、このドキュメントを理解するために、両方のPIM[RFC4601]とMSDP[RFC3618]ドキュメントを理解しなければなりません。 その結果、これらのドキュメントの参照は規範的です。

   The IETF has adopted the policy that BCPs must not have normative
   references to Experimental protocols.  However, this document is a
   special case in that the underlying Experimental document (MSDP) is
   not planned to be advanced to Proposed Standard.

IETFは方針を採りました。そのBCPsには、Experimentalプロトコルの引用規格があってはいけません。 しかしながら、基本的なExperimentalドキュメント(MSDP)がProposed Standardに進められるために計画されていないので、このドキュメントは特別なケースです。

   The MBONED Working Group requests approval under the Variance
   Procedure as documented in RFC 2026 [RFC2026].  The IESG followed the
   Variance Procedure and, after an additional 4-week IETF Last Call,
   evaluated the comments and status and has approved the document.

MBONED作業部会はRFC2026[RFC2026]に記録されるようにVariance Procedureの下で承認を要求します。 IESGは追加4週間のIETF Last Callの後にVariance Procedureに続いて、コメントと状態を評価して、ドキュメントを承認しました。

Meyer, et al.            Best Current Practice                  [Page 3]

RFC 4608              Source-Specific PIM in 232/8           August 2006

マイヤー、他 232/2006年8月8日の最も良い現在の習慣[3ページ]RFC4608のソース特有のPIM

   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.  Operational practices in 232/8

2. 232/8における操作上の習慣

2.1.  Preventing Local Sources from Sending to Shared Tree

2.1. 地元筋が共有された木に発信するのを防ぎます。

   In order to eliminate the use of shared trees for groups in 232/8,
   while maintaining coexistence with ASM in PIM-SM, the behavior of the
   RP and/or the DR needs to be modified.  This can be accomplished by

PIM-SMでASMとの共存を維持している間、共有された木の232/8におけるグループの使用を排除するために、RP、そして/または、DRの動きは、変更される必要があります。 これを達成できます。

      -  preventing data for 232/8 groups from being sent encapsulated
         to the RP by the DR,

- 232/8のグループのためのデータが送られるのを防ぐのをDRによってRPに要約されました。

      -  preventing the RP from accepting registers for 232/8 groups
         from the DR, and

- そしてRPが受け入れるのを防ぐのがDRからの232/8のグループに登録する。

      -  preventing the RP from forwarding accepted data down (*,G) tree
         for 232/8 groups.

- 推進からRPを防ぐと、データは232/8のグループのために(*、G)木の下側に受け入れられました。

2.2.  Preventing Remote Sources from Being Learned/Joined via MSDP

2.2. MSDPを通してBeing Learned/接合されるのからRemote Sourcesを防ぎます。

   SSM does not require active source announcements via MSDP.  All
   source announcements are received out of band, and the last hop
   router is responsible for sending (S,G) joins directly to the source.
   To prevent propagation of SAs in the 232/8 range, an RP SHOULD

SSMはMSDPを通して活発なソース発表を必要としません。 バンドからすべてのソース発表を受けます、そして、ルータが送るのに原因となる最後のホップ(S、G)は直接ソースにつなぎます。 232/8範囲、RP SHOULDでのSAsの伝播を防ぐために

      -  never originate an SA for any 232/8 groups, and

- そしてどんな232/8のグループのためにもSAを決して溯源しないでください。

      -  never accept or forward an SA for any 232/8 groups.

- どんな232/8のグループのためにもSAを受け入れないでください、または決して進めないでください。

2.3.  Preventing Receivers from Joining the Shared Tree

2.3. 受信機が共有された木に合流するのを防ぎます。

   Local PIM domain practices need to be enforced to prevent local
   receivers from joining the shared tree for 232/8 groups.  This can be
   accomplished by

地方のPIMドメイン習慣は、地方の受信機が232/8のグループのために共有された木に合流するのを防ぐために実施される必要があります。 これを達成できます。

      -  preventing DR from sending (*,G) joins for 232/8 groups, and

- そしてDRが発信するのを(*、G)防ぐのが232/8のグループのために接合する。

      -  preventing RP from accepting (*,G) join for 232/8 groups.

- RPが受け入れるのを防いで、(*、G)は232/8のグループのために接合します。

   However, within a local PIM domain, any last-hop router NOT
   preventing (*,G) joins may trigger unwanted (*,G) state toward the RP
   that intersects an existing (S,G) tree, allowing the receiver on the
   shared tree to receive the data, which breaks the source-specific

地方のPIMドメインの中で防止(*、G)が接合するどれか最後のホップルータNOTがどのように求められていない(*、G)状態の交差するRPに向かって引き金となっても、存在(S、G)は木に登られます、共有された木の上の受信機がソース詳細を壊すデータを受け取るのを許容して

Meyer, et al.            Best Current Practice                  [Page 4]

RFC 4608              Source-Specific PIM in 232/8           August 2006

マイヤー、他 232/2006年8月8日の最も良い現在の習慣[4ページ]RFC4608のソース特有のPIM

   [RFC3569] service model.  It is therefore recommended that ALL
   routers in the domain MUST reject AND never originate (*,G) joins for
   232/8 groups.

[RFC3569]はモデルにサービスを提供します。 それはそうであり、したがって、推薦されて、そのドメインのすべてのルータが(*、G)を拒絶して、決して溯源してはいけないのは232/8のグループのために接合します。

   In those cases in which an ISP is offering its customers (or others)
   the use of the ISP's RP, the ISP SHOULD NOT allow (*,G) joins in the
   232/8 range.

ISP SHOULD NOTがISPに顧客(または、他のもの)にISPのRPの使用を提供させるそれらの場合では、(*、G)は232/8範囲に参加します。

2.4.  Preventing RPs as Candidates for 232/8

2.4. 232/8の候補としてRPsを防ぎます。

   Because SSM does not require an RP, all RPs SHOULD NOT offer
   themselves as candidates in the 232/8 range.  This can be
   accomplished by

SSMがRPを必要としないので、232/8のものの候補が及ぶとき、すべてのRPs SHOULDは自薦しません。 これを達成できます。

      -  preventing RP/BSR from announcing in the 232/8 range,

- RP/BSRが232/8範囲で発表するのを防ぎます。

      -  preventing ALL routers from accepting RP delegations in the
         232/8 range, and

- そしてすべてのルータが232/8範囲でRP代表団を受け入れるのを防ぐ。

      -  precluding RP functionality on RP for the 232/8 range.

- RPに関するRPの機能性を232/8範囲に排除します。

   Note that in typical practice, RPs announce themselves as candidates
   for the 224/4 (which obviously includes 232/8).  It is still
   acceptable to allow the advertisement of 224/4 (or any other superset
   of 232/8); however, this approach relies on the second point, above;
   namely, that routers silently ignore the RP delegation in the 232/8
   range and prevent sending or receiving using the shared tree, as
   described previously.  Finally, an RP SHOULD NOT be configured as a
   candidate RP for 232/8 (or for a more specific range).

実際には、典型的なRPsが224/4のものの候補として自分たちを発表することに注意してください(明らかに232/8を含んでいます)。 224/4(または、232/8のいかなる他のスーパーセットも)の広告を許すのはまだ許容できています。 しかしながら、このアプローチは上の2番目のポイントを当てにします。 すなわち、そのルータは、232/8範囲で静かにRP代表団を無視して、共有された木を使用することで発信するか、または受信するのを防ぎます、以前に説明されるように。 最終的にRP SHOULD NOT、232/8(またはより特定の範囲に)の候補RPとして、構成されてください。

3.  Acknowledgements

3. 承認

   This document is the work of many people in the multicast community,
   including (but not limited to) Dino Farinacci, John Meylor, John
   Zwiebel, Tom Pusateri, Dave Thaler, Toerless Eckert, Leonard
   Giuliano, Mike McBride, and Pekka Savola.

このドキュメントはマルチキャスト共同体での多くの人々の仕事です、Dinoファリナッチ、ジョンMeylor、ジョンZwiebel、トムPusateri、デーヴThaler、Toerlessエッケルト、レオナルド・ジュリアーノ、マイク・マックブライド、およびペッカSavolaを含んでいて(他)。

4.  Security Considerations

4. セキュリティ問題

   This document describes operational practices that introduce no new
   security issues to PIM-SM [RFC4601] in either or SSM [RFC3569] or ASM
   operation.

このドキュメントはどちらか、SSM[RFC3569]またはASM操作でPIM-SM[RFC4601]にどんな新しい安全保障問題も紹介しない操作上の習慣について説明します。

   However, in the event that the operational practices described in
   this document are not adhered to, some problems may surface.  In
   particular, Section 2.3 describes the effects of non-compliance of
   last-hop routers (or, to some degree, rogue hosts sending PIM
   messages themselves) on the source-specific service model.  Creating

しかしながら、本書では説明された操作上の習慣が固く守られない場合、いくつかの問題が表面化するかもしれません。 特に、セクション2.3は最後のホップルータ(メッセージ自体をPIMに送るホストをある程度だます)の不承諾の効果をソース特有のサービスモデルに説明します。 作成

Meyer, et al.            Best Current Practice                  [Page 5]

RFC 4608              Source-Specific PIM in 232/8           August 2006

マイヤー、他 232/2006年8月8日の最も良い現在の習慣[5ページ]RFC4608のソース特有のPIM

   the (*,G) state for source-specific (S,G) could enable a receiver to
   receive data it should not get.  This can be mitigated by host-side
   multicast source filtering.

ソース詳細(S、G)のための(*、G)州は、受信機がそれが得るべきでないデータを受け取るのを可能にすることができました。 ホストサイドマルチキャストソースフィルタリングはこれを緩和できます。

5.  References

5. 参照

5.1.  Normative References

5.1. 引用規格

   [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
             "Protocol Independent Multicast - Sparse Mode (PIM-SM):
             Protocol Specification (Revised)", RFC 4601, August 2006.

[RFC4601] フェナー、B.、ハンドレー、M.、ホルブルック、H.、およびI.Kouvelas、「プロトコルの独立しているマルチキャスト--まばらなモード(PIM-Sm):、」 「プロトコル仕様(改訂される)」、RFC4601、2006年8月。

   [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月。

   [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
             3", BCP 9, RFC 2026, October 1996.

[RFC2026] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」

   [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
             Multicast (SSM)", RFC 3569, July 2003.

[RFC3569]Bhattacharyya、2003年7月のS.、「ソース特有のマルチキャスト(SSM)の概観」RFC3569。

   [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery
             Protocol (MSDP)", RFC 3618, October 2003.

[RFC3618]フェナーとB.とD.マイヤー、「マルチキャストソース発見プロトコル(MSDP)」、RFC3618 2003年10月。

5.2.  Informative References

5.2. 有益な参照

   [IANA]    http://www.iana.org

[IANA] http://www.iana.org

   [RFCED]   http://www.rfc-editor.org/policy.html

[RFCED] http://www.rfc-editor.org/policy.html

Authors' Addresses

作者のアドレス

   David Meyer

デヴィッド・マイヤー

   EMail: dmm@1-4-5.net

メール: dmm@1-4-5.net

   Robert Rockell
   Sprint

ロバートRockellは全速力で走ります。

   EMail: rrockell@sprint.net

メール: rrockell@sprint.net

   Greg Shepherd
   Cisco

グレッグ羊飼いシスコ

   EMail: gjshep@gmail.com

メール: gjshep@gmail.com

Meyer, et al.            Best Current Practice                  [Page 6]

RFC 4608              Source-Specific PIM in 232/8           August 2006

マイヤー、他 232/2006年8月8日の最も良い現在の習慣[6ページ]RFC4608のソース特有のPIM

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   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 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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に情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Meyer, et al.            Best Current Practice                  [Page 7]

マイヤー、他 最も良い現在の習慣[7ページ]