[要約] RFC 3416はSNMPのプロトコル操作のバージョン2を定義しており、SNMPの管理操作を効率的に実行するための標準化を目的としています。
Network Working Group Editor of this version:
Request for Comments: 3416 R. Presuhn
STD: 62 BMC Software, Inc.
Obsoletes: 1905 Authors of previous version:
Category: Standards Track J. Case
SNMP Research, Inc.
K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
December 2002
Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)
簡易ネットワーク管理プロトコル（SNMP）のプロトコル操作のバージョン2
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
Abstract
概要
This document defines version 2 of the protocol operations for the Simple Network Management Protocol (SNMP). It defines the syntax and elements of procedure for sending, receiving, and processing SNMP PDUs. This document obsoletes RFC 1905.
このドキュメントでは、簡易ネットワーク管理プロトコル（SNMP）のプロトコル操作のバージョン2を定義します。 SNMP PDUを送信、受信、処理するための手順の構文と要素を定義します。このドキュメントはRFC 1905を廃止します。
Table of Contents
目次
1. Introduction ................................................ 3
2. Overview .................................................... 4
2.1. Management Information .................................... 4
2.2. Retransmission of Requests ................................ 4
2.3. Message Sizes ............................................. 4
2.4. Transport Mappings ........................................ 5
2.5. SMIv2 Data Type Mappings .................................. 6
3. Definitions ................................................. 6
4. Protocol Specification ...................................... 9
4.1. Common Constructs ......................................... 9
4.2. PDU Processing ............................................ 10
4.2.1. The GetRequest-PDU ...................................... 10
4.2.2. The GetNextRequest-PDU .................................. 11
4.2.2.1. Example of Table Traversal ............................ 12
4.2.3. The GetBulkRequest-PDU .................................. 14
4.2.3.1. Another Example of Table Traversal .................... 17
4.2.4. The Response-PDU ........................................ 18
4.2.5. The SetRequest-PDU ...................................... 19
4.2.6. The SNMPv2-Trap-PDU ..................................... 22
4.2.7. The InformRequest-PDU ................................... 23
5. Notice on Intellectual Property ............................. 24
6. Acknowledgments ............................................. 24
7. Security Considerations ..................................... 26
8. References .................................................. 26
8.1. Normative References ...................................... 26
8.2. Informative References .................................... 27
9. Changes from RFC 1905 ....................................... 28
10. Editor's Address ........................................... 30
11. Full Copyright Statement ................................... 31
The SNMP Management Framework at the time of this writing consists of five major components:
この記事の執筆時点でのSNMP管理フレームワークは、次の5つの主要コンポーネントで構成されています。
- An overall architecture, described in STD 62, RFC 3411 [RFC3411].
- STD 62、RFC 3411 [RFC3411]で説明されている全体的なアーキテクチャ。
- 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 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580].
- 管理の目的でオブジェクトとイベントを記述および命名するためのメカニズム。この管理情報構造（SMI）の最初のバージョンはSMIv1と呼ばれ、STD 16、RFC 1155 [RFC1155]、STD 16、RFC 1212 [RFC1212]およびRFC 1215 [RFC1215]で説明されています。 SMIv2と呼ばれる2番目のバージョンは、STD 58、RFC 2578 [RFC2578]、STD 58、RFC 2579 [RFC2579]およびSTD 58、RFC 2580 [RFC2580]で説明されています。
- Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and STD 62, RFC 3417 [RFC3417]. The third version of the message protocol is called SNMPv3 and described in STD 62, RFC 3417 [RFC3417], RFC 3412 [RFC3412] and RFC 3414 [RFC3414].
- 管理情報を転送するためのメッセージプロトコル。 SNMPメッセージプロトコルの最初のバージョンはSNMPv1と呼ばれ、STD 15、RFC 1157 [RFC1157]で説明されています。インターネット標準トラックプロトコルではない、SNMPメッセージプロトコルの2番目のバージョンはSNMPv2cと呼ばれ、RFC 1901 [RFC1901]およびSTD 62、RFC 3417 [RFC3417]で説明されています。メッセージプロトコルの3番目のバージョンはSNMPv3と呼ばれ、STD 62、RFC 3417 [RFC3417]、RFC 3412 [RFC3412]およびRFC 3414 [RFC3414]で説明されています。
- Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in this document.
- 管理情報にアクセスするためのプロトコル操作。プロトコル操作と関連するPDU形式の最初のセットは、STD 15、RFC 1157 [RFC1157]で説明されています。このドキュメントでは、プロトコル操作と関連するPDUフォーマットの2番目のセットについて説明します。
- A set of fundamental applications described in STD 62, RFC 3413 [RFC3413] and the view-based access control mechanism described in STD 62, RFC 3415 [RFC3415].
- STD 62、RFC 3413 [RFC3413]で説明されている基本的なアプリケーションのセット、およびSTD 62、RFC 3415 [RFC3415]で説明されているビューベースのアクセス制御メカニズム。
A more detailed introduction to the SNMP Management Framework at the time of this writing can be found in RFC 3410 [RFC3410].
この記事の執筆時点でのSNMP管理フレームワークの詳細については、RFC 3410 [RFC3410]を参照してください。
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で定義されたメカニズムを使用して定義されます。
This document, Version 2 of the Protocol Operations for the Simple Network Management Protocol, defines the operations of the protocol with respect to the sending and receiving of PDUs to be carried by the message protocol.
このドキュメント、Simple Network Management Protocolのプロトコル操作のバージョン2は、メッセージプロトコルによって伝送されるPDUの送受信に関するプロトコルの操作を定義しています。
SNMP entities supporting command generator or notification receiver applications (traditionally called "managers") communicate with SNMP entities supporting command responder or notification originator applications (traditionally called "agents"). The purpose of this protocol is the transport of management information and operations.
コマンドジェネレーターまたは通知レシーバーアプリケーション（従来は「マネージャー」と呼ばれていました）をサポートするSNMPエンティティは、コマンドレスポンダーまたは通知発信元アプリケーション（従来は「エージェント」と呼ばれていました）をサポートするSNMPエンティティーと通信します。このプロトコルの目的は、管理情報と操作の転送です。
The term "variable" refers to an instance of a non-aggregate object type defined according to the conventions set forth in the SMI [RFC2578] or the textual conventions based on the SMI [RFC2579]. 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 [RFC2578]で規定された規則またはSMI [RFC2579]に基づくテキストの規則に従って定義された非集合オブジェクトタイプのインスタンスを指します。 「変数バインディング」という用語は通常、変数の名前とそれに関連付けられた値のペアを指します。ただし、検索要求の処理中に特定の種類の例外条件が発生した場合、変数バインディングは名前とその例外の表示をペアにします。
A variable-binding list is a simple list of variable bindings.
変数バインディングリストは、変数バインディングの単純なリストです。
The name of a variable is an OBJECT IDENTIFIER which is the concatenation of the OBJECT IDENTIFIER of the corresponding object-type together with an OBJECT IDENTIFIER fragment identifying the instance. The OBJECT IDENTIFIER of the corresponding object-type is called the OBJECT IDENTIFIER prefix of the variable.
変数の名前は、対応するオブジェクトタイプのOBJECT IDENTIFIERとインスタンスを識別するOBJECT IDENTIFIERフラグメントを連結したOBJECT IDENTIFIERです。対応するオブジェクトタイプのOBJECT IDENTIFIERは、変数のOBJECT IDENTIFIERプレフィックスと呼ばれます。
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. See BCP 41 [RFC2914] for discussion of relevant congestion control principles.
このプロトコルのすべてのタイプの要求について、通常の状況下では、要求の発信者に応答を生成して送信するために受信者が必要です。対応する応答が適切な時間間隔で受信されない場合に要求を再送信する必要があるかどうかは、要求を発信したアプリケーションの裁量にあります。これは通常、リクエストの緊急度によって異なります。ただし、そのようなアプリケーションは、再送信の頻度と期間に関して責任を持って動作する必要があります。関連する輻輳制御の原則については、BCP 41 [RFC2914]を参照してください。
The maximum size of an SNMP message is limited to the minimum of:
SNMPメッセージの最大サイズは、次の最小値に制限されます。
(1) the maximum message size which the destination SNMP entity can accept; and,
（1）宛先SNMPエンティティが受け入れることができる最大メッセージサイズ。そして、
(2) the maximum message size which the source SNMP entity can generate.
（2）ソースSNMPエンティティが生成できる最大メッセージサイズ。
The former may be known on a per-recipient basis; and in the absence of such knowledge, is indicated by transport domain used when sending the message. The latter is imposed by implementation-specific local constraints.
前者は受信者ごとに知られている場合があります。そのような知識がない場合、メッセージの送信時に使用されるトランスポートドメインによって示されます。後者は、実装固有のローカル制約によって課せられます。
Each transport mapping for the SNMP indicates the minimum message size which a SNMP 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 SNMP entity.
SNMPの各トランスポートマッピングは、SNMP実装が生成または消費できる必要がある最小メッセージサイズを示します。実装では、可能な限り大きな値をサポートすることをお勧めしますが、準拠する実装では、受信側のSNMPエンティティで許可されているよりも大きなメッセージを生成してはなりません。
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 an SNMP entity supporting command generator applications 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 SNMP entity supporting command responder applications can generate, and the SNMP entity supporting command generator applications can receive.
このプロトコルで指定されているGetBulkRequest-PDUの目的の1つは、大量の管理情報を取得するために必要なプロトコル交換の数を最小限に抑えることです。そのため、このPDUタイプを使用すると、コマンドジェネレーターアプリケーションをサポートするSNMPエンティティが、メッセージサイズの制約を前提として、応答をできるだけ大きくするように要求できます。これらの制約には、コマンドレスポンダーアプリケーションをサポートするSNMPエンティティが生成でき、コマンドジェネレーターアプリケーションをサポートするSNMPエンティティが受信できるメッセージサイズの制限が含まれます。
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 [FRAG], since among other problems, it leads to a decrease in the reliability of the transfer of the messages. Thus, an SNMP 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.
ただし、そのような最大サイズのメッセージは、メッセージが通過するネットワーク全体のパスのパスMTUよりも大きくなる可能性があります。この状況では、そのようなメッセージは断片化する可能性があります。フラグメンテーションは一般に有害であると考えられています[FRAG]。これは、他の問題の中でも、メッセージ転送の信頼性の低下につながるためです。したがって、GetBulkRequest-PDUを送信するSNMPエンティティは、フラグメンテーションのリスクを減らすために、それに応じてパラメーターを設定するように注意する必要があります。特に、ネットワークに負荷がかかる状況では、max-repetitionsには小さな値のみを使用する必要があります。
It is important to note that the exchange of SNMP 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 [RFC3417]. However, the preferred mapping is the use of the User Datagram Protocol [RFC768].
SNMPメッセージの交換に必要なのは信頼性の低いデータグラムサービスだけであり、すべてのメッセージが完全に独立して単一のトランスポートデータグラムに含まれていることに注意することが重要です。特定のトランスポートマッピングとエンコーディングルールは、他の場所[RFC3417]で指定されています。ただし、推奨されるマッピングは、ユーザーデータグラムプロトコル[RFC768]の使用です。
The SMIv2 [RFC2578] defines 11 base types (INTEGER, OCTET STRING, OBJECT IDENTIFIER, Integer32, IpAddress, Counter32, Gauge32, Unsigned32, TimeTicks, Opaque, Counter64) and the BITS construct. The SMIv2 base types are mapped to the corresponding selection type in the SimpleSyntax and ApplicationSyntax choices of the ASN.1 SNMP protocol definition. Note that the INTEGER and Integer32 SMIv2 base types are mapped to the integer-value selection type of the SimpleSyntax choice. Similarly, the Gauge32 and Unsigned32 SMIv2 base types are mapped to the unsigned-integer-value selection type of the ApplicationSyntax choice.
SMIv2 [RFC2578]は、11の基本タイプ（INTEGER、OCTET STRING、OBJECT IDENTIFIER、Integer32、IpAddress、Counter32、Gauge32、Unsigned32、TimeTicks、Opaque、Counter64）およびBITS構成を定義します。 SMIv2基本タイプは、ASN.1 SNMPプロトコル定義のSimpleSyntaxとApplicationSyntaxの選択肢の対応する選択タイプにマップされます。 INTEGERおよびInteger32 SMIv2基本タイプは、SimpleSyntax選択の整数値選択タイプにマップされることに注意してください。同様に、Gauge32およびUnsigned32 SMIv2基本タイプは、ApplicationSyntax選択のunsigned-integer-value選択タイプにマップされます。
The SMIv2 BITS construct is mapped to the string-value selection type of the SimpleSyntax choice. A BITS value is encoded as an OCTET STRING, in which all the named bits in (the definition of) the bitstring, commencing with the first bit and proceeding to the last bit, are placed in bits 8 (high order bit) to 1 (low order bit) of the first octet, followed by bits 8 to 1 of each subsequent octet in turn, followed by as many bits as are needed of the final subsequent octet, commencing with bit 8. Remaining bits, if any, of the final octet are set to zero on generation and ignored on receipt.
SMIv2 BITS構成は、SimpleSyntax選択の文字列値選択タイプにマップされます。 BITS値はOCTET STRINGとしてエンコードされます。ビットストリング（の定義）内のすべての名前付きビットは、最初のビットから始まり、最後のビットに進み、ビット8（上位ビット）から1（最初のオクテットの下位ビット）、その後に続く各オクテットのビット8から1が順番に続き、最後の後続のオクテットに必要なだけのビットが続きます。ビット8から始まります。最後の残りのビット（ある場合）オクテットは生成時にゼロに設定され、受信時には無視されます。
The PDU syntax is defined using ASN.1 notation [ASN1].
PDU構文は、ASN.1表記[ASN1]を使用して定義されます。
SNMPv2-PDU DEFINITIONS ::= BEGIN
ObjectName ::= OBJECT IDENTIFIER
ObjectSyntax ::= CHOICE {
simple SimpleSyntax,
application-wide ApplicationSyntax }
SimpleSyntax ::= CHOICE {
integer-value INTEGER (-2147483648..2147483647),
string-value OCTET STRING (SIZE (0..65535)),
objectID-value OBJECT IDENTIFIER }
ApplicationSyntax ::= CHOICE {
ipAddress-value IpAddress,
counter-value Counter32,
timeticks-value TimeTicks,
arbitrary-value Opaque,
big-counter-value Counter64,
unsigned-integer-value Unsigned32 }
IpAddress ::= [APPLICATION 0] IMPLICIT OCTET STRING (SIZE (4))
Counter32 ::= [APPLICATION 1] IMPLICIT INTEGER (0..4294967295)
Unsigned32 ::= [APPLICATION 2] IMPLICIT INTEGER (0..4294967295)
Gauge32 ::= Unsigned32
TimeTicks ::= [APPLICATION 3] IMPLICIT INTEGER (0..4294967295)
Opaque ::= [APPLICATION 4] IMPLICIT OCTET STRING
Counter64 ::= [APPLICATION 6]
IMPLICIT INTEGER (0..18446744073709551615)
-- protocol data units
-プロトコルデータユニット
PDUs ::= CHOICE {
get-request GetRequest-PDU,
get-next-request GetNextRequest-PDU,
get-bulk-request GetBulkRequest-PDU,
response Response-PDU,
set-request SetRequest-PDU,
inform-request InformRequest-PDU,
snmpV2-trap SNMPv2-Trap-PDU,
report Report-PDU }
-- PDUs
-PDU
GetRequest-PDU ::= [0] IMPLICIT PDU
GetNextRequest-PDU ::= [1] IMPLICIT PDU
Response-PDU ::= [2] IMPLICIT PDU
SetRequest-PDU ::= [3] IMPLICIT PDU
-- [4] is obsolete
-[4]は廃止されました
GetBulkRequest-PDU ::= [5] IMPLICIT BulkPDU
InformRequest-PDU ::= [6] IMPLICIT PDU
SNMPv2-Trap-PDU ::= [7] IMPLICIT PDU
-- Usage and precise semantics of Report-PDU are not defined -- in this document. Any SNMP administrative framework making -- use of this PDU must define its usage and semantics.
-Report-PDUの使用法と正確なセマンティクスは定義されていません-このドキュメントでは。 SNMP管理フレームワークの作成-このPDUの使用は、その使用法とセマンティクスを定義する必要があります。
Report-PDU ::= [8] IMPLICIT PDU
max-bindings INTEGER ::= 2147483647
PDU ::= SEQUENCE {
request-id INTEGER (-214783648..214783647),
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) },
error-status-無視される場合があるINTEGER {noError（0）、tooBig（1）、noSuchName（2）、-プロキシ互換性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）}、
error-index -- sometimes ignored INTEGER (0..max-bindings),
error-index-INTEGER（0..max-bindings）が無視されることがある、
variable-bindings -- values are sometimes ignored VarBindList }
変数バインディング-値は時々無視されますVarBindList}
BulkPDU ::= -- must be identical in
SEQUENCE { -- structure to PDU
request-id INTEGER (-214783648..214783647),
non-repeaters INTEGER (0..max-bindings),
max-repetitions INTEGER (0..max-bindings),
variable-bindings -- values are ignored VarBindList }
variable-bindings-値は無視されますVarBindList}
-- variable binding VarBind ::= SEQUENCE {
name ObjectName,
CHOICE { value ObjectSyntax, unSpecified NULL, -- in retrieval requests
CHOICE {value ObjectSyntax、unSpecified NULL、-取得リクエスト内
-- exceptions in responses
noSuchObject [0] IMPLICIT NULL,
noSuchInstance [1] IMPLICIT NULL,
endOfMibView [2] IMPLICIT NULL
}
}
-- variable-binding list
-変数バインディングリスト
VarBindList ::= SEQUENCE (SIZE (0..max-bindings)) OF VarBind
END
終わり
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, an 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 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のrequest-idフィールドの値は、それが応答である要求PDUのrequest-idフィールドの値を取ります。 request-id値を使用することで、アプリケーションは（潜在的に複数の）未解決の要求を区別し、それによって着信応答を未解決の要求に関連付けることができます。信頼性の低いデータグラムサービスが使用されている場合、request-idは、ネットワークによって複製されたメッセージを識別する簡単な手段も提供します。要求の再送信で同じrequest-idを使用すると、元の送信または再送信のいずれかに対する応答で要求を満たすことができます。ただし、要求と応答のトランザクションの送信と処理の往復時間を計算するために、アプリケーションは再送信された要求で別の要求ID値を使用する必要があります。後者の戦略は、ほとんどの状況で使用することをお勧めします。
A non-zero value of the error-status field in a Response-PDU is used to indicate that an error 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 error. 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のerror-statusフィールドのゼロ以外の値は、要求の処理を妨げるためにエラーが発生したことを示すために使用されます。これらの場合、Response-PDUのerror-indexフィールドのゼロ以外の値は、リスト内のどの変数バインディングがエラーの原因であるかを識別することにより、追加情報を提供します。変数バインディングは、そのインデックス値によって識別されます。変数バインドリストの最初の変数バインドはインデックス1、2番目はインデックス2などです。
SNMP limits OBJECT IDENTIFIER values to a maximum of 128 sub-identifiers, where each sub-identifier has a maximum value of 2**32-1.
SNMPは、OBJECT IDENTIFIER値を最大128のサブ識別子に制限します。各サブ識別子の最大値は2 ** 32-1です。
In the elements of procedure below, any field of a PDU which is not referenced by the relevant procedure is ignored by the receiving SNMP entity. However, all components of a PDU, including those whose values are ignored by the receiving SNMP 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 SNMP entity. The unSpecified value is defined for use as the value portion of such bindings.
以下の手順の要素では、関連する手順で参照されていないPDUのフィールドは、受信SNMPエンティティによって無視されます。ただし、受信SNMPエンティティによって値が無視されるものを含め、PDUのすべてのコンポーネントには、有効なASN.1構文とエンコーディングが必要です。たとえば、一部のPDU（GetRequest-PDUなど）は、変数の名前だけに関係し、その値には関係しません。この場合、変数バインディングの値の部分は、受信SNMPエンティティによって無視されます。 unSpecified値は、そのようなバインディングの値部分として使用するために定義されています。
On generating a management communication, the message "wrapper" to encapsulate the PDU is generated according to the "Elements of Procedure" of the administrative framework in use. The definition of "max-bindings" imposes an upper bound on the number of variable bindings. In practice, the size of a message is also limited by constraints on the maximum message size. A compliant implementation must support as many variable bindings in a PDU or BulkPDU as fit into the overall maximum message size limit of the SNMP engine, but no more than 2147483647 variable bindings.
管理通信を生成すると、PDUをカプセル化するためのメッセージ「ラッパー」が、使用中の管理フレームワークの「Elements of Procedure」に従って生成されます。 「max-bindings」の定義は、変数バインディングの数に上限を課します。実際には、メッセージのサイズは最大メッセージサイズの制約によっても制限されます。準拠した実装は、SNMPエンジンの全体的な最大メッセージサイズの制限に適合するだけのPDUまたはBulkPDUの変数バインディングをサポートする必要がありますが、変数バインディングは2147483647以下でなければなりません。
On receiving a management communication, the "Elements of Procedure" of the administrative framework in use is followed, and if those procedures indicate that the operation contained within the message is to be performed locally, then those procedures also indicate the MIB view which is visible to the operation.
管理通信を受信すると、使用中の管理フレームワークの「Elements of Procedure」に従い、メッセージ内に含まれる操作がローカルで実行されることをこれらの手順が示している場合、それらの手順は表示されているMIBビューも示しています操作に。
A GetRequest-PDU is generated and transmitted at the request of an application.
GetRequest-PDUは、アプリケーションの要求で生成および送信されます。
Upon receipt of a GetRequest-PDU, the receiving SNMP 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を受信すると、受信SNMPエンティティは、変数バインディングリスト内の各変数バインディングを処理して、Response-PDUを生成します。以下に示す場合を除き、Response-PDUのすべてのフィールドは、受信したリクエストの対応するフィールドと同じ値です。各変数バインディングは次のように処理されます。
(1) If the variable binding's name exactly matches the name of a variable accessible by this request, then the variable binding's value field is set to the value of the named variable.
（1）変数バインディングの名前がこの要求でアクセス可能な変数の名前と完全に一致する場合、変数バインディングの値フィールドは名前付き変数の値に設定されます。
(2) Otherwise, if the variable binding's name does not have an OBJECT IDENTIFIER prefix which exactly matches the OBJECT IDENTIFIER prefix of any (potential) variable accessible by this request, then its value field is set to "noSuchObject".
（2）それ以外の場合、変数バインディングの名前に、このリクエストでアクセス可能な（潜在的な）変数のOBJECT IDENTIFIERプレフィックスと正確に一致するOBJECT IDENTIFIERプレフィックスがない場合、その値フィールドは「noSuchObject」に設定されます。
(3) Otherwise, the variable binding's value field is set to "noSuchInstance".
（3）それ以外の場合、変数バインディングの値フィールドは「noSuchInstance」に設定されます。
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は、request-idおよびvariable-bindingsフィールドの値が、受信した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 originator, it is transmitted to the originator of the GetRequest-PDU.
生成されたResponse-PDUは、メッセージにカプセル化されます。結果のメッセージのサイズがローカル制約と発信者の最大メッセージサイズの両方以下の場合、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 originator, it is transmitted to the originator of the GetRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded.
それ以外の場合は、代替のResponse-PDUが生成されます。この代替Response-PDUは、リクエストされたGetRequest-PDUと同じリクエストIDフィールドの値でフォーマットされ、エラーステータスフィールドの値は「tooBig」に設定され、エラーインデックスフィールドの値はゼロに設定されます。 、および空の変数バインディングフィールド。次に、この代替Response-PDUがメッセージにカプセル化されます。結果のメッセージのサイズがローカル制約と発信者の最大メッセージサイズの両方以下の場合、GetRequest-PDUの発信者に送信されます。それ以外の場合、snmpSilentDrops [RFC3418]カウンターが増分され、結果のメッセージは破棄されます。
A GetNextRequest-PDU is generated and transmitted at the request of an application.
GetNextRequest-PDUは、アプリケーションの要求で生成および送信されます。
Upon receipt of a GetNextRequest-PDU, the receiving SNMP 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を受信すると、受信SNMPエンティティは、変数バインディングリスト内の各変数バインディングを処理して、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）この要求によってアクセス可能なすべての変数の名前の辞書式順序付けされたリストにあり、その名前が着信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のrequest-idフィールドとvariable-bindingsフィールドの値は、受信した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 originator, it is transmitted to the originator of the GetNextRequest-PDU.
生成されたResponse-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 originator, it is transmitted to the originator of the GetNextRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded.
それ以外の場合は、代替のResponse-PDUが生成されます。この代替Response-PDUは、リクエストされたGetNextRequest-PDUと同じリクエストIDフィールドの値でフォーマットされ、エラーステータスフィールドの値は「tooBig」に設定され、エラーインデックスフィールドの値はゼロに設定されます。 、および空の変数バインディングフィールド。次に、この代替Response-PDUがメッセージにカプセル化されます。結果のメッセージのサイズがローカル制約と発信者の最大メッセージサイズの両方以下の場合、GetNextRequest-PDUの発信者に送信されます。それ以外の場合、snmpSilentDrops [RFC3418]カウンターが増分され、結果のメッセージは破棄されます。
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, an application retrieves the media-dependent physical address and the address-mapping type for each entry in the IP net-to-media Address Translation Table [RFC1213] of a particular network element. It also retrieves the value of sysUpTime [RFC3418], at which the mappings existed. Suppose that the command responder's IP net-to-media table has three entries:
以下に示すプロトコル交換では、アプリケーションは特定のネットワーク要素のIPネットからメディアへのアドレス変換テーブル[RFC1213]の各エントリのメディア依存の物理アドレスとアドレスマッピングタイプを取得します。また、マッピングが存在したsysUpTime [RFC3418]の値も取得します。コマンドレスポンダのIP net-to-mediaテーブルに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
The SNMP entity supporting a command generator application begins by sending a GetNextRequest-PDU containing the indicated OBJECT IDENTIFIER values as the requested variable names:
コマンドジェネレーターアプリケーションをサポートするSNMPエンティティは、要求された変数名として示されたOBJECT IDENTIFIER値を含むGetNextRequest-PDUを送信することから始まります。
GetNextRequest ( sysUpTime, ipNetToMediaPhysAddress, ipNetToMediaType )
GetNextRequest（sysUpTime、ipNetToMediaPhysAddress、ipNetToMediaType）
The SNMP entity supporting a command responder application responds with a Response-PDU:
コマンドレスポンダーアプリケーションをサポートするSNMPエンティティは、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 = "dynamic"））
The SNMP entity supporting the command generator application continues with:
コマンドジェネレーターアプリケーションをサポートするSNMPエンティティは、次のように続行されます。
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 SNMP entity supporting the command responder application responds with:
コマンドレスポンダーアプリケーションをサポートするSNMPエンティティは、次のように応答します。
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 = "static"））
The SNMP entity supporting the command generator application continues with:
コマンドジェネレーターアプリケーションをサポートするSNMPエンティティは、次のように続行されます。
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 SNMP entity supporting the command responder application responds with:
コマンドレスポンダーアプリケーションをサポートするSNMPエンティティは、次のように応答します。
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 = "dynamic"））
The SNMP entity supporting the command generator application continues with:
コマンドジェネレーターアプリケーションをサポートするSNMPエンティティは、次のように続行されます。
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 SNMP entity supporting the command responder application responds with the variables that are next in the lexicographical ordering of the accessible object names, for example:
テーブルにはそれ以上のエントリがないため、コマンドレスポンダーアプリケーションをサポートするSNMPエンティティは、アクセス可能なオブジェクト名の辞書式順序で次にある変数で応答します。次に例を示します。
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.4"）、（ipRoutingDiscards.0 = "2"））
Note how, having reached the end of the column for ipNetToMediaPhysAddress, the second variable binding from the command responder application has now "wrapped" to the first row in the next column. Furthermore, note how, having reached the end of the ipNetToMediaTable for the third variable binding, the command responder application has responded with the next available object, which is outside that table. This response signals the end of the table to the command generator application.
ipNetToMediaPhysAddressの列の終わりに達したので、コマンドレスポンダーアプリケーションからの2番目の変数バインディングが次の列の最初の行に「ラップ」されていることに注意してください。さらに、3番目の変数バインディングのipNetToMediaTableの終わりに達したときに、コマンドレスポンダーアプリケーションが、そのテーブルの外にある次の使用可能なオブジェクトで応答したことに注意してください。この応答は、コマンドジェネレーターアプリケーションにテーブルの終わりを通知します。
A GetBulkRequest-PDU is generated and transmitted at the request of an 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は、アプリケーションの要求で生成および送信されます。 GetBulkRequest-PDUの目的は、大規模なテーブルの効率的で迅速な取得など、潜在的に大量のデータの転送を要求することです。
Upon receipt of a GetBulkRequest-PDU, the receiving SNMP 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.
GetBulkRequest-PDUを受信すると、受信SNMPエンティティは、変数バインディングリストの各変数バインディングを処理して、リクエストと同じ値を持つrequest-idフィールドを持つ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に0個以上の変数バインディングが生成されます。つまり、GetRequest-PDU、GetNextRequest- PDU、およびSetRequest-PDUタイプの変数バインディング間の1対1マッピングと、結果のResponse-PDUは、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 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.
リクエスト内のnon-repeatersフィールドとmax-repetitionsフィールドの値は、リクエストされた処理を指定します。要求内の最初のN個の変数バインディングに対して1つのResponse-PDUの変数バインディングが要求され、要求内の残りのR個の変数バインディングのそれぞれに対してM個の変数バインディングが要求されます。したがって、要求によって通信される要求された変数バインディングの総数は、N +（M * R）で与えられます。ここで、Nは次の最小値です：a）要求内の非リピーターフィールドの値、およびb）数リクエスト内の変数バインディング。 Mは、リクエストのmax-repetitionsフィールドの値です。 Rは次の最大値です。a）要求内の変数バインディングの数-N、およびb）ゼロ。
The receiving SNMP 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.
受信側のSNMPエンティティは、要求によって通信された、要求された変数バインディングの合計数までのResponse-PDUを生成します。 request-idは、受信した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:
Nがゼロより大きい場合、Response-PDUの最初から（N）番目までの変数バインディングは、それぞれ次のように生成されます。
(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）この要求によってアクセス可能なすべての変数の名前の辞書式順序付きリストにあり、その名前が着信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: (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.
MとRがゼロ以外の場合、Response-PDUの（N + 1）番目以降の変数バインディングは、それぞれ同様の方法で生成されます。各反復i（iがゼロより大きくM以下）、および繰り返し変数r（rがゼロより大きくR以下）の場合、（N +（（i -1）* R）+ r）番目のResponse-PDUの変数バインディングは、次のように生成されます。着信GetBulkRequest-PDU内の（N + r）番目の変数バインディングの名前の（i）番目の辞書式サクセサが検索され、変数バインディングの名前と値のフィールドが、検索された変数の名前と値に設定されます。
(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 three reasons.
Response-PDUの変数バインディングの最大数はN +（M * R）によって制限されますが、3つの理由のいずれかにより、より少ない数の変数バインディング（おそらくゼロ）で応答が生成されることがあります。
(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 originator, 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 either a local constraint or the maximum message size of the originator. 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 "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））番目の変数バインディングの後に切り捨てられる場合があります。
(3) In the event that the processing of a request with many repetitions requires a significantly greater amount of processing time than a normal request, then a command responder application may terminate the request with less than the full number of repetitions, providing at least one repetition is completed.
（3）繰り返しが多いリクエストの処理に通常のリクエストよりも大幅に長い処理時間が必要な場合、コマンドレスポンダアプリケーションは、繰り返しの総数より少ないリクエストで終了し、少なくとも1回の繰り返しが完了しました。
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 variable binding in the original request which corresponds to the failed variable binding.
上記以外の理由で変数バインディングの処理が失敗した場合、Response-PDUのrequest-idフィールドとvariable-bindingsフィールドの値は、受信した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」に設定され、エラーインデックスフィールドの値はゼロに設定されます。
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 originator, it is transmitted to the originator of the GetBulkRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded.
生成されたResponse-PDU（変数バインディングフィールドが空の場合もある）は、メッセージにカプセル化されます。結果のメッセージのサイズがローカル制約と発信者の最大メッセージサイズの両方以下の場合は、GetBulkRequest-PDUの発信者に送信されます。それ以外の場合、snmpSilentDrops [RFC3418]カウンターが増分され、結果のメッセージは破棄されます。
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 SNMP entity supporting the command generator application 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:
コマンドジェネレーターアプリケーションをサポートするSNMPエンティティは、まず、適度なmax-repetitions値が2で、要求された変数名として指定されたOBJECT IDENTIFIER値を含むGetBulkRequest-PDUを送信します。
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] ( sysUpTime, ipNetToMediaPhysAddress, ipNetToMediaType )
GetBulkRequest [非リピーター= 1、最大繰り返し数= 2]（sysUpTime、ipNetToMediaPhysAddress、ipNetToMediaType）
The SNMP entity supporting the command responder application responds with a Response-PDU:
コマンドレスポンダーアプリケーションをサポートするSNMPエンティティは、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 = "dynamic"）、（ipNetToMediaPhysAddress.1.10.0.0.51 = " 000010012345 "）、（ipNetToMediaType.1.10.0.0.51 =" static "））
The SNMP entity supporting the command generator application continues with:
コマンドジェネレーターアプリケーションをサポートするSNMPエンティティは、次のように続行されます。
GetBulkRequest [ non-repeaters = 1, max-repetitions = 2 ] ( sysUpTime, ipNetToMediaPhysAddress.1.10.0.0.51, ipNetToMediaType.1.10.0.0.51 )
GetBulkRequest [non-repeaters = 1、max-repetitions = 2]（sysUpTime、ipNetToMediaPhysAddress.1.10.0.0.51、ipNetToMediaType.1.10.0.0.51）
The SNMP entity supporting the command responder application responds with:
コマンドレスポンダーアプリケーションをサポートするSNMPエンティティは、次のように応答します。
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 = "dynamic"）、（ipNetToMediaNetAddress.1.9.2.3.4 = " 9.2.3.4 "）、（ipRoutingDiscards.0 =" 2 "））
Note how, as in the first example, the variable bindings in the response indicate that the end of the table has been reached. The fourth variable binding does so by returning information from the next available column; the fifth variable binding does so by returning information from the first available object lexicographically following the table. This response signals the end of the table to the command generator application.
最初の例のように、応答の変数バインディングがテーブルの最後に到達したことを示していることに注意してください。 4番目の変数バインディングは、次に利用可能な列から情報を返すことによって行います。 5番目の変数バインディングは、辞書順でテーブルに従って、最初の使用可能なオブジェクトから情報を返すことで、これを行います。この応答は、コマンドジェネレーターアプリケーションにテーブルの終わりを通知します。
The Response-PDU is generated by an SNMP 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を受信したときにのみ、SNMPエンティティによって生成されます。
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番目はインデックス2などです。
A compliant SNMP entity supporting a command generator application must be able to properly receive and handle a Response-PDU with an error-status field equal to "noSuchName", "badValue", or "readOnly". (See sections 1.3 and 4.3 of [RFC2576].)
コマンドジェネレーターアプリケーションをサポートする準拠SNMPエンティティは、「noSuchName」、「badValue」、または「readOnly」に等しいエラーステータスフィールドを持つResponse-PDUを適切に受信して処理できる必要があります。 （[RFC2576]のセクション1.3と4.3を参照してください。）
Upon receipt of a Response-PDU, the receiving SNMP entity presents its contents to the application which generated the request with the same request-id value. For more details, see [RFC3412].
Response-PDUを受信すると、受信側のSNMPエンティティは、同じリクエストID値でリクエストを生成したアプリケーションにその内容を提示します。詳細については、[RFC3412]を参照してください。
A SetRequest-PDU is generated and transmitted at the request of an application.
SetRequest-PDUは、アプリケーションの要求で生成および送信されます。
Upon receipt of a SetRequest-PDU, the receiving SNMP entity determines the size of a message encapsulating a Response-PDU having the same values in its request-id and variable-bindings fields as the received SetRequest-PDU, and the largest possible sizes of the error-status and error-index fields. If the determined message size is greater than either a local constraint or the maximum message size of the originator, 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 originator, it is transmitted to the originator of the SetRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded. Regardless, processing of the SetRequest-PDU terminates.
SetRequest-PDUを受信すると、受信側のSNMPエンティティは、リクエストIDフィールドと変数バインディングフィールドに受信したSetRequest-PDUと同じ値を持つ最大サイズのResponse-PDUをカプセル化するメッセージのサイズを決定します。エラーステータスとエラーインデックスフィールド。決定されたメッセージサイズがローカル制約または発信者の最大メッセージサイズより大きい場合、代替のResponse-PDUが生成され、SetRequest-PDUの発信者に送信されます。その後、SetRequest-PDUの処理はすぐに終了します。 。この代替Response-PDUは、リクエストされたSetRequest-PDUと同じrequest-idフィールドの値でフォーマットされ、error-statusフィールドの値は "tooBig"に設定され、error-indexフィールドの値はゼロに設定されます。 、および空の変数バインディングフィールド。次に、この代替Response-PDUがメッセージにカプセル化されます。結果のメッセージのサイズがローカル制約と発信者の最大メッセージサイズの両方以下の場合、SetRequest-PDUの発信者に送信されます。それ以外の場合、snmpSilentDrops [RFC3418]カウンターが増分され、結果のメッセージは破棄されます。いずれにしても、SetRequest-PDUの処理は終了します。
Otherwise, the receiving SNMP 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.
それ以外の場合、受信SNMPエンティティは、変数バインディングリスト内の各変数バインディングを処理して、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 these conceptual phases as multiple implementation phases. Indeed, such multiple implementation phases may be necessary in some cases to ensure consistency.
変数バインディングは、概念的には2フェーズ操作として処理されます。最初のフェーズでは、各変数バインディングが検証されます。すべての検証が成功した場合、各変数は第2フェーズで変更されます。もちろん、実装者は、これらの概念的なフェーズの最初または2番目、あるいは両方を複数の実装フェーズとして自由に実装できます。実際、一貫性を確保するために、このような複数の実装フェーズが必要な場合があります。
The following validations are performed in the first phase on each variable binding until they are all successful, or until one fails:
次の検証は、すべてが成功するか、いずれかが失敗するまで、各変数バインディングの最初のフェーズで実行されます。
(1) If the variable binding's name specifies an existing or non-existent variable to which this request is/would be denied access because it is/would not be in the appropriate MIB view, 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）変数バインディングの名前が、この要求が適切なMIBビューにある/ないためにアクセスが拒否される/されない既存または存在しない変数を指定している場合、Response-PDUのエラーステータスの値フィールドは "noAccess"に設定され、そのerror-indexフィールドの値は、失敗した変数バインディングのインデックスに設定されます。
(2) Otherwise, if there are no variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, and which are able to be created or 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.
（2）それ以外の場合、変数バインディングの名前と同じOBJECT IDENTIFIERプレフィックスを共有し、どの新しい値が指定されても作成または変更できる変数がない場合、Response-PDUのエラーの値statusフィールドは "notWritable"に設定され、そのerror-indexフィールドの値は失敗した変数バインディングのインデックスに設定されます。
(3) Otherwise, if the variable binding's value field specifies, according to the ASN.1 language, a type which is inconsistent with that required for all variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, 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.
（3）それ以外の場合、ASN.1言語に従って、変数バインディングの値フィールドに、変数バインディングの名前と同じOBJECT IDENTIFIERプレフィックスを共有するすべての変数に必要なタイプと一致しないタイプが指定されている場合、 Response-PDUのエラーステータスフィールドは「wrongType」に設定され、そのエラーインデックスフィールドの値は、失敗した変数バインディングのインデックスに設定されます。
(4) Otherwise, if the variable binding's value field specifies, according to the ASN.1 language, a length which is inconsistent with that required for all variables which share the same OBJECT IDENTIFIER prefix as the variable binding's name, 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.
（4）それ以外の場合、ASN.1言語に従って、変数バインディングの値フィールドに、変数バインディングの名前と同じOBJECT IDENTIFIER接頭辞を共有するすべての変数に必要な長さと一致しない長さが指定されている場合、 Response-PDUのerror-statusフィールドは「wrongLength」に設定され、そのerror-indexフィールドの値は、失敗した変数バインディングのインデックスに設定されます。
(5) 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. (Note that not all implementation strategies will generate this error.)
（5）それ以外の場合、変数バインディングの値フィールドに、そのフィールドのASN.1タグと一致しないASN.1エンコーディングが含まれている場合、Response-PDUのエラーステータスフィールドの値は「wrongEncoding」に設定され、値error-indexフィールドのは、失敗した変数バインディングのインデックスに設定されます。 （すべての実装戦略がこのエラーを生成するわけではないことに注意してください。）
(6) 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 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.
（6）それ以外の場合、変数バインディングの値フィールドに、どのような状況でも変数に割り当てることができない値が指定されている場合、Response-PDUのerror-statusフィールドの値は「wrongValue」に設定され、そのエラーの値-indexフィールドは、失敗した変数バインディングのインデックスに設定されます。
(7) Otherwise, if the variable binding's name specifies a variable which does not exist and could not ever be created (even though some variables sharing the same OBJECT IDENTIFIER prefix might under some circumstances be able to 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.
（7）それ以外の場合、変数バインディングの名前が存在せず、作成できなかった変数を指定する場合（たとえ同じOBJECT IDENTIFIER接頭辞を共有する一部の変数を作成できる場合でも）の値Response-PDUのエラーステータスフィールドは「noCreation」に設定され、そのエラーインデックスフィールドの値は、失敗した変数バインディングのインデックスに設定されます。
(8) Otherwise, if the variable binding's name specifies a variable which does not exist but can not be created 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"に設定され、そのerror-indexフィールドの値は、失敗した変数バインディングのインデックスに設定されます。
(9) 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.
（9）それ以外の場合、変数バインディングの名前が存在するが、どの新しい値が指定されても変更できない変数を指定する場合、Response-PDUのエラーステータスフィールドの値は「notWritable」に設定され、値error-indexフィールドのは、失敗した変数バインディングのインデックスに設定されます。
(10) Otherwise, if the variable binding's value field specifies a value that could under other circumstances be held by the variable, but is presently inconsistent or otherwise unable to be assigned to the variable, 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.
（10）それ以外の場合、変数バインディングの値フィールドが、他の状況下では変数によって保持される可能性がある値を指定しているが、現時点では不整合であるか、さもなければ変数に割り当てることができない場合、Response-PDUのエラーステータスの値フィールドは "inconsistentValue"に設定され、そのerror-indexフィールドの値は、失敗した変数バインディングのインデックスに設定されます。
(11) When, during the above steps, 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.
（11）上記のステップ中に、変数バインディングの値フィールドで指定された値を指定された変数に割り当てるときに、現在利用できないリソースの割り当てが必要な場合、Response-PDUのエラーステータスフィールドの値は「resourceUnavailable」に設定され、そのerror-indexフィールドの値は、失敗した変数バインディングのインデックスに設定されます。
(12) 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.
（12）上記以外の理由で変数バインディングの処理が失敗した場合、Response-PDUのerror-statusフィールドの値は「genErr」に設定され、error-indexフィールドの値は失敗した変数バインディングのインデックス。
(13) Otherwise, the validation of the variable binding succeeds.
（13）それ以外の場合、変数バインディングの検証は成功します。
At the end of the first phase, if the validation of all variable bindings succeeded, then the value of the Response-PDU's error-status field is set to "noError" and the value of its error-index field is zero, and processing continues as follows.
最初のフェーズの終わりに、すべての変数バインディングの検証が成功した場合、Response-PDUのerror-statusフィールドの値は「noError」に設定され、そのerror-indexフィールドの値はゼロであり、処理は続行されます次のように。
For each variable binding in the request, the named variable is created if necessary, and the specified value is assigned 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.
要求内の各変数バインディングについて、必要に応じて名前付き変数が作成され、指定された値がそれに割り当てられます。これらの変数の割り当てはそれぞれ、同じリクエストで指定された他のすべての割り当てに関して同時に発生するかのように発生します。ただし、1つのリクエストで同じ変数が複数の名前で関連付けられた値が異なる場合、その変数に行われる実際の割り当ては実装固有です。
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が変更されて、そのerror-statusフィールドの値が「commitFailed」に設定され、その値が失敗した変数バインディングのインデックスに設定されたerror-indexフィールド。
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が変更され、error-statusフィールドの値が「undoFailed」に設定され、error-indexフィールドの値がゼロに設定されます。 。実装では、「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の発信者に送信されます。
An SNMPv2-Trap-PDU is generated and transmitted by an SNMP entity on behalf of a notification originator application. The SNMPv2-Trap-PDU is often used to notify a notification receiver application at a logically remote SNMP entity that an event has occurred or that a condition is present. There is no confirmation associated with this notification delivery mechanism.
SNMPv2-Trap-PDUは、通知元のアプリケーションに代わってSNMPエンティティによって生成および送信されます。 SNMPv2-Trap-PDUは、イベントが発生したこと、または状態が存在することを論理的にリモートのSNMPエンティティで通知受信アプリケーションに通知するためによく使用されます。この通知配信メカニズムに関連付けられている確認はありません。
The destination(s) to which an SNMPv2-Trap-PDU is sent is determined in an implementation-dependent fashion by the SNMP entity. The first two variable bindings in the variable binding list of an SNMPv2- Trap-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] 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. If any additional variables are being included (at the option of the generating SNMP entity), then each is copied to the variable-bindings field.
SNMPv2-Trap-PDUの送信先は、SNMPエンティティによって実装依存の方法で決定されます。 SNMPv2- Trap-PDUの変数バインディングリストの最初の2つの変数バインディングは、それぞれsysUpTime.0 [RFC3418]およびsnmpTrapOID.0 [RFC3418]です。対応するNOTIFICATION-TYPEマクロの呼び出しにOBJECTS句が存在する場合、この通知によってインスタンス化された対応する各変数が、順番に変数バインディングフィールドにコピーされます。追加の変数が（生成されるSNMPエンティティーのオプションで）含まれている場合、変数はそれぞれ変数バインディングフィールドにコピーされます。
An InformRequest-PDU is generated and transmitted by an SNMP entity on behalf of a notification originator application. The InformRequest-PDU is often used to notify a notification receiver application that an event has occurred or that a condition is present. This is a confirmed notification delivery mechanism, although there is, of course, no guarantee of delivery.
InformRequest-PDUは、通知元のアプリケーションに代わってSNMPエンティティによって生成および送信されます。 InformRequest-PDUは、イベントが発生したこと、または状態が存在することを通知受信アプリケーションに通知するためによく使用されます。これは確認済みの通知配信メカニズムですが、配信の保証はありません。
The destination(s) to which an InformRequest-PDU is sent is specified by the notification originator application. The first two variable bindings in the variable binding list of an InformRequest-PDU are sysUpTime.0 [RFC3418] and snmpTrapOID.0 [RFC3418] 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. If any additional variables are being included (at the option of the generating SNMP entity), then each is copied to the variable-bindings field.
InformRequest-PDUの送信先は、通知元のアプリケーションによって指定されます。 InformRequest-PDUの変数バインディングリストの最初の2つの変数バインディングは、それぞれsysUpTime.0 [RFC3418]とsnmpTrapOID.0 [RFC3418]です。対応するNOTIFICATION-TYPEマクロの呼び出しにOBJECTS句が存在する場合、この通知によってインスタンス化された対応する各変数が、順番に変数バインディングフィールドにコピーされます。追加の変数が（生成されるSNMPエンティティーのオプションで）含まれている場合、変数はそれぞれ変数バインディングフィールドにコピーされます。
Upon receipt of an InformRequest-PDU, the receiving SNMP 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 originator, 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 originator, it is transmitted to the originator of the InformRequest-PDU. Otherwise, the snmpSilentDrops [RFC3418] counter is incremented and the resultant message is discarded. Regardless, processing of the InformRequest-PDU terminates.
InformRequest-PDUを受信すると、受信SNMPエンティティは、要求ID、エラーステータス、エラーインデックス、および変数バインディングフィールドに、受信したInformRequest-と同じ値を持つResponse-PDUをカプセル化するメッセージのサイズを決定します。 PDU。決定されたメッセージサイズがローカル制約または発信者の最大メッセージサイズより大きい場合、代替のResponse-PDUが生成され、InformRequest-PDUの発信者に送信され、InformRequest-PDUの処理はその後すぐに終了します。 。この代替Response-PDUは、リクエストされたInformRequest-PDUと同じリクエストIDフィールドの値でフォーマットされ、エラーステータスフィールドの値は「tooBig」に設定され、エラーインデックスフィールドの値はゼロに設定されます。 、および空の変数バインディングフィールド。次に、この代替Response-PDUがメッセージにカプセル化されます。結果のメッセージのサイズがローカル制約と発信者の最大メッセージサイズの両方以下の場合、InformRequest-PDUの発信者に送信されます。それ以外の場合、snmpSilentDrops [RFC3418]カウンターが増分され、結果のメッセージは破棄されます。いずれにしても、InformRequest-PDUの処理は終了します。
Otherwise, the receiving SNMP entity:
それ以外の場合、受信SNMPエンティティ：
(1) presents its contents to the appropriate application;
（1）その内容を適切なアプリケーションに提示する。
(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 set to "noError" and the value of its error-index field set to zero; and
（2）リクエストIDおよび変数バインディングフィールドの値が、受信したInformRequest-PDUと同じ値であるResponse-PDUを生成し、そのエラーステータスフィールドの値を「noError」に設定し、そのエラー値を-インデックスフィールドはゼロに設定されます。そして
(3) transmits the generated Response-PDU to the originator of the InformRequest-PDU.
（3）生成されたResponse-PDUをInformRequest-PDUの発信者に送信します。
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 Executive Directorに情報を送信してください。
This document is the product of the SNMPv3 Working Group. Some special thanks are in order to the following Working Group members:
このドキュメントは、SNMPv3ワーキンググループの製品です。以下のワーキンググループのメンバーに感謝します。
Randy Bush Jeffrey D. Case Mike Daniele Rob Frye Lauren Heintz Keith McCloghrie Russ Mundy David T. Perkins Randy Presuhn Aleksey Romanov Juergen Schoenwaelder Bert Wijnen
ランディブッシュジェフリーD.ケースマイクダニエレロブフライローレンハインツキースマックロリーラスマンディデビッドT.パーキンスランディプレスーンアレクセイロマノフユルゲンシェーンヴェルダーバートウィイネン
This version of the document, edited by Randy Presuhn, was initially based on the work of a design team whose members were:
このバージョンのドキュメントは、Randy Presuhnによって編集され、当初は次のメンバーがいる設計チームの作業に基づいていました。
Jeffrey D. Case Keith McCloghrie David T. Perkins Randy Presuhn Juergen Schoenwaelder
Jeffrey D. Case Keith McCloghrie David T. Perkins Randy Presuhn Juergen Schoenwaelder
The previous versions of this document, edited by Keith McCloghrie, was the result of significant work by four major contributors:
このドキュメントの以前のバージョンは、Keith McCloghrieによって編集され、4人の主要な貢献者による重要な作業の結果でした。
Jeffrey D. Case Keith McCloghrie Marshall T. Rose Steven Waldbusser
Jeffrey D. Case Keith McCloghrie Marshall T. Rose Steven Waldbusser
Additionally, the contributions of the SNMPv2 Working Group to the previous versions are also acknowledged. In particular, a special thanks is extended for the contributions of:
さらに、以前のバージョンに対するSNMPv2ワーキンググループの貢献も認められています。特に、以下の貢献に感謝します。
Alexander I. Alten Dave Arneson Uri Blumenthal Doug Book Kim Curran Jim Galvin Maria Greene Iain Hanson Dave Harrington Nguyen Hien Jeff Johnson Michael Kornegay Deirdre Kostick David Levi Daniel Mahoney Bob Natale Brian O'Keefe Andrew Pearson Dave Perkins Randy Presuhn Aleksey Romanov Shawn Routhier Jon Saperia Juergen Schoenwaelder Bob Stewart Kaj Tesink Glenn Waters Bert Wijnen
アレクサンダーI.アルテンデイブアーネソンウリブルーメンタールダグブックキムカランジムギャルビンマリアグリーンイアンハンソンデイブハリントングエンヒエンジェフジョンソンマイケルコーンゲイディアドラコスティックデビッドレヴィダニエルマホニーボブナターレブライアンオキーフアンドリューピアソンデイブパーキンスランディプレスーンルプヒアシェイプアレクセイシェイクユルゲンシェーンヴェルダーボブスチュワートカイテシンクグレンウォーターズバートウィネン
The protocol defined in this document by itself does not provide a secure environment. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed access to management information.
このドキュメントで定義されているプロトコル自体は、安全な環境を提供しません。ネットワーク自体が（たとえばIPSecを使用して）安全であっても、安全なネットワーク上の誰が管理情報へのアクセスを許可されるかは制御できません。
It is recommended that the implementors consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model STD 62, RFC 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended.
実装者は、SNMPv3フレームワークによって提供されるセキュリティ機能を検討することをお勧めします。具体的には、ユーザーベースのセキュリティモデルSTD 62、RFC 3414 [RFC3414]、およびビューベースのアクセス制御モデルSTD 62、RFC 3415 [RFC3415]の使用をお勧めします。
It is then a customer/user responsibility to ensure that the SNMP entity is properly configured so that:
次に、SNMPエンティティが次のように正しく構成されていることを確認するのは、顧客/ユーザーの責任です。
- only those principals (users) having legitimate rights can access or modify the values of any MIB objects supported by that entity;
- 正当な権限を持つプリンシパル（ユーザー）のみが、そのエンティティでサポートされているMIBオブジェクトの値にアクセスまたは変更できます。
- the occurrence of particular events on the entity will be communicated appropriately;
- エンティティでの特定のイベントの発生は適切に通知されます。
- the entity responds appropriately and with due credence to events and information that have been communicated to it.
- エンティティは、通信されたイベントや情報に適切かつ適切に対応します。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[RFC768] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[RFC2578] 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.
[RFC2578] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M. and S. Waldbusser、 "Structure of Management Information Version 2（SMIv2）"、STD 58、RFC 2578、 1999年4月。
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M. and S. Waldbusser、 "Textual Conventions for SMIv2"、STD 58、RFC 2579、April 1999。
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580] McCloghrie、K.、Perkins、D.、Schoenwaelder、J.、Case、J.、Rose、M. and S. Waldbusser、 "Conformance Statements for SMIv2"、STD 58、RFC 2580、April 1999。
[RFC3411] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411] Harrington、D.、Presuhn、R。、およびB. Wijnen、「An Simple Architecture for Describing Simple Network Management Protocol（SNMP）Management Frameworks」、STD 62、RFC 3411、2002年12月。
[RFC3412] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3412, December 2002.
[RFC3412] Case、J.、Harrington、D.、Presuhn、R。、およびB. Wijnen、「メッセージ処理および簡易ネットワーク管理プロトコル（SNMP）のディスパッチ」、STD 62、RFC 3412、2002年12月。
[RFC3413] Levi, D., Meyer, P. and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002.
[RFC3413] Levi、D.、Meyer、P。およびB. Stewart、「Simple Network Management Protocol（SNMP）Applications」、STD 62、RFC 3413、2002年12月。
[RFC3414] Blumenthal, U. and B. Wijnen, "The User-Based Security Model (USM) for Version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
[RFC3414] Blumenthal、U。およびB. Wijnen、「簡易ネットワーク管理プロトコル（SNMPv3）バージョン3のユーザーベースのセキュリティモデル（USM）」、STD 62、RFC 3414、2002年12月。
[RFC3415] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002.
[RFC3415] Wijnen、B.、Presuhn、R。、およびK. McCloghrie、「簡易ネットワーク管理プロトコル（SNMP）のビューベースアクセスコントロールモデル（VACM）」、STD 62、RFC 3415、2002年12月。
[RFC3417] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for the Simple Network Management Protocol", STD 62, RFC 3417, December 2002.
[RFC3417] Presuhn、R.、Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Transport Mappings for the Simple Network Management Protocol」、STD 62、RFC 3417、2002年12月。
[RFC3418] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3418, December 2002.
[RFC3418] Presuhn、R.、Case、J.、McCloghrie、K.、Rose、M. and S. Waldbusser、 "Management Information Base（MIB）for the Simple Network Management Protocol（SNMP）"、STD 62、RFC 3418 、2002年12月。
[ASN1] Information processing systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1), International Organization for Standardization. International Standard 8824, December 1987.
[ASN1]情報処理システム-オープンシステム相互接続-抽象構文記法1（ASN.1）の仕様、国際標準化機構。国際規格8824、1987年12月。
[FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful," Proceedings, ACM SIGCOMM '87, Stowe, VT, August 1987.
[FRAG]ケントC.およびJ.モーグル、「フラグメンテーションは有害と見なされます」、Proceedings、ACM SIGCOMM '87、Stowe、VT、1987年8月。
[RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990.
[RFC1155] Rose、M。、およびK. McCloghrie、「構造およびTCP / IPベースのインターネットの管理情報の識別」、STD 16、RFC 1155、1990年5月。
[RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1157] Case、J.、Fedor、M.、Schoffstall、M。およびJ. Davin、「Simple Network Management Protocol」、STD 15、RFC 1157、1990年5月。
[RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991.
[RFC1212] Rose、M。、およびK. McCloghrie、「簡潔なMIB定義」、STD 16、RFC 1212、1991年3月。
[RFC1213] McCloghrie, K. and M. Rose, Editors, "Management Information Base for Network Management of TCP/IP-based internets: MIB-II", STD 17, RFC 1213, March 1991.
[RFC1213] McCloghrie、K。およびM. Rose、編集者、「TCP / IPベースのインターネットのネットワーク管理のための管理情報ベース：MIB-II」、STD 17、RFC 1213、1991年3月。
[RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991.
[RFC1215] Rose、M。、「SNMPで使用するトラップを定義するための規約」、RFC 1215、1991年3月。
[RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC1901] Case、J.、McCloghrie、K.、Rose、M。、およびS. Waldbusser、「Introduction to Community-based SNMPv2」、RFC 1901、1996年1月。
[RFC2576] Frye, R., Levi, D., Routhier, S. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-Standard Network Management Framework", RFC 2576, March 2000.
[RFC2576] Frye、R.、Levi、D.、Routhier、S。、およびB. Wijnen、「インターネット標準ネットワーク管理フレームワークのバージョン1、バージョン2、およびバージョン3の共存」、RFC 2576、2000年3月。
[RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[RFC2863] McCloghrie、K。およびF. Kastenholz、「The Interfaces Group MIB」、RFC 2863、2000年6月。
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.
[RFC2914]フロイド、S。、「輻輳制御原則」、BCP 41、RFC 2914、2000年9月。
[RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction and Applicability Statements for Internet-Standard Management Framework", RFC 3410, December 2002.
[RFC3410] Case、J.、Mundy、R.、Partain、D. and B. Stewart、 "Introduction and Applicability Statements for Internet-Standard Management Framework"、RFC 3410、December 2002。
These are the changes from RFC 1905:
RFC 1905からの変更点は次のとおりです。
- Corrected spelling error in copyright statement;
- 著作権ステートメントのスペルミスを修正。
- Updated copyright date;
- 著作権更新日;
- Updated with new editor's name and contact information;
- 新しい編集者の名前と連絡先情報で更新されました。
- Added notice on intellectual property;
- 知的財産に関する通知を追加。
- Cosmetic fixes to layout and typography;
- レイアウトとタイポグラフィの美容上の修正。
- Added table of contents;
- 目次を追加しました。
- Title changed;
- タイトルが変更されました。
- Updated document headers and footers;
- ドキュメントのヘッダーとフッターを更新しました。
- Deleted the old clause 2.3, entitled "Access to Management Information";
- 「管理情報へのアクセス」というタイトルの古い条項2.3を削除しました。
- Changed the way in which request-id was defined, though with the same ultimate syntax and semantics, to avoid coupling with SMI. This does not affect the protocol in any way;
- SMIとの結合を回避するために、最終的な構文とセマンティクスは同じですが、request-idの定義方法を変更しました。これはプロトコルに影響を与えません。
- Replaced the word "exception" with the word "error" in the old clause 4.1. This does not affect the protocol in any way;
- 古い4.1節で「例外」という単語を「エラー」という単語に置き換えました。これはプロトコルに影響を与えません。
- Deleted the first two paragraphs of the old clause 4.2;
- 古い条項4.2の最初の2つの段落を削除しました。
- Clarified the maximum number of variable bindings that an implementation must support in a PDU. This does not affect the protocol in any way;
- 実装がPDUでサポートする必要がある変数バインディングの最大数を明確にしました。これはプロトコルに影響を与えません。
- Replaced occurrences of "SNMPv2 application" with "application";
- 「SNMPv2アプリケーション」の出現箇所を「アプリケーション」に置き換えました。
- Deleted three sentences in old clause 4.2.3 describing the handling of an impossible situation. This does not affect the protocol in any way;
- 不可能な状況の取り扱いを説明する古い条項4.2.3の3つの文を削除しました。これはプロトコルに影響を与えません。
- Clarified the use of the SNMPv2-Trap-Pdu in the old clause 4.2.6. This does not affect the protocol in any way;
- 古い節4.2.6でのSNMPv2-Trap-Pduの使用を明確にしました。これはプロトコルに影響を与えません。
- Aligned description of the use of the InformRequest-Pdu in old clause 4.2.7 with the architecture. This does not affect the protocol in any way;
- 古い節4.2.7でのInformRequest-Pduの使用に関する説明をアーキテクチャーに合わせました。これはプロトコルに影響を与えません。
- Updated references;
- 参照を更新しました。
- Re-wrote introduction clause;
- 導入条項を書き直しました。
- Replaced manager/agent/SNMPv2 entity terminology with terminology from RFC 2571. This does not affect the protocol in any way;
- manager / agent / SNMPv2エンティティの用語をRFC 2571の用語に置き換えました。これはプロトコルに影響を与えません。
- Eliminated IMPORTS from the SMI, replaced with equivalent in-line ASN.1. This does not affect the protocol in any way;
- SMIからIMPORTSが削除され、同等のインラインASN.1に置き換えられました。これはプロトコルに影響を与えません。
- Added notes calling attention to two different manifestations of reaching the end of a table in the table walk examples;
- テーブルウォークの例で、テーブルの最後に到達する2つの異なる症状に注意を喚起するメモを追加しました。
- Added content to security considerations clause;
- セキュリティに関する考慮事項の条項にコンテンツを追加しました。
- Updated ASN.1 comment on use of Report-PDU. This does not affect the protocol in any way;
- Report-PDUの使用に関するASN.1コメントを更新しました。これはプロトコルに影響を与えません。
- Updated acknowledgments section;
- 謝辞のセクションを更新しました。
- Included information on handling of BITS;
- BITSの取り扱いに関する情報が含まれています。
- Deleted spurious comma in ASN.1 definition of PDUs;
- PDUのASN.1定義の誤ったコンマを削除しました。
- Added abstract;
- 要約を追加。
- Made handling of additional variable bindings in informs consistent with that for traps. This was a correction of an editorial oversight, and reflects implementation practice;
- インフォームでの追加の変数バインディングの処理を、トラップのそれと一致させました。これは編集上の見落としの修正であり、実装の実践を反映しています。
- Added reference to RFC 2914.
- RFC 2914への参照を追加しました。
Randy Presuhn BMC Software, Inc. 2141 North First Street San Jose, CA 95131 USA
Randy Presuhn BMC Software、Inc. 2141 North First Street San Jose、CA 95131 USA
Phone: +1 408 546 1006
EMail: randy_presuhn@bmc.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（C）The Internet Society（2002）。全著作権所有。
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 Editor機能への資金提供は、現在Internet Societyから提供されています。