[要約] RFC 3216は、SMIng（Structured Management Information Next Generation）の目標と要約を提供しています。その目的は、SNMP（Simple Network Management Protocol）のMIB（Management Information Base）の構造化と拡張を改善し、ネットワーク管理の効率と柔軟性を向上させることです。
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.
Copyright（c）The Internet Society（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.
このドキュメントの目的は、後続の言語仕様が対処しようとする一連の目的として機能することです。スミングの目的に関するコンセンサスに向けたワーキンググループの議論の結果を捉えています。
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] MIBSおよびSPPI [7] PIBSに翻訳することもできます。属性、属性グループ、メソッド、組織のための慣習の再利用可能なデータ構造、および関係を表現するためのメカニズムなどの概念について説明します。
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ベースの製品から、標準の管理プロトコルやテキストスクリプトまでさまざまです。操作される基礎となるシステムは、システムプログラミング、専用データの説明を介して、MIBS、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.
スミングワーキンググループは、別の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.
もう1つの動機は、モデル化された情報のより表現力豊かで完全な表現を許可することです。考慮される追加の表現力と完全性の例は、テーブルの存在関係、インスタンスの作成/削除能力の表現、および継承を使用して属性グループを定義する能力を正式に定義する能力です。これらの追加機能については、後続のセクションで説明します。
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）ネットワーク管理データモデリングのART状態を強化するという2つの主な目標は、競合につながる可能性があることが認識されています。そのような場合、スミングワーキンググループのコンセンサスは、ネットワーク管理データモデリングのART状態の強化に焦点を当てることです。
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.
Internet Research Task Force（IRTF）のネットワーク管理研究グループ（NMRG）は、複数のプロトコルで使用できるプロトコルに依存しないデータ定義言語を作成する問題を調査しました。SMIV2とSPPIは非常に似ているため、NMRGはこれら2つの言語の統合に焦点を合わせましたが、LDAPや直径などの他のプロトコルに使用できる言語を生成するための目的を抽象化する方法も調査しました。NMRGは、一方、期限切れのインターネットドラフトで彼らの研究の結果を公開しましたが、SMING言語の開発で考慮すべき提案の1つとして仕様を提出しました。
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 Working Groupは、検討のための提出を受け入れ、提案を使用して、克服すべき目標と障害の可能性をよりよく理解しています。有用な場合、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.
* Align：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 From：目的の起源を定義し、次の値の1つ以上を含むフィールド：
* 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 注：目的に関するオプションのメモ。たとえば、これには、この目的がスミングワーキンググループに必要ではない理由が、とにかく考慮すべき理由を正当化する理由が含まれている可能性があります。メモは、目標に関する議論の参加者の意見である可能性があり、そのため、ワーキンググループのコンセンサスまたは目標編集チームの推奨と見なされるべきではありません。
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.
このセクションでは、スミングワーキンググループが価値があると受け入れ、したがってさらなる検討に値するものとして受け入れられた目標のリストを表しています。これらの目的のそれぞれは、ワーキンググループによって評価され、利益が許容可能なレベルのコストが生じるかどうかを判断する必要があります。受け入れられた目標は、コスト/給付分析が利益がコストを正当化しない、またはより重要とみなされる他の1つ以上の受け入れられた目標と直接対立していると判断した場合、その後拒否される場合があります。
Type: new
タイプ：新品
From: NMRG
From：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に基づいて1つのドキュメントで定義されています。スミングのコアは1つのドキュメントで定義され、外部仕様とは無関係でなければなりません。
Motivation: Self-containment.
動機：自己満足。
Type: basic
タイプ：基本
From: SMI, SPPI, WG
FROM：SMI、SPPI、WG
Description: SMIng definitions must be represented in a textual format.
説明：スミングの定義は、テキスト形式で表現する必要があります。
Motivation: General IETF consensus.
動機：一般的なIETFコンセンサス。
Type: basic
タイプ：基本
From: WG
From：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モジュールを作成することは可能である必要があります。
Motivation: The syntax must make it easy for humans to read and write SMIng modules.
動機：構文により、人間がスミングモジュールを読み書きできるようにする必要があります。
Type: new
タイプ：新品
From: NMRG
From：nmrg
Description: There must be a rigorously defined syntax for the SMIng language.
説明：スミング言語には厳密に定義された構文が必要です。
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
タイプ：align
From: SMI, SPPI
From：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
From：nmrg
Description: The language must have characteristics, so that future modules can contain information of future syntax without breaking original SMIng parsers.
説明：言語には特性が必要なため、将来のモジュールには、元のスミングパーサーを壊すことなく、将来の構文の情報を含めることができます。
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
From：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
From：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
From：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
From：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
From：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
From：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では、オブジェクトアイデンティティを使用して、中央レジストリを必要とせずに明確なアイデンティティを定義できます。SMIはOIDを使用して、そのようなアイデンティティへの参照を表す値を表します。スミングには、同様のメカニズムが必要です（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
From：チャーター
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
From：チャーター
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 Working Groupは、他の目標の進捗を妨げない限り、他のプロトコルにマッピングを定義できます。
Motivation: SMIng working group charter.
動機：スミングワーキンググループチャーター。
Type: basic
タイプ：基本
From: Charter
From：チャーター
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.
説明：スミング言語構造は、可能な限り、SMIV2とSPPIに翻訳可能でなければなりません。SMING言語の標準化の時点で、標準のトラック上の既存のSMIV2 MIBSとSPPI PIBSは、SMING言語に翻訳する必要はありません。新しいMIBS/PIBSは、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.
動機：既存のツールの最良の逆方向の互換性を提供しながら、すでに標準のトラックにあるMIBS/PIBに不必要な負担をかけません。
Type: basic
タイプ：基本
From: SMI, SPPI
From：Smi、Sppi
Description: SMIng must support the base data types Integer32, Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString, and OID.
説明：SMINGは、ベースデータ型integer32、unsigned32、integer64、unsigned64、列挙、ビット、オクツーティング、および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
From：Smi、Sppi
Description: SMIng must provide support for enumerations. Enumerated values must be a part of the enumeration definition.
説明：スミングは列挙のサポートを提供する必要があります。列挙された値は、列挙定義の一部でなければなりません。
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
From：Wg
Description: SMIng must support discriminated unions.
説明：スミングは差別された組合を支援する必要があります。
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、inetAdddressipv6（Union）など、関連属性をグループ化できます。差別された組合の欠如は、一部のディスマンのミッドレベルマネージャーMIBSで比較的複雑なまばらなテーブルワークアラウンドにもつながりました。
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
From：Smi、Sppi
Description: SMIng must allow specifying pointers to instances (i.e., a pointer to a particular attribute in a row).
説明：スミングは、インスタンス（つまり、特定の属性へのポインターを連続して指定することを許可する必要があります。
Motivation: It is common practice in MIBs and PIBs to point to other instances.
動機：他のインスタンスを指すことは、MIBSとPIBSで一般的な慣行です。
Type: align
タイプ：align
From: SMI, SPPI
From：Smi、Sppi
Description: SMIng must allow specifying pointers to rows.
説明：スミングは、列にポインターを指定することを許可する必要があります。
Motivation: It is common practice in MIBs and PIBs to point to other rows (see RowPointer, PIB-REFERENCES).
動機：他の行を指すことは、MIBSとPIBSで一般的な慣行です（Rowpointer、PIB-Referencesを参照）。
Type: align
タイプ：align
From: SPPI
From：sppi
Description: SMIng must allow specifying the types of objects to which a pointer may point.
説明：スミングは、ポインターが指すことができるオブジェクトの種類を指定することを許可する必要があります。
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
From：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.
説明：スミングは、固定サイズと精度のベースタイプの固定セットをサポートする必要があります。SMI自体が変更されない限り、ベースタイプのリストを拡張できないでください。
Motivation: Interoperability.
動機付け：相互運用性。
Type: align
タイプ：align
From: 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.
from：smi、sppi説明：スミングは、ベースタイプから追加のセマンティクス（カウンター、ゲージ、文字列など）を提供する新しいタイプを導出するメカニズムをサポートする必要があります。派生型からの新しいタイプの導出を許可することも望ましい場合があります。新しいタイプは、専門化しているタイプよりも制限的または制限的でなければなりません。
Motivation: SMI uses application types and textual conventions. SPPI uses derived types.
動機：SMIはアプリケーションタイプとテキストの慣習を使用します。SPPIは派生タイプを使用します。
Type: fix
タイプ：修正
From: NMRG
From：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オブジェクトタイプの定義にはユニットが含まれている場合があり、defval句が含まれ、テキストコンベニオンにはディスプレイヒントが含まれている場合があります。同様のファッションユニットとデフォルト値は、定義されたタイプに適用する必要があり、フォーマット情報は属性に適用する必要があります。
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は、KBytesなどのTCを導入し、TCのすべての使用法はユニット「KBYTES」を指定します。ユニットがタイプ定義自体に添付されている場合、物事を単純化します。
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
タイプ：align
From: SMI, SPPI
From：Smi、Sppi
Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in the SNMP/COPS-PR protocol mappings.
説明：SMINGは、SNMP/COPS-PRプロトコルマッピングでインデックス、増強、および拡張をサポートする必要があります。
Motivation: These three table existence relationships exist either in the SMIv2 or the SPPI.
動機：これらの3つのテーブルの存在関係は、SMIV2またはSPPIに存在します。
Type: new
タイプ：新品
From: NMRG
From：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.
モチベーション：再発行声明により、インデックス付け注文を交換できます。拡張ステートメントは、テーブル行の間に1：nの存在関係があることを正式に述べています。
Type: new
タイプ：新品
From: NMRG
From：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
From：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
From：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
From：nmrg、wg
Description: SMIng must differentiate between "final" and reusable attribute groups, where the reuse of attribute groups covers inheritance and containment.
説明：スミングは、属性グループの再利用が継承と封じ込めをカバーする「最終」と再利用可能な属性グループを区別する必要があります。
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
From：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
タイプ：align
From: SMI, SPPI
From：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は、インスタンスの作成/削除操作を定義するメカニズムをサポートする必要があります。インストールエラーなどの特定の作成/削除エラーをサポートする必要があります。
Motivation: Available for row creation in SMI, and available in SPPI.
モチベーション：SMIでの列作成で利用可能で、SPPIで利用可能です。
Type: basic
タイプ：基本
From: SMI, SPPI
From：Smi、Sppi
Description: SMIng must allow specifying range and size constraints where applicable.
説明：スミングは、該当する場合は範囲とサイズの制約を指定する必要があります。
Motivation: The SMI and SPPI both support range and size constraints.
動機：SMIとSPPIはどちらも範囲とサイズの制約をサポートします。
Type: basic
タイプ：基本
From: SPPI
From：sppi
Description: SMIng must allow the specification of uniqueness constraints on attributes. SMIng must allow the specification of multiple independent uniqueness constraints.
説明：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.
動機：属性に対する一意性制約に関する知識により、プロトコル固有のマッピング（インデックス条項など）を検証できます。知識は、コードジェネレーターが生成された実装固有のデータ構造を改善するために使用することもできます。
Type: basic
タイプ：基本
From: SMI, SPPI
From：Smi、Sppi
Description: SMIng must provide clear rules how one can extend SMIng modules without causing interoperability problems "over the wire".
説明：スミングは、「ワイヤー上で」相互運用性の問題を引き起こすことなく、どのようにスミングモジュールを拡張できるかを明確なルールを提供する必要があります。
Motivation: SMIv2 and SPPI have extension rules.
動機：SMIV2とSPPIには拡張ルールがあります。
Type: fix
タイプ：修正
From: WG
From：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
From：nmrg
Description: The SMIng language must avoid redundancy.
説明：スミング言語は冗長性を避ける必要があります。
Motivation: Remove any textual redundancy for things like table entries and SEQUENCE definitions, which only increase specifications without providing any value.
動機：テーブルエントリやシーケンス定義などのテキスト冗長性を削除します。これは、価値を提供せずに仕様を増やすだけです。
Type: basic
タイプ：基本
From: SMI, SPPI Description: SMIng must provide a mechanism for compliance and conformance specifications for protocol-independent definitions as well as for protocol mappings.
from：smi、sppi説明：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
From：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".
存在する必要があるObjects句は、適合グループに含まれる各オブジェクトを指定するために使用されます。指定された各オブジェクトは、オブジェクトグループマクロが表示されるのと同じ情報モジュールで定義する必要があり、「アクセス可能なもの」、「読み取り専用」、「読み取りワイト」の最大アクセス句値が必要です。、または「読み取り」。
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/
最後の文は、アクセス不可能なインデックスオブジェクトをオブジェクトグループに入れることを禁止します。したがって、コンプライアンス定義でその構文を改善することはできません。詳細については、http：//www.ibr.cs.tu-bs.de/ietf/smi-errata/を参照してください。
Motivation: This error should not be repeated in SMIng.
動機：このエラーは、スミングで繰り返されるべきではありません。
Type: basic
タイプ：基本
From: SPPI
From：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
From：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モジュールでは、いくつかの言語キーワード（マクロと多くのベースタイプ）を異なるSMI言語を定義するモジュールからインポートする必要があります。Object-Type、Module-Identity、Integer32はSNMPV2-SMIからインポートする必要があり、テキストコンベンションは、使用する場合はSNMPV2-TCからインポートする必要があります。MIBの著者は、これらのインポートルールについて継続的に混乱しています。スミングでは、定義された識別子のみをインポートする必要があります。すべてのSMING言語キーワードは暗黙的に知られている必要があり、モジュールからインポートする必要はありません。
Motivation: Reduce confusion. Clarify the set of language keywords.
動機：混乱を減らす。言語キーワードのセットを明確にします。
Type: align
タイプ：align
From: SMI, SPPI
From：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の名前のインスタンスは異なります。スミングは、インスタンスの命名を整列する必要があります（プロトコルニュートラルモデルまたはプロトコルマッピングのいずれか）。
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
From：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.
説明：さまざまな種類の識別子の許可された長さは、現在の「32を超えないでください」（「64」を超えてはならない）ルールから延長する必要があります。
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
From：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の定義では同じではありません。MIBSとPIBSは、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
From：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]（Ping、Traceroute、Lookup操作）にあるような運用インターフェイスの定義をサポートするには、方法が必要です。また、Constructor/Destructorインターフェイスを定義する機能は、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
From：Wg
Description: SMIng should support a standard format for unions.
説明：スミングは、組合の標準形式をサポートする必要があります。
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.
動機：属性が多くのタイプの値のいずれかを含めることができます。組合の欠如は、一部のディスマンの中規模マネージャーで比較的複雑なまばらなテーブルワークアラウンドにつながりました。差別化された組合からのものにもかかわらず（セクション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.
注：SNMPとCOPS-PRは、特定のOIDにどのようなデータ型が採用するかを気にしないため、SNMPとCOPS-PRがすでに組合をサポートできるということです。
Type: new
タイプ：新品
From: WG, NMRG
From：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/...
動機：スミングの拡張であっても、言語を変更せずに追加できないため、ベースタイプを欠くことは後で傷つく可能性があります。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
From：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.
注：スミングワーキンググループがC様構文を採用している場合、C /Javaシングルラインコメントも同様に採用する必要があります。
Type: align
タイプ：align
From: SPPI
From：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 ROW属性は、別のテーブルにあるエントリのグループを参照します。SPPIは、PIBタグとPIBの参照条項を導入することにより、これを形式化します。この機能は、スミングで保持する必要があります。
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はタグ参照を形式化します。SMIV2は正式な表記を提供していない場合でも、一部のMIBSはタグ参照を使用しています（RFC2573のSNMP-Target-Mibを参照）。
Type: new
タイプ：新品
From: WG
From：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
From：Wg
Description: Informational text (DESCRIPTION, REFERENCE, ...) should allow i18nized encoding, probably UTF-8.
説明：情報テキスト（説明、参照、...）は、おそらくUTF-8をi18Nizedエンコードすることを許可する必要があります。
Motivation: There has been some demand for i18n in the past. The BCP RFC 2277 demands for internationalization.
モチベーション：過去にはI18Nに対する需要がありました。BCP RFC 2277は国際化の要求を要求しています。
Notes: Although English is the language of IETF documents, SMIng should allow other languages for private use.
注：英語はIETFドキュメントの言語ですが、スミングは他の言語を個人使用することを許可する必要があります。
Type: new
タイプ：新品
From: NMRG
From：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 MIBSおよびおそらくCOPR-PR PIBの設計に関心を持たざるを得ません。これは、特定のドメインの専門家が、少なくとも1つの外国（ネットワーク管理）テクノロジーの詳細に直面していることを意味します。これは、勤勉さと長い改訂プロセスにつながります。ネットワーク管理プロトコル固有のマッピングからドメインの専門家が簡単に実行できる純粋なデータモデリングのタスクを分離することは勝ちます。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.
このセクションでは、目的に関する議論中に拒否された目的のリストを表します。拒否されたこれらの目的は、スミングによって対処する必要はありません。これは、それらに対処してはならないことを意味するものではありません。
Type: basic
タイプ：基本
From: WG
From：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.
動機：スミングワーキンググループは、これを容易にするために必要です。
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.
注：スミング言語自体は、スミングを他の何かに変換するコンパイラーが行うことを要求することはできません。したがって、これは現在のワーキンググループチャーターの範囲から抜け出すようです。
Type: new
タイプ：新品
From: WG
From：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つ以上の属性が別の属性の値または値の範囲に影響を与える可能性がある場合に発生します。そのような関係の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
From：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は常に1回のトランザクションでテーブル行で操作を行います。一緒に変更する必要があるSMIV2属性の組み合わせがあります（InetAddress Type、InetAddressなど）。
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
From：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
From：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.
注：エージェント機能はSMINGの一部であるべきではなく、代わりに個別の機能テーブルである必要があります。
Type: new
タイプ：新品
From: NMRG, WG
From：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
From：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
From：Wg
Description: SMIng should provide mechanisms to explicitly specify associations.
説明：スミングは、関連性を明示的に指定するメカニズムを提供する必要があります。
Motivation: None.
動機：なし。
Notes: This objective has not been motivated by any proponent.
注：この目的は、どのような支持者によって動機付けられていません。
Type: new
タイプ：新品
From: WG
From：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のカーディナリティは、Aの1つのインスタンスがBの単一のインスタンスに関連付けられている可能性があることを示しています。たとえば、新しいテーブル、単一のポインターなど、最適なマッピングアルゴリズムを定義するために関連付けられています。たとえば、Rowpointerまたは整数インデックスを別のテーブルに使用しますか？協会/関係自体のインスタンスを保持するテーブルにマッピングしますか？
Notes: Without associations (Section 4.3.8), this has no use.
注：協会（セクション4.3.8）なしでは、これは役に立ちません。
Type: new
タイプ：新品
From: WG
From：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 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?).
from：nmrg説明：スミングモジュールがファイルにマッピングされる方法（1：1、n：1？）と[1：1のマッピングの場合はモジュール名によって）の名前を付ける方法が明確なステートメントがあります。
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、none）が表示されます。すべてのモジュールが単一のファイルにあると期待している人もいれば、そうでない人もいます。これにより、モジュールを交換することがより困難になります。
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
From：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
From：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モジュール同一性など）ではなく、モジュール自体にバインドする必要があります。
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
From：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?).
* すべての組織、WGS、およびベンダーに名前のプレフィックスを適用するように強制します（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））と他の目的と重複しています。
Type: fix
タイプ：修正
From: NMRG
From：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.
スミングは、あらゆる種類の識別子にハイフンを単純に許可する必要があります。例外なく。
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は、コンパイラーがスミンをマイナスにマッピングする必要があるという事実に気をつけてください。
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.
Dave Durhamのおかげで、元のNIM（ネットワーク情報モデル）ドラフトの作業がこのドキュメントの生成に使用されました。
Thanks to Andrea Westerinen for her contributions on the original NIM requirements and SMIng objectives drafts.
Andrea Westerinenに、元のNIM要件とSMINGの目標ドラフトに関する貢献について感謝します。
[1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.
[1] Case、J.、Fedor、M.、Schoffstall、M。and J. Davin、「Simple Network Management Protocol（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.、Case、J.、Rose、M。、およびS. Waldbusser、「単純なネットワーク管理プロトコル（SNMPV2）のバージョン2のプロトコル操作」、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] Chan、K.、Seligson、J.、Durham、D.、Gai、S.、McCloghrie、K.、Herzog、S.、Reichmeyer、F.、Yavatkar、R.、A。Smith、「ポリシープロビジョニングのための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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M。and 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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M. and 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.、Perkins、D。およびJ. Schoenwaelder、「SMIV2の適合ステートメント」、STD 58、RFC 2580、1999年4月。
[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.、Fine、M.、Seligson、J.、Chan、K.、Hahn、S.、Sahita、R.、Smith、A。and F. Reichmeyer、「政策プロビジョニング情報の構造（SPPI）」、RFC 3159、2001年8月。
Chris Elliott Cisco Systems 7025 Kit Creek Road Research Triangle Park, NC 27709 USA
Chris Elliott Cisco Systems 7025 Kit Creek Road Research Triangle Park、NC 27709 USA
EMail: chelliot@cisco.com
David Harrington Enterasys Networks 35 Industrial Way P.O. Box 5005 Rochester, NH 03866-5005 USA
David Harrington Enterasys Networks 35 Industrial Way P.O.ボックス5005ニューハンプシャー州ロチェスター03866-5005 USA
EMail: dbh@enterasys.com
Jamie Jason Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro, OR 97124 USA
Jamie Jason Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro、または97124 USA
EMail: jamie.jason@intel.com
Juergen Schoenwaelder TU Braunschweig Muehlenpfordtstr. 23 38106 Braunschweig Germany
Juergen Schoenwaelder Tu Braunschweig Muehlenpfordtr。23 38106 Braunschweigドイツ
EMail: schoenw@ibr.cs.tu-bs.de
URI: http://www.ibr.cs.tu-bs.de/
Frank Strauss
TU Braunschweig
Muehlenpfordtstr. 23
38106 Braunschweig
Germany
EMail: 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
Walter Weiss Ellacoya Networks 7 Henry Clay Dr. Merrimack、NH。03054 USA
EMail: wweiss@ellacoya.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。