INTERNET-DRAFT K. Vaughn Intended Status: Standards Track Trevilon LLC Expires: May 24, 2014 A. Triglia OSS Nokalva, Inc. R. Rausch Transcore, LP November 20, 2013 Protocol Operations for Condensed Network Management Protocol (CNMP) draft-vaughn-cnmp-pdu-00 Abstract This document specifies the protocol operations for Condensed Network Management Protocol (CNMP) messages. It defines the syntax and element of procedures for sending, receiving, and processing CNMP PDUs. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License Notice Copyright (c) 2013 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 Provisions Relating to IETF Documents K. Vaughn Expires May 24, 2014 [Page 1] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Management Information Base Definitions . . . . . . . . . . . 4 5. CNMP PDU Format . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Type Definitions . . . . . . . . . . . . . . . . . . . . 16 5.2.1. ObjectName . . . . . . . . . . . . . . . . . . . . . . 17 5.2.2. ObjectSyntax . . . . . . . . . . . . . . . . . . . . . 17 5.2.3. PDU Structure . . . . . . . . . . . . . . . . . . . . 18 5.2.4. DynamicObject-PDU . . . . . . . . . . . . . . . . . . 18 6. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 19 6.1.1. GetRequest-PDU . . . . . . . . . . . . . . . . . . . . 19 6.1.2. SetRequest-PDU and SetNoReply-PDU . . . . . . . . . . 20 6.1.3. GetNextRequest-PDU . . . . . . . . . . . . . . . . . . 21 6.1.1. GetResponse-PDU, SetResponse-PDU, InformResponse-PDU, and ErrorResponse-PDU . . . . . . 22 6.1.1. GetBulkRequest-PDU . . . . . . . . . . . . . . . . . . 22 6.1.1. Trap-PDU . . . . . . . . . . . . . . . . . . . . . . . 23 6.1.1. InformRequest-PDU . . . . . . . . . . . . . . . . . . 23 6.1.1. GetDynObjX . . . . . . . . . . . . . . . . . . . . . . 23 6.1.2. SetDynObjX and SetNoReplyDynObjX . . . . . . . . . . . 24 6.1.3. GetNextDynObjX . . . . . . . . . . . . . . . . . . . . 26 6.1.4. GetRespDynObjX, SetRespDynObjX, and ErrorRespDynObjX . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1 Normative References . . . . . . . . . . . . . . . . . . . 29 10.2 Informative References . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 K. Vaughn Expires May 24, 2014 [Page 2] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 1. Introduction The management framework used by CNMP consists of: 1) An architecture that conforms to that described in in STD 62 [RFC3411], [RFC5343], and [RFC5590], 2) Mechanisms for describing and naming objects and events for the purposes of management, as defined in STD 58 [RFC2578][RFC2579][RFC2580], 3) Message protocols for transferring management information, as defined in [Msg], 4) Protocol operations for accessing management information, as defined in this document, and 5) A set of fundamental applications and the view-based access control mechanism described in STD 62 [RFC3413][RFC3415]. A more complete introduction to CNMP can be found in [Intro]. This document, Protocol Operations for the Condensed Network Management Protocol, defines the operations of the protocol with respect to the sending and receiving of PDUs to be carried by the message protocol. Applications make use of the services of these subsystems. 2. 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 RFC 2119 [RFC2119]. Within this INTERNET-DRAFT and all referenced documents, CNMP is to be considered another version of SNMP. It is only given a different name because the protocol encoding does not follow the same message format as SNMP messages and the protocol will use a different binding with the transport layer. When referencing other RFCs, the any reference to SNMP in those RFCs shall be interpreted to reference CNMP, unless specifically stated otherwise within this document. 3. Overview CNMP Protocol Operations are nearly identical to those supported by SNMPv3, as defined in [RFC3416]. Readers of this document should become familiar with the content of that document. K. Vaughn Expires May 24, 2014 [Page 3] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 An overview of the exceptions to SNMPv3 Protocol Operations include: * CNMP defines a SetNoReply-PDU. This request type does not result in a response message. This request type can be useful for broadcasting commands that should be implemented by numerous devices near simultaneously. A manager can later verify the proper receipt of the command by issuing individual GetRequest- PDUs to each agent. * CNMP uses a separate ErrorResponse-PDU to report errors, eliminating the need to report no error in most messages. * CNMP defines a number of dynamic object PDUs that are placed directly over the transport without the normal CNMPVersionedMessage message wrapper. These PDUs offer the most condensed form of communication, but do not offer any real security features. * CNMP allows the use of RELATIVE-OIDs. In addition to providing more efficient encodings, this allows the GetNextRequest-PDU and GetBulkRequest-PDU to walk a defined range of the ISO naming tree. * CNMP makes a number of other refinements to decrease the size of a message without compromising key functionality of the protocol. * The Transport mappings for CNMP are defined in [Trans]. * CNMP uses SMIv2 as defined in [RFC2578]. 4. Management Information Base Definitions CNMP-PO-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-COMPLIANCE, OBJECT-GROUP FROM SNMPv2-CONF mgmt, MODULE-IDENTITY, OBJECT-TYPE FROM SNMPv2-SMI; cnmp OBJECT IDENTIFIER ::= { TBD1 } cnmpModules OBJECT IDENTIFIER ::= { cnmp 1 } cnmpPOMIB MODULE-IDENTITY LAST-UPDATED "201310170000Z" ORGANIZATION "Trevilon LLC" CONTACT-INFO "name: Kenneth Vaughn phone: +1-571-331-5670 email: kvaughn@trevilon.com postal: 6606 FM 1488 RD STE 148-503 K. Vaughn Expires May 24, 2014 [Page 4] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 Magnolia, TX 77354 USA " DESCRIPTION "The MIB for CNMP Protocol Operations." ::= { cnmpModules 2 } -- Administrative assignments *************************************** cnmpPOAdmin OBJECT IDENTIFIER ::= { cnmpPOMIB 1 } cnmpPOMIBObjects OBJECT IDENTIFIER ::= { cnmpPOMIB 2 } cnmpPOMIBConformance OBJECT IDENTIFIER ::= { cnmpPOMIB 3 } -- Statistics for CNMP Messages ************************************* dynObjectConfig OBJECT IDENTIFIER ::= { cnmpPOMIBObjects 1 } dynObjectMaxRows OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of dynamic objects supported by the entity. The first 13 dynamic objects can be retrieved with the most compact encodings of CNMP." ::= { dynObjectConfig 1 } dynObjectMaxVariables OBJECT-TYPE SYNTAX INTEGER (1..255) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of variables that can be referenced by a single dynamic object. This SHALL be equal to the number of conceptual rows that exist in the dynObjectVarTable for each dynObjectNumber and provides the maximum allowed value for dynObjectVarIndex. All dynamic objects within an implementation SHALL support the same maximum number of variable references. The actual number of variables contained within a dynamic object are defined by the rules in Clause X.X.X." ::= { dynObjectConfig 2 } dynObjectTable OBJECT-TYPE SYNTAX SEQUENCE OF DynObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table that defines the owner and status for each dynamic object and allows its retrieval. K. Vaughn Expires May 24, 2014 [Page 5] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 Agents that implement the Simple Transportation Management Protocol (STMP), as defined in NTCIP 1103, SHALL always synchronize the values of the objects in this table with the objects contained in the dynObjConfigTable." ::= { dynObjectConfig 3 } dynObjectEntry OBJECT-TYPE SYNTAX DynObjectEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dynObjTable. The table is indexed by the dynamic object number." INDEX { dynObjectNumber } ::= { dynObjectTable 1 } DynObjectEntry ::= SEQUENCE { dynObjectNumber INTEGER, dynObjectOwner DisplayString, dynObjectReset INTEGER, dynObjectValue OCTET STRING, dynObjectStatus RowStatus } dynObjectNumber OBJECT-TYPE SYNTAX INTEGER (1..dynObjectMaxRows) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The dynamic object number used as the index to the dynObjectTable and the primary index to the dynObjectVarTable." ::= { dynObjectEntry 1 } dynObjectOwner OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "The name of the owner of this dynamic object. This object cannot be set when the value of dynObjStatus is 'active'." ::= { dynObjectEntry 2 } dynObjectReset OBJECT-TYPE SYNTAX INTEGER { normal (1), clear (2) } (1..2) MAX-ACCESS read-write STATUS current DESCRIPTION "A control that allows a manager to easily reset all K. Vaughn Expires May 24, 2014 [Page 6] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 of the variable references for this dynamic object to null. A set to 'normal' SHALL have no effect. A set to 'clear' shall automatically set all dynObjVariable objects associated with this dynObjNumber to the value 'null' (i.e., 0.0). Once all of the dynObjVariable objects have been updated, the value of this object shall automatically transition to 'normal'. This object cannot be set when the value of dynObjStatus is 'active'." ::= { dynObjectEntry 3 } dynObjectValue OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The current value of the dynamic object. This is the Octet Encoding Rules [OER] encoding of the ASN.1 SEQUENCE of the referenced dynObjectVariable objects for this dynObjectNumber. This object shall only be accessible when dynObjectStatus for this dynamic object has a value of 'active'; at all other times, this object SHALL act as if its STATUS is 'not-accessible'." ::= { dynObjectEntry 4 } dynObjectStatus OBJECT-TYPE SYNTAX RowStatus (1..3) MAX-ACCESS read-write STATUS current DESCRIPTION "The status column used for modifying and validating instances of dynamic objects. The range of this object SAHLL be limited to 'active', 'notInService', and 'notReady'. Under no circumstances SHALL the values 'createAndGo', 'createAndWait', or 'destroy' be assigned to this object (i.e., 'wrongValue' error). An attempt to set this object to 'active' SHALL initiate consistency checks, which may cause an 'inconsistentValue' error. The value of this object SHALL NOT be 'active' when attempting to set any other column of this table (i.e., 'inconsistentValue' error)." ::= { dynObjectEntry 6 } dynObjectVarTable OBJECT-TYPE SYNTAX SEQUENCE OF DynObjectVarEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table that indicates the ordered list of K. Vaughn Expires May 24, 2014 [Page 7] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 variables contained in the dynamic object. Agents that implement the Simple Transportation Management Protocol (STMP), as defined in NTCIP 1103, SHALL always synchronize the values of the objects in this table with the objects contained in the dynObjDef table." ::= { dynObjectConfig 4 } dynObjectVarEntry OBJECT-TYPE SYNTAX DynObjectVarEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the dynObjVarTable. The table is indexed by the dynamic object number (from the dynObjTable) and the dynObjVarIndex." INDEX { dynObjectNumber, dynObjectVarIndex } ::= { dynObjectVarTable 1 } DynObjectVarEntry ::= SEQUENCE { dynObjectVarIndex INTEGER, dynObjectVariable OBJECT IDENTIFIER } dynObjectVarIndex OBJECT-TYPE SYNTAX INTEGER (1..dynObjectMaxVariables) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index position of the referenced variable within the dynamic object. This is the secondary index to the dynObjectVarTable." ::= { dynObjectVarEntry 1 } dynObjectVariable OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current DESCRIPTION "The instance of an object type to be included within the dynamic object. If this value is 'null' (0.0), the value of all dynObjectVariable objects for this dynObjectNumber with larger dynObjectVarIndexes shall be ignored. See Clause X.X.X. for a complete definition." ::= { dynObjectVarEntry 2 } defaultNodeConfig OBJECT IDENTIFIER ::= { cnmpPOMIBObjects 2 } K. Vaughn Expires May 24, 2014 [Page 8] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 defaultNodeMaxRows OBJECT-TYPE SYNTAX INTEGER (0..15) MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of defaultNode options supported by the entity within the ObjectName construct of CNMP." ::= { defaultNodeConfig 1 } defaultNodeTable OBJECT-TYPE SYNTAX SEQUENCE OF DefaultNodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table that defines the base nodes on the naming tree from which to identify objects when using one of the defaultNode (RELATIVE OID) options of the ObjectName format. See Clause X.X.X. for a complete definition." ::= { defaultNodeConfig 2 } defaultNodeEntry OBJECT-TYPE SYNTAX DefaultNodeEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the DefaultNodeTable. The table is indexed by the defaultNodeIndex." INDEX { defaultNodeIndex } ::= { defaultNodeTable 1 } defaultNodeEntry ::= SEQUENCE { defaultNodeIndex INTEGER, defaultNodeOid OBJECT IDENTIFIER } defaultNodeIndex OBJECT-TYPE SYNTAX INTEGER (1..defaultNodeMaxRows) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The default node number. Row 1 corresponds with the defaultNode1 option of the ObjectName construct." ::= { defaultNodeEntry 1 } defaultNodeOid OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-write STATUS current K. Vaughn Expires May 24, 2014 [Page 9] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 DESCRIPTION "The node on the naming tree from which the ObjectName is encoded. For example, if the value of the referenced defaultNodeOid is 'mib-2' (1.3.6.1.2.1), the ObjectName field would only need to encode '1.5' in order to reference the object 'sysName'." ::= { defaultNodeEntry 2 } -- Conformance information ****************************************** cnmpPOMIBCompliances OBJECT IDENTIFIER ::= {cnmpPOMIBConformance 1} cnmpPOMIBGroups OBJECT IDENTIFIER ::= {cnmpPOMIBConformance 2} -- Compliance statements cnmpPOCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The compliance statement for CNMP entities which implement the CNMP-PO-MIB." MODULE -- this module MANDATORY-GROUPS { cnmpCapabilitiesGroup } GROUP dynObjectGroup DESCRIPTION "The dynObjectGroup is mandatory if the value of dynObjectMaxRows is greater than zero (0)." GROUP defaultNode DESCRIPTION "The defaultNodeGroup is mandatory if the value of defaultNodeMaxRows is greater than zero (0)." ::= { cnmpPOMIBCompliances 1 } cnmpCapabilitiesGroup OBJECT-GROUP OBJECTS { dynObjectMaxRows, defaultNodeMaxRows } STATUS current DESCRIPTION "A collection of objects that indicate basic capabilities supported (or not supported) by the CNMP entity." ::= { cnmpPOMIBGroups 1 } dynObjectGroup OBJECT-GROUP OBJECTS { K. Vaughn Expires May 24, 2014 [Page 10] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 dynObjectMaxVariables, dynObjectOwner, dynObjectReset, dynObjectValue, dynObjectStatus, dynObjectVariable } STATUS current DESCRIPTION "A collection of objects providing for configuration and retrieval of dynamic objects." ::= { cnmpPOMIBGroups 1 } defaultNodeGroup OBJECT-GROUP OBJECTS { defaultNodeOid } STATUS current DESCRIPTION "A collection of objects providing for configuration and retrieval of dynamic objects." ::= { cnmpPOMIBGroups 1 } END 5. CNMP PDU Format 5.1. Definition CNMP-PDU DEFINITIONS ::= BEGIN IMPORTS IpAddress, Counter32, Unsigned32, Gauge32, TimeTicks, Opaque, Counter64 FROM SNMPv2-PDU; ObjectName ::= CHOICE { fullOid [0] OBJECT IDENTIFIER, -- OID is formed by the base and extension pair pair [1] OidPair, -- OID is relative to most recently used base extension [2] RELATIVE-OID, -- dynObject is relative to dynObjectValue, dynObject [3] RELATIVE-OID, -- defaultNodeX is relative to defaultNodeOid.X defaultNode1 [PRIVATE 1] RELATIVE-OID, K. Vaughn Expires May 24, 2014 [Page 11] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 defaultNode2 [PRIVATE 2] RELATIVE-OID, defaultNode3 [PRIVATE 3] RELATIVE-OID, defaultNode4 [PRIVATE 4] RELATIVE-OID, defaultNode5 [PRIVATE 5] RELATIVE-OID, defaultNode6 [PRIVATE 6] RELATIVE-OID, defaultNode7 [PRIVATE 7] RELATIVE-OID, defaultNode8 [PRIVATE 8] RELATIVE-OID, defaultNode9 [PRIVATE 9] RELATIVE-OID, defaultNode10 [PRIVATE 10] RELATIVE-OID, defaultNode11 [PRIVATE 11] RELATIVE-OID, defaultNode12 [PRIVATE 12] RELATIVE-OID, defaultNode13 [PRIVATE 13] RELATIVE-OID, defaultNode14 [PRIVATE 14] RELATIVE-OID, defaultNode15 [PRIVATE 15] RELATIVE-OID } OidPair ::= SEQUENCE { base OBJECT IDENTIFIER, extension RELATIVE-OID } ObjectSyntax ::= CHOICE { long Signed32, string-value OCTET STRING (SIZE (0..65535)), objectID-value OBJECT IDENTIFIER, ipAddress-value IpAddress, counter-value Counter32, ulong Unsigned32, timeticks-value TimeTicks, arbitrary-value Opaque, big-counter-value Counter64, byte Signed8, short Signed16, ubyte Unsigned8, ushort Unsigned16 } Signed8 ::= [APPLICATION 7] INTEGER (-128..127) Signed16 ::= [APPLICATION 8] INTEGER (-32768..32767) Signed32 ::= INTEGER (-2147483648..2147483647) Unsigned8 ::= [APPLICATION 9] INTEGER (0..255) Unsigned16 ::= [APPLICATION 10] INTEGER (0..65535) VarBind ::= SEQUENCE { name ObjectName, value CHOICE { value ObjectSyntax, noSuchObject [0] NULL, K. Vaughn Expires May 24, 2014 [Page 12] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 noSuchInstance [1] NULL, endOfMibView [2] NULL, endOfRange [3] NULL, processTimeout [4] NULL } } VarBinds ::= SEQUENCE (SIZE (0..255)) OF VarBind VarNames ::= SEQUENCE (SIZE (0..255)) OF ObjectName GetBulkRequest ::= SEQUENCE { non-repeaters Unsigned8, max-repetitions Unsigned8, variables VarNames } ErrorStatus ::= INTEGER { noError(0), tooBig(1), noSuchName(2), -- for proxy compatibility badValue(3), -- for proxy compatibility readOnly(4), -- for proxy compatibility genErr(5), noAccess(6), wrongType(7), wrongLength(8), wrongEncoding(9), wrongValue(10), noCreation(11), inconsistentValue(12), resourceUnavailable(13), commitFailed(14), undoFailed(15), authorizationError(16), notWritable(17), inconsistentName(18), invalidName(19), processTimeout(20) } (0..255) ErrorResponse ::= SEQUENCE { errorStatus ErrorStatus, errorIndex INTEGER (0..255), errorVariable OBJECT IDENTIFIER } CNMP-PDUs ::= CHOICE { getRequest GetRequest-PDU, K. Vaughn Expires May 24, 2014 [Page 13] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 setRequest SetRequest-PDU, setNoReply SetNoReply-PDU, getNextRequest GetNextRequest-PDU, getResponse GetResponse-PDU, setResponse SetResponse-PDU, errorResponse ErrorResponse-PDU, getBulkRequest GetBulkRequest-PDU, trap Trap-PDU, inform InformRequest-PDU, informResponse InformResponse-PDU } GetRequest-PDU ::= [0] VarNames SetRequest-PDU ::= [16] VarBinds SetNoReply-PDU ::= [32] VarBinds GetNextRequest-PDU ::= [48] VarNames GetResponse-PDU ::= [PRIVATE 0] VarBinds SetResponse-PDU ::= [PRIVATE 16] NULL ErrorResponse-PDU ::= [PRIVATE 32] ErrorResponse GetBulkRequest-PDU ::= [PRIVATE 48] GetBulkRequest Trap-PDU ::= [PRIVATE 49] VarBinds InformRequest-PDU ::= [PRIVATE 50] VarBinds InformResponse-PDU ::= [PRIVATE 51] NULL -- The following definitions provide for the most compact encoding -- but do not offer built-in security. They should only be used -- over networks that are either physically secure or secured by -- other means (e.g., VPN). GetDynObj1 ::= [1] NULL GetDynObj2 ::= [2] NULL GetDynObj3 ::= [3] NULL GetDynObj4 ::= [4] NULL GetDynObj5 ::= [5] NULL GetDynObj6 ::= [6] NULL GetDynObj7 ::= [7] NULL GetDynObj8 ::= [8] NULL GetDynObj9 ::= [9] NULL GetDynObj10 ::= [10] NULL GetDynObj11 ::= [11] NULL GetDynObj12 ::= [12] NULL GetDynObj13 ::= [13] NULL SetDynObj1 ::= [17] DynamicObject-PDU SetDynObj2 ::= [18] DynamicObject-PDU SetDynObj3 ::= [19] DynamicObject-PDU SetDynObj4 ::= [20] DynamicObject-PDU SetDynObj5 ::= [21] DynamicObject-PDU K. Vaughn Expires May 24, 2014 [Page 14] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 SetDynObj6 ::= [22] DynamicObject-PDU SetDynObj7 ::= [23] DynamicObject-PDU SetDynObj8 ::= [24] DynamicObject-PDU SetDynObj9 ::= [25] DynamicObject-PDU SetDynObj10 ::= [26] DynamicObject-PDU SetDynObj11 ::= [27] DynamicObject-PDU SetDynObj12 ::= [28] DynamicObject-PDU SetDynObj13 ::= [29] DynamicObject-PDU SetNoReplyDynObj1 ::= [33] DynamicObject-PDU SetNoReplyDynObj2 ::= [34] DynamicObject-PDU SetNoReplyDynObj3 ::= [35] DynamicObject-PDU SetNoReplyDynObj4 ::= [36] DynamicObject-PDU SetNoReplyDynObj5 ::= [37] DynamicObject-PDU SetNoReplyDynObj6 ::= [38] DynamicObject-PDU SetNoReplyDynObj7 ::= [39] DynamicObject-PDU SetNoReplyDynObj8 ::= [40] DynamicObject-PDU SetNoReplyDynObj9 ::= [41] DynamicObject-PDU SetNoReplyDynObj10 ::= [42] DynamicObject-PDU SetNoReplyDynObj11 ::= [43] DynamicObject-PDU SetNoReplyDynObj12 ::= [44] DynamicObject-PDU SetNoReplyDynObj13 ::= [45] DynamicObject-PDU GetNextDynObj1 ::= [49] NULL GetNextDynObj2 ::= [50] NULL GetNextDynObj3 ::= [51] NULL GetNextDynObj4 ::= [52] NULL GetNextDynObj5 ::= [53] NULL GetNextDynObj6 ::= [54] NULL GetNextDynObj7 ::= [55] NULL GetNextDynObj8 ::= [56] NULL GetNextDynObj9 ::= [57] NULL GetNextDynObj10 ::= [58] NULL GetNextDynObj11 ::= [59] NULL GetNextDynObj12 ::= [60] NULL GetNextDynObj13 ::= [61] NULL GetRespDynObj1 ::= [PRIVATE 1] DynamicObject-PDU GetRespDynObj2 ::= [PRIVATE 2] DynamicObject-PDU GetRespDynObj3 ::= [PRIVATE 3] DynamicObject-PDU GetRespDynObj4 ::= [PRIVATE 4] DynamicObject-PDU GetRespDynObj5 ::= [PRIVATE 5] DynamicObject-PDU GetRespDynObj6 ::= [PRIVATE 6] DynamicObject-PDU GetRespDynObj7 ::= [PRIVATE 7] DynamicObject-PDU GetRespDynObj8 ::= [PRIVATE 8] DynamicObject-PDU GetRespDynObj9 ::= [PRIVATE 9] DynamicObject-PDU GetRespDynObj10 ::= [PRIVATE 10] DynamicObject-PDU GetRespDynObj11 ::= [PRIVATE 11] DynamicObject-PDU K. Vaughn Expires May 24, 2014 [Page 15] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 GetRespDynObj12 ::= [PRIVATE 12] DynamicObject-PDU GetRespDynObj13 ::= [PRIVATE 13] DynamicObject-PDU SetRespDynObj1 ::= [PRIVATE 17] NULL SetRespDynObj2 ::= [PRIVATE 18] NULL SetRespDynObj3 ::= [PRIVATE 19] NULL SetRespDynObj4 ::= [PRIVATE 20] NULL SetRespDynObj5 ::= [PRIVATE 21] NULL SetRespDynObj6 ::= [PRIVATE 22] NULL SetRespDynObj7 ::= [PRIVATE 23] NULL SetRespDynObj8 ::= [PRIVATE 24] NULL SetRespDynObj9 ::= [PRIVATE 25] NULL SetRespDynObj10 ::= [PRIVATE 26] NULL SetRespDynObj11 ::= [PRIVATE 27] NULL SetRespDynObj12 ::= [PRIVATE 28] NULL SetRespDynObj13 ::= [PRIVATE 29] NULL ErrorRespDynObj1 ::= [PRIVATE 33] ErrorInformation-PDU ErrorRespDynObj2 ::= [PRIVATE 34] ErrorInformation-PDU ErrorRespDynObj3 ::= [PRIVATE 35] ErrorInformation-PDU ErrorRespDynObj4 ::= [PRIVATE 36] ErrorInformation-PDU ErrorRespDynObj5 ::= [PRIVATE 37] ErrorInformation-PDU ErrorRespDynObj6 ::= [PRIVATE 38] ErrorInformation-PDU ErrorRespDynObj7 ::= [PRIVATE 39] ErrorInformation-PDU ErrorRespDynObj8 ::= [PRIVATE 40] ErrorInformation-PDU ErrorRespDynObj9 ::= [PRIVATE 41] ErrorInformation-PDU ErrorRespDynObj10 ::= [PRIVATE 42] ErrorInformation-PDU ErrorRespDynObj11 ::= [PRIVATE 43] ErrorInformation-PDU ErrorRespDynObj12 ::= [PRIVATE 44] ErrorInformation-PDU ErrorRespDynObj13 ::= [PRIVATE 45] ErrorInformation-PDU -- The definition for DynamicObject-PDU is a placeholder -- See Clause 5.2.4 for a complete definition DynamicObject-PDU ::= SEQUENCE {} ErrorInformation-PDU ::= SEQUENCE { errorStatus ErrorStatus, errorIndex INTEGER (0..255) } END 5.2. Type Definitions The Type definitions of CNMP are conceptually similar to those defined in SNMPv3 [RFC3416] with the following exceptions. K. Vaughn Expires May 24, 2014 [Page 16] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 5.2.1. ObjectName CNMP allows the object name to be represented in several different forms as indicated by the CHOICE construct. The 'fullOid' option presents the ObjectName as a complete OBJECT IDENTIFIER, just as it would appear in SNMPv3. The 'pair' option presents the ObjectName as a base OBJECT IDENTIFIER coupled with an extension as a RELATIVE-OID. Combining the two components together provides the complete OBJECT IDENTIFIER as would be used in SNMPv3. The 'extension' option presents only an extension. It SHALL be coupled with the 'base' of the most recent, previously encoded 'pair' contained within the same PDU. For example, if a PDU contains four objects, where the first and third use the 'pair' encoding and the second and fourth use the 'extension' encoding', the second object extension would be combined with the base from the first object and the fourth object extension would be combined with the base from the third object. The 'dynObject' option presents the ObjectName as a RELATIVE OID, showing only the node that occurs after the node 'dynObjectValue' (i.e., the index of this object). For example, the RELATIVE OID for dynamic object 1 would be { 1 }, which in OER would be encoded as the hexadecimal value 0x0101, i.e., a length field of 0x01 followed by the node number of 0x01. The 'defaultNodeX' options present the ObjectName as a RELATIVE OID, showing only the node numbers that occur after the node referenced by 'defaultNodeOid.X' (See Clause 4), where the X equals the X in the option name. A CNMP entity is not required to support the default node option, but is required to support the defaultNodeMaxRows object to indicate how many default nodes are supported (including zero). Response PDUs SHALL use the same ObjectName format as used in the corresponding request without changing any base. For example, a GetResponse-PDU to a GetNextRequest-PDU using the 'pair' format SHALL use the 'pair' format in the response using the same 'base' value. If there is no such object in the current view, the CNMP entity will return an endOfRange value. 5.2.2. ObjectSyntax CNMP adds options for one- and two-byte, signed and unsigned integers in order to allow for more efficient encoding. The encoding of integral values SHALL be as follows: K. Vaughn Expires May 24, 2014 [Page 17] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 * If the object value to be encoded is for an object with a SYNTAX of Counter64 or any other INTEGER with only a positive value range that exceeds 2^32-1, the object value SHALL be encoded as a big- counter-value. * Otherwise, if the object value to be encoded is for an object with a SYNTAX of Counter32 or any other INTEGER with only a positive value range that exceeds 2^31-1, the object value SHALL be encoded as a big-counter-value. * Otherwise, CNMP restricts the value of the integer to a 32-bit signed value. The actual value instance to be encoded SHALL be encoded as follows: +-------------------------------+-------------------+ | Value to be Encoded | ObjectSyntax | +-------------------------------+-------------------+ | Lower Bound | Upper Bound | Option | +---------------+---------------+-------------------+ |-2,147,483,648 | -32,769 | long | +---------------+---------------+-------------------+ | -32,769 | -129 | short | +---------------+---------------+-------------------+ | -128 | -1 | byte | +---------------+---------------+-------------------+ | 0 | 255 | ubyte | +---------------+---------------+-------------------+ | 256 | 65,535 | ushort | +---------------+---------------+-------------------+ | 65,536 | 2,147,483,647 | long | +---------------+---------------+-------------------+ This mapping allows efficient encoding without knowledge of the specific object range while also allowing easy translation between SNMP and CNMP messages for Counter32 and Counter64 values. 5.2.3. PDU Structure The CNMPVersionedMessage uses one of 11 PDU structures in order to provide more efficient communications by only including information that is needed. The request-id field is removed from these structures; the message-id field from the parent message shall be used for this purpose. 5.2.4. DynamicObject-PDU The definition of the DynamicObject-PDU structure SHALL be defined at run-time based on the current configuration of the indicated dynamic K. Vaughn Expires May 24, 2014 [Page 18] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 object. Specifically, the definition the DynamicObject-PDU for a specific dynamic object SHALL be an ASN.1 SEQUENCE of the objects referenced by the dynObjectVariables for the specific dynamic object, in the order of their index values, ending at (and excluding) the first dynObjectVariable that is set to "null" (i.e., 0.0). EXAMPLE: dynObjectVariable.1.1 references sysDescr.0 dynObjectVariable.1.2 references sysUpTime.0 dynObjectVariable.1.3 references null The DynamicObject-PDU structure for dynamic object 1 would be defined as: DynamicObject-PDU ::= SEQUENCE { variable1 DisplayString (SIZE (0..255)), variable2 TimeTicks } 6. Elements of Procedure On generating a management communication, the message wrapper to encapsulate the PDU is generated according to the "Elements of Procedure" of the administrative framework in use. A compliant implementation must support as many bindings (i.e., size of ReqVarBinds, RespVarBinds, and VarNames) as fit into the overall maximum message size limit of the CNMP engine, but no more than 255 variable bindings. On receiving a management communication, the "Elements of Procedure" of the administrative framework in use is followed, and if those procedures indicate that the operation contained within the message is to be performed locally, then those procedures also indicate the MIB view which is visible to the operation. 6.1.1. GetRequest-PDU The processing of a GetRequest-PDU SHALL be identical to that as defined in Clause 4.2.1 of [RFC3416], with the following exceptions: 1) If an ObjectName using the 'extension' option appears prior to an ObjectSyntax using the 'pair' option, the response PDU SHALL be an ErrorResponse-PDU. The errorStatus field SHALL be set to "missingBase", the errorIndex field SHALL indicate the index of the objectName using the invalid extension format, and the errorVariable SHALL be set to "null" (0.0). 2) Otherwise, if the rules of [RFC3416] result in a response PDU with K. Vaughn Expires May 24, 2014 [Page 19] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 a non-zero error-status field, the response PDU SHALL be an ErrorResponse-PDU, as defined in Clause 5 of this Internet-Draft. If the errorIndex field is non-zero, the errorVariable field of the PDU SHALL be set to the full Object identifier of the requested ObjectName referenced by the errorIndex field; otherwise, the errorVariable field SHALL be set to 'null' (i.e., 0.0). 3) Otherwise, the response PDU SHALL be a GetResponse-PDU, as defined in Clause 5 of this Internet-Draft. 4) If the PDU contains multiple ObjectNames, the implementation may return a value of "processTimeout" for any request for any instance of dynObjectValue. This can be useful to prevent overloading of an agent's processor. 5) Any fields referenced in Clause 4.2.1 of [RFC3416] that do not have a parallel construct in the response PDU in Clause 5 of this Internet-Draft shall be ignored. 6.1.2. SetRequest-PDU and SetNoReply-PDU The processing of a SetRequest-PDU and a SetNoReply-PDU SHALL be identical to that as defined in Clause 4.2.5 of [RFC3416], with the following exceptions: 1) If the request is a SetNoReply-PDU, the entity SHALL NOT produce a response PDU, but all other rules shall be followed. 2) Otherwise, if an ObjectName using the 'extension' option appears prior to an ObjectSyntax using the 'pair' option, the entire request SHALL be rejected and the response PDU SHALL be an ErrorResponse-PDU. The errorStatus field SHALL be set to "missingBase", the errorIndex field SHALL indicate the index of the objectName using the invalid extension format, and the errorVariable SHALL be set to "null" (0.0). 3) Otherwise, if the rules of [RFC3416] result in a response PDU with a non-zero error-status field, the response PDU SHALL be an ErrorResponse-PDU, as defined in Clause 5 of this Internet-Draft. If the errorIndex field is non-zero, the errorVariable field of the PDU SHALL be set to the full Object identifier of the requested ObjectName referenced by the errorIndex field; otherwise, the errorVariable field SHALL be set to 'null' (i.e., 0.0). 4) Otherwise, if the PDU contains multiple ObjectNames and one or more of the ObjectNames reference instance(s) of dynObjectValue, K. Vaughn Expires May 24, 2014 [Page 20] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 the entire request MAY be rejected, in which case, the Response PDU SHALL be an ErrorResponse-PDU. The errorStatus field SHALL be set to "processTimeout", the errorIndex field SHALL indicate the index of the offending ObjectName field, and the errorVariable SHALL indicate the OBJECT IDENTIFIER of the dynObjectValue instance. 5) Otherwise, the response PDU SHALL be a SetResponse-PDU, as defined in Clause 5 of this Internet-Draft. 6) Any fields referenced in Clause 4.2.5 of [RFC3416] do not have a parallel construct in the response PDU in Clause 5 of this Internet-Draft shall be ignored. 6.1.3. GetNextRequest-PDU The processing of a GetNextRequest-PDU SHALL be identical to that as defined in Clause 4.2.2 of [RFC3416], with the following exceptions: 1) If an ObjectName using the 'extension' option appears prior to an ObjectSyntax using the 'pair' option, the response PDU SHALL be an ErrorResponse-PDU. The errorStatus field SHALL be set to "missingBase", the errorIndex field SHALL indicate the index of the objectName using the invalid extension format, and the errorVariable SHALL be set to "null" (0.0). 2) Otherwise, while processing a variable binding that uses a RELATIVE-OID, if the requested variable binding's name does not lexicographically precede the name of any variable accessible by this request which is a sub-node of the base used by the RELATIVE- OID, i.e., there is no lexicographic successor using the same base, then the corresponding variable binding produced in the Response-PDU has its value field set to "endOfRange", and its name field set to the variable binding's name in the request. If the endOfRange also corresponds to the endOfMibView, it is implementation dependent which value field is returned. 3) If the rules of [RFC3416] result in a response PDU with a non-zero error-status field, the response PDU SHALL be an ErrorResponse- PDU, as defined in Clause 5 of this Internet-Draft. If the errorIndex field is non-zero, the errorVariable field of the PDU SHALL be set to the full Object identifier of the requested ObjectName referenced by the errorIndex field; otherwise, the errorVariable field SHALL be set to 'null' (i.e., 0.0). 4) Otherwise, the response PDU SHALL be a GetResponse-PDU, as defined in Clause 5 of this Internet-Draft. K. Vaughn Expires May 24, 2014 [Page 21] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 5) If the PDU contains multiple ObjectNames, the implementation may return a value of "processTimeout" for any instance of dynObjectValue. This can be useful to prevent overloading of an agent's processor. 6) Any fields referenced in Clause 4.2.2 of [RFC3416] do not have a parallel construct in the response PDU in Clause 5 of this Internet-Draft shall be ignored. 6.1.1. GetResponse-PDU, SetResponse-PDU, InformResponse-PDU, and ErrorResponse-PDU The processing of a GetResponse-PDU, SetResponse-PDU, InformResponse- PDU, and ErrorResponse-PDU SHALL be identical to that as defined in Clause 4.2.4 of [RFC3416], with the following exceptions: 1) These PDUs are generated by a CNMP entity only according to the rules defined elsewhere in this Internet-Draft. 6.1.1. GetBulkRequest-PDU The processing of a GetBulkRequest-PDU SHALL be identical to that as defined in Clause 4.2.3 of [RFC3416], with the following exceptions: 1) If an ObjectName using the 'extension' option appears prior to an ObjectSyntax using the 'pair' option, the response PDU SHALL be an ErrorResponse-PDU. The errorStatus field SHALL be set to "missingBase", the errorIndex field SHALL indicate the index of the objectName using the invalid extension format, and the errorVariable SHALL be set to "null" (0.0). 2) Otherwise, while processing a variable binding that uses a RELATIVE-OID, if the requested variable instance (i.e., a non- repeater or any instance of a repeated request) does not have a lexicographic successor accessible by this request which is a sub- node of the base used by the RELATIVE-OID, then the corresponding variable binding produced in the Response-PDU has its value field set to "endOfRange", and its name field set to the variable binding's name in the request. If the endOfRange also corresponds to the endOfMibView, it is implementation dependent which value field is returned. 3) The response PDU may be generated with a lesser number of variable bindings if for some value of iteration i, such that i is greater than zero and less than or equal to M, that all of the generated variable bindings have the value field set to either "endOfRange" or "endOfMibView". In this case, the variable bindings may be truncated after the (N + (i * R))-th variable binding. See K. Vaughn Expires May 24, 2014 [Page 22] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 [RFC3416] for the definition of i, M, N, and R. 4) If the rules of [RFC3416] result in a response PDU with a non-zero error-status field, the response PDU SHALL be an ErrorResponse- PDU, as defined in Clause 5 of this Internet-Draft. If the errorIndex field is non-zero, the errorVariable field of the PDU SHALL be set to the full Object identifier of the requested ObjectName referenced by the errorIndex field; otherwise, the errorVariable field SHALL be set to 'null' (i.e., 0.0). 5) Otherwise, the response PDU SHALL be a GetResponse-PDU, as defined in Clause 5 of this Internet-Draft. 6) If the PDU contains multiple ObjectNames, the implementation may return a value of "processTimeout" for any instance of dynObjectValue. This can be useful to prevent overloading of an agent's processor. 7) Any fields referenced in Clause 4.2.3 of [RFC3416] do not have a parallel construct in the response PDU in Clause 5 of this Internet-Draft shall be ignored. 6.1.1. Trap-PDU The processing of a Trap-PDU SHALL be identical to that as defined in Clause 4.2.6 of [RFC3416]. 6.1.1. InformRequest-PDU The processing of an InformRequest-PDU SHALL be identical to that as defined in Clause 4.2.7 of [RFC3416], with the following exceptions: 1) Otherwise, the response PDU SHALL be a InformResponse-PDU, as defined in Clause 5 of this Internet-Draft. 2) Any fields referenced in Clause 4.2.3 of [RFC3416] do not have a parallel construct in the response PDU in Clause 5 of this Internet-Draft shall be ignored. 6.1.1. GetDynObjX Each of the 13 GetDynObjX types represent a get request for the indicated dynamic object (i.e., GetDynObj1 represents a get request for dynamic object 1). A GetDynObjX PDU is generated and transmitted at the request of an application. Upon receipt of a GetDynObjX PDU, the receiving CNMP entity processes the request as follows: K. Vaughn Expires May 24, 2014 [Page 23] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 1) If the PDU contains any information, the entity SHALL increment the value of snmpInASNParseErrs. The message SHALL be discarded and processing SHALL be complete. 2) Otherwise, if the dynObjectStatus of the indicated dynamic object is not 'active', the entity SHALL produce an ErrorInformation-PDU. The errorStatus field SHALL be set to 'noSuchName' and the errorIndex field SHALL be set to zero (0). 3) Otherwise, if the dynamic object contains a reference to an object in one of its dynObjectVariable values that is not in the current MIB view (i.e., not currently instantiated, not visible, etc.), the entity SHALL produce an ErrorInformation-PDU. The errorStatus field SHALL be set to 'noSuchName' and the errorIndex field SHALL be set to the index of the first dynObjectVariable of the dynamic object that is invalid. 4) Otherwise, if the dynamic object cannot be retrieved for any other reason, the entity SHALL produce an ErrorInformation-PDU. The errorStatus field SHALL be set to 'genErr' and the errorIndex field SHALL be set to the index of the dynObjectVariable that is causing the problem, if known, and zero (0) otherwise. 5) Otherwise, the entity SHALL produce a DynamicObject-PDU containing the value of dynObjectValue.X. 6) The response PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetNextDynObjX. 7) Otherwise, an ErrorRespDynObjX is generated for the subject dynamic object. The value of the errorStatus field SHALL be to "tooBig" and the value of the error-index field SHALL be zero. This ErrorRespDynObj is then encapsulated into a message and transmitted to the originator of the GetDynObjX. 6.1.2. SetDynObjX and SetNoReplyDynObjX Each of the 13 SetDynObjX types and 13 SetNoReplyDynObjX types represent a set request for the indicated dynamic object. These PDU are generated and transmitted at the request of an application. Upon receipt of such a PDU, the receiving CNMP entity processes the request as follows: 1) If the dynObjectStatus of the indicated dynamic object is not 'active', the entity SHALL produce an ErrorInformation-PDU. The K. Vaughn Expires May 24, 2014 [Page 24] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 errorStatus field SHALL be set to 'noSuchName' and the errorIndex field SHALL be set to zero (0). 2) Otherwise, if the dynamic object contains a reference to an object in one of its dynObjectVariable values that is not in the current MIB view (i.e., not currently instantiated, not visible, etc.), the entity SHALL produce an ErrorInformation-PDU. The errorStatus field SHALL be set to 'noSuchName' and the errorIndex field SHALL be set to the index of the first dynObjectVariable of the dynamic object that is invalid. 3) Otherwise, if the dynamic object contains a reference to an an object that is not available for set operations with the current MIB view, the entity SHALL produce an ErrorInformation-PDU. The errorStatus field SHALL be set to 'readOnly' and the errorIndex field SHALL be set to the index of the dynObjectVariable that cannot be set. 4) Otherwise, if any parsing errors occur when decoding the contents of the DynamicObject-PDU, the entity SHALL increment the value of snmpInASNParseErrs and SHALL produce an ErrorInformation-PDU. The errorStatus field SHALL be set to 'badValue' and the errorIndex field SHALL indicate the index of the dynObjectVariable where parsing failed. 5) Otherwise, if any of the objects referenced by the dynamic object cannot be changed for any other reason, the entity SHALL produce an ErrorInformation-PDU. The errorStatus field SHALL be set to 'genErr' and the errorIndex field SHALL indicate the index of the dynObjectVariable causing the problem. 6) Otherwise, for each referenced object in the dynamic object request, the entity SHALL create the object, if necessary, and SHALL assign the requested value to it. Each of these assignments occurs as if simultaneously with respect to all other assignments specified in the same request. a) If any of these assignments fail (even after all the previous validations), then the entity SHALL undo all other assignments and produce an ErrorInformation-PDU. The errorStatus field SHALL be set to 'commitFailed' and the errorIndex field SHALL be set to the index of the dynObjectVariable that cannot be set. b) If it is not possible to undo all the assignments, then the entity SHALL produce an ErrorInformation-PDU; the errorStatus field SHALL be set to 'undoFailed', and the errorIndex field SHALL be set to zero. Note that implementations are strongly K. Vaughn Expires May 24, 2014 [Page 25] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 encouraged to take all possible measures to avoid use of either "commitFailed" or "undoFailed" - these two error-status codes are not to be taken as license to take the easy way out in an implementation. c) Otherwise, the entity SHALL produce a SetRespDynObjX PDU as the response PDU. 7) If the request was a SetNoReplyDynObjX PDU, the processing SHALL be complete and no response is sent. 8) The response PDU is then encapsulated into a message and is transmitted to the originator of the SetDynObjX PDU. 6.1.3. GetNextDynObjX Each of the 13 GetNextDynObjX types represent a get request for the next 'active' dynamic object. A GetNextDynObjX PDU is generated and transmitted at the request of an application. Upon receipt of a GetNextDynObjX PDU, the receiving CNMP entity processes the request as follows: 1) If the PDU contains any information, the entity SHALL increment the value of snmpInASNParseErrs. The message SHALL be discarded and processing SHALL be complete. 2) The dynamic object is located which is the next lexicographical successor of the indicated dynamic object where the dynObjectStatus has a value of 'active'. 3) If there is no lexicographical successor which is a dynamic object with a status of 'active', the entity SHALL produce an ErrorInformation-PDU. The response dynamic object SHALL be the dynamic object contained in the request. The errorStatus field SHALL be set to 'noSuchName' and the errorIndex field SHALL be set to zero (0). 4) If there is no lexicographical successor which is a dynamic object with a status of 'active' that has a dynObjectIndex of 13 or less, the entity SHALL produce an ErrorInformation-PDU. The response dynamic object SHALL be the lexicographical successor dynamic object. The errorStatus field SHALL be set to 'inconsistentValue' and the errorIndex field SHALL be set to zero (0). 5) Otherwise, if the lexicographical successor dynamic object contains a reference to an object in one of its dynObjectVariable values that is not in the current MIB view (i.e., not currently K. Vaughn Expires May 24, 2014 [Page 26] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 instantiated, not visible, etc.), the entity SHALL produce an ErrorInformation-PDU. The response dynamic object SHALL be the lexicographical successor dynamic object. The errorStatus field SHALL be set to 'noSuchName' and the errorIndex field SHALL be set to the index of the first dynObjectVariable of the dynamic object that is invalid. 6) Otherwise, if the lexicographical successor dynamic object cannot be retrieved for any other reason, the entity SHALL produce an ErrorInformation-PDU. The response dynamic object SHALL be the lexicographical successor dynamic object. The errorStatus field SHALL be set to 'genErr' and the errorIndex field SHALL be set to the index of the dynObjectVariable that is causing the problem, if known, and zero (0) otherwise. 7) Otherwise, the entity SHALL produce a DynamicObject-PDU containing the value of dynObjectValue for the lexicographical successor dynamic object. 8) The response PDU is then encapsulated into a message. If the size of the resultant message is less than or equal to both a local constraint and the maximum message size of the originator, it is transmitted to the originator of the GetNextDynObjX. 8) Otherwise, an ErrorRespDynObjX is generated for the subject dynamic object. The value of the errorStatus field SHALL be to "tooBig" and the value of the error-index field SHALL be zero. This ErrorRespDynObj is then encapsulated into a message and transmitted to the originator of the GetNextDynObjX. The entity SHALL send the response PDU to the originator. 6.1.4. GetRespDynObjX, SetRespDynObjX, and ErrorRespDynObjX Each of the 13 GetRespDynObjX types and 13 SetRespDynObjX types represent a response for a dynamic object with the indicated dynamic object index. These PDUs are generated by a CNMP entity according to the rules defined elsewhere in this document. Upon receipt of such a PDU, the receiving CNMP entity presents its contents to the application which generated the most recent request PDU for the indicated dynamic object. 7. Acknowledgements This document is based largely on material contained in [RFC3416] and K. Vaughn Expires May 24, 2014 [Page 27] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 [STMP]. 8. Security Considerations The protocol defined in this document by itself does not provide a secure environment. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed access to management information. It is recommended that the implementors consider the security features as provided by [Msg]. Specifically, the use of the User- based Security Model STD 62, RFC 3414 [RFC3414], the Transport Security Model [RFC5590], and the View-based Access Control Model STD 62, RFC 3415 [RFC3415] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity is properly configured so that: - only those principals (users) having legitimate rights can access or modify the values of any MIB objects supported by that entity; - the occurrence of particular events on the entity will be communicated appropriately; - the entity responds appropriately and with due credence to events and information that have been communicated to it. 9. IANA Considerations IANA needs to assign an OBJECT IDENTIFIER value (TBD1) to the "cnmp" node defined near the top of Clause 4 of this Internet- Draft. This node number must be registered as a part of the "Structure and Identification of Management Information for TCP/IP-based Internets" (SMI) naming tree . It is suggested that the node be placed under the mgmt node (1.3.6.1.2), but we leave the exact location to the discretion of the registrar and the IETF. In order to define the node, the parent node will need to be imported into the module defined in Clause 4. This node number should be the same node number assigned for the variable TBD1 in draft-vaughn-cnmp-message-00. 10. References K. Vaughn Expires May 24, 2014 [Page 28] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 10.1 Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. [RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder, "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. [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network Management Protocol (SNMP) Applications", STD 62, RFC 3413, December 2002. [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", STD 62, RFC 3414, December 2002. [RFC3415] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3415, December 2002. [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations for the Simple Network Management Protocol (SNMP)", STD 62, RFC 3416, December 2002. [RFC5343] Schoenwaelder, J., "Simple Network Management Protocol (SNMP) Context EngineID Discovery", RFC 5343, September 2008. [RFC5590] Harrington, D. and J. Schoenwaelder, "Transport Subsystem for the Simple Network Management Protocol (SNMP)", RFC 5590, June 2009. [Msg] Vaughn, K., "Message Processing for Condensed Network K. Vaughn Expires May 24, 2014 [Page 29] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 Management Protocol (CNMP)", Internet-Draft draft-vaughn- cnmp-message-00, November 2013. [Trans] Vaughn, K., "Transport Mappings for Condensed Network Management Protocol (CNMP)", Internet-Draft draft-vaughn- cnmp-trans-00, November 2013. [OER] "Information Technology - ASN.1 encoding rules: Specification of Octet Encoding Rules (OER)", published by International Telecommunications Union. Initial Draft X.oer, January 2014. 10.2 Informative References [Intro] Vaughn, K., "Document Roadmap for Condensed Network Management Protocol (CNMP)", Internet-Draft draft-vaughn- cnmp-intro-00, November 2013. [STMP] "Transport Management Protocols", published by American Association of State Highway Officials (AASHTO), Institute of Transportation Engineers (ITE), and National Electrical Manufacturers Association (NEMA). NTCIP (National Transportation Communications for ITS Protocol) 1103v02.17, July 2010. Authors' Addresses Kenneth Vaughn Trevilon LLC 6606 FM 1488 RD STE 148-503 Magnolia, TX 77316 USA Phone: +1-571-331-5670 Email: kvaughn@trevilon.com Alessandro Triglia OSS Nokolva, Inc. 1 Executive Drive Suite 450 Somerset, NJ 08873 Email: sandro@oss.com Robert Rausch K. Vaughn Expires May 24, 2014 [Page 30] INTERNET DRAFT Protocol Operations for CNMP November 20, 2013 Transcore, LP 192 Technology Parkway Suite 500 Norcross, GA 30092 Email: robert.rausch@transcore.com K. Vaughn Expires May 24, 2014 [Page 31]