[要約] 要約：RFC 3444は、情報モデルとデータモデルの違いについて説明しており、情報モデルは抽象的な概念を表現し、データモデルは具体的なデータの表現方法を示すことを目的としています。目的：RFC 3444の目的は、情報モデルとデータモデルの違いを明確にし、それぞれの役割と目的を理解することです。
Network Working Group A. Pras
Request for Comments: 3444 University of Twente
Category: Informational J. Schoenwaelder
University of Osnabrueck
January 2003
On the Difference between Information Models and Data Models
情報モデルとデータモデルの違いについて
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
There has been ongoing confusion about the differences between Information Models and Data Models for defining managed objects in network management. This document explains the differences between these terms by analyzing how existing network management model specifications (from the IETF and other bodies such as the International Telecommunication Union (ITU) or the Distributed Management Task Force (DMTF)) fit into the universe of Information Models and Data Models.
ネットワーク管理で管理されたオブジェクトを定義するための情報モデルとデータモデルの違いについて、継続的な混乱がありました。このドキュメントでは、既存のネットワーク管理モデルの仕様（IETFおよび国際電気通信連合（ITU）や分散管理タスクフォース（DMTF）などの他の団体からの既存のネットワーク管理モデルの仕様が、情報モデルの世界にどのように適合するかを分析することにより、これらの用語の違いを説明します。データモデル。
This memo documents the main results of the 8th workshop of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) hosted by the University of Texas at Austin.
このメモは、テキサス大学オースティン校が主催するインターネット研究タスクフォース（IRTF）のネットワーク管理研究グループ（NMRG）の第8回ワークショップの主な結果を文書化しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Information Models . . . . . . . . . . . . . . . . . . . . . . 3
4. Data Models . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
8. Informative References . . . . . . . . . . . . . . . . . . . . 7
9. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
10. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
Currently multiple languages exist to define managed objects. Examples of such languages are the Structure of Management Information (SMI) [1], the Structure of Policy Provisioning Information (SPPI) [2] and, within the DMTF, the Managed Object Format (MOF) [3]. Despite the fact that multiple languages exist, a number of people still believe that none of these languages really suits all needs.
現在、管理されたオブジェクトを定義するために複数の言語が存在しています。このような言語の例は、管理情報の構造（SMI）[1]、ポリシープロビジョニング情報の構造（SPPI）[2]、およびDMTF内で、管理されたオブジェクト形式（MOF）[3]です。複数の言語が存在するという事実にもかかわらず、多くの人々は依然としてこれらの言語のどれもすべてのニーズに適していないと信じています。
There have been many discussions to understand the advantages and disadvantages, as well as the main differences, between various languages. For instance, the IETF organized a BoF on "Network Information Modeling" (NIM) at its 48th meeting (Pittsburgh, August 2000). During these discussions, it turned out that people had a different understanding of the main terms, which caused confusion and long arguments. In particular, the meaning of the terms "Information Model" (IM) and "Data Model" (DM) turned out to be controversial.
さまざまな言語間の主な違いだけでなく、利点と欠点、および主な違いを理解するための多くの議論がありました。たとえば、IETFは、第48回会議（Pittsburgh、2000年8月）で「ネットワーク情報モデリング」（NIM）に関するBOFを編成しました。これらの議論の中で、人々は主要な用語について異なる理解を持っていることが判明し、それが混乱と長い議論を引き起こしました。特に、「情報モデル」（IM）および「データモデル」（DM）という用語の意味は議論の余地があることが判明しました。
In an attempt to address this issue, the IRTF Network Management Research Group (NMRG) dedicated its 8th workshop (Austin, December 2000) to harmonizing the terminology used in information and data modeling. Attendees included experts from the IETF, DMTF and ITU, as well as academics who do research in this field (see the Acknowledgments section for a list of participants). The main outcome of this successful workshop -- a better understanding of the terms "Information Model" and "Data Model" -- is presented in this document.
この問題に対処するために、IRTFネットワーク管理研究グループ（NMRG）は、情報とデータモデリングで使用される用語を調和させるために、第8回ワークショップ（オースティン、2000年12月）を捧げました。参加者には、IETF、DMTF、ITUの専門家、およびこの分野で研究を行う学者が含まれていました（参加者のリストについては、謝辞セクションを参照）。この成功したワークショップの主な結果 - 「情報モデル」と「データモデル」という用語のより良い理解 - は、このドキュメントに示されています。
Short definitions of these terms can also be found elsewhere (e.g., in RFC 3198 [8]). Compared to most other documents, this one explains the rationale behind the proposed definitions and provides examples.
これらの用語の短い定義は、他の場所にも見つけることができます（例：RFC 3198 [8]）。他のほとんどの文書と比較して、この文書は提案された定義の背後にある理論的根拠を説明し、例を提供します。
One of the key observations made at the NMRG workshop was that IMs and DMs are different because they serve different purposes.
NMRGワークショップで行われた重要な観察結果の1つは、IMSとDMが異なる目的を果たすため、異なることです。
The main purpose of an IM is to model managed objects at a conceptual level, independent of any specific implementations or protocols used to transport the data. The degree of specificity (or detail) of the abstractions defined in the IM depends on the modeling needs of its designers. In order to make the overall design as clear as possible, an IM should hide all protocol and implementation details. Another important characteristic of an IM is that it defines relationships between managed objects.
IMの主な目的は、データの輸送に使用される特定の実装またはプロトコルとは無関係に、概念レベルで管理されたオブジェクトをモデル化することです。IMで定義された抽象化の特異性（または詳細）の程度は、デザイナーのモデリングニーズに依存します。全体的な設計を可能な限り明確にするために、IMはすべてのプロトコルと実装の詳細を非表示にする必要があります。IMのもう1つの重要な特徴は、管理されたオブジェクト間の関係を定義することです。
DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs.
逆に、DMはより低いレベルの抽象化で定義され、多くの詳細が含まれています。それらは実装者向けであり、プロトコル固有の構成要素を含みます。
IM --> conceptual/abstract model
| for designers and operators
+----------+---------+
| | |
DM DM DM --> concrete/detailed model
for implementors
The relationship between an IM and DM is shown in the Figure above. Since conceptual models can be implemented in different ways, multiple DMs can be derived from a single IM.
IMとDMの関係は、上の図に示されています。概念モデルはさまざまな方法で実装できるため、複数のDMを単一のIMから導出できます。
Although IMs and DMs serve different purposes, it is not always possible to precisely define what kind of details should be expressed in an IM and which ones belong in a DM. There is a gray area where IMs and DMs overlap -- just like there are gray areas between the models produced during the analysis, high-level design and low-level design phases in object-oriented software engineering. In some cases, it is very difficult to determine whether an abstraction belongs to an IM or a DM.
IMSとDMはさまざまな目的に役立ちますが、IMでどのような詳細を表現するか、どの種類の詳細をDMに属しているかを正確に定義することが常に可能であるとは限りません。IMSとDMSが重複する灰色の領域があります。分析中に生成されたモデルの間に灰色の領域があり、オブジェクト指向のソフトウェアエンジニアリングにおける高レベルの設計、低レベルの設計フェーズがあります。場合によっては、抽象化がIMに属しているかDMに属しているかを判断することは非常に困難です。
IMs are primarily useful for designers to describe the managed environment, for operators to understand the modeled objects, and for implementors as a guide to the functionality that must be described and coded in the DMs. The terms "conceptual models" and "abstract models", which are often used in the literature, relate to IMs. IMs can be implemented in different ways and mapped on different protocols. They are protocol neutral.
IMSは主に、設計者が管理された環境を説明し、オペレーターがモデル化されたオブジェクトを理解し、DMSで説明およびコーディングする必要がある機能のガイドとして、実装者が主に役立ちます。文献でよく使用される「概念モデル」と「抽象モデル」という用語は、IMSに関連しています。IMSはさまざまな方法で実装し、異なるプロトコルにマッピングできます。それらはプロトコルニュートラルです。
An important characteristic of IMs is that they can (and generally should) specify relationships between objects. Organizations may use the contents of an IM to delimit the functionality that can be included in a DM.
IMSの重要な特徴は、オブジェクト間の関係を指定できる（そして一般的にすべき）ことです。組織は、IMのコンテンツを使用して、DMに含めることができる機能を区切ることができます。
IMs can be defined in an informal way, using natural languages such as English. An example of such an IM is provided by RFC 3290 [9], which describes a conceptual model of a Diffserv Router and specifies the relationships between the components of such a router that need to be managed. Within the IETF, however, it is exceptional that an IM be explicitly described, and even more that the IM and DM be specified in separate RFCs. In such cases, the document specifying the IM is usually an Informational RFC whereas the document defining the DM usually follows the Standards Track [4]. In general, most of the RFCs that define an SNMP Management Information Base (MIB) module also include some kind of informal description explaining parts of the model behind that MIB module. Such a model can be considered as a document of an IM. An example of this is RFC 2863, which defines "The Interfaces Group MIB" [10]. But most MIB modules published to date include only a rudimentary and incomplete description of the underlying IM.
IMSは、英語などの自然言語を使用して、非公式の方法で定義できます。そのようなIMの例は、Diffservルーターの概念モデルを説明し、管理する必要があるルーターのコンポーネント間の関係を指定するRFC 3290 [9]によって提供されます。ただし、IETF内では、IMが明示的に記述されることは例外的であり、さらに多くのRFCでIMとDMが指定されることは例外的です。そのような場合、IMを指定するドキュメントは通常情報RFCですが、DMを定義するドキュメントは通常、標準トラック[4]に従います。一般に、SNMP管理情報ベース（MIB）モジュールを定義するRFCのほとんどには、そのMIBモジュールの背後にあるモデルの部分を説明する何らかの非公式の説明も含まれています。このようなモデルは、IMの文書と見なすことができます。この例はRFC 2863で、「インターフェイスグループMIB」[10]を定義します。しかし、これまでに公開されたほとんどのMIBモジュールには、基礎となるIMの初歩的で不完全な説明のみが含まれています。
Alternatively, IMs can be defined using a formal language or a semi-formal structured language. One of the possibilities to formally specify IMs is to use class diagrams of the Unified Modeling Language (UML). Although such diagrams are still rarely used within the IETF, several other organizations routinely use them for defining IMs, including the DMTF, the ITU-T SG 4, 3GPP SA5, the TeleManagement Forum, and the ATM Forum. An important advantage of UML class diagrams is that they represent objects and the relationships between them in a standard graphical way. Because of this graphical representation, designers and operators may find it easier to understand the underlying management model. Although there are other techniques to graphically represent objects and relationships (e.g., Entity-Relationship (ER) diagrams), UML presents the advantage of being widely adopted in the industry and taught in universities. Also, many tools for editing UML diagrams are now available. UML is standardized by the Object Management Group (OMG) [5].
あるいは、IMSは、正式な言語または半形式の構造化言語を使用して定義できます。IMSを正式に指定する可能性の1つは、Unified Modeling Language（UML）のクラス図を使用することです。このような図はIETF内で依然として使用されていませんが、他のいくつかの組織は、DMTF、ITU-T SG 4、3GPP SA5、TeleMenagementフォーラム、ATMフォーラムなど、IMSを定義するために日常的に使用しています。UMLクラス図の重要な利点は、それらがオブジェクトとそれらの間の関係を標準的なグラフィカルな方法で表すことです。このグラフィカルな表現のため、デザイナーとオペレーターは、基礎となる管理モデルを理解しやすいと感じるかもしれません。オブジェクトと関係をグラフィカルに表す他の手法（例：エンティティ関連（ER）図）がありますが、UMLは業界で広く採用され、大学で教えられているという利点を提示します。また、UML図を編集するための多くのツールが利用可能になりました。UMLは、オブジェクト管理グループ（OMG）[5]によって標準化されています。
In general, it seems advisable to use object-oriented techniques to describe an IM. In particular, the notions of abstraction and encapsulation, as well as the possibility that object definitions include methods, are considered to be important.
一般に、オブジェクト指向の手法を使用してIMを説明することをお勧めします。特に、抽象化とカプセル化の概念、およびオブジェクトの定義にメソッドが含まれる可能性が重要であると考えられています。
Compared to IMs, DMs define managed objects at a lower level of abstraction. They include implementation- and protocol-specific details, e.g. rules that explain how to map managed objects onto lower-level protocol constructs.
IMSと比較して、DMSは、より低いレベルの抽象化で管理されたオブジェクトを定義します。実装およびプロトコル固有の詳細が含まれます。管理されたオブジェクトを低レベルのプロトコルコンストラクトにマッピングする方法を説明するルール。
Most of the management models standardized to date are DMs. Examples include:
これまで標準化された管理モデルのほとんどはDMSです。例は次のとおりです。
o Management Information Base (MIB) modules defined within the IETF. The language (syntax) used to define these DMs is called the "Structure of Management Information" (SMI) [1] and is derived from ASN.1 [6].
o IETF内で定義された管理情報ベース（MIB）モジュール。これらのDMを定義するために使用される言語（構文）は「管理情報の構造」（SMI）[1]と呼ばれ、ASN.1 [6]に由来しています。
o Policy Information Base (PIB) modules, developed within the IETF. Their syntax is defined by the "Structure of Policy Provisioning Information" (SPPI) [2], which is close to SMI and is also derived from ASN.1 [6].
o IETF内で開発されたポリシー情報ベース（PIB）モジュール。それらの構文は、「ポリシープロビジョニング情報の構造」（SPPI）[2]によって定義されます。これはSMIに近く、ASN.1 [6]にも由来しています。
o Management Information Base (MIB) modules, originally defined by the ISO and currently maintained and enhanced by the ITU-T. The syntax of these DMs is specified in the "Guidelines for the Definition of Managed Objects" (GDMO) [7]. GDMO MIB modules make use of object-oriented principles.
o 経営情報ベース（MIB）モジュールは、もともとISOによって定義されており、現在ITU-Tによって維持および強化されています。これらのDMの構文は、「管理されたオブジェクトの定義のガイドライン」（GDMO）[7]で指定されています。GDMO MIBモジュールは、オブジェクト指向の原則を使用します。
o CIM Schemas, developed within the DMTF. The DMTF publishes them in two forms: graphical and textual. The graphical forms use UML diagrams and are not normative (because not all details can be represented graphically). They can be downloaded from the DMTF Web site in PDF and Visio formats. (Visio is a tool to draw UML class diagrams.) The textual forms are normative and written in a language called the "Managed Object Format" (MOF) [3]. CIM Schemas are object-oriented.
o DMTF内で開発されたCIMスキーマ。DMTFは、グラフィカルとテキストの2つの形式で公開します。グラフィカルフォームはUML図を使用し、規範的ではありません（すべての詳細をグラフィカルに表現できるわけではないため）。PDFおよびVisio形式のDMTF Webサイトからダウンロードできます。（VisioはUMLクラスの図を描くためのツールです。）テキストフォームは規範的であり、「管理されたオブジェクト形式」（MOF）[3]と呼ばれる言語で書かれています。CIMスキーマはオブジェクト指向です。
Because CIM Schemas support a graphical notation whereas IETF MIB modules do not, designers and operators may find it easier to understand CIM Schemas than IETF MIB modules. One could therefore argue that CIM Schemas are closer to IMs than IETF MIB modules.
CIMスキーマはグラフィカルな表記をサポートしているのに対し、IETF MIBモジュールはそうではないため、設計者とオペレーターはIETF MIBモジュールよりもCIMスキーマを理解しやすいと感じるかもしれません。したがって、CIMスキーマはIETF MIBモジュールよりもIMSに近いと主張することができます。
The Figure below summarizes these examples. The languages that are used to define the DMs are shown between brackets.
以下の図は、これらの例をまとめたものです。DMの定義に使用される言語は、括弧間で表示されます。
IM --> IM
|
+----------+-------+-------+--------------+
| | | |
MIB PIB CIM schema OSI-MIB --> DM
(SMI) (SPPI) (MOF) (GDMO)
To illustrate what details are included in a DM, let us consider the example of IETF MIB modules. As opposed to IMs, IETF MIB modules include details such as OID assignments and indexing structures. The relationships defined in the IM are implemented as OID pointers or realized through indexing relationships specified in INDEX clauses. Many other implementation-specific details are included, such as MAX-ACCESS and STATUS clauses and conformance statements.
DMに含まれる詳細を説明するには、IETF MIBモジュールの例を考えてみましょう。IMSとは対照的に、IETF MIBモジュールには、OID割り当てやインデックス構造などの詳細が含まれています。IMで定義された関係は、OIDポインターとして実装されているか、インデックス条項で指定されたインデックス作成関係を通じて実現されます。Max-Accessやステータス条項や適合ステートメントなど、他の多くの実装固有の詳細が含まれています。
A special kind of DM language is the SMIng language defined by the NMRG. This language was designed at a higher conceptual level than SMIv1/SMIv2 and SPPI. In fact, one of the intentions behind SMIng was to stop the proliferation of different DM languages within the IETF and to harmonize the various models. As a result, MIB and PIB modules defined in SMIng can be mapped on different underlying protocols. There is a mapping on SNMP and another mapping on COPS-PR. SMIng is therefore more protocol neutral than other IETF approaches. It also supports some object-oriented principles and provides extension mechanisms that allow the addition of new features (e.g., the support for methods). New features can then be used when they are supported by the underlying protocols, without breaking SMIng implementations. Still, SMIng should be considered a DM. For instance, to express relationships between managed objects, techniques such as UML and ER diagrams still give better results because these diagrams are easier to understand.
特別な種類のDM言語は、NMRGによって定義されたスミング言語です。この言語は、SMIV1/SMIV2およびSPPIよりも高い概念レベルで設計されました。実際、Smingの背後にある意図の1つは、IETF内のさまざまなDM言語の増殖を停止し、さまざまなモデルを調和させることでした。その結果、スミングで定義されたMIBおよびPIBモジュールは、さまざまな基礎となるプロトコルでマッピングできます。SNMPにはマッピングがあり、COPS-PRの別のマッピングがあります。したがって、スミングは他のIETFアプローチよりもプロトコル中性です。また、いくつかのオブジェクト指向の原則をサポートし、新しい機能（方法のサポートなど）の追加を可能にする拡張メカニズムを提供します。その後、新しい機能は、スミングの実装を破ることなく、基礎となるプロトコルによってサポートされている場合に使用できます。それでも、スミングはDMと見なされるべきです。たとえば、管理されたオブジェクト間の関係を表現するために、UMLやER図などの手法は、これらの図を理解しやすいため、より良い結果が得られます。
Note that the IETF SMING Working Group took a different approach and decided not to use the SMIng language defined by the NMRG. Instead, the SMING Working Group is developing a third version of SMI (SMIv3) that is primarily targeted towards SNMP, and which incorporates only some of the ideas developed within the NMRG.
IETF SMINGワーキンググループは別のアプローチを取っており、NMRGによって定義されたSMING言語を使用しないことを決定したことに注意してください。代わりに、SMINGワーキンググループは、主にSNMPを対象としたSMI（SMIV3）の3番目のバージョンを開発しており、NMRG内で開発されたアイデアの一部のみを組み込んでいます。
The meaning of the terms Information Model and Data Model has no direct security impact on the Internet.
情報モデルとデータモデルという用語の意味は、インターネットに直接的なセキュリティの影響を与えません。
The authors would like to thank everyone who participated in the 8th NMRG workshop (in alphabetic order): Szabolcs Boros, Marcus Brunner, David Durham, Dave Harrington, Jean-Philippe Martin-Flatin, George Pavlou, Robert Parhonyi, David Perkins, David Sidor, Andrea Westerinen and Bert Wijnen.
著者は、第8回NMRGワークショップ（アルファベット順）に参加したすべての人に感謝したいと思います。SzabolcsBoros、Marcus Brunner、David Durham、Dave Harrington、Jean-Philippe Martin-Flatin、George Pavlou、Robert Parhonyi、David Sidor、Andrea WesterinenとBert Wijnen。
[1] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[1] McCloghrie、K.、Perkins、D。、およびJ. Schoenwaelder、「管理情報の構造バージョン2（SMIV2）」、STD 58、RFC 2578、1999年4月。
[2] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy Provisioning Information (SPPI)", RFC 3159, August 2001.
[2] McCloghrie、K.、Fine、M.、Seligson、J.、Chan、K.、Hahn、S.、Sahita、R.、Smith、A。and F. Reichmeyer、「政策プロビジョニング情報の構造（SPPI）」、RFC 3159、2001年8月。
[3] Distributed Management Task Force, "Common Information Model (CIM) Specification Version 2.2", DSP 0004, June 1999.
[3] 分散管理タスクフォース、「Common Information Model（CIM）仕様バージョン2.2」、DSP 0004、1999年6月。
[4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[4] Bradner、S。、「インターネット標準プロセス - リビジョン3」、BCP 9、RFC 2026、1996年10月。
[5] Object Management Group, "Unified Modeling Language (UML), Version 1.4", formal/2001-09-67, September 2001.
[5] オブジェクト管理グループ、「統一モデリング言語（UML）、バージョン1.4」、フォーマル/2001-09-67、2001年9月。
[6] International Organization for Standardization, "Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)", International Standard 8824, December 1987.
[6] 国際標準化機関、「情報処理システム - オープンシステムの相互接続 - 抽象的構文表記1（ASN.1）の仕様」、国際標準8824、1987年12月。
[7] International Telecommunication Union, "Information technology - Open Systems Interconnection - Structure of Management Information: Guidelines for the Definition of Managed Objects", Recommendation X.722, 1992.
[7] International Telecommunication Union、「情報技術 - オープンシステムの相互接続 - 管理情報の構造：管理されたオブジェクトの定義のガイドライン」、推奨X.722、1992。
[8] Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M., Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S. Waldbusser, "Terminology for Policy-Based Management", RFC 3198, November 2001.
[8] Westerinen、A.、Schnizlein、J.、Strassner、J.、Scherling、M.、Quinn、B.、Herzog、S.、Huynh、A.、Carlson、M.、Perry、J. and S. Waldbusser、 "ポリシーベースの管理の用語」、RFC 3198、2001年11月。
[9] Bernet, Y., Blake, S., Grossman, D. and A. Smith, "An Informal Management Model for Diffserv Routers", RFC 3290, May 2002.
[9] Bernet、Y.、Blake、S.、Grossman、D。and A. Smith、「Diffservルーターの非公式管理モデル」、RFC 3290、2002年5月。
[10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[10] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
Aiko Pras University of Twente PO Box 217 7500 AE Enschede The Netherlands
Aiko Pras University of Twente PO Box 217 7500 Ae Enschede The Netherlands
Phone: +31 53 4893778
EMail: pras@ctit.utwente.nl
Juergen Schoenwaelder University of Osnabrueck Albrechtstr. 28 49069 Osnabrueck Germany
Juergen Schoenwaelder Osnabrueck Albrechtstr大学。28 49069 Osnabrueckドイツ
Phone: +49 541 969-2483
EMail: schoenw@informatik.uni-osnabrueck.de
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エディター機能の資金は現在、インターネット協会によって提供されています。