RFC2741 日本語訳
2741 Agent Extensibility (AgentX) Protocol Version 1. M. Daniele, B.Wijnen, M. Ellison, D. Francisco. January 2000. (Format: TXT=199867 bytes) (Obsoletes RFC2257) (Status: DRAFT STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Daniele
Request for Comments: 2741 Compaq Computer Corporation
Obsoletes: 2257 B. Wijnen
Category: Standards Track T.J. Watson Research Center, IBM Corp.
M. Ellison, Ed.
Ellison Software Consulting, Inc.
D. Francisco. Ed.
Cisco Systems, Inc.
January 2000
コメントを求めるワーキンググループM.ダニエル要求をネットワークでつないでください: 2741 コンパックコンピュータ社は以下を時代遅れにします。 2257年のB.Wijnenカテゴリ: 規格はエドT.J.ワトソン研究所、IBM社のM.エリソン、エリソンソフトウェアコンサルティングInc.D.フランシスコを追跡します。 エドシスコシステムズInc.2000年1月
Agent Extensibility (AgentX) Protocol
Version 1
エージェント伸展性(AgentX)プロトコルバージョン1
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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages. This memo obsoletes RFC 2257.
このメモは広げることができるSNMPエージェントのために標準化されたフレームワークを定義します。 プロトコル(AgentX)は、以前はそれらと、手順の要素の広げることができるエージェントがSNMPプロトコルメッセージを処理する間でよくそれがマスターエージェントと副代理店と呼ばれる処理実体を定義すると伝えていました。 このメモはRFC2257を時代遅れにします。
Table of Contents
目次
1. Introduction.....................................................4
2. The SNMP Management Framework....................................4
2.1. A Note on Terminology........................................5
3. Extending the MIB................................................5
3.1. Motivation for AgentX........................................6
4. AgentX Framework.................................................6
4.1. AgentX Roles.................................................7
4.2. Applicability................................................8
4.3. Design Features of AgentX....................................9
4.4. Non-Goals...................................................10
1. 序論…4 2. SNMP管理フレームワーク…4 2.1. 用語に関する注…5 3. MIBを広げています…5 3.1. AgentXに関する動機…6 4. AgentXフレームワーク…6 4.1. AgentXの役割…7 4.2. 適用性…8 4.3. AgentXの特徴を設計してください…9 4.4. 非目標…10
Daniele, et al. Standards Track [Page 1] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[1ページ]。
5. AgentX Encodings................................................11
5.1. Object Identifier...........................................11
5.2. SearchRange.................................................13
5.3. Octet String................................................14
5.4. Value Representation........................................15
6. Protocol Definitions............................................17
6.1. AgentX PDU Header...........................................17
6.1.1. Context.................................................20
6.2. AgentX PDUs.................................................20
6.2.1. The agentx-Open-PDU.....................................20
6.2.2. The agentx-Close-PDU....................................22
6.2.3. The agentx-Register-PDU.................................23
6.2.4. The agentx-Unregister-PDU...............................27
6.2.5. The agentx-Get-PDU......................................29
6.2.6. The agentx-GetNext-PDU..................................30
6.2.7. The agentx-GetBulk-PDU..................................32
6.2.8. The agentx-TestSet-PDU..................................34
6.2.9. The agentx-CommitSet, -UndoSet, -CleanupSet PDUs........35
6.2.10. The agentx-Notify-PDU..................................36
6.2.11. The agentx-Ping-PDU....................................37
6.2.12. The agentx-IndexAllocate-PDU...........................37
6.2.13. The agentx-IndexDeallocate-PDU.........................38
6.2.14. The agentx-AddAgentCaps-PDU............................39
6.2.15. The agentx-RemoveAgentCaps-PDU.........................41
6.2.16. The agentx-Response-PDU................................43
7. Elements of Procedure...........................................45
7.1. Processing AgentX Administrative Messages...................45
7.1.1. Processing the agentx-Open-PDU..........................46
7.1.2. Processing the agentx-IndexAllocate-PDU.................47
7.1.3. Processing the agentx-IndexDeallocate-PDU...............49
7.1.4. Processing the agentx-Register-PDU......................50
7.1.4.1. Handling Duplicate and Overlapping Subtrees.........50
7.1.4.2. Registering Stuff...................................51
7.1.4.2.1. Registration Priority...........................51
7.1.4.2.2. Index Allocation................................51
7.1.4.2.3. Examples........................................53
7.1.5. Processing the agentx-Unregister-PDU....................55
7.1.6. Processing the agentx-AddAgentCaps-PDU..................55
7.1.7. Processing the agentx-RemoveAgentCaps-PDU...............55
7.1.8. Processing the agentx-Close-PDU.........................56
7.1.9. Detecting Connection Loss...............................56
7.1.10. Processing the agentx-Notify-PDU.......................56
7.1.11. Processing the agentx-Ping-PDU.........................57
7.2. Processing Received SNMP Protocol Messages..................58
7.2.1. Dispatching AgentX PDUs.................................58
7.2.1.1. agentx-Get-PDU......................................61
7.2.1.2. agentx-GetNext-PDU..................................61
7.2.1.3. agentx-GetBulk-PDU..................................62
5. AgentX Encodings…11 5.1. オブジェクト識別子…11 5.2. SearchRange…13 5.3. 八重奏ストリング…14 5.4. 表現を評価してください…15 6. 定義について議定書の中で述べてください…17 6.1. AgentX PDUヘッダー…17 6.1.1. 文脈…20 6.2. AgentX PDUs…20 6.2.1. agentxの開いているPDU…20 6.2.2. agentxの近いPDU…22 6.2.3. agentxレジスタPDU…23 6.2.4. agentx-Unregister-PDU…27 6.2.5. agentxはPDUを手に入れます…29 6.2.6. agentx-GetNext-PDU…30 6.2.7. agentx-GetBulk-PDU…32 6.2.8. agentx-TestSet-PDU…34 6.2.9. agentx-CommitSet、-UndoSet、-CleanupSet PDUs…35 6.2.10. agentxはPDUに通知しています…36 6.2.11. agentxピングPDU…37 6.2.12. agentx-IndexAllocate-PDU…37 6.2.13. agentx-IndexDeallocate-PDU…38 6.2.14. agentx-AddAgentCaps-PDU…39 6.2.15. agentx-RemoveAgentCaps-PDU…41 6.2.16. agentx応答PDU…43 7. 手順のElements…45 7.1. AgentXの管理メッセージを処理します…45 7.1.1. agentxの開いているPDUを処理します…46 7.1.2. agentx-IndexAllocate-PDUを処理します…47 7.1.3. agentx-IndexDeallocate-PDUを処理します…49 7.1.4. agentxレジスタPDUを処理します…50 7.1.4.1. 写しを扱って、下位木を重ね合わせます…50 7.1.4.2. ものを登録します…51 7.1.4.2.1. 登録優先権…51 7.1.4.2.2. 配分に索引をつけてください…51 7.1.4.2.3. 例…53 7.1.5. agentx-Unregister-PDUを処理します…55 7.1.6. agentx-AddAgentCaps-PDUを処理します…55 7.1.7. agentx-RemoveAgentCaps-PDUを処理します…55 7.1.8. agentxの近いPDUを処理します…56 7.1.9. 接続の損失を検出します…56 7.1.10. agentxにPDUに通知しているのを処理します…56 7.1.11. agentxピングPDUを処理します…57 7.2. 処理はSNMPプロトコルメッセージを受け取りました…58 7.2.1. AgentX PDUsを派遣します…58 7.2 .1 .1 agentxはPDUを手に入れます…61 7.2.1.2agentx-GetNext-PDU…61 7.2.1.3agentx-GetBulk-PDU…62
Daniele, et al. Standards Track [Page 2] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[2ページ]。
7.2.1.4. agentx-TestSet-PDU..................................63
7.2.1.5. Dispatch............................................64
7.2.2. Subagent Processing.....................................64
7.2.3. Subagent Processing of agentx-Get, GetNext, GetBulk-PDUs65
7.2.3.1. Subagent Processing of the agentx-Get-PDU...........65
7.2.3.2. Subagent Processing of the agentx-GetNext-PDU.......66
7.2.3.3. Subagent Processing of the agentx-GetBulk-PDU.......66
7.2.4. Subagent Processing of agentx-TestSet, -CommitSet,
-UndoSet, -CleanupSet-PDUs..............................67
7.2.4.1. Subagent Processing of the agentx-TestSet-PDU.......68
7.2.4.2. Subagent Processing of the agentx-CommitSet-PDU.....69
7.2.4.3. Subagent Processing of the agentx-UndoSet-PDU.......69
7.2.4.4. Subagent Processing of the agentx-CleanupSet-PDU....70
7.2.5. Master Agent Processing of AgentX Responses.............70
7.2.5.1. Common Processing of All AgentX Response PDUs.......70
7.2.5.2. Processing of Responses to agentx-Get-PDUs..........70
7.2.5.3. Processing of Responses to agentx-GetNext-PDU and
agentx-GetBulk-PDU..................................71
7.2.5.4. Processing of Responses to agentx-TestSet-PDUs......72
7.2.5.5. Processing of Responses to agentx-CommitSet-PDUs....73
7.2.5.6. Processing of Responses to agentx-UndoSet-PDUs......74
7.2.6. Sending the SNMP Response-PDU...........................74
7.2.7. MIB Views...............................................74
7.3. State Transitions...........................................75
7.3.1. Set Transaction States..................................75
7.3.2. Transport Connection States.............................77
7.3.3. Session States..........................................78
8. Transport Mappings..............................................79
8.1. AgentX over TCP.............................................79
8.1.1. Well-known Values.......................................79
8.1.2. Operation...............................................79
8.2. AgentX over UNIX-domain Sockets.............................80
8.2.1. Well-known Values.......................................80
8.2.2. Operation...............................................80
9. Security Considerations.........................................81
10. Acknowledgements...............................................82
11. Authors' and Editor's Addresses................................83
12. References.....................................................84
13. Notices........................................................86
Appendix A. Changes relative to RFC 2257 ..........................87
Full Copyright Statement ..........................................91
7.2.1.4. agentx-TestSet-PDU…63 7.2.1.5. 急いでください…64 7.2.2. 副代理店処理…64 7.2.3. agentx得ることの副代理店処理、GetNext、GetBulk-PDUs65 7.2.3、.1 agentxがPDUを手に入れることの副代理店処理…65 7.2.3.2. agentx-GetNext-PDUの副代理店処理…66 7.2.3.3. agentx-GetBulk-PDUの副代理店処理…66 7.2.4. agentx-TestSet、-CommitSet、-UndoSet、-CleanupSet-PDUsの副代理店処理…67 7.2.4.1. agentx-TestSet-PDUの副代理店処理…68 7.2.4.2. agentx-CommitSet-PDUの副代理店処理…69 7.2.4.3. agentx-UndoSet-PDUの副代理店処理…69 7.2.4.4. agentx-CleanupSet-PDUの副代理店処理…70 7.2.5. AgentX応答の処理をエージェントにマスタリングしてください…70 7.2.5.1. すべてのAgentX応答PDUsの一般的な処理…70 7.2.5.2. agentxがPDUsを手に入れることへの応答の処理…70 7.2.5.3. agentx-GetNext-PDUとagentx-GetBulk-PDUへの応答の処理…71 7.2.5.4. agentx-TestSet-PDUsへの応答の処理…72 7.2.5.5. agentx-CommitSet-PDUsへの応答の処理…73 7.2.5.6. agentx-UndoSet-PDUsへの応答の処理…74 7.2.6. SNMP応答-PDUを送ります…74 7.2.7. MIB視点…74 7.3. 変遷を述べてください…75 7.3.1. トランザクション州を設定してください…75 7.3.2. 接続州を輸送してください…77 7.3.3. セッション州…78 8. マッピングを輸送してください…79 8.1. TCPの上のAgentX…79 8.1.1. よく知られる値…79 8.1.2. 操作…79 8.2. UNIX-ドメインの上のAgentXソケット…80 8.2.1. よく知られる値…80 8.2.2. 操作…80 9. セキュリティ問題…81 10. 承認…82 11. 作者とエディタのアドレス…83 12. 参照…84 13. 通知…86 RFC2257に比例した付録A.Changes…87 完全な著作権宣言文…91
Daniele, et al. Standards Track [Page 3] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[3ページ]。
1. Introduction
1. 序論
This memo defines a standardized framework for extensible SNMP agents. It defines processing entities called master agents and subagents, a protocol (AgentX) used to communicate between them, and the elements of procedure by which the extensible agent processes SNMP protocol messages.
このメモは広げることができるSNMPエージェントのために標準化されたフレームワークを定義します。 プロトコル(AgentX)は、以前はそれらと、手順の要素の広げることができるエージェントがSNMPプロトコルメッセージを処理する間でよくそれがマスターエージェントと副代理店と呼ばれる処理実体を定義すると伝えていました。
This memo obsoletes RFC 2257. It is worth noting that most of the changes are for the purpose of clarification. The only changes affecting AgentX protocol messages on the wire are:
このメモはRFC2257を時代遅れにします。 変化の大部分が明確化の目的のためのものであることに注意する価値があります。 ワイヤに関するAgentXプロトコルメッセージに影響する唯一の変化は以下の通りです。
- The agentx-Notify-PDU and agentx-Close-PDU now generate an
agentx-Response-PDU
- agentxがPDUに通知していて、agentxの近いPDUは現在、agentx応答PDUを生成します。
- Three new error codes are available: parseFailed(266),
requestDenied(267), and processingError(268)
- 3つの新しいエラーコードが利用可能です: parseFailed(266)、requestDenied(267)、およびprocessingError(268)
Appendix A provides a detailed list of changes relative to RFC 2257.
付録AはRFC2257に比例して変化の詳細なリストを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [27].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[27]で説明されるように本書では解釈されることであるべきですか?
2. The SNMP Management Framework
2. SNMP管理フレームワーク
The SNMP Management Framework presently consists of five major components:
SNMP Management Frameworkは現在、5個の主要コンポーネントから成ります:
An overall architecture, described in RFC 2571 [1].
RFC2571[1]で説明された総合的なアーキテクチャ。
Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [2], STD 16, RFC 1212 [3] and RFC 1215 [4]. The second version, called SMIv2, is described in STD 58, RFC 2578 [5], STD 58, RFC 2579 [6] and STD 58, RFC 2580 [7].
オブジェクトを説明して、命名するためのメカニズムと管理の目的のためのイベント。 Management情報(SMI)のこのStructureの最初のバージョンは、STD16、RFC1155[2]、STD16、RFC1212[3]、およびRFC1215[4]でSMIv1と呼ばれて、説明されます。 SMIv2と呼ばれる第2バージョンはSTD58、RFC2578[5]、STD58、RFC2579[6]、およびSTD58(RFC2580[7])で説明されます。
Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [8]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [9] and RFC 1906 [10]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [10], RFC 2572 [11] and RFC 2574 [12].
経営情報を移すためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンは、STD15、RFC1157[8]でSNMPv1と呼ばれて、説明されます。 SNMPメッセージプロトコルの第2のバージョンは、RFC1901[9]とRFC1906[10]でSNMPv2cと呼ばれて、説明されます。(プロトコルはインターネット標準化過程プロトコルではありません)。 メッセージプロトコルの第3バージョンは、RFC1906[10]、RFC2572[11]、およびRFC2574[12]でSNMPv3と呼ばれて、説明されます。
Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in
経営情報にアクセスするための操作について議定書の中で述べてください。 形式が説明されるプロトコル操作と関連PDUの第一セット
Daniele, et al. Standards Track [Page 4] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[4ページ]。
STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].
STD15、RFC1157[8]。 2番目のセットのプロトコル操作と関連PDU形式はRFC1905[13]で説明されます。
A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15].
1セットの基礎的応用はRFCで2573[14]について説明しました、そして、視点ベースのアクセス管理機構はRFCで2575[15]について説明しました。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16].
RFC2570[16]で現在のSNMP Management Frameworkへの、より詳細な紹介を見つけることができます。
Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.
管理オブジェクトはManagement Information基地と呼ばれた仮想情報店かMIBを通してアクセスされます。 MIBのオブジェクトは、SMIで定義されたメカニズムを使用することで定義されます。
2.1. A Note on Terminology
2.1. 用語に関する注
The term "variable" refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMIv2 (STD 58, RFC 2578, [5]) or the textual conventions based on the SMIv2 (STD 58, RFC 2579 [6]). The term "variable binding" normally refers to the pairing of the name of a variable and its associated value. However, if certain kinds of exceptional conditions occur during processing of a retrieval request, a variable binding will pair a name and an indication of that exception.
STD58、RFC2578、[5])または原文のコンベンションがSMIv2を基礎づけました。「可変である」という用語がSMIv2に詳しく説明されたコンベンションに従って定義された非集団オブジェクトタイプのインスタンスについて言及する、((STD58(RFC2579[6]))。 通常、「変項束縛」という用語は可変価値とその関連価値の名前の組み合わせについて言及します。 しかしながら、ある種類の例外的な状態が検索要求の処理の間、現れると、変項束縛はその例外の名前としるしを対にするでしょう。
A variable-binding list is a simple list of variable bindings.
変項束縛リストは変項束縛に関する単純並びです。
The name of a variable is an OBJECT IDENTIFIER, which is the concatenation of the OBJECT IDENTIFIER of the corresponding object type together with an OBJECT IDENTIFIER fragment identifying the instance. The OBJECT IDENTIFIER of the corresponding object-type is called the OBJECT IDENTIFIER prefix of the variable.
変数の名前はOBJECT IDENTIFIERです。(そのOBJECT IDENTIFIERはインスタンスを特定するOBJECT IDENTIFIER断片に伴う対応するオブジェクト・タイプのOBJECT IDENTIFIERの連結です)。 対応するオブジェクト・タイプのOBJECT IDENTIFIERは変数のOBJECT IDENTIFIER接頭語と呼ばれます。
3. Extending the MIB
3. MIBを広げています。
New MIB modules that extend the Internet-standard MIB are continuously being defined by various IETF working groups. It is also common for enterprises or individuals to create or extend enterprise-specific or experimental MIBs.
インターネット標準MIBを広げる新しいMIBモジュールが様々なIETFワーキンググループによって絶え間なく定義されています。 また、企業か個人が企業特有の、または、実験的なMIBsを作成するか、または広げるのも、一般的です。
As a result, managed devices are frequently complex collections of manageable components that have been independently installed on a managed node. Each component provides instrumentation for the managed objects defined in the MIB module(s) it implements.
その結果、管理されたデバイスは独自に管理されたノードにインストールされた処理しやすいコンポーネントの頻繁に複雑な収集です。 各コンポーネントはそれが実装するMIBモジュールで定義された管理オブジェクトのための計装を提供します。
The SNMP framework does not describe how the set of managed objects supported by a particular agent may be changed dynamically.
SNMPフレームワークはどうダイナミックに特定代理人によってサポートされた管理オブジェクトのセットを変えるかもしれないかを説明しません。
Daniele, et al. Standards Track [Page 5] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[5ページ]。
3.1. Motivation for AgentX
3.1. AgentXに関する動機
This very real need to dynamically extend the management objects within a node has given rise to a variety of "extensible agents", which typically comprise
ノードの中でダイナミックに管理オブジェクトを広げるこの非常に本当の必要性がさまざまな「広げることができるエージェント」をもたらした、どれ、通常包括するか。
- a "master" agent that is available on the standard transport
address and that accepts SNMP protocol messages
- 標準の輸送アドレスで利用可能であり、SNMPプロトコルメッセージを受け入れる「マスター」エージェント
- a set of "subagents" that each contain management
instrumentation
- それぞれ管理計装を含む1セットの「副代理店」
- a protocol that operates between the master agent and
subagents, permitting subagents to "connect" to the master
agent, and the master agent to multiplex received SNMP protocol
messages amongst the subagents.
- マスターエージェントと副代理店の間で作動するプロトコル、マスターエージェント、およびマスターエージェントへの「接続してください」への副代理店が多重送信されることを許可するのがSNMPプロトコルメッセージを副代理店に受け取りました。
- a set of tools to aid subagent development, and a runtime (API)
environment that hides much of the protocol operation between a
subagent and the master agent.
- 副代理店開発を支援するツール、およびたくさん隠す副代理店とマスターエージェントの間のプロトコル操作のランタイム(API)環境の1セット。
The wide deployment of extensible SNMP agents, coupled with the lack of Internet standards in this area, makes it difficult to field SNMP-manageable applications. A vendor may have to support several different subagent environments (APIs) in order to support different target platforms.
この領域における、インターネット標準の不足に結びつけられた広げることができるSNMPエージェントの広い展開で、SNMP処理しやすいアプリケーションをさばくのは難しくなります。 ベンダーは、異なった目標プラットホームをサポートするためにいくつかの異なった副代理店環境が(API)であるとサポートしなければならないかもしれません。
It can also become quite cumbersome to configure subagents and (possibly multiple) master agents on a particular managed node.
また、特定の管理されたノードの上の副代理店と(ことによると複数)のマスターエージェントを構成するのはかなり厄介になることができます。
Specifying a standard protocol for agent extensibility (AgentX) provides the technical foundation required to solve both of these problems. Independently developed AgentX-capable master agents and subagents will be able to interoperate at the protocol level. Vendors can continue to differentiate their products in all other respects.
エージェント伸展性(AgentX)に標準プロトコルを指定すると、これらの問題の両方を解決するのに必要である技術的な基礎を提供します。独自に開発されたAgentX有能なマスターエージェントと副代理店はプロトコルレベルで共同利用できるでしょう。 ベンダーは、他のすべての点でそれらの製品を差別化し続けることができます。
4. AgentX Framework
4. AgentXフレームワーク
Within the SNMP framework, a managed node contains a processing entity, called an agent, which has access to management information.
SNMPフレームワークの中では、管理されたノードは経営情報に近づく手段を持っているエージェントと呼ばれる処理実体を含みます。
Within the AgentX framework, an agent is further defined to consist of:
AgentXフレームワークの中では、エージェントは、以下から成るようにさらに定義されます。
Daniele, et al. Standards Track [Page 6] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[6ページ]。
- a single processing entity called the master agent, which sends
and receives SNMP protocol messages in an agent role (as
specified by the SNMP framework documents) but typically has
little or no direct access to management information.
- マスターエージェントと呼ばれるただ一つの処理実体はまず経営情報に直接アクセスをエージェントの役割(SNMPフレームワークドキュメントによって指定されるように)、しかし、通常持っていません。そのエージェントは、SNMPプロトコルメッセージを送って、受け取ります。
- zero or more processing entities called subagents, which are
"shielded" from the SNMP protocol messages processed by the
master agent, but which have access to management information.
- ゼロかさらに処理している実体が、副代理店と呼びました。(マスターエージェントによって処理されたSNMPプロトコルメッセージから「保護されます」が、副代理店は経営情報に近づく手段を持っています)。
The master and subagent entities communicate via AgentX protocol messages, as specified in this memo. Other interfaces (if any) on these entities, and their associated protocols, are outside the scope of this document. While some of the AgentX protocol messages appear similar in syntax and semantics to the SNMP, bear in mind that AgentX is not SNMP.
マスターと副代理店実体はこのメモで指定されるようにAgentXプロトコルメッセージで交信します。 このドキュメントの範囲の外にこれらの実体、およびそれらの関連プロトコルの他のインタフェース(もしあれば)があります。 AgentXプロトコルメッセージのいくつかが構文と意味論においてSNMPと同様に見えている間、AgentXがSNMPでないことを覚えておいてください。
The internal operations of AgentX are invisible to an SNMP entity operating in a manager role. From a manager's point of view, an extensible agent behaves exactly as would a non-extensible (monolithic) agent that has access to the same management instrumentation.
AgentXの社内業務はマネージャの役割で作動するSNMP実体に目に見えません。 マネージャの観点から、広げることができるエージェントはちょうど同じ管理計装に近づく手段を持っている非広げることができる(一枚岩的な)エージェントであるだろうことのように振る舞います。
This transparency to managers is a fundamental requirement of AgentX, and is what differentiates AgentX subagents from SNMP proxy agents.
マネージャへのこの透明は、AgentXの基本的な要件であり、SNMPプロキシエージェントとAgentX副代理店を区別することです。
4.1. AgentX Roles
4.1. AgentXの役割
An entity acting in a master agent role performs the following functions:
マスターエージェントの役割で行動する実体は以下の機能を実行します:
- Accepts AgentX session establishment requests from subagents.
- 副代理店からAgentXセッション設立要求を受け入れます。
- Accepts registration of MIB regions by subagents.
- 副代理店はMIB領域の登録を受け入れます。
- Sends and accepts SNMP protocol messages on the agent's
specified transport addresses.
- エージェントの指定された輸送アドレスに関するSNMPプロトコルメッセージを送って、受け入れます。
- Implements the agent role Elements of Procedure specified for
the administrative framework applicable to the SNMP protocol
message, except where they specify performing management
operations. (The application of MIB views, and the access
control policy for the managed node, are implemented by the
master agent.)
- エージェントの役割が管理操作を実行する彼らが指定するところ以外のSNMPプロトコルメッセージに適切な管理フレームワークに指定されたProcedureのElementsであると実装します。 (MIB視点のアプリケーションと、管理されたノードのためのアクセス制御政策はマスターエージェントによって実施されます。)
- Provides instrumentation for the MIB objects defined in RFC
1907 [17], and for any MIB objects relevant to any
administrative framework it supports.
- RFC1907[17]で定義されたMIBオブジェクト、およびそれがサポートするどんな管理フレームワークにも関連しているどんなMIBオブジェクトのための計装も提供します。
Daniele, et al. Standards Track [Page 7] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[7ページ]。
- Sends and receives AgentX protocol messages to access
management information, based on the current registry of MIB
regions.
- MIB領域の現在の登録に基づいて経営情報にアクセスするAgentXプロトコルメッセージを送って、受け取ります。
- Forwards notifications on behalf of subagents.
- 副代理店を代表して通知を転送します。
An entity acting in a subagent role performs the following functions:
副代理店の役割で行動する実体は以下の機能を実行します:
- Initiates AgentX sessions with the master agent.
- マスターエージェントとのAgentXセッションを開始します。
- Registers MIB regions with the master agent.
- マスターエージェントにMIB領域を登録します。
- Instantiates managed objects.
- 管理オブジェクトを例示します。
- Binds OIDs within its registered MIB regions to actual
variables.
- 実際の変数への登録されたMIB領域の中のひものOIDs。
- Performs management operations on variables.
- 変数に管理操作を実行します。
- Initiates notifications.
- 通知を開始します。
4.2. Applicability
4.2. 適用性
It is intended that this memo specify the smallest amount of required behavior necessary to achieve the largest benefit, that is, to cover a very large number of possible MIB implementations and configurations with minimum complexity and low "cost of entry".
このメモが最も大きい利益を達成するのに必要な必要な振舞いの最小量を指定することを意図して、最小の複雑さがある可能なMIB実装と非常に多くの構成と低い「エントリーの費用」をカバーするために、それはいます。
This section discusses several typical usage scenarios.
このセクションはいくつかの典型的な用法シナリオについて論じます。
1) Subagents implement separate MIB modules -- for example, subagent
`A' implements "mib-2", subagent `B' implements "host-resources".
1) 副代理店は別々のMIBモジュールを実装します--例えば、「何mib-2インチも、副代理店'B'は「ホストリソース」を実装する」副代理店'A'道具。
It is anticipated that this will be the most common subagent
configuration.
これが最も一般的な副代理店構成になると予期されます。
2) Subagents implement rows in a "simple table". A simple table is
one in which row creation is not specified, and for which the MIB
does not define an object that counts entries in the table.
Examples of simple tables are rdbmsDbTable, udpTable, and
hrSWRunTable.
2) 副代理店は「単純分類表」の行を実装します。 単純分類表はテーブルの行作成が指定されないで、またMIBがエントリーを数えるオブジェクトを定義しないものです。 単純分類表に関する例は、rdbmsDbTableと、udpTableと、hrSWRunTableです。
This is the most commonly defined type of MIB table, and probably
represents the next most typical configuration that AgentX would
support.
これは、最も一般的に定義されたタイプのMIBテーブルであり、たぶん、次のAgentXがサポートする中で最も典型的な構成を表します。
Daniele, et al. Standards Track [Page 8] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[8ページ]。
3) Subagents share MIBs along non-row partitions. Subagents register
"chunks" of the MIB that represent multiple rows, due to the
nature of the MIB's index structure. Examples include registering
ipNetToMediaEntry.n, where n represents the ifIndex value for an
interface implemented by the subagent, and tcpConnEntry.a.b.c.d,
where a.b.c.d represents an IP address on an interface implemented
by the subagent.
3) 副代理店は非行パーティションに沿ってMIBsを共有します。 副代理店はMIBのインデックス構造の本質のため複数の行を表すMIBの「塊」を登録します。 例は、ipNetToMediaEntry.n、およびtcpConnEntry.a.b.c.dを登録するのを含んでいます。そこでは、nが副代理店によって実装されたインタフェースにifIndex値を表します。(そこでは、a.b.c.dは副代理店によって実装されたインタフェースに関するIPアドレスを表します)。
AgentX supports these three common configurations, and all permutations of them, completely. The consensus is that they comprise a very large majority of current and likely future uses of multi-vendor extensible agent configurations.
AgentXは、これらが3つの一般的な構成と、それらの全順列であると完全にサポートします。 コンセンサスは彼らがマルチベンダの広げることができるエージェント構成の現在の、そして、ありそうな将来の用途の非常に大きい大部分を包括するということです。
4) Subagents implement rows in tables that permit row creation, for
example, the RMON historyControlTable. To implement row creation
in such tables, at least one AgentX subagent must register at a
point "higher" in the OID tree than an individual row (per
AgentX's dispatching procedure).
4) 副代理店はテーブルの例えば行作成を可能にする行にRMON historyControlTableを実装します。 そのようなテーブルで行作成を実装するために、少なくとも1つのAgentX副代理店がOIDでポイント「個々の行(AgentXの急ぎ手順あたりの)より高い」木に登録されなければなりません。
5) Subagents implement rows in tables whose MIB also defines an
object that counts entries in the table, for example the MIB-2
ifTable (due to ifNumber). The subagent that implements such a
counter object (like ifNumber) must go beyond AgentX to correctly
implement it. This is an implementation issue (and most new MIB
designs no longer include such objects).
5) 副代理店はまたMIBがテーブルでエントリーを数えるオブジェクトを定義するテーブルの行を実装します、例えば、MIB-2 ifTable(ifNumberのため)。 そのようなカウンタオブジェクト(ifNumberのような)を実装する副代理店は、正しくそれを実装するためにAgentXを越えなければなりません。 これは導入問題(ほとんどの新しいMIBデザインはもうそのようなオブジェクトを含んでいない)です。
Scenarios in these latter 2 categories were thought to occur somewhat rarely in configurations where subagents are independently implemented by different vendors. The focus of a standard protocol, however, must be in just those areas where multi-vendor interoperability must be assured.
副代理店が異なったベンダーによって独自に実装されるところにこれらの後者の2つのカテゴリにおけるシナリオが構成でいくらかめったに起こらないと考えられました。 しかしながら、標準プロトコルの焦点がまさしくマルチベンダ相互運用性を保証しなければならないそれらの領域にあるに違いありません。
Note that it would be inefficient (due to AgentX registration overhead) to share a table among AgentX subagents if the table contains very dynamic instances, and each subagent registers fully qualified instances. ipRouteTable could be an example of such a table in some environments.
テーブルが非常にダイナミックなインスタンスを含むなら、AgentX副代理店の中に同席するのが効率が悪いことに(AgentX登録オーバーヘッドによる)注意してください。そうすれば、各副代理店は完全に適切なインスタンスを登録します。ipRouteTableはいくつかの環境におけるそのようなテーブルに関する例であるかもしれません。
4.3. Design Features of AgentX
4.3. AgentXに関する設計上の特徴
The primary features of the design described in this memo are:
このメモで説明されたデザインのプライマリ特徴は以下の通りです。
1) A general architectural division of labor between master agent and
subagent: The master agent is MIB ignorant and SNMP omniscient,
while the subagent is SNMP ignorant and MIB omniscient (for the
MIB variables it instantiates). That is, master agents,
exclusively, are concerned with SNMP protocol operations and the
translations to and from AgentX protocol operations needed to
1) マスターエージェントと副代理店の間の一般的な建築分業: マスターエージェントは、MIB無知であって、SNMP全知です、副代理店は、SNMP無知であって、MIB全知ですが(それが例示するMIB変数のための)。 プロトコル操作が、必要だったことをSNMPプロトコル操作とAgentXとAgentXからの翻訳にすなわち、マスターエージェントを排他的に心配させます。
Daniele, et al. Standards Track [Page 9] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[9ページ]。
carry them out; subagents are exclusively concerned with
management instrumentation; and neither should intrude on the
other's territory.
それらを行ってください。 副代理店は排他的に管理計装に関係があります。 そして、もう片方の領土にどちらも立ち入るべきではありません。
2) A standard protocol and "rules of engagement" to enable
interoperability between management instrumentation and extensible
agents.
2) 管理計装と広げることができるエージェントの間の可能にする標準プロトコルと「交戦規則」相互運用性。
3) Mechanisms for independently developed subagents to integrate into
the extensible agent on a particular managed node in such a way
that they need not be aware of any other existing subagents.
3) 独自に開発された副代理店がそれらがいかなる他の既存の副代理店も意識している必要はないような方法で特定の管理されたノードの上の広げることができるエージェントと統合するメカニズム。
4) A simple, deterministic registry and dispatching algorithm. For a
given extensible agent configuration, there is a single subagent
who is "authoritative" for any particular region of the MIB (where
"region" may extend from an entire MIB down to a single object-
instance).
4) 簡単で、決定論的な登録と急ぎアルゴリズム。 与えられた広げることができるエージェント構成のために、ただ一つのそうする副代理店がMIB(「領域」が全体のMIBからただ一つのオブジェクトインスタンスまで広がるかもしれないところ)のどんな特定の領域にも「正式」の状態であります。
5) Performance considerations. It is likely that the master agent
and all subagents will reside on the same host, and in such cases
AgentX is more a form of inter-process communication than a
traditional communications protocol.
5) パフォーマンス問題。 マスターエージェントとすべての副代理店が同じホストの上にありそうであって、そのような場合AgentXは伝統的な通信規約より相互プロセスコミュニケーションのフォームです。
Some of the design decisions made with this in mind include:
念頭でこれでされたデザイン決定のいくつかは:
- 32-bit alignment of data within PDUs
- PDUsの中のデータの32ビットの整列
- Native byte-order encoding by subagents
- 副代理店によるネイティブのバイトオーダーコード化
- Large AgentX PDU payload sizes.
- 大きいAgentX PDUペイロードサイズ。
4.4. Non-Goals
4.4. 非目標
1) Subagent-to-subagent communication. This is out of scope, due to
the security ramifications and complexity involved.
1) 副代理店から副代理店へのコミュニケーション。 範囲の外にこれは分岐と複雑さが伴ったセキュリティのためにあります。
2) Subagent access (via the master agent) to MIB variables. This is
not addressed, since various other mechanisms are available and it
was not a fundamental requirement.
2) MIB変数への副代理店アクセス(マスターエージェントを通した)。 他の様々なメカニズムが利用可能であるので、これは扱われません、そして、それは基本的な要件ではありませんでした。
3) The ability to accommodate every conceivable extensible agent
configuration option. This was the most contentious aspect in the
development of this protocol. In essence, certain features
currently available in some commercial extensible agent products
are not included in AgentX. Although useful or even vital in some
implementation strategies, the rough consensus was that these
features were not appropriate for an Internet Standard, or not
3) 想像できるあらゆる広げることができるエージェント設定オプションに対応する能力。 これはこのプロトコルの開発で最も議論好きな局面でした。 本質では、現在いくつかの商業広げることができるエージェント製品の中に利用可能なある特徴はAgentXに含まれていません。 役に立つか、またはいくつかの実装戦略で重大でさえありますが、荒いコンセンサスはインターネットStandardには、これらの特徴が適切でなかったということでした。
Daniele, et al. Standards Track [Page 10] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[10ページ]。
typically required for independently developed subagents to
coexist. The set of supported extensible agent configurations is
described above, in Section 4.2, "Applicability".
独自に開発された副代理店が共存するのが通常必要です。 サポートしている広げることができるエージェント構成のセットはセクション4.2の「適用性」を超えて説明されます。
Some possible future version of the AgentX protocol may provide coverage for one or more of these "non-goals" or for new goals that might be identified after greater deployment experience.
AgentXプロトコルの何らかの可能な将来のバージョンがこれらの「非目標」の1つ以上か、より大きい展開経験の後に特定されるかもしれない新しい目標に適用範囲を提供するかもしれません。
5. AgentX Encodings
5. AgentX Encodings
AgentX PDUs consist of a common header, followed by PDU-specific data of variable length. Unlike SNMP PDUs, AgentX PDUs are not encoded using the BER (as specified in ISO 8824 [18]), but are transmitted as a contiguous byte stream. The data within this stream is organized to provide natural alignment with respect to the start of the PDU, permitting direct (integer) access by the processing entities.
AgentX PDUsは可変長のPDU特有のデータがあとに続いた一般的なヘッダーから成ります。 SNMP PDUsと異なって、AgentX PDUsは、BERを使用することでコード化されません。(ISO8824[18])で指定しますが、隣接のバイト・ストリームとして伝えられるように。 このストリームの中のデータがPDUの始まりに関して自然な整列を提供するのが組織化されます、処理実体でダイレクト(整数)アクセスを可能にして。
The first four fields in the header are single-byte values. A bit (NETWORK_BYTE_ORDER) in the third field (h.flags) is used to indicate the byte ordering of all multi-byte integer values in the PDU, including those which follow in the header itself. This is described in more detail in Section 6.1, "AgentX PDU Header", below.
ヘッダーの最初の4つの分野が単一のバイト値です。 少し、(NETWORK_BYTE_ORDER)はPDUのすべてのマルチバイト整数値のバイト順を示すのに3番目の分野(h.旗)で使用されます、ヘッダー自体で続くものを含んでいて。 これはさらに詳細にセクション6.1、以下の「AgentX PDUヘッダー」で説明されます。
PDUs are depicted in this memo using the following convention (where byte 1 is the first transmitted byte):
PDUsはこのメモに以下のコンベンション(バイト1が最初の伝えられたバイトであるところ)を使用することで表現されます:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | byte 1 | byte 2 | byte 3 | byte 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | byte 5 | byte 6 | byte 7 | byte 8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バイト1| バイト2| バイト3| バイト4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バイト5| バイト6| バイト7| バイト8| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields marked "<reserved>" are reserved for future use and must be zero-filled.
「<は>を予約しました」であることが示される分野は、今後の使用のために予約されて、無いっぱいにしなければなりません。
5.1. Object Identifier
5.1. オブジェクト識別子
An object identifier is encoded as a 4-byte header, followed by a variable number of contiguous 4-byte fields representing sub- identifiers. This representation (termed Object Identifier) is as follows:
オブジェクト識別子はサブ識別子を表す可変数の隣接の4バイトの分野があとに続いた4バイトのヘッダーとしてコード化されます。 この表現(Object Identifierと呼ばれる)は以下の通りです:
Daniele, et al. Standards Track [Page 11] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[11ページ]。
Object Identifier
オブジェクト識別子
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | include | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Identifier header fields:
オブジェクトIdentifierヘッダーフィールド:
n_subid
n_subid
The number (0-128) of sub-identifiers in the object identifier.
An ordered list of "n_subid" 4-byte sub-identifiers follows the
4-byte header.
オブジェクト識別子のサブ識別子の数(0-128)。 「n_subid」4バイトのサブ識別子の規則正しいリストは4バイトのヘッダーに続きます。
prefix
接頭語
An unsigned value used to reduce the length of object
identifier encodings. A non-zero value "x" is interpreted as
the first sub-identifier after "internet" (1.3.6.1), and
indicates an implicit prefix "internet.x" to the actual sub-
identifiers encoded in the Object Identifier. For example, a
prefix field value 2 indicates an implicit prefix "1.3.6.1.2".
A value of 0 in the prefix field indicates there is no prefix
to the sub-identifiers.
未署名の値は以前はオブジェクト識別子encodingsの長さをよく減少させていました。 非ゼロ値「x」が「インターネット」の後に最初のサブ識別子として解釈される、(1.3、.6、.1)、暗黙の接頭語"internet.x"をObject Identifierでコード化された実際のサブ識別子に示します。 例えば、接頭語分野価値2が暗黙の接頭語を示す、「1.3 .6 .1 0.2インチ」 接頭語分野の0の値は、サブ識別子への接頭語が全くないのを示します。
include
インクルード
Used only when the Object Identifier is the start of a
SearchRange, as described in section 5.2, "SearchRange".
Object IdentifierがSearchRangeセクション5.2で説明されるような"SearchRange"の始まりであるときにだけ、使用されます。
sub-identifier 1, 2, ... n_subid
サブ識別子1、2… n_subid
A 4-byte unsigned integer, encoded according to the header's
NETWORK_BYTE_ORDER bit.
_ヘッダーのNETWORKによると、コード化された4バイトの符号のない整数に、BYTE_ORDERは噛み付きました。
A null Object Identifier consists of the 4-byte header with all bytes set to 0.
ヌルObject Identifierは0に設定されたすべてのバイトで4バイトのヘッダーから成ります。
Daniele, et al. Standards Track [Page 12] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[12ページ]。
Examples:
例:
sysDescr.0 (1.3.6.1.2.1.1.1.0)
sysDescr.0(1.3.6.1.2.1.1.1.0)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.2.3.4
1.2.3.4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 0 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.2. SearchRange
5.2. SearchRange
A SearchRange consists of two Object Identifiers. In its communication with a subagent, the master agent uses a SearchRange to identify a requested variable binding, and, in GetNext and GetBulk operations, to set an upper bound on the names of managed object instances the subagent may send in reply.
SearchRangeは2Object Identifiersから成ります。 副代理店とのコミュニケーションでは、マスターエージェントは、そして、GetNextとGetBulk操作で要求された変項束縛を特定して、副代理店が回答で送るかもしれない管理オブジェクトインスタンスの名前に上限をけしかけるのにSearchRangeを使用します。
The first Object Identifier in a SearchRange (called the starting OID) indicates the beginning of the range. It is frequently (but not necessarily) the name of a requested variable binding.
SearchRange(始めのOIDと呼ばれる)における最初のObject Identifierは範囲の始まりを示します。 (必ずない)頻繁にそれは要求された変項束縛の名前です。
The "include" field in this OID's header is a boolean value (0 or 1) indicating whether or not the starting OID is included in the range.
このOIDのヘッダーの「包含」分野は始めのOIDが範囲に含まれているかどうかを示すブール値(0か1)です。
The second object identifier (ending OID) indicates the non-inclusive end of the range, and its "include" field is always 0. A null value for ending OID indicates an unbounded SearchRange.
第二目的語識別子(終わりのOID)は範囲の非含んでいる端を示します、そして、いつも「包含」分野は0です。 終わりのOIDのためのヌル値は限りないSearchRangeを示します。
Daniele, et al. Standards Track [Page 13] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[13ページ]。
Example: To indicate a search range from 1.3.6.1.2.1.25.2 (inclusive) to 1.3.6.1.2.1.25.2.1 (exclusive), the SearchRange would be:
例: 1.3から検索範囲を示す、.6、.1、.2、.1、.25、.2、(包括的)、1.3 .6 .1 .2 .1 .25 .2 .1 (排他的)であり、SearchRangeは以下の通りでしょう。
(start) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | 2 | 1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(始めます) +++++++++++++++++++++++++++++++++| 3 | 2 | 1 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | 2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(終わり)+++++++++++++++++++++++++++++++++| 4 | 2 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 25 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A SearchRangeList is a contiguous list of SearchRanges.
SearchRangeListはSearchRangesの隣接のリストです。
5.3. Octet String
5.3. 八重奏ストリング
An octet string is represented by a contiguous series of bytes, beginning with a 4-byte integer (encoded according to the header's NETWORK_BYTE_ORDER bit) whose value is the number of octets in the octet string, followed by the octets themselves. This representation is termed an Octet String. If the last octet does not end on a 4- byte offset from the start of the Octet String, padding bytes are appended to achieve alignment of following data. This padding must be added even if the Octet String is the last item in the PDU. Padding bytes must be zero filled.
八重奏ストリングは隣接のシリーズの何バイトも表されます、値が八重奏の八重奏自体があとに続いた八重奏ストリングの数である4バイトの整数(ヘッダーのNETWORK_BYTE_ORDERビットに従って、コード化される)で始まって。 この表現はOctet Stringと呼ばれます。 最後の八重奏がOctet Stringの始まりから相殺された4バイトで終わらないなら、次のデータの整列を達成するために詰め物バイトを追加します。 Octet StringがPDUで最後の項目であってもこの詰め物を加えなければなりません。 バイトを水増しするのは、いっぱいにされたゼロであるに違いありません。
Daniele, et al. Standards Track [Page 14] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[14ページ]。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A null Octet String consists of a 4-byte length field set to 0.
ヌルOctet Stringは0に4バイトの長さの分野セットから成ります。
5.4. Value Representation
5.4. 値の表現
Variable bindings may be encoded within the variable-length portion of some PDUs. The representation of a variable binding (termed a VarBind) consists of a 2-byte type field, a name (Object Identifier), and the actual value data.
変項束縛はいくつかのPDUsの可変長の部分の中でコード化されるかもしれません。 変項束縛(VarBindと呼ばれる)の表現は2バイトのタイプ分野、名前(オブジェクトIdentifier)、および実価データから成ります。
VarBind
VarBind
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v.type | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v. タイプしてください。| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(v.name) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(名前に対する) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(v.data) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(データに対する) +++++++++++++++++++++++++++++++++| データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | データ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VarBind fields:
VarBind分野:
v.type
v. タイプしてください。
Indicates the variable binding's syntax, and must be one of the following values:
変項束縛の構文を示して、以下の値の1つでなければなりません:
Daniele, et al. Standards Track [Page 15] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[15ページ]。
Integer (2),
Octet String (4),
Null (5),
Object Identifier (6),
IpAddress (64),
Counter32 (65),
Gauge32 (66),
TimeTicks (67),
Opaque (68),
Counter64 (70),
noSuchObject (128),
noSuchInstance (129),
endOfMibView (130)
整数(2)、八重奏ストリング(4)、ヌル(5)、オブジェクト識別子(6)、IpAddress(64)、Counter32(65)、Gauge32(66)(TimeTicks(67))は(68)について不透明にします、Counter64(70)、noSuchObject(128)、noSuchInstance(129)、endOfMibView(130)
v.name
v.名
The Object Identifier which names the variable.
変数を命名するObject Identifier。
v.data
v. データ
The actual value, encoded as follows:
以下の通りコード化された実価:
- Integer, Counter32, Gauge32, and TimeTicks are encoded as 4
contiguous bytes, according to the header's
NETWORK_BYTE_ORDER bit.
- ヘッダーのNETWORK_BYTE_ORDERビットに従って、整数、Counter32、Gauge32、およびTimeTicksは隣接の4バイトとしてコード化されます。
- Counter64 is encoded as 8 contiguous bytes, according to
the header's NETWORK_BYTE_ORDER bit.
- ヘッダーのNETWORK_BYTE_ORDERビットに従って、Counter64は隣接の8バイトとしてコード化されます。
- Object Identifiers are encoded as described in section 5.1,
Object Identifier.
- Object Identifier、オブジェクトIdentifiersはセクション5.1で説明されるようにコード化されます。
- IpAddress, Opaque, and Octet String are all octet strings
and are encoded as described in section 5.3, "Octet
String", Octet String. Note that the octets used to
represent IpAddress are always ordered most significant to
least significant.
- IpAddress、Opaque、およびOctet Stringはセクション5.3、「八重奏ストリング」(Octet String)で説明されるように八重奏ストリングであり、コード化されます。 IpAddressを表すのに使用される八重奏がいつも最も重要でなく最も重要な状態で命令されることに注意してください。
Value data always follows v.name whenever v.type is one of
the above types. These data bytes are present even if they
will not be used (as, for example, in certain types of
index allocation).
値のデータはいつも名前に対してv.タイプが上のタイプのひとりであるときはいつも、従います。 それらが使用されないでも(例えばあるタイプのインデックス配分のように)、これらのデータ・バイトは存在しています。
- Null, noSuchObject, noSuchInstance, and endOfMibView do not
contain any encoded value. Value data never follows v.name
in these cases.
- ヌル、noSuchObject、noSuchInstance、およびendOfMibViewは少しのコード化された値も含んでいません。 値のデータはこれらの場合における名前に対して決して従いません。
Daniele, et al. Standards Track [Page 16] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[16ページ]。
Note that the VarBind itself does not contain the value size.
That information is implied for the fixed-length types, and
explicitly contained in the encodings of variable-length types
Object Identifier and Octet String).
VarBind自身が値のサイズを含まないことに注意してください。 情報は、固定長タイプのために含意されて、可変長のタイプのObject IdentifierとOctet Stringのencodingsに明らかに含まれています)
A VarBindList is a contiguous list of VarBinds. Within a VarBindList, a particular VarBind is identified by an index value. The first VarBind in a VarBindList has index value 1, the second has index value 2, and so on.
VarBindListはVarBindsの隣接のリストです。 VarBindListの中では、特定のVarBindはインデックス値によって特定されます。 VarBindListにおける最初のVarBindには、インデックス値1があって、2番目にインデックス値2などがあります。
6. Protocol Definitions
6. プロトコル定義
6.1. AgentX PDU Header
6.1. AgentX PDUヘッダー
The AgentX PDU header is a fixed-format, 20-octet structure:
AgentX PDUヘッダーは固定形式の、そして、20八重奏の構造です:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version | h.type | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. バージョン| h. タイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An AgentX PDU header contains the following fields:
AgentX PDUヘッダーは以下の分野を含んでいます:
h.version
h. バージョン
The version of the AgentX protocol (1 for this memo).
AgentXプロトコル(このメモのための1)のバージョン。
h.type
h. タイプしてください。
The PDU type; one of the following values:
PDUはタイプします。 以下の値の1つ:
agentx-Open-PDU (1),
agentx-Close-PDU (2),
agentx-Register-PDU (3),
agentx-Unregister-PDU (4),
agentx-Get-PDU (5),
agentx-GetNext-PDU (6),
agentx-GetBulk-PDU (7),
agentx-TestSet-PDU (8),
agentx-CommitSet-PDU (9),
agentx-UndoSet-PDU (10),
agentxの開いているPDU(1)、agentxの近いPDU(2)、agentxレジスタPDU(3)、agentx-Unregister-PDU(4)、agentxがPDUを手に入れている(5)、agentx-GetNext-PDU(6)、agentx-GetBulk-PDU(7)、agentx-TestSet-PDU(8)、agentx-CommitSet-PDU(9)、agentx-UndoSet-PDU(10)
Daniele, et al. Standards Track [Page 17] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[17ページ]。
agentx-CleanupSet-PDU (11),
agentx-Notify-PDU (12),
agentx-Ping-PDU (13),
agentx-IndexAllocate-PDU (14),
agentx-IndexDeallocate-PDU (15),
agentx-AddAgentCaps-PDU (16),
agentx-RemoveAgentCaps-PDU (17),
agentx-Response-PDU (18)
agentx-CleanupSet-PDU(11)、agentxがPDUに通知している(12)、agentxピングPDU(13)、agentx-IndexAllocate-PDU(14)、agentx-IndexDeallocate-PDU(15)、agentx-AddAgentCaps-PDU(16)、agentx-RemoveAgentCaps-PDU(17)、agentx応答PDU(18)
The set of PDU types for "administrative processing" are 1-4
and 12-17. The set of PDU types for "SNMP request
processing" are 5-11.
「管理処理」のためのPDUタイプのセットは、1-4と12-17です。 「SNMPは処理を要求する」PDUタイプのセットが5-11です。
h.flags
h. 旗
A bitmask, with bit 0 the least significant bit. The bit
definitions are as follows:
ビット0があるビットマスク、最下位ビット。 噛み付いている定義は以下の通りです:
Bit Definition
--- ----------
0 INSTANCE_REGISTRATION
1 NEW_INDEX
2 ANY_INDEX
3 NON_DEFAULT_CONTEXT
4 NETWORK_BYTE_ORDER
5-7 (reserved)
噛み付いている定義--- ---------- 0 どんな_インデックス3非_のデフォルト_文脈4ネットワーク_バイト_も5-7に注文するインスタンス_登録1の新しい_インデックス2(予約される)です。
The NETWORK_BYTE_ORDER bit applies to all multi-byte integer
values in the entire AgentX packet, including the remaining
header fields. If set, then network byte order (most
significant byte first; "big endian") is used. If not set,
then least significant byte first ("little endian") is used.
NETWORK_BYTE_ORDERビットは残っているヘッダーフィールドを含む全体のAgentXパケットのすべてのマルチバイト整数値に適用されます。 設定されるならバイトオーダーをネットワークでつないでください、(最も重要なバイト、1番目; 「ビッグエンディアン」) 使用されます。 設定されないなら、最も重要でないバイトは最初に、使用されています(「リトルエンディアン」)。
The NETWORK_BYTE_ORDER bit applies to all AgentX PDUs.
NETWORK_BYTE_ORDERビットはすべてのAgentX PDUsに適用されます。
The NON_DEFAULT_CONTEXT bit is used only in the AgentX PDUs
described in section 6.1.1, "Context".
NON_DEFAULT_CONTEXTビットはセクション6.1.1、「文脈」で説明されたAgentX PDUsだけで使用されます。
The NEW_INDEX and ANY_INDEX bits are used only within the
agentx-IndexAllocate-, and -IndexDeallocate-PDUs.
NEW_INDEXとどんな_INDEXビットもagentx-IndexAllocate、および-IndexDeallocate-PDUsだけの中で使用されます。
The INSTANCE_REGISTRATION bit is used only within the
agentx-Register-PDU.
INSTANCE_REGISTRATIONビットはagentxレジスタPDUだけの中で使用されます。
Daniele, et al. Standards Track [Page 18] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[18ページ]。
h.sessionID
h. sessionID
The session ID uniquely identifies a session over which
AgentX PDUs are exchanged between a subagent and the master
agent. The session ID has no significance and no defined
value in the agentx-Open-PDU sent by a subagent to open a
session with the master agent; in this case, the master
agent will assign a unique session ID that it will pass back
in the corresponding agentx-Response-PDU. From that point
on, that same session ID will appear in every AgentX PDU
exchanged over that session between the master and the
subagent. A subagent may establish multiple AgentX sessions
by sending multiple agentx-Open-PDUs to the master agent.
セッションIDは唯一、AgentX PDUsが副代理店とマスターエージェントの間で交換されるセッションを特定します。 セッションIDは副代理店によって送られた、マスターエージェントと共に開会したagentxの開いているPDUに意味がなくて定義された値を全く持っていません。 この場合、マスターエージェントはそれが対応するagentx応答PDUで戻すIDをユニークなセッションに割り当てるでしょう。 そのポイントから、その同じセッションIDはマスターと副代理店とのそのセッションの間に交換されたあらゆるAgentX PDUに現れるでしょう。 副代理店は、複数のagentxの開いているPDUsをマスターエージェントに送ることによって、複数のAgentXセッションを確立するかもしれません。
In master agents that support multiple transport protocols,
the sessionID should be globally unique rather than unique
just to a particular transport.
複数の輸送がプロトコルであるとサポートするマスターエージェントでは、まさしく特定の輸送にユニークであるというよりむしろsessionIDはグローバルにユニークであるべきです。
h.transactionID
h. transactionID
The transaction ID uniquely identifies, for a given session,
the single SNMP management request (and single SNMP PDU)
with which an AgentX PDU is associated. If a single SNMP
management request results in multiple AgentX PDUs being
sent by the master agent with the same session ID, each of
these AgentX PDUs must contain the same transaction ID;
conversely, AgentX PDUs sent during a particular session,
that result from distinct SNMP management requests, must
have distinct transaction IDs within the limits of the 32-
bit field).
トランザクションIDは与えられたセッションのために、唯一、AgentX PDUが関連しているただ一つのSNMP管理要求(SNMP PDUを選抜する)を特定します。 ただ一つのSNMP経営者側がマスターエージェントによって送られる複数のAgentX PDUsで同じセッションIDで結果を要求するなら、それぞれのこれらのAgentX PDUsは同じトランザクションIDを含まなければなりません。 逆に、AgentX PDUsは特定のセッションの間、発信して、異なったSNMP管理要求、必須からの結果は32の噛み付いている分野の限界の中に異なったトランザクションIDを持っています)
Note that the transaction ID is not the same as the SNMP
PDU's request-id (as described in section 4.1 of RFC 1905
[13], nor is it the same as the SNMP Message's msgID (as
described in section 6.2 of RFC 2572 [11]), nor can it be,
since a master agent might receive SNMP requests with the
same request-ids or msgIDs from different managers.
中で説明されるように4.1RFC1905[13]を区分してください、そして、それはSNMP MessageのmsgIDと同じではありません。トランザクションIDがSNMP PDUの要求イドと同じでないことに注意してください、((説明されるように、または、マスターエージェントが異なったマネージャから同じ要求イドかmsgIDsとのSNMP要求を受け取るかもしれないので、セクション6.2のRFC2572[11])にあるはずがありません。
The transaction ID has no significance and no defined value
in AgentX administrative PDUs, i.e., AgentX PDUs that are
not associated with an SNMP management request.
トランザクションIDはAgentXの管理PDUs(すなわち、SNMP管理要求に関連づけられないAgentX PDUs)に意味がなくて定義された値を全く持っていません。
h.packetID
h. packetID
A packet ID generated by the sender for all AgentX PDUs
except the agentx-Response-PDU. In an agentx-Response-PDU,
the packet ID must be the same as that in the received
AgentX PDU to which it is a response. A master agent might
IDがagentx応答PDU以外のすべてのAgentX PDUsのために送付者で生成したパケット。 agentx応答PDUでは、パケットIDはそれが応答である容認されたAgentX PDUのそれと同じであるに違いありません。 マスターエージェントはそうするかもしれません。
Daniele, et al. Standards Track [Page 19] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[19ページ]。
use this field to associate subagent response PDUs with
their corresponding request PDUs. A subagent might use this
field to correlate responses to multiple (batched)
registrations.
この分野を使用して、彼らの対応する要求PDUsに副代理店応答PDUsを関連づけてください。 副代理店は、複数の(batchedしました)登録証明書への応答を関連させるのにこの分野を使用するかもしれません。
h.payload_length
h. ペイロード_長さ
The size in octets of the PDU contents, excluding the 20-
byte header. As a result of the encoding schemes and PDU
layouts, this value will always be either 0, or a multiple
of 4.
20バイトヘッダーを除いたPDUコンテンツの八重奏におけるサイズ。 コード化体系とPDUレイアウトの結果、この値は、いつも4の0か倍数のどちらかになるでしょう。
6.1.1. Context
6.1.1. 文脈
In the SNMPv1 or SNMPv2c, the community string may be used as an index into a local repository of configuration information that may include community profiles or more complex context information. In SNMPv3 this notion of "context" is formalized (see section 3.3.1 in RFC 2571 [1].
SNMPv1かSNMPv2cでは、共同体ストリングはインデックスとして共同体プロフィールを含むかもしれない設定情報か、より複雑な文脈情報の地方の倉庫に使用されるかもしれません。 SNMPv3の「文脈」のこの概念は正式にされます。(RFC2571[1]でセクション3.3.1を見てください。
AgentX provides a mechanism for transmitting a context specification within relevant PDUs, but does not place any constraints on the content of that specification.
AgentXは関連PDUsの中で文脈仕様を伝えるのにメカニズムを提供しますが、その仕様の内容に少しの規制も置きません。
An optional context field may be present in the agentx-Register-, UnRegister-, AddAgentCaps-, RemoveAgentCaps-, Get-, GetNext-, GetBulk-, IndexAllocate-, IndexDeallocate-, Notify-, TestSet-, and Ping- PDUs.
任意の文脈分野がagentx-レジスタに存在しているかもしれない、-、UnRegister、AddAgentCaps、RemoveAgentCaps、Get、GetNext、GetBulk、IndexAllocate、IndexDeallocate、Notify、TestSet、およびPing- PDUs。
If the NON_DEFAULT_CONTEXT bit in the AgentX header field h.flags is clear, then there is no context field in the PDU, and the operation refers to the default context. (This does not mean there is a zero- length Octet String, it means there is no Octet String present.) If the NON_DEFAULT_CONTEXT bit is set, then a context field immediately follows the AgentX header, and the operation refers to that specific context. The context is represented as an Octet String. There are no constraints on its length or contents.
AgentXヘッダーフィールドh.旗によるNON_DEFAULT_CONTEXTビットが明確であるなら、文脈分野が全くPDUにありません、そして、操作はデフォルト文脈を示します。 (これは、無の長さのOctet Stringがあることを意味しないで、それは、どんな存在しているOctet Stringもないことを意味します。) NON_DEFAULT_CONTEXTビットが設定されるなら、文脈分野はすぐにAgentXヘッダーに続きます、そして、操作はその特定の文脈を示します。 文脈はOctet Stringとして表されます。 規制が全くその長さかコンテンツにありません。
Thus, all of these AgentX PDUs (that is, those listed immediately above) refer to, or "indicate" a context, which is either the default context, or a non-default context explicitly named in the PDU.
したがって、これらのAgentX PDUs(すなわち、すぐに上に記載されたもの)のすべてが、文脈を示すか、または「示します」。(それは、PDUで明らかに指定されたデフォルト文脈か非デフォルト文脈のどちらかです)。
6.2. AgentX PDUs
6.2. AgentX PDUs
6.2.1. The agentx-Open-PDU
6.2.1. agentxの開いているPDU
An agentx-Open-PDU is generated by a subagent to request establishment of an AgentX session with the master agent.
agentxの開いているPDUは副代理店によって生成されて、マスターエージェントとのAgentXセッションの設立を要求します。
Daniele, et al. Standards Track [Page 20] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[20ページ]。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (1) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (1)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o.timeout | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o.timeout| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.id)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subidentifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subidentifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.イド) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「副-識別子」#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 「副-識別子」#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.descr)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.descr) +++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Open-PDU contains the following fields:
agentxの開いているPDUは以下の分野を含んでいます:
o.timeout
o.timeout
The length of time, in seconds, that a master agent should
allow to elapse after dispatching a message on a session
before it regards the subagent as not responding. This is
the default value for the session, and may be overridden by
秒のマスターエージェントがそれの前にセッションに送信した後に経過するのを許すべきである時間の長さは、副代理店が応じていないとみなします。 これは、セッションのためのデフォルト値であり、くつがえされるかもしれません。
Daniele, et al. Standards Track [Page 21] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[21ページ]。
values associated with specific registered MIB regions. The
default value of 0 indicates that there is no session-wide
default value.
特定に関連している値はMIB領域を登録しました。 0のデフォルト値は、どんなセッション全体のデフォルト値もないのを示します。
o.id
o.id
An Object Identifier that identifies the subagent.
Subagents that do not support such an notion may send a null
Object Identifier.
副代理店を特定するObject Identifier。 そのような概念を支持しない副代理店はヌルObject Identifierを送るかもしれません。
o.descr
o.descr
An Octet String containing a DisplayString describing the
subagent.
副代理店について説明するDisplayStringを含むOctet String。
6.2.2. The agentx-Close-PDU
6.2.2. agentxの近いPDU
An agentx-Close-PDU issued by either a subagent or the master agent terminates an AgentX session.
副代理店かマスターエージェントのどちらかによって発行されたagentxの近いPDUはAgentXセッションを終えます。
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (2) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (2)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c.reason | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c. 理由| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Close-PDU contains the following field:
agentxの近いPDUは以下の分野を含んでいます:
c.reason
c. 理由
An enumerated value that gives the reason that the master
agent or subagent closed the AgentX session. This field may
take one of the following values:
マスターエージェントか副代理店がAgentXセッションを終えた理由をあげる列挙された値。 この分野は以下の値の1つを取るかもしれません:
Daniele, et al. Standards Track [Page 22] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[22ページ]。
reasonOther(1)
None of the following reasons
以下のいずれも推論しないreasonOther(1)
reasonParseError(2)
Too many AgentX parse errors from peer
reasonParseError(2)、多く過ぎるAgentXは同輩から誤りを分析します。
reasonProtocolError(3)
Too many AgentX protocol errors from peer
reasonProtocolError(3)、多く過ぎるAgentXは同輩から誤りについて議定書の中で述べます。
reasonTimeouts(4)
Too many timeouts waiting for peer
reasonTimeouts(4)、同輩を待つあまりに多くのタイムアウト
reasonShutdown(5)
Sending entity is shutting down
reasonShutdown(5)送付実体は停止しています。
reasonByManager(6)
Due to Set operation; this reason code can be used only
by the master agent, in response to an SNMP management
request.
Set操作へのreasonByManager(6)Due。 単にマスターエージェントはSNMP管理要求に対応してこの理由コードを使用できます。
6.2.3. The agentx-Register-PDU
6.2.3. agentxレジスタPDU
An agentx-Register-PDU is generated by a subagent for each region of the MIB variable naming tree (within one or more contexts) that it wishes to support.
agentxレジスタPDUは副代理店でそれが支持したがっているMIBの可変命名木(1つ以上の文脈の中の)の各領域に発生します。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (3) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (3)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 23] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[23ページ]。
(r.context) (OPTIONAL)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.文脈) (任意)の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r.timeout | r.priority | r.range_subid | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r. タイムアウト| r. 優先権| r. 範囲_subid| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.subtree)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.下位木) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.upper_bound)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional upper-bound sub-identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.の上側の_は固まりました) +++++++++++++++++++++++++++++++++| 任意の上限サブ識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Register-PDU contains the following fields:
agentxレジスタPDUは以下の分野を含んでいます:
r.context
r. 文脈
An optional non-default context.
任意の非デフォルト文脈。
r.timeout
r. タイムアウト
The length of time, in seconds, that a master agent should
allow to elapse after dispatching a message on a session
before it regards the subagent as not responding. r.timeout
applies only to messages that concern MIB objects within
r.subtree. It overrides both the session's default value
(if any) indicated when the AgentX session with the master
agent was established, and the master agent's default
timeout. The default value for r.timeout is 0 (no
override).
秒のマスターエージェントがそれの前にセッションに送信した後に経過するのを許すべきである時間の長さは、副代理店が応じていないとみなします。r.タイムアウトは関心MIBがr.下位木の中で反対するというメッセージだけに適用されます。 それはマスターエージェントとのAgentXセッションが確立されたとき(もしあれば)の値が示したセッションのデフォルトとマスターエージェントのデフォルトタイムアウトの両方をくつがえします。 r.タイムアウトのためのデフォルト値は0(オーバーライドがない)です。
Daniele, et al. Standards Track [Page 24] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[24ページ]。
r.priority
r. 優先権
A value between 1 and 255, used to achieve a desired
configuration when different sessions register identical or
overlapping regions. Subagents with no particular knowledge
of priority should register with the default value of 127.
1と255の間の異なったセッションが同じ状態で登録されるとき、必要な構成を達成するのに使用されるか、または領域を重ね合わせる値。 優先権に関する特定の知識のない副代理店は127のデフォルト値とともに記名するべきです。
In the master agent's dispatching algorithm, smaller values
of r.priority take precedence over larger values, as
described in section 7.1.4.1, "Handling Duplicate and
Overlapping Subtrees".
マスターエージェントの急ぎアルゴリズムで、r.優先権の、より小さい値は、より大きい値の上で優先します、セクション7.1.4.1と、「取り扱い写しと重なっている下位木」で説明されるように。
r.subtree
r. 下位木
An Object Identifier that names the basic subtree of a MIB
region for which a subagent indicates its support. The term
"subtree" is used generically here, it may represent a
fully-qualified instance name, a partial instance name, a
MIB table, an entire MIB, etc.
副代理店がサポートを示すMIB領域の基本的な下位木を命名するObject Identifier。 「下位木」という用語はここで一般的に使用されて、それは完全に適切な例の名、部分的な例の名、MIBテーブル、全体のMIBなどを表すかもしれません。
The choice of what to register is implementation-specific;
this memo does not specify permissible values. Standard
practice however is for a subagent to register at the
highest level of the naming tree that makes sense.
Registration of fully- qualified instances is typically done
only when a subagent can perform management operations only
on particular rows of a conceptual table.
登録するべきことの選択は実現特有です。 このメモは許容値を指定しません。 しかしながら、標準的技法は理解できる命名木の最高水準で登録する副代理店のためのものです。 副代理店が概念的なテーブルの特定の列だけに管理操作を実行できるときだけ、通常完全に適切な例の登録をします。
If r.subtree is in fact a fully qualified instance name, the
INSTANCE_REGISTRATION bit in h.flags must be set, otherwise
it must be cleared. The master agent may save this
information to optimize subsequent operational dispatching.
事実上、r.下位木が完全に適切な例の名であるなら、h.旗によるINSTANCE_REGISTRATIONビットを設定しなければなりません。さもなければ、それは晴れなければなりません。 マスターエージェントは、その後の操作上の急ぎを最適化するためにこの情報を保存するかもしれません。
r.range_subid
r. 範囲_subid
Permits specifying a range in place of one of r.subtree's
sub-identifiers. If this value is 0, no range is being
specified and there is no r.upper_bound field present in the
PDU. In this case the MIB region being registered is the
single subtree named by r.subtree.
r.下位木のサブ識別子の1つに代わって範囲を指定する許可証。 この値が0であるなら、範囲は全く指定されていません、そして、PDUの現在のどんな_のr.上側のバウンド分野もありません。 この場合、登録されるMIB領域はr.下位木によって指定されたただ一つの下位木です。
Otherwise the "r.range_subid"-th sub-identifier in r.subtree
is a range lower bound, and the range upper bound sub-
identifier (r.upper_bound) immediately follows r.subtree.
In this case the MIB region being registered is the union of
the subtrees formed by enumerating this range.
そうでなければ、「r.範囲_subid」、-、中のサブ識別子r.下位木は範囲下界であり、範囲上限サブ識別子(r.の上側の_は固まった)はすぐに、r.下位木に第従います。 この場合、登録されるMIB領域はこの範囲を列挙することによって形成された下位木の組合です。
Daniele, et al. Standards Track [Page 25] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[25ページ]。
Note that r.range_subid indicates the (1-based) index of
this sub-identifier within the OID represented by r.subtree,
regardless of whether or not r.subtree is encoded using a
prefix. (See the example below.)
r.下位木が接頭語を使用することでコード化されるかどうかにかかわらずr.範囲_subidがr.下位木によって表されたOIDの中にこのサブ識別子の(1ベース)のインデックスを示すことに注意してください。 (以下の例を見てください。)
r.upper_bound
r. 上側の_は固まりました。
The upper bound of a sub-identifier's range. This field is
present only if r.range_subid is not 0.
サブ識別子の範囲の上限。 この分野はr.範囲_subidが0でない場合にだけ存在しています。
The use of r.range_subid and r.upper_bound provide a general
shorthand mechanism for specifying a MIB region. For
example, if r.subtree is the OID 1.3.6.1.2.1.2.2.1.1.7,
r.range_subid is 10, and r.upper_bound is 22, the specified
MIB region can be denoted 1.3.6.1.2.1.2.2.1.[1-22].7.
Registering this region is equivalent to registering the
union of subtrees
r.範囲_subidと上側の_が縛ったr.の使用は一般的な速記メカニズムをMIB領域を指定するのに提供します。 例えば、r. 下位木であるなら、OID1.3は.6です。.1 .2 .1 .2 .2 .1 .1 .7 r. 上側の_が縛ったr.が22である、範囲_subidは10であり、指定されたMIB領域は指示された1.3.6.1.2.1.2.2.1.[1-22].7であるかもしれない。 この領域を登録するのは下位木の組合を登録するのに同等です。
1.3.6.1.2.1.2.2.1.1.7
1.3.6.1.2.1.2.2.1.2.7
1.3.6.1.2.1.2.2.1.3.7
...
1.3.6.1.2.1.2.2.1.22.7
1.3.6.1.2.1.2.2.1.1.7 1.3.6.1.2.1.2.2.1.2.7 1.3.6.1.2.1.2.2.1.3.7 ... 1.3.6.1.2.1.2.2.1.22.7
One expected use of this mechanism is registering a
conceptual row with a single PDU. In the example above, the
MIB region happens to be row 7 of the RFC 1573 ifTable. The
actual PDU would be:
あるものは、このメカニズムの使用が概念的な列を独身のPDUに示していると予想しました。 例では、MIB領域はたまたま上では、RFC1573ifTableの列7です。 実際のPDUは以下の通りでしょう。
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (3) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (3)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r.timeout | r.priority | 10 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | r. タイムアウト| r. 優先権| 10 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 26] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[26ページ]。
(r.subtree) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 6 | 2 | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.下位木) +++++++++++++++++++++++++++++++++| 6 | 2 | 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.upper_bound) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.の上側の_は固まりました) +++++++++++++++++++++++++++++++++| 22 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note again that here r.range_subid is 10, even though n_subid in r.subtree is only 6.
r.下位木におけるn_subidは6にすぎませんが、r.範囲_subidがここの、10であることにもう一度注意してください。
r.range_subid may be used at any level within a subtree, it need not represent row-level registration. This mechanism may be used in any way that is convenient for a subagent to achieve its registrations.
r. 範囲_subidは下位木の中でどんなレベルにも使用されるかもしれなくて、それは列レベル登録を表す必要はありません。 このメカニズムはどんな副代理店が登録証明書を実現するのに便利な方法でも使用されるかもしれません。
6.2.4. The agentx-Unregister-PDU
6.2.4. agentx-Unregister-PDU
The agentx-Unregister-PDU is sent by a subagent to remove a MIB region that was previously registered on this session.
副代理店でagentx-Unregister-PDUを送って、このセッションのときに以前に登録されたMIB領域を取り除きます。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (4) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (4)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 27] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[27ページ]。
(u.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <reserved> | u.priority | u.range_subid | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <は>を予約しました。| u. 優先権| u. 範囲_subid| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.subtree)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.下位木) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.upper_bound)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional upper-bound sub-identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.の上側の_は固まりました) +++++++++++++++++++++++++++++++++| 任意の上限サブ識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Unregister-PDU contains the following fields:
agentx-Unregister-PDUは以下の分野を含んでいます:
u.context
u. 文脈
An optional non-default context.
任意の非デフォルト文脈。
u.priority
u. 優先権
The priority at which this region was originally registered.
この領域が元々登録された優先権。
u.subtree
u. 下位木
Indicates a previously-registered region of the MIB that a
subagent no longer wishes to support.
副代理店がもう支持したがっていないMIBの以前に登録された領域を示します。
Daniele, et al. Standards Track [Page 28] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[28ページ]。
u.range_subid
u. 範囲_subid
Indicates a sub-identifier in u.subtree is a range lower
bound.
u.下位木におけるサブ識別子が範囲下界であることを示します。
u.upper_bound
u. 上側の_は固まりました。
The upper bound of the range sub-identifier. This field is
present in the PDU only if u.range_subid is not 0.
範囲サブ識別子の上限。 この分野はu.範囲_subidが0でない場合にだけPDUに存在しています。
6.2.5. The agentx-Get-PDU
6.2.5. agentxはPDUを手に入れます。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (5) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (5)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.sr)
(g.sr)
(start 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1を始めます) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 29] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[29ページ]。
(end 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(start n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(終わり1) +++++++++++++++++++++++++++++++++| 0 | 0 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... (始めn) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(終わりn) +++++++++++++++++++++++++++++++++| 0 | 0 | 0 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Get-PDU contains the following fields:
agentxにPDUを手に入れてください、以下の分野を含んでいます:
g.context
g. 文脈
An optional non-default context.
任意の非デフォルト文脈。
g.sr
g. sr
A SearchRangeList containing the requested variables for
this session. Within the agentx-Get-PDU, the Ending OIDs
within SearchRanges are null-valued Object Identifiers.
このセッションのために要求された変数を含むSearchRangeList。 agentxがPDUを手に入れる中では、SearchRangesの中のEnding OIDsはヌルで評価されたObject Identifiersです。
6.2.6. The agentx-GetNext-PDU
6.2.6. agentx-GetNext-PDU
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (6) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentXヘッダー) +++++++++++++++++++++++++++++++++| h. バージョン(1)| h. (6)をタイプしてください。| h. 旗| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. sessionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. transactionID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. packetID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h. ペイロード_長さ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 30] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[30ページ]。
(g.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.文脈) 任意の+++++++++++++++++++++++++++++++++| 八重奏ストリング長(L)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏1| 八重奏2| 八重奏3| 八重奏4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 八重奏L--1| 八重奏L| (必要に応じて)そっと歩くこと。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.sr)
(g.sr)
(start 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(1を始めます) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(終わり1) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| 0 | <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
(start n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(nを始めます) +++++++++++++++++++++++++++++++++| n_subid| 接頭語| インクルード| <は>を予約しました。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | サブ識別子#n_subid| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 31] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 31] RFC 2741 AgentX January 2000
(end n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(end n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
An agentx-GetNext-PDU contains the following fields:
An agentx-GetNext-PDU contains the following fields:
g.context
g.context
An optional non-default context.
An optional non-default context.
g.sr
g.sr
A SearchRangeList containing the requested variables for
this session.
A SearchRangeList containing the requested variables for this session.
6.2.7. The agentx-GetBulk-PDU
6.2.7. The agentx-GetBulk-PDU
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (7) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (7) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 32] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 32] RFC 2741 AgentX January 2000
(g.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.context) OPTIONAL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| g.non_repeaters | g.max_repetitions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g.non_repeaters | g.max_repetitions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.sr)
...
(g.sr) ...
An agentx-GetBulk-PDU contains the following fields:
An agentx-GetBulk-PDU contains the following fields:
g.context
g.context
An optional non-default context.
An optional non-default context.
g.non_repeaters
g.non_repeaters
The number of variables in the SearchRangeList that are not
repeaters.
The number of variables in the SearchRangeList that are not repeaters.
g.max_repetitions
g.max_repetitions
The maximum number of repetitions requested for repeating
variables.
The maximum number of repetitions requested for repeating variables.
g.sr
g.sr
A SearchRangeList containing the requested variables for
this session.
A SearchRangeList containing the requested variables for this session.
Daniele, et al. Standards Track [Page 33] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 33] RFC 2741 AgentX January 2000
6.2.8. The agentx-TestSet-PDU
6.2.8. The agentx-TestSet-PDU
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (8) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (8) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(t.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(t.context) OPTIONAL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(t.vb)
(t.vb)
(VarBind 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| v.type | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(VarBind 1) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v.type | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
Daniele, et al. Standards Track [Page 34] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 34] RFC 2741 AgentX January 2000
(VarBind n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| v.type | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(VarBind n) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | v.type | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-TestSet-PDU contains the following fields:
An agentx-TestSet-PDU contains the following fields:
t.context
t.context
An optional non-default context.
An optional non-default context.
t.vb
t.vb
A VarBindList containing the requested VarBinds for this
subagent.
A VarBindList containing the requested VarBinds for this subagent.
6.2.9. The agentx-CommitSet, -UndoSet, -CleanupSet PDUs
6.2.9. The agentx-CommitSet, -UndoSet, -CleanupSet PDUs
These PDUs consist of the AgentX header only.
These PDUs consist of the AgentX header only.
The agentx-CommitSet-, -UndoSet-, and -Cleanup-PDUs are used in processing an SNMP SetRequest operation.
The agentx-CommitSet-, -UndoSet-, and -Cleanup-PDUs are used in processing an SNMP SetRequest operation.
Daniele, et al. Standards Track [Page 35] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 35] RFC 2741 AgentX January 2000
6.2.10. The agentx-Notify-PDU
6.2.10. The agentx-Notify-PDU
An agentx-Notify-PDU is sent by a subagent to cause the master agent to forward a notification.
An agentx-Notify-PDU is sent by a subagent to cause the master agent to forward a notification.
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (12) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (12) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(n.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(n.context) OPTIONAL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(n.vb)
...
(n.vb) ...
An agentx-Notify-PDU contains the following fields:
An agentx-Notify-PDU contains the following fields:
n.context
n.context
An optional non-default context.
An optional non-default context.
n.vb
n.vb
A VarBindList whose contents define the actual PDU to be
sent. This memo places the following restrictions on its
contents:
A VarBindList whose contents define the actual PDU to be sent. This memo places the following restrictions on its contents:
- If the subagent supplies sysUpTime.0, it must be
present as the first varbind.
- If the subagent supplies sysUpTime.0, it must be present as the first varbind.
Daniele, et al. Standards Track [Page 36] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 36] RFC 2741 AgentX January 2000
- snmpTrapOID.0 must be present, as the second varbind
if sysUpTime.0 was supplied, as the first if it was
not.
- snmpTrapOID.0 must be present, as the second varbind if sysUpTime.0 was supplied, as the first if it was not.
6.2.11. The agentx-Ping-PDU
6.2.11. The agentx-Ping-PDU
The agentx-Ping-PDU is sent by a subagent to the master agent to monitor the master agent's ability to receive and send AgentX PDUs over their AgentX session.
The agentx-Ping-PDU is sent by a subagent to the master agent to monitor the master agent's ability to receive and send AgentX PDUs over their AgentX session.
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (13) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (13) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(p.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(p.context) OPTIONAL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Ping-PDU may contain the following field:
An agentx-Ping-PDU may contain the following field:
p.context
p.context
An optional non-default context.
An optional non-default context.
Using p.context a subagent can retrieve the sysUpTime value for a specific context, if required.
Using p.context a subagent can retrieve the sysUpTime value for a specific context, if required.
6.2.12. The agentx-IndexAllocate-PDU
6.2.12. The agentx-IndexAllocate-PDU
An agentx-IndexAllocate-PDU is sent by a subagent to request allocation of a value for specific index objects. Refer to section 7.1.4.2, "Registering Stuff", for suggested usage.
An agentx-IndexAllocate-PDU is sent by a subagent to request allocation of a value for specific index objects. Refer to section 7.1.4.2, "Registering Stuff", for suggested usage.
Daniele, et al. Standards Track [Page 37] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 37] RFC 2741 AgentX January 2000
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (14) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (14) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.context) OPTIONAL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.vb)
...
(i.vb) ...
An agentx-IndexAllocate-PDU contains the following fields:
An agentx-IndexAllocate-PDU contains the following fields:
i.context
i.context
An optional non-default context.
An optional non-default context.
i.vb
i.vb
A VarBindList containing the index names and values
requested for allocation.
A VarBindList containing the index names and values requested for allocation.
6.2.13. The agentx-IndexDeallocate-PDU
6.2.13. The agentx-IndexDeallocate-PDU
An agentx-IndexDeallocate-PDU is sent by a subagent to release previously allocated index values.
An agentx-IndexDeallocate-PDU is sent by a subagent to release previously allocated index values.
Daniele, et al. Standards Track [Page 38] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 38] RFC 2741 AgentX January 2000
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (15) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (15) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.context) OPTIONAL +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Padding (as required) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(i.vb)
...
(i.vb) ...
An agentx-IndexDeallocate-PDU contains the following fields:
An agentx-IndexDeallocate-PDU contains the following fields:
i.context
i.context
An optional non-default context.
An optional non-default context.
i.vb
i.vb
A VarBindList containing the index names and values to be
released.
A VarBindList containing the index names and values to be released.
6.2.14. The agentx-AddAgentCaps-PDU
6.2.14. The agentx-AddAgentCaps-PDU
An agentx-AddAgentCaps-PDU is generated by a subagent to inform the master agent of agent capabilities for the specified session.
An agentx-AddAgentCaps-PDU is generated by a subagent to inform the master agent of agent capabilities for the specified session.
Daniele, et al. Standards Track [Page 39] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 39] RFC 2741 AgentX January 2000
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (16) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (16) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.context) (OPTIONAL)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Optional Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.context) (OPTIONAL) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Optional Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.id)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.id) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.descr)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Optional Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.descr) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Optional Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 40] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 40] RFC 2741 AgentX January 2000
An agentx-AddAgentCaps-PDU contains the following fields:
An agentx-AddAgentCaps-PDU contains the following fields:
a.context
a.context
An optional non-default context.
An optional non-default context.
a.id
a.id
An Object Identifier containing the value of an invocation
of the AGENT-CAPABILITIES macro, which the master agent
exports as a value of sysORID for the indicated context.
(Recall that the value of an invocation of an AGENT-
CAPABILITIES macro is an object identifier that describes a
precise level of support with respect to implemented MIB
modules. A more complete discussion of the AGENT-
CAPABILITIES macro and related sysORID values can be found
in section 6 of STD 58, RFC 2580 [7].)
An Object Identifier containing the value of an invocation of the AGENT-CAPABILITIES macro, which the master agent exports as a value of sysORID for the indicated context. (Recall that the value of an invocation of an AGENT- CAPABILITIES macro is an object identifier that describes a precise level of support with respect to implemented MIB modules. A more complete discussion of the AGENT- CAPABILITIES macro and related sysORID values can be found in section 6 of STD 58, RFC 2580 [7].)
a.descr
a.descr
An Octet String containing a DisplayString to be used as the
value of sysORDescr corresponding to the sysORID value
above.
An Octet String containing a DisplayString to be used as the value of sysORDescr corresponding to the sysORID value above.
6.2.15. The agentx-RemoveAgentCaps-PDU
6.2.15. The agentx-RemoveAgentCaps-PDU
An agentx-RemoveAgentCaps-PDU is generated by a subagent to request that the master agent stop exporting a particular value of sysORID. This value must have previously been advertised by the subagent in an agentx-AddAgentCaps-PDU for this session.
An agentx-RemoveAgentCaps-PDU is generated by a subagent to request that the master agent stop exporting a particular value of sysORID. This value must have previously been advertised by the subagent in an agentx-AddAgentCaps-PDU for this session.
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (17) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(AgentX header) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (17) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Daniele, et al. Standards Track [Page 41] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 41] RFC 2741 AgentX January 2000
(a.context) (OPTIONAL)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Optional Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.context) (OPTIONAL) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet String Length (L) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet 1 | Octet 2 | Octet 3 | Octet 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Octet L - 1 | Octet L | Optional Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.id)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(a.id) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | n_subid | prefix | 0 | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | sub-identifier #n_subid | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-RemoveAgentCaps-PDU contains the following fields:
An agentx-RemoveAgentCaps-PDU contains the following fields:
a.context
a.context
An optional non-default context.
An optional non-default context.
a.id
a.id
An ObjectIdentifier containing the value of sysORID that
should no longer be exported.
An ObjectIdentifier containing the value of sysORID that should no longer be exported.
Daniele, et al. Standards Track [Page 42] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 42] RFC 2741 AgentX January 2000
6.2.16. The agentx-Response-PDU
6.2.16. The agentx-Response-PDU
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (18) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.version (1) | h.type (18) | h.flags | <reserved> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.sessionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.transactionID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.packetID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h.payload_length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| res.sysUpTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| res.error | res.index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res.sysUpTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | res.error | res.index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ...
An agentx-Response-PDU contains the following fields:
An agentx-Response-PDU contains the following fields:
h.sessionID
h.sessionID
If this is a response to an agentx-Open-PDU, then it
contains the new and unique sessionID (as assigned by the
master agent) for this session.
If this is a response to an agentx-Open-PDU, then it contains the new and unique sessionID (as assigned by the master agent) for this session.
Otherwise it must be identical to the h.sessionID value in
the PDU to which this PDU is a response.
Otherwise it must be identical to the h.sessionID value in the PDU to which this PDU is a response.
h.transactionID
h.transactionID
Must be identical to the h.transactionID value in the PDU to
which this PDU is a response.
Must be identical to the h.transactionID value in the PDU to which this PDU is a response.
In an agentx response PDU from the master agent to the
subagent, the value of h.transactionID has no significance
and can be ignored by the subagent.
In an agentx response PDU from the master agent to the subagent, the value of h.transactionID has no significance and can be ignored by the subagent.
h.packetID
h.packetID
Must be identical to the h.packetID value in the PDU to
which this PDU is a response.
Must be identical to the h.packetID value in the PDU to which this PDU is a response.
Daniele, et al. Standards Track [Page 43] RFC 2741 AgentX January 2000
Daniele, et al. Standards Track [Page 43] RFC 2741 AgentX January 2000
res.sysUpTime
res.sysUpTime
This field contains the current value of sysUpTime for the
context indicated within the PDU to which this PDU is a
response. It is relevant only in agentx response PDUs sent
from the master agent to a subagent in response to the set
of administrative PDUs listed in section 6.1, "AgentX PDU
Header".
この分野はこのPDUが応答であるPDUの中に示された文脈のためのsysUpTimeの現行価値を含んでいます。 それはPDUsがセクション6.1で記載された、管理PDUs、「AgentX PDUヘッダー」のセットに対応してマスターエージェントから副代理店に送ったagentx応答だけで関連しています。
In an agentx response PDU from the subagent to the master
agent, the value of res.sysUpTime has no significance and is
ignored by the master agent.
agentx応答では、副代理店からマスターエージェントまでのPDU、res.sysUpTimeの値は、意味を全く持たないで、マスターエージェントによって無視されます。
res.error
res.error
Indicates error status. Within responses to the set of
"administrative" PDU types listed in section 6.1, "AgentX
PDU Header", values are limited to the following:
エラー状況を示します。 セクション6.1、「AgentX PDUヘッダー」に記載された「管理」のPDUタイプのセットへの応答の中では、値は以下に制限されます:
noAgentXError (0),
openFailed (256),
notOpen (257),
indexWrongType (258),
indexAlreadyAllocated (259),
indexNoneAvailable (260),
indexNotAllocated (261),
unsupportedContext (262),
duplicateRegistration (263),
unknownRegistration (264),
unknownAgentCaps (265),
parseError (266),
requestDenied (267),
processingError (268)
noAgentXError(0)、openFailed(256)、notOpen(257)、indexWrongType(258)、indexAlreadyAllocated(259)、indexNoneAvailable(260)、indexNotAllocated(261)、unsupportedContext(262)、duplicateRegistration(263)、unknownRegistration(264)、unknownAgentCaps(265)、parseError(266)、requestDenied(267)、processingError(268)
Within responses to the set of "SNMP request processing" PDU
types listed in section 6.1, "AgentX PDU Header", values may
also include those defined for errors in the SNMPv2 PDU (RFC
1905 [13]).
中では、「AgentX PDUヘッダー」と、「SNMPが処理を要求する」PDUタイプのセットへの応答がセクション6.1で記載しました、また、値がSNMPv2 PDUの誤りによって定義されたものを含むかもしれません。(RFC1905[13])。
res.index
res.index
In error cases, this is the index of the failed variable
binding within a received request PDU. (Note: As explained
in section 5.4, "Value Representation", the index values of
variable bindings within a variable binding list are 1-
based.)
誤り事件では、これは容認された要求PDUの中の失敗した変項束縛のインデックスです。 (注意: セクション5.4、「値の表現」で説明されるように、変項束縛リストの中の変項束縛のインデックス値は基づく1です。)
Daniele, et al. Standards Track [Page 44] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[44ページ]。
A VarBindList may follow res.index, depending on which AgentX PDU is being responded to. These data are specified in the subsequent elements of procedure.
どのAgentX PDUが応じているかによって、VarBindListはres.indexに続くかもしれません。 これらのデータは手順のその後の要素で指定されます。
7. Elements of Procedure
7. 手順のElements
This section describes the actions of protocol entities (master agents and subagents) implementing the AgentX protocol. Note, however, that it is not intended to constrain the internal architecture of any conformant implementation.
このセクションは、AgentXプロトコルを実行しながら、プロトコル実体(マスターエージェントと副代理店)の動作について説明します。 しかしながら、どんなconformant実現の内部の構造も抑制することを意図しないことに注意してください。
The actions of AgentX protocol entities can be broadly categorized under two headings, each of which is described separately:
2つの見出しの下でAgentXプロトコル実体の動作を露骨に分類できます:それのそれぞれが別々に見出しのために説明されます。
(1) processing AgentX administrative messages (e.g., registration
requests from a subagent to a master agent); and
(1) AgentXの管理メッセージ(例えば、副代理店からマスターエージェントまでの登録要求)を処理します。 そして
(2) processing SNMP messages (the coordinated actions of a master
agent and one or more subagents in processing, for example, a
received SNMP GetRequest-PDU).
(2) 処理SNMPメッセージ(マスターエージェントの連携動作と処理、例えば、容認されたSNMP GetRequest-PDUの1つ以上の副代理店)。
7.1. Processing AgentX Administrative Messages
7.1. AgentXの管理メッセージを処理します。
This subsection describes the actions of AgentX protocol entities in processing AgentX administrative messages. Such messages include those involved in establishing and terminating an AgentX session between a subagent and a master agent, those by which a subagent requests allocation of instance index values, and those by which a subagent communicates to a master agent which MIB regions it supports.
この小区分はAgentXの管理メッセージを処理することにおける、AgentXプロトコル実体の動作について説明します。 そのようなメッセージは副代理店とマスターエージェント(副代理店が例のインデックス値、および副代理店が、それがどのMIB領域を支持するかをマスターエージェントに伝えるそれらの配分を要求するそれら)とのAgentXセッションを確立して、終える際に関係者を含んでいます。
Processing is defined specifically for each PDU type in its own section. For the master agent, many of these PDU types require the same initial processing steps. This common processing is defined here, and referenced as needed in the PDU type-specific descriptions.
処理は特にそれ自身のセクションのそれぞれのPDUタイプのために定義されます。 マスターエージェントに関しては、これらのPDUタイプの多くが同じ初期の処理ステップを必要とします。 この一般的な処理は、必要に応じてPDUのタイプ明確な記述でここで定義されて、参照をつけられます。
Common Processing:
一般的な処理:
The master agent initially processes a received AgentX PDU as follows:
マスターエージェントは初めは、以下の容認されたAgentX PDUを処理します:
1) An agentx-Response-PDU is created, res.sysUpTime is set to the
value of sysUpTime.0 for the default context, res.error is set
to `noAgentXError', and res.index is set to 0.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています、そして、res.errorは'noAgentXError'に用意ができています、そして、res.indexは0に用意ができています。
2) If the received PDU cannot be parsed, res.error is set to `
parseError'. Examples of a parse error are:
2) 容認されたPDUを分析できないなら、res.errorは'parseError'に用意ができています。 aに関する例は分析されます。誤りは以下の通りです。
Daniele, et al. Standards Track [Page 45] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[45ページ]。
- PDU length (h.payload) too short to contain current
construct (Object Identifier header indicates more sub-
identifiers, VarBind v.type indicates data follows, etc)
- 現在の構造物を含むことができないくらい不足したPDUの長さ(h.ペイロード)(物のIdentifierヘッダーは、より多くのサブ識別子、タイプが、データが続くのを示すVarBind v.などを示します)
- An unrecognized value is encountered for h.type, v.type,
etc.
- 認識されていない値はh.タイプのためにタイプなどに対して遭遇します。
3) Otherwise, if h.sessionID does not correspond to a currently
established session with this subagent, res.error is set to
`notOpen'.
3) さもなければ、h.sessionIDがこの副代理店との現在確立したセッションに対応していないなら、res.errorは'notOpen'に用意ができています。
4) Otherwise, if the NON_DEFAULT_CONTEXT bit is set and the master
agent does not support the indicated context, res.error is set
to `unsupportedContext'. If the master agent does support the
indicated context, the value of res.sysUpTime is set to the
value of sysUpTime.0 for that context.
4) さもなければ、NON_DEFAULT_CONTEXTビットが設定されて、マスターエージェントが示された文脈を支持しないなら、res.errorは'unsupportedContext'に用意ができています。 マスターエージェントが示された文脈を支持するなら、res.sysUpTimeの値はその文脈のためのsysUpTime.0の値に設定されます。
Note: Non-default contexts might be added on the fly by the master
agent, or the master agent might require such non-default
contexts to be pre-configured. The choice is
implementation-specific.
以下に注意してください。 非デフォルト文脈がマスターエージェントによって急いで言い足されるかもしれませんか、またはマスターエージェントは、そのような非デフォルト文脈があらかじめ設定されるのを必要とするかもしれません。 選択は実現特有です。
5) If resources cannot be allocated or some other condition
prevents processing, res.error is set to `processingError'.
5) リソースを割り当てることができないか、またはある他の状態が、処理するのを防ぐなら、res.errorは'processingError'に用意ができています。
6) At this point, if res.error is not `noAgentXError', the
received PDU is not processed further. If the received PDU's
header was successfully parsed, the AgentX-Response-PDU is sent
in reply. If the received PDU contained a VarBindList which
was successfully parsed, the AgentX-Response-PDU contains the
identical VarBindList. If the received PDU's header was not
successfully parsed or for some other reason the master agent
cannot send a reply, processing is complete.
6) ここに、容認されたPDUはres.errorが'noAgentXError'でないなら、さらに処理されません。 首尾よく容認されたPDUのヘッダーを分析したなら、回答でAgentX応答PDUを送ります。 容認されたPDUが首尾よく分析されたVarBindListを含んだなら、AgentX応答PDUは同じVarBindListを含んでいます。 容認されたPDUのヘッダーが首尾よく分析されないか、マスターエージェントが返信できないある他の理由であったなら、処理は完全です。
7.1.1. Processing the agentx-Open-PDU
7.1.1. agentxの開いているPDUを処理します。
When the master agent receives an agentx-Open-PDU, it processes it as follows:
マスターエージェントがagentxの開いているPDUを受け取るとき、以下の通りそれを処理します:
1) An agentx-Response-PDU is created, res.sysUpTime is set to the
value of sysUpTime.0 for the default context, res.error is set to
`noAgentXError', and res.index is set to 0.
1) agentx応答PDUは作成されます、そして、res.sysUpTimeはデフォルト文脈のためのsysUpTime.0の値に用意ができています、そして、res.errorは'noAgentXError'に用意ができています、そして、res.indexは0に用意ができています。
2) If the received PDU cannot be parsed, res.error is set to
`parseError'.
2) 容認されたPDUを分析できないなら、res.errorは'parseError'に用意ができています。
3) Otherwise, if the master agent is unable to open an AgentX session
for any reason, res.error is set to `openFailed'.
3) さもなければ、マスターエージェントがどんな理由でもAgentXセッションを開くことができないなら、res.errorは'openFailed'に用意ができています。
Daniele, et al. Standards Track [Page 46] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[46ページ]。
4) Otherwise: The master agent assigns a sessionID to the new
session and puts the value in the h.sessionID field of the
agentx-Response-PDU. This value must be unique among all existing
open sessions.
4) そうでなければ: マスターエージェントは、新しいセッションまでsessionIDを割り当てて、agentx応答PDUのh.sessionID分野に値を置きます。 この値はすべての既存の公開審議の中でユニークであるに違いありません。
The master agent retains session-specific information from the PDU
for this session:
マスターエージェントはこのセッションのためにPDUからのセッション特殊情報を保有します:
- The NETWORK_BYTE_ORDER value in h.flags is retained. All
subsequent AgentX protocol operations initiated by the master
agent for this session must use this byte ordering and set this
bit accordingly.
- h.旗によるNETWORK_BYTE_ORDER価値は保有されます。 このセッションのためにマスターエージェントによって開始されたすべてのその後のAgentXプロトコル操作が、このバイト順を使用して、それに従って、このビットを設定しなければなりません。
The subagent typically sets this bit to correspond to its native
byte ordering, and typically does not vary byte ordering for an
initiated session. The master agent must be able to decode each
PDU according to the h.flag NETWORK_BYTE_ORDER bit in the PDU, but
does not need to toggle its retained value for the session if the
subagent varies its byte ordering.
副代理店は、このビットにネイティブのバイト順に相当するように通常設定して、開始しているセッションのためにバイト順を通常変えません。 マスターエージェントは、h.旗のNETWORK_BYTE_ORDERビットに従ってPDUで各PDUを解読できなければなりませんが、副代理店がバイト順を変えるなら、セッションのために保有された値を切り換える必要はありません。
- The o.timeout value is used in calculating response timeout
conditions for this session. This field is also referenced in
the AgentX MIB (a work-in-progress) by the agentxSessionTimeout
object.
- o.タイムアウト価値はこのセッションに計算の応答タイムアウト状態で使用されます。 また、この分野はAgentX MIB(処理中の作業)でagentxSessionTimeout物によって参照をつけられます。
- The o.id and o.descr fields are used for informational
purposes. These two fields are also referenced in the AgentX
MIB (a work-in-progress) by the agentxSessionObjectID object,
and by the agentxSessionDescr object.
- o.イドとo.descr分野は情報の目的に使用されます。 また、これらの2つの分野がAgentX MIB(処理中の作業)でagentxSessionObjectID物、およびagentxSessionDescr物によって参照をつけられます。
5) The agentx-Response-PDU is sent with the res.error field
indicating the result of the session initiation.
5) res.error分野がセッション開始の結果を示していて、agentx応答PDUを送ります。
If processing was successful, an AgentX session is considered established between the master agent and the subagent. An AgentX session is a distinct channel for the exchange of AgentX protocol messages between a master agent and one subagent, qualified by the session-specific attributes listed in 4) above. AgentX session establishment is initiated by the subagent. An AgentX session can be terminated by either the master agent or the subagent.
処理がうまくいったなら、AgentXセッションはマスターエージェントと副代理店の間で確立していると考えられます。 AgentXセッションは4で)記載されたセッション特有の属性によって上に資格があったマスターエージェントと1つの副代理店の間のAgentXプロトコルメッセージの交換のための異なったチャンネルです。 AgentXセッション設立は副代理店によって開始されます。 マスターエージェントか副代理店のどちらかはAgentXセッションを終えることができます。
7.1.2. Processing the agentx-IndexAllocate-PDU
7.1.2. agentx-IndexAllocate-PDUを処理します。
When the master agent receives an agentx-IndexAllocate-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages". If as a result res.error is `noAgentXError', processing continues as follows:
マスターエージェントがagentx-IndexAllocate-PDUを受け取るとき、それは「AgentXの管理メッセージを処理し」て、セクション7.1で説明された一般的な処理を実行します。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
Daniele, et al. Standards Track [Page 47] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[47ページ]。
1) Each VarBind in the VarBindList is processed until either all are
successful, or one fails. If any VarBind fails, the agentx-
Response-PDU is sent in reply containing the original VarBindList,
with res.index set to indicate the failed VarBind, and with
res.error set as described subsequently. All other VarBinds are
ignored; no index values are allocated.
1) すべてがうまくいっているか、または1つが失敗するまで、VarBindListの各VarBindは処理されます。 どれかVarBindが失敗するなら、agentx応答-PDUは失敗したVarBindを示すres.index set、および次に説明されるように用意ができているres.errorとオリジナルのVarBindListを含む送られた回答です。 他のすべてのVarBindsが無視されます。 インデックス値を全く割り当てません。
VarBinds are processed as follows:
VarBindsは以下の通り処理されます:
- v.name is the OID prefix of the MIB OBJECT-TYPE for which a
value is to be allocated.
- v. 名前は割り当てられる値がことであるMIB OBJECT-TYPEのOID接頭語です。
- v.type is the syntax of the MIB OBJECT-TYPE for which a value is
to be allocated.
- v. タイプは割り当てられる値がことであるMIB OBJECT-TYPEの構文です。
- v.data indicates the specific index value requested. If the
NEW_INDEX or the ANY_INDEX bit is set, the actual value in
v.data is ignored and an appropriate index value is generated.
- v. データは値が要求した特定のインデックスを示します。 または、NEW_INDEXである、どんな_INDEXビットも設定されて、v.データの実価は無視されて、適切なインデックス値は発生します。
a) If there are no currently allocated index values for v.name in
the indicated context, and v.type does not correspond to a
valid index type value, the VarBind fails and res.error is set
to `indexWrongType'.
a) 示された文脈にはv.名のための現在割り当てられたインデックス値が全くなくて、またv.タイプが有効なインデックスタイプ価値に文通していないなら、VarBindは失敗します、そして、res.errorは'indexWrongType'に用意ができています。
b) If there are currently allocated index values for v.name in the
indicated context, but the syntax of those values does not
match v.type, the VarBind fails and res.error is set to
`indexWrongType'.
b) 示された文脈にはv.名のための現在割り当てられたインデックス値がありますが、それらの値の構文がタイプに対して合っていないなら、VarBindは失敗します、そして、res.errorは'indexWrongType'に用意ができています。
c) Otherwise, if both the NEW_INDEX and ANY_INDEX bits are clear,
allocation of a specific index value is being requested. If
the requested index is already allocated for v.name in the
indicated context, the VarBind fails and res.error is set to
`indexAlreadyAllocated'.
c) さもなければ、NEW_INDEXとどんな_INDEXビットの両方も明確であるなら、特定のインデックス価値の配分は要求されています。 示された文脈のv.名のために既に要求されたインデックスを割り当てるなら、VarBindは失敗します、そして、res.errorは'indexAlreadyAllocated'に用意ができています。
d) Otherwise, if the NEW_INDEX bit is set, the master agent should
generate the next available index value for v.name in the
indicated context, with the constraint that this value must not
have been allocated (even if subsequently released) to any
subagent since the last re-initialization of the master agent.
If no such value can be generated, the VarBind fails and
res.error is set to `indexNoneAvailable'.
d) さもなければ、NEW_INDEXビットが設定されるなら、マスターエージェントは示された文脈のv.名のために次の利用可能なインデックス値を発生させるべきです、マスターエージェントの最後の再初期化以来この値をどんな副代理店にも割り当てていてはいけないという(次にリリースされても)規制で。 何かそのような値が発生できないなら、VarBindは失敗します、そして、res.errorは'indexNoneAvailable'に用意ができています。
e) Otherwise, if the ANY_INDEX bit is set, the master agent should
generate an index value for v.name in the indicated context,
with the constraint that this value is not currently allocated
to any subagent. If no such value can be generated, then the
VarBind fails and res.error is set to `indexNoneAvailable'.
e) そうでなければ、どんな_INDEXビットも設定されて、マスターエージェントは示された文脈のv.名のためにインデックス値を発生させるべきです、この値が現在どんな副代理店にも割り当てられないという規制で。 何かそのような値が発生できないなら、VarBindは失敗します、そして、res.errorは'indexNoneAvailable'に用意ができています。
Daniele, et al. Standards Track [Page 48] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[48ページ]。
2) If all VarBinds are processed successfully, the agentx-Response-
PDU is sent in reply with res.error set to `noAgentXError'. A
VarBindList is included that is identical to the one sent in the
agentx-IndexAllocate-PDU, except that VarBinds requesting a
NEW_INDEX or ANY_INDEX value are generated with an appropriate
value.
2) 首尾よくすべてのVarBindsを処理するなら、'noAgentXError'に用意ができているres.errorとの回答でagentx応答-PDUを送ります。 含まれていたものと同じVarBindListはagentx-IndexAllocate-PDUを送りました、NEW_INDEXかどんな_INDEX価値も要求するVarBindsが適切な値で発生するのを除いて。
See section 7.1.4.2, "Registering Stuff" for more information on
how subagents should perform index allocations.
セクション7.1を見てください。.4 .2 副代理店がどうインデックス配分を実行するべきであるかに関する詳しい情報のために「ものを登録します」。
7.1.3. Processing the agentx-IndexDeallocate-PDU
7.1.3. agentx-IndexDeallocate-PDUを処理します。
When the master agent receives an agentx-IndexDeallocate-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages". If as a result res.error is `noAgentXError', processing continues as follows:
マスターエージェントがagentx-IndexDeallocate-PDUを受け取るとき、それは「AgentXの管理メッセージを処理し」て、セクション7.1で説明された一般的な処理を実行します。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
1) Each VarBind in the VarBindList is processed until either all are
successful, or one fails. If any VarBind fails, the agentx-
Response-PDU is sent in reply, containing the original
VarBindList, with res.index set to indicate the failed VarBind,
and with res.error set as described subsequently. All other
VarBinds are ignored; no index values are released.
1) すべてがうまくいっているか、または1つが失敗するまで、VarBindListの各VarBindは処理されます。 どれかVarBindが失敗するなら、回答でagentx応答-PDUを送ります、失敗したVarBindを示すres.index set、および次に説明されるように用意ができているres.errorとオリジナルのVarBindListを含んでいて。 他のすべてのVarBindsが無視されます。 インデックス値は全くリリースされません。
VarBinds are processed as follows:
VarBindsは以下の通り処理されます:
- v.name is the name of the index for which a value is to be
released
- v. 名前はリリースされる値がことであるインデックスの名前です。
- v.type is the syntax of the index object
- v. タイプはインデックス物の構文です。
- v.data indicates the specific index value to be released. The
NEW_INDEX and ANY_INDEX bits are ignored.
- v. データは、リリースされるために特定のインデックス値を示します。 NEW_INDEXとどんな_INDEXビットも無視されます。
a) If the index value for the named index is not currently
allocated to this session, the VarBind fails and res.error is
set to `indexNotAllocated'.
a) 命名されたインデックスのためのインデックス値が現在このセッションまで割り当てられないなら、VarBindは失敗します、そして、res.errorは'indexNotAllocated'に用意ができています。
2) If all VarBinds are processed successfully, res.error is set to
`noAgentXError' and the agentx-Response-PDU is sent. A
VarBindList is included which is identical to the one sent in the
agentx-IndexDeallocate-PDU.
2) すべてのVarBindsが首尾よく処理されるなら、res.errorは'noAgentXError'に用意ができています、そして、agentx応答PDUを送ります。 VarBindListは含まれています(agentx-IndexDeallocate-PDUで送られたものと同じです)。
All released index values are now available, and may be used in response to subsequent allocation requests for ANY_INDEX values and in response to subsequent allocation requests for the particular index value.
すべてのリリースされたインデックス値が、現在、利用可能であり、どんな_INDEX値を求めるその後の配分要求に対応して特定のインデックス値を求めるその後の配分要求に対応して使用されるかもしれません。
Daniele, et al. Standards Track [Page 49] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[49ページ]。
7.1.4. Processing the agentx-Register-PDU
7.1.4. agentxレジスタPDUを処理します。
When the master agent receives an agentx-Register-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages". If as a result res.error is `noAgentXError', processing continues as follows:
マスターエージェントがagentxレジスタPDUを受け取るとき、それは「AgentXの管理メッセージを処理し」て、セクション7.1で説明された一般的な処理を実行します。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
If any of the union of subtrees defined by this MIB region is exactly the same as any subtree defined by a MIB region currently registered within the indicated context, those subtrees are termed "duplicate subtrees".
このMIB領域によって定義された下位木の組合のどれかがまさに現在MIB領域によって定義されているどんな下位木も示された文脈の中に登録されたのと同じであるなら、それらの下位木は「写し下位木」と呼ばれます。
If any of the union of subtrees defined by this MIB region overlaps, or is itself overlapped by, any subtree defined by a MIB region currently registered within the indicated context, those subtrees are termed "overlapping subtrees".
このMIBによって定義された下位木の組合のどれかであるなら、領域によって重なるか、または重なられていて、現在MIB領域によって定義されているどんな下位木も示された文脈の中に登録されて、それらの下位木は「下位木を重ね合わせます」と呼ばれます。
1) If this registration would result in duplicate subtrees registered
with the same value of r.priority, the request fails and an
agentx-Response-PDU is returned with res.error set to
`duplicateRegistration'.
1) この登録がr.優先権の同じ価値に登録された写し下位木をもたらすなら、要求は失敗します、そして、'duplicateRegistration'に用意ができているres.errorでagentx応答PDUを返します。
2) Otherwise, if the master agent does not wish to permit this
registration for implementation-specific reasons, the request
fails and an agentx-Response-PDU is returned with res.error set to
`requestDenied'.
2) さもなければ、マスターエージェントが実現特有の理由でこの登録を可能にしたくないなら、要求は失敗します、そして、'requestDenied'に用意ができているres.errorでagentx応答PDUを返します。
3) Otherwise, the agentx-Response-PDU is returned with res.error set
to `noAgentXError'.
3) さもなければ、'noAgentXError'に用意ができているres.errorでagentx応答PDUを返します。
The master agent adds this MIB region to its registration data
store for the indicated context, to be considered during the
dispatching phase for subsequently received SNMP protocol
messages.
マスターエージェントは、次に受信されたSNMPプロトコルメッセージのために急ぎ段階の間、考えられるために示された文脈のための登録データ・ストアにこのMIB領域を加えます。
7.1.4.1. Handling Duplicate and Overlapping Subtrees
7.1.4.1. 取り扱い写しと下位木を重ね合わせること。
As a result of this registration algorithm there are likely to be duplicate and/or overlapping subtrees within the registration data store of the master agent. Whenever the master agent's dispatching algorithm (see section 7.2.1, "Dispatching AgentX PDUs") determines that there are multiple subtrees that could potentially contain the same MIB object instances, the master agent selects one to use, termed the 'authoritative region', as follows:
この登録アルゴリズムの結果、マスターエージェントの登録データ・ストアの中に写しである、そして/または、重なっているのに下位木がおそらくあります。 マスターエージェントの急ぎアルゴリズム(セクション7.2.1を見てください、「AgentX PDUsを派遣し」て)が、潜在的に同じMIB物の例を含むことができた複数の下位木があることを決定するときはいつも、マスターエージェントは以下の'正式の領域'と呼ばれた使用への1つを選択します:
Daniele, et al. Standards Track [Page 50] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[50ページ]。
1) Choose the one whose original agentx-Register-PDU r.subtree
contained the most subids, i.e., the most specific r.subtree.
Note: The presence or absence of a range subid has no bearing
on how "specific" one object identifier is compared to another.
1) オリジナルのagentxレジスタPDU r.下位木が含んだ中ですなわち、最も多くのsubids、r.下位木最も特定であるものを選んでください。 以下に注意してください。 範囲subidの存在か不在には、1つの「特定」の物の識別子がどう別のものと比較されるかの堪えることがありません。
2) If still ambiguous, there were duplicate subtrees. Choose the
one whose original agentx-Register-PDU specified the smaller
value of r.priority.
2) まだあいまいであるなら、写し下位木がありました。 オリジナルのagentxレジスタPDUがr.優先権の、より小さい値を指定したものを選んでください。
7.1.4.2. Registering Stuff
7.1.4.2. 登録もの
This section describes more fully how AgentX subagents use the agentx-IndexAllocate-PDU and agentx-Register-PDU to achieve desired configurations.
このセクションはAgentX副代理店が必要な構成を達成するのにどうagentx-IndexAllocate-PDUとagentxレジスタPDUを使用するかをより完全に説明します。
7.1.4.2.1. Registration Priority
7.1.4.2.1. 登録優先権
The r.priority field in the agentx-Register-PDU is intended to be manipulated by human administrators to achieve a desired subagent configuration. Typically this would be needed where a legacy application registers a specific subtree, and a different (configurable) application may need to become authoritative for the identical subtree.
agentxレジスタPDUのr.優先権分野は必要な副代理店構成を達成するために人間の管理者によって操られることを意図します。 これが遺産アプリケーションが特定の下位木を登録するところで通常、必要でしょう、そして、異なった(構成可能な)アプリケーションは同じ下位木に正式になる必要があるかもしれません。
The result of this configuration (the same subtree registered on different sessions with different priorities) is that the session using the better priority (see section 7.1.4.1, "Handling Duplicate and Overlapping Subtrees") will be authoritative. The other session will simply never be dispatched to.
この構成(異なったプライオリティとの異なったセッションのときに登録された同じ下位木)の結果は、より良い優先権(セクション7.1.4.1と、「取り扱い写しと重なっている下位木」を見る)を使用するセッションが正式になるということです。 もう片方のセッションまで単に決して急がないでしょう。
This is useful in the case described above, but is NOT useful in other cases, particularly when subagents share tables indexed by arbitrary values (see below). In general, subagents should register using the default priority (127).
これは、上で説明された場合で役に立ちますが、他の場合では役に立ちません、特に副代理店が任意の値によって索引をつけられたテーブルを共有するとき(以下を見てください)。 一般に、副代理店は、デフォルト優先権(127)を使用することで登録されるべきです。
7.1.4.2.2. Index Allocation
7.1.4.2.2. インデックス配分
Index allocation is a service provided by an AgentX master agent. It provides generic support for sharing MIB conceptual tables among subagents who are assumed to have no knowledge of each other.
インデックス配分はAgentXマスターエージェントによって提供されたサービスです。 それは、互いに関する知識を全く持たないように概念的な副代理店の中のそうするMIBテーブルを共有するために想定されていた状態で一般的なサポートを提供します。
The master agent maintains a database of index objects (OIDs), and, for each index, the values that have been allocated for it. It is unaware of what MIB variables (if any) the index objects represent.
そして、マスターエージェントは各インデックス(それのために割り当てられた値)のためにインデックス物(OIDs)に関するデータベースを維持します。 インデックス物がどんなMIB変数(もしあれば)を表すかにそれは気づきません。
Daniele, et al. Standards Track [Page 51] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[51ページ]。
By convention, subagents use the MIB variable listed in the INDEX clause as the index object for which values must be allocated. For tables indexed by multiple variables, values may be allocated for each index (although this is frequently unnecessary; see example 2 below). The subagent may request allocation of
コンベンションで、副代理店は値を割り当てなければならないインデックス物としてINDEX節に記載されたMIB変数を使用します。 複数の変数によって索引をつけられたテーブルに関しては各インデックスのために値を割り当てるかもしれない、(これは頻繁に不要です; 以下の例2を見てください、) 副代理店は配分を要求するかもしれません。
a) a specific index value
b) an index value that is not currently allocated
c) an index value that has never been allocated
a) 特定のインデックス値b) c) 一度も割り当てられたことがないインデックス値が現在割り当てられないインデックス値
The last two alternatives reflect the uniqueness and constancy requirements present in many MIB specifications for arbitrary integer indexes (e.g., ifIndex in the IF-MIB (RFC 2233 [19]), snmpFddiSMTIndex in the FDDI MIB (RFC 1285 [20]), or sysApplInstallPkgIndex in the System Application MIB (RFC 2287 [21])). The need for subagents to share tables using such indexes is the main motivation for index allocation in AgentX.
最後の2つの選択肢が任意の整数インデックスのための多くのMIB仕様の現在のユニークさと不変性要件を反映する、(例えば、中のifIndex、-、MIB、(RFC2233[19])、FDDI MIBのsnmpFddiSMTIndex、(RFC1285[20])、またはSystem Application MIBのsysApplInstallPkgIndex、(RFC2287[21]))。 副代理店がそのようなインデックスを使用することでテーブルを共有する必要性はAgentXでのインデックス配分に関する主な動機です。
It is important to note that index allocation and MIB region registration are not coupled in the master agent. The current state of index allocations is not considered when processing registration requests, and the current registry is not considered when processing index allocation requests. (This is mainly to accommodate non-AgentX subagents.)
インデックス配分とMIB領域登録がマスターエージェントで結合されないことに注意するのは重要です。 登録要求を処理する場合、インデックス配分の現状は考えられません、そして、インデックス配分要求を処理するとき、現在の登録は考えられません。 (これは主に非AgentX副代理店を収容するためのものです。)
AgentX subagents should follow the model of "first request allocation of an index, then register the corresponding region". Then a successful index allocation request gives a subagent a good hint (but no guarantee) of what it should be able to register. The registration may fail (with `duplicateRegistration') because some other subagent session has already registered that row of the table.
AgentX副代理店は「最初に、インデックスの配分を要求してください、そして、次に、対応部分を登録してください」のモデルに従うべきです。 そして、うまくいっているインデックス配分要求はそれが何であるべきであるかに関する良いヒント(しかし、保証がない)を副代理店に登録できる状態で与えます。 ある他の副代理店セッションが既にテーブルのその列を示したので、登録は失敗するかもしれません('duplicateRegistration'と共に)。
The recommended mechanism for subagents to register conceptual rows in a shared table is
副代理店が共有されたテーブルの概念的な列を示すお勧めのメカニズムはそうです。
1) Successfully allocate an index value.
1) 首尾よくインデックス値を割り当ててください。
2) Use that value to fully qualify the MIB region(s), and attempt to
register using the default priority.
2) その値を使用して、MIB領域に完全に資格を与えてください、デフォルト優先権を使用することで登録するのを試みてください。
3) If the registration fails with `duplicateRegistration' deallocate
the previously allocated index value(s) for this row and go to
step 1).
3) 登録が'duplicateRegistration'deallocateで以前に割り当てられたインデックスに失敗するなら、この列への(s)を評価してください、そして、ステップ1)に行ってください。
Daniele, et al. Standards Track [Page 52] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[52ページ]。
Note that index allocation is necessary only when the index in question is an arbitrary value, and hence the subagent has no other reasonable way to determine which index values to use. When index values have intrinsic meaning it is not expected that subagents will allocate their index values.
問題のインデックスが任意の値であるだけときにはインデックス配分が必要であることに注意してください。そうすれば、したがって、副代理店はどれが使用する値に索引をつけるかを決定する他のどんな合理的な方法も持っていません。 インデックス値に本質的な意味があると、副代理店がそれらのインデックス値を割り当てないと予想されます。
For example, RFC 1514's table of running software processes (hrSWRunTable) is indexed by the system's native process identifier (pid). A subagent implementing the row of hrSWRunTable corresponding to its own process would simply register the region defining that row's object instances without allocating index values.
例えば、システムの固有の過程識別子(pid)によってRFC1514の走行ソフトウェア処理(hrSWRunTable)のテーブルは索引をつけられます。 それ自身の過程に対応するhrSWRunTableの列を実行する副代理店は単にインデックス値を割り当てないでその列の物の例を定義する領域を登録するでしょう。
7.1.4.2.3. Examples
7.1.4.2.3. 例
Example 1:
例1:
A subagent implements an interface, and wishes to register a
single row of the RFC 2233 ifTable. It requests an allocation for
the index object "ifIndex", for a value that has never been
allocated (since ifIndex values must be unique). The master agent
returns the value "7".
副代理店はインタフェース、およびRFC2233ifTableの一つの列を示すという願望を実行します。 それはインデックス物の"ifIndex"のために配分を要求します、一度も割り当てられたことがない値のために(ifIndex値がユニークであるに違いないので)。 マスターエージェントは「7インチ」を値に返します。
The subagent now attempts to register row 7 of ifTable, by
specifying a MIB region in the agentx-Register-PDU of
1.3.6.1.2.1.2.2.1.[1-22].7. If the registration succeeds, no
further processing is required. The master agent will dispatch to
this subagent correctly.
副代理店は、現在、1.3.6.1.2.1.2.2.1.[1-22]のagentxレジスタPDU.7におけるMIB領域を指定することによってifTableの列7を示すのを試みます。 登録が成功するなら、どんなより遠い処理も必要ではありません。 マスターエージェントは正しくこの副代理店に急ぐでしょう。
If the registration failed with `duplicateRegistration', the
subagent should deallocate the failed index, request allocation of
a new index i, and attempt to register ifTable.[1-22].i, until
successful.
'duplicateRegistration'に応じて登録が失敗するなら、副代理店は失敗が索引をつけるdeallocate、新しいインデックスi、およびifTable.[1-22].iを登録する試みのうまくいくまでの要求配分に失敗するでしょうに。
Example 2:
例2:
This same subagent wishes to register ipNetToMediaTable rows
corresponding to its interface (ifIndex i). Due to the structure
of this table, no further index allocation need be done. The
subagent can register the MIB region ipNetToMediaTable.[1-4].i, It
is claiming responsibility for all rows of the table whose value
of ipNetToMediaIfIndex is i.
この同じ副代理店はインタフェース(ifIndex i)に対応するipNetToMediaTable列を示したがっています。 このテーブルの構造のため、さらなるインデックス配分を全くする必要はありません。 副代理店はMIB領域ipNetToMediaTable.[1-4].iを登録できて、ItはipNetToMediaIfIndexの値がiであるテーブルのすべての列に犯行声明を出しています。
Daniele, et al. Standards Track [Page 53] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[53ページ]。
Example 3:
例3:
A network device consists of a set of processors, each of which
accepts network connections for a unique set of IP addresses.
Further, each processor contains a subagent that implements
tcpConnTable. In order to represent tcpConnTable for the entire
managed device, the subagents need to share tcpConnTable.
ネットワーク装置は1セットのプロセッサから成ります。それはそれぞれユニークなIPアドレスのためのネットワーク接続を受け入れます。 さらに、各プロセッサはtcpConnTableを実行する副代理店を含んでいます。 全体の管理された装置のためにtcpConnTableを表すために、副代理店は、tcpConnTableを共有する必要があります。
In this case, no index allocation need be done at all. Each
subagent can register a MIB region of tcpConnTable.[1-5].a.b.c.d,
where a.b.c.d represents an unique IP address of the individual
processor.
この場合、全くインデックス配分をする必要はありません。 各副代理店はtcpConnTable.[1-5].a.b.c.dのMIB領域を登録できます。(そこでは、a.b.c.dは個々のプロセッサの固有のIPアドレスを表します)。
Each subagent is claiming responsibility for the region of
tcpConnTable where the value of tcpConnLocalAddress is a.b.c.d.
各副代理店はtcpConnLocalAddressの値がa.b.c.dであるtcpConnTableの領域に犯行声明を出しています。
Example 4:
例4:
The Application Management MIB (RFC 2564 [22]) uses two objects to
index several tables. A partial description of them is:
Application Management MIB、(RFC2564[22])は、数個のテーブルに索引をつけるのに2個の物を使用します。 それらの部分的な記述は以下の通りです。
applSrvIndex OBJECT-TYPE
SYNTAX Unsigned32 (1..'ffffffff'h)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"An applSrvIndex is the system-unique identifier
of an instance of a service. The value is unique
not only across all instances of a given service,
but also across all services in a system."
applSrvIndex OBJECT-TYPE SYNTAX Unsigned32('1ffffffff'h)のマックス-ACCESSの書き込み禁止のSTATUSの現在の記述、「applSrvIndexはサービスの例のシステムユニークな識別子である」、' 「値は与えられたサービスのすべての例の向こう側にユニークであるだけではなく、システムにおけるすべてのサービスの向こう側にもユニークです。」
applSrvName OBJECT-TYPE
SYNTAX SnmpAdminString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The human-readable name of a service. Where
appropriate, as in the case where a service can
be identified in terms of a single protocol, the
strings should be established names such as those
assigned by IANA and found in STD 2 [23], or
defined by some other authority. In some cases
private conventions apply and the string should
in these cases be consistent with these
non-standard conventions. An applicability
statement may specify the service name(s) to be
used."
「人間読み込み可能はサービスについて命名する」applSrvName OBJECT-TYPE SYNTAX SnmpAdminStringのマックス-ACCESSの書き込み禁止のSTATUSの現在の記述。 適切であるところでは、ストリングがただ一つのプロトコルでサービスを特定できるケースの中ようにIANAによって割り当てられて、STD2[23]で見つけられるか、またはある他の権威によって定義されたものなどの確立した名前であるべきです。 私設のコンベンションが適用して、ストリングがこれらの場合でそうするはずであるいくつかの場合では、これらの標準的でないコンベンションと一致してください。 「適用性証明は使用されるためにサービス名を指定するかもしれません。」
Daniele, et al. Standards Track [Page 54] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[54ページ]。
Since applSrvIndex is an arbitrary value, it would be reasonable
for subagents to allocate values for this index. applSrvName
however has intrinsic meaning and any values a subagent would use
should be known a priori, hence it is not reasonable for subagents
to allocate values of this index.
applSrvIndexが任意の値であるので、副代理店がこのインデックスのために値を割り当てるのは、妥当でしょう。しかしながら、applSrvNameには、本質的な意味があります、そして、副代理店が使用するどんな値も先験的に知られているべきです、そして、したがって、副代理店がこのインデックスの値を割り当てるのは、妥当ではありません。
7.1.5. Processing the agentx-Unregister-PDU
7.1.5. agentx-Unregister-PDUを処理します。
When the master agent receives an agentx-Unregister-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages". If as a result res.error is ` noAgentXError', processing continues as follows:
マスターエージェントがagentx-Unregister-PDUを受け取るとき、それは「AgentXの管理メッセージを処理し」て、セクション7.1で説明された一般的な処理を実行します。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
1) If u.subtree, u.priority, u.range_subid (and if u.range_subid is
not 0, u.upper_bound), and the indicated context do not match an
existing registration made during this session, the agentx-
Response-PDU is returned with res.error set to `
unknownRegistration'.
1) u.下位木、u.優先権、u.範囲_subid(u.範囲_subidが0でないなら、u.の上側の_は固まった)、および示された文脈が今会期中にされた既存の登録に合っていないなら、'unknownRegistration'に用意ができているres.errorでagentx応答-PDUを返します。
2) Otherwise, the agentx-Response-PDU is sent in reply with res.error
set to `noAgentXError', and the previous registration is removed
from the registration data store.
2) さもなければ、'noAgentXError'に用意ができているres.errorとの回答でagentx応答PDUを送ります、そして、登録データ・ストアから前の登録を取り除きます。
7.1.6. Processing the agentx-AddAgentCaps-PDU
7.1.6. agentx-AddAgentCaps-PDUを処理します。
When the master agent receives an agentx-AddAgentCaps-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages". If as a result res.error is ` noAgentXError', processing continues as follows:
マスターエージェントがagentx-AddAgentCaps-PDUを受け取るとき、それは「AgentXの管理メッセージを処理し」て、セクション7.1で説明された一般的な処理を実行します。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
1) The master agent adds this agent capabilities information to the
sysORTable for the indicated context. An agentx-Response-PDU is
sent in reply with res.error set to `noAgentXError'.
1) マスターエージェントは示された文脈のためにこのエージェント能力情報をsysORTableに加えます。 'noAgentXError'に用意ができているres.errorとの回答でagentx応答PDUを送ります。
7.1.7. Processing the agentx-RemoveAgentCaps-PDU
7.1.7. agentx-RemoveAgentCaps-PDUを処理します。
When the master agent receives an agentx-RemoveAgentCaps-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages". If as a result res.error is `noAgentXError', processing continues as follows:
マスターエージェントがagentx-RemoveAgentCaps-PDUを受け取るとき、それは「AgentXの管理メッセージを処理し」て、セクション7.1で説明された一般的な処理を実行します。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
1) If the combination of a.id and the optional a.context does not
represent a sysORTable entry that was added by this subagent
during this session, the agentx-Response-PDU is returned with
res.error set to `unknownAgentCaps'.
1) a.イドと任意のa.文脈の組み合わせがこの副代理店によって今会期中に加えられたsysORTableエントリーを表さないなら、'unknownAgentCaps'に用意ができているres.errorでagentx応答PDUを返します。
Daniele, et al. Standards Track [Page 55] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[55ページ]。
2) Otherwise the master agent deletes the corresponding sysORTable
entry and sends in reply the agentx-Response-PDU, with res.error
set to `noAgentXError'.
2) さもなければ、マスターエージェントは、対応するsysORTableエントリーを削除して、回答におけるres.errorとagentx応答PDUセットを'noAgentXError'に送ります。
7.1.8. Processing the agentx-Close-PDU
7.1.8. agentxの近いPDUを処理します。
When the master agent receives an agentx-Close-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages", with the exception that step 4) is not performed since the agentx-Close-PDU does may not contain a context field. If as a result res.error is `noAgentXError', processing continues as follows:
マスターエージェントがagentxの近いPDUを受け取るとき、セクション7.1で説明された一般的な処理を実行して、ステップ4)がagentxの近いPDUが実行されるので実行されないという例外がある「処理のAgentXの管理メッセージ」は文脈分野を含まないかもしれません。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
1) The master agent closes the AgentX session as described below, and
sends in reply the agentx-Response-PDU with res.error set to
`noAgentXError':
1) マスターエージェントはres.errorとagentx応答PDUセットを'noAgentXError'に下で説明されて、回答で送るAgentXセッションを終えます:
- All MIB regions that have been registered during this session
are unregistered, as described in section 7.1.5, "Processing
the agentx-Unregister-PDU".
- 登録されたすべてのMIB領域が今会期中に登録されていないです、セクション7.1.5で説明されるように、「agentx-Unregister-PDUを処理し」て。
- All index values allocated during this session are freed, as
described in section 7.1.3, "Processing the agentx-
IndexDeallocate-PDU".
- 「agentx- IndexDeallocate-PDUを処理し」て、今会期中に割り当てられたすべてのインデックス値がセクション7.1.3で説明されるように解放されます。
- All sysORID values that were registered during this session are
removed, as described in section 7.1.7, "Processing the
agentx-RemoveAgentCaps-PDU".
- 「agentx-RemoveAgentCaps-PDUを処理し」て、セクション7.1.7で説明されるように今会期中に示されたすべてのsysORID値を取り除きます。
The master agent does not maintain state for closed sessions. If a subagent wishes to re-establish a session after it has been closed, it needs to re-register MIB regions, agent capabilities, etc.
マスターエージェントは非公開審議のために状態を維持しません。 副代理店であるなら、それがあった後にセッションを復職させるという願望は終えられて、それは、MIB領域、エージェント能力などを再登録する必要があります。
7.1.9. Detecting Connection Loss
7.1.9. 接続の損失を検出します。
If a master agent is able to detect (from the underlying transport) that a subagent cannot receive AgentX PDUs, it should close all affected AgentX sessions as described in section 7.1.8, "Processing the agentx-Close-PDU", step 1).
マスターエージェントがそれを検出できるなら(基本的な輸送から)、副代理店はAgentX PDUsを受けることができないで、セクション7.1.8で説明されるようにすべての影響を受けるAgentXセッションに閉じるべきです、「agentxの近いPDUを処理し」て、ステップ1)。
7.1.10. Processing the agentx-Notify-PDU
7.1.10. agentxにPDUに通知しているのを処理します。
A subagent sending SNMPv1 trap information must map this into (minimally) a value of snmpTrapOID.0, as described in 3.1.2 of RFC 1908 [24].
副代理店送付SNMPv1罠情報はsnmpTrapOID.0の(最少量で)値にこれを写像しなければなりません、中で説明されるように3.1、.2、RFC1908[24]について。
Daniele, et al. Standards Track [Page 56] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[56ページ]。
When the master agent receives an agentx-Notify-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages". If as a result res.error is `noAgentXError', processing continues as follows:
マスターエージェントが受信する、agentxにPDUに通知してください、そして、それは「AgentXの管理メッセージを処理し」て、セクション7.1で説明された一般的な処理を実行します。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
1) If the first VarBind is sysUpTime.0;
1) 最初のVarBindがsysUpTime.0であるなら。
(a) if the second VarBind is not snmpTrapOID.0, res.error is set
to `processingError' and res.index to 2
(a) 第2VarBindがsnmpTrapOID.0でないなら、res.errorは2への'processingError'とres.indexに用意ができています。
(b) otherwise these two VarBinds are used as the first two
VarBinds within the generated notification.
(b) さもなければ、これらの2VarBindsが発生している通知の中の最初の2VarBindsとして使用されます。
2) If the first VarBind is not sysUpTime.0;
2) 最初のVarBindがsysUpTime.0でないなら。
(a) if the first VarBind is not snmpTrapOID.0, res.error is set
to `processingError' and res.index to 1
(a) 最初のVarBindがsnmpTrapOID.0でないなら、res.errorは1への'processingError'とres.indexに用意ができています。
(b) otherwise this VarBind is used for snmpTrapOID.0 within the
generated notification, and the master agent uses the current
value of sysUpTime.0 for the indicated context as sysUpTime.0
within the notification.
(b) さもなければ、このVarBindはsnmpTrapOID.0に発生している通知の中で使用されます、そして、マスターエージェントは示された文脈にsysUpTime.0として通知の中でsysUpTime.0の現行価値を使用します。
3) An agentx-Response-PDU is sent containing the original
VarBindList, and with res.error and res.index set as described
above. If res.error is `noAgentXError', notifications are sent
according to the implementation-specific configuration of the
master agent. If SNMPv1 Trap PDUs are generated, the recommended
mapping is as described in RFC 2089 [25]. If res.error indicates
an error in processing, no notifications are generated.
3) agentx応答PDUが上で説明されるオリジナルのVarBindListを含ませる、res.error、およびres.index setであります。 res.errorが'noAgentXError'であるなら、マスターエージェントの実現特有の構成に応じて、通知を送ります。 SNMPv1 Trap PDUsが発生するなら、お勧めのマッピングがRFC2089[25]で説明されるようにあります。 res.errorが処理における誤りを示すなら、通知は全く発生しません。
Note that the master agent's successful response indicates the
agentx-Notify-PDU was received and validated. It does not
indicate that any particular notifications were actually generated
or received by notification targets.
マスターエージェントのうまくいっている応答が、agentxがPDUに通知しているのが受け取られて、有効にされたのを示すことに注意してください。 それは、どんな特定の通知も通知目標によって実際に発生したか、または受け取られたのを示しません。
7.1.11. Processing the agentx-Ping-PDU
7.1.11. agentxピングPDUを処理します。
When the master agent receives an agentx-Ping-PDU, it performs the common processing described in section 7.1, "Processing AgentX Administrative Messages". If as a result res.error is ` noAgentXError', processing continues as follows:
マスターエージェントがagentxピングPDUを受け取るとき、それは「AgentXの管理メッセージを処理し」て、セクション7.1で説明された一般的な処理を実行します。 その結果、res.errorが'noAgentXError'であるなら、処理は以下の通り続きます:
Daniele, et al. Standards Track [Page 57] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[57ページ]。
1) An agentx-Response-PDU is sent in reply.
1) 回答でagentx応答PDUを送ります。
If a subagent does not receive a response to its pings, or if it is able to detect (from the underlying transport) that the master agent is not able to receive AgentX messages, then it eventually must initiate a new AgentX session, re-register its MIB regions, etc.
副代理店がピングへの応答を受けないか、それを検出できるなら(基本的な輸送から)マスターエージェントがAgentXメッセージを受け取ることができない、次に、結局新しいAgentXセッションを開始しなければならなくて、再レジスタがそのMIB領域であるなら、などです。
7.2. Processing Received SNMP Protocol Messages
7.2. 処理はSNMPプロトコルメッセージを受け取りました。
When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or SetRequest protocol message is received by the master agent, the master agent applies its access control policy.
SNMP GetRequest、GetNextRequest、GetBulkRequest、またはSetRequestプロトコルメッセージがマスターエージェントによって受け取られるとき、マスターエージェントはアクセス管理方針を適用します。
In particular, for SNMPv1 or SNMPv2c protocol messages, the master agent applies the Elements of Procedure defined in section 4.1 of STD 15, RFC 1157 [8] that apply to receiving entities. For SNMPv3, the master agent applies an Access Control Model, possibly the View-based Access Control Model (see RFC 2575 [15]), as described in section 3.1.2 and section 4.3 of RFC 2571 [1].
SNMPv1かSNMPv2cプロトコルメッセージに関して、特に、マスターエージェントはSTD15(実体を受けるのに適用されるRFC1157[8])のセクション4.1で定義されたProcedureのElementsを適用します。 SNMPv3に関して、マスターエージェントはAccess Control Modelを適用します、ことによるとViewベースのAccess Control Model。(RFC2575[15])を見てください、セクション3.1.2とセクション4.3のRFC2571[1]で説明されるように。
For SNMPv1 and SNMPv2c, the master agent uses the community string as an index into a local repository of configuration information that may include community profiles or more complex context information. For SNMPv3, the master agent uses the SNMP Context (see section 3.3.1 of RFC 2571 [1]) for these purposes.
SNMPv1とSNMPv2cのために、マスターエージェントはインデックスとして共同体プロフィールを含むかもしれない設定情報か、より複雑な文脈情報の地方の倉庫に共同体ストリングを使用します。 SNMPv3に、マスターエージェントはSNMP Contextを使用します。(これらの目的のための.1セクション3.3RFC2571[1])を見てください。
If application of the access control policy results in a valid SNMP request PDU, then an SNMP Response-PDU is constructed from information gathered in the exchange of AgentX PDUs between the master agent and one or more subagents. Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents, marshal the subagent responses, and construct an SNMP response PDU.
アクセス管理方針の適用が有効なSNMP要求PDUをもたらすなら、SNMP Response-PDUはマスターエージェントと1つ以上の副代理店の間にAgentX PDUsの交換で集められた情報から組み立てられます。 SNMP要求PDUの領収書と初期の合法化のときに、マスターエージェントは適切な副代理店にAgentX PDUsを派遣して、副代理店応答を整理して、SNMP応答PDUを組み立てるために以下で説明された手順を用います。
7.2.1. Dispatching AgentX PDUs
7.2.1. AgentX PDUsを派遣します。
Upon receipt and initial validation of an SNMP request PDU, a master agent uses the procedures described below to dispatch AgentX PDUs to the proper subagents.
SNMP要求PDUの領収書と初期の合法化のときに、マスターエージェントは適切な副代理店にAgentX PDUsを派遣するために以下で説明された手順を用います。
General Rules of Procedure
一般手続き規則
While processing a particular SNMP request, the master agent may send one or more AgentX PDUs on one or more subagent sessions. The following rules of procedure apply in general to the AgentX master agent. PDU-specific rules are listed in the applicable sections.
特定のSNMP要求を処理している間、マスターエージェントは1つ以上の副代理店セッションに1AgentX PDUsを送るかもしれません。 一般に、以下の手続き規則はAgentXマスターエージェントに適用されます。 PDU特有の規則は適切なセクションで記載されています。
Daniele, et al. Standards Track [Page 58] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[58ページ]。
1) Honoring the registry
1) 登録を光栄に思います。
Because AgentX supports registration of duplicate and overlapping
regions, it is possible for the master agent to obtain a value for
a requested varbind from within multiple registered MIB regions.
AgentXが写しと重なっている領域の登録を支持するので、マスターエージェントが複数の登録されたMIB領域から値を要求されたvarbindに得るのは、可能です。
The master agent must ensure that the value (or exception)
actually returned in the SNMP response PDU is taken from the
authoritative region (as defined in section 7.1.4.1, "Handling
Duplicate and Overlapping Subtrees").
マスターエージェントは、実際にSNMP応答PDUで返された値(または、例外)が正式の領域から取られるのを保証しなければなりません(セクション7.1.4.1と、「取り扱い写しと重なっている下位木」で定義されるように)。
2) GetNext and GetBulk Processing
2) GetNextとGetBulk処理
The master agent may choose to send agentx-Get-PDUs while
servicing an SNMP GetNextRequest-PDU. The master agent may choose
to send agentx-Get-PDUs or agentx-GetNext-PDUs while servicing an
SNMP GetBulkRequest-PDU. One possible reason for this would be if
the current iteration has targeted instance-level registrations.
マスターエージェントは、agentxがPDUsを手に入れた状態でSNMP GetNextRequest-PDUを調整している間、発信するのを選ぶかもしれません。 マスターエージェントが、agentxにPDUsを手に入れた状態で発信するのを選ぶかもしれませんか、またはagentx-GetNext-PDUsは整備点検をゆったり過ごします。SNMP GetBulkRequest-PDU。 この1つの可能な理由は現在の繰り返しが例レベル登録証明書を狙ったかどうかということでしょう。
The master agent may choose to "scope" the possible instances
returned by a subagent by specifying an ending OID in the
SearchRange. If such scoping is used, typically the ending OID
would be the first lexicographical successor to the target region
that was registered on a session other than the target session.
Regardless of this choice, rule (1) must be obeyed.
マスターエージェントは、SearchRangeで終わりのOIDを指定することによって、副代理店によって返された可能な例を「範囲」に選ぶかもしれません。 そのような見るのが使用されているなら、終わりのOIDは第1代通常、目標セッション以外のセッションのときに登録された目標領域の辞書編集の後継者でしょう。 この選択にかかわらず、規則(1)に従わなければなりません。
The master agent may require multiple request-response iterations
on the same subagent session, to determine the final value of all
requested variables.
マスターエージェントは、すべての検査値が変数を要求したことを決定するために同じ副代理店セッションの複数の要求応答繰り返しを必要とするかもしれません。
All AgentX PDUs sent on the session while processing a given SNMP
request must contain identical values of transactionID. Each
different SNMP request processed by the master agent must present
a unique value of transactionID (within the limits of the 32-bit
field) to the session.
与えられたSNMP要求を処理している間のセッションの転送されたすべてのAgentX PDUsがtransactionIDの同じ値を含まなければなりません。 マスターエージェントによって処理されたそれぞれの異なったSNMP要求はセッションまでtransactionID(32ビットの分野の限界の中の)のユニークな値を提示しなければなりません。
3) Number and order of variables sent per AgentX PDU
3) AgentX PDU単位で送られた変数の数と注文
For Get/GetNext/GetBulk operations, at any stage of the possibly
iterative process, the master agent may need to dispatch several
SearchRanges to a particular subagent session. The master agent
may send one, some, or all of the SearchRanges in a single AgentX
PDU.
Get/GetNext/GetBulk操作のために、ことによると繰り返しの過程のどんな段階でも、マスターエージェントは、特定の副代理店セッションまで数個のSearchRangesを派遣する必要があるかもしれません。 マスターエージェントは独身のAgentX PDUでSearchRangesの1、いくつか、またはすべてを送るかもしれません。
The master agent must ensure that the correct contents and
ordering of the VarBindList in the SNMP Response-PDU are
maintained.
マスターエージェントは、SNMP Response-PDUでのVarBindListの正しいコンテンツと注文が維持されるのを保証しなければなりません。
Daniele, et al. Standards Track [Page 59] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[59ページ]。
The following rules govern the number of VarBinds in a given
AgentX PDU:
以下の規則は与えられたAgentX PDUのVarBindsの数を決定します:
a) The subagent must support processing of AgentX PDUs with
multiple VarBinds.
a) 副代理店は複数のVarBindsとのAgentX PDUsのサポート処理がそうしなければなりません。
b) When processing an SNMP Set request, the master agent must
send all of the VarBinds applicable to a particular subagent
session in a single agentx-TestSet-PDU.
b) SNMP Set要求を処理するとき、マスターエージェントは独身のagentx-TestSet-PDUで特定の副代理店セッションに適切なVarBindsのすべてを送らなければなりません。
c) When processing an SNMP Get, GetNext, or GetBulk request,
the master agent may send a single AgentX PDU on the session
with all applicable VarBinds, or multiple PDUs with single
VarBinds, or something in between those extremes. The
determination of which method to use in a particular case is
implementation-specific.
c) SNMP Get、GetNext、またはGetBulk要求を処理するとき、マスターエージェントはそれらの極端の間ですべての適切なVarBindsとのセッション、または独身のVarBinds、または何かがある複数のPDUsに独身のAgentX PDUを送るかもしれません。 特定の場合にどの方法を使用したらよいかに関する決断は実現特有です。
4) Timeout Values
4) タイムアウト値
The master agent chooses a timeout value for each MIB region being
queried, which is
マスターエージェントは質問されるそれぞれのMIB領域へのタイムアウト値を選んで、どれがありますか?
a) the value specified during registration of the MIB region,
if it was non-zero
a) それが非ゼロであったならMIB領域の登録の間に指定された値
b) otherwise, the value specified during establishment of the
session in which this region was subsequently registered, if
that value was non-zero
b) さもなければ、値はこの領域が次に登録されたセッションの設立の間、指定しました、その値が非ゼロであったなら
c) otherwise, or, if the specified value is not practical, the
master agent's implementaton-specific default value
c)、そうでなさ、規定値が実用的でないときにマスターエージェントのimplementaton特有のデフォルト値
When an AgentX PDU that references multiple MIB regions is
dispatched, the timeout value used for the PDU is the maximum
value of the timeouts so determined for each of the referenced MIB
regions.
AgentX PDUであるときに、参照倍数MIB領域が派遣されて、PDUに使用されるタイムアウト値がタイムアウトの最大値であることはそれぞれの参照をつけられたMIB領域にそう決定しました。
5) Context
5) 文脈
If the master agent has determined that a specific non-default
context is associated with the SNMP request PDU, that context is
encoded into the AgentX PDU's context field and the
NON_DEFAULT_CONTEXT bit is set in h.flags.
マスターエージェントが、特定の非デフォルト文脈がSNMP要求PDUに関連していると決心していたなら、その文脈はAgentX PDUの文脈分野にコード化されます、そして、NON_DEFAULT_CONTEXTビットはh.旗で設定されます。
Otherwise, no context Octet String is added to the PDU, and the
NON_DEFAULT_CONTEXT bit is cleared.
さもなければ、文脈がないOctet StringはPDUに加えられます、そして、NON_DEFAULT_CONTEXTビットはきれいにされます。
Daniele, et al. Standards Track [Page 60] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[60ページ]。
7.2.1.1. agentx-Get-PDU
7.2.1.1. agentxはPDUを手に入れます。
Each variable binding in the SNMP request PDU is processed as follows:
SNMP要求PDUの各変項束縛は以下の通り処理されます:
(1) Identify the target MIB region.
(1) 目標MIB領域を特定してください。
Within a lexicographically ordered set of registered MIB
regions, valid for the indicated context, locate the
authoritative region (according to section 7.1.4.1, "Handling
Duplicate and Overlapping Subtrees") that contains the binding's
name.
中では、辞書編集の順序集合の示された文脈に、有効な登録されたMIB領域が結合の名前を含む正式の領域(セクション7.1.4.1と、「取り扱い写しと重なっている下位木」に従って)の場所を見つけます。
(2) If no such region exists, the variable binding is not processed
further, and its value is set to `noSuchObject'.
(2) 何かそのような領域が存在していないなら、変項束縛はさらに処理されません、そして、値は'noSuchObject'に設定されます。
(3) Identify the subagent session in which this region was
registered, termed the target session.
(3) 目標セッションと呼ばれて、この領域が登録された副代理店セッションを特定してください。
(4) If this is the first variable binding to be dispatched over the
target session in a request-response exchange entailed in the
processing of this management request:
(4) これがこの管理の処理で伴われた要求応答交換における目標セッションの間に派遣されるべき最初の変項束縛であるなら、以下を要求してください。
- Create an agentx-Get-PDU for this session, with the header
fields initialized as described above (see section 6.1,
"AgentX PDU Header").
- 上で説明されるように初期化されたagentxがヘッダーとのこのセッションのためにPDUを手に入れている分野を作成してください(セクション6.1、「AgentX PDUヘッダー」を見てください)。
(5) Add a SearchRange to the end of the target session's PDU for
this variable binding.
(5) この変項束縛のために目標セッションのPDUの端にSearchRangeを加えてください。
- The variable binding's name is encoded into the starting OID.
- 変項束縛の名前は始めのOIDにコード化されます。
- The ending OID is encoded as null.
- 終わりのOIDはヌルとしてコード化されます。
7.2.1.2. agentx-GetNext-PDU
7.2.1.2. agentx-GetNext-PDU
Each variable binding in the SNMP request PDU is processed as follows:
SNMP要求PDUの各変項束縛は以下の通り処理されます:
(1) Identify the target MIB region.
(1) 目標MIB領域を特定してください。
Within a lexicographically ordered set of registered MIB
regions, valid for the indicated context, locate the
authoritative region (according to section 7.1.4.1, "Handling
Duplicate and Overlapping Subtrees") that
中では、辞書編集の順序集合の示された文脈に、有効な登録されたMIB領域が正式の領域(セクション7.1.4.1と、「取り扱い写しと重なっている下位木」に従って)の場所を見つける、それ
a) contains the variable binding's name and is not a fully
qualified instance, or
またはa)が変項束縛の名前を含んでいて、完全な適切な例であるというわけではない。
Daniele, et al. Standards Track [Page 61] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[61ページ]。
b) is the first lexicographical successor to the variable
binding's name.
b)は第1代変項束縛の名前の辞書編集の後継者です。
(2) If no such region exists, the variable binding is not processed
further, and its value is set to `endOfMibView'.
(2) 何かそのような領域が存在していないなら、変項束縛はさらに処理されません、そして、値は'endOfMibView'に設定されます。
(3) Identify the subagent session in which this region was
registered, termed the target session.
(3) 目標セッションと呼ばれて、この領域が登録された副代理店セッションを特定してください。
(4) If this is the first variable binding to be dispatched over the
target session in a request-response exchange entailed in the
processing of this management request:
(4) これがこの管理の処理で伴われた要求応答交換における目標セッションの間に派遣されるべき最初の変項束縛であるなら、以下を要求してください。
- Create an agentx-GetNext-PDU for the session, with the header
fields initialized as described above (see section 6.1,
"AgentX PDU Header").
- セッションのためにagentx-GetNext-PDUを作成してください、上で説明されるように初期化されたヘッダーフィールドで(セクション6.1、「AgentX PDUヘッダー」を見てください)。
(5) Add a SearchRange to the end of the target session's agentx-
GetNext-PDU for this variable binding.
(5) この変項束縛のために目標セッションのagentx- GetNext-PDUの端にSearchRangeを加えてください。
- if (1a) applies, the variable binding's name is encoded into
the starting OID, and the OID's "include" field is set to 0.
- (という1a)は適用されます、変項束縛名前が始めのOIDにコード化されて、OIDの「包含」分野が0に設定されるなら。
- if (1b) applies, the target region's r.subtree is encoded
into the starting OID, and its "include" field is set to 1.
(This is the recommended method. An implementation may
choose to use a Starting OID value that precedes r.subtree,
in which case the include bit must be 0. A starting OID
value that succeeds r.subtree is not permitted.)
- (1b)が適用されるなら、目標領域r.の下位木は始めのOIDにコード化されます、そして、「包含」分野は1に設定されます。 (これはお勧めの方法です。 実現は、r.下位木に先行するStarting OID値を使用するのを選ぶかもしれません、その場合、インクルードビットが0であるに違いありません。 r.下位木を引き継ぐ始めのOID値は受入れられません。)
- the Ending OID for the SearchRange is encoded to be either
NULL, or a value that lexicographically succeeds the Starting
OID. This is an implementation-specific choice depending on
how the master agent wishes to "scope" the possible returned
instances.
- SearchRangeのためのEnding OIDは、辞書編集にStarting OIDを引き継ぐNULLか値のどちらかになるようにコード化されます。 これはマスターエージェントがどう「範囲」に可能な返された例を願っているか次第であるこの実現特有の選択です。
7.2.1.3. agentx-GetBulk-PDU
7.2.1.3. agentx-GetBulk-PDU
(Note: The outline of the following procedure is based closely on section 4.2.3, "The GetBulkRequest-PDU" of RFC 1905 [13]. Please refer to it for details on the format of the SNMP GetBulkRequest-PDU itself.)
以下の手順のアウトラインは密接にセクション4.2.3に基づいています、RFCの「GetBulkRequest-PDU」1905[13]。(注意: SNMP GetBulkRequest-PDU自身の形式に関する詳細についてそれを参照してください。)
Daniele, et al. Standards Track [Page 62] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[62ページ]。
Each variable binding in the request PDU is processed as follows:
要求PDUにおける各変項束縛は以下の通り処理されます:
(1) Identify the authoritative target region and target session,
exactly as described for the agentx-GetNext-PDU (see section
7.2.1.2, "agentx-GetNext-PDU").
(1) ちょうどagentx-GetNext-PDUのために説明されるように正式の目標領域と目標セッションを特定してください、(.2、"agentx-GetNext-PDU"が、7.2に.1を区分するのを見る、)
(2) If this is the first variable binding to be dispatched over the
target session in a request-response exchange entailed in the
processing of this management request:
(2) これがこの管理の処理で伴われた要求応答交換における目標セッションの間に派遣されるべき最初の変項束縛であるなら、以下を要求してください。
- Create an agentx-GetBulk-PDU for the session, with the header
fields initialized as described above (see section 6.1,
"AgentX PDU Header").
- セッションのためにagentx-GetBulk-PDUを作成してください、上で説明されるように初期化されたヘッダーフィールドで(セクション6.1、「AgentX PDUヘッダー」を見てください)。
(3) Add a SearchRange to the end of the target session's agentx-
GetBulk-PDU for this variable binding, as described for the
agentx-GetNext-PDU. If the variable binding was a non-repeater
in the original request PDU, it must be a non-repeater in the
agentx-GetBulk-PDU.
(3) この変項束縛のために目標セッションのagentx- GetBulk-PDUの端にSearchRangeを加えてください、agentx-GetNext-PDUのために説明されるように。 変項束縛がオリジナルの要求PDUの非リピータであったなら、それはagentx-GetBulk-PDUの非リピータであるに違いありません。
The value of g.max_repetitions in the agentx-GetBulk-PDU may be less than (but not greater than) the value in the original request PDU.
agentx-GetBulk-PDUのg.最大_反復の値が、より少ないかもしれない、(よりすばらしくない、)、オリジナルの要求PDUの値。
The master agent may make such alterations due to simple sanity checking, optimizations for the current iteration based on the registry, the maximum possible size of a potential Response-PDU, known constraints of the AgentX transport, or any other implementation-specific constraint.
マスターエージェントは簡単な正気を伴うそのような変更を照合、登録に基づく現在の繰り返しのための最適化、潜在的Response-PDUの最大の可能なサイズ、AgentX輸送の知られている規制、またはいかなる他の実現特有の規制にもするかもしれません。
7.2.1.4. agentx-TestSet-PDU
7.2.1.4. agentx-TestSet-PDU
AgentX employs test-commit-undo-cleanup phases to achieve "as if simultaneous" semantics of the SNMP SetRequest-PDU within the extensible agent. The initial phase involves the agentx-TestSet-PDU.
AgentXは、広げることができるエージェントの中で「まるで同時であるかのように」SNMP SetRequest-PDUの意味論を達成するのに試しにアンドゥクリーンアップを遂行しているフェーズを使います。 初期位相はagentx-TestSet-PDUにかかわります。
Each variable binding in the SNMP request PDU is processed in order, as follows:
SNMP要求PDUの各変項束縛は以下の通りオーダーで処理されます:
(1) Identify the target MIB region and target session exactly as
described in section 7.2.1.1, "agentx-Get-PDU", step 1).
(1) セクション7.2.1におけるちょうど説明されるとしての「agentxはPDUを手に入れる」という.1が1を)踏む目標MIB領域と目標セッションを特定してください。
Within a lexicographically ordered set of OID ranges, valid for
the indicated context, locate the authoritative range that
contains the variable binding's name.
中では、辞書編集の順序集合の示された文脈に、有効なOID範囲が変項束縛の名前を含む正式の範囲の場所を見つけます。
(2) If no such target region exists, this variable binding fails
with an error of `notWritable'. Processing is complete for this
request.
(2) 何かそのような目標領域が存在していないなら、'notWritable'の誤りに応じて、この変項束縛は失敗します。 この要求に、処理は完全です。
Daniele, et al. Standards Track [Page 63] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[63ページ]。
(3) If this is the first variable binding to be dispatched over the
target session in a request-response exchange entailed in the
processing of this management request:
(3) これがこの管理の処理で伴われた要求応答交換における目標セッションの間に派遣されるべき最初の変項束縛であるなら、以下を要求してください。
- create an agentx-TestSet-PDU for the session, with the header
fields initialized as described above (see section 6.1,
"AgentX PDU Header").
- セッションのためにagentx-TestSet-PDUを作成してください、上で説明されるように初期化されたヘッダーフィールドで(セクション6.1、「AgentX PDUヘッダー」を見てください)。
(4) Add a VarBind to the end of the target session's PDU for this
variable binding, as described in section 5.4, "Value
Representation".
(4) この変項束縛のために目標セッションのPDUの端にVarBindを加えてください、セクション5.4、「値の表現」で説明されるように。
Note that all VarBinds applicable to a given session must be sent in a single agentx-TestSet-PDU.
独身のagentx-TestSet-PDUで与えられたセッションに適切なすべてのVarBindsを送らなければならないことに注意してください。
7.2.1.5. Dispatch
7.2.1.5. 発信
A timeout value is calculated for each PDU to be sent, which is the maximum value of the timeouts determined for each of the PDU's SearchRanges (as described above in section 7.2.1, "Dispatching AgentX PDUs", item 4). Each pending PDU is mapped (via its h.sessionID value) to a particular transport domain/endpoint, as described in section 8 (Transport Mappings).
タイムアウト値は各送られるべきPDUのために計算されます(セクション7.2.1、「急ぎAgentX PDUs」項目4で上で説明されるように)。(PDUはそれぞれのPDUのSearchRangesのために決定するタイムアウトの最大値です)。 それぞれの未定のPDUは特定の輸送ドメイン/終点に写像されます(h.sessionID価値で)、セクション8(輸送Mappings)で説明されるように。
7.2.2. Subagent Processing
7.2.2. 副代理店処理
A subagent initially processes a received AgentX PDU as follows:
副代理店は初めは、以下の容認されたAgentX PDUを処理します:
- If the received PDU is an agentx-Response-PDU:
- 容認されたPDUがagentx応答PDUであるなら:
1) If there are any errors parsing or interpreting the PDU, it is
silently dropped.
1) 何か誤り構文解析があれば、PDUを解釈して、落とされて、それは静かにあります。
2) Otherwise the response is matched to the original request via
h.packetID, and handled in an implementation-specific manner. For
example, if this response indicates an error attempting to
register a MIB region, the subagent may wish to register a
different region, or log an error and halt, etc.
2) さもなければ、応答は、h.packetIDを通してオリジナルの要求に合わせられていて、実現特有の方法で扱われます。 この応答が、副代理店が異なった領域を登録したいか、誤りを登録して、または誤りが、MIB領域を登録するのを試みる場合、停止したがっているかもしれないのを例えば示すなら、などです。
- If the received PDU is any other type:
- 容認されたPDUがいかなる他のであるも、タイプしてください:
1) an agentx-Response-PDU is created whose header fields are
identical to the received request PDU except that h.type is set to
Response, res.error to `noError', res.index to 0, and the
VarBindList to null.
1) h.タイプがResponse、'noError'へのres.error、0へのres.index、およびヌルへのVarBindListに用意ができているのを除いて、ヘッダーフィールドが容認された要求PDUと同じであるagentx応答PDUは作成されます。
2) If the received PDU cannot be parsed, res.error is set to
`parseError'.
2) 容認されたPDUを分析できないなら、res.errorは'parseError'に用意ができています。
Daniele, et al. Standards Track [Page 64] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[64ページ]。
3) Otherwise, if h.sessionID does not correspond to a currently
established session, res.error is set to `notOpen'.
3) さもなければ、h.sessionIDが現在確立したセッションに対応していないなら、res.errorは'notOpen'に用意ができています。
4) At this point, if res.error is not `noError', the received PDU is
not processed further. If the received PDU's header was
successfully parsed, the AgentX-Response-PDU is sent in reply. If
the received PDU's header was not successfully parsed or for some
other reason the subagent cannot send a reply, processing is
complete.
4) ここに、容認されたPDUはres.errorが'noError'でないなら、さらに処理されません。 首尾よく容認されたPDUのヘッダーを分析したなら、回答でAgentX応答PDUを送ります。 容認されたPDUのヘッダーが首尾よく分析されないか、副代理店が返信できないある他の理由であったなら、処理は完全です。
7.2.3. Subagent Processing of agentx-Get, GetNext, GetBulk-PDUs
7.2.3. agentx得ることの副代理店処理、GetNext、GetBulk-PDUs
A conformant AgentX subagent must support the agentx-Get, -GetNext, and -GetBulk PDUs, and must support multiple variables being supplied in each PDU.
conformant AgentX副代理店は、agentx得る、-GetNext、および-GetBulk PDUsを支持しなければならなくて、各PDUで供給される複数の変数を支持しなければなりません。
When a subagent receives an agentx-Get-, GetNext-, or GetBulk-PDU, it performs the indicated management operations and returns an agentx- Response-PDU.
-副代理店がagentxを受けたら得てください。-GetNext、またはGetBulk-PDU、それは示された管理操作を実行して、agentx応答-PDUを返します。
Each SearchRange in the request PDU's SearchRangeList is processed as described below, and a VarBind is added in the corresponding location of the agentx-Response-PDU's VarbindList. If processing should fail for any reason not described below, res.error is set to `genErr', res.index to the index of the failed SearchRange, the VarBindList is reset to null, and this agentx-Response-PDU is returned to the master agent.
要求PDUのSearchRangeListの各SearchRangeは以下で説明されるように処理されます、そして、VarBindはagentx応答PDU VarbindListの対応する位置で加えられます。 処理が以下で説明されなかった少しの理由でも失敗するべきであり、res.errorが'genErr'、失敗したSearchRangeのインデックスへのres.indexに用意ができて、ヌルにVarBindListをリセットして、このagentx応答PDUをマスターエージェントに返すなら。
7.2.3.1. Subagent Processing of the agentx-Get-PDU
7.2.3.1. agentxがPDUを手に入れることの副代理店処理
Upon the subagent's receipt of an agentx-Get-PDU, each SearchRange in the request is processed as follows:
副代理店の領収書、agentxにPDUを手に入れてください、そして、要求における各SearchRangeは以下の通り処理されます:
(1) The starting OID is copied to v.name.
(1) 始めのOIDはv.名にコピーされます。
(2) If the starting OID exactly matches the name of a variable
instantiated by this subagent within the indicated context and
session, v.type and v.data are encoded to represent the
variable's syntax and value, as described in section 5.4, "Value
Representation".
(2) 始めのOIDがまさに示された文脈とセッション対タイプのときにこの副代理店によって例示された変数の名前を合わせて、変数の構文と値を表すためにデータに対してコード化されるなら、セクション5.4で説明されるように「表現を評価してください。」
(3) Otherwise, if the starting OID does not match the object
identifier prefix of any variable instantiated within the
indicated context and session, the VarBind is set to
`noSuchObject', in the manner described in section 5.4, "Value
Representation".
(3) さもなければ、始めのOIDが示された文脈とセッション中に例示されたどんな変数の物の識別子接頭語にも合わないなら、VarBindは'noSuchObject'に用意ができています、セクション5.4、「値の表現」で説明された方法で。
Daniele, et al. Standards Track [Page 65] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[65ページ]。
(4) Otherwise, the VarBind is set to `noSuchInstance' in the manner
described in section 5.4, "Value Representation".
(4) さもなければ、VarBindはセクション5.4、「値の表現」で説明された方法による'noSuchInstance'へのセットです。
7.2.3.2. Subagent Processing of the agentx-GetNext-PDU
7.2.3.2. agentx-GetNext-PDUの副代理店処理
Upon the subagent's receipt of an agentx-GetNext-PDU, each SearchRange in the request is processed as follows:
副代理店のagentx-GetNext-PDUの領収書に、要求における各SearchRangeは以下の通り処理されます:
(1) The subagent searches for a variable within the
lexicographically ordered list of variable names for all
variables it instantiates (without regard to registration of
regions) within the indicated context and session, as follows:
(1) 副代理店はそれが示された文脈とセッション中に例示する(領域の登録への尊敬なしで)すべての変数のために変数名の辞書編集の規則正しいリストの中で変数を捜し求めます、以下の通りです:
- if the "include" field of the starting OID is 0, the
variable's name is the closest lexicographical successor to
the starting OID.
- 始めのOIDの「包含」分野が0であるなら、変数の名前は始めのOIDの最も近い辞書編集の後継者です。
- if the "include" field of the starting OID is 1, the
variable's name is either equal to, or the closest
lexicographical successor to, the starting OID.
- 始めのOIDの「インクルード」分野が1であるなら、変数の名前が等しくて、最も近い辞書編集の後継者である、始めのOID。
- If the ending OID is not null, the variable's name
lexicographically precedes the ending OID.
- 終わりのOIDがヌルでないなら、変数の名前は辞書編集に終わりのOIDに先行します。
If a variable is successfully located, v.name is set to that
variable's name. v.type and v.data are encoded to represent the
variable's syntax and value, as described in section 5.4, "Value
Representation".
変数が首尾よく見つけられているなら、v.名はその変数の名前に設定されます。v.タイプとv.データは、変数の構文を表して、セクション5.4で説明されるように「表現を評価してください」と評価するためにコード化されます。
(2) If the subagent cannot locate an appropriate variable, v.name is
set to the starting OID, and the VarBind is set to `
endOfMibView', in the manner described in section 5.4, "Value
Representation".
(2) 副代理店が適切な変数の場所を見つけることができないで、v.名が始めのOIDに設定されて、VarBindがセクション5.4で説明された方法で'endOfMibView'に用意ができているなら、「表現を評価してください。」
7.2.3.3. Subagent Processing of the agentx-GetBulk-PDU
7.2.3.3. agentx-GetBulk-PDUの副代理店処理
A maximum of N + (M * R) VarBinds are returned, where
最大(M*R)VarBindsが返されるN+、どこ
N equals g.non_repeaters,
M equals g.max_repetitions, and
R is (number of SearchRanges in the GetBulk request) - N.
Rは(GetBulk要求における、SearchRangesの数)です--Nはg.の非_のリピータと等しいです、そして、Mはg.最大_反復と等しいです、そして、N。
The first N SearchRanges are processed exactly as for the agentx- GetNext-PDU.
最初のN SearchRangesがちょうどagentx- GetNext-PDUのように処理されます。
If M and R are both non-zero, the remaining R SearchRanges are processed iteratively to produce potentially many VarBinds. For each iteration i, such that i is greater than zero and less than or equal
MとRがともに非ゼロに合わせるなら、残っているR SearchRangesは、潜在的に多くのVarBindsを生産するために繰り返しに処理されます。 各繰り返しi、iがゼロよりすばらしくて、以下か等しいようなもののために
Daniele, et al. Standards Track [Page 66] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[66ページ]。
to M, and for each repeated SearchRange s, such that s is greater than zero and less than or equal to R, the (N+((i-1)*R)+s)-th VarBind is added to the agentx-Response-PDU as follows:
sがM、およびそれぞれの繰り返されたSearchRange sゼロ以上とR、(N+(i-1)*R)より+s)以下である、-、第VarBindは以下のagentx応答PDUに加えられます:
1) The subagent searches for a variable within the
lexicographically ordered list of variable names for all
variables it instantiates (without regard to registration of
regions) within the indicated context and session, for which
the following are all true:
1) 副代理店はそれが以下がすべて本当である示された文脈とセッション中に例示する(領域の登録への尊敬なしで)すべての変数のために変数名の辞書編集の規則正しいリストの中で変数を捜し求めます:
- The variable's name is the (i)-th lexicographical successor
to the (N+s)-th requested OID.
- 変数の名前がそうである、(i)、-、(N+s)の辞書編集の第後継者、-、要求された第OID。
(Note that if i is 0 and the "include" field is 1, the
variable's name may be equivalent to, or the first
lexicographical successor to, the (N+s)-th requested OID.)
(変数の名前がiが0であり、「インクルード」分野が1であるなら、相当していて第1代辞書編集の後継者であるかもしれないことに注意してください、(N+s)、-、第要求されたOID)。
- If the ending OID is not null, the variable's name
lexicographically precedes the ending OID.
- 終わりのOIDがヌルでないなら、変数の名前は辞書編集に終わりのOIDに先行します。
If all of these conditions are met, v.name is set to the located
variable's name. v.type and v.data are encoded to represent the
variable's syntax and value, as described in section 5.4, "Value
Representation".
これらの状態のすべてが会われるなら、v.名は見つけられた変数の名前に設定されます。v.タイプとv.データは、変数の構文を表して、セクション5.4で説明されるように「表現を評価してください」と評価するためにコード化されます。
2) If no such variable exists, the VarBind is set to `
endOfMibView' as described in section 5.4, "Value
Representation". v.name is set to v.name of the (N+((i-
2)*R)+s)-th VarBind unless i is currently 1, in which case it
is set to the value of the starting OID in the (N+s)-th
SearchRange.
2) そのような変数が全く存在していないなら、VarBindはセクション5.4、「値の表現」で説明されるように'endOfMibView'に用意ができています。v.名は(N+ (i2)*R)+sのv.名に設定されます)、-、どれがそれをケースに入れるかで現在iが1でない、VarBindが(N+s)の始めのOIDの値に第用意ができている、-、第SearchRange。
Note that further iterative processing should stop if
さらなる繰り返しの処理が止まるべきであることに注意してください。
- For any iteration i, all s values of v.type are `
endOfMibView'.
- どんな繰り返しiのためにも、v.タイプのすべてのs値が'endOfMibView'です。
- An AgentX transport constraint or other implementation-
specific constraint is reached.
- AgentX輸送規制か他の実現の特定の規制に達しています。
7.2.4. Subagent Processing of agentx-TestSet, -CommitSet, -UndoSet,
-CleanupSet-PDUs
7.2.4. agentx-TestSet、-CommitSet、-UndoSet、-CleanupSet-PDUsの副代理店処理
A conformant AgentX subagent must support the agentx-TestSet, -CommitSet, -UndoSet, and -CleanupSet PDUs, and must support multiple variables being supplied in the agentx-TestSet-PDU.
conformant AgentX副代理店は、agentx-TestSet、-CommitSet、-UndoSet、および-CleanupSet PDUsを支持しなければならなくて、agentx-TestSet-PDUで供給される複数の変数を支持しなければなりません。
Daniele, et al. Standards Track [Page 67] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[67ページ]。
These four PDUs are used to collectively perform the indicated management operation. An agentx-Response-PDU is sent in reply to each of the PDUs (except -CleanupSet), to inform the master agent of the state of the operation.
これらの4PDUsが、示された管理操作をまとめて実行するのに使用されます。 操作の状態についてマスターエージェントに知らせるためにそれぞれのPDUs(-CleanupSetを除いた)に対してagentx応答PDUを送ります。
The master agent must serialize Set transactions for each session. That is, a session need not handle multiple concurrent Set transactions.
マスターエージェントは各セッションのためにSet取引を連載しなければなりません。 すなわち、セッションは複数の同時発生のSet取引を扱う必要はありません。
These Response-PDUs do not contain a VarBindList.
これらのResponse-PDUsはVarBindListを含んでいません。
7.2.4.1. Subagent Processing of the agentx-TestSet-PDU
7.2.4.1. agentx-TestSet-PDUの副代理店処理
Upon the subagent's receipt of an agentx-TestSet-PDU, each VarBind in the PDU is validated until they are all successful, or until one fails, as described in section 4.2.5 of RFC 1905 [13]. The subagent validates variables with respect to the context and session indicated in the testSet-PDU.
副代理店のagentx-TestSet-PDUの領収書では、それらがすべてうまくいっているか、または1つが失敗するまで、PDUの各VarBindは有効にされます、.5セクション4.2RFC1905[13]で説明されるように。 副代理店はtestSet-PDUで示された文脈とセッションに関して変数を有効にします。
If each VarBind is successful, the subagent has a further responsibility to ensure the availability of all resources (memory, write access, etc.) required for successfully carrying out a subsequent agentx-CommitSet operation. If this cannot be guaranteed, the subagent should set res.error to `resourceUnavailable'. As a result of this validation step, an agentx-Response-PDU is sent in reply whose res.error field is set to one of the following SNMPv2 PDU error-status values (see section 3, "Definitions", in RFC 1905 [13]):
書いてください。それぞれのVarBindがうまくいくなら、副代理店にはすべてのリソースの有用性を確実にするさらなる責任がある、(メモリ、アクセスなど) 首尾よくその後のagentx-CommitSet操作を行うために、必要です。 これを保証できないなら、副代理店は'resourceUnavailable'にres.errorを設定するべきです。 この合法化ステップの結果、res.error分野が以下のSNMPv2 PDUエラー状況値の1つに設定される回答でagentx応答PDUを送ります。(セクション3、「定義」を見てください、RFC1905[13])で:
noError (0),
genErr (5),
noAccess (6),
wrongType (7),
wrongLength (8),
wrongEncoding (9),
wrongValue (10),
noCreation (11),
inconsistentValue (12),
resourceUnavailable (13),
notWritable (17),
inconsistentName (18)
noError(0)、genErr(5)、noAccess(6)、wrongType(7)、wrongLength(8)、wrongEncoding(9)、wrongValue(10)、noCreation(11)、inconsistentValue(12)、resourceUnavailable(13)、notWritable(17)、inconsistentName(18)
If this value is not `noError', the res.index field must be set to the index of the VarBind for which validation failed.
この値が'noError'でないなら、res.index fieldは合法化が失敗したVarBindのインデックスに用意ができなければなりません。
Daniele, et al. Standards Track [Page 68] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[68ページ]。
Implementation of rigorous validation code may be one of the most demanding aspects of subagent development. Implementors are strongly encouraged to do this right, so as to avoid if at all possible the extensible agent's having to return `commitFailed' or `undoFailed' during subsequent processing.
厳密な認証コードの実現は副代理店開発の最も過酷な局面の1つであるかもしれません。 作成者が何かこの正しいことをするよう強く奨励されます、できればその後の処理の間に'commitFailed'か'undoFailed'を返さなければならない広げることができるエージェントを避けるために。
7.2.4.2. Subagent Processing of the agentx-CommitSet-PDU
7.2.4.2. agentx-CommitSet-PDUの副代理店処理
The agentx-CommitSet-PDU indicates that the subagent should actually perform (as described in the post-validation sections of 4.2.5 of RFC 1905 [13]) the management operation indicated by the previous TestSet-PDU. After carrying out the management operation, the subagent sends in reply an agentx-Response-PDU whose res.error field is set to one of the following SNMPv2 PDU error-status values (see section 3, "Definitions", in RFC 1905 [13]):
agentx-CommitSet-PDUは、副代理店が実際に働くべきであるのを示します。(4.2人のポスト合法化部で管理操作が前のTestSet-PDUで示した.5RFC1905[13])について説明するので。 管理操作を行った後に、副代理店は回答でres.error分野が以下のSNMPv2 PDUエラー状況値の1つに設定されるagentx応答PDUを送ります。(セクション3、「定義」を見てください、RFC1905[13])で:
noError (0),
commitFailed (14)
noError(0)、commitFailed(14)
If this value is `commitFailed', the res.index field must be set to the index of the VarBind (as it occurred in the agentx-TestSet-PDU) for which the operation failed. Otherwise res.index is set to 0.
この値が'commitFailed'であるなら、res.index fieldは操作が失敗したVarBind(agentx-TestSet-PDUに起こったので)のインデックスに用意ができなければなりません。 さもなければ、res.indexは0に用意ができています。
7.2.4.3. Subagent Processing of the agentx-UndoSet-PDU
7.2.4.3. agentx-UndoSet-PDUの副代理店処理
The agentx-UndoSet-PDU indicates that the subagent should undo the management operation requested in a preceding CommitSet-PDU. The undo process is as described in section 4.2.5 of RFC 1905 [13].
agentx-UndoSet-PDUは、副代理店が前のCommitSet-PDUで要求された管理操作を元に戻すべきであるのを示します。 元に戻すことの過程が.5セクション4.2RFC1905[13]で説明されるようにあります。
After carrying out the undo process, the subagent sends in reply an agentx-Response-PDU whose res.error field is set to one of the following SNMPv2 PDU error-status values (see section 3, "Definitions", in RFC 1905 [13]):
元に戻すことの過程を行った後に、副代理店は回答でres.error分野が以下のSNMPv2 PDUエラー状況値の1つに設定されるagentx応答PDUを送ります。(セクション3、「定義」を見てください、RFC1905[13])で:
noError (0),
undoFailed (15)
noError(0)、undoFailed(15)
If this value is `undoFailed', the res.index field must be set to the index of the VarBind (as it occurred in the agentx-TestSet-PDU) for which the operation failed. Otherwise res.index is set to 0.
この値が'undoFailed'であるなら、res.index fieldは操作が失敗したVarBind(agentx-TestSet-PDUに起こったので)のインデックスに用意ができなければなりません。 さもなければ、res.indexは0に用意ができています。
This PDU also signals the end of processing of the management operation initiated by the previous TestSet-PDU. The subagent should release resources, etc. as described in section 7.2.4.4, "Subagent Processing of the agentx-CleanupSet-PDU".
また、このPDUは前のTestSet-PDUによって開始された管理操作の処理の終わりに合図します。 副代理店は、セクション7.2.4で.4、「agentx-CleanupSet-PDUの副代理店処理」について説明するので、リソースを発表するべきですなど。
Daniele, et al. Standards Track [Page 69] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[69ページ]。
7.2.4.4. Subagent Processing of the agentx-CleanupSet-PDU
7.2.4.4. agentx-CleanupSet-PDUの副代理店処理
The agentx-CleanupSet-PDU signals the end of processing of the management operation requested in the previous TestSet-PDU. This is an indication to the subagent that it may now release any resources it may have reserved in order to carry out the management request. No response is sent by the subagent.
agentx-CleanupSet-PDUは前のTestSet-PDUで要求された管理操作の処理の終わりに合図します。 これは副代理店への現在管理要求を行うために予約したどんなリソースも発表するかもしれないという指示です。 副代理店は応答を全く送りません。
7.2.5. Master Agent Processing of AgentX Responses
7.2.5. AgentX応答のマスターエージェント処理
The master agent now marshals all subagent AgentX response PDUs and builds an SNMP response PDU. In the next several subsections, the initial processing of all subagent AgentX response PDUs is described, followed by descriptions of subsequent processing for each specific subagent Response.
マスターエージェントは、現在、すべての副代理店AgentX応答PDUsを整列させて、SNMP応答PDUを造ります。 次のいくつかの小区分では、すべての副代理店AgentX応答PDUsの初期の処理は説明されます、それぞれの特定の副代理店Responseのためのその後の処理の記述があとに続いていて。
7.2.5.1. Common Processing of All AgentX Response PDUs
7.2.5.1. すべてのAgentX応答PDUsの一般的な処理
1) If a response is not received on a session within the timeout
interval for this dispatch, it is treated as if the subagent had
returned `genErr' and processed as described below.
1) 応答がタイムアウト間隔中にこの発信のためにセッションに受けられないなら、それは、以下で説明されるようにまるで副代理店が'genErr'を返したかのように扱われて、処理されます。
A timeout may be due to a variety of reasons, and does not
necessarily denote a failed or malfunctioning subagent. As such,
the master agent's response to a subagent timeout is
implementation-specific, but with the following constraint:
タイムアウトは、さまざまな理由のためにあるかもしれなくて、必ず失敗されるか誤動作副代理店を指示するというわけではありません。 実現特有ですがそういうものとして以下の規制で副代理店タイムアウトへのマスターエージェントの応答:
A session that times out on three consecutive AgentX requests is
considered unable to respond, and the master agent must close the
AgentX session as described in section 7.1.8, "Processing the
agentx-Close-PDU", step (2).
3の連続したAgentXの上の回が要求するセッションは応じることができないと考えられます、そして、マスターエージェントはセクション7.1.8で説明されるようにAgentXセッションを終えなければなりません、「agentxの近いPDUを処理し」て、ステップ(2)。
2) Otherwise, the h.packetID, h.sessionID, and h.transactionID fields
of the AgentX response PDU are used to correlate subagent
responses. If the response does not pertain to this SNMP
operation, it is ignored.
2) さもなければ、AgentX応答PDUのh.packetID、h.sessionID、およびh.transactionID分野は、副代理店応答を関連させるのに使用されます。 応答がこのSNMP操作に関しないなら、それは無視されます。
3) Otherwise, the responses are processed jointly to form the SNMP
response PDU.
3) さもなければ、応答は、SNMP応答PDUを形成するために共同で処理されます。
7.2.5.2. Processing of Responses to agentx-Get-PDUs
7.2.5.2. agentxがPDUsを手に入れることへの応答の処理
After common processing of the subagent's response to an agentx-Get- PDU (see section 7.2.5.1, "Common Processing of All AgentX Response PDUs", above), processing continues with the following steps:
-一般的であった後に、agentxへの副代理店の応答を処理して、得てください、-、PDU、(「コモンはすべてのAgentX応答PDUsを処理し」て、.1が、上で7.2に.5を区分するのを見る、)、処理が以下のステップで以下を続けています。
Daniele, et al. Standards Track [Page 70] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[70ページ]。
1) For any received AgentX response PDU, if res.error is not
`noError', the SNMP response PDU's error code is set to this
value. If res.error contains an AgentX specific value (e.g.
`parseError'), the SNMP response PDU's error code is set to a
value of genErr instead. Also, the SNMP response PDU's error
index is set to the index of the variable binding corresponding to
the failed VarBind in the subagent's AgentX response PDU.
1) どんな容認されたAgentX応答PDUにおいても、SNMP応答PDUのエラーコードはres.errorが'noError'でないなら、この値に設定されます。 res.errorがAgentXの特定の値(例えば、'parseError')を含んでいるなら、SNMP応答PDUのエラーコードは代わりにgenErrの値に設定されます。 また、SNMP応答PDUの誤りインデックスは副代理店のAgentX応答PDUにおける失敗したVarBindに対応する変項束縛のインデックスへのセットです。
All other AgentX response PDUs received due to processing this
SNMP request are ignored. Processing is complete; the SNMP
Response PDU is ready to be sent (see section 7.2.6, "Sending the
SNMP Response-PDU").
このSNMPが要求する処理のため受け取られた他のすべてのAgentX応答PDUsは無視されます。 処理は完全です。 SNMP Response PDUは送る準備ができています(「SNMP応答-PDUを送っ」て、セクション7.2.6を見てください)。
2) Otherwise, the content of each VarBind in the AgentX response PDU
is used to update the corresponding variable binding in the SNMP
Response-PDU.
2) さもなければ、AgentX応答PDUにおけるそれぞれのVarBindの内容は、SNMP Response-PDUで対応する変項束縛をアップデートするのに使用されます。
7.2.5.3. Processing of Responses to agentx-GetNext-PDU and
agentx-GetBulk-PDU
7.2.5.3. agentx-GetNext-PDUとagentx-GetBulk-PDUへの応答の処理
After common processing of the subagent's response to an agentx- GetNext-PDU or agentx-GetBulk-PDU (see section 7.2.5.1, "Common Processing of All AgentX Response PDUs", above), processing continues with the following steps:
agentx- GetNext-PDUかagentx-GetBulk-PDUへの副代理店の応答の一般的な処理の後、(「コモンはすべてのAgentX応答PDUsを処理し」て、.1が、上で7.2に.5を区分するのを見る、)、処理が以下のステップで以下を続けています。
1) For any received AgentX response PDU, if res.error is not
`noError', the SNMP response PDU's error code is set to this
value. If res.error contains an AgentX specific value (e.g.
`parseError'), the SNMP response PDU's error code is set to a
value of genErr instead. Also, the SNMP response PDU's error
index is set to the index of the variable binding corresponding to
the failed VarBind in the subagent's AgentX response PDU.
1) どんな容認されたAgentX応答PDUにおいても、SNMP応答PDUのエラーコードはres.errorが'noError'でないなら、この値に設定されます。 res.errorがAgentXの特定の値(例えば、'parseError')を含んでいるなら、SNMP応答PDUのエラーコードは代わりにgenErrの値に設定されます。 また、SNMP応答PDUの誤りインデックスは副代理店のAgentX応答PDUにおける失敗したVarBindに対応する変項束縛のインデックスへのセットです。
All other AgentX response PDUs received due to processing this
SNMP request are ignored. Processing is complete; the SNMP
response PDU is ready to be sent (see section 7.2.6, "Sending the
SNMP Response-PDU").
このSNMPが要求する処理のため受け取られた他のすべてのAgentX応答PDUsは無視されます。 処理は完全です。 SNMP応答PDUは送る準備ができています(「SNMP応答-PDUを送っ」て、セクション7.2.6を見てください)。
2) Otherwise, the content of each VarBind in the AgentX response PDU
is used to update the corresponding VarBind in the SNMP response
PDU.
2) さもなければ、AgentX応答PDUにおけるそれぞれのVarBindの内容は、SNMP応答PDUで対応するVarBindをアップデートするのに使用されます。
After all expected AgentX response PDUs have been processed, if any VarBinds still contain the value `endOfMibView' in their v.type fields, processing must continue:
結局予想されたAgentX応答PDUsは処理されました、どんなVarBindsも彼らのv.タイプ分野にまだ値の'endOfMibView'を保管しています、と処理は続けなければなりません:
Daniele, et al. Standards Track [Page 71] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[71ページ]。
3) A new iteration of AgentX request dispatching is initiated (as
described in section 7.2.1.2, "agentx-GetNext-PDU"), in which only
those VarBinds whose v.type is `endOfMibView' are processed.
3) AgentX要求の急ぎの新しい繰り返し((処理されます)v.タイプが'endOfMibView'であるそれらのVarBindsだけ)は開始されます(セクション7.2.1で.2、"agentx-GetNext-PDU"について説明するので)。
4) For each such VarBind, an authoritative target MIB region is
identified in which the master agent expects to find suitable MIB
variables. The target session is the one on which this new target
region was registered.
4) そのような各VarBindに関しては、マスターエージェントが適当なMIB変数を見つけると予想する正式の目標MIB領域は特定されます。 目標セッションはこの新しい目標領域が登録されたものです。
The starting OID in each SearchRange is set to the value of v.name
for the corresponding VarBind, and its "include" field is set to
0.
各SearchRangeの始めのOIDは対応するVarBindのためにv.名の値に用意ができています、そして、「包含」分野は0に設定されます。
5) The value of transactionID must be identical to the value used
during the previous iteration.
5) transactionIDの値は前の繰り返しの間に使用される値と同じであるに違いありません。
6) The AgentX PDUs are sent on the target session(s), and the
responses are received and processed according to the steps
described in section 7.2.5, "Master Agent Processing of AgentX
Responses".
6) 目標セッションにAgentX PDUsを送って、セクション7.2.5で説明されたステップ、「AgentX応答のマスターエージェント処理」に従って、応答は、受けられて、処理されます。
7) This process continues iteratively until a complete SNMP
Response-PDU has been built, or until there remain no
authoritative MIB regions to query.
7) 完全なSNMP Response-PDUが造られたか、または質問するどんな正式のMIB領域も残らないまで、この過程は繰り返しに持続します。
Note that r.subtree for the new target region identified in step 4) may not lexicographically succeed r.subtree for the region that has returned `endOfMibView'. For example, consider the following registry:
新しい目標領域へのr.下位木がステップ4で特定した注意) 辞書編集が'endOfMibView'を返した領域にr.下位木を引き継ぎませんように。 例えば、以下の登録を考えてください:
session A `mib-2' (1.3.6.1.2.1)
session B `ip' (1.3.6.1.2.1.4)
session C `tcp' (1.3.6.1.2.1.6)
セッションA'mib-2'、(1.3.6.1.2.1)セッションB'ip'、(1.3.6.1.2.1.4)セッションC'tcp'(1.3.6.1.2.1.6)
If while processing a GetNext-Request-PDU session B returns `endOfMibView' for a variable name within 1.3.6.1.2.1.4, the target MIB region identified in step 4) would be 1.3.6.1.2.1 (since it may contain variables whose names precede 1.3.6.1.2.1.6).
そうするかもしれないので、名前が先行する変数を含んでください。GetNextがPDUを要求しているaセッションBが処理している間、1.3の中の変数名のための'endOfMibView'に.6を返すかどうか、.1、.2、.1、.4、1.3が.6であったならステップ4)で特定された目標MIB領域、.1、.2、.1、(1.3 .6 .1 .2 .1 .6)。
Note also that if session A returned variables from within 1.3.6.1.2.1.6, they must be discarded since session A is NOT authoritative for that region.
また、セッションAが中から変数を返したなら、それに注意してください。1.3 .6 .1 .2 .1 .6 その領域には、セッションAが正式でないので、それらを捨てなければなりません。
7.2.5.4. Processing of Responses to agentx-TestSet-PDUs
7.2.5.4. agentx-TestSet-PDUsへの応答の処理
After common processing of the subagent's response to an agentx-
TestSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX
Response PDUs", above), processing continues with the further
agentx- TestSet-PDUへの副代理店の応答の一般的な処理の後、(「コモンはすべてのAgentX応答PDUsを処理し」て、.1が、上で7.2に.5を区分するのを見る、)、処理が一層を続行します。
Daniele, et al. Standards Track [Page 72] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[72ページ]。
exchange of AgentX PDUs. The value of h.transactionID in the agentx-CommitSet, -UndoSet, and -CleanupSet-PDUs must be identical to the value sent in the testSet-PDU.
AgentX PDUsの交換。 agentx-CommitSet、-UndoSet、および-CleanupSet-PDUsのh.transactionIDの値はtestSet-PDUで送られた値と同じであるに違いありません。
The state transitions and PDU sequences are depicted in section 7.3, "State Transitions".
状態遷移とPDU系列はセクション7.3、「状態遷移」で表現されます。
The set of all sessions who have been sent an agentx-TestSet-PDU for this particular transaction are referred to below as "involved sessions".
agentx-TestSet-PDUがこの特定の取引のために送られたすべてのセッションのセットは「かかわったセッション」として以下と呼ばれます。
1) If any target session's response is not `noError', all other
agentx-Response-PDUs received due to processing this SNMP request
are ignored.
1) 目標セッションのどんなものの間の応答も'noError'でないなら、このSNMPが要求する処理のため受け取られた他のすべてのagentx応答PDUsが無視されます。
An agentx-CleanupSet-PDU is sent to all involved sessions.
Processing is complete; the SNMP response PDU is constructed as
described below in 7.2.6, "Sending the SNMP Response-PDU".
すべてのかかわったセッションにagentx-CleanupSet-PDUを送ります。 処理は完全です。 SNMP応答PDUが中で以下で説明されるように組み立てられる、7.2、.6、「SNMP応答-PDUを送ります」。
2) Otherwise an agentx-CommitSet-PDU is sent to all involved
sessions.
2) さもなければ、すべてのかかわったセッションにagentx-CommitSet-PDUを送ります。
7.2.5.5. Processing of Responses to agentx-CommitSet-PDUs
7.2.5.5. agentx-CommitSet-PDUsへの応答の処理
After common processing of the subagent's response to an agentx- CommitSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX Response PDUs", above), processing continues with the following steps:
agentx- CommitSet-PDUへの副代理店の応答の一般的な処理の後、(「コモンはすべてのAgentX応答PDUsを処理し」て、.1が、上で7.2に.5を区分するのを見る、)、処理が以下のステップで以下を続けています。
1) If any response is not `noError', the SNMP response PDU's error
code is set to this value. If res.error contains an AgentX
specific value (e.g. `parseError'), the SNMP response PDU's error
code is set to a value of genErr instead. Also, the SNMP response
PDU's error index is set to the index of the VarBind corresponding
to the failed VarBind in the agentx-TestSet-PDU.
1) 何か応答も'noError'でないなら、SNMP応答PDUのエラーコードはこの値に設定されます。 res.errorがAgentXの特定の値(例えば、'parseError')を含んでいるなら、SNMP応答PDUのエラーコードは代わりにgenErrの値に設定されます。 また、SNMP応答PDUの誤りインデックスはagentx-TestSet-PDUの失敗したVarBindに対応するVarBindのインデックスに設定されます。
An agentx-UndoSet-PDU is sent to each target session that has been
sent an agentx-CommitSet-PDU. An agentx-CleanupSet-PDU is sent to
the remainder of the involved sessions.
agentx-CommitSet-PDUが送られたそれぞれの目標セッションにagentx-UndoSet-PDUを送ります。 かかわったセッションの残りにagentx-CleanupSet-PDUを送ります。
2) Otherwise an agentx-CleanupSet-PDU is sent to all involved
sessions. Processing is complete; the SNMP response PDU is
constructed as described below in section 7.2.6, "Sending the SNMP
Response-PDU".
2) さもなければ、すべてのかかわったセッションにagentx-CleanupSet-PDUを送ります。 処理は完全です。 「SNMP応答-PDUを送っ」て、SNMP応答PDUは以下でセクション7.2.6で説明されるように組み立てられます。
Daniele, et al. Standards Track [Page 73] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[73ページ]。
7.2.5.6. Processing of Responses to agentx-UndoSet-PDUs
7.2.5.6. agentx-UndoSet-PDUsへの応答の処理
After common processing of the subagent's response to an agentx- UndoSet-PDU (see section 7.2.5.1, "Common Processing of All AgentX Response PDUs", above), processing continues with the following steps:
agentx- UndoSet-PDUへの副代理店の応答の一般的な処理の後、(「コモンはすべてのAgentX応答PDUsを処理し」て、.1が、上で7.2に.5を区分するのを見る、)、処理が以下のステップで以下を続けています。
1) If any response is `undoFailed' the SNMP response PDU's error code
is set to this value. Also, the SNMP response PDU's error index
is set to 0.
1) 何か応答が'undoFailed'であるなら、SNMP応答PDUのエラーコードはこの値に設定されます。 また、SNMP応答PDUの誤りインデックスは0に設定されます。
2) Otherwise, if any response is not `noError' the SNMP response
PDU's error code is set to this value. Also, the SNMP response
PDU's error index is set to the index of the VarBind corresponding
to the failed VarBind in the agentx-TestSet-PDU. If res.error is
an AgentX specific value (e.g. `parseError'), the SNMP response
PDU's error code is set to a value of genErr instead.
2) さもなければ、何か応答も'noError'でないなら、SNMP応答PDUのエラーコードはこの値に設定されます。 また、SNMP応答PDUの誤りインデックスはagentx-TestSet-PDUの失敗したVarBindに対応するVarBindのインデックスに設定されます。 res.errorがAgentXの特定の値(例えば、'parseError')であるなら、SNMP応答PDUのエラーコードは代わりにgenErrの値に設定されます。
3) Otherwise the SNMP response PDU's error code and error index were
set in section 7.2.5.5 step 1)
3) さもなければ、SNMP応答PDUのエラーコードと誤りインデックスはセクション7.2.5.5ステップ1)に設定されました。
7.2.6. Sending the SNMP Response-PDU
7.2.6. SNMP応答-PDUを送ります。
Once the processing described in section 7.2.5, "Master Agent Processing of AgentX Responses" is complete, there is an SNMP response PDU available. The master agent now implements the Elements of Procedure for the applicable version of the SNMP protocol in order to encapsulate the PDU into a message, and transmit it to the originator of the SNMP management request. Note that this may involve altering the PDU contents (for instance, to replace the original VarBinds if an error condition is to be returned).
かつての処理がセクション7.2.5で説明されて、「AgentX応答のマスターエージェント処理」が完全である、PDU利用可能なSNMP応答があります。 メッセージにPDUを要約して、経営者側が要求するSNMPの創始者にそれを伝えて、マスターエージェントは現在、SNMPプロトコルの適切なバージョンのためにProcedureのElementsを実行します。 これが、PDUコンテンツを変更することを伴うかもしれないことに注意してください(例えば、オリジナルを置き換えるには、VarBindsはエラー条件であるなら返されることになっています)。
The response PDU may also be altered in order to support the SNMPv1 PDU. In such cases the required PDU mapping is that defined in RFC 2089 [25]. (Note in particular that the rules for handling Counter64 syntax may require re-sending AgentX GetBulk or GetNext PDUs until a VarBind of suitable syntax is returned.)
また、応答PDUは、SNMPv1 PDUを支持するために変更されるかもしれません。 そのような場合必要なPDUマッピングはRFC2089[25]でそんなに定義されています。 (取り扱いCounter64構文のための規則が、適当な構文のVarBindを返すまでAgentX GetBulkかGetNext PDUsを再送するのを必要とするかもしれないことに特に注意してください。)
7.2.7. MIB Views
7.2.7. MIB視点
AgentX subagents are not aware of MIB views, since view information is not contained in AgentX PDUs.
視点情報がAgentX PDUsに含まれていないので、AgentX副代理店はMIB視点を意識していません。
As stated above, the descriptions of procedures in section 7, "Elements of Procedure", of this memo are not intended to constrain the internal architecture of any conformant implementation. In particular, the master agent procedures described in section 7.2.1,
セクション7の手順の記述、上に同じくらい述べられていて、このメモ「手順の要素」がどんなconformant実現の内部の構造も抑制することを意図しません。 特にセクション7.2.1で説明されたマスターエージェント手順
Daniele, et al. Standards Track [Page 74] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[74ページ]。
"Dispatching AgentX PDUs" and in section 7.2.5, "Master Agent Processing of AgentX Responses" may be altered so as to optimize AgentX exchanges when implementing MIB views.
「AgentX PDUsを派遣します」、およびセクション7.2.5における「AgentX応答のマスターエージェント処理」は、MIB視点を実行するとき、AgentX交換を最適化するために変更されるかもしれません。
Such optimizations are beyond the scope of this memo. But note that section 7.2.3, "Subagent Processing of agentx-Get, GetNext, GetBulk- PDUs", defines subagent behavior in such a way that alteration of SearchRanges may be used in such optimizations.
そのような最適化はこのメモの範囲を超えています。 しかし、そのセクション7.2.3、「agentx得ることの副代理店処理、GetNext、GetBulk- PDUs」という注意はSearchRangesの変更がそのような最適化に使用されるかもしれないような方法で副代理店の振舞いを定義します。
7.3. State Transitions
7.3. 状態遷移
State diagrams are presented from the master agent's perspective for transport connection and session establishment, and from the subagent's perspective for Set transaction processing.
州のダイヤグラムは輸送接続とセッション設立のためのマスターエージェントの見解と、Setトランザクション処理のための副代理店の見解から提示されます。
7.3.1. Set Transaction States
7.3.1. 取引州を設定してください。
The following table presents, from the subagent's perspective, the state transitions involved in Set transaction processing:
以下のテーブルは副代理店の見解からSetトランザクション処理にかかわる状態遷移を提示します:
Daniele, et al. Standards Track [Page 75] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[75ページ]。
STATE
+---------------+--------------+---------+--------+--------
| A | B | C | D | E
| (Initial | TestOK | Commit | Test | Commit
| State) | | OK | Fail | Fail
| | | | |
EVENT | | | | |
---------+---------------+--------------+---------+--------+--------
| 7.2.4.1 | | | |
Receive | All varbinds | | | |
TestSet | OK? | X | X | X | X
PDU | Yes ->B | | | |
| No ->D | | | |
---------+---------------+--------------+---------+--------+--------
| | 7.2.4.2 | | |
Receive | | NoError? | | |
Commit- | X | Yes ->C | X | X | X
Set PDU | | No ->E | | |
---------+---------------+--------------+---------+--------+--------
Receive | | | 7.2.4.3 | |7.2.4.3
UndoSet | X | X | ->done | X | ->done
PDU | | | | |
---------+---------------+--------------+---------+--------+--------
Receive | | 7.2.4.4 | 7.2.4.4 |7.2.4.4 |
Cleanup- | X | ->done | ->done | ->done | X
Set PDU | | | | |
---------+---------------+--------------+---------+--------+--------
Session | | rollback | undo | |
Loss | ->done | ->done | ->done | ->done | ->done
---------+---------------+--------------+---------+--------+--------
状態+---------------+--------------+---------+--------+-------- | A| B| C| D| E| (TestOK| 公約してください| テストしてください| |頭文字をつけてください、そして、| 状態を遂行してください) | | OK| 失敗してください。| 失敗してください。| | | | | 出来事| | | | | ---------+---------------+--------------+---------+--------+-------- | 7.2.4.1 | | | | 受信してください。| すべてのvarbinds| | | | TestSet| OK? | X| X| X| X PDU| はい>B| | | | | >がありませんD。| | | | ---------+---------------+--------------+---------+--------+-------- | | 7.2.4.2 | | | 受信してください。| | NoError? | | | 公約してください。| X| はい>C| X| X| XセットPDU| | >がありませんE。| | | ---------+---------------+--------------+---------+--------+-------- 受信してください。| | | 7.2.4.3 | |7.2.4.3 UndoSet| X| X| -行われた>。| X| -PDUが行われた>。| | | | | ---------+---------------+--------------+---------+--------+-------- 受信してください。| | 7.2.4.4 | 7.2.4.4 |7.2.4.4 | クリーンアップ| X| -行われた>。| -行われた>。| -行われた>。| XセットPDU| | | | | ---------+---------------+--------------+---------+--------+-------- セッション| | 引き下げ| アンドゥ| | 損失| -行われた>。| -行われた>。| -行われた>。| -行われた>。| -行われた>。---------+---------------+--------------+---------+--------+--------
There are three possible sequences that a subagent may follow for a particular set transaction:
副代理店が特定のセット取引のために従うかもしれない3つの可能な順序があります:
1) TestSet CommitSet CleanupSet
2) TestSet CommitSet UndoSet
3) TestSet CleanupSet
1) TestSet CommitSet CleanupSet2) TestSet CommitSet UndoSet3) TestSet CleanupSet
Note that a single PDU sequence may result in multiple paths through the finite state machine (FSM). For example, the sequence
ただ一つのPDU系列が有限状態機械(FSM)を通した複数の経路をもたらすかもしれないことに注意してください。 例えば、系列
TestSet CommitSet UndoSet
TestSet CommitSet UndoSet
may walk through either of these two state sequences:
これらの2のどちらかを通した散歩が系列を述べますように:
(initial) TestOK CommitOK (done)
(initial) TestOK CommitFail (done)
(初期)のTestOK CommitOK(する)の(初期)のTestOK CommitFail(します)
Daniele, et al. Standards Track [Page 76] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[76ページ]。
7.3.2. Transport Connection States
7.3.2. 輸送接続州
The following table presents, from the master agent's perspective,
the state transitions involved in transport connection setup and
teardown:
STATE
+--------------+--------------
| A | B
| No transport | Transport
| | connected
| |
EVENT | |
----------------+--------------+--------------
Transport | |
connect | ->B | X
indication | |
----------------+--------------+--------------
Receive | | if no resources
Open-PDU | | available
| | reject, else
| X | establish
| | session
| |
| | ->B
----------------+--------------+--------------
Receive | | if matching
Response-PDU | | session id,
| | feed to that
| X | session's FSM
| | else ignore
| |
| | ->B
----------------+--------------+--------------
Receive other | | if matching
PDUs | | session id,
| | feed to that
| X | session's FSM
| | else reject
| |
| | ->B
----------------+--------------+--------------
Transport | |notify all
disconnect | |sessions on
indication | X |this transport
| |
| | ->A
----------------+--------------+--------------
状態遷移がマスターエージェントの見解から輸送接続設定にかかわった以下のテーブルプレゼントと分解: 状態+--------------+-------------- | A| B| 輸送がありません。| 輸送| | 接続されます。| | イベント| | ----------------+--------------+-------------- 輸送| | 接続してください。| ->B| X指示| | ----------------+--------------+-------------- 受信してください。| | いいえ、リソースオープン-PDUなら| | 利用可能| | ほかに廃棄物| X| 設立します。| | セッション| | | | ->B----------------+--------------+-------------- 受信してください。| | Response-PDUを合わせます。| | セッションイド| | それに食べてください。| X| セッションのFSM| | ほか、無視| | | | ->B----------------+--------------+-------------- 別に受信してください。| | PDUsを合わせます。| | セッションイド| | それに食べてください。| X| セッションのFSM| | ほかの廃棄物| | | | ->B----------------+--------------+-------------- 輸送| |すべての分離に通知してください。| |指示のセッション| X|この輸送| | | | ->A----------------+--------------+--------------
Daniele, et al. Standards Track [Page 77] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[77ページ]。
7.3.3. Session States
7.3.3. セッション州
The following table presents, from the master agent's perspective, the state transitions involved in session setup and teardown:
以下のテーブルはマスターエージェントの見解からセッションセットアップと分解にかかわる状態遷移を提示します:
STATE
+-------------+----------------
| A | B
| No session | Session
| | established
EVENT | |
---------------+-------------+----------------
| 7.1.1 |
Receive | | X
Open PDU | ->B |
---------------+-------------+----------------
| | 7.1.8
Receive | X |
Close PDU | | ->A
---------------+-------------+----------------
Receive | | 7.1.4
Register PDU | X |
| | ->B
---------------+-------------+----------------
Receive | | 7.1.5
Unregister | X |
PDU | | ->B
---------------+-------------+----------------
Receive | |
Get PDU | |
GetNext PDU | |
GetBulk PDU | X | X
TestSet PDU | |
CommitSet PDU | |
UndoSet PDU | |
CleanupSet PDU | |
---------------+-------------+----------------
Receive | | 7.1.10
Notify PDU | X |
| | ->B
---------------+-------------+----------------
Receive Ping | | 7.1.11
PDU | X |
| | ->B
---------------+-------------+----------------
(continued next page)
状態+-------------+---------------- | A| B| セッションがありません。| セッション| | 確立したEVENT| | ---------------+-------------+---------------- | 7.1.1 | 受信してください。| | X開いているPDU| ->B| ---------------+-------------+---------------- | | 7.1.8 受信してください。| X| PDUを閉じてください。| | ->A---------------+-------------+---------------- 受信してください。| | 7.1.4 PDUを登録してください。| X| | | ->B---------------+-------------+---------------- 受信してください。| | 7.1.5 Unregister| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | PDUを手に入れてください。| | GetNext PDU| | GetBulk PDU| X| X TestSet PDU| | CommitSet PDU| | UndoSet PDU| | CleanupSet PDU| | ---------------+-------------+---------------- 受信してください。| | 7.1.10 PDUに通知してください。| X| | | ->B---------------+-------------+---------------- ピングを受けてください。| | 7.1.11 PDU| X| | | ->B---------------+-------------+---------------- (次のページを続けています)
Daniele, et al. Standards Track [Page 78] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[78ページ]。
---------------+-------------+----------------
Receive | | 7.1.2
IndexAllocate | X |
PDU | | ->B
---------------+-------------+----------------
Receive | | 7.1.3
IndexDeallocate| X |
PDU | | ->B
---------------+-------------+----------------
Receive | | 7.1.6
AddAgentxCaps | X |
PDU | | ->B
---------------+-------------+----------------
Receive | | 7.1.7
RemoveAgentxCap| X |
PDU | | ->B
---------------+-------------+----------------
Receive | | 7.2.5
Response PDU | X |
| | ->B
---------------+-------------+----------------
Receive | |
Other PDU | X | X
---------------+-------------+----------------
---------------+-------------+---------------- 受信してください。| | 7.1.2 IndexAllocate| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | 7.1.3 IndexDeallocate| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | 7.1.6 AddAgentxCaps| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | 7.1.7 RemoveAgentxCap| X| PDU| | ->B---------------+-------------+---------------- 受信してください。| | 7.2.5 応答PDU| X| | | ->B---------------+-------------+---------------- 受信してください。| | 他のPDU| X| X---------------+-------------+----------------
8. Transport Mappings
8. 輸送マッピング
The same AgentX PDU formats, encodings, and elements of procedure are used regardless of the underlying transport.
手順の同じAgentX PDU形式、encodings、および要素は基本的な輸送にかかわらず使用されます。
8.1. AgentX over TCP
8.1. TCPの上のAgentX
8.1.1. Well-known Values
8.1.1. よく知られる値
The master agent accepts TCP connection requests for the well-known port 705. Subagents connect to the master agent using this port number.
マスターエージェントはウェルノウンポート705を求めるTCP接続要求を受け入れます。 このポートナンバーを使用することで副代理店はマスターエージェントに接します。
8.1.2. Operation
8.1.2. 操作
Once a TCP connection has been established, the AgentX peers use this connection to carry all AgentX PDUs. Multiple AgentX sessions may be established using the same TCP connection. AgentX PDUs are sent within an AgentX session. AgentX peers are responsible for mapping the h.sessionID to a particular TCP connection.
TCP接続がいったん確立されると、AgentX同輩は、すべてのAgentX PDUsを運ぶのにこの接続を使用します。 複数のAgentXセッションが、同じTCP接続を使用することで確立されるかもしれません。 AgentXセッション以内にAgentX PDUsを送ります。 AgentX同輩は特定のTCP接続にh.sessionIDを写像するのに責任があります。
Daniele, et al. Standards Track [Page 79] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[79ページ]。
The AgentX entity must not "interleave" AgentX PDUs within the TCP byte stream. All the bytes of one PDU must be sent before any bytes of a different PDU. The receiving entity must be prepared for TCP to deliver byte sequences that do not coincide with AgentX PDU boundaries.
AgentX実体はTCPバイト・ストリームの中でAgentX PDUsを「はさみ込んではいけません」。 異なったPDUのどんなバイト前にも1PDUのすべてのバイトを送らなければなりません。 TCPがAgentX PDU境界と一致していないバイト列を提供するように受信実体を準備しなければなりません。
8.2. AgentX over UNIX-domain Sockets
8.2. UNIX-ドメインソケットの上のAgentX
Many (BSD-derived) implementations of the UNIX operating system support the UNIX pathname address family (AF_UNIX) for socket communications. This provides a convenient method of sending and receiving data between processes on the same host.
Unixオペレーティングシステムの多くの(BSDによって派生する)の実装が、ソケットコミュニケーションのためにUNIXパス名アドレスがファミリー(AF_UNIX)であるとサポートします。 これは同じホストの上で送受信データの便利な方法をプロセスの間に提供します。
Mapping AgentX to this transport is useful for environments that
この輸送にAgentXを写像するのが環境の役に立つ、それ
- wish to guarantee subagents are running on the same managed
node as the master agent, and where
- 副代理店がマスターエージェント、およびどこと同じ管理されたノードで動いているかを保証することを願ってください。
- sockets provide better performance than TCP or UDP, especially
in the presence of heavy network I/O
- ソケットは特に重いネットワーク入出力があるときTCPかUDPより良い性能を提供します。
8.2.1. Well-known Values
8.2.1. よく知られる値
The master agent creates a well-known UNIX-domain socket endpoint called "/var/agentx/master". (It may create other, implementation- specific endpoints.)
マスターエージェントは"/var/agentx/master"と呼ばれるよく知られるUNIX-ドメインソケット終点を作成します。 (それは他の、そして、実装特有の終点を作成するかもしれません。)
This endpoint name uses the character set encoding native to the managed node, and represents a UNIX-domain stream (SOCK_STREAM) socket.
この終点名は、管理されたノード固有の文字集合コード化を使用して、UNIX-ドメインストリーム(SOCK_STREAM)ソケットを表します。
8.2.2. Operation
8.2.2. 操作
Once a connection has been established, the AgentX peers use this connection to carry all AgentX PDUs.
接続がいったん確立されると、AgentX同輩は、すべてのAgentX PDUsを運ぶのにこの接続を使用します。
Multiple AgentX sessions may be established using the same connection. AgentX PDUs are sent within an AgentX session. AgentX peers are responsible for mapping the h.sessionID to a particular connection.
複数のAgentXセッションが、同じ接続を使用することで確立されるかもしれません。 AgentXセッション以内にAgentX PDUsを送ります。 AgentX同輩はh.sessionIDを特定の接続に写像するのに責任があります。
The AgentX entity must not "interleave" AgentX PDUs within the socket byte stream. All the bytes of one PDU must be sent before any bytes of a different PDU. The receiving entity must be prepared for the socket to deliver byte sequences that do not coincide with AgentX PDU boundaries.
AgentX実体はソケットバイト・ストリームの中でAgentX PDUsを「はさみ込んではいけません」。 異なったPDUのどんなバイト前にも1PDUのすべてのバイトを送らなければなりません。 ソケットがAgentX PDU境界と一致していないバイト列を提供するように受信実体を準備しなければなりません。
Daniele, et al. Standards Track [Page 80] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[80ページ]。
9. Security Considerations
9. セキュリティ問題
This memo defines a protocol between two processing entities, one of which (the master agent) is assumed to perform authentication of received SNMP requests and to control access to management information. The master agent performs these security operations independently of the other processing entity (the subagent).
このメモは2つの処理実体((マスターエージェント)が受信されたSNMP要求の認証を実行して、経営情報へのアクセスを制御すると思われるもの)の間のプロトコルを定義します。 マスターエージェントはもう片方の処理実体(副代理店)の如何にかかわらずこれらのセキュリティ操作を実行します。
Security considerations require three questions to be answered:
セキュリティ問題は、3つの質問が答えられるのを必要とします:
1. Is a particular subagent allowed to initiate a session with a
particular master agent?
1. 特定の副代理店は特定のマスターエージェントとのセッションを開始できますか?
2. During an AgentX session, is any SNMP security-related
information (for example, community names) passed from the
master agent to the subagent?
2. AgentXセッションの間、何かSNMPのセキュリティ関連の情報(例えば、共同体名)がマスターエージェントから副代理店まで通過されますか?
3. During an AgentX session, what part of the MIB tree is this
subagent allowed to register?
3. AgentXセッションの間、この副代理店はMIB木のどんな部分に登録できますか?
The answer to the third question is: A subagent can register any subtree (subject to AgentX elements of procedure, section 7.1.4, "Processing the agentx-Register-PDU"). Currently there is no access control mechanism defined in AgentX. A concern here is that a malicious subagent that registers an unauthorized "sensitive" subtree, could see modification requests to those objects, or by giving its own clever answer to NMS queries, could cause the NMS to do something that leads to information disclosure or other damage.
3番目の質問の答えは以下の通りです。 副代理店はどんな下位木(手順のAgentX要素、セクション7.1.4を条件とした「agentxレジスタPDUを処理する」)も登録できます。 現在、AgentXで定義されたアクセス管理機構が全くありません。 NMSが権限のない「敏感な」下位木を登録して、それらのオブジェクト、またはそれ自身のNMS質問の賢明な答えを与えることによって変更要求を見ることができるだろう悪意がある副代理店で情報公開か他の損害に通じる何かをするかもしれないという関心がここにあります。
The answer to the second question is: No.
2番目の質問の答えは以下の通りです。 いいえ
Now we can answer the first question. AgentX does not contain a mechanism for authorizing/refusing session initiations. Thus, controlling subagent access to the master agent may only be done at a lower layer (e.g., transport).
今、私たちは最初の質問に答えることができます。 AgentXはセッション開始を権限を与えるか、または拒否するためのメカニズムを含んでいません。 したがって、マスターエージェントへの副代理店アクセスは下層(例えば、輸送)で制御されるだけであるかもしれません。
An AgentX subagent can connect to a master agent using either a network transport mechanism (e.g., TCP), or a "local" mechanism (e.g., shared memory, named pipes).
ネットワーク移送機構(例えば、TCP)か「地方」のメカニズム(例えば、共有メモリ、名前付きパイプ)のどちらかを使用することでAgentX副代理店はマスターエージェントに接できます。
In the case where a local transport mechanism is used and both subagent and master agent are running on the same host, connection authorization can be delegated to the operating system features. The answer to the first security question then becomes: "If and only if the subagent has sufficient privileges, then the operating system will allow the connection".
ローカル運送メカニズムが使用されていて、副代理店とマスターエージェントの両方が同じホストで走っている場合では、接続承認をオペレーティングシステム機能へ代表として派遣することができます。 次に、最初のセキュリティ質問の答えはなります: 「副代理店に十分な特権がある場合にだけオペレーティングシステムが接続を許す、」
Daniele, et al. Standards Track [Page 81] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[81ページ]。
If a network transport is used, currently there is no inherent security. Transport Layer Security, SSL, or IPsec SHOULD be used to control and protect subagent connections in this mode of operation.
ネットワーク輸送が使用されているなら、現在、どんな固有のセキュリティもありません。 輸送Layer Security、SSL、またはIPsec SHOULDがコントロールに慣れて、この運転モードで副代理店接続を保護します。
However, we RECOMMEND that subagents always run on the same host as the master agent and that operating system features be used to ensure that only properly authorized subagents can establish connections to the master agent.
副代理店がいつも同じように上で作業するRECOMMENDはマスターエージェントとそのオペレーティングシステムとして特徴を接待します。しかしながら、私たち、使用されて、適切に認可された副代理店しかマスターエージェントに関係を樹立できないのを保証してください。
10. Acknowledgements
10. 承認
The initial development of this memo was heavily influenced by the DPI 2.0 specification RFC 1592 [26].
このメモの初期の開発はDPI2.0仕様RFC1592[26]によって大いに影響を及ぼされました。
This document was produced by the IETF Agent Extensibility (AgentX) Working Group, and benefited especially from the contributions of the following working group members:
このドキュメントは、IETFエージェントExtensibility(AgentX)作業部会によって起こされて、特に以下のワーキンググループのメンバーの貢献の利益を得ました:
David Battle, Uri Blumenthal, Jeff Case, Maria Greene, Lauren
Heintz, Dave Keeney, Harmen van der Linde, Bob Natale, Aleksey
Romanov, Don Ryan, and Juergen Schoenwaelder.
デヴィッドBattle、ユリ・ブルーメンソル、ジェフCase、マリア・グリーン、ローレン・ハインツ、デーヴ・キーニー、Harmenはderリンデ、ボブNatale、アレックセイ・ロマーノフ、ドン・ライアン、およびユルゲンSchoenwaelderをバンに積みます。
An honorable mention is extended to Randy Presuhn in recognition for his numerous technical contributions to this specification; for his many answers provided on (and hosting of) the AgentX e-mail list and ftp site, and, for the valued support and guidance Randy provided to the Working Group chair.
立派な言及はこの仕様への彼の頻繁な技術的な貢献のために認識でランディPresuhnに与えられます。 提供された彼の多くの答え、(接待、)、AgentXはリストとFTPサイトをメールして、評価されたサポートと指導のために、ランディは作業部会いすに供給しました。
The AgentX Working Group is chaired by:
AgentX作業部会は以下によってまとめられます。
Bob Natale ACE*COMM Corporation 704 Quince Orchard Road Gaithersburg, MD 20878
オーチャード・ロードゲイザースバーグ、ボブNatale ACE*COMM社704のQuince MD 20878
Phone: +1-301-721-3000 Fax: +1-301-721-3001 EMail: bnatale@acecomm.com
以下に電話をしてください。 +1-301-721-3000 Fax: +1-301-721-3001 メールしてください: bnatale@acecomm.com
Daniele, et al. Standards Track [Page 82] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[82ページ]。
11. Authors' and Editor's Addresses
11. 作者とエディタのアドレス
Mike Daniele Compaq Computer Corporation 110 Spit Brook Rd Nashua, NH 03062
マイクダニエルコンパックコンピュータ社110はブルック・第ナッシュア、ニューハンプシャー 03062に痰唾を吐きました。
Phone: +1-603-881-1423 EMail: daniele@zk3.dec.com
以下に電話をしてください。 +1-603-881-1423 メールしてください: daniele@zk3.dec.com
Bert Wijnen IBM T.J.Watson Research Schagen 33 3461 GL Linschoten Netherlands
バートWijnen IBM T.J.ワトソン研究Schagen33 3461GLリンスホーテン・オランダ
Phone: +31-348-432-794 EMail: wijnen@vnet.ibm.com
以下に電話をしてください。 +31-348-432-794 メールしてください: wijnen@vnet.ibm.com
Mark Ellison (WG editor) Ellison Software Consulting, Inc. 38 Salem Road Atkinson, NH 03811
マーク・エリソン(WGエディタ)エリソンSoftware Consulting Inc.38Salem Roadアトキンソン、ニューハンプシャー 03811
Phone: +1-603-362-9270 EMail: ellison@world.std.com
以下に電話をしてください。 +1-603-362-9270 メールしてください: ellison@world.std.com
Dale Francisco (editor) Cisco Systems 150 Castilian Dr Goleta CA 93117
デールフランシスコ(エディタ)シスコシステムズ150カスティリャのゴレタカリフォルニア博士 93117
Phone: +1-805-961-3642 Fax: +1-805-961-3600 EMail: dfrancis@cisco.com
以下に電話をしてください。 +1-805-961-3642 Fax: +1-805-961-3600 メールしてください: dfrancis@cisco.com
Daniele, et al. Standards Track [Page 83] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[83ページ]。
12. References
12. 参照
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[1] ハリントンとD.とPresuhnとR.とB.Wijnen、「SNMP管理フレームワークについて説明するためのアーキテクチャ」、RFC2571、1999年4月。
[2] Rose, M. and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[2] ローズ、M.、およびK.McCloghrie、「TCP/IPベースのインターネットのための経営情報の構造と識別」(STD16、RFC1155)は1990がそうするかもしれません。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
[3] ローズとM.とK.McCloghrie、「簡潔なMIB定義」、STD16、RFC1212、1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[4] ローズ、1991年3月、M.、「SNMPとの使用のためのDefining TrapsのためのConvention」RFC1215。
[5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[5]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「経営情報バージョン2(SMIv2)の構造」、STD58、RFC2578(1999年4月)。
[6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[6]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2579、1999年4月の原文のコンベンション。」
[7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
58, RFC 2580, April 1999.
[7]McCloghrie、K.、パーキンス、D.、Schoenwaelder、J.、ケース、J.、ローズ、M.、およびS.Waldbusser、「SMIv2"、STD58、RFC2580、1999年4月のための順応声明。」
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[8] ケース、J.、ヒョードル、M.、Schoffstall、M.、およびJ.デーヴィン(「簡単なネットワーク管理プロトコル」、STD15、RFC1157)は1990がそうするかもしれません。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January
1996.
[9]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「地域密着型のSNMPv2"への紹介、RFC1901、1996年1月。」
[10] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1906, January 1996.
[10]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワークマネージメントのバージョン2のための輸送マッピングは(SNMPv2)について議定書の中で述べます」、RFC1906、1996年1月。
[11] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[11]ケース、J.、ハリントンD.、Presuhn R.、およびB.Wijnen、「メッセージ処理と簡単なネットワークマネージメントのために急いでいるのは(SNMP)について議定書の中で述べます」、RFC2572、1999年4月。
[12] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, April 1999.
[12] ブルーメンソルとU.とB.Wijnen、「Simple Network Managementプロトコル(SNMPv3)のバージョン3のためのユーザベースのSecurity Model(USM)」、RFC2574、1999年4月。
Daniele, et al. Standards Track [Page 84] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[84ページ]。
[13] 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.
[13] ケース、J.、McCloghrie(K.、ローズ、M.、およびS.Waldbusser)は「簡単なネットワーク管理プロトコル(SNMPv2)のバージョン2のための操作について議定書の中で述べます」、RFC1905、1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC
2573, April 1999.
[14] レビとD.とマイヤーとP.とB.スチュワート、「SNMPv3アプリケーション」、RFC2573、1999年4月。
[15] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
[15] Wijnen、B.、Presuhn、R.、およびK.McCloghrie、「簡単なネットワークマネージメントのための視点ベースのアクセス制御モデル(VACM)は(SNMP)について議定書の中で述べます」、RFC2575、1999年4月。
[16] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
[16] ケースとJ.とマンディとR.、パーテインとD.とB.スチュワート、「インターネット標準ネットワークマネージメントフレームワークのバージョン3への序論」RFC2570(1999年4月)。
[17] 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.
[17]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「簡単なネットワーク管理プロトコルのバージョン2のための管理情報ベース(SNMPv2)」、RFC1907(1996年1月)。
[18] Information processing systems - Open Systems Interconnection -
Specification of Abstract Syntax Notation One (ASN.1),
International Organization for Standardization. International
Standard 8824, (December, 1987).
[18] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)
[19] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB
using SMIv2", RFC 2233, November 1997.
[19] McCloghrie、K.、およびF.Kastenholz、「インタフェースは1997年11月にSMIv2"、RFC2233を使用するMIBを分類します」。
[20] Case, J., "FDDI Management Information Base", RFC 1285, January
1992.
[20] ケース、J.、「FDDI管理情報ベース」、RFC1285、1992年1月。
[21] Krupczak, C. and J. Saperia, "Definitions of System-Level
Managed Objects for Applications", RFC 2287, April 1997.
[21]KrupczakとC.とJ.Saperia、「アプリケーションのためのシステムレベル管理オブジェクトの定義」、RFC2287、1997年4月。
[22] Kalbfleisch, C., Krupczak, C., Presuhn, R. and J. Saperia,
"Application Management MIB", RFC 2564, May 1999.
[22] Kalbfleisch、C.、Krupczak、C.、Presuhn、R.、およびJ.Saperia(「アプリケーション管理MIB」、RFC2564)は1999がそうするかもしれません。
[23] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[23] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、1994年10月。
[24] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser,
"Coexistence between Version 1 and Version 2 of the Internet-
standard Network Management Framework", RFC 1908, January 1996.
[24]ケース、J.、McCloghrie、K.、ローズ、M.、およびS.Waldbusser、「インターネットの標準のNetwork Management Frameworkのバージョン1とバージョン2の間の共存」、RFC1908(1996年1月)。
[25] Wijnen, B. and D. Levi, "V2ToV1: Mapping SNMPv2 onto SNMPv1
Within a Bilingual SNMP Agent", RFC 2089, January 1997.
[25]Wijnen、B.、およびD.レビ、「V2ToV1:」 「バイリンガルSNMPエージェントの中でSNMPv2をSNMPv1に写像する」RFC2089、1997年1月。
Daniele, et al. Standards Track [Page 85] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[85ページ]。
[26] Wijnen, B., Carpenter, G., Curran, K., Sehgal, A. and G.
Waters, "Simple Network Management Protocol: Distributed
Protocol Interface, Version 2.0", RFC 1592, March 1994.
[26]WijnenとB.と大工、G.、カラン、K.とSehgalとA.とG.水域、「簡単なネットワークマネージメントは以下について議定書の中で述べます」。 1994年3月にRFC1592をプロトコルインタフェース、バージョン2インチ分配しました。
[27] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[27] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
13. Notices
13. 通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。
Daniele, et al. Standards Track [Page 86] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[86ページ]。
A. Changes relative to RFC 2257
A。 RFC2257に比例した変化
Changes on the wire:
ワイヤの上の変化:
- The agentx-Notify-PDU and agentx-Close-PDU now generate an
agentx-Response-PDU.
- agentxがPDUに通知していて、agentxの近いPDUは現在、agentx応答PDUを生成します。
- The res.error field may contain three new error codes:
parseFailed(266), requestDenied(267), and processingError(268).
- res.error分野は3つの新しいエラーコードを含むかもしれません: parseFailed(266)、requestDenied(267)、およびprocessingError(268)。
Clarifications to the text of the memo:
メモの原本への明確化:
- Modified the text of step (4) in section 4.2, "Applicability"
to separate the two concerns of row creation, and counters that
count rows.
- 行を数えるセクション4.2、行作成の二人を引き離す「適用性」関心、およびカウンタでステップ(4)のテキストを変更しました。
- The use of the r.range_subid field is more clearly defined in
section 6.2.3, "The agentx-Register-PDU".
- r.範囲_subid分野の使用はセクション6.2.3、「agentxレジスタPDU」で、より明確に定義されます。
- Default priority (127) for registration added to the
description of r.priority in section 6.2.3, "The agentx-
Register-PDU".
- 「agentxレジスタ-PDU」と、登録のためのデフォルト優先権(127)はセクション6.2.3における、r.優先権の記述に言い足しました。
- Made the distinction of "administrative processing" PDUs and
"SNMP request processing" PDUs in section 6.1, "AgentX PDU
Header" description of h.type. This distinction is used in the
Elements of Procedure relative to the res.sysuptime and
res.error fields.
- セクション6.1、h.タイプの「AgentX PDUヘッダー」記述で「管理処理」の区別をPDUsと「SNMPは処理を要求する」PDUsにしました。 この区別はProcedureのElementsでres.sysuptimeとres.error分野に比例して使用されます。
- Rewrote portions of text in section 6.2.3, "The agentx-
Register-PDU" to be more explicit about the following points:
- 以下のポイントに関して、より明白になるように.3、「agentxレジスタ-PDU」というセクション6.2でテキストの部分を書き直しました:
- There is a default registration priority of 127.
- Improved the description of r.range_subid, independent of
the prefix in r.region.
- Improved description and examples of how to use the
registration mechanism.
- Added a description for r.upper_bound.
- changed r.region to r.subtree (because the text used the
terms "region", "range", and "OID range" in too loose a
fashion. r.subtree can not represent anything more by
itself than a simple subtree. In conjunction with
r.range_subid and r.upper_bound, it can represent a
"region", that is, a union of subtrees)
- 127のデフォルト登録優先があります。 - r.領域の接頭語の如何にかかわらずr.範囲_subidの記述を改良しました。 - どう登録メカニズムを使用するかに関する改良された記述と例。 - r.の上側の_のための記述が付いたと言い足しました。 - r.下位木への変えられたr.領域テキストが「領域」という用語を使用したので「及んでください」、ゆる過ぎるファッションで「OIDは及びます」。r.下位木自体は何も表すことができません。(subidとr.の上側の_が縛ったr.範囲_に関連して「領域」を表すことができます、すなわち、下位木の組合)
- Modified the text in section 6.2.4, "The agentx-Unregister-PDU" to
include a description of u.range_subid and u.upper_bound
- 縛られたセクション6.2.4におけるテキスト、u.範囲_subidとu.の記述を含む「agentx-Unregister-PDU」変更された上側の_
Daniele, et al. Standards Track [Page 87] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[87ページ]。
- Added use of the `requestDenied' error code in section 7.1.4,
"Processing the agentx-Register-PDU".
- 「agentxレジスタPDUを処理し」て、セクション7.1.4における'requestDenied'エラーコードの使用を加えました。
- Removed text in section 7, "Elements of Procedure" on parse errors
and protocol errors.
- 7、「手順の要素」というセクションでオンな取り除かれたテキストは誤りとプロトコル誤りを分析します。
- Added a new section, 7.1, "Processing AgentX Administrative
Messages" which defines common processing and how to use the
`parseError' and `processingError' instead of closing a session,
and how to handle context.
- 新しいセクションと、7.1と、一般的な処理を定義する「処理のAgentXの管理メッセージ」とどう閉会することの代わりに'parseError'と'processingError'と、どう文脈を扱うかを使用するかを加えました。
- Removed the common processing text from the other administrative
processing Elements of Procedure sections, and added a reference
to section 7.1, "Processing AgentX Administrative Messages". The
affected sections are:
- Procedure部のもう片方の管理処理Elementsから一般的な処理テキストを移して、「AgentXの管理メッセージを処理し」て、セクション7.1に参照を追加しました。 影響を受けるセクションは以下の通りです。
- 7.1.2, "Processing the agentx-IndexAllocate-PDU"
- 7.1.3, "Processing the agentx-IndexDeallocate-PDU"
- 7.1.4, "Processing the agentx-Register-PDU"
- 7.1.5, "Processing the agentx-Unregister-PDU"
- 7.1.6, "Processing the agentx-AddAgentCaps-PDU"
- 7.1.7, "Processing the agentx-RemoveAgentCaps-PDU"
- 7.1.8, "Processing the agentx-Close-PDU"
- 7.1.10, "Processing the agentx-Notify-PDU"
- 7.1.11, "Processing the agentx-Ping-PDU"
- 7.1.2, "Processing the agentx-IndexAllocate-PDU" - 7.1.3, "Processing the agentx-IndexDeallocate-PDU" - 7.1.4, "Processing the agentx-Register-PDU" - 7.1.5, "Processing the agentx-Unregister-PDU" - 7.1.6, "Processing the agentx-AddAgentCaps-PDU" - 7.1.7, "Processing the agentx-RemoveAgentCaps-PDU" - 7.1.8, "Processing the agentx-Close-PDU" - 7.1.10, "Processing the agentx-Notify-PDU" - 7.1.11, "Processing the agentx-Ping-PDU"
- Reworked the text in section 7.1.1, "Processing the
agentx-Open-PDU" to include new error codes, and, to eliminate
reference to an indicated context.
- そして、示された文脈の参照を排除するために新しいエラーコードを含むように「agentxの開いているPDUを処理し」て、セクション7.1.1におけるテキストを作りなおしました。
- Modified the text in Section 7.1.10, "Processing the
agentx-Notify-PDU" to state that context checking is performed.
- 文脈の照合が実行されると述べるために「agentxにPDUに通知しているのを処理し」て、セクション7.1.10におけるテキストを変更しました。
- Substantially modified the text in section 7.1.4.1, "Handling
Duplicate and Overlapping Subtrees".
- 実質的に、.4.1と、「取り扱い写しと重なっている下位木」というセクション7.1でテキストを変更しました。
- Removed the section on "Using the agentx-IndexAllocate-PDU" and
added section 7.1.4.2, "Registering Stuff". This change is
intended to provide a more concise and a more cohesive
description of how things are supposed to work.
- 「agentx-IndexAllocate-PDUを使用します」と加えられたセクション7.1.4の.2、「登録もの」というセクションを取り外しました。 この変化がものがどう働くべきであるかに関する、より簡潔な記述と、より粘着性がある記述を提供することを意図します。
- Modified the test in section 7.1.5, "Processing the
agentx-Unregister-PDU" to require a match on u.range_subid and
on u.upper_bound when these fields were applicable in the
corresponding agentx-Register-PDU.
- u.範囲_subidの上と、そして、これらの分野が対応するagentxレジスタPDUで適切であったときに縛られたu.の上側の_の上のマッチを必要とするように「agentx-Unregister-PDUを処理し」て、セクション7.1.5におけるテストを変更しました。
Daniele, et al. Standards Track [Page 88] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[88ページ]。
- Removed all references to "splitting", and all uses of the term
"OID range". The text now refers to regions or subtrees
directly, and relies on rule (1), "Honoring the Registry", in
section 7.2.1, "Dispatching AgentX PDUs".
- 「分かれること」のすべての参照、および「OID範囲」という用語のすべての用途を取り除きました。 テキストは、現在直接領域か下位木を示して、規則(1)を当てにします、「登録を光栄に思っ」て、セクション7.2.1で、「AgentX PDUsを派遣し」て。
- Modified text in clause 4(c) of section 7.2.1, "Dispatching
AgentX PDUs", clarifying that the master agent can use its
implementation-specific default timeout value when the timeout
value registered by the subagent is impractical.
- セクション7.2.1の節4(c)の変更されたテキスト、副代理店によって示されたタイムアウト値が非実用的であるときに、「AgentX PDUsを派遣し」て、それをはっきりさせて、マスターエージェントは実装特有のデフォルトタイムアウト価値を使用できます。
- Added text in section 7.2.2, "Subagent Processing" describing
common processing.
- 「副代理店処理」が一般的な処理について説明して、セクション7.2.2におけるテキストを加えました。
- Added an example to the text in section 7.2.5.3, "Processing of
Responses to agentx-GetNext-PDU and agentx-GetBulk-PDU",
and, removed the definition of "contains" from this section.
- 加えられて、テキストへの例は中で7.2を区分します。.5 .3 そして、「agentx-GetNext-PDUとagentx-GetBulk-PDUへの応答の処理」であることはこのセクションからの「含有」の定義を取り除きました。
- Modified text in step (1) of section 7.2.5.5, "Processing of
Responses to agentx-CommitSet-PDUs", eliminating directive for
master agent to ignore additional responses to
agentx-CommitSet-PDUs after the first error response.
- .5、「agentx-CommitSet-PDUsへの応答の処理」というマスターエージェントが最初の誤り応答の後にagentx-CommitSet-PDUsへの追加応答を無視するように指示を排除するセクション7.2.5のステップ(1)における変更されたテキスト。
- Modified text in section 7.2.5.6, "Processing of Responses to
agentx-UndoSet-PDUs", cleaning up commit/undo elements of
procedure per feedback received on the AgentX email list.
- 変更されたテキストコネセクション7.2.5.6、掃除して、「agentx-UndoSet-PDUsへの応答の処理」であることは1AgentXメールリストに受け取られたフィードバックあたりの手順の要素を遂行するか、または元に戻します。
- Modified the text in section 8.1.2, "Operation" to explicitly
prohibit interleaved sends, and, added a caution about
exchanging AgentX messages via TCP.
- 変更されて、.2、明らかに禁止する「操作」というはさみ込まれたセクション8.1のテキストは発信します、そして、AgentXを交換することに関する加えられたa警告はTCPを通して通信します。
- Modified text to be more explicit that the OID in the
agentx-Allocate-PDU is an OBJECT-TYPE and does not contain any
instance sub-identifiers.
- 変更されたテキスト、 より明白に、なるように、agentxがPDUを割り当てるところのOIDがOBJECT-TYPEであり、いずれも含んでいないのがサブ識別子を例証します。
- Replaced the term "subagent" with the term "session" in many
places throughout the text.
- テキスト中の多くの場所で「副代理店」という用語を「セッション」という用語に取り替えました。
- Modified the text relative to master agent processing of the
agentx-TestSet-PDU, agentx-CommitSet-PDU, and the
agentx-UndoSet-PDU to explicitly state that only "involved"
sessions receive an agentx-CommitSet-PDU, and possibly, an
agentx-UndoSet-PDU.
- 「かかわった」セッションだけがagentx-CommitSet-PDU、およびことによるとagentx-UndoSet-PDUを受けると明らかに述べるようにagentx-TestSet-PDU、agentx-CommitSet-PDU、およびagentx-UndoSet-PDUのマスターエージェント処理に比例してテキストを変更しました。
- Modified the text to use the term "transaction", instead of
"packet" (and others), where appropriate. This helps
distinguish the overall transaction from a particular sequence
of packets or PDUs.
- 「パケット」(そして、他のもの)の代わりに適切であるところで「取引」という用語を使用するようにテキストを変更しました。 これは、パケットかPDUsの特定の系列と総合的な取引を区別するのを助けます。
Daniele, et al. Standards Track [Page 89] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[89ページ]。
- Modified the text to explicitly state that a session is not
required to support concurrent sets.
- セッションは同時発生のセットを支えるのに必要でないと明らかに述べるようにテキストを変更しました。
- Added section 13, "Notices".
- セクション13、「通知」を加えました。
- Added text to section 1, Introduction, relative to BCP 14 key
words.
- BCP14キーワードに比例してセクション1、Introductionにテキストを加えました。
- Modified text to section 9, Security Considerations, to include
use of BCP 14 key words.
- BCP14キーワードの使用を含むようにセクション9、Security Considerationsにテキストを変更しました。
- Modified text to section 9, Security Considerations, to include
IPSEC as a suggested Transport Layer Security.
- 提案されたTransport Layer SecurityとしてIPSECを含むようにセクション9、Security Considerationsにテキストを変更しました。
Daniele, et al. Standards Track [Page 90] RFC 2741 AgentX January 2000
ダニエル、他 規格はAgentX2000年1月にRFC2741を追跡します[90ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Daniele, et al. Standards Track [Page 91]
ダニエル、他 標準化過程[91ページ]
一覧
スポンサーリンク
