Internet DRAFT - draft-fan-meng-snmp-lock

draft-fan-meng-snmp-lock






Network Working Group                                             W. Fan
Internet-Draft                                                   T. Meng
Intended status: Standards Track            Huawei-Symantec Technologies
Expires: November 2, 2009                                       May 2009


                         A lock feature to SNMP
                      draft-fan-meng-snmp-lock-00

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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 November 2, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal



Fan & Meng              Expires November 2, 2009                [Page 1]

Internet-Draft           A lock feature to SNMP                 May 2009


   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This memo is intended to provide a lock mechanism to SNMP for
   protecting SET operations from being interrupted by any other network
   management operations such as NETCONF <edit-config> or CLI writes.
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular, it extends
   LOCK-MIB defined in [I-D.meng-fan-lock-mib] to define objects for
   managing SNMP locks.  The lock acquisition and release can be
   achieved through manipulating those objects.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Usage Scenarios  . . . . . . . . . . . . . . . . . . . . .  3
       1.1.1.  A large SET operation handling . . . . . . . . . . . .  3
       1.1.2.  Multiple SET operations handling as a transaction  . .  3
   2.  The Internet-Standard Management Framework . . . . . . . . . .  4
   3.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   5.  MIB extension to LOCK-MIB  . . . . . . . . . . . . . . . . . .  5
   6.  Elements of Procedure  . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Procedure of lock acquisition  . . . . . . . . . . . . . .  7
     6.2.  Procedure of lock release  . . . . . . . . . . . . . . . .  9
     6.3.  Procedure of lock validation . . . . . . . . . . . . . . .  9
   7.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   8.  Relationship to other MIBs . . . . . . . . . . . . . . . . . . 15
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
     9.1.  MIB Security Considerations  . . . . . . . . . . . . . . . 16
   10. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 18













Fan & Meng              Expires November 2, 2009                [Page 2]

Internet-Draft           A lock feature to SNMP                 May 2009


1.  Introduction

   Network devices may support multiple management protocols for
   flexible operation and management.  For example, a device may support
   NETCONF [RFC4741] , SNMP, and proprietary CLI for configuration and
   allow for multiple operators using different protocols configure it
   at the same time.  It is needed to protect operations from
   intervention by the others for data consistency, regardless of which
   NM protocol is used.

   This memo is intended to provide a lock mechanism to SNMP for
   protecting SET operations from being interrupted by any other network
   management operations such as NETCONF <edit-config> or CLI writes.
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols.  In particular it extends
   LOCK-MIB defined in [I-D.meng-fan-lock-mib] to define objects for
   managing SNMP locks.  The lock acquisition and releasing can be
   achieved through manipulating those objects.

1.1.  Usage Scenarios

   In the following we describe a few scenarios for SNMP locking.
   Besides the two described here, there might be many other usage
   scenarios possible.

1.1.1.  A large SET operation handling

   Now that SSH running over TCP as well as DTLS running over TCP and
   SCTP is proposed or accepted as an optional transport mapping for
   SNMP, people could write bigger messages, including SET messages.  In
   this case, SNMP agent may consume more time for processing the single
   large SET operation, SNMP would like to use locks to prevent
   conflicts during the processing as other NM interfaces might do.
   Nevertheless, locks should only be used when the manager knows they
   are sending an especially large SET except for the following cases,
   not for the normal SETs that only carry a few varbinds and complete
   in millisecond timeframes.

1.1.2.  Multiple SET operations handling as a transaction

   In some cases, we should treat multiple SET operations as a logic
   transaction as a whole, whatever they are across multiple tables or
   agents or even administrative domains.

   SNMP offers RowStatus, which can maintain state over a sequence of
   operations to a particular row in a table, but SNMP does not have a
   mechanism for "locking" while an SNMP manager builds transaction
   state across multiple tables or locking a configuration while a



Fan & Meng              Expires November 2, 2009                [Page 3]

Internet-Draft           A lock feature to SNMP                 May 2009


   manager builds a transaction across multiple agents. all operations
   within a transaction would be kept as atomic by using SNMP locking.

   New technologies that can be managed using SNMP can be implemented on
   devices that cross administrative domains.  IEEE 802.1 provider
   bridging, for example, might allow SETs to be done to a CPE device
   from two different administrative domains, where who can change what
   is determined using access controls.  But in some cases, it could be
   important when they can change what; it might be important that two
   administrators not try to modify the same device at the same time
   because this could cause misconfiguration.  Real locks (not the
   simple advisory locks commonly used in SNMP) might be used to prevent
   conflicts in provisioning shared administration environments.

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 3410 [RFC3410].

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

   Terms "SNMP manager" and "SNMP agent" have been defined in section
   3.1.3.1 and 3.1.3.2 respectively in [RFC3411] .

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

4.  Overview

   This memo enable SNMP agent to lock a portion or all of configuration
   data for a specific user.  In particular, the protected area by a
   lock is a set of object types (and instances) which are specified by
   a family of view subtrees, per section 2.4.2, [RFC3415].

   The SNMP agent MUST ensure that all the configuration resources
   protected by a lock are not modified by other SNMP or non-SNMP users
   (and sessions) such as NETCONF and the CLI.



Fan & Meng              Expires November 2, 2009                [Page 4]

Internet-Draft           A lock feature to SNMP                 May 2009


   The duration of a lock begins when the lock is granted and lasts
   until the corresponding unlock (whether forcibly or not) request
   succeeds or the underlying session terminates or the system where the
   agent resides reboots.

   A SNMP user MAY have multiple part of the configuration data locked
   via multiple lock requests.

   The SNMP agent assigns a lock identifier to the lock when a lock
   request has been processed (whether the lock is granted or not at
   last).

5.  MIB extension to LOCK-MIB

   This section describes the MIB extension to LOCK-MIB for managing
   SNMP locks.

   LOCK-MIB is defined in [I-D.meng-fan-lock-mib] to monitor locks via
   multiple NM interfaces.  It consists of the lockTable and several
   specific NM interface tables as well as several scalar variables.
   The lockTable collects generic information for all locks being
   managed by the device regardless of protocol and its structure is
   like:

   --lockObjects(1)
     |
     +--lockTable(3)
        |
        +--lockEntry(1) [lockIndex]
           |
           +--Unsigned32      lockIndex(1)
           |
           +--SnmpAdminString lockUserName(2)
           |
           +--SnmpAdminString lockNMInterface(3)
           |
           +--INTEGER         lockType(4)
           |
           +--TimeTicks       lockStartTime(5)
           |
           +--TimeTicks       lockEndTime(6)
           |
           +--INTEGER         lockState(7)

   [I-D.meng-fan-lock-mib] has more details.

   A specific NM interface lock table collects specific information with
   regard to all locks via one specific protocol, for example,



Fan & Meng              Expires November 2, 2009                [Page 5]

Internet-Draft           A lock feature to SNMP                 May 2009


   lockNetconfTable collects specific information of all locks via
   NETCONF.  Since LOCK-MIB allows for being extended by adding a new
   specific NM interface lock table, we organize specific information of
   all locks via SNMP into a specific NM interface lock table called
   lockSnmpTable:

   --lockObjects(1)
     |
     +--lockSnmpObjects(6)
        |
        +--TestAndIncr lockSnmpSpinLock(1)
        |
        +--lockSnmpTable(2)
           |
           +--lockSnmpEntry(1) [lockSnmpLockId]
              |
              +--Unsigned32        lockSnmpLockId(1)
              |
              +--SnmpAdminString   lockSnmpViewTreeFamilyViewName(2)
              |
              +--OBJECT IDENTIFIER lockSnmpViewTreeFamilySubtree(3)
              |
              +--OCTET STRING      lockSnmpViewTreeFamilyMask(4)
              |
              +--INTEGER           lockSnmpViewTreeFamilyType(5)
              |
              +--Unsigned32        lockSnmpIndex(6)
              |
              +--RowStatus         lockSnmpStatus(7)

   The meaning of each Object Type is explained as below:

      lockSnmpSpinLock is an advisory lock which is used to coordinate
      multiple simultaneous SETs to lockSnmpTable.

      lockSnmpLockId is an instance-identifier to differentiate multiple
      entries in lockSnmpTable.

      lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree,
      lockSnmpViewTreeFamilyMask and lockSnmpViewTreeFamilyType are
      jointly used to represent the protected area by a lock as a MIB
      view. their semantics is specified in [RFC3415].

      lockSnmpIndex connects a entry in lockSnmpTable to the
      corresponding entry in lockTable.

      lockSnmpStatus is used to indicate the status of the associated
      entry, "notReady" means the lock request is pending, "active"



Fan & Meng              Expires November 2, 2009                [Page 6]

Internet-Draft           A lock feature to SNMP                 May 2009


      means the lock takes effect.

   The lockSnmpTable can be used to acquire or release a lock, and can
   be combined with lockTable to monitor all SNMP locks.

6.  Elements of Procedure

   This section describes how to manipulate objects defined in section 5
   in order to acquire and release a lock.  It gives the procedure of
   lock acquisition, lock release as well as lock validation.

6.1.  Procedure of lock acquisition

   SNMP manager can request a lock by trying to create an entry in
   lockSnmpTable.  Before that, we should retrieve the value of
   lockSnmpSpinLock as the instance-identifier of the entry to be
   created and calculate the value of lockSnmpViewTreeFamilySubtree and
   lockSnmpViewTreeFamilyMask as well as specify the value of
   lockSnmpViewTreeFamilyViewName and lockSnmpViewTreeFamilyType to
   identify the intended protected area by the lock based on subsequent
   SET(s) to be issued.  Even though we create a entry successfully, its
   status column won't be active until the lock is granted.  Lock
   request failure would destroy the associate entry.  Whatever the lock
   is granted or not, a entry collecting generic information about the
   lock will be added to lockTable.

   Manager                     Agent
                 (1)
            <----------->
   (2)
                 (3)
           <------------>
                             (4)
                             (5)
                             (6)
                 (7)
            <----------->

      (1) the manager GET(lockSnmpSpinLock.0) and save in sValue. sValue
      is used to be the instance-identifier of the entry to be created.
      I.e., if an entry is created successfully, the value of the
      lockSnmpLockId associated with the entry equals to sValue.

      (2) the manager specifies the viewValue and typeValue, calculates
      the subtreeValue and maskValue based on the SET operations to be
      protected.  Combination of them is used to identify the intended
      protected area by the lock.  How to get these values is out of the
      scope of this document, and it is left to implementation-specific.



Fan & Meng              Expires November 2, 2009                [Page 7]

Internet-Draft           A lock feature to SNMP                 May 2009


      (3) the manager SET(lockSnmpSpinLock.0=sValue,
      lockSnmpViewTreeFamilyViewName=viewValue,
      lockSnmpViewTreeFamilySubtree=subtreeValue,
      lockSnmpVIewTreeFamilyMask=maskValue,
      lockSnmpViewTreeFamilyViewType=typeValue)

      (4) An entry is created with lockSnmpStatus="notReady" by the
      agent.

      (5) the agent processes the lock request based on criteria
      mentioned later.

      (6) After the lock request processing completes, an entry
      representing the lock is added to lockTable with
      lockState="ACTIVE" or lockState="FAILED" depending on the lock
      request succeeded or not, if lockState=ACTIVE, then the value of
      lockSnmpIndex is set to the value of the corresponding lockIndex
      in lockTable and the value of status column is set to ACTIVE,
      otherwise, the associated entry in lockSnmpTable is deleted.

      (7) the manager GET(lockSnmpStatus).  When the value of
      lockSnmpStatus is "active", the lock is valid.  Otherwise the lock
      failed.

   Granted locks protect all instances specified by the associated
   family of view subtrees (i.e., combination of values of
   lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree,
   lockSnmpViewFamilyMask and lockSnmpViewFamilyType) from modification
   by others, regardless of SNMP or non-SNMP operations.

   A lock request MUST be handled atomically by the agent.  The agent
   either locks all requested parts of the configuration data or none.
   If during the lock request processing one of the requested parts
   cannot be locked, the agent MUST unlock all parts that have already
   been locked during the lock request processing.

   The agent MUST be able to grant multiple simultaneous locks to a
   single user.  If the protected area of the individual locks overlaps,
   instances in the common area MUST be protected until all of the locks
   are released.

   With point (5) above, a lock request MUST fail if:

   o  Any part of the MIB to be protected is already locked by other
      users, including SNMP users or any other non-SNMP management
      method.





Fan & Meng              Expires November 2, 2009                [Page 8]

Internet-Draft           A lock feature to SNMP                 May 2009


   o  The agent implements access control model(s), and the locking user
      does not have sufficient access rights.  The exact handling of
      access rights is outside the scope of this document, but it is
      assumed that there is an access control system that MAY deny or
      allow the lock request.

6.2.  Procedure of lock release

   Manager can try to delete an entry in lockSnmpTable in order to
   release the associated active lock.

      (1) the manager SET(lockSnmpStatus=destroy)

      (2) the agent release the lock.

      (3) the manager GET(lockState) to check if the lock has been
      released or not.

   Manager                      Agent
               (1)
           <----------->
                             (2)
               (3)
           <----------->

6.3.  Procedure of lock validation

   An active SNMP lock should protect locked managed object types (and
   instances) from modification by other SNMP users or any other non-
   SNMP methods.  When the operations attempting to modify locked object
   types (and instances) arrives, the server MUST fail them (with error
   codes).  A locked object MUST be treated as an unavailable resource.
   For example, in a SNMPv3 message, the error code MUST be
   resourceUnavailable.

   According to section 4.2.5, [RFC3416], a SET operation is
   conceptually processed as a two phase operation.  Before actual
   variable assignments, there are 12 validation steps for checking,
   e.g., access rights, value types, etc.  If any variable binding's
   name specifies an already locked managed object types (or instance),
   step (11) will be triggered, i.e., the value of the Response-PDU's
   error-status field is set to "resourceUnavailable", and the value of
   its error-index field is set to the index of the failed variable
   binding.







Fan & Meng              Expires November 2, 2009                [Page 9]

Internet-Draft           A lock feature to SNMP                 May 2009


7.  Definitions

LOCK-SNMP-MIB DEFINITIONS ::= BEGIN

IMPORTS
    OBJECT-TYPE, MODULE-IDENTITY,
    mib-2, Unsigned32                FROM SNMPv2-SMI
    TestAndIncr, RowStatus           FROM SNMPv2-TC
    SnmpAdminString                  FROM SNMP-FRAMEWORK-MIB
    MODULE-COMPLIANCE, OBJECT-GROUP  FROM SNMPv2-CONF;

lockSnmpMIB MODULE-IDENTITY
    LAST-UPDATED "200905270000Z"-- 27 May 2009
    ORGANIZATION "Operations and Management Area Working Group"
    CONTACT-INFO
    "          Tony Meng
               Postal: Huawei-Symantec Technologies
                           3rd Floor, Section D, Keshi Building
                           No.28, Xinxi Rd., Shangdi, Haidian Dist.
                           Beijing 100085
                           China
               Email:  mengjian@huaweisymantec.com

               Washam Fan
               Postal: Huawei-Symantec Technologies
                           3rd Floor, Section D, Keshi Building
                           No.28, Xinxi Rd., Shangdi, Haidian Dist.
                           Beijing 100085
                           China
               Email:  Washam.Fan@huaweisymantec.com
    "
    DESCRIPTION  "The module defines management information for
                 managing SNMP locks for network management protocols.

                 Copyright (C) The IETF Trust (2009).  This version
                 of this MIB module is part of RFC XXXX; see the RFC
                 itself for full legal notices."

-- RFC Ed.: replace XXXX with actual RFC number & remove this note

    REVISION     "200905270000Z"-- 27 May 2009
    DESCRIPTION  "Initial version, published as RFC XXXX."

    ::= { mib-2 xxx } --to be assigned by IANA

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

lockSnmpObjects     OBJECT IDENTIFIER ::= { lockSnmpMIB 1 }



Fan & Meng              Expires November 2, 2009               [Page 10]

Internet-Draft           A lock feature to SNMP                 May 2009


lockSnmpConformance OBJECT IDENTIFIER ::= { lockSnmpMIB 2 }

lockSnmpSpinLock OBJECT-TYPE
    SYNTAX       TestAndIncr
    MAX-ACCESS   read-write
    STATUS       current
    DESCRIPTION "An advisory lock used to allow cooperating SNMP
                 Command Generator applications to coordinate their
                 use of the Set operation in creating SNMP locks.

                 When creating a new SNMP lock, it is important to
                 understand the potential interactions with other
                 uses of the lock.  The lockSnmpSpinLock should be
                 retrieved.  The lockSnmpLockId of the lock to be
                 created should be determined to be unique by the
                 SNMP Command Generator application by consulting
                 the lockSnmpSpinLock.  Finally, the requested lock
                 may be created (Set), including the advisory lock.

                 If another SNMP Command Generator application has
                 altered the locks in the meantime, then the spin
                 lock's value will have changed, and so this creation
                 will fail because it will specify the wrong value for
                 the spin lock.

                 Since this is an advisory lock, the use of this lock
                 is not enforced.
                "
    ::= { lockSnmpObjects 1 }

lockSnmpTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF LockSnmpEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "This table collects specific information of all locks
                 via SNMP. The information includes lock identifiers for
                 identifying all locks via SNMP, intended protected area
                 by the lock, etc.

                 Users can request a lock by creating a new entry
                 successfully. Combination of values of
                 lockSnmpViewTreeFamilyViewName,
                 lockSnmpViewTreeFamilySubtree,
                 lockSnmpViewTreeFamilyMask
                 and lockSnmpViewTreeFamilyType represents the intended
                 protected area by the lock.

                 Users can release an active lock by trying to destroy



Fan & Meng              Expires November 2, 2009               [Page 11]

Internet-Draft           A lock feature to SNMP                 May 2009


                 the associated entry.

                 Users can retrieve the information of a lock from
                 lockTable by referencing the value of snmpLockIndex
                 when the lock is active.
                "
    ::= { lockSnmpObjects 2 }

lockSnmpEntry OBJECT-TYPE
    SYNTAX       LockSnmpEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry represents a SNMP lock and includes all
                 specific information about the lock.
                "
    INDEX       { lockSnmpLockId }
    ::= { lockSnmpTable 1 }

LockSnmpEntry ::= SEQUENCE
    {
        lockSnmpLockId                    Unsigned32,
        lockSnmpViewTreeFamilyViewName    SnmpAdminString,
        lockSnmpViewTreeFamilySubtree     OBJECT IDENTIFIER,
        lockSnmpViewTreeFamilyMask        OCTET STRING,
        lockSnmpViewTreeFamilyType        INTEGER,
        lockSnmpIndex                     Unsigned32,
        lockSnmpStatus                    RowStatus
    }

lockSnmpLockId OBJECT-TYPE
    SYNTAX       Unsigned32
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Lock identifier to differentiate all SNMP locks.
                 The value should equal to the value of lockSnmpSpinLock
                 when creating the associated entry.
                "
    ::= { lockSnmpEntry 1 }

lockSnmpViewTreeFamilyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The human readable name for a family of view subtrees.
                "
    ::= { lockSnmpEntry 2 }





Fan & Meng              Expires November 2, 2009               [Page 12]

Internet-Draft           A lock feature to SNMP                 May 2009


lockSnmpViewTreeFamilySubtree OBJECT-TYPE
    SYNTAX       OBJECT IDENTIFIER
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The MIB subtree which when combined with the
                 corresponding instance of lockSnmpViewTreeFamilyMask
                 defines a family of view subtrees.
                "
    ::= { lockSnmpEntry 3 }

lockSnmpViewTreeFamilyMask OBJECT-TYPE
    SYNTAX       OCTET STRING (SIZE (0..16))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The bit mask which, in combination with the
                 corresponding instance of
                 lockSnmpViewTreeFamilySubtree,
                 defines a family of view subtrees.

                 Readers can refer to [RFC3415] for details how to
                 define a family of view subtrees with the two values.
                "
    DEFVAL      { ''H }
    ::= { lockSnmpEntry 4 }

lockSnmpViewTreeFamilyType OBJECT-TYPE
    SYNTAX       INTEGER  { included(1), excluded(2) }
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "Indicates whether the corresponding instances of
                 lockSnmpViewTreeFamilySubtree and
                 lockSnmpViewTreeFamilyMask
                 define a family of view subtrees which is included in
                 or excluded from the MIB view.
                "
    DEFVAL      { included }
    ::= { lockSnmpEntry 5 }

lockSnmpIndex OBJECT-TYPE
    SYNTAX       Unsigned32
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "Lock identifier to differentiate all locks via
                 multiple NM interfaces. It connects the entry to
                 the corresponding entry in lockTable.

                 Users can retrieve the info of the lock from lockTable
                 by referencing the value.



Fan & Meng              Expires November 2, 2009               [Page 13]

Internet-Draft           A lock feature to SNMP                 May 2009


                "
    ::= { lockSnmpEntry 6 }

lockSnmpStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-write
    STATUS       current
    DESCRIPTION "With value 'notReady' means the lock request has been
                 submitted successfully but not yet processed.
                 With value 'active' means the lock is granted at last.
                 Failed and released lock will be deleted.
                "
    ::= { lockSnmpEntry 7 }

-- Conformance Information *******************************************

lockSnmpCompliances OBJECT IDENTIFIER ::= { lockSnmpConformance 1 }
lockSnmpGroups      OBJECT IDENTIFIER ::= { lockSnmpConformance 2 }


-- Compliance statements

lockSnmpCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION  "The compliance statement for an entity who implements
                 this LOCK-SNMP-MIB."

    MODULE       -- this module
    MANDATORY-GROUPS { lockSnmpGroup }

     ::= { lockSnmpCompliances 1 }

lockSnmpGroup OBJECT-GROUP
    OBJECTS     {
                  lockSnmpSpinLock,
                  lockSnmpViewTreeFamilyViewName,
                  lockSnmpViewTreeFamilySubtree,
                  lockSnmpViewTreeFamilyMask,
                  lockSnmpViewTreeFamilyType,
                  lockSnmpIndex,
                  lockSnmpStatus
                }
    STATUS       current
    DESCRIPTION "A collection of objects providing basic instrumentation
                of an entity which supports SNMP lock."
    ::= { lockSnmpGroups 1 }

END



Fan & Meng              Expires November 2, 2009               [Page 14]

Internet-Draft           A lock feature to SNMP                 May 2009


8.  Relationship to other MIBs

   LOCK-MIB defined in [I-D.meng-fan-lock-mib] collects generic
   information of all locks supported in the device, the memo extends
   LOCK-MIB to collect specific information of all SNMP locks described
   in this memo.  LOCK-MIB and the extension done in this memo can be
   used jointly to manage and control SNMP locks, per section 6.

   When the extension is added to LOCK-MIB, statistics variables should
   reflect SNMP locks defined in this memo as well as other NM interface
   locks.  When a SNMP lock becomes active, the value of lockActivelocks
   should be incremented by 1, when a SNMP lock failure occurs, the
   value of lockFailures should be incremented by 1, when an active SNMP
   lock is released, the value of lockActivelocks should be reduced by
   1.

   SNMP-VIEW-BASED-ACM-MIB defined in [RFC3416] defines
   vacmViewTreeFamilyTable to represent views. lockSnmpTable represents
   views in the identical way which is used to identify protected areas
   by locks.

9.  Security Considerations

   This document enable a SNMP agent to handle the lock acquisition,
   lock release and lock validation.  These work should be done in
   accordance with Security Model and Access Control Model to manage and
   control locks.

   Before a manager can set lockSnmpTable, it should be authenticated
   successfully.  When a conceptual row is to be created in
   lockSnmpTable, the agent should check if the authenticated manager
   has appropriate privileges about all objects falling into the
   intended locked area as well as other criteria if necessary.

   A lock might prevent other users from configuring the system (which
   might lead to DoS attack).  The following mechanisms are in place to
   prevent the misuse of this possibility:

      Only an authenticated and authorized user should be allowed to
      request a lock.

      The lock is automatically released when a session (if it exists,
      e.g., SSH transport mapping is used) is terminated regardless of
      how the session ends.  The reboot behavior leads to all the active
      locks automatically released.

      Implementations should allow an administrator to release an SNMP
      lock via SNMP and through the native CLI console interface, to be



Fan & Meng              Expires November 2, 2009               [Page 15]

Internet-Draft           A lock feature to SNMP                 May 2009


      able to prevent denial of service attacks.

      Keeping track of the number of active locks using lockActivelocks
      counter can uncover some bad behaviors.  E.g.  If the number of
      active locks grows rapidly or there are locks lasting for a long
      period of time, somebody might be trying to launch a denial of
      service attack.

      The SNMP agent may log lock requests in an audit trail.

   LOCK-MIB doesn't allow for modifying specific NM interface lock
   tables except for lockSnmpTable, which means a non SNMP lock can't be
   released via manipulating managed objects defined in LOCK-MIB.  Since
   the access control system is different among different NM interfaces,
   SNMP lock SHOULD NOT be released by non SNMP interfaces or methods.

   lock release forcibly might lead to difficult recovery, as It is
   impossible to rollback all successful SET(s) protected by the lock.
   When a lock is grant in a SET processing procedure, it may cause The
   SET processing in place failed.  In that case, the agent SHOULD try
   to undo all the assignments in the SET, the corresponding Response
   PDU is returned with error-status with value "commitFailed" or
   "undoFailed" (in the latter case. the undone failed).

9.1.  MIB Security Considerations

   There are a number of management objects defined in this MIB module
   with a MAX-ACCESS clause of read-write and/or read-create.  Such
   objects may be considered sensitive or vulnerable in some network
   environments.  The support for SET operations in a non-secure
   environment without proper protection can have a negative effect on
   network operations.  These are the tables and objects and their
   sensitivity/vulnerability:

   o  lockSnmpViewTreeFamilyViewName, lockSnmpViewTreeFamilySubtree,
      lockSnmpViewTreeFamilyMask, lockSnmpViewTreeFamilyType: these
      objects are used to identify the scope of intended locked area.
      If any object falling into this area is unauthorized to the
      requesting user, the lock request will fail.  If the SET operation
      has altered in an unauthoritative way, the lock request probably
      fails.

   o  lockSnmpStatus: this object indicates the state of the lock via
      combining with the lockState column in lockTable.  SET operations
      attempting set lockSnmpStatus to 'notInService' will release the
      lock or abort the lock request.  SET operations attempting set
      lockSnmpStatus to 'destroy' will delete the entry (and release an
      active lock).  So unauthorized SET operations will probably broken



Fan & Meng              Expires November 2, 2009               [Page 16]

Internet-Draft           A lock feature to SNMP                 May 2009


      an active lock illegally.

   SNMP versions prior to SNMPv3 did not include adequate security.
   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/SET (read/change/create/delete) the objects
   in this MIB module.

   It is RECOMMENDED that implementers consider the security features as
   provided by the SNMPv3 framework (see [RFC3410], section 8),
   including full support for the SNMPv3 cryptographic mechanisms (for
   authentication and privacy).

   Further, deployment of SNMP versions prior to SNMPv3 is NOT
   RECOMMENDED.  Instead, it is RECOMMENDED to deploy SNMPv3 and to
   enable cryptographic security.  It is then a customer/operator
   responsibility to ensure that the SNMP entity giving access to an
   instance of this MIB module is properly configured to give access to
   the objects only to those principals (users) that have legitimate
   rights to indeed GET or SET (change/create/delete) them.

10.  Acknowledges

   This draft partially borrows from Balazs Lengyel and Martin
   Bjorklund's [I-D.ietf-netconf-partial-lock].  Many thanks to David
   Harrington for his guidance and feedback on this doc.

11.  References

11.1.  Normative References

   [I-D.meng-fan-lock-mib]          Meng, T. and W. Fan, "Definitions of
                                    Managed Objects for lock via network
                                    management protocols", April 2009.

   [RFC2119]                        Bradner, S., "Key words for use in
                                    RFCs to Indicate Requirement
                                    Levels", BCP 14, EFC 2119,
                                    March 1997.

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

   [RFC2579]                        McCloghrie, K., Ed., Perkins, D.,
                                    Ed., and J. Schoenwaelder, Ed.,



Fan & Meng              Expires November 2, 2009               [Page 17]

Internet-Draft           A lock feature to SNMP                 May 2009


                                    "Textual Conventions for SMIv2",
                                    STD 58, RFC 2579, April 1999.

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

   [RFC3411]                        Harrington, D., Presuhn, R., and B.
                                    Wijnen, "An Architecture for
                                    Describing Simple Network Management
                                    Protocol (SNMP) Management
                                    Frameworks", STD 62, RFC 3411,
                                    December 2002.

   [RFC3415]                        Wijnen, B., Presuhn , R., and K.
                                    McCloghrie, "View-based Access
                                    Control Model (VACM) for the Simple
                                    Network Management Protocol (SNMP)",
                                    RFC 3415, December 2002.

   [RFC3416]                        Presuhn, R., "Version 2 of the
                                    Protocol Operations for the Simple
                                    Network Management Protocol (SNMP)",
                                    STD 62, RFC 3416, December 2002.

11.2.  Informative References

   [I-D.ietf-netconf-partial-lock]  Lengyel, B. and M. Bjorklund,
                                    "Partial Lock RPC for NETCONF",
                                    Feburary 2009.

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

   [RFC4741]                        Enns, R., Ed., "NETCONF
                                    Configuration Protocol", RFC 4741,
                                    December 2006.










Fan & Meng              Expires November 2, 2009               [Page 18]

Internet-Draft           A lock feature to SNMP                 May 2009


Authors' Addresses

   Washam Fan
   Huawei-Symantec Technologies
   3rd Floor, Section D, Keshi Building
   No.28, Xinxi Rd., Shangdi, Haidian Dist.
   Beijing  100085
   China

   EMail: Washam.Fan@huaweisymantec.com
   URI:   http://www.huaweisymantec.com


   Tony Meng
   Huawei-Symantec Technologies
   3rd Floor, Section D, Keshi Building
   No.28, Xinxi Rd., Shangdi, Haidian Dist.
   Beijing  100085
   China

   EMail: mengjian@huaweisymantec.com
   URI:   http://www.huaweisymantec.com





























Fan & Meng              Expires November 2, 2009               [Page 19]