[要約] RFC 4548は、NSAPアドレスのためのインターネットコードポイント（ICP）の割り当てに関する情報を提供する。このRFCの目的は、ICPの割り当てを通じて、NSAPアドレスの一意性と相互運用性を確保することである。
Network Working Group E. Gray
Request for Comments: 4548 J. Rutemiller
Updates: 1888, 4048 Ericsson
Category: Standards Track G. Swallow
Cisco Systems, Inc.
May 2006
Internet Code Point (ICP) Assignments for NSAP Addresses
NSAPアドレスのインターネットコードポイント（ICP）割り当て
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document is intended to accomplish two highly inter-related tasks: to establish an "initial" Internet Code Point (ICP) assignment for each of IPv4 and IPv6 address encoding in Network Service Access Point (NSAP) Addresses, and to recommend an IANA assignment policy for currently unassigned ICP values. In the first task, this document is a partial replacement for RFC 1888 -- particularly for section 6 of RFC 1888. In the second task, this document incorporates wording and specifications from ITU-T Recommendation X.213 and further recommends that IANA use the "IETF consensus" assignment policy in making future ICP assignments.
このドキュメントは、2つの高度に関連するタスクを達成することを目的としています。ネットワークサービスアクセスポイント（NSAP）アドレスでエンコードするIPv4およびIPv6アドレスのそれぞれの「初期」インターネットコードポイント（ICP）割り当てを確立すること、およびIANAの割り当てを推奨することを目的としています。現在割り当てられていないICP値のポリシー。最初のタスクでは、このドキュメントはRFC 1888（特にRFC 1888のセクション6の部分的な代替品）です。2番目のタスクでは、このドキュメントにはITU-T推奨X.213の文言と仕様が組み込まれており、IANAがIANAを使用することをさらに推奨しています。将来のICP割り当てを行う際の「IETFコンセンサス」割り当てポリシー。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions ................................................2
1.2. Acronyms and Terminology ...................................3
2. IANA Considerations .............................................3
3. Initial Allocations and Uses ....................................4
3.1. IPv4 Address Encoding in an NSAPA ..........................4
3.2. IPv6 Address Encoding in an NSAPA ..........................5
4. Security Considerations .........................................6
5. References ......................................................7
5.1. Normative References .......................................7
5.2. Informative References .....................................7
Section 6 of RFC 1888 [1888] previously provided for assignment of the initial Internet Code Point (ICP) value '0' for encoding an IPv6 address in a Network Service Access (or Attachment) Point [NSAP] address. RFC 1888 also defined multiple means for restricted encoding of an NSAP address in an IPv6 address.
RFC 1888 [1888]のセクション6 [1888]は、ネットワークサービスアクセス（または添付ファイル）ポイント[NSAP]アドレスでIPv6アドレスをエンコードするための初期インターネットコードポイント（ICP）値「0」の割り当てを以前に提供していました。RFC 1888は、IPv6アドレスのNSAPアドレスの制限されたエンコードの複数の手段も定義しました。
The means RFC 1888 defined for encoding NSAP addresses in IPv6 address format was heavily annotated with warnings and limitations that apply should this encoding be used. Possibly as a result, these encodings are not used and appear never to have been used in any IPv6 deployment. In addition, section 6 contains minor errors. As a result of these various considerations, RFC 1888 [1888] has been obsoleted and declared Historic by RFC 4048 [4048].
IPv6アドレス形式でNSAPアドレスをエンコードするために定義された平均RFC 1888には、このエンコーディングが使用された場合に適用される警告と制限が大きく注釈が付けられました。おそらくその結果、これらのエンコードは使用されず、IPv6の展開では使用されていないように見えます。さらに、セクション6には軽微なエラーが含まれています。これらのさまざまな考慮事項の結果として、RFC 1888 [1888]は、RFC 4048 [4048]によって歴史的に廃止され、宣言されています。
It is the belief of the authors of this document that the errors in section 6 of RFC 1888 resulted -- at least in part -- because the ITU-T specification [X.213] that originally assigned Authority and Format Identifier (AFI) '35' to IANA was not freely publicized, nor was it incorporated or explained using the mechanism commonly used in the IETF, i.e., an RFC.
この文書の著者の信念は、RFC 1888のセクション6のエラーが、少なくとも部分的には、元々権限と形式の識別子（AFI）を割り当てたITU-T仕様[X.213]のために生じたことです。35 'からIANAへは自由に公表されておらず、IETFで一般的に使用されるメカニズム、つまりRFCを使用して組み込まれたり説明したりしませんでした。
It is therefore part of the purpose of this document to provide that explanation.
したがって、このドキュメントの目的の一部は、その説明を提供することです。
In addition, because there are other documents that refer to the IPv6 ICP assignment in RFC 1888, it is necessary for the errors in section 6 of RFC 1888 to be corrected, irrespective of the RFC's ultimate status.
さらに、RFC 1888のIPv6 ICP割り当てを参照する他のドキュメントがあるため、RFC 1888のセクション6のエラーを修正する必要があります。
Finally, no previous RFC (including RFC 1888) has ever formalized an assignment of an IPv4 ICP. This may have been in part because of a lack of formal definition of an IANA assignment policy for ICP values under the IANA-allocated AFI ('35').
最後に、以前のRFC（RFC 1888を含む）は、IPv4 ICPの割り当てを正式化したことはありません。これは、IANAに割り当てられたAFI（ '35'）に基づくICP値のIANA割り当てポリシーの正式な定義がないことのために、一部である可能性があります。
This document replaces section 6 of RFC 1888 in defining the ICP for IPv6 address encoding in an NSAP address, and it formalizes the ICP assignment for IPv4 address encoding in an NSAP address.
このドキュメントは、NSAPアドレスでエンコードするIPv6アドレスのICPを定義する際に、RFC 1888のセクション6に代わって、NSAPアドレスでエンコードするIPv4アドレスのICP割り当てを形式化します。
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 [2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [2119]に記載されているように解釈される。
AFI - Authority and Format Identifier BCD - Binary Coded Decimal DSP - Domain Specific Part IANA - Internet Assigned Numbers Authority ICP - Internet Code Point IDI - Initial Domain Identifier IDP - Initial Domain Part IETF - Internet Engineering Task Force ISO - International Organization for Standardization NSAP - Network Service Access (or Attachment) Point (often NSAPA) NSAPA - NSAP Address; 20-Octet Address Format OSI - Open Systems Interconnection RFC - Request For Comments WIP - Work In Progress
AFI-権限およびフォーマット識別子BCD-バイナリコーディングされた小数DSP-ドメイン固有のパートIANA-インターネット割り当て番号権限ICP-初期ドメイン識別子IDP-初期ドメインパートIETF -INTERNERTENGINEERING TASK FORCE ISO-国際標準化NSAP - ネットワークサービスアクセス（または添付ファイル）ポイント（多くの場合NSAPA）NSAPA -NSAPアドレス。20 -OCTETアドレスフォーマットOSI-オープンシステムの相互接続RFC-コメントのリクエストWIP-進行中の作業
An ITU-T Recommendation [X.213] has allocated two AFIs designating IANA as the assignment authority. One of these two AFIs ('34') is allocated for assignment of NSAPA in Decimal Numeric Format. This document does not address allocation for this AFI as it is not clear what use (if any) can be made of this encoding format at this time. The other AFI ('35') is to be used for binary encoding except as noted below.
ITU-Tの推奨[X.213]は、IANAを割り当て当局として指定する2つのAFIを割り当てました。これら2つのAFI（ '34'）の1つは、10進数形式でNSAPAを割り当てるために割り当てられています。このドキュメントは、この時点でこのエンコード形式で使用できる（もしあれば）使用できることは明らかではないため、このAFIの割り当てに対処しません。他のAFI（ '35'）は、以下の場合を除き、バイナリエンコードに使用されます。
The NSAPA format consists of an Initial Domain Part (IDP) and Domain Specific Part (DSP). The IDP, in turn, consists of an Authority and Format Identifier (AFI) and an Initial Domain Identifier (IDI). The AFI is defined to be a binary octet, and the IDI is defined to be a four decimal digit number encoded in two octets using Binary Coded Decimal format. Each nibble of the IDI is used to represent a decimal digit, using binary value '0000' through '1001'.
NSAPA形式は、初期ドメインパーツ（IDP）とドメイン固有のパーツ（DSP）で構成されています。IDPは、順番に、権限とフォーマット識別子（AFI）と初期ドメイン識別子（IDI）で構成されています。AFIはバイナリオクテットであると定義され、IDIはバイナリコード化された小数形式を使用して2オクテットでエンコードされた4桁の数桁数であると定義されています。IDIの各ニブルは、バイナリ値「0000」を使用して「1001」を使用して、10進数を表すために使用されます。
In assigning allocation authority for AFI '35' to IANA, the ITU-T Recommendation [X.213] specifies that the two-octet IDI will be used to hold an Internet Code Point (ICP) that, because of the decimal encoding, MUST be in the decimal range from '0' to '9999'.
AFI '35'の割り当て局をIANAに割り当てる際に、ITU-Tの推奨[X.213]は、2オクテットのIDIを使用して、小数点以下のエンコードのために、必要なものであることを指定します。「0」から「9999」までの小数の範囲になります。
The ITU-T recommendation assumes the assignment of ICP '0' (zero) for IPv6 address encoding in a Network Service Access Point Address (NSAPA, or often NSAP). In addition, ITU-T assumed that IANA would assign an ICP for IPv4 address encoding in an NSAPA and X.213 assumed that the ICP value for this purpose would be '1'.
ITU-Tの推奨は、ネットワークサービスアクセスポイントアドレス（NSAPA、またはしばしばNSAP）でエンコードするIPv6アドレスのICP '0'（ゼロ）の割り当てを想定しています。さらに、ITU-Tは、IANAがNSAPAでエンコードするIPv4アドレスにICPを割り当てると想定し、X.213はこの目的のICP値が「1」になると仮定しました。
In an NSAPA, the DSP is the remaining octets after the IDP. For AFI '35', this is 17 octets having a format as defined by IANA or as defined by another party and published with IANA consent.
NSAPAでは、DSPはIDP後の残りのオクテットです。AFI '35'の場合、これはIANAによって定義されているか、別の当事者によって定義され、IANAの同意で公開された形式を持つ17オクテットです。
IANA, as the authority responsible for AFI '35', SHOULD NOT assign an ICP unless there is a corresponding defined, and published, format at the time of the code point assignment.
IANAは、AFI '35'を担当する当局として、コードポイントの割り当て時に対応する定義および公開形式がない限り、ICPを割り当てるべきではありません。
The IANA has assigned the following ICP values:
IANAは、次のICP値を割り当てました。
ICP Value Address Encoding Format Definition
---------- ----------------- ----------------------------
'0' IPv6 RFC 4548, section 3.2
'1' IPv4 RFC 4548, section 3.1
Remaining decimal values '2' through '9999' MUST be assigned on an IETF consensus basis [2434].
残りの小数値「2」から「9999」は、IETFコンセンサスベースで割り当てる必要があります[2434]。
This document continues the ICP assignment and format definition as previously defined in RFC 1888, and it formalizes the allocation of ICP value '1' for IPv4 encoding and the format to be used. The sections below describe the specific IPv4 and IPv6 address encoding formats.
このドキュメントは、RFC 1888で以前に定義されたICP割り当てと形式の定義を継続し、IPv4エンコードのICP値 '1'の割り当てと使用する形式を形式化します。以下のセクションでは、特定のIPv4およびIPv6アドレスエンコード形式について説明します。
If it is required, for whatever reason, to embed an IPv4 address inside a 20-octet NSAP address, then the following format MUST be used. Note: alignment is an artifact of existing NSAPA usage.
何らかの理由で、20-OCTET NSAPアドレス内にIPv4アドレスを埋め込む必要がある場合は、次の形式を使用する必要があります。注：アラインメントは、既存のNSAPA使用量のアーティファクトです。
A specific possible use of this embedding is to express an IP address within the ATM Forum address format. Another possible use would be to allow Connectionless Network Protocol (CLNP) packets that encapsulate IPv4 packets to be routed in a CLNP network using the IPv4 address architecture. Several leading octets of the IPv4 address could be used as a CLNP routing prefix.
この埋め込みの特定の使用は、ATMフォーラムアドレス形式内でIPアドレスを表現することです。別の使用可能な使用は、IPv4アドレスアーキテクチャを使用してIPv4パケットをCLNPネットワークでルーティングできるようにするConnectionless Network Protocol（CLNP）パケットを許可することです。IPv4アドレスのいくつかの主要なオクテットを、CLNPルーティングプレフィックスとして使用できます。
An NSAPA with an AFI value of '35' and an ICP value of '1' (one) encodes a 4-octet IPv4 address in the first 4 octets of the DSP. The last 13 octets of the DSP are unspecified in this document. To maintain compatibility with both NSAP format and IPv4 addressing, these octets MUST be present, but have no intrinsic significance for IPv4. The default values for the unspecified octets is zero.
AFI値の「35」と「1」のICP値を持つNSAPAは、DSPの最初の4オクテットで4-OCTET IPv4アドレスをエンコードします。DSPの最後の13オクテットは、このドキュメントでは不特定です。NSAP形式とIPv4アドレス指定の両方との互換性を維持するには、これらのオクテットが存在する必要がありますが、IPv4にとって本質的な重要性はありません。不特定のオクテットのデフォルト値はゼロです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | AFI = 0x35 | ICP = 0001 | IPv4 (octet 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv4 (octets 1-3) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An NSAPA with the IANA AFI code and ICP set to '1' (one) is converted to an IPv4 address by stripping off the first 3 and the last 13 octets. If the NSAP-addressed contents are passed to a higher layer, the last 13 octets SHOULD be presented to the higher layer as well.
IANA AFIコードとICPセットを「1」（1）に設定したNSAPAは、最初の3と最後の13オクテットを除去することにより、IPv4アドレスに変換されます。NSAPがアドレスした内容がより高い層に渡される場合、最後の13個のオクテットも高層に提示する必要があります。
If an NSAP address using this encoding is used for routing in an IPv4 routing architecture, only the 4-octet IPv4 address MAY be considered.
このエンコードを使用してNSAPアドレスがIPv4ルーティングアーキテクチャでのルーティングに使用される場合、4-OCTET IPv4アドレスのみを考慮することができます。
If it is required, for whatever reason, to embed an IPv6 address inside a 20-octet NSAP address, then the following format MUST be used. Note: alignment is an artifact of existing NSAPA usage.
何らかの理由で、20-OCTET NSAPアドレス内にIPv6アドレスを埋め込む必要がある場合は、次の形式を使用する必要があります。注：アラインメントは、既存のNSAPA使用量のアーティファクトです。
A specific possible use of this embedding is to express an IP address within the ATM Forum address format. Another possible use would be to allow CLNP packets that encapsulate IPv6 packets to be routed in a CLNP network using the IPv6 address architecture. Several leading octets of the IPv6 address could be used as a CLNP routing prefix.
この埋め込みの特定の使用は、ATMフォーラムアドレス形式内でIPアドレスを表現することです。別の可能な用途は、IPv6パケットをカプセル化するCLNPパケットを、IPv6アドレスアーキテクチャを使用してCLNPネットワークでルーティングできるようにすることです。IPv6アドレスのいくつかの主要なオクテットをCLNPルーティングプレフィックスとして使用できます。
An NSAPA with an AFI value of '35' and an ICP value of '0' (zero) encodes a 16-octet IPv6 address in the first 16 octets of the DSP. The last octet of the DSP is a selector. To maintain compatibility with both NSAP format and IPv6 addressing, this octet MUST be present, but it has no intrinsic significance for IPv6. Its default value is zero, but other values may be used as specified for any specific application. For example, this octet may be used to specify one of 255 possible port numbers.
「35」のAFI値と「0」（ゼロ）のICP値を持つNSAPAは、DSPの最初の16オクテットで16オクテットIPv6アドレスをエンコードします。DSPの最後のオクテットはセレクターです。NSAP形式とIPv6アドレス指定の両方との互換性を維持するには、このオクテットが存在する必要がありますが、IPv6にとって本質的な重要性はありません。デフォルト値はゼロですが、特定のアプリケーションで指定されているように、他の値を使用できます。たとえば、このオクテットは、255の可能なポート番号のいずれかを指定するために使用できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0-3 | AFI = 0x35 | ICP = 0000 | IPv6 (octet 0)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4-7 | IPv6 (octets 1-4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8-11 | IPv6 (octets 5-8) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12-15| IPv6 (octets 9-12) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-19| IPv6 (octets 13-15) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An NSAPA with the IANA AFI code and ICP set to '0' (zero) is converted to an IPv6 address by stripping off the first 3 octets and the 20th octet. If the NSAP-addressed contents are passed to a higher layer, the last octet SHOULD be presented to the higher layer as well.
IANA AFIコードとICPセットを「0」（ゼロ）に設定したNSAPAは、最初の3オクテットと20番目のオクテットを除去することにより、IPv6アドレスに変換されます。NSAPがアドレスした内容がより高い層に渡される場合、最後のオクテットも高層に提示する必要があります。
If an NSAP address using this encoding is used for routing in an IPv6 routing architecture, only the 16-octet IPv6 address MAY be considered.
このエンコードを使用してNSAPアドレスがIPv6ルーティングアーキテクチャでのルーティングに使用される場合、16-OCTET IPv6アドレスのみを考慮することができます。
The NSAP encoding of IPv4 and IPv6 addresses is compatible with the corresponding security mechanisms of RFC 4301 [4301], hence this document introduces no new security exposure in the Internet.
IPv4およびIPv6アドレスのNSAPエンコードは、RFC 4301 [4301]の対応するセキュリティメカニズムと互換性があるため、このドキュメントではインターネットに新しいセキュリティエクスポージャーが導入されません。
[4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[NSAP] International Organization for Standardization, "Information technology - Open Systems Interconnection - Network service Definition", ISO/IEC 8348:2002, 2002.
[NSAP]国際標準化機関、「情報技術 - オープンシステムの相互接続 - ネットワークサービス定義」、ISO/IEC 8348：2002、2002。
[X.213] ITU-T Recommendation X.213, X-Series Recommendations, Data Networks and Open Systems Communications, October, 2001.
[X.213] ITU-Tの推奨X.213、Xシリーズの推奨事項、データネットワーク、およびオープンシステム通信、2001年10月。
[2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[1888] Bound, J., Carpenter, B., Harrington, D., Houldsworth, J., and A. Lloyd, "OSI NSAPs and IPv6", RFC 1888, August 1996.
[1888] Bound、J.、Carpenter、B.、Harrington、D.、Houldsworth、J.、およびA. Lloyd、 "Osi nsaps and IPv6"、RFC 1888、1996年8月。
[4048] Carpenter, B., "RFC 1888 Is Obsolete", RFC 4048, April 2005.
[4048] Carpenter、B。、「RFC 1888は時代遅れ」、RFC 4048、2005年4月。
Authors' Addresses
著者のアドレス
Eric Gray Ericsson 900 Chelmsford Street Lowell, MA, 01851
エリック・グレイ・エリクソン900チェルムスフォード・ストリート・ローウェル、マサチューセッツ州、01851
EMail: Eric.Gray@Marconi.com
John Rutemiller Ericsson 3000 Marconi Drive Warrendale, PA, 15086-7502
ジョン・ルートミラーエリクソン3000マルコーニドライブペンシルバニア州ワーレンデール、15086-7502
EMail: John.Rutemiller@Marconi.com
George Swallow Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA, 01719
George Swallow Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA、01719
EMail: swallow@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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エディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。