RFC3444 日本語訳
3444 On the Difference between Information Models and Data Models. A.Pras, J. Schoenwaelder. January 2003. (Format: TXT=18596 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Pras
Request for Comments: 3444 University of Twente
Category: Informational J. Schoenwaelder
University of Osnabrueck
January 2003
Prasがコメントのために要求するワーキンググループA.をネットワークでつないでください: 3444年のTwenteカテゴリの大学: Osnabrueck2003年1月の情報のJ.Schoenwaelder大学
On the Difference between
Information Models and Data Models
情報モデルとデータモデルの違いに関して
Status of this Memo
この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)インターネット協会(2003)。 All rights reserved。
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.
ネットワークマネージメントで管理オブジェクトを定義するための情報ModelsとData Modelsの違いに関して進行中の混乱がありました。 このドキュメントで、既存のネットワーク管理モデル仕様(国際電気通信連合(ITU)かDistributed Management Task Force(DMTF)などのIETFと他のボディーからの)がどう情報ModelsとData Modelsの宇宙に収まるかを分析することによって、これらの用語の違いがわかります。
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.
このメモはテキサス大学オースティン校によって接待されたインターネットResearch Task Force(IRTF)のNetwork Management Research Group(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 概観. . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3。 情報は.3 4をモデル化します。 データは.4 5をモデル化します。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 6 6。 承認. . . . . . . . . . . . . . . . . . . . . . . 6 7。 引用規格. . . . . . . . . . . . . . . . . . . . . 6 8。 有益な参照. . . . . . . . . . . . . . . . . . . . 7 9。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 7 10。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 8
Pras & Schoenwaelder Informational [Page 1] RFC 3444 Information Models and Data Models January 2003
Pras&Schoenwaelderの情報[1ページ]のRFC3444情報モデルとデータは2003年1月にモデル化されます。
1. Introduction
1. 序論
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.
現在、複数の言語が、管理オブジェクトを定義するために存在しています。 そのような言語に関する例は、Management情報(SMI)[1]のStructureと、Policy Provisioning情報(SPPI)[2]のStructureとDMTFの中でManaged Object Format(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 Network Management Research Group(NMRG)は8番目のワークショップ(2000年12月のオースチン)を情報とデータのモデル化に使用される用語を調和させるのに捧げました。 出席者はIETF、DMTF、およびITUからの専門家を入れました、この分野で研究するアカデミー会員と同様に(関係者のリストに関してAcknowledgments部を見てください)。 このうまくいっているワークショップの主な結果(用語「情報モデル」と「データはモデル化する」の、より良い理解)は本書では提示されます。
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.
これらの用語の短い定義はそうすることができます、また、ほかの場所で見つけられてください。(例えば、RFC3198[8])で。 他のほとんどのドキュメントと比べて、これは、提案された定義の後ろで原理について説明して、例を提供します。
2. Overview
2. 概観
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の別の重要な特性は管理オブジェクトの間の関係を定義するということです。
Pras & Schoenwaelder Informational [Page 2] RFC 3444 Information Models and Data Models January 2003
Pras&Schoenwaelderの情報[2ページ]のRFC3444情報モデルとデータは2003年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.
DMsは逆に抽象化の下のレベルで定義されて、多くの詳細を含んでいます。 彼らは、作成者のために意図して、プロトコル特有の構造物を含んでいます。
IM --> conceptual/abstract model
| for designers and operators
+----------+---------+
| | |
DM DM DM --> concrete/detailed model
for implementors
IM-->の概念的であるか抽象的なモデル| デザイナーとオペレータ+のために----------+---------+ | | | DM DM DM--作成者のための>の具体的であるか詳細なモデル
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との関係は上の図に示されます。 異なった方法で概念モデルを実行できるので、独身のIMから複数のDMsを得ることができます。
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に属すかどうか決定するのは非常に難しいです。
3. Information Models
3. 情報モデル
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. 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の重要な特性が彼らがそうすることができるということである、(一般に、)、物の間の関係を指定するべきであってください。 組織は、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
英語などの自然言語を使用して、非公式の方法でIMsを定義できます。 そのようなIMに関する例は、RFC3290[9]によって提供されて、管理される必要があるそのようなルータのコンポーネントの間の関係を指定します。([9]はDiffserv Routerの概念モデルについて説明します)。 しかしながら、IETFの中では、IMが明らかに説明されていて、さらに多いのは、例外的です。IMとDMは別々のRFCsで指定されます。 そのような場合、IMを指定するドキュメントは通常Informational RFCですが、通常、DMを定義するドキュメントはStandards Track[4]に続きます。 一般に、だいたい
Pras & Schoenwaelder Informational [Page 3] RFC 3444 Information Models and Data Models January 2003
Pras&Schoenwaelderの情報[3ページ]のRFC3444情報モデルとデータは2003年1月にモデル化されます。
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 Management Information基地(MIB)のモジュールを定義するRFCsはそのMIBモジュールの後ろにモデルのある種の非公式の記述説明部分を含んでいます。 IMのドキュメントであるとそのようなモデルをみなすことができます。 この例はRFC2863です。(そのRFCは「インタフェースは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つは統一モデリング言語(UML)のクラスダイヤグラムを使用することです。 そのようなダイヤグラムはIETFの中でまだめったに使用されていませんが、他のいくつかの組織がIMsを定義するのにきまりきってそれらを使用します、DMTF、ITU-T SG4、3GPP SA5、TeleManagement Forum、およびATM Forumを含んでいて。 UMLクラスダイヤグラムの重要な利点は彼らが標準のグラフィカルな方法でそれらの間の物と関係を表すということです。 このグラフ表示のために、デザイナーとオペレータは、基本的なマネジメント・モデルを理解しているのが、より簡単であることがわかるかもしれません。 グラフィカルに、物と関係(例えば、Entity-関係(ER)ダイヤグラム)を表すために、他のテクニックがありますが、UMLは産業で広く採用されて、大学で教えられる利点を提示します。 また、UMLダイヤグラムを編集するための多くのツールも現在、利用可能です。 UMLはObject Management Group(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について説明するのにオブジェクト指向テクニックを使用するのは賢明に思えます。 特に、抽象化とカプセル化の概念、およびオブジェクト定義が方法を含んでいる可能性が重要であると考えられます。
4. Data Models
4. データモデル
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の中で定義された管理Information基地(MIB)のモジュール。 これらのDMsを定義するのに使用される言語(構文)を、「経営情報の構造」(SMI)[1]と呼んで、ASN.1[6]から得ます。
Pras & Schoenwaelder Informational [Page 4] RFC 3444 Information Models and Data Models January 2003
Pras&Schoenwaelderの情報[4ページ]のRFC3444情報モデルとデータは2003年1月にモデル化されます。
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の中で開発された方針Information基地(PIB)のモジュール。 それらの構文を「情報に食糧を供給する方針の構造」(SPPI)[2]で定義して、また、ASN.1[6]から得ます。(SMIの近くに[2]はあります)。
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 ITU-Tによって元々、ISOによって定義されて、現在、維持されて、高められた管理Information基地(MIB)のモジュール。 これらのDMsの構文は「管理オブジェクトの定義のためのガイドライン」(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 Schemas。 DMTFは2つのフォームでそれらを発行します: グラフィカルであって、原文です。 グラフィカルなフォームは、UMLダイヤグラムを使用して、規範的ではありません(グラフィカルにすべての詳細を表すことができるというわけではないので)。 PDFのDMTFウェブサイトとVisio形式からそれらをダウンロードできます。 (VisioはUMLクラスダイヤグラムを作成するツールです。) 原文のフォームは、標準で「管理オブジェクト形式」(MOF)[3]と呼ばれる言語で書かれています。 CIM Schemasはオブジェクト指向です。
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 Schemasがグラフィカルな記法を支持しますが、IETF MIBモジュールが支持するというわけではないので、デザイナーとオペレータは、それはIETF MIBモジュールよりCIM Schemasを理解しやすいのがわかるかもしれません。 したがって、1つは、CIM SchemasがIMsのIETF MIBモジュールより近くにあると主張するかもしれません。
The Figure below summarizes these examples. The languages that are used to define the DMs are shown between brackets.
以下の図はこれらの例をまとめます。 DMsを定義するのに使用される言語は括弧の間に示されます。
IM --> IM
|
+----------+-------+-------+--------------+
| | | |
MIB PIB CIM schema OSI-MIB --> DM
(SMI) (SPPI) (MOF) (GDMO)
不-、--、>、不-| +----------+-------+-------+--------------+ | | | | MIB PIB CIM図式オウシ-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節で指定された関係に索引をつけることで実現されます。 他の多くの実装時固有事項がマックス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
特別な種類のDM言語はNMRGによって定義されたSMIng言語です。 この言語はSMIv1/SMIv2とSPPIより高い概念的なレベルで設計されました。 事実上、SMIngの後ろの意志の1つは、IETFの中で異なったDM言語の増殖を止めて、様々なモデルを調和させることでした。 結果、MIB、およびPIBとして
Pras & Schoenwaelder Informational [Page 5] RFC 3444 Information Models and Data Models January 2003
Pras&Schoenwaelderの情報[5ページ]のRFC3444情報モデルとデータは2003年1月にモデル化されます。
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.
異なった基本的なプロトコルでSMIngで定義されたモジュールは写像できます。 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に向かって狙って、NMRGの中で開発された考えのいくつかだけを取り入れるSMI(SMIv3)の第3のバージョンを開発しています。
5. Security Considerations
5. セキュリティ問題
The meaning of the terms Information Model and Data Model has no direct security impact on the Internet.
用語の情報ModelとData Modelの意味はダイレクトセキュリティ変化もインターネットに与えません。
6. Acknowledgments
6. 承認
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ワークショップ(アルファベット順に)に参加した皆に感謝したがっています: Szabolcsボロシュ、Marcusブルンナー、デヴィッド・ダラム、デーヴ・ハリントン、ジャンフィリップマーチン-Flatin、ジョージPavlou、ロバートParhonyi、デヴィッド・パーキンス、デヴィッドSidor、アンドレアWesterinen、およびバートWijnen。
7. Normative References
7. 引用規格
[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、「経営情報バージョン2(SMIv2)の構造」STD58、RFC2578(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.、おかげさまで元気です、M.、Seligson、J.、チェン、K.、ハーン、S.、Sahita、R.、スミス、A.、およびF.Reichmeyer、「方針の構造は情報(SPPI)に食糧を供給し」て、RFC3159、2001年8月。
[3] Distributed Management Task Force, "Common Information Model
(CIM) Specification Version 2.2", DSP 0004, June 1999.
[3] 分散管理特別委員会、「一般的な情報モデル(CIM)仕様バージョン2.2インチ、DSP0004、1999年6月。」
[4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[4] ブラドナー、S.、「改正3インチ、BCP9、RFC2026、1996年インターネット標準化過程--10月。」
Pras & Schoenwaelder Informational [Page 6] RFC 3444 Information Models and Data Models January 2003
Pras&Schoenwaelderの情報[6ページ]のRFC3444情報モデルとデータは2003年1月にモデル化されます。
[5] Object Management Group, "Unified Modeling Language (UML),
Version 1.4", formal/2001-09-67, September 2001.
[5] 「2001-09-67と、2001年9月に正式な/を言語(UML)、バージョン1.4インチモデル化しながら、統一された」物のManagement Group。
[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] 国際標準化機構、「情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(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] 国際電気通信連合、「情報技術--オープン・システム・インターコネクション--Management情報の構造:、」 「管理オブジェクトの定義のためのガイドライン」、推薦X.722、1992。
8. Informative References
8. 有益な参照
[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.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針を拠点とする管理のための用語」RFC3198(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ルータのためにモデル化します」、RFC3290、2002年5月。
[10] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2863, June 2000.
[10]McCloghrieとK.とF.Kastenholz、「インタフェースはMIBを分類する」RFC2863、2000年6月。
9. Authors' Addresses
9. 作者のアドレス
Aiko Pras University of Twente PO Box 217 7500 AE Enschede The Netherlands
Twente私書箱217 7500AEエンスヘーデオランダのAiko Pras大学
Phone: +31 53 4893778 EMail: pras@ctit.utwente.nl
以下に電話をしてください。 +31 53 4893778はメールされます: pras@ctit.utwente.nl
Juergen Schoenwaelder University of Osnabrueck Albrechtstr. 28 49069 Osnabrueck Germany
Osnabrueck AlbrechtstrのユルゲンSchoenwaelder大学。 28 49069Osnabrueckドイツ
Phone: +49 541 969-2483 EMail: schoenw@informatik.uni-osnabrueck.de
以下に電話をしてください。 +49 541 969-2483 メールしてください: schoenw@informatik.uni-osnabrueck.de
Pras & Schoenwaelder Informational [Page 7] RFC 3444 Information Models and Data Models January 2003
Pras&Schoenwaelderの情報[7ページ]のRFC3444情報モデルとデータは2003年1月にモデル化されます。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Pras & Schoenwaelder Informational [Page 8]
Pras&Schoenwaelder情報です。[8ページ]
一覧
スポンサーリンク
