An Architecture for Describing
                       SNMP Management Frameworks

                              1 August 1997
INTERNET-DRAFT                                             D. Harrington
                                                 Cabletron Systems, Inc.
                            dbh@cabletron.com
                                                              R. Presuhn
                                                      BMC Software, Inc.
                                                               B. Wijnen
                                               IBM T.J. T. J. Watson Research
                           wijnen@vnet.ibm.com

                <draft-ietf-snmpv3-next-gen-arch-04.txt>
                                                       30 September 1997

                     An Architecture for Describing
                       SNMP Management Frameworks
                <draft-ietf-snmpv3-next-gen-arch-05.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), nic.nordu.net (Europe), or
   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Coast).

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 network management data.

Harrington/Wijnen         Expires  February 1998              [Page  1]

0. Issues

0.1. Resolved Issues
 . contextEngineID in reportPDU = snmpEngineID of report generator
 . returnResponsePDU - are all parameters needed? overrides allowed?
    all parameters kept for future flexibility
    overrides not supported by SNMPv3
 . use of IN/OUT indicators in primitives accepted
 . NT/Unix-like access control - 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 to SNMPv3? while undesirable, it is
   acceptable. A cleaner model may be defined in the future.
 . should securityModel "any" be supported? for ACM use, not SNMPv3
 . what

1.  Introduction

1.1.  Overview

   This document defines SNMPv3? a document will be published after Munich
 . Is vocabulary for describing SNMP Management
   Frameworks, and an application-level handle needed architecture for request/response matching?
   yes. create sendPduhandle
 . Is wildcard contextEngineID/pduType registration needed? No. describing the major portions of
   SNMP Management Frameworks.

   This is
   an internal interface, document does not provide a general introduction to SNMP. Other
   documents and wildcarding books can provide a much better introduction to SNMP.
   Nor does this document provide a history of SNMP. That also can be supported by an
   implementation, but is not required
   found in books and other documents.

   Section 1 describes the standard.
 . Should indices be integers or SnmpAdminStrings? SnmpAdminStrings
   is the consensus.
 . Should protocols be identified as OIDs or Integers? OIDs
 . terminology:
    securityLevel rather than LoS
    msgXXXX purpose, goals, and design decisions of this
   architecture.

   Section 2 describes various types of documents which define SNMP
   Frameworks, and how they fit into this architecture. It also provides
   a minimal road map to identify message fields in SNMPv3
 . OID or Integer the documents which have previously defined
   SNMP frameworks.

   Section 3 details the vocabulary of this architecture and its pieces.
   This section is important for auth/priv protocol identifiers
   Consensus: use OID
 . Is Glossary needed understanding the remaining sections,
   and for understanding documents which are written to describe primitive parameters, or is fit within this
   architecture.

   Section 4 describes the
   expanded template adequate primitives used for the abstract service
   interfaces between the various subsystems, models and applications
   within this purpose?
   Consensus: Terms architecture.

   Section 5 defines a collection of managed objects used to instrument
   SNMP entities within this architecture.

   Sections 6, 7, 8, and 9 are basically all defined administrative in section 3.
 . state_reference releases
   Consensus: documents checked; we think it is OK now
 . new SnmpEngineID format rules nature.

   Appendix A contains guidelines for designers of Models which are
   expected to be discussed yet.
   Consensus: Limit size fit within this architecture.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are 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 interpreted as described in each SNMPv3 message. However, we may want [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 have access to
   re-introduce it so that SNMPv1/v2c managers can learn the value!!
   Consensus: Nobody picked up on this, so it seems not needed.
 . Do we need management instrumentation
         (traditionally called agents);

      -  at least one SNMP entity containing command generator and/or
         notification receiver applications (traditionally called a mechanism to discover securityModels supported
   Can be decided after Munich
 . add
         manager) and,

      -  a "Decision History" section (as an appendix?)
   Can be decided after Munich

Harrington/Wijnen         Expires  February 1998              [Page  2]

0.1.1. Issues discussed at second Interim Meeting:

 . A "readable" introduction supplement may be done after Munich.
 . Applications are responsible for retries, but implementations may
     differ.
 . TCs should not be defined just management protocol, used to describe primitive parameters.
   If they cannot be described adequately in text, they can be defined
   in a Glossary. Avoid describing implementation details.
 . Is SnmpAdminString appropriate for all strings, such as
   securityIdentifier and context convey management information
         between the SNMP entities.

   SNMP entities executing command generator and group? These had different
   sizes notification receiver
   applications monitor and semantics.  size control managed elements.  Managed elements
   are devices such as hosts, routers, terminal servers, etc., which are
   monitored and semantics may be defined controlled via access to their management information.

   It is the purpose of this document to define an architecture which
   can evolve to realize effective management in
   syntax and description a variety of OBJECT
 . AdminString
   configurations and environments. The architecture has size (0..255); revisit for utf8 discussions
 . securityModel #s been designed
   to meet the needs of implementations of:

      - 00 for IETF standards; from v2* documents
 . protocol IDs  minimal SNMP entities with command responder and/or
         notification originator applications (traditionally called SNMP
         agents),

      - integer  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),

      -  SNMP entities with  command generator and/or notification
         receiver, plus command responder and/or notification originator
         applications (traditionally called SNMP mid-level managers or OID? voted 13-0 for OID.
 . uniqueness of securityName
 . mapping between principal
         dual-role entities),

      -  SNMP entities with command generator and/or notification
         receiver and securityName is outside scope of WG.
 . principals may have more than one securityName in an entity
 . mappings may exist between many possibly other types of MDID and applications for managing
         a single
   securityName
 . mappings may exist between different    (model, Name) and the same
   securityName potentially very large number of managed nodes (traditionally
         called (network) management stations).

1.3.  Goals of this Architecture

   This architecture was driven by varying the model or the Name.
 . the securityName following goals:

      -  Use existing materials as much as possible. It is heavily based
         on previous work, informally known as SNMPv2u and a MDID may be identical. This can be defined
   by SNMPv2*.

      -  Address the Security Model.
   (user,"public") may map to securityName "public"
 . [securityName, securityModel] yields zero or one MDName, with
   exceptions need for backwards compatibility. The exception secure SET support, which is defined
   by the model, and considered
         the problems are the province of the model to
   resolve.

Harrington/Wijnen         Expires  February 1998              [Page  3]

0.2.  Change Log

[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 to snmpv3 mailing list
[version 4.11]
 . Change Primitives between MP most important deficiency in SNMPv1 and SEC SNMPv2c.

      -  Make it possible to try and address the issue move portions of architectural binding to message format.
 . Added securityName and securityLevel to the returnResponsePdu
   primitive so architecture forward
         in the standards track, even if consensus has not been reached
         on all pieces.

      -  Define an architecture that architecturally it could be different allows for a
   request longevity of the SNMP
         Frameworks that have been and a response.
 . Rename processMsg primitive will be defined.

      -  Keep SNMP as simple as possible.

      -  Make it relatively inexpensive to processIncomingMsg

[version 4.10]
 . spell check

[version 4.9]
 . editorial changes
 . fix SnmpEngineID TC
 . add deploy a note minimal conforming
         implementation.

      -  Make it possible to SnmpAdminString
 . rename title upgrade portions of section 1.1
 . expand description 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 expense of Dispatcher supporting a bit

[version 4.8]
 . Added parameter pduVersion on primitives:
         sendPdu
         processPdu
         returnResponsePdu
         processResponsePdu
         prepareDataElements
         prepareOutgoingMessage
         prepareResponseMessage
 . Added parameter messageProcessingModel on feature directly
         related to the primitive:
         processPdu
         processResponsePdu
         returnResponsePdu
 . Removed messageProcessingModel parameter from primitives:
         registerContextEngineID

Harrington/Wijnen         Expires  February 1998              [Page  4]
         unregisterContextEngineID
 . Renamed SNMP Version Multiplexer support of the feature.

1.4.  Security Requirements of this Architecture

   Several of the classical threats to Dispatcher
 . Renamed Version Multiplexer network protocols are applicable
   to Message Multiplexer
 . Renamed Application Multiplexer the management problem and therefore would be applicable to PDU Dispatcher
 . Rearranged some parameters any
   Security Model used in various Primitives so an SNMP Management Framework. Other threats
   are not applicable to the sequence management problem.  This section discusses
   principal threats, secondary threats, and threats which are of parameters lesser
   importance.

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

   Modification of Information
      The modification threat is now more consistent.

[version 4.7]
 . editorial cleanup
 . changed asterisk text
 . modified snmpv3 framework description to eliminate dependencies
 . reorder 4.2.x to reflect transaction order
 . changed SnmpEngineID size to 1..32

[version 4.6]
 . Changes to use synchronous primitives where possible
 . Changes to describe the danger that some unauthorized SNMP Version Multiplexer
 . Remove (empty) glossary
 . Redraw documentation figure
 . Redraw Operational Overview Figure
 . Remove old section 4 (Architectural Elements
      entity may alter in-transit SNMP messages generated on behalf of Procedure)
   These moved
      an authorized principal in such a way as to effect unauthorized
      management operations, including falsifying the MP document into value of an
      object.

   Masquerade
      The masquerade threat is the SNMP Version Multiplexer
   section.
 . Move Overview danger that management operations not
      authorized for some principal may be attempted by assuming the
      identity of all primitives from Appendix to Section 4.
 . Simplify Appendix A to just described Model Designer Guidelines another principal that has the appropriate
      authorizations.

   Message Stream Modification
      The SNMP protocol is typically based upon a connectionless
      transport service which may operate over any subnetwork service.
      The re-ordering, delay or replay of messages can and 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 it was actually posted
   to does occur
      through the SNMPv3 mailing list).

[version 4.5]
 . start with <draft-ietf-snmpv3-next-gen-arch-03.txt>
 . change vendor to implementor
 . change LoS to securityLevel
 . remove mention natural operation of enterprise
 . change Internet Management Framework many such subnetwork services.
      The message stream modification threat is the danger that messages
      may be maliciously re-ordered, delayed or replayed to SNMP Management Framework
 . modify usage an extent
      which is greater than can occur through the natural operation of "frameworks" to improve internal consistency.
 . change Message Processing Abstract Service Interface a
      subnetwork service, in order to
   Application Multiplexor
 . change description effect unauthorized management
      operations.

   Disclosure
      The disclosure threat is the danger of eavesdropping on the
      exchanges between SNMP engine
 . moved "one-to-one association" for entity and engine to discussion engines.  Protecting against this threat
      may be required as a matter of engine.
 . changed distributing to dispatching
 . added asterisks to indicate v3* items local policy.

   There are also not required.
 . changed "community access control" to "other access control"
 . added TC for SnmpMessageProcessingModel
 . modified at least two threats against which a Security Considerations
 . modified acknowledgements

[version 4.4]

Harrington/Wijnen         Expires  February 1998              [Page  5]
 . Fixed one error in the MIB (found with SMICng)
 . Reformatted text for SnmpAdminString, no change in text.
 . Changed text for SnmpEngineID..  this is still under discussion.
   But Model within
   this new text seems to be getting close to what we want.
 . Added an issue w.r.t. snmpEngineMaxMessageSize
 . adapt Primitive names and parameters architecture need not protect.

   Denial of Service
      A Security Model need not attempt to very latest (july 11) names
 . removed blank lines before address 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 broad range of entities
      attacks by which service on behalf of authorized users is denied.
      Indeed, such denial-of-service attacks are meant to be
   supported
 . reorganized sections 1 through 4 for more consistency in contents.
 . described section contents in Introduction:Target Audience
 . move documentation descriptions to section 2
 . rewrite section 4 many cases
      indistinguishable from the type of network failures with which any
      viable management protocol must cope as a matter of course.

   Traffic Analysis
      A Security Model need not attempt to address traffic analysis
      attacks.  Many traffic patterns are predictable - entities may be more like
      managed on a real elements regular basis by a relatively small number of procedure.
 . modified SnmpSecurityModel and SnmpEngineID definitions
 . replaced MIB with Bert's replacement
 . added Randy's TC for SnmpAdminString
 . modified the example algorithm text 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 an earlier email
 . Changed Introduction section to new terminology
 . changed wording for "implementation" to indicate it may contain
   multiple models.
 . Section 2. Started some wording on Goals
      management stations - and therefore there is no significant
      advantage afforded by protecting against traffic analysis.

1.5.  Design Decisions

   Various design decisions
 . Added were made in support of the overview picture goals of a traditional agent the
   architecture and a
   traditional manager. This is in section 2.
 . Changed overview figure in section 3. to address the comments
   by Dave Levi. It now lists security requirements:

      - Architecture
         An architecture should be defined which identifies the type
         conceptual boundaries between the documents. Subsystems should
         be defined which describe the abstract services provided by
         specific portions of applications
 . At various places ensure that text (easily) fits within 72
   columns an SNMP framework. Abstract service
         interfaces, as required described by RFC-editors Guidelines document.
 . Section 2.3 (new section) has service primitives, define the documents set overview.
   I verified
         abstract boundaries between documents, and the claims about standards. Not sure I worded abstract
         services that are provided by the
   SNMPv2 std correctly,. We'll hear it if we did it wrong.
 . Section 2.4 (new section) gives overview conceptual subsystems of an
         SNMP entities based
   on modified Dave Levi figure. I (Bert) wonder however if it would
   not 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.

Harrington/Wijnen         Expires  February 1998              [Page  6]
 . Added a picture in section 3.2.
   It also shows some framework.

      - Self-contained Documents
         Elements 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 procedure plus the MIB objects which seems
   better in are needed for
         processing for a text document.
 . Renamed section 4.1 to "SNMP engine processing" instead specific portion of
   "The Message Processing Subsystem" because an SNMP framework should
         be defined in the transport
   mappings, mpc multiplexor same document, and such is done as much as possible,
         should not be referenced in ARCH document so
   it other documents. This allows pieces
         to be designed and documented as independent and self-contained
         parts, which is done "in consistent with the general in SNMP MIB module
         approach.  As portions of SNMP change over time, the engine" documents
         describing other portions of SNMP are not directly impacted.
         This modularity allows, for example, Security Models,
         authentication and privacy mechanisms, and it passes a specific message formats to a Message Processing Subsystem.
 . "bulletized" some stuff
         be upgraded and supplemented as the need arises. The self-
         contained documents can move along the standards track on
         different time-lines.

      - Threats
         The Security Models in section 4.2 the Security Subsystem SHOULD protect
         against the principal threats: modification of information,
         masquerade, message stream modification and 4.3.
   Dave, this is just how I (Bert) like it better. Feel free to
   undo it if you strongly disagree
 . Section 4.3 changed "initiate a transaction" disclosure.  They
         do not need to "originate protect against denial of service and traffic
         analysis.

      - Remote Configuration
         The Security and Access Control Subsystems add a
   notification".
 . Inserted title line for section 4.4 (I think it was missing)
   I have named it "Information Model" in accordance with whole new set
         of SNMP configuration parameters.  The Security Subsystem also
         requires frequent changes of secrets at the change
   I made (after Russ's comments) various SNMP
         entities. To make this deployable in a large operational
         environment, these SNMP parameters must be able to be remotely
         configured.

      - Controlled Complexity
         It is recognized that producers of simple managed devices want
         to keep the document figure resources used by SNMP to lump SMI,
   TC and Conformance together.
 . Inserted a title minimum.  At the same
         time, there is a need for section 4.5 named "Operational Model" more complex configurations which can
         spend more resources for SNMP and thus provide more
         functionality.  The design tries to
   get in sync with the keep the lumping together competing
         requirements of ProtoOps and Transport
   Mappings these two environments in document overview
 . Renumber section 4.4.4 to 4,5,1 balance and added 4.5.2 to follow allows
         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 more complex environments to move
   it before applications as section 4.3, so logically extend the 4.x above should
   all 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 simple
         environment.

2.  Documentation Overview

   The following figure shows the MIB.
   That was agreed at 2nd interim. It travels in every message and so
   seems to be useless. However, I think it could indeed still help
   SNMPv1 or SNMPv2c managers.
 . I kept your definitions set of registration-points for auth and priv
   protocols, but my recollection is that they would be completely
   removed from ARCH and that it would all be done in SEC document.
 . Modified Security Considerations. Was still talking about LPM.
 . Appendix. I am still wondering 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 is consistent (at least I tried).
 . Appendix, renamed imf to snmpFramework
 . Appendix, changed state_reference and state_release to
   stateReference and stateRelease to be consistent with other names
   for abstract data and primitives.
 . A.2 changed MessageEngine to SNMP engine
 . Fixed ASI primitives to be in sync with SEC document.
   I also thought documents that our ARCH document-outline wanted to at least
   have the primitives listed within the main body of the text, no?

Harrington/Wijnen         Expires  February 1998              [Page  7]
 . Adapted send_pdu to sendPdu 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 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 - 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 Message Processing and Control to Message Processing
 . changed future tense to present tense
 . eliminate messageEngine
 . added/updated primitives
 . addressed issues raised on the mailing list

[version 3.1]
 . change securityIdentity to MIID
 . write text to explain the differences between security-identities,
   model-dependent identifiers, and model-independent identifiers.
 . write text to explain distinction within the LCD of the security
   data, the access control data, and the orangelet data.
 . identify issues
 . publish as <draft-ietf-snmpv3-next-gen-arch-02.txt>

[version 3.0]
 . add section on threats for message security
 . add section on threats for access control
 . change application to orangelet
 . remove references to F-Ts
 . change securityIdentity to security-identity
 . change securityCookie to securityIdentity
 . the format of securityIdentity is defined by the model
 . add securityModel to passed parameters as needed
 . eliminate group from passed parameters
 . remove unused IMPORTS

Harrington/Wijnen         Expires  February 1998              [Page  8]
 . add glossary section with initial set of words to define
 . differentiate the messageEngine from the contextEngine
 . eliminate 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 to v3edit list

Harrington/Wijnen         Expires  February 1998              [Page  9]

1. Introduction

1.1. Overview

This document assumes an audience with varying levels of technical
understanding of SNMP.

This document does not provide a general introduction to SNMP. Other
documents and books can provide a much better introduction to SNMP.
Nor does this document provide a history of SNMP. That also can be
found in books and other documents.

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

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

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

Section 3 details the vocabulary of this architecture and its pieces.
This section is important for understanding the remaining sections,
and for understanding documents which are written to fit within this
architecture.

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 of managed objects used to instrument
SNMP entities within this architecture.

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

Appendix A contains guidelines for designers of Models which are
expected to fit within this architecture.

1.2. SNMP Management Systems

  An SNMP management system contains:
    - several (potentially many) nodes, each with an SNMP entity
      containing command responder and notification originator
      applications, which have access to management instrumentation;
    - at least one SNMP entity containing command generator and/or
      notification receiver applications; and,
    - a management protocol, used to convey management information
      between the SNMP entities.

  SNMP entities executing command generator and notification receiver
  applications monitor and control managed elements.  Managed elements
  are devices such as hosts, routers, terminal servers, etc., which
  are monitored and controlled via access to their management
  information.

  It is the purpose of this document to define an architecture which
  can evolve to realize effective network management in a variety
  of configurations and environments. The architecture has been
  designed to meet the needs of implementations of:
    - minimal SNMP entities with command responder and/or notification
      originator applications (traditionally called SNMP agents),
    - SNMP 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),
    - SNMP entities with  command generator and/or notification
      receiver, plus command responder and/or notification originator
      applications (traditionally called SNMP mid-level managers or
      dual-role entities),
    - SNMP entities with command generator and/or notification
      receiver and possibly other types of applications for managing
      a potentially very large number of managed nodes (traditionally
      called network management stations).

1.3. Goals of this Architecture

This architecture was driven by the following goals:

   - Use existing materials as much as possible. It is heavily based
     on previous work, informally known as SNMPv2u and SNMPv2*.
   - Address the need for secure SET support, which is considered
     the most important deficiency in SNMPv1 and SNMPv2c.
   - Make it possible to move portions of the architecture forward
     in the standards track, even if consensus has not been reached
     on all pieces.
   - Define an architecture that allows for longevity of the SNMP
     Frameworks that have been and will be defined.
   - Keep SNMP as simple as possible.
   - Make it relatively inexpensive to deploy a minimal conformant
     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 expense of supporting a feature directly related
     to the support of the feature.

1.4. Security Requirements of this Architecture

Several of the classical threats to network protocols are applicable
to the network management problem and therefore would be applicable
to any Security Model used in an SNMP Management Framework. Other
threats are not applicable to the network management problem.  This
section discusses principal threats, secondary threats, and threats
which are of lesser importance.

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

Modification of Information
   The modification threat is the danger that some unauthorized 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 the danger that management operations
   not authorized for some principal may be attempted by assuming
   the identity of another principal that has the appropriate
   authorizations.

Message Stream Modification
   The SNMP protocol is typically based upon a connectionless
   transport service which may operate over any subnetwork service.
   The re-ordering, delay or replay of messages can and does occur
   through the natural operation of many such subnetwork services.
   The message stream modification threat is the danger that messages
   may be maliciously re-ordered, delayed or replayed to an extent
   which is greater than can occur through the natural operation of
   a subnetwork service, in order to effect unauthorized management
   operations.

Disclosure
   The disclosure threat is the danger of eavesdropping on the
   exchanges between SNMP engines.  Protecting against this threat
   may be required as a matter of local policy.

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 in many cases
   indistinguishable from the type of network failures with which any
   viable network management protocol must cope as a matter of course.

Traffic Analysis
   A Security Model need not attempt to address traffic analysis
   attacks.  Many traffic patterns are predictable - entities may
   be managed on a regular basis by a relatively small number of
   management stations - and therefore there is no significant
   advantage afforded by protecting against traffic analysis.

1.5. Design Decisions

Various designs decision were made in support of the goals of the
architecture and the security requirements:

   - Architecture
     An architecture should be defined which identifies the conceptual
     boundaries between the documents. Subsystems should be defined
     which describe the abstract services provided by specific
     portions of an SNMP framework. Abstract service interfaces, as
     described by service primitives, define the abstract boundaries
     between documents, and the abstract services that are provided
     by the conceptual subsystems of an SNMP framework.

   - Self-contained Documents
     Elements of procedure plus the MIB objects which are needed for
     processing for a specific portion of an SNMP framework should be
     defined in the same document, and as much as possible, should
     not be referenced in other documents. This allows pieces to be
     designed and documented as independent and self-contained parts,
     which is consistent with the general SNMP MIB module approach.
     As portions of SNMP change over time, the documents describing
     other portions of SNMP are not directly impacted. This modularity
     allows, for example, Security Models, authentication and privacy
     mechanisms, and message formats to be upgraded and supplemented
     as the need arises. The self-contained documents can move along
     the standards track on different time-lines.

   - The Security Models in the Security Subsystem SHOULD protect
     against the principal threats: modification of information,
     masquerade, message stream modification and disclosure.
     They do not need to protect against denial of service and
     traffic analysis.

   - Remote Configuration
     The Security and Access Control Subsystems add a whole new set
     of SNMP configuration parameters.  The Security Subsystem also
     requires frequent changes of secrets at the various SNMP
     entities. To make this deployable in a large operational
     environment, these SNMP parameters must be able to be remotely
     configured.

   - Controlled Complexity
     It is recognized that simple managed devices want to keep the
     resources used by SNMP to a minimum.  At the same time, there
     is a need for more complex configurations which can spend more
     resources for SNMP and thus provide more functionality.
     The design tries to keep the competing requirements of these
     two environments in balance and allows the more complex
     environments to logically extend the simple environment.

2.  Documentation Overview

The following figure shows the set of documents that fit fit within the
   SNMP Architecture.

 +--------------------------

   +------------------------- Document Set ----------------------------+
   |                                                                   |
   | +------------+            +-----------------+  +----------------+ |
   | | Document * |            | Applicability * |  | Coexistence  * | |
   | | Roadmap    |            | Statement       |  | & Transition   | |
   | +------------+            +-----------------+  +----------------+ |
   |                                                                   |
   | +----------------------------------------------------------------+ +---------------------------------------------------------------+ |
   | | Message Handling                                              | |
   | | +-----------------+ +----------------+  +-----------------+  +-----------------+  | |
   | | | Transport      |  | Message         |  | Security        |  | |
   | | | Mappings       |  | Processing and  |  |                 |  | |
   | | |                |  | Dispatching 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 the
   future. Each of these documents may be replaced or supplemented.
   This Architecture document specifically describes how new documents
   fit into the set of documents in the area of Message and PDU
   handling.

2.1.  Document Roadmap

   One or more documents may be written to describe how sets of
   documents taken together form specific Frameworks. The configuration
   of document sets might change over time, so the "roadmap" "road map" should be
   maintained in 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 of network management.
   Some models will be designed to address specific problems of network
   management, such as message security.

   One or more documents may be written to describe the environments to
   which certain versions of SNMP or models within SNMP would be
   appropriately applied, and those to which a given model might be
   inappropriately applied.

2.3.  Coexistence and Transition

   The purpose of an evolutionary architecture is to permit new models
   to replace or supplement existing models. The interactions between
   models could result in incompatibilities, security "holes", and other
   undesirable effects.

   The purpose of Coexistence documents is to detail recognized
   anomalies and to describe required and recommended behaviors for
   resolving the interactions between models within the architecture.

It would be very difficult to document all the possible interactions
between a model and all other previously existing models while in the
process of developing a new model.

   Coexistence documents are therefore expected to may be prepared separately from model
   definition documents, to describe and resolve interaction anomalies
   between a model definition and one or more other model definitions.

   Additionally, recommendations for transitions between models may also
   be described, either in a coexistence document or in a separate
   document.

2.4.  Transport Mappings

   SNMP messages are sent over various transports. It is the purpose of
   Transport Mapping documents to define how the mapping between SNMP
   and the transport is done.

2.5.  Message Processing

   A Message Processing Model document defines a message format, which
   is typically identified by a version field in an SNMP message header.
   The document may also define a MIB module for use in message
   processing and for instrumentation of version-specific interactions.

   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:

      -  in the transmission/receipt of messages, and

      -  in the processing of the contents of messages.

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

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

   A security document describes a Security Model, the threats against
   which the model protects, the goals of the Security Model, the
   protocols which it uses to meet those goals, and it may define a MIB
   module to describe the data used during processing, and to allow the
   remote configuration of message-level security parameters, such as
   passwords.

   An SNMP engine may support multiple Security Models concurrently.

2.7.  Access Control

   During processing, it may be required to control access to certain
instrumentation managed
   objects for certain operations.

   An Access Control Model
determines whether access to an object should be allowed. The
mechanism by which access control is checked is defined by the
Access Control Model.

An Access Control Model document defines the mechanisms used to determine whether
   access to a managed object should be allowed,
and allowed.  An Access Control
   Model may define a MIB module used during processing, processing and to allow the
   remote configuration of access control policies.

2.8.  Protocol Operations

   SNMP messages encapsulate an SNMP Protocol Data Unit (PDU). It is the
   purpose of a Protocol Operations document to define the operations of
   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 entity normally includes a number of applications.
   Applications use the services of an SNMP engine to accomplish
   specific tasks. They coordinate the processing of management
   information operations, and may use SNMP messages to communicate with
   other SNMP entities.

   Applications documents describe the purpose of an application, the
   services required of the associated SNMP engine, and the protocol
   operations and informational model that the application uses to
   perform network management operations.

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

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
   Information Base (MIB). Collections of related objects are defined in
   MIB modules.

   It is the purpose of a 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 to those defined in the SMI, but with more precise semantics,
   or which have special semantics associated with them. These newly
   defined types are termed textual conventions, and may defined in
   separate documents, or within a MIB module.

2.12.  Conformance Statements

   It may be useful to define the acceptable lower-bounds of
   implementation, along with the actual level of implementation
   achieved. It is the purpose of 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 a 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 the documents for Message processing Models,
   Security Models, etc. for the purpose of instrumenting those Models,
   and for the purpose of allowing remote configuration of the Model.

2.14.  SNMP Framework Documents

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

   Throughout the rest of this document, the term "subsystem" refers to
   an abstract and incomplete specification of a portion of a Framework,
   that is further refined by a model specification.

   A "model" describes a specific design of a subsystem, defining
   additional constraints and rules for conformance to the model.  A
   model is sufficiently detailed to make it possible to implement the
   specification.

   An "implementation" is an instantiation of a subsystem, conforming to
   one or more specific models.

   SNMP version 1 (SNMPv1), is the original Internet-standard Network
   Management Framework, as described in RFCs 1155, 1157, and 1212.

   SNMP version 2 (SNMPv2), is the SNMPv2 Framework as derived from 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 SNMP
   Framework which supplements the SNMPv2 Framework, as described in
   RFC1901. It adds the SNMPv2c message format, which is similar to the
   SNMPv1 message format.

   SNMP version 3 (SNMPv3), is an extensible SNMP Framework which
   supplements the SNMPv2 Framework, by supporting the following:
  - a new SNMP message format,
  - Security following:

      -  a new SNMP message format,

      -  Security for Messages, and

      -  Access Control.

   Other SNMP Frameworks, i.e., other configurations of implemented
   subsystems, are expected to also be consistent with this
   architecture.

3.  Elements of the 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 Messages, and
  - Access Control.

Other SNMP Frameworks, i.e. other configurations of implemented
subsystems, constructs that
   are expected to also be consistent with this architecture.

2.15. Operational Overview

The following pictures show two communicating SNMP entities using used in the conceptual modularity described by this SNMP Architecture. documentation.

3.1.  The pictures represent SNMP entities that have traditionally been
called Naming of Entities

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

   +-------------------------------------------------------------------+
   |  SNMP agent respectively.
* One or more models may be present.

                      (traditional entity                                                      |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  SNMP manager)
 +--------------------------------------------------------------------+ engine (identified by snmpEngineID)                   |  |
   |  |                                                             |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |  |            | |            | |           | |           |  |  |
   |  |  | Dispatcher | | Message    | | Security  | | Access    |  |  |
   |  |  |            | | Processing | | Subsystem | | Control   |  |  |
   |  |  |            | | Subsystem  | |           | | Subsystem |  |  |
   |  |  |            | |            | |           | |           |  |  |
   |  |  +------------+ +------------+ +-----------+ +-----------+  |  |
   |  |                                                             |  |
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   |  +-------------------------------------------------------------+  |
   |  |  Application(s)                                             |  |
   |  |                                                             |  |
   |  |  +-------------+  +--------------+  +--------------+  +--------------+   SNMP entity        |  |
   | NOTIFICATION  |  | NOTIFICATION Command     |  | Notification |  | Proxy        |        |  |
   |  |  | Generator   |  | Receiver     |  | Forwarder    |        |  |
   |  |  +-------------+  +--------------+  +--------------+        |  |
   |   COMMAND  |                                                             |  |
   |  ORIGINATOR  |  +-------------+  +--------------+  +--------------+        |   RECEIVER  |
   |  GENERATOR  |  | Command     |  | applications Notification |  | applications Other        |        | applications  |
   |  | +--------------+  +--------------+  +--------------+  | Responder   |         ^                ^                 ^  | Originator   |  |              |        |  |
   |         v                v                 v  |  +-------------+  +--------------+  +--------------+        |         +-------+--------+-----------------+  |
   |                 ^  |                                                             |  |     +---------------------+  +-----------------+
   |  +-------------------------------------------------------------+  |
   |                                                                   |
   +-------------------------------------------------------------------+

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 for sending and receiving messages,
   authenticating and encrypting messages, and controlling access to
   managed objects. There is a one-to-one association between an SNMP
   engine and the SNMP entity which contains it.

   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, an snmpEngineID is the unique and
   unambiguous identifier of an SNMP engine. Since there is a one-to-one
   association between SNMP engines and SNMP entities, it also uniquely
   and unambiguously identifies the SNMP entity.

3.1.4.  Dispatcher

   There is only one Dispatcher in an SNMP engine. It allows for
   concurrent support of multiple versions of SNMP messages in the SNMP
   engine. It does so by:

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

      -  determining the version of an SNMP message and interact with
         the corresponding Message Processing Model,

      -  providing an abstract interface to SNMP applications for
         delivery of a PDU to an application.

      -  providing an abstract interface for SNMP applications that
         allows them to send a PDU to 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  |  | Security        | |
 | Dispatcher      v     | Subsystem           |  | Subsystem       | |
 | +-------------------+ |     +------------+  |  |                 | |
 | | PDU Dispatcher    | |  +->| v1MP     * |<--->| +-------------+ | |
 | |                   | |  |  +------------+  |  | | Other       | | |
 | |                   | |  |  +------------+  |  | | Security    | | |
 | |                   | |  +->| v2cMP    * |<--->| | Model       | | |
 | | potentially contains multiple
   Message           | |  |  +------------+  |  | +-------------+ | |
 | | Dispatcher  <--------->+                  |  |                 | |
 | |                   | |  |  +------------+  |  | +-------------+ | |
 | |                   | |  +->| v3MP     * |<--->| | User-based  | | |
 | | Transport         | |  |  +------------+  |  | | Security    | | |
 | | Mapping           | |  |  +------------+  |  | | Model       | | |
 | | (e.g RFC1906)     | |  +->| otherMP Processing Models as shown in the next figure.

   * |<--->| +-------------+ | |
 | +-------------------+ |     +------------+  |  |                 | |
 |          ^            +---------------------+  +-----------------+ |
 |          |                                                         |
 |          v                                                         |
 +--------------------------------------------------------------------+
 +-----+ +-----+       +-------+
 | UDP | | IPX | . . . | other |
 +-----+ +-----+       +-------+
    ^       ^              ^
    |       |              |
    v       v              v
 +------------------------------+
 |           Network            |
 +------------------------------+
 +------------------------------+
 |           Network            |
 +------------------------------+
    ^       ^              ^
    |       |              |
    v       v              v
 +-----+ +-----+       +-------+
 | UDP | One or more Message Processing Models may be present.

   +------------------------------------------------------------------+
   | IPX                                                                  | . . .
   | other  Message Processing Subsystem                                    |
 +-----+ +-----+       +-------+               (traditional SNMP agent)
 +--------------------------------------------------------------------+
   |              ^                                                                  |
   |  +------------+  +------------+  +------------+  +------------+  |        +---------------------+  +-----------------+
   |  |          * |  | Message Processing          * |  | Security          * |  |          * | Dispatcher   v  | Subsystem
   |  | Subsystem SNMPv3     |  | SNMPv1     | +-------------------+  |     +------------+ SNMPv2c    |  | Other      |  |
   |  | Transport Message    |  |  +->| v1MP     * |<--->| +-------------+ Message    |  | Message    |  | Mapping Message    |  |
   |  +------------+  | Processing |  | Other Processing |  | Processing |  | Processing | (e.g. RFC1906)  |
   |  |  +------------+ Model      |  | Model      | Security  | Model      |  | Model      |  |
   |  |  +->| v2cMP    * |<--->|            | Model  |            |  |            |  | Message            |  |
   |  +------------+  +------------+  +------------+  +------------+  |
   | +-------------+                                                                  |
   +------------------------------------------------------------------+

3.1.6.  Message Processing Model

   Each Message Processing Model defines the format of a particular
   version of an SNMP message and coordinates the preparation and
   extraction of each such version-specific messages.

3.1.7.  Security Subsystem

   The Security Subsystem provides security services such as the
   authentication and privacy of messages and potentially contains
   multiple Security Models as shown in the following figure

   * One or more Security Models may be present.

   +------------------------------------------------------------------+
   |                                                                  |
   | Dispatcher  <--------->+  Security Subsystem                                              |
   |                                                                  |
   |  +----------------+  +-----------------+  +-------------------+  |
   |  |              * |  |  +------------+               * |  | +-------------+                 * |  |
   |  | User-Based     |  |  +->| v3MP     * |<--->| Other           | User-based  | Other             |  |
   |  | Security       |  | Security        |  +------------+  | Security          |  | Security
   |  | Model          |  | Model           |  | Model             |  |  +------------+
   |  |                | Model  |                 |  |                   |  | PDU Dispatcher
   |  +----------------+  +-----------------+  +-------------------+  |  +->| otherMP  * |<--->| +-------------+
   |                                                                  |
   +------------------------------------------------------------------+

3.1.8.  Security Model

   A Security Model defines the threats against which it protects, the
   goals of its services, and the security protocols used to provide
   security services such as authentication and privacy.

3.1.9.  Security Protocol

   A Security Protocol defines the mechanisms, procedures, and MIB data
   used to provide a security service 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                                        |
   |                                                                  |
   |              ^        +---------------------+  +---------------+   +-----------------+   +------------------+  |
   |  |             * |   |              v                                                     |
 |      +-------+-------------------------+----------------+          |
 |      ^                                 ^                ^          |
 |      |                                 |               * |   |                * |      v                                 v                v  |
   | +-------------+   +---------+   +--------------+   +-------------+  | View-Based    |   |   COMMAND Other           |   | ACCESS Other            |  | NOTIFICATION
   |  |    PROXY  * Access        |   | Access          |   |  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR Access           |  |  FORWARDER
   |  | Control       |   | application Control         |   | Control          |  | applications
   |  | application Model         |   | Model           | +-------------+   +---------+   +--------------+   +-------------+   | Model            |      ^                                 ^  |
   |  |               |   |                 |      v                                 v   |                  | +----------------------------------------------+  |
   |  +---------------+   +-----------------+   +------------------+  |             MIB instrumentation
   |       SNMP entity                                                                  |
 +--------------------------------------------------------------------+

3. Elements of the Architecture

This section describes the various elements of the architecture and
how they are named.
   +------------------------------------------------------------------+

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 three kinds of naming:

  1) the naming of entities,
  2) the naming several types of identities, applications, including:

      -  command generators, which monitor and
  3) the naming of manipulate management information.

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

3.1. The Naming
         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 Entities

The following picture shows detail about the services provided by the 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 an SNMP entity and how
components within it are named.

 +--------------------------------------------------------------------+ manager.
   * One or more models may be present.

                       (traditional SNMP manager)
   +-------------------------------------------------------------------+
   | +--------------+  +--------------+  +--------------+  SNMP entity |
   | | NOTIFICATION |  +--------------------------------------------------------------+  | NOTIFICATION |  |  SNMP engine (identified by snmpEngineID)   COMMAND    |              |
   | |  ORIGINATOR  |  |   RECEIVER   |  |  +-------------+ +------------+ +-----------+ +-----------+  GENERATOR   |              |
   | | applications |  | applications |  | applications |              |
   | +--------------+  +--------------+  +--------------+              |
   |         ^                ^                 ^                      |
   |         |                | Dispatcher                 |                      | Message
   |         v                v                 v                      | Security
   |         +-------+--------+-----------------+                      | Access
   |                 ^                                                 |
   |                 |     +---------------------+  +----------------+ |
   |                 |     | Message Processing  |  | Subsystem | | Control Security       | |
   | Dispatcher      v     | Subsystem           |  | Subsystem      | | Subsystem
   | +-------------------+ |     +------------+  |  | Subsystem                | |
   | | PDU Dispatcher    | |  +->| v1MP     * |<--->| +------------+ | |
   | |                   | |  |  +------------+  |  | | Other      |  +-------------+ +------------+ +-----------+ +-----------+ | |
   | |                   | |  |  +--------------------------------------------------------------+  +------------+  |  | | Security   |  +--------------------------------------------------------------+ | |
   |  Application(s) |                   | |  +->| v2cMP    * |<--->| | Model      | | |
   |  +-------------+  +--------------+  +--------------+ | Message           | |  |  +------------+  | Command  | +------------+ | Notification |
   | Proxy | Dispatcher  <--------->+                  |  |                | |
   | Generator |                   | Receiver |  | Forwarder  +------------+  |  | +------------+ | |
   |  +-------------+  +--------------+  +--------------+ |                   | |  +->| v3MP     * |<--->| | User-based | | |
   |  +-------------+  +--------------+  +--------------+ | Transport         | |  |  +------------+  | Command  | | Notification Security   | | Other |
   | | Mapping           | |  | Responder  +------------+  |  | Originator | Model      | | |
   | | (e.g RFC1906)     |  +-------------+  +--------------+  +--------------+ |  +->| otherMP  * |<--->| +------------+ | |
   | +-------------------+ |     +------------+  |  |  +--------------------------------------------------------------+                | |
   |
 +--------------------------------------------------------------------+

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 for sending and receiving messages,
authenticating and encrypting messages, and controlling access to
managed objects. There is a one-to-one association between an SNMP
engine and the SNMP entity which contains it.

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, an snmpEngineID is the unique
and unambiguous identifier of an SNMP engine. Since there is a
one-to-one association between SNMP engines and          ^            +---------------------+  +----------------+ |
   |          |                                                        |
   |          v                                                        |
   +-------------------------------------------------------------------+
   +-----+ +-----+       +-------+
   | UDP | | IPX | . . . | other |
   +-----+ +-----+       +-------+
      ^       ^              ^
      |       |              |
      v       v              v
   +------------------------------+
   |           Network            |
   +------------------------------+

3.1.14.  SNMP entities,
it also uniquely and unambiguously identifies the Agent

   An SNMP entity.

3.1.4. Dispatcher

There is only entity containing one Dispatcher in an SNMP engine. It allows for
concurrent support of multiple versions of SNMP messages in the
SNMP engine. It does so by:

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

  - determining the version of an SNMP message and interact or more command responder and/or
   notification originator applications (along with the corresponding Message Processing Model,

  - providing an abstract interface to their associated
   SNMP applications for
    dispatching a PDU to an application.

  - providing engine) has traditionally been called an abstract interface for SNMP applications that
    allows them to send a PDU to a remote agent.
   +------------------------------+
   |           Network            |
   +------------------------------+
      ^       ^              ^
      |       |              |
      v       v              v
   +-----+ +-----+       +-------+
   | UDP | | IPX | . . . | other |
   +-----+ +-----+       +-------+              (traditional SNMP entity.

3.1.5. Message Processing Subsystem

The agent)
   +-------------------------------------------------------------------+
   |              ^                                                    |
   |              |        +---------------------+  +----------------+ |
   |              |        | Message Processing  |  | Security       | |
   | Dispatcher   v        | Subsystem is responsible for preparing
messages for sending, and extracting data from received messages.

The Message Processing           |  | Subsystem potentially contains multiple
Message Processing Models as shown in the next picture.
* One or more Message Processing Models may be present.

 +------------------------------------------------------------------+      | |
   |  Message Processing Subsystem +-------------------+ |     +------------+  |  |                | |
   |  +------------+  +------------+  +------------+  +------------+ | Transport         | |  +->| v1MP     * |<--->| +------------+ | |          *
   | |          * Mapping           | |          *  |  +------------+  |  | | SNMPv3 Other      | | SNMPv1 |
   | SNMPv2c | (e.g. RFC1906)    | | Other  |  +------------+  |  | | Message Security   | | Message |
   | Message |                   | Message |  +->| v2cMP    * |<--->| | Model      | | Processing |
   | Processing | Message           | Processing |  | Processing  +------------+  |  | +------------+ | | Model
   | | Model Dispatcher  <--------->|  +------------+  |  | Model +------------+ | | Model
   | |                   | |  +->| v3MP     * |<--->| | User-based | | |
   | |                   | |  |  +------------+  +------------+  +------------+  +------------+  |  | |
 +------------------------------------------------------------------+

3.1.6. Message Processing Model

Each Message Processing Model defines the format of a particular
version of an SNMP message and coordinates the preparation and
extraction of each such version-specific messages.

3.1.7. Security Subsystem

The Security Subsystem provides security services such as the
authentication and privacy of messages and potentially contains
multiple Security Models as shown in the next picture.
* One or more Security Models may be present.

 +------------------------------------------------------------------+
 |   | |  Security Subsystem |
   | | PDU Dispatcher    |  +----------------+  +-----------------+  +-------------------+ |  |  +------------+  |              *  | |               * Model      | |                 * |
   | +-------------------+ |  +->| otherMP  * |<--->| +------------+ | User-Based |
   | Other              ^        |     +------------+  | Other  |                | |
   | Security              |        +---------------------+  +----------------+ | Security
   |              v                                                    | Security
   |      +-------+-------------------------+---------------+          |
   |      ^                                 ^               ^          | Model
   |      | Model                                 |               | Model          |
   |      v                                 v               v          |
   | +-------------+   +---------+   +--------------+  +-------------+ |
   | |   COMMAND   |   | ACCESS  |   |  +----------------+  +-----------------+  +-------------------+ NOTIFICATION |  |    PROXY  * |
 +------------------------------------------------------------------+

3.1.8. Security Model

A Security Model defines the threats against which it protects,
the goals of its services, and the security protocols used to provide
security services such as authentication and privacy.

3.1.9. Security Protocol

A Security Protocol defines the mechanisms, procedures, and MIB
data used to provide a security service 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  RESPONDER  |<->| CONTROL |<->|  ORIGINATOR  |  |  FORWARDER  | |  +---------------+   +-----------------+   +------------------+
   | | application |             *   |         |               *   | applications |                *  | application | |
   | View-Based +-------------+   +---------+   +--------------+  +-------------+ |
   | Other      ^                                 ^                          |
   | Other      |                                 |                          |
   | Access      v                                 v                          |
   | Access +----------------------------------------------+                  |
   | Access |             MIB instrumentation              |      SNMP entity |
   +-------------------------------------------------------------------+

3.2.  The Naming of Identities

                            principal
                                ^
                                | Control
                                |
   +----------------------------|-------------+
   | Control SNMP engine                v             |
   | Control                    +--------------+      |
   |                    |              | Model      |
   | Model  +-----------------| securityName |---+  |
   |  | Security 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 of applications, including:

  - command generators, which monitor and manipulate management data,
  - command responders, which provide access to management data,
  - notification originators, which initiate asynchronous messages,
  - notification receivers, which process asynchronous messages, and
  - proxy forwarders, which forward messages between entities.

These applications make use of the services provided by the SNMP
engine.

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

3.1.14. 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 SNMP manager.

3.2. The Naming of Identities

principal  <---------------------------------+                         |
       +-------------------------------------|-----+          |  SNMP engine  |
   |  |                         v          |  |
   |  +-----------------------+  |  +------------------------------+  |  |
   | Security Model  |  |                              |  |  |  +-------------+
   |  |  |
  wire Model                        |  |  |
   | Model  |    +------------+--+  |
<----------->| Dependent   |<-->|                    | securityName|  |  |
   |  |  | 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; 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 model-independent
    format, and can be used outside a particular Security Model.

3.2.3. Model dependent  Model-dependent security ID

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

Model dependent

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

   The transformation of model dependent 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 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 context, or just "context" 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 short, 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
management these sets of information accessible by is referred to as an SNMP entity. An item
   entity's Local Configuration Datastore (LCD).

3.4.3.  securityLevel

   This architecture recognizes three levels of
management information may exist in more 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 one context. An SNMP
engine potentially
   authNoPriv and authNoPriv is less than authPriv.

   Every message has access to many contexts.

Typically, there an associated securityLevel. All Subsystems
   (Message Processing, Security, Access Control) and applications are many instances
   required to either supply a value of each managed object type 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 management domain. For simplicity, 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 method for identifying
instances specified SNMP applications
   via its PDU Dispatcher.  This section describes the primitives
   provided by the MIB module does not allow each instance 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 distinguished amongst the set of all instances within a management
domain; rather, it allows each instance used
     IN   transportAddress          -- transport address to be identified only within
some scope or "context", where there are multiple such contexts within
the management domain.  Often, a 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 is a physical device,
     IN   pduVersion                -- the version of the PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   expectResponse            -- TRUE or
perhaps, a logical device, although a context can also encompass
multiple devices, FALSE
          )

4.2.2.  Process Incoming Request or a subset 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 a single device, or even a subset this principal
     IN   securityLevel             -- Level of
multiple devices, but a Security
     IN   contextEngineID           -- data from/at this SNMP entity
     IN   contextName               -- data from/in this context is always defined as a subset
     IN   pduVersion                -- the version of a
single the PDU
     IN   PDU                       -- SNMP entity.  Thus, in order to identify an individual item Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size of
management the Response PDU
     IN   stateReference            -- reference to state information within
          )                         -- needed when sending a response

4.2.3.  Generate Outgoing Response

   The PDU Dispatcher provides the management domain, its contextName
and contextEngineID must be identified in addition following primitive for an
   application to return an SNMP Response PDU to its object type
and its instance.

For example, the managed object type ifDescr [RFC1573], is defined PDU Dispatcher:

   returnResponsePdu(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model in use
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- same as on incoming request
     IN   contextEngineID           -- data from/at this SNMP entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the description version of a network interface.  To identify the description PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   maxSizeResponseScopedPDU  -- maximum size of device-X's first network interface, four pieces 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

4.2.4.  Process Incoming Response PDU

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

   processResponsePdu(              -- process Response PDU
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel             -- Security Model in use
     IN   securityName              -- on behalf of information are
needed: the snmpEngineID this principal
     IN   securityLevel             -- Level of the Security
     IN   contextEngineID           -- data from/at this SNMP entity which provides access to
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the management information at device-X, version of the contextName (device-X), PDU
     IN   PDU                       -- SNMP Protocol Data Unit
     IN   statusInformation         -- success or errorIndication
     IN   sendPduHandle             -- handle from sendPdu
          )

4.2.5.  Registering Responsibility for Handling SNMP PDUs.

   Applications can register/unregister responsibility for a specific
   contextEngineID, for specific pduTypes, with the managed object type (ifDescr), and PDU Dispatcher
   according to these primitives:

   statusInformation =            -- success or errorIndication
     registerContextEngineID(
     IN   contextEngineID         -- take responsibility for this one
     IN   pduType                 -- the instance ("1").

Each context has (at least) pduType(s) to be registered
          )

   unregisterContextEngineID(
     IN   contextEngineID         -- give up responsibility for this one unique identification within
     IN   pduType                 -- the
management domain. The same item of management information can exist
in multiple contexts. So, an item pduType(s) to be unregistered
          )

   Note that realizations of management information can have
multiple unique identifications, either because it exists in multiple
contexts, and/or because each such context has multiple unique
identifications.

The combination the registerContextEngineID and
   unregisterContextEngineID abstract service interfaces may provide
   implementation-specific ways for applications to register/deregister
   responsiblity for all possible values of a the contextEngineID and a contextName unambiguously
identifies or
   pduType parameters.

4.3.  Message Processing Subsystem Primitives

   The Dispatcher interacts with a context within an administrative domain.

3.3.2. contextEngineID

Within an administrative domain, Message Processing Model to process a contextEngineID uniquely
identifies
   specific version of an SNMP entity that may realize Message. This section describes the
   primitives provided by the Message Processing Subsystem.

4.3.1.  Prepare Outgoing SNMP Request or Notification Message

   The Message Processing Subsystem provides this service primitive for
   preparing an instance of a
context with a particular contextName.

3.3.3. contextName

A contextName is outgoing SNMP Request or Notification Message:

   statusInformation =              -- success or errorIndication
     prepareOutgoingMessage(
     IN   transportDomain           -- transport domain to be used
     IN   transportAddress          -- transport address to name a context. Each contextName
MUST be unique within an used
     IN   messageProcessingModel    -- typically, SNMP entity.

3.3.4. scopedPDU

A scopedPDU is a block version
     IN   securityModel             -- Security Model to use
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- Level of Security requested
     IN   contextEngineID           -- data containing a contextEngineID,
a contextName, and a PDU.

The from/at this entity
     IN   contextName               -- data from/in this context
     IN   pduVersion                -- the version of the PDU is an
     IN   PDU                       -- SNMP Protocol Data Unit containing information
named in
     IN   expectResponse            -- TRUE or FALSE
     IN   sendPduHandle             -- the handle for matching
                                    -- incoming responses
     OUT  destTransportDomain       -- destination transport domain
     OUT  destTransportAddress      -- destination transport address
     OUT  outgoingMessage           -- the message to send
     OUT  outgoingMessageLength     -- its length
          )

4.3.2.  Prepare an Outgoing SNMP Response Message

   The Message Processing Subsystem provides this service primitive 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               -- data from/in this context which is unambiguously identified within
an administrative domain by
     IN   pduVersion                -- the combination version of the contextEngineID
and the contextName. See, for example, RFC1905 for more information
about PDU
     IN   PDU                       -- SNMP PDUs.

3.4. Other Constructs

3.4.1. maxSizeResponseScopedPDU

The Protocol Data Unit
     IN   maxSizeResponseScopedPDU is the  -- maximum size of a scopedPDU to
be included in a response message, making allowance for the message
header.

3.4.2. Local Configuration Datastore

The subsystems, models, and applications within an SNMP entity may
need Response PDU
     IN   stateReference            -- reference 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 state 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 presented 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 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 and its contents.

4. Abstract Service Interfaces.

Abstract service interfaces have been defined to describe the
conceptual interfaces between the various subsystems within send
     OUT  outgoingMessageLength     -- its length
          )

4.3.3.  Prepare Data Elements from an Incoming SNMP
entity.

These abstract Message

   The Message Processing Subsystem provides this service interfaces are defined by a set of primitives
that define the services provided and primitive for
   preparing the abstract data elements that
are from an incoming SNMP message:

   result =                         -- SUCCESS or errorIndication
     prepareDataElements(
     IN   transportDomain           -- origin transport domain
     IN   transportAddress          -- origin transport address
     IN   wholeMsg                  -- as received from the network
     IN   wholeMsgLength            -- as received from the network
     OUT  messageProcessingModel    -- typically, SNMP version
     OUT  securityModel             -- Security Model to be passed when use
     OUT  securityName              -- on behalf of this principal
     OUT  securityLevel             -- Level of Security requested
     OUT  contextEngineID           -- data from/at this entity
     OUT  contextName               -- data from/in this context
     OUT  pduVersion                -- the services are invoked.  This section lists version of the primitives that have been defined PDU
     OUT  PDU                       -- SNMP Protocol Data Unit
     OUT  pduType                   -- SNMP PDU type
     OUT  sendPduHandle             -- handle for matched request
     OUT  maxSizeResponseScopedPDU  -- maximum size of the various subsystems.

4.1.  Common 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.4.  Access Control Subsystem Primitives

These primitive(s)

   Applications are the typical clients of the service(s) of the Access
   Control Subsystem.

   The following primitive is provided by multiple Subsystems.

4.1.1.  Release State Reference Information

All Subsystems which pass stateReference information also provide a
primitive the Access Control Subsystem
   to check if access is allowed:

   statusInformation =              -- success or errorIndication
     isAccessAllowed(
     IN   securityModel             -- Security Model in use
     IN   securityName              -- principal who wants to release the memory that holds the referenced state
information:

stateRelease( access
     IN   stateReference   securityLevel             -- handle Level of reference to be released Security
     IN   viewType                  -- read, write, or notify view
     IN   contextName               -- context containing variableName
     IN   variableName              -- OID for the managed object
          )

4.2.  Dispatcher

4.5.  Security Subsystem Primitives

   The Dispatcher typically provides services to Message Processing Subsystem is the SNMP applications via
its PDU Dispatcher.  This section describes typical client of the primitives provided by
   services of the PDU Dispatcher.

4.2.1. Security Subsystem.

4.5.1.  Generate Outgoing a Request or Notification Message

   The PDU Dispatcher Security Subsystem provides the following primitive for an application to send an SNMP generate a
   Request or Notification to another SNMP entity: message:

   statusInformation =
     generateRequestMsg(
     IN   messageProcessingModel    -- sendPduHandle if success typically, SNMP version
     IN   globalData                -- errorIndication if failure
  sendPdu( message header, admin data
     IN   transportDomain   maxMessageSize            -- transport domain to be used of the sending SNMP entity
     IN   transportAddress   securityModel             -- transport address for the outgoing message
     IN   securityEngineID          -- authoritative SNMP entity
     IN   securityName              -- on behalf of this principal
     IN   securityLevel             -- Level of Security requested
     IN   scopedPDU                 -- message (plaintext) payload
     OUT  securityParameters        -- filled in by Security Module
     OUT  wholeMsg                  -- complete generated message
     OUT  wholeMsgLength            -- length of the generated message
          )

4.5.2.  Process Incoming Message

   The Security Subsystem provides the following primitive to be used process an
   incoming message:

   statusInformation =              -- errorIndication or success
                                    -- error counter OID/value if error
     processIncomingMsg(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   maxMessageSize            -- of the sending SNMP entity
     IN   securityParameters        -- for the received message
     IN   securityModel             -- for the received message
     IN   securityLevel             -- Level of Security Model to use
     IN   securityName   wholeMsg                  -- as received on the wire
     IN   wholeMsgLength            -- length as received on behalf the wire
     OUT  securityEngineID          -- identification of this the principal
  IN   securityLevel
     OUT  securityName              -- Level identification of Security requested
  IN   contextEngineID           -- data from/at this entity
  IN   contextName the principal
     OUT  scopedPDU,                -- data from/in this context
  IN   pduVersion message (plaintext) payload
     OUT  maxSizeResponseScopedPDU  -- the version maximum size of the Response PDU
  IN   PDU                       -- SNMP Protocol Data Unit
  IN   expectResponse
     OUT  securityStateReference    -- TRUE or FALSE reference to security state
          )

4.2.2.  Process Incoming Request or Notification PDU                         -- information, needed for response

4.5.3.  Generate a Response Message

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

processPdu(                      -- process Request/Notification PDU generate a
   Response message:

   statusInformation =
     generateResponseMsg(
     IN   messageProcessingModel    -- typically, SNMP version
     IN   securityModel   globalData                -- Security Model in use message header, admin data
     IN   securityName   maxMessageSize            -- on behalf of this principal the sending SNMP entity
     IN   securityLevel   securityModel             -- Level of Security for the outgoing message
     IN   contextEngineID   securityEngineID          -- data from/at this authoritative SNMP entity
     IN   contextName   securityName              -- data from/in on behalf of this context principal
     IN   pduVersion   securityLevel             -- for the version of the PDU outgoing message
     IN   PDU   scopedPDU                 -- SNMP Protocol Data Unit message (plaintext) payload
     IN   maxSizeResponseScopedPDU   securityStateReference    -- maximum size 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 Response PDU 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 state information be released
          )                         -- needed when sending

4.7.  Scenario Diagrams

4.7.1.  Command Generator or Notification Originator

   This diagram shows how a response

4.2.3.  Generate Outgoing Response

The PDU Dispatcher provides the following primitive for an Command Generator or Notification Originator
   application
to return an SNMP Response requests that a PDU to be sent, and how the PDU Dispatcher:

returnResponsePdu(
  IN   messageProcessingModel    -- typically, SNMP version
  IN   securityModel             -- response is
   returned (asynchronously) to that application.

   Command           Dispatcher               Message           Security
   Generator            |                     Processing           Model in use
  IN   securityName              -- on behalf of this principal
  IN   securityLevel             -- same as on incoming request
  IN   contextEngineID           -- data from/at this
   |                    |                     Model                    |
   |      sendPdu       |                        |                     |
   |------------------->|                        |                     |
   |                    | prepareOutgoingMessage |                     |
   :                    |----------------------->|                     |
   :                    |                        | generateRequestMsg  |
   :                    |                        |-------------------->|
   :                    |                        |                     |
   :                    |                        |<--------------------|
   :                    |                        |                     |
   :                    |<-----------------------|                     |
   :                    |                        |                     |
   :                    |------------------+     |                     |
   :                    | Send SNMP entity
  IN   contextName               -- data from/in this context
  IN   pduVersion                -- the version of the PDU
  IN        |     |                     |
   :                    | Request Message  |     |                     |
   :                    | to Network       |     |                     |
   :                    |                  v     |                     |
   :                    :                  :     :                     :
   :                    :                  :     :                     :
   :                    :                  :     :                     :
   :                    |                  |     |                     |
   :                    | Receive SNMP     |     |                     |
   :                    | Response Message |     |                     |
   :                    | from Network     |     |                     |
   :                    |<-----------------+     |                     |
   :                    |                        |                     |
   :                    |   prepareDataElements  |                     |
   :                    |----------------------->|                     |
   :                    |                        | processIncomingMsg  |
   :                    |                        |-------------------->|
   :                    |                        |                     |
   :                    |                        |<--------------------|
   :                    |                        |                     |
   :                    |<-----------------------|                     |
   | processResponsePdu |                        |                     |
   |<-------------------|                        |                     |
   |                    |                        |                     |

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 Protocol Data Unit
  IN   maxSizeResponseScopedPDU  -- maximum size of message is received, and how the
   Response PDU
  IN   stateReference            -- reference is (asynchronously) send back to state information
                                 -- 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 network.

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

processResponsePdu(              -- process Response PDU
  IN   messageProcessingModel    -- typically, SNMP version
  IN   securityModel             --            Message          Security
   Responder                 |                 Processing          Model in use
  IN   securityName              -- on behalf of this principal
  IN   securityLevel             -- Level of Security
  IN   contextEngineID           -- data from/at this SNMP entity
  IN   contextName               -- data from/in this context
  IN   pduVersion                -- the version of the PDU
  IN   PDU                       --
   |                         |                 Model                   |
   |                         |                    |                    |
   | registerContextEngineID |                    |                    |
   |------------------------>|                    |                    |
   |<------------------------|              |     |                    |
   |                         | Receive SNMP Protocol Data Unit
  IN   statusInformation         -- success or errorIndication
  IN   sendPduHandle             -- handle |     |                    |
   :                         | Message      |     |                    |
   :                         | from sendPDU
       )

4.2.5.  Registering Responsibility for Handling Network |     |                    |
   :                         |<-------------+     |                    |
   :                         |                    |                    |
   :                         |prepareDataElements |                    |
   :                         |------------------->|                    |
   :                         |                    | processIncomingMsg |
   :                         |                    |------------------->|
   :                         |                    |                    |
   :                         |                    |<-------------------|
   :                         |                    |                    |
   :                         |<-------------------|                    |
   |     processPdu          |                    |                    |
   |<------------------------|                    |                    |
   |                         |                    |                    |
   :                         :                    :                    :
   :                         :                    :                    :
   |    returnResponsePdu    |                    |                    |
   |------------------------>|                    |                    |
   :                         | prepareResponseMsg |                    |
   :                         |------------------->|                    |
   :                         |                    |generateResponseMsg |
   :                         |                    |------------------->|
   :                         |                    |                    |
   :                         |                    |<-------------------|
   :                         |                    |                    |
   :                         |<-------------------|                    |
   :                         |                    |                    |
   :                         |--------------+     |                    |
   :                         | Send SNMP PDUs.

Applications can register/unregister responsibility for a specific
contextEngineID, for specific pduTypes, with the PDU Dispatcher
according    |     |                    |
   :                         | Message      |     |                    |
   :                         | to these primitives:

statusInformation =              -- success or errorIndication
  registerContextEngineID(
  IN   contextEngineID           -- take responsibility Network   |     |                    |
   :                         |              v     |                    |

5.  Managed Object Definitions for this one
  IN   pduType 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"            -- the pduType(s) to be registered
       )

unregisterContextEngineID(
  IN   contextEngineID 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 }  -- give up responsibility for DBH: check if this one
  IN   pduType number is indeed OK

   -- Textual Conventions used in the pduType(s) to be unregistered
       )

4.3.  Message Processing Subsystem Primitives

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

4.3.1.  Prepare an Outgoing Management Architecture ***

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

                    The Message Processing Subsystem provides this service primitive value for
preparing 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 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 object may not be all zeros or
                    all 'ff'H or FALSE
  IN   sendPduHandle             -- the handle for matching
                                 -- incoming responses
  OUT  destTransportDomain       -- destination transport domain
  OUT  destTransportAddress      -- destination transport address
  OUT  outgoingMessage           -- the message to send
  OUT  outgoingMessageLength     -- its length
       )

4.3.2.  Prepare an Outgoing SNMP Response Message empty (zero length) string.

                    The Message Processing Subsystem provides this service primitive initial value for
preparing an outgoing SNMP Response Message:

result =                         -- SUCCESS this object may be configured
                    via an operator console entry or FAILURE
  prepareResponseMessage(
  IN   messageProcessingModel    -- typically, SNMP version
  IN   securityModel             -- same as via an algorithmic
                    function.  In the latter case, the following
                    example algorithm is recommended.

                    In cases where there are multiple engines on incoming request
  IN   securityName              -- the
                    same system, the use of this algorithm is NOT
                    appropriate, as on incoming request
  IN   securityLevel             -- it would result in all of those
                    engines ending up with the same as on incoming request
  IN   contextEngineID           -- data from/at this SNMP entity
  IN   contextName               -- data from/in this context
  IN   pduVersion                -- ID value.

                    1) The very first bit is used to indicate how the version
                       rest of the PDU
  IN   PDU                       -- SNMP Protocol Data Unit
  IN   maxSizeResponseScopedPDU  -- maximum size 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 of the Response PDU
  IN   stateReference            -- reference to state information
                                 --
                       engineID (also known 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 AgentID [RFC1910]) to send
  OUT  outgoingMessageLength     -- its
                       co-exist with any new uses.

                    2) The snmpEngineID has a length
       )

4.3.3. Prepare Data Elements from an Incoming SNMP Message of 12 octets.

                       The Message Processing Subsystem provides this service primitive for
preparing first four octets are set to the abstract data elements from an incoming binary
                       equivalent of the agent's SNMP message:

result =                         -- SUCCESS or errorIndication
  prepareDataElements(
  IN   transportDomain           -- origin transport domain
  IN   transportAddress          -- origin transport address
  IN   wholeMsg                  -- management
                       private enterprise number as received from assigned by the network
  IN   wholeMsglength            -- as received from
                       Internet Assigned Numbers Authority (IANA).
                       For example, if Acme Networks has been assigned
                       { enterprises 696 }, the network
  OUT  messageProcessingModel    -- typically, SNMP version
  OUT  securityModel             -- Security Model 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 use
  OUT  securityName              -- on behalf of this principal
  OUT  securityLevel             -- Level maximize the
                       possibility that the value of Security requested
  OUT  contextEngineID           -- data from/at this entity
  OUT  contextName               -- data from/in this context
  OUT  pduVersion                -- object will
                       be unique in the version agent's administrative domain.
                       For example, it may be the IP address of the PDU
  OUT  PDU                       -- SNMP Protocol Data Unit
  OUT  pduType                   -- SNMP PDU type
  OUT  sendPduHandle             -- handle for matched request
  OUT  maxSizeResponseScopedPDU  -- maximum size
                       entity, or the MAC address of one of the Response PDU
  OUT  statusInformation         -- success or errorIndication
                                 -- error counter OID/value if error
  OUT  stateReference            -- reference to state information
                                 -- to be
                       interfaces, with each address suitably padded
                       with random octets.  If multiple methods are
                       defined, then it is recommended that the first
                       octet indicate the method being used for and the
                       remaining octets be a possible Response
       )

4.4.  Access Control Subsystem Primitives

Applications function of the method.

                    3) The length of the octet strings varies.

                       The first four octets are set to the typical clients of the service(s) binary
                       equivalent of the Access
Control Subsystem.

The following primitive is provided agent's SNMP management
                       private enterprise number as assigned by the Access Control Subsystem
to check
                       Internet Assigned Numbers Authority (IANA).
                       For example, if access is allowed:

statusInformation =              -- success or errorIndication
  isAccessAllowed(
  IN   securityModel             -- Security Model in use
  IN   securityName              -- principal who wants to access
  IN   securityLevel             -- Level of Security
  IN   viewType                  -- read, write, or notify view
  IN   contextName               -- context containing variableName
  IN   variableName              -- OID for Acme Networks has been assigned
                       { enterprises 696 }, the managed object
       )

4.5.  Security Subsystem Primitives first four octets would
                       be assigned '000002b8'H.

                       The Message Processing Subsystem very first bit is set to 1. For example, the typical client of the services
of the Security Subsystem.

4.5.1.  Generate a Request or Notification Message
                       above value for Acme Networks now changes to be
                       '800002b8'H.

                       The Security Subsystem provides fifth octet indicates how the rest (6th and
                       following primitive to generate 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 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 Request or Notification message:

statusInformation =
  generateRequestMsg(
  IN   messageProcessingModel    -- typically, SNMP version
  IN   globalData                -- message header, admin data
  IN   maxMessageSize            --
                    securityModel of the sending Security Subsystem within the
                    SNMP entity
  IN Management Architecture.

                    The values for securityModel             -- are allocated as
                    follows:

                    - The zero value is reserved.
                    - Values between 1 and 255, inclusive, are reserved
                      for the outgoing message
  IN   securityEngineID          -- authoritative SNMP entity
  IN   securityName              -- on behalf of this principal
  IN   securityLevel             -- Level of standards-track Security requested
  IN   scopedPDU                 -- message (plaintext) payload
  OUT  securityParameters        -- filled in Models and are
                      managed by Security Module
  OUT  wholeMsg                  -- complete generated message
  OUT  wholeMsgLength            -- length of the generated message
       )

4.5.2.  Process Incoming Message

The Internet Assigned Numbers Authority
                      (IANA).
                    - Values greater than 255 are allocated to
                      enterprise-specific Security Subsystem provides the following primitive Models.  An
                      enterprise-specific securityModel value is defined
                      to process
an incoming message:

statusInformation =              -- errorIndication or success
                                 -- error counter OID/value if error
  processIncomingMsg(
  IN   messageProcessingModel    -- typically, SNMP version
  IN   maxMessageSize            -- of the sending SNMP entity
  IN   securityParameters        -- for be:

                      enterpriseID * 256 + security model within
                      enterprise

                      For example, the received message
  IN   securityModel             -- for fourth Security Model defined by
                      the received message
  IN   securityLevel             -- Level enterprise whose enterpriseID is 1 would be
                      260.

                    The eight bits allow a maximum of 255 (256-1
                    reserved) standards based Security Models.
                    Similarly, they allow a maximum of 255 Security
  IN   wholeMsg                  -- as received on the wire
  IN   wholeMsgLength            -- length as received on
                    Models per enterprise.

                    It is believed that the wire
  OUT  securityEngineID          -- identification assignment of new
                    securityModel values will be rare in practice
                    because the principal
  OUT  securityName              -- identification of larger the principal
  OUT  scopedPDU,                -- message (plaintext) payload
  OUT  maxSizeResponseScopedPDU  -- maximum size number of simultaneously
                    utilized Security Models, the Response PDU
  OUT  securityStateReference    -- reference larger the
                    chance that interoperability will suffer.
                    Consequently, it is believed that such a range
                    will be sufficient.  In the unlikely event that
                    the standards committee finds this number to security state
       )                         -- information, needed be
                    insufficient over time, an 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 response

4.5.3.  Generate a Response Message

The various
                    organizations to design and define non-standard
                    securityModels.  This limits the ability to
                    define new proprietary implementations of Security Subsystem provides
                    Models to the following primitive first 8,388,608 enterprises.

                    It is worthwhile to generate note that, in its encoded
                    form, the securityModel value will normally
                    require only a Response message:

statusInformation =
  generateResponseMsg(
  IN   messageProcessingModel    -- typically, single byte since, in practice,
                    the leftmost bits will be zero for most messages
                    and sign extension is suppressed by the encoding
                    rules.

                    As of this writing, there are several values
                    of securityModel defined for use with SNMP version
  IN   globalData                -- message header, admin data
  IN   maxMessageSize            -- or
                    reserved for use with supporting MIB objects.
                    They are as follows:

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

   SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION "An identifier that uniquely identifies a Message
                    Processing Model of the sending Message Processing
                    Subsystem within a SNMP entity
  IN   securityModel             -- Management Architecture.

                    The values for the outgoing message
  IN   securityEngineID          -- authoritative SNMP entity
  IN   securityName              -- on behalf of this principal
  IN   securityLevel             -- messageProcessingModel are
                    allocated as follows:

                    - Values between 0 and 255, inclusive, are
                      reserved for standards-track Message Processing
                      Models and are managed by the outgoing message
  IN   scopedPDU                 -- message (plaintext) payload
  IN   securityStateReference    -- reference Internet Assigned
                      Numbers Authority (IANA).
                    - Values greater than 255 are allocated to security state
                                 -- information from original request
  OUT  securityParameters        -- filled in by Security Module
  OUT  wholeMsg                  -- complete generated message
  OUT  wholeMsgLength            -- length of
                      enterprise-specific Message Processing Models.
                      An enterprise messageProcessingModel value is
                      defined to be:

                      enterpriseID * 256 +
                           messageProcessingModel within enterprise

                      For example, the generated message
       )

4.6.  User Based Security Model Internal Primitives

4.6.1.  User-based Security fourth Message Processing Model Primitives for Authentication
                      defined by the enterprise whose enterpriseID
                      is 1 would be 260.

                    The User-based Security Model provides 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 the following internal
primitives to pass data back and forth between assignment of new
                    messageProcessingModel values will be rare
                    in practice because the Security Model
itself and larger the authentication service:

statusInformation =
  authenticateOutgoingMsg(
  IN   authKey                   -- secret key for authentication
  IN   wholeMsg                  -- unauthenticated complete message
  OUT  authenticatedWholeMsg     -- complete authenticated message
       )

statusInformation =
  authenticateIncomingMsg(
  IN   authKey                   -- secret key for authentication
  IN   authParameters            -- as received on number of
                    simultaneously utilized Message Processing Models,
                    the wire
  IN   wholeMsg                  -- as received on larger the wire
  OUT  authenticatedWholeMsg     -- complete authenticated message
       )

4.6.2.  User-based Security Model Primitives for Privacy

The User-based Security Model provides chance that interoperability
                    will suffer. It is believed that such a range
                    will be sufficient.  In the following internal
primitives unlikely event that
                    the standards committee finds this number to pass data back and forth between be
                    insufficient over time, an enterprise number
                    can be allocated to obtain an additional 256
                    possible values.

                    Note that the Security Model
itself 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 privacy service:

statusInformation =
  encryptData(
  IN    encryptKey               -- secret key for encryption
  IN    dataToEncrypt            -- data ability
                    to encrypt (scopedPDU)
  OUT   encryptedData            -- encrypted data (encryptedPDU)
  OUT   privParameters           -- filled define new proprietary implementations of
                    Message Processing Models to the 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 most messages
                    and sign extension is suppressed by service provider
        )

statusInformation =
  decryptData(
  IN    decryptKey               -- secret key the encoding
                    rules.

                    As of this writing, there are several values of
                    messageProcessingModel defined for decrypting
  IN    privParameters           -- use with SNMP.
                    They are as received on the wire
  IN    encryptedData            -- encrypted data (encryptedPDU)
  OUT   decryptedData            -- decrypted data (scopedPDU)
        )

4.7. Scenario Diagrams

4.7.1. Command Generator or Notification Originator Application

This diagram shows how a Command Generator 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 messages can be
                    sent or Notification Originator
application requests 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 a PDU be sent,
                    noAuthNoPriv is less than authNoPriv and how the response
                    authNoPriv is
returned (asynchronously) to that application.

Command           Dispatcher                 Message           Security
Generator            |                       Processing           Model
|                    |                       Model                    |
|                    |                          |                     |
|      sendPdu       |                          |                     |
|------------------->|                          |                     |
|                    | prepareOutgoingMessage   |                     |
:                    |------------------------->|                     |
:                    |                          | generateRequestMsg  |
:                    |                          |-------------------->|
:                    |                          |                     |
:                    |                          |<--------------------|
:                    |                          |                     |
:                    |<-------------------------|                     |
:                    |                          |                     |
:                    |------------------+       |                     |
:                    | Send SNMP        |       |                     |
:                    | Request Message  |       |                     |
:                    | 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, this
                    information is represented using the ISO/IEC
                    IS 10646-1 character set, encoded as an octet
                    string using the UTF-8 transformation format
                    described in [RFC2044].

                    Since additional code points are added by
                    amendments to Network       |       |                     |
:                    |                  v       |                     |
:                    :                  :       :                     :
:                    :                  :       :                     :
:                    :                  :       :                     :
:                    |                  |       |                     |
:                    |                  |       |                     |
:                    | Receive SNMP     |       |                     |
:                    | Response Message |       |                     |
:                    | the 10646 standard from Network     |       |                     |
:                    |<-----------------+       |                     |
:                    |                          |                     |
:                    |   prepareDataElements    |                     |
:                    |------------------------->|                     |
:                    |                          | processIncomingMsg  |
:                    |                          |-------------------->|
:                    |                          |                     |
:                    |                          |<--------------------|
:                    |                          |                     |
:                    |<-------------------------|                     |
| processResponsePdu |                          |                     |
|<-------------------|                          |                     |
|                    |                          |                     |

4.7.2. Scenario Diagram for a Command Responder Application

This diagram shows how time
                    to time, implementations must be prepared to
                    encounter any code point from 0x00000000 to
                    0x7fffffff.

                    The use of control codes should be avoided.

                    When it is necessary to represent a Command Responder newline,
                    the control code sequence CR LF should be used.

                    The use of leading or Notification Receiver
application registers trailing white space should
                    be avoided.

                    For code points not directly supported by user
                    interface hardware or software, an alternative
                    means of entry and display, such as hexadecimal,
                    may be provided.

                    For information encoded in 7-bit US-ASCII,
                    the UTF-8 encoding is identical to the
                    US-ASCII encoding.

                    Note that when this TC is used for handling a pduType, how a PDU an object that
                    is dispatched used or envisioned to be used as an index, then
                    a SIZE restriction must be specified so that the
                    number sub-identifiers for any object instance
                    do not exceed the limit of 128, as 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 the application after a SNMP message is received, and how 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 of seconds since the
Response is (asynchronously) send back to SNMP engine last
                    incremented the network.

Command               Dispatcher             Message           Security
Responder                 |                  Processing           Model
|                         |                  Model                    |
|                         |                     |                     |
| registerContextEngineID |                     |                     |
|------------------------>|                     |                     |
|<------------------------|              |      |                     |
|                         | Receive snmpEngineBoots object.
                   "
       ::= { snmpEngine 3 }

   snmpEngineMaxMessageSize OBJECT-TYPE
       SYNTAX       INTEGER (484..2147483647)
       MAX-ACCESS   read-only
       STATUS       current
       DESCRIPTION "The maximum length in octets of an SNMP |      |                     |
:                         | Message      |      |                     |
:                         | from Network |      |                     |
:                         |<-------------+      |                     |
:                         |                     |                     |
:                         | prepareDataElements |                     |
:                         |-------------------->|                     |
:                         |                     | processIncomingMsg  |
:                         |                     |-------------------->|
:                         |                     |                     |
:                         |                     |<--------------------|
:                         |                     |                     |
:                         |<--------------------|                     |
|     processPdu          |                     |                     |
|<------------------------|                     |                     |
|                         |                     |                     |
:                         :                     :                     :
:                         :                     :                     :
|    returnResponsePdu    |                     |                     |
|------------------------>|                     |                     |
:                         |  prepareResponseMsg |                     |
:                         |-------------------->|                     |
:                         |                     | generateResponseMsg |
:                         |                     |-------------------->|
:                         |                     |                     |
:                         |                     |<--------------------|
:                         |                     |                     |
:                         |<--------------------|                     |
:                         |                     |                     |
:                         |--------------+      |                     |
:                         | Send message
                    which this SNMP    |      |                     |
:                         | Message      |      |                     |
:                         | to Network   |      |                     |
:                         |              v      |                     |

5. Definition engine can send or receive and
                    process, determined as the minimum of Managed Objects the maximum
                    message size values supported among all of the
                    transports available to and supported by the engine.
                   "
       ::= { snmpEngine 4 }

   -- Registration Points for Authentication and Privacy Protocols **

   snmpAuthProtocols OBJECT-IDENTITY
       STATUS        current
       DESCRIPTION  "Registration point for standards-track
                     authentication protocols used in SNMP Management Frameworks

SNMP-FRAMEWORK-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-IDENTITY, OBJECT-TYPE,
    OBJECT-IDENTITY,
    snmpModules, Unsigned32, Integer32    FROM SNMPv2-SMI
    TEXTUAL-CONVENTION                    FROM SNMPv2-TC
    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF;

snmpFrameworkMIB MODULE-IDENTITY
    LAST-UPDATED "9707260000Z"            -- 26 July 1997, midnight
    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
                              MailStop: Durham
                              35 Industrial Way
                              Rochester NH 03867-5005
                              USA
                  email:      dbh@cabletron.com
                  phone:      +1-603-337-7357

                  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
                     Frameworks.
                    "
       ::= { snmpFrameworkAdmin 1 }

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

   -- DBH: check if this number is indeed OK Conformance information ******************************************

   snmpFrameworkMIBCompliances
                  OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 1}
   snmpFrameworkMIBGroups
                  OBJECT IDENTIFIER ::= {snmpFrameworkMIBConformance 2}

   -- Textual Conventions used in compliance statements

   snmpFrameworkMIBCompliance MODULE-COMPLIANCE
       STATUS       current
       DESCRIPTION "The compliance statement for SNMP engines which
                    implement the SNMP Management Architecture ***

SnmpEngineID Framework MIB.
                   "
       MODULE    -- this module
           MANDATORY-GROUPS { snmpEngineGroup }

       ::= TEXTUAL-CONVENTION { snmpFrameworkMIBCompliances 1 }

   -- units of conformance

   snmpEngineGroup OBJECT-GROUP
       OBJECTS {
                 snmpEngineID,
                 snmpEngineBoots,
                 snmpEngineTime,
                 snmpEngineMaxMessageSize
               }
       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 the empty (zero length) string.

                 The initial value "A collection of objects for this object may be configured
                 via an operator console entry or via an algorithmic
                 function.  In the latter case, the following
                 example algorithm is recommended.

                 1) The very first bit is used to indicate how identifying and
                    determining the
                    rest configuration and current timeliness
                    values of the data is composed.

                    0 - as defined by enterprise using former methods
                        that existed before SNMPv3. See item 2 below. an SNMP engine.
                   "
       ::= { snmpFrameworkMIBGroups 1 - as defined by this architecture, see item 3
                        below.

                    Note that this allows existing uses of the
                    engineID (also known as AgentID [RFC1910]) to
                    co-exist with any new uses.

                 2) The snmpEngineID has }

   END

6.  Security Considerations

   This document describes how an implementation can include a length of 12 octets.

                    The first four octets are set Security
   Model to the binary
                    equivalent of the agent's SNMP network protect 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 messages and an Access Control Model to maximize the
                    possibility that the value of this object will
                    be unique in
   control access to management information.

   The level of security provided is determined by the agent's administrative domain.
                    For example, it may be specific Security
   Model implementation(s) and the IP address of specific Access Control Model
   implementation(s) used.

   Applications have access to data which is not secured.  Applications
   should take reasonable steps to protect the SNMP
                    entity, or data from disclosure.

   It is the MAC address of one responsibility of the
                    interfaces, with each address suitably padded purchaser of an implementation to
   ensure that:

      1) an implementation complies with random octets.  If multiple methods are
                    defined, then it is recommended that the first
                    octet indicate rules defined by this
         architecture,

      2) the method being used Security and Access Control Models utilized satisfy the
                    remaining octets be a function
         security and access control needs of the method. organization,

      3) The length of the octet strings varies.

                    The first four octets are set to the binary
                    equivalent implementations of the agent's SNMP network management
                    private enterprise number as assigned by Models and Applications comply with
         the
                    Internet Assigned Numbers Authority (IANA).
                    For example, if Acme Networks has been assigned
                    { enterprises 696 }, model and application specifications,

      4) and the first four octets would
                    be assigned '000002b8'H.

                    The very first bit 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 set to 1. For example, the
                    above value for Acme Networks now changes result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to be
                    '800002b8'H.

                    The fifth octet indicates how the rest (6th and following octets) are formatted. 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)

   The values for document is based on recommendations of 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 IETF 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 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
                 of Advisory Team and the Security Subsystem within SNMPv3 Working Group
   Charter, the SNMP
                 Management Architecture.

                 The values for securityModel are allocated design incorporates as follows:

                 - The zero value is reserved.
                 - Values between 1 and 255, inclusive, are reserved
                   for standards-track Security Models much as practical from previous
   RFCs and drafts. As a result, special thanks are managed
                   by the Internet Assigned Numbers Authority (IANA).
                 - Values greater than 255 are allocated to enterprise
                   specific Security Models.  An enterprise specific
                   securityModel value is defined due to be:

                   enterpriseID * 256 + security model within enterprise

                   For example, the fourth Security Model defined by the enterprise whose enterpriseID is 1 would be 260.

                 The eight bits allow a maximum of 255 (256-1 reserved)
                 standards based Security Models.  Similarly, they
                 allow a maximum authors
   of 255 Security Models per enterprise.

                 It is believed that the assignment 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
      of new
                 securityModel values will be rare in practice
                 because the larger the number 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
      of simultaneously
                 utilized Security Models, the larger the chance that
                 interoperability will suffer.  Consequently, it is
                 believed that such a range will be sufficient.
                 In the unlikely event that the standards committee
                 finds this number to be insufficient over time, an
                 enterprise number can be allocated to obtain an
                 additional 255 possible values.

                 Note that Tennessee at Knoxville, Performance Systems s International,
      Performance International, and the most significant bit must be zero;
                 hence, there are 23 bits allocated MIT Laboratory for various
                 organizations to design Computer
      Science, May 1990.

   [RFC1212] Rose, M., and define non-standard
                 securityModels.  This limits the ability K. McCloghrie, "Concise MIB Definitions", STD
      16, RFC 1212, March 1991.

   [RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S., Waldbusser, "Introduction to define
                 new proprietary implementations Community-based SNMPv2",
      RFC 1901, January 1996.

   [RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and S., Waldbusser, "Structure of Management Information for
      Version  2 of Security Models
                 to the first 8,388,608 enterprises.

                 It is worthwhile to note that, in its encoded form, 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 Version 2 of the securityModel value will normally require only a
                 single byte since, in practice,
      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 Version 2 of
      the leftmost bits will
                 be zero 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 most messages Version 2 of the
      Simple Network Management Protocol (SNMPv2)", RFC 1905, January
      1996.

   [RFC1906] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose,
      M., and sign extension is
                 suppressed by S. Waldbusser, "Transport Mappings for Version 2 of the encoding rules.

                 As
      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 this writing, there are several values 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 and Version
      2 of
                 securityModel defined for use with SNMP or reserved the SNMP-standard Network Management Framework", RFC 1908,
      January 1996.

   [RFC1909] McCloghrie, K., Editor, "An Administrative Infrastructure
      for use with supporting MIB objects.  They are as
                 follows:

                     0  reserved SNMPv2", RFC1909, February 1996.

   [RFC1910] Waters, G., Editor, "User-based Security Model for 'none'
                     1  reserved 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 SNMPv1
                     2  reserved use in RFCs to Indicate
      Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D.,
      Wijnen, B., "Message Processing and Dispatching for SNMPv2c
                     3  User-Base 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 Security Model (USM)
                   255  reserved for 'any'
                "
    SYNTAX       INTEGER(0..2147483647)

SnmpMessageProcessingModel ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "An identifier that uniquely identifies a Message
                 Processing Model Version 3 of the Message Processing Subsystem
                 within a SNMP Simple Network
      Management Architecture. Protocol (SNMPv3)", draft-ietf-snmpv3-usm-01.txt,
      August 1997.

   [SNMP-ACM] The values for messageProcessingModel are allocated
                 as follows:

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

                   enterpriseID * 256 +
                        messageProcessingModel within enterprise

                   For example, the fourth Message Processing SNMPv3 Working Group, Wijnen, B., Presuhn, R.,
      McCloghrie, K., "View-based Access Control Model
                   defined by for the enterprise whose enterpriseID is 1
                   would be 260. Simple
      Network Management Protocol (SNMP)", draft-ietf-snmpv3-acm-02.txt,
      August 1997.

   [SNMP-APPL] 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 the assignment of new
                 messageProcessingModel values will be rare in practice
                 because the larger the number of simultaneously
                 utilized Message Processing Models, the larger the
                 chance that interoperability will suffer. It is
                 believed that such a range will be sufficient.
                 In the unlikely event that the standards committee
                 finds this number to be insufficient over time, an
                 enterprise number can be allocated to obtain an
                 additional 256 possible values.

                 Note that the most significant bit must be zero;
                 hence, there are 23 bits allocated 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 various
                 organizations to design and define non-standard
                 messageProcessingModels. Model Designers

   This limits the ability
                 to define new proprietary implementations appendix describes guidelines for designers of Message
                 Processing Models to the first 8,388,608 enterprises.

                 It is worthwhile models which are
   expected to note that, in its encoded form, fit into the securityModel value will normally require only a
                 single byte since, architecture defined in practice, the leftmost bits will
                 be zero for most messages and sign extension is
                 suppressed by the encoding rules.

                 As of this writing, there are several values of
                 messageProcessingModel defined for use with SNMP.

                 They are as follows:

                     0  reserved for document.

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

SnmpSecurityLevel ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION "A Level of Security at which are two SNMP messages can be
                 sent or with frameworks which operations are being processed;
                 in particular, one of:

                   noAuthNoPriv - without use communities to
   provide trivial authentication and
                                  without privacy,
                   authNoPriv   - with authentication but
                                  without privacy,
                   authPriv     - with authentication access control. SNMPv1 and SNMPv2c
   Frameworks can coexist with privacy.

                 These three values are ordered such Frameworks designed according to this
   architecture, and modified versions of SNMPv1 and SNMPv2c Frameworks
   could be designed to meet the requirements of this architecture, but
   this document does not provide guidelines for that noAuthNoPriv 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 is less than authNoPriv deliberately described as
   a fixed set of abstract data elements 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, primitive functions which
   can be overloaded to satisfy the needs of multiple model definitions.

   Documents which define models to be used within this information
                 is represented using architecture
   SHOULD use the ISO/IEC IS 10646-1 character
                 set, encoded as an octet string using standard primitives between subsystems, possibly
   defining specific mechanisms for converting the UTF-8
                 character encoding scheme described in RFC 2044.

                 Since additional code points are added by amendments abstract data
   elements into model-usable formats. This constraint exists to allow
   subsystem and model documents to be written recognizing common
   borders of the 10646 subsystem and model. Vendors are not constrained to
   recognize these borders in their implementations.

   The architecture defines certain standard from time services to time,
                 implementations must be prepared to encounter any code
                 point from 0x00000000 provided
   between subsystems, and the architecture defines abstract service
   interfaces to 0x7fffffff.

                 The use 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 document describing a Security Model MUST describe how the model
   protects against the threats described under "Security Requirements
   of control codes should be avoided.

                 For code points not directly supported this Architecture", section 1.4.

A.1.2.  Security Processing

   Received messages MUST be validated by user
                 interface hardware or software, an alternative means a Model of entry and display, such as hexadecimal, may be
                 provided.

                 For information encoded in 7-bit US-ASCII, the UTF-8
                 representation Security
   Subsystem.  Validation includes authentication and privacy processing
   if needed, but it is identical explicitly allowed to the US-ASCII encoding.

                 Note that when this TC is used for an object that
                 is used send messages which do not
   require authentication or envisioned privacy.

   A received message contains a specified securityLevel to be used as an index, then a
                 SIZE restriction must be specified so that the number
                 sub-identifiers for any object instance do not exceed
                 the limit of 128, as defined
   during processing.  All messages requiring privacy MUST also require
   authentication.

   A Security Model specifies rules 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 }

-- which authentication and privacy
   are to be done.  A model may define mechanisms to provide additional
   security features, but 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       Unsigned32 -- (1..4294967295)
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number of times that model definition is constrained to using
   (possibly a subset of) the SNMP engine has
                 (re-)initialized itself since its initial
                 configuration.
                "
    ::= { snmpEngine 2 }

snmpEngineTime   OBJECT-TYPE
    SYNTAX       Integer32 (0..2147483647)
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "The number abstract data elements defined in this
   document for transferring data between subsystems.

   Each Security Model may allow multiple security protocols to be used
   concurrently within an implementation of seconds since the SNMP engine last
                 incremented model. Each Security
   Model defines how to determine which protocol to use, given the snmpEngineBoots object.
                "
    ::= { snmpEngine 3 }

-- Registration Points for
   securityLevel and the security parameters relevant to the message.
   Each Security Model, with its associated protocol(s) defines how the
   sending/receiving entities are identified, and how secrets are
   configured.

   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 supported by Security Models are
   uniquely identified using Object Identifiers. IETF standard 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 authentication or privacy should have an identifier defined
   within the SNMP Management Framework MIB.
                "
    MODULE    -- this module
        MANDATORY-GROUPS { snmpEngineGroup }

    ::= { snmpFrameworkMIBCompliances 1 }

-- units of conformance

snmpEngineGroup OBJECT-GROUP
    OBJECTS {
              snmpEngineID,
              snmpEngineBoots,
              snmpEngineTime
            }
    STATUS       current
    DESCRIPTION "A collection snmpAuthProtocols or the snmpPrivProtocols subtrees.
   Enterprise specific protocol identifiers should be defined within the
   enterprise subtree.

   For privacy, the Security Model defines what portion of objects the message
   is encrypted.

   The persistent data used for identifying and
                 determining security should be SNMP-manageable, but
   the configuration and current timeliness
                 values Security Model defines whether an instantiation of the MIB is a
   conformance requirement.

   Security Models are replaceable within the Security Subsystem.
   Multiple Security Model implementations may exist concurrently within
   an SNMP engine.
                "
    ::= { snmpFrameworkMIBGroups 1 }

END

6.  The number of Security Considerations

This document describes how an implementation can include Models defined by the SNMP
   community should remain small to promote interoperability.

A.1.3.  Validate the security-stamp in a received message

   A Message Processing Model requests that a Security Model:
     - verifies that the message has not been altered,
     - authenticates the identification of the principal for whom the
       message was generated.
     - decrypts the message if it was encrypted.

   Additional requirements may be defined by the model, and additional
   services may be provided by the model, but the model is constrained
   to use the following primitives for transferring data between
   subsystems. Implementations are not so constrained.

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

A.1.4.  Security MIBs

   Each Security Model defines the MIB module(s) required for security
   processing, including any MIB module(s) required for the security
   protocol(s) supported.  The MIB module(s) SHOULD be defined
   concurrently with the procedures which use the MIB module(s).  The
   MIB module(s) are subject to protect network management messages normal access control rules.

   The mapping between the model-dependent security ID and an Access Control the
   securityName MUST be able to be determined using SNMP, if the model-
   dependent MIB is instantiated and if access control policy allows
   access.

A.1.5.  Cached Security Data

   For each message received, the Security Model to control access to management information.

The level of caches the state
   information such that a Response message can be generated using the
   same security provided information, even if the Local Configuration Datastore
   is determined by altered between the specific Security
Model implementation(s) time of the incoming request and the specific Access Control outgoing
   response.

   A Message Processing Model
implementation(s) used.

Applications have access to data which is not secured.  Applications
should take reasonable steps to protect the data from disclosure.

It is has the responsibility of for explicitly
   releasing the purchaser of an implementation to
ensure that:
  1) cached data if such data is no longer needed. To enable
   this, an implementation complies with the rules defined by this
      architecture,
  2) abstract securityStateReference data element is passed from
   the Security and Access Control Models utilized satisfy Model to the Message Processing Model.

   The cached security and access control needs of the organization,
  3) data may be implicitly released via the implementations
   generation of a response, or explicitly released by using 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
                               MailStop: Durham
                               35 Industrial Way
                               Rochester NH 03867-5005
                               USA
                   email:      dbh@cabletron.com
                   phone:      +1-603-337-7357

8. Acknowledgements

This document is
   stateRelease primitive, as described in section 4.1.

A.2.  Message Processing Model Design 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 result
   complete PDU, i.e., it never forwards less than the complete list of
   varBinds.

A.2.1.  Receiving an SNMP Message from the efforts Network

   Upon receipt of a message from the SNMPv3 Working Group.
Some special thanks are network, the Dispatcher in order to 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)

The document is based on recommendations
   SNMP engine determines the version of the IETF Security SNMP message and
Administrative Framework Evolution for interacts
   with the corresponding Message Processing Model to determine the
   abstract data elements.

   A Message Processing Model specifies the SNMP Advisory Team.
Members Message format it
   supports and describes how to determine the values 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 the Advisory Team and abstract
   data elements (like msgID, msgMaxSize, msgFlags,
   msgSecurityParameters, securityModel, securityLevel etc). A Message
   Processing Model interacts with a Security Model to provide security
   processing for the message using the SNMPv3 Working Group
Charter, processMsg primitive, as
   described in section 4.5.

A.2.2.  Sending an SNMP Message to the design incorporates Network

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

      -  for requests and notifications: prepareOutgoingMessage, as much
         described in section 4.4

      -  for response messages: prepareResponseMessage, as practical from previous
RFCs and drafts. As described in
         section 4.4

   A Message Processing Model, when preparing an Outgoing SNMP Message,
   interacts with a result, special thanks are due Security Model to secure 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.)

9. References

[RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification
    of Management Information message. For that it
   uses the following primitives:

      -  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 of Tennessee at Knoxville, Performance Systems s
    International, Performance International, 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 MIT Laboratory
    for Computer Science, May 1990.

[RFC1212] Rose, M., Dispatcher sends the message to the desired address using the
      appropriate transport.

A.3.  Application Design Requirements

   Within an application, there may be an explicit binding to a specific
   SNMP message version, i.e., a specific Message Processing Model, and K. McCloghrie, "Concise
   to a specific Access Control Model, but there should be no reference
   to any data defined by a specific Message Processing Model or Access
   Control Model.

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

   An application determines whether explicit or implicit access control
   should be applied to the operation, and, if access control is needed,
   which Access Control Model should be used.

   An application has the responsibility to define any MIB Definitions",
    STD 16, RFC 1212, March 1991.

[RFC1901] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M.,
    and S., Waldbusser, "Introduction module(s)
   used to Community-based SNMPv2",
    RFC 1901, January 1996.

[RFC1902] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., and S., Waldbusser, "Structure of Management
    Information for Version  2 of provide application-specific services.

   Applications interact with the Simple Network Management
    Protocol (SNMPv2)", RFC 1902, January 1996.

[RFC1903] The SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., SNMP engine to initiate messages,
   receive responses, receive asynchronous messages, and S. Waldbusser, "Textual Conventions for Version 2 of send responses.

A.3.1.  Applications that Initiate Messages

   Applications may request that the SNMP engine send messages
   containing SNMP commands or notifications using 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 Version 2 of sendPdu primitive
   as described in section 4.2.

   If it is desired that a message be sent to multiple targets, it is
   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 responsibility 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 for
    Version 2 of application to provide the Simple Network Management Protocol (SNMPv2)",
    RFC 1906, January 1996.

[RFC1907] iteration.

   The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., and S. Waldbusser, "Management Information Base for
    Version 2 of SNMP engine assumes necessary access control has been applied to
   the Simple Network Management Protocol (SNMPv2)",
    RFC 1907 January 1996.

[RFC1908] The SNMPv2 Working Group, Case, J., McCloghrie, K.,
    Rose, M., PDU, and S. Waldbusser, "Coexistence between Version 1 provides no access control services.

   The SNMP engine looks at the "expectResponse" parameter, and Version 2 of if a
   response is expected, then 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 for SNMPv2",
    RFC1910, February 1996

[SNMP-MPD] The SNMPv3 Working Group, Case, J., Harrington, D.,
     Wijnen, B., "Message Processing appropriate information is cached such
   that a later response can be associated to this message, and Dispatching for can then
   be returned to 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 Security Model for Version 3 of application. A sendPduHandle is returned to 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
   application so it can later correspond the Simple
     Network Management Protocol (SNMP)",
     draft-ietf-snmpv3-acm-02.txt, August 1997.

[SNMP-APPL] response with this message
   as well.

A.3.2.  Applications that Receive Responses

   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 for designers of models SNMP engine matches the incoming response messages to outstanding
   messages sent by this SNMP engine, and forwards the response to the
   associated application using the processResponsePdu primitive, as
   described in section 4.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 engine using the primitive
   unregisterContextEngineID as described in section 4.2.

   Only one registration per combination of PDU type and contextEngineID
   is permitted at the same time. Duplicate registrations are
expected ignored.
   An errorIndication will be returned to fit into the architecture defined in this document.

SNMPv1 application that attempts
   to duplicate a registration.

   All asynchronously received messages containing a registered
   combination of PDU type and SNMPv2c contextEngineID are two SNMP frameworks sent to the
   application which use communities registered to
provide trivial authentication and access control. SNMPv1 and SNMPv2c
Frameworks can coexist with Frameworks designed according support that combination.

   The engine forwards the PDU to this
architecture, 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 the returnResponsePdu primitive, as described in section
   4.2.

   The contextEngineID, contextName, securityModel, securityName,
   securityLevel, and modified versions of SNMPv1 stateReference parameters are from the initial
   processPdu primitive. The PDU and SNMPv2c Frameworks
could be designed to meet statusInformation are the requirements results
   of this architecture, but
this document does not provide guidelines processing.

A.4.  Access Control Model Design Requirements

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

   The persistent data used for that
coexistence.

Within any subsystem model, there access control should be no reference to any
specific model manageable
   using SNMP, but the Access Control Model defines whether an
   instantiation of another subsystem, or to data defined by the MIB is a specific
model of another subsystem.

Transfer of data between conformance requirement.

   The Access Control Model must provide the subsystems primitive isAccessAllowed.

B.  Issues

   The change log will be deleted for last call; the issues list will be
   deleted when it is deliberately described time to publish as an RFC.

B.1.  Showstoppers

B.2.  Open Issues

   -  we need a fixed set of abstract data elements and primitive functions which
can mechanism for a manager to be overloaded able to satisfy the needs discover what
      securityModels are supported by a particular implementation

B.3.  Resolved Issues
    . contextEngineID in reportPDU = snmpEngineID of multiple model definitions.

Documents which define models to be used within this architecture
SHOULD report generator
    . returnResponsePdu - are all parameters needed? overrides allowed?
       all parameters kept for future flexibility
       overrides not supported by SNMPv3
    . use the standard of IN/OUT indicators in primitives between subsystems, possibly
defining specific mechanisms for converting the abstract data elements
into model-usable formats. This constraint exists to allow subsystem
and accepted
    . NT/Unix-like access control - can be defined as future model documents
    . 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 to SNMPv3? while undesirable, it is
      acceptable. A cleaner model may be written recognizing common borders of defined in the
subsystem and model. Vendors are future.
    . should securityModel "any" be supported? for ACM use, not constrained to recognize these
borders in their implementations.

The architecture SNMPv3
    . what defines certain standard services to SNMPv3? a document will be provided
between subsystems, 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, and the architecture defines abstract service
interfaces to request these services.

Each model definition for a subsystem SHOULD support the standard
service interfaces, wild carding can be supported by an
      implementation, but whether, or how, or how well, it performs is not required in the service standard.
    . Should indices be integers or SnmpAdminStrings? SnmpAdminStrings
      is dependent on the model definition.

A.1. Security Model Design Requirements

A.1.1. Threats

A document describing a Security Model MUST 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 how the model
protects against primitive parameters, or is the threats described under "Security Requirements
of
      expanded template adequate for this Architecture", purpose?
      Consensus: Terms are basically all defined in section 1.4.

A.1.2. Security Processing

Received messages MUST be validated by a Model of the Security
Subsystem.  Validation includes authentication and privacy processing

if needed, but 3.
    . state_reference releases
      Consensus: documents checked; we think it is explicitly allowed OK now
    . new SnmpEngineID format rules to send messages which do 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 to
      re-introduce it so that SNMPv1/v2c managers can learn the value!!
      Consensus: Nobody picked up on this, so it seems not
require authentication or privacy.

A received message contains needed.
    . Do we need a specified Level of Security mechanism to discover securityModels supported
      Can be used
during processing.  All messages requiring privacy MUST also require
authentication.

A Security Model specifies rules by which authentication and privacy
are to decided after Munich
    . add a "Decision History" section (as an appendix?)
      Can be done. decided after Munich

B.3.1.  Issues discussed at second Interim Meeting:
    . A model "readable" introduction supplement may define mechanisms to provide additional
security features, be done after Munich.
    . Applications are responsible for retries, but the model definition is constrained implementations may
        differ.
    . TCs should not be defined just to using
(possibly describe primitive parameters.
      If they cannot be described adequately in text, they can be defined
      in a subset of) the abstract data elements Glossary. Avoid describing implementation details.
    . Is SnmpAdminString appropriate for all strings, such as
      securityIdentifier and context and group? These had different
      sizes and semantics.  size and semantics may be defined in this
document
      syntax and description of OBJECT
    . AdminString has size (0..255); revisit for transferring data UTF-8 discussions
    . securityModel #s - 00 for IETF standards; from v2* documents
    . protocol IDs - integer or OID? voted 13-0 for OID.
    . uniqueness of securityName
    . mapping between subsystems.

Each Security Model principal and securityName is outside scope of WG.
    . principals may allow multiple security protocols to be used
concurrently within have more than one securityName in an implementation entity
    . mappings may exist between many types of the model. Each Security
Model defines how to determine which protocol to use, given the
securityLevel MDID and a single
      securityName
    . mappings may exist between different    (model, Name) and the security parameters relevant to same
      securityName by varying the message.
Each Security Model, with its associated protocol(s) defines how model or the
sending/receiving entities are identified, and how secrets are
configured.

Authentication Name.
    . the securityName and Privacy protocols supported a MDID may be identical. This can be defined
      by the Security Models are
uniquely identified using Object Identifiers. IETF standard protocols
for authentication Model.
      (user,"public") may map to securityName "public"
    . [securityName, securityModel] yields zero or privacy should have an identifier one MDName, with
      exceptions for backwards compatibility. The exception is defined within
      by the snmpAuthProtocols or model, and the snmpPrivProtocols subtrees. Enterprise
specific protocol identifiers should be defined within problems are the enterprise
subtree.

For privacy, 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 of maxSizeResponseScopedPDU

      -  added RFC 2119 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 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 to snmpv3 mailing list
      [version 4.11]
       . Change Primitives between MP and SEC to try and address the Security Model defines what portion issue
         of the architectural binding to message
is encrypted.

The persistent data used for security should be SNMP-manageable, but format.
       . Added securityName and securityLevel to the Security Model defines whether an instantiation returnResponsePdu
         primitive so that architecturally it could be different for a
         request 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 the MIB is section 1.1
       . expand description of Dispatcher a
conformance requirement.

Security Models are replaceable within bit

      [version 4.8]
       . Added parameter pduVersion on primitives:
               sendPdu
               processPdu
               returnResponsePdu
               processResponsePdu
               prepareDataElements
               prepareOutgoingMessage
               prepareResponseMessage
       . Added parameter messageProcessingModel on the Security Subsystem.
Multiple Security Model implementations may exist concurrently within
an primitive:
               processPdu
               processResponsePdu
               returnResponsePdu
       . Removed messageProcessingModel parameter from primitives:
               registerContextEngineID
               unregisterContextEngineID
       . Renamed SNMP engine.  The number Version Multiplexer to Dispatcher
       . Renamed Version Multiplexer to Message Multiplexer
       . Renamed Application Multiplexer to PDU Dispatcher
       . Rearranged some parameters in various Primitives so the sequence
         of Security Models defined by parameters is now more consistent.

      [version 4.7]
       . editorial cleanup
       . changed asterisk text
       . modified snmpv3 framework description to eliminate dependencies
       . reorder 4.2.x to reflect transaction order
       . changed SnmpEngineID size to 1..32

      [version 4.6]
       . Changes to use synchronous primitives where possible
       . Changes 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 to the MP document into the SNMP
community should remain small Version Multiplexer
         section.
       . Move Overview of all primitives from Appendix to promote interoperability.

A.1.3. Validate the security-stamp in a received message Section 4.
       . Simplify Appendix A Message Processing to just described Model requests that a Security Model:
  - verifies that the message has not been altered,
  - authenticates the identification of the principal Designer Guidelines
         and refer back to section 4 for whom the
    message was generated. specific primitives
       . Remove Appendix B (An Evolutionary Architecture - decrypts the message if Design Goals)
       . added design decision regarding security
       . Included latest Snmp SecurityModel TC (as it was encrypted.

Additional requirements may be defined by the model, and additional
services may be provided by the model, but the model is constrained actually posted
         to use the following primitives SNMPv3 mailing list).

      [version 4.5]
       . start with <draft-ietf-snmpv3-next-gen-arch-03.txt>
       . change vendor to implementor
       . change LoS to 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 transferring data between

subsystems. Implementations entity and engine to discussion
         of engine.
       . changed distributing to dispatching
       . added asterisks to indicate v3* items are also not so constrained.

A Message Processing Model uses the processMsg primitive as
described required.
       . changed "community access control" to "other access control"
       . added TC for SnmpMessageProcessingModel
       . modified Security Considerations
       . modified acknowledgements

      [version 4.4]
       . Fixed one error in section 4.5.

A.1.4. Security MIBs

Each Security Model defines the MIB module(s) required (found with SMICng)
       . Reformatted text for security
processing, including any MIB module(s) required SnmpAdminString, no change in text.
       . Changed text for the security
protocol(s) supported.  The MIB module(s) SHOULD be defined
concurrently with the procedures which use the MIB module(s).  The
MIB module(s) are subject SnmpEngineID..  this is still under discussion.
         But this new text seems to normal access control rules.

The mapping between the model dependent security ID and the
securityName MUST be able getting close to be determined using SNMP, if the model
dependent MIB is 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 a Response message can be generated using the
same security information, even if the Local Configuration Datastore
is altered between the time of the incoming request what we want.
       . Added an issue w.r.t. snmpEngineMaxMessageSize
       . adapt Primitive names and parameters to very latest (July 11) names
       . removed blank lines before 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 .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 securityStateReference data element so there is passed from
the Security Model no requirement for one entity
          to the Message Processing Model.

The cached security data may be implicitly released via the generation contain both a command generator and a notification receiver.
       . modify Introduction list of a response, or explicitly released by using the stateRelease
primitive, as entities which are meant to be
         supported
       . reorganized sections 1 through 4 for more consistency in contents.
       . described section contents in Introduction:Target Audience
       . move documentation descriptions to section 4.1.

A.2. Message Processing Model Design 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 2
       . rewrite section 4 to be more like a message from the network, the Dispatcher in the
SNMP engine determines the version real elements of the SNMP message procedure.
       . modified SnmpSecurityModel and interacts SnmpEngineID definitions
       . replaced MIB with Bert's replacement
       . added Randy's TC for SnmpAdminString
       . modified the corresponding Message Processing Model example algorithm text for SnmpEngineID
       . rewrote security considerations for brevity.

       . modified "context" description
       . moved "Threats" to determine the
abstract data elements.

A Message Processing Model specifies the SNMP Message format it
supports and describes how Goals/Requirements
       . eliminated snmpEngineMaxMessageSize object
       . posted to determine the values of the abstract
data elements (like msgID, msgMaxSize, msgFlags, msgSecurityParameters,
securityModel, securityLevel etc). A Message Processing Model interacts
with snmpv3 (by DBH)
      [version 4.1]
       . Adopt "abstract" to new terminology
       . Addressed all comments I (BW) made to DBH in an earlier email
       . Changed Introduction section to new terminology
       . changed wording for "implementation" to indicate it may contain
         multiple models.
       . Section 2. Started some wording on Goals and Design decisions
       . Added the overview picture of a Security Model traditional agent and a
         traditional manager. This is in section 2.
       . Changed overview figure in section 3. to provide security processing for address the message
using comments
         by Dave Levi. It now lists the processMsg primitive, type of applications
       . At various places ensure that text (easily) fits within 72
         columns as described in section 4.5.

A.2.2. Sending an SNMP Message to required by RFC-editors Guidelines document.
       . Section 2.3 (new section) has the Network

The Dispatcher in documents set overview.
         I verified the claims about standards. Not sure I worded the
         SNMPv2 std correctly,. We'll hear it if we did it wrong.
       . Section 2.4 (new section) gives overview of SNMP engine interacts with a Message Processing
Model entities based
         on modified Dave Levi figure. I (Bert) wonder however if it would
         not be better to prepare an outgoing message. For that move it uses the following
primitives:

 - for requests and notifications:
   prepareOutgoingMessage, as described in to after section 4.4

 - for response messages:
   prepareResponseMessage, as described 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 4.4

A Message Processing Model, when preparing an Outgoing SNMP Message,
interacts 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 a Security Model to secure the message. For that it uses
the following primitives:

 - for requests and notifications:
   generateRequestMsg, as described "is lower than" in section 4.5.

 - for response messages:
   generateResponseMsg as described 3.4.3 which seems
         better in section 4.5.

Once the SNMP message is prepared by a text document.
       . Renamed section 4.1 to "SNMP engine processing" instead of
         "The Message Processing Model, the
Dispatcher sends the message to Subsystem" because the desired address using transport
         mappings, mpc multiplexor and such is done in ARCH document so
         it is done "in general in the appropriate
transport.

A.3. Application Design Requirements

Within an application, there may be an explicit binding to engine" and it passes a specific
SNMP
         message version, i.e. to a specific Message Processing Model, Subsystem.
       . "bulletized" some stuff in section 4.2 and 4.3.
         Dave, this is just how I (Bert) like it better. Feel free to
         undo it if you strongly disagree
       . Section 4.3 changed "initiate a specific Access Control Model, but there should be no reference transaction" to
any data defined by "originate a specific Message Processing Model or Access
Control Model.

Within an application, there should be no reference
         notification".
       . Inserted title line for section 4.4 (I think it was missing)
         I have named it "Information Model" in accordance with the change
         I made (after Russ's comments) in the document figure to any specific
Security Model, or any data defined by lump SMI,
         TC and Conformance together.
       . Inserted a specific Security Model.

An application determines whether explicit or implicit access control
should be applied title for section 4.5 named "Operational Model" to
         get in sync with the 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 to follow the operation, and, if access control is needed,
which
         document overview figure. If we really want to follow it, then
         maybe we should also reorder some of these sections. Like
         Access Control Model seems specifically misplaced. So I decided to move
         it before applications as section 4.3, so the 4.x above should
         all be used.

An application has the responsibility read as 4.x+1
       . Removed size from SnmpEngineID TC... why did you limit it to define any MIB module(s) used
         (0..2048). Did we not decide to provide application-specific services.

Applications interact with leave it open?
       . Should we not remove snmpEngineMaxMessageSize from the SNMP engine MIB.
         That was agreed at 2nd interim. It travels in every message and so
         seems to initiate messages,
receive responses, receive asynchronous messages, be useless. However, I think it could indeed still help
         SNMPv1 or SNMPv2c managers.
       . I kept your definitions of registration-points for auth and send responses.

A.3.1. Applications priv
         protocols, but my recollection is that Initiate Messages

Applications may request they would be completely
         removed from ARCH and that the SNMP engine send messages containing
SNMP commands or notifications using the sendPdu primitive as described
in section 4.2.

If it is desired that a message would all be sent done in SEC document.
       . Modified Security Considerations. Was still talking about LPM.
       . Appendix. I am still wondering if we need to multiple targets, 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 is the
responsibility of the application consistent (at least I tried).
       . Appendix, renamed imf to provide the iteration.

The SNMP engine assumes necessary access control has been applied snmpFramework
       . Appendix, changed state_reference and state_release to
the PDU,
         stateReference and provides no access control services.

The stateRelease to be consistent with other names
         for abstract data and primitives.
       . A.2 changed MessageEngine to SNMP engine looks at the "expectResponse" parameter, and if a
response is expected, then the appropriate information is cached such
that a later response can be associated
       . Fixed ASI primitives to this message, and can then be returned in sync with SEC document.
         I also thought that our ARCH document-outline wanted to at least
         have the application. A sendPduHandle is returned to primitives listed within the
application main body of the text, no?
       . Adapted send_pdu to sendPdu 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 can later correspond the response fits on 1 line in contents
       . I did not look at appendix B. That is your (DBH) specialty is it
         not ?  ;-).
       . Quick simple spell check done with this message
as well.

A.3.2. Applications that Receive Responses

The SNMP engine matches the incoming response messages "spell" on AIX
      [version 4.0]
       . move section 7 - Model Requirements to an appendix
       . move Section 3 - Design Goals to an appendix
       . modified Section 5 - Naming
       . remove "possibly multiple"
       . moved Section 5 to outstanding
messages sent by this SNMP engine, Section 3
       . change orangelets to applications
       . modify description of applications
       . change scopedPDU-MMS and forwards the response PDU-MMS 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 maxSizeResponseScopedPDU
       . change Scoped-PDU and ScopedPDU to a
request from this SNMP engine, it must determine scopedPDU (no dash, lower case S)
       . change imfxxx to which application
the message should be given.

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

An Application that wishes principal
       . change securityIdentity to stop receiving asynchronous messages
should unregister itself with the SNMP engine using the primitive
unregisterContextEngineID as described 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 section 4.2.

Only one registration per combination of PDU type MIBs - securityIdentity TC etc
       . changed Message Processing and contextEngineID
is permitted at the same time. Duplicate registrations are ignored.
An errorIndication will be returned Control to the application that attempts Message Processing
       . changed future tense to duplicate a registration.

All asynchronously received messages containing a registered
combination of PDU type and contextEngineID are sent present tense
       . eliminate messageEngine
       . added/updated primitives
       . addressed issues raised on the mailing list

      [version 3.1]
       . change securityIdentity to the
application which registered MIID
       . write text to support that combination.

The engine forwards explain the PDU differences between security-identities,
         model-dependent identifiers, and model-independent identifiers.
       . write text to explain distinction within the registered application, using LCD of the
processPdu primitive, security
         data, the access control data, and the orangelet data.
       . identify issues
       . publish as described in <draft-ietf-snmpv3-next-gen-arch-02.txt>

      [version 3.0]
       . add section 4.2.

A.3.4. Applications that Send Responses

Request operations require responses.  An on threats for message security
       . add section on threats for access control
       . change application sends
a response via to orangelet
       . remove references to F-Ts
       . change securityIdentity to security-identity
       . change securityCookie to securityIdentity
       . the returnResponsePdu primitive, as described in
section 4.2.

The contextEngineID, contextName, securityModel, securityName,
securityLevel, and stateReference format of securityIdentity is defined by the model
       . add securityModel to passed parameters are as needed
       . eliminate group from the passed parameters
       . remove unused IMPORTS
       . add glossary section with initial
processPdu primitive. The PDU and statusInformation are the results set of processing.

A.4. Access Control Model Design Requirements

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

The persistent data used for access control should be manageable using
SNMP, but messageEngine from the Access Control Model defines whether an instantiation of contextEngine
       . eliminate 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 is a conformance requirement.

The Access Control Model must provide the primitive isAccessAllowed objects at this level (previously only TCs)
       . rewrote 7.x
       . sent to v3edit list
                            Table of Contents

0. Issues                                                             2
0.1. Resolved Issues                                                  2
0.1.1. Issues discussed at second Interim Meeting:                    3
0.2.  Change Log                                                      4

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

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

1.2. SNMP Management Systems                                         10 .........................................................    2

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

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

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

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

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

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

2.3. Coexistence and Transition                                      16 ...................................    8

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

2.5. Message Processing                                              17 ...........................................    9

2.6. Security                                                        17 .....................................................    9

2.7. Access Control                                                  17 ...............................................    9

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

2.9. Applications                                                    18 .................................................   10

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

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

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

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

2.13.1. SNMP Instrumentation MIBs                                    19 .................................   11

2.14. SNMP Framework Documents                                       19
2.15. Operational Overview                                           21 ....................................   11

3. Elements of the Architecture                                      23 ...................................   12

3.1. The Naming of Entities                                          23 .......................................   12

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

3.1.2. SNMP engine                                                   24 ................................................   13

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

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

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

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

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

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

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

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

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

3.1.12. Applications                                                 28 ..............................................   17

3.1.13. SNMP Agent                                                   28 Manager ..............................................   18

3.1.14. SNMP Manager                                                 28 Agent ................................................   19

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

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

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

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

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

3.3.1. An SNMP Context                                               31 ............................................   23

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

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

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

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

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

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

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

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

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

4.1.1. Release State Reference Information                          33 ........................   25

4.2. Dispatcher Primitives                                          33 ........................................   25

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

4.2.2. Process Incoming Request or Notification PDU                 34 ...............   26

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

4.2.4. Process Incoming Response PDU                                34 ..............................   27

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

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

4.3.1. Prepare an Outgoing SNMP Request or Notification Message     35 ......   28

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

4.3.3. Prepare Data Elements from an Incoming SNMP Message           36 ........   30

4.4. Access Control Subsystem Primitives                            37 ..........................   30

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

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

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

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

4.6.  User Based Security Model Internal Common Primitives                  38 ............................................   32

4.6.1.  User-based Security Model Primitives for Authentication      38
4.6.2.  User-based Security Model Primitives for Privacy             39 Release State Reference Information ........................   32

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

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

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

5. Definition of Managed Objects Object Definitions for SNMP Management Frameworks      42 ......   35

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

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

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

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

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

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

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

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

A.1.3. Validate the security-stamp in a received message             58 ..........   50

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

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

A.2. Message Processing Model Design Requirements                    60 .................   51

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

A.2.2. Sending an SNMP Message to the Network                        60 .....................   52

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

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

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

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

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

A.4. Access Control Model Design Requirements                        62 .....................   54

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

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. Change Log ...................................................   56