module SNMP-FRAMEWORK-MIB {

    yang-version 1;

    namespace
      "urn:ietf:params:xml:ns:yang:smiv2:SNMP-FRAMEWORK-MIB";

    prefix SNMP-FRAMEWORK-MIB;

    import ietf-yang-smiv2 {
      prefix smiv2;
    }

    organization "SNMPv3 Working Group";

    contact
      "WG-EMail:   snmpv3@lists.tislabs.com
Subscribe:  snmpv3-request@lists.tislabs.com

Co-Chair:   Russ Mundy
	    Network Associates Laboratories
postal:     15204 Omega Drive, Suite 300
	    Rockville, MD 20850-4601
	    USA
EMail:      mundy@tislabs.com
phone:      +1 301-947-7107

Co-Chair &
Co-editor:  David Harrington
	    Enterasys Networks
postal:     35 Industrial Way
	    P. O. Box 5005
	    Rochester, New Hampshire 03866-5005
	    USA
EMail:      dbh@enterasys.com
phone:      +1 603-337-2614

Co-editor:  Randy Presuhn
	    BMC Software, Inc.
postal:     2141 North First Street
	    San Jose, California 95131
	    USA
EMail:      randy_presuhn@bmc.com
phone:      +1 408-546-1006

Co-editor:  Bert Wijnen
	    Lucent Technologies
postal:     Schagen 33
	    3461 GL Linschoten
	    Netherlands


EMail:      bwijnen@lucent.com
phone:      +31 348-680-485
  ";

    description
      "The SNMP Management Architecture MIB

Copyright (C) The Internet Society (2002). This
version of this MIB module is part of RFC 3411;
see the RFC itself for full legal notices.";

    revision "2002-10-14" {
      description
        "Changes in this revision:
- Updated various administrative information.
- Corrected some typos.
- Corrected typo in description of SnmpEngineID
  that led to range overlap for 127.
- Changed '255a' to '255t' in definition of
  SnmpAdminString to align with current SMI.
- Reworded 'reserved' for value zero in
  DESCRIPTION of SnmpSecurityModel.
- The algorithm for allocating security models
  should give 256 per enterprise block, rather
  than 255.
- The example engine ID of 'abcd' is not
  legal. Replaced with '800002b804616263'H based
  on example enterprise 696, string 'abc'.
- Added clarification that engineID should
  persist across re-initializations.
This revision published as RFC 3411.";
    }

    revision "1999-01-19" {
      description
        "Updated editors' addresses, fixed typos.
Published as RFC 2571.";
    }

    revision "1997-11-20" {
      description
        "The initial version, published in RFC 2271.";
    }

    smiv2:oid "1.3.6.1.6.3.10.1.1";
    smiv2:oid "1.3.6.1.6.3.10.1.2";
    smiv2:alias "snmpFrameworkMIB" {
      smiv2:oid "1.3.6.1.6.3.10";
    }
    smiv2:alias "snmpFrameworkAdmin" {
      smiv2:oid "1.3.6.1.6.3.10.1";
    }
    smiv2:alias "snmpAuthProtocols" {
      description "Registration point for standards-track
authentication protocols used in SNMP Management
Frameworks.";
      smiv2:oid "1.3.6.1.6.3.10.1.1";
    }
    smiv2:alias "snmpPrivProtocols" {
      description "Registration point for standards-track privacy
protocols used in SNMP Management Frameworks.";
      smiv2:oid "1.3.6.1.6.3.10.1.2";
    }
    smiv2:alias "snmpFrameworkMIBObjects" {
      smiv2:oid "1.3.6.1.6.3.10.2";
    }
    smiv2:alias "snmpEngine" {
      smiv2:oid "1.3.6.1.6.3.10.2.1";
    }
    smiv2:alias "snmpFrameworkMIBConformance" {
      smiv2:oid "1.3.6.1.6.3.10.3";
    }
    smiv2:alias "snmpFrameworkMIBCompliances" {
      smiv2:oid "1.3.6.1.6.3.10.3.1";
    }
    smiv2:alias "snmpFrameworkMIBGroups" {
      smiv2:oid "1.3.6.1.6.3.10.3.2";
    }

    typedef SnmpEngineID {
      type binary {
        length "5..32";
      }
      description
        "An SNMP engine's administratively-unique identifier.
Objects of this type are for identification, not for
addressing, even though it is possible that an
address may have been used in the generation of
a specific value.


The value for this object may not be all zeros or
all 'ff'H or the empty (zero length) string.

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

In cases where there are multiple engines on the
same system, the use of this algorithm is NOT
appropriate, as it would result in all of those
engines ending up with the same ID value.

1) The very first bit is used to indicate how the
   rest of the data is composed.

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

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

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

2) The snmpEngineID has a length of 12 octets.

   The first four octets are set to the binary
   equivalent of the agent's SNMP management
   private enterprise number as assigned by the
   Internet Assigned Numbers Authority (IANA).
   For example, if Acme Networks has been assigned
   { enterprises 696 }, the first four octets would
   be assigned '000002b8'H.

   The remaining eight octets are determined via
   one or more enterprise-specific methods. Such
   methods must be designed so as to maximize the
   possibility that the value of this object will
   be unique in the agent's administrative domain.
   For example, it may be the IP address of the SNMP
   entity, or the MAC address of one of the
   interfaces, with each address suitably padded
   with random octets.  If multiple methods are
   defined, then it is recommended that the first
   octet indicate the method being used and the
   remaining octets be a function of the method.


3) The length of the octet string varies.

   The first four octets are set to the binary
   equivalent of the agent's SNMP management
   private enterprise number as assigned by the
   Internet Assigned Numbers Authority (IANA).
   For example, if Acme Networks has been assigned
   { enterprises 696 }, the first four octets would
   be assigned '000002b8'H.

   The very first bit is set to 1. For example, the
   above value for Acme Networks now changes to be
   '800002b8'H.

   The fifth octet indicates how the rest (6th and
   following octets) are formatted. The values for
   the fifth octet are:

     0     - reserved, unused.

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

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

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

     4     - Text, administratively assigned
	     Maximum remaining length 27

     5     - Octets, administratively assigned
	     Maximum remaining length 27

     6-127 - reserved, unused

   128-255 - as defined by the enterprise
	     Maximum remaining length 27";
    }

    typedef SnmpSecurityModel {
      type int32 {
        range "0..2147483647";
      }
      description
        "An identifier that uniquely identifies a
Security Model of the Security Subsystem within
this SNMP Management Architecture.

The values for securityModel are allocated as
follows:

- The zero value does not identify any particular
  security model.

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

  enterpriseID * 256 + security model within
  enterprise

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

This scheme for allocation of securityModel
values allows for a maximum of 255 standards-
based Security Models, and for a maximum of
256 Security Models per enterprise.

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

Note that the most significant bit must be zero;
hence, there are 23 bits allocated for various
organizations to design and define non-standard


securityModels.  This limits the ability to
define new proprietary implementations of Security
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 the encoding
rules.

As of this writing, there are several values
of securityModel defined for use with SNMP or
reserved for use with supporting MIB objects.
They are as follows:

    0  reserved for 'any'
    1  reserved for SNMPv1
    2  reserved for SNMPv2c
    3  User-Based Security Model (USM)";
    }

    typedef SnmpMessageProcessingModel {
      type int32 {
        range "0..2147483647";
      }
      description
        "An identifier that uniquely identifies a Message
Processing Model of the Message Processing
Subsystem within this SNMP Management Architecture.

The values for messageProcessingModel are
allocated as follows:

- Values between 0 and 255, inclusive, are
  reserved for standards-track Message Processing
  Models and 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 Model
  defined by the enterprise whose enterpriseID


  is 1 would be 259.

This scheme for allocating messageProcessingModel
values allows for a maximum of 255 standards-
based Message Processing Models, and for a
maximum of 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 for various
organizations to design and define non-standard
messageProcessingModels.  This limits the ability
to define new proprietary implementations of
Message Processing Models to the first 8,388,608
enterprises.

It is worthwhile to note that, in its encoded
form, the messageProcessingModel value will
normally require only a single byte since, in
practice, the leftmost bits will be zero for
most messages and sign extension is suppressed
by the encoding rules.

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

    0  reserved for SNMPv1
    1  reserved for SNMPv2c
    2  reserved for SNMPv2u and SNMPv2*
    3  reserved for SNMPv3";
    }

    typedef SnmpSecurityLevel {
      type enumeration {
        enum "noAuthNoPriv" {
          value 1;
        }
        enum "authNoPriv" {
          value 2;
        }
        enum "authPriv" {
          value 3;
        }
      }
      description
        "A Level of Security at which SNMP messages can be
sent or with which operations are being processed;
in particular, one of:

  noAuthNoPriv - without authentication and
		 without privacy,
  authNoPriv   - with authentication but
		 without privacy,
  authPriv     - with authentication and
		 with privacy.

These three values are ordered such that
noAuthNoPriv is less than authNoPriv and
authNoPriv is less than authPriv.";
    }

    typedef SnmpAdminString {
      type string {
        smiv2:display-hint "255t";
      }
      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 [RFC2279].

Since additional code points are added by
amendments to the 10646 standard from time
to time, implementations must be prepared to
encounter any code point from 0x00000000 to
0x7fffffff.  Byte sequences that do not
correspond to the valid UTF-8 encoding of a
code point or are outside this range are
prohibited.

The use of control codes should be avoided.

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


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

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

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

UTF-8 may require multiple bytes to represent a
single character / code point; thus the length
of this object in octets may be different from
the number of characters encoded.  Similarly,
size constraints refer to the number of encoded
octets, not the number of characters represented
by an encoding.

Note that when this TC is used for an object that
is used or envisioned to be used as an index, then
a SIZE restriction MUST be specified so that the
number of sub-identifiers for any object instance
does not exceed the limit of 128, as defined by
[RFC3416].

Note that the size of an SnmpAdminString object is
measured in octets, not characters.";
    }

    identity snmpAuthProtocols {
      base smiv2:object-identity;
      description
        "Registration point for standards-track
authentication protocols used in SNMP Management
Frameworks.";
    }

    identity snmpPrivProtocols {
      base smiv2:object-identity;
      description
        "Registration point for standards-track privacy
protocols used in SNMP Management Frameworks.";
    }

    container SNMP-FRAMEWORK-MIB {
      config false;
      container snmpEngine {
        smiv2:oid "1.3.6.1.6.3.10.2.1";
        leaf snmpEngineID {
          smiv2:max-access "read-only";
          smiv2:oid "1.3.6.1.6.3.10.2.1.1";
          type SnmpEngineID;
          description
            "An SNMP engine's administratively-unique identifier.

This information SHOULD be stored in non-volatile
storage so that it remains constant across
re-initializations of the SNMP engine.";
        }

        leaf snmpEngineBoots {
          smiv2:max-access "read-only";
          smiv2:oid "1.3.6.1.6.3.10.2.1.2";
          type int32 {
            range "1..2147483647";
          }
          description
            "The number of times that the SNMP engine has
(re-)initialized itself since snmpEngineID
was last configured.";
        }

        leaf snmpEngineTime {
          smiv2:max-access "read-only";
          smiv2:oid "1.3.6.1.6.3.10.2.1.3";
          type int32 {
            range "0..2147483647";
          }
          units "seconds";
          description
            "The number of seconds since the value of
the snmpEngineBoots object last changed.
When incrementing this object's value would
cause it to exceed its maximum,
snmpEngineBoots is incremented as if a
re-initialization had occurred, and this
object's value consequently reverts to zero.";
        }

        leaf snmpEngineMaxMessageSize {
          smiv2:max-access "read-only";
          smiv2:oid "1.3.6.1.6.3.10.2.1.4";
          type int32 {
            range "484..2147483647";
          }
          description
            "The maximum length in octets of an SNMP message
which this SNMP engine can send or receive and
process, determined as the minimum of the maximum
message size values supported among all of the
transports available to and supported by the engine.";
        }
      }  // container snmpEngine
    }  // container SNMP-FRAMEWORK-MIB
  }  // module SNMP-FRAMEWORK-MIB