INTERNET-DRAFT                                             D. Harrington
                                                 Cabletron Systems, Inc.
                                                              R. Presuhn
                                                      BMC Software, Inc.
                                                               B. Wijnen
                                               IBM T. J. Watson Research
                                                       30 September
                                                         28 October 1997

                     An Architecture for Describing
                       SNMP Management Frameworks
                <draft-ietf-snmpv3-next-gen-arch-05.txt>
                <draft-ietf-snmpv3-next-gen-arch-06.txt>

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Copyright Notice

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

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.

Table of Contents

   1. Introduction ................................................    5
   1.1. Overview

   This document defines a vocabulary for describing ..................................................    5
   1.2. SNMP Management
   Frameworks, and an architecture for describing the major portions ......................................................    5
   1.3. Goals of
   SNMP Management Frameworks.

   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.

   Section 1 describes the purpose, goals, and design decisions Architecture ................................    6
   1.4. Security Requirements of this
   architecture.

   Section 2 describes various types Architecture ................    7
   1.5. Design Decisions ..........................................    8
   2. Documentation Overview ......................................    9
   2.1. Document Roadmap ..........................................   11
   2.2. Applicability Statement ...................................   11
   2.3. Coexistence and Transition ................................   11
   2.4. Transport Mappings ........................................   11
   2.5. Message Processing ........................................   12
   2.6. Security ..................................................   12
   2.7. Access Control ............................................   12
   2.8. Protocol Operations .......................................   13
   2.9. Applications ..............................................   13
   2.10. Structure of documents which define Management Information ......................   13
   2.11. Textual Conventions ......................................   13
   2.12. Conformance Statements ...................................   14
   2.13. Management Information Base Modules ......................   14
   2.13.1. SNMP
   Frameworks, and how they fit into this architecture. It also provides
   a minimal road map to the documents which have previously defined Instrumentation MIBs ..............................   14
   2.14. SNMP frameworks.

   Section 3 details the vocabulary Framework Documents .................................   14
   3. Elements 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.

   Section 4 describes the primitives used for the abstract service
   interfaces between the various subsystems, models and applications
   within this architecture.

   Section 5 defines a collection Architecture ................................   15
   3.1. The Naming of managed objects used to instrument Entities ....................................   15
   3.1.1. SNMP entities within this architecture.

   Sections 6, 7, 8, and 9 are administrative in nature.

   Appendix A contains guidelines for designers engine .............................................   16
   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 ....................................   19
   3.1.1.4.1. Security Model ......................................   19
   3.1.1.4.2. Security Protocol ...................................   19
   3.1.2. Access Control Subsystem ................................   20
   3.1.2.1. Access Control Model ..................................   20
   3.1.3. Applications ............................................   20
   3.1.3.1. SNMP Manager ..........................................   21
   3.1.3.2. SNMP Agent ............................................   22
   3.2. The Naming of Models which are
   expected to fit within this architecture. Identities ..................................   23
   3.2.1. Principal ...............................................   23
   3.2.2. securityName ............................................   23
   3.2.3. Model-dependent security ID .............................   24
   3.3. 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].

1.2.  SNMP Naming of Management Information ......................   25
   3.3.1. An SNMP management system contains:

      -  several (potentially many) nodes, each with an 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 ............   28
   4.1.3. Generate Outgoing Response ..............................   30
   4.1.4. Process Incoming Response PDU ...........................   30
   4.1.5. Registering Responsibility for Handling SNMP entity
         containing command responder and notification originator
         applications, which have access to management instrumentation
         (traditionally called agents);

      -  at least one PDUs .......   30
   4.2. Message Processing Subsystem Primitives ...................   31
   4.2.1. Prepare Outgoing SNMP entity containing command generator and/or
         notification receiver applications (traditionally called a
         manager) and,

      -  a management protocol, used to convey management information
         between the Request or Notification Message ...   31
   4.2.2. Prepare an Outgoing SNMP entities. Response Message ...............   32
   4.2.3. Prepare Data Elements from an Incoming SNMP entities executing command generator and notification receiver
   applications monitor and control managed elements. Message .....   33
   4.3. Access Control Subsystem Primitives .......................   33
   4.4. Security Subsystem Primitives .............................   34
   4.4.1. Generate a Request or Notification Message ..............   34
   4.4.2. Process Incoming Message ................................   34
   4.4.3. Generate a Response Message .............................   35
   4.5. Common Primitives .........................................   35
   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 elements
   are devices such as hosts, routers, terminal servers, etc., which are
   monitored and controlled via access to their management information.

   It is Object Definitions for SNMP Management Frameworks ...   38
   6. Intellectual Property .......................................   47
   7. Acknowledgements ............................................   48
   8. Security Considerations .....................................   49
   9. References ..................................................   50
   10. Editor's Addresses .........................................   52
   A. Guidelines for Model Designers ..............................   53
   A.1. Security Model Design Requirements ........................   53
   A.1.1. Threats .................................................   53
   A.1.2. Security Processing .....................................   54
   A.1.3. Validate the purpose of this document to define an architecture which
   can evolve to realize effective management security-stamp 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 entities with proxy forwarder applications (traditionally
         called SNMP proxy agent),

      -  command line driven SNMP entities with command generator and/or
         notification receiver applications (traditionally called SNMP
         command line managers),

      - received message .......   54
   A.1.4. Security MIBs ...........................................   55
   A.1.5. Cached Security Data ....................................   55
   A.2. Message Processing Model Design Requirements ..............   55
   A.2.1. Receiving an SNMP entities with  command generator and/or notification
         receiver, plus command responder and/or notification originator
         applications (traditionally called Message from the Network ..............   56
   A.2.2. Sending an SNMP mid-level managers or
         dual-role entities),

      - Message to the Network ..................   56
   A.3. Application Design Requirements ...........................   56
   A.3.1. Applications that Initiate Messages .....................   57
   A.3.2. Applications that Receive Responses .....................   57
   A.3.3. Applications that Receive Asynchronous Messages .........   57
   A.3.4. Applications that Send Responses ........................   58
   A.4. Access Control Model Design Requirements ..................   58
   B. Issues ......................................................   59
   B.1. Open Issues ...............................................   59
   B.2. Change Log ................................................   59
   C. Full Copyright Statement ....................................   59

1.  Introduction

1.1.  Overview

   This document defines a vocabulary for describing SNMP entities with command generator and/or notification
         receiver Management
   Frameworks, and possibly other types of applications for managing
         a potentially very large number of managed nodes (traditionally
         called (network) management stations).

1.3.  Goals of this Architecture

   This an 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*.

      -  Address the need for secure SET support, which is considered describing the most important deficiency in SNMPv1 and SNMPv2c.

      -  Make it possible to move major 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.

      -  Keep
   SNMP as simple as possible.

      -  Make it relatively inexpensive Management Frameworks.

   This document does not provide a general introduction to deploy SNMP. Other
   documents and books can provide a minimal conforming
         implementation.

      -  Make it possible much better introduction to upgrade portions SNMP.
   Nor does this document provide a history of SNMP as new approaches
         become available, without disrupting an entire SNMP framework.

      -  Make it possible to support features required SNMP. That also can be
   found in large
         networks, but make books and other documents.

   Section 1 describes the expense purpose, goals, and design decisions of supporting this
   architecture.

   Section 2 describes various types of documents which define SNMP
   Frameworks, and how they fit into this architecture. It also provides
   a feature directly
         related minimal road map to the support of documents which have previously defined
   SNMP frameworks.

   Section 3 details the feature.

1.4.  Security Requirements vocabulary of this Architecture

   Several of the classical threats to network protocols are applicable
   to the management problem architecture and therefore would be applicable to any
   Security Model used in an SNMP Management Framework. Other threats
   are not applicable to the management problem. its pieces.
   This section discusses
   principal threats, secondary threats, is important for understanding the remaining sections,
   and threats for understanding documents which are of lesser
   importance.

   The principal threats against which any Security Model used written to fit within this architecture SHOULD provide protection are:

   Modification of Information
      The modification threat is the danger that some unauthorized SNMP
      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.

   Masquerade
      The masquerade threat is
   architecture.

   Section 4 describes the danger that management operations not
      authorized primitives used for some principal may be attempted by assuming the
      identity of another principal that has abstract service
   interfaces between the appropriate
      authorizations.

   Message Stream Modification
      The SNMP protocol is typically based upon various subsystems, models and applications
   within this architecture.

   Section 5 defines a connectionless
      transport service which may operate over any subnetwork service.
      The re-ordering, delay or replay collection of messages can managed objects used to instrument
   SNMP entities within this architecture.

   Sections 6, 7, 8, and does occur
      through the natural operation 9 are administrative in nature.

   Appendix A contains guidelines for designers 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 Models which is greater than can occur through the natural operation of a
      subnetwork service, in order are
   expected to effect unauthorized management
      operations.

   Disclosure fit within this architecture.

   The disclosure threat is the danger of eavesdropping on the
      exchanges between SNMP engines.  Protecting against key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this threat
      may
   document are to be required interpreted as a matter of local policy.

   There are at least two threats against which a Security Model within
   this architecture need not protect.

   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 described in many cases
      indistinguishable from the type of network failures [RFC2119].

1.2.  SNMP

   An SNMP management system contains:

      -  several (potentially many) nodes, each with an SNMP entity
         containing command responder and notification originator
         applications, which any
      viable management protocol must cope as a matter of course.

   Traffic Analysis
      A Security Model need not attempt have access to address traffic analysis
      attacks.  Many traffic patterns are predictable management instrumentation
         (traditionally called agents);

      - entities may be
      managed on  at least one SNMP entity containing command generator and/or
         notification receiver applications (traditionally called a regular basis by
         manager) and,

      -  a relatively small number of management stations - protocol, used to convey management information
         between the SNMP entities.

   SNMP entities executing command generator and therefore there 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.

   It is no significant
      advantage afforded by protecting against traffic analysis.

1.5.  Design Decisions

   Various design decisions were made in support of the goals purpose of the this document to define an architecture which
   can evolve to realize effective management in a variety of
   configurations and the security requirements:

      - Architecture
         An environments. The architecture should be defined which identifies the
         conceptual boundaries between the documents. Subsystems should
         be defined which describe has been designed
   to meet the abstract services provided by
         specific portions needs of an implementations of:

      -  minimal SNMP framework. Abstract service
         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 entities with command responder and/or
         notification originator applications (traditionally called SNMP framework.
         agents),

      - Self-contained Documents
         Elements of procedure  SNMP entities with proxy forwarder applications (traditionally
         called SNMP proxy agents),

      -  command line driven SNMP entities with command generator and/or
         notification receiver applications (traditionally called SNMP
         command line managers),

      -  SNMP entities with  command generator and/or notification
         receiver, plus the MIB objects which are needed for
         processing command responder and/or notification originator
         applications (traditionally called SNMP mid-level managers or
         dual-role entities),

      -  SNMP entities with command generator and/or notification
         receiver and possibly other types of applications for managing
         a specific portion potentially very large number of an SNMP framework should
         be defined in managed nodes (traditionally
         called (network) management stations).

1.3.  Goals of this Architecture

   This architecture was driven by the same document, and following goals:

      -  Use existing materials as much as possible,
         should not be referenced in other documents. This allows pieces
         to be designed and documented possible. It is heavily based
         on previous work, informally known as independent SNMPv2u and self-contained
         parts, SNMPv2*.

      -  Address the need for secure SET support, which is consistent with considered
         the general SNMP MIB module
         approach.  As most important deficiency in SNMPv1 and SNMPv2c.

      -  Make it possible to move portions of SNMP change over time, the documents
         describing other portions of SNMP are architecture forward
         in the standards track, even if consensus has not directly impacted.
         This modularity allows, for example, Security Models,
         authentication and privacy mechanisms, been reached
         on all pieces.

      -  Define an architecture that allows for longevity of the SNMP
         Frameworks that have been and message formats to will be upgraded and supplemented defined.

      -  Keep SNMP as the need arises. The self-
         contained documents can move along the standards track on
         different time-lines. simple as possible.

      - Threats
         The Security Models  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.

      -  Make it possible to support features required in large
         networks, but make the Security Subsystem SHOULD protect
         against the principal threats: modification expense of information,
         masquerade, message stream modification and disclosure.  They
         do not need supporting a feature directly
         related to protect against denial the support of service and traffic
         analysis.

      - Remote Configuration
         The the feature.

1.4.  Security and Access Control Subsystems add a whole new set Requirements of SNMP configuration parameters.  The Security Subsystem also
         requires frequent changes this Architecture

   Several of secrets at the various SNMP
         entities. To make this deployable in a large operational
         environment, these SNMP parameters must be able classical threats to be remotely
         configured.

      - Controlled Complexity
         It is recognized that producers of simple managed devices want network protocols are applicable
   to keep the resources management problem and therefore would be applicable to any
   Security Model used by in an SNMP Management Framework. Other threats
   are not applicable to a minimum.  At the same
         time, there is a need for more complex configurations management problem.  This section discusses
   principal threats, secondary threats, and threats which can
         spend more resources for SNMP and thus are of lesser
   importance.

   The principal threats against which any Security Model used within
   this architecture SHOULD provide more
         functionality. protection are:

   Modification of Information
      The design tries to keep modification threat is the competing
         requirements danger that some unauthorized SNMP
      entity may alter in-transit SNMP messages generated on behalf of these two environments
      an authorized principal in balance and allows
         the more complex environments such a way as to logically extend effect unauthorized
      management operations, including falsifying the simple
         environment.

2.  Documentation Overview value of an
      object.

   Masquerade
      The following figure shows masquerade threat is the set danger that management operations not
      authorized for some principal may be attempted by assuming the
      identity of documents another principal that fit within has the
   SNMP Architecture.

   +------------------------- Document Set ----------------------------+
   |                                                                   |
   | +------------+            +-----------------+  +----------------+ |
   | | Document * |            | Applicability * |  | Coexistence  * | |
   | | Roadmap    |            | Statement       |  | & Transition   | |
   | +------------+            +-----------------+  +----------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | Message Handling                                              | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | | | Transport      |  | appropriate
      authorizations.

   Message         |  | Security        |  | |
   | | | Mappings       |  | Processing 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  |  |                 |  | |
   | | |                |  | Dispatcher      |  |                 |  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | PDU Handling                                                  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | | | Protocol       |  | Applications    |  | Access          |  | |
   | | | Operations     |  |                 |  | Control         |  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | Information Model                                             | |
   | | +--------------+   +--------------+    +---------------+      | |
   | | | Structure of |   | Textual      |    | Conformance   |      | |
   | | | Management   |   | Conventions  |    | Statements    |      | |
   | | | Information  |   |              |    |               |      | |
   | | +--------------+   +--------------+    +---------------+      | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | MIBs                                                          | |
   | | +-------------+ +-------------+ +----------+ +----------+     | |
   | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 |     | |
   | | | RFC1157     | | RFC1212     | | RFC14xx  | | RFC19xx  |     | |
   | | | format      | | format      | | format   | | format   |     | |
   | | +-------------+ +-------------+ +----------+ +----------+     | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   +-------------------------------------------------------------------+

   Those marked with an asterisk (*) are expected to be written in does occur
      through the
   future. Each natural operation of these documents many such subnetwork services.
      The message stream modification threat is the danger that messages
      may be replaced maliciously re-ordered, delayed or supplemented.
   This Architecture document specifically describes how new documents
   fit into the set of documents in replayed to an extent
      which is greater than can occur through the area natural operation of Message and PDU
   handling.

2.1.  Document Roadmap

   One or more documents may be written a
      subnetwork service, in order to describe how sets of
   documents taken together form specific Frameworks. effect unauthorized management
      operations.

   Disclosure
      The configuration disclosure threat is the danger of document sets might change over time, so eavesdropping on the "road map" should
      exchanges between SNMP engines.  Protecting against this threat
      may be
   maintained in required as a document separate from the standards documents
   themselves.

2.2.  Applicability Statement

   SNMP is used in networks that vary widely in size and complexity, by
   organizations that vary widely in their requirements matter of management.
   Some models will be designed local policy.

   There are at least two threats against which a Security Model within
   this architecture need not protect.

   Denial of Service
      A Security Model need not attempt to address specific problems the broad range of
   management,
      attacks by which service on behalf of authorized users is denied.
      Indeed, such as message security.

   One or more documents may be written to describe denial-of-service attacks are in many cases
      indistinguishable from the environments to
   which certain versions type of SNMP or models within SNMP would be
   appropriately applied, and those to network failures with which any
      viable management protocol must cope as a given model might be
   inappropriately applied.

2.3.  Coexistence and Transition

   The purpose matter of an evolutionary architecture is to permit new models course.

   Traffic Analysis
      A Security Model need not attempt to replace or supplement existing models. The interactions between
   models could result in incompatibilities, security "holes", and other
   undesirable effects.

   The purpose address traffic analysis
      attacks.  Many traffic patterns are predictable - entities may be
      managed on a regular basis by a relatively small number of Coexistence documents is to detail recognized
   anomalies
      management stations - and to describe required therefore there is no significant
      advantage afforded by protecting against traffic analysis.

1.5.  Design Decisions

   Various design decisions were made in support of the goals of the
   architecture and recommended behaviors for
   resolving the interactions security requirements:

      - Architecture
         An architecture should be defined which identifies the
         conceptual boundaries between models within the architecture.

   Coexistence documents may documents. Subsystems should
         be prepared separately from model
   definition documents, to defined which 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.

2.4.  Transport Mappings

   SNMP messages are sent over various transports. It is the purpose abstract services provided by
         specific portions of
   Transport Mapping documents to an SNMP framework. Abstract service
         interfaces, as described by service primitives, define how the mapping
         abstract boundaries between SNMP documents, and the transport is done.

2.5.  Message Processing

   A Message Processing Model document defines a message format, which
   is typically identified abstract
         services that are provided by a version field in the conceptual subsystems of an
         SNMP message header.
   The document may also define a framework.

      - Self-contained Documents
         Elements of procedure plus the MIB module objects which are needed for use in message
         processing and for instrumentation a specific portion of version-specific interactions.

   An an SNMP engine includes one or more Message Processing Models, and
   thus may support sending and receiving multiple versions of SNMP
   messages.

2.6.  Security

   Some environments require secure protocol interactions. Security is
   normally applied at two different stages:

      - framework should
         be defined in the transmission/receipt of messages, 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 processing general SNMP MIB module
         approach.  As portions of SNMP change over time, the contents of messages.

   For purposes documents
         describing other portions of this document, "security" refers to message-level
   security; "access control" refers to the security applied to protocol
   operations.

   Authentication, encryption, and timeliness checking SNMP are common
   functions of message level security.

   A security document describes a not directly impacted.
         This modularity allows, for example, Security Model, the threats against
   which the model protects, Models,
         authentication and privacy mechanisms, and message formats to
         be upgraded and supplemented as the goals of need arises. The self-
         contained documents can move along the standards track on
         different time-lines.

      - Threats
         The Security Model, Models in the
   protocols which it uses to meet those goals, and it may define a MIB
   module to describe Security Subsystem SHOULD protect
         against the data used during processing, principal threats: modification of information,
         masquerade, message stream modification and disclosure.  They
         do not need to allow the
   remote configuration protect against denial of message-level security parameters, such as
   passwords.

   An SNMP engine may support multiple service and traffic
         analysis.

      - Remote Configuration
         The Security Models concurrently.

2.7. and Access Control

   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 Subsystems add a MIB module used during processing and to allow the
   remote whole new set
         of SNMP configuration parameters.  The Security Subsystem also
         requires frequent changes of access control policies.

2.8.  Protocol Operations secrets at the various SNMP messages encapsulate an
         entities. To make this deployable in a large operational
         environment, these SNMP Protocol Data Unit (PDU). parameters must be able to be remotely
         configured.

      - Controlled Complexity
         It is the
   purpose of a Protocol Operations document to define the operations recognized that producers of
   the protocol with respect simple managed devices want
         to keep the processing of the PDUs.

   An application document defines which Protocol Operations documents
   are supported resources used by the application.

2.9.  Applications

   An SNMP entity normally includes to a number of applications.
   Applications use minimum.  At the services of an same
         time, there is a need for more complex configurations which can
         spend more resources for SNMP engine to accomplish
   specific tasks. They coordinate the processing of management
   information operations, and may use SNMP messages thus provide more
         functionality.  The design tries to communicate with
   other SNMP entities.

   Applications documents describe the purpose of an application, keep the
   services required competing
         requirements of the associated SNMP engine, and the protocol
   operations these two environments in balance and informational model that allows
         the application uses more complex environments to
   perform management operations.

   An application document defines which logically extend the simple
         environment.

2.  Documentation Overview

   The following figure shows the set of documents are used to
   specifically define that fit within the structure of management information, textual
   conventions, conformance requirements,
   SNMP Architecture.

   +------------------------- Document Set ----------------------------+
   |                                                                   |
   | +------------+            +-----------------+  +----------------+ |
   | | Document * |            | Applicability * |  | Coexistence  * | |
   | | Roadmap    |            | Statement       |  | & Transition   | |
   | +------------+            +-----------------+  +----------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | Message Handling                                              | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | | | Transport      |  | Message         |  | Security        |  | |
   | | | Mappings       |  | Processing and operations supported by
   the application.

2.10.  Structure of Management Information

   Management information is viewed as a collection of managed objects,
   residing in a virtual information store, termed the Management  |  |                 |  | |
   | | |                |  | Dispatcher      |  |                 |  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | PDU Handling                                                  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | | | Protocol       |  | Applications    |  | Access          |  | |
   | | | Operations     |  |                 |  | Control         |  | |
   | | +----------------+  +-----------------+  +-----------------+  | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | Information Base (MIB). Collections of related objects are defined in
   MIB modules.

   It is the purpose of a Model                                             | |
   | | +--------------+   +--------------+    +---------------+      | |
   | | | Structure of Management Information document
   to establish the syntax for defining objects, modules, and other
   elements of managed information.

2.11. |   | Textual Conventions

   When designing a MIB module, it is often useful to define new types
   similar      |    | Conformance   |      | |
   | | | Management   |   | Conventions  |    | Statements    |      | |
   | | | Information  |   |              |    |               |      | |
   | | +--------------+   +--------------+    +---------------+      | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   | +---------------------------------------------------------------+ |
   | | MIBs                                                          | |
   | | +-------------+ +-------------+ +----------+ +----------+     | |
   | | | Standard v1 | | Standard v1 | | Historic | | Draft v2 |     | |
   | | | RFC1157     | | RFC1212     | | RFC14xx  | | RFC19xx  |     | |
   | | | format      | | format      | | format   | | format   |     | |
   | | +-------------+ +-------------+ +----------+ +----------+     | |
   | +---------------------------------------------------------------+ |
   |                                                                   |
   +-------------------------------------------------------------------+

   Those marked with an asterisk (*) are expected to those defined be written 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
   future. Each of these documents may defined be replaced or supplemented.
   This Architecture document specifically describes how new documents
   fit into the set of documents in
   separate documents, the area of Message and PDU
   handling.

2.1.  Document Roadmap

   One or within a MIB module.

2.12.  Conformance Statements

   It more documents may be useful written to define the acceptable lower-bounds describe how sets of
   implementation, along with the actual level
   documents taken together form specific Frameworks. The configuration
   of implementation
   achieved. It is document sets might change over time, so the purpose of Conformance Statements to define the
   notation used for these purposes.

2.13.  Management Information Base Modules

   MIB documents describe collections of managed objects which
   instrument some aspect of "road map" should be
   maintained in a managed node.

2.13.1.  SNMP Instrumentation MIBs

   An SNMP MIB document may define a collection of managed objects which
   instrument separate from the standards documents
   themselves.

2.2.  Applicability Statement

   SNMP protocol itself. In addition, MIB modules may 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
   defined within the documents which describe portions designed to address specific problems of the SNMP
   architecture,
   management, such as the message security.

   One or more documents for Message processing Models,
   Security Models, etc. for may be written to describe the purpose environments to
   which certain versions of instrumenting SNMP or models within SNMP would be
   appropriately applied, and those Models, to which a given model might be
   inappropriately applied.

2.3.  Coexistence and for the Transition

   The purpose of allowing remote configuration of the Model.

2.14.  SNMP Framework Documents

   This an evolutionary architecture is designed to allow an orderly evolution of
   portions of SNMP Frameworks.

   Throughout the rest of this document, the term "subsystem" refers permit new models
   to
   an abstract replace or supplement existing models. The interactions between
   models could result in incompatibilities, security "holes", and incomplete specification of a portion other
   undesirable effects.

   The purpose of a Framework,
   that Coexistence documents is further refined by a model specification.

   A "model" describes a specific design of a subsystem, defining
   additional constraints to detail recognized
   anomalies and rules for conformance to describe required and recommended behaviors for
   resolving the model.  A
   model is sufficiently detailed to make it possible to implement the
   specification.

   An "implementation" is an instantiation of a subsystem, conforming 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 specific models.

   SNMP version 1 (SNMPv1), is the original Internet-standard Network
   Management Framework, as described other model definitions.

   Additionally, recommendations for transitions between models may also
   be described, either in RFCs 1155, 1157, and 1212. a coexistence document or in a separate
   document.

2.4.  Transport Mappings

   SNMP version 2 (SNMPv2), messages are sent over various transports. It is the SNMPv2 Framework as derived from purpose of
   Transport Mapping documents to define how the
   SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no
   message definition.

   The Community-based SNMP version 2 (SNMPv2c), is an experimental mapping between SNMP
   Framework which supplements the SNMPv2 Framework, as described in
   RFC1901. It adds
   and the SNMPv2c transport is done.

2.5.  Message Processing

   A Message Processing Model document defines a message format, which
   is similar to the
   SNMPv1 message format.

   SNMP version 3 (SNMPv3), is an extensible SNMP Framework which
   supplements the SNMPv2 Framework, typically identified by supporting the following:

      - a new version field in an SNMP message format,

      -  Security header.
   The document may also define a MIB module for Messages, use in message
   processing and

      -  Access Control.

   Other for instrumentation of version-specific interactions.

   An SNMP Frameworks, i.e., other configurations engine includes one or more Message Processing Models, and
   thus may support sending and receiving multiple versions of implemented
   subsystems, are expected to also be consistent with this
   architecture.

3.  Elements SNMP
   messages.

2.6.  Security

   Some environments require secure protocol interactions. Security is
   normally applied at two different stages:

      -  in the transmission/receipt of messages, and

      -  in the Architecture

   This section describes processing of the various elements contents of messages.

   For purposes of this document, "security" refers to message-level
   security; "access control" refers to the architecture security applied to protocol
   operations.

   Authentication, encryption, and
   how they are named. There timeliness checking are three kinds common
   functions of naming:

      1) message level security.

   A security document describes a Security Model, the naming of entities,

      2) threats against
   which the naming model protects, the goals of identities, the Security Model, the
   protocols which it uses to meet those goals, and

      3) it may define a MIB
   module to describe the naming of management information.

   This architecture also defines some names for other constructs that
   are data used in during processing, and to allow the documentation.

3.1.  The Naming
   remote configuration of Entities

   The following figure shows detail about an SNMP entity and how
   components within it are named.

   +-------------------------------------------------------------------+
   |  SNMP entity                                                      |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  | message-level security parameters, such as
   passwords.

   An SNMP engine (identified by snmpEngineID)                   |  |
   |  |                                                             |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |  |            | |            | |           | |           |  |  |
   |  |  | Dispatcher | | Message    | | may support multiple Security  | | Models concurrently.

2.7.  Access    |  |  |
   |  |  |            | | Processing | | Subsystem | | Control   |  |  |
   |  |  |            | | Subsystem  | |           | | Subsystem |  |  |
   |  |  |            | |            | |           | |           |  |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |                                                             |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  Application(s)                                             |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |  | Command     |  | Notification |  | Proxy        |        |  |
   |  |  | Generator   |  | Receiver     |  | Forwarder    |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |  | Command     |  | Notification |  | Other        |        |  |
   |  |  | Responder   |  | Originator   |  |              |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |                                                             |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

3.1.1.  SNMP entity

   An SNMP entity is an implementation of this architecture. Each such
   SNMP entity consists of an SNMP engine and one or more associated
   applications.

3.1.2.  SNMP engine

   An SNMP engine provides services

   During processing, it may be required to control access to managed
   objects for sending and receiving messages,
   authenticating and encrypting messages, and controlling operations.

   An Access Control Model defines mechanisms to determine whether
   access to a managed objects. There is object should be allowed.  An Access Control
   Model may define a one-to-one association between an SNMP
   engine MIB module used during processing and to allow the
   remote configuration of access control policies.

2.8.  Protocol Operations

   SNMP entity which contains it.

   The engine contains:

      1) a Dispatcher,

      2) a Message Processing Subsystem,

      3) a Security Subsystem, and

      4) an Access Control Subsystem.

3.1.3.  snmpEngineID

   Within an administrative domain, messages encapsulate an snmpEngineID SNMP Protocol Data Unit (PDU). It is the unique and
   unambiguous identifier
   purpose of an SNMP engine. Since there is a one-to-one
   association between SNMP engines and SNMP entities, it also uniquely
   and unambiguously identifies Protocol Operations document to define the SNMP entity.

3.1.4.  Dispatcher

   There is only one Dispatcher in an SNMP engine. It allows for
   concurrent support operations of multiple versions
   the protocol with respect to the processing of the PDUs.

   An application document defines which Protocol Operations documents
   are supported by the application.

2.9.  Applications

   An SNMP messages in entity normally includes a number of applications.
   Applications use the services of an SNMP
   engine. It does so by:

      -  sending engine to accomplish
   specific tasks. They coordinate the processing of management
   information operations, and receiving may use SNMP messages to/from the network,

      -  determining to communicate with
   other SNMP entities.

   Applications documents describe the version purpose of an application, the
   services required of the associated SNMP message engine, and interact with the corresponding Message Processing Model,

      -  providing an abstract interface protocol
   operations and informational model that the application uses to SNMP applications for
         delivery
   perform management operations.

   An application document defines which set of a PDU documents are used to an
   specifically define the structure of management information, textual
   conventions, conformance requirements, and operations supported by
   the application.

      -  providing an abstract interface for SNMP applications that
         allows them to send

2.10.  Structure of Management Information

   Management information is viewed as a PDU to collection of managed objects,
   residing in a remote SNMP entity.

3.1.5.  Message Processing Subsystem

   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 virtual information store, termed 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      |  |
   |  |            |  |            |  |            |  |            |  |
   |  +------------+  +------------+  +------------+  +------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.6.  Message Processing Model

   Each Message Processing Model defines Management
   Information Base (MIB). Collections of related objects are defined in
   MIB modules.

   It is the format purpose of a particular
   version of an SNMP message and coordinates the preparation and
   extraction Structure of each such version-specific messages.

3.1.7.  Security Subsystem

   The Security Subsystem provides security services such as Management Information document
   to establish the
   authentication syntax for defining objects, modules, and privacy other
   elements of messages and potentially contains
   multiple Security Models as shown managed information.

2.11.  Textual Conventions

   When designing a MIB module, it is often useful to define new types
   similar to those defined in the following figure

   * One or SMI, but with more Security Models precise semantics,
   or which have special semantics associated with them. These newly
   defined types are termed textual conventions, and may defined in
   separate documents, or within a MIB module.

2.12.  Conformance Statements

   It may be present.

   +------------------------------------------------------------------+
   |                                                                  |
   |  Security Subsystem                                              |
   |                                                                  |
   |  +----------------+  +-----------------+  +-------------------+  |
   |  |              * |  |               * |  |                 * |  |
   |  | User-Based     |  | Other           |  | Other             |  |
   |  | Security       |  | Security        |  | Security          |  |
   |  | Model          |  | Model           |  | Model             |  |
   |  |                |  |                 |  |                   |  |
   |  +----------------+  +-----------------+  +-------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.8.  Security Model

   A Security Model defines useful to define the threats against which it protects, acceptable lower-bounds of
   implementation, along with the
   goals actual level of its services, and implementation
   achieved. It is the security protocols used purpose of Conformance Statements to provide
   security services such as authentication and privacy.

3.1.9.  Security Protocol

   A Security Protocol defines define the mechanisms, procedures, and MIB data
   notation used to provide for these purposes.

2.13.  Management Information Base Modules

   MIB documents describe collections of managed objects which
   instrument some aspect of a security service managed node.

2.13.1.  SNMP Instrumentation MIBs

   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 authentication or privacy.

3.1.10.  Access Control Subsystem

   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            |  |
   |  |               |   |                 |   |                  |  |
   |  +---------------+   +-----------------+   +------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.11.  Access Control Model

   An Access Control Model defines a particular access decision function
   in order to support decisions regarding access rights.

3.1.12.  Applications

   There are several types the documents for Message processing Models,
   Security Models, etc. for the purpose 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, instrumenting those Models,
   and

      -  proxy forwarders, which forward messages between entities.

   These applications make use of for the services provided by purpose of allowing remote configuration of the Model.

2.14.  SNMP
   engine.

3.1.13.  SNMP Manager

   An SNMP entity containing one or more command generator and/or
   notification receiver applications (along with their associated SNMP
   engine) has traditionally been called Framework Documents

   This architecture is designed to allow an orderly evolution of
   portions of SNMP manager.
   * 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            |
   +------------------------------+

3.1.14.  SNMP Agent

   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 |
   +-------------------------------------------------------------------+

3.2.  The Naming of Identities

                            principal
                                ^
                                |
                                |
   +----------------------------|-------------+
   | SNMP engine                v             |
   |                    +--------------+      |
   |                    |              |      |
   |  +-----------------| securityName |---+  |
   |  | Security Model  |              |   |  |
   |  |                 +--------------+   |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  |                         v          |  |
   |  |  +------------------------------+  |  |
   |  |  |                              |  |  |
   |  |  | Model                        |  |  |
   |  |  | Dependent                    |  |  |
   |  |  | Security ID                  |  |  |
   |  |  |                              |  |  |
   |  |  +------------------------------+  |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  +-------------------------|----------+  |
   |                            |             |
   |                            |             |
   +----------------------------|-------------+
                                |
                                v
                               wire

3.2.1.  Principal

   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.

3.2.2.  securityName

   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.

3.2.3.  Model-dependent security ID

   A model-dependent security ID is the model-specific representation of
   a securityName within a particular Security Model.

   Model-dependent security IDs may or may not be human readable, and
   have a model-dependent syntax. Examples include community names, user
   names, and parties.

   The transformation of model-dependent security IDs into securityNames
   and vice versa is the responsibility of the relevant Security Model.

3.3.  The Naming of Management Information

   Management information resides at an SNMP entity where a Command
   Responder Application has local access to potentially multiple
   contexts. Such a Command Responder application uses a contextEngineID
   equal to the snmpEngineID of its associated SNMP engine.

   +-----------------------------------------------------------------+
   |  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 | | | | other MIB  | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | | | some  MIB  | |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   +-----------------------------------------------------------------+

3.3.1.  An SNMP Context

   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
   engine potentially has access to many contexts.

   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.

   For example, the managed object type ifDescr [RFC1573], 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").

   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.

3.3.2.  contextEngineID

   Within an administrative domain, a contextEngineID uniquely
   identifies an SNMP entity that may realize an instance of a context
   with a particular contextName.

3.3.3.  contextName

   A contextName is used to name a context. Each contextName MUST be
   unique within an SNMP entity.

3.3.4.  scopedPDU

   A scopedPDU is a block of data containing a contextEngineID, a
   contextName, and a 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.

3.4.  Other Constructs

3.4.1.  maxSizeResponseScopedPDU

   The maxSizeResponseScopedPDU is the maximum size of a scopedPDU to be
   included in a response message.  Note that the size of a scopedPDU
   does not include the size of the SNMP message header.

3.4.2.  Local Configuration Datastore

   The subsystems, models, and applications within an SNMP entity may
   need to retain their own sets of configuration information.

   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).

3.4.3.  securityLevel

   This architecture recognizes three levels of security:

      -  without authentication and without privacy (noAuthNoPriv)

      -  with authentication but without privacy (authNoPriv)

      -  with authentication and with privacy (authPriv)

   These three values are ordered such that noAuthNoPriv is less than
   authNoPriv and authNoPriv is less than 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.

4.  Abstract Service Interfaces.

   Abstract service interfaces have been defined to describe the
   conceptual interfaces between the various subsystems within an SNMP
   entity.

   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.

4.1.  Common Primitives

   These primitive(s) are provided by multiple Subsystems.

4.1.1.  Release State Reference Information

   All Subsystems which pass stateReference information also provide a
   primitive to release the memory that holds the referenced state
   information:

   stateRelease(
     IN   stateReference       -- handle of reference to be released
          )

4.2.  Dispatcher Primitives

   The Dispatcher typically provides services to the SNMP applications
   via its PDU Dispatcher.  This section describes the primitives
   provided by the PDU Dispatcher.

4.2.1.  Generate Outgoing Request or Notification

   The PDU Dispatcher provides the following primitive for an
   application to send an SNMP Request or Notification to another SNMP
   entity:

   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
          )

4.2.2.  Process Incoming Request or Notification PDU

   The PDU Dispatcher provides the following primitive to pass an
   incoming SNMP PDU to an application:

   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 Frameworks.

   Throughout the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size rest of this document, the Response PDU
     IN   stateReference            -- reference term "subsystem" refers to state information
          )                         -- needed when sending
   an abstract and incomplete specification of a response

4.2.3.  Generate Outgoing Response

   The PDU Dispatcher provides the following primitive 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 an
   application conformance to return an SNMP Response PDU the model.  A
   model is sufficiently detailed to make it possible to implement the PDU Dispatcher:

   returnResponsePdu(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model in use
     IN   securityName              -- on behalf
   specification.

   An "implementation" is an instantiation of this principal
     IN   securityLevel             -- same as on incoming request
     IN   contextEngineID           -- data from/at this a subsystem, conforming to
   one or more specific models.

   SNMP entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the version of 1 (SNMPv1), is the PDU
     IN   PDU                       -- original Internet-standard Network
   Management Framework, as described in RFCs 1155, 1157, and 1212.

   SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size of version 2 (SNMPv2), is the Response PDU
     IN   stateReference            -- reference to state information
                                    -- SNMPv2 Framework as presented with the request
     IN   statusInformation         -- success or errorIndication
          )                         -- error counter OID/value if error

4.2.4.  Process Incoming Response PDU

   The PDU Dispatcher provides derived from the following primitive to pass
   SNMPv1 Framework. It is described in RFCs 1902-1907. SNMPv2 has no
   message definition.

   The Community-based SNMP version 2 (SNMPv2c), is an
   incoming experimental SNMP Response PDU
   Framework which supplements the SNMPv2 Framework, as described in
   RFC1901. It adds the SNMPv2c message format, which is similar to an application:

   processResponsePdu(              -- process Response PDU
     IN   messageProcessingModel    -- typically, the
   SNMPv1 message format.

   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 3 (SNMPv3), is an extensible SNMP entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- Framework which
   supplements the version of SNMPv2 Framework, by supporting the PDU
     IN   PDU                       -- following:

      -  a new SNMP Protocol Data Unit
     IN   statusInformation         -- success or errorIndication
     IN   sendPduHandle             -- handle from sendPdu
          )

4.2.5.  Registering Responsibility message format,

      -  Security for Handling Messages, and

      -  Access Control.

   Other SNMP PDUs.

   Applications can register/unregister responsibility for a specific
   contextEngineID, for specific pduTypes, Frameworks, i.e., other configurations of implemented
   subsystems, are expected to also be consistent with this
   architecture.

3.  Elements of the PDU Dispatcher
   according to these primitives:

   statusInformation =            -- success or errorIndication
     registerContextEngineID(
     IN   contextEngineID         -- take responsibility Architecture

   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,

      2) the naming of identities, and

      3) the naming of management information.

   This architecture also defines some names for other constructs that
   are used in the documentation.

3.1.  The Naming of Entities

   An SNMP entity is an implementation of this architecture. Each such
   SNMP entity consists of an SNMP engine and one
     IN   pduType                 -- or more associated
   applications.

   The following figure shows details about an SNMP entity and the pduType(s) to be registered
          )

   unregisterContextEngineID(
     IN   contextEngineID         -- give up responsibility
   components within it.

   +-------------------------------------------------------------------+
   |  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   |  |              |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |  |                                                             |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

3.1.1.  SNMP engine

   An SNMP engine provides services for this one
     IN   pduType                 -- the pduType(s) to be unregistered
          )

   Note that realizations of the registerContextEngineID sending and
   unregisterContextEngineID abstract service interfaces may provide
   implementation-specific ways for applications receiving messages,
   authenticating and encrypting messages, and controlling access to register/deregister
   responsiblity for all possible values of
   managed objects. There is a one-to-one association between an SNMP
   engine and the contextEngineID or
   pduType parameters.

4.3.  Message Processing Subsystem Primitives SNMP entity which contains it.

   The Dispatcher interacts with engine contains:

      1) a Dispatcher,

      2) a Message Processing Model to process Subsystem,

      3) a
   specific version Security Subsystem, and
      4) an Access Control Subsystem.

3.1.1.1.  snmpEngineID

   Within an administrative domain, an snmpEngineID is the unique and
   unambiguous identifier of an SNMP Message. This section describes the
   primitives provided by engine. Since there is a one-to-one
   association between SNMP engines and SNMP entities, it also uniquely
   and unambiguously identifies the Message Processing Subsystem.

4.3.1.  Prepare Outgoing SNMP Request or Notification Message

   The Message Processing Subsystem provides this service primitive for
   preparing entity.

3.1.1.2.  Dispatcher

   There is only one Dispatcher in an outgoing SNMP Request or Notification Message:

   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 engine. It allows for
   concurrent support of this principal
     IN   securityLevel             -- Level multiple versions of Security requested
     IN   contextEngineID           -- data from/at this entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- SNMP messages in the SNMP
   engine. It does so by:

      -  sending and receiving SNMP messages to/from the network,

      -  determining the version of the PDU
     IN   PDU                       -- an SNMP Protocol Data Unit
     IN   expectResponse            -- TRUE or FALSE
     IN   sendPduHandle             -- message and interacting with
         the handle corresponding Message Processing Model,

      -  providing an abstract interface to SNMP applications for matching
                                    -- incoming responses
     OUT  destTransportDomain       -- destination transport domain
     OUT  destTransportAddress      -- destination transport address
     OUT  outgoingMessage           -- the message
         delivery of a PDU to send
     OUT  outgoingMessageLength     -- its length
          )

4.3.2.  Prepare an Outgoing application.

      -  providing an abstract interface for SNMP Response applications that
         allows them to send a PDU to a remote SNMP entity.

3.1.1.3.  Message Processing Subsystem

   The Message Processing Subsystem provides this service primitive is responsible for preparing an outgoing SNMP Response Message:

   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               --
   messages for sending, and extracting data from/in this context
     IN   pduVersion                -- 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      |  |
   |  |            |  |            |  |            |  |            |  |
   |  +------------+  +------------+  +------------+  +------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.1.3.1.  Message Processing Model

   Each Message Processing Model defines the format of a particular
   version of the PDU
     IN   PDU                       -- an SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size of the Response PDU
     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           -- message and coordinates the preparation and
   extraction of each such version-specific message to send
     OUT  outgoingMessageLength     -- its length
          )

4.3.3.  Prepare Data Elements from an Incoming SNMP Message format.

3.1.1.4.  Security Subsystem

   The Message Processing Security Subsystem provides this service primitive for
   preparing the abstract data elements from an incoming SNMP message:

   result =                         -- SUCCESS or errorIndication
     prepareDataElements(
     IN   transportDomain           -- origin transport domain
     IN   transportAddress          -- origin transport address
     IN   wholeMsg                  -- security services such as received from the network
     IN   wholeMsgLength            --
   authentication and privacy of messages and potentially contains
   multiple Security Models as received from shown in the network
     OUT  messageProcessingModel    -- typically, SNMP version
     OUT  securityModel             -- following figure

   * One or more Security Models may be present.

   +------------------------------------------------------------------+
   |                                                                  |
   |  Security Subsystem                                              |
   |                                                                  |
   |  +----------------+  +-----------------+  +-------------------+  |
   |  |              * |  |               * |  |                 * |  |
   |  | User-Based     |  | Other           |  | Other             |  |
   |  | Security       |  | Security        |  | Security          |  |
   |  | Model to use
     OUT  securityName              -- on behalf of this principal
     OUT  securityLevel             -- Level of          |  | Model           |  | Model             |  |
   |  |                |  |                 |  |                   |  |
   |  +----------------+  +-----------------+  +-------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.1.4.1.  Security requested
     OUT  contextEngineID           -- data from/at this entity
     OUT  contextName               -- data from/in this context
     OUT  pduVersion                -- Model

   A Security Model defines the version of threats against which it protects, the PDU
     OUT  PDU                       -- SNMP Protocol Data Unit
     OUT  pduType                   -- SNMP PDU type
     OUT  sendPduHandle             -- handle for matched request
     OUT  maxSizeResponseScopedPDU  -- maximum size
   goals of its services, and the Response PDU
     OUT  statusInformation         -- success or errorIndication
                                    -- error counter OID/value if error
     OUT  stateReference            -- reference to state information
                                    -- security protocols used to be provide
   security services such as authentication and privacy.

3.1.1.4.2.  Security Protocol

   A Security Protocol defines the mechanisms, procedures, and MIB data
   used for possible Response
          )

4.4. to provide a security service such as authentication or privacy.

3.1.2.  Access Control Subsystem

   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 Subsystem Primitives

   Applications are the typical clients of the service(s) of the       |   | Control         |   | Control          |  |
   |  | Model         |   | Model           |   | Model            |  |
   |  |               |   |                 |   |                  |  |
   |  +---------------+   +-----------------+   +------------------+  |
   |                                                                  |
   +------------------------------------------------------------------+

3.1.2.1.  Access Control Subsystem.

   The following primitive is provided by the Model

   An Access Control Subsystem
   to check if access is allowed:

   statusInformation =              -- success or errorIndication
     isAccessAllowed(
     IN   securityModel             -- Security Model defines a particular access decision function
   in use
     IN   securityName              -- principal who wants order to support decisions regarding 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
          )

4.5.  Security Subsystem Primitives

   The Message Processing Subsystem is the typical client of the
   services of the Security Subsystem.

4.5.1.  Generate a Request or Notification Message

   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 rights.

3.1.3.  Applications

   There are several types of Security requested
     IN   scopedPDU                 -- message (plaintext) payload
     OUT  securityParameters        -- filled in by Security Module
     OUT  wholeMsg                  -- complete generated message
     OUT  wholeMsgLength            -- length 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 generated message
          )

4.5.2.  Process Incoming Message

   The Security Subsystem provides services provided by the following primitive to process SNMP
   engine.

3.1.3.1.  SNMP Manager

   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
   incoming message:

   statusInformation =              -- errorIndication SNMP manager.
   * One or success
                                    -- error counter OID/value if error
     processIncomingMsg(
     IN   messageProcessingModel    -- typically, more models may be present.

                       (traditional SNMP version
     IN   maxMessageSize            -- of the sending manager)
   +-------------------------------------------------------------------+
   | +--------------+  +--------------+  +--------------+  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 of the Response PDU
     OUT  securityStateReference    -- reference to security state
          )                         -- information, needed for response

4.5.3.  Generate a Response |
   | | NOTIFICATION |  | NOTIFICATION |  |   COMMAND    |              |
   | |  ORIGINATOR  |  |   RECEIVER   |  |  GENERATOR   |              |
   | | applications |  | applications |  | applications |              |
   | +--------------+  +--------------+  +--------------+              |
   |         ^                ^                 ^                      |
   |         |                |                 |                      |
   |         v                v                 v                      |
   |         +-------+--------+-----------------+                      |
   |                 ^                                                 |
   |                 |     +---------------------+  +----------------+ |
   |                 |     | Message

   The Processing  |  | Security       | |
   | Dispatcher      v     | 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           |  | 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            |
   +------------------------------+

3.1.3.2.  SNMP entity
     IN   securityModel             -- for the outgoing message
     IN   securityEngineID          -- authoritative Agent

   An 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
          )

4.6.  Common Primitives

   These primitive(s) are provided by multiple Subsystems.

4.6.1.  Release State Reference Information

   All Subsystems which pass stateReference information also provide a
   primitive to release the memory that holds the referenced state
   information:

   stateRelease(
     IN   stateReference       -- handle of reference to be released
          )

4.7.  Scenario Diagrams

4.7.1.  Command Generator or Notification Originator

   This diagram shows how a Command Generator containing one or Notification Originator
   application requests that a PDU be sent, and how the response is
   returned (asynchronously) to that application.

   Command           Dispatcher 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
   Generator       |                     Processing           Model |
   |                     Model Dispatcher   v        | Subsystem           |  | Subsystem      | |
   | +-------------------+ |     +------------+  |  |                | |
   | | Transport         | |  +->| v1MP     * |<--->| +------------+ | |
   | | Mapping           |      sendPdu |  |  +------------+  |
   |------------------->|  | | Other      | | prepareOutgoingMessage |
   |
   :                    |----------------------->| |
   : (e.g. RFC1906)    | | generateRequestMsg  |
   :  +------------+  |                        |-------------------->|
   :  | | Security   |
   : |                        |<--------------------|
   : |
   | |
   :                    |<-----------------------|                   |
   : |  +->| v2cMP    * |<--->| | Model      |
   :                    |------------------+ | |
   :
   | Send SNMP | Message           | |
   :  | Request Message  +------------+  |  | +------------+ |
   : | to Network
   | | Dispatcher  <--------->|  +------------+  |
   :  |                  v +------------+ | |
   :                    :                  :     :                     :
   :                    :                  :     :                     :
   :                    :                  :     :                     :
   :
   | |                   | |
   :  +->| v3MP     * |<--->| | Receive SNMP User-based | | |
   :
   | Response Message |                   | |
   :  | from Network  +------------+  |  | |
   :                    |<-----------------+ Security   | |
   : |
   | |
   : PDU Dispatcher    |   prepareDataElements |  |
   :                    |----------------------->|  +------------+  |
   :  | | processIncomingMsg Model      |
   : |                        |-------------------->|
   : |
   | +-------------------+ |
   :  +->| otherMP  * |<--->| +------------+ |                        |<--------------------|
   : |
   |              ^        |
   :                    |<-----------------------|     +------------+  |  | processResponsePdu                | |
   |
   |<-------------------|              |        +---------------------+  +----------------+ |
   |              v                                                    |
   |      +-------+-------------------------+---------------+          |

4.7.2.  Scenario Diagram for a Command Responder Application

   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.

   Command               Dispatcher            Message          Security
   Responder
   |                 Processing          Model      ^                                 ^               ^          |
   |                 Model      |                                 |               |          |
   |      v                                 v               v          | registerContextEngineID
   | +-------------+   +---------+   +--------------+  +-------------+ |
   |
   |------------------------>| |   COMMAND   |
   |<------------------------|   | ACCESS  |   | NOTIFICATION |  | Receive SNMP    PROXY  * | |
   |
   : | Message  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR  |  |  FORWARDER  |
   : | from Network
   | | application |
   :                         |<-------------+   |         |
   :   | applications |  |
   :                         |prepareDataElements application | |
   | +-------------+   +---------+   +--------------+  +-------------+ |
   |      ^                                 ^                          |
   |      |                                 |                          |
   |      v                                 v                          |
   | +----------------------------------------------+                  |
   | |             MIB instrumentation              |      SNMP entity |
   +-------------------------------------------------------------------+

3.2.  The Naming of Identities

                            principal
                                ^
                                |
                                |
   +----------------------------|-------------+
   | SNMP engine                v             |
   :                         |------------------->|
   |
   :                    +--------------+      |
   | processIncomingMsg                    |
   :              |                    |------------------->|
   :      |
   |  +-----------------| securityName |---+  |
   :
   |                    |<-------------------|
   :  | Security Model  |              |
   :                         |<-------------------|   |  |     processPdu
   |  |                 +--------------+   |
   |<------------------------|  |
   |  |                         ^          |  |
   |
   :                         :                    :                    :
   :                         :                    :                    :  |    returnResponsePdu                         |          |  |
   |------------------------>|
   |  |
   :                         v          | prepareResponseMsg  |
   |
   :                         |------------------->|  |
   :  +------------------------------+  |                    |generateResponseMsg  |
   :
   |                    |------------------->|
   :  |  |                              |
   :  |                    |<-------------------|
   :  |
   |  |
   :                         |<-------------------|  |
   : Model                        |  |  |
   :                         |--------------+
   |  |
   :  | Send SNMP Dependent                    |  |  |
   :
   | Message  |  | Security ID                  |
   :  | to Network  |
   |  |
   :  |              v                              |  |

5.  Managed Object Definitions for SNMP Management Frameworks

   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;

   snmpFrameworkMIB MODULE-IDENTITY
       LAST-UPDATED "9709300000Z"            -- 30 September 1997
       ORGANIZATION "SNMPv3 Working Group"
       CONTACT-INFO "WG-email:   snmpv3@tis.com
                     Subscribe:  majordomo@tis.com
                                 In message body:  subscribe snmpv3

                     Chair:      Russ Mundy
                                 Trusted Information Systems
                     postal:     3060 Washington Rd
                                 Glenwood MD 21738
                                 USA
                     email:      mundy@tis.com
                     phone:      +1 301-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@cabletron.com
                     phone:      +1 603-337-7357

                     Co-editor   Randy Presuhn
                                 BMC Software, Inc.
                     postal:     1190 Saratoga Avenue
                                 Suite 130
                                 San Jose, CA 95129
                                 USA
                     email:      rpresuhn@bmc.com
                     phone:      +1 408-556-0720

                     Co-editor:  Bert Wijnen
                                 IBM T.J. Watson Research
                     postal:     Schagen 33
                                 3461 GL Linschoten
                                 Netherlands
                     email:      wijnen@vnet.ibm.com
                     phone:      +31 348-432-794
                    "
       DESCRIPTION  "The SNMP Management Architecture MIB"
       ::= { snmpModules 7 }  -- DBH: check if this number is indeed OK

   -- Textual Conventions used in the SNMP Management Architecture ***

   SnmpEngineID ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "An SNMP engine's administratively-unique identifier.

                    The value for this object may not be all zeros or
                    all 'ff'H or  |
   |  |  +------------------------------+  |  |
   |  |                         ^          |  |
   |  |                         |          |  |
   |  +-------------------------|----------+  |
   |                            |             |
   |                            |             |
   +----------------------------|-------------+
                                |
                                v
                             network

3.2.1.  Principal

   A principal is the empty (zero length) string.

                    The initial value for this object may be configured
                    via an operator console entry "who" on whose behalf services are provided or via
   processing takes place.

   A principal can be, among other things, 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 individual acting in all a
   particular role; a set of those
                    engines ending up individuals, with the same ID value.

                    1) The very first bit each acting in a
   particular role; an application or a set of applications; and
   combinations thereof.

3.2.2.  securityName

   A securityName is a human readable string representing a principal.
   It has a model-independent format, and can be used to indicate how outside a
   particular Security Model.

3.2.3.  Model-dependent security ID

   A model-dependent security ID is the
                       rest model-specific representation of the data is composed.

                       0 - as defined by enterprise using former methods
                           that existed before SNMPv3. See item 2 below.

                       1 - as defined by this architecture, see item 3
                           below.

                       Note that this allows existing uses
   a securityName within a particular Security Model.

   Model-dependent security IDs may or may not be human readable, and
   have a model-dependent syntax. Examples include community names, user
   names, and parties.

   The transformation of model-dependent security IDs into securityNames
   and vice versa is the responsibility of the
                       engineID (also known as AgentID [RFC1910]) to
                       co-exist with any new uses.

                    2) relevant Security Model.

3.3.  The snmpEngineID Naming of Management Information

   Management information resides at an SNMP entity where a Command
   Responder Application has local access to potentially multiple
   contexts.  This application uses a length of 12 octets.

                       The first four octets are set contextEngineID equal to the binary
                       equivalent
   snmpEngineID of the agent's its associated SNMP engine.

   +-----------------------------------------------------------------+
   |  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 | | | | other MIB  | |  | |
   |  |  | +------------+ | | +------------+ | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | | | some  MIB  | |  | |
   |  |  |                | |                | | +------------+ |  | |
   |  |  |                | |                | |                |  | |
   +-----------------------------------------------------------------+

3.3.1.  An 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.

                       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 Context

   An SNMP
                       entity, context, or the MAC address of one of the
                       interfaces, with each address suitably padded
                       with random octets.  If multiple methods are
                       defined, then it just "context" for short,  is recommended that the first
                       octet indicate the method being used and the
                       remaining octets be a function of the method.

                    3) The length of the octet strings varies.

                       The first four octets are set to the binary
                       equivalent collection 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.

                       The very first bit is set to 1. For example, the
                       above value for Acme Networks now changes to be
                       '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.

                         1     - IPv4 address (4 octets)
                                 lowest non-special IP address

                         2     - IPv6 address (16 octets)
                                 lowest non-special IP address

                         3     - MAC address (6 octets)
                                 lowest IEEE MAC address, canonical
                                 order

                         4     - Text, administratively assigned
                                 Maximum remaining length 27
                         5     - Octets, administratively assigned
                                 Maximum remaining length 27

                         6-127 - reserved, unused

                       127-255 - as defined information accessible by the enterprise
                                 Maximum remaining length 27
                   "
       SYNTAX       OCTET STRING (SIZE(1..32))

   SnmpSecurityModel ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "An identifier that uniquely identifies a
                    securityModel an SNMP entity. An item of the Security Subsystem within the
   management information may exist in more than one context. An SNMP Management Architecture.

                    The values for securityModel are allocated as
                    follows:

                    - The zero value is reserved.
                    - Values between 1 and 255, inclusive, are reserved
                      for standards-track Security Models and
   entity potentially has access to many contexts.

   Typically, there are many instances of each managed object type
   within a management domain. For simplicity, the method for
   identifying instances specified by the Internet Assigned Numbers Authority
                      (IANA).
                    - Values greater than 255 are allocated MIB module does not allow each
   instance to
                      enterprise-specific Security Models.  An
                      enterprise-specific securityModel value 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 be:

                      enterpriseID * 256 + security model identify an
   individual item of management information within
                      enterprise the management
   domain, its contextName and contextEngineID must be identified in
   addition to its object type and its instance.

   For example, the fourth Security Model managed object type ifDescr [RFC1573], is defined by as
   the enterprise whose enterpriseID is 1 would be
                      260.

                    The eight bits allow description of a maximum 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").

   Each context has (at least) one unique identification within the
   management domain. The same item of 255 (256-1
                    reserved) standards based Security Models.
                    Similarly, they allow a maximum management information can exist
   in multiple contexts.  An item of 255 Security
                    Models per enterprise.

                    It is believed that the assignment management information may have
   multiple unique identifications.  This occurs when an item of new
                    securityModel values will be rare
   management information exists in practice
                    because the larger the number multiple contexts, and this also
   occurs when a context has multiple unique identifications.

   The combination of simultaneously
                    utilized Security Models, the larger the
                    chance that interoperability will suffer.
                    Consequently, it is believed that such a range
                    will contextEngineID and a contextName unambiguously
   identifies a context within an administrative domain; note that there
   may be sufficient.  In the unlikely event multiple unique combinations of contextEngineID and
   contextName that unambiguously identify the standards committee finds this number to be
                    insufficient over time, same context.

3.3.2.  contextEngineID

   Within an enterprise number
                    can be allocated to obtain administrative domain, a contextEngineID uniquely
   identifies an additional 255
                    possible values.

                    Note SNMP entity that the most significant bit must be zero;
                    hence, there are 23 bits allocated for various
                    organizations may realize an instance of a context
   with a particular contextName.

3.3.3.  contextName

   A contextName is used to design name a context. Each contextName MUST be
   unique within an SNMP entity.

3.3.4.  scopedPDU

   A scopedPDU is a block of data containing a contextEngineID, a
   contextName, and define non-standard
                    securityModels.  This limits a PDU.

   The PDU is an SNMP Protocol Data Unit containing information named in
   the ability to
                    define new proprietary implementations of Security
                    Models to context which is unambiguously identified within an
   administrative domain by the combination of the first 8,388,608 enterprises.

                    It contextEngineID and
   the contextName. See, for example, RFC1905 for more information about
   SNMP PDUs.

3.4.  Other Constructs

3.4.1.  maxSizeResponseScopedPDU

   The maxSizeResponseScopedPDU is worthwhile the maximum size of a scopedPDU to note that, be
   included in its encoded
                    form, a response message.  Note that the securityModel value will normally
                    require only size of a single byte since, in practice, scopedPDU
   does not include the leftmost bits will be zero for most messages size of the SNMP message header.

3.4.2.  Local Configuration Datastore

   The subsystems, models, and sign extension is suppressed by applications within an SNMP entity may
   need to retain their own sets of configuration information.

   Portions of the encoding
                    rules.

                    As configuration information may be accessible as
   managed objects.

   The collection of this writing, there are several values these sets of securityModel defined for use information is referred to as an
   entity's Local Configuration Datastore (LCD).

3.4.3.  securityLevel

   This architecture recognizes three levels of security:

      -  without authentication and without privacy (noAuthNoPriv)

      -  with SNMP or
                    reserved for use authentication but without privacy (authNoPriv)

      -  with supporting MIB objects.
                    They authentication and with privacy (authPriv)

   These three values are as follows:

                        0  reserved for 'any'
                        1  reserved for SNMPv1
                        2  reserved for SNMPv2c
                        3  User-Based Security Model (USM)
                   "
       SYNTAX       INTEGER(0..2147483647)

   SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "An identifier ordered such that uniquely identifies noAuthNoPriv is less than
   authNoPriv and authNoPriv is less than authPriv.

   Every message has an associated securityLevel. All Subsystems
   (Message Processing, Security, Access Control) and applications are
   required to either supply a Message
                    Processing Model value of securityLevel or to abide by the
   supplied value of securityLevel while processing the Message Processing
                    Subsystem message and its
   contents.

4.  Abstract Service Interfaces

   Abstract service interfaces have been defined to describe the
   conceptual interfaces between the various subsystems within a an SNMP Management Architecture.

                    The values for messageProcessingModel are
                    allocated as follows:

                    - Values between 0 and 255, inclusive, are
                      reserved for standards-track Message Processing
                      Models and
   entity.

   These abstract service interfaces are managed defined by a set of primitives
   that define the Internet Assigned
                      Numbers Authority (IANA).
                    - Values greater than 255 services provided and the abstract data elements that
   are allocated to
                      enterprise-specific Message Processing Models.
                      An enterprise messageProcessingModel value is be passed when the services are invoked.  This section lists
   the primitives that have been defined for the various subsystems.

4.1.  Dispatcher Primitives

   The Dispatcher typically provides services to be:

                      enterpriseID * 256 +
                           messageProcessingModel within enterprise

                      For example, the fourth Message Processing Model
                      defined SNMP applications
   via its PDU Dispatcher.  This section describes the primitives
   provided by the enterprise whose enterpriseID
                      is 1 would be 260. PDU Dispatcher.

4.1.1.  Generate Outgoing Request or Notification

   The eight bits allow a maximum of 256 standards
                    based Message Processing Models.  Similarly, they
                    allow a maximum 256 Message Processing Models
                    per enterprise.

                    It is believed that PDU Dispatcher provides the assignment following primitive for an
   application to send an SNMP Request or Notification to another SNMP
   entity:

   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 new
                    messageProcessingModel values will be rare
                    in practice because the larger the number this principal
     IN   securityLevel             -- Level of
                    simultaneously utilized Message Processing Models,
                    the larger Security requested
     IN   contextEngineID           -- data from/at this entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the chance that interoperability
                    will suffer. It is believed that such a range
                    will be sufficient.  In version of the unlikely event that PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   expectResponse            -- TRUE or FALSE
          )

4.1.2.  Process Incoming Request or Notification PDU

   The PDU Dispatcher provides the standards committee finds this number following primitive to be
                    insufficient over time, pass an enterprise number
                    can be allocated
   incoming SNMP PDU to obtain an additional 256
                    possible values.

                    Note that application:

   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 most significant bit must be zero;
                    hence, there are 23 bits allocated for various
                    organizations to design and define non-standard
                    messageProcessingModels.  This limits version of the ability
                    to define new proprietary implementations PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size of
                    Message Processing Models the Response PDU
     IN   stateReference            -- reference to state information
          )                         -- needed when sending a response

4.1.3.  Generate Outgoing Response

   The PDU Dispatcher provides the first 8,388,608
                    enterprises.

                    It is worthwhile following primitive for an
   application to return an SNMP Response PDU to note that, in its encoded
                    form, the PDU Dispatcher:

   returnResponsePdu(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel value will normally
                    require only a single byte since,             -- Security Model in practice,
                    the leftmost bits will be zero for most messages
                    and sign extension is suppressed by the encoding
                    rules.

                    As use
     IN   securityName              -- on behalf of this writing, there are several values of
                    messageProcessingModel defined for use with SNMP.
                    They are principal
     IN   securityLevel             -- same as follows:

                        0  reserved for SNMPv1
                        1  reserved for SNMPv2c
                        2  reserved for SNMPv2u and SNMPv2*
                        3  reserved for SNMPv3
                   "
       SYNTAX       INTEGER(0..2147483647)

   SnmpSecurityLevel ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "A Level of Security at which on incoming request
     IN   contextEngineID           -- data from/at this 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.

                    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)
                            }

   SnmpAdminString ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "255a"
       STATUS       current
       DESCRIPTION "An octet string containing administrative
                    information, preferably in human-readable form.

                    To facilitate internationalization, entity
     IN   contextName               -- data from/in this
                    information is represented using context
     IN   pduVersion                -- the ISO/IEC
                    IS 10646-1 character set, encoded as an octet
                    string using version of the UTF-8 transformation format
                    described in [RFC2044].

                    Since additional code points are added by
                    amendments to PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size of the 10646 standard from time Response PDU
     IN   stateReference            -- reference to time, implementations must be prepared state information
                                    -- as presented with the request
     IN   statusInformation         -- success or errorIndication
          )                         -- error counter OID/value if error

4.1.4.  Process Incoming Response PDU

   The PDU Dispatcher provides the following primitive to
                    encounter any code point from 0x00000000 pass an
   incoming SNMP Response PDU to
                    0x7fffffff.

                    The an application:

   processResponsePdu(              -- process Response PDU
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model in use
     IN   securityName              -- on behalf of control codes should be avoided.

                    When it is necessary to represent a newline, 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 control code sequence CR LF should be used.

                    The use version of leading or trailing white space should
                    be avoided.

                    For code points not directly supported by user
                    interface hardware the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   statusInformation         -- success or software, an alternative
                    means of entry and display, such as hexadecimal,
                    may be provided.

                    For information encoded in 7-bit US-ASCII, errorIndication
     IN   sendPduHandle             -- handle from sendPdu
          )

4.1.5.  Registering Responsibility for Handling SNMP PDUs

   Applications can register/unregister responsibility for a specific
   contextEngineID, for specific pduTypes, with the UTF-8 encoding is identical PDU Dispatcher
   according to the
                    US-ASCII encoding.

                    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 following primitives.  The list of particular
   pduTypes that the
                    number sub-identifiers an application can register for any object instance
                    do not exceed is determined by the limit of 128, as defined
   Message Processing Model(s) supported by
                    [RFC1905].
                   "
       SYNTAX       OCTET STRING (SIZE (0..255))

   -- Administrative assignments ***************************************

   snmpFrameworkAdmin
       OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
   snmpFrameworkMIBObjects
       OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
   snmpFrameworkMIBConformance
       OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }

   -- the snmpEngine Group ********************************************

   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 }

   snmpEngineBoots  OBJECT-TYPE
       SYNTAX       INTEGER (1..2147483647)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of times entity that
   contains the SNMP engine has
                    (re-)initialized itself since its initial
                    configuration.
                   "
       ::= { snmpEngine 2 }

   snmpEngineTime   OBJECT-TYPE
       SYNTAX       INTEGER (0..2147483647)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number PDU Dispatcher.

   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
          )

   Note that realizations of seconds since the SNMP engine last
                    incremented registerContextEngineID and
   unregisterContextEngineID abstract service interfaces may provide
   implementation-specific ways for applications to register/deregister
   responsiblity for all possible values of the snmpEngineBoots object.
                   "
       ::= { snmpEngine 3 }

   snmpEngineMaxMessageSize OBJECT-TYPE
       SYNTAX       INTEGER (484..2147483647)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The maximum length in octets contextEngineID or
   pduType parameters.

4.2.  Message Processing Subsystem Primitives

   The Dispatcher interacts with a Message Processing Model to process a
   specific version of an SNMP message
                    which Message. This section describes the
   primitives provided by the Message Processing Subsystem.

4.2.1.  Prepare Outgoing SNMP Request or Notification Message

   The Message Processing Subsystem provides this service primitive for
   preparing an outgoing SNMP engine can send Request or receive and
                    process, determined as the minimum Notification Message:

   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 the maximum
                    message size values supported among all 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
                    transports available to and supported by version of the engine.
                   "
       ::= { snmpEngine 4 } PDU
     IN   PDU                       -- 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 }

   snmpPrivProtocols OBJECT-IDENTITY
       STATUS        current
       DESCRIPTION  "Registration point Protocol Data Unit
     IN   expectResponse            -- TRUE or FALSE
     IN   sendPduHandle             -- the handle for standards-track privacy
                     protocols used in SNMP Management Frameworks.
                    "
       ::= { snmpFrameworkAdmin 2 } matching
                                    -- Conformance information ******************************************

   snmpFrameworkMIBCompliances
                  OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
   snmpFrameworkMIBGroups
                  OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2} incoming responses
     OUT  destTransportDomain       -- compliance statements

   snmpFrameworkMIBCompliance MODULE-COMPLIANCE
       STATUS       current
       DESCRIPTION "The compliance statement destination transport domain
     OUT  destTransportAddress      -- destination transport address
     OUT  outgoingMessage           -- the message to send
     OUT  outgoingMessageLength     -- its length
          )

4.2.2.  Prepare an Outgoing SNMP Response Message

   The Message Processing Subsystem provides this service primitive for
   preparing an outgoing SNMP engines which
                    implement the Response Message:

   result =                         -- SUCCESS or FAILURE
     prepareResponseMessage(
     IN   messageProcessingModel    -- typically, SNMP Management Framework MIB.
                   "
       MODULE 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 module
           MANDATORY-GROUPS { snmpEngineGroup }

       ::= { snmpFrameworkMIBCompliances 1 } context
     IN   pduVersion                -- 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 version of an the PDU
     IN   PDU                       -- SNMP engine.
                   "
       ::= { snmpFrameworkMIBGroups 1 }

   END

6.  Security Considerations

   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 Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size of security provided is determined by the specific Security
   Model implementation(s) and the specific Access Control Model
   implementation(s) used.

   Applications have access Response PDU
     IN   stateReference            -- reference to data which is not secured.  Applications
   should take reasonable steps 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 protect send
     OUT  outgoingMessageLength     -- its length
          )

4.2.3.  Prepare Data Elements from an Incoming SNMP Message

   The Message Processing Subsystem provides this service primitive for
   preparing the abstract data elements from disclosure.

   It is the responsibility of the purchaser of an implementation to
   ensure that:

      1) an implementation complies with incoming SNMP message:

   result =                         -- SUCCESS or errorIndication
     prepareDataElements(
     IN   transportDomain           -- origin transport domain
     IN   transportAddress          -- origin transport address
     IN   wholeMsg                  -- as received from the rules defined by this
         architecture,

      2) network
     IN   wholeMsgLength            -- as received from the network
     OUT  messageProcessingModel    -- typically, SNMP version
     OUT  securityModel             -- Security and Access Control Models utilized satisfy the
         security and access control needs Model to use
     OUT  securityName              -- on behalf of the organization,

      3) the implementations 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 Models and Applications comply with
         the model and application specifications,

      4) and the implementation protects configuration secrets from
         inadvertent disclosure.

7.  Editor's Addresses

                      Co-editor:  Bert Wijnen
                                  IBM T.J. Watson Research
                      postal:     Schagen 33
                                  3461 GL Linschoten
                                  Netherlands
                      email:      wijnen@vnet.ibm.com
                      phone:      +31 348-432-794

                      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@cabletron.com
                      phone:      +1 603-337-7357

                      Co-editor   Randy Presuhn
                                  BMC Software, Inc.
                      postal:     1190 Saratoga Avenue
                                  Suite 130
                                  San Jose, CA 95129
                                  USA
                      email:      rpresuhn@bmc.com
                      phone:      +1 408-556-0720

8.  Acknowledgements

   This document is version of the result PDU
     OUT  PDU                       -- SNMP Protocol Data Unit
     OUT  pduType                   -- SNMP PDU type
     OUT  sendPduHandle             -- handle for matched request
     OUT  maxSizeResponseScopedPDU  -- maximum size of the efforts Response PDU
     OUT  statusInformation         -- success or errorIndication
                                    -- error counter OID/value if error
     OUT  stateReference            -- reference to state information
                                    -- to be used for possible Response
          )

4.3.  Access Control Subsystem Primitives

   Applications are the typical clients of the SNMPv3 Working
   Group.  Some special thanks are in order to service(s) of the following SNMPv3 WG
   members:

       Dave Battle (SNMP Research, Inc.)
       Uri Blumenthal (IBM T.J. Watson Research Center)
       Jeff Case (SNMP Research, Inc.)
       John Curran (BBN)
       T. Max Devlin (Hi-TECH Connections)
       John Flick (Hewlett Packard)
       David Harrington (Cabletron Systems Inc.)
       N.C. Hien (IBM T.J. Watson Research Center)
       Dave Levi (SNMP Research, Inc.)
       Louis A Mamakos (UUNET Technologies Inc.)
       Paul Meyer (Secure Computing Corporation)
       Keith McCloghrie (Cisco Systems)
       Russ Mundy (Trusted Information Systems, Inc.)
       Bob Natale (ACE*COMM Corporation)
       Mike O'Dell (UUNET Technologies Inc.)
       Dave Perkins (DeskTalk)
       Peter Polkinghorne (Brunel University)
       Randy Presuhn (BMC Software, Inc.)
       David Reid (SNMP Research, Inc.)
       Shawn Routhier (Epilogue)
       Juergen Schoenwaelder (TU Braunschweig)
       Bob Stewart (Cisco Systems)
       Bert Wijnen (IBM T.J. Watson Research Center) Access
   Control Subsystem.

   The document following primitive is based on recommendations of provided by the IETF Access Control Subsystem
   to check if access is allowed:

   statusInformation =              -- success or errorIndication
     isAccessAllowed(
     IN   securityModel             -- Security and
   Administrative Framework Evolution for SNMP Advisory Team.  Members
   of that Advisory Team were:

       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)

   As recommended by 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 Advisory Team and managed object
          )

4.4.  Security Subsystem Primitives

   The Message Processing Subsystem is the SNMPv3 Working Group
   Charter, typical client of the design incorporates as much as practical from previous
   RFCs and drafts. As
   services of the Security Subsystem.

4.4.1.  Generate a result, special thanks are due Request or Notification Message

   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 authors sending SNMP entity
     IN   securityModel             -- for the outgoing message
     IN   securityEngineID          -- authoritative SNMP entity
     IN   securityName              -- on behalf of previous designs known as SNMPv2u and 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.)

9.  References

   [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification this principal
     IN   securityLevel             -- Level of Management Information for TCP/IP-based internets", STD 16, RFC
      1155, May 1990.

   [RFC1157] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "The
      Simple Network Management Protocol", STD 15, RFC 1157, University Security requested
     IN   scopedPDU                 -- message (plaintext) payload
     OUT  securityParameters        -- filled in by Security Module
     OUT  wholeMsg                  -- complete generated message
     OUT  wholeMsgLength            -- length of Tennessee at Knoxville, Performance Systems s International,
      Performance International, and the MIT Laboratory for Computer
      Science, May 1990.

   [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD
      16, RFC 1212, March 1991.

   [RFC1901] generated message
          )

4.4.2.  Process Incoming Message

   The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S., Waldbusser, "Introduction Security Subsystem provides the following primitive to Community-based SNMPv2",
      RFC 1901, January 1996.

   [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S., Waldbusser, "Structure process an
   incoming message:

   statusInformation =              -- errorIndication or success
                                    -- error counter OID/value if error
     processIncomingMsg(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   maxMessageSize            -- of Management Information the sending SNMP entity
     IN   securityParameters        -- for
      Version  2 the received message
     IN   securityModel             -- for the received message
     IN   securityLevel             -- Level of Security
     IN   wholeMsg                  -- as received on the Simple Network Management Protocol (SNMPv2)",
      RFC 1902, January 1996.

   [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S. Waldbusser, "Textual Conventions 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 of the Response PDU
     OUT  securityStateReference    -- reference to security state
          )                         -- information, needed for Version 2 response

4.4.3.  Generate a Response Message

   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
      Simple Network Management Protocol (SNMPv2)", RFC 1903, January
      1996.

   [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S., Waldbusser, "Conformance Statements sending SNMP entity
     IN   securityModel             -- for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1904,
      January 1996.

   [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S., Waldbusser, "Protocol Operations for Version 2 outgoing message
     IN   securityEngineID          -- authoritative SNMP entity
     IN   securityName              -- on behalf of the
      Simple Network Management Protocol (SNMPv2)", RFC 1905, January
      1996.

   [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S. Waldbusser, "Transport Mappings this principal
     IN   securityLevel             -- for Version 2 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
      Simple Network Management Protocol (SNMPv2)", RFC 1906, January
      1996.

   [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S. Waldbusser, "Management generated message
          )

4.5.  Common Primitives

   These primitive(s) are provided by multiple Subsystems.

4.5.1.  Release State Reference Information Base for Version 2
      of

   All Subsystems which pass stateReference information also provide a
   primitive to release the Simple Network Management Protocol (SNMPv2)", RFC 1907
      January 1996.

   [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S. Waldbusser, "Coexistence between Version 1 memory that holds the referenced state
   information:

   stateRelease(
     IN   stateReference       -- handle of reference to be released
          )

4.6.  Scenario Diagrams

4.6.1.  Command Generator or Notification Originator

   This diagram shows how a Command Generator or Notification Originator
   application requests that a PDU be sent, and Version
      2 of how the SNMP-standard Network Management Framework", RFC 1908,
      January 1996.

   [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
      for SNMPv2", RFC1909, February 1996.

   [RFC1910] Waters, G., Editor, "User-based response is
   returned (asynchronously) to that application.

   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 |                        |                     |
   |<-------------------|                        |                     |
   |                    |                        |                     |

4.6.2.  Scenario Diagram for SNMPv2",
      RFC1910, February 1996.

   [RFC2044] Yergeau, F., "UTF-8, a transformation format of Unicode and
      ISO 10646", RFC 2044, October 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs a Command Responder Application

   This diagram shows how a Command Responder or Notification Receiver
   application registers for handling a pduType, how a PDU is dispatched
   to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D.,
      Wijnen, B., "Message Processing the application after a SNMP message is received, and Dispatching for how the Simple
      Network Management Protocol (SNMP)", draft-ietf-snmpv3-mpc-03.txt,
      August 1997.

   [SNMP-USM] The SNMPv3 Working Group, Blumenthal, U., Wijnen, B., "The
      User-Based
   Response is (asynchronously) send back to the network.

   Command               Dispatcher            Message          Security
   Responder                 |                 Processing          Model for Version 3 of the Simple Network
      Management Protocol (SNMPv3)", draft-ietf-snmpv3-usm-01.txt,
      August 1997.

   [SNMP-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R.,
      McCloghrie, K., "View-based Access Control
   |                         |                 Model for the Simple                   |
   |                         |                    |                    |
   | registerContextEngineID |                    |                    |
   |------------------------>|                    |                    |
   |<------------------------|              |     |                    |
   |                         | Receive SNMP |     |                    |
   :                         | Message      |     |                    |
   :                         | from Network |     |                    |
   :                         |<-------------+     |                    |
   :                         |                    |                    |
   :                         |prepareDataElements |                    |
   :                         |------------------->|                    |
   :                         |                    | processIncomingMsg |
   :                         |                    |------------------->|
   :                         |                    |                    |
   :                         |                    |<-------------------|
   :                         |                    |                    |
   :                         |<-------------------|                    |
   |     processPdu          |                    |                    |
   |<------------------------|                    |                    |
   |                         |                    |                    |
   :                         :                    :                    :
   :                         :                    :                    :
   |    returnResponsePdu    |                    |                    |
   |------------------------>|                    |                    |
   :                         | prepareResponseMsg |                    |
   :                         |------------------->|                    |
   :                         |                    |generateResponseMsg |
   :                         |                    |------------------->|
   :                         |                    |                    |
   :                         |                    |<-------------------|
   :                         |                    |                    |
   :                         |<-------------------|                    |
   :                         |                    |                    |
   :                         |--------------+     |                    |
   :                         | Send SNMP    |     |                    |
   :                         | Message      |     |                    |
   :                         | to Network Management Protocol (SNMP)", draft-ietf-snmpv3-acm-02.txt,
      August 1997.

   [SNMP-APPL] The SNMPv3 Working Group, Levi, D. B., Meyer, P.,
      Stewart, B., "SNMPv3 Applications",
      <draft-ietf-snmpv3-appl-01.txt>, August 1997

APPENDIX A

A.  Guidelines for Model Designers

   This appendix describes guidelines   |     |                    |
   :                         |              v     |                    |

5.  Managed Object Definitions 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 Management Frameworks
   could be designed to meet the requirements of this architecture, but

   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;

   snmpFrameworkMIB MODULE-IDENTITY
       LAST-UPDATED "9710280000Z"            -- 28 October 1997
       ORGANIZATION "SNMPv3 Working Group"
       CONTACT-INFO "WG-email:   snmpv3@tis.com
                     Subscribe:  majordomo@tis.com
                                 In message body:  subscribe snmpv3

                     Chair:      Russ Mundy
                                 Trusted Information Systems
                     postal:     3060 Washington Rd
                                 Glenwood MD 21738
                                 USA
                     email:      mundy@tis.com
                     phone:      +1 301-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@cabletron.com
                     phone:      +1 603-337-7357

                     Co-editor   Randy Presuhn
                                 BMC Software, Inc.
                     postal:     1190 Saratoga Avenue
                                 Suite 130
                                 San Jose, CA 95129
                                 USA
                     email:      rpresuhn@bmc.com
                     phone:      +1 408-556-0720

                     Co-editor:  Bert Wijnen
                                 IBM T.J. Watson Research
                     postal:     Schagen 33
                                 3461 GL Linschoten
                                 Netherlands
                     email:      wijnen@vnet.ibm.com
                     phone:      +31 348-432-794
                    "
       DESCRIPTION  "The SNMP Management Architecture MIB"
       ::= { snmpModules 7 }  -- DBH: check if this document does not provide guidelines for that coexistence.

   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 number 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 indeed OK

   -- Textual Conventions used within this architecture
   SHOULD use in the standard primitives between subsystems, possibly
   defining specific mechanisms SNMP Management Architecture ***

   SnmpEngineID ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "An SNMP engine's administratively-unique identifier.

                    The value 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 this object may 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, all zeros or how,
                    all 'ff'H or how well, it performs the
   service is dependent on empty (zero length) string.

                    The initial value for this object may be configured
                    via an operator console entry or via an algorithmic
                    function.  In the model definition.

A.1.  Security Model Design Requirements

A.1.1.  Threats

   A document describing a Security Model MUST describe how latter case, the model
   protects against following
                    example algorithm is recommended.

                    In cases where there are multiple engines on the threats described under "Security Requirements
                    same system, the use of this Architecture", section 1.4.

A.1.2.  Security Processing

   Received messages MUST be validated by a Model algorithm is NOT
                    appropriate, as it would result in all of those
                    engines ending up with the Security
   Subsystem.  Validation includes authentication and privacy processing
   if needed, but it same ID value.

                    1) The very first bit 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.

   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 indicate how the model definition is constrained to using
   (possibly a subset of)
                       rest of the abstract data elements is composed.

                       0 - as defined in by enterprise using former methods
                           that existed before SNMPv3. See item 2 below.

                       1 - as defined by this
   document for transferring data between subsystems.

   Each Security Model may allow multiple security protocols to be used
   concurrently within an implementation architecture, see item 3
                           below.

                       Note that this allows existing uses of the model. Each Security
   Model defines how to determine which protocol to use, given the
   securityLevel and the security parameters relevant
                       engineID (also known as AgentID [RFC1910]) to the message.
   Each Security Model,
                       co-exist with its associated protocol(s) defines how the
   sending/receiving entities are identified, and how secrets any new uses.

                    2) The snmpEngineID has a length of 12 octets.

                       The first four octets are
   configured.

   Authentication and Privacy protocols supported set to the binary
                       equivalent of the agent's SNMP management
                       private enterprise number as assigned by Security Models 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.

                       The remaining eight octets are
   uniquely identified using Object Identifiers. IETF standard protocols
   for authentication determined via
                       one or privacy should have an identifier defined
   within more enterprise-specific methods. Such
                       methods must be designed so as to maximize the snmpAuthProtocols or
                       possibility that the snmpPrivProtocols subtrees.
   Enterprise specific protocol identifiers should value of this object will
                       be defined within unique in the
   enterprise subtree. agent's administrative domain.
                       For privacy, example, it may be the Security Model defines what portion IP address of the message
   is encrypted.

   The persistent data used for security should be SNMP-manageable, but SNMP
                       entity, or the Security Model defines whether an instantiation MAC address of one of the MIB is a
   conformance requirement.

   Security Models
                       interfaces, with each address suitably padded
                       with random octets.  If multiple methods are replaceable within
                       defined, then it is recommended that the Security Subsystem.
   Multiple Security Model implementations may exist concurrently within
   an SNMP engine.  The number of Security Models defined by first
                       octet indicate the SNMP
   community should remain small to promote interoperability.

A.1.3.  Validate method being used and the security-stamp in a received message

   A Message Processing Model requests that
                       remaining octets be a Security Model:
     - verifies that function of the message has not been altered,
     - authenticates method.

                    3) The length of the octet strings varies.

                       The first four octets are set to the identification binary
                       equivalent of the principal for whom the
       message was generated.
     - decrypts agent's SNMP management
                       private enterprise number as assigned by the message
                       Internet Assigned Numbers Authority (IANA).
                       For example, if it was encrypted.

   Additional requirements may be defined by Acme Networks has been assigned
                       { enterprises 696 }, the model, and additional
   services may first four octets would
                       be provided by the model, but the model assigned '000002b8'H.

                       The very first bit is constrained set to use 1. For example, the following primitives
                       above value for transferring data between
   subsystems. Implementations are not so constrained.

   A Message Processing Model uses the processMsg primitive as described
   in section 4.5.

A.1.4.  Security MIBs

   Each Security Model defines Acme Networks now changes to be
                       '800002b8'H.

                       The fifth octet indicates how the MIB module(s) required for security
   processing, including any MIB module(s) required rest (6th and
                       following octets) are formatted. The values for
                       the security
   protocol(s) supported.  The MIB module(s) SHOULD be fifth octet are:

                         0     - reserved, unused.

                         1     - IPv4 address (4 octets)
                                 lowest non-special IP address

                         2     - IPv6 address (16 octets)
                                 lowest non-special IP address

                         3     - MAC address (6 octets)
                                 lowest IEEE MAC address, canonical
                                 order

                         4     - Text, administratively assigned
                                 Maximum remaining length 27
                         5     - Octets, administratively assigned
                                 Maximum remaining length 27

                         6-127 - reserved, unused

                       127-255 - as defined
   concurrently with by the procedures which use enterprise
                                 Maximum remaining length 27
                   "
       SYNTAX       OCTET STRING (SIZE(1..32))

   SnmpSecurityModel ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "An identifier that uniquely identifies a
                    securityModel of the MIB module(s). Security Subsystem within the
                    SNMP Management Architecture.

                    The
   MIB module(s) values for securityModel are subject to normal access control rules. allocated as
                    follows:

                    - The mapping zero value is reserved.
                    - Values between the model-dependent security ID 1 and 255, inclusive, are reserved
                      for standards-track Security Models and are
                      managed by the
   securityName MUST be able Internet Assigned Numbers Authority
                      (IANA).
                    - Values greater than 255 are allocated to be determined using SNMP, if the model-
   dependent MIB is instantiated and if access control policy allows
   access.

A.1.5.  Cached
                      enterprise-specific Security Data Models.  An
                      enterprise-specific securityModel value is defined
                      to be:

                      enterpriseID * 256 + security model within
                      enterprise

                      For each message received, example, the fourth Security Model caches defined by
                      the state
   information such that a Response message can enterprise whose enterpriseID is 1 would be generated using the
   same security information, even if the Local Configuration Datastore
                      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.

                    It is altered between believed that the time assignment of new
                    securityModel values will be rare in practice
                    because the incoming request and larger the outgoing
   response.

   A Message Processing Model has number of simultaneously
                    utilized Security Models, the responsibility for explicitly
   releasing larger the cached data if such data
                    chance that interoperability will suffer.
                    Consequently, it is no longer needed. To enable
   this, 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 abstract securityStateReference data element is passed from enterprise number
                    can be allocated to obtain an additional 255
                    possible values.

                    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 Model
                    Models to the Message Processing Model.

   The cached security data may be implicitly released via first 8,388,608 enterprises.

                    It is worthwhile to note that, in its encoded
                    form, the
   generation of securityModel value will normally
                    require only a response, or explicitly released single byte since, in practice,
                    the leftmost bits will be zero for most messages
                    and sign extension is suppressed by using the
   stateRelease primitive, encoding
                    rules.

                    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 described in section 4.1.

A.2.  Message Processing follows:

                        0  reserved for 'any'
                        1  reserved for SNMPv1
                        2  reserved for SNMPv2c
                        3  User-Based Security Model Design Requirements

   An SNMP engine contains (USM)
                   "
       SYNTAX       INTEGER(0..2147483647)

   SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "An identifier that uniquely identifies a Message
                    Processing Subsystem which may
   contain multiple Message Processing Models.

   The Message Processing Model MUST always (conceptually) pass the
   complete PDU, i.e., it never forwards less than the complete list of
   varBinds.

A.2.1.  Receiving an SNMP Message from the Network

   Upon receipt of Message Processing
                    Subsystem within a message from the network, the Dispatcher in the
   SNMP engine determines the version of the SNMP message Management Architecture.

                    The values for messageProcessingModel are
                    allocated as follows:

                    - Values between 0 and interacts
   with 255, inclusive, are
                      reserved for standards-track Message Processing
                      Models and are managed by the corresponding Internet Assigned
                      Numbers Authority (IANA).
                    - Values greater than 255 are allocated to
                      enterprise-specific Message Processing Model Models.
                      An enterprise messageProcessingModel value is
                      defined to determine be:

                      enterpriseID * 256 +
                           messageProcessingModel within enterprise

                      For example, the
   abstract data elements.

   A fourth Message Processing Model specifies
                      defined by the SNMP enterprise whose enterpriseID
                      is 1 would be 260.

                    This scheme for allocation of securityModel
                    values allows for a maximum of 255 standards-
                    based Message format it
   supports Processing Models, and describes how to determine for a
                    maximum of 255 Message Processing Models per
                    enterprise.

                    It is believed that the values assignment of new
                    messageProcessingModel values will be rare
                    in practice because the abstract
   data elements (like msgID, msgMaxSize, msgFlags,
   msgSecurityParameters, securityModel, securityLevel etc). A larger the number of
                    simultaneously utilized Message Processing Model interacts with Models,
                    the larger the chance that interoperability
                    will suffer. It is believed that such a Security Model to provide security
   processing for range
                    will be sufficient.  In the message using unlikely event that
                    the processMsg primitive, as
   described in section 4.5.

A.2.2.  Sending standards committee finds this number to be
                    insufficient over time, an SNMP Message enterprise number
                    can be allocated to obtain an additional 256
                    possible values.

                    Note that the Network

   The Dispatcher in 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 SNMP engine interacts with a ability
                    to define new proprietary implementations of
                    Message Processing
   Model Models to prepare an outgoing message. For that it uses the following
   primitives:

      - first 8,388,608
                    enterprises.

                    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 requests most messages
                    and notifications: prepareOutgoingMessage, as
         described in section 4.4

      - sign extension is suppressed by the encoding
                    rules.

                    As of this writing, there are several values of
                    messageProcessingModel defined for response messages: prepareResponseMessage, use with SNMP.
                    They are as described in
         section 4.4

   A Message Processing Model, when preparing an Outgoing follows:

                        0  reserved for SNMPv1
                        1  reserved for SNMPv2c
                        2  reserved for SNMPv2u and SNMPv2*
                        3  reserved for SNMPv3
                   "
       SYNTAX       INTEGER(0..2147483647)

   SnmpSecurityLevel ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "A Level of Security at which SNMP Message,
   interacts messages can be
                    sent or with a Security Model to secure the message. For that it
   uses the following primitives: which operations are being processed;
                    in particular, one of:

                      noAuthNoPriv -  for requests without authentication and notifications: generateRequestMsg, as
         described in section 4.5.
                                     without privacy,
                      authNoPriv   -  for response messages: generateResponseMsg as described with authentication but
                                     without privacy,
                      authPriv     - with authentication and
                                     with privacy.

                    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)
                            }

   SnmpAdminString ::= TEXTUAL-CONVENTION
       DISPLAY-HINT "255a"
       STATUS       current
       DESCRIPTION "An octet string containing administrative
                    information, preferably in
         section 4.5.

      Once the SNMP message human-readable form.

                    To facilitate internationalization, this
                    information is prepared by a Message Processing Model,
      the Dispatcher sends the message to the desired address represented using the
      appropriate transport.

A.3.  Application Design Requirements

   Within an application, there may be ISO/IEC
                    IS 10646-1 character set, encoded as an explicit binding octet
                    string using the UTF-8 transformation format
                    described in [RFC2044].

                    Since additional code points are added by
                    amendments to a specific
   SNMP message version, i.e., a specific Message Processing Model, and the 10646 standard from time
                    to a specific Access Control Model, but there should time, implementations must be no reference prepared to
                    encounter any data defined by a specific Message Processing Model or Access
   Control Model.

   Within an application, there should be no reference code point from 0x00000000 to any specific
   Security Model, or any data defined by a specific Security Model.

   An application determines whether explicit or implicit access
                    0x7fffffff.

                    The use of control codes should be applied avoided.

                    When it is necessary to represent a newline,
                    the operation, and, if access control is needed,
   which Access Control Model code sequence CR LF should be used.

   An application has the responsibility to define any MIB module(s)
   used to provide application-specific services.

   Applications interact with the SNMP engine to initiate messages,
   receive responses, receive asynchronous messages, and send responses.

A.3.1.  Applications that Initiate Messages

   Applications may request that the SNMP engine send messages
   containing SNMP commands

                    The use of leading or notifications using the sendPdu primitive
   as described in section 4.2.

   If it is desired that a message trailing white space should
                    be sent to multiple targets, it is
   the responsibility avoided.

                    For code points not directly supported by user
                    interface hardware or software, an alternative
                    means of the application to provide the iteration.

   The SNMP engine assumes necessary access control has been applied to
   the PDU, entry and provides no access control services.

   The SNMP engine looks at display, such as hexadecimal,
                    may be provided.

                    For information encoded in 7-bit US-ASCII,
                    the "expectResponse" parameter, and if a
   response UTF-8 encoding is expected, then identical to the appropriate information
                    US-ASCII encoding.

                    Note that when this TC is cached such used for an object that a later response can be associated
                    is used or envisioned to this message, and can be used as an index, then
                    a SIZE restriction must be returned to the application. A sendPduHandle is returned to the
   application specified so it can later correspond that the response with this message
                    number of sub-identifiers for any object instance
                    does not exceed the limit of 128, as well.

A.3.2.  Applications defined by
                    [RFC1905].
                   "
       SYNTAX       OCTET STRING (SIZE (0..255))

   -- Administrative assignments ***************************************

   snmpFrameworkAdmin
       OBJECT IDENTIFIER ::= { snmpFrameworkMIB 1 }
   snmpFrameworkMIBObjects
       OBJECT IDENTIFIER ::= { snmpFrameworkMIB 2 }
   snmpFrameworkMIBConformance
       OBJECT IDENTIFIER ::= { snmpFrameworkMIB 3 }

   -- the snmpEngine Group ********************************************

   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 }

   snmpEngineBoots  OBJECT-TYPE
       SYNTAX       INTEGER (1..2147483647)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of times that Receive Responses

   The the SNMP engine matches has
                    (re-)initialized itself since its initial
                    configuration.
                   "
       ::= { snmpEngine 2 }

   snmpEngineTime   OBJECT-TYPE
       SYNTAX       INTEGER (0..2147483647)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The number of seconds since the incoming response messages to outstanding
   messages sent by this SNMP engine, and forwards the response to the
   associated application using engine last
                    incremented the processResponsePdu primitive, as
   described snmpEngineBoots object.
                   "
       ::= { snmpEngine 3 }

   snmpEngineMaxMessageSize OBJECT-TYPE
       SYNTAX       INTEGER (484..2147483647)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The maximum length in section 4.2.

A.3.3.  Applications that Receive Asynchronous Messages

   When octets of an SNMP engine receives a message that is not the response to a
   request from
                    which this SNMP engine, it must determine to which application
   the message should be given.

   An Application that wishes to receive asynchronous messages registers
   itself with the engine using the primitive registerContextEngineID can send or receive and
                    process, determined as
   described in section 4.2.

   An Application that wishes to stop receiving asynchronous messages
   should unregister itself with the SNMP engine using minimum of the primitive
   unregisterContextEngineID as described in section 4.2.

   Only one registration per combination maximum
                    message size values supported among all of PDU type and contextEngineID
   is permitted at the same time. Duplicate registrations are ignored.
   An errorIndication will be returned
                    transports available to and supported by the application that attempts
   to duplicate a registration.

   All asynchronously received messages containing a registered
   combination 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 }

   snmpPrivProtocols OBJECT-IDENTITY
       STATUS        current
       DESCRIPTION  "Registration point for standards-track privacy
                     protocols used in SNMP Management Frameworks.
                    "
       ::= { snmpFrameworkAdmin 2 }

   -- Conformance information ******************************************

   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 }

       ::= { snmpFrameworkMIBCompliances 1 }

   -- units of conformance

   snmpEngineGroup OBJECT-GROUP
       OBJECTS {
                 snmpEngineID,
                 snmpEngineBoots,
                 snmpEngineTime,
                 snmpEngineMaxMessageSize
               }
       STATUS       current
       DESCRIPTION "A collection of PDU type objects for identifying and contextEngineID are sent to
                    determining the
   application which registered to support that combination. configuration and current timeliness
                    values of an SNMP engine.
                   "
       ::= { snmpFrameworkMIBGroups 1 }

   END

6.  Intellectual Property

   The engine forwards IETF takes no position regarding the PDU validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the registered application, using the
   processPdu primitive, as described in section 4.2.

A.3.4.  Applications that Send Responses

   Request operations require responses.  An application sends a
   response via implementation or use of the returnResponsePdu primitive, as technology described in section
   4.2.

   The contextEngineID, contextName, securityModel, securityName,
   securityLevel, and stateReference parameters are from the initial
   processPdu primitive. The PDU and statusInformation are the results
   of processing.

A.4.  Access Control Model Design Requirements

   An Access Control Model determines whether
   this document or the specified securityName
   is allowed extent to perform the requested operation on a specified managed
   object. The Access Control Model specifies the rules by which access
   control is determined.

   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.

   The Access Control Model must provide the primitive isAccessAllowed.

B.  Issues

   The change log will be deleted for last call; the issues list will any license under such rights
   might or might not be
   deleted when available; neither does it is time represent that it
   has made any effort to publish as an RFC.

B.1.  Showstoppers

B.2.  Open Issues

   -  we need a mechanism 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 a manager publication and any assurances of
   licenses to be able made available, or the result of an attempt made to discover what
      securityModels are supported by
   obtain a particular implementation

B.3.  Resolved Issues
    . contextEngineID in reportPDU = snmpEngineID of report generator
    . returnResponsePdu - are all parameters needed? overrides allowed?
       all parameters kept general license or permission for future flexibility
       overrides not supported by SNMPv3
    . the use of IN/OUT indicators in primitives accepted
    . NT/Unix-like access control - such
   proprietary rights by implementors or users of this specification can
   be defined as future model
    . user-friendly names? yes, but with limits
    . SnmpAdminString as index? yes, but restrict sizes
    . need both MMS and maxSizeResponseScopedPDU? yes.
    . synchronous vs. asynchronous primitives? synchronous preferred
    . should we change MIB naming? no, it is acceptable
    . is it ok that USM is bound obtained from the IETF Secretariat.

   The IETF invites any interested party to SNMPv3? while undesirable, it is
      acceptable. A cleaner model bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be defined required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

7.  Acknowledgements

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the future.
    . should securityModel "any" be supported? for ACM use, not following SNMPv3
    . what defines SNMPv3? a WG
   members:

       Dave Battle (SNMP Research, Inc.)
       Uri Blumenthal (IBM T.J. Watson Research Center)
       Jeff Case (SNMP Research, Inc.)
       John Curran (BBN)
       T. Max Devlin (Hi-TECH Connections)
       John Flick (Hewlett Packard)
       David Harrington (Cabletron Systems Inc.)
       N.C. Hien (IBM T.J. Watson Research Center)
       Dave Levi (SNMP Research, Inc.)
       Louis A Mamakos (UUNET Technologies Inc.)
       Paul Meyer (Secure Computing Corporation)
       Keith McCloghrie (Cisco Systems)
       Russ Mundy (Trusted Information Systems, Inc.)
       Bob Natale (ACE*COMM Corporation)
       Mike O'Dell (UUNET Technologies Inc.)
       Dave Perkins (DeskTalk)
       Peter Polkinghorne (Brunel University)
       Randy Presuhn (BMC Software, Inc.)
       David Reid (SNMP Research, Inc.)
       Shawn Routhier (Epilogue)
       Juergen Schoenwaelder (TU Braunschweig)
       Bob Stewart (Cisco Systems)
       Bert Wijnen (IBM T.J. Watson Research Center)

   The document will be published after Munich
    . Is an application-level handle needed for request/response matching?
      yes. create sendPduHandle
    . Is wild card contextEngineID/pduType registration needed? No. This is
      an internal interface, based on recommendations of the IETF Security and wild carding can be supported
   Administrative Framework Evolution for SNMP Advisory Team.  Members
   of that Advisory Team were:

       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)

   As recommended by an
      implementation, but is not required in the standard.
    . Should indices be integers or SnmpAdminStrings? SnmpAdminStrings
      is Advisory Team and the consensus.
    . Should protocols be identified as OIDs or Integers? OIDs
    . terminology:
       securityLevel rather than LoS
       msgXXXX to identify message fields in SNMPv3
    . OID or Integer for auth/priv protocol identifiers
      Consensus: use OID
    . Is Glossary needed to describe primitive parameters, or is Working Group
   Charter, the
      expanded template adequate for this purpose?
      Consensus: Terms design incorporates as much as practical from previous
   RFCs and drafts. As a result, special thanks are basically all defined in section 3.
    . state_reference releases
      Consensus: documents checked; we think it is OK now
    . new SnmpEngineID format rules to be discussed yet.
      Consensus: Limit size to be 1..32
    . needs changes to meet STDGUIDE guidelines
      We think we're meeting them now
    . we punted snmpEngineMaxMessageSize at 2nd interim because that
      info travels in each SNMPv3 message. However, we may want due to
      re-introduce it so that SNMPv1/v2c managers the authors
   of previous designs known as SNMPv2u and 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.)

8.  Security Considerations

   This document describes how an implementation can learn the value!!
      Consensus: Nobody picked up on this, so it seems not needed.
    . Do we need include a mechanism Security
   Model to discover securityModels supported
      Can be decided after Munich
    . add a "Decision History" section (as protect management messages and an appendix?)
      Can be decided after Munich

B.3.1.  Issues discussed at second Interim Meeting:
    . A "readable" introduction supplement may be done after Munich.
    . 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 are responsible for retries, but implementations may
        differ.
    . TCs should have access to data which is not be defined just secured.  Applications
   should take reasonable steps to describe primitive parameters.
      If they cannot be described adequately in text, they can be 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
      in a Glossary. Avoid describing by this
         architecture,

      2) the Security and Access Control Models utilized satisfy the
         security and access control needs of the organization,

      3) the implementations of the Models and Applications comply with
         the model and application specifications,

      4) and the implementation details.
    . Is SnmpAdminString appropriate protects configuration secrets from
         inadvertent disclosure.

9.  References

   [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification
      of Management Information for all strings, such as
      securityIdentifier TCP/IP-based internets", STD 16, RFC
      1155, May 1990.

   [RFC1157] Case, J., M. Fedor, M. Schoffstall, and context J. Davin, "The
      Simple Network Management Protocol", STD 15, RFC 1157, University
      of Tennessee at Knoxville, Performance Systems s International,
      Performance International, and group? These had different
      sizes the MIT Laboratory for Computer
      Science, May 1990.

   [RFC1212] Rose, M., and semantics.  size K. McCloghrie, "Concise MIB Definitions", STD
      16, RFC 1212, March 1991.

   [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and semantics may be defined in
      syntax S. Waldbusser, "Introduction to Community-based SNMPv2",
      RFC 1901, January 1996.

   [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and description S. Waldbusser, "Structure of OBJECT
    . AdminString has size (0..255); revisit Management Information for UTF-8 discussions
    . securityModel #s - 00
      Version  2 of the Simple Network Management Protocol (SNMPv2)",
      RFC 1902, January 1996.

   [RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S. Waldbusser, "Textual Conventions for IETF standards; from v2* documents
    . protocol IDs - integer or OID? voted 13-0 Version 2 of the
      Simple Network Management Protocol (SNMPv2)", RFC 1903, January
      1996.

   [RFC1904] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S. Waldbusser, "Conformance Statements for OID.
    . uniqueness Version 2 of securityName
    . mapping between principal
      the Simple Network Management Protocol (SNMPv2)", RFC 1904,
      January 1996.

   [RFC1905] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and securityName is outside scope S. Waldbusser, "Protocol Operations for Version 2 of WG.
    . principals may have more than one securityName in an entity
    . mappings may exist between many types the
      Simple Network Management Protocol (SNMPv2)", RFC 1905, January
      1996.

   [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.

   [RFC1907] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S. Waldbusser, "Management Information Base for Version 2
      of MDID the Simple Network Management Protocol (SNMPv2)", RFC 1907
      January 1996.

   [RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and a single
      securityName
    . mappings may exist S. Waldbusser, "Coexistence between different    (model, Name) and the same
      securityName by varying the model or the Name.
    . the securityName Version 1 and a MDID may be identical. This can be defined
      by Version
      2 of the SNMP-standard Network Management Framework", RFC 1908,
      January 1996.

   [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
      for SNMPv2", RFC1909, February 1996.

   [RFC1910] Waters, G., Editor, "User-based Security Model.
      (user,"public") may map to securityName "public"
    . [securityName, securityModel] yields zero or one MDName, with
      exceptions Model for backwards compatibility. The exception is defined
      by the model, and the problems are the province of the model to
      resolve.

B.4.  Change Log

   Current version

      -  Changed MIB objects from Integer32 to INTEGER to match USM
         fields.

      -  changed "network management" to simply "management"
      -  added caveat to EngineID selection algorithm

      -  Added language in register/deregister ASI to permit
         implementation-specific wildcarding, as agreed in Munich.

      -  re-worded description SNMPv2",
      RFC1910, February 1996.

   [RFC2044] Yergeau, F., "UTF-8, a transformation format of maxSizeResponseScopedPDU

      -  added Unicode and
      ISO 10646", RFC 2119 2044, October 1996.

   [RFC2119] Bradner, S., "Key words and referece

      -  added reference for UTF-8

      -  removed "none" reserved value from SnmpSecurityModel textual
         convention, changed "any" value from 255 to zero.

      -  modifications to SnmpAdminString agreed to use in Munich meeting

      -  updated editor list

      -  converted to nroff, with some minor layout changes
      [version 4.14]
       . formatting
       . pagination
      [version 4.13]
       . new acknowledgements
       . updated references
       . updated issues list
       . ordered security, editors, acknowledgements, references sections
       . checked line lengths
      [version 4.12]
       . cleanup
       . added expectResponse to processIncomingMsg to address Levi-raised
         concern
       . acknowledgements
       . MIB checked by SMICng
       . post RFCs to snmpv3 mailing list
      [version 4.11]
       . Change Primitives between MP Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.

   [BCP-11] Hovey, R., and SEC to try S. Bradner, "The Organizations Involved in
      the IETF Standards Process", BCP 11, RFC 2028, October 1996.

   [SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D.,
      Presuhn, R., and B. Wijnen, "Message Processing and address Dispatching
      for the issue
         of architectural binding to message format.
       . Added securityName Simple Network Management Protocol (SNMP)",
      draft-ietf-snmpv3-mpc-06.txt, October 1997.

   [SNMP-USM] The SNMPv3 Working Group, Blumenthal, U., and securityLevel to B. Wijnen,
      "The User-Based Security Model for Version 3 of the returnResponsePdu
         primitive so that architecturally it could be different Simple Network
      Management Protocol (SNMPv3)", draft-ietf-snmpv3-usm-03.txt,
      October 1997.

   [SNMP-ACM] The SNMPv3 Working Group, Wijnen, B., Presuhn, R., and K.
      McCloghrie, "View-based Access Control Model for a
         request the Simple
      Network Management Protocol (SNMP)", draft-ietf-snmpv3-acm-04.txt,
      October 1997.

   [SNMP-APPL] The SNMPv3 Working Group, Levi, D. B., Meyer, P., and a response.
       . Rename processMsg primitive to processIncomingMsg

      [version 4.10]
       . spell check

      [version 4.9]
       . editorial changes
       . fix SnmpEngineID TC
       . add a note to SnmpAdminString
       . rename title of section 1.1
       . expand description B.
      Stewart, "SNMPv3 Applications", <draft-ietf-snmpv3-appl-04.txt>,
      October 1997.

10.  Editor's Addresses

   Bert Wijnen
   IBM T.J. Watson Research
   Schagen 33
   3461 GL Linschoten
   Netherlands

   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

   Phone:      +1 603-337-7357
   EMail:      dbh@cabletron.com

   Randy Presuhn
   BMC Software, Inc.
   1190 Saratoga Avenue
   Suite 130
   San Jose, CA 95129
   USA

   Phone:      +1 408-556-0720
   EMail:      rpresuhn@bmc.com

APPENDIX A

A.  Guidelines for Model Designers

   This appendix describes guidelines for designers of Dispatcher a bit

      [version 4.8]
       . Added parameter pduVersion on primitives:
               sendPdu
               processPdu
               returnResponsePdu
               processResponsePdu
               prepareDataElements
               prepareOutgoingMessage
               prepareResponseMessage
       . Added parameter messageProcessingModel on models which are
   expected to fit into the primitive:
               processPdu
               processResponsePdu
               returnResponsePdu
       . Removed messageProcessingModel parameter from primitives:
               registerContextEngineID
               unregisterContextEngineID
       . Renamed architecture defined in this document.

   SNMPv1 and SNMPv2c are two SNMP Version Multiplexer frameworks which use communities to Dispatcher
       . Renamed Version Multiplexer
   provide trivial authentication and access control. SNMPv1 and SNMPv2c
   Frameworks can coexist with Frameworks designed according to Message Multiplexer
       . Renamed Application Multiplexer this
   architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks
   could be designed to PDU Dispatcher
       . Rearranged some parameters in various Primitives so meet the sequence requirements of parameters is now more consistent.

      [version 4.7]
       . editorial cleanup
       . changed asterisk text
       . modified snmpv3 framework description this architecture, but
   this document does not provide guidelines for that coexistence.

   Within any subsystem model, there should be no reference to eliminate dependencies
       . reorder 4.2.x any
   specific model of another subsystem, or to reflect transaction order
       . changed SnmpEngineID size 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 1..32

      [version 4.6]
       . Changes satisfy the needs of multiple model definitions.

   Documents which define models to be used within this architecture
   SHOULD use synchronous the standard primitives where possible
       . Changes between subsystems, possibly
   defining specific mechanisms for converting the abstract data
   elements into model-usable formats. This constraint exists to describe SNMP Version Multiplexer
       . Remove (empty) glossary
       . Redraw documentation figure
       . Redraw Operational Overview Figure
       . Remove old section 4 (Architectural Elements of Procedure)
         These moved allow
   subsystem and model documents to be written recognizing common
   borders of the MP document into 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 SNMP Version Multiplexer
         section.
       . Move Overview of all primitives from Appendix architecture defines abstract service
   interfaces to Section 4.
       . Simplify Appendix 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.1.  Security Model Design Requirements

A.1.1.  Threats

   A to just document describing a Security Model MUST describe how the model
   protects against the threats described under "Security Requirements
   of this Architecture", section 1.4.

A.1.2.  Security Processing

   Received messages MUST be validated by a Model Designer Guidelines of the Security
   Subsystem.  Validation includes authentication and refer back to section 4 for specific primitives
       . Remove Appendix B (An Evolutionary Architecture - Design Goals)
       . added design decision regarding security
       . Included latest Snmp SecurityModel TC (as privacy processing
   if needed, but it was actually posted
         to the SNMPv3 mailing list).

      [version 4.5]
       . start with <draft-ietf-snmpv3-next-gen-arch-03.txt>
       . change vendor to implementor
       . change LoS is explicitly allowed to send messages which do not
   require authentication or privacy.

   A received message contains a specified securityLevel
       . remove mention of enterprise
       . change Internet Management Framework to SNMP Management Framework
       . modify usage of "frameworks" to improve internal consistency.
       . change Message Processing Abstract Service Interface to
         Application Multiplexor
       . change description of SNMP engine
       . moved "one-to-one association" for entity be used
   during processing.  All messages requiring privacy MUST also require
   authentication.

   A Security Model specifies rules by which authentication and engine to discussion
         of engine.
       . changed distributing privacy
   are to dispatching
       . added asterisks be done.  A model may define mechanisms to indicate v3* items are also not required.
       . changed "community access control" provide additional
   security features, but the model definition is constrained to "other access control"
       . added TC for SnmpMessageProcessingModel
       . modified Security Considerations
       . modified acknowledgements

      [version 4.4]
       . Fixed one error in using
   (possibly a subset of) the MIB (found with SMICng)
       . Reformatted text for SnmpAdminString, no change abstract data elements defined in text.
       . Changed text for SnmpEngineID..  this is still under discussion.
         But this new text seems
   document for transferring data between subsystems.

   Each Security Model may allow multiple security protocols to be getting close to what we want.
       . Added used
   concurrently within an issue w.r.t. snmpEngineMaxMessageSize
       . adapt Primitive names implementation of the model. Each Security
   Model defines how to determine which protocol to use, given the
   securityLevel and the security parameters relevant to very latest (July 11) names
       . removed blank lines before the .p page controls.
       . publish as <draft-ietf-snmpv3-next-gen-arch-03.txt>

      [version 4.3]
       . some minor editing adjustments
      [version 4.2]
       . modify abstract so there is no requirement for one entity
          to contain both a command generator and a notification receiver.
       . modify Introduction list of message.
   Each Security Model, with its associated protocol(s) defines how the
   sending/receiving entities which are meant to be identified, and how secrets are
   configured.

   Authentication and Privacy protocols supported
       . reorganized sections 1 through 4 by Security Models are
   uniquely identified using Object Identifiers. IETF standard protocols
   for more consistency in contents.
       . described section contents in Introduction:Target Audience
       . move documentation descriptions to section 2
       . rewrite section 4 to authentication or privacy should have an identifier defined
   within the snmpAuthProtocols or the snmpPrivProtocols subtrees.
   Enterprise specific protocol identifiers should be more like a real elements defined within the
   enterprise subtree.

   For privacy, the Security Model defines what portion of procedure.
       . modified SnmpSecurityModel and SnmpEngineID definitions
       . replaced MIB with Bert's replacement
       . added Randy's TC for SnmpAdminString
       . modified the example algorithm text message
   is encrypted.

   The persistent data used for SnmpEngineID
       . rewrote security considerations for brevity.

       . modified "context" description
       . moved "Threats" to Goals/Requirements
       . eliminated snmpEngineMaxMessageSize object
       . posted to snmpv3 (by DBH)
      [version 4.1]
       . Adopt "abstract" to new terminology
       . Addressed all comments I (BW) made to DBH in should be SNMP-manageable, but
   the Security Model defines whether an earlier email
       . Changed Introduction section to new terminology
       . changed wording for "implementation" to indicate it instantiation of the MIB is a
   conformance requirement.

   Security Models are replaceable within the Security Subsystem.
   Multiple Security Model implementations may contain
         multiple models.
       . Section 2. Started some wording on Goals and Design decisions
       . Added exist concurrently within
   an SNMP engine.  The number of Security Models defined by the SNMP
   community should remain small to promote interoperability.

A.1.3.  Validate the overview picture of security-stamp in a traditional agent and received message

   A Message Processing Model requests that a
         traditional manager. This is in section 2.
       . Changed overview figure in section 3. to address Security Model:
     - verifies that the comments
         by Dave Levi. It now lists message has not been altered,
     - authenticates the type identification of applications
       . At various places ensure that text (easily) fits within 72
         columns as required by RFC-editors Guidelines document.
       . Section 2.3 (new section) has the documents set overview.
         I verified principal for whom the claims about standards. Not sure I worded
       message was generated.
     - decrypts the
         SNMPv2 std correctly,. We'll hear it if we did it wrong.
       . Section 2.4 (new section) gives overview of SNMP entities based
         on modified Dave Levi figure. I (Bert) wonder however message if it would
         not was encrypted.

   Additional requirements may be better to move it to after section 3.1.13
       . Section 3. Added more figures... please let us know if you find
         then useful and/or helpful. We could also move these back to
         section 2 if such makes more sense.
       . Added a picture in section 3.2.
         It also shows some of access control, so not sure it really fits
         here, although it does map principal to model-dependent security
         ID to securityName
       . Replace "<" with "is lower than" in section 3.4.3 which seems
         better in a text document.
       . Renamed section 4.1 to "SNMP engine processing" instead of
         "The Message Processing Subsystem" because defined by the transport
         mappings, mpc multiplexor model, and such is done in ARCH document so
         it is done "in general in additional
   services may be provided by the engine" and it passes a specific
         message to a Message Processing Subsystem.
       . "bulletized" some stuff in section 4.2 and 4.3.
         Dave, this model, but the model is just how I (Bert) like it better. Feel free to
         undo it if you strongly disagree
       . Section 4.3 changed "initiate a transaction" constrained
   to "originate a
         notification".
       . Inserted title line use the following primitives for section 4.4 (I think it was missing)
         I have named it "Information Model" in accordance with transferring data between
   subsystems. Implementations are not so constrained.

   A Message Processing Model uses the change
         I made (after Russ's comments) processMsg primitive as described
   in section 4.5.

A.1.4.  Security MIBs

   Each Security Model defines the document figure to lump SMI,
         TC and Conformance together.
       . Inserted a title MIB module(s) required for section 4.5 named "Operational Model" to
         get in sync 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 lumping together of ProtoOps and Transport
         Mappings in document overview
       . Renumber section 4.4.4 to 4,5,1 and added 4.5.2 MIB module(s).  The
   MIB module(s) are subject to follow normal access control rules.

   The mapping between the
         document overview figure. If we really want to follow it, then
         maybe we should also reorder some of these sections. Like
         Access Control seems specifically misplaced. So I decided to move
         it before applications as section 4.3, so model-dependent security ID and the 4.x above should
         all
   securityName MUST be read as 4.x+1
       . Removed size from SnmpEngineID TC... why did you limit it to
         (0..2048). Did we not decide to leave it open?
       . Should we not remove snmpEngineMaxMessageSize from the MIB.
         That was agreed at 2nd interim. It travels in every message and so
         seems able to be useless. However, I think it could indeed still help
         SNMPv1 or SNMPv2c managers.
       . I kept your definitions of registration-points for auth and priv
         protocols, but my recollection determined using SNMP, if the model-
   dependent MIB is that they would be completely
         removed from ARCH instantiated and if access control policy allows
   access.

A.1.5.  Cached Security Data

   For each message received, the Security Model caches the state
   information such that it would all a Response message can be done in SEC document.
       . Modified Security Considerations. Was still talking about LPM.
       . Appendix. I am still wondering generated using the
   same security information, even if we need to use capitals for
         things like "Security Model" "Subsystem" and such. This is only
         an appendix... but we better be consistent, no? Anyway
         I changed it so it the Local Configuration Datastore
   is consistent (at least I tried).
       . Appendix, renamed imf to snmpFramework
       . Appendix, changed state_reference and state_release to
         stateReference altered between the time of the incoming request and stateRelease to be consistent with other names 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 and primitives.
       . A.2 changed MessageEngine to SNMP engine
       . Fixed ASI primitives to be in sync with SEC document.
         I also thought that our ARCH document-outline wanted element is passed from
   the Security Model to at least
         have the primitives listed within Message Processing Model.

   The cached security data may be implicitly released via the main body
   generation of a response, or explicitly released by using the text, no?
       . Adapted send_pdu to sendPdu primitive
   stateRelease primitive, as reconciled by Randy
         In fact I made sure all primitives are in-line with current
         agreement on names and parameters.
       . Rename title of A.2.4 and A.2.5 so it fits on 1 line described in contents
       . I did not look at appendix B. That is your (DBH) specialty is it
         not ?  ;-).
       . Quick simple spell check done with "spell" on AIX
      [version 4.0]
       . move section 7 - 4.1.

A.2.  Message Processing Model Requirements to an appendix
       . move Section 3 - Design Goals to an appendix
       . modified Section 5 - Naming
       . remove "possibly multiple"
       . moved Section 5 to Section 3
       . change orangelets to applications
       . modify description of applications
       . change scopedPDU-MMS and PDU-MMS to maxSizeResponseScopedPDU
       . change Scoped-PDU and ScopedPDU to scopedPDU (no dash, lower case S)
       . change imfxxx to snmpFrameworkxxx
       . change security-entity to principal
       . change securityIdentity to securityName
       . change MIID to securityName
       . eliminate all reference to groupName or group
       . LoS ordering noAuthNoPriv < authNoPriv < authPriv
       . Los TC  naming - noAuthNoPriv(1), authNoPriv(2), authPriv(3)
       . remove TCs not used in MIBs - securityIdentity TC etc
       . changed Requirements

   An SNMP engine contains a Message Processing Subsystem which may
   contain multiple Message Processing Models.

   The Message Processing Model MUST always (conceptually) pass the
   complete PDU, i.e., it never forwards less than the complete list of
   varBinds.

A.2.1.  Receiving an SNMP Message from the Network

   Upon receipt of a message from the network, the Dispatcher in the
   SNMP engine determines the version of the SNMP message and Control to interacts
   with the corresponding Message Processing
       . changed future tense Model to present tense
       . eliminate messageEngine
       . added/updated primitives
       . addressed issues raised on determine the mailing list

      [version 3.1]
       . change securityIdentity to MIID
       . write text to explain
   abstract data elements.

   A Message Processing Model specifies the differences between security-identities,
         model-dependent identifiers, SNMP Message format it
   supports and model-independent identifiers.
       . write text describes how to explain distinction within determine the LCD 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
         data,
   processing for the access control data, and message using the orangelet data.
       . identify issues
       . publish processMsg primitive, as <draft-ietf-snmpv3-next-gen-arch-02.txt>

      [version 3.0]
       . add section on threats for message security
       . add
   described in section on threats for access control
       . change application to orangelet
       . remove references to F-Ts
       . change securityIdentity to security-identity
       . change securityCookie 4.5.

A.2.2.  Sending an SNMP Message to securityIdentity
       . the format of securityIdentity is defined by Network

   The Dispatcher in the model
       . add securityModel SNMP engine interacts with a Message Processing
   Model to passed parameters prepare an outgoing message. For that it uses the following
   primitives:

      -  for requests and notifications: prepareOutgoingMessage, as needed
       . eliminate group from passed parameters
       . remove unused IMPORTS
       . add glossary
         described in section 4.4

      -  for response messages: prepareResponseMessage, as described in
         section 4.4

   A Message Processing Model, when preparing an Outgoing SNMP Message,
   interacts with initial set of words a Security Model to define
       . differentiate secure the messageEngine from message. For that it
   uses the following primitives:

      -  for requests and notifications: generateRequestMsg, as
         described in section 4.5.

      -  for response messages: generateResponseMsg as described in
         section 4.5.

      Once the SNMP message is prepared by a Message Processing Model,
      the contextEngine
       . eliminate Dispatcher sends the term SNMPng
       . rewrote 1.1. A Note on Terminology
       . eliminated assumptions about SNMP processing always being message related
       . rewrote 4.x to reflect new thinking
       . rewrote 5.x to reflect new thinking
       . rewrote 6.x (the MIB) to reflect new thinking
       . added MIB objects at this level (previously only TCs)
       . rewrote 7.x
       . sent the desired address using the
      appropriate transport.

A.3.  Application Design Requirements

   Within an application, there may be an explicit binding to v3edit list
                            Table of Contents

1. Introduction ...................................................    2

1.1. Overview .....................................................    2

1.2. a specific
   SNMP .........................................................    2

1.3. Goals of this Architecture ...................................    3

1.4. Security Requirements of this Architecture ...................    4

1.5. Design Decisions .............................................    5

2. Documentation Overview .........................................    6

2.1. Document Roadmap .............................................    8

2.2. Applicability Statement ......................................    8

2.3. Coexistence message version, i.e., a specific Message Processing Model, and Transition ...................................    8

2.4. Transport Mappings ...........................................    8

2.5.
   to a specific Access Control Model, but there should be no reference
   to any data defined by a specific Message Processing ...........................................    9

2.6. Model or Access
   Control Model.

   Within an application, there should be no reference to any specific
   Security .....................................................    9

2.7. 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 ...............................................    9

2.8. Protocol Operations ..........................................   10

2.9. Model should be used.

   An application has the responsibility to define any MIB module(s)
   used to provide application-specific services.

   Applications .................................................   10

2.10. Structure of Management Information .........................   10

2.11. Textual Conventions .........................................   10

2.12. Conformance Statements ......................................   11

2.13. Management Information Base Modules .........................   11

2.13.1. interact with the SNMP engine to initiate messages,
   receive responses, receive asynchronous messages, and send responses.

A.3.1.  Applications that Initiate Messages

   Applications may request that the SNMP Instrumentation MIBs .................................   11

2.14. engine send messages
   containing SNMP Framework Documents ....................................   11

3. Elements commands or notifications using the sendPdu primitive
   as described in section 4.2.

   If it is desired that a message be sent to multiple targets, it is
   the responsibility of the Architecture ...................................   12

3.1. application to provide the iteration.

   The Naming of Entities .......................................   12

3.1.1. SNMP entity ................................................   13

3.1.2. engine assumes necessary access control has been applied to
   the PDU, and provides no access control services.

   The SNMP engine ................................................   13

3.1.3. snmpEngineID ...............................................   14

3.1.4. Dispatcher .................................................   14

3.1.5. Message Processing Subsystem ...............................   15

3.1.6. Message Processing Model ...................................   15

3.1.7. Security Subsystem .........................................   16

3.1.8. Security Model .............................................   16

3.1.9. Security Protocol ..........................................   16

3.1.10. Access Control Subsystem ..................................   17

3.1.11. Access Control Model ......................................   17

3.1.12. 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.

A.3.2.  Applications ..............................................   17

3.1.13. that Receive Responses

   The SNMP Manager ..............................................   18

3.1.14. engine matches the incoming response messages to outstanding
   messages sent by this SNMP Agent ................................................   19

3.2. The Naming of Identities .....................................   20

3.2.1. Principal ..................................................   20

3.2.2. securityName ...............................................   20

3.2.3. Model-dependent security ID ................................   21

3.3. The Naming of Management Information .........................   22

3.3.1. engine, and forwards the response to the
   associated application using the processResponsePdu primitive, as
   described in section 4.2.

A.3.3.  Applications that Receive Asynchronous Messages

   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.

   An Application that wishes to receive asynchronous messages registers
   itself with the engine using the primitive registerContextEngineID as
   described in section 4.2.

   An Application that wishes to stop receiving asynchronous messages
   should unregister itself with the SNMP Context ............................................   23

3.3.2. contextEngineID ............................................   23

3.3.3. contextName ................................................   24

3.3.4. scopedPDU ..................................................   24

3.4. Other Constructs .............................................   24

3.4.1. maxSizeResponseScopedPDU ...................................   24

3.4.2. Local Configuration Datastore ..............................   24

3.4.3. securityLevel ..............................................   24

4. Abstract Service Interfaces.  ..................................   25

4.1. Common Primitives ............................................   25

4.1.1. Release State Reference Information ........................   25 engine using the primitive
   unregisterContextEngineID as described in section 4.2. Dispatcher Primitives ........................................   25

4.2.1. Generate Outgoing Request or Notification ..................   25

4.2.2. Process Incoming Request or Notification

   Only one registration per combination of PDU ...............   26

4.2.3. Generate Outgoing Response .................................   27

4.2.4. Process Incoming Response 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.

   All asynchronously received messages containing a registered
   combination of PDU ..............................   27

4.2.5. Registering Responsibility for Handling SNMP PDUs.  ........   27

4.3. Message Processing Subsystem Primitives ......................   28

4.3.1. Prepare Outgoing SNMP type and contextEngineID are sent to the
   application which registered to support that combination.

   The engine forwards the PDU to the registered application, using the
   processPdu primitive, as described in section 4.2.

A.3.4.  Applications that Send Responses

   Request or Notification Message ......   28

4.3.2. Prepare an Outgoing SNMP Response Message ..................   29

4.3.3. Prepare Data Elements operations require responses.  An application sends a
   response via the returnResponsePdu primitive, as described in section
   4.2.

   The contextEngineID, contextName, securityModel, securityName,
   securityLevel, and stateReference parameters are from an Incoming SNMP Message ........   30

4.4. the initial
   processPdu primitive. The PDU and statusInformation are the results
   of processing.

A.4.  Access Control Subsystem Primitives ..........................   30

4.5. Security Subsystem Primitives ................................   31

4.5.1. Generate a Request or Notification Message .................   31

4.5.2. Process Incoming Message ...................................   31

4.5.3. Generate a Response Message ................................   32

4.6. Common Primitives ............................................   32

4.6.1. Release State Reference Information ........................   32

4.7. Scenario Diagrams ............................................   33

4.7.1. Command Generator or Notification Originator ...............   33

4.7.2. Scenario Diagram for a Command Responder Application .......   34

5. Managed Object Definitions for SNMP Management Frameworks ......   35

6. Security Considerations ........................................   44

7. Editor's Addresses .............................................   45

8. Acknowledgements ...............................................   45

9. References .....................................................   47

A. Guidelines for Model Designers .................................   49

A.1. Security Model Design Requirements ...........................   49

A.1.1. Threats ....................................................   49

A.1.2. Security Processing ........................................   50

A.1.3. Validate

   An Access Control Model determines whether the security-stamp in specified securityName
   is allowed to perform the requested operation on a received message ..........   50

A.1.4. Security MIBs ..............................................   51

A.1.5. Cached Security Data .......................................   51

A.2. Message Processing specified managed
   object. The Access Control Model Design Requirements .................   51

A.2.1. Receiving an SNMP Message from specifies the Network .................   52

A.2.2. Sending an SNMP Message to rules by which access
   control is determined.

   The persistent data used for access control should be manageable
   using SNMP, but the Access Control Model defines whether an
   instantiation of the Network .....................   52

A.3. Application Design Requirements ..............................   52

A.3.1. Applications that Initiate Messages ........................   53

A.3.2. Applications that Receive Responses ........................   53

A.3.3. Applications that Receive Asynchronous Messages ............   53

A.3.4. Applications that Send Responses ...........................   54

A.4. MIB is a conformance requirement.

   The Access Control Model Design Requirements .....................   54 must provide the primitive isAccessAllowed.

B.  Issues .........................................................   55

   The issues list will be deleted when it is time to publish as an RFC.

B.1. Showstoppers .................................................   55

B.2.  Open Issues ..................................................   55

B.3. Resolved Issues ..............................................   55

B.3.1. Issues discussed at second Interim Meeting: ................   56

B.4.

   -  we need a mechanism for a manager to be able to discover what
      securityModels are supported by a particular implementation

B.2.  Change Log ...................................................   56

   Current version

      -  Minor layout and editorial clarifications.

      -  Adjusted layout per RFC 2223 and added copyright statements
         required by RFC 2026.

      -  Removed duplicate description of common primitives.

C.  Full Copyright Statement

   Copyright (C) The Internet Society (1997).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation 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.