Network Working Group D. Harrington
Request for Comments: 2571 Cabletron Systems, Inc.
Obsoletes: 2271 R. Presuhn
Category: Standards Track BMC Software, Inc.
B. Wijnen
IBM T. J. Watson Research
April 1999
Network Working Group D. Harrington
Request for Comments: 2571 Cabletron Systems, Inc.
Obsoletes: 2271 R. Presuhn
Category: Standards Track BMC Software, Inc.
B. Wijnen
IBM T. J. Watson Research
April 1999
An Architecture for Describing SNMP Management Frameworks
描述SNMP管理框架的体系结构
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 (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This document describes an architecture for describing SNMP Management Frameworks. The architecture is designed to be modular to allow the evolution of the SNMP protocol standards over time. The major portions of the architecture are an SNMP engine containing a Message Processing Subsystem, a Security Subsystem and an Access Control Subsystem, and possibly multiple SNMP applications which provide specific functional processing of management data.
本文档描述了用于描述SNMP管理框架的体系结构。该体系结构设计为模块化，以允许SNMP协议标准随着时间的推移而演变。该体系结构的主要部分是包含消息处理子系统、安全子系统和访问控制子系统的SNMP引擎，以及可能提供管理数据特定功能处理的多个SNMP应用程序。
Table of Contents
目录
1. Introduction ................................................ 4
1.1. Overview .................................................. 4
1.2. SNMP ...................................................... 4
1.3. Goals of this Architecture ................................ 5
1.4. Security Requirements of this Architecture ................ 6
1.5. Design Decisions .......................................... 7
2. Documentation Overview ...................................... 9
2.1. Document Roadmap .......................................... 10
2.2. Applicability Statement ................................... 10
2.3. Coexistence and Transition ................................ 10
2.4. Transport Mappings ........................................ 11
2.5. Message Processing ........................................ 11
1. Introduction ................................................ 4
1.1. Overview .................................................. 4
1.2. SNMP ...................................................... 4
1.3. Goals of this Architecture ................................ 5
1.4. Security Requirements of this Architecture ................ 6
1.5. Design Decisions .......................................... 7
2. Documentation Overview ...................................... 9
2.1. Document Roadmap .......................................... 10
2.2. Applicability Statement ................................... 10
2.3. Coexistence and Transition ................................ 10
2.4. Transport Mappings ........................................ 11
2.5. Message Processing ........................................ 11
2.6. Security .................................................. 11
2.7. Access Control ............................................ 12
2.8. Protocol Operations ....................................... 12
2.9. Applications .............................................. 13
2.10. Structure of Management Information ...................... 14
2.11. Textual Conventions ...................................... 14
2.12. Conformance Statements ................................... 14
2.13. Management Information Base Modules ...................... 14
2.13.1. SNMP Instrumentation MIBs .............................. 14
2.14. SNMP Framework Documents ................................. 14
3. Elements of the Architecture ................................ 15
3.1. The Naming of Entities .................................... 16
3.1.1. SNMP engine ............................................. 17
3.1.1.1. snmpEngineID .......................................... 17
3.1.1.2. Dispatcher ............................................ 17
3.1.1.3. Message Processing Subsystem .......................... 18
3.1.1.3.1. Message Processing Model ............................ 18
3.1.1.4. Security Subsystem .................................... 18
3.1.1.4.1. Security Model ...................................... 19
3.1.1.4.2. Security Protocol ................................... 19
3.1.2. Access Control Subsystem ................................ 19
3.1.2.1. Access Control Model .................................. 20
3.1.3. Applications ............................................ 20
3.1.3.1. SNMP Manager .......................................... 20
3.1.3.2. SNMP Agent ............................................ 22
3.2. The Naming of Identities .................................. 23
3.2.1. Principal ............................................... 23
3.2.2. securityName ............................................ 23
3.2.3. Model-dependent security ID ............................. 24
3.3. The Naming of Management Information ...................... 25
3.3.1. An SNMP Context ......................................... 26
3.3.2. contextEngineID ......................................... 26
3.3.3. contextName ............................................. 27
3.3.4. scopedPDU ............................................... 27
3.4. Other Constructs .......................................... 27
3.4.1. maxSizeResponseScopedPDU ................................ 27
3.4.2. Local Configuration Datastore ........................... 27
3.4.3. securityLevel ........................................... 27
4. Abstract Service Interfaces ................................. 28
4.1. Dispatcher Primitives ..................................... 28
4.1.1. Generate Outgoing Request or Notification ............... 28
4.1.2. Process Incoming Request or Notification PDU ............ 29
4.1.3. Generate Outgoing Response .............................. 29
4.1.4. Process Incoming Response PDU ........................... 29
4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 30
4.2. Message Processing Subsystem Primitives ................... 30
4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 31
4.2.2. Prepare an Outgoing SNMP Response Message ............... 31
2.6. Security .................................................. 11
2.7. Access Control ............................................ 12
2.8. Protocol Operations ....................................... 12
2.9. Applications .............................................. 13
2.10. Structure of Management Information ...................... 14
2.11. Textual Conventions ...................................... 14
2.12. Conformance Statements ................................... 14
2.13. Management Information Base Modules ...................... 14
2.13.1. SNMP Instrumentation MIBs .............................. 14
2.14. SNMP Framework Documents ................................. 14
3. Elements of the Architecture ................................ 15
3.1. The Naming of Entities .................................... 16
3.1.1. SNMP engine ............................................. 17
3.1.1.1. snmpEngineID .......................................... 17
3.1.1.2. Dispatcher ............................................ 17
3.1.1.3. Message Processing Subsystem .......................... 18
3.1.1.3.1. Message Processing Model ............................ 18
3.1.1.4. Security Subsystem .................................... 18
3.1.1.4.1. Security Model ...................................... 19
3.1.1.4.2. Security Protocol ................................... 19
3.1.2. Access Control Subsystem ................................ 19
3.1.2.1. Access Control Model .................................. 20
3.1.3. Applications ............................................ 20
3.1.3.1. SNMP Manager .......................................... 20
3.1.3.2. SNMP Agent ............................................ 22
3.2. The Naming of Identities .................................. 23
3.2.1. Principal ............................................... 23
3.2.2. securityName ............................................ 23
3.2.3. Model-dependent security ID ............................. 24
3.3. The Naming of Management Information ...................... 25
3.3.1. An SNMP Context ......................................... 26
3.3.2. contextEngineID ......................................... 26
3.3.3. contextName ............................................. 27
3.3.4. scopedPDU ............................................... 27
3.4. Other Constructs .......................................... 27
3.4.1. maxSizeResponseScopedPDU ................................ 27
3.4.2. Local Configuration Datastore ........................... 27
3.4.3. securityLevel ........................................... 27
4. Abstract Service Interfaces ................................. 28
4.1. Dispatcher Primitives ..................................... 28
4.1.1. Generate Outgoing Request or Notification ............... 28
4.1.2. Process Incoming Request or Notification PDU ............ 29
4.1.3. Generate Outgoing Response .............................. 29
4.1.4. Process Incoming Response PDU ........................... 29
4.1.5. Registering Responsibility for Handling SNMP PDUs ....... 30
4.2. Message Processing Subsystem Primitives ................... 30
4.2.1. Prepare Outgoing SNMP Request or Notification Message ... 31
4.2.2. Prepare an Outgoing SNMP Response Message ............... 31
4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 32
4.3. Access Control Subsystem Primitives ....................... 32
4.4. Security Subsystem Primitives ............................. 33
4.4.1. Generate a Request or Notification Message .............. 33
4.4.2. Process Incoming Message ................................ 33
4.4.3. Generate a Response Message ............................. 34
4.5. Common Primitives ......................................... 34
4.5.1. Release State Reference Information ..................... 35
4.6. Scenario Diagrams ......................................... 36
4.6.1. Command Generator or Notification Originator ............ 36
4.6.2. Scenario Diagram for a Command Responder Application .... 37
5. Managed Object Definitions for SNMP Management Frameworks ... 38
6. IANA Considerations ......................................... 48
6.1. Security Models ........................................... 48
6.2. Message Processing Models ................................. 48
6.3. SnmpEngineID Formats ...................................... 49
7. Intellectual Property ....................................... 49
8. Acknowledgements ............................................ 49
9. Security Considerations ..................................... 51
10. References ................................................. 52
11. Editor's Addresses ......................................... 54
A. Guidelines for Model Designers .............................. 55
A.1. Security Model Design Requirements ........................ 55
A.1.1. Threats ................................................. 55
A.1.2. Security Processing ..................................... 56
A.1.3. Validate the security-stamp in a received message ....... 56
A.1.4. Security MIBs ........................................... 57
A.1.5. Cached Security Data .................................... 57
A.2. Message Processing Model Design Requirements .............. 57
A.2.1. Receiving an SNMP Message from the Network .............. 58
A.2.2. Sending an SNMP Message to the Network .................. 58
A.3. Application Design Requirements ........................... 59
A.3.1. Applications that Initiate Messages ..................... 59
A.3.2. Applications that Receive Responses ..................... 59
A.3.3. Applications that Receive Asynchronous Messages ......... 60
A.3.4. Applications that Send Responses ........................ 60
A.4. Access Control Model Design Requirements .................. 60
B. Full Copyright Statement .................................... 62
4.2.3. Prepare Data Elements from an Incoming SNMP Message ..... 32
4.3. Access Control Subsystem Primitives ....................... 32
4.4. Security Subsystem Primitives ............................. 33
4.4.1. Generate a Request or Notification Message .............. 33
4.4.2. Process Incoming Message ................................ 33
4.4.3. Generate a Response Message ............................. 34
4.5. Common Primitives ......................................... 34
4.5.1. Release State Reference Information ..................... 35
4.6. Scenario Diagrams ......................................... 36
4.6.1. Command Generator or Notification Originator ............ 36
4.6.2. Scenario Diagram for a Command Responder Application .... 37
5. Managed Object Definitions for SNMP Management Frameworks ... 38
6. IANA Considerations ......................................... 48
6.1. Security Models ........................................... 48
6.2. Message Processing Models ................................. 48
6.3. SnmpEngineID Formats ...................................... 49
7. Intellectual Property ....................................... 49
8. Acknowledgements ............................................ 49
9. Security Considerations ..................................... 51
10. References ................................................. 52
11. Editor's Addresses ......................................... 54
A. Guidelines for Model Designers .............................. 55
A.1. Security Model Design Requirements ........................ 55
A.1.1. Threats ................................................. 55
A.1.2. Security Processing ..................................... 56
A.1.3. Validate the security-stamp in a received message ....... 56
A.1.4. Security MIBs ........................................... 57
A.1.5. Cached Security Data .................................... 57
A.2. Message Processing Model Design Requirements .............. 57
A.2.1. Receiving an SNMP Message from the Network .............. 58
A.2.2. Sending an SNMP Message to the Network .................. 58
A.3. Application Design Requirements ........................... 59
A.3.1. Applications that Initiate Messages ..................... 59
A.3.2. Applications that Receive Responses ..................... 59
A.3.3. Applications that Receive Asynchronous Messages ......... 60
A.3.4. Applications that Send Responses ........................ 60
A.4. Access Control Model Design Requirements .................. 60
B. Full Copyright Statement .................................... 62
This document defines a vocabulary for describing SNMP Management Frameworks, and an architecture for describing the major portions of SNMP Management Frameworks.
本文档定义了用于描述SNMP管理框架的词汇表，以及用于描述SNMP管理框架主要部分的体系结构。
This document does not provide a general introduction to SNMP. Other documents and books can provide a much better introduction to SNMP. Nor does this document provide a history of SNMP. That also can be found in books and other documents.
本文档不提供SNMP的一般介绍。其他文档和书籍可以更好地介绍SNMP。本文档也没有提供SNMP的历史记录。这也可以在书籍和其他文件中找到。
Section 1 describes the purpose, goals, and design decisions of this architecture.
第1节描述了此体系结构的目的、目标和设计决策。
Section 2 describes various types of documents which define (elements of) SNMP Frameworks, and how they fit into this architecture. It also provides a minimal road map to the documents which have previously defined SNMP frameworks.
第2节描述了定义SNMP框架（元素）的各种类型的文档，以及它们如何适应此体系结构。它还为以前定义过SNMP框架的文档提供了一个最低限度的路线图。
Section 3 details the vocabulary of this architecture and its pieces. This section is important for understanding the remaining sections, and for understanding documents which are written to fit within this architecture.
第3节详细介绍了该体系结构及其各个部分的词汇。本节对于理解其余部分以及理解为适应此体系结构而编写的文档非常重要。
Section 4 describes the primitives used for the abstract service interfaces between the various subsystems, models and applications within this architecture.
第4节描述了用于此体系结构中各种子系统、模型和应用程序之间的抽象服务接口的原语。
Section 5 defines a collection of managed objects used to instrument SNMP entities within this architecture.
第5节定义了用于在此体系结构中为SNMP实体提供仪表的托管对象的集合。
Sections 6, 7, 8, 9, 10 and 11 are administrative in nature.
第6、7、8、9、10和11条属于行政性质。
Appendix A contains guidelines for designers of Models which are expected to fit within this architecture.
附录A包含适用于该体系结构的模型设计者的指南。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An SNMP management system contains:
SNMP管理系统包含：
- several (potentially many) nodes, each with an SNMP entity containing command responder and notification originator
- 多个（可能是多个）节点，每个节点都有一个包含命令响应者和通知发起人的SNMP实体
applications, which have access to management instrumentation (traditionally called agents);
可以访问管理工具（传统上称为代理）的应用程序；
- at least one SNMP entity containing command generator and/or notification receiver applications (traditionally called a manager) and,
- 至少一个包含命令生成器和/或通知接收器应用程序（传统上称为管理器）的SNMP实体，以及，
- a management protocol, used to convey management information between the SNMP entities.
- 一种管理协议，用于在SNMP实体之间传递管理信息。
SNMP entities executing command generator and notification receiver applications monitor and control managed elements. Managed elements are devices such as hosts, routers, terminal servers, etc., which are monitored and controlled via access to their management information.
执行命令生成器和通知接收器应用程序的SNMP实体监视和控制托管元素。被管理元素是通过访问其管理信息来监视和控制的设备，如主机、路由器、终端服务器等。
It is the purpose of this document to define an architecture which can evolve to realize effective management in a variety of configurations and environments. The architecture has been designed to meet the needs of implementations of:
本文档的目的是定义一个体系结构，该体系结构可以在各种配置和环境中实现有效管理。该体系结构旨在满足以下实现的需要：
- minimal SNMP entities with command responder and/or notification originator applications (traditionally called SNMP agents),
- 具有命令响应程序和/或通知发起人应用程序（传统上称为SNMP代理）的最小SNMP实体，
- SNMP entities with proxy forwarder applications (traditionally called SNMP proxy agents),
- 具有代理转发器应用程序的SNMP实体（传统上称为SNMP代理），
- command line driven SNMP entities with command generator and/or notification receiver applications (traditionally called SNMP command line managers),
- 具有命令生成器和/或通知接收器应用程序（传统上称为SNMP命令行管理器）的命令行驱动的SNMP实体，
- SNMP entities with command generator and/or notification receiver, plus command responder and/or notification originator applications (traditionally called SNMP mid-level managers or dual-role entities),
- 具有命令生成器和/或通知接收器的SNMP实体，以及命令响应者和/或通知发起人应用程序（传统上称为SNMP中级管理器或双角色实体），
- SNMP entities with command generator and/or notification receiver and possibly other types of applications for managing a potentially very large number of managed nodes (traditionally called (network) management stations).
- 具有命令生成器和/或通知接收器的SNMP实体，以及可能用于管理大量受管节点（传统上称为（网络）管理站）的其他类型的应用程序。
This architecture was driven by the following goals:
此体系结构由以下目标驱动：
- Use existing materials as much as possible. It is heavily based on previous work, informally known as SNMPv2u and SNMPv2*, based in turn on SNMPv2p.
- 尽量使用现有材料。它在很大程度上基于以前的工作，非正式地称为SNMPv2u和SNMPv2*，反过来又基于SNMPv2p。
- Address the need for secure SET support, which is considered the most important deficiency in SNMPv1 and SNMPv2c.
- 解决对安全集支持的需求，这被认为是SNMPv1和SNMPv2c中最重要的缺陷。
- Make it possible to move portions of the architecture forward in the standards track, even if consensus has not been reached on all pieces.
- 使架构的一部分在标准轨道上向前移动成为可能，即使尚未就所有部分达成共识。
- Define an architecture that allows for longevity of the SNMP Frameworks that have been and will be defined.
- 定义一个体系结构，该体系结构允许已经定义和将要定义的SNMP框架的使用寿命。
- Keep SNMP as simple as possible.
- 使SNMP尽可能简单。
- Make it relatively inexpensive to deploy a minimal conforming implementation.
- 使部署最小一致性实现的成本相对较低。
- Make it possible to upgrade portions of SNMP as new approaches become available, without disrupting an entire SNMP framework.
- 可以在新方法可用时升级部分SNMP，而不会中断整个SNMP框架。
- Make it possible to support features required in large networks, but make the expense of supporting a feature directly related to the support of the feature.
- 使支持大型网络所需的功能成为可能，但使支持功能的费用与支持该功能直接相关。
Several of the classical threats to network protocols are applicable to the management problem and therefore would be applicable to any Security Model used in an SNMP Management Framework. Other threats are not applicable to the management problem. This section discusses principal threats, secondary threats, and threats which are of lesser importance.
网络协议的几个经典威胁适用于管理问题，因此适用于SNMP管理框架中使用的任何安全模型。其他威胁不适用于管理问题。本节讨论主要威胁、次要威胁和次要威胁。
The principal threats against which any Security Model used within this architecture SHOULD provide protection are:
此体系结构中使用的任何安全模型应提供保护的主要威胁包括：
Modification of Information The modification threat is the danger that some unauthorized entity may alter in-transit SNMP messages generated on behalf of an authorized principal in such a way as to effect unauthorized management operations, including falsifying the value of an object.
修改信息修改威胁是指某些未经授权的实体可能以影响未经授权的管理操作的方式更改代表授权主体生成的传输中SNMP消息的危险，包括伪造对象的值。
Masquerade The masquerade threat is the danger that management operations not authorized for some principal may be attempted by assuming the identity of another principal that has the appropriate authorizations.
伪装伪装威胁是一种危险，即通过假定具有适当授权的另一个主体的身份，可能会尝试对某些主体未授权的管理操作。
Secondary threats against which any Security Model used within this architecture SHOULD provide protection are:
此体系结构中使用的任何安全模型都应提供保护的次要威胁包括：
Message Stream Modification The SNMP protocol is typically based upon a connectionless transport service which may operate over any subnetwork service. The re-ordering, delay or replay of messages can and does occur through the natural operation of many such subnetwork services. The message stream modification threat is the danger that messages may be maliciously re-ordered, delayed or replayed to an extent which is greater than can occur through the natural operation of a subnetwork service, in order to effect unauthorized management operations.
消息流修改SNMP协议通常基于可在任何子网服务上运行的无连接传输服务。消息的重新排序、延迟或重播可以并且确实通过许多这样的子网络服务的自然操作发生。消息流修改威胁是指消息可能被恶意重新排序、延迟或重播到比子网服务的自然运行更大的程度，从而影响未经授权的管理操作的危险。
Disclosure The disclosure threat is the danger of eavesdropping on the exchanges between SNMP engines. Protecting against this threat may be required as a matter of local policy.
泄露泄露威胁是指在SNMP引擎之间的交换上进行窃听的危险。作为当地政策的一项内容，可能需要针对这种威胁进行保护。
There are at least two threats against which a Security Model within this architecture need not protect, since they are deemed to be of lesser importance in this context:
此体系结构中的安全模型不需要保护至少两种威胁，因为在这种情况下，它们被认为不太重要：
Denial of Service A Security Model need not attempt to address the broad range of attacks by which service on behalf of authorized users is denied. Indeed, such denial-of-service attacks are in many cases indistinguishable from the type of network failures with which any viable management protocol must cope as a matter of course.
拒绝服务安全模型不需要尝试解决广泛的攻击，通过这些攻击，代表授权用户的服务被拒绝。事实上，在许多情况下，这种拒绝服务攻击与任何可行的管理协议都必须处理的网络故障类型是无法区分的。
Traffic Analysis A Security Model need not attempt to address traffic analysis attacks. Many traffic patterns are predictable - entities may be managed on a regular basis by a relatively small number of management stations - and therefore there is no significant advantage afforded by protecting against traffic analysis.
流量分析安全模型不需要尝试解决流量分析攻击。许多交通模式是可预测的——实体可以由数量相对较少的管理站定期管理——因此，防止交通分析不会带来显著优势。
Various design decisions were made in support of the goals of the architecture and the security requirements:
为支持架构（architecture）目标和安全需求，做出了各种设计决策：
- Architecture An architecture should be defined which identifies the conceptual boundaries between the documents. Subsystems should be defined which describe the abstract services provided by specific portions of an SNMP framework. Abstract service
- 架构（Architecture）应定义一个架构（Architecture），该架构确定了文档之间的概念边界。应定义子系统，这些子系统描述SNMP框架特定部分提供的抽象服务。抽象服务
interfaces, as described by service primitives, define the abstract boundaries between documents, and the abstract services that are provided by the conceptual subsystems of an SNMP framework.
由服务原语描述的接口定义了文档之间的抽象边界，以及SNMP框架的概念子系统提供的抽象服务。
- Self-contained Documents Elements of procedure plus the MIB objects which are needed for processing for a specific portion of an SNMP framework should be defined in the same document, and as much as possible, should not be referenced in other documents. This allows pieces to be designed and documented as independent and self-contained parts, which is consistent with the general SNMP MIB module approach. As portions of SNMP change over time, the documents describing other portions of SNMP are not directly impacted. This modularity allows, for example, Security Models, authentication and privacy mechanisms, and message formats to be upgraded and supplemented as the need arises. The self-contained documents can move along the standards track on different time-lines.
- 应在同一文档中定义过程的自包含文档元素以及处理SNMP框架特定部分所需的MIB对象，并且尽可能不在其他文档中引用。这允许将各个部分设计为独立的、自包含的部分，这与一般的SNMP MIB模块方法一致。随着时间的推移，SNMP的某些部分会发生变化，描述SNMP其他部分的文档不会受到直接影响。例如，这种模块化允许根据需要升级和补充安全模型、身份验证和隐私机制以及消息格式。自包含的文档可以在不同的时间线上沿着标准轨道移动。
This modularity of specification is not meant to be interpreted as imposing any specific requirements on implementation.
规范的模块化并不意味着对实现强加任何特定的要求。
- Threats The Security Models in the Security Subsystem SHOULD protect against the principal and secondary threats: modification of information, masquerade, message stream modification and disclosure. They do not need to protect against denial of service and traffic analysis.
- 威胁安全子系统中的安全模型应防止主要和次要威胁：信息修改、伪装、消息流修改和泄露。它们不需要针对拒绝服务和流量分析进行保护。
- Remote Configuration The Security and Access Control Subsystems add a whole new set of SNMP configuration parameters. The Security Subsystem also requires frequent changes of secrets at the various SNMP entities. To make this deployable in a large operational environment, these SNMP parameters must be remotely configurable.
- 远程配置安全和访问控制子系统添加了一组全新的SNMP配置参数。安全子系统还需要频繁更改各个SNMP实体的机密。为了使其能够在大型操作环境中部署，这些SNMP参数必须可以远程配置。
- Controlled Complexity It is recognized that producers of simple managed devices want to keep the resources used by SNMP to a minimum. At the same time, there is a need for more complex configurations which can spend more resources for SNMP and thus provide more functionality. The design tries to keep the competing requirements of these two environments in balance and allows the more complex environments to logically extend the simple environment.
- 控制复杂性人们认识到，简单受管设备的生产者希望将SNMP使用的资源保持在最低限度。同时，还需要更复杂的配置，这些配置可以为SNMP花费更多的资源，从而提供更多的功能。该设计试图平衡这两个环境中相互竞争的需求，并允许更复杂的环境在逻辑上扩展简单的环境。
The following figure shows the set of documents that fit within the
SNMP Architecture.
+------------------------- Document Set ----------------------------+
| |
| +----------+ +-----------------+ +----------------+ |
| | Document | | Applicability * | | Coexistence | |
| | Roadmap | | Statement | | & Transition | |
| +----------+ +-----------------+ +----------------+ |
| |
| +---------------------------------------------------------------+ |
| | Message Handling | |
| | +----------------+ +-----------------+ +-----------------+ | |
| | | Transport | | Message | | Security | | |
| | | Mappings | | Processing and | | | | |
| | | | | Dispatcher | | | | |
| | +----------------+ +-----------------+ +-----------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | PDU Handling | |
| | +----------------+ +-----------------+ +-----------------+ | |
| | | Protocol | | Applications | | Access | | |
| | | Operations | | | | Control | | |
| | +----------------+ +-----------------+ +-----------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | Information Model | |
| | +--------------+ +--------------+ +---------------+ | |
| | | Structure of | | Textual | | Conformance | | |
| | | Management | | Conventions | | Statements | | |
| | | Information | | | | | | |
| | +--------------+ +--------------+ +---------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | MIB Modules written in various formats, e.g.: | |
| | +-------------+ +-------------+ +----------+ +----------+ | |
| | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | |
| | | RFC 1157 | | RFC 1212 | | RFC 14xx | | RFC 19xx | | |
| | | format | | format | | format | | format | | |
| | +-------------+ +-------------+ +----------+ +----------+ | |
| +---------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
The following figure shows the set of documents that fit within the
SNMP Architecture.
+------------------------- Document Set ----------------------------+
| |
| +----------+ +-----------------+ +----------------+ |
| | Document | | Applicability * | | Coexistence | |
| | Roadmap | | Statement | | & Transition | |
| +----------+ +-----------------+ +----------------+ |
| |
| +---------------------------------------------------------------+ |
| | Message Handling | |
| | +----------------+ +-----------------+ +-----------------+ | |
| | | Transport | | Message | | Security | | |
| | | Mappings | | Processing and | | | | |
| | | | | Dispatcher | | | | |
| | +----------------+ +-----------------+ +-----------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | PDU Handling | |
| | +----------------+ +-----------------+ +-----------------+ | |
| | | Protocol | | Applications | | Access | | |
| | | Operations | | | | Control | | |
| | +----------------+ +-----------------+ +-----------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | Information Model | |
| | +--------------+ +--------------+ +---------------+ | |
| | | Structure of | | Textual | | Conformance | | |
| | | Management | | Conventions | | Statements | | |
| | | Information | | | | | | |
| | +--------------+ +--------------+ +---------------+ | |
| +---------------------------------------------------------------+ |
| |
| +---------------------------------------------------------------+ |
| | MIB Modules written in various formats, e.g.: | |
| | +-------------+ +-------------+ +----------+ +----------+ | |
| | | Standard v1 | | Standard v1 | | Historic | | Draft v2 | | |
| | | RFC 1157 | | RFC 1212 | | RFC 14xx | | RFC 19xx | | |
| | | format | | format | | format | | format | | |
| | +-------------+ +-------------+ +----------+ +----------+ | |
| +---------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
Those marked with an asterisk (*) are expected to be written in the future. Each of these documents may be replaced or supplemented. This Architecture document specifically describes how new documents fit into the set of documents in the area of Message and PDU handling.
标有星号（*）的内容预计将在将来写入。这些文件中的每一份都可以替换或补充。本体系结构文档具体描述了在消息和PDU处理方面，新文档如何融入文档集。
One or more documents may be written to describe how sets of documents taken together form specific Frameworks. The configuration of document sets might change over time, so the "road map" should be maintained in a document separate from the standards documents themselves.
可以编写一个或多个文档来描述文档集如何组合在一起形成特定的框架。文档集的配置可能会随着时间的推移而改变，因此“路线图”应该保存在与标准文档本身分离的文档中。
An example of such a roadmap is "Introduction to Version 3 of the Internet-standard Network Management Framework" [RFC2570].
这种路线图的一个例子是“互联网标准网络管理框架第3版简介”[RFC2570]。
SNMP is used in networks that vary widely in size and complexity, by organizations that vary widely in their requirements of management. Some models will be designed to address specific problems of management, such as message security.
SNMP用于大小和复杂度差异很大的网络中，由管理要求差异很大的组织使用。一些模型将被设计用于解决特定的管理问题，例如消息安全性。
One or more documents may be written to describe the environments to which certain versions of SNMP or models within SNMP would be appropriately applied, and those to which a given model might be inappropriately applied.
可以编写一个或多个文档来描述将适当应用某些版本的SNMP或SNMP中的模型的环境，以及可能不适当地应用给定模型的环境。
The purpose of an evolutionary architecture is to permit new models to replace or supplement existing models. The interactions between models could result in incompatibilities, security "holes", and other undesirable effects.
演化体系结构的目的是允许新模型替换或补充现有模型。模型之间的交互可能会导致不兼容、安全“漏洞”和其他不良影响。
The purpose of Coexistence documents is to detail recognized anomalies and to describe required and recommended behaviors for resolving the interactions between models within the architecture.
共存文档的目的是详细说明已识别的异常，并描述解决体系结构中模型之间交互所需的和推荐的行为。
Coexistence documents may be prepared separately from model definition documents, to describe and resolve interaction anomalies between a model definition and one or more other model definitions.
共存文件可与模型定义文件分开编制，以描述和解决模型定义与一个或多个其他模型定义之间的交互异常。
Additionally, recommendations for transitions between models may also be described, either in a coexistence document or in a separate document.
此外，还可以在共存文档或单独的文档中描述模型之间转换的建议。
One such coexistance document is [SNMP-COEX], "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework".
一个这样的共存文件是[SNMP-COEX]，“互联网标准网络管理框架的第1版、第2版和第3版之间的共存”。
SNMP messages are sent over various transports. It is the purpose of Transport Mapping documents to define how the mapping between SNMP and the transport is done.
SNMP消息通过各种传输发送。传输映射文档的目的是定义SNMP和传输之间的映射是如何完成的。
A Message Processing Model document defines a message format, which is typically identified by a version field in an SNMP message header. The document may also define a MIB module for use in message processing and for instrumentation of version-specific interactions.
消息处理模型文档定义消息格式，该格式通常由SNMP消息头中的版本字段标识。该文档还可以定义一个MIB模块，用于消息处理和版本特定交互的检测。
An SNMP engine includes one or more Message Processing Models, and thus may support sending and receiving multiple versions of SNMP messages.
SNMP引擎包括一个或多个消息处理模型，因此可以支持发送和接收多个版本的SNMP消息。
Some environments require secure protocol interactions. Security is normally applied at two different stages:
某些环境需要安全的协议交互。通常在两个不同阶段应用安全性：
- in the transmission/receipt of messages, and
- 在发送/接收信息时，以及
- in the processing of the contents of messages.
- 在信息内容的处理过程中。
For purposes of this document, "security" refers to message-level security; "access control" refers to the security applied to protocol operations.
在本文件中，“安全性”是指消息级安全性；“访问控制”是指应用于协议操作的安全性。
Authentication, encryption, and timeliness checking are common functions of message level security.
身份验证、加密和及时性检查是消息级安全的常见功能。
A security document describes a Security Model, the threats against which the model protects, the goals of the Security Model, the protocols which it uses to meet those goals, and it may define a MIB module to describe the data used during processing, and to allow the remote configuration of message-level security parameters, such as keys.
安全文档描述安全模型、模型保护的威胁、安全模型的目标、用于实现这些目标的协议，并且可以定义MIB模块来描述处理期间使用的数据，并允许远程配置消息级安全参数，如密钥。
An SNMP engine may support multiple Security Models concurrently.
SNMP引擎可以同时支持多个安全模型。
During processing, it may be required to control access to managed objects for operations.
在处理过程中，可能需要控制对托管对象的访问以进行操作。
An Access Control Model defines mechanisms to determine whether access to a managed object should be allowed. An Access Control Model may define a MIB module used during processing and to allow the remote configuration of access control policies.
访问控制模型定义了确定是否允许访问托管对象的机制。访问控制模型可以定义在处理期间使用的MIB模块，并允许远程配置访问控制策略。
SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). SNMP PDUs define the operations performed by the receiving SNMP engine. It is the purpose of a Protocol Operations document to define the operations of the protocol with respect to the processing of the PDUs. Every PDU belongs to one or more of the PDU classes defined below:
SNMP消息封装SNMP协议数据单元（PDU）。SNMP PDU定义接收SNMP引擎执行的操作。协议操作文档的目的是定义与PDU处理相关的协议操作。每个PDU都属于以下定义的一个或多个PDU类：
1) Read Class:
1) 阅读课：
The Read Class contains protocol operations that retrieve management information. For example, RFC 1905 defines the following protocol operations for the Read Class: GetRequest-PDU, GetNextRequest-PDU, and GetBulkRequest-PDU.
Read类包含检索管理信息的协议操作。例如，RFC1905为Read类定义了以下协议操作：GetRequestPDU、GetNextRequestPDU和GetBulkRequestPDU。
2) Write Class:
2) 编写类：
The Write Class contains protocol operations which attempt to modify management information. For example, RFC 1905 defines the following protocol operation for the Write Class: SetRequest-PDU.
Write类包含尝试修改管理信息的协议操作。例如，RFC1905为Write类定义了以下协议操作：setRequestPDU。
3) Response Class:
3) 回应类别：
The Response Class contains protocol operations which are sent in response to a previous request. For example, RFC 1905 defines the following for the Response Class: Response-PDU, Report-PDU.
Response类包含为响应以前的请求而发送的协议操作。例如，RFC1905为响应类定义了以下内容：响应PDU、报告PDU。
4) Notification Class:
4) 通知类别：
The Notification Class contains protocol operations which send a notification to a notification receiver application. For example, RFC 1905 defines the following operations for the Notification Class: Trapv2-PDU, InformRequest-PDU.
Notification类包含向通知接收方应用程序发送通知的协议操作。例如，RFC1905为通知类定义了以下操作：Trapv2 PDU、InformRequest PDU。
5) Internal Class:
5) 内部类：
The Internal Class contains protocol operations which are exchanged internally between SNMP engines. For example, RFC 1905 defines the following operations for the Internal Class: Report-PDU.
内部类包含在SNMP引擎之间内部交换的协议操作。例如，RFC1905为内部类定义了以下操作：ReportPDU。
The preceding five classifications are based on the functional properties of a PDU. It is also useful to classify PDUs based on whether a response is expected:
前五种分类基于PDU的功能特性。根据是否预期响应对PDU进行分类也很有用：
6) Confirmed Class:
6) 确认课程：
The Confirmed Class contains all protocol operations which cause the receiving SNMP engine to send back a response. For example, RFC 1905 defines the following operations for the Confirmed Class: GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU, and InformRequest-PDU.
确认类包含导致接收SNMP引擎发回响应的所有协议操作。例如，RFC1905为确认类定义了以下操作：GetRequest PDU、GetNextRequest PDU、GetBulkRequest PDU、SetRequest PDU和InformRequest PDU。
7) Unconfirmed Class:
7) 未确认类别：
The Unconfirmed Class contains all protocol operations which are not acknowledged. For example, RFC 1905 defines the following operations for the Unconfirmed Class: Report-PDU, Trapv2-PDU, and GetResponse-PDU.
未确认类包含所有未确认的协议操作。例如，RFC1905为未确认类定义了以下操作：Report PDU、Trapv2 PDU和GetResponse PDU。
An application document defines which Protocol Operations are supported by the application.
应用程序文档定义应用程序支持哪些协议操作。
An SNMP entity normally includes a number of applications. Applications use the services of an SNMP engine to accomplish specific tasks. They coordinate the processing of management information operations, and may use SNMP messages to communicate with other SNMP entities.
SNMP实体通常包括多个应用程序。应用程序使用SNMP引擎的服务来完成特定任务。它们协调管理信息操作的处理，并可能使用SNMP消息与其他SNMP实体通信。
Applications documents describe the purpose of an application, the services required of the associated SNMP engine, and the protocol operations and informational model that the application uses to perform management operations.
应用程序文档描述应用程序的用途、相关SNMP引擎所需的服务以及应用程序用于执行管理操作的协议操作和信息模型。
An application document defines which set of documents are used to specifically define the structure of management information, textual conventions, conformance requirements, and operations supported by the application.
应用程序文档定义了用于具体定义管理信息结构、文本约定、一致性要求和应用程序支持的操作的一组文档。
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.
管理信息被视为托管对象的集合，驻留在虚拟信息存储中，称为管理信息库（MIB）。相关对象的集合在MIB模块中定义。
It is the purpose of a Structure of Management Information document to establish the notation for defining objects, modules, and other elements of managed information.
管理信息文档结构的目的是建立用于定义管理信息的对象、模块和其他元素的符号。
When designing a MIB module, it is often useful to define new types similar to those defined in the SMI, but with more precise semantics, or which have special semantics associated with them. These newly defined types are termed textual conventions, and may be defined in separate documents, or within a MIB module.
在设计MIB模块时，定义与SMI中定义的类型类似的新类型通常很有用，但具有更精确的语义，或者具有与之相关联的特殊语义。这些新定义的类型称为文本约定，可以在单独的文档中定义，也可以在MIB模块中定义。
It may be useful to define the acceptable lower-bounds of implementation, along with the actual level of implementation achieved. It is the purpose of the Conformance Statements document to define the notation used for these purposes.
定义可接受的实现下限以及实现的实际实现水平可能很有用。一致性声明文件的目的是定义用于这些目的的符号。
MIB documents describe collections of managed objects which instrument some aspect of a managed node.
MIB文档描述托管对象的集合，这些对象为托管节点的某些方面提供工具。
An SNMP MIB document may define a collection of managed objects which instrument the SNMP protocol itself. In addition, MIB modules may be defined within the documents which describe portions of the SNMP architecture, such as the documents for Message processing Models, Security Models, etc. for the purpose of instrumenting those Models, and for the purpose of allowing remote configuration of the Model.
SNMP MIB文档可以定义管理对象的集合，这些对象为SNMP协议本身提供工具。此外，MIB模块可以在描述SNMP体系结构的部分的文档中定义，例如用于消息处理模型、安全模型等的文档，以便对这些模型进行检测，并允许对模型进行远程配置。
This architecture is designed to allow an orderly evolution of portions of SNMP Frameworks.
该体系结构设计为允许SNMP框架各部分的有序演进。
Throughout the rest of this document, the term "subsystem" refers to an abstract and incomplete specification of a portion of a Framework, that is further refined by a model specification.
在本文档的其余部分，术语“子系统”指的是框架部分的抽象且不完整的规范，该规范通过模型规范进一步细化。
A "model" describes a specific design of a subsystem, defining additional constraints and rules for conformance to the model. A model is sufficiently detailed to make it possible to implement the specification.
“模型”描述子系统的特定设计，定义与模型一致的附加约束和规则。模型足够详细，可以实现规范。
An "implementation" is an instantiation of a subsystem, conforming to one or more specific models.
“实现”是子系统的实例化，符合一个或多个特定模型。
SNMP version 1 (SNMPv1), is the original Internet-standard Network Management Framework, as described in RFCs 1155, 1157, and 1212.
SNMP版本1（SNMPv1）是最初的Internet标准网络管理框架，如RFCs 1155、1157和1212所述。
SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from the SNMPv1 Framework. It is described in STD 58, RFCs 2578, 2579, 2580, and RFCs 1905-1907. SNMPv2 has no message definition.
SNMP版本2（SNMPv2）是从SNMPv1框架派生的SNMPv2框架。STD 58、RFCs 2578、2579、2580和RFCs 1905-1907中对其进行了描述。SNMPv2没有消息定义。
The Community-based SNMP version 2 (SNMPv2c), is an experimental SNMP Framework which supplements the SNMPv2 Framework, as described in RFC 1901. It adds the SNMPv2c message format, which is similar to the SNMPv1 message format.
基于社区的SNMP版本2（SNMPv2c）是一个实验性的SNMP框架，它补充了SNMPv2框架，如RFC1901所述。它添加了SNMPv2c消息格式，与SNMPv1消息格式类似。
SNMP version 3 (SNMPv3), is an extensible SNMP Framework which supplements the SNMPv2 Framework, by supporting the following:
SNMP版本3（SNMPv3）是一个可扩展的SNMP框架，它通过支持以下内容来补充SNMPv2框架：
- a new SNMP message format,
- 一种新的SNMP消息格式，
- Security for Messages,
- 消息的安全性，
- Access Control, and
- 访问控制，以及
- Remote configuration of SNMP parameters.
- SNMP参数的远程配置。
Other SNMP Frameworks, i.e., other configurations of implemented subsystems, are expected to also be consistent with this architecture.
其他SNMP框架，即已实现子系统的其他配置，也应与此体系结构保持一致。
This section describes the various elements of the architecture and how they are named. There are three kinds of naming:
本节描述了体系结构的各种元素及其命名方式。有三种命名方式：
1) the naming of entities,
1) 实体的命名，
2) the naming of identities, and
2) 身份的命名，以及
3) the naming of management information.
3) 管理信息的命名。
This architecture also defines some names for other constructs that are used in the documentation.
该体系结构还为文档中使用的其他构造定义了一些名称。
An SNMP entity is an implementation of this architecture. Each such SNMP entity consists of an SNMP engine and one or more associated applications.
SNMP实体是此体系结构的实现。每个这样的SNMP实体由一个SNMP引擎和一个或多个相关应用程序组成。
The following figure shows details about an SNMP entity and the components within it.
下图显示了有关SNMP实体及其组件的详细信息。
+-------------------------------------------------------------------+
| SNMP entity |
| |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | | | | | | | | | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
+-------------------------------------------------------------------+
| SNMP entity |
| |
| +-------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | | | | | | | | | | |
| | +------------+ +------------+ +-----------+ +-----------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
| +-------------------------------------------------------------+ |
| | Application(s) | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Proxy | | |
| | | Generator | | Receiver | | Forwarder | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | Command | | Notification | | Other | | |
| | | Responder | | Originator | | | | |
| | +-------------+ +--------------+ +--------------+ | |
| | | |
| +-------------------------------------------------------------+ |
| |
+-------------------------------------------------------------------+
An SNMP engine provides services for sending and receiving messages, authenticating and encrypting messages, and controlling access to managed objects. There is a one-to-one association between an SNMP engine and the SNMP entity which contains it.
SNMP引擎提供用于发送和接收消息、验证和加密消息以及控制对托管对象的访问的服务。SNMP引擎和包含它的SNMP实体之间存在一对一的关联。
The engine contains:
发动机包括：
1) a Dispatcher,
1) 调度员，
2) a Message Processing Subsystem,
2) 消息处理子系统，
3) a Security Subsystem, and
3) 安全子系统，以及
4) an Access Control Subsystem.
4) 访问控制子系统。
Within an administrative domain, an snmpEngineID is the unique and unambiguous identifier of an SNMP engine. Since there is a one-to-one association between SNMP engines and SNMP entities, it also uniquely and unambiguously identifies the SNMP entity within that administrative domain. Note that it is possible for SNMP entities in different administrative domains to have the same value for snmpEngineID. Federation of administrative domains may necessitate assignment of new values.
在管理域中，snmpEngineID是SNMP引擎的唯一且明确的标识符。由于SNMP引擎和SNMP实体之间存在一对一的关联，因此它还可以唯一且明确地标识该管理域中的SNMP实体。请注意，不同管理域中的SNMP实体可能具有相同的snmpEngineID值。管理域的联合可能需要分配新的值。
There is only one Dispatcher in an SNMP engine. It allows for concurrent support of multiple versions of SNMP messages in the SNMP engine. It does so by:
SNMP引擎中只有一个调度程序。它允许在SNMP引擎中同时支持多个版本的SNMP消息。它通过以下方式做到这一点：
- sending and receiving SNMP messages to/from the network,
- 向网络发送SNMP消息或从网络接收SNMP消息，
- determining the version of an SNMP message and interacting with the corresponding Message Processing Model,
- 确定SNMP消息的版本并与相应的消息处理模型交互，
- providing an abstract interface to SNMP applications for delivery of a PDU to an application.
- 为SNMP应用程序提供抽象接口，以便将PDU交付给应用程序。
- providing an abstract interface for SNMP applications that allows them to send a PDU to a remote SNMP entity.
- 为SNMP应用程序提供抽象接口，允许它们向远程SNMP实体发送PDU。
The Message Processing Subsystem is responsible for preparing messages for sending, and extracting data from received messages.
消息处理子系统负责准备用于发送的消息，并从接收到的消息中提取数据。
The Message Processing Subsystem potentially contains multiple Message Processing Models as shown in the next figure.
消息处理子系统可能包含多个消息处理模型，如下图所示。
* One or more Message Processing Models may be present.
* 可能存在一个或多个消息处理模型。
+------------------------------------------------------------------+
| |
| Message Processing Subsystem |
| |
| +------------+ +------------+ +------------+ +------------+ |
| | * | | * | | * | | * | |
| | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | |
| | Message | | Message | | Message | | Message | |
| | Processing | | Processing | | Processing | | Processing | |
| | Model | | Model | | Model | | Model | |
| | | | | | | | | |
| +------------+ +------------+ +------------+ +------------+ |
| |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| |
| Message Processing Subsystem |
| |
| +------------+ +------------+ +------------+ +------------+ |
| | * | | * | | * | | * | |
| | SNMPv3 | | SNMPv1 | | SNMPv2c | | Other | |
| | Message | | Message | | Message | | Message | |
| | Processing | | Processing | | Processing | | Processing | |
| | Model | | Model | | Model | | Model | |
| | | | | | | | | |
| +------------+ +------------+ +------------+ +------------+ |
| |
+------------------------------------------------------------------+
Each Message Processing Model defines the format of a particular version of an SNMP message and coordinates the preparation and extraction of each such version-specific message format.
每个消息处理模型定义SNMP消息的特定版本的格式，并协调每个特定版本消息格式的准备和提取。
The Security Subsystem provides security services such as the authentication and privacy of messages and potentially contains multiple Security Models as shown in the following figure
安全子系统提供安全服务，如消息的身份验证和隐私，并可能包含多个安全模型，如下图所示
* One or more Security Models may be present.
* 可能存在一个或多个安全模型。
+------------------------------------------------------------------+
| |
| Security Subsystem |
| |
| +----------------+ +-----------------+ +-------------------+ |
| | * | | * | | * | |
| | User-Based | | Other | | Other | |
| | Security | | Security | | Security | |
| | Model | | Model | | Model | |
| | | | | | | |
| +----------------+ +-----------------+ +-------------------+ |
| |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| |
| Security Subsystem |
| |
| +----------------+ +-----------------+ +-------------------+ |
| | * | | * | | * | |
| | User-Based | | Other | | Other | |
| | Security | | Security | | Security | |
| | Model | | Model | | Model | |
| | | | | | | |
| +----------------+ +-----------------+ +-------------------+ |
| |
+------------------------------------------------------------------+
A Security Model specifies the threats against which it protects, the goals of its services, and the security protocols used to provide security services such as authentication and privacy.
安全模型指定了它所保护的威胁、服务的目标以及用于提供安全服务（如身份验证和隐私）的安全协议。
A Security Protocol specifies the mechanisms, procedures, and MIB objects used to provide a security service such as authentication or privacy.
安全协议指定用于提供身份验证或隐私等安全服务的机制、过程和MIB对象。
The Access Control Subsystem provides authorization services by means of one or more (*) Access Control Models.
访问控制子系统通过一个或多个（*）访问控制模型提供授权服务。
+------------------------------------------------------------------+
| |
| Access Control Subsystem |
| |
| +---------------+ +-----------------+ +------------------+ |
| | * | | * | | * | |
| | View-Based | | Other | | Other | |
| | Access | | Access | | Access | |
| | Control | | Control | | Control | |
| | Model | | Model | | Model | |
| | | | | | | |
| +---------------+ +-----------------+ +------------------+ |
| |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| |
| Access Control Subsystem |
| |
| +---------------+ +-----------------+ +------------------+ |
| | * | | * | | * | |
| | View-Based | | Other | | Other | |
| | Access | | Access | | Access | |
| | Control | | Control | | Control | |
| | Model | | Model | | Model | |
| | | | | | | |
| +---------------+ +-----------------+ +------------------+ |
| |
+------------------------------------------------------------------+
An Access Control Model defines a particular access decision function in order to support decisions regarding access rights.
访问控制模型定义了一个特定的访问决策函数，以支持有关访问权限的决策。
There are several types of applications, including:
有几种类型的应用程序，包括：
- command generators, which monitor and manipulate management data,
- 命令生成器，用于监视和操作管理数据，
- command responders, which provide access to management data,
- 命令响应器，提供对管理数据的访问，
- notification originators, which initiate asynchronous messages,
- 发起异步消息的通知发起人，
- notification receivers, which process asynchronous messages, and
- 处理异步消息的通知接收器，以及
- proxy forwarders, which forward messages between entities.
- 代理转发器，在实体之间转发消息。
These applications make use of the services provided by the SNMP engine.
这些应用程序利用SNMP引擎提供的服务。
An SNMP entity containing one or more command generator and/or notification receiver applications (along with their associated SNMP engine) has traditionally been called an SNMP manager.
包含一个或多个命令生成器和/或通知接收器应用程序（及其关联的SNMP引擎）的SNMP实体传统上称为SNMP管理器。
* One or more models may be present.
* 可能存在一个或多个模型。
(traditional SNMP manager)
+-------------------------------------------------------------------+
| +--------------+ +--------------+ +--------------+ SNMP entity |
| | NOTIFICATION | | NOTIFICATION | | COMMAND | |
| | ORIGINATOR | | RECEIVER | | GENERATOR | |
| | applications | | applications | | applications | |
| +--------------+ +--------------+ +--------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------+--------+-----------------+ |
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | |
| | | | | +------------+ | | | Other | | |
| | | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->+ | | | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | Transport | | | +------------+ | | | Security | | |
| | Mapping | | | +------------+ | | | Model | | |
| | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +----------------+ |
| | |
| v |
+-------------------------------------------------------------------+
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+
^ ^ ^
| | |
v v v
+------------------------------+
| Network |
+------------------------------+
(traditional SNMP manager)
+-------------------------------------------------------------------+
| +--------------+ +--------------+ +--------------+ SNMP entity |
| | NOTIFICATION | | NOTIFICATION | | COMMAND | |
| | ORIGINATOR | | RECEIVER | | GENERATOR | |
| | applications | | applications | | applications | |
| +--------------+ +--------------+ +--------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------+--------+-----------------+ |
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | PDU Dispatcher | | +->| v1MP * |<--->| +------------+ | |
| | | | | +------------+ | | | Other | | |
| | | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->+ | | | |
| | | | | +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | Transport | | | +------------+ | | | Security | | |
| | Mapping | | | +------------+ | | | Model | | |
| | (e.g RFC1906) | | +->| otherMP * |<--->| +------------+ | |
| +-------------------+ | +------------+ | | | |
| ^ +---------------------+ +----------------+ |
| | |
| v |
+-------------------------------------------------------------------+
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+
^ ^ ^
| | |
v v v
+------------------------------+
| Network |
+------------------------------+
An SNMP entity containing one or more command responder and/or
notification originator applications (along with their associated
SNMP engine) has traditionally been called an SNMP agent.
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+ (traditional SNMP agent)
+-------------------------------------------------------------------+
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | Transport | | +->| v1MP * |<--->| +------------+ | |
| | Mapping | | | +------------+ | | | Other | | |
| | (e.g. RFC1906) | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->| +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | | | | +------------+ | | | Security | | |
| | PDU Dispatcher | | | +------------+ | | | Model | | |
| +-------------------+ | +->| otherMP * |<--->| +------------+ | |
| ^ | +------------+ | | | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | application | | | | applications | | application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
An SNMP entity containing one or more command responder and/or
notification originator applications (along with their associated
SNMP engine) has traditionally been called an SNMP agent.
+------------------------------+
| Network |
+------------------------------+
^ ^ ^
| | |
v v v
+-----+ +-----+ +-------+
| UDP | | IPX | . . . | other |
+-----+ +-----+ +-------+ (traditional SNMP agent)
+-------------------------------------------------------------------+
| ^ |
| | +---------------------+ +----------------+ |
| | | Message Processing | | Security | |
| Dispatcher v | Subsystem | | Subsystem | |
| +-------------------+ | +------------+ | | | |
| | Transport | | +->| v1MP * |<--->| +------------+ | |
| | Mapping | | | +------------+ | | | Other | | |
| | (e.g. RFC1906) | | | +------------+ | | | Security | | |
| | | | +->| v2cMP * |<--->| | Model | | |
| | Message | | | +------------+ | | +------------+ | |
| | Dispatcher <--------->| +------------+ | | +------------+ | |
| | | | +->| v3MP * |<--->| | User-based | | |
| | | | | +------------+ | | | Security | | |
| | PDU Dispatcher | | | +------------+ | | | Model | | |
| +-------------------+ | +->| otherMP * |<--->| +------------+ | |
| ^ | +------------+ | | | |
| | +---------------------+ +----------------+ |
| v |
| +-------+-------------------------+---------------+ |
| ^ ^ ^ |
| | | | |
| v v v |
| +-------------+ +---------+ +--------------+ +-------------+ |
| | COMMAND | | ACCESS | | NOTIFICATION | | PROXY * | |
| | RESPONDER |<->| CONTROL |<->| ORIGINATOR | | FORWARDER | |
| | application | | | | applications | | application | |
| +-------------+ +---------+ +--------------+ +-------------+ |
| ^ ^ |
| | | |
| v v |
| +----------------------------------------------+ |
| | MIB instrumentation | SNMP entity |
+-------------------------------------------------------------------+
principal
^
|
|
+----------------------------|-------------+
| SNMP engine v |
| +--------------+ |
| | | |
| +-----------------| securityName |---+ |
| | Security Model | | | |
| | +--------------+ | |
| | ^ | |
| | | | |
| | v | |
| | +------------------------------+ | |
| | | | | |
| | | Model | | |
| | | Dependent | | |
| | | Security ID | | |
| | | | | |
| | +------------------------------+ | |
| | ^ | |
| | | | |
| +-------------------------|----------+ |
| | |
| | |
+----------------------------|-------------+
|
v
network
principal
^
|
|
+----------------------------|-------------+
| SNMP engine v |
| +--------------+ |
| | | |
| +-----------------| securityName |---+ |
| | Security Model | | | |
| | +--------------+ | |
| | ^ | |
| | | | |
| | v | |
| | +------------------------------+ | |
| | | | | |
| | | Model | | |
| | | Dependent | | |
| | | Security ID | | |
| | | | | |
| | +------------------------------+ | |
| | ^ | |
| | | | |
| +-------------------------|----------+ |
| | |
| | |
+----------------------------|-------------+
|
v
network
A principal is the "who" on whose behalf services are provided or processing takes place.
委托人是代表其提供服务或进行处理的“谁”。
A principal can be, among other things, an individual acting in a particular role; a set of individuals, with each acting in a particular role; an application or a set of applications; and combinations thereof.
除其他外，委托人可以是扮演特定角色的个人；一组个人，每个人都扮演一个特定的角色；一个或一组应用程序；及其组合。
A securityName is a human readable string representing a principal. It has a model-independent format, and can be used outside a particular Security Model.
securityName是表示主体的可读字符串。它具有独立于模型的格式，可以在特定安全模型之外使用。
A model-dependent security ID is the model-specific representation of a securityName within a particular Security Model.
依赖于模型的安全ID是特定安全模型中securityName的特定于模型的表示形式。
Model-dependent security IDs may or may not be human readable, and have a model-dependent syntax. Examples include community names, and user names.
依赖于模型的安全ID可能是可读的，也可能不是可读的，并且具有依赖于模型的语法。示例包括社区名称和用户名。
The transformation of model-dependent security IDs into securityNames and vice versa is the responsibility of the relevant Security Model.
相关安全模型负责将依赖于模型的安全ID转换为SecurityName，反之亦然。
Management information resides at an SNMP entity where a Command Responder Application has local access to potentially multiple contexts. This application uses a contextEngineID equal to the snmpEngineID of its associated SNMP engine.
管理信息驻留在SNMP实体中，其中命令响应程序应用程序可以本地访问潜在的多个上下文。此应用程序使用的contextEngineID等于其关联SNMP引擎的snmpEngineID。
+-----------------------------------------------------------------+
| SNMP entity (identified by snmpEngineID, example: abcd) |
| |
| +------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +-------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | | | | | | | | | | |
| | +-------------+ +------------+ +-----------+ +-----------+ | |
| | | |
| +------------------------------------------------------------+ |
| |
| +------------------------------------------------------------+ |
| | Command Responder Application | |
| | (contextEngineID, example: abcd) | |
| | | |
| | example contextNames: | |
| | | |
| | "bridge1" "bridge2" "" (default) | |
| | --------- --------- ------------ | |
| | | | | | |
| +------|------------------|-------------------|--------------+ |
| | | | |
| +------|------------------|-------------------|--------------+ |
| | MIB | instrumentation | | | |
| | +---v------------+ +---v------------+ +----v-----------+ | |
| | | context | | context | | context | | |
| | | | | | | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | | | | | | |
| | | | | | | +------------+ | | |
| | | | | | | | other MIB | | | |
| | | | | | | +------------+ | | |
| | | | | | | | | |
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
| SNMP entity (identified by snmpEngineID, example: abcd) |
| |
| +------------------------------------------------------------+ |
| | SNMP engine (identified by snmpEngineID) | |
| | | |
| | +-------------+ +------------+ +-----------+ +-----------+ | |
| | | | | | | | | | | |
| | | Dispatcher | | Message | | Security | | Access | | |
| | | | | Processing | | Subsystem | | Control | | |
| | | | | Subsystem | | | | Subsystem | | |
| | | | | | | | | | | |
| | +-------------+ +------------+ +-----------+ +-----------+ | |
| | | |
| +------------------------------------------------------------+ |
| |
| +------------------------------------------------------------+ |
| | Command Responder Application | |
| | (contextEngineID, example: abcd) | |
| | | |
| | example contextNames: | |
| | | |
| | "bridge1" "bridge2" "" (default) | |
| | --------- --------- ------------ | |
| | | | | | |
| +------|------------------|-------------------|--------------+ |
| | | | |
| +------|------------------|-------------------|--------------+ |
| | MIB | instrumentation | | | |
| | +---v------------+ +---v------------+ +----v-----------+ | |
| | | context | | context | | context | | |
| | | | | | | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | bridge MIB | | | | bridge MIB | | | | some MIB | | | |
| | | +------------+ | | +------------+ | | +------------+ | | |
| | | | | | | | | |
| | | | | | | +------------+ | | |
| | | | | | | | other MIB | | | |
| | | | | | | +------------+ | | |
| | | | | | | | | |
+-----------------------------------------------------------------+
An SNMP context, or just "context" for short, is a collection of management information accessible by an SNMP entity. An item of management information may exist in more than one context. An SNMP entity potentially has access to many contexts.
SNMP上下文，简称“上下文”，是SNMP实体可访问的管理信息的集合。一项管理信息可能存在于多个上下文中。SNMP实体可能可以访问许多上下文。
Typically, there are many instances of each managed object type within a management domain. For simplicity, the method for identifying instances specified by the MIB module does not allow each instance to be distinguished amongst the set of all instances within a management domain; rather, it allows each instance to be identified only within some scope or "context", where there are multiple such contexts within the management domain. Often, a context is a physical device, or perhaps, a logical device, although a context can also encompass multiple devices, or a subset of a single device, or even a subset of multiple devices, but a context is always defined as a subset of a single SNMP entity. Thus, in order to identify an individual item of management information within the management domain, its contextName and contextEngineID must be identified in addition to its object type and its instance.
通常，在一个管理域中，每个托管对象类型都有许多实例。为简单起见，用于识别由MIB模块指定的实例的方法不允许在管理域内的所有实例集合中区分每个实例；相反，它只允许在某个范围或“上下文”中标识每个实例，其中在管理域中有多个这样的上下文。通常，上下文是物理设备，或者可能是逻辑设备，尽管上下文也可以包含多个设备、单个设备的子集、甚至多个设备的子集，但上下文始终定义为单个SNMP实体的子集。因此，为了标识管理域中的单个管理信息项，除了其对象类型和实例之外，还必须标识其contextName和contextEngineID。
For example, the managed object type ifDescr [RFC2233], is defined as the description of a network interface. To identify the description of device-X's first network interface, four pieces of information are needed: the snmpEngineID of the SNMP entity which provides access to the management information at device-X, the contextName (device-X), the managed object type (ifDescr), and the instance ("1").
例如，管理对象类型ifDescr[rfc223]被定义为网络接口的描述。要识别device-X的第一个网络接口的描述，需要四条信息：SNMP实体的snmpEngineID，它提供对device-X上的管理信息的访问、contextName（device-X）、托管对象类型（ifDescr）和实例（“1”）。
Each context has (at least) one unique identification within the management domain. The same item of management information can exist in multiple contexts. An item of management information may have multiple unique identifications. This occurs when an item of management information exists in multiple contexts, and this also occurs when a context has multiple unique identifications.
每个上下文在管理域中都有（至少）一个唯一标识。同一项管理信息可以存在于多个上下文中。一项管理信息可能具有多个唯一标识。当一项管理信息存在于多个上下文中时会发生这种情况，当一个上下文具有多个唯一标识时也会发生这种情况。
The combination of a contextEngineID and a contextName unambiguously identifies a context within an administrative domain; note that there may be multiple unique combinations of contextEngineID and contextName that unambiguously identify the same context.
contextEngineID和contextName的组合明确标识了管理域中的上下文；请注意，contextEngineID和contextName可能有多个唯一的组合，可以明确标识相同的上下文。
Within an administrative domain, a contextEngineID uniquely identifies an SNMP entity that may realize an instance of a context with a particular contextName.
在管理域中，contextEngineID唯一地标识可能实现具有特定contextName的上下文实例的SNMP实体。
A contextName is used to name a context. Each contextName MUST be unique within an SNMP entity.
contextName用于命名上下文。每个contextName在SNMP实体中必须是唯一的。
A scopedPDU is a block of data containing a contextEngineID, a contextName, and a PDU.
scopedPDU是包含contextEngineID、contextName和PDU的数据块。
The PDU is an SNMP Protocol Data Unit containing information named in the context which is unambiguously identified within an administrative domain by the combination of the contextEngineID and the contextName. See, for example, RFC1905 for more information about SNMP PDUs.
PDU是一个SNMP协议数据单元，包含上下文中命名的信息，该信息通过contextEngineID和contextName的组合在管理域中明确标识。如需有关SNMP PDU的更多信息，请参阅RFC1905。
The maxSizeResponseScopedPDU is the maximum size of a scopedPDU that a PDU's sender would be willing to accept. Note that the size of a scopedPDU does not include the size of the SNMP message header.
maxSizeResponseScopedPDU是PDU发送方愿意接受的scopedPDU的最大大小。请注意，scopedPDU的大小不包括SNMP消息头的大小。
The subsystems, models, and applications within an SNMP entity may need to retain their own sets of configuration information.
SNMP实体中的子系统、模型和应用程序可能需要保留自己的配置信息集。
Portions of the configuration information may be accessible as managed objects.
部分配置信息可以作为托管对象访问。
The collection of these sets of information is referred to as an entity's Local Configuration Datastore (LCD).
这些信息集的集合称为实体的本地配置数据存储（LCD）。
This architecture recognizes three levels of security:
此体系结构可识别三个安全级别：
- without authentication and without privacy (noAuthNoPriv)
- 没有身份验证和隐私（noAuthNoPriv）
- with authentication but without privacy (authNoPriv)
- 具有身份验证但不具有隐私（authNoPriv）
- with authentication and with privacy (authPriv)
- 具有身份验证和隐私（authPriv）
These three values are ordered such that noAuthNoPriv is less than authNoPriv and authNoPriv is less than authPriv.
这三个值的顺序是noAuthNoPriv小于authNoPriv，authNoPriv小于authPriv。
Every message has an associated securityLevel. All Subsystems (Message Processing, Security, Access Control) and applications are REQUIRED to either supply a value of securityLevel or to abide by the supplied value of securityLevel while processing the message and its contents.
每个消息都有一个关联的securityLevel。所有子系统（消息处理、安全、访问控制）和应用程序在处理消息及其内容时都需要提供securityLevel值或遵守提供的securityLevel值。
Abstract service interfaces have been defined to describe the conceptual interfaces between the various subsystems within an SNMP entity. The abstract service interfaces are intended to help clarify the externally observable behavior of SNMP entities, and are not intended to constrain the structure or organization of implementations in any way. Most specifically, they should not be interpreted as APIs or as requirements statements for APIs.
抽象服务接口已定义为描述SNMP实体内各子系统之间的概念接口。抽象服务接口旨在帮助澄清SNMP实体的外部可观察行为，而不是以任何方式限制实现的结构或组织。最具体地说，它们不应被解释为API或API的需求声明。
These abstract service interfaces are defined by a set of primitives that define the services provided and the abstract data elements that are to be passed when the services are invoked. This section lists the primitives that have been defined for the various subsystems.
这些抽象服务接口由一组原语定义，这些原语定义所提供的服务以及调用服务时要传递的抽象数据元素。本节列出了为各个子系统定义的原语。
The Dispatcher typically provides services to the SNMP applications via its PDU Dispatcher. This section describes the primitives provided by the PDU Dispatcher.
调度程序通常通过其PDU调度程序向SNMP应用程序提供服务。本节介绍PDU调度程序提供的原语。
The PDU Dispatcher provides the following primitive for an application to send an SNMP Request or Notification to another SNMP entity:
PDU Dispatcher为应用程序提供以下原语，以向另一个SNMP实体发送SNMP请求或通知：
statusInformation = -- sendPduHandle if success
-- errorIndication if failure
sendPdu(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
)
statusInformation = -- sendPduHandle if success
-- errorIndication if failure
sendPdu(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
)
The PDU Dispatcher provides the following primitive to pass an incoming SNMP PDU to an application:
PDU Dispatcher提供以下原语，将传入的SNMP PDU传递给应用程序：
processPdu( -- process Request/Notification PDU
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
IN stateReference -- reference to state information
) -- needed when sending a response
processPdu( -- process Request/Notification PDU
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size of the Response PDU
IN stateReference -- reference to state information
) -- needed when sending a response
The PDU Dispatcher provides the following primitive for an application to return an SNMP Response PDU to the PDU Dispatcher:
PDU调度程序为应用程序提供以下原语，以将SNMP响应PDU返回给PDU调度程序：
result = -- SUCCESS or FAILURE
returnResponsePdu(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size sender can accept
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
) -- error counter OID/value if error
result = -- SUCCESS or FAILURE
returnResponsePdu(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size sender can accept
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
) -- error counter OID/value if error
The PDU Dispatcher provides the following primitive to pass an incoming SNMP Response PDU to an application:
PDU Dispatcher提供以下原语，将传入的SNMP响应PDU传递给应用程序：
processResponsePdu( -- process Response PDU
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN statusInformation -- success or errorIndication
IN sendPduHandle -- handle from sendPdu
)
processResponsePdu( -- process Response PDU
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model in use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN statusInformation -- success or errorIndication
IN sendPduHandle -- handle from sendPdu
)
Applications can register/unregister responsibility for a specific contextEngineID, for specific pduTypes, with the PDU Dispatcher according to the following primitives. The list of particular pduTypes that an application can register for is determined by the Message Processing Model(s) supported by the SNMP entity that contains the PDU Dispatcher.
应用程序可以根据以下原语向PDU Dispatcher注册/注销特定contextEngineID、特定PDUType的责任。应用程序可以注册的特定PDU类型的列表由包含PDU Dispatcher的SNMP实体支持的消息处理模型确定。
statusInformation = -- success or errorIndication
registerContextEngineID(
IN contextEngineID -- take responsibility for this one
IN pduType -- the pduType(s) to be registered
)
statusInformation = -- success or errorIndication
registerContextEngineID(
IN contextEngineID -- take responsibility for this one
IN pduType -- the pduType(s) to be registered
)
unregisterContextEngineID(
IN contextEngineID -- give up responsibility for this one
IN pduType -- the pduType(s) to be unregistered
)
unregisterContextEngineID(
IN contextEngineID -- give up responsibility for this one
IN pduType -- the pduType(s) to be unregistered
)
Note that realizations of the registerContextEngineID and unregisterContextEngineID abstract service interfaces may provide implementation-specific ways for applications to register/deregister responsibility for all possible values of the contextEngineID or pduType parameters.
注意，registerContextEngineID和unregisterContextEngineID抽象服务接口的实现可能为应用程序提供特定于实现的方法，以注册/注销contextEngineID或pduType参数的所有可能值的责任。
The Dispatcher interacts with a Message Processing Model to process a specific version of an SNMP Message. This section describes the primitives provided by the Message Processing Subsystem.
Dispatcher与消息处理模型交互，以处理特定版本的SNMP消息。本节介绍消息处理子系统提供的原语。
The Message Processing Subsystem provides this service primitive for preparing an outgoing SNMP Request or Notification Message:
消息处理子系统提供此服务原语，用于准备传出SNMP请求或通知消息：
statusInformation = -- success or errorIndication
prepareOutgoingMessage(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching
-- incoming responses
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
)
statusInformation = -- success or errorIndication
prepareOutgoingMessage(
IN transportDomain -- transport domain to be used
IN transportAddress -- transport address to be used
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- Security Model to use
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN contextEngineID -- data from/at this entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN expectResponse -- TRUE or FALSE
IN sendPduHandle -- the handle for matching
-- incoming responses
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
)
The Message Processing Subsystem provides this service primitive for preparing an outgoing SNMP Response Message:
消息处理子系统提供此服务原语，用于准备传出SNMP响应消息：
result = -- SUCCESS or FAILURE
prepareResponseMessage(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- same as on incoming request
IN securityName -- same as on incoming request
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size able to accept
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
result = -- SUCCESS or FAILURE
prepareResponseMessage(
IN messageProcessingModel -- typically, SNMP version
IN securityModel -- same as on incoming request
IN securityName -- same as on incoming request
IN securityLevel -- same as on incoming request
IN contextEngineID -- data from/at this SNMP entity
IN contextName -- data from/in this context
IN pduVersion -- the version of the PDU
IN PDU -- SNMP Protocol Data Unit
IN maxSizeResponseScopedPDU -- maximum size able to accept
IN stateReference -- reference to state information
-- as presented with the request
IN statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT destTransportDomain -- destination transport domain
OUT destTransportAddress -- destination transport address
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
)
OUT outgoingMessage -- the message to send
OUT outgoingMessageLength -- its length
)
The Message Processing Subsystem provides this service primitive for preparing the abstract data elements from an incoming SNMP message:
消息处理子系统提供此服务原语，用于从传入的SNMP消息准备抽象数据元素：
result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- the version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for possible Response
)
result = -- SUCCESS or errorIndication
prepareDataElements(
IN transportDomain -- origin transport domain
IN transportAddress -- origin transport address
IN wholeMsg -- as received from the network
IN wholeMsgLength -- as received from the network
OUT messageProcessingModel -- typically, SNMP version
OUT securityModel -- Security Model to use
OUT securityName -- on behalf of this principal
OUT securityLevel -- Level of Security requested
OUT contextEngineID -- data from/at this entity
OUT contextName -- data from/in this context
OUT pduVersion -- the version of the PDU
OUT PDU -- SNMP Protocol Data Unit
OUT pduType -- SNMP PDU type
OUT sendPduHandle -- handle for matched request
OUT maxSizeResponseScopedPDU -- maximum size sender can accept
OUT statusInformation -- success or errorIndication
-- error counter OID/value if error
OUT stateReference -- reference to state information
-- to be used for possible Response
)
Applications are the typical clients of the service(s) of the Access Control Subsystem.
应用程序是访问控制子系统服务的典型客户端。
The following primitive is provided by the Access Control Subsystem to check if access is allowed:
以下原语由访问控制子系统提供，用于检查是否允许访问：
statusInformation = -- success or errorIndication
isAccessAllowed(
IN securityModel -- Security Model in use
IN securityName -- principal who wants to access
IN securityLevel -- Level of Security
IN viewType -- read, write, or notify view
IN contextName -- context containing variableName
IN variableName -- OID for the managed object
)
statusInformation = -- success or errorIndication
isAccessAllowed(
IN securityModel -- Security Model in use
IN securityName -- principal who wants to access
IN securityLevel -- Level of Security
IN viewType -- read, write, or notify view
IN contextName -- context containing variableName
IN variableName -- OID for the managed object
)
The Message Processing Subsystem is the typical client of the services of the Security Subsystem.
消息处理子系统是安全子系统服务的典型客户端。
The Security Subsystem provides the following primitive to generate a Request or Notification message:
安全子系统提供以下原语来生成请求或通知消息：
statusInformation =
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
statusInformation =
generateRequestMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- Level of Security requested
IN scopedPDU -- message (plaintext) payload
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
The Security Subsystem provides the following primitive to process an incoming message:
安全子系统提供以下原语来处理传入消息：
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
OUT securityEngineID -- identification of the principal
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response
statusInformation = -- errorIndication or success
-- error counter OID/value if error
processIncomingMsg(
IN messageProcessingModel -- typically, SNMP version
IN maxMessageSize -- of the sending SNMP entity
IN securityParameters -- for the received message
IN securityModel -- for the received message
IN securityLevel -- Level of Security
IN wholeMsg -- as received on the wire
IN wholeMsgLength -- length as received on the wire
OUT securityEngineID -- identification of the principal
OUT securityName -- identification of the principal
OUT scopedPDU, -- message (plaintext) payload
OUT maxSizeResponseScopedPDU -- maximum size sender can handle
OUT securityStateReference -- reference to security state
) -- information, needed for response
The Security Subsystem provides the following primitive to generate a Response message:
安全子系统提供以下原语以生成响应消息：
statusInformation =
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- for the outgoing message
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
statusInformation =
generateResponseMsg(
IN messageProcessingModel -- typically, SNMP version
IN globalData -- message header, admin data
IN maxMessageSize -- of the sending SNMP entity
IN securityModel -- for the outgoing message
IN securityEngineID -- authoritative SNMP entity
IN securityName -- on behalf of this principal
IN securityLevel -- for the outgoing message
IN scopedPDU -- message (plaintext) payload
IN securityStateReference -- reference to security state
-- information from original request
OUT securityParameters -- filled in by Security Module
OUT wholeMsg -- complete generated message
OUT wholeMsgLength -- length of the generated message
)
These primitive(s) are provided by multiple Subsystems.
这些原语由多个子系统提供。
All Subsystems which pass stateReference information also provide a primitive to release the memory that holds the referenced state information:
传递stateReference信息的所有子系统还提供一个原语来释放保存引用状态信息的内存：
stateRelease( IN stateReference -- handle of reference to be released )
stateRelease（在stateReference中——要释放的引用句柄）
This diagram shows how a Command Generator or Notification Originator application requests that a PDU be sent, and how the response is returned (asynchronously) to that application.
此图显示命令生成器或通知发起者应用程序如何请求发送PDU，以及响应如何（异步）返回给该应用程序。
Command Dispatcher Message Security
Generator | Processing Model
| | Model |
| sendPdu | | |
|------------------->| | |
| | prepareOutgoingMessage | |
: |----------------------->| |
: | | generateRequestMsg |
: | |-------------------->|
: | | |
: | |<--------------------|
: | | |
: |<-----------------------| |
: | | |
: |------------------+ | |
: | Send SNMP | | |
: | Request Message | | |
: | to Network | | |
: | v | |
: : : : :
: : : : :
: : : : :
: | | | |
: | Receive SNMP | | |
: | Response Message | | |
: | from Network | | |
: |<-----------------+ | |
: | | |
: | prepareDataElements | |
: |----------------------->| |
: | | processIncomingMsg |
: | |-------------------->|
: | | |
: | |<--------------------|
: | | |
: |<-----------------------| |
| processResponsePdu | | |
|<-------------------| | |
| | | |
Command Dispatcher Message Security
Generator | Processing Model
| | Model |
| sendPdu | | |
|------------------->| | |
| | prepareOutgoingMessage | |
: |----------------------->| |
: | | generateRequestMsg |
: | |-------------------->|
: | | |
: | |<--------------------|
: | | |
: |<-----------------------| |
: | | |
: |------------------+ | |
: | Send SNMP | | |
: | Request Message | | |
: | to Network | | |
: | v | |
: : : : :
: : : : :
: : : : :
: | | | |
: | Receive SNMP | | |
: | Response Message | | |
: | from Network | | |
: |<-----------------+ | |
: | | |
: | prepareDataElements | |
: |----------------------->| |
: | | processIncomingMsg |
: | |-------------------->|
: | | |
: | |<--------------------|
: | | |
: |<-----------------------| |
| processResponsePdu | | |
|<-------------------| | |
| | | |
This diagram shows how a Command Responder or Notification Receiver application registers for handling a pduType, how a PDU is dispatched to the application after a SNMP message is received, and how the Response is (asynchronously) send back to the network.
此图显示命令响应程序或通知接收器应用程序如何注册以处理pduType，收到SNMP消息后如何将PDU调度到应用程序，以及如何（异步）将响应发送回网络。
Command Dispatcher Message Security
Responder | Processing Model
| | Model |
| | | |
| registerContextEngineID | | |
|------------------------>| | |
|<------------------------| | | |
| | Receive SNMP | | |
: | Message | | |
: | from Network | | |
: |<-------------+ | |
: | | |
: |prepareDataElements | |
: |------------------->| |
: | | processIncomingMsg |
: | |------------------->|
: | | |
: | |<-------------------|
: | | |
: |<-------------------| |
| processPdu | | |
|<------------------------| | |
| | | |
: : : :
: : : :
| returnResponsePdu | | |
|------------------------>| | |
: | prepareResponseMsg | |
: |------------------->| |
: | |generateResponseMsg |
: | |------------------->|
: | | |
: | |<-------------------|
: | | |
: |<-------------------| |
: | | |
: |--------------+ | |
: | Send SNMP | | |
: | Message | | |
: | to Network | | |
: | v | |
Command Dispatcher Message Security
Responder | Processing Model
| | Model |
| | | |
| registerContextEngineID | | |
|------------------------>| | |
|<------------------------| | | |
| | Receive SNMP | | |
: | Message | | |
: | from Network | | |
: |<-------------+ | |
: | | |
: |prepareDataElements | |
: |------------------->| |
: | | processIncomingMsg |
: | |------------------->|
: | | |
: | |<-------------------|
: | | |
: |<-------------------| |
| processPdu | | |
|<------------------------| | |
| | | |
: : : :
: : : :
| returnResponsePdu | | |
|------------------------>| | |
: | prepareResponseMsg | |
: |------------------->| |
: | |generateResponseMsg |
: | |------------------->|
: | | |
: | |<-------------------|
: | | |
: |<-------------------| |
: | | |
: |--------------+ | |
: | Send SNMP | | |
: | Message | | |
: | to Network | | |
: | v | |
SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN
IMPORTS MODULE-IDENTITY, OBJECT-TYPE, OBJECT-IDENTITY, snmpModules FROM SNMPv2-SMI TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF;
从SNMPv2导入模块标识、对象类型、对象标识、SNMPv2 SMI文本约定中的snmpModules，从SNMPv2 CONF导入TC MODULE-COMPLIANCE、对象组；
snmpFrameworkMIB MODULE-IDENTITY LAST-UPDATED "9901190000Z" -- 19 January 1999 ORGANIZATION "SNMPv3 Working Group" CONTACT-INFO "WG-EMail: snmpv3@tis.com Subscribe: majordomo@tis.com In message body: subscribe snmpv3
snmpFrameworkMIB MODULE-IDENTITY最后更新的“990119000Z”-1999年1月19日组织“SNMPv3工作组”联系方式工作组电子邮件：snmpv3@tis.com订阅：majordomo@tis.com在消息正文中：订阅snmpv3
Chair: Russ Mundy TIS Labs at Network Associates postal: 3060 Washington Rd Glenwood MD 21738 USA EMail: mundy@tis.com phone: +1 301-854-6889
主席：美国网络协会Russ Mundy TIS实验室邮编：美国马里兰州格伦伍德华盛顿路3060号邮编：21738电子邮件：mundy@tis.com电话：+1301-854-6889
Co-editor Dave Harrington Cabletron Systems, Inc. postal: Post Office Box 5005 Mail Stop: Durham 35 Industrial Way Rochester, NH 03867-5005 USA EMail: dbh@ctron.com phone: +1 603-337-7357
合编Dave Harrington Cabletron Systems，Inc.邮政：邮政信箱5005邮递站：达勒姆35工业路罗彻斯特，NH 03867-5005美国电子邮件：dbh@ctron.com电话：+1603-337-7357
Co-editor Randy Presuhn BMC Software, Inc. postal: 965 Stewart Drive Sunnyvale, CA 94086 USA EMail: randy_presuhn@bmc.com phone: +1 408-616-3100
联合编辑Randy Presohn BMC Software，Inc.邮政编码：965 Stewart Drive Sunnyvale，CA 94086美国电子邮件：Randy_presuhn@bmc.com电话：+1408-616-3100
Co-editor: Bert Wijnen IBM T.J. Watson Research postal: Schagen 33 3461 GL Linschoten
共同编辑：Bert Wijnen IBM T.J.Watson研究邮政：Schagen 33 3461 GL Linschoten
Netherlands EMail: wijnen@vnet.ibm.com phone: +31 348-432-794 " DESCRIPTION "The SNMP Management Architecture MIB" -- Revision History
荷兰电子邮件：wijnen@vnet.ibm.com电话：+31348-432-794“说明”SNMP管理体系结构MIB--修订历史
REVISION "9901190000Z" -- 19 January 1999
DESCRIPTION "Updated editors' addresses, fixed typos.
Published as RFC2571.
"
REVISION "9711200000Z" -- 20 November 1997
DESCRIPTION "The initial version, published in RFC 2271.
"
::= { snmpModules 10 }
REVISION "9901190000Z" -- 19 January 1999
DESCRIPTION "Updated editors' addresses, fixed typos.
Published as RFC2571.
"
REVISION "9711200000Z" -- 20 November 1997
DESCRIPTION "The initial version, published in RFC 2271.
"
::= { snmpModules 10 }
-- Textual Conventions used in the SNMP Management Architecture ***
-- Textual Conventions used in the SNMP Management Architecture ***
SnmpEngineID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
Objects of this type are for identification, not for
addressing, even though it is possible that an
address may have been used in the generation of
a specific value.
SnmpEngineID ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
Objects of this type are for identification, not for
addressing, even though it is possible that an
address may have been used in the generation of
a specific value.
The value for this object may not be all zeros or all 'ff'H or the empty (zero length) string.
此对象的值不能全部为零或全部为“ff”H或空（零长度）字符串。
The initial value for this object may be configured via an operator console entry or via an algorithmic function. In the latter case, the following example algorithm is recommended.
该对象的初始值可通过操作员控制台条目或算法功能进行配置。在后一种情况下，建议使用以下示例算法。
In cases where there are multiple engines on the same system, the use of this algorithm is NOT appropriate, as it would result in all of those engines ending up with the same ID value.
在同一系统上有多个引擎的情况下，使用此算法是不合适的，因为它会导致所有这些引擎都以相同的ID值结束。
1) The very first bit is used to indicate how the rest of the data is composed.
1) 第一位用于指示其余数据的组成方式。
0 - as defined by enterprise using former methods that existed before SNMPv3. See item 2 below.
0-由企业使用SNMPv3之前存在的方法定义。见下文第2项。
1 - as defined by this architecture, see item 3 below.
1-根据本架构的定义，见下文第3项。
Note that this allows existing uses of the engineID (also known as AgentID [RFC1910]) to co-exist with any new uses.
请注意，这允许engineID的现有用途（也称为AgentID[RFC1910]）与任何新用途共存。
2) The snmpEngineID has a length of 12 octets.
2) snmpEngineID的长度为12个八位字节。
The first four octets are set to the binary equivalent of the agent's SNMP management private enterprise number as assigned by the Internet Assigned Numbers Authority (IANA). For example, if Acme Networks has been assigned { enterprises 696 }, the first four octets would be assigned '000002b8'H.
前四个八位字节被设置为代理的SNMP管理私有企业号的二进制等效值，由Internet分配号码管理局（IANA）分配。例如，如果Acme Networks已分配{enterprises 696}，则前四个八位组将分配为“00000 2B8”H。
The remaining eight octets are determined via one or more enterprise-specific methods. Such methods must be designed so as to maximize the possibility that the value of this object will be unique in the agent's administrative domain. For example, it may be the IP address of the SNMP entity, or the MAC address of one of the interfaces, with each address suitably padded with random octets. If multiple methods are defined, then it is recommended that the first octet indicate the method being used and the remaining octets be a function of the method.
其余八个八位字节通过一种或多种特定于企业的方法确定。此类方法的设计必须使该对象的价值在代理的管理域中具有唯一性的可能性最大化。例如，它可以是SNMP实体的IP地址，或者是其中一个接口的MAC地址，每个地址用随机八位字节适当地填充。如果定义了多个方法，则建议第一个八位字节指示所使用的方法，其余八位字节是该方法的函数。
3) The length of the octet strings varies.
3) 八位组字符串的长度各不相同。
The first four octets are set to the binary equivalent of the agent's SNMP management private enterprise number as assigned by the Internet Assigned Numbers Authority (IANA). For example, if Acme Networks has been assigned { enterprises 696 }, the first four octets would be assigned '000002b8'H.
前四个八位字节被设置为代理的SNMP管理私有企业号的二进制等效值，由Internet分配号码管理局（IANA）分配。例如，如果Acme Networks已分配{enterprises 696}，则前四个八位组将分配为“00000 2B8”H。
The very first bit is set to 1. For example, the above value for Acme Networks now changes to be '800002b8'H.
第一位设置为1。例如，Acme Networks的上述值现在更改为“800002b8”H。
The fifth octet indicates how the rest (6th and following octets) are formatted. The values for the fifth octet are:
第五个八位字节表示其余八位字节（第六个和后面的八位字节）的格式。第五个八位字节的值为：
0 - reserved, unused.
0-保留，未使用。
1 - IPv4 address (4 octets)
1-IPv4地址（4个八位字节）
lowest non-special IP address
最低非特殊IP地址
2 - IPv6 address (16 octets) lowest non-special IP address
2-IPv6地址（16个八位字节）最低非特殊IP地址
3 - MAC address (6 octets) lowest IEEE MAC address, canonical order
3-MAC地址（6个八位字节）最低IEEE MAC地址，规范顺序
4 - Text, administratively assigned Maximum remaining length 27
4-文本，行政分配的最大剩余长度27
5 - Octets, administratively assigned Maximum remaining length 27
5-八位字节，管理分配的最大剩余长度27
6-127 - reserved, unused
6-127-保留、未使用
127-255 - as defined by the enterprise Maximum remaining length 27 " SYNTAX OCTET STRING (SIZE(5..32))
127-255-根据企业最大剩余长度27”语法八位字节字符串（大小（5..32））的定义
SnmpSecurityModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a
securityModel of the Security Subsystem within the
SNMP Management Architecture.
SnmpSecurityModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a
securityModel of the Security Subsystem within the
SNMP Management Architecture.
The values for securityModel are allocated as follows:
securityModel的值分配如下：
- The zero value is reserved. - Values between 1 and 255, inclusive, are reserved for standards-track Security Models and are managed by the Internet Assigned Numbers Authority (IANA). - Values greater than 255 are allocated to enterprise-specific Security Models. An enterprise-specific securityModel value is defined to be:
- 保留零值。-介于1和255之间（含1和255）的值为标准轨道安全模型保留，并由Internet分配号码管理局（IANA）管理大于255的值分配给特定于企业的安全模型。特定于企业的securityModel值定义为：
enterpriseID * 256 + security model within enterprise
企业内部的enterpriseID*256+安全模型
For example, the fourth Security Model defined by the enterprise whose enterpriseID is 1 would be 260.
例如，enterpriseID为1的企业定义的第四个安全模型是260。
This scheme for allocation of securityModel values allows for a maximum of 255 standards-based Security Models, and for a maximum of 255 Security Models per enterprise.
此securityModel值分配方案最多允许255个基于标准的安全模型，每个企业最多允许255个安全模型。
It is believed that the assignment of new securityModel values will be rare in practice because the larger the number of simultaneously utilized Security Models, the larger the chance that interoperability will suffer. Consequently, it is believed that such a range will be sufficient. In the unlikely event that the standards committee finds this number to be insufficient over time, an enterprise number can be allocated to obtain an additional 255 possible values.
人们相信，在实践中，分配新的securityModel值是很少见的，因为同时使用的安全模型数量越多，互操作性受到影响的可能性就越大。因此，相信这样一个范围就足够了。如果标准委员会发现该数字随着时间的推移而不足，则可以分配一个企业编号，以获得额外的255个可能值。
Note that the most significant bit must be zero; hence, there are 23 bits allocated for various organizations to design and define non-standard securityModels. This limits the ability to define new proprietary implementations of Security Models to the first 8,388,608 enterprises.
请注意，最高有效位必须为零；因此，分配给不同组织的23位用于设计和定义非标准安全模型。这限制了第一批8388608企业定义新的安全模型专有实现的能力。
It is worthwhile to note that, in its encoded form, the securityModel value will normally require only a single byte since, in practice, the leftmost bits will be zero for most messages and sign extension is suppressed by the encoding rules.
值得注意的是，在其编码形式中，securityModel值通常只需要一个字节，因为在实践中，对于大多数消息，最左边的位将为零，并且符号扩展被编码规则抑制。
As of this writing, there are several values of securityModel defined for use with SNMP or reserved for use with supporting MIB objects. They are as follows:
在撰写本文时，定义了几个securityModel值，用于SNMP或保留用于支持MIB对象。详情如下:
0 reserved for 'any' 1 reserved for SNMPv1 2 reserved for SNMPv2c 3 User-Based Security Model (USM) " SYNTAX INTEGER(0 .. 2147483647)
0保留用于“任意”1保留用于SNMPv1 2保留用于SNMPv2c 3基于用户的安全模型（USM）“语法整数（0..2147483647）
SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a Message
Processing Model of the Message Processing
Subsystem within a SNMP Management Architecture.
SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "An identifier that uniquely identifies a Message
Processing Model of the Message Processing
Subsystem within a SNMP Management Architecture.
The values for messageProcessingModel are allocated as follows:
messageProcessingModel的值分配如下：
- Values between 0 and 255, inclusive, are reserved for standards-track Message Processing Models and are managed by the Internet Assigned Numbers Authority (IANA).
- 介于0和255（含0和255）之间的值为标准跟踪消息处理模型保留，并由Internet分配号码管理局（IANA）管理。
- Values greater than 255 are allocated to enterprise-specific Message Processing Models. An enterprise messageProcessingModel value is defined to be:
- 大于255的值分配给特定于企业的消息处理模型。enterprise messageProcessingModel值定义为：
enterpriseID * 256 + messageProcessingModel within enterprise
enterpriseID*256+企业内的messageProcessingModel
For example, the fourth Message Processing Model defined by the enterprise whose enterpriseID is 1 would be 260.
例如，enterpriseID为1的企业定义的第四个消息处理模型将是260。
This scheme for allocating messageProcessingModel values allows for a maximum of 255 standards-based Message Processing Models, and for a maximum of 255 Message Processing Models per enterprise.
此分配messageProcessingModel值的方案最多允许255个基于标准的消息处理模型，每个企业最多允许255个消息处理模型。
It is believed that the assignment of new messageProcessingModel values will be rare in practice because the larger the number of simultaneously utilized Message Processing Models, the larger the chance that interoperability will suffer. It is believed that such a range will be sufficient. In the unlikely event that the standards committee finds this number to be insufficient over time, an enterprise number can be allocated to obtain an additional 256 possible values.
人们相信，在实践中，分配新的messageProcessingModel值是很少见的，因为同时使用的消息处理模型的数量越多，互操作性受到影响的可能性就越大。相信这样的范围就足够了。如果标准委员会发现该数字随着时间的推移而不足，则可以分配一个企业编号，以获得额外的256个可能值。
Note that the most significant bit must be zero; hence, there are 23 bits allocated for various organizations to design and define non-standard messageProcessingModels. This limits the ability to define new proprietary implementations of Message Processing Models to the first 8,388,608 enterprises.
请注意，最高有效位必须为零；因此，分配给不同组织的23位用于设计和定义非标准messageProcessingModels。这限制了最初8388608家企业定义消息处理模型的新专有实现的能力。
It is worthwhile to note that, in its encoded form, the messageProcessingModel value will
值得注意的是，在其编码形式中，messageProcessingModel值将
normally require only a single byte since, in practice, the leftmost bits will be zero for most messages and sign extension is suppressed by the encoding rules.
通常只需要一个字节，因为在实践中，对于大多数消息，最左边的位将为零，并且符号扩展被编码规则抑制。
As of this writing, there are several values of messageProcessingModel defined for use with SNMP. They are as follows:
在撰写本文时，有几个messageProcessingModel值是为与SNMP一起使用而定义的。详情如下:
0 reserved for SNMPv1 1 reserved for SNMPv2c 2 reserved for SNMPv2u and SNMPv2* 3 reserved for SNMPv3 " SYNTAX INTEGER(0 .. 2147483647)
0为SNMPv1保留1为SNMPv2c保留2为SNMPv2u保留，SNMPv2*3为SNMPv3保留”语法整数（0..2147483647）
SnmpSecurityLevel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "A Level of Security at which SNMP messages can be
sent or with which operations are being processed;
in particular, one of:
SnmpSecurityLevel ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION "A Level of Security at which SNMP messages can be
sent or with which operations are being processed;
in particular, one of:
noAuthNoPriv - without authentication and without privacy, authNoPriv - with authentication but without privacy, authPriv - with authentication and with privacy.
noAuthNoPriv-无身份验证且无隐私，authNoPriv-有身份验证但无隐私，authPriv-有身份验证且有隐私。
These three values are ordered such that noAuthNoPriv is less than authNoPriv and authNoPriv is less than authPriv. " SYNTAX INTEGER { noAuthNoPriv(1), authNoPriv(2), authPriv(3) }
这三个值的顺序是noAuthNoPriv小于authNoPriv，authNoPriv小于authPriv。语法整数{noAuthNoPriv（1），authNoPriv（2），authPriv（3）}
SnmpAdminString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION "An octet string containing administrative
information, preferably in human-readable form.
SnmpAdminString ::= TEXTUAL-CONVENTION
DISPLAY-HINT "255a"
STATUS current
DESCRIPTION "An octet string containing administrative
information, preferably in human-readable form.
To facilitate internationalization, this information is represented using the ISO/IEC IS 10646-1 character set, encoded as an octet string using the UTF-8 transformation format
为便于国际化，该信息使用ISO/IEC is 10646-1字符集表示，并使用UTF-8转换格式编码为八位字符串
described in [RFC2279].
如[RFC2279]所述。
Since additional code points are added by amendments to the 10646 standard from time to time, implementations must be prepared to encounter any code point from 0x00000000 to 0x7fffffff. Byte sequences that do not correspond to the valid UTF-8 encoding of a code point or are outside this range are prohibited.
由于额外的代码点是通过对10646标准的不时修订而添加的，因此实现必须准备好遇到从0x00000000到0x7FFFFF的任何代码点。禁止与代码点的有效UTF-8编码不对应或超出此范围的字节序列。
The use of control codes should be avoided.
应避免使用控制代码。
When it is necessary to represent a newline, the control code sequence CR LF should be used.
当需要表示换行时，应使用控制代码序列CR LF。
The use of leading or trailing white space should be avoided.
应避免使用前导或尾随空格。
For code points not directly supported by user interface hardware or software, an alternative means of entry and display, such as hexadecimal, may be provided.
对于用户界面硬件或软件不直接支持的代码点，可提供其他输入和显示方式，如十六进制。
For information encoded in 7-bit US-ASCII, the UTF-8 encoding is identical to the US-ASCII encoding.
对于以7位US-ASCII编码的信息，UTF-8编码与US-ASCII编码相同。
UTF-8 may require multiple bytes to represent a single character / code point; thus the length of this object in octets may be different from the number of characters encoded. Similarly, size constraints refer to the number of encoded octets, not the number of characters represented by an encoding.
UTF-8可能需要多个字节来表示单个字符/代码点；因此，该对象的长度（以八位字节为单位）可能与编码的字符数不同。类似地，大小约束是指编码的八位字节数，而不是编码所表示的字符数。
Note that when this TC is used for an object that is used or envisioned to be used as an index, then a SIZE restriction MUST be specified so that the number of sub-identifiers for any object instance does not exceed the limit of 128, as defined by [RFC1905].
请注意，当此TC用于用作或预期用作索引的对象时，必须指定大小限制，以便任何对象实例的子标识符数量不超过[RFC1905]定义的128个限制。
Note that the size of an SnmpAdminString object is measured in octets, not characters. " SYNTAX OCTET STRING (SIZE (0..255))
请注意，SnmpAdminString对象的大小是以八位字节（而不是字符）度量的。“语法八位字符串（大小（0..255））
-- Administrative assignments ***************************************
-- Administrative assignments ***************************************
snmpFrameworkAdmin
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
snmpFrameworkMIBObjects
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
snmpFrameworkMIBConformance
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }
snmpFrameworkAdmin
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
snmpFrameworkMIBObjects
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
snmpFrameworkMIBConformance
OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }
-- the snmpEngine Group ********************************************
-- the snmpEngine Group ********************************************
snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
snmpEngine OBJECT IDENTIFIER ::= { snmpFrameworkMIBObjects 1 }
snmpEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
"
::= { snmpEngine 1 }
snmpEngineID OBJECT-TYPE
SYNTAX SnmpEngineID
MAX-ACCESS read-only
STATUS current
DESCRIPTION "An SNMP engine's administratively-unique identifier.
"
::= { snmpEngine 1 }
snmpEngineBoots OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times that the SNMP engine has
(re-)initialized itself since snmpEngineID
was last configured.
"
::= { snmpEngine 2 }
snmpEngineBoots OBJECT-TYPE
SYNTAX INTEGER (1..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of times that the SNMP engine has
(re-)initialized itself since snmpEngineID
was last configured.
"
::= { snmpEngine 2 }
snmpEngineTime OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of seconds since the value of
the snmpEngineBoots object last changed.
When incrementing this object's value would
cause it to exceed its maximum,
snmpEngineBoots is incremented as if a
re-initialization had occurred, and this
object's value consequently reverts to zero.
"
::= { snmpEngine 3 }
snmpEngineTime OBJECT-TYPE
SYNTAX INTEGER (0..2147483647)
UNITS "seconds"
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The number of seconds since the value of
the snmpEngineBoots object last changed.
When incrementing this object's value would
cause it to exceed its maximum,
snmpEngineBoots is incremented as if a
re-initialization had occurred, and this
object's value consequently reverts to zero.
"
::= { snmpEngine 3 }
snmpEngineMaxMessageSize OBJECT-TYPE SYNTAX INTEGER (484..2147483647)
snmpEngineMaxMessageSize对象类型语法整数（484..2147483647）
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum length in octets of an SNMP message
which this SNMP engine can send or receive and
process, determined as the minimum of the maximum
message size values supported among all of the
transports available to and supported by the engine.
"
::= { snmpEngine 4 }
MAX-ACCESS read-only
STATUS current
DESCRIPTION "The maximum length in octets of an SNMP message
which this SNMP engine can send or receive and
process, determined as the minimum of the maximum
message size values supported among all of the
transports available to and supported by the engine.
"
::= { snmpEngine 4 }
-- Registration Points for Authentication and Privacy Protocols **
--身份验证和隐私协议的注册点**
snmpAuthProtocols OBJECT-IDENTITY
STATUS current
DESCRIPTION "Registration point for standards-track
authentication protocols used in SNMP Management
Frameworks.
"
::= { snmpFrameworkAdmin 1 }
snmpAuthProtocols OBJECT-IDENTITY
STATUS current
DESCRIPTION "Registration point for standards-track
authentication protocols used in SNMP Management
Frameworks.
"
::= { snmpFrameworkAdmin 1 }
snmpPrivProtocols OBJECT-IDENTITY
STATUS current
DESCRIPTION "Registration point for standards-track privacy
protocols used in SNMP Management Frameworks.
"
::= { snmpFrameworkAdmin 2 }
snmpPrivProtocols OBJECT-IDENTITY
STATUS current
DESCRIPTION "Registration point for standards-track privacy
protocols used in SNMP Management Frameworks.
"
::= { snmpFrameworkAdmin 2 }
-- Conformance information ******************************************
-- Conformance information ******************************************
snmpFrameworkMIBCompliances
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
snmpFrameworkMIBGroups
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
snmpFrameworkMIBCompliances
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
snmpFrameworkMIBGroups
OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}
-- compliance statements
--合规声明
snmpFrameworkMIBCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for SNMP engines which implement the SNMP Management Framework MIB. " MODULE -- this module MANDATORY-GROUPS { snmpEngineGroup }
SNMPFrameworkMIB COMPLIANCE MODULE-COMPLIANCE STATUS当前描述“用于实现SNMP管理框架MIB的SNMP引擎的符合性声明。”模块--此模块为必填项-组{snmpEngineGroup}
::= { snmpFrameworkMIBCompliances 1 }
::= { snmpFrameworkMIBCompliances 1 }
-- units of conformance
--一致性单位
snmpEngineGroup OBJECT-GROUP
OBJECTS {
snmpEngineID,
snmpEngineBoots,
snmpEngineTime,
snmpEngineMaxMessageSize
}
STATUS current
DESCRIPTION "A collection of objects for identifying and
determining the configuration and current timeliness
values of an SNMP engine.
"
::= { snmpFrameworkMIBGroups 1 }
snmpEngineGroup OBJECT-GROUP
OBJECTS {
snmpEngineID,
snmpEngineBoots,
snmpEngineTime,
snmpEngineMaxMessageSize
}
STATUS current
DESCRIPTION "A collection of objects for identifying and
determining the configuration and current timeliness
values of an SNMP engine.
"
::= { snmpFrameworkMIBGroups 1 }
END
终止
This document defines three number spaces administered by IANA, one for security models, another for message processing models, and a third for SnmpEngineID formats.
本文档定义了IANA管理的三个数字空间，一个用于安全模型，另一个用于消息处理模型，第三个用于SnmpEngineID格式。
The SnmpSecurityModel TEXTUAL-CONVENTION values managed by IANA are in the range from 0 to 255 inclusive, and are reserved for standards-track Security Models. If this range should in the future prove insufficient, an enterprise number can be allocated to obtain an additional 255 possible values.
IANA管理的SnmpSecurityModel文本约定值的范围为0到255（含0到255），并为标准轨道安全模型保留。如果将来证明该范围不够，则可以分配一个企业编号以获得额外的255个可能值。
As of this writing, there are several values of securityModel defined for use with SNMP or reserved for use with supporting MIB objects. They are as follows: 0 reserved for 'any' 1 reserved for SNMPv1 2 reserved for SNMPv2c 3 User-Based Security Model (USM)
在撰写本文时，定义了几个securityModel值，用于SNMP或保留用于支持MIB对象。它们如下：0为“任意”保留1为SNMPv1保留2为SNMPv2c保留3基于用户的安全模型（USM）
The SnmpMessageProcessingModel TEXTUAL-CONVENTION values managed by IANA are in the range 0 to 255, inclusive. Each value uniquely identifies a standards-track Message Processing Model of the Message Processing Subsystem within a SNMP Management Architecture.
IANA管理的SnmpMessageProcessingModel文本约定值的范围为0到255（含0到255）。每个值唯一标识SNMP管理体系结构中消息处理子系统的标准跟踪消息处理模型。
Should this range prove insufficient in the future, an enterprise number may be obtained for the standards committee to get an
如果将来证明该范围不足，则可获得企业编号，以便标准委员会获得批准
additional 256 possible values.
额外的256个可能值。
As of this writing, there are several values of messageProcessingModel defined for use with SNMP. They are as follows: 0 reserved for SNMPv1 1 reserved for SNMPv2c 2 reserved for SNMPv2u and SNMPv2* 3 reserved for SNMPv3
在撰写本文时，有几个messageProcessingModel值是为与SNMP一起使用而定义的。它们是：0为SNMPv1保留1为SNMPv2c保留2为SNMPv2u保留，SNMPv2*3为SNMPv3保留
The SnmpEngineID TEXTUAL-CONVENTION's fifth octet contains a format identifier. The values managed by IANA are in the range 6 to 127, inclusive. Each value uniquely identifies a standards-track SnmpEngineID format.
SnmpEngineID文本约定的第五个八位组包含格式标识符。IANA管理的值范围为6到127（含6到127）。每个值唯一标识一个标准曲目SnmpEngineID格式。
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执行董事。
This document is the result of the efforts of the SNMPv3 Working Group. Some special thanks are in order to the following SNMPv3 WG members:
本文件是SNMPv3工作组努力的结果。特别感谢以下SNMPv3工作组成员：
Harald Tveit Alvestrand (Maxware) Dave Battle (SNMP Research, Inc.) Alan Beard (Disney Worldwide Services)
Harald Tveit Alvestrand（Maxware）Dave Battle（SNMP研究公司）Alan Beard（迪士尼全球服务）
Paul Berrevoets (SWI Systemware/Halcyon Inc.) Martin Bjorklund (Ericsson) Uri Blumenthal (IBM T.J. Watson Research Center) Jeff Case (SNMP Research, Inc.) John Curran (BBN) Mike Daniele (Compaq Computer Corporation) T. Max Devlin (Eltrax Systems) John Flick (Hewlett Packard) Rob Frye (MCI) Wes Hardaker (U.C.Davis, Information Technology - D.C.A.S.) David Harrington (Cabletron Systems Inc.) Lauren Heintz (BMC Software, Inc.) N.C. Hien (IBM T.J. Watson Research Center) Michael Kirkham (InterWorking Labs, Inc.) Dave Levi (SNMP Research, Inc.) Louis A Mamakos (UUNET Technologies Inc.) Joe Marzot (Nortel Networks) Paul Meyer (Secure Computing Corporation) Keith McCloghrie (Cisco Systems) Bob Moore (IBM) Russ Mundy (TIS Labs at Network Associates) Bob Natale (ACE*COMM Corporation) Mike O'Dell (UUNET Technologies Inc.) Dave Perkins (DeskTalk) Peter Polkinghorne (Brunel University) Randy Presuhn (BMC Software, Inc.) David Reeder (TIS Labs at Network Associates) David Reid (SNMP Research, Inc.) Aleksey Romanov (Quality Quorum) Shawn Routhier (Epilogue) Juergen Schoenwaelder (TU Braunschweig) Bob Stewart (Cisco Systems) Mike Thatcher (Independent Consultant) Bert Wijnen (IBM T.J. Watson Research Center)
Paul Berrevoets（SWI Systemware/Halcyon Inc.）Martin Bjorklund（爱立信）Uri Blumenthal（IBM T.J.Watson研究中心）Jeff Case（SNMP Research，Inc.）John Curran（BBN）Mike Daniele（Compaq Computer Corporation）T.Max Devlin（Eltrax Systems）John Flick（惠普）Rob Frye（MCI）Wes Hardaker（U.C.Davis，信息技术-D.C.A.S.）David Harrington（Cabletron Systems Inc.）Lauren Heintz（BMC Software，Inc.）N.C.Hien（IBM T.J.Watson研究中心）Michael Kirkham（InterWorking Labs，Inc.）Dave Levi（SNMP Research，Inc.）Louis A Mamakos（UUNET Technologies Inc.）Joe Marzot（Nortel Networks）Paul Meyer（安全计算公司）Keith McLoghrie（Cisco Systems）Bob Moore（IBM）Russ Mundy（网络协会的TIS实验室）Bob Natale（ACE*通信公司）Mike O'Dell（Uune Technologies Inc.）Dave Perkins（DeskTalk）Peter Polkinghorne（布鲁内尔大学）Randy Presohn（BMC软件公司）David Reeder（网络协会的TIS实验室）David Reid（SNMP研究公司）Aleksey Romanov（质量仲裁）肖恩·劳希尔（结语）尤尔根·舍恩瓦德（图布伦瑞克）鲍勃·斯图尔特（思科系统）迈克·撒切尔（独立顾问）伯特·维恩（IBM T.J.沃森研究中心）
The document is based on recommendations of the IETF Security and Administrative Framework Evolution for SNMP Advisory Team. Members of that Advisory Team were:
本文件基于IETF安全和管理框架演进SNMP咨询团队的建议。该咨询小组的成员是：
David Harrington (Cabletron Systems Inc.) Jeff Johnson (Cisco Systems) David Levi (SNMP Research Inc.) John Linn (Openvision) Russ Mundy (Trusted Information Systems) chair Shawn Routhier (Epilogue) Glenn Waters (Nortel) Bert Wijnen (IBM T. J. Watson Research Center)
David Harrington（Cabletron Systems Inc.）Jeff Johnson（Cisco Systems）David Levi（SNMP Research Inc.）John Linn（Openvision）Russ Mundy（Trusted Information Systems）Shawn Routhier（尾声）Glenn Waters（Nortel）Bert Wijnen（IBM T.J.Watson研究中心）
As recommended by the Advisory Team and the SNMPv3 Working Group Charter, the design incorporates as much as practical from previous RFCs and drafts. As a result, special thanks are due to the authors of previous designs known as SNMPv2u and SNMPv2*:
根据咨询小组和SNMPv3工作组章程的建议，该设计尽可能多地结合了先前RFC和草案中的实际内容。因此，我们特别感谢以前设计的SNMPv2u和SNMPv2*的作者：
Jeff Case (SNMP Research, Inc.) David Harrington (Cabletron Systems Inc.) David Levi (SNMP Research, Inc.) Keith McCloghrie (Cisco Systems) Brian O'Keefe (Hewlett Packard) Marshall T. Rose (Dover Beach Consulting) Jon Saperia (BGS Systems Inc.) Steve Waldbusser (International Network Services) Glenn W. Waters (Bell-Northern Research Ltd.)
Jeff Case（SNMP Research，Inc.）David Harrington（Cabletron Systems Inc.）David Levi（SNMP Research，Inc.）Keith McCloghrie（Cisco Systems）Brian O'Keefe（惠普）Marshall T.Rose（多佛海滩咨询）Jon Saperia（BGS Systems Inc.）Steve Waldbusser（国际网络服务）Glenn W.Waters（贝尔北方研究有限公司）
This document describes how an implementation can include a Security Model to protect management messages and an Access Control Model to control access to management information.
本文档描述了实现如何包括用于保护管理消息的安全模型和用于控制对管理信息的访问的访问控制模型。
The level of security provided is determined by the specific Security Model implementation(s) and the specific Access Control Model implementation(s) used.
提供的安全级别由所使用的特定安全模型实现和特定访问控制模型实现决定。
Applications have access to data which is not secured. Applications SHOULD take reasonable steps to protect the data from disclosure.
应用程序可以访问不安全的数据。应用程序应采取合理措施保护数据不被披露。
It is the responsibility of the purchaser of an implementation to ensure that:
实施的买方有责任确保：
1) an implementation complies with the rules defined by this architecture,
1) 实现符合此体系结构定义的规则，
2) the Security and Access Control Models utilized satisfy the security and access control needs of the organization,
2) 使用的安全和访问控制模型满足组织的安全和访问控制需求，
3) the implementations of the Models and Applications comply with the model and application specifications,
3) 模型和应用程序的实现符合模型和应用程序规范，
4) and the implementation protects configuration secrets from inadvertent disclosure.
4) 并且该实现可以保护配置机密不被无意中泄露。
This document also contains a MIB definition module. None of the objects defined is writable, and the information they represent is not deemed to be particularly sensitive. However, if they are deemed
本文档还包含一个MIB定义模块。定义的对象都不可写，它们所代表的信息也不被认为是特别敏感的。但是，如果它们被视为
sensitive in a particular environment, access to them should be restricted through the use of appropriately configured Security and Access Control models.
在特定环境中，应通过使用适当配置的安全和访问控制模型来限制对它们的访问。
[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., M. Fedor, M. Schoffstall and J. Davin, "The Simple Network Management Protocol", STD 15, RFC 1157, May 1990.
[RFC1157]Case，J.，M.Fedor，M.Schoffstall和J.Davin，“简单网络管理协议”，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月。
[RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[RFC1901]SNMPv2工作组，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“基于社区的SNMPv2简介”，RFC 1901，1996年1月。
[RFC2578] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[RFC2578]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“管理信息的结构版本2（SMIv2）”，STD 58，RFC 2578，1999年4月。
[RFC2579] McCloghrie, K., Perkins, D. and J. Schoenwaelder,, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.
[RFC2579]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“SMIv2的文本约定”，STD 58，RFC 2579，1999年4月。
[RFC2580] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.
[RFC2580]McCloghrie，K.，Perkins，D.和J.Schoenwaeld，“SMIv2的一致性声明”，STD 58，RFC 25801999年4月。
[RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, January 1996.
[RFC1905]SNMPv2工作组，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的协议操作”，RFC 1905，1996年1月。
[RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, January 1996.
[RFC1906]SNMPv2工作组，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的传输映射”，RFC 1906，1996年1月。
[RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1907 January 1996.
[RFC1907]SNMPv2工作组，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“简单网络管理协议（SNMPv2）版本2的管理信息库”，RFC 1907，1996年1月。
[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Coexistence between Version 1 and Version 2 of the SNMP-standard Network Management Framework", RFC 1908, January 1996.
[RFC1908]SNMPv2工作组，Case，J.，McCloghrie，K.，Rose，M.和S.Waldbusser，“SNMP标准网络管理框架版本1和版本2之间的共存”，RFC 1908，1996年1月。
[RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure for SNMPv2", RFC 1909, February 1996.
[RFC1909]McCloghrie，K.，编辑，“SNMPv2的管理基础设施”，RFC1909，1996年2月。
[RFC1910] Waters, G., Editor, "User-based Security Model for SNMPv2", RFC 1910, February 1996.
[RFC1910]Waters，G.，编辑，“SNMPv2基于用户的安全模型”，RFC1910，1996年2月。
[RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January, 1998.
[RFC2279]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，RFC 2279，1998年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[BCP-11] Hovey, R. and S. Bradner, "The Organizations Involved in the IETF Standards Process", BCP 11, RFC 2028, October 1996.
[BCP-11]Hovey，R.和S.Bradner，“参与IETF标准过程的组织”，BCP 11，RFC 2028，1996年10月。
[RFC2233] McCloghrie, K. and F. Kastenholz. "The Interfaces Group MIB using SMIv2", RFC 2233, November 1997.
[RFC2233]McCloghrie，K.和F.Kastenholz。“使用SMIv2的接口组MIB”，RFC 2233，1997年11月。
[RFC2572] Case, J., Harrington, D., Presuhn, R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.
[RFC2572]Case，J.，Harrington，D.，Presohn，R.和B.Wijnen，“简单网络管理协议（SNMP）的消息处理和调度”，RFC 2572，1999年4月。
[RFC2574] Blumenthal, U. and B. Wijnen, "The User-Based Security Model for Version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[RFC2574]Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版基于用户的安全模型”，RFC 2574，1999年4月。
[RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[RFC2575]Wijnen，B.，Presuhn，R.和K.McCloghrie，“简单网络管理协议（SNMP）基于视图的访问控制模型”，RFC 2575，1999年4月。
[RFC2573] Levi, D. B., Meyer, P. and B. Stewart, "SNMP Applications", RFC 2573, April 1999.
[RFC2573]Levi，D.B.，Meyer，P.和B.Stewart，“SNMP应用”，RFC2573，1999年4月。
[RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, April 1999.
[RFC2570]Case，J.，Mundy，R.，Partain，D.和B.Stewart，“互联网标准网络管理框架第3版简介”，RFC 25701999年4月。
[SNMP-COEX] Frye, R., Levi, D. and B. Wijnen, "Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework", Work in Progress.
[SNMP-COEX]Frye，R.，Levi，D.和B.Wijnen，“互联网标准网络管理框架第1版、第2版和第3版之间的共存”，正在进行中。
Bert Wijnen IBM T.J. Watson Research Schagen 33 3461 GL Linschoten Netherlands
Bert Wijnen IBM T.J.Watson Research Schagen 33 3461 GL Linschoten荷兰
Phone: +31 348-432-794
EMail: wijnen@vnet.ibm.com
Phone: +31 348-432-794
EMail: wijnen@vnet.ibm.com
Dave Harrington Cabletron Systems, Inc Post Office Box 5005 Mail Stop: Durham 35 Industrial Way Rochester, NH 03867-5005 USA
Dave Harrington Cabletron Systems，Inc.邮政信箱5005邮递站：美国新罕布什尔州罗彻斯特市达勒姆工业大道35号，邮编03867-5005
Phone: +1 603-337-7357
EMail: dbh@ctron.com
Phone: +1 603-337-7357
EMail: dbh@ctron.com
Randy Presuhn BMC Software, Inc. 965 Stewart Drive Sunnyvale, CA 94086 USA
Randy Presohn BMC软件公司，美国加利福尼亚州桑尼维尔市斯图尔特大道965号，邮编94086
Phone: +1 408-616-3100
Fax: +1 408-616-3101
EMail: randy_presuhn@bmc.com
Phone: +1 408-616-3100
Fax: +1 408-616-3101
EMail: randy_presuhn@bmc.com
APPENDIX A
附录A
A. Guidelines for Model Designers
A.模型设计师指南
This appendix describes guidelines for designers of models which are expected to fit into the architecture defined in this document.
本附录描述了适用于模型设计者的指南，这些模型应符合本文件中定义的体系结构。
SNMPv1 and SNMPv2c are two SNMP frameworks which use communities to provide trivial authentication and access control. SNMPv1 and SNMPv2c Frameworks can coexist with Frameworks designed according to this architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks could be designed to meet the requirements of this architecture, but this document does not provide guidelines for that coexistence.
SNMPv1和SNMPv2c是两个SNMP框架，它们使用社区提供简单的身份验证和访问控制。SNMPv1和SNMPv2c框架可以与根据此体系结构设计的框架共存，SNMPv1和SNMPv2c框架的修改版本可以设计为满足此体系结构的要求，但本文档不提供这种共存的指南。
Within any subsystem model, there should be no reference to any specific model of another subsystem, or to data defined by a specific model of another subsystem.
在任何子系统模型中，不应参考另一子系统的任何特定模型，或参考由另一子系统的特定模型定义的数据。
Transfer of data between the subsystems is deliberately described as a fixed set of abstract data elements and primitive functions which can be overloaded to satisfy the needs of multiple model definitions.
子系统之间的数据传输被有意地描述为一组固定的抽象数据元素和原始函数，这些元素和函数可以重载以满足多个模型定义的需要。
Documents which define models to be used within this architecture SHOULD use the standard primitives between subsystems, possibly defining specific mechanisms for converting the abstract data elements into model-usable formats. This constraint exists to allow subsystem and model documents to be written recognizing common borders of the subsystem and model. Vendors are not constrained to recognize these borders in their implementations.
定义此体系结构中使用的模型的文档应在子系统之间使用标准原语，可能定义将抽象数据元素转换为模型可用格式的特定机制。此约束允许编写子系统和模型文档，以识别子系统和模型的公共边界。供应商不必在其实现中识别这些边界。
The architecture defines certain standard services to be provided between subsystems, and the architecture defines abstract service interfaces to request these services.
体系结构定义了子系统之间要提供的某些标准服务，体系结构定义了请求这些服务的抽象服务接口。
Each model definition for a subsystem SHOULD support the standard service interfaces, but whether, or how, or how well, it performs the service is dependent on the model definition.
子系统的每个模型定义都应该支持标准服务接口，但它是否、如何或如何执行服务取决于模型定义。
A document describing a Security Model MUST describe how the model protects against the threats described under "Security Requirements of this Architecture", section 1.4.
描述安全模型的文件必须描述该模型如何抵御“该体系结构的安全要求”第1.4节中描述的威胁。
Received messages MUST be validated by a Model of the Security Subsystem. Validation includes authentication and privacy processing if needed, but it is explicitly allowed to send messages which do not require authentication or privacy.
接收到的消息必须通过安全子系统的模型进行验证。如果需要，验证包括身份验证和隐私处理，但明确允许发送不需要身份验证或隐私的消息。
A received message contains a specified securityLevel to be used during processing. All messages requiring privacy MUST also require authentication.
接收到的消息包含处理期间要使用的指定securityLevel。所有需要隐私的邮件也必须进行身份验证。
A Security Model specifies rules by which authentication and privacy are to be done. A model may define mechanisms to provide additional security features, but the model definition is constrained to using (possibly a subset of) the abstract data elements defined in this document for transferring data between subsystems.
安全模型指定了执行身份验证和隐私的规则。模型可以定义提供额外安全特性的机制，但模型定义仅限于使用本文档中定义的抽象数据元素（可能是其中的一个子集）在子系统之间传输数据。
Each Security Model may allow multiple security protocols to be used concurrently within an implementation of the model. Each Security Model defines how to determine which protocol to use, given the securityLevel and the security parameters relevant to the message. Each Security Model, with its associated protocol(s) defines how the sending/receiving entities are identified, and how secrets are configured.
每个安全模型可允许在该模型的实现内同时使用多个安全协议。每个安全模型定义了如何确定要使用的协议，给出了securityLevel和与消息相关的安全参数。每个安全模型及其相关协议定义了如何识别发送/接收实体以及如何配置机密。
Authentication and Privacy protocols supported by Security Models are uniquely identified using Object Identifiers. IETF standard protocols for authentication or privacy should have an identifier defined within the snmpAuthProtocols or the snmpPrivProtocols subtrees. Enterprise specific protocol identifiers should be defined within the enterprise subtree.
安全模型支持的身份验证和隐私协议使用对象标识符进行唯一标识。IETF认证或隐私标准协议应在snmpAuthProtocols或snmpPrivProtocols子树中定义标识符。企业特定的协议标识符应在企业子树中定义。
For privacy, the Security Model defines what portion of the message is encrypted.
对于隐私，安全模型定义了消息的哪一部分是加密的。
The persistent data used for security should be SNMP-manageable, but the Security Model defines whether an instantiation of the MIB is a conformance requirement.
用于安全的持久数据应该是SNMP可管理的，但是安全模型定义了MIB的实例化是否是一致性要求。
Security Models are replaceable within the Security Subsystem. Multiple Security Model implementations may exist concurrently within an SNMP engine. The number of Security Models defined by the SNMP community should remain small to promote interoperability.
安全模型在安全子系统中是可替换的。SNMP引擎中可能同时存在多个安全模型实现。SNMP社区定义的安全模型数量应保持较小，以促进互操作性。
A Message Processing Model requests that a Security Model: - verifies that the message has not been altered,
消息处理模型要求安全模型：-验证消息未被更改，
- authenticates the identification of the principal for whom the message was generated. - decrypts the message if it was encrypted.
- 验证为其生成消息的主体的标识。-如果消息已加密，则对其进行解密。
Additional requirements may be defined by the model, and additional services may be provided by the model, but the model is constrained to use the following primitives for transferring data between subsystems. Implementations are not so constrained.
附加需求可以由模型定义，附加服务可以由模型提供，但是模型被限制使用以下原语在子系统之间传输数据。实现并不是那么受限。
A Message Processing Model uses the processIncomingMsg primitive as described in section 4.4.2.
消息处理模型使用processIncomingMsg原语，如第4.4.2节所述。
Each Security Model defines the MIB module(s) required for security processing, including any MIB module(s) required for the security protocol(s) supported. The MIB module(s) SHOULD be defined concurrently with the procedures which use the MIB module(s). The MIB module(s) are subject to normal access control rules.
每个安全模型定义安全处理所需的MIB模块，包括支持的安全协议所需的任何MIB模块。MIB模块应与使用MIB模块的过程同时定义。MIB模块受正常访问控制规则的约束。
The mapping between the model-dependent security ID and the securityName MUST be able to be determined using SNMP, if the model-dependent MIB is instantiated and if access control policy allows access.
如果模型相关MIB已实例化，并且访问控制策略允许访问，则必须能够使用SNMP确定模型相关安全ID和securityName之间的映射。
For each message received, the Security Model caches the state information such that a Response message can be generated using the same security information, even if the Local Configuration Datastore is altered between the time of the incoming request and the outgoing response.
对于接收到的每条消息，安全模型缓存状态信息，以便可以使用相同的安全信息生成响应消息，即使在传入请求和传出响应之间更改了本地配置数据存储。
A Message Processing Model has the responsibility for explicitly releasing the cached data if such data is no longer needed. To enable this, an abstract securityStateReference data element is passed from the Security Model to the Message Processing Model.
如果不再需要缓存数据，则消息处理模型负责显式释放缓存数据。要启用此功能，将抽象securityStateReference数据元素从安全模型传递到消息处理模型。
The cached security data may be implicitly released via the generation of a response, or explicitly released by using the stateRelease primitive, as described in section 4.5.1.
缓存的安全数据可以通过生成响应隐式释放，也可以通过使用stateRelease原语显式释放，如第4.5.1节所述。
An SNMP engine contains a Message Processing Subsystem which may contain multiple Message Processing Models.
SNMP引擎包含一个消息处理子系统，该子系统可能包含多个消息处理模型。
The Message Processing Model MUST always (conceptually) pass the complete PDU, i.e., it never forwards less than the complete list of varBinds.
消息处理模型必须始终（从概念上）传递完整的PDU，即，它转发的变量绑定数不得少于完整列表。
Upon receipt of a message from the network, the Dispatcher in the SNMP engine determines the version of the SNMP message and interacts with the corresponding Message Processing Model to determine the abstract data elements.
在收到来自网络的消息后，SNMP引擎中的调度器确定SNMP消息的版本，并与相应的消息处理模型交互以确定抽象数据元素。
A Message Processing Model specifies the SNMP Message format it supports and describes how to determine the values of the abstract data elements (like msgID, msgMaxSize, msgFlags, msgSecurityParameters, securityModel, securityLevel etc). A Message Processing Model interacts with a Security Model to provide security processing for the message using the processIncomingMsg primitive, as described in section 4.4.2.
消息处理模型指定其支持的SNMP消息格式，并描述如何确定抽象数据元素的值（如msgID、msgMaxSize、msgFlags、msgSecurityParameters、securityModel、securityLevel等）。消息处理模型与安全模型交互，使用processIncomingMsg原语为消息提供安全处理，如第4.4.2节所述。
The Dispatcher in the SNMP engine interacts with a Message Processing Model to prepare an outgoing message. For that it uses the following primitives:
SNMP引擎中的调度器与消息处理模型交互以准备传出消息。为此，它使用以下基本体：
- for requests and notifications: prepareOutgoingMessage, as described in section 4.2.1.
- 对于请求和通知：如第4.2.1节所述，准备OutgoingMessage。
- for response messages: prepareResponseMessage, as described in section 4.2.2.
- 对于响应消息：prepareResponseMessage，如第4.2.2节所述。
A Message Processing Model, when preparing an Outgoing SNMP Message, interacts with a Security Model to secure the message. For that it uses the following primitives:
在准备传出SNMP消息时，消息处理模型与安全模型交互以保护消息。为此，它使用以下基本体：
- for requests and notifications: generateRequestMsg, as described in section 4.4.1.
- 对于请求和通知：generateRequestMsg，如第4.4.1节所述。
- for response messages: generateResponseMsg as described in section 4.4.3.
- 对于响应消息：如第4.4.3节所述的generateResponseMsg。
Once the SNMP message is prepared by a Message Processing Model, the Dispatcher sends the message to the desired address using the appropriate transport.
消息处理模型准备好SNMP消息后，调度器使用适当的传输将消息发送到所需的地址。
Within an application, there may be an explicit binding to a specific SNMP message version, i.e., a specific Message Processing Model, and to a specific Access Control Model, but there should be no reference to any data defined by a specific Message Processing Model or Access Control Model.
在应用程序中，可能存在到特定SNMP消息版本（即特定消息处理模型）和特定访问控制模型的显式绑定，但不应引用由特定消息处理模型或访问控制模型定义的任何数据。
Within an application, there should be no reference to any specific Security Model, or any data defined by a specific Security Model.
在应用程序中，不应该引用任何特定的安全模型，也不应该引用由特定安全模型定义的任何数据。
An application determines whether explicit or implicit access control should be applied to the operation, and, if access control is needed, which Access Control Model should be used.
应用程序确定是对操作应用显式访问控制还是隐式访问控制，如果需要访问控制，则确定应使用哪种访问控制模型。
An application has the responsibility to define any MIB module(s) used to provide application-specific services.
应用程序有责任定义用于提供应用程序特定服务的任何MIB模块。
Applications interact with the SNMP engine to initiate messages, receive responses, receive asynchronous messages, and send responses.
应用程序与SNMP引擎交互以启动消息、接收响应、接收异步消息和发送响应。
Applications may request that the SNMP engine send messages containing SNMP commands or notifications using the sendPdu primitive as described in section 4.1.1.
应用程序可能会请求SNMP引擎使用sendPdu原语发送包含SNMP命令或通知的消息，如第4.1.1节所述。
If it is desired that a message be sent to multiple targets, it is the responsibility of the application to provide the iteration.
如果希望将消息发送到多个目标，则应用程序负责提供迭代。
The SNMP engine assumes necessary access control has been applied to the PDU, and provides no access control services.
SNMP引擎假定对PDU应用了必要的访问控制，并且不提供访问控制服务。
The SNMP engine looks at the "expectResponse" parameter, and if a response is expected, then the appropriate information is cached such that a later response can be associated to this message, and can then be returned to the application. A sendPduHandle is returned to the application so it can later correspond the response with this message as well.
SNMP引擎查看“expectResponse”参数，如果需要响应，则缓存适当的信息，以便稍后的响应可以与此消息关联，然后可以返回给应用程序。sendPduHandle将返回给应用程序，以便稍后它也可以将响应与此消息对应起来。
The SNMP engine matches the incoming response messages to outstanding messages sent by this SNMP engine, and forwards the response to the associated application using the processResponsePdu primitive, as described in section 4.1.4.
SNMP引擎将传入响应消息与此SNMP引擎发送的未完成消息相匹配，并使用processResponsePdu原语将响应转发给相关应用程序，如第4.1.4节所述。
When an SNMP engine receives a message that is not the response to a request from this SNMP engine, it must determine to which application the message should be given.
当SNMP引擎接收到的消息不是对来自该SNMP引擎的请求的响应时，它必须确定该消息应发送给哪个应用程序。
An Application that wishes to receive asynchronous messages registers itself with the engine using the primitive registerContextEngineID as described in section 4.1.5.
如第4.1.5节所述，希望接收异步消息的应用程序使用原始registerContextEngineID向引擎注册自身。
An Application that wishes to stop receiving asynchronous messages should unregister itself with the SNMP engine using the primitive unregisterContextEngineID as described in section 4.1.5.
如第4.1.5节所述，希望停止接收异步消息的应用程序应使用原语unregisterContextEngineID在SNMP引擎中注销自身。
Only one registration per combination of PDU type and contextEngineID is permitted at the same time. Duplicate registrations are ignored. An errorIndication will be returned to the application that attempts to duplicate a registration.
同时，每个PDU类型和contextEngineID组合只允许进行一次注册。重复注册将被忽略。尝试复制注册的应用程序将返回错误指示。
All asynchronously received messages containing a registered combination of PDU type and contextEngineID are sent to the application which registered to support that combination.
所有异步接收的包含已注册的PDU类型和contextEngineID组合的消息将发送到已注册以支持该组合的应用程序。
The engine forwards the PDU to the registered application, using the processPdu primitive, as described in section 4.1.2.
引擎使用processPdu原语将PDU转发给注册的应用程序，如第4.1.2节所述。
Request operations require responses. An application sends a response via the returnResponsePdu primitive, as described in section 4.1.3.
请求操作需要响应。应用程序通过returnResponsePdu原语发送响应，如第4.1.3节所述。
The contextEngineID, contextName, securityModel, securityName, securityLevel, and stateReference parameters are from the initial processPdu primitive. The PDU and statusInformation are the results of processing.
contextEngineID、contextName、securityModel、securityName、securityLevel和stateReference参数来自初始processPdu原语。PDU和状态信息是处理的结果。
An Access Control Model determines whether the specified securityName is allowed to perform the requested operation on a specified managed object. The Access Control Model specifies the rules by which access control is determined.
访问控制模型确定是否允许指定的securityName对指定的托管对象执行请求的操作。访问控制模型指定确定访问控制的规则。
The persistent data used for access control should be manageable using SNMP, but the Access Control Model defines whether an instantiation of the MIB is a conformance requirement.
用于访问控制的持久数据应该可以使用SNMP进行管理，但是访问控制模型定义了MIB的实例化是否是一致性要求。
The Access Control Model must provide the primitive isAccessAllowed.
访问控制模型必须提供原语isAccessAllowed。
B. Full Copyright Statement
B.完整的版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
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编辑功能的资金目前由互联网协会提供。