RFC1904 日本語訳
1904 Conformance Statements for Version 2 of the Simple NetworkManagement Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S.Waldbusser. January 1996. (Format: TXT=47083 bytes) (Obsoletes RFC1444) (Obsoleted by RFC2580) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group SNMPv2 Working Group
Request for Comments: 1904 J. Case
Obsoletes: 1444 SNMP Research, Inc.
Category: Standards Track K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
January 1996
コメントを求めるワーキンググループSNMPv2ワーキンググループ要求をネットワークでつないでください: 1904年のJ.ケースは時代遅れにします: 1444年のSNMP研究Inc.カテゴリ: 標準化過程K.McCloghrieシスコシステムズInc.M.はドーヴァービーチコンサルティングInc.S.Waldbusser国際ネットワークサービス1996年1月に上昇しました。
Conformance Statements for Version 2 of the
Simple Network Management Protocol (SNMPv2)
簡単なネットワーク管理プロトコルのバージョン2のための順応声明(SNMPv2)
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Introduction ................................................ 2 1.1 A Note on Terminology ...................................... 3 2. Definitions ................................................. 3 2.1 The OBJECT-GROUP macro ..................................... 3 2.2 The NOTIFICATION-GROUP macro ............................... 4 2.3 The MODULE-COMPLIANCE macro ................................ 5 2.4 The AGENT-CAPABILITIES macro ............................... 7 3. Mapping of the OBJECT-GROUP macro ........................... 9 3.1 Mapping of the OBJECTS clause .............................. 10 3.2 Mapping of the STATUS clause ............................... 10 3.3 Mapping of the DESCRIPTION clause .......................... 10 3.4 Mapping of the REFERENCE clause ............................ 10 3.5 Mapping of the OBJECT-GROUP value .......................... 10 3.6 Usage Example .............................................. 11 4. Mapping of the NOTIFICATION-GROUP macro ..................... 11 4.1 Mapping of the NOTIFICATIONS clause ........................ 11 4.2 Mapping of the STATUS clause ............................... 11 4.3 Mapping of the DESCRIPTION clause .......................... 12 4.4 Mapping of the REFERENCE clause ............................ 12 4.5 Mapping of the NOTIFICATION-GROUP value .................... 12 4.6 Usage Example .............................................. 12 5. Mapping of the MODULE-COMPLIANCE macro ...................... 12 5.1 Mapping of the STATUS clause ............................... 13
1. 序論… 2 1.1 用語に関する注… 3 2. 定義… 3 2.1 OBJECT-GROUPマクロ… 3 2.2 NOTIFICATION-GROUPマクロ… 4 2.3 MODULE-COMPLIANCEマクロ… 5 2.4 エージェント-CAPABILITIESマクロ… 7 3. OBJECT-GROUPマクロに関するマッピング… 9 OBJECTS節に関する3.1マッピング… 10 STATUS節に関する3.2マッピング… 10 記述節に関する3.3マッピング… 10 REFERENCE節に関する3.4マッピング… 10 OBJECT-GROUP価値に関する3.5マッピング… 10 3.6使用例… 11 4. NOTIFICATION-GROUPマクロに関するマッピング… 11 NOTIFICATIONS節に関する4.1マッピング… 11 STATUS節に関する4.2マッピング… 11 記述節に関する4.3マッピング… 12 REFERENCE節に関する4.4マッピング… 12 NOTIFICATION-GROUP価値に関する4.5マッピング… 12 4.6使用例… 12 5. MODULE-COMPLIANCEマクロに関するマッピング… 12 STATUS節に関する5.1マッピング… 13
SNMPv2 Working Group Standards Track [Page 1] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[1ページ]RFC1904順応声明
5.2 Mapping of the DESCRIPTION clause .......................... 13 5.3 Mapping of the REFERENCE clause ............................ 13 5.4 Mapping of the MODULE clause ............................... 13 5.4.1 Mapping of the MANDATORY-GROUPS clause ................... 13 5.4.2 Mapping of the GROUP clause .............................. 14 5.4.3 Mapping of the OBJECT clause ............................. 14 5.4.3.1 Mapping of the SYNTAX clause ........................... 14 5.4.3.2 Mapping of the WRITE-SYNTAX clause ..................... 15 5.4.3.3 Mapping of the MIN-ACCESS clause ....................... 15 5.4.4 Mapping of the DESCRIPTION clause ........................ 15 5.5 Mapping of the MODULE-COMPLIANCE value ..................... 15 5.6 Usage Example .............................................. 16 6. Mapping of the AGENT-CAPABILITIES macro ..................... 16 6.1 Mapping of the PRODUCT-RELEASE clause ...................... 17 6.2 Mapping of the STATUS clause ............................... 17 6.3 Mapping of the DESCRIPTION clause .......................... 17 6.4 Mapping of the REFERENCE clause ............................ 17 6.5 Mapping of the SUPPORTS clause ............................. 18 6.5.1 Mapping of the INCLUDES clause ........................... 18 6.5.2 Mapping of the VARIATION clause .......................... 18 6.5.2.1 Mapping of the SYNTAX clause ........................... 18 6.5.2.2 Mapping of the WRITE-SYNTAX clause ..................... 18 6.5.2.3 Mapping of the ACCESS clause ........................... 19 6.5.2.4 Mapping of the CREATION-REQUIRES clause ................ 19 6.5.2.5 Mapping of the DEFVAL clause ........................... 20 6.5.2.6 Mapping of the DESCRIPTION clause ...................... 20 6.6 Mapping of the AGENT-CAPABILITIES value .................... 20 6.7 Usage Example .............................................. 20 7. Extending an Information Module ............................. 22 7.1 Conformance Groups ......................................... 22 7.2 Compliance Definitions ..................................... 22 7.3 Capabilities Definitions ................................... 22 8. Security Considerations ..................................... 23 9. Editor's Address ............................................ 23 10. Acknowledgements ........................................... 23 11. References ................................................. 24
記述節に関する5.2マッピング… 13 REFERENCE節に関する5.3マッピング… 13 MODULE節に関する5.4マッピング… 13 5.4 MANDATORY-GROUPS節に関する.1マッピング… 13 5.4 GROUP節に関する.2マッピング… 14 5.4 OBJECT節に関する.3マッピング… 14 5.4 .3 SYNTAX節に関する.1マッピング… 14 5.4 .3 WRITE-SYNTAX節に関する.2マッピング… 15 5.4 .3 MIN-ACCESS節に関する.3マッピング… 15 5.4 記述節に関する.4マッピング… 15 MODULE-COMPLIANCE価値に関する5.5マッピング… 15 5.6使用例… 16 6. エージェント-CAPABILITIESマクロに関するマッピング… 16 PRODUCT-RELEASE節に関する6.1マッピング… 17 STATUS節に関する6.2マッピング… 17 記述節に関する6.3マッピング… 17 REFERENCE節に関する6.4マッピング… 17 SUPPORTS節に関する6.5マッピング… 18 6.5 INCLUDES節に関する.1マッピング… 18 6.5 VARIATION節に関する.2マッピング… 18 6.5 .2 SYNTAX節に関する.1マッピング… 18 6.5 .2 WRITE-SYNTAX節に関する.2マッピング… 18 6.5 .2 ACCESS節に関する.3マッピング… 19 6.5 .2 CREATION-REQUIRES節に関する.4マッピング… 19 6.5 .2 DEFVAL節に関する.5マッピング… 20 6.5 .2 記述節に関する.6マッピング… 20 エージェント-CAPABILITIES価値に関する6.6マッピング… 20 6.7使用例… 20 7. 情報モジュールを広げています… 22 7.1 順応は分類されます… 22 7.2 承諾定義… 22 7.3の能力定義… 22 8. セキュリティ問題… 23 9. エディタのアドレス… 23 10. 承認… 23 11. 参照… 24
1. Introduction
1. 序論
A management system contains: several (potentially many) nodes, each with a processing entity, termed an agent, which has access to management instrumentation; at least one management station; and, a management protocol, used to convey management information between the agents and management stations. Operations of the protocol are carried out under an administrative framework which defines authentication, authorization, access control, and privacy policies.
マネージメントシステムは以下を含んでいます。 数個の(潜在的に多く)のノード(処理実体があるそれぞれ)がエージェントを呼びました。(そのエージェントは、管理計装に近づく手段を持っています)。 少なくとも1つの管理局。 そして、エージェントと管理局の間に経営情報を伝えるのに使用されて、管理は議定書を作ります。 プロトコルの操作が認証、承認、アクセスコントロール、およびプライバシーに関する方針を定義する管理フレームワークの下で行われます。
SNMPv2 Working Group Standards Track [Page 2] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[2ページ]RFC1904順応声明
Management stations execute management applications which monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information.
管理局は管理された要素をモニターして、制御する管理アプリケーションを作成します。 管理された要素はホスト、ルータ、それらの経営情報へのアクセスでモニターされて、制御されるターミナルサーバなどのデバイスです。
Management information is viewed as a collection of managed objects, residing in a virtual information store, termed the Management Information Base (MIB). Collections of related objects are defined in MIB modules. These modules are written using a subset of OSI's Abstract Syntax Notation One (ASN.1) [1], termed the Structure of Management Information (SMI) [2].
仮想情報店に住んでいて、管理オブジェクトの収集がInformation基地(MIB)とManagementを呼んだので、経営情報は見られます。 関連するオブジェクトの収集はMIBモジュールで定義されます。 Management情報(SMI)[2]のStructureは、これらのモジュールがOSIの抽象的なSyntax Notation One(ASN.1)[1]の部分集合を使用することで書かれていると呼びました。
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of this document to define the notation used for these purposes.
実装の許容できる下界を定義するのは達成された実装の実際のレベルと共に役に立つかもしれません。 これらの目的に使用される記法を定義するのは、このドキュメントの目的です。
1.1. A Note on Terminology
1.1. 用語に関する注
For the purpose of exposition, the original Internet-standard Network Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD 15), and 1212 (STD 16), is termed the SNMP version 1 framework (SNMPv1). The current framework is termed the SNMP version 2 framework (SNMPv2).
博覧会の目的のために、RFCs1155(STD16)、1157年(STD15)、および1212年(STD16)に説明されるオリジナルのインターネット標準Network Management FrameworkはSNMPバージョン1フレームワーク(SNMPv1)と呼ばれます。 現在のフレームワークはSNMPバージョン2フレームワーク(SNMPv2)と呼ばれます。
2. Definitions
2. 定義
SNMPv2-CONF DEFINITIONS ::= BEGIN
SNMPv2-CONF定義:、:= 始まってください。
-- definitions for conformance groups
-- 順応グループのための定義
OBJECT-GROUP MACRO ::=
BEGIN
TYPE NOTATION ::=
ObjectsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
オブジェクトグループマクロ:、:= タイプ記法を始めてください:、:= ObjectsPart「状態」状態「記述」テキストReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= 値(値のオブジェクト識別子)
ObjectsPart ::=
"OBJECTS" "{" Objects "}"
Objects ::=
Object
| Objects "," Object
Object ::=
ObjectsPart:、:= 「オブジェクト」が「「反対」」というオブジェクト:、:= オブジェクト| 」 「オブジェクト」、オブジェクトオブジェクト:、:=
SNMPv2 Working Group Standards Track [Page 3] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[3ページ]RFC1904順応声明
value(Name ObjectName)
値(名前ObjectName)
Status ::=
"current"
| "deprecated"
| "obsolete"
状態:、:= 「電流」| 「推奨しないです」。| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
-- uses the NVT ASCII character set
Text ::= """" string """"
END
-- 用途、NVT ASCII文字の組Text:、:= 「「「「ストリング、「「「「終わってください」
-- more definitions for conformance groups
-- 順応グループにおける、より多くの定義
NOTIFICATION-GROUP MACRO ::=
BEGIN
TYPE NOTATION ::=
NotificationsPart
"STATUS" Status
"DESCRIPTION" Text
ReferPart
通知グループマクロ:、:= タイプ記法を始めてください:、:= NotificationsPart「状態」状態「記述」テキストReferPart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= 値(値のオブジェクト識別子)
NotificationsPart ::=
"NOTIFICATIONS" "{" Notifications "}"
Notifications ::=
Notification
| Notifications "," Notification
Notification ::=
value(Name NotificationName)
NotificationsPart:、:= 「通知」、「「通知」、」 通知:、:= 通知| 」 「通知」、通知通知:、:= 値(名前NotificationName)
Status ::=
"current"
| "deprecated"
| "obsolete"
状態:、:= 「電流」| 「推奨しないです」。| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
-- uses the NVT ASCII character set
Text ::= """" string """"
-- 用途、NVT ASCII文字の組Text:、:= 「「「「ストリング、「「「」」
SNMPv2 Working Group Standards Track [Page 4] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[4ページ]RFC1904順応声明
END
終わり
-- definitions for compliance statements
-- 承諾声明のための定義
MODULE-COMPLIANCE MACRO ::=
BEGIN
TYPE NOTATION ::=
"STATUS" Status
"DESCRIPTION" Text
ReferPart
ModulePart
モジュールコンプライアンスマクロ:、:= タイプ記法を始めてください:、:= 「状態」状態「記述」テキストReferPart ModulePart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= 値(値のオブジェクト識別子)
Status ::=
"current"
| "deprecated"
| "obsolete"
状態:、:= 「電流」| 「推奨しないです」。| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
ModulePart ::=
Modules
| empty
Modules ::=
Module
| Modules Module
Module ::=
-- name of module --
"MODULE" ModuleName
MandatoryPart
CompliancePart
ModulePart:、:= モジュール| Modulesを空にしてください:、:= モジュール| モジュールモジュールモジュール:、:= -- モジュールの名前--「モジュール」ModuleName MandatoryPart CompliancePart
ModuleName ::=
modulereference ModuleIdentifier
-- must not be empty unless contained
-- in MIB Module
| empty
ModuleIdentifier ::=
value(ModuleID OBJECT IDENTIFIER)
| empty
ModuleName:、:= modulereference ModuleIdentifier--含まれていない場合、MIB Moduleで空であるはずがありません。| ModuleIdentifierを空にしてください:、:= 値(ModuleIDオブジェクト識別子)| 空になってください。
MandatoryPart ::=
"MANDATORY-GROUPS" "{" Groups "}"
MandatoryPart:、:= 「義務的なグループ」は「「分類」にされます」。
SNMPv2 Working Group Standards Track [Page 5] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[5ページ]RFC1904順応声明
| empty
| 空になってください。
Groups ::=
Group
| Groups "," Group
Group ::=
value(Group OBJECT IDENTIFIER)
グループ:、:= グループ| 」 「グループ」、グループは以下から構成されています:= 値(群対象識別子)
CompliancePart ::=
Compliances
| empty
CompliancePart:、:= 承諾| 空になってください。
Compliances ::=
Compliance
| Compliances Compliance
Compliance ::=
ComplianceGroup
| Object
コンプライアンス:、:= 承諾| コンプライアンス承諾コンプライアンス:、:= ComplianceGroup| オブジェクト
ComplianceGroup ::=
"GROUP" value(Name OBJECT IDENTIFIER)
"DESCRIPTION" Text
ComplianceGroup:、:= 「グループ」価値(名前オブジェクト識別子)の「記述」というテキスト
Object ::=
"OBJECT" value(Name ObjectName)
SyntaxPart
WriteSyntaxPart
AccessPart
"DESCRIPTION" Text
オブジェクト:、:= 「オブジェクト」価値(名前ObjectName)のSyntaxPart WriteSyntaxPart AccessPart「記述」というテキスト
-- must be a refinement for object's SYNTAX clause
SyntaxPart ::=
"SYNTAX" type(SYNTAX)
| empty
-- オブジェクトのSYNTAX節SyntaxPartのための気品でなければなりません:、:= 「構文」タイプ(構文)| 空になってください。
-- must be a refinement for object's SYNTAX clause
WriteSyntaxPart ::=
"WRITE-SYNTAX" type(WriteSYNTAX)
| empty
-- オブジェクトのSYNTAX節WriteSyntaxPartのための気品でなければなりません:、:= 「構文を書く、」 タイプ(WriteSYNTAX)| 空になってください。
AccessPart ::=
"MIN-ACCESS" Access
| empty
Access ::=
"not-accessible"
| "accessible-for-notify"
| "read-only"
| "read-write"
AccessPart:、:= 「分アクセス」アクセス| Accessを空にしてください:、:= 「アクセスしやすくはありません」。| 「アクセスしやすい、通知、」| 「書き込み禁止」| 「-読まれて、書いてください」
SNMPv2 Working Group Standards Track [Page 6] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[6ページ]RFC1904順応声明
| "read-create"
|、「読書する作成」
-- uses the NVT ASCII character set
Text ::= """" string """"
END
-- 用途、NVT ASCII文字の組Text:、:= 「「「「ストリング、「「「「終わってください」
-- definitions for capabilities statements
-- 能力声明のための定義
AGENT-CAPABILITIES MACRO ::=
BEGIN
TYPE NOTATION ::=
"PRODUCT-RELEASE" Text
"STATUS" Status
"DESCRIPTION" Text
ReferPart
ModulePart
エージェント能力マクロ:、:= タイプ記法を始めてください:、:= 「製品発売」テキスト「状態」状態「記述」テキストReferPart ModulePart
VALUE NOTATION ::=
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= 値(値のオブジェクト識別子)
Status ::=
"current"
| "obsolete"
状態:、:= 「電流」| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
ModulePart ::=
Modules
| empty
Modules ::=
Module
| Modules Module
Module ::=
-- name of module --
"SUPPORTS" ModuleName
"INCLUDES" "{" Groups "}"
VariationPart
ModulePart:、:= モジュール| Modulesを空にしてください:、:= モジュール| モジュールモジュールモジュール:、:= -- モジュールの名前--ModuleNameが「含んでいる」「サポート」はVariationPartを「「分類」」。
ModuleName ::=
identifier ModuleIdentifier
ModuleIdentifier ::=
value(ModuleID OBJECT IDENTIFIER)
| empty
ModuleName:、:= 識別子ModuleIdentifier ModuleIdentifier:、:= 値(ModuleIDオブジェクト識別子)| 空になってください。
Groups ::=
グループ:、:=
SNMPv2 Working Group Standards Track [Page 7] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[7ページ]RFC1904順応声明
Group
| Groups "," Group
Group ::=
value(Name OBJECT IDENTIFIER)
グループ| 」 「グループ」、グループは以下から構成されています:= 値(名前オブジェクト識別子)
VariationPart ::=
Variations
| empty
Variations ::=
Variation
| Variations Variation
VariationPart:、:= 変化| Variationsを空にしてください:、:= 変化| 変化変化
Variation ::=
ObjectVariation
| NotificationVariation
変化:、:= ObjectVariation| NotificationVariation
NotificationVariation ::=
"VARIATION" value(Name NotificationName)
AccessPart
"DESCRIPTION" Text
NotificationVariation:、:= 「変化」価値(名前NotificationName)のAccessPart「記述」というテキスト
ObjectVariation ::=
"VARIATION" value(Name ObjectName)
SyntaxPart
WriteSyntaxPart
AccessPart
CreationPart
DefValPart
"DESCRIPTION" Text
ObjectVariation:、:= 「変化」価値(名前ObjectName)のSyntaxPart WriteSyntaxPart AccessPart CreationPart DefValPart「記述」というテキスト
-- must be a refinement for object's SYNTAX clause
SyntaxPart ::=
"SYNTAX" type(SYNTAX)
| empty
-- オブジェクトのSYNTAX節SyntaxPartのための気品でなければなりません:、:= 「構文」タイプ(構文)| 空になってください。
-- must be a refinement for object's SYNTAX clause
WriteSyntaxPart ::=
"WRITE-SYNTAX" type(WriteSYNTAX)
| empty
-- オブジェクトのSYNTAX節WriteSyntaxPartのための気品でなければなりません:、:= 「構文を書く、」 タイプ(WriteSYNTAX)| 空になってください。
AccessPart ::=
"ACCESS" Access
| empty
AccessPart:、:= 「アクセス」アクセス| 空になってください。
Access ::=
"not-implemented"
-- only "not-implemented" for notifications
| "accessible-for-notify"
以下にアクセスしてください:= 通知のために「実装されないだけでなくなく」て、「実装されません」。| 「アクセスしやすい、通知、」
SNMPv2 Working Group Standards Track [Page 8] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[8ページ]RFC1904順応声明
| "read-only"
| "read-write"
| "read-create"
-- following is for backward-compatibility only
| "write-only"
| 「書き込み禁止」| 「-読まれて、書いてください」| 「読書する作成」、--次の事柄が後方の互換性だけのためのものである| 「書く、-単に、」
CreationPart ::=
"CREATION-REQUIRES" "{" Cells "}"
| empty
CreationPart:、:= 「作成必要である」、「「セル」、」| 空になってください。
Cells ::=
Cell
| Cells "," Cell
セル:、:= セル| 」 「セル」、セル
Cell ::=
value(Cell ObjectName)
セル:、:= 値(セルObjectName)
DefValPart ::=
"DEFVAL" "{" value(Defval ObjectSyntax) "}"
| empty
DefValPart:、:= "DEFVAL"「「値(Defval ObjectSyntax)」」| 空になってください。
-- uses the NVT ASCII character set
Text ::= """" string """"
END
-- 用途、NVT ASCII文字の組Text:、:= 「「「「ストリング、「「「「終わってください」
END
終わり
3. Mapping of the OBJECT-GROUP macro
3. OBJECT-GROUPマクロに関するマッピング
For conformance purposes, it is useful to define a collection of related managed objects. The OBJECT-GROUP macro is used to define each such collection of related objects. It should be noted that the expansion of the OBJECT-GROUP macro is something which conceptually happens during implementation and not during run-time.
順応目的に、関連する管理オブジェクトの収集を定義するのは役に立ちます。 OBJECT-GROUPマクロは、関連するオブジェクトのそのような各収集を定義するのに使用されます。 OBJECT-GROUPマクロの拡張がランタイムの間、起こるのではなく、実装の間に概念的に起こる何かであることに注意されるべきです。
To "implement" an object, a SNMPv2 entity acting in an agent role must return a reasonably accurate value for management protocol retrieval operations; similarly, if the object is writable, then in response to a management protocol set operation, a SNMPv2 entity must accordingly be able to reasonably influence the underlying managed entity. If a SNMPv2 entity acting in an agent role can not implement an object, the management protocol provides for the SNMPv2 entity to return an exception or error, e.g, noSuchObject [4]. Under no circumstances shall a SNMPv2 entity return a value for objects which it does not implement -- it must always return the appropriate exception or error, as described in the protocol specification [4].
オブジェクトを「実装する」ために、エージェントの役割で行動するSNMPv2実体は管理プロトコル検索操作のために合理的に正確な値を返さなければなりません。 同様に、オブジェクトが書き込み可能であるなら、管理プロトコル集合演算に対応して、SNMPv2実体はそれに従って、合理的に基本的な管理された実体に影響を及ぼすことができなければなりません。 エージェントの役割で行動するSNMPv2実体がオブジェクトを実装することができないなら、管理プロトコルは例外か誤りを返すためにSNMPv2実体に備えます、e.g、noSuchObject[4]。 SNMPv2実体はそれが実装しないオブジェクトのために値を決して、返さないものとします--いつも適切な例外か誤りを返さなければなりません、プロトコル仕様[4]で説明されるように。
SNMPv2 Working Group Standards Track [Page 9] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[9ページ]RFC1904順応声明
3.1. Mapping of the OBJECTS clause
3.1. OBJECTS節に関するマッピング
The OBJECTS clause, which must be present, is used to name each object contained in the conformance group. Each of the named 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節(存在していなければならない)は、順応グループに含まれた各オブジェクトを命名するのに使用されます。 または、それぞれの名前付のオブジェクトがOBJECT-GROUPマクロと同じ情報モジュールが現れて、マックス-ACCESS節価値を持たなければならない定義されたコネでなければならない、「アクセスしやすい、通知、」 「読書唯一であっ」て、「読書して書く」、「読書して作成します」。
It is required that every object defined in an information module with a MAX-ACCESS clause other than "not-accessible" be contained in at least one object group. This avoids the common error of adding a new object to an information module and forgetting to add the new object to a group.
「アクセスしやすくないこと」を除いたマックス-ACCESS節で情報モジュールで定義されたあらゆるオブジェクトが少なくとも1つのオブジェクトグループに含まれているのが必要です。 これは新しいオブジェクトを情報モジュールに追加して、新しいオブジェクトをグループに追加するのを忘れる一般的な誤りを避けます。
3.2. Mapping of the STATUS clause
3.2. STATUS節に関するマッピング
The STATUS clause, which must be present, indicates whether this definition is current or historic.
STATUS節(存在していなければならない)は、この定義が現在である、または歴史的であるかを示します。
The values "current", and "obsolete" are self-explanatory. The "deprecated" value indicates that the definition is obsolete, but that an implementor may wish to support the group to foster interoperability with older implementations.
値「電流」、および「時代遅れ」は自明です。 「推奨しない」値は、定義が時代遅れですが、作成者が、より古い実装で相互運用性を伸ばすためにグループをサポートしたがっているかもしれないのを示します。
3.3. Mapping of the DESCRIPTION clause
3.3. 記述節に関するマッピング
The DESCRIPTION clause, which must be present, contains a textual definition of that group, along with a description of any relations to other groups. Note that generic compliance requirements should not be stated in this clause. However, implementation relationships between this group and other groups may be defined in this clause.
記述節(存在していなければならない)はそのグループの原文の定義を含んでいます、他のグループとのどんな関係の記述と共にも。 ジェネリック承諾要件がこの節に述べられているべきでないことに注意してください。 しかしながら、このグループと他のグループとの実装関係はこの節で定義されるかもしれません。
3.4. Mapping of the REFERENCE clause
3.4. REFERENCE節に関するマッピング
The REFERENCE clause, which need not be present, contains a textual cross-reference to a group defined in some other information module. This is useful when de-osifying a MIB module produced by some other organization.
REFERENCE節(存在している必要はない)はある他の情報モジュールで定義されたグループに原文の相互参照を含んでいます。 反-ある他の組織によって作成されたMIBモジュールをosifyingするとき、これは役に立ちます。
3.5. Mapping of the OBJECT-GROUP value
3.5. OBJECT-GROUP価値に関するマッピング
The value of an invocation of the OBJECT-GROUP macro is the name of the group, which is an OBJECT IDENTIFIER, an administratively assigned name.
OBJECT-GROUPマクロの実施の値はグループの名前です。(OBJECT IDENTIFIER、それは、行政上割り当てられた名前です)。
SNMPv2 Working Group Standards Track [Page 10] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[10ページ]RFC1904順応声明
3.6. Usage Example
3.6. 使用例
The SNMP Group [3] is described:
SNMP Group[3]は説明されます:
snmpGroup OBJECT-GROUP
OBJECTS { snmpInPkts,
snmpInBadVersions,
snmpInASNParseErrs,
snmpBadOperations,
snmpSilentDrops,
snmpProxyDrops,
snmpEnableAuthenTraps }
STATUS current
DESCRIPTION
"A collection of objects providing basic instrumentation and
control of an SNMPv2 entity."
::= { snmpMIBGroups 8 }
snmpGroup OBJECT-GROUP OBJECTS、snmpInPkts、snmpInBadVersions、snmpInASNParseErrs、snmpBadOperations、snmpSilentDrops、snmpProxyDrops、snmpEnableAuthenTraps、STATUSの現在の記述、「基本的な計装を提供するオブジェクトの収集とSNMPv2実体のコントロール。」 ::= snmpMIBGroups8
According to this invocation, the conformance group named
この実施、指定された順応グループによると
{ snmpMIBGroups 8 }
snmpMIBGroups8
contains 7 objects.
7個のオブジェクトを含んでいます。
4. Mapping of the NOTIFICATION-GROUP macro
4. NOTIFICATION-GROUPマクロに関するマッピング
For conformance purposes, it is useful to define a collection of notifications. The NOTIFICATION-GROUP macro serves this purpose. It should be noted that the expansion of the NOTIFICATION-GROUP macro is something which conceptually happens during implementation and not during run-time.
順応目的に、通知の収集を定義するのは役に立ちます。 NOTIFICATION-GROUPマクロはこの目的に役立ちます。 NOTIFICATION-GROUPマクロの拡張がランタイムの間、起こるのではなく、実装の間に概念的に起こる何かであることに注意されるべきです。
4.1. Mapping of the NOTIFICATIONS clause
4.1. NOTIFICATIONS節に関するマッピング
The NOTIFICATIONS clause, which must be present, is used to name each notification contained in the conformance group. Each of the named notifications must be defined in the same information module as the NOTIFICATION-GROUP macro appears.
NOTIFICATIONS節(存在していなければならない)は、順応グループに含まれた各通知を命名するのに使用されます。 NOTIFICATION-GROUPマクロとしてのモジュールが現れるという同じ情報でそれぞれの命名された通知を定義しなければなりません。
4.2. Mapping of the STATUS clause
4.2. STATUS節に関するマッピング
The STATUS clause, which must be present, indicates whether this definition is current or historic.
STATUS節(存在していなければならない)は、この定義が現在である、または歴史的であるかを示します。
The values "current", and "obsolete" are self-explanatory. The "deprecated" value indicates that the definition is obsolete, but that an implementor may wish to support the group to foster
値「電流」、および「時代遅れ」は自明です。 「推奨しない」値は、定義が時代遅れですが、作成者が伸ばすグループをサポートしたがっているかもしれないのを示します。
SNMPv2 Working Group Standards Track [Page 11] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[11ページ]RFC1904順応声明
interoperability with older implementations.
より古い実装がある相互運用性。
4.3. Mapping of the DESCRIPTION clause
4.3. 記述節に関するマッピング
The DESCRIPTION clause, which must be present, contains a textual definition of the group, along with a description of any relations to other groups. Note that generic compliance requirements should not be stated in this clause. However, implementation relationships between this group and other groups may be defined in this clause.
記述節(存在していなければならない)はグループの原文の定義を含んでいます、他のグループとのどんな関係の記述と共にも。 ジェネリック承諾要件がこの節に述べられているべきでないことに注意してください。 しかしながら、このグループと他のグループとの実装関係はこの節で定義されるかもしれません。
4.4. Mapping of the REFERENCE clause
4.4. REFERENCE節に関するマッピング
The REFERENCE clause, which need not be present, contains a textual cross-reference to a group defined in some other information module. This is useful when de-osifying a MIB module produced by some other organization.
REFERENCE節(存在している必要はない)はある他の情報モジュールで定義されたグループに原文の相互参照を含んでいます。 反-ある他の組織によって作成されたMIBモジュールをosifyingするとき、これは役に立ちます。
4.5. Mapping of the NOTIFICATION-GROUP value
4.5. NOTIFICATION-GROUP価値に関するマッピング
The value of an invocation of the NOTIFICATION-GROUP macro is the name of the group, which is an OBJECT IDENTIFIER, an administratively assigned name.
NOTIFICATION-GROUPマクロの実施の値はグループの名前です。(OBJECT IDENTIFIER、それは、行政上割り当てられた名前です)。
4.6. Usage Example
4.6. 使用例
The SNMP Basic Notifications Group [3] is described:
SNMP Basic Notifications Group[3]は説明されます:
snmpBasicNotificationsGroup NOTIFICATION-GROUP
NOTIFICATIONS { coldStart, authenticationFailure }
STATUS current
DESCRIPTION
"The two notifications which an SNMPv2 entity is required to
implement."
::= { snmpMIBGroups 7 }
snmpBasicNotificationsGroup NOTIFICATION-GROUP NOTIFICATIONS、coldStart、authenticationFailure、STATUSの現在の記述、「SNMPv2実体が実装するのに必要である2つの通知。」 ::= snmpMIBGroups7
According to this invocation, the conformance group named
この実施、指定された順応グループによると
{ snmpMIBGroups 1 }
snmpMIBGroups1
contains 2 notifications.
2つの通知を含んでいます。
5. Mapping of the MODULE-COMPLIANCE macro
5. MODULE-COMPLIANCEマクロに関するマッピング
The MODULE-COMPLIANCE macro is used to convey a minimum set of requirements with respect to implementation of one or more MIB modules. It should be noted that the expansion of the MODULE- COMPLIANCE macro is something which conceptually happens during implementation and not during run-time.
MODULE-COMPLIANCEマクロは、1つ以上のMIBモジュールの実装に関して最小のセットの要件を伝えるのに使用されます。 MODULE- COMPLIANCEマクロの拡張がランタイムの間、起こるのではなく、実装の間に概念的に起こる何かであることに注意されるべきです。
SNMPv2 Working Group Standards Track [Page 12] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[12ページ]RFC1904順応声明
A requirement on all "standard" MIB modules is that a corresponding MODULE-COMPLIANCE specification is also defined, either in the same information module or in a companion information module.
すべての「標準」のMIBモジュールに関する要件はまた、対応するMODULE-COMPLIANCE仕様が同じ情報モジュールか仲間情報モジュールで定義されるということです。
5.1. Mapping of the STATUS clause
5.1. STATUS節に関するマッピング
The STATUS clause, which must be present, indicates whether this definition is current or historic.
STATUS節(存在していなければならない)は、この定義が現在である、または歴史的であるかを示します。
The values "current", and "obsolete" are self-explanatory. The "deprecated" value indicates that the specification is obsolete, but that an implementor may wish to support that object to foster interoperability with older implementations.
値「電流」、および「時代遅れ」は自明です。 「推奨しない」値は、仕様が時代遅れですが、作成者が、より古い実装で相互運用性を伸ばすためにそのオブジェクトを支えたがっているかもしれないのを示します。
5.2. Mapping of the DESCRIPTION clause
5.2. 記述節に関するマッピング
The DESCRIPTION clause, which must be present, contains a textual definition of this compliance statement and should embody any information which would otherwise be communicated in any ASN.1 commentary annotations associated with the statement.
記述節(存在していなければならない)は、この承諾声明の原文の定義を含んでいて、そうでなければ声明に関連しているどんなASN.1論評注釈でも伝えられるどんな情報も具体化するべきです。
5.3. Mapping of the REFERENCE clause
5.3. REFERENCE節に関するマッピング
The REFERENCE clause, which need not be present, contains a textual cross-reference to a compliance statement defined in some other information module.
REFERENCE節(存在している必要はない)はある他の情報モジュールで定義された承諾声明に原文の相互参照を含んでいます。
5.4. Mapping of the MODULE clause
5.4. MODULE節に関するマッピング
The MODULE clause, which must be present, is repeatedly used to name each MIB module for which compliance requirements are being specified. Each MIB module is named by its module name, and optionally, by its associated OBJECT IDENTIFIER as well. The module name can be omitted when the MODULE-COMPLIANCE invocation occurs inside a MIB module, to refer to the encompassing MIB module.
MODULE節(存在していなければならない)は、承諾要件が指定されているそれぞれのMIBモジュールを命名するのに繰り返して使用されます。 それぞれのMIBモジュールはモジュール名によってまた、関連OBJECT IDENTIFIERによって任意に命名されます。 MODULE-COMPLIANCE実施が取り囲んでいるMIBモジュールを示すためにMIBモジュールで起こるとき、モジュール名を省略できます。
5.4.1. Mapping of the MANDATORY-GROUPS clause
5.4.1. MANDATORY-GROUPS節に関するマッピング
The MANDATORY-GROUPS clause, which need not be present, names the one or more object or notification groups within the correspondent MIB module which are unconditionally mandatory for implementation. If a SNMPv2 entity acting in an agent role claims compliance to the MIB module, then it must implement each and every object and notification within each conformance group listed. That is, if a SNMPv2 entity returns a noSuchObject exception in response to a management protocol get operation [4] for any object within any mandatory conformance group for every MIB view, or if the SNMPv2 entity cannot generate each notification listed in any conformance group under the
MANDATORY-GROUPS節(存在している必要はない)は通信員MIBモジュールの中の無条件に実装に義務的な1個以上のオブジェクトか通知グループを命名します。 エージェントの役割で行動するSNMPv2実体がMIBモジュールにコンプライアンスを要求するなら、ありとあらゆるオブジェクトを実装しなければなりません、そして、それぞれの順応グループの中の通知はリストアップされました。 すなわち、SNMPv2実体が管理プロトコルに対応してnoSuchObject例外を返すなら、あらゆるMIB視点かそれともSNMPv2実体がそれぞれを生成することができるというわけではないように通知がどんな順応グループでも記載したどんな義務的な順応グループ以内でもどんなオブジェクトのための操作[4]も得てください。
SNMPv2 Working Group Standards Track [Page 13] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[13ページ]RFC1904順応声明
appropriate circumstances, then that SNMPv2 entity is not a conformant implementation of the MIB module.
事情を当ててください、そして、そして、そのSNMPv2実体はMIBモジュールのconformant実装ではありません。
5.4.2. Mapping of the GROUP clause
5.4.2. GROUP節に関するマッピング
The GROUP clause, which need not be present, is repeatedly used to name each object and notification group which is conditionally mandatory or unconditionally optional for compliance to the MIB module. A group named in a GROUP clause must be absent from the correspondent MANDATORY-GROUPS clause.
GROUP節(存在している必要はない)は、それぞれの条件付きに義務的なオブジェクトと通知グループを命名するのに繰り返して使用されているか、または承諾には、MIBモジュールに無条件に任意です。 GROUP節で指定されたグループは通信員MANDATORY-GROUPS節から欠けているに違いありません。
Conditionally mandatory groups include those which are mandatory only if a particular protocol is implemented, or only if another group is implemented. A GROUP clause's DESCRIPTION specifies the conditions under which the group is conditionally mandatory.
条件付きに義務的なグループは特定のプロトコルが単に実装されるか、または別のグループが実装される場合にだけ義務的なものを含んでいます。 GROUP節の記述はグループが条件付きに義務的である状態を指定します。
A group which is named in neither a MANDATORY-GROUPS clause nor a GROUP clause, is unconditionally optional for compliance to the MIB module.
承諾には、どちらもMANDATORY-GROUPS節かGROUP節で命名されるグループはMIBモジュールに無条件に任意です。
5.4.3. Mapping of the OBJECT clause
5.4.3. OBJECT節に関するマッピング
The OBJECT clause, which need not be present, is repeatedly used to name each MIB object for which compliance has a refined requirement with respect to the MIB module definition. The MIB object must be present in one of the conformance groups named in the correspondent MANDATORY-GROUPS clause or GROUP clauses.
OBJECT節(存在している必要はない)は、MIBモジュール定義に関して承諾には洗練された要件があるそれぞれのMIBオブジェクトを命名するのに繰り返して使用されます。 MIBオブジェクトは通信員MANDATORY-GROUPS節かGROUP節で指定された順応グループの1つで存在していなければなりません。
By definition, each object specified in an OBJECT clause follows a MODULE clause which names the information module in which that object is defined. Therefore, the use of an IMPORTS statement, to specify from where such objects are imported, is redundant and is not required in an information module.
定義上、OBJECT節で指定された各オブジェクトはそのオブジェクトが定義される情報モジュールを命名するMODULE節に従います。 したがって、IMPORTS声明の使用、そのようなものが反対するところから指定するのは、インポートされて、余分であり、情報モジュールで必要ではありません。
5.4.3.1. Mapping of the SYNTAX clause
5.4.3.1. SYNTAX節に関するマッピング
The SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent OBJECT clause. Note that if this clause and a WRITE-SYNTAX clause are both present, then this clause only applies when instances of the object named in the correspondent OBJECT clause are read.
SYNTAX節(存在している必要はない)は、通信員OBJECT節で指定されたオブジェクトに洗練されたSYNTAXを供給するのに使用されます。 通信員OBJECT節で指定されたオブジェクトのインスタンスが読まれるときだけ、この節とWRITE-SYNTAX節がともに存在しているならこの節が適用されることに注意してください。
Consult Section 9 of [2] for more information on refined syntax.
洗練された構文に関する詳しい情報のための[2]のセクション9に相談してください。
SNMPv2 Working Group Standards Track [Page 14] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[14ページ]RFC1904順応声明
5.4.3.2. Mapping of the WRITE-SYNTAX clause
5.4.3.2. WRITE-SYNTAX節に関するマッピング
The WRITE-SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent OBJECT clause when instances of that object are written.
WRITE-SYNTAX節(存在している必要はない)は、そのオブジェクトのインスタンスが書かれると通信員OBJECT節で指定されたオブジェクトに洗練されたSYNTAXを供給するのに使用されます。
Consult Section 9 of [2] for more information on refined syntax.
洗練された構文に関する詳しい情報のための[2]のセクション9に相談してください。
5.4.3.3. Mapping of the MIN-ACCESS clause
5.4.3.3. MIN-ACCESS節に関するマッピング
The MIN-ACCESS clause, which need not be present, is used to define the minimal level of access for the object named in the correspondent OBJECT clause. If this clause is absent, the minimal level of access is the same as the maximal level specified in the correspondent invocation of the OBJECT-TYPE macro. If present, this clause must not specify a greater level of access than is specified in the correspondent invocation of the OBJECT-TYPE macro.
MIN-ACCESS節(存在している必要はない)は、通信員OBJECT節で指定されたオブジェクトのために最小量のアクセスのレベルを定義するのに使用されます。 この節が欠けるなら、最小量のアクセスのレベルは最大限度のレベルがOBJECT-TYPEマクロの通信員実施で指定したのと同じです。 存在しているなら、この節はOBJECT-TYPEマクロの通信員実施で指定されるより大きいアクセスのレベルを指定してはいけません。
The level of access for certain types of objects is fixed according to their syntax definition. These types include: conceptual tables and rows, auxiliary objects, and objects with the syntax of Counter32, Counter64 (and possibly, certain types of textual conventions). A MIN-ACCESS clause should not be present for such objects.
彼らの構文定義に従って、あるタイプのオブジェクトのためのアクセスのレベルは修理されています。 これらのタイプは: Counter32、Counter64(そして、ことによるとあるタイプの原文のコンベンション)の構文がある概念的なテーブル、行、補助のオブジェクト、およびオブジェクト。 MIN-ACCESS節はそのようなオブジェクトのために存在しているべきではありません。
An implementation is compliant if the level of access it provides is greater or equal to the minimal level in the MODULE-COMPLIANCE macro and less or equal to the maximal level in the OBJECT-TYPE macro.
それが提供するアクセスのレベルがMODULE-COMPLIANCEマクロにおける最小量のレベルと、そして、以下OBJECT-TYPEマクロにおける最大限度のレベルと、より優れているか、または等しいなら、実装は対応します。
5.4.4. Mapping of the DESCRIPTION clause
5.4.4. 記述節に関するマッピング
The DESCRIPTION clause must be present for each use of the GROUP or OBJECT clause. For an OBJECT clause, it contains a textual description of the refined compliance requirement. For a GROUP clause, it contains a textual description of the conditions under which the group is conditionally mandatory or unconditionally optional.
記述節はGROUPかOBJECT節の各使用のために存在していなければなりません。 OBJECT節に関しては、それは洗練された承諾要件の原文の記述を含んでいます。 GROUP節に関しては、それはグループが条件付きに義務的であるか、または無条件に任意である状態の原文の記述を含んでいます。
5.5. Mapping of the MODULE-COMPLIANCE value
5.5. MODULE-COMPLIANCE価値に関するマッピング
The value of an invocation of the MODULE-COMPLIANCE macro is an OBJECT IDENTIFIER. As such, this value may be authoritatively used when referring to the compliance statement embodied by that invocation of the macro.
MODULE-COMPLIANCEマクロの実施の値はOBJECT IDENTIFIERです。 そういうものとして、マクロのその実施によって具体化された承諾声明を参照すると、この値は厳然と使用されるかもしれません。
SNMPv2 Working Group Standards Track [Page 15] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[15ページ]RFC1904順応声明
5.6. Usage Example
5.6. 使用例
The compliance statement contained in the (hypothetical) XYZv2-MIB might be:
(仮定する)のXYZv2-MIBに含まれた承諾声明は以下の通りです。
xyzMIBCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for XYZv2 entities which implement
the XYZv2 MIB."
MODULE -- compliance to the containing MIB module
MANDATORY-GROUPS { xyzSystemGroup,
xyzStatsGroup, xyzTrapGroup,
xyzSetGroup,
xyzBasicNotificationsGroup }
xyzMIBCompliance MODULE-COMPLIANCE STATUSの現在の記述、「XYZv2 MIBを実装するXYZv2実体のための承諾声明。」 MODULE--含んでいるMIBモジュールMANDATORY-GROUPSへの承諾xyzSystemGroup、xyzStatsGroup、xyzTrapGroup、xyzSetGroup、xyzBasicNotificationsGroup
GROUP xyzV1Group
DESCRIPTION
"The xyzV1 group is mandatory only for those
XYZv2 entities which also implement XYZv1."
::= { xyzMIBCompliances 1 }
GROUP xyzV1Group記述、「xyzV1グループはまた、XYZv1を実装するそれらのXYZv2実体だけに義務的です」。 ::= xyzMIBCompliances1
According to this invocation, to claim alignment with the compliance statement named
承諾声明が命名されているクレーム整列へのこの実施に従って
{ xyzMIBCompliances 1 }
xyzMIBCompliances1
a system must implement the XYZv2-MIB's xyzSystemGroup, xyzStatsGroup, xyzTrapGroup, and xyzSetGroup object conformance groups, as well as the xyzBasicNotificationsGroup notifications group. Furthermore, if the XYZv2 entity also implements XYZv1, then it must also support the XYZv1Group group, if compliance is to be claimed.
システムはXYZv2-MIBのxyzSystemGroup、xyzStatsGroup、xyzTrapGroup、およびxyzSetGroupにオブジェクト順応グループを実装しなければなりません、xyzBasicNotificationsGroup通知グループと同様に。 その上、また、また、XYZv2実体がXYZv1を実装するなら、XYZv1Groupグループをサポートしなければなりません、承諾が要求されることであるなら。
6. Mapping of the AGENT-CAPABILITIES macro
6. エージェント-CAPABILITIESマクロに関するマッピング
The AGENT-CAPABILITIES macro is used to convey a set of capabilities present in a SNMPv2 entity acting in an agent role. It should be noted that the expansion of the AGENT-CAPABILITIES macro is something which conceptually happens during implementation and not during run- time.
エージェント-CAPABILITIESマクロは、エージェントの役割で行動するSNMPv2実体における現在の能力のセットを運ぶのに使用されます。 エージェント-CAPABILITIESマクロの拡張が走行時間起こるのではなく、実装の間に概念的に起こる何かであることに注意されるべきです。
When a MIB module is written, it is divided into units of conformance termed groups. If a SNMPv2 entity acting in an agent role claims to implement a group, then it must implement each and every object within that group. Of course, for whatever reason, a SNMPv2 entity might implement only a subset of the groups within a MIB module. In addition, the definition of some MIB objects leave some aspects of
MIBモジュールが書かれると、それはグループと呼ばれたユニットの順応に分割されます。 エージェントの役割で行動するSNMPv2実体が、グループを実装すると主張するなら、それはそのグループの中のありとあらゆるオブジェクトを実装しなければなりません。 もちろん、いかなる理由でも、SNMPv2実体はMIBモジュールの中でグループの部分集合だけを実装するかもしれません。 追加、オブジェクトがいくつかの局面を出るいくらかのMIBの定義で
SNMPv2 Working Group Standards Track [Page 16] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[16ページ]RFC1904順応声明
the definition to the discretion of an implementor.
作成者の思慮深さとの定義。
Practical experience has demonstrated a need for concisely describing the capabilities of an agent with respect to one or more MIB modules. The AGENT-CAPABILITIES macro allows an agent implementor to describe the precise level of support which an agent claims in regards to a MIB group, and to bind that description to the value of an instance of sysORID [3]. In particular, some objects may have restricted or augmented syntax or access-levels.
実用的な経験は1つ以上のMIBモジュールに関してエージェントの能力について簡潔に説明する必要性を示しました。 エージェント-CAPABILITIESマクロで、エージェントの作成者は、エージェントがMIBグループに関して要求する正確なサポート水準について説明して、sysORID[3]のインスタンスの値にその記述を縛ります。 いくつかのオブジェクトが、構文かアクセスレベルを特に、制限したか、または増大させたかもしれません。
If the AGENT-CAPABILITIES invocation is given to a management-station implementor, then that implementor can build management applications which optimize themselves when communicating with a particular agent. For example, the management-station can maintain a database of these invocations. When a management-station interacts with an agent, it retrieves from the agent the values of all instances of sysORID [3]. Based on this, it consults the database to locate each entry matching one of the retrieved values of sysORID. Using the located entries, the management application can now optimize its behavior accordingly.
エージェント-CAPABILITIES実施を管理局作成者に与えるなら、その作成者は特定代理人とコミュニケートするとき自分たちを最適化する管理アプリケーションを組立てることができます。 例えば、管理局はこれらの実施に関するデータベースを維持できます。 管理局がエージェントと対話すると、それはエージェントからsysORID[3]のすべてのインスタンスの値を検索します。 これに基づいて、それは、sysORIDの検索された値の1つを合わせながら各エントリーの場所を見つけるようにデータベースに相談します。 見つけられたエントリーを使用して、管理アプリケーションは現在、それに従って、振舞いを最適化できます。
Note that the AGENT-CAPABILITIES macro specifies refinements or variations with respect to OBJECT-TYPE and NOTIFICATION-TYPE macros in MIB modules, NOT with respect to MODULE-COMPLIANCE macros in compliance statements.
エージェント-CAPABILITIESマクロが承諾声明のMODULE-COMPLIANCEマクロで指定するのではなく、OBJECT-TYPEとNOTIFICATION-TYPEマクロに関してMIBモジュールで気品か変化を指定することに注意してください。
6.1. Mapping of the PRODUCT-RELEASE clause
6.1. PRODUCT-RELEASE節に関するマッピング
The PRODUCT-RELEASE clause, which must be present, contains a textual description of the product release which includes this set of capabilities.
PRODUCT-RELEASE節(存在していなければならない)はこのセットの能力を含んでいる製品発売の原文の記述を含んでいます。
6.2. Mapping of the STATUS clause
6.2. STATUS節に関するマッピング
The STATUS clause, which must be present, indicates whether this
definition is current ("current") or historic ("obsolete").
STATUS節(存在していなければならない)は、この定義が現在である(「現在」の)、または歴史的であるかを(「時代遅れ」の)示します。
6.3. Mapping of the DESCRIPTION clause
6.3. 記述節に関するマッピング
The DESCRIPTION clause, which must be present, contains a textual description of this set of capabilities.
記述節(存在していなければならない)はこのセットの能力の原文の記述を含んでいます。
6.4. Mapping of the REFERENCE clause
6.4. REFERENCE節に関するマッピング
The REFERENCE clause, which need not be present, contains a textual cross-reference to a capability statement defined in some other information module.
REFERENCE節(存在している必要はない)はある他の情報モジュールで定義された能力声明に原文の相互参照を含んでいます。
SNMPv2 Working Group Standards Track [Page 17] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[17ページ]RFC1904順応声明
6.5. Mapping of the SUPPORTS clause
6.5. SUPPORTS節に関するマッピング
The SUPPORTS clause, which need not be present, is repeatedly used to name each MIB module for which the agent claims a complete or partial implementation. Each MIB module is named by its module name, and optionally, by its associated OBJECT IDENTIFIER as well.
SUPPORTS節(存在している必要はない)は、エージェントが完全であるか部分的な実装を要求するそれぞれのMIBモジュールを命名するのに繰り返して使用されます。 それぞれのMIBモジュールはモジュール名によってまた、関連OBJECT IDENTIFIERによって任意に命名されます。
6.5.1. Mapping of the INCLUDES clause
6.5.1. INCLUDES節に関するマッピング
The INCLUDES clause, which must be present for each use of the SUPPORTS clause, is used to name each MIB group associated with the SUPPORTS clause, which the agent claims to implement.
INCLUDES節(SUPPORTS節の各使用のために存在していなければならない)は、エージェントが実装すると主張するSUPPORTS節に関連しているそれぞれのMIBグループを命名するのに使用されます。
6.5.2. Mapping of the VARIATION clause
6.5.2. VARIATION節に関するマッピング
The VARIATION clause, which need not be present, is repeatedly used to name each object or notification which the agent implements in some variant or refined fashion with respect to the correspondent invocation of the OBJECT-TYPE or NOTIFICATION-TYPE macro.
VARIATION節(存在している必要はない)はOBJECT-TYPEかNOTIFICATION-TYPEマクロの通信員実施に関する繰り返してエージェントが、ある異形で実装する各オブジェクトか通知を命名するのに使用されたか、または精製されたファッションです。
Note that the variation concept is meant for generic implementation restrictions, e.g., if the variation for an object depends on the values of other objects, then this should be noted in the appropriate DESCRIPTION clause.
変化概念がジェネリック施行規則のために意味されて、例えば、オブジェクトのための変化が他のオブジェクトの値によるならこれが適切な記述節に述べられるべきであることに注意してください。
By definition, each object specified in a VARIATION clause follows a SUPPORTS clause which names the information module in which that object is defined. Therefore, the use of an IMPORTS statement, to specify from where such objects are imported, is redundant and is not required in an information module.
定義上、VARIATION節で指定された各オブジェクトはそのオブジェクトが定義される情報モジュールを命名するSUPPORTS節に従います。 したがって、IMPORTS声明の使用、そのようなものが反対するところから指定するのは、インポートされて、余分であり、情報モジュールで必要ではありません。
6.5.2.1. Mapping of the SYNTAX clause
6.5.2.1. SYNTAX節に関するマッピング
The SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent VARIATION clause. Note that if this clause and a WRITE-SYNTAX clause are both present, then this clause only applies when instances of the object named in the correspondent VARIATION clause are read.
SYNTAX節(存在している必要はない)は、通信員VARIATION節で指定されたオブジェクトに洗練されたSYNTAXを供給するのに使用されます。 通信員VARIATION節で指定されたオブジェクトのインスタンスが読まれるときだけ、この節とWRITE-SYNTAX節がともに存在しているならこの節が適用されることに注意してください。
Consult Section 9 of [2] for more information on refined syntax.
洗練された構文に関する詳しい情報のための[2]のセクション9に相談してください。
6.5.2.2. Mapping of the WRITE-SYNTAX clause
6.5.2.2. WRITE-SYNTAX節に関するマッピング
The WRITE-SYNTAX clause, which need not be present, is used to provide a refined SYNTAX for the object named in the correspondent VARIATION clause when instances of that object are written.
WRITE-SYNTAX節(存在している必要はない)は、そのオブジェクトのインスタンスが書かれると通信員VARIATION節で指定されたオブジェクトに洗練されたSYNTAXを供給するのに使用されます。
Consult Section 9 of [2] for more information on refined syntax.
洗練された構文に関する詳しい情報のための[2]のセクション9に相談してください。
SNMPv2 Working Group Standards Track [Page 18] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[18ページ]RFC1904順応声明
6.5.2.3. Mapping of the ACCESS clause
6.5.2.3. ACCESS節に関するマッピング
The ACCESS clause, which need not be present, is used to indicate the agent provides less than the maximal level of access to the object or notification named in the correspondent VARIATION clause.
ACCESS節(存在している必要はない)は、エージェントが最大限度のアクセスのレベルほど通信員VARIATION節で指定されたオブジェクトか通知に供給しないのを示すのに使用されます。
The only value applicable to notifications is "not-implemented".
通知に適切な唯一の値は「実装されません」。
The value "not-implemented" indicates the agent does not implement the object or notification, and in the ordering of possible values is equivalent to "not-accessible".
「実装されなかった」値は、エージェントがオブジェクトか通知を実装しないのを示します、そして、可能な値の注文には、「アクセスしやすくないこと」と同等物があります。
The value "write-only" is provided solely for backward compatibility, and shall not be used for newly-defined object types. In the ordering of possible values, "write-only" is less than "not- accessible".
値、「書く、-単に、」 唯一後方の互換性に提供されて、新たに定義されたオブジェクト・タイプに使用しないでしょう。 可能な値の注文で「書く、-単に、」、 より少ない、「-、アクセスしやすさ、」
6.5.2.4. Mapping of the CREATION-REQUIRES clause
6.5.2.4. CREATION-REQUIRES節に関するマッピング
The CREATION-REQUIRES clause, which need not be present, is used to name the columnar objects of a conceptual row to which values must be explicitly assigned, by a management protocol set operation, before the agent will allow the instance of the status column of that row to be set to `active'. (Consult the definition of RowStatus [5].)
CREATION-REQUIRES節(存在している必要はない)は明らかに値を割り当てなければならない概念的な行の円柱状のオブジェクトを命名するのに使用されます、管理プロトコル集合演算で、エージェントが、その行に関する状態コラムのインスタンスが'アクティブに'設定されるのを許す前に。 (RowStatus[5]の定義に相談してください。)
If the conceptual row does not have a status column (i.e., the objects corresponding to the conceptual table were defined using the mechanisms in [6,7]), then the CREATION-REQUIRES clause, which need not be present, is used to name the columnar objects of a conceptual row to which values must be explicitly assigned, by a management protocol set operation, before the agent will create new instances of objects in that row.
概念的な行に状態コラムがないなら(すなわち、概念的なテーブルに対応するオブジェクトは[6、7]にメカニズムを使用することで定義されました)、CREATION-REQUIRES節(存在している必要はない)は明らかに値を割り当てなければならない概念的な行の円柱状のオブジェクトを命名するのに使用されます、管理プロトコル集合演算で、エージェントがその行でオブジェクトの新しいインスタンスを作成する前に。
This clause must not present unless the object named in the correspondent VARIATION clause is a conceptual row, i.e., has a syntax which resolves to a SEQUENCE containing columnar objects. The objects named in the value of this clause usually will refer to columnar objects in that row. However, objects unrelated to the conceptual row may also be specified.
節が提示してはいけないこれはすなわち、通信員VARIATION節で指定されたオブジェクトが概念的な行でないなら含有円柱状のオブジェクトをSEQUENCEに分解する構文を持っています。 その行で通常、この節の値で指定されたオブジェクトは円柱状のオブジェクトについて言及するでしょう。 しかしながら、また、概念的な行に関係ないオブジェクトは指定されるかもしれません。
All objects which are named in the CREATION-REQUIRES clause for a conceptual row, and which are columnar objects of that row, must have an access level of "read-create".
概念的な行のためのCREATION-REQUIRES節で命名されて、その行の円柱状のオブジェクトであるすべての目的でアクセスは平らにならなければなりません。「読書して作成します」。
SNMPv2 Working Group Standards Track [Page 19] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[19ページ]RFC1904順応声明
6.5.2.5. Mapping of the DEFVAL clause
6.5.2.5. DEFVAL節に関するマッピング
The DEFVAL clause, which need not be present, is used to provide a refined DEFVAL value for the object named in the correspondent VARIATION clause. The semantics of this value are identical to those of the OBJECT-TYPE macro's DEFVAL clause.
DEFVAL節(存在している必要はない)は、通信員VARIATION節で指定されたオブジェクトに洗練されたDEFVAL値を供給するのに使用されます。 この価値の意味論はOBJECT-TYPEマクロのDEFVAL節のものと同じです。
6.5.2.6. Mapping of the DESCRIPTION clause
6.5.2.6. 記述節に関するマッピング
The DESCRIPTION clause, which must be present for each use of the VARIATION clause, contains a textual description of the variant or refined implementation of the object or notification.
記述節(VARIATION節の各使用のために存在していなければならない)はオブジェクトか通知の異形か洗練された実装の原文の記述を含んでいます。
6.6. Mapping of the AGENT-CAPABILITIES value
6.6. エージェント-CAPABILITIES価値に関するマッピング
The value of an invocation of the AGENT-CAPABILITIES macro is an OBJECT IDENTIFIER, which names the value of sysORID [3] for which this capabilities statement is valid.
エージェント-CAPABILITIESマクロの実施の値はOBJECT IDENTIFIERです。(そのOBJECT IDENTIFIERはこの能力声明が有効である[3]とsysORIDの値を命名します)。
6.7. Usage Example
6.7. 使用例
Consider how a capabilities statement for an agent might be described:
エージェントのための能力声明がどのように説明されるかもしれないか考えてください:
exampleAgent AGENT-CAPABILITIES
PRODUCT-RELEASE "ACME Agent release 1.1 for 4BSD"
STATUS current
DESCRIPTION "ACME agent for 4BSD"
「4BSDのためのACMEエージェントリリース1.1」exampleAgentのエージェント-CAPABILITIES PRODUCT-RELEASEのSTATUSの現在の記述、「4BSDのACMEエージェント」
SUPPORTS SNMPv2-MIB
INCLUDES { systemGroup, snmpGroup, snmpSetGroup,
snmpBasicNotificationsGroup }
SNMPv2-MIBが含むサポートsystemGroup、snmpGroup、snmpSetGroup、snmpBasicNotificationsGroup
VARIATION coldStart
DESCRIPTION "A coldStart trap is generated on all
reboots."
「coldStart罠はすべてのリブートのときに生成される」VARIATION coldStart記述。
SUPPORTS IF-MIB
INCLUDES { ifGeneralGroup, ifPacketGroup }
サポート、-、MIB、包含ifGeneralGroup、ifPacketGroup
VARIATION ifAdminStatus
SYNTAX INTEGER { up(1), down(2) }
DESCRIPTION "Unable to set test mode on 4BSD"
(2)への(1)へのVARIATION ifAdminStatus SYNTAX INTEGER、「4BSDにテスト・モードを設定できない」記述
VARIATION ifOperStatus
SYNTAX INTEGER { up(1), down(2) }
DESCRIPTION "Information limited on 4BSD"
(2)への(1)へのVARIATION ifOperStatus SYNTAX INTEGER、「情報は4BSDで制限した」記述
SNMPv2 Working Group Standards Track [Page 20] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[20ページ]RFC1904順応声明
SUPPORTS IP-MIB
INCLUDES { ipGroup, icmpGroup }
IP-MIBが含むサポートipGroup、icmpGroup
VARIATION ipDefaultTTL
SYNTAX INTEGER (255..255)
DESCRIPTION "Hard-wired on 4BSD"
「4BSDでは配線された」変化ipDefaultTTL構文整数(255 .255)記述
VARIATION ipInAddrErrors
ACCESS not-implemented
DESCRIPTION "Information not available on 4BSD"
VARIATION ipInAddrErrors ACCESSは、記述が「4BSDで利用可能でない情報」であると実装しませんでした。
VARIATION ipNetToMediaEntry
CREATION-REQUIRES { ipNetToMediaPhysAddress }
DESCRIPTION "Address mappings on 4BSD require
both protocol and media addresses"
VARIATION ipNetToMediaEntry CREATION-REQUIRES ipNetToMediaPhysAddress、記述、「4BSDに関するアドレス・マッピングはプロトコルとメディアアドレスの両方を必要とします」。
SUPPORTS TCP-MIB
INCLUDES { tcpGroup }
VARIATION tcpConnState
ACCESS read-only
DESCRIPTION "Unable to set this on 4BSD"
SUPPORTS TCP-MIB INCLUDES tcpGroup、「4BSDにこれを設定できない」VARIATION tcpConnState ACCESS書き込み禁止記述
SUPPORTS UDP-MIB
INCLUDES { udpGroup }
UDP-MIBが含むサポートudpGroup
SUPPORTS EVAL-MIB
INCLUDES { functionsGroup, expressionsGroup }
VARIATION exprEntry
CREATION-REQUIRES { evalString }
DESCRIPTION "Conceptual row creation supported"
SUPPORTS EVAL-MIB INCLUDES、functionsGroup、expressionsGroup、VARIATION exprEntry CREATION-REQUIRES evalString、「概念的な行作成はサポートした」記述
::= { acmeAgents 1 }
::= acmeAgents1
According to this invocation, an agent with a sysORID value of
この実施、sysORID値をもっているエージェント
{ acmeAgents 1 }
acmeAgents1
supports six MIB modules.
6つのMIBモジュールをサポートします。
From SNMPv2-MIB, five conformance groups are supported.
SNMPv2-MIBから、5つの順応グループがサポートされます。
From IF-MIB, the ifGeneralGroup and ifPacketGroup groups are supported. However, the objects ifAdminStatus and ifOperStatus have a restricted syntax.
-、MIB、ifGeneralGroupとifPacketGroupグループはサポートされます。 しかしながら、オブジェクトのifAdminStatusとifOperStatusには、制限された構文があります。
SNMPv2 Working Group Standards Track [Page 21] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[21ページ]RFC1904順応声明
From IP-MIB, all objects in the ipGroup and icmpGroup are supported except ipInAddrErrors, while ipDefaultTTL has a restricted range, and when creating a new instance in the ipNetToMediaTable, the set- request must create an instance of atPhysAddress.
IP-MIBから、ipInAddrErrorsを除いて、ipGroupとicmpGroupのすべてのオブジェクトが支えられます、ipDefaultTTLには、制限された範囲があります、そして、ipNetToMediaTableで新しいインスタンスを作成するとき、セット要求はatPhysAddressのインスタンスを作成しなければなりませんが。
From TCP-MIB, the tcpGroup is supported except that tcpConnState is available only for reading.
TCP-MIBから、tcpConnStateが読書するだけに利用可能であるのを除いて、tcpGroupはサポートされます。
From UDP-MIB, the udpGroup is fully supported.
UDP-MIBから、udpGroupは完全にサポートされます。
From the EVAL-MIB, all the objects contained in the functionsGroup and expressionsGroup conformance groups are supported, without variation. In addition, creation of new instances in the expr table is supported.
EVAL-MIBから、functionsGroupとexpressionsGroup順応グループに含まれたすべてのオブジェクトが変化なしで支えられます。 さらに、exprテーブルの新しいインスタンスの作成はサポートされます。
7. Extending an Information Module
7. 情報モジュールを広げています。
As experience is gained with a published information module, it may be desirable to revise that information module.
広められた情報モジュールで経験するのに従って、その情報モジュールを改訂するのは望ましいかもしれません。
Section 10 of [2] defines the rules for extending an information module. The remainder of this section defines how conformance groups, compliance statements, and capabilities statements may be extended.
[2]のセクション10は、情報モジュールを広げるために規則を決めます。 このセクションの残りは順応グループ、承諾声明、および能力声明がどう広げられるかもしれないかを定義します。
7.1. Conformance Groups
7.1. 順応グループ
If any non-editorial change is made to any clause of an object group then the OBJECT IDENTIFIER value associated with that object group must also be changed, along with its associated descriptor.
また、そのオブジェクトグループに関連しているOBJECT IDENTIFIER値を変えなければなりません、何か非社説変更をオブジェクトグループのどんな節にもするなら関連記述子と共に。
7.2. Compliance Definitions
7.2. 承諾定義
If any non-editorial change is made to any clause of a compliance definition, then the OBJECT IDENTIFIER value associated with that compliance definition must also be changed, along with its associated descriptor.
また、何か非社説変更を承諾定義のどんな節にもするなら、その承諾定義に関連しているOBJECT IDENTIFIER値を変えなければなりません、関連記述子と共に。
7.3. Capabilities Definitions
7.3. 能力定義
If any non-editorial change is made to any clause of a capabilities definition, then the OBJECT IDENTIFIER value associated with that capabilities definition must also be changed, along with its associated descriptor.
また、何か非社説変更を能力定義のどんな節にもするなら、その能力定義に関連しているOBJECT IDENTIFIER値を変えなければなりません、関連記述子と共に。
SNMPv2 Working Group Standards Track [Page 22] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[22ページ]RFC1904順応声明
8. Security Considerations
8. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
9. Editor's Address
9. エディタのアドレス
Keith McCloghrie Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 US
西タスマン・DriveキースMcCloghrieシスコシステムズInc.170カリフォルニア95134-1706サンノゼ(米国)
Phone: +1 408 526 5260 EMail: kzm@cisco.com
以下に電話をしてください。 +1 5260年の408 526メール: kzm@cisco.com
10. Acknowledgements
10. 承認
This document is the result of significant work by the four major contributors:
このドキュメントは4人の一流の貢献者による重要な仕事の結果です:
Jeffrey D. Case (SNMP Research, case@snmp.com) Keith McCloghrie (Cisco Systems, kzm@cisco.com) Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us) Steven Waldbusser (International Network Services, stevew@uni.ins.com)
ジェフリーD.事件(SNMP研究、 case@snmp.com )キースMcCloghrie(シスコシステムズ、 kzm@cisco.com )マーシャル・T.ローズ(ドーヴァーのビーチコンサルティング、 mrose@dbc.mtview.ca.us )スティーブンWaldbusser(国際ネットワークサービス、 stevew@uni.ins.com )
In addition, the contributions of the SNMPv2 Working Group are acknowledged. In particular, a special thanks is extended for the contributions of:
さらに、SNMPv2作業部会の貢献は承諾されます。 特に、以下の貢献のために特別な感謝を表します。
Alexander I. Alten (Novell)
Dave Arneson (Cabletron)
Uri Blumenthal (IBM)
Doug Book (Chipcom)
Kim Curran (Bell-Northern Research)
Jim Galvin (Trusted Information Systems)
Maria Greene (Ascom Timeplex)
Iain Hanson (Digital)
Dave Harrington (Cabletron)
Nguyen Hien (IBM)
Jeff Johnson (Cisco Systems)
Michael Kornegay (Object Quest)
Deirdre Kostick (AT&T Bell Labs)
David Levi (SNMP Research)
Daniel Mahoney (Cabletron)
Bob Natale (ACE*COMM)
Brian O'Keefe (Hewlett Packard)
Andrew Pearson (SNMP Research)
Dave Perkins (Peer Networks)
アレクサンダーI; アルテン(ノベル)デーヴArneson(Cabletron)ユリ・ブルーメンソル(IBM)ダグBook(Chipcom)キム・カラン(ベル-北研究)・ジム・ガルビン(情報システムを信じる)・マリア・グリーン(Ascom Timeplex)イアンハンソン(デジタル)のデーヴ・ハリントン(Cabletron)Nguyen Hien(IBM)ジェフ・ジョンソン(シスコシステムズ)マイケルKornegay(オブジェクト探索)ディアドラKostick(AT&Tベル研究所)デヴィッド・レビ(SNMP研究)・ダニエル・マホニー(Cabletron)ボブNatale(ACE*COMM)ブライアン・オキーフ(ヒューレットパッカード)アンドリューピアソン(SNMP研究)のデーヴ・パーキンス(同輩ネットワーク)
SNMPv2 Working Group Standards Track [Page 23] RFC 1904 Conformance Statements for SNMPv2 January 1996
SNMPv2 January 1996のためのSNMPv2ワーキンググループ標準化過程[23ページ]RFC1904順応声明
Randy Presuhn (Peer Networks)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Jon Saperia (BGS Systems)
Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
Kaj Tesink (Bellcore)
Glenn Waters (Bell-Northern Research)
Bert Wijnen (IBM)
ランディ・Presuhn(同輩Networks)アレックセイ・ロマーノフ(品質Quorum)ショーンRouthier(エピローグ)ジョンSaperia(BGS Systems)ボブ・スチュワート(シスコシステムズ、 bstewart@cisco.com )、いすカイTesink(Bellcore)グレンWaters(ベル-北Research)バートWijnen(IBM)
11. References
11. 参照
[1] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[1] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)
[2] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Structure of Management Information for Version 2
of the Simple Network Management Protocol (SNMPv2)", RFC 1902,
January 1996.
[2]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための経営情報の構造」、RFC1902(1996年1月)。
[3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Management Information Base for Version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1907,
January 1996.
[3]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコルのバージョン2のための管理情報ベース(SNMPv2)」、RFC1907(1996年1月)。
[4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[4] SNMPv2作業部会、ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Textual Conventions for Version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1903, January 1996.
[5]SNMPv2作業部会、ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための原文のコンベンションは(SNMPv2)について議定書の中で述べます」、RFC1903、1996年1月。
[6] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based internets", STD 16, RFC
1155, May 1990.
[6]ローズ、M.、およびK.のMcCloghrieと、「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155(1990年5月)
[7] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[7] ローズ、M.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
SNMPv2 Working Group Standards Track [Page 24]
SNMPv2ワーキンググループ標準化過程[24ページ]
一覧
スポンサーリンク
