idnits 2.17.1 draft-ietf-sming-snmp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 16 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There are 22 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 519 has weird spacing: '... node org ...' == Line 523 has weird spacing: '... node zero...' == Line 1452 has weird spacing: '... node zero...' == Line 1459 has weird spacing: '... node org ...' == Line 1662 has weird spacing: '...noError see 1...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Scalar objects, which have exactly one object instance and no child nodes. See Section 2.2 for scalar objects' instances. A set of scalar objects is mapped from one or more SMIng classes using the `scalars' statement. The statement block of the `scalars' statement contains one `implements' statement for each class. The associated statement blocks in turn contain `object' statements that specify the mapping of attributes to scalar objects. Scalar objects MUST not have any child node. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Tables, which represent the root node of a collection of information structured in table rows. Table nodes are defined by the `table' statement. A table object identifier SHOULD not have any other child node than the implicitly defined row node (see below). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: o Columnar objects, which belong to a row (that is, the columnar objects' object identifier consists of the row's full object identifier plus a single column-identifying sub-identifier) and have zero or more object instances and no child nodes. They are defined as follows: The classes that are implemented by a `table' statement are identified by `implements' statements. The statement block of each `implements' statement contains `object' statements that specify the mapping of attributes to columnar objects of this table. Columnar objects MUST not have any child node. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: o Notifications, which represent information that is sent by agents within unsolicited transmissions. The `notification' statement is used to map an SMIng event to a notification. A notification's object identifier SHOULD not have any child node. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 20, 2001) is 8317 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'APPLICATION 10' on line 416 -- Looks like a reference, but probably isn't: 'APPLICATION 11' on line 420 -- Looks like a reference, but probably isn't: 'APPLICATION 12' on line 424 -- Looks like a reference, but probably isn't: 'APPLICATION 13' on line 428 -- Looks like a reference, but probably isn't: 'APPLICATION 14' on line 432 == Unused Reference: '4' is defined on line 2133, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2148, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 2152, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2155, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' ** Obsolete normative reference: RFC 2570 (ref. '3') (Obsoleted by RFC 3410) ** Obsolete normative reference: RFC 2571 (ref. '4') (Obsoleted by RFC 3411) ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '10') ** Obsolete normative reference: RFC 2234 (ref. '11') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 1907 (ref. '14') (Obsoleted by RFC 3418) ** Obsolete normative reference: RFC 2629 (ref. '15') (Obsoleted by RFC 7749) == Outdated reference: A later version (-08) exists of draft-ietf-snmpv3-update-proto-06 -- Possible downref: Normative reference to a draft: ref. '16' Summary: 11 errors (**), 0 flaws (~~), 16 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Strauss 3 Internet-Draft J. Schoenwaelder 4 Expires: January 18, 2002 TU Braunschweig 5 July 20, 2001 7 SMIng Mappings to SNMP 8 draft-ietf-sming-snmp-02 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 18, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This memo presents an SMIng language extension that supports the 40 mapping of SMIng definitions of identities, classes, and their 41 attributes and events to dedicated definitions of nodes, scalar 42 objects, tables and columnar objects, and notifications for 43 application in the SNMP management framework. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 48 2. SNMP Based Internet Management . . . . . . . . . . . . . . 5 49 2.1 Kinds of Nodes . . . . . . . . . . . . . . . . . . . . . . 6 50 2.2 Scalar and Columnar Object Instances . . . . . . . . . . . 7 51 2.3 Object Identifier Hierarchy . . . . . . . . . . . . . . . 8 52 3. SMIng Data Type Mappings . . . . . . . . . . . . . . . . . 9 53 3.1 ASN.1 Definitions . . . . . . . . . . . . . . . . . . . . 11 54 4. The snmp Extension Statement . . . . . . . . . . . . . . . 11 55 4.1 The oid Statement . . . . . . . . . . . . . . . . . . . . 12 56 4.2 The node Statement . . . . . . . . . . . . . . . . . . . . 12 57 4.2.1 The node's oid Statement . . . . . . . . . . . . . . . . . 12 58 4.2.2 The node's represents Statement . . . . . . . . . . . . . 12 59 4.2.3 The node's status Statement . . . . . . . . . . . . . . . 12 60 4.2.4 The node's description Statement . . . . . . . . . . . . . 13 61 4.2.5 The node's reference Statement . . . . . . . . . . . . . . 13 62 4.2.6 Usage Examples . . . . . . . . . . . . . . . . . . . . . . 13 63 4.3 The scalars Statement . . . . . . . . . . . . . . . . . . 13 64 4.3.1 The scalars' oid Statement . . . . . . . . . . . . . . . . 13 65 4.3.2 The scalars' implements Statement . . . . . . . . . . . . 14 66 4.3.2.1 The implements' object Statement . . . . . . . . . . . . . 14 67 4.3.3 The scalars' status Statement . . . . . . . . . . . . . . 14 68 4.3.4 The scalars' description Statement . . . . . . . . . . . . 14 69 4.3.5 The scalars' reference Statement . . . . . . . . . . . . . 15 70 4.3.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 15 71 4.4 The table Statement . . . . . . . . . . . . . . . . . . . 15 72 4.4.1 The table's oid Statement . . . . . . . . . . . . . . . . 15 73 4.4.2 Table Indexing Statements . . . . . . . . . . . . . . . . 15 74 4.4.2.1 The table's index Statement for Table Indexing . . . . . . 16 75 4.4.2.2 The table's augments Statement for Table Indexing . . . . 16 76 4.4.2.3 The table's extends Statement for Table Indexing . . . . . 16 77 4.4.2.4 The table's reorders Statement for Table Indexing . . . . 17 78 4.4.2.5 The table's expands Statement for Table Indexing . . . . . 17 79 4.4.3 The table's create Statement . . . . . . . . . . . . . . . 18 80 4.4.4 The table's implements Statement . . . . . . . . . . . . . 18 81 4.4.4.1 The implements' object Statement . . . . . . . . . . . . . 18 82 4.4.5 The table's status Statement . . . . . . . . . . . . . . . 18 83 4.4.6 The table's description Statement . . . . . . . . . . . . 19 84 4.4.7 The table's reference Statement . . . . . . . . . . . . . 19 85 4.4.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . 19 86 4.5 The notification Statement . . . . . . . . . . . . . . . . 19 87 4.5.1 The notification's oid Statement . . . . . . . . . . . . . 20 88 4.5.2 The notification's signals Statement . . . . . . . . . . . 20 89 4.5.2.1 The signals' object Statement . . . . . . . . . . . . . . 20 90 4.5.3 The notification's status Statement . . . . . . . . . . . 20 91 4.5.4 The notification's description Statement . . . . . . . . . 20 92 4.5.5 The notification's reference Statement . . . . . . . . . . 20 93 4.5.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 21 94 4.6 The group Statement . . . . . . . . . . . . . . . . . . . 21 95 4.6.1 The group's oid Statement . . . . . . . . . . . . . . . . 21 96 4.6.2 The group's members Statement . . . . . . . . . . . . . . 21 97 4.6.3 The group's status Statement . . . . . . . . . . . . . . . 22 98 4.6.4 The group's description Statement . . . . . . . . . . . . 22 99 4.6.5 The group's reference Statement . . . . . . . . . . . . . 22 100 4.6.6 Usage Example . . . . . . . . . . . . . . . . . . . . . . 22 101 4.7 The compliance Statement . . . . . . . . . . . . . . . . . 22 102 4.7.1 The compliance's oid Statement . . . . . . . . . . . . . . 23 103 4.7.2 The compliance's status Statement . . . . . . . . . . . . 23 104 4.7.3 The compliance's description Statement . . . . . . . . . . 23 105 4.7.4 The compliance's reference Statement . . . . . . . . . . . 23 106 4.7.5 The compliance's mandatory Statement . . . . . . . . . . . 23 107 4.7.6 The compliance's optional Statement . . . . . . . . . . . 24 108 4.7.6.1 The optional's description Statement . . . . . . . . . . . 24 109 4.7.7 The compliance's refine Statement . . . . . . . . . . . . 24 110 4.7.7.1 The refine's type Statement . . . . . . . . . . . . . . . 24 111 4.7.7.2 The refine's writetype Statement . . . . . . . . . . . . . 25 112 4.7.7.3 The refine's access Statement . . . . . . . . . . . . . . 25 113 4.7.7.4 The refine's description Statement . . . . . . . . . . . . 25 114 4.7.8 Usage Example . . . . . . . . . . . . . . . . . . . . . . 25 115 5. IETF-SMING-SNMP-EXT . . . . . . . . . . . . . . . . . . . 26 116 6. IETF-SMING-SNMP . . . . . . . . . . . . . . . . . . . . . 33 117 7. Security Considerations . . . . . . . . . . . . . . . . . 46 118 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 46 119 References . . . . . . . . . . . . . . . . . . . . . . . . 47 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 48 121 A. SMIng SNMP Mapping ABNF Grammar . . . . . . . . . . . . . 48 122 B. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . 53 123 Full Copyright Statement . . . . . . . . . . . . . . . . . 55 125 1. Introduction 127 This memo presents an SMIng language extension that supports the 128 mapping of SMIng definitions of identities, classes, and their 129 attributes and events to dedicated definitions of nodes, scalar 130 objects, tables and columnar objects, and notifications for 131 application in the SNMP management framework. 133 Section 2 introduces basics of the SNMP management framework. 134 Section 3 defines how SMIng data types are mapped to the data types 135 supported by the SNMP protocol. It introduces some new ASN.1 136 definitions which are used to represent new SMIng base types such as 137 floats in the SNMP protocol via the opaque mapping technique. 139 Section 4 describes the semantics of the SNMP mapping extensions for 140 SMIng. The formal SMIng specification of the extension is provided 141 in Section 5. 143 Section 6 contains an SMIng module which defines data types and 144 classes (such as RowStatus) that are specific to the SNMP mapping. 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [2]. 150 2. SNMP Based Internet Management 152 The SNMP network management framework [3] is based on the model of 153 "managed objects". A managed object represents a class of any real 154 or synthesized variable of systems that are to be managed. Note that 155 in spite of these terms this model is not object-oriented. The 156 managed objects are organized hierarchically in an "object identifier 157 tree", where only leaf nodes may represent objects. 159 Nodes in the object identifier tree may also identify conceptual 160 tables, rows of conceptual tables, notifications, groups of objects 161 and/or notifications, compliance statements, modules or other 162 information. Each node is identified by an unique "object 163 identifier" value which is an ordered list of non-negative numbers, 164 named "sub-identifiers", where the left-most sub-identifier refers to 165 the node next to the root of the tree and the right-most sub- 166 identifier refers to the node that is identified by the complete 167 object identifier. The number of sub-identifiers of an object 168 identifier must not exceed 128. Each sub-identifier has a value 169 between 0 and 2^32-1 (4294967295). 171 The SMIng extensions described in this document are used to map SMIng 172 data definitions to SNMP compliant managed objects. This mapping is 173 done in a way readable to computer programs, named MIB compilers, as 174 well as to human readers. 176 2.1 Kinds of Nodes 178 Each node in the object identifier tree is of a certain kind and may 179 represent management information or not: 181 o Simple nodes, that do not represent management information, but 182 may be used for grouping nodes in a subtree. Those nodes are 183 defined by the `node' statement. This statement can also be used 184 to map an SMIng `identity' to a node. 186 o Nodes representing the identity of a module to allow references to 187 a module in other objects of type `ObjectIdentifier'. Those nodes 188 are defined by the `snmp' statement, 190 o Scalar objects, which have exactly one object instance and no 191 child nodes. See Section 2.2 for scalar objects' instances. A 192 set of scalar objects is mapped from one or more SMIng classes 193 using the `scalars' statement. The statement block of the 194 `scalars' statement contains one `implements' statement for each 195 class. The associated statement blocks in turn contain `object' 196 statements that specify the mapping of attributes to scalar 197 objects. Scalar objects MUST not have any child node. 199 o Tables, which represent the root node of a collection of 200 information structured in table rows. Table nodes are defined by 201 the `table' statement. A table object identifier SHOULD not have 202 any other child node than the implicitly defined row node (see 203 below). 205 o Rows, which belong to a table (that is, row's object identifier 206 consists of the table's full object identifier plus a single `1' 207 sub-identifier) and represent a sequence of one or more columnar 208 objects. A row node is implicitly defined for each table node. 210 o Columnar objects, which belong to a row (that is, the columnar 211 objects' object identifier consists of the row's full object 212 identifier plus a single column-identifying sub-identifier) and 213 have zero or more object instances and no child nodes. They are 214 defined as follows: The classes that are implemented by a `table' 215 statement are identified by `implements' statements. The 216 statement block of each `implements' statement contains `object' 217 statements that specify the mapping of attributes to columnar 218 objects of this table. Columnar objects MUST not have any child 219 node. 221 o Notifications, which represent information that is sent by agents 222 within unsolicited transmissions. The `notification' statement is 223 used to map an SMIng event to a notification. A notification's 224 object identifier SHOULD not have any child node. 226 o Groups of objects and notifications, which may be used for 227 compliance statements. They are defined using the `group' 228 statement. 230 o Compliance statements which define requirements for MIB module 231 implementations. They are defined using the `compliance' 232 statement. 234 2.2 Scalar and Columnar Object Instances 236 Instances of managed objects are identified by appending an instance- 237 identifier to the object's object identifier. Scalar objects and 238 columnar objects use different ways to construct the instance- 239 identifier. 241 Scalar objects have exactly one object instance. It is identified by 242 appending a single `0' sub-identifier to the object identifier of the 243 scalar object. 245 Within tables, different instances of the same columnar object are 246 identified by appending a sequence of one or more sub-identifiers to 247 the object identifier of the columnar object which consists of the 248 values of object instances that unambiguously distinguish a table 249 row. These indexing objects can be columnar objects of the same 250 and/or another table, but MUST NOT be scalar objects. Multiple 251 applications of the same object in a single table indexing 252 specification are strongly discouraged. 254 The base types of the indexing objects indicate how to form the 255 instance-identifier: 257 o integer-valued or enumeration-valued: a single sub-identifier 258 taking the integer value (this works only for non-negative 259 integers and integers of a size of up to 32 bits), 261 o string-valued, fixed-length strings (or variable-length with 262 compact encoding): `n' sub-identifiers, where `n' is the length of 263 the string (each octet of the string is encoded in a separate sub- 264 identifier), 266 o string-valued, variable-length strings or bits-valued: `n+1' sub- 267 identifiers, where `n' is the length of the string or bits 268 encoding (the first sub-identifier is `n' itself, following this, 269 each octet of the string or bits is encoded in a separate sub- 270 identifier), 272 o object identifier-valued (with compact encoding): `n' sub- 273 identifiers, where `n' is the number of sub-identifiers in the 274 value (each sub-identifier of the value is copied into a separate 275 sub-identifier), 277 o object identifier-valued: `n+1' sub-identifiers, where `n' is the 278 number of sub-identifiers in the value (the first sub-identifier 279 is `n' itself, following this, each sub-identifier in the value is 280 copied), 282 Note that compact encoding can only be applied to an object having a 283 variable-length syntax (e.g., variable-length strings, bits objects 284 or object identifier-valued objects). Further, compact encoding can 285 only be associated with the last object in a list of indexing 286 objects. Finally, compact encoding MUST NOT be used on a variable- 287 length string object if that string might have a value of zero- 288 length. 290 Instances identified by use of integer-valued or enumeration-valued 291 objects are RECOMMENDED to be numbered starting from one (i.e., not 292 from zero). Integer objects that allow negative values, Unsigned64 293 objects, Integer64 objects and floating point objects MUST NOT be 294 used for table indexing. 296 Objects which are both specified for indexing in a row and also 297 columnar objects of the same row are termed auxiliary objects. 298 Auxiliary objects SHOULD be non-accessible, except in the following 299 circumstances: 301 o within a module originally written to conform to SMIv1, or 303 o a row must contain at least one columnar object which is not an 304 auxiliary object. In the event that all of a row's columnar 305 objects are also specified to be indexing objects then one of them 306 MUST be accessible. 308 2.3 Object Identifier Hierarchy 310 The layers of the object identifier tree near the root are well 311 defined and organized by standardization bodies. The first level 312 next to the root has three nodes: 314 0: ccitt 315 1: iso 317 2: joint-iso-ccitt 319 Note that the renaming of the Commite Consultatif International de 320 Telegraphique et Telephonique (CCITT) to International 321 Telecommunications Union (ITU) had no consequence on the names used 322 in the object identifier tree. 324 The root of the subtree administered by the Internet Assigned Numbers 325 Authority (IANA) for the Internet is `1.3.6.1' which is assigned with 326 the identifier `internet'. That is, the Internet subtree of object 327 identifiers starts with the prefix `1.3.6.1.'. 329 Several branches underneath this subtree are used for network 330 management: 332 The `mgmt' (internet.2) subtree is used to identify "standard" 333 definitions. An information module produced by an IETF working group 334 becomes a "standard" information module when the document is first 335 approved by the IESG and enters the Internet standards track. 337 The `experimental' (internet.3) subtree is used to identify 338 experimental definitions being designed by working groups of the IETF 339 or IRTF. If an information module produced by a working group 340 becomes a "standard" module, then at the very beginning of its entry 341 onto the Internet standards track, the definitions are moved under 342 the mgmt subtree. 344 The `private' (internet.4) subtree is used to identify definitions 345 defined unilaterally. The `enterprises' (private.1) subtree beneath 346 private is used, among other things, to permit providers of 347 networking subsystems to register information modules of their 348 products. 350 These and some other nodes are defined in the SMIng standard module 351 IETF-SMING-SNMP-EXT (Section 5). 353 3. SMIng Data Type Mappings 355 SMIng [1] supports the following set of base types: OctetString, 356 Identity, Integer32, Integer64, Unsigned32, Unsigned64, Float32, 357 Float64, Float128, Enumeration, and Bits. The SMIng core module 358 IETF-SMING [1] defines additional derived data types, among them 359 Counter32 (derived from Unsigned32), Counter64 (derived from 360 Unsigned64), TimeTicks (derived from Unsigned32), IpAddress (derived 361 from OctetString), and Opaque (derived from OctetString). 363 The version 2 of the protocol operations for SNMP document [16] 364 defines the following 9 data types which are distinguished by the 365 protocol: INTEGER, OCTET STRING, OBJECT IDENTIFIER, IpAddress, 366 Counter32, TimeTicks, Opaque, Counter64, Unsigned32. 368 The SMIng data types and their derived types are mapped to SNMP data 369 types according to the following table: 371 SMIng Data Type SNMP Data Type Comment 372 --------------- ------------------- ------- 373 OctetString OCTET STRING (1) 374 Identity OBJECT IDENTIFIER 375 Integer32 INTEGER 376 Integer64 Opaque (Integer64) (2) 377 Unsigned32 Unsigned32 (3) 378 Unsigned64 Opaque (Unsigned64) (2) (4) 379 Float32 Opaque (Float32) (2) 380 Float64 Opaque (Float64) (2) 381 Float128 Opaque (Float128) (2) 382 Enumeration INTEGER 383 Bits OCTET STRING 385 Counter32 Counter32 386 Counter64 Counter64 387 TimeTicks TimeTicks 388 IpAddress IpAddress 389 Opaque Opaque 391 (1) This mapping includes all types derived from the OctetString type 392 except those types derived from the IpAddress and Opaque SMIng 393 type defined in [1]. 395 (2) This type is encoded according to the ASN.1 type with the same 396 name defined in Section 3.1. The resulting BER encoded value is 397 then wrapped in an Opaque value. 399 (3) This mapping includes all types derived from the Unsigned32 type 400 except those types derived from the Counter32 and TimeTicks SMIng 401 type defined in [1]. 403 (4) This mapping includes all types derived from the Unsigned64 type 404 except those types derived from the Counter64 SMIng type defined 405 in [1]. 407 3.1 ASN.1 Definitions 409 The ASN.1 [12] type definitions below introduce data types which are 410 used to new SMIng base types into the set of ASN.1 types supported by 411 the second version of SNMP protocol operations [16]. 413 IETF-SMING-SNMP-MAPPING DEFINITIONS ::= BEGIN 415 Integer64 ::= 416 [APPLICATION 10] 417 IMPLICIT INTEGER (-9223372036854775808..9223372036854775807) 419 Unsigned64 420 [APPLICATION 11] 421 IMPLICIT INTEGER (0..18446744073709551615) 423 Float32 424 [APPLICATION 12] 425 IMPLICIT OCTET STRING (SIZE (4)) 427 Float64 428 [APPLICATION 13] 429 IMPLICIT OCTET STRING (SIZE (8)) 431 Float128 432 [APPLICATION 14] 433 IMPLICIT OCTET STRING (SIZE (16)) 435 END 437 The definitions of Integer64 and Unsigned64 are consistent with the 438 same definitions in the SPPI. The floating point types Float32, 439 Float64 and Float128 support single, double and quadruple IEEE 440 floating point values. The encoding of the values follows the "IEEE 441 Standard for Binary Floating-Point Arithmetic" as defined in 442 ANSI/IEEE Standard 754-1985 [13]. 444 4. The snmp Extension Statement 446 The `snmp' statement is the main statement of the SNMP mapping 447 specification. It gets one or two arguments: an optional lower-case 448 identifier that can specifies a node that represents the module's 449 identity, and a mandatory statement block that contains all details 450 of the SNMP mapping. All information of an SNMP mapping are mapped 451 to an SNMP conformant module of the same name as the containing SMIng 452 module. A single SMIng module must not contain more than one `snmp' 453 statement. 455 4.1 The oid Statement 457 The snmp's `oid' statement, which must be present, if the snmp 458 statement contains a module identifier and must be absent otherwise, 459 gets one argument which specifies the object identifier value that is 460 assigned to this module's identity node. 462 4.2 The node Statement 464 The `node' statement is used to name and describe a node in the 465 object identifier tree, without associating any class or attribute 466 information with this node. This may be useful to group definitions 467 in a subtree of related management information, or to uniquely define 468 an SMIng `identity' to be referenced in attributes of type Identity. 469 The `node' statement gets two arguments: a lower-case node identifier 470 and a statement block that holds detailed node information in an 471 obligatory order. 473 See the `nodeStatement' rule of the SMIng grammar (Section 5) for the 474 formal syntax of the `node' statement. 476 4.2.1 The node's oid Statement 478 The node's `oid' statement, which must be present, gets one argument 479 which specifies the object identifier value that is assigned to this 480 node. 482 4.2.2 The node's represents Statement 484 The node's `represents' statement, which need not be present, makes 485 this node represent an SMIng identity, so that objects of type 486 Identity can reference that identity. The statement gets one 487 argument which specifies the identity name. 489 4.2.3 The node's status Statement 491 The node's `status' statement, which must be present, gets one 492 argument which is used to specify whether this node definition is 493 current or historic. The value `current' means that the definition 494 is current and valid. The value `obsolete' means the definition is 495 obsolete and should not be implemented and/or can be removed if 496 previously implemented. While the value `deprecated' also indicates 497 an obsolete definition, it permits new/continued implementation in 498 order to foster interoperability with older/existing implementations. 500 4.2.4 The node's description Statement 502 The node's `description' statement, which need not be present, gets 503 one argument which is used to specify a high-level textual 504 description of this node. 506 It is RECOMMENDED to include all semantics and purposes of this node. 508 4.2.5 The node's reference Statement 510 The node's `reference' statement, which need not be present, gets one 511 argument which is used to specify a textual cross-reference to some 512 other document, either another module which defines related 513 definitions, or some other document which provides additional 514 information relevant to this node. 516 4.2.6 Usage Examples 518 node iso { oid 1; status current; }; 519 node org { oid iso.3; status current; }; 520 node dod { oid org.6; status current; }; 521 node internet { oid dod.1; status current; }; 523 node zeroDotZero { 524 oid 0.0; 525 represents IETF-SMING::null; 526 status current; 527 description "A value used for null identifiers."; 528 }; 530 4.3 The scalars Statement 532 The `scalars' statement is used to define the mapping of one or more 533 classes to a group of SNMP scalar managed objects organized under a 534 common parent node. The `scalars' statement gets two arguments: a 535 lower-case scalar group identifier and a statement block that holds 536 detailed mapping information of this scalar group in an obligatory 537 order. 539 See the `scalarsStatement' rule of the SMIng grammar (Section 5) for 540 the formal syntax of the `scalars' statement. 542 4.3.1 The scalars' oid Statement 544 The scalars' `oid' statement, which must be present, gets one 545 argument which specifies the object identifier value that is assigned 546 to the common parent node of this scalar group. 548 4.3.2 The scalars' implements Statement 550 The scalars' `implements' statement, which must be present at least 551 once, makes this scalar group contain scalar objects that are defined 552 by a given class. It gets two arguments: the class being implemented 553 and a statement block that holds detailed information on the 554 attributes of that class being implemented in an obligatory order. 556 Note: It is possible to apply multiple implements statements to a 557 single scalars statement, each specifying a distinct class. However, 558 it is considerable to define a new class containing thoses classes 559 and making the scalar group implement that single container class. 561 4.3.2.1 The implements' object Statement 563 The `object' statement, which must be present at least once, makes a 564 single attribute of the class being contained as a scalar object in 565 the scalar group. It gets two arguments: the scalar object name and 566 the class attribute being implemented. 568 The object identifier of this scalar object is implicitly specified 569 by concatenating the scalar group's object identifier and the 570 position of the object, starting at 1. [XXX see open issues: we 571 better use mandatory explicit OID mapping.] 573 4.3.3 The scalars' status Statement 575 The scalars' `status' statement, which must be present, gets one 576 argument which is used to specify whether this scalar group 577 definition is current or historic. The value `current' means that 578 the definition is current and valid. The value `obsolete' means the 579 definition is obsolete and should not be implemented and/or can be 580 removed if previously implemented. While the value `deprecated' also 581 indicates an obsolete definition, it permits new/continued 582 implementation in order to foster interoperability with 583 older/existing implementations. 585 Scalar groups SHOULD NOT be defined as `current' if one or more of 586 their classes are `deprecated' or `obsolete'. Similarly, they SHOULD 587 NOT be defined as `deprecated' if one or more of their classes are 588 `obsolete'. Nevertheless, subsequent revisions of used class 589 definition cannot be avoided, but SHOULD be taken into account in 590 subsequent revisions of the local module. 592 4.3.4 The scalars' description Statement 594 The scalars' `description' statement, which must be present, gets one 595 argument which is used to specify a high-level textual description of 596 this scalar group. 598 It is RECOMMENDED to include all semantic definitions necessary for 599 the implementation of this scalar group. 601 4.3.5 The scalars' reference Statement 603 The scalars' `reference' statement, which need not be present, gets 604 one argument which is used to specify a textual cross-reference to 605 some other document, either another module which defines related 606 definitions, or some other document which provides additional 607 information relevant to this scalars statement. 609 4.3.6 Usage Example 611 scalars ip { 612 oid mib-2.4; 613 implements Ip { 614 object ipForwarding forwarding; 615 object ipDefaultTTL defaultTTL; 616 // ... 617 } 618 status current; 619 description 620 "This scalar group implements the Ip class."; 621 }; 623 4.4 The table Statement 625 The `table' statement is used to define the mapping of one or more 626 classes to a single SNMP table of columnar managed objects. The 627 `table' statement gets two arguments: a lower-case table identifier 628 and a statement block that holds detailed mapping information of this 629 table in an obligatory order. 631 See the `tableStatement' rule of the SMIng grammar (Section 5) for 632 the formal syntax of the `table' statement. 634 4.4.1 The table's oid Statement 636 The table's `oid' statement, which must be present, gets one argument 637 which specifies the object identifier value that is assigned to this 638 table's node. 640 4.4.2 Table Indexing Statements 642 SNMP table mappings offers five methods to supply table indexing 643 information: ordinary tables, table augmentations, sparse table 644 augmentations, table expansions, and reordered tables use different 645 statements to denote their indexing information. Each table 646 definition must contain exactly one of the following indexing 647 statements. 649 4.4.2.1 The table's index Statement for Table Indexing 651 The table's `index' statement, which is used to supply table indexing 652 information of base tables, gets one argument that specifies a comma- 653 separated list of objects, that are used for table indexing, enclosed 654 in parenthesis. 656 The elements of the `unique' statement of the implemented class(es) 657 (see Section 4.4.4) and their order should be regarded as a hint for 658 the index elements of the table. 660 Under some circumstances, an optional `implied' keyword may be added 661 in front of the list to indicate a compact encoding of the last 662 object in the list. See Section 2.2 for details. 664 4.4.2.2 The table's augments Statement for Table Indexing 666 The table's `augments' statement, which is used to supply table 667 indexing information of tables that augment a base table, gets one 668 argument that specifies the identifier of the table to be augmented. 669 Note that a table augmentation cannot itself be augmented. Anyhow, a 670 base table may be augmented by multiple table augmentations. 672 A table augmentation makes instances of subordinate columnar objects 673 identified according to the index specification of the base table 674 corresponding to the table named in the `augments' statement. 675 Further, instances of subordinate columnar objects of a table 676 augmentation exist according to the same semantics as instances of 677 subordinate columnar objects of the base table being augmented. As 678 such, note that creation of a base table row implies the 679 correspondent creation of any table row augmentations. Table 680 augmentations MUST NOT be used in table row creation and deletion 681 operations. 683 4.4.2.3 The table's extends Statement for Table Indexing 685 The table's `extends' statement, which is used to supply table 686 indexing information of tables that sparsely augment a base table, 687 gets one argument that specifies the identifier of the table to be 688 sparsely augmented. Note that a sparse table augmentation cannot 689 itself be augmented. Anyhow, a base table may be augmented by 690 multiple table augmentations, sparsely or not. 692 A sparse table augmentation makes instances of subordinate columnar 693 objects identified, if present, according to the index specification 694 of the base table corresponding to the table named in the `extends' 695 statement. Further, instances of subordinate columnar objects of a 696 sparse table augmentation exist according to the semantics as 697 instances of subordinate columnar objects of the base table and the 698 (non-formal) rules that confine the sparse relationship. As such, 699 note that creation of a sparse table row augmentation may be implied 700 by the creation of a base table row as well as done by an explicit 701 creation. However, if a base table row gets deleted, any dependent 702 sparse table row augmentations get also deleted implicitly. 704 4.4.2.4 The table's reorders Statement for Table Indexing 706 The table's `reorders' statement is used to supply table indexing 707 information of tables, that contain exactly the same index objects of 708 a base table, except in another order. It gets at least two 709 arguments. The first one specifies the identifier of the base table. 710 The second one specifies a comma-separated list of exactly those 711 object identifiers of the base table's `index' statement, but in the 712 order to be used in this table. Note that a reordered table cannot 713 itself be reordered. Anyhow, a base table may be used for multiple 714 reordered tables. 716 Under some circumstances, an optional `implied' keyword may be added 717 in front of the list to indicate a compact encoding of the last 718 object in the list. See Section 2.2 for details. 720 Instances of subordinate columnar objects of a reordered table exist 721 according to the same semantics as instances of subordinate columnar 722 objects of the base table. As such, note that creation of a base 723 table row implies the correspondent creation of any related reordered 724 table row. Reordered tables MUST NOT be used in table row creation 725 and deletion operations. 727 4.4.2.5 The table's expands Statement for Table Indexing 729 The table's `expands' statement is used to supply table indexing 730 information of table expansions. Table expansions use exactly the 731 same index objects of another table together with additional indexing 732 objects. Thus, the `expands' statement gets at least two arguments. 733 The first one specifies the identifier of the related table. The 734 second one specifies a comma-separated list of the additional object 735 identifiers used for indexing. Note that an expanded table may 736 itself be expanded, and related tables may be used for multiple table 737 expansions. 739 Under some circumstances, an optional `implied' keyword may be added 740 in front of the list to indicate a compact encoding of the last 741 object in the list. See Section 2.2 for details. 743 4.4.3 The table's create Statement 745 The table's `create' statement, which need not be present, gets no 746 argument. If the `create' statement is present, table row creation 747 (and deletion) is possible. 749 4.4.4 The table's implements Statement 751 The table's `implements' statement, which must be present at least 752 once, makes this table contain columnar objects that are defined by a 753 given class. It gets two arguments: the class being implemented and 754 a statement block that holds detailed information on the attributes 755 of that class being implemented in an obligatory order. 757 Note: It is possible to apply multiple implements statements to a 758 single table statement, each specifying a distinct class. However, 759 it is considerable to define a new class containing thoses classes 760 and making the table implement that single container class. 762 4.4.4.1 The implements' object Statement 764 The `object' statement, which must be present at least once, makes a 765 single attribute of the class being contained as a columnar object in 766 the table. It gets two arguments: the columnar object name and the 767 class attribute being implemented. 769 The object identifier of this columnar object is implicitly specified 770 by concatenating the table's object identifier, a single sub- 771 identifier of the value 1 (in SMIv2 this represents the table entry 772 definition) and the position of the object, starting at 1. [XXX see 773 open issues: we better use mandatory explicit OID mapping.] 775 4.4.5 The table's status Statement 777 The table's `status' statement, which must be present, gets one 778 argument which is used to specify whether this table definition is 779 current or historic. The value `current' means that the definition 780 is current and valid. The value `obsolete' means the definition is 781 obsolete and should not be implemented and/or can be removed if 782 previously implemented. While the value `deprecated' also indicates 783 an obsolete definition, it permits new/continued implementation in 784 order to foster interoperability with older/existing implementations. 786 Tables SHOULD NOT be defined as `current' if one or more of their 787 classes are `deprecated' or `obsolete'. Similarly, they SHOULD NOT 788 be defined as `deprecated' if one or more of their classes are 789 `obsolete'. Nevertheless, subsequent revisions of used class 790 definition cannot be avoided, but SHOULD be taken into account in 791 subsequent revisions of the local module. 793 4.4.6 The table's description Statement 795 The table's `description' statement, which must be present, gets one 796 argument which is used to specify a high-level textual description of 797 this table. 799 It is RECOMMENDED to include all semantic definitions necessary for 800 the implementation of this scalar group. 802 4.4.7 The table's reference Statement 804 The table's `reference' statement, which need not be present, gets 805 one argument which is used to specify a textual cross-reference to 806 some other document, either another module which defines related 807 definitions, or some other document which provides additional 808 information relevant to this table statement. 810 4.4.8 Usage Example 812 table ifTable { 813 oid interfaces.2; 814 index (ifIndex); 815 implements Interface { 816 object ifIndex index; 817 object ifDescr description; 818 // ... 819 } 820 status current; 821 description 822 "This table implements the Interface class."; 823 }; 825 4.5 The notification Statement 827 The `notification' statement is used to map events of classes to SNMP 828 notifications. The statement gets two arguments: a lower-case 829 notification identifier and a statement block that holds detailed 830 notification information in an obligatory order. 832 See the `notificationStatement' rule of the SMIng grammar (Section 5) 833 for the formal syntax of the `notification' statement. 835 4.5.1 The notification's oid Statement 837 The notification's `oid' statement, which must be present, gets one 838 argument which specifies the object identifier value that is assigned 839 to this notification. 841 4.5.2 The notification's signals Statement 843 The notification's `signals' statement, which must be present, 844 denotes the event that is signaled by this notification. The 845 statement gets two argument: the event to be signaled (in the 846 qualifed form `Class.event') and a statement block that holds 847 detailed information on the objects transmitted with this 848 notification in an obligatory order. 850 4.5.2.1 The signals' object Statement 852 The signals' `object' statement, which can be present zero, one or 853 multiple times, makes a single instance of a class attribute be 854 contained in this notification. It gets one argument: the specific 855 class attribute. The namespace of attributes not specified by 856 qualified names is the namespace of the event's class specified in 857 the `signals' statement. 859 4.5.3 The notification's status Statement 861 The notification's `status' statement, which must be present, gets 862 one argument which is used to specify whether this notification 863 definition is current or historic. The value `current' means that 864 the definition is current and valid. The value `obsolete' means the 865 definition is obsolete and should not be implemented and/or can be 866 removed if previously implemented. While the value `deprecated' also 867 indicates an obsolete definition, it permits new/continued 868 implementation in order to foster interoperability with 869 older/existing implementations. 871 4.5.4 The notification's description Statement 873 The notification's `description' statement, which need not be 874 present, gets one argument which is used to specify a high-level 875 textual description of this notification. 877 It is RECOMMENDED to include all semantics and purposes of this 878 notification. 880 4.5.5 The notification's reference Statement 882 The notification's `reference' statement, which need not be present, 883 gets one argument which is used to specify a textual cross-reference 884 to some other document, either another module which defines related 885 definitions, or some other document which provides additional 886 information relevant to this notification statement. 888 4.5.6 Usage Example 890 notification linkDown { 891 oid snmpTraps.3; 892 signals Interface.linkDown { 893 object ifIndex; 894 object ifAdminStatus; 895 object ifOperStatus; 896 }; 897 status current; 898 description 899 "This notification signals the linkDown event 900 of the Interface class."; 901 }; 903 4.6 The group Statement 905 The `group' statement is used to define a group of arbitrary nodes in 906 the object identifier tree. It gets two arguments: a lower-case 907 group identifier and a statement block that holds detailed group 908 information in an obligatory order. 910 Note that the primary application of groups are compliance 911 statements, although they might be referred in other formal or 912 informal documents. 914 See the `groupStatement' rule of the SMIng grammar (Section 5) for 915 the formal syntax of the `group' statement. 917 4.6.1 The group's oid Statement 919 The group's `oid' statement, which must be present, gets one argument 920 which specifies the object identifier value that is assigned to this 921 group. 923 4.6.2 The group's members Statement 925 The group's `members' statement, which must be present, gets one 926 argument which specifies the list of nodes by their identifiers to be 927 contained in this group. The list of nodes has to be comma-separated 928 and enclosed in parenthesis. 930 4.6.3 The group's status Statement 932 The group's `status' statement, which must be present, gets one 933 argument which is used to specify whether this group definition is 934 current or historic. The value `current' means that the definition 935 is current and valid. The value `obsolete' means the definition is 936 obsolete and the group should no longer be used. While the value 937 `deprecated' also indicates an obsolete definition, it permits 938 new/continued use of this group. 940 4.6.4 The group's description Statement 942 The group's `description' statement, which must be present, gets one 943 argument which is used to specify a high-level textual description of 944 this group. It is RECOMMENDED to include any relation to other 945 groups. 947 4.6.5 The group's reference Statement 949 The group's `reference' statement, which need not be present, gets 950 one argument which is used to specify a textual cross-reference to 951 some other document, either another module which defines related 952 groups, or some other document which provides additional information 953 relevant to this group. 955 4.6.6 Usage Example 957 The snmpGroup, originally defined in [14], may be described as 958 follows: 960 group snmpGroup { 961 oid snmpMIBGroups.8; 962 objects (snmpInPkts, snmpInBadVersions, 963 snmpInASNParseErrs, 964 snmpSilentDrops, snmpProxyDrops, 965 snmpEnableAuthenTraps); 966 status current; 967 description 968 "A collection of objects providing basic 969 instrumentation and control of an agent."; 970 }; 972 4.7 The compliance Statement 974 The `compliance' statement is used to define a set of compliance 975 requirements, named a `compliance statement'. It gets two arguments: 976 a lower-case compliance identifier and a statement block that holds 977 detailed compliance information in an obligatory order. 979 See the `complianceStatement' rule of the SMIng grammar (Section 5) 980 for the formal syntax of the `compliance' statement. 982 4.7.1 The compliance's oid Statement 984 The compliance's `oid' statement, which must be present, gets one 985 argument which specifies the object identifier value that is assigned 986 to this compliance statement. 988 4.7.2 The compliance's status Statement 990 The compliance's `status' statement, which must be present, gets one 991 argument which is used to specify whether this compliance statement 992 is current or historic. The value `current' means that the 993 definition is current and valid. The value `obsolete' means the 994 definition is obsolete and no longer specifies a valid definition of 995 conformance. While the value `deprecated' also indicates an obsolete 996 definition, it permits new/continued use of the compliance 997 specification. 999 4.7.3 The compliance's description Statement 1001 The compliance's `description' statement, which must be present, gets 1002 one argument which is used to specify a high-level textual 1003 description of this compliance statement. 1005 4.7.4 The compliance's reference Statement 1007 The compliance's `reference' statement, which need not be present, 1008 gets one argument which is used to specify a textual cross-reference 1009 to some other document, either another module which defines related 1010 compliance statements, or some other document which provides 1011 additional information relevant to this compliance statement. 1013 4.7.5 The compliance's mandatory Statement 1015 The compliance's `mandatory' statement, which need not be present, 1016 gets one argument which is used to specify a comma-separated list of 1017 one or more groups (Section 4.6) of objects and/or notifications 1018 enclosed in parenthesis. These groups are unconditionally mandatory 1019 for implementation. 1021 If an agent claims compliance to a MIB module then it must implement 1022 each and every object and notification within each group listed the 1023 `mandatory' statement(s) of the compliance statement(s) of that 1024 module. 1026 4.7.6 The compliance's optional Statement 1028 The compliance's `optional' statement, which need not be present, is 1029 repeatedly used to name each group which is conditionally mandatory 1030 for compliance to the module. It can also be used to name 1031 unconditionally optional groups. A group named in an `optional' 1032 statement MUST be absent from the correspondent `mandatory' 1033 statement. The `optional' statement gets two arguments: a lower-case 1034 group identifier and a statement block that holds detailed compliance 1035 information on that group. 1037 Conditionally mandatory groups include those which are mandatory only 1038 if a particular protocol is implemented, or only if another group is 1039 implemented. The `description' statement specifies the conditions 1040 under which the group is conditionally mandatory. 1042 A group which is named in neither a `mandatory' statement nor an 1043 `optional' statement, is unconditionally optional for compliance to 1044 the module. 1046 See the `optionalStatement' rule of the SMIng grammar (Section 5) for 1047 the formal syntax of the `optional' statement. 1049 4.7.6.1 The optional's description Statement 1051 The optional's `description' statement, which must be present, gets 1052 one argument which is used to specify a high-level textual 1053 description of the conditions under which this group is conditionally 1054 mandatory or unconditionally optional. 1056 4.7.7 The compliance's refine Statement 1058 The compliance's `refine' statement, which need not be present, is 1059 repeatedly used to specify each object for which compliance has a 1060 refined requirement with respect to the module definition. The 1061 object must be present in one of the conformance groups named in the 1062 correspondent `mandatory' or `optional' statements. The `refine' 1063 statement gets two arguments: a lower-case identifier of a scalar or 1064 columnar object and a statement block that holds detailed refinement 1065 information on that object. 1067 See the `refineStatement' rule of the SMIng grammar (Section 5) for 1068 the formal syntax of the `refine' statement. 1070 4.7.7.1 The refine's type Statement 1072 The refine's `type' statement, which need not be present, gets one 1073 argument that is used to provide a refined type for the correspondent 1074 object. Type restrictions may be applied by appending subtyping 1075 information according to the rules of the base type. See [1] for 1076 SMIng base types and their type restrictions. In case of enumeration 1077 or bitset types the order of named numbers is not significant. 1079 Note that if a `type' and a `writetype' statement are both present 1080 then this type only applies when instances of the correspondent 1081 object are read. 1083 4.7.7.2 The refine's writetype Statement 1085 The refine's `writetype' statement, which need not be present, gets 1086 one argument that is used to provide a refined type for the 1087 correspondent object, only when instances of that object are written. 1088 Type restrictions may be applied by appending subtyping information 1089 according to the rules of the base type. See [1] for SMIng base 1090 types and their type restrictions. In case of enumeration or bitset 1091 types the order of named numbers is not significant. 1093 4.7.7.3 The refine's access Statement 1095 The refine's `access' statement, which need not be present, gets one 1096 argument that is used to specify the minimal level of access that the 1097 correspondent object must implement in the sense of its original 1098 `access' statement. Hence, the refine's `access' statement MUST NOT 1099 specify a greater level of access than is specified in the 1100 correspondent object definition. 1102 An implementation is compliant if the level of access it provides is 1103 greater or equal to the minimal level in the refine's `access' 1104 statement and less or equal to the maximal level in the object's 1105 `access' statement. 1107 4.7.7.4 The refine's description Statement 1109 The refine's `description' statement, which must be present, gets one 1110 argument which is used to specify a high-level textual description of 1111 the refined compliance requirement. 1113 4.7.8 Usage Example 1115 The compliance statement contained in the SNMPv2-MIB, converted to 1116 SMIng: 1118 compliance snmpBasicCompliance { 1119 oid snmpMIBCompliances.2; 1120 status current; 1121 description 1122 "The compliance statement for SNMPv2 entities which 1123 implement the SNMPv2 MIB."; 1125 mandatory (snmpGroup, snmpSetGroup, systemGroup, 1126 snmpBasicNotificationsGroup); 1128 optional snmpCommunityGroup { 1129 description 1130 "This group is mandatory for SNMPv2 entities which 1131 support community-based authentication."; 1132 }; 1133 }; 1135 5. IETF-SMING-SNMP-EXT 1137 The grammar of the SNMP mapping SMIng extension conforms to the 1138 Augmented Backus-Naur Form (ABNF) [11]. It is included in the abnf 1139 statement of the snmp SMIng extension definition in the IETF-SMING- 1140 SNMP-EXT module below. 1142 module IETF-SMING-SNMP-EXT { 1144 organization "IETF Next Generation Structure of 1145 Management Information Working Group (SMING)"; 1147 contact "Frank Strauss 1149 TU Braunschweig 1150 Bueltenweg 74/75 1151 38106 Braunschweig 1152 Germany 1154 Phone: +49 531 391-3266 1155 EMail: strauss@ibr.cs.tu-bs.de"; 1157 description "This module defines a SMIng extension to define 1158 the mapping of SMIng definitions of class and 1159 their attributes and events to SNMP compatible 1160 definitions of modules, node, scalars, tables, 1161 and notifications, and additional information on 1162 module compliances."; 1164 revision { 1165 date "2001-03-02"; 1166 description "Initial revision, published as RFC &rfc.number;."; 1167 }; 1169 // 1170 // 1171 // 1173 extension snmp { 1175 description 1176 "The snmp statement maps SMIng definitions to SNMP 1177 conformant definitions."; 1178 abnf " 1179 ;; 1180 ;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF 1181 ;; notation (RFC 2234). 1182 ;; 1183 ;; @(#) $Id: sming-snmp.abnf,v 1.8 2001/03/07 15:06:56 strauss Exp $ 1184 ;; 1185 ;; Copyright (C) The Internet Society (2001). All Rights Reserved. 1186 ;; 1188 ;; 1189 ;; Statement rules. 1190 ;; 1192 snmpStatement = snmpKeyword *1(sep lcIdentifier) optsep 1193 '{' stmtsep 1194 *1(oidStatement stmtsep) 1195 *(nodeStatement stmtsep) 1196 *(scalarsStatement stmtsep) 1197 *(tableStatement stmtsep) 1198 *(notificationStatement stmtsep) 1199 *(groupStatement stmtsep) 1200 *(complianceStatement stmtsep) 1201 *1(statusStatement stmtsep) 1202 descriptionStatement stmtsep 1203 *1(referenceStatement stmtsep) 1204 '}' optsep ';' 1206 nodeStatement = nodeKeyword sep lcIdentifier optsep 1207 '{' stmtsep 1208 oidStatement stmtsep 1209 *1(representsStatement stmtsep) 1210 *1(statusStatement stmtsep) 1211 *1(descriptionStatement stmtsep) 1212 *1(referenceStatement stmtsep) 1213 '}' optsep ';' 1215 representsStatement = representsKeyword sep 1216 qucIdentifier optsep ';' 1218 scalarsStatement = scalarsKeyword sep lcIdentifier optsep 1219 '{' stmtsep 1220 oidStatement stmtsep 1221 1*(implementsStatement stmtsep) 1222 *1(statusStatement stmtsep) 1223 descriptionStatement stmtsep 1224 *1(referenceStatement stmtsep) 1225 '}' optsep ';' 1227 tableStatement = tableKeyword sep lcIdentifier optsep 1228 '{' stmtsep 1229 oidStatement stmtsep 1230 anyIndexStatement stmtsep 1231 *1(createStatement stmtsep) 1232 1*(implementsStatement stmtsep) 1233 *1(statusStatement stmtsep) 1234 descriptionStatement stmtsep 1235 *1(referenceStatement stmtsep) 1236 '}' optsep ';' 1238 implementsStatement = implementsKeyword sep qucIdentifier optsep 1239 '{' stmtsep 1240 1*(implObjectStatement stmtsep) 1241 '}' optsep ';' 1243 implObjectStatement = objectKeyword sep 1244 lcIdentifier sep 1245 attrIdentifier optsep; 1247 notificationStatement = notificationKeyword sep lcIdentifier 1248 optsep '{' stmtsep 1249 oidStatement stmtsep 1250 signalsStatement stmtsep 1251 *1(statusStatement stmtsep) 1252 descriptionStatement stmtsep 1253 *1(referenceStatement stmtsep) 1254 '}' optsep ';' 1256 signalsStatement = signalsKeyword sep qattrIdentifier 1257 optsep '{' stmtsep 1258 *(signalsObjectStatement) 1259 '}' optsep ';' 1261 signalsObjectStatement = objectKeyword sep 1262 qattrIdentifier optsep ';' 1263 groupStatement = groupKeyword sep lcIdentifier optsep 1264 '{' stmtsep 1265 oidStatement stmtsep 1266 membersStatement stmtsep 1267 *1(statusStatement stmtsep) 1268 descriptionStatement stmtsep 1269 *1(referenceStatement stmtsep) 1270 '}' optsep ';' 1272 complianceStatement = complianceKeyword sep lcIdentifier optsep 1273 '{' stmtsep 1274 oidStatement stmtsep 1275 *1(statusStatement stmtsep) 1276 descriptionStatement stmtsep 1277 *1(referenceStatement stmtsep) 1278 *1(mandatoryStatement stmtsep) 1279 *(optionalStatement stmtsep) 1280 *(refineStatement stmtsep) 1281 '}' optsep ';' 1283 anyIndexStatement = indexStatement / 1284 augmentsStatement / 1285 reordersStatement / 1286 extendsStatement / 1287 expandsStatement 1289 indexStatement = indexKeyword *1(sep impliedKeyword) optsep 1290 '(' optsep qlcIdentifierList 1291 optsep ')' optsep ';' 1293 augmentsStatement = augmentsKeyword sep qlcIdentifier 1294 optsep ';' 1296 reordersStatement = reordersKeyword sep qlcIdentifier 1297 *1(sep impliedKeyword) 1298 optsep '(' optsep 1299 qlcIdentifierList optsep ')' 1300 optsep ';' 1302 extendsStatement = extendsKeyword sep qlcIdentifier optsep ';' 1304 expandsStatement = expandsKeyword sep qlcIdentifier 1305 *1(sep impliedKeyword) 1306 optsep '(' optsep 1307 qlcIdentifierList optsep ')' 1308 optsep ';' 1310 createStatement = createKeyword optsep ';' 1311 membersStatement = membersKeyword optsep '(' optsep 1312 qlcIdentifierList optsep 1313 ')' optsep ';' 1315 mandatoryStatement = mandatoryKeyword optsep '(' optsep 1316 qlcIdentifierList optsep 1317 ')' optsep ';' 1319 optionalStatement = optionalKeyword sep qlcIdentifier optsep 1320 '{' descriptionStatement stmtsep 1321 '}' optsep ';' 1323 refineStatement = refineKeyword sep qlcIdentifier optsep '{' 1324 *1(typeStatement stmtsep) 1325 *1(writetypeStatement stmtsep) 1326 *1(accessStatement stmtsep) 1327 descriptionStatement stmtsep 1328 '}' optsep ';' 1330 typeStatement = typeKeyword sep 1331 (refinedBaseType / refinedType) 1332 optsep ';' 1334 writetypeStatement = writetypeKeyword sep 1335 (refinedBaseType / refinedType) 1336 optsep ';' 1338 oidStatement = oidKeyword sep objectIdentifier optsep ';' 1340 ;; 1341 ;; 1342 ;; 1344 objectIdentifier = (qlcIdentifier / subid) *127('.' subid) 1346 subid = decimalNumber 1348 ;; 1349 ;; Statement keywords. 1350 ;; 1352 snmpKeyword = %x73 %x6E %x6D %x70 1353 nodeKeyword = %x6E %x6F %x64 %x65 1354 representsKeyword = %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6E %x74 1355 %x73 1356 scalarsKeyword = %x73 %x63 %x61 %x6C %x61 %x72 %x73 1357 tableKeyword = %x74 %x61 %x62 %x6C %x65 1358 implementsKeyword = %x69 %x6D %x70 %x6C %x65 %x6D %x65 %x6E %x74 1359 %x73 1360 objectKeyword = %x6F %x62 %x6A %x65 %x63 %x74 1361 notificationKeyword = %x6E %x6F %x74 %x69 %x66 %x69 %x63 %x61 %x74 1362 %x69 %x6F %x6E 1363 signalsKeyword = %x73 %x69 %x67 %x6E %x61 %x6C %x73 1364 oidKeyword = %x6F %x69 %x64 1365 groupKeyword = %x67 %x72 %x6F %x75 %x70 1366 complianceKeyword = %x63 %x6F %x6D %x70 %x6C %x69 %x61 %x6E %x63 1367 %x65 1368 impliedKeyword = %x69 %x6D %x70 %x6C %x69 %x65 %x64 1369 indexKeyword = %x69 %x6E %x64 %x65 %x78 1370 augmentsKeyword = %x61 %x75 %x67 %x6D %x65 %x6E %x74 %x73 1371 reordersKeyword = %x72 %x65 %x6F %x72 %x64 %x65 %x72 %x73 1372 extendsKeyword = %x65 %x78 %x74 %x65 %x6E %x64 %x73 1373 expandsKeyword = %x65 %x78 %x70 %x61 %x6E %x64 %x73 1374 createKeyword = %x63 %x72 %x65 %x61 %x74 %x65 1375 membersKeyword = %x6D %x65 %x6D %x62 %x65 %x72 %x73 1376 mandatoryKeyword = %x6D %x61 %x6E %x64 %x61 %x74 %x6F %x72 %x79 1377 optionalKeyword = %x6F %x70 %x74 %x69 %x6F %x6E %x61 %x6C 1378 refineKeyword = %x72 %x65 %x66 %x69 %x6E %x65 1379 writetypeKeyword = %x77 %x72 %x69 %x74 %x65 %x74 %x79 %x70 %x65 1381 ;; 1382 ;; EOF 1383 ;; 1384 "; 1385 }; 1387 extension agentcaps { 1388 status current; 1389 description 1390 "The agentcaps extension statement is used to describe 1391 an SNMP agent's deviation from the compliance statements 1392 of the modules it implements. It is designed to be 1393 compatible with the SMIv2 AGENT-CAPABILITIES macro. 1395 The agentcaps extension statement should only be used 1396 in the snmp statement body of a module that does not 1397 contain any other definitions that do not 1398 correspond to an agent implementation."; 1399 abnf 1400 " 1401 ;; 1402 ;; 1403 ;; 1405 agentcapsStatement = 'agentcaps' sep lcIdentifier 1406 optsep '{' stmtsep 1407 oidStatement stmtsep 1408 releaseStatement stmtsep 1409 *1(statusStatement stmtsep) 1410 descriptionStatement stmtsep 1411 *1(referenceStatement stmtsep) 1412 *(includesStatement stmtsep) 1413 '}' optsep ';' 1415 includesStatement = 'includes' sep qlcIdentifier 1416 optsep '{' stmtsep 1417 *(variationStatement stmtsep) 1418 '}' optsep ';' 1420 variationStatement = 'variation' sep qlcIdentifier 1421 optsep '{' stmtsep 1422 typeStatement stmtsep 1423 writetypeStatement stmtsep 1424 accessStatement stmtsep 1425 createStatement stmtsep 1426 '}' optsep ';' 1428 ;; 1429 ;; 1430 ;; 1431 "; 1432 }; 1434 // 1435 // 1436 // 1438 typedef ObjectIdentifier { 1439 type Pointer; 1440 description 1441 ""; 1442 }; 1444 // 1445 // 1446 // 1448 snmp { 1450 node ccitt { oid 0; }; 1452 node zeroDotZero { 1453 oid 0.0; 1454 description "A value used for null identifiers."; 1456 }; 1458 node iso { oid 1; }; 1459 node org { oid iso.3; }; 1460 node dod { oid org.6; }; 1461 node internet { oid dod.1; }; 1462 node directory { oid internet.1; }; 1463 node mgmt { oid internet.2; }; 1464 node mib-2 { oid mgmt.1; }; 1465 node transmission { oid mib-2.10; }; 1466 node experimental { oid internet.3; }; 1467 node private { oid internet.4; }; 1468 node enterprises { oid private.1; }; 1469 node security { oid internet.5; }; 1470 node snmpV2 { oid internet.6; }; 1471 node snmpDomains { oid snmpV2.1; }; 1472 node snmpProxys { oid snmpV2.2; }; 1473 node snmpModules { oid snmpV2.3; }; 1475 node joint-iso-ccitt { oid 2; }; 1477 }; 1479 }; 1481 6. IETF-SMING-SNMP 1483 module IETF-SMING-SNMP { 1485 organization "IETF Next Generation Structure of 1486 Management Information Working Group (SMING)"; 1488 contact "Frank Strauss 1490 TU Braunschweig 1491 Bueltenweg 74/75 1492 38106 Braunschweig 1493 Germany 1495 Phone: +49 531 391-3266 1496 EMail: strauss@ibr.cs.tu-bs.de"; 1498 description "Core type definitions for the SMIng SNMP mapping. 1499 These definitions are based on RFC 2579 definitions 1500 that are specific to the SNMP protocol and its 1501 naming system."; 1503 revision { 1504 date "2001-01-04"; 1505 description "Initial version, published as RFC &rfc.number;."; 1506 }; 1508 typedef TestAndIncr { 1509 type Integer32 (0..2147483647); 1510 description 1511 "Represents integer-valued information used for atomic 1512 operations. When the management protocol is used to 1513 specify that an object instance having this syntax is to 1514 be modified, the new value supplied via the management 1515 protocol must precisely match the value presently held by 1516 the instance. If not, the management protocol set 1517 operation fails with an error of `inconsistentValue'. 1518 Otherwise, if the current value is the maximum value of 1519 2^31-1 (2147483647 decimal), then the value held by the 1520 instance is wrapped to zero; otherwise, the value held by 1521 the instance is incremented by one. (Note that 1522 regardless of whether the management protocol set 1523 operation succeeds, the variable- binding in the request 1524 and response PDUs are identical.) 1526 The value of the SNMP access clause for objects having 1527 this syntax is either `read-write' or `read-create'. 1528 When an instance of a columnar object having this syntax 1529 is created, any value may be supplied via the management 1530 protocol. 1532 When the network management portion of the system is re- 1533 initialized, the value of every object instance having 1534 this syntax must either be incremented from its value 1535 prior to the re-initialization, or (if the value prior to 1536 the re- initialization is unknown) be set to a 1537 pseudo-randomly generated value."; 1538 }; 1540 typedef AutonomousType { 1541 type Pointer; 1542 description 1543 "Represents an independently extensible type 1544 identification value. It may, for example, indicate a 1545 particular OID sub-tree with further MIB definitions, or 1546 define a particular type of protocol or hardware."; 1547 }; 1549 typedef VariablePointer { 1550 type Pointer; 1551 description 1552 "A pointer to a specific object instance. For example, 1553 sysContact.0 or ifInOctets.3."; 1554 }; 1556 typedef RowPointer { 1557 type Pointer; 1558 description 1559 "Represents a pointer to a conceptual row. The value is 1560 the name of the instance of the first accessible columnar 1561 object in the conceptual row. 1563 For example, ifIndex.3 would point to the 3rd row in the 1564 ifTable (note that if ifIndex were not-accessible, then 1565 ifDescr.3 would be used instead)."; 1566 }; 1568 typedef RowStatus { 1569 type Enumeration (active(1), notInService(2), 1570 notReady(3), createAndGo(4), 1571 createAndWait(5), destroy(6)); 1572 description 1573 "The RowStatus textual convention is used to manage the 1574 creation and deletion of conceptual rows, and is used as the 1575 value of the SYNTAX clause for the status column of a 1576 conceptual row (as described in Section 7.7.1 of [2].) 1578 The status column has six defined values: 1580 - `active', which indicates that the conceptual row is 1581 available for use by the managed device; 1583 - `notInService', which indicates that the conceptual 1584 row exists in the agent, but is unavailable for use by 1585 the managed device (see NOTE below); 1587 - `notReady', which indicates that the conceptual row 1588 exists in the agent, but is missing information 1589 necessary in order to be available for use by the 1590 managed device; 1592 - `createAndGo', which is supplied by a management 1593 station wishing to create a new instance of a 1594 conceptual row and to have its status automatically set 1595 to active, making it available for use by the managed 1596 device; 1598 - `createAndWait', which is supplied by a management 1599 station wishing to create a new instance of a 1600 conceptual row (but not make it available for use by 1601 the managed device); and, 1603 - `destroy', which is supplied by a management station 1604 wishing to delete all of the instances associated with 1605 an existing conceptual row. 1607 Whereas five of the six values (all except `notReady') may 1608 be specified in a management protocol set operation, only 1609 three values will be returned in response to a management 1610 protocol retrieval operation: `notReady', `notInService' or 1611 `active'. That is, when queried, an existing conceptual row 1612 has only three states: it is either available for use by the 1613 managed device (the status column has value `active'); it is 1614 not available for use by the managed device, though the 1616 agent has sufficient information to make it so (the status 1617 column has value `notInService'); or, it is not available 1618 for use by the managed device, and an attempt to make it so 1619 would fail because the agent has insufficient information 1620 (the state column has value `notReady'). 1622 NOTE WELL 1624 This textual convention may be used for a MIB table, 1625 irrespective of whether the values of that table's 1626 conceptual rows are able to be modified while it is 1627 active, or whether its conceptual rows must be taken 1628 out of service in order to be modified. That is, it is 1629 the responsibility of the DESCRIPTION clause of the 1630 status column to specify whether the status column must 1631 not be `active' in order for the value of some other 1632 column of the same conceptual row to be modified. If 1633 such a specification is made, affected columns may be 1634 changed by an SNMP set PDU if the RowStatus would not 1635 be equal to `active' either immediately before or after 1636 processing the PDU. In other words, if the PDU also 1637 contained a varbind that would change the RowStatus 1638 value, the column in question may be changed if the 1639 RowStatus was not equal to `active' as the PDU was 1640 received, or if the varbind sets the status to a value 1641 other than 'active'. 1643 Also note that whenever any elements of a row exist, the 1644 RowStatus column must also exist. 1646 To summarize the effect of having a conceptual row with a 1647 status column having a SYNTAX clause value of RowStatus, 1648 consider the following state diagram: 1650 STATE 1651 +--------------+-----------+-------------+------------- 1652 | A | B | C | D 1653 | |status col.|status column| 1654 |status column | is | is |status column 1655 ACTION |does not exist| notReady | notInService| is active 1656 --------------+--------------+-----------+-------------+------------- 1657 set status |noError ->D|inconsist- |inconsistent-|inconsistent- 1658 column to | or | entValue| Value| Value 1659 createAndGo |inconsistent- | | | 1660 | Value| | | 1661 --------------+--------------+-----------+-------------+------------- 1662 set status |noError see 1|inconsist- |inconsistent-|inconsistent- 1663 column to | or | entValue| Value| Value 1664 createAndWait |wrongValue | | | 1665 --------------+--------------+-----------+-------------+------------- 1666 set status |inconsistent- |inconsist- |noError |noError 1667 column to | Value| entValue| | 1668 active | | | | 1669 | | or | | 1670 | | | | 1671 | |see 2 ->D|see 8 ->D| ->D 1672 --------------+--------------+-----------+-------------+------------- 1673 set status |inconsistent- |inconsist- |noError |noError ->C 1674 column to | Value| entValue| | 1675 notInService | | | | 1676 | | or | | or 1677 | | | | 1678 | |see 3 ->C| ->C|see 6 1679 --------------+--------------+-----------+-------------+------------- 1680 set status |noError |noError |noError |noError ->A 1681 column to | | | | or 1682 destroy | ->A| ->A| ->A|see 7 1683 --------------+--------------+-----------+-------------+------------- 1684 set any other |see 4 |noError |noError |see 5 1685 column to some| | | | 1686 value | | see 1| ->C| ->D 1687 --------------+--------------+-----------+-------------+------------- 1689 (1) goto B or C, depending on information available to the 1691 agent. 1693 (2) if other variable bindings included in the same PDU, 1694 provide values for all columns which are missing but 1695 required, then return noError and goto D. 1697 (3) if other variable bindings included in the same PDU, 1698 provide values for all columns which are missing but 1699 required, then return noError and goto C. 1701 (4) at the discretion of the agent, the return value may be 1702 either: 1704 inconsistentName: because the agent does not choose to 1705 create such an instance when the corresponding 1706 RowStatus instance does not exist, or 1708 inconsistentValue: if the supplied value is 1709 inconsistent with the state of some other MIB object's 1710 value, or 1712 noError: because the agent chooses to create the 1713 instance. 1715 If noError is returned, then the instance of the status 1716 column must also be created, and the new state is B or C, 1717 depending on the information available to the agent. If 1718 inconsistentName or inconsistentValue is returned, the row 1719 remains in state A. 1721 (5) depending on the MIB definition for the column/table, 1722 either noError or inconsistentValue may be returned. 1724 (6) the return value can indicate one of the following 1725 errors: 1727 wrongValue: because the agent does not support 1728 createAndWait, or 1730 inconsistentValue: because the agent is unable to take 1731 the row out of service at this time, perhaps because it 1732 is in use and cannot be de-activated. 1734 (7) the return value can indicate the following error: 1736 inconsistentValue: because the agent is unable to 1737 remove the row at this time, perhaps because it is in 1738 use and cannot be de-activated. 1740 NOTE: Other processing of the set request may result in a 1741 response other than noError being returned, e.g., 1742 wrongValue, noCreation, etc. 1744 Conceptual Row Creation 1746 There are four potential interactions when creating a 1747 conceptual row: selecting an instance-identifier which is 1748 not in use; creating the conceptual row; initializing any 1749 objects for which the agent does not supply a default; and, 1750 making the conceptual row available for use by the managed 1751 device. 1753 Interaction 1: Selecting an Instance-Identifier 1755 The algorithm used to select an instance-identifier varies 1756 for each conceptual row. In some cases, the instance- 1757 identifier is semantically significant, e.g., the 1758 destination address of a route, and a management station 1759 selects the instance-identifier according to the semantics. 1761 In other cases, the instance-identifier is used solely to 1762 distinguish conceptual rows, and a management station 1763 without specific knowledge of the conceptual row might 1764 examine the instances present in order to determine an 1765 unused instance-identifier. (This approach may be used, but 1766 it is often highly sub-optimal; however, it is also a 1767 questionable practice for a naive management station to 1768 attempt conceptual row creation.) 1770 Alternately, the MIB module which defines the conceptual row 1771 might provide one or more objects which provide assistance 1772 in determining an unused instance-identifier. For example, 1773 if the conceptual row is indexed by an integer-value, then 1774 an object having an integer-valued SYNTAX clause might be 1775 defined for such a purpose, allowing a management station to 1776 issue a management protocol retrieval operation. In order 1777 to avoid unnecessary collisions between competing management 1778 stations, `adjacent' retrievals of this object should be 1779 different. 1781 Finally, the management station could select a pseudo-random 1782 number to use as the index. In the event that this index 1783 was already in use and an inconsistentValue was returned in 1784 response to the management protocol set operation, the 1785 management station should simply select a new pseudo-random 1786 number and retry the operation. 1788 A MIB designer should choose between the two latter 1789 algorithms based on the size of the table (and therefore the 1790 efficiency of each algorithm). For tables in which a large 1791 number of entries are expected, it is recommended that a MIB 1792 object be defined that returns an acceptable index for 1793 creation. For tables with small numbers of entries, it is 1794 recommended that the latter pseudo-random index mechanism be 1795 used. 1797 Interaction 2: Creating the Conceptual Row 1799 Once an unused instance-identifier has been selected, the 1800 management station determines if it wishes to create and 1801 activate the conceptual row in one transaction or in a 1802 negotiated set of interactions. 1804 Interaction 2a: Creating and Activating the Conceptual Row 1806 The management station must first determine the column 1807 requirements, i.e., it must determine those columns for 1808 which it must or must not provide values. Depending on the 1809 complexity of the table and the management station's 1810 knowledge of the agent's capabilities, this determination 1811 can be made locally by the management station. Alternately, 1812 the management station issues a management protocol get 1813 operation to examine all columns in the conceptual row that 1814 it wishes to create. In response, for each column, there 1815 are three possible outcomes: 1817 - a value is returned, indicating that some other 1818 management station has already created this conceptual 1819 row. We return to interaction 1. 1821 - the exception `noSuchInstance' is returned, 1822 indicating that the agent implements the object-type 1823 associated with this column, and that this column in at 1824 least one conceptual row would be accessible in the MIB 1825 view used by the retrieval were it to exist. For those 1826 columns to which the agent provides read-create access, 1827 the `noSuchInstance' exception tells the management 1828 station that it should supply a value for this column 1829 when the conceptual row is to be created. 1831 - the exception `noSuchObject' is returned, indicating 1832 that the agent does not implement the object-type 1833 associated with this column or that there is no 1834 conceptual row for which this column would be 1835 accessible in the MIB view used by the retrieval. As 1836 such, the management station can not issue any 1837 management protocol set operations to create an 1838 instance of this column. 1840 Once the column requirements have been determined, a 1841 management protocol set operation is accordingly issued. 1842 This operation also sets the new instance of the status 1843 column to `createAndGo'. 1845 When the agent processes the set operation, it verifies that 1846 it has sufficient information to make the conceptual row 1847 available for use by the managed device. The information 1848 available to the agent is provided by two sources: the 1849 management protocol set operation which creates the 1850 conceptual row, and, implementation-specific defaults 1851 supplied by the agent (note that an agent must provide 1852 implementation-specific defaults for at least those objects 1853 which it implements as read-only). If there is sufficient 1854 information available, then the conceptual row is created, a 1855 `noError' response is returned, the status column is set to 1856 `active', and no further interactions are necessary (i.e., 1857 interactions 3 and 4 are skipped). If there is insufficient 1858 information, then the conceptual row is not created, and the 1859 set operation fails with an error of `inconsistentValue'. 1860 On this error, the management station can issue a management 1861 protocol retrieval operation to determine if this was 1862 because it failed to specify a value for a required column, 1863 or, because the selected instance of the status column 1864 already existed. In the latter case, we return to 1865 interaction 1. In the former case, the management station 1867 can re-issue the set operation with the additional 1868 information, or begin interaction 2 again using 1869 `createAndWait' in order to negotiate creation of the 1870 conceptual row. 1872 NOTE WELL 1874 Regardless of the method used to determine the column 1875 requirements, it is possible that the management 1876 station might deem a column necessary when, in fact, 1877 the agent will not allow that particular columnar 1878 instance to be created or written. In this case, the 1879 management protocol set operation will fail with an 1880 error such as `noCreation' or `notWritable'. In this 1881 case, the management station decides whether it needs 1882 to be able to set a value for that particular columnar 1883 instance. If not, the management station re-issues the 1884 management protocol set operation, but without setting 1885 a value for that particular columnar instance; 1886 otherwise, the management station aborts the row 1887 creation algorithm. 1889 Interaction 2b: Negotiating the Creation of the Conceptual 1890 Row 1892 The management station issues a management protocol set 1893 operation which sets the desired instance of the status 1894 column to `createAndWait'. If the agent is unwilling to 1895 process a request of this sort, the set operation fails with 1896 an error of `wrongValue'. (As a consequence, such an agent 1897 must be prepared to accept a single management protocol set 1898 operation, i.e., interaction 2a above, containing all of the 1899 columns indicated by its column requirements.) Otherwise, 1900 the conceptual row is created, a `noError' response is 1901 returned, and the status column is immediately set to either 1902 `notInService' or `notReady', depending on whether it has 1903 sufficient information to make the conceptual row available 1904 for use by the managed device. If there is sufficient 1905 information available, then the status column is set to 1906 `notInService'; otherwise, if there is insufficient 1907 information, then the status column is set to `notReady'. 1908 Regardless, we proceed to interaction 3. 1910 Interaction 3: Initializing non-defaulted Objects 1912 The management station must now determine the column 1913 requirements. It issues a management protocol get operation 1914 to examine all columns in the created conceptual row. In 1915 the response, for each column, there are three possible 1916 outcomes: 1918 - a value is returned, indicating that the agent 1919 implements the object-type associated with this column 1920 and had sufficient information to provide a value. For 1921 those columns to which the agent provides read-create 1922 access (and for which the agent allows their values to 1923 be changed after their creation), a value return tells 1924 the management station that it may issue additional 1925 management protocol set operations, if it desires, in 1926 order to change the value associated with this column. 1928 - the exception `noSuchInstance' is returned, 1929 indicating that the agent implements the object-type 1930 associated with this column, and that this column in at 1931 least one conceptual row would be accessible in the MIB 1932 view used by the retrieval were it to exist. However, 1933 the agent does not have sufficient information to 1934 provide a value, and until a value is provided, the 1935 conceptual row may not be made available for use by the 1936 managed device. For those columns to which the agent 1937 provides read-create access, the `noSuchInstance' 1938 exception tells the management station that it must 1939 issue additional management protocol set operations, in 1940 order to provide a value associated with this column. 1942 - the exception `noSuchObject' is returned, indicating 1943 that the agent does not implement the object-type 1944 associated with this column or that there is no 1945 conceptual row for which this column would be 1946 accessible in the MIB view used by the retrieval. As 1947 such, the management station can not issue any 1948 management protocol set operations to create an 1949 instance of this column. 1951 If the value associated with the status column is 1952 `notReady', then the management station must first deal with 1953 all `noSuchInstance' columns, if any. Having done so, the 1954 value of the status column becomes `notInService', and we 1955 proceed to interaction 4. 1957 Interaction 4: Making the Conceptual Row Available 1959 Once the management station is satisfied with the values 1960 associated with the columns of the conceptual row, it issues 1961 a management protocol set operation to set the status column 1962 to `active'. If the agent has sufficient information to 1963 make the conceptual row available for use by the managed 1964 device, the management protocol set operation succeeds (a 1965 `noError' response is returned). Otherwise, the management 1966 protocol set operation fails with an error of 1967 `inconsistentValue'. 1969 NOTE WELL 1971 A conceptual row having a status column with value 1972 `notInService' or `notReady' is unavailable to the 1973 managed device. As such, it is possible for the 1974 managed device to create its own instances during the 1975 time between the management protocol set operation 1976 which sets the status column to `createAndWait' and the 1977 management protocol set operation which sets the status 1978 column to `active'. In this case, when the management 1979 protocol set operation is issued to set the status 1980 column to `active', the values held in the agent 1981 supersede those used by the managed device. 1983 If the management station is prevented from setting the 1984 status column to `active' (e.g., due to management station 1985 or network failure) the conceptual row will be left in the 1986 `notInService' or `notReady' state, consuming resources 1987 indefinitely. The agent must detect conceptual rows that 1988 have been in either state for an abnormally long period of 1989 time and remove them. It is the responsibility of the 1990 DESCRIPTION clause of the status column to indicate what an 1991 abnormally long period of time would be. This period of 1992 time should be long enough to allow for human response time 1993 (including `think time') between the creation of the 1994 conceptual row and the setting of the status to `active'. 1995 In the absence of such information in the DESCRIPTION 1996 clause, 1997 it is suggested that this period be approximately 5 minutes 1998 in length. This removal action applies not only to newly- 1999 created rows, but also to previously active rows which are 2000 set to, and left in, the notInService state for a prolonged 2001 period exceeding that which is considered normal for such a 2002 conceptual row. 2004 Conceptual Row Suspension 2006 When a conceptual row is `active', the management station 2007 may issue a management protocol set operation which sets the 2008 instance of the status column to `notInService'. If the 2009 agent is unwilling to do so, the set operation fails with an 2010 error of `wrongValue' or `inconsistentValue'. 2011 Otherwise, the conceptual row is taken out of service, and a 2012 `noError' response is returned. It is the responsibility of 2013 the DESCRIPTION clause of the status column to indicate 2014 under what circumstances the status column should be taken 2015 out of service (e.g., in order for the value of some other 2016 column of the same conceptual row to be modified). 2018 Conceptual Row Deletion 2020 For deletion of conceptual rows, a management protocol set 2021 operation is issued which sets the instance of the status 2022 column to `destroy'. This request may be made regardless of 2023 the current value of the status column (e.g., it is possible 2024 to delete conceptual rows which are either `notReady', 2025 `notInService' or `active'.) If the operation succeeds, then 2026 all instances associated with the conceptual row are 2027 immediately removed."; 2028 }; 2030 typedef StorageType { 2031 type Enumeration (other(1), volatile(2), 2032 nonVolatile(3), permanent(4), 2033 readOnly(5)); 2034 description 2035 "Describes the memory realization of a conceptual row. A 2036 row which is volatile(2) is lost upon reboot. A row 2037 which is either nonVolatile(3), permanent(4) or 2038 readOnly(5), is backed up by stable storage. A row which 2039 is permanent(4) can be changed but not deleted. A row 2040 which is readOnly(5) cannot be changed nor deleted. 2042 If the value of an object with this syntax is either 2043 permanent(4) or readOnly(5), it cannot be modified. 2044 Conversely, if the value is either other(1), volatile(2) 2045 or nonVolatile(3), it cannot be modified to be 2046 permanent(4) or readOnly(5). (All illegal modifications 2047 result in a 'wrongValue' error.) 2049 Every usage of this textual convention is required to 2050 specify the columnar objects which a permanent(4) row 2051 must at a minimum allow to be writable."; 2052 }; 2054 typedef TDomain { 2055 type Pointer; 2056 description 2057 "Denotes a kind of transport service. 2059 Some possible values, such as snmpUDPDomain, are defined 2060 in the SNMPv2-TM MIB module. Other possible values are 2061 defined in other MIB modules." 2062 reference 2063 "The SNMPv2-TM MIB module is defined in RFC 1906." 2064 }; 2066 typedef TAddressOrZero { 2067 type OctetString (0..255); 2068 description 2069 "Denotes a transport service address. 2071 A TAddress value is always interpreted within the context 2072 of a TDomain value. Thus, each definition of a TDomain 2073 value must be accompanied by a definition of a textual 2074 convention for use with that TDomain. Some possible 2075 textual conventions, such as SnmpUDPAddress for 2076 snmpUDPDomain, are defined in the SNMPv2-TM MIB module. 2077 Other possible textual conventions are defined in other 2078 MIB modules. 2080 A zero-length TAddress value denotes an unknown transport 2081 service address." 2082 reference 2083 "The SNMPv2-TM MIB module is defined in RFC 1906." 2084 }; 2086 typedef TAddress { 2087 type TAddressOrZero (1..255); 2088 description 2089 "Denotes a transport service address. 2091 This type does not allow a zero-length TAddress value." 2092 }; 2094 }; 2096 7. Security Considerations 2098 This document presents an extension of the SMIng data definition 2099 langauge which support the mapping of SMIng data definitions so that 2100 they can be used with the SNMP management framework. The language 2101 extension and the mapping itself has no security impact on the 2102 Internet. 2104 8. Acknowledgements 2106 Since SMIng started as a close successor of SMIv2, some paragraphs 2107 and phrases are directly taken from the SMIv2 specifications [5], 2108 [6], [7] written by Jeff Case, Keith McCloghrie, David Perkins, 2109 Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser. 2111 The authors would like to thank all participants of the 7th NMRG 2112 meeting held in Schloss Kleinheubach from 6-8 September 2000, which 2113 was a major step towards the current status of this memo, namely 2114 Heiko Dassow, David Durham, and Bert Wijnen. 2116 Marshall T. Rose's work on an XML framework for RFC authors [15] 2117 made the writing of an Internet standards document much more 2118 comfortable. 2120 References 2122 [1] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation 2123 Structure of Management Information", draft-ietf-sming-02.txt, 2124 July 2001. 2126 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2127 Levels", RFC 2119, BCP 14, March 1997. 2129 [3] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction 2130 to Version 3 of the Internet-standard Network Management 2131 Framework", RFC 2570, April 1999. 2133 [4] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 2134 Describing SNMP Management Frameworks", RFC 2571, April 1999. 2136 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2137 M. and S. Waldbusser, "Structure of Management Information 2138 Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. 2140 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2141 M. and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2142 2579, STD 59, April 1999. 2144 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 2145 M. and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2146 2580, STD 60, April 1999. 2148 [8] Rose, M. and K. McCloghrie, "Structure and Identification of 2149 Management Information for TCP/IP-based Internets", RFC 1155, 2150 STD 16, May 1990. 2152 [9] Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC 2153 1212, STD 16, March 1991. 2155 [10] Rose, M., "A Convention for Defining Traps for use with the 2156 SNMP", RFC 1215, March 1991. 2158 [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2159 Specifications: ABNF", RFC 2234, November 1997. 2161 [12] International Organization for Standardization, "Specification 2162 of Abstract Syntax Notation One (ASN.1)", International 2163 Standard 8824, December 1987. 2165 [13] Institute of Electrical and Electronics Engineers, "IEEE 2166 Standard for Binary Floating-Point Arithmetic", ANSI/IEEE 2167 Standard 754-1985, August 1985. 2169 [14] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, 2170 "Management Information Base for Version 2 of the Simple 2171 Network Management Protocol (SNMPv2)", RFC 1907, January 1996. 2173 [15] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 2174 1999. 2176 [16] Presuhn, R., Case, J., McCloghrie, K., Rose, M. and S. 2177 Waldbusser, "Version 2 of the Protocol Operations for the 2178 Simple Network Management Protocol", draft-ietf-snmpv3-update- 2179 proto-06.txt, July 2001. 2181 Authors' Addresses 2183 Frank Strauss 2184 TU Braunschweig 2185 Bueltenweg 74/75 2186 38106 Braunschweig 2187 Germany 2189 Phone: +49 531 391-3266 2190 EMail: strauss@ibr.cs.tu-bs.de 2191 URI: http://www.ibr.cs.tu-bs.de/ 2193 Juergen Schoenwaelder 2194 TU Braunschweig 2195 Bueltenweg 74/75 2196 38106 Braunschweig 2197 Germany 2199 Phone: +49 531 391-3289 2200 EMail: schoenw@ibr.cs.tu-bs.de 2201 URI: http://www.ibr.cs.tu-bs.de/ 2203 Appendix A. SMIng SNMP Mapping ABNF Grammar 2205 The grammar of the SMIng SNMP mapping conforms to the Augmented 2206 Backus-Naur Form (ABNF) [11]. 2208 ;; 2209 ;; sming-snmp.abnf -- Grammar of SNMP mappings in ABNF 2210 ;; notation (RFC 2234). 2211 ;; 2212 ;; @(#) $Id: sming-snmp.abnf,v 1.9 2001/07/20 14:13:10 strauss Exp $ 2213 ;; 2214 ;; Copyright (C) The Internet Society (2001). All Rights Reserved. 2215 ;; 2217 ;; 2218 ;; Statement rules. 2219 ;; 2221 snmpStatement = snmpKeyword *1(sep lcIdentifier) optsep 2222 "{" stmtsep 2223 *1(oidStatement stmtsep) 2224 *(nodeStatement stmtsep) 2225 *(scalarsStatement stmtsep) 2226 *(tableStatement stmtsep) 2227 *(notificationStatement stmtsep) 2228 *(groupStatement stmtsep) 2229 *(complianceStatement stmtsep) 2230 statusStatement stmtsep 2231 descriptionStatement stmtsep 2232 *1(referenceStatement stmtsep) 2233 "}" optsep ";" 2235 nodeStatement = nodeKeyword sep lcIdentifier optsep 2236 "{" stmtsep 2237 oidStatement stmtsep 2238 *1(representsStatement stmtsep) 2239 statusStatement stmtsep 2240 *1(descriptionStatement stmtsep) 2241 *1(referenceStatement stmtsep) 2242 "}" optsep ";" 2244 representsStatement = representsKeyword sep 2245 qucIdentifier optsep ";" 2247 scalarsStatement = scalarsKeyword sep lcIdentifier optsep 2248 "{" stmtsep 2249 oidStatement stmtsep 2250 1*(implementsStatement stmtsep) 2251 statusStatement stmtsep 2252 descriptionStatement stmtsep 2253 *1(referenceStatement stmtsep) 2254 "}" optsep ";" 2256 tableStatement = tableKeyword sep lcIdentifier optsep 2257 "{" stmtsep 2258 oidStatement stmtsep 2259 anyIndexStatement stmtsep 2260 *1(createStatement stmtsep) 2261 1*(implementsStatement stmtsep) 2262 statusStatement stmtsep 2263 descriptionStatement stmtsep 2264 *1(referenceStatement stmtsep) 2265 "}" optsep ";" 2267 implementsStatement = implementsKeyword sep qucIdentifier optsep 2268 "{" stmtsep 2269 1*(implObjectStatement stmtsep) 2270 "}" optsep ";" 2272 implObjectStatement = objectKeyword sep 2273 lcIdentifier sep 2274 attrIdentifier optsep; 2276 notificationStatement = notificationKeyword sep lcIdentifier 2277 optsep "{" stmtsep 2278 oidStatement stmtsep 2279 signalsStatement stmtsep 2280 statusStatement stmtsep 2281 descriptionStatement stmtsep 2282 *1(referenceStatement stmtsep) 2283 "}" optsep ";" 2285 signalsStatement = signalsKeyword sep qattrIdentifier 2286 optsep "{" stmtsep 2287 *(signalsObjectStatement) 2288 "}" optsep ";" 2290 signalsObjectStatement = objectKeyword sep 2291 qattrIdentifier optsep ";" 2293 groupStatement = groupKeyword sep lcIdentifier optsep 2294 "{" stmtsep 2295 oidStatement stmtsep 2296 membersStatement stmtsep 2297 statusStatement stmtsep 2298 descriptionStatement stmtsep 2299 *1(referenceStatement stmtsep) 2300 "}" optsep ";" 2302 complianceStatement = complianceKeyword sep lcIdentifier optsep 2303 "{" stmtsep 2304 oidStatement stmtsep 2305 statusStatement stmtsep 2306 descriptionStatement stmtsep 2307 *1(referenceStatement stmtsep) 2308 *1(mandatoryStatement stmtsep) 2309 *(optionalStatement stmtsep) 2310 *(refineStatement stmtsep) 2311 "}" optsep ";" 2313 anyIndexStatement = indexStatement / 2314 augmentsStatement / 2315 reordersStatement / 2316 extendsStatement / 2317 expandsStatement 2319 indexStatement = indexKeyword *1(sep impliedKeyword) optsep 2320 "(" optsep qlcIdentifierList 2321 optsep ")" optsep ";" 2323 augmentsStatement = augmentsKeyword sep qlcIdentifier 2324 optsep ";" 2326 reordersStatement = reordersKeyword sep qlcIdentifier 2327 *1(sep impliedKeyword) 2328 optsep "(" optsep 2329 qlcIdentifierList optsep ")" 2330 optsep ";" 2332 extendsStatement = extendsKeyword sep qlcIdentifier optsep ";" 2334 expandsStatement = expandsKeyword sep qlcIdentifier 2335 *1(sep impliedKeyword) 2336 optsep "(" optsep 2337 qlcIdentifierList optsep ")" 2338 optsep ";" 2340 createStatement = createKeyword optsep ";" 2342 membersStatement = membersKeyword optsep "(" optsep 2343 qlcIdentifierList optsep 2344 ")" optsep ";" 2346 mandatoryStatement = mandatoryKeyword optsep "(" optsep 2347 qlcIdentifierList optsep 2348 ")" optsep ";" 2350 optionalStatement = optionalKeyword sep qlcIdentifier optsep 2351 "{" descriptionStatement stmtsep 2352 "}" optsep ";" 2354 refineStatement = refineKeyword sep qlcIdentifier optsep "{" 2355 *1(typeStatement stmtsep) 2356 *1(writetypeStatement stmtsep) 2357 *1(accessStatement stmtsep) 2358 descriptionStatement stmtsep 2359 "}" optsep ";" 2361 typeStatement = typeKeyword sep 2362 (refinedBaseType / refinedType) 2363 optsep ";" 2365 writetypeStatement = writetypeKeyword sep 2366 (refinedBaseType / refinedType) 2367 optsep ";" 2369 oidStatement = oidKeyword sep objectIdentifier optsep ";" 2371 ;; 2372 ;; 2373 ;; 2375 objectIdentifier = (qlcIdentifier / subid) *127("." subid) 2377 subid = decimalNumber 2379 ;; 2380 ;; Statement keywords. 2381 ;; 2383 snmpKeyword = %x73 %x6E %x6D %x70 2384 nodeKeyword = %x6E %x6F %x64 %x65 2385 representsKeyword = %x72 %x65 %x70 %x72 %x65 %x73 %x65 %x6E %x74 2386 %x73 2387 scalarsKeyword = %x73 %x63 %x61 %x6C %x61 %x72 %x73 2388 tableKeyword = %x74 %x61 %x62 %x6C %x65 2389 implementsKeyword = %x69 %x6D %x70 %x6C %x65 %x6D %x65 %x6E %x74 2390 %x73 2391 objectKeyword = %x6F %x62 %x6A %x65 %x63 %x74 2392 notificationKeyword = %x6E %x6F %x74 %x69 %x66 %x69 %x63 %x61 %x74 2393 %x69 %x6F %x6E 2394 signalsKeyword = %x73 %x69 %x67 %x6E %x61 %x6C %x73 2395 oidKeyword = %x6F %x69 %x64 2396 groupKeyword = %x67 %x72 %x6F %x75 %x70 2397 complianceKeyword = %x63 %x6F %x6D %x70 %x6C %x69 %x61 %x6E %x63 2398 %x65 2399 impliedKeyword = %x69 %x6D %x70 %x6C %x69 %x65 %x64 2400 indexKeyword = %x69 %x6E %x64 %x65 %x78 2401 augmentsKeyword = %x61 %x75 %x67 %x6D %x65 %x6E %x74 %x73 2402 reordersKeyword = %x72 %x65 %x6F %x72 %x64 %x65 %x72 %x73 2403 extendsKeyword = %x65 %x78 %x74 %x65 %x6E %x64 %x73 2404 expandsKeyword = %x65 %x78 %x70 %x61 %x6E %x64 %x73 2405 createKeyword = %x63 %x72 %x65 %x61 %x74 %x65 2406 membersKeyword = %x6D %x65 %x6D %x62 %x65 %x72 %x73 2407 mandatoryKeyword = %x6D %x61 %x6E %x64 %x61 %x74 %x6F %x72 %x79 2408 optionalKeyword = %x6F %x70 %x74 %x69 %x6F %x6E %x61 %x6C 2409 refineKeyword = %x72 %x65 %x66 %x69 %x6E %x65 2410 writetypeKeyword = %x77 %x72 %x69 %x74 %x65 %x74 %x79 %x70 %x65 2412 ;; 2413 ;; EOF 2414 ;; 2416 Appendix B. OPEN ISSUES 2418 Pointers - We don't know how to express assiciations/relations to 2419 class instances or attribute instances. If we should define a 2420 `Pointer' base type, it would probably be mapped to OIDs. One can 2421 argue to generalize the concept of pointers so that they can be 2422 used to model relationships that are not necessarily realized by 2423 OID pointers. 2425 Associations - In general, the modeling of associations between 2426 instances may need better supported at the SMIng data definition 2427 level so that SNMP table interrelationships just map these 2428 instance-level associations. 2430 Mapping to SNMPv1 - The data type mapping is currently only defined 2431 for SNMPv2c and SNMPv3. A straight-forward extension is possible 2432 to also support SNMPv1. 2434 Conversion SMIng -> SMIv2 - It may be useful to define the 2435 conversion from SMIng to SMIv2. 2437 Conversion SMIv2 -> SMIng - It may be useful to define the 2438 conversion from SMIv2 to SMIng. 2440 Revision of IETF-SMING-SNMP - The IETF-SMING-SNMP needs a serious 2441 review to see which wordings must be adapted to the new 2442 terminology. Perhaps some new classes should be added (such as a 2443 grouping of RowStatus and StorageType). 2445 Document Structure - There are some parts in this document which 2446 will also be needed by the COPS-PR mapping. Does it make sense to 2447 separate them out? 2449 SNMP access Statement - There must be an SNMP access statement which 2450 provides the semantics known from SMIv2. 2452 Implicit Entry Definitions - Is it ok to have table row nodes 2453 (Entries) implicitly defined (e.g., naming conventions)? 2455 Order of `object' arguments - The order of the arguments in the 2456 objects statement is not intuitive. 2458 `implements' keyword - The `implements' statement is confusing - 2459 need a better keyword name. 2461 Implicit OID Assignments considered harmful - Implicit OID 2462 assignments are a potential source of problems. It might be 2463 better to explicitly assign OIDs. 2465 SNMP Mapping Identifiers - What's the scope of identifiers defined 2466 by SNMP mapping? Do we need to import such identifiers in SNMP 2467 mapping modules? 2469 `extends' vs. `expands' - These two keyword seem to be confusing? 2470 Any proposals? 2472 Special Table Relationships - Dave Perkins noted that RMON2 has a 2473 table relationship which is not covered by what we have. 2475 Full Copyright Statement 2477 Copyright (C) The Internet Society (2001). All Rights Reserved. 2479 This document and translations of it may be copied and furnished to 2480 others, and derivative works that comment on or otherwise explain it 2481 or assist in its implementation may be prepared, copied, published 2482 and distributed, in whole or in part, without restriction of any 2483 kind, provided that the above copyright notice and this paragraph are 2484 included on all such copies and derivative works. However, this 2485 document itself may not be modified in any way, such as by removing 2486 the copyright notice or references to the Internet Society or other 2487 Internet organizations, except as needed for the purpose of 2488 developing Internet standards in which case the procedures for 2489 copyrights defined in the Internet Standards process must be 2490 followed, or as required to translate it into languages other than 2491 English. 2493 The limited permissions granted above are perpetual and will not be 2494 revoked by the Internet Society or its successors or assigns. 2496 This document and the information contained herein is provided on an 2497 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2498 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2499 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2500 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2501 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2503 Acknowledgement 2505 Funding for the RFC Editor function is currently provided by the 2506 Internet Society.