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.
著作権（C）インターネット協会（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.
このメモは、テキサス大学オースティン校が主催するインターネットリサーチタスクフォースのネットワーク管理研究グループ（NMRG）（IRTF）の第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回会合（ピッツバーグ、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）は、情報やデータモデリングで使用される用語の調和にその第八ワークショップ（オースチン、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]）。ほとんどの他の文書と比較すると、この1は、提案された定義の根拠を説明し、例を提供します。
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およびDMSが異なっているということでした。
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のもう一つの重要な特徴は、管理対象オブジェクト間の関係を定義することです。
DMs, conversely, are defined at a lower level of abstraction and include many details. They are intended for implementors and include protocol-specific constructs.
DMSは、逆に、抽象化の低いレベルで定義され、多くの詳細が含まれます。彼らは、実装者を対象としており、プロトコル固有の構文が含まれています。
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との間の関係は、上記の図に示されています。概念モデルは、様々な方法で実装することができるので、複数のDMSは、単一の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およびDMSは異なる目的を果たすが、正確に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.
設計者は、事業者がモデル化されたオブジェクトを理解するために、管理された環境を記述し、説明と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.
インスタントメッセージの重要な特徴は、彼らができる（一般的にすべきである）オブジェクト間の関係を指定することです。組織はDMに含めることができる機能を区切るためにIMの内容を使用してもよいです。
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
インスタントメッセージは、英語などの自然言語を使用して、非公式な方法で定義することができます。そのようなIMの例はDiffservのルータの概念モデルを説明し、管理する必要のあるそのようなルータのコンポーネント間の関係を指定するRFC 3290 [9]によって提供されます。 IETF内で、しかし、IMを明示的に記載されていることが例外であり、さらによりIM及びDMが別のRFCで指定すること。 DMを定義文書は、通常、標準化過程をたどる一方、そのような場合には、IMを指定文書[4]通常の情報RFCです。一般的に、ほとんどのの
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.
SNMP管理情報ベース（MIB）モジュールを定義するRFCは、そのMIBモジュールの背後にあるモデルの一部を説明する非公式の記述のいくつかの種類があります。このようなモデルは、IMの文書とみなすことができます。この例は、「インタフェースグループMIB」[10]を定義するRFC 2863、です。しかし、これまでに公表され、ほとんどの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].
代替的に、インスタントメッセージは形式言語またはセミフォーマル構造化言語を用いて定義することができます。正式にインスタントメッセージを指定するための可能性のうちの1つは、統一モデリング言語（UML）のクラス図を使用することです。そのような図はまだめったにIETF内で使用されていないが、他のいくつかの組織が日常DMTF、ITU-TのSG 4、3GPP SA5、テレマネージメントフォーラム、およびATMフォーラムなどの、インスタントメッセージを定義するためにそれらを使用します。 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].
IETF内で定義されたモジュール管理情報ベース（MIB）は、O。これらの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].
IETF内で開発Oポリシー情報ベース（PIB）モジュール、。その構文は、SMIに近く、また、ASN.1から誘導される（SPPI）[2]「ポリシーのプロビジョニング情報の構造」によって定義される[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の構文は[7]「管理オブジェクトの定義のためのガイドライン」（GDMO）に指定されています。 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 CIMスキーマは、DMTFの中で開発します。グラフィカルとテキスト：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のポインタとして実装またはINDEX句で指定されたインデックスの関係を通じて実現されます。他の多くの実装固有の詳細は、このようなMAX-ACCESSおよびSTATUS句と適合ステートメントとして、含まれています。
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によって定義されたSMIng言語です。この言語はでSMIv1 / SMIv2のとSPPIよりも高い概念レベルで設計されました。実際には、SMIng背後にある意図の一つは、IETF内で異なるDM言語の増殖を停止するために、さまざまなモデルを調和させることでした。結果として、SMIngで定義されたMIBおよびPIBモジュールは、異なる基礎となるプロトコルにマッピングすることができます。 SNMPのマッピングとCOPS-PR上の別のマッピングがあります。 SMIngは、したがって、他のIETFのアプローチよりも中立以上のプロトコルです。また、いくつかのオブジェクト指向の原則をサポートし、新しい機能（例えば、メソッドのサポート）の添加を可能にする拡張メカニズムを提供します。彼らは基本的なプロトコルによってサポートされているときに、新しい機能は、SMIng実装を壊すことなく、使用することができます。それでも、SMIngは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ワークショップに参加したみんなに感謝したいと思います：サボルチボロス、マーカスブルンナー、デビッド・ダーラム、デイブ・ハリントン、ジャン・フィリップ・マルタンFlatin、ジョージ・パブルー、ロバートParhonyi、デビッド・パーキンス、デビッドSIDOR 、アンドレアWesterinenとバート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.、パーキンス、D.およびJ. Schoenwaelder、STD 58、RFC 2578、1999年4月 "管理情報バージョン2（SMIv2）の構造"。
[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.、ファイン、M.、Seligson、J.、チャン、K.、ハーン、S.、Sahita、R.、スミス、A.及びSPPI F. Reichmeyer、「ポリシーのプロビジョニング情報の構造（ ）」、RFC 3159、2001年8月。
[3] Distributed Management Task Force, "Common Information Model (CIM) Specification Version 2.2", DSP 0004, June 1999.
[3]分散管理タスクフォース、 "共通情報モデル（CIM）仕様バージョン2.2"、DSP 0004、1999年6月。
[4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[4]ブラドナー、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]国際電気通信連合、「情報技術 - 開放型システム間相互接続 - 管理情報の構造：管理オブジェクトの定義のためのガイドライン」、勧告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.、クイン、B.、ヘルツォーク、S.、フイン、A.、カールソン、M.、ペリー、J.、および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.、ブレイク、S.、グロスマン、D.とA.スミス、 "Diffservのルータのための非公式の管理モデル"、RFC 3290、2002年5月。
[10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[10] McCloghrie、K.およびF. Kastenholzと、 "インターフェイスグループMIB"、RFC 2863、2000年6月。
Aiko Pras University of Twente PO Box 217 7500 AE Enschede The Netherlands
愛子PRAS大学トウェンテの私書箱217 7500 AEエンスヘーデオランダ
Phone: +31 53 4893778 EMail: pras@ctit.utwente.nl
電話：+31 53 4893778 Eメール：pras@ctit.utwente.nl
Juergen Schoenwaelder University of Osnabrueck Albrechtstr. 28 49069 Osnabrueck Germany
オスナブリュックAlbrechtstrのユルゲンSchoenwaelder大学。 28 49069オスナブリュックドイツ
Phone: +49 541 969-2483 EMail: schoenw@informatik.uni-osnabrueck.de
電話：+49 541 969-2483 Eメール：schoenw@informatik.uni-osnabrueck.de
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。