Network Working Group C. Elliott
Request for Comments: 3216 Cisco Systems
Category: Informational D. Harrington
Enterasys Networks
J. Jason
Intel Corporation
J. Schoenwaelder
F. Strauss
TU Braunschweig
W. Weiss
Ellacoya Networks
December 2001
SMIng Objectives
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 (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
Abstract
抽象
This document describes the objectives for a new data definition language, suitable for the modeling of network management constructs, that can be directly mapped into SNMP and COPS-PR protocol operations.
この文書では、直接SNMPとCOPS - PRプロトコル動作にマッピングすることができるネットワーク管理構造のモデリングに適した新しいデータ定義言語、のための目的を説明しています。
The purpose of this document is to serve as a set of objectives that a subsequent language specification should try to address. It captures the results of the working group discussions towards consensus on the SMIng objectives.
このドキュメントの目的は、その後の言語仕様が対処しようとする必要があります目標のセットとして提供することです。それはSMIng目標について合意に向けたワーキンググループの議論の結果をキャプチャします。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Background . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Specific Objectives for SMIng . . . . . . . . . . . . . . 4
4.1 Accepted Objectives . . . . . . . . . . . . . . . . . . . 5
4.1.1 The Set of Specification Documents . . . . . . . . . . . . 6
4.1.2 Textual Representation . . . . . . . . . . . . . . . . . . 6
4.1.3 Human Readability . . . . . . . . . . . . . . . . . . . . 6
4.1.4 Rigorously Defined Syntax . . . . . . . . . . . . . . . . 6
4.1.5 Accessibility . . . . . . . . . . . . . . . . . . . . . . 7
4.1.6 Language Extensibility . . . . . . . . . . . . . . . . . . 7
4.1.7 Special Characters in Text . . . . . . . . . . . . . . . . 7
4.1.8 Naming . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.9 Namespace Control . . . . . . . . . . . . . . . . . . . . 8
4.1.10 Modules . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1.11 Module Conformance . . . . . . . . . . . . . . . . . . . . 9
4.1.12 Arbitrary Unambiguous Identities . . . . . . . . . . . . . 9
4.1.13 Protocol Independence . . . . . . . . . . . . . . . . . . 9
4.1.14 Protocol Mapping . . . . . . . . . . . . . . . . . . . . . 10
4.1.15 Translation to Other Data Definition Languages . . . . . . 10
4.1.16 Base Data Types . . . . . . . . . . . . . . . . . . . . . 10
4.1.17 Enumerations . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.18 Discriminated Unions . . . . . . . . . . . . . . . . . . . 11
4.1.19 Instance Pointers . . . . . . . . . . . . . . . . . . . . 11
4.1.20 Row Pointers . . . . . . . . . . . . . . . . . . . . . . . 12
4.1.21 Constraints on Pointers . . . . . . . . . . . . . . . . . 12
4.1.22 Base Type Set . . . . . . . . . . . . . . . . . . . . . . 12
4.1.23 Extended Data Types . . . . . . . . . . . . . . . . . . . 12
4.1.24 Units, Formats, and Default Values of Defined Types and
Attributes . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1.25 Table Existence Relationships . . . . . . . . . . . . . . 13
4.1.26 Table Existence Relationships (2) . . . . . . . . . . . . 14
4.1.27 Attribute Groups . . . . . . . . . . . . . . . . . . . . . 14
4.1.28 Containment . . . . . . . . . . . . . . . . . . . . . . . 14
4.1.29 Single Inheritance . . . . . . . . . . . . . . . . . . . . 15
4.1.30 Reusable vs. Final Attribute Groups . . . . . . . . . . . 15
4.1.31 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.32 Creation/Deletion . . . . . . . . . . . . . . . . . . . . 16
4.1.33 Range and Size Constraints . . . . . . . . . . . . . . . . 16
4.1.34 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.35 Extension Rules . . . . . . . . . . . . . . . . . . . . . 17
4.1.36 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . . 17
4.1.37 No Redundancy . . . . . . . . . . . . . . . . . . . . . . 17
4.1.38 Compliance and Conformance . . . . . . . . . . . . . . . . 17
4.1.39 Allow Refinement of All Definitions in Conformance
Statements . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.40 Categories . . . . . . . . . . . . . . . . . . . . . . . . 18
4.1.41 Core Language Keywords vs. Defined Identifiers . . . . . . 19
4.1.42 Instance Naming . . . . . . . . . . . . . . . . . . . . . 19
4.1.43 Length of Identifiers . . . . . . . . . . . . . . . . . . 19
4.1.44 Assign OIDs in the Protocol Mappings . . . . . . . . . . . 20
4.2 Nice-to-Have Objectives . . . . . . . . . . . . . . . . . 20
4.2.1 Methods . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.2 Unions . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.3 Float Data Types . . . . . . . . . . . . . . . . . . . . . 21
4.2.4 Comments . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.5 Referencing Tagged Rows . . . . . . . . . . . . . . . . . 22
4.2.6 Arrays . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.7 Internationalization . . . . . . . . . . . . . . . . . . . 23
4.2.8 Separate Data Modelling from Management Protocol Mapping . 23
4.3 Rejected Objectives . . . . . . . . . . . . . . . . . . . 24
4.3.1 Incomplete Translations . . . . . . . . . . . . . . . . . 24
4.3.2 Attribute Value Constraints . . . . . . . . . . . . . . . 24
4.3.3 Attribute Transaction Constraints . . . . . . . . . . . . 25
4.3.4 Method Constraints . . . . . . . . . . . . . . . . . . . . 25
4.3.5 Agent Capabilities . . . . . . . . . . . . . . . . . . . . 25
4.3.6 Relationships . . . . . . . . . . . . . . . . . . . . . . 26
4.3.7 Procedures . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.8 Associations . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.9 Association Cardinalities . . . . . . . . . . . . . . . . 27
4.3.10 Categories of Modules . . . . . . . . . . . . . . . . . . 27
4.3.11 Mapping Modules to Files . . . . . . . . . . . . . . . . . 27
4.3.12 Simple Grammar . . . . . . . . . . . . . . . . . . . . . . 28
4.3.13 Place of Module Information . . . . . . . . . . . . . . . 28
4.3.14 Module Namespace . . . . . . . . . . . . . . . . . . . . . 29
4.3.15 Hyphens in Identifiers . . . . . . . . . . . . . . . . . . 29
5. Security Considerations . . . . . . . . . . . . . . . . . 30
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 30
7. References . . . . . . . . . . . . . . . . . . . . . . . . 30
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . 31
9. Full Copyright Statement . . . . . . . . . . . . . . . . . 33
This document describes the objectives for a new data definition language that can be mapped into SNMP [1], [2] and COPS-PR [3] protocol operations. It may also be translated into SMIv2 [4], [5], [6] MIBs and SPPI [7] PIBs. Concepts such as attributes, attribute groups, methods, conventions for organization into reusable data structures, and mechanisms for representing relationships are discussed.
この文書では、SNMPにマッピングすることができる新しいデータ定義言語の目的を説明し[1]、[2]、COPS-PR [3]プロトコル操作。またSMIv2のに翻訳することができる[4]、[5]、[6] MIBとSPPI [7]のPIB。そのような属性、属性グループ、方法、再利用可能なデータ構造に組織の規則、および関係を表現するためのメカニズムが議論されているような概念。
As networking technology has evolved, a diverse set of technologies has been deployed to manage the resulting products. These vary from Web based products, to standard management protocols and text scripts. The underlying systems to be manipulated are represented in varying ways including implicitly in the system programming, via proprietary data descriptions, or with standardized descriptions using a range of technologies including MIBs, PIBs, or LDAP schemas. The result is that management interfaces for network protocols, services, and applications such as Differentiated Services may be represented in many different, inconsistent fashions.
ネットワーキング技術が進化したように、技術の多様なセットが得られた生成物を管理するために展開されています。これらは、Webベースの製品から、標準管理プロトコルとテキストスクリプトに異なります。操作される基礎となるシステムは、独自のデータ記述を介して、またはMIBの、のPIB、またはLDAPスキーマを含む技術の範囲を使用して標準化された記述と、システムプログラミングで暗黙的に含む様々な方法で表現されます。結果は、差別化サービスのようなネットワークプロトコル、サービス、およびアプリケーションの管理インタフェースは、多くの異なる、一貫性のない様式で表すことができることです。
The SMIng working group has been chartered to define a new data definition language that will eliminate the need for a separate SMIv2 and SPPI language. That is, the new language should address the needs for the current SMIv2 and SPPI languages so that over time we can all use the new language instead.
SMIngワーキンググループは、個別のSMIv2とSPPI言語の必要性を排除する新しいデータ定義言語を定義するためにチャーターされました。それは時間をかけて、我々はすべての代わりに新しい言語を使用できるように、新しい言語が現在のSMIv2とSPPI言語のためのニーズに対処すべきである、です。
Another motivation is to permit a more expressive and complete representation of the modeled information. Examples of additional expressiveness and completeness that are considered are the ability to formally define table existence relationships, the expression of instance creation/deletion capabilities, and the ability to define attribute groups using inheritance. These additional features are discussed in subsequent sections.
もう一つの動機は、モデル化された情報のより表現と完全な表現を可能にすることです。みなされ、追加の表現力と完成度の例としては、正式にテーブルの存在との関係を定義する機能、インスタンス作成/削除機能の発現、および継承を使用して属性グループを定義する機能です。これらの追加機能は、次のセクションで説明されています。
It has been recognized that the two main goals of (a) merging SMIv2/SPPI and (b) enhancing the state of art in network management data modeling can lead to conflicts. In such cases, the SMIng working group's consensus is to focus on enhancing the state of art in network management data modeling.
（a）は合併のSMIv2 / SPPIおよび（b）のネットワーク管理データモデリングにおける最先端技術を強化する2つの主要な目標は、紛争につながる可能性が認識されています。このような場合には、SMIngワーキンググループのコンセンサスは、ネットワーク管理データモデリングにおける最先端技術の向上に注力することです。
The Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF) has researched the issues of creating a protocol-independent data definition language that could be used by multiple protocols. Because SMIv2 and SPPI are very similar, the NMRG focused on merging these two languages, but also researched ways to abstract the objectives to produce a language that could be used for other protocols, such as LDAP and Diameter. The NMRG has published the results of their work in a meanwhile expired Internet Draft, but has submitted their specification as one proposal to consider in the development of the SMIng language.
インターネットリサーチタスクフォースのネットワーク管理研究グループ（NMRG）（IRTF）は、複数のプロトコルで使用できるプロトコルに依存しないデータ定義言語を作成する問題を研究しています。 SMIv2とSPPIは非常に似ているので、NMRGは、これら二つの言語をマージに焦点を当てた、だけでなく、LDAPや直径など、他のプロトコルを使用することができる言語を生成するために、抽象目的に方法を研究しました。 NMRGは、インターネットドラフトを有効期限が切れますが、SMIng言語の開発を検討する一つの提案として、その仕様を提出した一方で、自分の仕事の結果を発表しました。
The SMIng Working Group has accepted their submission for consideration, and to use their proposal to better understand the objectives and possible obstacles to be overcome. Where useful, the NMRG proposal has been referenced in the details below.
SMIngワーキンググループが検討のための彼らの提出を受理した、より良い目標や可能性の障害を克服するために理解するために彼らの提案を使用します。どこに便利な、NMRGの提案は、以下の内容で参照されています。
The following sections define the objectives for the definition of a new data definition language. The objectives have been organized as follows: accepted objectives (Section 4.1), nice-to-have objectives (Section 4.2), and rejected objectives (Section 4.3). Each objective has the following information:
次のセクションでは、新しいデータ定義言語の定義のための目標を定義します。受け入れられた目標（4.1節）、素敵なツー持っている目標（4.2項）、及び目標（4.3節）を拒否：目的は、以下のように整理されています。それぞれの目的は、以下の情報があります。
o Type: a field that identifies the type of objective, using one of the following values:
O型：以下の値のいずれかを使用して、目的のタイプを識別するフィールド。
* basic: considered a basic objective for SMIng and is contained in SMIv2 and/or SPPI.
*基本：SMIngのための基本的な目的とみなされ、SMIv2のおよび/またはSPPIに含まれています。
* align: supported in different ways in SMIv2 and SPPI and they must be aligned.
*整列：のSMIv2とSPPIでさまざまな方法でサポートされており、彼らが整列しなければなりません。
* fix: considered a fix for a known problem in SMIv2 and/or SPPI.
*修正：SMIv2のおよび/またはSPPIの既知の問題の修正と考えます。
* new: considered a new feature.
*新：新機能と考えます。
o From: a field that defines the origin of the objective and that contains one or more of the following values:
Oから：目的の起源を定義し、それが次の値のいずれかまたは複数を含むフィールド：
* SMI: exists in SMIv2.
* SMI：SMIv2の中で存在しています。
* SPPI: exists in SPPI.
* SPPI：SPPIに存在します。
* NMRG: exists in the NMRG proposal, but not in SMIv2 or SPPI.
* NMRGは：NMRGの提案ではなく、SMIv2のかSPPIに存在します。
* Charter: exists in working group charter.
*憲章は：ワーキンググループ憲章に存在しています。
* WG: proposed during working group discussions.
* WG：ワーキンググループの議論の際に提案しました。
o Description: a quick description of the objective.
O説明：目的の簡単な説明。
o Motivation: rationale for the objective.
Oの動機：目標の根拠。
o Notes: optional notes about an objective. For example, for nice-to-have or rejected this may contain reasoning why this objective is not required by the SMIng working group, but justification why it should be considered anyway. Notes may be the opinions of the participants in the discussion on objectives and as such should not be taken as consensus of the working group or the recommendation of the objectives editing team.
O注：目的に関するオプションのメモ。例えば、への持っている、素敵なまたはのために、これは、この目的はSMIngワーキンググループによって必要とされていない理由を推論が含まれているが、それはとにかく考慮しなければならない理由を正当化も拒否。ノートは目的に議論の参加者の意見であってもよく、そのようにワーキンググループのコンセンサスまたは目的の編集チームの勧告として取られるべきではありません。
This section represents the list of objectives that have been accepted by the SMIng working group as worthwhile and therefore deserving of further consideration. Each of these objectives must be evaluated by the working group to determine if the benefit incurs an acceptable level of cost. An accepted objective may subsequently be rejected if the cost/benefit analysis determines that the benefit does not justify the cost or that the objective is in direct conflict with one or more other accepted objectives that are deemed more important.
このセクションでは、価値があると更なる検討のため、値するとしてSMIngワーキンググループによって承認された目的のリストを表します。これらの目的は、それぞれの利点は、コストの許容レベルを負うかどうかを判断するためにワーキンググループによって評価されなければなりません。費用/便益分析は、便益が費用を正当化するか、目的はより重要とみなされている1つのまたは複数の他の許容目的と直接競合していることをしないと判断した場合に認められた目的は、その後に拒否することができます。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: SMIv2 is defined in three documents, based on an obsolete ITU ASN.1 specification. SPPI is defined in one document, based on SMIv2. The core of SMIng must be defined in one document and must be independent of external specifications.
説明：SMIv2のは時代遅れITU ASN.1仕様に基づいて、3つの文書で定義されています。 SPPIはSMIv2のに基づいて、一つの文書で定義されています。 SMIngのコアは、一つの文書で定義されている必要があり、外部仕様に独立していなければなりません。
Motivation: Self-containment.
動機：自己封じ込め。
Type: basic
タイプ：ベーシック
From: SMI, SPPI, WG
投稿者：SMI、SPPI、WG
Description: SMIng definitions must be represented in a textual format.
説明：SMIng定義は、テキスト形式で表現されなければなりません。
Motivation: General IETF consensus.
動機：一般IETFコンセンサス。
Type: basic
タイプ：ベーシック
From: WG
投稿者：WG
Description: The syntax must make it easy for humans to directly read and write SMIng modules. It must be possible for SMIng module authors to produce SMIng modules with text editing tools.
説明：構文は、それが簡単に人間が直接読み込むとSMIngモジュールを記述するために作る必要があります。 SMIngモジュールの作者がテキスト編集ツールでSMIngモジュールを生成することが可能でなければなりません。
Motivation: The syntax must make it easy for humans to read and write SMIng modules.
動機：構文は、それが簡単に人間が読んでSMIngモジュールを記述するために作る必要があります。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: There must be a rigorously defined syntax for the SMIng language.
説明：SMIng言語の厳密に定義されている構文が存在する必要があります。
Motivation: An unambiguous language promotes consistency across vendors so that different parsers produce the same results. It also provides authoritative rules to SMIng modules designers.
動機：明確な言語別のパーサは同じ結果を生成するように、ベンダー間の一貫性を促進します。また、SMIngモジュールの設計者に権威のルールを提供します。
Type: align
タイプ：合わせ
From: SMI, SPPI
投稿者：SMI、SPPI
Description: Attribute definitions must indicate whether attributes can be read, written, created, deleted, and whether they are accessible for notifications, or are not accessible. Align PIB-ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.
説明：属性の定義属性は、読み出し、書き込み、作成、削除することができるかどうかを示す必要があり、彼らは、通知のためにアクセスされている、またはアクセスすることはできませんか。 PIB-ACCESSおよびMAX-ACCESS、およびPIB-MIN-ACCESSおよびMIN-ACCESSの位置を合わせます。
Motivation: Alignment of SMIv2 and SPPI.
動機：SMIv2のとSPPIの整列。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: The language must have characteristics, so that future modules can contain information of future syntax without breaking original SMIng parsers.
説明：将来のモジュールは、元のSMIngパーサを壊すことなく、将来の構文の情報を含めることができるように、言語は、特性を持っている必要があります。
E.g., when SMIv2 introduced REFERENCEs it would have been nice if it would not have broken SMIv1 parsers.
SMIv2のは、参照を導入したとき、それは壊れたでSMIv1パーサを持っていないならば、例えば、それは素敵だったでしょう。
Motivation: Achieve language extensibility without breaking core compatibility.
動機：コア互換性を壊すことなく、言語の拡張を実現します。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: Allow an escaping mechanism to encode special characters, e.g. double quotes and new-line characters, in text such as DESCRIPTIONs or REFERENCEs.
説明：例えば、エスケープ機構は特殊文字をエンコードすることを許可しますそのような説明や参考資料などのテキストに二重引用符と改行文字、。
Motivation: ABNF can contain literal characters enclosed in double quotes; to provide the ABNF grammar, there must be the ability to escape special characters.
動機：ABNFは、二重引用符で囲まれたリテラル文字を含めることができます。 ABNF文法を提供するために、特殊文字をエスケープする能力がなければなりません。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must provide mechanisms to uniquely identify attributes, groups of attributes, and events. It is necessary to specify how name collisions are handled.
説明：SMIng一意の属性、属性のグループ、およびイベントを識別するためのメカニズムを提供しなければなりません。名前の衝突をどのように処理するかを指定する必要があります。
Motivation: Already in SMIv2 and SPPI.
動機：すでにのSMIv2とSPPIインチ
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: There must be a hierarchical, centrally-controlled namespace for standard named items, and a distributed namespace must be supported to allow vendor-specific naming and to assure unique module names across vendors and organizations.
説明：そこ標準という名前の項目の階層的、集中制御名前空間でなければならず、分散名前空間は、ベンダー固有のネーミングを可能にし、ベンダーや組織全体で一意のモジュール名を確保するためにサポートしなければなりません。
Motivation: Need to unambiguously identify definitions of various kinds. Some SMI implementations have problems with different objects from multiple modules but with the same name. Furthermore, the probability of module name clashes rises over time (for example, different vendors defining their own SYSTEM-MIB).
動機：明確に様々な種類の定義を特定する必要があります。いくつかのSMIの実装は、複数のモジュールからではなく、同じ名前を持つ異なるオブジェクトに問題があります。また、モジュールの名前の衝突の確率は、（例えば、異なるベンダーが独自のシステム-MIBを定義する）時間をかけて上昇します。
Notes: An example naming scheme is the one employed by the Java programming language with a central naming authority assigning the top-level names.
注：スキームの命名の例では、最上位レベルの名前を割り当てる中央命名権限を持つJavaプログラミング言語によって使用されるものです。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must provide a mechanism for uniquely identifying a module, and specifying the status, contact person, revision information, and the purpose of a module.
説明：SMIng一意モジュールを識別し、ステータス、担当者、改訂情報、及びモジュールの目的を指定するためのメカニズムを提供しなければなりません。
SMIng must provide mechanisms to group definitions into modules and it must provide rules for referencing definitions from other modules.
SMIngは、モジュールにグループ定義するメカニズムを提供する必要があり、それは他のモジュールからの定義を参照するための規則を提供しなければなりません。
Motivation: Modularity and independent advancement of documents.
動機：モジュール性と文書の独立した進歩。
Notes: Text about module conformance has been moved to Section 4.1.11.
注：モジュールの適合性についてのテキストは、セクション4.1.11に移動されました。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must provide mechanisms to detail the minimum requirements implementers must meet to claim conformance to a standard based on the module.
説明：SMIngは、細部に実装モジュールに基づいて、標準への適合性を主張するために満たさなければならない最低限の要件を機構を提供しなければなりません。
Motivation: Ability to convey conformance requirements.
動機：適合性要件を伝える能力。
Type: basic
タイプ：ベーシック
From: SMI
投稿者：SMI
Description: SMI allows the use of OBJECT-IDENTITIES to define unambiguous identities without the need of a central registry. SMI uses OIDs to represent values that represent references to such identities. SMIng needs a similar mechanism (a statement to register identities, and a base type to represent values).
説明：SMIはOBJECT-アイデンティティの使用が中心のレジストリを必要とせずに明確なアイデンティティを定義することができます。 SMIは、そのようなアイデンティティへの参照を表す値を表すためにOIDを使用しています。 SMIngは、同様のメカニズム（IDを登録するステートメント、および値を表す基本型）を必要とします。
Motivation: SMI Compatibility.
動機：SMIの互換性。
Notes: This is an obvious objective. Additionally, everything not on the wire, such as modules, will still be assigned OIDs.
注：これは明白な目的です。さらに、すべてではないワイヤ上、このようなモジュールとして、まだOIDを割り当てられます。
It is yet to be determined whether the assignment of the OID occurs within the core or within a protocol-specific mapping.
それはまだOIDの割り当てがコア内またはプロトコル固有のマッピング内で発生したか否かを判断します。
Type: basic
タイプ：ベーシック
From: Charter
投稿者：チャーター
Description: SMIng must define data definitions in support of the SNMP and COPS-PR protocols. SMIng may define data definitions in support of other protocols.
説明：SMIngはSNMPとCOPS-PRのプロトコルをサポートするデータ定義を定義する必要があります。 SMIngは、他のプロトコルをサポートするデータ定義を定義することもできます。
Motivation: So data definitions may be used with multiple protocols and multiple versions of those protocols.
動機：データ定義は、複数のプロトコルとそれらのプロトコルの複数のバージョンで使用することができるので。
Type: basic
タイプ：ベーシック
From: Charter
投稿者：チャーター
Description: The SMIng working group, in accordance with the working group charter, will define mappings of protocol independent data definitions to protocols based upon installed implementations. The SMIng working group can define mappings to other protocols as long as this does not impede the progress on other objectives.
説明：SMIngワーキンググループは、ワーキンググループ憲章に従って、インストールの実装に基づくプロトコルにプロトコルに依存しないデータ定義のマッピングを定義します。 SMIngワーキンググループがいる限り、これは他の目的の進展を妨げないように、他のプロトコルにマッピングを定義することができます。
Motivation: SMIng working group charter.
動機：SMIngワーキンググループのチャーター。
Type: basic
タイプ：ベーシック
From: Charter
投稿者：チャーター
Description: SMIng language constructs must, wherever possible, be translatable to SMIv2 and SPPI. At the time of standardization of a SMIng language, existing SMIv2 MIBs and SPPI PIBs on the standards track will not be required to be translated to the SMIng language. New MIBs/PIBs will be defined using the SMIng language.
説明：SMIng言語構造は、可能な限り、のSMIv2とSPPIに翻訳可能でなければなりません。標準化過程の上のSMIv2 MIBとSPPIのPIBを既存のSMIng言語の標準化の時点でSMIng言語に翻訳する必要はありません。新しいMIBは/ PIBのはSMIng言語を使用して定義されます。
Motivation: Provide best-effort backwards compatibility for existing tools while not placing an unnecessary burden on MIBs/PIBs that are already on the standards track.
動機：のMIB /標準トラック上に既にあるのPIBに不必要な負担をかけずに、既存のツールのためのベストエフォート型の後方互換性を提供します。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must support the base data types Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString, and OID.
説明：SMIngは、基本データ型Integer32の、Unsigned32の、Integer64、Unsigned64に、列挙、ビット、OctetStringに、およびOIDをサポートしなければなりません。
Motivation: Most are already common. Unsigned64 and Integer64 are in SPPI, must fix in SMI. Note that Counter and Gauge types can be regarded as derived types instead of base types.
動機：ほとんどは、すでに一般的です。 Unsigned64にとInteger64は、SPPIであるSMIに修正する必要があります。そのカウンタに注意し、タイプが代わりに基本型の派生型とみなすことができるゲージ。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must provide support for enumerations. Enumerated values must be a part of the enumeration definition.
説明：SMIngは、列挙型のサポートを提供する必要があります。列挙値は、列挙定義の一部でなければなりません。
Motivation: SMIv2 already has enumerated numbers.
動機：SMIv2のは、既に番号を列挙しています。
Notes: Enumerations have the implicit constraint that the attribute is constrained to the values for the enumeration.
注：列挙型の属性は、列挙の値に制約されている暗黙の制約があります。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: SMIng must support discriminated unions.
説明：SMIngは、判別共用体をサポートしている必要があります。
Motivation: Allows to group related attributes together, such as InetAddressType (discriminator) and InetAddress, InetAddressIPv4, InetAddressIPv6 (union). The lack of discriminated unions has also lead to relatively complex sparse table work-around in some DISMAN mid-level manager MIBs.
動機は：例えばInetAddressTypeの（弁別）とのInetAddress、InetAddressIPv4、InetAddressIPv6（ユニオン）として、一緒にグループに関連する属性を可能にします。判別組合の欠如はまた、いくつかのDISMAN中間レベルのマネージャのMIBで比較的複雑なまばらなテーブルの周りの仕事につながりました。
Notes: Discriminated unions have the property that the union attribute type is constrained by the value of the discriminator attribute.
注：識別型組合が組合の属性タイプは、識別子属性の値によって制約されるという特性を持っています。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must allow specifying pointers to instances (i.e., a pointer to a particular attribute in a row).
説明：SMIngは、インスタンスへのポインタを指定できるようにしなければならない（即ち、行の特定の属性へのポインタ）。
Motivation: It is common practice in MIBs and PIBs to point to other instances.
動機：それは他のインスタンスを指すようにMIBとのPIBで一般的に行われています。
Type: align
タイプ：合わせ
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must allow specifying pointers to rows.
説明：SMIngは、行へのポインタを指定できるようにする必要があります。
Motivation: It is common practice in MIBs and PIBs to point to other rows (see RowPointer, PIB-REFERENCES).
動機：これはMIBの中で一般的に行われているとのPIBは、他の行を指すように（RowPointer、PIB-参考文献を参照）。
Type: align
タイプ：合わせ
From: SPPI
投稿者：SPPI
Description: SMIng must allow specifying the types of objects to which a pointer may point.
説明：SMIngは、ポインタが指してもよいれるオブジェクトのタイプを指定できるようにしなければなりません。
Motivation: Allows code generators to detect and reject illegal pointers automatically. Can also be used to automatically generate more reasonable implementation-specific data structures.
動機：コードジェネレータを検出し、自動的に不正なポインタを拒否することができます。また、自動的に、より合理的な実装固有のデータ構造を生成するために使用することができます。
Notes: Pointer constraints are a special case of attribute value constraints (Section 4.3.2) in which the prefix of the OID (row or instance pointer) value is limited to be only from a particular table.
注：ポインタ制約値OID（行またはインスタンスポインタ）の接頭辞は、特定のテーブルからのものに制限されている属性値の制約（4.3.2）の特殊なケースです。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must support a fixed set of base types of fixed size and precision. The list of base types must not be extensible unless the SMI itself changes.
説明：SMIngは固定サイズと精度の基本型の固定セットをサポートしなければなりません。 SMI自体は変更しない限り、基本タイプのリストは、拡張可能であってはなりません。
Motivation: Interoperability.
動機：相互運用性。
Type: align
タイプ：合わせ
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must support a mechanism to derive new types, which provide additional semantics (e.g., Counters, Gauges, Strings, etc.), from base types. It may be desirable to also allow the derivation of new types from derived types. New types must be as restrictive or more restrictive than the types that they are specializing.
説明：SMIngは、ベースタイプから、追加の意味論（例えば、カウンタ、ゲージ、文字列など）を提供する新しいタイプを導出するメカニズムをサポートしなければなりません。また、派生型から新しいタイプの導出を可能にすることが望ましいことがあります。新しいタイプは、制限や、彼らが特化しているタイプよりも限定的でなければなりません。
Motivation: SMI uses application types and textual conventions. SPPI uses derived types.
動機：SMIは、アプリケーションの種類やテキストの表記法を使用しています。 SPPIは派生型を使用しています。
4.1.24 Units, Formats, and Default Values of Defined Types and Attributes
定義された型と属性の4.1.24単位、フォーマット、およびデフォルト値
Type: fix
タイプ：修正
From: NMRG
投稿者：NMRG
Description: In SMIv2 OBJECT-TYPE definitions may contain UNITS and DEFVAL clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-HINTs. In a similar fashion units and default values must be applicable to defined types and format information must be applicable to attributes.
説明：SMIv2のOBJECT-TYPEの定義はUNITSとDEFVAL条項が含まれていてもよいし、テキストの表記法DISPLAY-ヒントが含まれていてもよいです。同様ユニットおよびデフォルト値の属性に適用可能でなければならない定義されたタイプとフォーマット情報に適用しなければなりません。
Motivation: Some MIBs introduce TCs such as KBytes and every usage of the TC then specifies the UNITS "KBytes". It would simplify things if the UNITS were attached to the type definition itself.
動機：一部のMIBは、キロバイトとしてのTCを導入し、TCのすべての使用法は、UNITS「Kバイト」を指定します。単位は型定義自体に添付された場合、それは物事を単純化します。
Notes: The SMIng WG must clarify the behavior if an attribute uses a defined type and both, the attribute and the defined type, have units/default/format information.
注：属性が定義された型との両方を使用している場合SMIng WGは、行動を明確にしなければならない、属性と定義されたタイプは、単位/デフォルト/フォーマット情報を持っています。
Type: align
タイプ：合わせ
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in the SNMP/COPS-PR protocol mappings.
説明：SMIngは、INDEX、AUGMENTSをサポートし、SNMP / COPS-PRプロトコルマッピングに延びている必要があります。
Motivation: These three table existence relationships exist either in the SMIv2 or the SPPI.
動機：これらの3人の表の存在との関係は、SMIv2のかSPPIのいずれかで存在します。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: SMIng must support EXPANDS and REORDERS relationships in the SNMP/COPS-PR protocol mappings.
説明：SMIngが拡張をサポートし、SNMP / COPS-PRプロトコルマッピングで関係を並べ替える必要があります。
Motivation: A REORDERS statement allows indexing orders to be swapped. An EXPANDS statement formally states that there is a 1:n existence relationship between table rows.
動機：並べ替え文のインデックスの注文を交換することを可能にします。テーブルの行の間にn個存在関係：拡大するステートメントは、正式に1があると述べています。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: An attribute group is a named, reusable set of attributes that are meaningful together. It can be reused as the type of attributes in other attribute groups (see also Section 4.1.28). This is similar to `structs' in C.
説明：属性グループが一緒に意味のある属性の名前の、再利用可能なセットです。これは、他の属性グループ内の属性の種類として再利用することができます（セクション4.1.28を参照してください）。これは、C言語の構造体 `と似ています
Motivation: Required to map the same grouping of attributes into SNMP and COPS-PR tables. Allows to do index reordering without having to redefine the attribute group. Allows to group related attributes together (e.g. InetAddressType, InetAddress).
動機：SNMPとCOPS-PRのテーブルに同じ属性グループをマップするために必要です。属性グループを再定義することなく、インデックスの並べ替えを行うことができます。一緒にグループに関連する属性を可能にする（例えばInetAddressTypeの、のInetAddress）。
The ability to group attributes provides an indication that the attributes are meaningful together.
グループ属性の能力は、属性が一緒に意味のあることの指標を提供します。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: SMIng must provide support for the creation of new attribute groups from attributes of more basic types and potentially other attribute groups.
説明：SMIngは、より基本的なタイプ、潜在的に他の属性グループの属性から、新しい属性グループを作成するためのサポートを提供しなければなりません。
Motivation: Simplifies the reuse of attribute groups such as InetAddressType and InetAddress pairs.
動機：などのInetAddressTypeとInetAddressのペアとしての属性グループの再利用を簡素化します。
Notes: Containment has the implicit existence constraint that if an instance of a contained attribute group exists, then the corresponding instance of the containing attribute group must also exist.
注意事項：封じ込めが含まれる属性グループのインスタンスが存在する場合、含む属性グループの、対応するインスタンスも存在しなければならないという暗黙の存在制約を有しています。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: SMIng must provide support for mechanisms to extend attribute groups through single inheritance.
説明：SMIngは、単一継承によって属性グループを拡張するためのメカニズムのサポートを提供する必要があります。
Motivation: Allows to extend attribute groups, like a generic DiffServ scheduler, with attributes for a specific scheduler, without cut&paste.
動機：カット＆ペーストせずに、特定のスケジューラの属性と、ジェネリックのDiffServスケジューラのように、属性グループを拡張することができます。
Notes: Single inheritance with multiple levels (e.g., C derives from B, and B derives from A) must be allowed.
注：複数のレベル（例えば、CはBから派生し、BはAから派生）を有する単一継承が許可されなければなりません。
Inheritance has the implicit existence constraint that if an instance of a derived attribute group exists, then the corresponding instance of the base attribute group must also exist.
継承は、派生属性グループのインスタンスが存在する場合、基地属性グループの対応する例も存在しなければならないという暗黙の存在制約を有しています。
Inheritance could help to add attributes to an attribute group that are specific to a certain protocol mapping and do not appear in the protocol-neutral attribute group.
継承は、特定のプロトコルマッピングに固有のものであり、プロトコル中立属性グループに表示されない属性グループに属性を追加することに役立つ可能性があります。
Type: new
タイプ：新しいです
From: NMRG, WG
投稿者：NMRG、WG
Description: SMIng must differentiate between "final" and reusable attribute groups, where the reuse of attribute groups covers inheritance and containment.
説明：SMIngは属性グループの再利用が継承と封じ込めをカバーして「最終」と再利用可能な属性グループ、区別しなければなりません。
Motivation: This information gives people more information how attribute groups can and should be used. It hinders them from misusing them.
動機：この情報は人々にグループができる属性とどのように使用するかをより多くの情報を提供します。これは、それらを悪用するのを妨げています。
Notes: This objective attempts to convey the idea that some attribute groups are not meant to stand on their own and instead only make sense if contained within another attribute group.
注：この目的は、いくつかの属性グループは、独自の上に立つことを意図し、別の属性グループ内に含まれている場合だけではなく意味を成していないという考えを伝えるためにしようとします。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must provide mechanisms to define events which identify significant state changes.
説明：SMIngは重要な状態変化を特定するイベントを定義するためのメカニズムを提供しなければなりません。
Motivation: These represent the protocol-independent events that lead to SMI notifications or SPPI reports.
動機：これらは、SMI通知またはSPPI報告につながるプロトコルに依存しない事象を表します。
Type: align
タイプ：合わせ
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must support a mechanism to define creation/deletion operations for instances. Specific creation/deletion errors, such as INSTALL-ERRORS, must be supported.
説明：SMIngは、インスタンスの作成/削除の操作を定義するためのメカニズムをサポートしている必要があります。このようINSTALL-エラーなどの特定の作成/削除エラーは、サポートされなければなりません。
Motivation: Available for row creation in SMI, and available in SPPI.
動機：SMIでの列の作成のために利用できる、とSPPIで利用できます。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must allow specifying range and size constraints where applicable.
説明：SMIngはどこ適用範囲やサイズ制約を指定できるようにする必要があります。
Motivation: The SMI and SPPI both support range and size constraints.
動機：SMIとSPPIの両方のサポート範囲とサイズの制約。
Type: basic
タイプ：ベーシック
From: SPPI
投稿者：SPPI
Description: SMIng must allow the specification of uniqueness constraints on attributes. SMIng must allow the specification of multiple independent uniqueness constraints.
説明：SMIngは属性の一意性制約の仕様を許可する必要があります。 SMIngは、複数の独立した一意性制約の仕様を許可する必要があります。
Motivation: Knowledge of the uniqueness constraints on attributes allows to verify protocol specific mappings (e.g. INDEX clauses). The knowledge can also be used by code generators to improve generated implementation-specific data structures.
モチベーション：属性の一意性制約の知識は、プロトコル固有のマッピング（例えば、INDEX句）を検証することを可能にします。知識はまた、生成された実装固有のデータ構造を改善するために、コードジェネレータによって使用することができます。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must provide clear rules how one can extend SMIng modules without causing interoperability problems "over the wire".
説明：SMIngは1が「ワイヤ上の」相互運用性の問題を引き起こすことなくSMIngモジュールを拡張することができますどのように明確なルールを提供する必要があります。
Motivation: SMIv2 and SPPI have extension rules.
動機：SMIv2のとSPPIは、拡張ルールを持っています。
Type: fix
タイプ：修正
From: WG
投稿者：WG
Description: The SMIng SNMP mapping must deprecate the use of the IMPLIED indexing schema.
説明：SMIng SNMPマッピングは暗黙のインデックススキーマの使用を廃止しなければなりません。
Motivation: IMPLIED is confusing and most people don't understand it. The solution (IMPLIED) is worse than the problem it is trying to solve and therefore for the sake of simplicity, the use of IMPLIED should be deprecated.
動機：黙示は混乱であり、ほとんどの人はそれを理解していません。溶液（黙示）は、解決しようとしているので、簡単のために、黙示の使用は推奨されなければならない問題よりも悪いです。
Type: fix
タイプ：修正
From: NMRG
投稿者：NMRG
Description: The SMIng language must avoid redundancy.
説明：SMIng言語は重複を避ける必要があります。
Motivation: Remove any textual redundancy for things like table entries and SEQUENCE definitions, which only increase specifications without providing any value.
動機：唯一の任意の値を提供することなく仕様を増やすテーブルエントリとSEQUENCEの定義のようなもののために任意のテキストの冗長性を、削除します。
Type: basic
タイプ：ベーシック
From: SMI, SPPI
投稿者：SMI、SPPI
Description: SMIng must provide a mechanism for compliance and conformance specifications for protocol-independent definitions as well as for protocol mappings.
説明：SMIngは、プロトコルに依存しない定義については、コンプライアンスおよび適合仕様のためだけでなく、プロトコルマッピングするためのメカニズムを提供しなければなりません。
Motivation: This capability exists in SMIv2 and SPPI. The NMRG proposal has the ability to express much of this information at the protocol-dependent layer. Some compliance or conformance information may be protocol-independent, therefore there is also a need to be able to express this information protocol-independent part.
動機：この機能はSMIv2のとSPPIに存在します。 NMRG提案は、プロトコル依存レイヤでこの情報の多くを発現する能力を有しています。いくつかのコンプライアンスまたは適合情報は、プロトコルに依存してもよく、したがってこの情報のプロトコルに依存しない部分を発現することができるようにする必要もあります。
Type: fix
タイプ：修正
From: WG
投稿者：WG
Description: SMIv2, RFC 2580, Section 3.1 says:
説明：SMIv2の、RFC 2580、セクション3.1は言います：
The OBJECTS clause, which must be present, is used to specify
each object contained in the conformance group. Each of the
specified objects must be defined in the same information
module as the OBJECT-GROUP macro appears, and must have a MAX-
ACCESS clause value of "accessible-for-notify", "read-only",
"read-write", or "read-create".
The last sentence forbids to put a not-accessible INDEX object into an OBJECT-GROUP. Hence, you can not refine its syntax in a compliance definition. For more details, see http://www.ibr.cs.tu-bs.de/ietf/smi-errata/
最後の文は、OBJECT-GROUPにアクセス可能ではないINDEXオブジェクトを置くことを禁止します。したがって、あなたは、コンプライアンスの定義でその構文を絞り込むことができません。詳細については、http://www.ibr.cs.tu-bs.de/ietf/smi-errata/を参照してください
Motivation: This error should not be repeated in SMIng.
動機：このエラーはSMIngで繰り返すべきではありません。
Type: basic
タイプ：ベーシック
From: SPPI
投稿者：SPPI
Description: SMIng must provide a mechanism to group definitions into subject categories. Concrete instances may only exist in the scope of a given subject category or context.
説明：SMIngは、対象カテゴリにグループ定義へのメカニズムを提供しなければなりません。具体的な例は、所与の対象のカテゴリまたはコンテキストの範囲で存在することができます。
Motivation: To scope the categories to which a module applies. In SPPI this is used to allow a division of labor between multiple client types.
動機：モジュールが適用されるスコープに分類。 SPPIでは、これは複数のクライアントタイプ間の分業を可能にするために使用されます。
Type: fix
タイプ：修正
From: NMRG
投稿者：NMRG
Description: In SMI and SPPI modules some language keywords (macros and a number of basetypes) have to be imported from different SMI language defining modules, e.g. OBJECT-TYPE, MODULE-IDENTITY, Integer32 must to be imported from SNMPv2-SMI and TEXTUAL-CONVENTION must be imported from SNMPv2-TC, if used. MIB authors are continuously confused about these import rules. In SMIng only defined identifiers must be imported. All SMIng language keywords must be implicitly known and there must not be a need to import them from any module.
説明：SMIとSPPIの一部の言語キーワード（マクロ及びbasetypesの数）が異なるSMI言語定義モジュールからインポートされなければならないモジュール、例えばOBJECT-TYPE、MODULE-IDENTITY、構文Integer32はSNMPv2の-SMIからインポートする必要があり、使用している場合TEXTUAL-CONVENTIONが、SNMPv2の-TCからインポートする必要があります。 MIBの著者らは、これらのインポートルールについて継続的に混乱しています。 SMIngでのみ定義された識別子は、インポートする必要があります。すべてのSMIng言語キーワードは、暗黙的に知られなければならないし、任意のモジュールからインポートする必要があってはなりません。
Motivation: Reduce confusion. Clarify the set of language keywords.
動機：混乱を減らします。言語のキーワードのセットを明確にします。
Type: align
タイプ：合わせ
From: SMI, SPPI
投稿者：SMI、SPPI
Description: Instance naming in SMIv2 and SPPI is different. SMIng must align the instance naming (either in the protocol neutral model or the protocol mappings).
説明：SMIv2のとSPPIに命名インスタンスが異なっています。 SMIngは、（いずれかのプロトコル中性モデルまたはプロトコルマッピングで）名前付けインスタンスを整列しなければなりません。
Motivation: COPS-PR and SNMP have different instance identification schemes that must be handled.
動機：COPS-PRおよびSNMPを扱わなければならない別のインスタンスの識別スキームを持っています。
Notes: A solution requires to investigate how close the naming schemes dictated by the protocols are. Perhaps it is feasible to have a single instance naming scheme in both SNMP and COPS-PR, even though the current SPPI and SMIv2 are different.
注：ソリューションはプロトコルによって決定命名スキームがどれだけ近いかを調査することが必要です。おそらく現在のSPPIとSMIv2のが異なっていても、SNMPとCOPS-PRの両方で命名方式単一のインスタンスを持つことが可能です。
Type: fix
タイプ：修正
From: NMRG
投稿者：NMRG
Description: The allowed length of the various kinds of identifiers must be extended from the current `should not exceed 32' (maybe even from the `must not exceed 64') rule.
説明：識別子の各種の許容長さは、ルール（多分 `超えてはならない64' から）` 32' を超えてはならない電流から延長されなければなりません。
Motivation: Reflect current practice of definitions.
動機：定義の現在の慣行を反映しています。
Notes: The 32-rule was added back in the days where compilers could not deal with long identifiers. This rule is continuously violated these days and it does not make sense to keep it.
注：32-ルールはコンパイラが長い識別子を扱うことができなかった時代に戻って追加されました。このルールは、継続的に、これらの日に違反していると、それはそれを維持しても意味がありません。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: SMIng must not assign OIDs to reusable definition of attributes, attribute groups, events, etc. Instead, SNMP and COPS-PR mappings must assign OIDs to the mapped items.
説明：SMIngは属性の再利用可能な定義にOIDを割り当てる必要がありません、代わりに、SNMPとCOPS-PRマッピングがマッピングされたアイテムにOIDを割り当てる必要がありますなどのグループ、イベント、属性。
Motivation: Assignment of OIDs in protocol neutral definitions can complicate reuse. OIDs of synonymous attributes are not the same in SMI and SPPI definitions. MIBs and PIBs are already registered in different parts of the OID namespace.
動機：プロトコル中立的な定義でのOIDの割り当ては、再利用を複雑にすることができます。同義語属性のOIDはSMIとSPPIの定義に同じではありません。 MIBとのPIBは、すでにOID名前空間のさまざまな部分に登録されています。
This section represents the list of recommended objectives that would be nice to have. However, these are not automatically thought of as accepted objectives as, for example, they may entail a non-trivial amount of work in underlying protocols to support or they may be regarded as less important than other contradicting objectives that are accepted.
このセクションでは、持っていいだろうお勧め目標のリストを表します。例えば、それらがサポートするプロトコルの基礎となる中で、作業の非自明な量を伴ってもよいか、それらが受け入れられ、他の矛盾の目標よりも重要とみなすことができる、しかし、これらは自動的に受け入れられた目標を考えていません。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: SMIng should support a mechanism to define method signatures (parameters, return values, exception) that are implemented on agents.
説明：SMIngは、エージェント上に実装されるメソッドシグネチャ（パラメータ、戻り値、例外）を定義するためのメカニズムをサポートしなければなりません。
Motivation: Methods are needed to support the definition of operational interfaces such as found in [RFC2925] (ping, traceroute and lookup operations). Also, the ability to define constructor/destructor interfaces could address issues such as encountered with SNMP's RowStatus solution.
モチベーション：方法は、[RFC2925]（ピング、トレースルート、およびルックアップ操作）に見られるような操作インタフェースの定義をサポートするために必要とされます。 SNMPのRowStatusの溶液で遭遇したとしても、コンストラクタ/デストラクタのインタフェースを定義する機能は、このような問題に対処することができます。
Notes: Is it possible to do methods without changing the underlying protocol? There is agreement that methods are useful, but disagreement upon the impact - one end of the spectrum sees this as a documentation tool for existing SNMP capabilities, while the other end sees this as a protocol update, moving forward, to natively support methods. The proposal is to wait and see if this is practical to implement as a syntax that is useful and can map to the protocol.
注：それは基本的なプロトコルを変更せずにメソッドを行うことは可能ですか？方法が有用で合意が、インパクト時に不一致があります - もう一方の端は、ネイティブメソッドをサポートするために、前進し、プロトコルの更新としてこれを見ながら、スペクトルの一端は、既存のSNMP機能のための文書化ツールとして、これを見ています。提案は待って、これは有用であり、プロトコルにマッピングすることができます構文として実装することが現実的であるかどうかを確認することです。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: SMIng should support a standard format for unions.
説明：SMIngは、労働組合のための標準フォーマットをサポートする必要があります。
Motivation: Allows an attribute to contain one of many types of values. The lack of unions has also lead to relatively complex sparse table work-around in some DISMAN mid-level managers. Despite from discriminated unions (see Section 4.1.18), this kind of union has no accompanied explicit discriminator attribute that selects the union's type of value.
動機：属性は、値の多くの種類のいずれかを含めることができます。組合の欠如はまた、いくつかのDISMAN中間レベルの管理職では比較的複雑なまばらなテーブルの周りの仕事につながりました。判別組合（セクション4.1.18を参照）からもかかわらず、組合のこの種は、値の組合の種類を選択何ら伴う明示的な識別子属性を持っていません。
Notes: The thought is that SNMP and COPS-PR can already support unions because they do not care about what data type goes with a particular OID.
注：考えは、彼らがデータ型は、特定のOIDと何が起こるのか気にしないので、SNMPとCOPS-PRは、すでに労働組合をサポートすることができるということです。
Type: new
タイプ：新しいです
From: WG, NMRG
投稿者：WG、NMRG
Description: SMIng should support the base data types Float32, Float64, Float128.
説明：SMIngは、基本データ型のfloat32、float64型、Float128をサポートする必要があります。
Motivation: Missing base types can hurt later on, because they cannot be added without changing the language, even as an SMIng extension. Lesson learned from the SMIv1/v2 debate about Counter64/Integer64/...
動機：彼らもSMIng拡張として、言語を変更せずに追加することができないので、不足している基本型は、後に傷つけることができます。レッスンはCounter64の/ Integer64程度でSMIv1 / v2の議論から学びました/ ...
Notes: There is no mention as to whether or not the underlying protocols will have to natively support float data types. This is left to the mapping. However, it seems imperative that the float data type needs to be added to the set of intrinsic types in the SMIng language at the creation of the language as it will be impossible to add them later without changing the language.
注：基本的なプロトコルがネイティブ浮動小数点データ型をサポートする必要がありますかどうかの全く言及がありません。これは、マッピングに委ねられています。しかし、floatデータ型は、言語を変更せずに後で追加することは不可能であるように、言語の作成時にSMIng言語での組み込み型のセットに追加する必要があることが不可欠と思われます。
Type: fix
タイプ：修正
From: NMRG
投稿者：NMRG
Description: The syntax of comments should be well defined, unambiguous and intuitive to most people, e.g., the C++/Java `//' syntax.
説明：コメントの構文はうまくほとんどの人には、明確なと直感的に定義する必要があり、例えば、C ++ / Javaの `//」構文。
Motivation: ASN.1 Comments (and thus SMI and SPPI comments) have been
a constant source of confusion. People use arbitrary lengthy
strings of dashes (`-----------') in the wrong assumption that
this is always treated as a comment. Some implementations try to
accept these syntactically wrong constructs which even raises
confusion. We should get rid of this problem.
Notes: If the SMIng working group adopts a C-like syntax, then the C++/Java single-line comment should be adopted as well.
注：SMIngワーキンググループはCに似た構文を採用した場合、C ++ / Javaの単一行コメントが同様に採用されなければなりません。
Type: align
タイプ：合わせ
From: SPPI
投稿者：SPPI
Description: PIB and MIB row attributes reference a group of entries in another table. SPPI formalizes this by introducing PIB-TAG and PIB-REFERENCES clauses. This functionality should be retained in SMIng.
説明：PIBとMIB行属性は、別のテーブル内のエントリのグループを参照します。 SPPIは、PIB-TAGとPIB-REFERENCES句を導入することで、これを定式化します。この機能はSMIngに保持されるべきです。
Motivation: SPPI formalizes tag references. Some MIBs also use tag references (see SNMP-TARGET-MIB in RFC2573) even though SMIv2 does not provide a formal notation.
動機：SPPIはタグ参照を形式化。一部のMIBはまたSMIv2のが正式な表記法を提供していないにもかかわらず、（RFC2573にSNMP-TARGET-MIBを参照してください）タグ参照を使用しています。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: SMIng should allow the definition of a SEQUENCE OF attributes or attribute groups (Section 4.1.27).
説明：SMIngは属性または属性グループ（セクション4.1.27）の配列の定義を可能にしなければなりません。
Motivation: The desire for the ability to have variable-length, multi-valued objects.
モチベーション：可変長、多値オブジェクトを有する能力に対する要望。
Notes: Some issues with arrays are still unclear. As long as there are no concepts to solve the problems with access semantics (how to achieve atomic access to arbitrary-sized arrays) and their mappings to SNMP and COPS-PR protocol operations, arrays cannot be more than a nice to have objective.
注意：アレイを持ついくつかの問題がまだ不明です。限りアクセスのセマンティクス（任意のサイズのアレイへのアトミックアクセスを実現する方法）とSNMPとCOPS - PRプロトコル操作へのマッピングの問題を解決するために何の概念が存在しないとして、配列は目的を持っている素敵超えることはできません。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: Informational text (DESCRIPTION, REFERENCE, ...) should allow i18nized encoding, probably UTF-8.
説明：情報テキスト（DESCRIPTION、REFERENCEは、...）i18nizedエンコーディング、おそらくUTF-8を可能にしなければなりません。
Motivation: There has been some demand for i18n in the past. The BCP RFC 2277 demands for internationalization.
動機：過去の国際化のためのいくつかの要望がありました。 BCPのRFC国際化のための2277の需要。
Notes: Although English is the language of IETF documents, SMIng should allow other languages for private use.
注：英語がIETFの文書の言語ですが、SMIngは、私的使用のために他の言語を許可する必要があります。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: It should be possible to separate the domain specific data modelling work from the network management protocol specific work.
説明：これは、ネットワーク管理プロトコル特有の仕事からドメイン固有のデータモデリング作業を分離することが可能でなければなりません。
Motivation: Today, working groups designing new protocols are forced to care about the design of SNMP MIBs and maybe COPR-PR PIBs to manage the new protocol. This means that experts in a specific domain are faced with details of at least one foreign (network management) technology. This leads to hard work and long revision processes. It would be a win to separate the task of pure data modelling which can be done by the domain experts easily from the network management protocol specific mappings. The mapping to SNMP and/or COPS-PR can be done (a) later separately and (b) by network management experts. This required NM expertise no longer hinders the progress of the domain specific working groups.
動機：今日は、新しいプロトコルを設計ワーキンググループは、SNMP MIBと多分COPR-PRのPIBは、新しいプロトコルを管理するためのデザインを気にすることを余儀なくされています。これは、特定のドメインの専門家は、少なくとも一つの外国（ネットワーク管理）技術の詳細に直面していることを意味します。これは、ハードワークと長い改正のプロセスにつながります。ネットワーク管理プロトコル固有のマッピングから簡単にドメインの専門家が行うことができ、純粋なデータモデリングのタスクを分離するために勝つだろう。 SNMPおよび/またはCOPS-PRへのマッピングを行うことができる（a）の後、別々におよびネットワーク管理の専門家（B）。この必須NMの専門知識は、もはやドメイン固有のワーキンググループの進歩を妨げません。
This section represents the list of objectives that were rejected during the discussion on the objectives. Those objectives that have been rejected need not be addressed by SMIng. This does not imply that they must not be addressed.
このセクションでは、目標の議論の中に拒否された目標のリストを表します。拒否されたこれらの目的はSMIngによって対処する必要はありません。これは、彼らが対処してはならないことを意味するものではありません。
Type: basic
タイプ：ベーシック
From: WG
投稿者：WG
Description: Reality sucks. All information expressed in SMIng may not be directly translatable to a MIB or PIB construct, but all information should be able to be conveyed in documentation or via other mechanisms.
説明：現実は吸います。 SMIngで発現されるすべての情報は、MIBまたはPIB構築するために直接翻訳可能ではないかもしれないが、すべての情報は、ドキュメントの中、または他の機構を介して搬送することができなければなりません。
Motivation: SMIng working group requires this to ease transition.
動機：SMIngワーキンググループは、移行を容易にするために、これを必要とします。
Notes: The SMIng language itself cannot require what compilers do that translate SMIng into something else. So this seems to fall out of the scope of the current working group charter.
注：SMIng言語自体は、それが何か他のものにSMIngを翻訳何のコンパイラ要求できません。これは、現在のワーキンググループ憲章の適用範囲から外れるように思われます。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: SMIng should provide mechanisms to formally specify constraints between values of multiple attributes.
説明：SMIngは正式に複数の属性の値の間の制約を指定するためのメカニズムを提供する必要があります。
Motivation: Constraints on attribute values occur where one or more attributes may affect the value or range of values for another attribute. One such relationship exists in IPsec, where the type of security algorithm determines the range of possible values for other attributes such as the corresponding key size.
動機：1つ以上の属性が別の属性の値または値の範囲に影響を与える可能性がある場所属性値の制約が発生します。一つのそのような関係は、セキュリティアルゴリズムのタイプは、対応するキーのサイズなどの他の属性の可能な値の範囲を決定するのIPsec、に存在します。
Notes: This objective as is has been rejected as too general, and therefore virtually impossible to implement. However, constraints that are implicit with discriminated unions (Section 4.1.18), enumerated types (Section 4.1.17), pointer constraints (Section 4.1.21)), etc., are accepted and these implicit constraints are mentioned in the respective objectives.
注：この目的はそのままあまりにも一般的なとして拒否されたので、事実上不可能実装します。しかし、差別組合（セクション4.1.18）と暗黙的制約、列挙型は、（セクション4.1.17）、ポインタの制約（セクション4.1.21））などが、受け入れられ、これらの暗黙的な制約は、それぞれの目的に記載されています。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: SMIng should provide a mechanism to formally express that certain sets of attributes can only be modified in combination.
説明：SMIngは、正式な属性の特定のセットのみの組み合わせで修飾することができることを表現するためのメカニズムを提供しなければなりません。
Motivation: COPS-PR always does operations on table rows in a single transaction. There are SMIv2 attribute combinations that need to be modified together (such as InetAddressType, InetAddress).
動機：COPS-PRは、常に、単一のトランザクションでテーブルの行の操作を行います。 （などのInetAddressType、InetAddressのように）一緒に変更する必要がSMIv2の属性の組み合わせがあります。
Notes: Alternative is to either use Methods (Section 4.2.1) or assume that all attributes in an attribute group (Section 4.1.27) are to be considered atomic.
注：代替は、使用方法（4.2.1項）のいずれかにあるか、属性グループ（セクション4.1.27）内のすべての属性が原子考慮されるべきであることを前提としています。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: Method definitions should provide constraints on parameters.
説明：メソッドの定義はパラメータの制約を提供する必要があります。
Motivation: None.
動機：なし。
Notes: Unless methods (Section 4.2.1) are done, there is no use for this. Furthermore, this objective has not been motivated by any proponent.
注：メソッド（セクション4.2.1）が行われない限り、このための使用はありません。さらに、この目的は、任意の提案者が動機とされていません。
Type: basic
タイプ：ベーシック
From: SMI
投稿者：SMI
Description: SMIng should provide mechanisms to describe agent implementations.
説明：SMIngは、エージェントの実装を記述するためのメカニズムを提供する必要があります。
Motivation: To permit manager to determine variations from the standard for an implementation.
動機：実装の標準からの変化を決定するために管理を許可します。
Notes: Agent capabilities should not be part of SMIng, but should instead be a separate capabilities table.
注：Agentの機能はSMIngの一部であってはならないが、代わりに別の機能テーブルでなければなりません。
Type: new
タイプ：新しいです
From: NMRG, WG
投稿者：NMRG、WG
Description: Ability to formally depict existence dependency, value dependency, aggregation, containment, and other relationships between attributes or attribute groups.
説明：正式に存在依存、値依存性、集約、封じ込め、および属性または属性グループ間の他の関係を描写する能力。
Motivation: Helps humans to understand the conceptual model of a module. Helps implementers of MIB compilers to generate more `intelligent' code.
動機：人間はモジュールの概念モデルを理解するのに役立ちます。 MIBコンパイラの実装がより `インテリジェント」なコードを生成するのに役立ちます。
Notes: This objective was deemed too general to be useful and instead the individual types of relationship objectives (e.g., pointers, inheritance, containment, etc.) are evaluated on a case-by-case basis with the specific relationships deemed useful being included as accepted objectives.
注：この目的は便利であるには余りにも一般的なものとみなされ、代わりに特定の関係のように含まれている有用であると考えて関係の目標（例えば、ポインタ、相続、封じ込めなど）の個々のタイプは、ケースバイケースで評価されています目標を受け入れました。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: SMIng should support a mechanism to formally define procedures that are used by managers when interacting with an agent.
説明：SMIngは正式エージェントと対話するときマネージャーによって使用される手順を定義するためのメカニズムをサポートしなければなりません。
Motivation: None.
動機：なし。
Notes: This objective has not been motivated by any proponent.
注：この目的は、任意の提案者によって動機づけされていません。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: SMIng should provide mechanisms to explicitly specify associations.
説明：SMIngは、明示的に関連付けを指定するためのメカニズムを提供しなければなりません。
Motivation: None.
動機：なし。
Notes: This objective has not been motivated by any proponent.
注：この目的は、任意の提案者によって動機づけされていません。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: Cardinalities between associations should be formally defined.
説明：団体間のカーディナリティが、正式に定義されなければなりません。
Motivation: If you have an association between attribute groups A and B, the cardinality of A indicates how many instances of A may be associated with a single instance of B. Our discussions in Minneapolis indicated that we want to convey "how many" instances are associated in order to define the best mapping algorithm - whether a new table, a single pointer, etc. For example, do we use RowPointer or an integer index into another table? Do we map to a table that holds instances of the association/relationship itself?
動機：あなたは属性グループAとBとの間の関連性を持っている場合は、Aの基数はミネアポリスで私たちの議論は、我々がインスタンスである「どのように多くの」伝えたいことが示されたB.の単一のインスタンスに関連付けすることができるどのように多くのAのインスタンスを示しています最高のマッピングアルゴリズムを定義するために、関連する - たとえば、新しいテーブルかどうか、単一のポインタなどを、我々は別のテーブルにRowPointerまたは整数インデックスを使用していますか？私たちは協会/関係自体のインスタンスを保持するテーブルにマップしていますか？
Notes: Without associations (Section 4.3.8), this has no use.
注：団体（4.3.8）がなければ、これは使用していません。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: The SMIng documents should give clear guidance on which kind of information (with respect to generality, type/attribute group/extension/..) should be put in which kind of a module.
説明：SMIngドキュメントは、（一般性に関しては、タイプ/属性グループ/拡張/ ..）情報の種類は、モジュールのどの種類に置かれるべきで明確な指針を与える必要があります。
E.g., in SMIv2 we don't like to import Utf8String from SYSAPPL-MIB, but we also do not like to introduce a redundant definition.
例えば、SMIv2の中で私たちは、SYSAPPL-MIBからUTF8STRINGをインポートするのが好きではありませんが、我々はまた、冗長な定義を紹介して好きではありません。
A module review process should probably be described that ensures that generally useful definitions do not go into device or service specific modules.
モジュールのレビュープロセスは、おそらく一般的に有用な定義は、デバイスまたはサービスの特定のモジュールに行かないことを確実に記述する必要があります。
Motivation: Bad experience with SMIv2.
動機：SMIv2のと悪い経験。
Notes: It is not clear how this can be done with the language to be created by SMIng WG.
注：これはSMIng WGによって作成される言語で行うことができますどのようにそれは明らかではありません。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: There should be a clear statement how SMIng modules are mapped to files (1:1, n:1?) and how files should be named (by module name in case of 1:1 mapping?).
説明：（1の場合にはモジュール名で？：1マッピング）ファイルを命名する方法と、（1？：1、nは1）がありSMIngモジュールがファイルにどのようにマッピングされるか明確な声明でなければなりません。
Motivation: SMI implementations show up a variety of filename extensions (.txt, .smi, .my, none). Some expect all modules in a single file, others don't. This makes it more difficult to exchange modules.
動機：SMIの実装は、ファイル名の拡張子の様々な表示形式（.txt、.smi、.MY、なし）。いくつかは他の人にはない、単一のファイルにすべてのモジュールを期待しています。これは、交換モジュールに、それはより困難にします。
Notes: This is just an implementation detail and is best left to a BCP and not made a part of the language definition.
注：これは単なる実装の詳細で、最高の言語定義の一部を作ったBCPに左とされていません。
Type: new
タイプ：新しいです
From: NMRG
投稿者：NMRG
Description: The grammar of the language should be as simple as possible. It should be free of exception rules. A measurement of simplicity is shortness of the ABNF grammar.
説明：言語の文法は、できるだけ簡単にする必要があります。これは、例外ルールがあってはなりません。シンプルさの測定は、ABNF文法の短さです。
Motivation: Ease of implementation. Ease of learning/understanding.
動機：実装のしやすさ。学習/理解を容易にします。
Notes: This seems like an obvious objective, however shortness of the ABNF grammar is not necessarily a reflection of the simplicity of the grammar.
注：これは、しかし、ABNF文法の短さは、必ずしも文法の単純さの反映ではない、明確な目的のように思えます。
Type: fix
タイプ：修正
From: NMRG
投稿者：NMRG
Description: Module specific information (organization, contact, description, revision information) should be bound to the module itself and not to an artificial node (like SMIv2 MODULE-IDENTITY).
説明：モジュール固有の情報（組織、コンタクト、説明、リビジョン情報）モジュール自体にではなく（SMIv2のMODULE-IDENTITYなど）人工ノードに結合されなければなりません。
Motivation: Simplicity and design cleanup.
動機：シンプルさとデザインのクリーンアップ。
Notes: This does not seem to be a problem with the current SMI. Although simplification is a good thing, this detail is not considered an objective.
注：これは、現在のSMIに問題があるとは思われません。簡素化は良いことですが、この詳細は、客観的とはみなされません。
Type: new
タイプ：新しいです
From: WG
投稿者：WG
Description: Currently the namespace of modules is flat and there is no structure in module naming causing the potential risk of name clashes. Possible solutions:
説明：現在のモジュールの名前空間は平坦であり、名前の衝突の潜在的なリスクの原因となるモジュールの命名には構造がありません。可能な解決策：
* Assume module names are globally unique (just as SMIv1/v2), just give some recommendations on module names.
*単にモジュール名にいくつかの勧告を与え、モジュール名が（ちょうどでSMIv1 / v2のような）世界的にユニークであると仮定します。
* Force all organizations, WGs and vendors to apply a name prefix (e.g. CISCO-GAGA-MIB, IETF-DISMAN-SCRIPT-MIB?).
*フォースすべての組織、のWGとベンダーは名前の接頭辞（例えば、CISCO-GAGA-MIB、IETF-DISMAN-SCRIPT-MIBを？）を適用します。
* Force enterprises to apply a prefix based on the enterprise number (e.g. ENT2021-SOME-MIB).
*強制企業は、企業数（例えばENT2021-SOME-MIB）に基づいてプレフィックスを適用します。
* Put module names in a hierarchical domain based namespace (e.g. DISMAN-SCRIPT-MIB.ietf.org).
*階層的なドメインベースの名前空間（例えばDISMAN-SCRIPT-MIB.ietf.org）でモジュール名を入れてください。
Motivation: Reduce risk of module name clashes.
動機：モジュール名の衝突の危険性を軽減します。
Notes: Some aspects of this objective overlap with other objectives (namespace control (Section 4.1.9)) and other aspects were thought best left to a BCP.
注：その他の目的（名前空間制御（第4.1.9項））および他の局面で、この目的の重なりのいくつかの側面が考え最高のBCPに残っていました。
Type: fix
タイプ：修正
From: NMRG
投稿者：NMRG
Description: There has been some confusion whether hyphens are allowed in SMIv2 identifiers: Module names are allowed to contain hyphens. Node identifiers usually are not. But for example `mib-2' is a frequently used identifier that contains a hyphen due to its SMIv1 origin, when hyphen were not disallowed. Similarly, a number of named numbers of enumeration types contain hyphens violating an SMIv2 rule.
説明：モジュール名がハイフンを含むように許可されています。ハイフンはSMIv2の識別子で許可されているかどうかを、いくつかの混乱がありました。ノード識別子は、通常はありません。しかし、例えば `MIB-2' はハイフンが禁止されていなかったのでSMIv1の原点に起因するハイフンが含まれて頻繁に使用される識別子です。同様に、列挙型の名前の番号の数は、SMIv2のルールに違反ハイフンが含まれています。
SMIng should simply allow hyphens in all kinds of identifiers. No exceptions.
SMIngは単に識別子のすべての種類のハイフンを許可する必要があります。例外なく。
Motivation: Reduce confusion and exceptions. Requires, however, that implementation mappings properly quote hyphens where appropriate.
動機：混乱や例外を減らします。適切な場合には、しかし、その実装のマッピングが適切にハイフンを引用必要です。
Notes: This nit-picking is not worth to be subject to the discussion on objectives. However, SMIng should care about the fact that compilers have to map SMIng to programming languages where a hyphen is a minus and thus not allowed in identifiers.
注：このNIT-ピッキングが目標に関する議論の対象にする価値はありません。しかし、SMIngは、コンパイラは、ハイフンがマイナスであるため、識別子では許可されていないプログラミング言語にSMIngをマップするために持っているという事実を気にする必要があります。
This document defines objectives for a language with which to write and read descriptions of management information. The language itself has no security impact on the Internet.
この文書では、書き込みと管理情報の記述を読んでいると、言語のための目標を定義します。言語自体は、インターネット上ではセキュリティへの影響はありません。
Thanks to Dave Durham, whose work on the original NIM (Network Information Model) draft was used in generating this document.
作品のオリジナルNIM（ネットワーク情報モデル）のドラフトでこの文書を生成するのに使用されたデイブ・ダーラム、に感謝します。
Thanks to Andrea Westerinen for her contributions on the original NIM requirements and SMIng objectives drafts.
オリジナルのNIM要件とSMIng目的のドラフトでの彼女の貢献のためアンドレアWesterinenに感謝します。
[1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[1]ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィンを、 "簡易ネットワーク管理プロトコル（SNMP）"、STD 15、RFC 1157、1990年5月。
[2] McCloghrie, K., Case, J., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[2] McCloghrie、K.、ケース、J.、ローズ、M.、およびS. Waldbusser、 "簡易ネットワーク管理プロトコルのバージョン2のためのプロトコル操作（SNMPv2の）"、RFC 1905、1996年1月。
[3] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.
[3]チャン、K.、Seligson、J.、ダラム、D.、ガイ、S.、McCloghrie、K.、ヘルツォーク、S.、Reichmeyer、F.、Yavatkar、R.およびA.スミス、「使用をCOPSポリシープロビジョニング（COPS-PR）」、RFC 3084、2001年3月のため。
[4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[4] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "経営情報バージョン2（SMIv2）の構造"、STD 58、RFC 2578、 1999年4月。
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[5] McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.およびS. Waldbusser、 "SMIv2のためのテキストの表記法"、STD 58、RFC 2579、1999年4月。
[6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[6] McCloghrie、K.、パーキンス、D.およびJ. Schoenwaelder、STD 58、RFC 2580、1999年4月 "SMIv2のための順応文"。
[7] 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.
[7] McCloghrie、K.、ファイン、M.、Seligson、J.、チャン、K.、ハーン、S.、Sahita、R.、スミス、A.及びSPPI F. Reichmeyer、「ポリシーのプロビジョニング情報の構造（ ）」、RFC 3159、2001年8月。
Chris Elliott Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA
クリス・エリオットシスコシステムズ7025キットクリーク道路リサーチトライアングルパーク、NC 27709 USA
EMail: chelliot@cisco.com
メールアドレス：chelliot@cisco.com
David Harrington Enterasys Networks 35 Industrial Way P.O. Box 5005 Rochester, NH 03866-5005 USA
デヴィッド・ハリントンのEnterasys Networksの35産業ウェイ私書箱ボックス5005ロチェスター、NH 03866から5005 USA
EMail: dbh@enterasys.com
メールアドレス：dbh@enterasys.com
Jamie Jason Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro, OR 97124 USA
ジェイミージェイソンインテルコーポレーションMS JF3-206 2111 NE 25日アベニュー。ヒルズボロ、OR 97124 USA
EMail: jamie.jason@intel.com
メールアドレス：jamie.jason@intel.com
Juergen Schoenwaelder TU Braunschweig Muehlenpfordtstr. 23 38106 Braunschweig Germany
ユルゲンSchoenwaelder TUブラウンシュヴァイクMühlenpfordtstr。 23 38106ブラウンシュヴァイク、ドイツ
EMail: schoenw@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/
電子メール：schoenw@ibr.cs.tu-bs.de URI：http://www.ibr.cs.tu-bs.de/
Frank Strauss TU Braunschweig Muehlenpfordtstr. 23 38106 Braunschweig Germany
フランク・シュトラウスTUブラウンシュヴァイクMühlenpfordtstr。 23 38106ブラウンシュヴァイク、ドイツ
EMail: strauss@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/
電子メール：strauss@ibr.cs.tu-bs.de URI：http://www.ibr.cs.tu-bs.de/
Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack, NH. 03054 USA
ウォルター・ワイスEllacoya Networksの7ヘンリー・クレイ博士メリマック、NH。 03054 USA
EMail: wweiss@ellacoya.com
メールアドレス：wweiss@ellacoya.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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機能のための基金は現在、インターネット協会によって提供されます。