[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 RFC 4498

Network Working Group                        Glenn Mansfield Keeni
INTERNET-DRAFT                                Cyber Solutions Inc.
Expires: June 15, 2003                            December 16 2002



                   The Managed Object Aggregation MIB
                    <draft-glenn-mo-aggr-mib-02.txt>

Status of this Memo

   Status of this Memo

      This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026.

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

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt.

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

      This Internet-Draft will expire on June 15, 2003.

   Copyright Notice

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



Abstract

   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it is used to configure an agent to aggregate MOs
   and to service queries related to the aggregated MOs.





Expires: June 15, 2003                                          [Page 1]

Internet Draft                                          December 16 2002


Table of Contents

   1.  Introduction .................................................. 3
   2.  The Internet-Standard Management Framework .................... 5
   3.  The Requirements for Managed Object Aggregation ............... 5
   4.  MIB Design .................................................... 6
   5.  The Managed Object Aggregation MIB ............................ 7
   6.  Intellectual Property .........................................16
   7.  Acknowledgements ..............................................17
   References ........................................................18
   Security Considerations ...........................................20
   Authors' Addresses ................................................21
   Full Copyright Statement ..........................................22






































Expires: June 15, 2003                                          [Page 2]

Internet Draft                                          December 16 2002


1.  Introduction.

   For the purpose of management it is necessary to access Managed
   Objects (MOs). The SNMP framework provides a mechanism for naming and
   describing managed objects.  These objects are accessed via a virtual
   information store termed a Management Information Base (MIB). MIBs
   have been defined by equipment, protocol and, application developers
   to provide management access to the managed entities. We will call
   the MOs defined in these MIBs - simple MOs (SMO). Management
   applications will access one or more of these MOs, one or more times,
   to monitor the target entity.

   There is a cost associated with polling. The cost is the network
   bandwidth and the packet header processing overhead at the command
   generator (manager) and the command responder (agent). This cost
   constrains the number of objects that can be polled and the interval
   at which polling can be carried out.

   The overhead reduction can be carried out by reducing the number of
   query-response packets. This will reduce the packet processing
   overhead and to some extent the bandwidth.

   The payloads in a typical SNMP "get" packet and the corresponding
   response are as shown in Fig. 1. In the example shown in the figure
   polling is carried out for 'n' Managed Objects (MOs) OID1, OID2, ..,
   OIDn. It is obvious that a substantial amount of the payload in an
   SNMP packet consists of the OIDs. In [ODC-Dft] OID compression has
   been proposed by using the OID Delta Compression mechanism.

   In this draft a mechanism of MO aggregation for payload compression
   is defined.  The idea is simple: we introduce the concept of an
   Aggregate MO (AgMO). An AgMO is just another MO as far as the SNMP
   protocol is concerned. No new protocol operations will be required to
   handle these MOs. As in the case of any other MO it requires
   additional instrumentaion  at the command responder (agent) and at
   the (command generator) manager.  In this  mechanism the user defines
   an Aggregate MO (AgMO) corresponding to one or more (predefined) MOs.
   Semantically, the AgMO will be equivalent to the concatenation of the
   values of the specified MOs.  With the definitions done, the user
   can, as and when the necessity arises, do an SNMP 'get' on instances
   of the AgMO to fetch the value of instances of the constituent MOs.
   There is substantial savings on bandwidth as only one instance object
   identifier is carried in the request and the response. In the normal
   case, instance object identifiers for each of the constituent MO
   instances would be carried in the requests and the response.  This is
   the basic concept of Aggregate Managed Objects.

   The concepts are explained in Fig. 2. An aggregate managed object



Expires: June 15, 2003                                          [Page 3]

Internet Draft                                          December 16 2002


   AgMOx has been defined for MO instances MOI1, ... MOIn. The value of
   an instance of AgMOx will be a concatenation of the values of of
   MOI1, ... MOIn, in that order.




     Polling for MO Instances [MOI1, MOI2, ... MOIn] :

               +--------+------+-------+... -+------+------+
        Query: |Get req | MOI1 | NULL  |     | MOIn | NULL |
               +--------+------+-------+... -+------+------+


               +--------+------+-------+... -+------+------+
     Response: |Get resp| MOI1 | Val1  |     | MOIn | Valn |
               +--------+------+-------+... -+------+------+

                       Fig. 1 Polling for MO instances



     Polling for an instance (AgMOIx) of an aggregate MO [AgMOx]:
     AgMOx = aggr{AgMOI1, AgMOI2, ......AgMOIn}

               +--------+--------+-------+
        Query: |Get req | AgMOIx | NULL  |
               +--------+--------+-------+


               +--------+--------+------------------------+
     Response: |Get resp| AgMOIx |    Val1,Val2,...,Valn  |
               +--------+--------+------------------------+

                        Fig. 2 MO aggregation
















Expires: June 15, 2003                                          [Page 4]

Internet Draft                                          December 16 2002


2. The Internet-Standard Management Framework

   For a detailed overview of the documents that describe the current
   Internet-Standard Management Framework, please refer to section 7 of
   RFC xxxx [RFCxxxx].

   Managed objects are accessed via a virtual information store, termed
   the Management Information Base or MIB.  MIB objects are generally
   accessed through the Simple Network Management Protocol (SNMP).

   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

3.  The Requirements for Managed Object aggregation

   The general requirements of managed object aggregation are as
   follows:

          o It should lead to lesser number of packets
          o It should lead to lesser bandwidth consumption
          o It should not lead to loss of information

   The manager application is expected to configure aggregate MOs with
   care so that the response size is not too large. In case the
   resultant response size is larger than the maximum acceptable message
   size of the originator or larger than the local maximum message size
   then the error-status field will be set to "tooBig".





















Expires: June 15, 2003                                          [Page 5]

Internet Draft                                          December 16 2002


4.  MIB Design.

The basic principle has been to keep the MIB as simple as  possible and
at the same time to make it flexible enough so that a large number of
users and applications can use the MIB to configure aggregate MOs
conveniently.

The MIB comprises of three tables described below.
    - The aggrCtlTable controls the aggregation process. Each row in
      this table defines the attributes of aggregate object defined in
      the aggrMOTable.

    - The aggrMOTable defines the primary MO-based aggregation
      i.e. the MOs that will be aggregated.

    - The aggrDataTable contains the details of the aggregated object
      The size of the table may be decided by implementations.


































Expires: June 15, 2003                                          [Page 6]

Internet Draft                                          December 16 2002


5.  The Managed Object Aggregation MIB.


      AGGREGATE-MIB DEFINITIONS ::= BEGIN
       IMPORTS
         MODULE-IDENTITY,  experimental, Integer32,
         OBJECT-TYPE, Opaque
                    FROM SNMPv2-SMI
         OwnerString
                    FROM RMON-MIB
         RowStatus, TEXTUAL-CONVENTION
                    FROM SNMPv2-TC
         MODULE-COMPLIANCE, OBJECT-GROUP
                    FROM SNMPv2-CONF
         SnmpAdminString
                    FROM SNMP-FRAMEWORK-MIB;

     aggrMIB MODULE-IDENTITY
          LAST-UPDATED "200207140000Z"        --  14th July 2002
          ORGANIZATION "Cyber Solutions  NetMan Working Group"
          CONTACT-INFO
         "                      Glenn Mansfield Keeni
                        Postal: Cyber Solutions Inc.
                                6-6-3, Minami Yoshinari
                                Aoba-ku, Sendai, Japan 989-3204.
                           Tel: +81-22-303-4012
                           Fax: +81-22-303-4015
                        E-mail: glenn@cysols.com

             Support Group E-mail: mibsupport@cysols.com"

             DESCRIPTION
                     " The MIB for servicing aggregate objects."

                  ::= { experimental nnn } -- will be assigned by IANA
















Expires: June 15, 2003                                          [Page 7]

Internet Draft                                          December 16 2002


      AggrMOErrorStatus ::= TEXTUAL-CONVENTION
        STATUS       current
        DESCRIPTION
          "This data type is used to model the error status of the
           constituent MO instances. The error status for a constituent
           MO instance is given in terms of two elements -
             o the moIndex which indicates the position of the MO
               instance (starting at 1) in the value of the aggregated MO
               instance.
             o the moError which indicates the error that was encountered
               in fetching that MO instance.
           The syntax in ASN.1 Notation will be
           ErrorStatus :: = SEQUENCE {
              moIndex  Integer32,
              moError  SnmpPduErrorStatus
           }
           AggrMOErrorStatus ::= SEQUENCE OF {
              ErrorStatus
           }
           Note1: the command responder will supply values for all
                  constituent MO instances and in the same order in which
                  AggrMO is defined. If an error is
                  encountered for an MO instance then the corresponding
                  value will have an ASN.1 value NULL and, an error
                  flagged in the corresponding AggrMOErrorStatus object.
                  Only MOs for which errors have been encountered will
                  have the corresponding moIndex and moError values set.
           Note2: the error code for the component MO instances will be
                  in accordance with the SnmpPduErrorStatus TC defined in
                  the DISMAN-SCHEDULE-MIB.
           Note3: the command generator will need to know the constituent
                  MO instances and their order to correctly interpret
                  AggrMOErrorStatus.
          "
        SYNTAX      Opaque (SIZE (0..1024))
















Expires: June 15, 2003                                          [Page 8]

Internet Draft                                          December 16 2002


      AggrMOValue ::= TEXTUAL-CONVENTION
        STATUS       current
        DESCRIPTION
          "This data type is used to model the aggregate
           MOs. It will have a format dependent on the constituent
           MOs, a sequence of values. The syntax in  ASN.1 Notation will
           be
           MOValue :: = SEQUENCE {
                value ObjectSyntax
           }
           Where, 'value' is the value of a constituent MO instance.
           AggrMOValue :: = SEQUENCE OF {
               MOValue
           }

   -- I would have preferred to have have an object as follows. But this
   -- is probably not allowed. Is it binding for textual conventions too?

   --      AggrMO :: = SEQUENCE {
   --           aggrMOValue        AggrMOValue,
   --           aggrMOErrorStatus  AggrMOErrorStatus
   --      }

           Note: the command generator will need to know the
           the constituent MO instances and their order to
           correctly interpret AggrMOValue."
        SYNTAX      Opaque (SIZE (0..1024))

      CompressedAggrMOValue ::= TEXTUAL-CONVENTION
        STATUS       current
        DESCRIPTION
          "This data type is used to model the compressed
           aggregate MOs. "
        SYNTAX      OCTET STRING (SIZE (0..1024))

   --
   -- The aggregation control table
   -- There will be a row for each aggregate MO
   --
      aggrCtlTable OBJECT-TYPE
           SYNTAX  SEQUENCE OF AggrCtlEntry
           MAX-ACCESS  not-accessible
           STATUS current
           DESCRIPTION
             " A table that controls the aggregation of the MOs."
           ::= {aggrMIB 1}





Expires: June 15, 2003                                          [Page 9]

Internet Draft                                          December 16 2002


       aggrCtlEntry OBJECT-TYPE
           SYNTAX  AggrCtlEntry
           MAX-ACCESS  not-accessible
           STATUS  current
           DESCRIPTION
             "A row of the control table that defines one aggregated
              MO."
           INDEX {aggrEntryID }
           ::= {aggrCtlTable 1 }

       AggrCtlEntry ::= SEQUENCE {
          aggrEntryID
                        SnmpAdminString,
          aggrAgMOIndex
                        Integer32,
          aggrAgMODescr
                        SnmpAdminString,
          aggrCompressionAlgorithm
                        Integer32,
          aggrEntryOwner
                        OwnerString,
          aggrEntryStatus
                        RowStatus
       }

      aggrEntryID OBJECT-TYPE
           SYNTAX SnmpAdminString (SIZE(1..32))
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
             " A locally-unique administratively assigned name
               for this aggregated MO. It is used as an index to
               uniquely identify this row in the table."
           ::= { aggrCtlEntry 1 }

      aggrAgMOIndex OBJECT-TYPE
           SYNTAX Integer32
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
             " A pointer to a group of MOs identified by aggrMOEntryID
               in the aggrMOTable. This is the group of MOs that will
               be aggregated."
           ::= { aggrCtlEntry 2 }







Expires: June 15, 2003                                         [Page 10]

Internet Draft                                          December 16 2002


      aggrAgMODescr OBJECT-TYPE
           SYNTAX SnmpAdminString (SIZE(0..64))
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
             " A textual description of the object that is
               being aggregated."
           ::= {aggrCtlEntry 3}

      aggrCompressionAlgorithm OBJECT-TYPE
           SYNTAX INTEGER {
                  none      (1)
           }
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
             " The Compression algorithm that will be used by
               the agent to compress the aggregated object."
           DEFVAL { 1 }
           ::= {aggrCtlEntry 4}

      aggrEntryOwner OBJECT-TYPE
           SYNTAX OwnerString
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
             " The entity that created this entry."
           ::= {aggrCtlEntry 5}

      aggrEntryStatus OBJECT-TYPE
           SYNTAX RowStatus
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
              "The row status variable, used according to row
               installation and removal conventions."
           ::= {aggrCtlEntry 6}














Expires: June 15, 2003                                         [Page 11]

Internet Draft                                          December 16 2002


   --
   -- The Table of primary MOs
   -- Each row in this table represents a MO which will be aggregated.
   -- The aggrMOEntryID index is used to identify the group of MOs
   -- that will be aggregated. The aggrMOEntryMOID index is used to
   -- identify an MO in the group.
   --
      aggrMOTable OBJECT-TYPE
           SYNTAX  SEQUENCE OF AggrMOEntry
           MAX-ACCESS  not-accessible
           STATUS current
           DESCRIPTION
             " A table of the MOs that will be aggregated."
           ::= {aggrMIB 2}

       aggrMOEntry OBJECT-TYPE
           SYNTAX  AggrMOEntry
           MAX-ACCESS  not-accessible
           STATUS  current
           DESCRIPTION
             "A row of the table that specifies one MO."
           INDEX { aggrMOEntryID, aggrMOEntryMOID }
           ::= {aggrMOTable 1 }

       AggrMOEntry ::= SEQUENCE {
          aggrMOEntryID
                        Integer32,
          aggrMOEntryMOID
                        Integer32,
          aggrMOInstance
                        OBJECT IDENTIFIER,
          aggrMODescr
                        SnmpAdminString,
          aggrMOEntryStatus
                        RowStatus
       }

      aggrMOEntryID OBJECT-TYPE
           SYNTAX Integer32 (0..65535)
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
             " An Index uniquely indentifying a group of MOs
               that will be aggregated."
           ::= { aggrMOEntry 1 }






Expires: June 15, 2003                                         [Page 12]

Internet Draft                                          December 16 2002


      aggrMOEntryMOID OBJECT-TYPE
           SYNTAX Integer32 (0..65535)
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
             " An Index to uniquely identify an MO instance in the
               group of MO instances that will be aggregated."
           ::= { aggrMOEntry 2 }

      aggrMOInstance OBJECT-TYPE
           SYNTAX OBJECT IDENTIFIER
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
             " The OID of the MO instance - the value of which will
               being sampled by the agent."
           ::= { aggrMOEntry 3 }

      aggrMODescr OBJECT-TYPE
           SYNTAX SnmpAdminString (SIZE(0..64))
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
             " A textual description of the object that will
               be aggregated."
           ::= {aggrMOEntry 4}

      aggrMOEntryStatus OBJECT-TYPE
           SYNTAX RowStatus
           MAX-ACCESS read-create
           STATUS current
           DESCRIPTION
              "The row status variable, used according to row
               installation and removal conventions."
           ::= {aggrMOEntry 5}
















Expires: June 15, 2003                                         [Page 13]

Internet Draft                                          December 16 2002


      --
      -- aggrDataTable: The Table of Data. Each row represents a Data set.
      -- aggrEntryID is the key to the table.
      -- of instances of the aggregated MO that will be present in the table.
      --
      aggrDataTable OBJECT-TYPE
           SYNTAX  SEQUENCE OF AggrDataEntry
           MAX-ACCESS  not-accessible
           STATUS  current
           DESCRIPTION
             " Each row of this table contains information
               about an aggregateMO indexed by aggrEntryID."
           ::= {aggrMIB 3}

      aggrDataEntry OBJECT-TYPE
           SYNTAX  AggrDataEntry
           MAX-ACCESS  not-accessible
           STATUS  current
           DESCRIPTION
             " Entry containing information pertaining
               an aggregate MO."
           INDEX {aggrEntryID}
           ::= {aggrDataTable 1 }

      AggrDataEntry ::= SEQUENCE {
         aggrDataRec
                    AggrMOValue,
         aggrDataRecC
                    CompressedAggrMOValue,
         aggrErrorRec
                    AggrMOErrorStatus
         }

      aggrDataRec OBJECT-TYPE
           SYNTAX AggrMOValue
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
             "The snapshot value of the aggregated MO."
           ::= { aggrDataEntry 1}











Expires: June 15, 2003                                         [Page 14]

Internet Draft                                          December 16 2002


      aggrDataRecC OBJECT-TYPE
           SYNTAX CompressedAggrMOValue
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
             " The compressed value of the aggregated MO.
               The compression algorithm will depend on the
               aggrCompressionAlgorithm given in the corresponding
               aggrCtlEntry. In case the value of the corresponding
               aggrCompressionAlgorithm is (1) none then this MO
               will be inaccessible.
             "
           ::= { aggrDataEntry 2}

      aggrErrorRec OBJECT-TYPE
           SYNTAX AggrMOErrorStatus
           MAX-ACCESS read-only
           STATUS current
           DESCRIPTION
             " The error status corresponding to the MO instances
               aggregated in aggrDataRec (and aggrDataRecC)."
           ::= { aggrDataEntry 3}

       -- Conformance information
      aggrConformance OBJECT IDENTIFIER ::= { aggrMIB 4 }
      aggrGroups      OBJECT IDENTIFIER ::= { aggrConformance 1 }
      aggrCompliances OBJECT IDENTIFIER ::= { aggrConformance 2 }

       -- Compliance statements
      aggrDataCompliance MODULE-COMPLIANCE
           STATUS  current
           DESCRIPTION
                   "The compliance statement for SNMP entities
                    which implement the
                               AGGREGATE-MIB."
           MODULE  -- this module
               MANDATORY-GROUPS { aggrDataGroup }
           ::= { aggrCompliances 1 }













Expires: June 15, 2003                                         [Page 15]

Internet Draft                                          December 16 2002


       -- Units of conformance
      aggrDataGroup    OBJECT-GROUP
           OBJECTS {
                      aggrEntryID,
                      aggrAgMOIndex,
                      aggrAgMODescr,
                      aggrCompressionAlgorithm,
                      aggrEntryOwner,
                      aggrEntryStatus,
                      aggrMOEntryID,
                      aggrMOEntryMOID,
                      aggrMOInstance,
                      aggrMODescr,
                      aggrMOEntryStatus,
                      aggrDataRec,
                      aggrDataRecC,
                      aggrErrorRec
          }
           STATUS  current
           DESCRIPTION
                   " A collection of objects for aggregation of MOs."
           ::= { aggrGroups 1 }
      END




























Expires: June 15, 2003                                         [Page 16]

Internet Draft                                          December 16 2002


6.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

7.  Acknowledgements

This draft is the product of discussions and deliberations carried out
in the WIDE-netman group and the IETF-EOS-WG.

























Expires: June 15, 2003                                         [Page 17]

Internet Draft                                          December 16 2002


References

[Normative References]

[RFC2578]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Structure of Management
            Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999

[RFC2579]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Textual Conventions for
            SMIv2", STD 58, RFC 2579, April 1999

[RFC2580]   McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
            Rose, M., and S. Waldbusser, "Conformance Statements for
            SMIv2", STD 58, RFC 2580, April 1999


[Informative References]

[ODC-Dft]   Schoenwaelder, J. "SNMP Payload Compression", Work In Progress
            http://www.ietf.org/internet-drafts/internet-draft draft-irtf-
            nmrg-snmp-compression-01.txt, April, 2001.
[RFC2571]   Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture
            for Describing SNMP Management Frameworks", RFC 2571, April
            1999

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

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

[RFC1215]   M. Rose, "A Convention for Defining Traps for use with the
            SNMP", RFC 1215, March 1991

[RFC1157]   Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
            Network Management Protocol", STD 15, RFC 1157, May 1990.

[RFC1901]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Introduction to Community-based SNMPv2", RFC 1901, January
            1996.

[RFC1906]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Transport Mappings for Version 2 of the Simple Network
            Management Protocol (SNMPv2)", RFC 1906, January 1996.

[RFC2572]   Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message



Expires: June 15, 2003                                         [Page 18]

Internet Draft                                          December 16 2002


            Processing and Dispatching for the Simple Network Management
            Protocol (SNMP)", RFC 2572, April 1999

[RFC2574]   Blumenthal, U., and B. Wijnen, "User-based Security Model
            (USM) for version 3 of the Simple Network Management
            Protocol (SNMPv3)", RFC 2574, April 1999

[RFC1905]   Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
            "Protocol Operations for Version 2 of the Simple Network
            Management Protocol (SNMPv2)", RFC 1905, January 1996.

[RFC2573]   Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications",
            RFC 2573, April 1999

[RFC2575]   Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
            Access Control Model (VACM) for the Simple Network

[RFC2570]   Case, J., Mundy, R., Partain, D., and B. Stewart,
            "Introduction to Version 3 of the Internet-standard Network
            Management Framework", RFC 2570, April 1999

[RFCxxxx]  Case, J., Mundy, R., Partain, D., and B. Stewart,
           "Introduction and Applicability Statements for the
            Internet-Standard Management Framework", RFC xxxx,
            December 2002.


























Expires: June 15, 2003                                         [Page 19]

Internet Draft                                          December 16 2002


Security Considerations

   There are management objects defined in this MIB that have a MAX-
   ACCESS clause of read-write and read-create. There is the risk that
   an intruder can alter or create any management objects of this MIB
   via direct SNMP SET operations. So, care must be taken to put in place
   the security provisions of SNMP for authentication and access control.
   Not all versions of SNMP provide features for such a secure environment.

   SNMPv1 by itself is such an insecure environment.  Even if the
   network itself is secure (for example by using IPSec), even then,
   there is no control as to who on the secure network is allowed to
   access and GET (read) and SET (write) the objects in this MIB.

   It is strongly recommended that the implementors consider the security
   features as provided by the SNMPv3 framework.  Specifically, the use
   of the User-based Security Model RFC 2274 [RFC2274] and the View-based
   Access Control Model RFC 2275 [RFC2275] is recommended.

   It is then a customer/user responsibility to ensure that the SNMP
   entity giving access to an instance of this MIB, is properly
   configured to give access to those objects only to those principals
   (users) that have legitimate rights to access them.




























Expires: June 15, 2003                                         [Page 20]

Internet Draft                                          December 16 2002


Authors' Addresses

   Glenn Mansfield Keeni
   Cyber Solutions Inc.
   6-6-3 Minami Yoshinari
   Aoba-ku, Sendai 989-3204
   Japan

   Phone: +81-22-303-4012
   EMail: glenn@cysols.com









































Expires: June 15, 2003                                         [Page 21]

Internet Draft                                          December 16 2002


Full Copyright statement

         "Copyright (C) The Internet Society (2002). All Rights
         Reserved.

         This document and translations of it may be copied and
         furnished to others, and derivative works that comment on or
         otherwise explain it or assist in its implmentation may be
         prepared, copied, published and distributed, in whole or in
         part, without restriction of any kind, provided that the above
         copyright notice and this paragraph are included on all such
         copies and derivative works.  However, this document itself may
         not be modified in any way, such as by removing the copyright
         notice or references to the Internet Society or other Internet
         organizations, except as needed for the  purpose of developing
         Internet standards in which case the procedures for copyrights
         defined in the Internet Standards process must be followed, or
         as required to translate it into languages other than English.

         The limited permissions granted above are perpetual and will
         not be revoked by the Internet Society or its successors or
         assigns.

         This document and the information contained herein is provided
         on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
         ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
         IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE
         OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY
         IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
         PARTICULAR PURPOSE."





















Expires: June 15, 2003                                         [Page 22]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/