[要約] RFC 3528は、メッシュ強化サービスロケーションプロトコル（mSLP）に関する規格であり、ネットワーク内のサービスの位置情報を効率的に検索するためのプロトコルを提供します。mSLPの目的は、ネットワーク内のサービスの発見と位置情報の管理を改善することです。
Network Working Group W. Zhao
Request for Comments: 3528 H. Schulzrinne
Category: Experimental Columbia University
E. Guttman
Sun Microsystems
April 2003
Mesh-enhanced Service Location Protocol (mSLP)
メッシュ強化サービスロケーションプロトコル（MSLP）
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes the Mesh-enhanced Service Location Protocol (mSLP). mSLP enhances the Service Location Protocol (SLP) with a scope-based fully-meshed peering Directory Agent (DA) architecture. Peer DAs exchange new service registrations in shared scopes via anti-entropy and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies Service Agent (SA) registrations in systems with multiple DAs. mSLP is backward compatible with SLPv2 and can be deployed incrementally.
このドキュメントでは、メッシュ強化サービスロケーションプロトコル（MSLP）について説明します。MSLPは、スコープベースの完全メッシュのピアリングディレクトリエージェント（DA）アーキテクチャを使用して、サービスロケーションプロトコル（SLP）を強化します。ピアダスは、反エントロピーと直接転送を介して共有スコープで新しいサービス登録を交換します。MSLPは、SLP DAサービスの信頼性と一貫性を改善し、複数のDAを持つシステムのサービスエージェント（SA）登録を簡素化します。MSLPはSLPV2との後方互換性があり、徐々に展開できます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notation Conventions . . . . . . . . . . . . . . . . . . 2
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Compatibility . . . . . . . . . . . . . . . . . . . . . 3
2. Scope-based Fully-meshed Peering DA Architecture . . . . . . . 4
3. Peer Relationship Management . . . . . . . . . . . . . . . . . 6
3.1. Learning about New Peers . . . . . . . . . . . . . . . . 6
3.2. Establishing a Peering Connection . . . . . . . . . . . 6
3.3. Exchanging Information about Existing Peers . . . . . . 6
3.4. Maintaining a Peer Relationship . . . . . . . . . . . . 7
3.5. Tearing Down a Peer Relationship . . . . . . . . . . . . 7
4. Registration Propagation Control . . . . . . . . . . . . . . . 7
4.1. Accept ID and Propagation Order . . . . . . . . . . . . 7
4.2. Version Timestamp and Registration Version Resolution . 8
4.3. Mesh Forwarding Extension . . . . . . . . . . . . . . . 8
4.4. Summary Vector . . . . . . . . . . . . . . . . . . . . . 9
4.5. Service Deregistration . . . . . . . . . . . . . . . . . 10
4.6. Anti-entropy Request Message . . . . . . . . . . . . . . 10
4.7. Anti-entropy . . . . . . . . . . . . . . . . . . . . . . 11
4.8. Direct Forwarding . . . . . . . . . . . . . . . . . . . 11
4.9. SrvAck Message . . . . . . . . . . . . . . . . . . . . . 12
4.10. Control Information . . . . . . . . . . . . . . . . . . 12
5. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Protocol Timing Defaults . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 14
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
In the Service Location Protocol (SLPv2 [RFC2608]), Directory Agents (DAs) accept service registrations from Service Agents (SAs) and answer queries from User Agents (UAs); they enhance the performance and scalability of SLPv2. The use of scopes in SLPv2 further improves its scalability. In general, a DA can serve multiple scopes, and a scope can be served by multiple DAs. When multiple DAs are present for a scope, how should they interact with each other? This document describes the Mesh-enhanced Service Location Protocol (mSLP), addressing this open issue in SLPv2.
サービスロケーションプロトコル（SLPV2 [RFC2608]）で、ディレクトリエージェント（DAS）は、サービスエージェント（SAS）からのサービス登録を受け入れ、ユーザーエージェント（UAS）からの回答クエリを受け入れます。SLPV2のパフォーマンスとスケーラビリティを向上させます。SLPV2でスコープを使用すると、スケーラビリティがさらに向上します。一般に、DAは複数のスコープを提供でき、複数のDAがスコープを提供できます。複数のDAが範囲に存在する場合、彼らはどのように相互作用する必要がありますか？このドキュメントでは、SLPV2のこのオープンな問題に対処するメッシュ強化サービスロケーションプロトコル（MSLP）について説明します。
mSLP defines a scope-based fully-meshed peering DA architecture: for each scope, all DAs serving the scope form a fully-meshed peer relationship (similar to IBGP [RFC1771]). Peer DAs exchange new service registrations in shared scopes via anti-entropy [EPID-ALGO,UPDA-PROP] and direct forwarding. mSLP improves the reliability and consistency of SLP DA services, and simplifies SA registrations in systems with multiple DAs.
MSLPは、スコープベースの完全メッシュのピアリングDAアーキテクチャを定義します。各スコープについて、スコープにサービスを提供するすべてのDASが完全にメッシュのピア関係を形成します（IBGP [RFC1771]）。ピアダスは、反エントロピー[EPID-Algo、Upda-Prop]および直接転送を介して共有スコープで新しいサービス登録を交換します。MSLPは、SLP DAサービスの信頼性と一貫性を改善し、複数のDAを持つシステムのSA登録を簡素化します。
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, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
Peer DAs (or Peers) DAs that share one or multiple scopes are peers.
1つまたは複数のスコープを共有するピアダス（またはピア）DAはピアです。
Peering Connection A persistent connection (e.g., TCP) that provides reliable and ordered transfers between two peers. The closing of a peering connection terminates the peer relationship.
ピアリング接続2つのピア間の信頼性の高い順序付けられた転送を提供する永続的な接続（TCPなど）。ピアリング接続を閉じると、ピア関係が終了します。
Mesh-enhanced DA (MDA) An MDA carries the "mesh-enhanced" attribute keyword in its DA Advertisement (DAAdvert) message, maintains peering connections to all peers, and properly interacts with peers.
MESH強化DA（MDA）AN MDAは、DA広告（DAADVERT）メッセージに「メッシュ強化」属性キーワードを運び、すべてのピアへのピアリング接続を維持し、ピアと適切に対話します。
Mesh-enhanced SA (MSA) An MSA uses the Mesh Forwarding extension (Section 4.3) when it registers with MDAs.
MESH強化SA（MSA）AN MSAは、MDAに登録するときにメッシュ転送拡張（セクション4.3）を使用します。
Registration Update A registration update refers to a Service Registration (SrvReg) or Service Deregistration (SrvDeReg) message.
登録更新登録更新とは、サービス登録（SRVREG）またはサービス規制省（SRVDEREG）メッセージを指します。
Registration State A registration state refers to an entry in the registration database.
登録状態登録状態とは、登録データベースのエントリを指します。
Accept DA When a DA accepts a registration update from an SA, the DA is the accept DA for the update.
DAがSAからの登録アップデートを受け入れた場合、DAはDAがアップデートのAccept DAです。
Accept Timestamp The arrival timestamp of a registration update at its accept DA is the accept timestamp of the update. All accept timestamps assigned by the same DA MUST be monotonically increasing.
受け入れるタイムスタンプ登録アップデートの到着タイムスタンプは、そのAccept DAでのアップデートの受け入れタイムスタンプです。同じDAによって割り当てられたタイムスタンプをすべて受け入れることは、単調に増加する必要があります。
Version Timestamp When an MSA sends a registration update to an MDA, the MSA assigns a version timestamp to the update. All version timestamps assigned by the same MSA MUST be monotonically increasing.
バージョンタイムスタンプMSAがMDAに登録アップデートを送信すると、MSAはバージョンのタイムスタンプをアップデートに割り当てます。同じMSAによって割り当てられたすべてのバージョンタイムスタンプは、単調に増加する必要があります。
mSLP is designed as a lightweight enhancement to SLPv2. It is backward compatible with SLPv2. mSLP defines two enhanced entities: MDAs and MSAs. They can be deployed incrementally. An enhanced entity supports extended operations without affecting its original functionality as defined in RFC 2608 [RFC2608]. For simplicity and compatibility, an enhanced entity works as a non-enhanced entity to interact with non-enhanced entities. Table 1 summarizes all interactions involving an MDA or MSA.
MSLPは、SLPV2の軽量強化として設計されています。SLPV2との後方互換性があります。MSLPは、MDAとMSAの2つの拡張エンティティを定義します。それらは段階的に展開できます。強化されたエンティティは、RFC 2608 [RFC2608]で定義されているように、元の機能に影響を与えることなく、拡張操作をサポートします。単純さと互換性のために、強化されたエンティティは、強化されていないエンティティと対話するための非強化エンティティとして機能します。表1は、MDAまたはMSAを含むすべての相互作用をまとめたものです。
Interaction Equivalent To Defined In
----------------------------------------------
MDA <--> MDA mSLP
MDA <--> MSA mSLP
MDA <--> DA DA <--> DA RFC 2608
MDA <--> SA DA <--> SA RFC 2608
MDA <--> UA DA <--> UA RFC 2608
MSA <--> DA SA <--> DA RFC 2608
MSA <--> UA SA <--> UA RFC 2608
Table 1. Interactions involving an MDA or MSA
表1. MDAまたはMSAを含む相互作用
(x,y)
+--------------------------------------------------+
| +------------+ |
| | MDA4 (z) | |
| +------------+ |
| | (z) |
+------------+ (y) +------------+ (y) +------------+
| MDA1 (x,y) | ---------- | MDA3 (y,z) | ---------- | MDA2 (x,y) |
+------------+ +------------+ +------------+
Figure 1. A scope-based fully-meshed peering DA architecture
図1.スコープベースの完全にメッシュしたピアリングDAアーキテクチャ
mSLP employs a scope-based fully-meshed peering DA architecture. For each scope, all MDAs that serve the scope form a fully-meshed peer relationship. Figure 1 shows an example for four MDAs and three scopes (x, y, and z). Note that a single peering connection is needed between two peers for exchanging all service registrations in their shared scopes.
MSLPは、スコープベースの完全にメッシュのピアリングDAアーキテクチャを採用しています。各範囲について、スコープに役立つすべてのMDAは、完全にメッシュのピア関係を形成します。図1は、4つのMDAと3つのスコープ（x、y、z）の例を示しています。共有されたスコープのすべてのサービス登録を交換するために、2人のピア間の単一のピアリング接続が必要であることに注意してください。
This architecture enhances SLP DA services. First, it improves the consistency among peer DAs by automatically reconciling inconsistent states among them. Second, it enables newly booted and rebooted MDAs to catch up on all new registrations at once from their peers, purely through DA interaction, without involving SAs.
このアーキテクチャは、SLP DAサービスを強化します。まず、彼らの間で一貫性のない状態を自動的に調整することにより、ピアダス間の一貫性を改善します。第二に、新たに起動し、再起動したMDAは、SASを伴わずに、純粋にDAの相互作用を通じて、仲間から一度にすべての新しい登録に追いつくことができます。
This architecture also simplifies SA registrations. In SLPv2, an SA needs to discover and register with all existing DAs in its scopes, and re-register when new DAs are discovered or old DAs are found to have rebooted. In mSLP, for all MDAs, an MSA only needs to discover and register with a sufficient number of them, such that the union of their scopes covers its scopes; the registrations will then be propagated automatically to other MDAs in the registration scopes. For example, in Figure 2, MSA1 only needs to discover and register with MDA2, or with both MDA1 and MDA3.
このアーキテクチャは、SA登録も簡素化します。SLPV2では、SAはそのスコープで既存のすべてのDASを発見および登録し、新しいDAが発見された場合、または古いDAが再起動したことがわかった場合に再登録する必要があります。MSLPでは、すべてのMDAについて、MSAは十分な数のそれらを発見して登録するだけで、そのスコープの結合がそのスコープをカバーする必要があります。登録は、登録スコープで他のMDAに自動的に伝播されます。たとえば、図2では、MSA1はMDA2、またはMDA1とMDA3の両方を発見して登録する必要があります。
(option2) +------------+ (option2)
+----------------- | MSA1 (x,y) | -----------------+
| +------------+ |
| | (option1) |
V V V
+----------+ +------------+ +----------+
| MDA1 (x) | ----------- | MDA2 (x,y) | ----------- | MDA3 (y) |
+----------+ +------------+ +----------+
Figure 2. Options for registering with MDAs
図2. MDAに登録するためのオプション
Furthermore, this architecture provides scaling advantages. Consider a scope that has N SAs and M DAs, and assume N > M >= 2. Although mSLP and SLPv2 need the same number of SLP messages to distribute registrations from N SAs to M DAs, mSLP can reduce the number of agents needed for taking care of registration distribution, and reduce the number of TCP connections needed if each SA uses TCP for its registrations. More specifically, the agents that need to take care of registration distribution are all N SAs in SLPv2, but only M DAs in mSLP. Also, the number of needed TCP connections is N*M in SLPv2 as each SA has to connect with each DA and register, but only N+M*(M-1)/2 in mSLP as each SA only needs to connect to one contacting DA of a full mesh of M node and register, then registrations are propagated through the DA mesh. For N=100 and M=10, SLPv2 needs 1000 TCP connections, but mSLP only needs 145 such connections.
さらに、このアーキテクチャはスケーリングの利点を提供します。N SASとM DASを備えたスコープを考え、N> M> = 2を想定しています。MSLPとSLPV2はn SASからM DASに登録を配布するために同じ数のSLPメッセージが必要ですが、MSLPは必要なエージェントの数を減らすことができます登録配布の世話をし、各SAが登録にTCPを使用した場合に必要なTCP接続の数を減らします。より具体的には、登録分布の世話をする必要があるエージェントはすべてSLPV2のn SASですが、MSLPではM DAのみです。また、各SAが各DAとレジスタに接続する必要があるため、必要なTCP接続の数はslpv2でn*mですが、各SAがDAに接触する1つに接続する必要があるため、MSLPでn m*（m-1）/2のみがmslpです。Mノードと登録の完全なメッシュの場合、登録はDAメッシュを介して伝播されます。n = 100およびM = 10の場合、SLPV2は1000 TCP接続が必要ですが、MSLPは145のそのような接続のみが必要です。
Note that as mSLP employs full-mesh topology, which is mainly for simplicity and reliability, it cannot scale to a large number of MDAs in a single mesh. In general, mSLP can be applied if the number of MDAs in a mesh is on the order of tens or below. One way to avoid having a large number of MDAs in a mesh is to split the scope into several finer scopes. For example, if we have N MDAs for scope "x", and N is too large, then we can split "x" into two finer scopes: "x-1" and "x-2", with N1 MDAs for "x-1" only, N2 MDAs for "x-2" only, N3 MDAs for both "x-1" and "x-2", and N1+N2+N3=N. Thus, instead of having a large full mesh of size N, we now have two smaller full meshes of size N1+N3 and N2+N3, respectively. Accordingly, a service registration that previously targets for scope "x", now needs to be registered under both "x-1" and "x-2".
MSLPは主に単純さと信頼性のためのフルメッシュトポロジを採用しているため、単一のメッシュで多数のMDAにスケーリングすることはできないことに注意してください。一般に、メッシュ内のMDAの数が数十またはそれ以下である場合、MSLPを適用できます。メッシュに多数のMDAがあることを避ける1つの方法は、スコープをいくつかのより細かい範囲に分割することです。たとえば、スコープ「x」のn MDAがあり、nが大きすぎる場合、「x」を「x-1」と「x-2」の2つのより細かいスコープに分割できます。-1 "のみ、" x-2 "のN2 MDAのみ、「x-1」と「x-2」の両方のn3 mdas、およびn1 n2 n3 = n。したがって、サイズnの大きな完全なメッシュを持つ代わりに、それぞれサイズN1 N3とN2 N3の2つの小さなフルメッシュがあります。したがって、以前にスコープ「X」を対象としたサービス登録は、「X-1」と「X-2」の両方に登録する必要があります。
An MDA can learn about new peers via static configuration, DHCP [RFC2610], and DAAdvert multicast and unicast. In any case, an MDA MUST get a peer's DAAdvert before establishing a peer relationship to the peer.
MDAは、静的構成、DHCP [RFC2610]、およびDaAdvertマルチキャストとユニキャストを介して新しいピアについて学ぶことができます。いずれにせよ、MDAはピアとのピア関係を確立する前に、ピアのダアドバートを取得する必要があります。
After getting a new peer's DAAdvert, an MDA establishes a peering connection (if such a connection does not exist yet) to the peer, and sends its DAAdvert via the connection (Figure 3). An MDA can identify a peering connection initiated by a peer by receiving the peer's DAAdvert from the connection. Normally, a single peering connection is set up between two peers, but there is a small possibility that a pair of peering connections might be created between two peers if they try to initiate a connection to each other at almost the same time. Thus, when an MDA identifies a new peering connection initiated by a peer, it SHOULD check whether it has initiated another peering connection to the peer. If this is the case, and it has a lower-numbered IP address than the peer, then the MDA SHOULD terminate the connection it has initiated.
新しいピアのダアドバートを取得した後、MDAはピアへのピアリング接続（そのような接続がまだ存在しない場合）を確立し、接続を介してそのダアドバートを送信します（図3）。MDAは、接続からピアのダアドバートを受信することにより、ピアによって開始されたピアリング接続を識別できます。通常、2つのピア間に単一のピアリング接続が設定されますが、ほぼ同時に互いに接続を開始しようとする場合、2つのピア間に一対のピアリング接続が作成される可能性があります。したがって、MDAがピアによって開始された新しいピアリング接続を識別する場合、ピアへの別のピアリング接続を開始したかどうかを確認する必要があります。この場合、ピアよりも少数のIPアドレスがある場合、MDAは開始した接続を終了する必要があります。
+------+ (1) MDA2's DAAdvert | +------+
| | <----------------------+ | |
| MDA1 | (2) Create a Peering Connection | MDA2 |
| | ---------------------------------------> | |
+------+ (3) MDA1's DAAdvert +------+
Figure 3. Establishing a peering connection
図3.ピアリング接続の確立
After establishing a peering connection, two peers (say, MDA1 and MDA2) exchange information about their existing peers by forwarding peers' DAAdverts via the peering connection (Figure 4). MDA1 will forward the DAAdvert of a peer (say, MDA3) to MDA2 if:
ピアリング接続を確立した後、2人のピア（たとえば、MDA1とMDA2）は、ピアーリング接続を介してピアのダアドバートを転送することにより、既存のピアに関する情報を交換します（図4）。MDA1は、ピア（たとえば、MDA3）のDaAdvertをMDA2に転送します。
(1) MDA3 shares scopes with MDA2, and (2) MDA3 is an active peer of MDA1 (i.e., there is a peering connection between MDA3 and MDA1) or an accept DA for registrations currently maintained by MDA1 (i.e., MDA1 has registrations originally accepted by MDA3).
(1) MDA3はMDA2とスコープを共有し、（2）MDA3はMDA1のアクティブピアです（つまり、MDA3とMDA1の間にはピアーリング接続があります）またはMDA1が現在維持している登録の受け入れDAがあります（つまり、MDA1はMDA3によって元々受け入れられた登録登録があります。）。
MDA2 operates similarly. Note that all DAAdverts can be sent as one TCP stream for efficiency. Exchanging information about existing peers enables an MDA to learn about new peers incrementally.
MDA2も同様に動作します。すべてのDaAdvertは、効率のために1つのTCPストリームとして送信できることに注意してください。既存のピアに関する情報を交換することで、MDAは新しい仲間について徐々に学ぶことができます。
+------+ DAAdverts of MDA1's existing peers +------+
| | ------------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <------------------------------------------ | |
+------+ DAAdverts of MDA2's existing peers +------+
Figure 4. Exchanging information about existing peers
図4.既存のピアに関する情報の交換
+------+ MDA1's DAAdvert +------+
| | ---------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <--------------------------------------- | |
+------+ MDA2's DAAdvert +------+
Figure 5. Maintaining a peer relationship
図5.ピア関係の維持
To detect failures (network partitions and peer crashes), mSLP uses a heart-beat mechanism. An MDA sends its DAAdvert to peers (Figure 5) every CONFIG_DA_KEEPALIVE seconds. The timeout value for this message is CONFIG_DA_TIMEOUT seconds (Section 6).
障害（ネットワークパーティションとピアクラッシュ）を検出するために、MSLPは心拍メカニズムを使用します。MDAは、daAdvertをピアに送信します（図5）config_da_keepalive秒ごとに。このメッセージのタイムアウト値は、config_da_timeout秒（セクション6）です。
An MDA SHOULD tear down a peer relationship when it finds that the peer has closed the peering connection, when it receives a DAAdvert multicast from the peer with a DA stateless boot timestamp set to 0 (meaning that the peer is going to shutdown), or when it has not received the peer's DAAdvert for more than CONFIG_DA_TIMEOUT seconds.
MDAは、ピアがピアーの接続を閉じたことがわかったときにピア関係を取り壊す必要があります。config_da_timeout秒以上にわたってピアのdaAdvertを受け取っていない場合。
When an MDA accepts a registration update from an MSA, the MDA assigns a unique accept ID to the update. An accept ID has two components: an accept DA URL and an accept timestamp. The accept timestamp is a 64-bit integer representing elapsed microseconds since 00:00 Coordinated Universal Time (UTC), January 1, 1900. Figure 6 shows the format for an accept ID entry. A registration state has the same accept ID as that of the latest update applied to it.
MDAがMSAからの登録アップデートを受け入れると、MDAは一意の受け入れIDを更新に割り当てます。Accept IDには2つのコンポーネントがあります。Acceptda urlとAccept Timestamp。Accept Timestampは、1900年1月1日、00:00調整されたUniversal Time（UTC）以降の経過マイクロ秒を表す64ビット整数です。図6は、IDエントリの受け入れの形式を示しています。登録状態は、適用された最新のアップデートと同じ受け入れIDを持っています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept Timestamp, cont'd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Accept DA URL | Accept DA URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. Accept ID entry
図6. IDエントリを受け入れます
An MDA MUST propagate registrations in the increasing order of their accept IDs, i.e., registrations having the same accept DA MUST be propagated in the increasing order of their accept timestamps. Note that registrations having different accept DAs MAY be propagated in any order.
MDAは、受け入れIDの増加順序で登録を伝播する必要があります。つまり、同じ受け入れDAを持つ登録は、受け入れるタイムスタンプの増加順序で伝播する必要があります。DASが異なる登録は、任意の順序で伝播する場合があることに注意してください。
When registrations are propagated among MDAs, their arrival timestamps at MDAs cannot be used for version resolution. For example, assume that MSA1 sends a registration (R1) to MDA1 first, and a new version of the same registration (R2) to MDA2 later. When R1 and R2 are propagated, the arrival timestamp of R1 at MDA2 is later than that of R2, but R1 SHOULD NOT overwrite R2 at MDA2 as R2 is a newer version.
MDAで登録が伝播される場合、MDASでの到着タイムスタンプはバージョン解像度に使用できません。たとえば、MSA1が最初にMDA1に登録（R1）を送信し、同じ登録（R2）の新しいバージョンをMDA2に送信して後で仮定します。R1とR2が伝播されると、MDA2でのR1の到着タイムスタンプはR2の到着タイムスタンプよりも遅くなりますが、R1はMDA2でR2を上書きしてはなりません。R2は新しいバージョンであるためです。
mSLP resolves registration versions using version timestamps. When an MSA sends a registration update to an MDA, the MSA assigns a version timestamp to the update. The version timestamp is a 64-bit integer representing elapsed microseconds since 00:00 UTC, January 1, 1900. mSLP assumes that each registration is updated only by one SA, thus an MDA does not need to compare version timestamps from different MSAs. An MDA installs a registration update if the update has a newer version timestamp (from an MSA), or the update does not have the Mesh Forwarding extension (from a non-MSA).
MSLPは、バージョンタイムスタンプを使用して登録バージョンを解決します。MSAが登録アップデートをMDAに送信すると、MSAはバージョンのタイムスタンプを更新に割り当てます。バージョンタイムスタンプは、1900年1月1日、00:00 UTC以降の経過マイクロ秒を表す64ビット整数です。MSLPは、各登録が1つのSAによってのみ更新されると仮定しているため、MDAは異なるMSAのバージョンタイムスタンプを比較する必要はありません。MDAは、更新に新しいバージョンのタイムスタンプ（MSAから）がある場合、または更新にメッシュ転送拡張機能（非MSAから）がない場合、登録更新をインストールします。
The Mesh Forwarding (MeshFwd) extension carries a version timestamp and an accept ID entry. Figure 7 shows its format and two defined Forwarding IDs (Fwd-IDs).
メッシュ転送（MESHFWD）拡張機能には、バージョンのタイムスタンプとAccept IDエントリが搭載されています。図7は、その形式と2つの定義された転送ID（FWD-ID）を示しています。
The MeshFwd extension is used with a Srv(De)Reg message, but it can only be used with a fresh SrvReg, or a complete SrvDeReg.
MESHFWD拡張機能はSRV（de）regメッセージで使用されますが、新鮮なSRVREGまたは完全なSRVDEREGでのみ使用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MeshFwd Extension ID = 0x0006 | Next Extension Offset (NEO) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NEO, cont'd. | Fwd-ID | Version Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Timestamp, cont'd. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version Timestamp, cont'd. | Accept ID Entry \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fwd-ID Abbreviation
1 RqstFwd
2 Fwded
Figure 7. MeshFwd extension and its Fwd-IDs
図7. MeshFWD拡張機能とそのFWD-ID
An MSA uses the RqstFwd MeshFwd extension (Fwd-ID = RqstFwd, accept timestamp = 0) in a Srv(De)Reg to explicitly request an MDA (the accept DA) to forward the message.
MSAは、SRV（DE）REGでRQSTFWD MESHFWD拡張機能（FWD-ID = RQSTFWD、Accept TimestAmp = 0）を使用して、MDA（Accept DA）を明示的に要求してメッセージを転送します。
An MDA uses the Fwded MeshFwd extension (Fwd-ID = Fwded, accept timestamp != 0) in each Srv(De)Reg sent from it to another MDA, either forwarding a Srv(De)Reg received from an MSA (if the message has the RqstFwd MeshFwd extension), or propagating a registration state in its database.
MDAは、各SRV（DE）REGでFWDED MESHFWD拡張機能（FWD-ID = FWDED、Accept Timestamp！= 0）を使用します。RQSTFWD MESHFWD拡張機能を持っています）、またはそのデータベースに登録状態を伝播します。
An MDA uses a summary vector to represent its received Srv(De)Reg(s) that have a MeshFwd extension. This summary vector records the latest accept timestamp for each accept DA that appears in the MeshFwd extension. For example, consider n MDAs for a scope, if MDAi has a summary vector as ((MDA1, T1), (MDA2, T2), ..., (MDAn, Tn)), then MDAi has received all registrations originally accepted by MDAj up to timestamp Tj, where 1<=i,j<=n.
MDAは、概要ベクトルを使用して、MESHFWD拡張機能を備えた受信したSRV（DE）REG（s）を表します。この概要ベクトルは、meshfwd拡張機能に表示される各受け入れDAの最新の受け入れタイムスタンプを記録します。たとえば、MDAIに（MDA1、T1）、（MDA2、T2）、...、（MDAN、TN））として要約ベクトルがある場合、スコープについてはn MDAを考慮してください。MdajはタイムスタンプTJまで、ここで1 <= i、j <= n。
An MDA updates its summary vector when it receives a Srv(De)Reg that has a MeshFwd extension. The MDA adds a new accept ID to its summary vector if the Srv(De)Reg has a new accept DA; the MDA updates the accept timestamp of an existing accept ID in its summary vector if the Srv(De)Reg has an existing accept DA.
MDAは、MESHFWD拡張機能を備えたSRV（DE）REGを受信すると、概要ベクトルを更新します。MDAは、SRV（DE）REGに新しいAccept DAがある場合、その要約ベクトルに新しいAcceptIDを追加します。MDAは、SRV（de）Regに既存のAccept DAがある場合、既存のAccept IDの既存の受け入れIDの受け入れタイムスタンプを要約ベクトルに更新します。
When an MDA receives a SrvDeReg that has a MeshFwd extension, it SHOULD retain the corresponding registration in the database, and mark it as deleted. This way, the registration will not appear in any query reply, and an earlier SrvReg will not mistakenly cause the registration to reappear in the database. A registration state will be purged from the database when it expires.
MDAがMESHFWD拡張機能を備えたSRVDEREGを受信すると、データベースに対応する登録を保持し、削除されたものとしてマークする必要があります。このようにして、登録はクエリの返信には表示されず、以前のSRVREGが誤って登録をデータベースに再び表示することはありません。登録状態が期限切れになると、データベースから削除されます。
The Anti-entropy Request (AntiEtrpRqst) message carries an anti-entropy type ID and a list of accept ID entries. Figure 8 shows its format and two defined anti-entropy type IDs.
アンチエントロピーリクエスト（antietrprqst）メッセージには、エントロピータイプIDと受け入れIDエントリのリストが含まれています。図8は、その形式と2つの定義されたアンチエントロピータイプIDを示しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location Header (AntiEtrpRqst Function-ID = 12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Anti-Entropy Type ID | Number of Accept ID Entries |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Accept ID Entry 1 . . . Accept ID Entry k \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Anti-Entropy Type Type ID
selective 1
complete 2
Figure 8. AntiEtrpRqst message and anti-entropy types
図8. antietrprqstメッセージとアンチエントロピータイプ
The AntiEtrpRqst message is used by an MDA to request new registration states from a peer. The anti-entropy type is either selective or complete. If the anti-entropy type is selective, only registration states that have an accept ID greater than any specified accept ID in the message are requested. If the anti-entropy type is complete, all registration states that have an accept ID greater than any specified accept ID in the message or have an accept DA not specified in the message are requested.
Antietrprqstメッセージは、MDAによって使用されて、ピアから新しい登録状態を要求します。エントロピータイプは選択的または完全です。アンチエントロピータイプが選択的である場合、メッセージ内の指定された受け入れIDよりも承認IDが大きい登録状態のみが要求されます。アンチエントロピータイプが完了した場合、メッセージ内の指定されたAccept IDよりも承認IDが大きいすべての登録状態、またはメッセージで指定されていないAccept DAが要求されます。
For example, consider three MDAs (MDA1, MDA2, and MDA3) for a scope. MDA2 has registration states originally accepted by MDA1, MDA2, and MDA3. If MDA1 sends a selective AntiEtrpRqst to MDA2 using an accept ID list as ((MDA2, T2)), then MDA1 only requests registration states that are originally accepted by MDA2, and have an accept timestamp greater than T2. If MDA1 sends a complete AntiEtrpRqst to MDA2 using an accept ID list as ((MDA2, T2)), then MDA1 requests all registration states originally accepted by MDA1 and MDA3, plus those originally accepted by MDA2 and having an accept timestamp greater than T2.
たとえば、スコープについては、3つのMDA（MDA1、MDA2、およびMDA3）を検討してください。MDA2には、もともとMDA1、MDA2、およびMDA3が受け入れた登録状態があります。MDA1が[（MDA2、T2））として受け入れたIDリストを使用して選択的antietrPrqSTをMDA2に送信する場合、MDA1は元々MDA2によって受け入れられた登録状態のみを要求し、T2よりも大きいAccept Timestamsを持っています。MDA1が（（MDA2、T2））として受け入れたIDリストを使用してMDA2に完全なantietRPRQSTをMDA2に送信した場合、MDA1は元々MDA1およびMDA3に受け入れられたすべての登録状態に加えて、元々MDA2に受け入れられ、T2を超えたTimestampを受け入れたものを要求します。
Anti-entropy is used for exchanging initial registration states when two peers recognize each other for the first time, and for updating new registration states after failures.
アンチエントロピーは、2人のピアが初めて互いに認識したときに初期登録状態を交換し、失敗後に新しい登録状態を更新するために使用されます。
When an MDA receives an AntiEtrpRqst from a peer, it sends the requested new registration states in the increasing order of their accept IDs. At last a Service Acknowledgment (SrvAck) message is sent to indicate that the processing of a corresponding AntiEtrpRqst has been completed (Figure 9). A new registration state is sent as a fresh SrvReg with its remaining lifetime. A newly deregistered state is propagated as a SrvDeReg. Note that multiple Srv(De)Reg(s) can be sent as one TCP stream for efficiency.
MDAがピアからantietrprqSTを受け取ると、要求された新しい登録状態が受け入れられたIDの増加順序で送信されます。ついに、対応するAntietrprqSTの処理が完了したことを示すために、サービス謝辞（SRVACK）メッセージが送信されます（図9）。新しい登録状態は、残りの寿命で新鮮なSRVREGとして送信されます。新しく登録された状態は、srvderegとして伝播されます。複数のSRV（de）reg（s）は、効率のために1つのTCPストリームとして送信できることに注意してください。
+------+ AntiEtrpRqst +------+
| | -------------------------------------------> | |
| MDA1 | (Peering Connection) | MDA2 |
| | <------------------------------------------- | |
+------+ New States via Srv(De)Reg(s) + SrvAck +------+
Figure 9. Anti-entropy via AntiEtrpRqst, Srv(De)Reg(s) and SrvAck
図9. antietrprqst、SRV（de）reg（s）、およびsrvackを介した抗エントロピー
+------+ RqstFwd Srv(De)Reg +------+ Fwded Srv(De)Reg +------+
| | ---------------------> | | --------------------> | |
| MSA1 | | MDA1 | | MDA2 |
| | <--------------------- | | | |
+------+ SrvAck +------+ +------+
Figure 10. Direct forwarding of a Srv(De)Reg
図10. SRV（de）regの直接転送
After sending all new registration states accepted by itself to a peer (via anti-entropy), an MDA directly forwards newly received registration updates from MSAs to the peer until a failure occurs.
MDAは、障害が発生するまで、MSAからピアに新たに受け取った登録更新を直接転送します。
In Figure 10, when a Srv(De)Reg is directly forwarded from MDA1 to MDA2, its Fwd-ID is set to Fwded, and its accept timestamp is set to its arrival timestamp at MDA1. Note that a direct forwarding is performed asynchronously: MDA1 can send a SrvAck to MSA1 before it forwards the Srv(De)Reg to MDA2. Also note that the direct forwarding of a Srv(De)Reg goes only one-hop from its accept DA (say, MDA1) to all MDA1's peers that are in the registration scopes.
図10では、SRV（DE）REGがMDA1からMDA2に直接転送されると、FWD-IDがFWDEDに設定され、その受け入れタイムスタンプはMDA1の到着タイムスタンプに設定されます。直接転送は非同期に実行されることに注意してください。MDA1は、SRV（DE）REGをMDA2に転送する前にSRVACKをMSA1に送信できます。また、SRV（DE）REGの直接転送は、登録スコープにあるすべてのMDA1の仲間に、その受け入れDA（たとえば、MDA1）から1ホップのみになることに注意してください。
According to [RFC2608], a DA MUST reply with a SrvAck to a Srv(De)Reg when the message is received from an SA. However, an MDA SHOULD NOT reply with a SrvAck to a Srv(De)Reg if the message is received from a peer. This is for efficiency because peers exchange Srv(De)Reg messages via reliable peering connections. Note that an MDA MUST reply with a SrvAck to an AntiEtrpRqst.
[RFC2608]によれば、DAは、SAからメッセージが受信されたときにSRV（de）regにSRVACKで返信する必要があります。ただし、MDAは、ピアからメッセージが受信された場合、SRV（DE）REGにSRVACKで返信しないでください。これは、信頼できるピアリング接続を介してSRV（de）Regメッセージを交換するため、効率のためです。MDAはantietrprqstにsrvackで返信する必要があることに注意してください。
For each registration entry, an MDA maintains the following control information: an accept ID (for registration propagation), a version timestamp (for registration version resolution - rejecting previous updates), and a deletion flag (deregistered or not).
登録エントリごとに、MDAは次の制御情報を維持します：受け入れID（登録伝播用）、バージョンタイムスタンプ（登録バージョンの解決 - 以前の更新を拒否）、および削除フラグ（登録済みかどうか）。
For all registration entries, an MDA maintains a summary vector to reflect its received registrations so far.
すべての登録エントリについて、MDAはこれまでに受け取った登録を反映するために要約ベクトルを維持しています。
mSLP extends SLPv2 with three new definitions: a new attribute - "mesh-enhanced" for DAAdvert, a new message extension - MeshFwd, and a new message type - AntiEtrpRqst.
MSLPは、3つの新しい定義でSLPV2を拡張します。新しい属性 - DaAdvertの「Mesh -Enhanced」、新しいメッセージ拡張機能 - MeshFWD、および新しいメッセージタイプ-Antietrprqst。
A UA MAY prefer an MDA to a non-MDA since an MDA is more likely to reliably contain the complete set of current service registrations for the UA's scopes.
UAは、MDAがUAのスコープの現在のサービス登録の完全なセットを確実に含める可能性が高いため、非MDAよりもMDAを好む場合があります。
A non-MSA needs to discover and register with all DAs in its scopes. It does not use the MeshFwd extension.
非MSAは、そのスコープですべてのDASを発見して登録する必要があります。MeshFWD拡張機能を使用しません。
A non-MDA accepts Srv(De)Reg(s) from SAs. It does not forward them.
非MDAは、SASからSRV（de）reg（s）を受け入れます。それらを転送しません。
For all MDAs, an MSA only needs to discover and register with sufficient number of them, such that they cover its scopes. It uses the MeshFwd extension when it registers with MDAs.
すべてのMDAについて、MSAは十分な数のそれらを発見して登録するだけで、そのスコープをカバーする必要があります。MESHFWD拡張機能をMDAに登録するときに使用します。
An MDA carries the "mesh-enhanced" attribute keyword in its DAAdvert. It maintains a peer relationship to each peer. It accepts registrations from SAs and peers, propagates registrations via anti-entropy and direct forwarding to peers.
MDAは、DAADVERTに「メッシュ強化」属性キーワードを運びます。各ピアとのピア関係を維持します。SASおよびピアからの登録を受け入れ、アンチエントロピーとピアへの直接転送を介して登録を伝播します。
Interval Name Default Value Defined in
------------------- ------------- -----------
CONFIG_DA_KEEPALIVE 200 seconds Section 3.4
CONFIG_DA_TIMEOUT 300 seconds Section 3.4
The Mesh Forwarding (MeshFwd) extension ID, 0x0006, described in Section 4.3, has been assigned by IANA out of the SLP extension space (RFC 2608, Section 9.1) reserved for "optional to implement" extensions (i.e., the 0x0000-0x3FFF range).
セクション4.3で説明されているメッシュ転送（MESHFWD）拡張ID、0x0006は、IANAによってSLP拡張スペース（RFC 2608、セクション9.1）から割り当てられています。）。
The function-ID of the Anti-entropy Request (AntiEtrpRqst) message type, 12, described in Section 4.6, has been assigned by IANA (RFC 2608, Section 15).
セクション4.6で説明されているアンチエントロピーリクエスト（antiTRPRQST）メッセージタイプの関数IDは、IANA（RFC 2608、セクション15）によって割り当てられています。
mSLP uses standard SLPv2 authentication. First, an MDA SHOULD authenticate other MDAs before setting up a peer relationship with them so as to prevent any malicious MDA from joining the DA mesh. Second, as a successful attack at an MDA may affect all MDAs in the DA mesh, an MDA SHOULD authenticate MSAs before accepting and forwarding their Srv(De)Reg messages to prevent illegitimate modification or elimination of service registrations. Third, as an MSA depends on the MDA with which it registers to forward its Srv(De)Reg messages, it SHOULD authenticate the MDA to avoid using a malicious MDA.
MSLPは標準のSLPV2認証を使用します。まず、MDAは、悪意のあるMDAがDAメッシュに参加するのを防ぐために、他のMDAを認証する前に、それらとのピア関係を設定する必要があります。第二に、MDAでの攻撃の成功はDAメッシュのすべてのMDAに影響を与える可能性があるため、MDAはSRV（DE）REGメッセージを受け入れて転送して、違法な変更またはサービス登録の排除を防ぐ前にMSAを認証する必要があります。第三に、MSAはSRV（DE）REGメッセージを転送するために登録するMDAに依存するため、悪意のあるMDAの使用を避けるためにMDAを認証する必要があります。
Thomas Narten, James Kempf, Mike Day, Mikael Pahmp, Ira McDonald, Qiaobing Xie and Xingang Guo provided valuable comments for this document.
Thomas Narten、James Kempf、Mike Day、Mikael Pahmp、Ira McDonald、Qiaobing Xie、Xingang Guoは、この文書に貴重なコメントを提供しました。
[RFC2608] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。and M. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC1771] Rekhter, R. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[RFC1771] Rekhter、R。およびT. Li、「Border Gateway Protocol 4（BGP-4）」、RFC 1771、1995年3月。
[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June, 1999.
[RFC2610] Perkins、C。およびE. Guttman、「サービスロケーションプロトコルのDHCPオプション」、RFC 2610、1999年6月。
[EPID-ALGO] A. Demers, D. Greene, C. Hauser, W. Irish, J. Larson, S. Shenker, H. Sturgis, D. Swinehart and D. Terry, "Epidemic algorithms for replicated database maintenance", the sixth ACM symposium on principles of distributed computing, Vancouver, Canada, 1987.
[Epid-Algo] A. Demers、D。Greene、C。Hauser、W。Irish、J。Rarson、S。Shenker、H。Sturgis、D。Swinehart、D。Terry、「複製されたデータベースメンテナンスのための流行アルゴリズム」1987年、カナダ、バンクーバーの分散コンピューティングの原則に関する第6回ACMシンポジウム。
[UPDA-PROP] K. Petersen, M. Spreizer, D. Terry, M. Theimer and A. Demers, "Flexible update propagation for weakly consistent replication", the sixteenth ACM symposium on operating systems principles, Saint Malo, France, 1997.
[UPDA-PLOP] K. Petersen、M。Spreizer、D。Terry、M。Theimer、A。Demers、「弱く一貫した複製のための柔軟な更新伝播」、オペレーティングシステム原則に関する第16回ACMシンポジウム、セントマロ、フランス、1997年。
Weibin Zhao Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
ワイビンZhaoコンピュータサイエンスコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027-7003
EMail: zwb@cs.columbia.edu
Henning Schulzrinne Department of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027-7003
ヘニングシュルツリンコンピュータサイエンスコロンビア大学1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027-7003
EMail: hgs@cs.columbia.edu
Erik Guttman Sun Microsystems Eichhoelzelstr. 7 74915 Waibstadt Germany
Erik Guttman Sun Microsystems Eichhoelzelstr。7 74915 Waibstadtドイツ
EMail: Erik.Guttman@sun.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。