RFC1448 日本語訳
1448 Protocol Operations for version 2 of the Simple NetworkManagement Protocol (SNMPv2). J. Case, K. McCloghrie, M. Rose, S.Waldbusser. April 1993. (Format: TXT=74224 bytes) (Obsoleted by RFC1905) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Case
Request for Comments: 1448 SNMP Research, Inc.
K. McCloghrie
Hughes LAN Systems
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
Carnegie Mellon University
April 1993
コメントを求めるワーキンググループJ.ケース要求をネットワークでつないでください: 1448台のSNMP研究Inc.K.McCloghrieヒューズLANシステムM.がドーヴァービーチコンサルティングInc.S.Waldbusserカーネギーメロン大学1993年4月に上昇しました。
Protocol Operations
for version 2 of the
Simple Network Management Protocol (SNMPv2)
Simple Network Managementプロトコルのバージョン2のためのプロトコルOperations(SNMPv2)
Status of this Memo
このMemoの状態
This RFC specifes an IAB standards track protocol for the
Internet community, and requests discussion and suggestions
for improvements. Please refer to the current edition of the
"IAB Official Protocol Standards" for the standardization
state and status of this protocol. Distribution of this memo
is unlimited.
改良のためのIAB規格道がインターネットコミュニティのために議定書の中で述べるこのRFC specifes、要求議論、および提案。 このプロトコルの標準化状態と状態の「IABの公式のプロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1 Introduction .......................................... 2
1.1 A Note on Terminology ............................... 2
2 Overview .............................................. 3
2.1 Roles of Protocol Entities .......................... 3
2.2 Management Information .............................. 3
2.3 Access to Management Information .................... 4
2.4 Retransmission of Requests .......................... 4
2.5 Message Sizes ....................................... 5
2.6 Transport Mappings .................................. 6
3 Definitions ........................................... 7
4 Protocol Specification ................................ 12
4.1 Common Constructs ................................... 12
4.2 PDU Processing ...................................... 12
4.2.1 The GetRequest-PDU ................................ 13
4.2.2 The GetNextRequest-PDU ............................ 15
4.2.2.1 Example of Table Traversal ...................... 16
4.2.3 The GetBulkRequest-PDU ............................ 18
4.2.3.1 Another Example of Table Traversal .............. 21
4.2.4 The Response-PDU .................................. 22
4.2.5 The SetRequest-PDU ................................ 23
4.2.6 The SNMPv2-Trap-PDU ............................... 26
4.2.7 The InformRequest-PDU ............................. 27
1つの序論… 2 1.1 用語に関する注… 2 2概要… 3 プロトコル実体の2.1の役割… 3 2.2 管理情報… 3 2.3 情報に管理にアクセスしてください… 4 2.4 要求のRetransmission… 4 2.5 メッセージサイズ… 5 2.6 マッピングを輸送してください… 6 3の定義… 7 4は仕様を議定書の中で述べます… 12 4.1 一般的な構造物… 12 4.2 PDU処理… 12 4.2 .1 GetRequest-PDU… 13 4.2 .2 GetNextRequest-PDU… 15 4.2 .2 テーブル縦断に関する.1の例… 16 4.2 .3 GetBulkRequest-PDU… 18 4.2 .3 .1 テーブル縦断に関する別の例… 21 4.2 .4 応答-PDU… 22 4.2 .5 SetRequest-PDU… 23 4.2 .6 SNMPv2はPDUを捕らえます… 26 4.2 .7 InformRequest-PDU… 27
Case, McCloghrie, Rose & Waldbusser [Page i]
ケース、McCloghrie、ローズ、およびWaldbusser[ページi]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
5 Acknowledgements ...................................... 29
6 References ............................................ 33
7 Security Considerations ............................... 35
8 Authors' Addresses .................................... 35
5つの承認… 29 6つの参照箇所… 33 7 セキュリティ問題… 35 8人の作者のアドレス… 35
Case, McCloghrie, Rose & Waldbusser [Page 1]
ケース、McCloghrie、ローズ、およびWaldbusser[1ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
1. Introduction
1. 序論
A network management system contains: several (potentially
many) nodes, each with a processing entity, termed an agent,
which has access to management instrumentation; at least one
management station; and, a management protocol, used to convey
management information between the agents and management
stations. Operations of the protocol are carried out under an
administrative framework which defines both authentication and
authorization policies.
ネットワーク管理システムは以下を含んでいます。 数個の(潜在的に多く)のノード(処理実体があるそれぞれ)がエージェントを呼びました。(そのエージェントは、管理計装に近づく手段を持っています)。 少なくとも1つの管理局。 そして、エージェントと管理局の間に経営情報を伝えるのに使用されて、管理は議定書を作ります。 プロトコルの操作が認証と承認方針の両方を定義する管理フレームワークの下で行われます。
Network management stations execute management applications
which monitor and control network elements. Network elements
are devices such as hosts, routers, terminal servers, etc.,
which are monitored and controlled through access to their
management information.
ネットワークマネージメントステーションはネットワーク要素をモニターして、制御する管理アプリケーションを作成します。 ネットワーク要素はホスト、ルータ、それらの経営情報へのアクセスでモニターされて、制御されるターミナルサーバなどのデバイスです。
Management information is viewed as a collection of managed
objects, residing in a virtual information store, termed the
Management Information Base (MIB). Collections of related
objects are defined in MIB modules. These modules are written
using a subset of OSI's Abstract Syntax Notation One (ASN.1)
[1], termed the Structure of Management Information (SMI) [2].
仮想情報店に住んでいて、管理オブジェクトの収集がInformation基地(MIB)とManagementを呼んだので、経営情報は見られます。 関連するオブジェクトの収集はMIBモジュールで定義されます。 Management情報(SMI)[2]のStructureは、これらのモジュールがOSIの抽象的なSyntax Notation One(ASN.1)[1]の部分集合を使用することで書かれていると呼びました。
The management protocol, version 2 of the Simple Network
Management Protocol, provides for the exchange of messages
which convey management information between the agents and the
management stations. The form of these messages is a message
"wrapper" which encapsulates a Protocol Data Unit (PDU). The
form and meaning of the "wrapper" is determined by an
administrative framework which defines both authentication and
authorization policies.
管理プロトコル(Simple Network Managementプロトコルのバージョン2)はエージェントと管理局の間に経営情報を伝えるメッセージの交換に備えます。 これらのメッセージのフォームはプロトコルData Unit(PDU)をカプセル化する「ラッパー」というメッセージです。 「ラッパー」のフォームと意味は認証と承認方針の両方を定義する管理フレームワークで決定します。
It is the purpose of this document, Protocol Operations for
SNMPv2, to define the operations of the protocol with respect
to the sending and receiving of the PDUs.
それは、PDUsの送受信に関してプロトコルの操作を定義するためにはこのドキュメント、SNMPv2のためのプロトコルOperationsの目的です。
1.1. A Note on Terminology
1.1. 用語に関する注
For the purpose of exposition, the original Internet-standard
Network Management Framework, as described in RFCs 1155, 1157,
and 1212, is termed the SNMP version 1 framework (SNMPv1).
The current framework is termed the SNMP version 2 framework
(SNMPv2).
博覧会の目的のために、RFCs1155、1157年、および1212年に説明されるオリジナルのインターネット標準Network Management FrameworkはSNMPバージョン1フレームワーク(SNMPv1)と呼ばれます。 現在のフレームワークはSNMPバージョン2フレームワーク(SNMPv2)と呼ばれます。
Case, McCloghrie, Rose & Waldbusser [Page 2]
ケース、McCloghrie、ローズ、およびWaldbusser[2ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
2. Overview
2. 概要
2.1. Roles of Protocol Entities
2.1. プロトコル実体の役割
A SNMPv2 entity may operate in a manager role or an agent
role.
SNMPv2実体はマネージャの役割かエージェントの役割で作動するかもしれません。
A SNMPv2 entity acts in an agent role when it performs SNMPv2
management operations in response to received SNMPv2 protocol
messages (other than an inform notification) or when it sends
trap notifications.
受信されたSNMPv2プロトコルメッセージに対応してSNMPv2管理操作を実行するとき、SNMPv2実体がエージェントの役割で行動する、(案内、通知)、または、それはいつ罠通知を送るか。
A SNMPv2 entity acts in a manager role when it initiates
SNMPv2 management operations by the generation of SNMPv2
protocol messages or when it performs SNMPv2 management
operations in response to received trap or inform
notifications.
SNMPv2プロトコルメッセージの世代によるSNMPv2管理操作を開始するとき、SNMPv2実体がマネージャの役割で行動するか、または働くとき、受け取られていることに対応したSNMPv2管理操作は、捕らえるか、通知を知らせます。
A SNMPv2 entity may support either or both roles, as dictated
by its implementation and configuration. Further, a SNMPv2
entity can also act in the role of a proxy agent, in which it
appears to be acting in an agent role, but satisfies
management requests by acting in a manager role with a remote
entity. The use of proxy agents and the transparency
principle that defines their behavior is described in [3].
SNMPv2実体はその実装と構成によって書き取られるようにどちらかか役割の両方をサポートするかもしれません。 また、さらに、SNMPv2実体はプロキシエージェントの役割で行動できます。(そこでは、それは、エージェントの役割で行動しているように見えますが、リモート実体でマネージャの役割で行動することによって、管理要求を満たします)。 プロキシエージェントと透明原則の彼らの振舞いを定義する使用は[3]で説明されます。
2.2. Management Information
2.2. 経営情報
The term, variable, refers to an instance of a non-aggregate
object type defined according to the conventions set forth in
the SMI [2] or the textual conventions based on the SMI [4].
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.
可変である用語はSMI[2]に詳しく説明されたコンベンションかSMI[4]に基づく原文のコンベンションに従って定義された非集団オブジェクトタイプのインスタンスについて言及します。 通常、用語(変項束縛)は可変価値とその関連価値の名前の組み合わせについて言及します。 しかしながら、ある種類の例外的な状態が検索要求の処理の間、現れると、変項束縛はその例外の名前としるしを対にするでしょう。
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
インスタンスを特定するOBJECT IDENTIFIER断片と共に変数の名前は対応するオブジェクト・タイプのOBJECT IDENTIFIERの連結であるOBJECT IDENTIFIERです。 対応するオブジェクト・タイプのOBJECT IDENTIFIERはOBJECT IDENTIFIERと呼ばれます。
Case, McCloghrie, Rose & Waldbusser [Page 3]
ケース、McCloghrie、ローズ、およびWaldbusser[3ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
prefix of the variable.
変数の接頭語。
2.3. Access to Management Information
2.3. 経営情報へのアクセス
Three types of access to management information are provided
by the protocol. One type is a request-response interaction,
in which a SNMPv2 entity, acting in a manager role, sends a
request to a SNMPv2 entity, acting in an agent role, and the
latter SNMPv2 entity then responds to the request. This type
is used to retrieve or modify management information
associated with the managed device.
プロトコルは経営情報へのアクセスの3つのタイプを提供します。 エージェントの役割で行動して、1つのタイプが要求応答相互作用です、そして、次に、後者のSNMPv2実体は要求に応じます。(マネージャの役割で行動して、SNMPv2実体はそれでSNMPv2実体に要求を送ります)。 このタイプは、管理されたデバイスに関連している経営情報を検索するか、または変更するのに使用されます。
A second type is also a request-response interaction, in which
a SNMPv2 entity, acting in a manager role, sends a request to
a SNMPv2 entity, also acting in a manager role, and the latter
SNMPv2 entity then responds to the request. This type is used
to notify a SNMPv2 entity, acting in a manager role, of
management information associated with another SNMPv2 entity,
also acting in a manager role.
また、2番目のタイプは要求応答相互作用です、そして、次に、後者のSNMPv2実体は要求に応じます。(SNMPv2実体(マネージャの役割における芝居)はそれでSNMPv2実体、マネージャの役割における芝居にも要求を送ります)。 このタイプはSNMPv2実体に通知するのに使用されます、別のSNMPv2実体に関連している経営情報のマネージャの役割で行動して、また、マネージャの役割で行動して。
The third type of access is an unconfirmed interaction, in
which a SNMPv2 entity, acting in an agent role, sends a
unsolicited message, termed a trap, to a SNMPv2 entity, acting
in a manager role, and no response is returned. This type is
used to notify a SNMPv2 entity, acting in a manager role, of
an exceptional situation, which has resulted in changes to
management information associated with the managed device.
3番目のタイプのアクセスは未確認の相互作用です、マネージャの役割における芝居、そして、応答を全く返しません。(そこでは、SNMPv2実体(エージェントの役割における芝居)は罠と呼ばれたお節介なメッセージをSNMPv2実体に送ります)。 このタイプはSNMPv2実体に通知するのに使用されます、管理されたデバイスに関連している経営情報への変化をもたらした例外的な状況のマネージャの役割で行動して。
2.4. Retransmission of Requests
2.4. 要求のRetransmission
For all types of request in this protocol, the receiver is
required under normal circumstances, to generate and transmit
a response to the originator of the request. Whether or not a
request should be retransmitted if no corresponding response
is received in an appropriate time interval, is at the
discretion of the application originating the request. This
will normally depend on the urgency of the request. However,
such an application needs to act responsibly in respect to the
frequency and duration of re-transmissions.
このプロトコルにおける、すべてのタイプの要求において、受信機は、要求の創始者への応答を生成して、通常の状況下で伝えなければなりません。 要求が対応する応答でないなら再送されるべきであるかどうかは、適切な時期間隔に受け取られて、要求を溯源するアプリケーションの裁量にはあります。 通常、これは要求の緊急によるでしょう。 しかしながら、そのようなアプリケーションは、再トランスミッションの頻度と持続時間に関して責任を持って行動する必要があります。
Case, McCloghrie, Rose & Waldbusser [Page 4]
ケース、McCloghrie、ローズ、およびWaldbusser[4ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
2.5. Message Sizes
2.5. メッセージサイズ
The maximum size of a SNMPv2 message is limited the minimum
of:
SNMPv2メッセージの最大サイズが限られている、以下の最小限
(1) the maximum message size which the destination SNMPv2
entity can accept; and,
(1) 目的地SNMPv2実体が受け入れることができる最大のメッセージサイズ。 そして
(2) the maximum message size which the source SNMPv2 entity
can generate.
(2) ソースSNMPv2実体が生成することができる最大のメッセージサイズ。
The former is indicated by partyMaxMessageSize[5] of the
destination party. The latter is imposed by implementation-
specific local constraints.
前者は目的地パーティーのpartyMaxMessageSize[5]によって示されます。 後者は実装の特定の地方の規制で課されます。
Each transport mapping for the SNMPv2 indicates the minimum
message size which a SNMPv2 implementation must be able to
produce or consume. Although implementations are encouraged
to support larger values whenever possible, a conformant
implementation must never generate messages larger than
allowed by the receiving SNMPv2 entity.
SNMPv2のためのそれぞれの輸送マッピングはSNMPv2実装が生産しなければならないか、または消費できなければならない最小のメッセージサイズを示します。 可能であるときはいつも、実装が、より大きい値をサポートするよう奨励されますが、conformant実装は受信SNMPv2実体によって許容されているより大きいメッセージを決して生成してはいけません。
One of the aims of the GetBulkRequest-PDU, specified in this
protocol, is to minimize the number of protocol exchanges
required to retrieve a large amount of management information.
As such, this PDU type allows a SNMPv2 entity acting in a
manager role to request that the response be as large as
possible given the constraints on message sizes. These
constraints include the limits on the size of messages which
the SNMPv2 entity acting in an agent role can generate, and
the SNMPv2 entity acting in a manager role can receive.
GetBulkRequest-PDUの目的のこのプロトコルで指定された1つは多量の経営情報を検索するのに必要であるプロトコル交換の数を最小にすることです。 そういうものとして、このPDUタイプはメッセージサイズにおける規制を考えて、応答ができるだけ大きいようマネージャの役割で行動するSNMPv2実体を要求させます。 これらの規制はエージェントの役割におけるSNMPv2実体芝居が生成することができるメッセージのサイズにおける限界を含んでいます、そして、マネージャの役割で行動するSNMPv2実体は受信されることができます。
However, it is possible that such maximum sized messages may
be larger than the Path MTU of the path across the network
traversed by the messages. In this situation, such messages
are subject to fragmentation. Fragmentation is generally
considered to be harmful [6], since among other problems, it
leads to a decrease in the reliability of the transfer of the
messages. Thus, a SNMPv2 entity which sends a
GetBulkRequest-PDU must take care to set its parameters
accordingly, so as to reduce the risk of fragmentation. In
particular, under conditions of network stress, only small
values should be used for max-repetitions.
しかしながら、メッセージによって横断されたネットワークの向こう側に、最大の大きさで分けられたメッセージが経路のPath MTUと同じくらい大きいのは、可能です。 この状況で、そのようなメッセージは断片化を受けることがあります。 一般に、断片化は有害な[6]であると考えられます、他の問題の中でメッセージの転送の信頼性の減少に通じるので。 したがって、GetBulkRequest-PDUを送るSNMPv2実体はそれに従って、パラメタを設定するために注意されなければなりません、断片化の危険を減少させるために。 ネットワーク圧力に関する条件のもとで、特に、小さい値だけが最大反復に使用されるべきです。
Case, McCloghrie, Rose & Waldbusser [Page 5]
ケース、McCloghrie、ローズ、およびWaldbusser[5ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
2.6. Transport Mappings
2.6. 輸送マッピング
It is important to note that the exchange of SNMPv2 messages
requires only an unreliable datagram service, with every
message being entirely and independently contained in a single
transport datagram. Specific transport mappings and encoding
rules are specified elsewhere [7]. However, the preferred
mapping is the use of the User Datagram Protocol [8].
SNMPv2メッセージの交換が頼り無いデータグラムサービスだけを必要とすることに注意するのは重要です、あらゆるメッセージが単一の輸送データグラムに完全に独自に含まれている状態で。 特定の輸送マッピングと符号化規則はほかの場所で指定されます。[7]。 しかしながら、都合のよいマッピングはユーザー・データグラム・プロトコル[8]の使用です。
Case, McCloghrie, Rose & Waldbusser [Page 6]
ケース、McCloghrie、ローズ、およびWaldbusser[6ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
3. Definitions
3. 定義
SNMPv2-PDU DEFINITIONS ::= BEGIN
SNMPv2-PDU定義:、:= 始まってください。
IMPORTS
ObjectName, ObjectSyntax, Integer32
FROM SNMPv2-SMI;
SNMPv2-SMIからObjectName、ObjectSyntax、Integer32をインポートします。
-- protocol data units
-- プロトコルデータ単位
PDUs ::=
CHOICE {
get-request
GetRequest-PDU,
PDUs:、:= CHOICE、要求を得ているGetRequest-PDU
get-next-request
GetNextRequest-PDU,
次の要求を得ているGetNextRequest-PDU
get-bulk-request
GetBulkRequest-PDU,
大量の要求を得ているGetBulkRequest-PDU
response
Response-PDU,
応答Response-PDU
set-request
SetRequest-PDU,
SetRequest-PDUをセット要求してください。
inform-request
InformRequest-PDU,
要求を知らせているInformRequest-PDU
snmpV2-trap
SNMPv2-Trap-PDU
}
snmpV2-罠SNMPv2罠PDU
Case, McCloghrie, Rose & Waldbusser [Page 7]
ケース、McCloghrie、ローズ、およびWaldbusser[7ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
-- PDUs
-- PDUs
GetRequest-PDU ::=
[0]
IMPLICIT PDU
GetRequest-PDU:、:= [0] 内在しているPDU
GetNextRequest-PDU ::=
[1]
IMPLICIT PDU
GetNextRequest-PDU:、:= [1] 内在しているPDU
Response-PDU ::=
[2]
IMPLICIT PDU
応答-PDU:、:= [2] 内在しているPDU
SetRequest-PDU ::=
[3]
IMPLICIT PDU
SetRequest-PDU:、:= [3] 内在しているPDU
-- [4] is obsolete
-- [4]は時代遅れです。
GetBulkRequest-PDU ::=
[5]
IMPLICIT BulkPDU
GetBulkRequest-PDU:、:= [5] 内在しているBulkPDU
InformRequest-PDU ::=
[6]
IMPLICIT PDU
InformRequest-PDU:、:= [6] 内在しているPDU
SNMPv2-Trap-PDU ::=
[7]
IMPLICIT PDU
SNMPv2はPDUを捕らえます:、:= [7] 内在しているPDU
Case, McCloghrie, Rose & Waldbusser [Page 8]
ケース、McCloghrie、ローズ、およびWaldbusser[8ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
max-bindings
INTEGER ::= 2147483647
最大結合INTEGER:、:= 2147483647
PDU ::=
SEQUENCE {
request-id
Integer32,
PDU:、:= SEQUENCE、要求イドInteger32
error-status -- sometimes ignored
INTEGER {
noError(0),
tooBig(1),
noSuchName(2), -- for proxy compatibility
badValue(3), -- for proxy compatibility
readOnly(4), -- for proxy compatibility
genErr(5),
noAccess(6),
wrongType(7),
wrongLength(8),
wrongEncoding(9),
wrongValue(10),
noCreation(11),
inconsistentValue(12),
resourceUnavailable(13),
commitFailed(14),
undoFailed(15),
authorizationError(16),
notWritable(17),
inconsistentName(18)
},
エラー状況--時々INTEGERを無視する、noError(0)、tooBig(1)、プロキシの互換性badValue(3)、プロキシの互換性readOnly(4)、プロキシの互換性genErr(5)、noAccess(6)、wrongType(7)、wrongLength(8)、wrongEncoding(9)、wrongValue(10)、noCreation(11)、inconsistentValue(12)、resourceUnavailable(13)、commitFailed(14)、undoFailed(15)、authorizationError(16)、notWritable(17)、inconsistentName(18)のためのnoSuchName(2)
error-index -- sometimes ignored
INTEGER (0..max-bindings),
誤りインデックス--時々無視されたINTEGER(0..max-結合)
variable-bindings -- values are sometimes ignored
VarBindList
}
変項束縛--値は時々無視されたVarBindListです。
Case, McCloghrie, Rose & Waldbusser [Page 9]
ケース、McCloghrie、ローズ、およびWaldbusser[9ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
BulkPDU ::= -- MUST be identical in
SEQUENCE { -- structure to PDU
request-id
Integer32,
BulkPDU:、:= -- SEQUENCEで同じでなければならない、--PDU要求イドInteger32への構造
non-repeaters
INTEGER (0..max-bindings),
非リピータINTEGER(0..max-結合)
max-repetitions
INTEGER (0..max-bindings),
最大反復INTEGER(0..max-結合)
variable-bindings -- values are ignored
VarBindList
}
変項束縛--値は無視されたVarBindListです。
Case, McCloghrie, Rose & Waldbusser [Page 10]
ケース、McCloghrie、ローズ、およびWaldbusser[10ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
-- variable binding
-- 変項束縛
VarBind ::=
SEQUENCE {
name
ObjectName,
VarBind:、:= SEQUENCE、ObjectNameを命名してください。
CHOICE {
value
ObjectSyntax,
CHOICE、ObjectSyntaxを評価してください。
unSpecified -- in retrieval requests
NULL,
unSpecifiedされました--検索では、NULLを要求します。
-- exceptions in responses
noSuchObject[0]
IMPLICIT NULL,
-- 応答noSuchObject[0] IMPLICIT NULLの例外
noSuchInstance[1]
IMPLICIT NULL,
noSuchInstance[1]の暗黙のヌル
endOfMibView[2]
IMPLICIT NULL
}
}
endOfMibView[2]の暗黙のヌル }
-- variable-binding list
-- 変項束縛リスト
VarBindList ::=
SEQUENCE (SIZE (0..max-bindings)) OF
VarBind
VarBindList:、:= VarBindの系列(サイズ(0..max-結合))
END
終わり
Case, McCloghrie, Rose & Waldbusser [Page 11]
ケース、McCloghrie、ローズ、およびWaldbusser[11ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
4. Protocol Specification
4. プロトコル仕様
4.1. Common Constructs
4.1. 一般的な構造物
The value of the request-id field in a Response-PDU takes the
value of the request-id field in the request PDU to which it
is a response. By use of the request-id value, a SNMPv2
application can distinguish the (potentially multiple)
outstanding requests, and thereby correlate incoming responses
with outstanding requests. In cases where an unreliable
datagram service is used, the request-id also provides a
simple means of identifying messages duplicated by the
network. Use of the same request-id on a retransmission of a
request allows the response to either the original
transmission or the retransmission to satisfy the request.
However, in order to calculate the round trip time for
transmission and processing of a request-response transaction,
the SNMPv2 application needs to use a different request-id
value on a retransmitted request. The latter strategy is
recommended for use in the majority of situations.
Response-PDUの要求イド分野の値はそれが応答である要求PDUにおける、要求イド分野の値を取ります。 要求イド価値の使用で、SNMPv2アプリケーションは、(潜在的に複数)の傑出している要求を区別して、その結果、傑出している要求で入って来る応答を関連させることができます。 また、頼り無いデータグラムサービスが使用されている場合では、要求イドはネットワークによってコピーされたメッセージを特定する簡潔な方法を提供します。 要求の「再-トランスミッション」における同じ要求イドの使用で、オリジナルのトランスミッションか「再-トランスミッション」のどちらかへの応答は要望に応じることができます。 しかしながら、要求応答取引のトランスミッションと処理のための周遊旅行時間について計算するために、SNMPv2アプリケーションは、再送された要求の異なった要求イド値を使用する必要があります。 後者の戦略は状況の大部分における使用のために推薦されます。
A non-zero value of the error-status field in a Response-PDU
is used to indicate that an exception occurred to prevent the
processing of the request. In these cases, a non-zero value
of the Response-PDU's error-index field provides additional
information by identifying which variable binding in the list
caused the exception. A variable binding is identified by its
index value. The first variable binding in a variable-binding
list is index one, the second is index two, etc.
Response-PDUのエラー状況分野の非ゼロ値は、例外が要求の処理を防ぐために起こったのを示すのに使用されます。 これらの場合では、リストにおけるどの変項束縛が例外を引き起こしたかを特定することによって、Response-PDUの誤りインデックス部の非ゼロ値は追加情報を提供します。 変項束縛はインデックス値によって特定されます。 変項束縛リストにおける最初の変項束縛がインデックス1である、2番目はインデックスtwoですなど。
SNMPv2 limits OBJECT IDENTIFIER values to a maximum of 128
sub-identifiers, where each sub-identifier has a maximum value
of 2**32-1.
SNMPv2はOBJECT IDENTIFIER値を最大128のサブ識別子に制限します。そこでは、それぞれのサブ識別子が2**32-1の最大値を持っています。
4.2. PDU Processing
4.2. PDU処理
It is mandatory that all SNMPv2 entities acting in an agent
role be able to generate the following PDU types: Response-PDU
and SNMPv2-Trap-PDU; further, all such implementations must be
able to receive the following PDU types: GetRequest-PDU,
GetNextRequest-PDU, GetBulkRequest-PDU, and SetRequest-PDU.
エージェントの役割で行動するすべてのSNMPv2実体が以下のPDUタイプを発生させることができるのは、義務的です: 応答-PDUとSNMPv2罠PDU。 さらに、そのようなすべての実現が以下のPDUタイプを受けることができなければなりません: GetRequest-PDU、GetNextRequest-PDU、GetBulkRequest-PDU、およびSetRequest-PDU。
Case, McCloghrie, Rose & Waldbusser [Page 12]
ケース、McCloghrie、ローズ、およびWaldbusser[12ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
It is mandatory that all SNMPv2 entities acting in a manager
role be able to generate the following PDU types: GetRequest-
PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU,
InformRequest-PDU, and Response-PDU; further, all such
implementations must be able to receive the following PDU
types: Response-PDU, SNMPv2-Trap-PDU, InformRequest-PDU;
マネージャの役割で行動するすべてのSNMPv2実体が以下のPDUタイプを発生させることができるのは、義務的です: GetRequest- PDU、GetNextRequest-PDU、GetBulkRequest-PDU、SetRequest-PDU、InformRequest-PDU、および応答-PDU。 さらに、そのようなすべての実現が以下のPDUタイプを受けることができなければなりません: 応答-PDU、SNMPv2罠PDU、InformRequest-PDU。
In the elements of procedure below, any field of a PDU which
is not referenced by the relevant procedure is ignored by the
receiving SNMPv2 entity. However, all components of a PDU,
including those whose values are ignored by the receiving
SNMPv2 entity, must have valid ASN.1 syntax and encoding. For
example, some PDUs (e.g., the GetRequest-PDU) are concerned
only with the name of a variable and not its value. In this
case, the value portion of the variable binding is ignored by
the receiving SNMPv2 entity. The unSpecified value is defined
for use as the value portion of such bindings.
以下の手順の要素では、関連手順で参照をつけられないPDUのどんな分野も受信SNMPv2実体によって無視されます。 しかしながら、値が受信SNMPv2実体によって無視されるものを含むPDUのすべての部品には、有効なASN.1構文とコード化がなければなりません。 例えば、いくつかのPDUs(例えば、GetRequest-PDU)が値ではなく、変数の名前だけに関係があります。 この場合、変項束縛の値の部分は受信SNMPv2実体によって無視されます。 unSpecified値は使用のためにそのような結合の値の部分と定義されます。
For all generated PDUs, the message "wrapper" to encapsulate
the PDU is generated and transmitted as specified in [3]. The
size of a message is limited only by constraints on the
maximum message size, either a local limitation or the limit
associated with the message's destination party, i.e., it is
not limited by the number of variable bindings.
すべての発生しているPDUsに関しては、PDUを要約する「包装紙」というメッセージは、[3]で指定されるように発生して、送られます。 メッセージのサイズは最大のメッセージサイズ(メッセージの目的地パーティーに関連している地方の制限か限界のどちらか)で単に規制で制限されます、すなわち、それは変項束縛の数によって制限されません。
On receiving a management communication, the procedures
defined in Section 3.2 of [3] are followed. If these
procedures indicate that the PDU contained within the message
"wrapper" is to be processed, then the SNMPv2 context
associated with the PDU defines the object resources which are
visible to the operation.
マネジメント・コミュニケーションを受け取ると、[3]のセクション3.2で定義された手順は従われています。 これらの手順が、「包装紙」というメッセージの中に含まれたPDUが処理されることになっているのを示すなら、PDUに関連しているSNMPv2文脈は操作に目に見える物のリソースを定義します。
4.2.1. The GetRequest-PDU
4.2.1. GetRequest-PDU
A GetRequest-PDU is generated and transmitted at the request
of a SNMPv2 application.
GetRequest-PDUはSNMPv2アプリケーションの依頼で発生して、伝えられます。
Upon receipt of a GetRequest-PDU, the receiving SNMPv2 entity
processes each variable binding in the variable-binding list
to produce a Response-PDU. All fields of the Response-PDU
have the same values as the corresponding fields of the
received request except as indicated below. Each variable
binding is processed as follows:
GetRequest-PDUを受け取り次第、受信SNMPv2実体は、Response-PDUを生産するために変項束縛リストにおける各変項束縛を処理します。 Response-PDUのすべての分野には、以下で示されるのを除いた受信された要求の対応する分野と同じ値があります。 各変項束縛は以下の通り処理されます:
Case, McCloghrie, Rose & Waldbusser [Page 13]
ケース、McCloghrie、ローズ、およびWaldbusser[13ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
(1) If the variable binding's name does not have an OBJECT
IDENTIFIER prefix which exactly matches the OBJECT
IDENTIFIER prefix of any variable accessible by this
request, then its value field is set to `noSuchObject'.
(1) 変項束縛の名前にまさにこの要求でアクセスしやすいどんな変数のOBJECT IDENTIFIER接頭語にも合っているOBJECT IDENTIFIER接頭語がないなら、値の分野は'noSuchObject'に設定されます。
(2) Otherwise, if the variable binding's name does not
exactly match the name of a variable accessible by this
request, then its value field is set to `noSuchInstance'.
(2) さもなければ、変項束縛の名前がまさにこの要求でアクセスしやすい変数の名前に合っていないなら、値の分野は'noSuchInstance'に設定されます。
(3) Otherwise, the variable binding's value field is set to
the value of the named variable.
(3) さもなければ、変項束縛の値の分野は名前付き変数の値に設定されます。
If the processing of any variable binding fails for a reason
other than listed above, then the Response-PDU is re-formatted
with the same values in its request-id and variable-bindings
fields as the received GetRequest-PDU, with the value of its
error-status field set to `genErr', and the value of its
error-index field is set to the index of the failed variable
binding.
どんな変項束縛の処理も上に記載されているのを除いた理由で失敗するなら、Response-PDUは容認されたGetRequest-PDUとしてその要求イドと変項束縛分野で同じ値で再フォーマットされます、'genErr'に設定されたエラー状況分野の値で、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
Otherwise, the value of the Response-PDU's error-status field
is set to `noError', and the value of its error-index field is
zero.
さもなければ、Response-PDUのエラー状況分野の値は'noError'に設定されます、そして、誤りインデックス部の値はゼロです。
The generated Response-PDU is then encapsulated into a
message. If the size of the resultant message is less than or
equal to both a local constraint and the maximum message size
of the request's source party, it is transmitted to the
originator of the GetRequest-PDU.
そして、発生しているResponse-PDUはメッセージに要約されます。 結果のメッセージのサイズがともにa地方の、より規制と要求のソースパーティーの最大のメッセージサイズであるなら、それはGetRequest-PDUの創始者に伝えられます。
Otherwise, an alternate Response-PDU is generated. This
alternate Response-PDU is formatted with the same value in its
request-id field as the received GetRequest-PDU, with the
value of its error-status field set to `tooBig', the value of
its error-index field set to zero, and an empty variable-
bindings field. This alternate Response-PDU is then
encapsulated into a message. If the size of the resultant
message is less than or equal to both a local constraint and
the maximum message size of the request's source party, it is
transmitted to the originator of the GetRequest-PDU.
Otherwise, the resultant message is discarded.
さもなければ、交互のResponse-PDUは発生します。 この交互のResponse-PDUは容認されたGetRequest-PDUとして要求イド分野で同じ値でフォーマットされます、'tooBig'に設定されたエラー状況分野の値、ゼロに設定された誤りインデックス部の値、および人影のない可変結合分野で。 そして、この交互のResponse-PDUはメッセージに要約されます。 結果のメッセージのサイズがともにa地方の、より規制と要求のソースパーティーの最大のメッセージサイズであるなら、それはGetRequest-PDUの創始者に伝えられます。 さもなければ、結果のメッセージは捨てられます。
Case, McCloghrie, Rose & Waldbusser [Page 14]
ケース、McCloghrie、ローズ、およびWaldbusser[14ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
4.2.2. The GetNextRequest-PDU
4.2.2. GetNextRequest-PDU
A GetNextRequest-PDU is generated and transmitted at the
request of a SNMPv2 application.
GetNextRequest-PDUはSNMPv2アプリケーションの依頼で発生して、伝えられます。
Upon receipt of a GetNextRequest-PDU, the receiving SNMPv2
entity processes each variable binding in the variable-binding
list to produce a Response-PDU. All fields of the Response-
PDU have the same values as the corresponding fields of the
received request except as indicated below. Each variable
binding is processed as follows:
GetNextRequest-PDUを受け取り次第、受信SNMPv2実体は、Response-PDUを生産するために変項束縛リストにおける各変項束縛を処理します。 Response- PDUのすべての分野には、以下で示されるのを除いた受信された要求の対応する分野と同じ値があります。 各変項束縛は以下の通り処理されます:
(1) The variable is located which is in the lexicographically
ordered list of the names of all variables which are
accessible by this request and whose name is the first
lexicographic successor of the variable binding's name in
the incoming GetNextRequest-PDU. The corresponding
variable binding's name and value fields in the
Response-PDU are set to the name and value of the located
variable.
(1) すべてのこの要求でアクセスしやすい変数の名前の辞書編集の規則正しいリストにあって、名前が第1代入って来るGetNextRequest-PDUの変項束縛の名前の辞書編集の後継者である変数は、見つけられています。 Response-PDUの対応する変項束縛の名前と値の分野は見つけられた変数の名前と値に設定されます。
(2) If the requested variable binding's name does not
lexicographically precede the name of any variable
accessible by this request, i.e., there is no
lexicographic successor, then the corresponding variable
binding produced in the Response-PDU has its value field
set to 'endOfMibView', and its name field set to the
variable binding's name in the request.
(2) 要求された変項束縛の名前が辞書編集にこの要求でアクセスしやすいどんな変数の名前にも先行しないなら、すなわち、どんな辞書編集の後継者もいませんでした、そして、次に、Response-PDUで起こされた対応する変項束縛で'endOfMibView'に値の分野を設定します、そして、名前欄は要求における変項束縛の名前にセットしました。
If the processing of any variable binding fails for a reason
other than listed above, then the Response-PDU is re-formatted
with the same values in its request-id and variable-bindings
fields as the received GetNextRequest-PDU, with the value of
its error-status field set to `genErr', and the value of its
error-index field is set to the index of the failed variable
binding.
どんな変項束縛の処理も上に記載されているのを除いた理由で失敗するなら、Response-PDUは容認されたGetNextRequest-PDUとしてその要求イドと変項束縛分野で同じ値で再フォーマットされます、'genErr'に設定されたエラー状況分野の値で、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
Otherwise, the value of the Response-PDU's error-status field
is set to `noError', and the value of its error-index field is
zero.
さもなければ、Response-PDUのエラー状況分野の値は'noError'に設定されます、そして、誤りインデックス部の値はゼロです。
The generated Response-PDU is then encapsulated into a
message. If the size of the resultant message is less than or
equal to both a local constraint and the maximum message size
of the request's source party, it is transmitted to the
そして、発生しているResponse-PDUはメッセージに要約されます。 結果のメッセージのサイズがともにa地方の、より規制と要求のソースパーティーの最大のメッセージサイズであるなら、それに伝えられます。
Case, McCloghrie, Rose & Waldbusser [Page 15]
ケース、McCloghrie、ローズ、およびWaldbusser[15ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
originator of the GetNextRequest-PDU.
GetNextRequest-PDUの創始者。
Otherwise, an alternate Response-PDU is generated. This
alternate Response-PDU is formatted with the same values in
its request-id field as the received GetNextRequest-PDU, with
the value of its error-status field set to `tooBig', the value
of its error-index field set to zero, and an empty variable-
bindings field. This alternate Response-PDU is then
encapsulated into a message. If the size of the resultant
message is less than or equal to both a local constraint and
the maximum message size of the request's source party, it is
transmitted to the originator of the GetNextRequest-PDU.
Otherwise, the resultant message is discarded.
さもなければ、交互のResponse-PDUは発生します。 この交互のResponse-PDUは容認されたGetNextRequest-PDUとして要求イド分野で同じ値でフォーマットされます、'tooBig'に設定されたエラー状況分野の値、ゼロに設定された誤りインデックス部の値、および人影のない可変結合分野で。 そして、この交互のResponse-PDUはメッセージに要約されます。 結果のメッセージのサイズがともにa地方の、より規制と要求のソースパーティーの最大のメッセージサイズであるなら、それはGetNextRequest-PDUの創始者に伝えられます。 さもなければ、結果のメッセージは捨てられます。
4.2.2.1. Example of Table Traversal
4.2.2.1. テーブル縦断に関する例
An important use of the GetNextRequest-PDU is the traversal of
conceptual tables of information within a MIB. The semantics
of this type of request, together with the method of
identifying individual instances of objects in the MIB,
provides access to related objects in the MIB as if they
enjoyed a tabular organization.
GetNextRequest-PDUの重要な使用はMIBの中の情報の概念的なテーブルの縦断です。 まるで彼らが表組織を楽しむかのようにこのタイプの要求の意味論はMIBの物の個々の例を特定する方法と共にMIBの関連する物へのアクセスを提供します。
In the protocol exchange sketched below, a SNMPv2 application
retrieves the media-dependent physical address and the
address-mapping type for each entry in the IP net-to-media
Address Translation Table [9] of a particular network element.
It also retrieves the value of sysUpTime [9], at which the
mappings existed. Suppose that the agent's IP net-to-media
table has three entries:
以下にスケッチされたプロトコル交換では、SNMPv2アプリケーションは特定のネットワーク要素のネットからメディアへのIP Address Translation Table[9]の各エントリーのためのメディア依存する物理アドレスとアドレス・マッピングタイプを救済します。 また、それはsysUpTime[9]の値を検索します。(そこでは、マッピングが存在しました)。 IPネットからメディアへのエージェントのテーブルには3つのエントリーがあると仮定してください:
Interface-Number Network-Address Physical-Address Type
インタフェース番号ネットワーク・アドレス物理アドレスタイプ
1 10.0.0.51 00:00:10:01:23:45 static
1 9.2.3.4 00:00:10:54:32:10 dynamic
2 10.0.0.15 00:00:10:98:76:54 dynamic
1 10.0.0.51 00:、01:23:45、00:10:静的な1 9.2.3.4 00:、54:32:10、00:10:ダイナミックな2 10.0.0.15 00:、98:76:54、00:10:ダイナミック
The SNMPv2 entity acting in a manager role begins by sending a
GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER
values as the requested variable names:
マネージャの役割で行動するSNMPv2実体は要求された変数名として示されたOBJECT IDENTIFIER値を含むGetNextRequest-PDUを送ることによって、始まります:
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )
GetNextRequest(sysUpTime、ipNetToMediaPhysAddress、ipNetToMediaType)
Case, McCloghrie, Rose & Waldbusser [Page 16]
ケース、McCloghrie、ローズ、およびWaldbusser[16ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
The SNMPv2 entity acting in an agent role responds with a
Response-PDU:
エージェントの役割で行動するSNMPv2実体はResponse-PDUと共に応じます:
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ))
応答(sysUpTime.0=「123456」)、(ipNetToMediaPhysAddress.1.9.2.3.4=、「000010543210」)、(ipNetToMediaType.1.9.2.3.4=「動力」)
The SNMPv2 entity acting in a manager role continues with:
マネージャの役割で行動するSNMPv2実体は以下で続きます。
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.1.9.2.3.4,
ipNetToMediaType.1.9.2.3.4 )
GetNextRequest(sysUpTime、ipNetToMediaPhysAddress、.1 .9 .2 .3 .4、ipNetToMediaType.1.9、.2、.3、.4)
The SNMPv2 entity acting in an agent role responds with:
エージェントの役割で行動するSNMPv2実体は以下で応じます。
Response (( sysUpTime.0 = "123461" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))
応答(sysUpTime.0=「123461」)、(ipNetToMediaPhysAddress.1.10.0.0.51=、「000010012345」)、(ipNetToMediaType.1.10.0.0.51=「静的」)
The SNMPv2 entity acting in a manager role continues with:
マネージャの役割で行動するSNMPv2実体は以下で続きます。
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )
GetNextRequest(sysUpTime、ipNetToMediaPhysAddress、.1 .10 .0 .0 .51、ipNetToMediaType.1.10、.0、.0、.51)
The SNMPv2 entity acting in an agent role responds with:
エージェントの役割で行動するSNMPv2実体は以下で応じます。
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 = "dynamic" ))
応答(sysUpTime.0=「123466」)、(ipNetToMediaPhysAddress.2.10.0.0.15=、「000010987654」)、(ipNetToMediaType.2.10.0.0.15=「動力」)
The SNMPv2 entity acting in a manager role continues with:
マネージャの役割で行動するSNMPv2実体は以下で続きます。
GetNextRequest ( sysUpTime,
ipNetToMediaPhysAddress.2.10.0.0.15,
ipNetToMediaType.2.10.0.0.15 )
GetNextRequest(sysUpTime、ipNetToMediaPhysAddress、.2 .10 .0 .0 .15、ipNetToMediaType.2.10、.0、.0、.15)
As there are no further entries in the table, the SNMPv2
entity acting in an agent role responds with the variables
that are next in the lexicographical ordering of the
accessible object names, for example:
エントリーがこれ以上テーブルにないとき、エージェントの役割で行動するSNMPv2実体は例えばアクセスしやすいオブジェクト名の辞書編集の注文で次の変数で応じます:
Case, McCloghrie, Rose & Waldbusser [Page 17]
ケース、McCloghrie、ローズ、およびWaldbusser[17ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
Response (( sysUpTime.0 = "123471" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))
応答(sysUpTime.0=「123471」)、(ipNetToMediaNetAddress.1.9.2.3.4=、「9.2 .3 0.4インチ)、(ipRoutingDiscards.0が等しい、「2インチ)」
This response signals the end of the table to the SNMPv2
entity acting in a manager role.
この応答はマネージャの役割で行動するSNMPv2実体にテーブルの端を示します。
4.2.3. The GetBulkRequest-PDU
4.2.3. GetBulkRequest-PDU
A GetBulkRequest-PDU is generated and transmitted at the
request of a SNMPv2 application. The purpose of the
GetBulkRequest-PDU is to request the transfer of a potentially
large amount of data, including, but not limited to, the
efficient and rapid retrieval of large tables.
GetBulkRequest-PDUはSNMPv2アプリケーションの依頼で発生して、伝えられます。 GetBulkRequest-PDUの目的は潜在的に大データ量の転送を要求することです、含んでいます、他、大きいテーブルの効率的で急速な検索。
Upon receipt of a GetBulkRequest-PDU, the receiving SNMPv2
entity processes each variable binding in the variable-binding
list to produce a Response-PDU with its request-id field
having the same value as in the request. Processing begins by
examining the values in the non-repeaters and max-repetitions
fields. If the value in the non-repeaters field is less than
zero, then the value of the field is set to zero. Similarly,
if the value in the max-repetitions field is less than zero,
then the value of the field is set to zero.
GetBulkRequest-PDUを受け取り次第、受信SNMPv2実体は、要求のように同じ値を持っている要求イド分野があるResponse-PDUを生産するために変項束縛リストにおける各変項束縛を処理します。 処理は、非リピータと最大反復分野で値を調べることによって、始まります。 非リピータ分野の値がゼロ未満であるなら、分野の値はゼロに設定されます。 同様に、分野の値は最大反復分野の値がゼロ未満であるならゼロに設定されます。
For the GetBulkRequest-PDU type, the successful processing of
each variable binding in the request generates zero or more
variable bindings in the Response-PDU. That is, the one-to-
one mapping between the variable bindings of the GetRequest-
PDU, GetNextRequest-PDU, and SetRequest-PDU types and the
resultant Response-PDUs does not apply for the mapping between
the variable bindings of a GetBulkRequest-PDU and the
resultant Response-PDU.
GetBulkRequest-PDUタイプのために、要求における、それぞれの変項束縛のうまくいっている処理はResponse-PDUでゼロか、より可変な結合を発生させます。 すなわち、GetRequest- PDU、GetNextRequest-PDU、SetRequest-PDUタイプ、および結果のResponse-PDUsの変項束縛の間の1〜1つのマッピングはGetBulkRequest-PDUと結果のResponse-PDUの変項束縛の間でマッピングに申し込みません。
The values of the non-repeaters and max-repetitions fields in
the request specify the processing requested. One variable
binding in the Response-PDU is requested for the first N
variable bindings in the request and M variable bindings are
requested for each of the R remaining variable bindings in the
request. Consequently, the total number of requested variable
bindings communicated by the request is given by N + (M * R),
where N is the minimum of: a) the value of the non-repeaters
field in the request, and b) the number of variable bindings
要求における、非リピータと最大反復分野の値は要求された処理を指定します。 Response-PDUの1つの変項束縛が要求における最初のN変項束縛のために要求されています、そして、M可変な結合は、それぞれのRのために要求で変項束縛のままで残りながら、要求されています。 その結果、N+(M*R)で要求で伝えられた要求された変項束縛の総数をNが最小限であるところに与えます: a) b) 要求における、非リピータ分野の値、および変項束縛の数
Case, McCloghrie, Rose & Waldbusser [Page 18]
ケース、McCloghrie、ローズ、およびWaldbusser[18ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
in the request; M is the value of the max-repetitions field in
the request; and R is the maximum of: a) number of variable
bindings in the request - N, and b) zero.
要求で。 Mは要求で、最大反復分野の値です。 そして、Rは以下の最大です。 a) 要求における、変項束縛の数--b) N、およびゼロ。
The receiving SNMPv2 entity produces a Response-PDU with up to
the total number of requested variable bindings communicated
by the request. The request-id shall have the same value as
the received GetBulkRequest-PDU.
要求された変項束縛の総数が要求で伝えられている状態で、受信SNMPv2実体はResponse-PDUを生産します。 要求イドには、容認されたGetBulkRequest-PDUと同じ値があるものとします。
If N is greater than zero, the first through the (N)-th
variable bindings of the Response-PDU are each produced as
follows:
ゼロ以上、第1がNであるなら突き抜けている、(N)、-、第Response-PDUの変項束縛は以下の通りそれぞれ起こされます:
(1) The variable is located which is in the lexicographically
ordered list of the names of all variables which are
accessible by this request and whose name is the first
lexicographic successor of the variable binding's name in
the incoming GetBulkRequest-PDU. The corresponding
variable binding's name and value fields in the
Response-PDU are set to the name and value of the located
variable.
(1) すべてのこの要求でアクセスしやすい変数の名前の辞書編集の規則正しいリストにあって、名前が第1代入って来るGetBulkRequest-PDUの変項束縛の名前の辞書編集の後継者である変数は、見つけられています。 Response-PDUの対応する変項束縛の名前と値の分野は見つけられた変数の名前と値に設定されます。
(2) If the requested variable binding's name does not
lexicographically precede the name of any variable
accessible by this request, i.e., there is no
lexicographic successor, then the corresponding variable
binding produced in the Response-PDU has its value field
set to `endOfMibView', and its name field set to the
variable binding's name in the request.
(2) 要求された変項束縛の名前が辞書編集にこの要求でアクセスしやすいどんな変数の名前にも先行しないなら、すなわち、どんな辞書編集の後継者もいませんでした、そして、次に、Response-PDUで起こされた対応する変項束縛で'endOfMibView'に値の分野を設定します、そして、名前欄は要求における変項束縛の名前にセットしました。
If M and R are non-zero, the (N + 1)-th and subsequent
variable bindings of the Response-PDU are each produced in a
similar manner. For each iteration i, such that i is greater
than zero and less than or equal to M, and for each repeated
variable, r, such that r is greater than zero and less than or
equal to R, the (N + ( (i-1) * R ) + r)-th variable binding of
the Response-PDU is produced as follows:
第そして、MとRが非ゼロであるなら(N+1)、-、Response-PDUのその後の変項束縛はそれぞれ同じように起こされます。 各繰り返し、それぞれの繰り返された変数のためのi、iがゼロと、よりMよりすばらしいようなものとrとrがさらにゼロ以上であるようにものとR、(N+(i-1)*R)+よりr)、-、第Response-PDUの変項束縛は以下の通り起こされます:
(1) The variable which is in the lexicographically ordered
list of the names of all variables which are accessible
by this request and whose name is the (i)-th
lexicographic successor of the (N + r)-th variable
binding's name in the incoming GetBulkRequest-PDU is
located and the variable binding's name and value fields
are set to the name and value of the located variable.
(1) この要求でアクセスしやすく、名前があるすべての変数の名前の辞書編集の規則正しいリストにある変数、(i)、-、(N+r)の辞書編集の第後継者、-、入って来るGetBulkRequest-PDUの変項束縛の名前は見つけられていて、変項束縛の名前と値の分野は見つけられた変数の名前と値に第設定されます。
Case, McCloghrie, Rose & Waldbusser [Page 19]
ケース、McCloghrie、ローズ、およびWaldbusser[19ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
(2) If there is no (i)-th lexicographic successor, then the
corresponding variable binding produced in the Response-
PDU has its value field set to `endOfMibView', and its
name field set to either the last lexicographic
successor, or if there are no lexicographic successors,
to the (N + r)-th variable binding's name in the request.
そこであるなら(2)がノーである、(i)、-、辞書編集の後継者、次に、Response- PDUで起こされた対応する変項束縛で'endOfMibView'に値の分野を設定します、そして、名前欄は最後の辞書編集の後継者かそれともどんな辞書編集の後継者もいないかどうかにセットしました、(N+r)に第-、要求における変項束縛の第名前。
While the maximum number of variable bindings in the
Response-PDU is bounded by N + (M * R), the response may be
generated with a lesser number of variable bindings (possibly
zero) for either of two reasons.
Response-PDUの変項束縛の最大数は境界がある間、+ (M*R)、Nによる応答は2つの理由のどちらかのための、より少ない数の変項束縛(ことによるとゼロ)で発生するかもしれません。
(1) If the size of the message encapsulating the Response-PDU
containing the requested number of variable bindings
would be greater than either a local constraint or the
maximum message size of the request's source party, then
the response is generated with a lesser number of
variable bindings. This lesser number is the ordered set
of variable bindings with some of the variable bindings
at the end of the set removed, such that the size of the
message encapsulating the Response-PDU is approximately
equal to but no greater than the minimum of the local
constraint and the maximum message size of the request's
source party. Note that the number of variable bindings
removed has no relationship to the values of N, M, or R.
(1) 変項束縛の要求された数を含むResponse-PDUを要約するメッセージのサイズが要求のソースパーティーの地方の規制か最大のメッセージサイズのどちらかより大きいなら、応答は、より少ない数の変項束縛で発生します。 このより少ない数がセットの端の変項束縛のいくつかを取り除いている変項束縛の順序集合であるので、Response-PDUを要約するメッセージのサイズは、要求のソースパーティー同輩にもかかわらず、地方の規制と最大のメッセージサイズのおよそより最小限以下です。 取り除かれた変項束縛の数にはN、M、またはRの値との関係が全くないことに注意してください。
(2) The response may also be generated with a lesser number
of variable bindings if for some value of iteration i,
such that i is greater than zero and less than or equal
to M, that all of the generated variable bindings have
the value field set to the `endOfMibView'. In this case,
the variable bindings may be truncated after the (N + (i
* R))-th variable binding.
(2) また、繰り返しi(iがゼロと、よりMよりすばらしく、発生している変項束縛のすべてが'endOfMibView'に値の分野を設定させるようなもの)の何らかの値のために応答は、より少ない数の変項束縛で発生するかもしれません。 この場合変項束縛が先端を切られたかもしれない後、(N+(i*R))、-、第変項束縛。
If the processing of any variable binding fails for a reason
other than listed above, then the Response-PDU is re-formatted
with the same values in its request-id and variable-bindings
fields as the received GetBulkRequest-PDU, with the value of
its error-status field set to `genErr', and the value of its
error-index field is set to the index of the failed variable
binding.
どんな変項束縛の処理も上に記載されているのを除いた理由で失敗するなら、Response-PDUは容認されたGetBulkRequest-PDUとしてその要求イドと変項束縛分野で同じ値で再フォーマットされます、'genErr'に設定されたエラー状況分野の値で、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
Otherwise, the value of the Response-PDU's error-status field
is set to `noError', and the value of its error-index field to
zero.
さもなければ、Response-PDUのエラー状況分野の値は'noError'、およびゼロへの誤りインデックス部の値に設定されます。
Case, McCloghrie, Rose & Waldbusser [Page 20]
ケース、McCloghrie、ローズ、およびWaldbusser[20ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
The generated Response-PDU (possibly with an empty variable-
bindings field) is then encapsulated into a message. If the
size of the resultant message is less than or equal to both a
local constraint and the maximum message size of the request's
source party, it is transmitted to the originator of the
GetBulkRequest-PDU. Otherwise, the resultant message is
discarded.
そして、発生しているResponse-PDU(ことによると人影のない可変結合分野がある)はメッセージに要約されます。 結果のメッセージのサイズがともにa地方の、より規制と要求のソースパーティーの最大のメッセージサイズであるなら、それはGetBulkRequest-PDUの創始者に伝えられます。 さもなければ、結果のメッセージは捨てられます。
4.2.3.1. Another Example of Table Traversal
4.2.3.1. テーブル縦断に関する別の例
This example demonstrates how the GetBulkRequest-PDU can be
used as an alternative to the GetNextRequest-PDU. The same
traversal of the IP net-to-media table as shown in Section
4.2.2.1 is achieved with fewer exchanges.
この例はGetNextRequest-PDUに代わる手段としてどうGetBulkRequest-PDUを使用できるかを示します。 より少ない交換で達成されて、セクション4.2.2で.1がそうであることが示されるようにネットからメディアがテーブルの上に置くIPの同じ縦断。
The SNMPv2 entity acting in a manager role begins by sending a
GetBulkRequest-PDU with the modest max-repetitions value of 2,
and containing the indicated OBJECT IDENTIFIER values as the
requested variable names:
マネージャの役割で行動するSNMPv2実体は2の穏やかな最大反復値と、要求された変数名として示されたOBJECT IDENTIFIER値を含むのにGetBulkRequest-PDUを送ることによって、始まります:
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress,
ipNetToMediaType )
GetBulkRequest[非リピータは1、最大反復=2と等しいです](sysUpTime、ipNetToMediaPhysAddress、ipNetToMediaType)
The SNMPv2 entity acting in an agent role responds with a
Response-PDU:
エージェントの役割で行動するSNMPv2実体はResponse-PDUと共に応じます:
Response (( sysUpTime.0 = "123456" ),
( ipNetToMediaPhysAddress.1.9.2.3.4 =
"000010543210" ),
( ipNetToMediaType.1.9.2.3.4 = "dynamic" ),
( ipNetToMediaPhysAddress.1.10.0.0.51 =
"000010012345" ),
( ipNetToMediaType.1.10.0.0.51 = "static" ))
応答(sysUpTime.0=「123456」)、(ipNetToMediaPhysAddress、.1 .9 .2 .3 .4 =「000010543210」) (ipNetToMediaType.1.9.2.3.4=「動力」)、(ipNetToMediaPhysAddress.1.10.0.0.51=、「000010012345」)、(ipNetToMediaType.1.10.0.0.51=「静的」)
The SNMPv2 entity acting in a manager role continues with:
マネージャの役割で行動するSNMPv2実体は以下で続きます。
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ]
( sysUpTime,
ipNetToMediaPhysAddress.1.10.0.0.51,
ipNetToMediaType.1.10.0.0.51 )
GetBulkRequest[非リピータは1、最大反復=2と等しいです](sysUpTime、ipNetToMediaPhysAddress、.1 .10 .0 .0 .51、ipNetToMediaType.1.10、.0、.0、.51)
Case, McCloghrie, Rose & Waldbusser [Page 21]
ケース、McCloghrie、ローズ、およびWaldbusser[21ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
The SNMPv2 entity acting in an agent role responds with:
エージェントの役割で行動するSNMPv2実体は以下で応じます。
Response (( sysUpTime.0 = "123466" ),
( ipNetToMediaPhysAddress.2.10.0.0.15 =
"000010987654" ),
( ipNetToMediaType.2.10.0.0.15 =
"dynamic" ),
( ipNetToMediaNetAddress.1.9.2.3.4 =
"9.2.3.4" ),
( ipRoutingDiscards.0 = "2" ))
応答(sysUpTime.0=「123466」)、(ipNetToMediaPhysAddress、.2 .10 .0 .0 .15 =「000010987654」) (ipNetToMediaType.2.10.0.0.15=「動力」)、(ipNetToMediaNetAddress.1.9.2.3.4=、「9.2 .3 0.4インチ)、(ipRoutingDiscards.0が等しい、「2インチ)」
This response signals the end of the table to the SNMPv2
entity acting in a manager role.
この応答はマネージャの役割で行動するSNMPv2実体にテーブルの端を示します。
4.2.4. The Response-PDU
4.2.4. 応答-PDU
The Response-PDU is generated by a SNMPv2 entity only upon
receipt of a GetRequest-PDU, GetNextRequest-PDU,
GetBulkRequest-PDU, SetRequest-PDU, or InformRequest-PDU, as
described elsewhere in this document.
Response-PDUは単にGetRequest-PDU、GetNextRequest-PDU、GetBulkRequest-PDU、SetRequest-PDU、またはInformRequest-PDUを受け取り次第SNMPv2実体によって生成されます、ほかの場所で本書では説明されるように。
If the error-status field of the Response-PDU is non-zero, the
value fields of the variable bindings in the variable binding
list are ignored.
Response-PDUのエラー状況分野が非ゼロであるなら、変項束縛リストにおける変項束縛の値の分野は無視されます。
If both the error-status field and the error-index field of
the Response-PDU are non-zero, then the value of the error-
index field is the index of the variable binding (in the
variable-binding list of the corresponding request) for which
the request failed. The first variable binding in a request's
variable-binding list is index one, the second is index two,
etc.
エラー状況分野とResponse-PDUの誤りインデックス部の両方が非ゼロであるなら、誤りインデックス部の値は要求が失敗した変項束縛(対応する要求の変項束縛リストの)のインデックスです。 要求の変項束縛リストにおける最初の変項束縛がインデックス1である、2番目はインデックスtwoですなど。
A compliant SNMPv2 entity acting in a manager role must be
able to properly receive and handle a Response-PDU with an
error-status field equal to `noSuchName', `badValue', or
`readOnly'. (See Section 3.1.2 of [10].)
マネージャの役割で行動する対応するSNMPv2実体は、適切に'noSuchName'、'badValue'、または'readOnly'と等しいエラー状況分野があるResponse-PDUを受けて、扱うことができなければなりません。 ([10]についてセクション3.1.2を見てください。)
Upon receipt of a Response-PDU, the receiving SNMPv2 entity
presents its contents to the SNMPv2 application which
generated the request with the same request-id value.
Response-PDUを受け取り次第、受信SNMPv2実体は同じ要求イド値で要求を生成したSNMPv2アプリケーションにコンテンツを提示します。
Case, McCloghrie, Rose & Waldbusser [Page 22]
ケース、McCloghrie、ローズ、およびWaldbusser[22ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
4.2.5. The SetRequest-PDU
4.2.5. SetRequest-PDU
A SetRequest-PDU is generated and transmitted at the request
of a SNMPv2 application.
SetRequest-PDUはSNMPv2アプリケーションの依頼で生成されて、伝えられます。
Upon receipt of a SetRequest-PDU, the receiving SNMPv2 entity
determines the size of a message encapsulating a Response-PDU
with the same values in its request-id, error-status, error-
index and variable-bindings fields as the received
SetRequest-PDU. If the determined message size is greater
than either a local constraint or the maximum message size of
the request's source party, then an alternate Response-PDU is
generated, transmitted to the originator of the SetRequest-
PDU, and processing of the SetRequest-PDU terminates
immediately thereafter. This alternate Response-PDU is
formatted with the same values in its request-id field as the
received SetRequest-PDU, with the value of its error-status
field set to `tooBig', the value of its error-index field set
to zero, and an empty variable-bindings field. This alternate
Response-PDU is then encapsulated into a message. If the size
of the resultant message is less than or equal to both a local
constraint and the maximum message size of the request's
source party, it is transmitted to the originator of the
SetRequest-PDU. Otherwise, the resultant message is
discarded. Regardless, processing of the SetRequest-PDU
terminates.
SetRequest-PDUを受け取り次第、受信SNMPv2実体は同じ値が要求イドにある状態でResponse-PDUをカプセル化するメッセージのサイズを決定します、エラー状況、容認されたSetRequest-PDUとしての誤りインデックスと変項束縛分野。 決定しているメッセージサイズが要求のソースパーティーの地方の規制か最大のメッセージサイズのどちらかより大きいなら、代替のResponse-PDUはSetRequest- PDUの創始者に発生して、伝えられます、そして、SetRequest-PDUの処理はその後、すぐに、終わります。 この代替のResponse-PDUは容認されたSetRequest-PDUとして要求イド分野で同じ値でフォーマットされます、'tooBig'に設定されたエラー状況分野の値、ゼロに設定された誤りインデックス部の値、および人影のない変項束縛分野で。 そして、この代替のResponse-PDUはメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と要求のソースパーティーの最大のメッセージサイズであるなら、それはSetRequest-PDUの創始者に伝えられます。 さもなければ、結果のメッセージは捨てられます。 不注意に、SetRequest-PDUの処理は終わります。
Otherwise, the receiving SNMPv2 entity processes each variable
binding in the variable-binding list to produce a Response-
PDU. All fields of the Response-PDU have the same values as
the corresponding fields of the received request except as
indicated below.
さもなければ、受信SNMPv2実体は、Response- PDUを生産するために変項束縛リストにおける各変項束縛を処理します。 Response-PDUのすべての分野には、以下で示されるのを除いた受信された要求の対応する分野と同じ値があります。
The variable bindings are conceptually processed as a two
phase operation. In the first phase, each variable binding is
validated; if all validations are successful, then each
variable is altered in the second phase. Of course,
implementors are at liberty to implement either the first, or
second, or both, of the these conceptual phases as multiple
implementation phases. Indeed, such multiple implementation
phases may be necessary in some cases to ensure consistency.
変項束縛は二相操作として概念的に処理されます。 第1段階では、各変項束縛は有効にされます。 すべての合法化がうまくいくなら、各変数は2番目のフェーズで変更されます。 もちろん、作成者が1番目2番目、または両方のどちらかを実装するのにおいて自由である、複数の実施フェーズとしてのこれらの概念的なフェーズ。 本当に、そのような複数の実施フェーズが、いくつかの場合、一貫性があることを保証するのに必要であるかもしれません。
The following validations are performed in the first phase on
each variable binding until they are all successful, or until
one fails:
それらがすべてうまくいっているか、または1つが失敗するまで、以下の合法化は第1段階で各変項束縛に実行されます:
Case, McCloghrie, Rose & Waldbusser [Page 23]
ケース、McCloghrie、ローズ、およびWaldbusser[23ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
(1) If the variable binding's name specifies a variable which
is not accessible by this request, then the value of the
Response-PDU's error-status field is set to `noAccess',
and the value of its error-index field is set to the
index of the failed variable binding.
(1) 変項束縛の名前がこの要求でアクセスしやすくない変数を指定するなら、Response-PDUのエラー状況分野の値は'noAccess'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(2) Otherwise, if the variable binding's name specifies a
variable which does not exist and could not ever be
created, then the value of the Response-PDU's error-
status field is set to `noCreation', and the value of its
error-index field is set to the index of the failed
variable binding.
(2) さもなければ、変項束縛の名前を存在しない変数を指定して、かつて作成できないなら、Response-PDU誤りの状態分野の値は'noCreation'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(3) Otherwise, if the variable binding's name specifies a
variable which exists but can not be modified no matter
what new value is specified, then the value of the
Response-PDU's error-status field is set to
`notWritable', and the value of its error-index field is
set to the index of the failed variable binding.
(3) さもなければ、どんな新しい値が指定されても、変項束縛の名前を存在する変数を指定しますが、変更できないなら、Response-PDUのエラー状況分野の値は'notWritable'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(4) Otherwise, if the variable binding's value field
specifies, according to the ASN.1 language, a type which
is inconsistent with that required for the variable, then
the value of the Response-PDU's error-status field is set
to `wrongType', and the value of its error-index field is
set to the index of the failed variable binding.
(4) 次に、Response-PDUのエラー状況分野の値は'wrongType'に設定されます、そして、ASN.1言語によると、変項束縛の値の分野が指定するなら、さもなければ、それに矛盾したタイプが変数に必要であり、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(5) Otherwise, if the variable binding's value field
specifies, according to the ASN.1 language, a length
which is inconsistent with that required for the
variable, then the value of the Response-PDU's error-
status field is set to `wrongLength', and the value of
its error-index field is set to the index of the failed
variable binding.
(5) 次に、Response-PDU誤りの状態分野の値は'wrongLength'に設定されます、そして、ASN.1言語によると、変項束縛の値の分野が指定するなら、さもなければ、それに矛盾した長さが変数に必要であり、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(6) Otherwise, if the variable binding's value field contains
an ASN.1 encoding which is inconsistent with that field's
ASN.1 tag, then: the value of the Response-PDU's error-
status field is set to `wrongEncoding', and the value of
its error-index field is set to the index of the failed
variable binding.
(6) そうでなければ、その時変項束縛の値の分野がそのフィールドのASN.1タグに矛盾したASN.1コード化を含んでいるなら: Response-PDU誤りの状態分野の値は'wrongEncoding'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(7) Otherwise, if the variable binding's value field
specifies a value which could under no circumstances be
assigned to the variable, then: the value of the
(7) さもなければ、変項束縛の値の分野が決してそうすることができた値を指定するなら、変数に割り当てられてください、そして: 価値
Case, McCloghrie, Rose & Waldbusser [Page 24]
ケース、McCloghrie、ローズ、およびWaldbusser[24ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
Response-PDU's error-status field is set to `wrongValue',
and the value of its error-index field is set to the
index of the failed variable binding.
応答-PDUのエラー状況分野は'wrongValue'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(8) Otherwise, if the variable binding's name specifies a
variable which does not exist but can not be created not
under the present circumstances (even though it could be
created under other circumstances), then the value of the
Response-PDU's error-status field is set to
`inconsistentName', and the value of its error-index
field is set to the index of the failed variable binding.
(8) さもなければ、変項束縛の名前を存在しない変数を指定しますが、現在の情勢ではない作成できないなら(他の状況でそれを作成できるでしょうが)、Response-PDUのエラー状況分野の値は'inconsistentName'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(9) Otherwise, if the variable binding's value field
specifies a value that could under other circumstances be
assigned to the variable, but is presently inconsistent,
then the value of the Response-PDU's error-status field
is set to `inconsistentValue', and the value of its
error-index field is set to the index of the failed
variable binding.
(9) さもなければ、変項束縛の値の分野が他の状況で変数に割り当てることができるでしょうが、現在矛盾した値を指定するなら、Response-PDUのエラー状況分野の値は'inconsistentValue'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(10) Otherwise, if the assignment of the value specified by
the variable binding's value field to the specified
variable requires the allocation of a resource which is
presently unavailable, then: the value of the Response-
PDU's error-status field is set to `resourceUnavailable',
and the value of its error-index field is set to the
index of the failed variable binding.
(10) そうでなければ、その時変項束縛の値の分野によって指定された変数に指定された価値の課題が現在入手できないリソースの配分が必要であるなら: Response- PDUのエラー状況分野の値は'resourceUnavailable'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(11) If the processing of the variable binding fails for a
reason other than listed above, then the value of the
Response-PDU's error-status field is set to `genErr', and
the value of its error-index field is set to the index of
the failed variable binding.
(11) 変項束縛の処理が上に記載されているのを除いた理由で失敗するなら、Response-PDUのエラー状況分野の値は'genErr'に設定されます、そして、誤りインデックス部の値は失敗した変項束縛のインデックスに設定されます。
(12) Otherwise, the validation of the variable binding
succeeds.
(12) さもなければ、変項束縛の合法化は成功します。
At the end of the first phase, if the validation of all
variable bindings succeeded, then:
1日の終わりでは、その時のすべての変項束縛の合法化が成功したなら位相を合わせてください:
The value of the Response-PDU's error-status field is set to
`noError' and the value of its error-index field is zero.
Response-PDUのエラー状況分野の値は'noError'に設定されます、そして、誤りインデックス部の値はゼロです。
For each variable binding in the request, the named variable
is created if necessary, and the specified value is assigned
必要なら、要求における各変項束縛において、名前付き変数は作成されます、そして、規定値は割り当てられます。
Case, McCloghrie, Rose & Waldbusser [Page 25]
ケース、McCloghrie、ローズ、およびWaldbusser[25ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
to it. Each of these variable assignments occurs as if
simultaneously with respect to all other assignments specified
in the same request. However, if the same variable is named
more than once in a single request, with different associated
values, then the actual assignment made to that variable is
implementation-specific.
それに。 それぞれのこれらの可変課題はまるで同時であるかのように同じ要求で指定された他のすべての課題に関して起こります。 しかしながら、同じ変数が異なった関連値があるただ一つの要求の一度よりもう少し命名されるなら、その変数までされた実際の課題は実装特有です。
If any of these assignments fail (even after all the previous
validations), then all other assignments are undone, and the
Response-PDU is modified to have the value of its error-status
field set to `commitFailed', and the value of its error-index
field set to the index of the failed variable binding.
これらの課題のどれかが失敗するなら(前のすべての合法化の後にさえ)、他のすべての課題が元に戻されました、そして、Response-PDUは'commitFailed'にエラー状況分野の値を設定させるように変更されました、そして、誤りインデックス部の値は失敗した変項束縛のインデックスにセットしました。
If and only if it is not possible to undo all the assignments,
then the Response-PDU is modified to have the value of its
error-status field set to `undoFailed', and the value of its
error-index field is set to zero. Note that implementations
are strongly encouraged to take all possible measures to avoid
use of either `commitFailed' or `undoFailed' - these two
error-status codes are not to be taken as license to take the
easy way out in an implementation.
そして、すべての課題を元に戻すのが可能でない場合にだけ、Response-PDUは'undoFailed'にエラー状況分野の値を設定させるように変更されて、誤りインデックス部の値はゼロに設定されます。 実装が'commitFailed'か'undoFailed'のどちらかの使用を避けるすべての可能な対策を実施するよう強く奨励されることに注意してください--これらの2つのエラー状況コードは実装で簡単なやり方を見つけるライセンスとして取られないことです。
Finally, the generated Response-PDU is encapsulated into a
message, and transmitted to the originator of the SetRequest-
PDU.
最終的に、発生しているResponse-PDUはメッセージにカプセル化されて、SetRequest- PDUの創始者に伝えられます。
4.2.6. The SNMPv2-Trap-PDU
4.2.6. SNMPv2はPDUを捕らえます。
A SNMPv2-Trap-PDU is generated and transmitted by a SNMPv2
entity acting in an agent role when an exceptional situation
occurs.
SNMPv2罠PDUは例外的な状況が起こるとエージェントの役割で行動するSNMPv2実体によって、生成されて、伝えられます。
The destination(s) to which a SNMPv2-Trap-PDU is sent is
determined by consulting the aclTable [5] to find all entries
satisfying the following conditions:
SNMPv2罠PDUが送られる目的地はすべてのエントリーが以下の条件を満たしているのがわかるためにaclTable[5]に相談することによって、決定します:
(1) The value of aclSubject refers to the SNMPv2 entity.
(1) aclSubjectの値はSNMPv2実体について言及します。
(2) The value of aclPrivileges allows for the SNMPv2-Trap-
PDU.
(2) aclPrivilegesの値はSNMPv2罠-PDUを考慮します。
(3) aclResources refers to a SNMPv2 context denoting local
object resources, and the notification's administratively
assigned name is present in the corresponding MIB view.
(3) aclResourcesはローカルのオブジェクトリソースを指示するSNMPv2文脈を示します、そして、通知の行政上割り当てられた名前は対応するMIB視点で存在しています。
Case, McCloghrie, Rose & Waldbusser [Page 26]
ケース、McCloghrie、ローズ、およびWaldbusser[26ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
(That is, the set of entries in the viewTable [5] for
which the instance of viewIndex has the same value as the
aclResources's contextViewIndex, define a MIB view which
contains the notification's administratively assigned
name.)
それはそうです、viewIndexのインスタンスには同じ値があるviewTable[5]のエントリーのセット。(aclResourcesのcontextViewIndexと、名前が行政上割り当てられて、通知のものを含むMIB視点を定義してください、)
(4) If the OBJECTS clause is present in the invocation of the
corresponding NOTIFICATION-TYPE macro, then the
correspondent variables are all present in the MIB view
corresponding to aclResource.
(4) OBJECTS節が対応するNOTIFICATION-TYPEマクロの実施で存在しているなら、通信員変数はaclResourceに対応するMIB視点ですべて存在しています。
Then, for each entry satisfying these conditions, a SNMPv2-
Trap-PDU is sent from aclSubject with context aclResources to
aclTarget. The instance of snmpTrapNumbers [11] corresponding
to aclTarget is incremented, and is used as the request-id
field of the SNMPv2-Trap-PDU. Then, the variable-bindings
field are constructed as:
そして、これらの状態を満たす各エントリーにおいて、SNMPv2罠-PDUを文脈aclResourcesとaclSubjectからaclTargetに送ります。 aclTargetに対応するsnmpTrapNumbers[11]のインスタンスは、増加されていて、SNMPv2がPDUを捕らえることの要求イド分野として使用されます。 そして、変項束縛分野は以下として構成されます。
(1) The first variable is sysUpTime.0 [9].
(1) 最初の変数はsysUpTime.0[9]です。
(2) The second variable is snmpTrapOID.0 [11], which contains
the administratively assigned name of the notification.
(2) 2番目の変数はsnmpTrapOID.0[11]です。(その[11]は通知の行政上割り当てられた名前を含みます)。
(3) If the OBJECTS clause is present in the invocation of the
corresponding NOTIFICATION-TYPE macro, then each
corresponding variable is copied, in order, to the
variable-bindings field.
(3) OBJECTS節が対応するNOTIFICATION-TYPEマクロの実施で存在しているなら、それぞれの対応する変数はコピーされます、オーダーで、変項束縛分野に。
(4) At the option of the SNMPv2 entity acting in an agent
role, additional variables may follow in the variable-
bindings field.
(4) エージェントの役割で行動するSNMPv2実体の選択のときに、追加変数は可変結合分野で従うかもしれません。
4.2.7. The InformRequest-PDU
4.2.7. InformRequest-PDU
An InformRequest-PDU is generated and transmitted at the
request an application in a SNMPv2 entity acting in a manager
role, that wishes to notify another application (in a SNMPv2
entity also acting in a manager role) of information in the
MIB View of a party local to the sending application.
InformRequest-PDUはSNMPv2実体におけるアプリケーションがマネージャの役割で行動して、それが送付アプリケーションへの地元のパーティーについてMIB Viewの情報の別のアプリケーション(また、マネージャの役割で行動するSNMPv2実体における)に通知したがっているという要求によって生成されて、伝えられます。
The destination(s) to which an InformRequest-PDU is sent is
determined by inspecting the snmpEventNotifyTable [12], or as
specified by the requesting application. The first two
variable bindings in the variable binding list of an
InformRequest-PDUが送られる目的地がsnmpEventNotifyTable[12]を点検することによって決定するか、または要求アプリケーションで指定するようにあります。 変項束縛における最初の2つの変項束縛が記載します。
Case, McCloghrie, Rose & Waldbusser [Page 27]
ケース、McCloghrie、ローズ、およびWaldbusser[27ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
InformRequest-PDU are sysUpTime.0 [9] and snmpEventID.i [12]
respectively. If the OBJECTS clause is present in the
invocation of the corresponding NOTIFICATION-TYPE macro, then
each corresponding variable, as instantiated by this
notification, is copied, in order, to the variable-bindings
field.
InformRequest-PDUはそれぞれsysUpTime.0[9]とsnmpEventID.i[12]です。 OBJECTS節が対応するNOTIFICATION-TYPEマクロの実施で存在しているなら、この通知で例示されるそれぞれの対応する変数はコピーされます、オーダーで、変項束縛分野に。
Upon receipt of an InformRequest-PDU, the receiving SNMPv2
entity determines the size of a message encapsulating a
Response-PDU with the same values in its request-id, error-
status, error-index and variable-bindings fields as the
received InformRequest-PDU. If the determined message size is
greater than either a local constraint or the maximum message
size of the request's source party, then an alternate
Response-PDU is generated, transmitted to the originator of
the InformRequest-PDU, and processing of the InformRequest-PDU
terminates immediately thereafter. This alternate Response-
PDU is formatted with the same values in its request-id field
as the received InformRequest-PDU, with the value of its
error-status field set to `tooBig', the value of its error-
index field set to zero, and an empty variable-bindings field.
This alternate Response-PDU is then encapsulated into a
message. If the size of the resultant message is less than or
equal to both a local constraint and the maximum message size
of the request's source party, it is transmitted to the
originator of the InformRequest-PDU. Otherwise, the resultant
message is discarded. Regardless, processing of the
InformRequest-PDU terminates.
InformRequest-PDUを受け取り次第、受信SNMPv2実体は同じ値が要求イドにある状態でResponse-PDUをカプセル化するメッセージのサイズ、誤り状態(容認されたInformRequest-PDUとしての誤りインデックスと変項束縛分野)を決定します。 決定しているメッセージサイズが要求のソースパーティーの地方の規制か最大のメッセージサイズのどちらかより大きいなら、代替のResponse-PDUはInformRequest-PDUの創始者に発生して、伝えられます、そして、InformRequest-PDUの処理はその後、すぐに、終わります。 この代替のResponse- PDUは容認されたInformRequest-PDUとして要求イド分野で同じ値でフォーマットされます、'tooBig'に設定されたエラー状況分野の値、ゼロに設定された誤りインデックス部の値、および人影のない変項束縛分野で。 そして、この代替のResponse-PDUはメッセージにカプセル化されます。 結果のメッセージのサイズがともにa地方の、より規制と要求のソースパーティーの最大のメッセージサイズであるなら、それはInformRequest-PDUの創始者に伝えられます。 さもなければ、結果のメッセージは捨てられます。 不注意に、InformRequest-PDUの処理は終わります。
Otherwise, the receiving SNMPv2 entity:
そうでなければ、受信SNMPv2実体:
(1) presents its contents to the appropriate SNMPv2
application;
(1)は適切なSNMPv2アプリケーションにコンテンツを提示します。
(2) generates a Response-PDU with the same values in its
request-id and variable-bindings fields as the received
InformRequest-PDU, with the value of its error-status
field is set to `noError' and the value of its error-
index field is zero; and
同じ値がその要求イドと変項束縛分野にある状態で、(2)は容認されたInformRequest-PDU、エラー状況の値で、分野が'noError'に設定されて、誤りインデックス部の値がゼロであるので、Response-PDUを生成します。 そして
(3) transmits the generated Response-PDU to the originator of
the InformRequest-PDU.
(3)は発生しているResponse-PDUをInformRequest-PDUの創始者に伝えます。
Case, McCloghrie, Rose & Waldbusser [Page 28]
ケース、McCloghrie、ローズ、およびWaldbusser[28ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
5. Acknowledgements
5. 承認
This document is based, in part, on RFC 1157. The mechanism
for bulk retrieval is influenced by many experiments,
including RFC1187 and also Greg Satz's work on SNMP over TCP.
このドキュメントはRFC1157に一部基づいています。 多くの実験で大量の検索のためのメカニズムは影響を及ぼされます、TCPの上にSNMPへのRFC1187とグレッグSatzの作業も含んでいて。
Finally, the comments of the SNMP version 2 working group are
gratefully acknowledged:
最終的に、SNMPバージョン2ワーキンググループのコメントは感謝して承諾されます:
Beth Adams, Network Management Forum
Steve Alexander, INTERACTIVE Systems Corporation
David Arneson, Cabletron Systems
Toshiya Asaba
Fred Baker, ACC
Jim Barnes, Xylogics, Inc.
Brian Bataille
Andy Bierman, SynOptics Communications, Inc.
Uri Blumenthal, IBM Corporation
Fred Bohle, Interlink
Jack Brown
Theodore Brunner, Bellcore
Stephen F. Bush, GE Information Services
Jeffrey D. Case, University of Tennessee, Knoxville
John Chang, IBM Corporation
Szusin Chen, Sun Microsystems
Robert Ching
Chris Chiotasso, Ungermann-Bass
Bobby A. Clay, NASA/Boeing
John Cooke, Chipcom
Tracy Cox, Bellcore
Juan Cruz, Datability, Inc.
David Cullerot, Cabletron Systems
Cathy Cunningham, Microcom
James R. (Chuck) Davin, Bellcore
Michael Davis, Clearpoint
Mike Davison, FiberCom
Cynthia DellaTorre, MITRE
Taso N. Devetzis, Bellcore
Manual Diaz, DAVID Systems, Inc.
Jon Dreyer, Sun Microsystems
David Engel, Optical Data Systems
Mike Erlinger, Lexcel
Roger Fajman, NIH
Daniel Fauvarque, Sun Microsystems
Karen Frisa, CMU
ベス・アダムス、ネットワークマネージメントフォーラムスティーブ・アレクサンダー、SynOpticsコミュニケーションInc.のインタラクティブシステム社のデヴィッドArneson、CabletronシステムToshiya浅羽フレッドパン屋(ACCジム・バーンズ)Xylogics Inc.ブライアンBatailleアンディBierman; ユリ・ブルーメンソル、IBM社のフレッドBohleはジャック・ブラウン・セオドア・ブルンナーを連結します、Bellcoreのスティーブン・F.ブッシュ、サービスジェフリーD.がケースに入れるGE情報、テネシーの大学、ノクスビルジョン・チャン、IBMの社のSzusinチェン、サン・マイクロシステムズロバートチンクリスChiotasso、アンガマン-BassボビーA; 粘土、NASA/ボーイングのジョン・クック、ChipcomトレーシーCox、Bellcoreのホアン・クルーズ、Datability Inc.デヴィッドCullerot、Cabletronシステムキャシーカニンハム、Microcomジェームス・R.(チャック)デーヴィン、BellcoreのMichael Davis、Clearpointマイク・デイヴィソン、FiberComシンシアDellaTorre、Inc.ジョン・ドレイヤー、サン・マイクロシステムズのデヴィッド・エンゲル、光学データシステムズマイクErlinger、LexcelロジャーFajman、NIHダニエルFauvarque、サン・マイクロシステムズカレンFrisa、斜め継ぎTaso N.Devetzis、Bellcoreの手動のディアーズデヴィッドSystems米カーネギーメロン大学
Case, McCloghrie, Rose & Waldbusser [Page 29]
ケース、McCloghrie、ローズ、およびWaldbusser[29ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
Shari Galitzer, MITRE
Shawn Gallagher, Digital Equipment Corporation
Richard Graveman, Bellcore
Maria Greene, Xyplex, Inc.
Michel Guittet, Apple
Robert Gutierrez, NASA
Bill Hagerty, Cabletron Systems
Gary W. Haney, Martin Marietta Energy Systems
Patrick Hanil, Nokia Telecommunications
Matt Hecht, SNMP Research, Inc.
Edward A. Heiner, Jr., Synernetics Inc.
Susan E. Hicks, Martin Marietta Energy Systems
Geral Holzhauer, Apple
John Hopprich, DAVID Systems, Inc.
Jeff Hughes, Hewlett-Packard
Robin Iddon, Axon Networks, Inc.
David Itusak
Kevin M. Jackson, Concord Communications, Inc.
Ole J. Jacobsen, Interop Company
Ronald Jacoby, Silicon Graphics, Inc.
Satish Joshi, SynOptics Communications, Inc.
Frank Kastenholz, FTP Software
Mark Kepke, Hewlett-Packard
Ken Key, SNMP Research, Inc.
Zbiginew Kielczewski, Eicon
Jongyeoi Kim
Andrew Knutsen, The Santa Cruz Operation
Michael L. Kornegay, VisiSoft
Deirdre C. Kostik, Bellcore
Cheryl Krupczak, Georgia Tech
Mark S. Lewis, Telebit
David Lin
David Lindemulder, AT&T/NCR
Ben Lisowski, Sprint
David Liu, Bell-Northern Research
John Lunny, The Wollongong Group
Robert C. Lushbaugh Martin, Marietta Energy Systems
Michael Luufer, BBN
Carl Madison, Star-Tek, Inc.
Keith McCloghrie, Hughes LAN Systems
Evan McGinnis, 3Com Corporation
Bill McKenzie, IBM Corporation
Donna McMaster, SynOptics Communications, Inc.
John Medicke, IBM Corporation
Doug Miller, Telebit
Shari Galitzer、斜め継ぎショーン・ギャラガー、DECリチャードGraveman、Bellcoreのマリア・グリーン、Xyplex Inc.ミシェルGuittet、アップルのロバート・グティエレス、NASAのビル・ハガーティ、ゲーリー・W.ヘーニー、マーチンマリエッタエネルギー・システムパトリックHanil、Cabletronシステムノキアのテレコミュニケーションマット・ヘヒト、SNMPはInc.について研究します; エドワードA.ハイナー、Jr.、Synernetics株式会社のスーザン・E.ヒックス、マーチンマリエッタエネルギー・システムGeral Holzhauer、アップルジョンHopprich、デヴィッドSystems Inc.ジェフ・ヒューズ、ヒューレット・パッカードロビンIddon、軸索はInc.をネットワークでつなぎます; デヴィッド・Itusakケビン・M.ジャクソン、Inc.Ole J.ジェイコブセン、一致コミュニケーションInterop会社のロナルド・ジャコービー、シリコングラフィックスのサティシュ・ジョーシー、SynOpticsコミュニケーションInc.フランクKastenholz、FTPソフトウェアマークKepke、ヒューレット・パッカードケンKey、SNMPはInc.Zbiginew Kielczewskiについて研究します、Eicon Jongyeoiキム・アンドリュー・クヌーセン、サンタクルス操作マイケルL.Kornegay、VisiSoftディアドラC.Kostik、BellcoreシェリルKrupczak、ジョージア工科大のマークS.ルイス、テレビットデヴィッドリンデヴィッドLindemulder、AT&T/NCRベンLisowski、短距離競走デヴィッド・リュウ、研究ジョンLunny、ベル-北ウォロンゴンはロバート・C.Lushbaughマーチン、マリエッタエネルギー・システムマイケルLuufer、BBNカール・マディソン、Tekに主演しているInc.キースMcCloghrie、エヴァン・マクギニス、ヒューズLANシステム3Com社のビル・マッケンジーを分類します、IBMの社のドナ・マクマスター、SynOpticsコミュニケーションInc.ジョンMedicke、IBMの社のダグ・ミラー、テレビット
Case, McCloghrie, Rose & Waldbusser [Page 30]
ケース、McCloghrie、ローズ、およびWaldbusser[30ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
Dave Minnich, FiberCom
Mohammad Mirhakkak, MITRE
Rohit Mital, Protools
George Mouradian, AT&T Bell Labs
Patrick Mullaney, Cabletron Systems
Dan Myers, 3Com Corporation
Rina Nathaniel, Rad Network Devices Ltd.
Hien V. Nguyen, Sprint
Mo Nikain
Tom Nisbet
William B. Norton, MERIT
Steve Onishi, Wellfleet Communications, Inc.
David T. Perkins, SynOptics Communications, Inc.
Carl Powell, BBN
Ilan Raab, SynOptics Communications, Inc.
Richard Ramons, AT&T
Venkat D. Rangan, Metric Network Systems, Inc.
Louise Reingold, Sprint
Sam Roberts, Farallon Computing, Inc.
Kary Robertson, Concord Communications, Inc.
Dan Romascanu, Lannet Data Communications Ltd.
Marshall T. Rose, Dover Beach Consulting, Inc.
Shawn A. Routhier, Epilogue Technology Corporation
Chris Rozman
Asaf Rubissa, Fibronics
Jon Saperia, Digital Equipment Corporation
Michael Sapich
Mike Scanlon, Interlan
Sam Schaen, MITRE
John Seligson, Ultra Network Technologies
Paul A. Serice, Corporation for Open Systems
Chris Shaw, Banyan Systems
Timon Sloane
Robert Snyder, Cisco Systems
Joo Young Song
Roy Spitier, Sprint
Einar Stefferud, Network Management Associates
John Stephens, Cayman Systems, Inc.
Robert L. Stewart, Xyplex, Inc. (chair)
Kaj Tesink, Bellcore
Dean Throop, Data General
Ahmet Tuncay, France Telecom-CNET
Maurice Turcotte, Racal Datacom
Warren Vik, INTERACTIVE Systems Corporation
Yannis Viniotis
デーヴ・ミンニヒ、FiberComムハマドMirhakkak、斜め継ぎRohit Mital、ProtoolsジョージMouradian、AT&Tのベル研究所のパトリック・マレイニイ、Cabletronシステムダン・マイアーズ、3Com社のリーナ・ナザニエル、radネットワークデバイス株式会社Hien V.Nguyen(Sprint Mo NikainトムニスベットウィリアムB.ノートン)がスティーブ鬼石に値して、WellfleetコミュニケーションがInc.デヴィッド・T.パーキンスであり、SynOpticsコミュニケーションはInc.カール・パウエルです、BBN宜蘭ラープ、SynOpticsコミュニケーションInc.リチャードRamons、AT&TヴェンカトD.Rangan、メートル法のネットワーク・システムInc; ルイーズ・レインゴールド、短距離競走サム・ロバーツ、ファラロンコンピューティングInc.Karyロバートソン、一致コミュニケーションInc.ダンRomascanu、Lannetデータ通信株式会社マーシャルT.は上昇しました、ドーヴァービーチコンサルティングInc.ショーンA; Routhier、エピローグ技術社のクリスRozman Asaf Rubissa、FibronicsジョンSaperia、DECのマイケル・Sapichマイク・スキャンロン、InterlanサムSchaen、斜め継ぎジョンSeligson、超ネットワーク技術のポールA.Serice、クリス・ショー、オープンシステムバニヤンシステムタイモンスローンロバートへの社 スナイダー、シスコシステムズのJooの若い歌のロイSpitier、短距離競走Einar Stefferud、ネットワークマネージメントはジョン・スティーブンスを関連づけます、ケイマンシステムInc.ロバート・L.スチュワート、Xyplex Inc.(いす)カイTesink(BellcoreディーンThroop)データゼネラルAhmet Tuncay、フランステレコム-CNETモーリスTurcotte、Racal Datacomウォレン・ビークインタラクティブシステム社のヤニスViniotis
Case, McCloghrie, Rose & Waldbusser [Page 31]
ケース、McCloghrie、ローズ、およびWaldbusser[31ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
Steven L. Waldbusser, Carnegie Mellon Universitty
Timothy M. Walden, ACC
Alice Wang, Sun Microsystems
James Watt, Newbridge
Luanne Waul, Timeplex
Donald E. Westlake III, Digital Equipment Corporation
Gerry White
Bert Wijnen, IBM Corporation
Peter Wilson, 3Com Corporation
Steven Wong, Digital Equipment Corporation
Randy Worzella, IBM Corporation
Daniel Woycke, MITRE
Honda Wu
Jeff Yarnell, Protools
Chris Young, Cabletron
Kiho Yum, 3Com Corporation
スティーブンL.Waldbusser、カーネギー・メロン・Universittyティモシー・M.ウォルデンACCアリスワング、サン・マイクロシステムズのジェームズ・ワット、NewbridgeルアンWaul、Timeplexドナルド・E.ウェストレークIII、DECゲリーホワイトバートWijnen、IBMの社のピーター・ウィルソン、3Com社のスティーブンWong、DECランディWorzella、IBM社のダニエルWoycke、斜め継ぎホンダウージェフYarnell、Protoolsクリス・ヤング、おいしいCabletron Kiho3Com社
Case, McCloghrie, Rose & Waldbusser [Page 32]
ケース、McCloghrie、ローズ、およびWaldbusser[32ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
6. References
6. 参照
[1] Information processing systems - Open Systems
Interconnection - Specification of Abstract Syntax
Notation One (ASN.1), International Organization for
Standardization. International Standard 8824, (December,
1987).
[1] 情報処理システム--オープン・システム・インターコネクション--抽象的なSyntax Notation One(ASN.1)、国際標準化機構の仕様。 国際規格8824、(1987年12月。)
[2] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Structure of Management Information for version 2 of the
Simple Network Management Protocol (SNMPv2)", RFC 1442,
SNMP Research, Inc., Hughes LAN Systems, Dover Beach
Consulting, Inc., Carnegie Mellon University, April 1993.
[2] ケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのManagement情報の構造」RFC1442、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[3] Galvin, J., and McCloghrie, K., "Administrative Model for
version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1445, Trusted Information Systems, Hughes
LAN Systems, April 1993.
[3] ガルビン、J.とMcCloghrie、K.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための管理Model」RFC1445、Trusted情報システム、ヒューズLAN Systems(1993年4月)。
[4] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Textual Conventions for version 2 of the the Simple
Network Management Protocol (SNMPv2)", RFC 1443, SNMP
Research, Inc., Hughes LAN Systems, Dover Beach
Consulting, Inc., Carnegie Mellon University, April 1993.
[4] ケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための原文のConventions」RFC1443、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[5] McCloghrie, K., and Galvin, J., "Party MIB for version 2
of the Simple Network Management Protocol (SNMPv2)", RFC
1447, Hughes LAN Systems, Trusted Information Systems,
April 1993.
[5] McCloghrie、K.とガルビン、J.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためのパーティMIB」RFC1447、ヒューズLAN Systems、Trusted情報システム(1993年4月)。
[6] C. Kent, J. Mogul, Fragmentation Considered Harmful,
Proceedings, ACM SIGCOMM '87, Stowe, VT, (August 1987).
[6] C.ケント、J.ムガール人、有害であると考えられた断片化、議事、ACM SIGCOMM87年、ストウ、バーモント(1987年8月)。
[7] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Transport Mappings for version 2 of the Simple Network
Management Protocol (SNMPv2)", RFC 1449, SNMP Research,
Inc., Hughes LAN Systems, Dover Beach Consulting, Inc.,
Carnegie Mellon University, April 1993.
[7] ケース、J.、McCloghrie、K.、ローズ、M.、およびWaldbusser、S.は「Simple Network Managementプロトコル(SNMPv2)のバージョン2のためにMappingsを輸送します」、RFC1449、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学、1993年4月。
[8] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC/Information Sciences Institute, August 1980.
[8] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、科学が1980年8月に設けるUSC/情報。
[9] McCloghrie, K., and Rose, M., "Management Information
Base for Network Management of TCP/IP-based internets:
MIB-II", STD 17, RFC 1213, March 1991.
[9] McCloghrie、K.とローズ、M.、「TCP/IPベースのインターネットのNetwork Managementのための管理Information基地:」 「MIB-II」、STD17、RFC1213、1991年3月。
Case, McCloghrie, Rose & Waldbusser [Page 33]
ケース、McCloghrie、ローズ、およびWaldbusser[33ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
[10] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Coexistence between version 1 and version 2 of the
Internet-standard Network Management Framework", RFC
1452, SNMP Research, Inc., Hughes LAN Systems, Dover
Beach Consulting, Inc., Carnegie Mellon University, April
1993.
[10] ケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「インターネット標準Network Management Frameworkのバージョン1とバージョン2の間の共存」RFC1452、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[11] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Management Information Base for version 2 of the Simple
Network Management Protocol (SNMPv2)", RFC 1450, SNMP
Research, Inc., Hughes LAN Systems, Dover Beach
Consulting, Inc., Carnegie Mellon University, April 1993.
[11] ケースとJ.とMcCloghrieとK.とローズ、M.とWaldbusser、S.、「Simple Network Managementプロトコル(SNMPv2)のバージョン2のための管理Information基地」RFC1450、SNMP Research Inc.、ヒューズLAN Systems、ドーヴァービーチConsulting Inc.、カーネギーメロン大学(1993年4月)。
[12] Case, J., McCloghrie, K., Rose, M., and Waldbusser, S.,
"Manager-to-Manager Management Information Base", RFC
1451, SNMP Research, Inc., Hughes LAN Systems, Dover
Beach Consulting, Inc., Carnegie Mellon University, April
1993.
[12] ケース、J.、McCloghrie、K.、ローズ、M.、およびWaldbusser、S.、「マネージャからマネージャへの管理情報ベース」、RFC1451、SNMPはInc.について研究します、ヒューズLANシステム、ドーヴァービーチコンサルティングInc.、カーネギーメロン大学、1993年4月。
Case, McCloghrie, Rose & Waldbusser [Page 34]
ケース、McCloghrie、ローズ、およびWaldbusser[34ページ]
RFC 1448 Protocol Operations for SNMPv2 April 1993
SNMPv2 April 1993のためのRFC1448プロトコル操作
7. Security Considerations
7. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
8. Authors' Addresses
8. 作者のアドレス
Jeffrey D. Case
SNMP Research, Inc.
3001 Kimberlin Heights Rd.
Knoxville, TN 37920-9716
US
ジェフリーD.ケースSNMP研究Inc.3001Kimberlin Heights通り ノクスビル、テネシー37920-9716米国
Phone: +1 615 573 1434
Email: case@snmp.com
以下に電話をしてください。 +1 1434年の615 573メール: case@snmp.com
Keith McCloghrie
Hughes LAN Systems
1225 Charleston Road
Mountain View, CA 94043
US
キースMcCloghrieヒューズLANシステム1225チャールストンRoadカリフォルニア94043マウンテンビュー(米国)
Phone: +1 415 966 7934
Email: kzm@hls.com
以下に電話をしてください。 +1 7934年の415 966メール: kzm@hls.com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
US
Inc.420Whisman法廷カリフォルニア94043-2186マウンテンビュー(米国)に相談するマーシャル・T.バラドーヴァービーチ
Phone: +1 415 968 1052
Email: mrose@dbc.mtview.ca.us
以下に電話をしてください。 +1 1052年の415 968メール: mrose@dbc.mtview.ca.us
Steven Waldbusser
Carnegie Mellon University
4910 Forbes Ave
Pittsburgh, PA 15213
US
スティーブンWaldbusserカーネギーメロン大学4910フォーブズ・Ave PA15213ピッツバーグ(米国)
Phone: +1 412 268 6628
Email: waldbusser@cmu.edu
以下に電話をしてください。 +1 6628年の412 268メール: waldbusser@cmu.edu
Case, McCloghrie, Rose & Waldbusser [Page 35]
ケース、McCloghrie、ローズ、およびWaldbusser[35ページ]
一覧
スポンサーリンク
