RFC1444 日本語訳
1444 Conformance Statements for version 2 of the Simple NetworkManagement Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S.Waldbusser. April 1993. (Format: TXT=57744 bytes) (Obsoleted by RFC1904) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Case
Request for Comments: 1444 SNMP Research, Inc.
K. McCloghrie
Hughes LAN Systems
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
Carnegie Mellon University
April 1993
コメントを求めるワーキンググループJ.ケース要求をネットワークでつないでください: 1444台のSNMP研究Inc.K.McCloghrieヒューズLANシステムM.がドーヴァービーチコンサルティングInc.S.Waldbusserカーネギーメロン大学1993年4月に上昇しました。
Conformance Statements
for version 2 of the
Simple Network Management Protocol (SNMPv2)
Simple Network Managementプロトコルのバージョン2のための順応Statements(SNMPv2)
Status of this Memo
このMemoの状態
This RFC specifes an IAB standards track protocol for the
Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"IAB Official Protocol Standards" for the standardization
state and status of this protocol. Distribution of this memo
is unlimited.
改良のためのIAB規格道がインターネットコミュニティのために議定書の中で述べるこのRFC specifes、要求議論、および提案。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1 Introduction .......................................... 2
1.1 A Note on Terminology ............................... 2
2 Definitions ........................................... 3
3.1 The OBJECT-GROUP macro .............................. 3
3.2 The MODULE-COMPLIANCE macro ......................... 4
3.3 The AGENT-CAPABILITIES macro ........................ 7
3 Mapping of the OBJECT-GROUP macro ..................... 10
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 ..................... 11
3.5 Mapping of the OBJECT-GROUP value ................... 11
3.6 Usage Example ....................................... 12
4 Mapping of the MODULE-COMPLIANCE macro ................ 13
4.1 Mapping of the STATUS clause ........................ 13
4.2 Mapping of the DESCRIPTION clause ................... 13
4.3 Mapping of the REFERENCE clause ..................... 13
4.4 Mapping of the MODULE clause ........................ 13
4.4.1 Mapping of the MANDATORY-GROUPS clause ............ 14
4.4.2 Mapping of the GROUP clause ....................... 14
4.4.3 Mapping of the OBJECT clause ...................... 14
1つの序論… 2 1.1 用語に関する注… 2 2の定義… 3 3.1 OBJECT-GROUPマクロ… 3 3.2 MODULE-COMPLIANCEマクロ… 4 3.3 エージェント-CAPABILITIESマクロ… OBJECT-GROUPマクロに関する7 3マッピング… 10 OBJECTS節に関する3.1マッピング… 10 STATUS節に関する3.2マッピング… 10 記述節に関する3.3マッピング… 10 REFERENCE節に関する3.4マッピング… 11 OBJECT-GROUP価値に関する3.5マッピング… 11 3.6使用例… 12 MODULE-COMPLIANCEマクロに関する4マッピング… 13 STATUS節に関する4.1マッピング… 13 記述節に関する4.2マッピング… 13 REFERENCE節に関する4.3マッピング… 13 MODULE節に関する4.4マッピング… 13 4.4 MANDATORY-GROUPS節に関する.1マッピング… 14 4.4 GROUP節に関する.2マッピング… 14 4.4 OBJECT節に関する.3マッピング… 14
Case, McCloghrie, Rose & Waldbusser [Page i]
ケース、McCloghrie、ローズ、およびWaldbusser[ページi]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
4.4.3.1 Mapping of the SYNTAX clause .................... 15
4.4.3.2 Mapping of the WRITE-SYNTAX clause .............. 15
4.4.3.3 Mapping of the MIN-ACCESS clause ................ 15
4.4.3.4 Mapping of the DESCRIPTION clause ............... 16
4.5 Mapping of the MODULE-COMPLIANCE value .............. 16
4.6 Usage Example ....................................... 17
5 Mapping of the AGENT-CAPABILITIES macro ............... 19
5.1 Mapping of the PRODUCT-RELEASE clause ............... 20
5.2 Mapping of the STATUS clause ........................ 20
5.3 Mapping of the DESCRIPTION clause ................... 20
5.4 Mapping of the REFERENCE clause ..................... 20
5.5 Mapping of the SUPPORTS clause ...................... 20
5.5.1 Mapping of the INCLUDES clause .................... 21
5.5.2 Mapping of the VARIATION clause ................... 21
5.5.2.1 Mapping of the SYNTAX clause .................... 21
5.5.2.2 Mapping of the WRITE-SYNTAX clause .............. 21
5.5.2.3 Mapping of the ACCESS clause .................... 22
5.5.2.4 Mapping of the CREATION-REQUIRES clause ......... 22
5.5.2.5 Mapping of the DEFVAL clause .................... 23
5.5.2.6 Mapping of the DESCRIPTION clause ............... 23
5.6 Mapping of the AGENT-CAPABILITIES value ............. 23
5.7 Usage Example ....................................... 24
6 Extending an Information Module ....................... 26
6.1 Conformance Groups .................................. 26
6.2 Compliance Definitions .............................. 26
6.3 Capabilities Definitions ............................ 26
7 Acknowledgements ...................................... 27
8 References ............................................ 31
9 Security Considerations ............................... 32
10 Authors' Addresses ................................... 32
4.4.3.1 SYNTAX節に関するマッピング… 15 4.4 .3 WRITE-SYNTAX節に関する.2マッピング… 15 4.4 .3 MIN-ACCESS節に関する.3マッピング… 15 4.4 .3 記述節に関する.4マッピング… 16 MODULE-COMPLIANCE価値に関する4.5マッピング… 16 4.6使用例… 17 エージェント-CAPABILITIESマクロに関する5マッピング… 19 PRODUCT-RELEASE節に関する5.1マッピング… 20 STATUS節に関する5.2マッピング… 20 記述節に関する5.3マッピング… 20 REFERENCE節に関する5.4マッピング… 20 SUPPORTS節に関する5.5マッピング… 20 5.5 INCLUDES節に関する.1マッピング… 21 5.5 VARIATION節に関する.2マッピング… 21 5.5 .2 SYNTAX節に関する.1マッピング… 21 5.5 .2 WRITE-SYNTAX節に関する.2マッピング… 21 5.5 .2 ACCESS節に関する.3マッピング… 22 5.5 .2 CREATION-REQUIRES節に関する.4マッピング… 22 5.5 .2 DEFVAL節に関する.5マッピング… 23 5.5 .2 記述節に関する.6マッピング… 23 エージェント-CAPABILITIES価値に関する5.6マッピング… 23 5.7使用例… 24 6 情報モジュールを広げています… 26 6.1 順応は分類されます… 26 6.2 承諾定義… 26 6.3の能力定義… 26 7つの承認… 27 8つの参照箇所… 31 9 セキュリティ問題… 32 10人の作者のアドレス… 32
Case, McCloghrie, Rose & Waldbusser [Page 1]
ケース、McCloghrie、ローズ、およびWaldbusser[1ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
1. Introduction
1. 序論
A network 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 both authentication and
authorization policies.
ネットワーク管理システムは以下を含んでいます。 数個の(潜在的に多く)のノード(処理実体があるそれぞれ)がエージェントを呼びました。(そのエージェントは、管理計装に近づく手段を持っています)。 少なくとも1つの管理局。 そして、エージェントと管理局の間に経営情報を伝えるのに使用されて、管理は議定書を作ります。 プロトコルの操作が認証と承認方針の両方を定義する管理フレームワークの下で行われます。
Network management stations execute management applications
which monitor and control network elements. Network elements
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through 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, 1157,
and 1212, is termed the SNMP version 1 framework (SNMPv1).
The current framework is termed the SNMP version 2 framework
(SNMPv2).
博覧会の目的のために、RFCs1155、1157年、および1212年に説明されるオリジナルのインターネット標準Network Management FrameworkはSNMPバージョン1フレームワーク(SNMPv1)と呼ばれます。 現在のフレームワークはSNMPバージョン2フレームワーク(SNMPv2)と呼ばれます。
Case, McCloghrie, Rose & Waldbusser [Page 2]
ケース、McCloghrie、ローズ、およびWaldbusser[2ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
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 ::=
value(Name ObjectName)
ObjectsPart:、:= 「オブジェクト」が「「反対」」というオブジェクト:、:= オブジェクト| 」 「オブジェクト」、オブジェクトオブジェクト:、:= 値(名前ObjectName)
Status ::=
"current"
| "obsolete"
状態:、:= 「電流」| 「時代遅れです」。
ReferPart ::=
"REFERENCE" Text
| empty
ReferPart:、:= 「参照」というテキスト| 空になってください。
-- uses the NVT ASCII character set
Text ::= """" string """"
END
-- 用途、NVT ASCII文字の組Text:、:= 「「「「ストリング、「「「「終わってください」
Case, McCloghrie, Rose & Waldbusser [Page 3]
ケース、McCloghrie、ローズ、およびWaldbusser[3ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
-- 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"
| "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 "}"
| empty
MandatoryPart:、:= 「義務的なグループ」は「「分類」にされます」。| 空になってください。
Case, McCloghrie, Rose & Waldbusser [Page 4]
ケース、McCloghrie、ローズ、およびWaldbusser[4ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
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"
| "read-only"
| "read-write"
AccessPart:、:= 「分アクセス」アクセス| Accessを空にしてください:、:= 「アクセスしやすくはありません」。| 「書き込み禁止」| 「-読まれて、書いてください」
Case, McCloghrie, Rose & Waldbusser [Page 5]
ケース、McCloghrie、ローズ、およびWaldbusser[5ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
| "read-create"
|、「読書する作成」
-- uses the NVT ASCII character set
Text ::= """" string """"
END
-- 用途、NVT ASCII文字の組Text:、:= 「「「「ストリング、「「「「終わってください」
Case, McCloghrie, Rose & Waldbusser [Page 6]
ケース、McCloghrie、ローズ、およびWaldbusser[6ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
-- definitions for capabilities statements
-- 能力声明のための定義
AGENT-CAPABILITIES MACRO ::=
BEGIN
TYPE NOTATION ::=
"PRODUCT-RELEASE" Text
"STATUS" Status
"DESCRIPTION" Text
ReferPart
ModulePart
エージェント能力マクロ:、:= タイプ記法を始めてください:、:= 「製品発売」テキスト「状態」状態「記述」テキストReferPart ModulePart
VALUE NOTATION ::=
-- agent's sysObjectID [3] or snmpORID [4]
value(VALUE OBJECT IDENTIFIER)
記法を評価してください:、:= -- エージェントsysObjectID[3]かsnmpORID[4]の値(値のオブジェクト識別子)
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 ::=
Group
| Groups "," Group
Group ::=
グループ:、:= グループ| 」 「グループ」、グループは以下から構成されています:=
Case, McCloghrie, Rose & Waldbusser [Page 7]
ケース、McCloghrie、ローズ、およびWaldbusser[7ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
value(Name OBJECT IDENTIFIER)
値(名前オブジェクト識別子)
VariationPart ::=
Variations
| empty
Variations ::=
Variation
| Variations Variation
VariationPart:、:= 変化| Variationsを空にしてください:、:= 変化| 変化変化
Variation ::=
"VARIATION" value(Name ObjectName)
SyntaxPart
WriteSyntaxPart
AccessPart
CreationPart
DefValPart
"DESCRIPTION" Text
変化:、:= 「変化」価値(名前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"
| "read-only"
| "read-write"
| "read-create"
-- following is for backward-compatibility only
| "write-only"
以下にアクセスしてください:= 「実装されません」。| 「書き込み禁止」| 「-読まれて、書いてください」| 「読書する作成」、--次の事柄が後方の互換性だけのためのものである| 「書く、-単に、」
CreationPart ::=
"CREATION-REQUIRES" "{" Cells "}"
| empty
CreationPart:、:= 「作成必要である」、「「セル」、」| 空になってください。
Cells ::=
セル:、:=
Case, McCloghrie, Rose & Waldbusser [Page 8]
ケース、McCloghrie、ローズ、およびWaldbusser[8ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
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
終わり
Case, McCloghrie, Rose & Waldbusser [Page 9]
ケース、McCloghrie、ローズ、およびWaldbusser[9ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
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 [6]. 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 [6].
オブジェクトを「実装する」ために、エージェントの役割で行動するSNMPv2実体は管理プロトコル検索操作のために合理的に正確な値を返さなければなりません。 同様に、オブジェクトが書き込み可能であるなら、管理プロトコル集合演算に対応して、SNMPv2実体はそれに従って、合理的に基本的な管理された実体に影響を及ぼすことができなければなりません。 エージェントの役割で行動するSNMPv2実体がオブジェクトを実装することができないなら、管理プロトコルは例外か誤りを返すためにSNMPv2実体に備えます、e.g、noSuchObject[6]。 SNMPv2実体はそれが実装しないオブジェクトのために値を決して、返さないものとします--いつも適切な例外か誤りを返さなければなりません、プロトコル仕様[6]で説明されるように。
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 "read-only", "read-write", or "read-create".
存在しなければならないOBJECTS節は順応グループに含まれた各オブジェクトを命名するのにおいて使用されています。 それぞれの名前付のオブジェクトはOBJECT-GROUPマクロと同じ情報モジュールが、見えて、マックス-ACCESS節が「書き込み禁止」を評価するか、「読書して書く」か、または「読書して作成すること」を持たなければならない定義されたコネでなければなりません。
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.
値「電流」、および「時代遅れ」は自明です。
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
記述節(存在していなければならない)はa記述に伴うそのグループのa原文の定義を含んでいます。
Case, McCloghrie, Rose & Waldbusser [Page 10]
ケース、McCloghrie、ローズ、およびWaldbusser[10ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
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、それは、行政上割り当てられた名前です)。
Case, McCloghrie, Rose & Waldbusser [Page 11]
ケース、McCloghrie、ローズ、およびWaldbusser[11ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
3.6. Usage Example
3.6. 使用例
Consider how the system group from MIB-II [3] might be
described:
MIB-II[3]からのシステムグループがどのように説明されるかもしれないか考えてください:
systemGroup OBJECT-GROUP
OBJECTS { sysDescr, sysObjectID, sysUpTime,
sysContact, sysName, sysLocation,
sysServices }
STATUS current
DESCRIPTION
"The system group defines objects which are common
to all managed systems."
::= { mibIIGroups 1 }
systemGroup OBJECT-GROUP OBJECTS、sysDescr、sysObjectID、sysUpTime、sysContact、sysName、sysLocation、sysServices、STATUSの現在の記述、「システムグループはすべての管理されたシステムに共通のオブジェクトを定義する」、:、:= mibIIGroups1
According to this invocation, the conformance group named
この実施、指定された順応グループによると
{ mibIIGroups 1 }
mibIIGroups1
contains 7 objects.
7個のオブジェクトを含んでいます。
Case, McCloghrie, Rose & Waldbusser [Page 12]
ケース、McCloghrie、ローズ、およびWaldbusser[12ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
4. Mapping of the MODULE-COMPLIANCE macro
4. 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マクロの拡張がランタイムの間、起こるのではなく、実装の間に概念的に起こる何かであることに注意されるべきです。
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仕様が同じ情報モジュールか仲間情報モジュールで定義されるということです。
4.1. Mapping of the STATUS clause
4.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 that object is obsolete,
but that an implementor may wish to support that object to
foster interoperability with older implementations.
値「電流」、および「時代遅れ」は自明です。 「推奨しない」値は、そのオブジェクトが時代遅れですが、作成者が、より古い実装で相互運用性を伸ばすためにそのオブジェクトを支えたがっているかもしれないのを示します。
4.2. Mapping of the DESCRIPTION clause
4.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論評注釈でも伝えられるどんな情報も具体化するべきです。
4.3. Mapping of the REFERENCE clause
4.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節(存在している必要はない)はある他の情報モジュールで定義された承諾声明に原文の相互参照を含んでいます。
4.4. Mapping of the MODULE clause
4.4. MODULE節に関するマッピング
The MODULE clause, which must be present, is repeatedly used
to name each MIB module for which compliance requirements are
MODULE節(存在していなければならない)は、それぞれのMIBモジュールを要件がどの承諾であるかにちなんで命名するのに繰り返して使用されます。
Case, McCloghrie, Rose & Waldbusser [Page 13]
ケース、McCloghrie、ローズ、およびWaldbusser[13ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
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.
指定されること。 それぞれのMIBモジュールはモジュール名によってまた、関連OBJECT IDENTIFIERによって任意に命名されます。 MODULE-COMPLIANCE実施が取り囲んでいるMIBモジュールを示すためにMIBモジュールで起こるとき、モジュール名を省略できます。
4.4.1. Mapping of the MANDATORY-GROUPS clause
4.4.1. MANDATORY-GROUPS節に関するマッピング
The MANDATORY-GROUPS clause, which need not be present, names
the one or more 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
within each conformance group listed. That is, if a SNMPv2
entity returns a noSuchObject exception in response to a
management protocol get operation [5] for any object within
any mandatory conformance group for every MIB view, then that
SNMPv2 entity is not a conformant implementation of the MIB
module.
MANDATORY-GROUPS節(存在している必要はない)は通信員MIBモジュールの中の無条件に実装に義務的な1つ以上のグループを命名します。 エージェントの役割で行動するSNMPv2実体がMIBモジュールにコンプライアンスを要求するなら、それぞれを実装しなければなりません、そして、それぞれの順応グループの中のあらゆるオブジェクトが記載しました。 すなわち、SNMPv2実体が管理プロトコルに対応してnoSuchObject例外を返すなら、そしてSNMPv2実体がMIBモジュールのconformant実装でないというあらゆるMIB意見のためにどんな義務的な順応グループの中でもどんなオブジェクトのための操作[5]も得てください。
4.4.2. Mapping of the GROUP clause
4.4.2. GROUP節に関するマッピング
The GROUP clause which need not be present, is repeatedly used
to name each MIB group which is conditionally mandatory or
unconditionally optional for compliance to the MIB module. A
MIB group named in a GROUP clause must be absent from the
correspondent MANDATORY-GROUPS clause.
存在する必要はないGROUP節は、それぞれの条件付きに義務的なMIBグループを命名するのに繰り返して使用されているか、または承諾には、MIBモジュールに無条件に任意です。 GROUP節で指定されたMIBグループは通信員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 MIB 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グループはMIBモジュールに無条件に任意です。
4.4.3. Mapping of the OBJECT clause
4.4.3. OBJECT節に関するマッピング
The OBJECT clause which need not be present, is repeatedly
used to name each MIB object for which compliance has a
存在している必要はなくて、それぞれのMIBオブジェクトをどの承諾にちなんで命名するかに繰り返して使用されるOBJECT節はaを持っています。
Case, McCloghrie, Rose & Waldbusser [Page 14]
ケース、McCloghrie、ローズ、およびWaldbusser[14ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
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.
MIBモジュール定義に関する洗練された要件。 MIBオブジェクトは通信員MANDATORY-GROUPS節かGROUP節で指定された順応グループの1つで存在していなければなりません。
4.4.3.1. Mapping of the SYNTAX clause
4.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 10 of [2] for more information on refined
syntax.
洗練された構文に関する詳しい情報のための[2]のセクション10に相談してください。
4.4.3.2. Mapping of the WRITE-SYNTAX clause
4.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 10 of [2] for more information on refined
syntax.
洗練された構文に関する詳しい情報のための[2]のセクション10に相談してください。
4.4.3.3. Mapping of the MIN-ACCESS clause
4.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 are:
conceptual tables and rows, auxiliary objects, and objects
with the syntax of Counter32, Counter64, or certain types of
彼らの構文定義に従って、あるタイプのオブジェクトのためのアクセスのレベルは修理されています。 これらのタイプは以下の通りです。 Counter64の、または、確かなCounter32の構文がある概念的なテーブル、行、補助のオブジェクト、およびオブジェクトはタイプします。
Case, McCloghrie, Rose & Waldbusser [Page 15]
ケース、McCloghrie、ローズ、およびWaldbusser[15ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
textual conventions (e.g., RowStatus [6]). A MIN-ACCESS
clause should not be present for such objects.
原文のコンベンション、(例えば、RowStatus[6])。 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マクロにおける最大限度のレベルと、より優れているか、または等しいなら、実装は対応します。
4.4.3.4. Mapping of the DESCRIPTION clause
4.4.3.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節に関しては、それはグループが条件付きに義務的であるか、または無条件に任意である状態の原文の記述を含んでいます。
4.5. Mapping of the MODULE-COMPLIANCE value
4.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です。 そういうものとして、マクロのその実施によって具体化された承諾声明を参照すると、この値は厳然と使用されるかもしれません。
Case, McCloghrie, Rose & Waldbusser [Page 16]
ケース、McCloghrie、ローズ、およびWaldbusser[16ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
4.6. Usage Example
4.6. 使用例
Consider how a compliance statement might be included at the
end of the MIB-II document [3], assuming that conformance
groups were defined therein:
承諾声明がMIB-IIドキュメント[3]の端にどのように含まれるかもしれないか考えてください、順応グループがそこに定義されたと仮定して:
mibIICompliances
OBJECT IDENTIFIER ::= { mibIIConformance 1 }
mibIIGroups OBJECT IDENTIFIER ::= { mibIIConformance 2 }
mibIICompliancesオブジェクト識別子:、:= mibIIConformance1mibIIGroupsオブジェクト識別子:、:= mibIIConformance2
mibIICompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMPv2 entities
residing on systems which implement the Internet
suite of protocols."
MODULE -- compliance to the containing MIB module
MANDATORY-GROUPS { systemGroup, snmpGroup }
mibIICompliance MODULE-COMPLIANCE STATUSの現在の記述、「プロトコルのインターネットスイートを実装するシステムの上にあるSNMPv2実体のための承諾声明。」 MODULE--含んでいるMIBモジュールMANDATORY-GROUPSへの承諾systemGroup、snmpGroup
GROUP interfacesGroup
DESCRIPTION
"The interfaces group is mandatory for systems
with network interfaces."
GROUP interfacesGroup記述、「インタフェースグループはネットワーク・インターフェースがあるシステムに義務的です」。
GROUP ipGroup
DESCRIPTION
"The ip group is mandatory for systems which
implement IP."
GROUP ipGroup記述、「ipグループはIPを実装するシステムに義務的です」。
GROUP icmpGroup
DESCRIPTION
"The icmp group is mandatory for systems which
implement ICMP."
GROUP icmpGroup記述、「icmpグループはICMPを実装するシステムに義務的です」。
GROUP tcpGroup
DESCRIPTION
"The tcp group is mandatory for systems which
implement TCP."
OBJECT tcpConnState
MIN-ACCESS read-only
DESCRIPTION
"A compliant system need not allow
write-access to this object."
GROUP tcpGroup記述、「tcpグループはTCPを実装するシステムに義務的です」。 「対応するシステムはこれにアクセスを書いているオブジェクトを許容する必要はない」OBJECT tcpConnState MIN-ACCESS書き込み禁止記述。
GROUP udpGroup
グループudpGroup
Case, McCloghrie, Rose & Waldbusser [Page 17]
ケース、McCloghrie、ローズ、およびWaldbusser[17ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
DESCRIPTION
"The udp group is mandatory for systems which
implement UDP."
記述、「udpグループはUDPを実装するシステムに義務的です」。
GROUP egpGroup
DESCRIPTION
"The egp group is mandatory for systems which
implement EGP."
GROUP egpGroup記述、「egpグループはEGPを実装するシステムに義務的です」。
::= { mibIICompliances 1 }
::= mibIICompliances1
According to this invocation, to claim alignment with the
compliance statement named
承諾声明が命名されているクレーム整列へのこの実施に従って
{ mibIICompliances 1 }
mibIICompliances1
a system must implement RFC1213's systemGroup and snmpGroup
conformance groups. If the system implements any network
interfaces, then RFC1213's interfacesGroup conformance group
must be implemented. Further, if the system implements any of
the IP, ICMP, TCP, UDP, or EGP protocols, then the
correspondent conformance group in RFC1213 must be
implemented, if compliance is to be claimed. Finally,
although RFC1213 specifies that it makes "protocol sense" for
the tcpConnState object to be writable, this specification
allows the system to permit only read-only access and still
claim compliance.
システムは、RFC1213のsystemGroupとsnmpGroupが順応グループであると実装しなければなりません。 システムが、どんなネットワークもインタフェースであると実装するなら、RFC1213のinterfacesGroup順応グループを実装しなければなりません。 さらに、システムがIP、ICMP、TCP、UDP、またはEGPプロトコルのどれかを実装するなら、RFC1213の通信員順応グループを実装しなければなりません、承諾が要求されることであるなら。 最終的に、RFC1213は、tcpConnStateオブジェクトが書き込み可能である「プロトコル感覚」を作ると指定しますが、システムはこの仕様でリード・オンリー・アクセスとそれでもクレームコンプライアンスしか可能にすることができません。
Case, McCloghrie, Rose & Waldbusser [Page 18]
ケース、McCloghrie、ローズ、およびWaldbusser[18ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
5. Mapping of the AGENT-CAPABILITIES macro
5. エージェント-CAPABILITIESマクロに関するマッピング
The AGENT-CAPABILITIES macro is used to convey the
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 the
definition to the discretion of an implementor.
MIBモジュールが書かれると、それはグループと呼ばれたユニットの順応に分割されます。 エージェントの役割で行動するSNMPv2実体が、グループを実装すると主張するなら、それはそのグループの中のありとあらゆるオブジェクトを実装しなければなりません。 もちろん、いかなる理由でも、SNMPv2実体はMIBモジュールの中でグループの部分集合だけを実装するかもしれません。 追加、MIBオブジェクトが作成者の思慮深さとの定義のいくつかの局面を出るいくつかの定義で。
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 sysObjectID [3] associated
with the agent, or to the value of an instance of the snmpORID
object in the snmpORTable [4]. In particular, some objects
may have restricted or augmented syntax or access-levels.
実用的な経験は1つ以上のMIBモジュールに関してエージェントの能力について簡潔に説明する必要性を示しました。 エージェント-CAPABILITIESマクロで、エージェントの作成者は、エージェントがMIBグループに関して要求する正確なサポート水準について説明して、エージェントに関連しているsysObjectID[3]の値、または、snmpORTable[4]のsnmpORIDオブジェクトのインスタンスの値にその記述を縛ります。 いくつかのオブジェクトが、構文かアクセスレベルを特に、制限したか、または増大させたかもしれません。
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 the agent's sysObjectID [3]. Based on
this, it consults the database. If an entry is found, then
the management application can optimize its behavior
accordingly.
エージェント-CAPABILITIES実施を管理局作成者に与えるなら、その作成者は特定代理人とコミュニケートするとき自分たちを最適化する管理アプリケーションを組立てることができます。 例えば、管理局はこれらの実施に関するデータベースを維持できます。 管理局がエージェントと対話すると、それはエージェントのsysObjectID[3]を検索します。 これに基づいて、それはデータベースに相談します。 エントリーが見つけられるなら、管理アプリケーションはそれに従って、振舞いを最適化できます。
Note that this binding to sysObjectID may not always suffice
to define all MIB objects to which an agent can provide
access. In particular, this situation occurs where the agent
dynamically learns of the objects it supports. In these
cases, the snmpORID column of snmpORTable [4] contains
information which should be used in addition to sysObjectID.
sysObjectIDとのこの結合がエージェントがアクセサリーを供給できるすべてのMIBオブジェクトを定義するためにいつも十分であるかもしれないというわけではないことに注意してください。 特に、この状況はエージェントがダイナミックにそれが支えるオブジェクトを知っているところに起こります。 これらの場合では、snmpORTable[4]に関するsnmpORIDコラムはsysObjectIDに加えて使用されるべきである情報を含んでいます。
Case, McCloghrie, Rose & Waldbusser [Page 19]
ケース、McCloghrie、ローズ、およびWaldbusser[19ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
Note that the AGENT-CAPABILITIES macro specifies refinements
or variations with respect to OBJECT-TYPE macros in MIB
modules, NOT with respect to MODULE-COMPLIANCE macros in
compliance statements.
エージェント-CAPABILITIESマクロが承諾声明のMODULE-COMPLIANCEマクロで指定するのではなく、OBJECT-TYPEマクロに関してMIBモジュールで気品か変化を指定することに注意してください。
5.1. Mapping of the PRODUCT-RELEASE clause
5.1. PRODUCT-RELEASE節に関するマッピング
The PRODUCT-RELEASE clause, which must be present, contains a
textual description of the product release which includes this
agent.
PRODUCT-RELEASE節(存在していなければならない)はこのエージェントを含んでいる製品発売の原文の記述を含んでいます。
5.2. Mapping of the STATUS clause
5.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 that object is obsolete,
but that an implementor may wish to support that object to
foster interoperability with older implementations.
値「電流」、および「時代遅れ」は自明です。 「推奨しない」値は、そのオブジェクトが時代遅れですが、作成者が、より古い実装で相互運用性を伸ばすためにそのオブジェクトを支えたがっているかもしれないのを示します。
5.3. Mapping of the DESCRIPTION clause
5.3. 記述節に関するマッピング
The DESCRIPTION clause, which must be present, contains a
textual description of this agent.
記述節(存在していなければならない)はこのエージェントの原文の記述を含んでいます。
5.4. Mapping of the REFERENCE clause
5.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節(存在している必要はない)はある他の情報モジュールで定義された能力声明に原文の相互参照を含んでいます。
5.5. Mapping of the SUPPORTS clause
5.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によって任意に命名されます。
Case, McCloghrie, Rose & Waldbusser [Page 20]
ケース、McCloghrie、ローズ、およびWaldbusser[20ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
5.5.1. Mapping of the INCLUDES clause
5.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 SUPPORT clause, which the agent claims to implement.
INCLUDES節(SUPPORTS節の各使用のために存在していなければならない)は、エージェントが実装すると主張するSUPPORT節に関連しているそれぞれのMIBグループを命名するのに使用されます。
5.5.2. Mapping of the VARIATION clause
5.5.2. VARIATION節に関するマッピング
The VARIATION clause, which need not be present, is repeatedly
used to name each MIB object which the agent implements in
some variant or refined fashion with respect to the
correspondent invocation of the OBJECT-TYPE macro.
VARIATION節(存在している必要はない)はOBJECT-TYPEマクロの通信員実施に関する繰り返してエージェントが、ある異形で実装するそれぞれのMIBオブジェクトを命名するのに使用されたか、または精製されたファッションです。
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.
変化概念がジェネリック施行規則のために意味されて、例えば、オブジェクトのための変化が他のオブジェクトの値によるならこれが適切な記述節に述べられるべきであることに注意してください。
5.5.2.1. Mapping of the SYNTAX clause
5.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 10 of [2] for more information on refined
syntax.
洗練された構文に関する詳しい情報のための[2]のセクション10に相談してください。
5.5.2.2. Mapping of the WRITE-SYNTAX clause
5.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 10 of [2] for more information on refined
syntax.
洗練された構文に関する詳しい情報のための[2]のセクション10に相談してください。
Case, McCloghrie, Rose & Waldbusser [Page 21]
ケース、McCloghrie、ローズ、およびWaldbusser[21ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
5.5.2.3. Mapping of the ACCESS clause
5.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 named in the correspondent VARIATION
clause.
ACCESS節(存在している必要はない)は、エージェントが最大限度のアクセスのレベルほど通信員VARIATION節で指定されたオブジェクトに供給しないのを示すのに使用されます。
The value "not-implemented" indicates the agent does not
implement the object, 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".
値、「書く、-単に、」 唯一後方の互換性に提供されて、新たに定義されたオブジェクト・タイプに使用しないでしょう。 可能な値の注文で「書く、-単に、」 「アクセスしやすくない」以下はそうですか?
5.5.2.4. Mapping of the CREATION-REQUIRES clause
5.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 [6].)
CREATION-REQUIRES節(存在している必要はない)は明らかに値を割り当てなければならない概念的な行の円柱状のオブジェクトを命名するのに使用されます、管理プロトコル集合演算で、エージェントが、その行に関する状態コラムのインスタンスが'アクティブに'設定されるのを許す前に。 (RowStatus[6]の定義に相談してください。)
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 [7,8]), 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.
概念的な行に状態コラムがないなら(すなわち、概念的なテーブルに対応するオブジェクトは[7、8]にメカニズムを使用することで定義されました)、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節で命名されて、その行の円柱状のオブジェクトであるすべての目的でアクセスは平らにならなければなりません。「読書して作成します」。
Case, McCloghrie, Rose & Waldbusser [Page 22]
ケース、McCloghrie、ローズ、およびWaldbusser[22ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
5.5.2.5. Mapping of the DEFVAL clause
5.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節のものと同じです。
5.5.2.6. Mapping of the DESCRIPTION clause
5.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.
記述節(VARIATION節の各使用のために存在していなければならない)は異形か洗練された実装の原文の記述を含んでいます。
5.6. Mapping of the AGENT-CAPABILITIES value
5.6. エージェント-CAPABILITIES価値に関するマッピング
The value of an invocation of the AGENT-CAPABILITIES macro is
an OBJECT IDENTIFIER, which names the value of sysObjectID [3]
or snmpORID [4] for which this capabilities statement is
valid.
エージェント-CAPABILITIESマクロの実施の値はOBJECT IDENTIFIERです。(そのOBJECT IDENTIFIERはこの能力声明が有効である[4]とsysObjectID[3]かsnmpORIDの値を命名します)。
Case, McCloghrie, Rose & Waldbusser [Page 23]
ケース、McCloghrie、ローズ、およびWaldbusser[23ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
5.7. Usage Example
5.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 RFC1213-MIB
INCLUDES { systemGroup, interfacesGroup,
atGroup, ipGroup, icmpGroup,
tcpGroup, udpGroup, snmpGroup }
RFC1213-MIBが含むサポートsystemGroup、interfacesGroup、atGroup、ipGroup、icmpGroup、tcpGroup、udpGroup、snmpGroup
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で制限した」記述
VARIATION atEntry
CREATION-REQUIRES { atPhysAddress }
DESCRIPTION "Address mappings on 4BSD require
both protocol and media addresses"
VARIATION atEntry CREATION-REQUIRES atPhysAddress、記述、「4BSDに関するアドレス・マッピングはプロトコルとメディアアドレスの両方を必要とします」。
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 ipRouteType
SYNTAX INTEGER { direct(3), indirect(4) }
WRITE-SYNTAX INTEGER { invalid(2), direct(3),
indirect(4) }
DESCRIPTION "Information limited on 4BSD"
VARIATION ipRouteType SYNTAX INTEGERが(3)、間接的な(4)を指示する、WRITE-SYNTAX INTEGER、病人(2)、ダイレクト(3)、間接的な(4)、「情報は4BSDで制限した」記述
VARIATION tcpConnState
ACCESS read-only
DESCRIPTION "Unable to set this on 4BSD"
「4BSDにこれを設定できない」VARIATION tcpConnState ACCESS書き込み禁止記述
Case, McCloghrie, Rose & Waldbusser [Page 24]
ケース、McCloghrie、ローズ、およびWaldbusser[24ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
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 sysObjectID (or
snmpORID) value of
この実施、sysObjectID(または、snmpORID)値をもっているエージェント
{ acmeAgents 1 }
acmeAgents1
supports two MIB modules.
2つのMIBモジュールをサポートします。
From MIB-II, all conformance groups except the egpGroup
conformance group are supported. However, the object
ipInAddrErrors is not implemented, whilst the objects
MIB-IIから、egpGroup順応グループ以外のすべての順応グループがサポートされます。 しかしながら、オブジェクトipInAddrErrorsはオブジェクトである間、実装されません。
ifAdminStatus
ifOperStatus
ipDefaultTTL
ipRouteType
ifAdminStatus ifOperStatus ipDefaultTTL ipRouteType
have a restricted syntax, and the object
制限された構文、およびオブジェクトを持ってください。
tcpConnState
tcpConnState
is available only for reading. Note that in the case of the
object ipRouteType the set of values which may be read is
different than the set of values which may be written.
Finally, when creating a new instance in the atTable, the
set-request must create an instance of atPhysAddress.
読書するだけに、利用可能です。 オブジェクトipRouteTypeの場合において、読まれるかもしれない値のセットが書かれているかもしれない値のセットと異なっていることに注意してください。 atTableで新しいインスタンスを作成するとき、最終的に、セット要求はatPhysAddressのインスタンスを作成しなければなりません。
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テーブルの新しいインスタンスの作成はサポートされます。
Case, McCloghrie, Rose & Waldbusser [Page 25]
ケース、McCloghrie、ローズ、およびWaldbusser[25ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
6. Extending an Information Module
6. 情報モジュールを広げています。
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は、情報モジュールを広げるために規則を決めます。 このセクションの残りは順応グループ、承諾声明、および能力声明がどう広げられるかもしれないかを定義します。
6.1. Conformance Groups
6.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値を変えなければなりません、何か非社説変更をオブジェクトグループのどんな節にもするなら関連記述子と共に。
6.2. Compliance Definitions
6.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値を変えなければなりません、関連記述子と共に。
6.3. Capabilities Definitions
6.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値を変えなければなりません、関連記述子と共に。
Case, McCloghrie, Rose & Waldbusser [Page 26]
ケース、McCloghrie、ローズ、およびWaldbusser[26ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
7. Acknowledgements
7. 承認
The section on compliance statements is based, in part, on a
conversation with James R. Davin in December, 1990.
承諾声明のセクションは1990年12月にジェームス・R.デーヴィンとの会話に一部基づいています。
The section on capabilities statements is based, in part, on
RFC 1303.
能力声明のセクションはRFC1303に一部基づいています。
Finally, the comments of the SNMP version 2 working group are
gratefully acknowledged:
最終的に、SNMPバージョン2ワーキンググループのコメントは感謝して承諾されます:
Beth Adams, Network Management Forum
Steve Alexander, INTERACTIVE Systems Corporation
David Arneson, Cabletron Systems
Toshiya Asaba
Fred Baker, ACC
Jim Barnes, Xylogics, Inc.
Brian Bataille
Andy Bierman, SynOptics Communications, Inc.
Uri Blumenthal, IBM Corporation
Fred Bohle, Interlink
Jack Brown
Theodore Brunner, Bellcore
Stephen F. Bush, GE Information Services
Jeffrey D. Case, University of Tennessee, Knoxville
John Chang, IBM Corporation
Szusin Chen, Sun Microsystems
Robert Ching
Chris Chiotasso, Ungermann-Bass
Bobby A. Clay, NASA/Boeing
John Cooke, Chipcom
Tracy Cox, Bellcore
Juan Cruz, Datability, Inc.
David Cullerot, Cabletron Systems
Cathy Cunningham, Microcom
James R. (Chuck) Davin, Bellcore
Michael Davis, Clearpoint
Mike Davison, FiberCom
Cynthia DellaTorre, MITRE
Taso N. Devetzis, Bellcore
Manual Diaz, DAVID Systems, Inc.
Jon Dreyer, Sun Microsystems
David Engel, Optical Data Systems
Mike Erlinger, Lexcel
Roger Fajman, NIH
ベス・アダムス、ネットワークマネージメントフォーラムスティーブ・アレクサンダー、SynOpticsコミュニケーションInc.のインタラクティブシステム社のデヴィッドArneson、CabletronシステムToshiya浅羽フレッドパン屋(ACCジム・バーンズ)Xylogics Inc.ブライアンBatailleアンディBierman; ユリ・ブルーメンソル、IBM社のフレッドBohleはジャック・ブラウン・セオドア・ブルンナーを連結します、Bellcoreのスティーブン・F.ブッシュ、サービスジェフリーD.がケースに入れるGE情報、テネシーの大学、ノクスビルジョン・チャン、IBMの社のSzusinチェン、サン・マイクロシステムズロバートチンクリスChiotasso、アンガマン-BassボビーA; 粘土、NASA/ボーイングのジョン・クック、ChipcomトレーシーCox、Bellcoreのホアン・クルーズ、Datability Inc.デヴィッドCullerot、Cabletronシステムキャシーカニンハム、Microcomジェームス・R.(チャック)デーヴィン、BellcoreのMichael Davis、Clearpointマイク・デイヴィソン、FiberComシンシアDellaTorre、Inc.ジョン・ドレイヤー、サン・マイクロシステムズのデヴィッド・エンゲル、光学データシステムズマイクErlinger、LexcelロジャーFajman、斜め継ぎTaso N.Devetzis、Bellcoreの手動のディアーズデヴィッドSystems NIH
Case, McCloghrie, Rose & Waldbusser [Page 27]
ケース、McCloghrie、ローズ、およびWaldbusser[27ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
Daniel Fauvarque, Sun Microsystems
Karen Frisa, CMU
Shari Galitzer, MITRE
Shawn Gallagher, Digital Equipment Corporation
Richard Graveman, Bellcore
Maria Greene, Xyplex, Inc.
Michel Guittet, Apple
Robert Gutierrez, NASA
Bill Hagerty, Cabletron Systems
Gary W. Haney, Martin Marietta Energy Systems
Patrick Hanil, Nokia Telecommunications
Matt Hecht, SNMP Research, Inc.
Edward A. Heiner, Jr., Synernetics Inc.
Susan E. Hicks, Martin Marietta Energy Systems
Geral Holzhauer, Apple
John Hopprich, DAVID Systems, Inc.
Jeff Hughes, Hewlett-Packard
Robin Iddon, Axon Networks, Inc.
David Itusak
Kevin M. Jackson, Concord Communications, Inc.
Ole J. Jacobsen, Interop Company
Ronald Jacoby, Silicon Graphics, Inc.
Satish Joshi, SynOptics Communications, Inc.
Frank Kastenholz, FTP Software
Mark Kepke, Hewlett-Packard
Ken Key, SNMP Research, Inc.
Zbiginew Kielczewski, Eicon
Jongyeoi Kim
Andrew Knutsen, The Santa Cruz Operation
Michael L. Kornegay, VisiSoft
Deirdre C. Kostik, Bellcore
Cheryl Krupczak, Georgia Tech
Mark S. Lewis, Telebit
David Lin
David Lindemulder, AT&T/NCR
Ben Lisowski, Sprint
David Liu, Bell-Northern Research
John Lunny, The Wollongong Group
Robert C. Lushbaugh Martin, Marietta Energy Systems
Michael Luufer, BBN
Carl Madison, Star-Tek, Inc.
Keith McCloghrie, Hughes LAN Systems
Evan McGinnis, 3Com Corporation
Bill McKenzie, IBM Corporation
Donna McMaster, SynOptics Communications, Inc.
ダニエルFauvarque、サン・マイクロシステムズカレンFrisa、米カーネギーメロン大学Shari Galitzer、斜め継ぎショーン・ギャラガー、DECリチャードGraveman、Bellcoreのマリア・グリーン、Xyplex Inc.ミシェルGuittet、アップルのロバート・グティエレス、NASAのビル・ハガーティ(CabletronシステムゲーリーW); ヘーニー、マーチン・マリエッタエネルギー・システムパトリックHanil、ノキアのテレコミュニケーションマット・ヘヒト、SNMP研究Inc.エドワードA.ハイナー、Jr.、Synernetics株式会社のスーザン・E.ヒックス、マーチンマリエッタエネルギー・システムGeral Holzhauer、アップルジョンHopprich、デヴィッドシステムInc; ジェフ・ヒューズ、ヒューレット・パッカードロビンIddon、軸索ネットワークInc.デヴィッド・Itusakケビン・M.ジャクソン、Inc.Ole J.ジェイコブセン、一致コミュニケーションInterop会社のロナルド・ジャコービー、シリコングラフィックスのサティシュ・ジョーシー、SynOpticsコミュニケーションInc.フランクKastenholz、FTPソフトウェアマークKepke、ヒューレット・パッカードケンKey、SNMPはInc.Zbiginew Kielczewskiについて研究します、Eicon Jongyeoiキム・アンドリュー・クヌーセン、サンタクルス操作マイケルL.Kornegay、VisiSoftディアドラC.Kostik、BellcoreシェリルKrupczak、ジョージア工科大マークS.Lewis、テレビットデヴィッドリンデヴィッドLindemulder、AT&T/NCRベンLisowski、スプリントのデヴィッド・リュウ、ベル-北ResearchジョンLunny、ウォロンゴンGroupロバート・C.Lushbaughマーチン、マリエッタEnergy SystemsマイケルLuufer BBNカール・マディソン、Star-Tek Inc.キースMcCloghrie、ヒューズ・LAN Systemsエヴァン・マクギニス、3Com社のビル・マッケンジー、IBMの社のドナ・マクマスター、SynOptics Communications Inc.
Case, McCloghrie, Rose & Waldbusser [Page 28]
ケース、McCloghrie、ローズ、およびWaldbusser[28ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
John Medicke, IBM Corporation
Doug Miller, Telebit
Dave Minnich, FiberCom
Mohammad Mirhakkak, MITRE
Rohit Mital, Protools
George Mouradian, AT&T Bell Labs
Patrick Mullaney, Cabletron Systems
Dan Myers, 3Com Corporation
Rina Nathaniel, Rad Network Devices Ltd.
Hien V. Nguyen, Sprint
Mo Nikain
Tom Nisbet
William B. Norton, MERIT
Steve Onishi, Wellfleet Communications, Inc.
David T. Perkins, SynOptics Communications, Inc.
Carl Powell, BBN
Ilan Raab, SynOptics Communications, Inc.
Richard Ramons, AT&T
Venkat D. Rangan, Metric Network Systems, Inc.
Louise Reingold, Sprint
Sam Roberts, Farallon Computing, Inc.
Kary Robertson, Concord Communications, Inc.
Dan Romascanu, Lannet Data Communications Ltd.
Marshall T. Rose, Dover Beach Consulting, Inc.
Shawn A. Routhier, Epilogue Technology Corporation
Chris Rozman
Asaf Rubissa, Fibronics
Jon Saperia, Digital Equipment Corporation
Michael Sapich
Mike Scanlon, Interlan
Sam Schaen, MITRE
John Seligson, Ultra Network Technologies
Paul A. Serice, Corporation for Open Systems
Chris Shaw, Banyan Systems
Timon Sloane
Robert Snyder, Cisco Systems
Joo Young Song
Roy Spitier, Sprint
Einar Stefferud, Network Management Associates
John Stephens, Cayman Systems, Inc.
Robert L. Stewart, Xyplex, Inc. (chair)
Kaj Tesink, Bellcore
Dean Throop, Data General
Ahmet Tuncay, France Telecom-CNET
Maurice Turcotte, Racal Datacom
ジョンMedicke、IBMの社のダグ・ミラー、テレビットのデーヴ・ミンニヒ、FiberComムハマドMirhakkak、斜め継ぎRohit Mital、ProtoolsジョージMouradian、AT&Tのベル研究所のパトリック・マレイニイ、Cabletronシステムダン・マイアーズ、3Com社のリーナ・ナザニエル、radネットワークデバイス株式会社Hien V.Nguyen(Sprint Mo NikainトムニスベットウィリアムB.ノートン)がスティーブ鬼石に値して、WellfleetコミュニケーションがInc.デヴィッド・T.パーキンスであり、SynOpticsコミュニケーションはInc.カール・パウエルです、BBN宜蘭ラープ、SynOpticsコミュニケーションInc.リチャードRamons、AT&TのヴェンカトD; Rangan、Inc.ルイーズ・レインゴールド、メートル法のネットワーク・システムスプリントのサム・ロバーツ、ファラロンコンピューティングInc.Karyロバートソン、一致コミュニケーションInc.ダンRomascanu、Lannetデータ通信株式会社マーシャルT.は上昇しました、ドーヴァービーチコンサルティングInc.ショーンA.Routhier、エピローグ技術社のクリスRozman Asaf Rubissa、FibronicsジョンSaperia、DECのマイケル・Sapichマイク・スキャンロン、InterlanサムSchaen、斜め継ぎジョンSeligson、超ネットワーク技術のポールA.Serice、開いているSysのための社temsクリス・ショー、Banyan Systemsタイモン・スローンロバート・スナイダー、シスコシステムズJooヤングSongロイSpitier、スプリントEinar Stefferud、Network Management Associatesジョン・スティーブンス、ケイマンSystems Inc.ロバート・L.スチュワート、Xyplex Inc.(いす)カイTesink、BellcoreディーンThroop、データゼネラルAhmet Tuncay、フランステレコム-CNETモーリスTurcotte Racal Datacom
Case, McCloghrie, Rose & Waldbusser [Page 29]
ケース、McCloghrie、ローズ、およびWaldbusser[29ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
Warren Vik, INTERACTIVE Systems Corporation
Yannis Viniotis
Steven L. Waldbusser, Carnegie Mellon Universitty
Timothy M. Walden, ACC
Alice Wang, Sun Microsystems
James Watt, Newbridge
Luanne Waul, Timeplex
Donald E. Westlake III, Digital Equipment Corporation
Gerry White
Bert Wijnen, IBM Corporation
Peter Wilson, 3Com Corporation
Steven Wong, Digital Equipment Corporation
Randy Worzella, IBM Corporation
Daniel Woycke, MITRE
Honda Wu
Jeff Yarnell, Protools
Chris Young, Cabletron
Kiho Yum, 3Com Corporation
ウォレン・ビーク、インタラクティブシステム社のヤニスViniotisスティーブンL.Waldbusser、カーネギー・メロン・Universittyティモシー・M.ウォルデンACCアリスワング、サン・マイクロシステムズのジェームズ・ワット、NewbridgeルアンWaul、Timeplexドナルド・E.ウェストレークIII、DECゲリーホワイトバートWijnen、IBMの社のピーター・ウィルソン、3Com社のスティーブンWong、DECランディWorzella、IBM社のダニエルWoycke、斜め継ぎホンダウージェフYarnell、Protoolsクリス・ヤング、おいしいCabletron Kiho3Com社
Case, McCloghrie, Rose & Waldbusser [Page 30]
ケース、McCloghrie、ローズ、およびWaldbusser[30ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
8. References
8. 参照
[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] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Structure of Management Information for version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1442,
SNMP Research, Inc., Hughes LAN Systems, Dover Beach
Consulting, Inc., Carnegie Mellon University, April 1993.
[2] ケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのManagement情報の構造」RFC1442、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[3] McCloghrie, K., and Rose, M., "Management Information
Base for Network Management of TCP/IP-based internets:
MIB-II", STD 17, RFC 1213, March 1991.
[3] McCloghrie、K.とローズ、M.、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、1991年3月。
[4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Management Information Base for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1450, SNMP
Research, Inc., Hughes LAN Systems, Dover Beach
Consulting, Inc., Carnegie Mellon University, April 1993.
[4] ケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための管理Information基地」RFC1450、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[5] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Protocol Operations for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1448, SNMP Research,
Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
Carnegie Mellon University, April 1993.
[5] ケース、J.、McCloghrie、K.、ローズ、M.、およびWaldbusser、S.は「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためにOperationsについて議定書の中で述べます」、RFC1448、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学、1993年4月。
[6] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Textual Conventions for version 2 of the the Simple
Network Management Protocol (SNMPv2)", RFC 1443, SNMP
Research, Inc., Hughes LAN Systems, Dover Beach
Consulting, Inc., Carnegie Mellon University, April 1993.
[6] ケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための原文のConventions」RFC1443、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[7] Rose, M., and McCloghrie, K., "Structure and
Identification of Management Information for TCP/IP-based
internets", STD 16, RFC 1155, May 1990.
[7] ローズ、M.、McCloghrie、K.、および「TCP/IPベースのインターネットのためのManagement情報の構造とIdentification」、STD16、RFC1155(1990年5月)
[8] Rose, M., and McCloghrie, K., "Concise MIB Definitions",
STD 16, RFC 1212, March 1991.
[8] ローズ、M.とMcCloghrie、K.、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
Case, McCloghrie, Rose & Waldbusser [Page 31]
ケース、McCloghrie、ローズ、およびWaldbusser[31ページ]
RFC 1444 Conformance Statements for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1444順応声明
9. Security Considerations
9. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
10. Authors' Addresses
10. 作者のアドレス
Jeffrey D. Case
SNMP Research, Inc.
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
US
ジェフリーD.ケースSNMP研究Inc.3001Kimberlin Heights通り ノクスビル、テネシー37920-9716米国
Phone: +1 615 573 1434
Email: case@snmp.com
以下に電話をしてください。 +1 1434年の615 573メール: case@snmp.com
Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA 94043
US
キースMcCloghrieヒューズLANシステム1225チャールストンRoadカリフォルニア94043マウンテンビュー(米国)
Phone: +1 415 966 7934
Email: kzm@hls.com
以下に電話をしてください。 +1 7934年の415 966メール: kzm@hls.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US
Inc.420Whisman法廷カリフォルニア94043-2186マウンテンビュー(米国)に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 1052年の415 968メール: mrose@dbc.mtview.ca.us
Steven Waldbusser
Carnegie Mellon University
4910 Forbes Ave
Pittsburgh, PA 15213
US
スティーブンWaldbusserカーネギーメロン大学4910フォーブズ・Ave PA15213ピッツバーグ(米国)
Phone: +1 412 268 6628
Email: waldbusser@cmu.edu
以下に電話をしてください。 +1 6628年の412 268メール: waldbusser@cmu.edu
Case, McCloghrie, Rose & Waldbusser [Page 32]
ケース、McCloghrie、ローズ、およびWaldbusser[32ページ]
一覧
スポンサーリンク
