[要約] RFC 2741は、AgentXプロトコルのバージョン1に関する仕様です。AgentXは、ネットワーク管理エージェントの拡張性を提供するために設計されています。
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
Agent Extensibility (AgentX) Protocol Version 1
エージェント拡張性（agentX）プロトコルバージョン1
Status of this 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の現在の版を参照してください。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット社会（2000）。全著作権所有。
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プロトコルメッセージを処理するプロトコルの要素を定義します。このメモはRFC 2257を廃止します。
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
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
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
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:
このメモはRFC 2257を廃止されています。ほとんどの変更は明確化の目的のためのものであることが注目に値します。ワイヤ上のAgentXプロトコルメッセージに影響を与える唯一の変更は次のとおりです。
- The agentx-Notify-PDU and agentx-Close-PDU now generate an agentx-Response-PDU
- AgentX-Notify-PDUとAgentX-Close-PDUはAgentX-Response-PDUを生成するようになりました
- Three new error codes are available: parseFailed(266), requestDenied(267), and processingError(268)
- 3つの新しいエラーコードが利用可能です：parsefailed（266）、requestdened（267）、およびProcessERROR（268）
Appendix A provides a detailed list of changes relative to RFC 2257.
付録Aは、RFC 2257に対する変更の詳細なリストを提供します。
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].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、[27]に記載されているように解釈されること。
The SNMP Management Framework presently consists of five major components:
SNMP管理フレームワークは現在5つの主要コンポーネントで構成されています。
An overall architecture, described in RFC 2571 [1].
RFC 2571 [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].
管理を目的としてオブジェクトやイベントを記述して命名するためのメカニズム。この管理情報の第1版（SMI）はSMIV1と呼ばれ、STD16、RFC 1155 [2]、STD 16、RFC 1212 [3]、RFC 1215 [4]に記載されている。SMIV2と呼ばれる第2のバージョンは、STD 58、RFC 2578 [5]、STD 58、RFC 2579 [6]、STD 58、RFC 2580 [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メッセージプロトコルの最初のバージョンはSNMPv1と呼ばれ、STD 15、RFC 1157 [8]に記載されています。インターネット規格トラックプロトコルではないSNMPメッセージプロトコルの2番目のバージョンは、SNMPv2Cと呼ばれ、RFC 1901 [9] [10]とRFC 1906 [10]に記載されています。メッセージプロトコルの3番目のバージョンはSNMPv3と呼ばれ、RFC 1906 [10]、RFC 2572 [11]、RFC 2574 [12]に記載されています。
Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [8]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [13].
管理情報へのアクセスのためのプロトコル操作。プロトコル操作と関連するPDUフォーマットの最初のセットはSTD15、RFC 1157 [8]に記載されています。第2組のプロトコル操作および関連PDUフォーマットは、RFC 1905 [13]に記載されている。
A set of fundamental applications described in RFC 2573 [14] and the view-based access control mechanism described in RFC 2575 [15].
RFC 2573 [14]で説明されている一連の基本的なアプリケーションとRFC 2575 [15]に記載されているビューベースのアクセス制御メカニズム。
A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [16].
現在のSNMP管理フレームワークのより詳細な紹介は、RFC 2570 [16]にあります。
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.
管理対象オブジェクトは、管理情報ベースまたはMIBと呼ばれる仮想インフォメーションストアを介してアクセスされます。MIB内のオブジェクトは、SMIで定義されているメカニズムを使用して定義されています。
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.
「変数」という用語は、SMIV2（STD 58、RFC 2578、[5]）またはSMIV2に基づくテキスト規則（STD 58、RFCに基づくテキスト規約）に従って定義された非集約オブジェクトタイプのインスタンスを指す。2579 [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.
変数の名前はオブジェクト識別子であり、これは、インスタンスを識別するオブジェクト識別子フラグメントとともに、対応するオブジェクトタイプのオブジェクト識別子の連結である。対応するオブジェクトタイプのオブジェクト識別子は、変数のオブジェクト識別子プレフィックスと呼ばれます。
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ワーキンググループによって継続的に定義されています。企業や個人が企業固有または実験的なMIBを作成または拡張するのも一般的です。
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フレームワークは、特定のエージェントによってサポートされている管理対象オブジェクトのセットを動的に変更できる方法を説明していません。
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
- それぞれが管理計測器を含む「サブエージェント」のセット
- 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）環境。
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.
Agent Extensibility（AgentX）の標準プロトコルの指定は、これらの問題の両方を解決するために必要な技術基盤を提供します。独立して開発された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フレームワーク内では、エージェントはさらに次のように構成されています。
- 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の基本的な要件であり、EgentXサブエージェントをSNMPプロキシエージェントから区別するものです。
An entity acting in a master agent role performs the following functions:
マスターエージェントロールで行動するエンティティは、次の機能を実行します。
- Accepts AgentX session establishment requests from subagents.
- 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.)
- 管理枠組みに適用される管理フレームワークに指定されたプロシージャのエージェントの役割要素を実行します。（MIBビューのアプリケーション、および管理対象ノードのアクセス制御ポリシーは、マスターエージェントによって実装されています。）
- Provides instrumentation for the MIB objects defined in RFC 1907 [17], and for any MIB objects relevant to any administrative framework it supports.
- RFC 1907 [17]で定義されているMIBオブジェクトのインストルメンテーション、およびそれがサポートする管理フレームワークに関連するMIBオブジェクトについて。
- 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.
- 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領域内のOIDを実際の変数にバインドします。
- Performs management operations on variables.
- 変数に対して管理操作を実行します。
- Initiates notifications.
- 通知を開始します。
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モジュールを実装します。
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がサポートする次の最も典型的な構成を表します。
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) サブエージェントは、非行のパーティションに沿ってMIBを共有します。MIBのインデックス構造の性質のために、複数行を表すMIBのサブアージャンの登録 "Chunks"。例は、ipnettomediaEntry.nを登録することを含み、ここで、nはサブエージェントによって実装されたインターフェイスのifIndex値、およびtcpconnentry.a.b.c.dは、subagentによって実装されたインターフェース上の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) サブアージャンは、ROWの作成を許可するテーブル内の行を実装します。たとえば、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がテーブル内のエントリをカウントするオブジェクトを定義するテーブル内の行を実装します（IFNUMBERのため）MIB-2の場合はMIB-2です。そのようなカウンタオブジェクトを実装するサブエージェント（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.
これらの後者のカテゴリのシナリオは、サブエージェントが異なるベンダによって独立して実装されている構成においてややめったに発生したと考えられました。ただし、標準的なプロトコルの焦点は、マルチベンダーの相互運用性を保証する必要がある領域だけでなければなりません。
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サブエージェントの間でテーブルを共有することが非効率的であることに注意してください。IPRoutetableは、環境によってはそのようなテーブルの例である可能性があります。
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 carry them out; subagents are exclusively concerned with management instrumentation; and neither should intrude on the other's territory.
1）マスターエージェントとサブエージェントとの間の一般的な建築部門：マスターエージェントはMIB無知およびSNMPオムニセンチントであり、サブエージェントはSNMP無知およびMIB OMNISCIENT（InstantiatiateSのMIB変数の場合）です。つまり、マスターエージェントは、排他的に、SNMPプロトコル操作とそれらを実行するために必要なAgentXプロトコル操作との翻訳に関する。サブエージェントは管理計測機器に排他的に関係しています。そして他人の領土に侵入するべきではありません。
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ペイロードサイズ。
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 typically required for independently developed subagents to coexist. The set of supported extensible agent configurations is described above, in Section 4.2, "Applicability".
3）考えられるすべての拡張可能なエージェント構成オプションを収容する能力。これはこのプロトコルの開発における最も一般的な側面でした。本質的に、現在の商業的拡張可能なエージェント製品で現在入手可能な特定の機能は、AgentXには含まれていません。いくつかの実装戦略において有用であるか不可欠でさえ、大まかなコンセンサスは、これらの機能はインターネット規格に適していなかった、または共存するために独立して開発されたサブエージェントには通常必要ではなかったことでした。サポートされている拡張可能エージェント構成のセットは、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つまたは複数またはより大きな展開経験の後に識別される可能性がある新しい目標のためのカバレッジを提供することがあります。
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 PDUは共通のヘッダーで構成され、続いて可変長のPDU固有のデータが続きます。SNMP PDUとは異なり、AgentX PDUは（ISO 8824 [18]で指定されている）BERを使用してエンコードされませんが、連続バイトストリームとして送信されます。このストリーム内のデータは、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つのフィールドは半角値です。3番目のフィールド（h.flags）内のビット（Network_byte_Order）は、PDU内のすべてのマルチバイト整数値のバイト順序付けを示すために、ヘッダー自体に続くものを含むビット整数値を示す。これは、下記の「AgentX PDUヘッダー」のセクション6.1でより詳細に説明されています。
PDUs are depicted in this memo using the following convention (where byte 1 is the first transmitted byte):
PDUは、次の条約を使用してこのメモに描かれています（バイト1は最初の送信バイトです）。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte 1 | byte 2 | byte 3 | byte 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| byte 5 | byte 6 | byte 7 | byte 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields marked "<reserved>" are reserved for future use and must be zero-filled.
"<Reserved>"とマークされたフィールドは将来の使用のために予約されており、ゼロ充填されている必要があります。
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: Object Identifier
オブジェクト識別子は4バイトのヘッダーとして符号化され、その後にサブ識別子を表す可変数の連続した4バイトのフィールドが続く。この表現（オブジェクト識別子と呼ばれる）は次のとおりです。オブジェクト識別子
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Object Identifier header fields:
オブジェクト識別子ヘッダーフィールド
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）。4バイトのヘッダーには、「N_SUBID」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.
オブジェクト識別子エンコーディングの長さを短くするために使用される符号なし値。ゼロ以外の値「X」は、「インターネット」（1.3.6.1）の後に最初のサブ識別子として解釈され、オブジェクト識別子に符号化された実際のサブ識別子への暗黙の接頭辞「Internet.x」を示す。たとえば、プレフィックスフィールド値2は、暗黙のプレフィックス "1.3.6.1.2"を示します。prefixフィールドの0の値は、サブ識別子への接頭辞がないことを示しています。
include
include
Used only when the Object Identifier is the start of a SearchRange, as described in section 5.2, "SearchRange".
セクション5.2「SearchRange」で説明されているように、オブジェクト識別子が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_Byte_Orderビットに従ってエンコードされた4バイトの符号なし整数。
A null Object Identifier consists of the 4-byte header with all bytes set to 0.
NULLオブジェクト識別子は、すべてのバイトが0に設定されている4バイトのヘッダーで構成されています。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1.2.3.4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 0 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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は2つのオブジェクト識別子で構成されています。サブエージェントとの通信では、マスターエージェントはSearchRangeを使用して要求された変数バインディングを識別し、getNextおよびgetBulk操作で、サブエージェントが返信で送信されることがあります。
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と呼ばれる）は、範囲の先頭を示します。要求された変数バインディングの名前は頻繁に（しかし必ずしもそうわかりません）。
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のヘッダーの "Include"フィールドは、開始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.
2番目のオブジェクト識別子（終了OID）は範囲の非包含終了を示し、その「INCLISIN」フィールドは常に0です.OIDを終了するためのNULL値は、無制限のSearchRangeを示します。
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.2.25.2.1（排他的）から検索範囲を示すために、SearchRangeは次のようになります。
(start)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 2 | 1 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 4 | 2 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 25 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A SearchRangeList is a contiguous list of SearchRanges.
SearchRanglegSは検索レンジの隣接リストです。
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.
Octet Stringは、値がオクテット文字列内のオクテットの数、その後にオクテットをオクテット自体の数である4バイトの整数（ヘッダのNetwork_byte_Orderビットに従ってエンコードされた）で始まる連続したシリーズのバイトによって表されます。この表現はオクテット文字列と呼ばれます。最後のオクテットがオクテット文字列の開始から4バイトのオフセットで終わらない場合、パディングバイトが追加されて以下のデータの配置を達成します。オクテット文字列がPDUの最後の項目であっても、このパディングを追加する必要があります。パディングバイトはゼロ充填されている必要があります。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A null Octet String consists of a 4-byte length field set to 0.
NULLオクテット文字列は、0に設定されている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.
可変バインディングは、いくつかのPDUの可変長部分内に符号化されてもよい。可変バインディングの表現（VARBINDと呼ばれる）は、2バイトのタイプのフィールド、名前（オブジェクト識別子）、および実際の値データで構成されています。
VarBind
varbind.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| v.type | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(v.name)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(v.data)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
VarBind fields:
varbindフィールド：
v.type
v.type.
Indicates the variable binding's syntax, and must be one of the following values:
変数バインディングの構文を示し、次の値のいずれかにする必要があります。
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）、NULL（5）、オブジェクト識別子（6）、IPAddress（64）、Counter32（65）、Gauge32（66）、Timeticks（67）、不透明（68）、Counter64（70）、NosuchObject（128）、Nosuchinstance（129）、EndofMibview（130）
v.name
The Object Identifier which names the variable.
変数を指定するオブジェクト識別子。
v.data
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ビットに従って、整数、カウンタ32、Gauge32、およびTimeticksは4つの連続バイトとしてエンコードされます。
- Counter64 is encoded as 8 contiguous bytes, according to the header's NETWORK_BYTE_ORDER bit.
- カウンタ64は、ヘッダのNetwork_Byte_Orderビットに従って、8つの隣接バイトとして符号化されている。
- Object Identifiers are encoded as described in section 5.1, Object Identifier.
- オブジェクト識別子は、セクション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文字列はすべてオクテット文字列で、セクション5.3「オクテット文字列」、オクテット文字列の説明に従ってエンコードされています。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.typeが上記の型の1つであるときはいつでもv.nameに値を付けます。これらのデータバイトは、（たとえば、特定の種類のインデックス割り当てで）使用されない場合でも存在します。
- Null, noSuchObject, noSuchInstance, and endOfMibView do not contain any encoded value. Value data never follows v.name in these cases.
- NULL、NOSUCHOBJECT、NOSUCHINSTANCE、およびENDOFMIBVIEWには、符号化値は含まれていません。これらの場合、Value Dataはv.nameにはなりません。
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自体に値サイズが含まれていません。その情報は固定長タイプに暗示され、可変長タイプオブジェクト識別子およびオクテット文字列のエンコードに明示的に含まれています）。
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は、varbindの連続リストです。varbindList内では、特定のvarbindがインデックス値によって識別されます。VARBINDLISTの最初のvarbindはインデックス値1、2番目のindex値2を持ちます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An AgentX PDU header contains the following fields:
AgentX PDUヘッダーには、次のフィールドが含まれています。
h.version
H.Version.
The version of the AgentX protocol (1 for this memo).
AgentXプロトコルのバージョン（このメモの1）。
h.type
h.type.
The PDU type; one of the following values:
PDUタイプ次のいずれかの値のいずれかです。
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-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-open-pdu（1）、agentX-requid-pdu（2）、agentX-register-pdu（3）、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-cleanupset-pdu（11）、agentX-notify-PDU（12）、AgentX-PING-PDU（13）、AgentX-IndexDeallocate-PDU（14）、AgentX-AddAgentCAPS-PDU（16）、AgentX-RembeAgentCAPS-PDU（16）17）、AgentX-Response-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.Flags.
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)
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パケット全体のすべてのマルチバイト整数値に適用されます。設定されている場合は、ネットワークバイト注文（最上位バイトが最初に;「ビッグエンディアン」）が使用されます。設定されていない場合は、最下位バイト（「リトルエンディアン」）が使用されます。
The NETWORK_BYTE_ORDER bit applies to all AgentX PDUs.
network_byte_orderビットはすべてのagentX PDUに適用されます。
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 PDUでのみ使用されます。
The NEW_INDEX and ANY_INDEX bits are used only within the agentx-IndexAllocate-, and -IndexDeallocate-PDUs.
new_indexおよびany_indexビットは、AgentX-IndexalCate-、および-indexDeallocate-PDU内でのみ使用されます。
The INSTANCE_REGISTRATION bit is used only within the agentx-Register-PDU.
instance_rugistrationビットは、AgentX-Register-PDU内でのみ使用されます。
h.sessionID
hsessionid.
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は、SubagentとMaster Agentの間でAgentX PDUが交換されるセッションを一意に識別します。セッションIDは、マスターエージェントとのセッションを開くために、サブエージェントによって送信されたagentX-Open-PDUに有意性があり、定義されていない値はありません。この場合、マスターエージェントは、対応するAgentX-Response-PDUに返送される固有のセッションIDを割り当てます。その点から、マスターとサブエージェントの間のそのセッションを交換したすべてのagentX PDUに同じセッションIDが表示されます。サブエージェントは、マスターエージェントに複数のAgentX-Open-PDUを送信することによって複数の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管理要求が同じセッションIDを持つマスターエージェントによって複数のAgentX PDUが送信されると、これらのAgentX PDUのそれぞれには同じトランザクションIDが含まれている必要があります。逆に、特定のセッション中に送信されたAgentX PDUは、異なる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.
トランザクションIDはSNMP PDUの要求IDと同じではありません（RFC 1905 [13]のセクション4.1で記述されている場合は、SNMPメッセージのMSGIDと同じでも、RFC 2572のセクション6.2で説明されています[11）。・マスターエージェントは、異なるマネージャからの同じ要求IDまたはMSGIDを使用してSNMP要求を受信することがあります。
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管理PDU、すなわちSNMP管理要求に関連付けられていないAgentX PDUで有意性がなく、定義されていません。
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 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.
AgentX-Response-PDUを除くすべてのAgentX PDUに対して送信者によって生成されたパケットID。AgentX-Response-PDUでは、パケットIDはそれが応答である受信したAgentX PDUのそれと同じでなければなりません。マスターエージェントはこのフィールドを使用して、サブエージェント応答PDUを対応する要求PDUと関連付けることがあります。サブエージェントは、このフィールドを使用して、回答を複数の（バッチ）登録に関連付けることができます。
h.payload_length
h.payload_length.
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レイアウトの結果として、この値は常に0、または4の倍数になります。
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では、「コンテキスト」の概念が形式化されています（RFC 2571 [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は、関連するPDU内でコンテキスト仕様を送信するためのメカニズムを提供しますが、その仕様の内容に制約を配置しません。
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-Register、Unregister、AddAgentCAPS-、removeAgentCAPS-、getNext、getBulk、getNext-、getBulk、indexalocate-、endDeallocate-、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.FlagsのNon_Default_Contextビットがクリアされている場合、PDUにコンテキストフィールドはありません。操作はデフォルトのコンテキストを参照します。（これは長さゼロのオクテット文字列があることを意味するわけではありません。）octet文字列が存在しないことを意味します。）Non_Default_Contextビットが設定されている場合、コンテキストフィールドがAgentXヘッダーのすぐ後に続き、その特定のコンテキストを参照します。コンテキストはオクテット文字列として表されます。その長さや内容に制約はありません。
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 PDUのすべて（つまり、直前にリストされているもの）は、デフォルトのコンテキスト、またはPDUで明示的に名前が付けられた非デフォルトのコンテキストであるコンテキストを参照しています。
An agentx-Open-PDU is generated by a subagent to request establishment of an AgentX session with the master agent.
AgentX-Open-PDUは、マスターエージェントとのagentXセッションの確立を要求するためにサブエージェントによって生成されます。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (1) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o.timeout | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.id)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subidentifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| subidentifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(o.descr)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Open-PDU contains the following fields:
AgentX-Open-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 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
An Object Identifier that identifies the subagent. Subagents that do not support such an notion may send a null Object Identifier.
サブエージェントを識別するオブジェクト識別子。そのような概念をサポートしていないサブエージェントは、NULLオブジェクト識別子を送信することがあります。
o.descr
o.descr.
An Octet String containing a DisplayString describing the subagent.
サブエージェントを記述する表示ストリングを含むオクテット文字列。
An agentx-Close-PDU issued by either a subagent or the master agent terminates an AgentX session.
サブエージェントまたはマスターエージェントによって発行されたAgentX-Close-PDUは、AgentXセッションを終了します。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (2) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| c.reason | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Close-PDU contains the following field:
AgentX-Close-PDUには、次のフィールドが含まれています。
c.reason
C.Reason
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: reasonOther(1) None of the following reasons
マスターエージェントまたはサブエージェントがAgentXセッションを閉じた理由を示す列挙値。このフィールドには、次のいずれかの値があります。reasionother（1）以下の理由のどれも
reasonParseError(2) Too many AgentX parse errors from peer
ReasonParSeError（2）ピアからのAgentX解析エラーが多すぎます
reasonProtocolError(3) Too many AgentX protocol errors from peer
reasionProtocolError（3）ピアからのAgentXプロトコルエラーが多すぎます
reasonTimeouts(4) Too many timeouts waiting for peer
reactimeouts（4）ピアを待っているタイムアウトが多すぎます
reasonShutdown(5) Sending entity is shutting down
reporyshutdown（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.
セット操作によるrionyByManager（6）。この理由コードは、SNMP管理要求に応答して、マスターエージェントによってのみ使用できます。
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-Register-PDUは、サポートしたいMIB変数命名ツリーの各領域ごとにサブエージェントによって生成されます。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (3) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.context) (OPTIONAL)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r.timeout | r.priority | r.range_subid | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.subtree)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.upper_bound)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional upper-bound sub-identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Register-PDU contains the following fields:
AgentX-Register-PDUには、次のフィールドが含まれています。
r.context
r.context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
r.timeout
r.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. 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.Timeout R.R.Stree内のMIBオブジェクトに関するメッセージにのみ適用されます。マスターエージェントとのagentXセッションが確立されたときに示されたセッションのデフォルト値（存在する場合）とマスターエージェントのデフォルトタイムアウトの両方をオーバーライドします。R.TimeOutのデフォルト値は0（オーバーライドなし）です。
r.priority
r.Priority.
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".
マスターエージェントのディスパッチングアルゴリズムでは、セクション7.1.4.1「重複および重複サブツリーの処理」で説明されているように、より大きな値よりも小さい値を超える値が大きくなります。
r.subtree
r.s
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領域の基本サブツリーを指定するオブジェクト識別子。「サブツリー」という用語は、ここで一般的に使用されているので、完全修飾インスタンス名、部分的インスタンス名、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 rteeが実際に完全修飾インスタンス名である場合、h.flagsのinstance_rugistrationビットを設定する必要があります。そうしないと、クリアする必要があります。マスターエージェントはこの情報を保存して、後続の運用上のディスパッチを最適化することができます。
r.range_subid
r.range_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つのサブ識別子のうちの1つの代わりに範囲を指定することを許可します。この値が0の場合、範囲は指定されていないため、PDUにr.upper_boundフィールドが存在しません。この場合、登録されているMIB領域は、R.Su6eeという名前の単一のサブツリーです。
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 rseuteの "r.range_subid" qual-識別子は範囲下限であり、範囲上限サブID（r.upper_bound）はR秒の直後です。この場合、登録されているMIB領域は、この範囲を列挙することによって形成されたサブツリーの共用体です。
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.range_subidは、r rteeが符号化されているかどうかにかかわらず、r.sutreeがプレフィックスを使用して符号化されているかどうかにかかわらず、このサブ識別子の（1ベース）インデックスを示す。（下記の例を参照してください。）
r.upper_bound
r.upper_bound.
The upper bound of a sub-identifier's range. This field is present only if r.range_subid is not 0.
サブ識別子の範囲の上限。このフィールドは、r.range_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.range_subidおよびr.upper_boundの使用は、MIB領域を指定するための一般的な短縮メカニズムを提供します。たとえば、r.RANG_SUBIDは10の場合、r.range_subidは10、r.upper_boundは22である場合、指定された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.71.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:
このメカニズムの予想される1つの使用は、概念的な行を単一のPDUで登録しています。上記の例では、MIB領域は、IFTableのRFC 1573の行7であることが起こります。実際のPDUは次のとおりです。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (3) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| r.timeout | r.priority | 10 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.subtree)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6 | 2 | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 7 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(r.upper_bound)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 22 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note again that here r.range_subid is 10, even though n_subid in r.subtree is only 6.
R.RANGE_SUBIDはここでもR.RANGE_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.Range_SubIDはサブツリー内の任意のレベルで使用されてもよいし、行レベルの登録を表す必要はありません。このメカニズムは、その登録を達成するためにサブエージェントに便利な任意の方法で使用され得る。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <reserved> | u.priority | u.range_subid | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.subtree)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(u.upper_bound)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional upper-bound sub-identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Unregister-PDU contains the following fields:
AgentX-Unregister-PDUには、次のフィールドが含まれています。
u.context
u.context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
u.priority
u.priority.
The priority at which this region was originally registered.
この地域がもともと登録された優先順位。
u.subtree
u stree.
Indicates a previously-registered region of the MIB that a subagent no longer wishes to support.
サブエージェントがサポートしていなくなったことをMIBの以前に登録された領域を示します。
u.range_subid
u.range_subid
Indicates a sub-identifier in u.subtree is a range lower bound.
u sub-識別子は、範囲の下限の範囲です。
u.upper_bound
u.upper_bound.
The upper bound of the range sub-identifier. This field is present in the PDU only if u.range_subid is not 0.
範囲サブ識別子の上限。このフィールドは、u.range_subidが0ではない場合にのみPDUに存在します。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (5) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.sr)
（g.sr）
(start 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(start n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | 0 | 0 | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Get-PDU contains the following fields:
AgentX-Get-PDUには、次のフィールドが含まれています。
g.context
g.context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
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-Get-PDU内では、SearchRanges内の終了OIDはNULL値のオブジェクト識別子です。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (6) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.context) OPTIONAL
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet String Length (L) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet 1 | Octet 2 | Octet 3 | Octet 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Octet L - 1 | Octet L | Padding (as required) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(g.sr)
（g.sr）
(start 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(end 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
(start n)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | include | <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:
AgentX-getNext-PDUには、次のフィールドが含まれています。
g.context
g.context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
g.sr
A SearchRangeList containing the requested variables for this session.
このセッションの要求された変数を含むSearchRangeList。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (7) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(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.sr) ...
（g.sr）...
An agentx-GetBulk-PDU contains the following fields:
AgentX-getBulk-PDUには、次のフィールドが含まれています。
g.context
g.context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
g.non_repeaters
g.non_repeaters.
The number of variables in the SearchRangeList that are not repeaters.
中継器ではないSearchRangeListの変数の数。
g.max_repetitions
g.max_repetitions.
The maximum number of repetitions requested for repeating variables.
変数を繰り返すために要求された最大繰り返し数。
g.sr
A SearchRangeList containing the requested variables for this session.
このセッションの要求された変数を含むSearchRangeList。
(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.vb)
（T.VB）
(VarBind 1)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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:
AgentX-TestSet-PDUには、次のフィールドが含まれています。
t.context
T.context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
t.vb
T.VB.
A VarBindList containing the requested VarBinds for this subagent.
このサブエージェントの要求されたvarbindを含むvarbindlist。
These PDUs consist of the AgentX header only.
これらのPDUはAgentXヘッダーのみで構成されています。
The agentx-CommitSet-, -UndoSet-, and -Cleanup-PDUs are used in processing an SNMP SetRequest operation.
agentX-commitsetset、-undoset-、および-cleanup-pdusは、SNMP SetRequest操作を処理する際に使用されます。
An agentx-Notify-PDU is sent by a subagent to cause the master agent to forward a notification.
AgentX-Notify-PDUは、マスタエージェントに通知を転送させるためにサブエージェントによって送信されます。
(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.vb) ...
（n.vb）...
An agentx-Notify-PDU contains the following fields:
AgentX-Notify-PDUには、次のフィールドが含まれています。
n.context
n.context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
n.vb
n n
A VarBindList whose contents define the actual PDU to be sent. This memo places the following restrictions on its contents:
内容が送信される実際のPDUを定義するvarbindlist。このメモはその内容に次の制限を課します。
- If the subagent supplies sysUpTime.0, it must be present as the first varbind.
- サブエージェントがSYSUPTIME.0を供給した場合、それは最初のvarbindとして存在する必要があります。
- snmpTrapOID.0 must be present, as the second varbind if sysUpTime.0 was supplied, as the first if it was not.
- sysuptime.0が指定されていなかった場合、sysuptime.0が指定されていなかった場合、snmptrapoid.0が存在している必要があります。
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-Ping-PDUは、AgentXセッションを介してAgentX PDUを受信して送信するマスターエージェントの能力を監視するために、マスターエージェントにサブエージェントによって送信されます。
(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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-Ping-PDU may contain the following field:
AgentX-Ping-PDUには、次のフィールドが含まれている場合があります。
p.context
P.Context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
Using p.context a subagent can retrieve the sysUpTime value for a specific context, if required.
P.Contextを使用する必要に応じて、サブエージェントは特定のコンテキストのsysuptime値を取得できます。
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.
AgentX-IndexAllocate-PDUは、特定のインデックスオブジェクトの値の割り当てを要求するためにサブエージェントによって送信されます。提案された使用法については、セクション7.1.4.2「登録」を参照してください。
(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.vb) ...
（i.vb）...
An agentx-IndexAllocate-PDU contains the following fields:
AgentX-IndexAllocate-PDUには、次のフィールドが含まれています。
i.context
I.Context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
i.vb
I.VB.
A VarBindList containing the index names and values requested for allocation.
割り当てに対して要求されたインデックス名と値を含むvarbindList。
An agentx-IndexDeallocate-PDU is sent by a subagent to release previously allocated index values.
AgentX-IndexDeallocate-PDUは、以前に割り当てられたインデックス値を解放するためにサブエージェントによって送信されます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.vb) ...
（i.vb）...
An agentx-IndexDeallocate-PDU contains the following fields:
AgentX-IndexDeallocate-PDUには、次のフィールドが含まれています。
i.context
I.Context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
i.vb
I.VB.
A VarBindList containing the index names and values to be released.
リリースされるインデックス名と値を含むvarbindlist。
An agentx-AddAgentCaps-PDU is generated by a subagent to inform the master agent of agent capabilities for the specified session.
AgentX-AddAgentCAPS-PDUは、指定されたセッションのエージェント機能のマスターエージェントに通知するためにサブエージェントによって生成されます。
(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.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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-AddAgentCaps-PDU contains the following fields:
AgentX-AddAgentCAPS-PDUには、次のフィールドが含まれています。
a.context
A.Context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
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].)
マスターエージェントが指定されたコンテキストのSysORIDの値としてエクスポートするエージェント・機能マクロの呼び出しの値を含むオブジェクト識別子。（エージェント機能マクロの呼び出しの値が、実装されたMIBモジュールに関して正確なサポートを記述するオブジェクト識別子であることを思い出してください。エージェント機能マクロと関連のSysorID値のより完全な説明は、STD 58のセクション6、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.
上記のsysorid値に対応するSySordSCRの値として使用されるDisplayStringを含むオクテット文字列。
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-RemoveAgentCAPS-PDUは、マスターエージェントがSysORIDの特定の値をエクスポートするのを停止するように、サブエージェントによって生成されます。この値は、このセッションのAgentX-AddAgentCAPS-PDUのサブエージェントによって以前にアドバタイズされていなければなりません。
(AgentX header)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (17) | 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.id)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| n_subid | prefix | 0 | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-identifier #n_subid |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
An agentx-RemoveAgentCaps-PDU contains the following fields:
AgentX-RemoveAgentCAPS-PDUには、次のフィールドが含まれています。
a.context
A.Context.
An optional non-default context.
オプションのデフォルト以外のコンテキスト
a.id
An ObjectIdentifier containing the value of sysORID that should no longer be exported.
エクスポートされなくなったSysORIDの値を含むObjectIdentifier。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.version (1) | h.type (18) | h.flags | <reserved> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.sessionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.transactionID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.packetID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| h.payload_length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| res.sysUpTime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| res.error | res.index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
An agentx-Response-PDU contains the following fields:
AgentX-Response-PDUには、次のフィールドが含まれています。
h.sessionID
hsessionid.
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.
これがagentX-Open-PDUに対する応答である場合、このセッションのために（マスターエージェントによって割り当てられている）新しいセッションIDが含まれています。
Otherwise it must be identical to the h.sessionID value in the PDU to which this PDU is a response.
そうでなければ、このPDUが応答であるPDUのhesessionID値と同じでなければなりません。
h.transactionID
h.transactionID
Must be identical to the h.transactionID value in the PDU to which this PDU is a response.
このPDUが応答であるPDUのh.transactionID値と同じでなければなりません。
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.
Master AgentからサブエージェントへのAgentX Response PDUでは、h.transactionIDの値は重要ではなく、サブエージェントによって無視されます。
h.packetID
h.packetid
Must be identical to the h.packetID value in the PDU to which this PDU is a response.
このPDUが応答であるPDUのh.packetID値と同じでなければなりません。
res.sysUpTime
res.sysuptire
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の現在の値を含みます。それは、セクション6.1「agentX PDUヘッダー」にリストされている管理PDUのセットに応答してマスターエージェントからサブエージェントに送信されたAgentX Response PDUが関連しています。
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.syspTimeの値は重要ではなく、マスターエージェントによって無視されます。
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（257）、NotoPen（257）、IndexWrongType（259）、IndexNoisaIdailable（260）、IndexNotAllocable（260）、UndupPortedContext（262）、duplicateRegistration（264）、登録（264）、UnknownAgentCAPS（265）、ParseError（266）、依頼された（267）、ProcessionError（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]).
セクション6.1「agentX PDUヘッダー」にリストされている「SNMP要求処理」PDUタイプのセットに対する応答内で、SNMPv2 PDU（RFC 1905 [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ベースです。）
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.
VARBINDLISTは、どのagentX PDUが応答しているかに応じて、Res.Indexに従うことができます。これらのデータは、後続の手順の要素に指定されています。
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プロトコルの実装プロトコルエンティティ（マスターエージェントとサブエージェント）の動作について説明します。ただし、適合性実装の内部アーキテクチャを制限することを意図していないことに注意してください。
The actions of AgentX protocol entities can be broadly categorized under two headings, each of which is described separately:
AgentXプロトコルエンティティのアクションは、2つの見出しの下で広く分類できます。それぞれが別々に説明されています。
(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つ以上のサブエージェント）。
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プロトコルエンティティのアクションについて説明します。そのようなメッセージには、サブエージェントとマスターエージェントとの間の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-Response-PDUが作成され、Res.SyspTimeがデフォルトのコンテキストで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 'に設定されます。解析エラーの例は次のとおりです。
- 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 Length（h.payload）現在の構文を含めるには短すぎる（オブジェクト識別子ヘッダーはより多くのサブ識別子を示し、varbind v.typeはデータを次に示します）
- An unrecognized value is encountered for h.type, v.type, etc.
- 認識されていない値は、h.type、v.typeなどで発生します。
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は `supportedContext 'に設定されます。マスターエージェントが示されたコンテキストをサポートしている場合、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が `ProcisionError 'に設定されます。
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) この時点で、Res.Errorが `NoagentXError 'ではない場合、受信したPDUはさらに処理されません。受信したPDUのヘッダーが正常に解析された場合、AgentX-Response-PDUは返信で送信されます。受信したPDUに正常に解析されたvarbindListが含まれている場合、agentX-response-pduには同じVARBINDLISTが含まれています。受信したPDUのヘッダーが正常に解析されなかった場合、またはマスターエージェントが返信を送信できないため、処理は完了です。
When the master agent receives an agentx-Open-PDU, it processes it as follows:
マスターエージェントがAgentX Open-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-Response-PDUが作成され、Res.SyspTimeがデフォルトのコンテキストで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 'に設定されています。
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-Response-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.Flagsの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.
サブエージェントは通常、このビットをそのネイティブバイト順序付けに対応させるように設定し、通常、開始されたセッションのバイト順序付けは異なりません。マスターエージェントは、PDU内のh.flag network_byte_orderビットに従って各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.Timeout値は、このセッションの応答タイムアウト条件の計算に使用されます。このフィールドは、AgentXSessionTimeOutオブジェクトによってAgentX MIB（作業内容）で参照されています。
- 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.IDおよびO.DESCRフィールドは情報提供の目的で使用されています。これら2つのフィールドは、AgentXSessionObjectIDオブジェクト、およびAgentXSessionDescrオブジェクトによって、AgentX MIB（作業内容）でも参照されています。
5) The agentx-Response-PDU is sent with the res.error field indicating the result of the session initiation.
5) AgentX-Response-PDUは、セッション開始の結果を示すRES.ERRORフィールドと共に送信されます。
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セッションは、上記のセッション固有の属性によって修飾されたマスターエージェントと1つのサブエージェントの間のAgentXプロトコルメッセージの交換のための異なるチャネルです。AgentXセッション確立は、サブエージェントによって開始されます。AgentXセッションは、マスターエージェントまたはサブエージェントのいずれかによって終了できます。
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: 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.
マスターエージェントがAgentX-IndexalCate-PDUを受信すると、セクション7.1「AgentX管理メッセージの処理」で説明した共通処理を実行します。結果Res.Errorが `NoagentXError 'である場合、処理は次のように続行されます.1）varbindlist内の各varbindは、すべて成功するまで処理されるか、または失敗するまで処理されます。varbindが失敗した場合、res.index setをres.Index setを含むREPORTX-RESPTION-PDUは、res.Indexセットを含むRESINDEX SET、およびその後に説明されているようにres.Errorセットを指定します。他のすべてのVARBINDは無視されます。インデックス値は割り当てられません。
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.Nameは、値が割り当てられるMIBオブジェクト・タイプのOIDプレフィックスです。
- v.type is the syntax of the MIB OBJECT-TYPE for which a value is to be allocated.
- v.typeは、値が割り当てられるMIBオブジェクト・タイプの構文です。
- 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.Dataは要求された特定のインデックス値を示します。new_indexまたはany_indexビットが設定されている場合、V.Dataの実際の値は無視され、適切なインデックス値が生成されます。
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.nameに現在割り当てられているインデックス値がない場合、v.typeは有効なインデックスタイプ値に対応していない場合、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.Nameの割り当てられているインデックス値が割り当てられているが、それらの値の構文がv.typeと一致しない場合、varbindは失敗し、rec.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とany_indexビットの両方がクリアされている場合、特定のインデックス値の割り当てが要求されています。指定されたコンテキストで要求されたインデックスがv.nameに既に割り当てられている場合、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.nameの次の利用可能なインデックス値を生成する必要があります。マスターエージェントの最後の再初期化そのような値が生成されない場合、varbindは失敗し、res.errorは `indexno_available 'に設定されます。
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) それ以外の場合、any_indexビットが設定されている場合、マスターエージェントは示されたコンテキストのv.nameのインデックス値を生成します。この値が現在すべてのサブエージェントに割り当てられていないという制約です。そのような値が生成されない場合、varbindは失敗し、res.errorは `indexno_available 'に設定されます。
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) すべてのvarbindが正常に処理された場合、agentx-response-pduはRes.Errorを `NoagentXError 'に返信して送信されます。agentx-indexalcate-pduで送信されたものと同一のvarbindlistが含まれています。
See section 7.1.4.2, "Registering Stuff" for more information on how subagents should perform index allocations.
サブゲントのインデックス割り当てを実行する方法の詳細については、セクション7.1.4.2「登録」を参照してください。
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を受信すると、セクション7.1「AgentX管理メッセージの処理」で説明した共通処理を実行します。結果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) varbindlist内の各varbindは、すべてが成功するまで処理されるか、または失敗するまで処理されます。VARBINDが失敗した場合、AgentX-Response-PDUは、Res.Index Setを含むREPLISHで送信され、res.Index Setがresexex setを指定し、その後説明されているようにRes.Errorセットを指定します。他のすべてのVARBINDは無視されます。インデックス値は解放されません。
VarBinds are processed as follows:
VARBINDSは次のように処理されます。
- v.name is the name of the index for which a value is to be released
- v.nameは、値がリリースされるべき索引の名前です。
- v.type is the syntax of the index object
- v.typeはインデックスオブジェクトの構文です
- v.data indicates the specific index value to be released. The NEW_INDEX and ANY_INDEX bits are ignored.
- v.Dataリリースする特定のインデックス値を示します。new_indexおよびany_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) すべてのvarbindが正常に処理された場合、res.errorは `NoagentXError 'に設定され、agentX-Response-PDUが送信されます。AgentX-IndexDeallocate-PDUで送信されたものと同一のvarbindlistが含まれています。
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.
解放されたすべてのインデックス値が利用可能になり、any_Index値に対する後続の割り当て要求および特定のインデックス値に対するその後の割り当て要求に応答して使用され得る。
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-Register-PDUを受信すると、セクション7.1「AgentX管理メッセージの処理」で説明した共通処理を実行します。結果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.Priorityの同じ値に登録された重複サブツリーが発生した場合、要求は失敗し、agentX-Response-PDUがRes.Errorセットを `duplicateRegistration 'に返されます。
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) それ以外の場合、マスターエージェントが実装固有の理由からこの登録を許可しない場合、要求は失敗し、agentX-Response-PDUがRes.Errorセットを `RequestDenied 'に返されます。
3) Otherwise, the agentx-Response-PDU is returned with res.error set to `noAgentXError'.
3) それ以外の場合、AgentX-Response-PDUはres.errorを `NoagentXError 'に設定されます。
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.
マスターエージェントは、このMIB領域を、表示されたコンテキストの登録データストアにその登録データストアに追加して、その後に受信されたSNMPプロトコルメッセージについてはディスパッチングフェーズ中に考慮されます。
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) 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-register-pdu r rstreeが最もサブID、すなわち最も具体的なrのrteeを含んでいたものを選択してください。注：SUBIDの範囲の有無は、「固有の」オブジェクト識別子が別のオブジェクト識別子と比較される方法についての使用権を持ちません。
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-register-pduがR.Priorityの値が小さいことを指定したものを選択してください。
This section describes more fully how AgentX subagents use the agentx-IndexAllocate-PDU and agentx-Register-PDU to achieve desired configurations.
このセクションでは、agentXサブエージェントがagentX-indexalcate-pduとagentx-register-pduを使用して望ましい構成を達成する方法について説明します。
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-Register-PDUのR.Priorityフィールドは、所望のサブエージェント構成を実現するために人間管理者によって操作されることを意図しています。通常、これは、レガシーアプリケーションが特定のサブツリーを登録する場合、異なる（設定可能な）アプリケーションが同一のサブツリーに対して権限になる必要があるかもしれません。
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）。
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.
マスターエージェントは、インデックスオブジェクト（OID）のデータベースを保持し、各インデックスに対して、それに割り当てられている値を保持します。インデックスオブジェクトが表現されているMIB変数（ある場合）のMIB変数を認識していません。
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つの選択肢は、任意の整数索引（例えば、IF-MIB（RFC 2233 [19]）、FDDI MIB（RFC 1285 [20]）のSNMPFDDISMTINDEXのための多くのMIB仕様に存在する一意性と恒星の要件を反映しています。System Application MIB（RFC 2287 [21]）のSYSAPPLINSTALLPKGINDEX）。そのようなインデックスを使用してテーブルを共有するためのサブエージェントの必要性は、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サブエージェントは、「インデックスの最初のリクエスト割り当て」のモデルに従って、対応する領域を登録する必要があります。その後、索引割り当て要求が成功すると、登録できるものの優れたヒント（まだ保証はありません）を提供します。他のサブエージェントセッションがすでにテーブルの行を登録しているため、登録は失敗する可能性があります（「重複履歴」）。
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 'で失敗した場合、この行のための以前に割り当てられたインデックス値を割り当て解除して、ステップ1）に進みます。
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.
たとえば、RFC 1514の実行中のソフトウェアプロセス（HRSWRuntable）の表は、システムのネイティブプロセス識別子（PID）によって索引付けされています。独自のプロセスに対応するHRSWRuntableの行を実装するサブエージェントは、インデックス値を割り当てることなく、その行のオブジェクトインスタンスを定義する領域を単に登録します。
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".
サブエージェントはインターフェースを実装し、IFTableのRFC 2233の単一行を登録したいと考えています。これは、割り当てられたことのない値に対して、索引オブジェクト "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.
SubAgentは、1.3.6.1.2.1.2.2.1のAgentX-Register-PDUのMIB領域を指定して、IFTableの行7を登録しようとします。[1-22] .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 'で失敗した場合、サブエージェントは失敗したインデックスを割り当て、新しいインデックス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.
この同じサブエージェントは、そのインタフェースに対応するIPNET文章を登録することを望みます（ifIndex i）。この表の構造のために、それ以上のインデックス割り当ては行われない。サブエージェントはMIB領域をIPNETOMETABLEに登録できます。[1-4] .i、ipnettomediaIfIndexの値がiのテーブルのすべての行に対して責任を主張しています。
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.
ネットワークデバイスは、一連のプロセッサで構成されており、各プロセッサは一意の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のMIB領域を登録できます。[1-5] .a.b.c.d。ここで、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.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:
アプリケーション管理MIB（RFC 2564 [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オブジェクト型構文Unsigned32（1 .. 'ffffffff'h）max-access read-only 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オブジェクト型構文SNMPADMINSTRING MAX-ACCESS STATUSの現在の説明「サービスの人間が読める名前。単一のプロトコルに関してサービスを識別できる場合と同様に、文字列を確立する必要があります。IANAが割り当てられたものなどの名前は、STD 2 [23]で見つけられるか、または他の何らかの権限によって定義されています。場合によっては、秘密の表記法が適用され、これらの場合に文字列はこれらの標準以外の規則と一致している場合があります。適用ステートメントは指定できます。使用するサービス名。」
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には固有の意味があり、サブエージェントが使用する値が既知であるため、このインデックスの値を割り当てるためにサブエージェントが合理的ではありません。
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を受信すると、セクション7.1「AgentX管理メッセージの処理」で説明した共通処理を実行します。結果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.UREE、U.PRIORITY、u.range_subid（およびu.range_subidが0、u.upper_boundの場合）で、示されているコンテキストがこのセッション中に行われた既存の登録と一致しない場合、AgentX-Response-PDUが返されます。Res.Errorを `unknownRegistration 'に設定します。
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) それ以外の場合、AgentX-Response-PDUはREPON.ERROR SETを `NOAGENTXERROR 'に返信し、前回の登録は登録データストアから削除されます。
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を受信すると、セクション7.1「AgentX管理メッセージの処理」で説明した共通処理を実行します。結果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に追加します。AgentX-Response-PDUはRes.Errorを `NoagentXError 'に返信して送信されます。
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を受信すると、セクション7.1「AgentX管理メッセージの処理」で説明した共通処理を実行します。結果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.idとオプションのA.Contextの組み合わせがこのセッション中にこのサブエージェントによって追加されたSySortableエントリを表していない場合、agentx-response-pduはres.errorセットを `UnknagentCaps 'に返されます。
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) それ以外の場合、マスターエージェントは対応するSYSOTTABLEエントリを削除し、res.errorを `NoagentXError 'に設定されているagentx-response-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-Close-PDUを受信すると、AgentX-Close-PDUが含まれていないため、ステップ4）が実行されないため、ステップ4）が実行されない場合は、セクション7.1「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) マスターエージェントは後述のようにAgentXセッションを閉じ、res.Errorをres.Errorを `NoagentXError 'に返信します。
- 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-register-pduの処理」で説明されているように未登録です。
- All index values allocated during this session are freed, as described in section 7.1.3, "Processing the agentx-IndexDeallocate-PDU".
- このセッション中に割り当てられたすべての索引値は、7.1.3項「agentX-indexDeallocate-PDUの処理」で説明されているように解放されます。
- All sysORID values that were registered during this session are removed, as described in section 7.1.7, "Processing the agentx-RemoveAgentCaps-PDU".
- このセッション中に登録されたすべてのSysORID値は、7.1.7項「AgentX-RemoveAgentCAPS-PDUの処理」で説明されているように削除されます。
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リージョン、エージェント機能などを再登録する必要があります。
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 PDUを受信できないことを（基盤となるトランスポートから）検出できる場合は、セクション7.1.8「AgentX-Close-PDUの処理」、ステップ1）で説明されているすべての影響を受けるAgentXセッションを閉じる必要があります。。
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トラップ情報を送信するサブエージェントは、RFC 1908の3.1.2で説明されているように、SNMPTRAPOID.0の値を（最小限に）マッピングする必要があります[24]。
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-Notify-PDUを受信すると、セクション7.1「AgentX管理メッセージの処理」で説明した共通処理を実行します。結果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) 2番目のvarbindがsnmptrapoid.0ではない場合、res.errorは `Processerror 'とRes.Indexに設定されています
(b) otherwise these two VarBinds are used as the first two VarBinds within the generated notification.
(b) それ以外の場合は、これら2つのVARBINDが生成された通知内の最初の2つのVARBINDとして使用されます。
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は `processerror 'とres.indexに設定されています1
(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-Response-PDUは、元のvarbindlistを含む、Res.ErrorとRes.Indexセットを設定し、上記のように送信されます。res.errorが `NoagentXError 'の場合、通知はマスターエージェントの実装固有の設定に従って送信されます。SNMPv1トラップPDUが生成された場合、推奨マッピングはRFC 2089 [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-Notify-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-PING-PDUを受信すると、セクション7.1「AgentX管理メッセージの処理」で説明した共通処理を実行します。結果Res.Errorの場合は `NoagentXError 'の場合、処理は次のように続行されます。
1) An agentx-Response-PDU is sent in reply.
1) AgentX-Response-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.
サブエージェントがそのPINGに応答を受け取らない場合、またはマスターエージェントがAgentXメッセージを受信できない（基盤となるトランスポートから）検出できる場合は、最終的には新しいAgentXセッションを再登録する必要があります。そのMIB地域など
When an SNMP GetRequest, GetNextRequest, GetBulkRequest, or SetRequest protocol message is received by the master agent, the master agent applies its access control policy.
Master Agentによって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プロトコルメッセージの場合、マスターエージェントは、受信エンティティに適用されるSTD 15、RFC 1157 [8]のセクション4.1で定義されているプロシージャの要素を適用します。SNMPv3の場合、Master Agentは、RFC 2571 [1]のセクション3.1.2およびセクション4.3で説明されているように、マスターエージェントは、場合によってはビューベースのアクセス制御モデル（RFC 2575 [15]を参照）を適用します（RFC 2575 [15]）。
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コンテキストを使用します（RFC 2571 [1]のセクション3.3.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 PDUの交換に収集された情報から構築されます。SNMP要求PDUの受信および初期検証が、Master Agentは、以下の手順を使用して、AgentX PDUを適切なサブエージェントにディスパッチし、サブエージェントの応答をマーシャリングし、SNMPレスポンスPDUを構築します。
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 PDUを適切なサブエージェントにディスパッチする。
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つ以上のサブエージェントセッションに1つ以上のAgentX PDUを送信することができます。一般にAgentXマスターエージェントには、以下の手順の規則が適用されます。PDU固有の規則は該当するセクションにリストされています。
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.
Master Agentは、SNMP getNextRequest-PDUを保守しながらAgentX-Get-PDUを送信することを選択できます。マスターエージェントは、SNMP getBulkRequest-PDUを保守しながらagentx-get-pdusまたはagentx-getnext-pdusを送信することを選択できます。これについての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）が従う必要があります。
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 PDUは、TransactionIDの同じ値を含める必要があります。マスターエージェントによって処理された各異なるSNMP要求は、セッションへの（32ビットフィールドの範囲内）TransactionIDの一意の値を存在する必要があります。
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操作の場合、場合によっては反復プロセスの任意の段階で、マスターエージェントは特定のサブエージェントセッションに複数の検索レンジをディスパッチする必要があるかもしれません。マスターエージェントは、1つのAgentX PDUに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の正しいコンテンツと順序付けが維持されていることを確認する必要があります。
The following rules govern the number of VarBinds in a given AgentX PDU:
次の規則は、特定のAgentX PDUのVARBINDの数を管理します。
a) The subagent must support processing of AgentX PDUs with multiple VarBinds.
a) サブエージェントは、複数のVARBINDを持つAgentX PDUの処理をサポートしている必要があります。
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要求を処理するとき、マスターエージェントは特定のサブエージェントセッションに適用可能なすべてのvarbindを単一のAgentX-TestSet-PDUに送信する必要があります。
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、または複数のPDUを単一のvarbindsを持つ複数のPDU、またはそれらの極値の間にあるPDUの単一の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) それ以外の場合、または指定された値が実用的でない場合は、マスターエージェント実装固有のデフォルト値
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.
複数のMIBリージョンを参照するAgentX PDUがディスパッチされると、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のコンテキストフィールドにエンコードされ、h.flagsにはon_default_contextビットが設定されます。
Otherwise, no context Octet String is added to the PDU, and the NON_DEFAULT_CONTEXT bit is cleared.
それ以外の場合は、PDUにコンテキストオクテット文字列が追加されず、Non_Default_Contextビットがクリアされます。
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領域のセット内で、バインディングの名前を含む正常な領域を見つけてください。
(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-get-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はNULLとしてエンコードされています。
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) 変数バインディングの名前を含み、完全修飾インスタンスではありません。
b) is the first lexicographical successor to the variable binding's name.
b) 可変バインディングの名前に対する最初の辞書の後継者です。
(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の "include"フィールドが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 @ Rteeは開始OIDにエンコードされ、その「INCLUDE」フィールドは1に設定されています（これは推奨されています。これは推奨されています。実装はRの手順です。実装はRに先行する開始OID値を使用することを選択できます。.subtree、その場合、includeビットは0にする必要があります。
- 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の終了OIDは、NULLのどちらか、または辞書学的には開始OIDを成功させる値であるようにエンコードされます。これは、マスターエージェントが可能な返されたインスタンスを「スコープ」したい方法に応じて実装固有の選択です。
(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.) Each variable binding in the request PDU is processed as follows:
（注：次の手順の概要は、RFC 1905の4.2.3「GetBulkRequest-PDU」のセクション4.2.3「13」に密接に基づいています。SNMP getBulkRequest-PDU自体の形式については、それを参照してください。）それぞれリクエスト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で説明されているとおりに、正式なターゲット領域とターゲットセッションを識別します（7.2.1.2項「agentX-getnext-pdu」を参照）。
(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-getNext-PDUで説明されているように、この変数バインディングのターゲットセッションのagentx-getBulk-PDUの末尾にSearchRangeを追加します。元のリクエスト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.max_repetitionsの値は、元の要求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.
マスターエージェントは、単純な健全性チェック、レジストリに基づく現在の反復の最適化、潜在的な応答-PDUの最大のサイズ、AgentXトランスポートの既知の制約、またはその他の実装固有の制約の最適化により、そのような変更を行うことがあります。
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のSNMP SetRequest-PDUのセマンティクスを実現するために、Test-Commit-Undo-Cleanupフェーズを採用しています。初期段階では、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.1項「AgentX-Get-PDU」、ステップ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) そのようなターゲット領域が存在しない場合、この変数バインディングは `notwrited 'のエラーで失敗します。このリクエストの処理は完了です。
(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) セクション5.4「値表現」で説明されているように、この可変バインディングのターゲットセッションのPDUの最後にVARBINDを追加します。
Note that all VarBinds applicable to a given session must be sent in a single agentx-TestSet-PDU.
特定のセッションに適用可能なすべてのVARBINDは、単一のAgentX-TestSet-PDUで送信する必要があります。
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に対して計算されます。セクション8（トランスポートマッピング）で説明されているように、保留中の各PDUは特定のトランスポートドメイン/エンドポイントに（hsessionID値を介して）マッピングされます。
A subagent initially processes a received AgentX PDU as follows:
サブエージェントは、最初に受信したAgentX PDUを次のように処理します。
- If the received PDU is an agentx-Response-PDU:
- 受信したPDUがAgentX-Response-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.typeは、h.typeがResponse Res.Error、res.Error、res.Error、varbindlist、およびvarbindlistに設定されていることを除いて、ヘッダーフィールドが受信した要求PDUと同じであるAgentX-Response-PDUが作成されます。
2) If the received PDU cannot be parsed, res.error is set to `parseError'.
2) 受信したPDUを解析できない場合、res.errorは `parseError 'に設定されます。
3) Otherwise, if h.sessionID does not correspond to a currently established session, res.error is set to `notOpen'.
3) それ以外の場合、hsessionIDが現在確立されているセッションに対応していない場合、res.errorは `onepen 'に設定されます。
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) この時点で、Res.Errorが `NoError 'ではない場合、受信したPDUはさらに処理されません。受信したPDUのヘッダーが正常に解析された場合、AgentX-Response-PDUは返信で送信されます。受信したPDUのヘッダーが正常に解析されなかった場合、または他の何らかの理由でサブエージェントが返信を送信できない場合は処理が完了しました。
A conformant AgentX subagent must support the agentx-Get, -GetNext, and -GetBulk PDUs, and must support multiple variables being supplied in each PDU.
適合性AgentXサブエージェントは、AgentX-Get、-getNext、および-GetBulk PDUをサポートし、各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-Get-、GetNext、またはGetBulk-PDUを受信すると、示されている管理操作を実行し、AgentX-Response-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は、後述のように処理され、AgentX-Response-PDUのvarbindListの対応する場所にvarbindが追加されます。以下で説明しない理由で処理が失敗する必要がある場合、Res.Errorはrecosr '、res.indexに設定されたSearchRangeのインデックスに設定され、varbindlistはnullにリセットされ、このAgentX-Responses-PDUが返されます。マスターエージェント。
Upon the subagent's receipt of an agentx-Get-PDU, each SearchRange in the request is processed as follows:
サブエージェントがagentX-get-pduを受信すると、要求内の各SearchRangeは次のように処理されます。
(1) The starting OID is copied to v.name.
(1) 開始OIDはv.nameにコピーされます。
(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が、示されているコンテキストとセッション内でこのサブエージェントによってインスタンス化された変数の名前と正確に一致した場合、v.typeとv.dataは、セクション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はセクション5.4「値表現」で説明されている方法で `nosuchObject 'に設定されます。
(4) Otherwise, the VarBind is set to `noSuchInstance' in the manner described in section 5.4, "Value Representation".
(4) それ以外の場合、VARBINDは、セクション5.4「値表現」に記載されている方法で「NosuchInstance」に設定されています。
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がNULLではない場合、変数の名前は終了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.nameはその変数の名前に設定されます。v.typeおよびv.dataは、セクション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.Nameは開始OIDに設定され、VARBINDはセクション5.4「値表現」で説明されている方法で `endofmibview 'に設定されます。
A maximum of N + (M * R) VarBinds are returned, where
最大N（M * R）VARBINDSが返されます。
N equals g.non_repeaters, M equals g.max_repetitions, and R is (number of SearchRanges in the GetBulk request) - N.
nはg.non_repeaters、mはgmax_repetitionsに等しく、Rは（GetBulk要求の検索レンジの数） - 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 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:
MとRが両方ともゼロでない場合、残りのR SearchRangesは繰り返し処理されて潜在的に多くのVARBINDを生成する。Iがゼロより大きい、M以上の各反復Iについて、Sがゼロより大きくr以下の繰り返しの繰り返し検索範囲Sが（n（n（（（i - 1））※R）S）varbindがAgentX-Response-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）rexicographical odeの要求されたOIDへの（i）辞書の後継です。
(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で、「include」フィールドが1の場合、変数の名前は、（N S）宛てのOIDと等価であるか、または最初の辞書の後継です。
- If the ending OID is not null, the variable's name lexicographically precedes the ending OID.
- 終了OIDがNULLではない場合、変数の名前は終了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.nameは配置された変数の名前に設定されます。v.typeおよびv.dataは、セクション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.Nameは、現在1でない限り、（n（（i-2）r）s）-th varbindのv.nameに設定されています。その場合は、（n（n）の開始OIDの値に設定されます。s）~th SearchRange。
Note that further iterative processing should stop if
さらに繰り返し処理を停止する必要があります
- For any iteration i, all s values of v.type are ` endOfMibView'.
- 繰り返しiの場合、v.typeのすべての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、-creanupset、-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.
適合性AgentXサブエージェントは、AgentX-TestSet、-CommitSet、-UndoSet、および-cleanupset PDUをサポートし、AgentX-TestSet-PDUで指定されている複数の変数をサポートしている必要があります。
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.
これら4つのPDUは、表示された管理操作をまとめて実行するために使用されます。AgentX-Response-PDUは、マスタエージェントに操作状態のマスターエージェントに通知するように、各PDUに返信されます。
The master agent must serialize Set transactions for each session. That is, a session need not handle multiple concurrent Set transactions.
マスターエージェントは、セッションごとに設定されたトランザクションをシリアル化する必要があります。つまり、セッションは複数の同時設定トランザクションを処理する必要はありません。
These Response-PDUs do not contain a VarBindList.
これらの応答PDUはvarbindlistを含みません。
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.
SubAgentのAgentX-TestSet-PDUの受信時に、PDU内の各VARBINDは、RFC 1905のセクション4.2.5のセクション4.2.5で説明されているように、それらがすべて成功するまでまたは失敗するまで検証されます[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操作を正常に実行するために必要なすべてのリソース（メモリ、ライトアクセスなど）の可用性を確保するためにさらなる責任を負います。これを保証できない場合、サブエージェントはres.errorを `ResourceUnavailable 'に設定する必要があります。この検証ステップの結果として、res.Errorフィールドが次のSNMPv2 PDUエラー状態の値のいずれかに設定されている応答でagentX-Response-PDUが送信されます（RFC 1905のセクション3「定義」を参照）。]）：
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）、不正確さ（7）、不正確さ（8）、不正なもの（9）、誤った値（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フィールドは、検証が失敗したvarbindのインデックスに設定する必要があります。
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つかもしれません。その後の処理中にextensibleエージェントが `CommitFailed 'または` undafailed'を返す必要があるのであれば、実装者はこの権利をすることを強く推奨されます。
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は、以前のTestSet-PDUが示す管理操作を実際に実行する必要があることを示しています（RFC 1905の4.2.5の検証後のセクションで説明されているように）。管理操作を実行した後、Res.Errorフィールドが次のSNMPv2 PDUエラーステータス値のいずれかに設定されているAgentX-Response-PDUを返信します（RFC 1905のセクション3、「定義」を参照）。]）：
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フィールドは、操作が失敗したagentx-testset-PDUでvarbindのインデックスに設定する必要があります。それ以外の場合、res.indexは0に設定されています。
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で要求された管理操作を元に戻す必要があることを示します。UNDOプロセスは、RFC 1905のセクション4.2.5で説明されています[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]):
UNDOプロセスを実行した後、サブエージェントは、RES.ERRORフィールドが次のSNMPv2 PDUエラー状態の値のいずれかに設定されているAgentX-Response-PDUを返信します（RFC 1905のセクション3「定義」を参照）。]）：
noError (0), undoFailed (15)
noerror（0）、undafailed（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.
この値が「undafailed」の場合、res.indexフィールドは、操作が失敗したagentX-testset-PDUで発生したvarbindのインデックスに設定する必要があります。それ以外の場合、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のサブエージェント処理」に記載されているようにリソースなどをリリースする必要があります。
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で要求された管理操作の処理の終わりをシグナリングします。これは、管理要求を実行するために予約されている可能性があるリソースを解放する可能性があることをサブエージェントへの表示です。サブエージェントによって応答は送信されません。
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.
マスターエージェントは、すべてのSubAgent AgentX Response PDUをマーシャリングし、SNMPレスポンスPDUを構築します。次のいくつかのサブセクションでは、すべてのSubAgent AgentX応答PDUの初期処理を説明し、続いて、各特定のサブエージェント応答についての後続の処理について説明します。
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-Close-PDUの処理の処理」、ステップ（2）で説明されているようにAgentXセッションを閉じる必要があります。
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 Response PDUのh.packetid、hesessionid、およびh.transactionIDフィールドは、サブジャント応答を相関させるために使用されます。応答がこのSNMP操作に関係しない場合は無視されます。
3) Otherwise, the responses are processed jointly to form the SNMP response PDU.
3) そうでなければ、応答は共同で処理されてSNMP応答PDUを形成する。
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: 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.
agentX-get-pduに対するサブエージェントの応答を共通処理した後（7.2.5.1項「すべてのAgentX Response PDUの一般的な処理」を参照）、処理は以下のステップで続行されます.1）受信されたAgentX Response PDUの場合、res.errorが `NoError 'ではない場合、SNMPレスポンスPDUのエラーコードはこの値に設定されます。Res.ErrorのagentX固有の値（ `parseError '）が含まれている場合、SNMPレスポンスPDUのエラーコードは代わりにGenerrの値に設定されます。また、SNMPレスポンスPDUのエラーインデックスは、SubAgentのAgentX Response PDUのFailed 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レスポンスPDUは無視されます。処理は完了です。SNMPレスポンスPDUを送信する準備が整いました（「SNMP Response-PDUの送信」を参照）。
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 Response 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に対するサブエージェントの応答を共通処理した後（7.2.5.1項「すべてのAgentX Response PDUの一般的な処理」を参照）、処理は以下のステップで続行されます。
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の場合、res.errorが `NoError 'ではない場合、SNMPレスポンスPDUのエラーコードはこの値に設定されます。Res.ErrorのagentX固有の値（ `parseError '）が含まれている場合、SNMPレスポンスPDUのエラーコードは代わりにGenerrの値に設定されます。また、SNMPレスポンスPDUのエラーインデックスは、SubAgentのAgentX Response PDUのFailed 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レスポンスPDUは無視されます。処理は完了です。SNMPレスポンスPDUを送信する準備が整いました（「SNMP Response-PDUの送信」を参照）。
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 Response 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: 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.
すべての予定されているAgentX Response PDUが処理された後に、VARBINDSに依然としてV.Typeフィールドに値 `endofmibview 'が含まれている場合、処理は続行される必要があります.3）AgentX要求ディスパッチの新しい反復が開始されます（7.2.1.2項で説明されているように）。v.typeが `endofmibview 'であるvarbindのみが処理される" 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.nameの値に設定され、その "include"フィールドは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 PDUはターゲットセッションで送信され、その応答は7.2.5項「AgentX Responsesのマスターエージェント処理」で説明されているステップに従って受信および処理されます。
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:
手順4で識別された新しいターゲット領域のR Recheは、 `EndofMibView 'を返した領域に対してrexicographical succemence r rsecteeではないかもしれないことに注意してください。たとえば、次のレジストリを考慮してください。
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-request-pduセッションBを処理している間に1.3.6.1.2.1.4で変数名の `endofmibview 'を返す場合、手順4で識別されたターゲットMIB領域は1.3.6.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がそのリージョンにとって権限がないため、破棄する必要があります。
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に対するサブエージェントの応答の一般的な処理の後（7.2.5.1項「すべてのAgentX Response PDUの一般的な処理」を参照）、処理はさらに続行されます。
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 PDUの交換AgentX-COMMITSET、-UNDOSET、および-CLEANUPSET-PDUの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-Response-PDUは無視されます。
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は、「SNMP Response-PDUの送信」の7.2.6で下述のように構築されています。
2) Otherwise an agentx-CommitSet-PDU is sent to all involved sessions.
2) それ以外の場合は、AgentX-COMMITSET-PDUがすべての関連セッションに送信されます。
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:
SubAgentのAgentX-COMMITSET-PDUに対する応答を共通処理した後（7.2.5.1項「すべてのAgentX Response PDUの一般的な処理」を参照）、処理は次のステップで続行されます。
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のFailed 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-UndoSet-PDUは、AgentX-COMMITSET-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 Response-PDUの送信」の7.2.6項に以下のように構成されています。
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に対するサブエージェントの応答を共通処理した後（セクション7.2.5.1「すべてのAgentX Response PDUの一般的な処理」を参照）、処理は次のステップで続行されます。
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) 任意の応答が「undafailed」の場合、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のFailed 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）で設定しました。
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応答のマスターエージェント処理」で説明されている処理が完了すると、利用可能なSNMP応答PDUがあります。Master Agentは、PDUをメッセージにカプセル化してSNMP管理要求の発信者に送信するために、SNMPプロトコルの該当するバージョンのプロシージャの要素を実装しています。これは、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マッピングはRFC 2089 [25]で定義されています。（特にCANTRO64の構文を処理するための規則は、適切な構文のvarbindが返されるまで、AgentX GetBulkまたはGetNext PDUを再送信する必要がある可能性があります。）
AgentX subagents are not aware of MIB views, since view information is not contained in AgentX PDUs.
AgentX PDUにビュー情報が含まれていないため、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節「手続きの要素」の手順の説明は、任意の適合的な実施の内部アーキテクチャを制約することを意図するものではない。特に、7.2.1項で説明されているマスターエージェントの手順
"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.
MIBビューを実装するときにAgentXの交換を最適化するように、「AgentX PDUのディスパッチ」およびセクション7.2.5に、「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-Get、GetNext、GetBulk-PDUのサブエージェント処理」は、そのような最適化で検索レンジの変更を使用できるように、サブエージェントの動作を定義します。
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.
状態図は、トランスポート接続とセッション確立のためのマスターエージェントの視点から、そしてセット取引処理のためのサブエージェントの視点から提示されます。
The following table presents, from the subagent's perspective, the state transitions involved in Set transaction processing:
次の表は、サブエージェントの観点から、SET取引処理に含まれる状態遷移を示しています。
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
---------+---------------+--------------+---------+--------+--------
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 CLEANUPSET 2）テストセットCOMMITSETアンドセット3）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
テストセットのコミッション
may walk through either of these two state sequences:
これら2つの状態シーケンスのどちらかを歩くことができます。
(initial) TestOK CommitOK (done) (initial) TestOK CommitFail (done)
（初期）Testok Commitok（完了）（初期）Testok CommitFail（完了）
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
----------------+--------------+--------------
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)
---------------+-------------+----------------
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
---------------+-------------+----------------
The same AgentX PDU formats, encodings, and elements of procedure are used regardless of the underlying transport.
基礎となるトランスポートにかかわらず、同じAgentX PDUフォーマット、エンコーディング、およびプロシージャの要素が使用されます。
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接続要求を受け入れます。このポート番号を使用してマスターエージェントに接続します。
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 PDUを運ぶ。同じTCP接続を使用して、複数のAgentXセッションを確立できます。AgentX PDUはAgentXセッション内で送信されます。AgentXピアは、hsessionIDを特定のTCP接続にマッピングする責任があります。
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 PDUを「インターリーブ」してはなりません。1つのPDUのすべてのバイトは、異なるPDUのバイトの前に送信する必要があります。受信エンティティは、AgentX PDUの境界と一致しないバイトシーケンスを配信するためにTCP用に準備する必要があります。
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
- ソケットは、特に重いネットワークI / Oの存在下で、TCPまたはUDPよりも優れた性能を提供します。
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）ソケットを表します。
Once a connection has been established, the AgentX peers use this connection to carry all AgentX PDUs.
接続が確立されると、AgentXピアはこの接続を使用してすべてのAgentX PDUを運ぶ。
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 PDUはAgentXセッション内で送信されます。AgentXピアは、hsessionIDを特定の接続にマッピングする責任があります。
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 PDUを「インターリーブ」してはなりません。1つのPDUのすべてのバイトは、異なるPDUのバイトの前に送信する必要があります。エージェントX PDUの境界と一致しないバイトシーケンスを配信するためのソケットに対して受信エンティティを作成する必要があります。
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つの処理エンティティ間のプロトコルを定義し、そのうちの1つが受信された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セッション中に、このサブエージェントのどの部分が登録できますか？
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-Register-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).
AgentXサブエージェントは、ネットワークトランスポートメカニズム（例えば、TCP）、または「ローカル」メカニズム（例えば、共有メモリ、名前付きパイプ）を使用してマスターエージェントに接続できます。
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".
ローカルトランスポートメカニズムを使用し、サブエージェントとマスターエージェントの両方が同じホスト上で実行されている場合、接続認証をオペレーティングシステムの機能に委任できます。その後、最初のセキュリティ問題に対する回答は次のとおりです。「サブエージェントに十分な権限がある場合に限り、オペレーティングシステムは接続を許可します。
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.
ネットワークトランスポートが使用されている場合、現在固有のセキュリティはありません。トランスポート層セキュリティ、SSL、またはIPSecは、この動作モードでサブエージェント接続を制御および保護するために使用する必要があります。
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.
ただし、マスターエージェントと同じホスト上でサブエージェントが常に実行され、オペレーティングシステム機能を使用して、正しく認証されたサブエージェントのみがマスターエージェントへの接続を確立できるようにすることをお勧めします。
The initial development of this memo was heavily influenced by the DPI 2.0 specification RFC 1592 [26].
このメモの初期発展は、DPI 2.0仕様RFC 1592の影響を強く受けていました[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エージェント拡張性（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.
David Battle、Uri Blumenthal、Jeff Case、Maria Greene、Lauren Heintz、Dave Keeney、Harmen Van Der Linde、Bob Natale、Aleksey Romanov、Don Ryan、Juergen 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.
名誉ある言及は、この仕様に対する彼の多数の技術的な貢献を認識してRandy Presuhnに拡張されています。AgentX EメールリストとFTPサイトの（およびホスティング）の彼の多くの答えは、ワーキンググループの議長に提供された価値のあるサポートとガイダンスランディのために。
The AgentX Working Group is chaired by:
AgentX Working Groupは議長を務めます。
Bob Natale ACE*COMM Corporation 704 Quince Orchard Road Gaithersburg, MD 20878
Bob Natale Ace * Comm Corporation 704 Quince Orchard Road Gaithersburg、MD 20878
Phone: +1-301-721-3000
Fax: +1-301-721-3001
EMail: bnatale@acecomm.com
Mike Daniele Compaq Computer Corporation 110 Spit Brook Rd Nashua, NH 03062
Mike Daniele Compaq Computer Corporation 110 Spit Brook Rd Nashua、NH 03062
Phone: +1-603-881-1423
EMail: daniele@zk3.dec.com
Bert Wijnen IBM T.J.Watson Research Schagen 33 3461 GL Linschoten Netherlands
Bert Wijnen IBM T.J.Watson Research Schagen 33 3461 GL Linschotenオランダ
Phone: +31-348-432-794
EMail: wijnen@vnet.ibm.com
Mark Ellison (WG editor) Ellison Software Consulting, Inc. 38 Salem Road Atkinson, NH 03811
Mark Ellison（WG Editor）エリソンソフトウェアコンサルティング、Inc。38 Salem Road Atkinson、NH 03811
Phone: +1-603-362-9270
EMail: ellison@world.std.com
Dale Francisco (editor) Cisco Systems 150 Castilian Dr Goleta CA 93117
Dale Francisco（編集）シスコシステムズ150カスティーリャ博士Goleta CA 93117
Phone: +1-805-961-3642
Fax: +1-805-961-3600
EMail: dfrancis@cisco.com
[1] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[1] Harrington、D.、Presuhn、R.およびB.Wijnen、「SNMP管理フレームワークを説明するためのアーキテクチャ」、RFC 2571、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] Rose、M.およびK. McCloghrie、「TCP / IPベースのインターネットの管理情報の構造と識別」、STD 16、RFC 1155、1990年5月。
[3] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[3] Rose、M.およびK. McCloghrie、「簡潔なMIB定義」、STD 16、RFC 1212、1991年3月。
[4] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[4] ローズ、M.、「SNMPと共に使用するためのトラップを定義するための条約」、RFC 1215、1991年3月。
[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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M.およびS. Waldbusser、「管理情報バージョン2（SMIV2）の構造（SMIV2）」、STD 58、RFC 2578、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M.およびS. WaldBusser、STD 58、RFC 2579、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.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M.およびS.WaldBusser、STD 58、RFC 2580、1999年4月。
[8] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[8] ケース、J.、Fedor、M.、Schoffstall、M.およびJ.Davin、「シンプルネットワーク管理プロトコル」、STD 15、RFC 1157、1990年5月。
[9] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[9] ケース、J.、McCloghrie、K.、Rose、M.およびS. Waldbusser、「コミュニティベースSNMPv2の紹介」、1906年1月、RFC 1901。
[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.、Rose、M.およびS. Waldbusser、「Simple Network Management Protocol（SNMPv2）のバージョン2のトランスポートマッピング（SNMPv2）」、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.、Harrington D.、Presuhn R.およびB.Wijnen、1999年4月、RFC 2572、RFC 2572、RFC 2572。
[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] Blumenthal、U.およびB.Wijnen、「Simple Network Management Protocol（SNMPv3）のバージョン3（SNMPv3）のユーザーベースのセキュリティモデル（USM））、RFC 2574、1999年4月。
[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.、Rose、M.およびS. WaldBusser、「Simple Network Management Protocol（SNMPv2）のバージョン2のプロトコル操作（SNMPv2）」、1996年1月。
[14] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.
[14] Levi、D.、Meyer、P.およびB.Stewart、「SNMPv3アプリケーション」、RFC 2573、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、「Simple Network Management Protocol（SNMP）」、RFC 2575、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.、Mundy、R.、D.およびB.Stewart、「インターネット標準ネットワーク管理フレームワークのバージョン3の紹介」、RFC 2570、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.、Rose、M.およびS. WaldBusser、「Simple Network Management Protocol（SNMPv2）のバージョン2の管理情報ベース（SNMPv2）」、1996年1月、RFC 1907。
[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] 情報処理システム - Open Systems Interconnection - 抽象構文表記法の仕様（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、「SMIV2を使用したInterfaces Group MIB」、RFC 2233、1997年11月。
[20] Case, J., "FDDI Management Information Base", RFC 1285, January 1992.
[20] ケース、J.、「FDDI管理情報ベース」、RFC 1285、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、「アプリケーション用システムレベル管理対象オブジェクトの定義」、RFC 2287、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」、RFC 2564、1999年5月。
[23] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[23] Reynolds、J.およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、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.、Rose、M.およびS. WaldBusser、「インターネット標準ネットワーク管理フレームワークのバージョン1とバージョン2の間の共存」、RFC 1908、1908年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. Levi、 "V2TOV1：Bympv2へのSNMPv2へのMapping SNMPv1へのマッピングSNMPv1"、RFC 2089、1997年1月。
[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.、Carpenter、G.、Curran、K.、Sehgal、A.およびG. Waters、「Simple Network Management Protocol：Distributed Protocol Interface、Version 2.0」、RFC 1592、1994年3月。
[27] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[27] Bradner、S.、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
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は、あるいはその他の権利の使用に関連している可能性がある、またはその他の権利の有効性または範囲に関する役割を果たしていません。利用可能です。それは、そのような権利を特定するために努力をしたことを表していません。標準トラックおよび標準関連のマニュアルにおける権利に関するIETFの手順に関する情報は、BCP-11にあります。公開可能な権利の特許請求の課題および利用可能なライセンスの保証、またはこの仕様書の実装者またはユーザによるそのような独自の権利を使用するための一般的なライセンスまたは許可を得るための試みの結果を得ることができる。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エグゼクティブディレクターに情報を取り扱ってください。
A. Changes relative to RFC 2257
A. RFC 2257に対する変更
Changes on the wire:
ワイヤの変更：
- The agentx-Notify-PDU and agentx-Close-PDU now generate an agentx-Response-PDU.
- AgentX-Notify-PDUとAgentX-Close-PDUは、AgentX-Response-PDUを生成します。
- The res.error field may contain three new error codes: parseFailed(266), requestDenied(267), and processingError(268).
- Res.Errorフィールドには、parsefailed（266）、要求された（267）、およびProcessERROR（268）の3つの新しいエラーコードを含めることができます。
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）のテキストを4.2節、「適用性」に変更して、行の作成の2つの懸念を区切り、カウントされたカウンタをカウントします。
- The use of the r.range_subid field is more clearly defined in section 6.2.3, "The agentx-Register-PDU".
- r.range_subidフィールドの使用は、6.2.3項「AgentX-Register-PDU」では明確に定義されています。
- Default priority (127) for registration added to the description of r.priority in section 6.2.3, "The agentx-Register-PDU".
- 登録のデフォルト優先順位（127）r.Priorityの説明に追加されました.6.2.3項「AgentX-Register-PDU」の登録。
- 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.
- h.typeの「AgentX PDUヘッダー」の説明6.1の「管理処理」PDUと「SNMP要求処理」PDUの違いを示しました。この区別は、res.sysptimeおよびres.Errorフィールドに対する手順の要素に使用されます。
- Rewrote portions of text in section 6.2.3, "The agentx-Register-PDU" to be more explicit about the following points:
- 次の点について、「AgentX-Register-PDU」の項でテキストの部分を書き直してください。
- 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.Regionのプレフィックスとは無関係に、r.range_subidの説明を改善しました。 - 登録メカニズムの使用方法の説明と例の改善。 - r.upper_boundの説明を追加しました。 - r.R.R.REGIONをR.R.REGIESに変更しました（テキストは、「領域」、「範囲」、および「OIDの範囲」、「範囲」と「範囲」という点が緩和されています。r.sureeは単純なサブツリーよりもそれ以上のものを表すことはできません。r.range_subidとr.upper_boundと組み合わせて、それは「地域」、すなわちサブツリー共和国を表すことができます）
- Modified the text in section 6.2.4, "The agentx-Unregister-PDU" to include a description of u.range_subid and u.upper_bound
- u.range_subidとu.upper_boundの説明を含むように、6.2.4項「agentx-unregister-pdu」のテキストを修正しました。
- Added use of the `requestDenied' error code in section 7.1.4, "Processing the agentx-Register-PDU".
- 7.1.4項「agentx-register-pduの処理」の「要求された」エラーコードの使用を追加しました。
- 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 'と` ProcesserRor'の使い方、およびコンテキストの処理方法を説明しました。
- 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:
- 手順セクションの他の管理処理要素から共通の処理テキストを削除し、セクション7.1「AgentX管理メッセージの処理」への参照を追加しました。影響を受けるセクションは次のとおりです。
- 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「AgentX-IndexAllocate-PDUの処理」 - 7.1.3「agentX-indexDeallocate-PDUの処理」 - 7.1.4「AgentX-Register-PDUの処理」 - 7.1.5の処理AgentXの処理-unregister-PDU " - 7.1.6「AgentX-AddAgentCAPS-PDUの処理」 - 7.1.7、「AgentX-RemoveAgentCAPS-PDUの処理」 - 7.1.8「AgentX-Close-PDUの処理」 - 7.1。10、「AgentX-Notify-PDUの処理」 - 7.1.11、「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.
- セクション7.1.1「AgentX-Open-PDUの処理」で、新しいエラーコードを含め、表示されているコンテキストへの参照を排除するためのテキストを書き直しました。
- Modified the text in Section 7.1.10, "Processing the agentx-Notify-PDU" to state that context checking is performed.
- 7.1.10項「agentx-notify-pduの処理」でテキストを修正して、コンテキストチェックが実行されていることを示します。
- Substantially modified the text in section 7.1.4.1, "Handling Duplicate and Overlapping Subtrees".
- セクション7.1.4.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.
- 7.1.5項「AgentX-Unregister-PDUの処理」で、これらのフィールドが対応するAgentX-Register-PDUに適用可能な場合は、u.range_subidおよびu.upper_boundでの一致を必要とします。
- 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範囲」という用語のすべての使用を削除しました。このテキストは、地域またはサブツリーを直接参照しており、7.2.1項「agentX PDUのディスパッチ」で、規則（1）「レジストリの称賛」に依存しています。
- 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.
- サブエージェントによって登録されているタイムアウト値が実用的でない場合、マスターエージェントが実装固有のデフォルトタイムアウト値を使用できることを明確にして、Master Agentが実装固有のデフォルトのタイムアウト値を使用できることを明確にしていることを明確にします。
- 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への応答の処理の処理」のテキストに例を追加しました。このセクションから「Contains」の定義を削除しました。
- 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.
- 7.2.5.5項「agentX-commitset-pdusへの応答の処理」のステップ（1）のテキストは、最初のエラー応答の後にAgentX-COMMITSET-PDUへの追加の応答を無視するようにマスターエージェントのディレクティブを排除します。
- 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への応答の処理」で、「AgentX-UndoSet-PDUへの応答の処理」、AgentXの電子メールリストで受信されたフィードバックごとにコミット/元に戻す要素をクリーンアップします。
- Modified the text in section 8.1.2, "Operation" to explicitly prohibit interleaved sends, and, added a caution about exchanging AgentX messages via TCP.
- インターリーブ送信を明示的に禁止するために、セクション8.1.2「操作」のテキストを修正し、TCPを介してAgentXメッセージの交換に関する注意を追加しました。
- 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-allocate-pduのOIDがオブジェクトタイプで、インスタンスサブ識別子を含まないことをより明確にするためのテキストを修正しました。
- Replaced the term "subagent" with the term "session" in many places throughout the text.
- テキスト全体の多くの場所で「SubAgent」という用語を「セッション」という用語に置き換えました。
- 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-TestSet-PDU、AgentX-COMMITSET-PDU、およびAgentX-UndoSet-PDUのマスターエージェント処理を基準にして、AgentX-UndoSet-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.
- 適切な場合には、「パケット」（およびその他）の代わりに「トランザクション」という用語を使用するためのテキストを修正しました。これにより、トランザクション全体を特定のパケットまたはPDUの特定のシーケンスと区別できます。
- 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.
- BCP 14のキーワードを基準にして、セクション1、序文にテキストを追加しました。
- Modified text to section 9, Security Considerations, to include use of BCP 14 key words.
- BCP 14キーワードの使用を含むように、セクション9、セキュリティ上の考慮事項へのテキストを修正しました。
- Modified text to section 9, Security Considerations, to include IPSEC as a suggested Transport Layer Security.
- 推奨トランスポート層のセキュリティとしてIPsecを含むように、セクション9、セキュリティ上の考慮事項へのテキストを修正しました。
Full Copyright Statement
完全著作権宣言
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット社会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書と翻訳はコピーされている可能性があり、他の文書にはコピーされ、その実装を説明するか、またはその実装を説明するか、またはその実装を支援することができます。上記の著作権通知とこの段落がそのようなすべてのコピーや派生的な作品に含まれているとしました。ただし、この文書自体は、インターネット規格を開発するために必要な場合を除き、インターネット社会や他のインターネット組織への参照を削除するなど、著作権社会やその他のインターネット組織への参照を除去することはできません。インターネット標準プロセスに従う必要があるか、それを英語以外の言語に翻訳する必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた権限は永続的であり、インターネット社会やその後継者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本明細書に含まれる情報は、「現状」ベースで提供されており、インターネット社会とインターネットエンジニアリングのタスクフォースは、本明細書の情報の使用が含まれないことを含むが、これに限定されない、またはこれに限定されないすべての保証を損なう。特定の目的のための商品性または適合性の権利または黙示的な保証を侵害する。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。