Network Working Group T. Meng Internet-Draft W. Fan Intended status: Standards Track Huawei-Symantec Technologies Expires: August 31, 2009 February 27, 2009 Definitions of Managed Objects for lock via network management protocols draft-meng-fan-lock-mib-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 August 31, 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 Meng & Fan Expires August 31, 2009 [Page 1] Internet-Draft Definitions of MOs for lock via NMps February 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 defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring locks on a device acquired or released by NETCONF and COPS-PR entities. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The Internet-Standard Management Framework . . . . . . . . . . 4 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Main lock Table . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. Specific NM interface lock Table . . . . . . . . . . . 5 4.1.2. Statistics . . . . . . . . . . . . . . . . . . . . . . 6 4.2. MIB References . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 4.4. Security Considerations . . . . . . . . . . . . . . . . . 17 4.5. IANA Considerations . . . . . . . . . . . . . . . . . . . 18 4.6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 18 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Normative References . . . . . . . . . . . . . . . . . . . 18 5.2. Informative References . . . . . . . . . . . . . . . . . . 19 Meng & Fan Expires August 31, 2009 [Page 2] Internet-Draft Definitions of MOs for lock via NMps February 2009 1. Introduction This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for monitoring locks on a device acquired or released by NETCONF and COPS-PR entities. The Network Configuration Protocol defined in RFC 4741 [RFC4741] provides mechanisms to install, manipulate, and delete the configuration of network devices. It provides global lock mechanism via lock and unlock operations for allowing only one session at a time to make a change to configuration datastore. However, [draft-ietf-netconf-partial-lock] defines partial lock mechanism as a capability to extending base NETCONF for allowing multiple sessions to be able to modify the configuration of a managed device in parallel. The primary purpose of this MIB module is to allow operators to monitor NETCONF locks and understand how they might be impacting the operation of the device and the network. A customer might be using applications that manage a particular type of functionality. For example, those applications might use SNMP to configure firewalls, but an operator applying a Netconf lock to the firewall might prevent SNMP from configuring the firewall. We want to make it possible for the operator to determine why the firewall is not getting configured on a timely basis. COPS usage for Policy Provisioning (COPS-PR) defined in RFC 3084 [RFC3084] provides mechanisms and conventions used to communicate provisioned information (QoS, Security policy,etc.) between PEPs and PDPs. Between PEP and PDP, there is a single connection per Client-Type for a given area of policy (e.g., QoS)so at a given time there must be only one server updates a particular policy configuration. Such a policy configuration is effectively locked. COPS-PR can be used for many types of provisioning policies, such as QoS policy in a Differentiated Services (DiffServ) environment, security policy in a firewall filtering policy provisioning environment, etc. COPS-PR uses locks and may co-exist with other NM interfaces, such as Netconf, SNMP and proprietary CLIs, and they might affect each other, so it should be included in this MIB module. Now this MIB module only contains common managed objects for generic lock and specific managed objects for NETCONF and COPS-PR locks. If Meng & Fan Expires August 31, 2009 [Page 3] Internet-Draft Definitions of MOs for lock via NMps February 2009 a device wants to support any other locks, this module SHALL be extended to contain more appropriate objects. 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 RFC3410 [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, RFC2578 [RFC2578], STD 58, RFC2579 [RFC2579] and STD 58, RFC2580 [RFC2580]. 3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [RFC2119]. 4. Overview The primary purpose of this mib module is to allow operators to monitor locks and understand how they might be impacting the operation of the device and the network. With such a MIB module, SNMP could be used to monitor locks set by NETCONF, COPS-PR (or by other protocols).If an entity's certain area of data is locked by a protocol,there must be a corresponding operation to add the information of this lock into this MIB module ,this memo leaves such as implementation specific. It will be useful for a SNMP operator that retrieving particular information of active locks before sending SET request. If there is any lock that intersects the requested objects, the operator could know how the SET request would be impacted by locks, e.g., the SET request would be delayed or denied by locks. When a (partial) system is locked, SNMP entity should not be permitted a SET request on the locked objects. If the device determines that all or a portion of requested objects is locked, it should probably response an error to the operator letting him know that the SET request could not be completed because certain network management entity has locked the relevant resources. This error should be "resource unavailable (13)" defined in [RFC3416]. Meng & Fan Expires August 31, 2009 [Page 4] Internet-Draft Definitions of MOs for lock via NMps February 2009 4.1. Main lock Table There is common information for all locks via any network management protocol. Lock Table, which contains entries for all locks, includes common information of locks such as the protocol by which a lock is acquired, the principal who own a lock, and duration the lock last, etc. This table exists on devices that can be managed and configured via SNMP, NETCONF or others protocols. This mib module also defines an object named lockNMInterfacesSupported to represent which NM interface locks are tracked. For example, without this indication, if there are no cops-pr locks in the main table, it may due to cops-pr is not supported on the device, cops-pr locks are not monitored or just that there are no active locks. By providing an object that says which interfaces are monitored for locks, an operator can better assess the lock status of the device. 4.1.1. Specific NM interface lock Table Now there is only two specific NM interface locks to be tracked. There might be some other lock tables for specific NM interfaces in the future. This lockNetconftable provides information on each lock instance set by Netconf NM interface in main table. The lockCopsPrTable provides specific information on each lock instance set by COPS-PR NM interface in main table. 4.1.1.1. Netconf lock table The netconf table represents the specific information of locks via NETCONF, including the sessions who own a lock, the lock ID, the datastore affected (running/candidate/startup/etc.), and the scope of the lock, etc. There is an object named lockNetconfModified for indicating the candidate datastore is changed or not. It is useful to have a flag for modified/unmodified status of the locked objects. Once locked, it remains unmodified until somebody changes the data. Once committed, it is clean again. This could be useful information for somebody considering forcing an unlock operation. It could also be useful for an operator to understand that a device is in the process of active maintenance (its config is likely to change soon). For example, if the lock owner is authorized to make such changes, the operator can probably ignore SNMP interface up/down Meng & Fan Expires August 31, 2009 [Page 5] Internet-Draft Definitions of MOs for lock via NMps February 2009 traps if there is an active lock on the interface configurations. Also a security manager might take interest when security configuration information is being modified. 4.1.1.2. COPS-PR lock table The COPS-PR lock table represents the specific information of locks via COPS-PR, including the area of the policy provisioning identified by the client-type, policies being installed, policies being removed and policies being updated, etc. There is an object named lockCopsPrModified for indicating the policy is modified or not. It is a useful flag as described in the lockNetconfModified object. 4.1.2. Statistics This mib module defines some statistic objects to keep track of the number of current active locks, failed locks. SNMP applications often retrieve the values of counters periodically in order to detect unusual conditions occurring. These statistic objects can help to warn about anomalous behavior. If the number of locks grows suddenly or locks keep getting set for long periods of time, this could be a security problem, e.g. somebody could be trying to cause a denial of service. Keeping track of the number of active locks can help to uncover this. If the number of lock failures is unusual, an attacker might be trying to lock things they are not authorized to lock. Or to lock as much as they can get away with, and they need to keep trying different expressions to see what works. The counter for lockFailures could help uncover this behavior. 4.2. MIB References The following MIB module has IMPORTS from [RFC2578], [RFC2579], [RFC2580], [RFC3411]. In REFERENCE clauses, it also refers to [RFC2748],[RFC4741] and [draft-ietf-netconf-partial-lock]. 4.3. Definitions LOCK-MIB DEFINITIONS ::= BEGIN IMPORTS Meng & Fan Expires August 31, 2009 [Page 6] Internet-Draft Definitions of MOs for lock via NMps February 2009 MODULE-IDENTITY, OBJECT-TYPE, mib-2, Unsigned32, TimeTicks, INTEGER, BITS,IpAddress FROM SNMPv2-SMI RowStatus, TruthValue FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF SnmpAdminString FROM SNMP-FRAMEWORK-MIB; lockMIB MODULE-IDENTITY LAST-UPDATED "200902270000Z"-- 27 February 2009 ORGANIZATION "IETF Operations and Management Area Working Group (opsawg) " CONTACT-INFO " Tony Meng Postal: Huawei-Symantec Technologies Harbour Building ZhongGuanCun Software Park, HaiDian District Beijing, China 100094 Email: mengjian@huaweisymantec.com Washam Fan Postal: Huawei-Symantec Technologies Harbour Building ZhongGuanCun Software Park, HaiDian District Beijing, China 100094 Email: Washam.Fan@huaweisymantec.com " DESCRIPTION "The module defines management information for managing 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 "200902270000Z"-- 27 February 2009 DESCRIPTION "Initial version, published as RFC XXXX." ::= { mib-2 XXX } --to be assigned by IANA -- Administrative assignments ******************************* lockObjects OBJECT IDENTIFIER ::= { lockMIB 1 } lockConformance OBJECT IDENTIFIER ::= { lockMIB 2 } -- NM interfaces supported by the agent *********************** lockNMInterfacesSupported OBJECT-TYPE Meng & Fan Expires August 31, 2009 [Page 7] Internet-Draft Definitions of MOs for lock via NMps February 2009 SYNTAX BITS{ Netconf(0), COPSPR(1) } MAX-ACCESS read-only STATUS current DESCRIPTION " Network management interfaces which supporting lock operation supported by this entity which implements this lock mib module. Setting a bit to 1 indicates the specific network management interface is supported. Otherwise, it is not supported." ::= { lockObjects 1 } -- Statistics for the Lock Model ******************************* lockStatistics OBJECT IDENTIFIER ::= { lockObjects 2 } lockActivelocks OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of active locks." ::= { lockStatistics 1 } lockFailures OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The total number of failed locks." ::= { lockStatistics 2 } -- Basic information about the lock *************************** lockTable OBJECT-TYPE SYNTAX SEQUENCE OF LockEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Common information about locks owned by NM interfaces. Common information that every lock must have is presented in this table, specific information about particular NM interface which owing this lock is presented in a specific table. Such as lockNetconfTable, it contains specific information about Netconf lock." ::= { lockObjects 3 } Meng & Fan Expires August 31, 2009 [Page 8] Internet-Draft Definitions of MOs for lock via NMps February 2009 lockEntry OBJECT-TYPE SYNTAX LockEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Common information about a lock owned by a particular NM interface." INDEX { lockIndex } ::= { lockTable 1 } LockEntry ::= SEQUENCE { lockIndex Unsigned32, lockUserName SnmpAdminString, lockNMInterface SnmpAdminString, lockType INTEGER, lockStartTime TimeTicks, lockEndTime TimeTicks, lockState INTEGER } lockIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value, greater than zero, for each lock. This value is assigned contiguously starting from 1 by the agent. If the system implementing this mib module is reset, it must assign this value contiguously from the last one it assigned." ::= { lockEntry 1 } lockUserName OBJECT-TYPE SYNTAX SnmpAdminString (SIZE (0..32)) MAX-ACCESS read-only STATUS current DESCRIPTION "A human readable user name identifying the owner of the lock. If the name is not known, it must be the empty string (''H). It also may be an application name varies depending on the NM interface. " ::= { lockEntry 2 } lockNMInterface OBJECT-TYPE SYNTAX SnmpAdminString Meng & Fan Expires August 31, 2009 [Page 9] Internet-Draft Definitions of MOs for lock via NMps February 2009 MAX-ACCESS read-only STATUS current DESCRIPTION "The lock represented in this conceptual row is set by Netconf, then this value is 'lockNetconf'. If there are any network management interfaces defined in the future, then this value could be it. " ::= { lockEntry 3 } lockType OBJECT-TYPE SYNTAX INTEGER { global(1), partial(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the type of this lock ,global lock or partial lock." ::= { lockEntry 4 } lockStartTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This value is equal to the instance of sysUpTime when the lock is set. " ::= { lockEntry 5 } lockEndTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION " This value is equal to the instance of sysUpTime when the lock is unlocked. Due to not all NM interfaces use an endtime on their locks, the value zero indicates there is no endtime. If the system implementing this mib module is reset, so the lock is forcibly unlocked, this value should be the maximum of the TimeTicks. " ::= { lockEntry 6 } lockState OBJECT-TYPE SYNTAX INTEGER{ ACTIVE(1), FAILED(2), DONE(3) Meng & Fan Expires August 31, 2009 [Page 10] Internet-Draft Definitions of MOs for lock via NMps February 2009 } MAX-ACCESS read-only STATUS current DESCRIPTION "The current state of the lock in this lock table. The value 'Active' represents that the lock is active currently. The value 'Failed' represents that the lock request is failed. The value 'Done' represents that the lock has been unlocked. " ::= { lockEntry 7 } --Lock information of specific NM interface: Netconf******************* lockNetconfTable OBJECT-TYPE SYNTAX SEQUENCE OF LockNetconfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the locked objects selected by a Netconf entity." ::= { lockObjects 4 } lockNetconfEntry OBJECT-TYPE SYNTAX LockNetconfEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the locked objects selected by a Netconf entity. " INDEX { lockNetconfIndex } ::= { lockNetconfTable 1 } LockNetconfEntry ::= SEQUENCE { lockNetconfIndex Unsigned32, lockNetconfSessionID Unsigned32, lockNetconfLockID Unsigned32, lockNetconfTarget BITS, lockNetconfSelectType INTEGER, lockNetconfSelect SnmpAdminString, lockNetconfModified TruthValue, lockNetconfReleasedBy Unsigned32 } lockNetconfIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) Meng & Fan Expires August 31, 2009 [Page 11] Internet-Draft Definitions of MOs for lock via NMps February 2009 MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies lock set by a netconf client. The lock identified by a particular value of this index is the same lock as identified by the same value of lockIndex." ::= { lockNetconfEntry 1} lockNetconfSessionID OBJECT-TYPE SYNTAX Unsigned32(1..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION "The sessionID of the Netconf session which owns this lock. " ::= { lockNetconfEntry 2 } lockNetconfLockID OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "This value is set to the Netconf lockID of this lock. " ::= { lockNetconfEntry 3 } lockNetconfTarget OBJECT-TYPE SYNTAX BITS{ Running(0), Candidate(1) } MAX-ACCESS read-only STATUS current DESCRIPTION " Represents the target of this lock." ::= { lockNetconfEntry 4 } lockNetconfSelectType OBJECT-TYPE SYNTAX INTEGER{ XPath(1), Subtree(2) } MAX-ACCESS read-only STATUS current DESCRIPTION "Represents the type of expression, XPath or subtree." ::= { lockNetconfEntry 5 } lockNetconfSelect OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current Meng & Fan Expires August 31, 2009 [Page 12] Internet-Draft Definitions of MOs for lock via NMps February 2009 DESCRIPTION "XPath or subtree expressions represent the scope of this lock. " ::= { lockNetconfEntry 6 } lockNetconfModified OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "The value 'true' indicates that the locked portion of the target has been modified by the user. The value 'false' indicates that no modifications have been done yet." ::= { lockNetconfEntry 7 } lockNetconfUnlockedBy OBJECT-TYPE SYNTAX Unsigned32(0..4294967295) MAX-ACCESS read-only STATUS current DESCRIPTION " Represents the session ID of the session which use unlock operation or end this lock forcibly. If the session which released this lock is the session which set this lock, then the value this instance is 0. " ::= { lockNetconfEntry 8 } --Lock information of specific NM interface: COPS-PR******************* lockCopsPrTable OBJECT-TYPE SYNTAX SEQUENCE OF LockCopsPrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the locked objects selected by a COPS-PR entity." ::= { lockObjects 6 } lockCopsPrEntry OBJECT-TYPE SYNTAX LockCopsPrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Information about the locked objects selected by a COPS-PR entity. " INDEX { lockCopsPrIndex } ::= { lockCopsPrTable 1 } LockCopsPrEntry ::= SEQUENCE { Meng & Fan Expires August 31, 2009 [Page 13] Internet-Draft Definitions of MOs for lock via NMps February 2009 lockCopsPrIndex Unsigned32, lockCopsPrPEPID OCTET STRING lockCopsPrPDPAddr IpAddress, lockCopsPrClientState INTEGER, lockCopsPrClientHandle Unsigned32, lockCopsPrClientType INTEGER, lockCopsPrInstallPolicies SnmpAdminString, lockCopsPrRemovePolicies SnmpAdminString, lockCopsPrUpdatePolicies SnmpAdminString, lockCopsPrModified TruthValue } lockCopsPrIndex OBJECT-TYPE SYNTAX Unsigned32 (1..4294967295) MAX-ACCESS not-accessible STATUS current DESCRIPTION "An index value that uniquely identifies lock owned by a COPS-PR client. The lock identified by a particular value of this index is the same lock as identified by the same value of lockIndex." ::= { lockCopsPrEntry 1 } lockCopsPrPEPID OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "It's value uniquely identifies the PEP whose policy configuration is locked. It's value is same as the value of PEPID defined in RFC 2748." ::= { lockCopsPrEntry 2 } locKCopsPrPDPAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "It's the IP address of the PDP which make the policy decision to the PEP." ::={ lockCopsPrEntry 3 } lockcopsPrClientState OBJECT-TYPE SYNTAX INTEGER{ CLOSE(0), OPEN(1) } MAX-ACCESS read-only STATUS current DESCRIPTION "This value indicates whether a particular type of client is supported both by the PEP identified by Meng & Fan Expires August 31, 2009 [Page 14] Internet-Draft Definitions of MOs for lock via NMps February 2009 PEPID and the PDP identified by LocKCopsPrPDPAddr. " ::={ lockCopsPrEntry 4 } lockCopsPrClientType OBJECT-TYPE SYNTAX INTEGER (0..65535) MAX-ACCESS read-only STATUS current DESCRIPTION "This value uniquely identifies the area of policy configuration. " ::= { lockCopsPrEntry 5 } lockCopsPrClientHandle OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION " The client handle value is used to uniquely identify a particular PEP's request among other currently installed requests." ::= { lockCopsPrEntry 6 } lockCopsPrInstallPolicies OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION "It's value indicates the provisioned policies to be installed by the PEP." ::= { lockCopsPrEntry 7 } lockCopsPrRemovePolicies OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " It's value indicates the provisioned policies to be deleted by the PEP." ::= { lockCopsPrEntry 8 } lockCopsPrUpdatePolicies OBJECT-TYPE SYNTAX SnmpAdminString MAX-ACCESS read-only STATUS current DESCRIPTION " It's value indicates the provisioned policies to be updated by the PEP." ::= { lockCopsPrEntry 9 } lockCopsPrModified OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current Meng & Fan Expires August 31, 2009 [Page 15] Internet-Draft Definitions of MOs for lock via NMps February 2009 DESCRIPTION "The value 'true' indicates that the locked portion of the target has been modified by the user. The value 'false' indicates that no modifications have been done yet." ::= { lockCopsPrEntry 10 } -- Conformance Information ******************************************* lockCompliances OBJECT IDENTIFIER ::= { lockConformance 1 } lockGroups OBJECT IDENTIFIER ::= { lockConformance 2 } -- Compliance statements lockCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for an entity who implements this LOCK-MIB." MODULE -- this module MANDATORY-GROUPS { lockBasicGroup } GROUP lockNetconfGroup DESCRIPTION "This group is mandatory only for those entities which implement Netconf." GROUP lockCopsPrGroup DESCRIPTION "This group is mandatory only for those entities which implement COPS-PR." ::= { lockCompliances 1 } lockBasicGroup OBJECT-GROUP OBJECTS { lockNMInterfacesSupported, lockUserName, lockNMInterface, lockType, lockStartTime, lockEndTime, lockState } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation of an entity which implements the lock managing and monitoring." ::= { lockGroups 1 } lockNetconfGroup OBJECT-GROUP Meng & Fan Expires August 31, 2009 [Page 16] Internet-Draft Definitions of MOs for lock via NMps February 2009 OBJECTS { lockNetconfSessionID, lockNetconfLockID, lockNetconfTarget, lockNetconfSelectType, lockNetconfSelect, lockNetconfModified, lockNetconfUnlockedBy } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation of an entity which supports Netconf." ::= { lockGroups 2 } lockCopsPrGroup OBJECT-GROUP OBJECTS { lockCopsPrPEPID, locKCopsPrPDPAddr, lockcopsPrClientState, lockCopsPrClientHandle, lockCopsPrClientType, lockCopsPrInstallPolicies, lockCopsPrRemovePolicies, lockCopsPrUpdatePolicies, lockCopsPrModified } STATUS current DESCRIPTION "A collection of objects providing basic instrumentation of an entity which supports COPS-PR." ::= { lockGroups 3 } END 4.4. Security Considerations There are no management objects defined in this MIB module that have a MAX-ACCESS clause of read-write and/or read-create. So, if this MIB module is implemented correctly, then there is no risk that an intruder can alter or create any management objects of this MIB module via direct SNMP SET operations. The readable objects in this MIB module are not sensitive. SNMP versions prior to SNMPv3 did not include adequate security. Even if the network itself is secure (for example by using IPsec), Meng & Fan Expires August 31, 2009 [Page 17] Internet-Draft Definitions of MOs for lock via NMps February 2009 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. 4.5. IANA Considerations The MIB module in this document uses the following IANA-assigned OBJECT IDENTIFIER values recorded in the SMI Numbers registry: Descriptor OBJECT IDENTIFIER value ---------- ----------------------- lockMIB { mib-2 XXX } Editor's Note (to be removed prior to publication): the IANA is requested to assign a value for "XXX" under the 'mib-2' subtree and to record the assignment in the SMI Numbers registry. 4.6. Acknowledgments Many thanks to David Harrington for his guidance and feedback on this MIB module. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 Meng & Fan Expires August 31, 2009 [Page 18] Internet-Draft Definitions of MOs for lock via NMps February 2009 (SMIv2)", RFC 2578, STD 58, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Textual Conventions for SMIv2", RFC 2579, STD 58, April 1999. [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Conformance Statements for SMIv2", RFC 2580, STD 58, April 1999. [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", RFC 3411, STD 62, December 2002. [RFC3416] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", RFC 3416, December 2002. [RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [draft-ietf-netconf-partial-lock] Lengyel, B. and M. Bjorklund, "Partial Lock RPC for NETCONF", December 2008. 5.2. Informative References [RFC2748] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R., and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001. Meng & Fan Expires August 31, 2009 [Page 19] Internet-Draft Definitions of MOs for lock via NMps February 2009 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction and Applicability Statements for Internet Standard Management Framework", December 2002. Authors' Addresses Tony Meng Huawei-Symantec Technologies Harbour Building ZhongGuanCun Software Park HaiDian District Beijing 100094 China EMail: mengjian@huaweisymantec.com URI: http://www.huaweisymantec.com Washam Fan Huawei-Symantec Technologies Harbour Building ZhongGuanCun Software Park HaiDian District Beijing 100094 China EMail: Washam.Fan@huaweisymantec.com URI: http://www.huaweisymantec.com Meng & Fan Expires August 31, 2009 [Page 20]