idnits 2.17.1 draft-ietf-sming-ds-00.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 Introduction section. ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2851 has weird spacing: '...imed to perta...' -- 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 (15 May 2002) is 8018 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: '17' on line 1054 -- Looks like a reference, but probably isn't: '1' on line 989 -- Looks like a reference, but probably isn't: '80' on line 989 == Missing Reference: 'Yes' is mentioned on line 2812, but not defined == Missing Reference: 'Maybe' is mentioned on line 2582, but not defined == Missing Reference: 'No' is mentioned on line 2779, but not defined ** Obsolete normative reference: RFC 1905 (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1906 (Obsoleted by RFC 3417) ** Obsolete normative reference: RFC 2571 (Obsoleted by RFC 3411) ** Obsolete normative reference: RFC 2572 (Obsoleted by RFC 3412) ** Obsolete normative reference: RFC 2573 (Obsoleted by RFC 3413) ** Obsolete normative reference: RFC 2574 (Obsoleted by RFC 3414) ** Obsolete normative reference: RFC 2575 (Obsoleted by RFC 3415) -- Obsolete informational reference (is this intentional?): RFC 2021 (Obsoleted by RFC 4502) -- Obsolete informational reference (is this intentional?): RFC 2570 (Obsoleted by RFC 3410) -- Obsolete informational reference (is this intentional?): RFC 2737 (Obsoleted by RFC 4133) -- Obsolete informational reference (is this intentional?): RFC 2851 (Obsoleted by RFC 3291) Summary: 13 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Andy Bierman 3 Cisco Systems, Inc. 4 15 May 2002 6 Structure of Management Information: 7 Data Structures 9 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026 [RFC2026]. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-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 material 23 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 Distribution of this document is unlimited. Please send comments to the 32 SMIng WG mailing list . 34 1. Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 2. Abstract 40 This memo defines a portion of the Structure of Management Information 41 (SMI) for use with network management protocols in the Internet 42 community. In particular, it describes a new structure and naming 43 scheme for network management information, allowing the specification of 44 arbitrarily complex hierarchical data structures. 46 3. Table of Contents 48 1 Copyright Notice ................................................ 1 49 2 Abstract ........................................................ 2 50 3 Table of Contents ............................................... 2 51 4 The SNMP Network Management Framework ........................... 3 52 5 Overview ........................................................ 4 53 5.1 Terms ......................................................... 4 54 5.2 Design Objectives ............................................. 5 55 5.3 Data Structure Constructs ..................................... 6 56 5.4 Relationship to SMIv2 ......................................... 7 57 5.5 Hierarchical Instance Naming .................................. 8 58 5.6 SMI-DS Data Object Usage Examples ............................. 10 59 5.6.1 InetAddress Example ......................................... 10 60 5.6.2 Generic High Capacity Counter Example ....................... 13 61 5.6.3 Converted SMIv2 TABLE Example ............................... 15 62 5.7 Data Structure Augmentations .................................. 17 63 5.8 SYNTAX POINTER Clause ......................................... 24 64 6 Definitions ..................................................... 26 65 6.1 Namespaces .................................................... 26 66 6.2 Syntax ........................................................ 26 67 7 Information Modules ............................................. 33 68 8 Appendix A: SMIv2 Compatibility ................................. 34 69 8.1 Common Constructs ............................................. 34 70 8.2 SMIv2 to SMI-DS Module Conversion ............................. 34 71 8.3 SMI-DS to SMIv2 Module Conversion ............................. 41 72 8.4 Compatibility Guidelines ...................................... 41 73 9 Appendix B: Complete MODULE Example ............................. 42 74 10 Appendix C: Open Issues ........................................ 49 75 11 Appendix D: Discussion of SMIng Objectives ..................... 51 76 12 Security Considerations ........................................ 66 77 13 Intellectual Property .......................................... 67 78 14 Acknowledgements ............................................... 67 79 15 Normative References ........................................... 68 80 16 Informative References ......................................... 69 81 17 Author's Address ............................................... 71 82 18 Full Copyright Statement ....................................... 72 83 4. The SNMP Network Management Framework 85 The SNMP Management Framework presently consists of five major 86 components: 88 o An overall architecture, described in RFC 2571 [RFC2571]. 90 o Mechanisms for describing and naming objects and events for the 91 purpose of management. The first version of this Structure of 92 Management Information (SMI) is called SMIv1 and described in 93 RFC 1155 [RFC1155], RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. 94 The second version, called SMIv2, is described in RFC 2578 95 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580]. 97 o Message protocols for transferring management information. The 98 first version of the SNMP message protocol is called SNMPv1 and 99 described in RFC 1157 [RFC1157]. A second version of the SNMP 100 message protocol, which is not an Internet standards track 101 protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 102 and RFC 1906 [RFC1906]. The third version of the message 103 protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 104 RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 106 o Protocol operations for accessing management information. The 107 first set of protocol operations and associated PDU formats is 108 described in RFC 1157 [RFC1157]. A second set of protocol 109 operations and associated PDU formats is described in RFC 1905 110 [RFC1905]. 112 o A set of fundamental applications described in RFC 2573 113 [RFC2573] and the view-based access control mechanism described 114 in RFC 2575 [RFC2575]. 116 A more detailed introduction to the current SNMP Management Framework 117 can be found in RFC 2570 [RFC2570]. 119 Managed objects are accessed via a virtual information store, termed 120 the Management Information Base or MIB. Objects in the MIB are 121 defined using the mechanisms defined in the SMI. 123 This memo does not specify a MIB module. 125 5. Overview 127 There is a need for a standardized way of defining aggregated data 128 structures for the representation of management information, which can 129 be utilized with existing and future versions of SNMP. The SMIv2 data 130 model is based on groups of rectangular tables, which are related 131 because they share one or more INDEX clause components. This model 132 provides a single containment layer per table, because all the objects 133 in a conceptual row must be simple types (e.g., Integer32, 134 SnmpAdminString, Counter64). 136 The practice of spreading a multi-layer data structure across several 137 rectangular tables causes MIB modules to be much too verbose, hard to 138 understand, and even harder to implement. The containment relationships 139 between tables are usually described in INDEX clauses and various 140 DESCRIPTION clauses. 142 This practice has a negative impact on agent implementations, which are 143 harder to implement and test, due to row creation and row activation 144 ordering issues. This practice adds complexity to management 145 application development as well. 147 Software development and human readability would benefit from a data 148 definition language which more closely represents the basic data 149 structures that exist in almost all programming languages. 151 [ed. - This revision is intended to introduce the SMI Data Structure 152 concepts and is not yet defined in sufficient detail to be suitable as a 153 formal specification.] 155 5.1. Terms 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 159 document are to be interpreted as described in RFC 2119. [RFC2119] 161 This document uses some terms that need introduction: 163 Aggregated Data Object 164 This term refers to any data object which provides some sort of 165 containment for other data objects, which is any variable construct 166 other than LEAF (e.g., ARRAY, UNION, or STRUCT). 168 Data Object 169 This term refers to any SMI Data Structure variable declaration, at 170 any level of containment. 172 MIB Object 173 This term generically refers to a SMIv2 OBJECT-TYPE macro 174 definition. It may also refer to an SMI Data Structure definition. 176 OID This is a shorthand term for 'OBJECT IDENTIFIER'. 178 LEAF This term refers to any accessible data object with a syntax that 179 resolves to a SMI base type. 181 SMI Data Structure (SMI-DS) 182 This term refers to the concepts and definitions defined in this 183 document. 185 5.2. Design Objectives 187 The working group objectives for this work are detailed in the SMIng 188 Objectives document [RFC3216]. (Refer to Appendix D for a detailed 189 discussion of each accepted objective.) 191 The primary high-level design goals of this work are: 193 - Significantly enhance the usefulness of the SMI as a network 194 management data definition language, by creating a modern 195 programming language like data model supporting aggregated 196 containment. 198 - Enhance SMI object instance naming to support aggregated 199 hierarchical data structures, while remaining backwardly-compatible 200 with SMIv2 naming. 202 - Improve readability by enhancing reusability and removing as much 203 redundant text as possible. The SMI should be as easy to use as 204 possible, for the largest number of people. Therefore, a priority 205 hierarchy can be established, starting with MIB readers, then MIB 206 writers, management software developers, and MIB compiler writers. 208 - Maintain 100% forward and backward translation compatibility with 209 SMIv2. It must be possible to convert all valid SMIv2 constructs 210 to SMI-DS constructs without loss of semantics (i.e., forward 211 compatibility). It should also be possible to translate any SMI-DS 212 construct to one or more SMIv2 constructs, if the associated 213 feature(s) exist in SMIv2. Refer to Appendix A for details on 214 SMIv2 <--> SMI-DS translations. 216 - Preserve as many of the SMIv2 mechanisms and 'installed knowledge- 217 base' as possible. There will a transition period lasting several 218 years, in which SMIv2 MIBs will be converted to SMIv3 format. It 219 is important that MIB readers and writers be able to understand 220 both SMI syntaxes during this period, and so it will be beneficial 221 to keep them as close as possible. Clauses that have not changed 222 at all in semantics between SMI versions should maintain the same 223 syntax. 225 - Make sure accessible data objects (i.e., LEAF objects) can be used 226 with existing versions of SNMP. 228 There are some relevant topics which not design objectives addressed by 229 this draft: 231 - Compatibility with any version of ASN.1. 233 - Equally weighted importance for support of COPS-PR and SNMP. There 234 is a huge disparity in deployment of applications utilizing these 235 protocols. The solution space is biased in favor of SNMP because 236 that will benefit the largest number of people. 238 - Idiot proof MIB design. Data structures can help better organize 239 the information found in a MIB, but they cannot prevent bad design 240 choices or badly written DESCRIPTION clauses. 242 5.3. Data Structure Constructs 244 There are four basic constructs available in the SMI-DS language for the 245 definition of data objects. 247 LEAF This construct is conceptually equivalent to an OBJECT-TYPE macro 248 definition for an accessible MIB object in SMIv2, except a LEAF can 249 be defined at any level of containment. A LEAF type definition or 250 variable declaration resolves to any SMIng base type. In SMI-DS, 251 all other constructs must eventually resolve to some number of 252 these objects, and only LEAF data objects are actually accessible 253 via SNMP. 255 ARRAY 256 This construct provides a multi-dimensional array structure, 257 similar to the SEQUENCE construct in SMIv2. However, instead of 258 one flat 'row' consisting of only accessible base-type MIB objects, 259 an ARRAY can consist of an arbitrary mix of any of the four types 260 of data object constructs. Only base type data objects can be used 261 in an ARRAY INDEX clause (the same ones as in SMIv2), and the rules 262 for encoding INDEX clause base types in OIDs are the same as for 263 SMIv2. 265 UNION 266 This construct provides a mechanism to conceptually allow a single 267 object definition to contain one of potentially several different 268 construct definitions. Only one of these constructs is actually 269 instantiated at any time by the agent. Unlike a union in the C 270 language, the unused union members cannot be accessed at all (no 271 'cast' operator in SMI). 273 STRUCT 274 This construct provides a mechanism to group an arbitrary number of 275 data constructs (of any type), allowing a theoretically unlimited 276 number of data containment layers. It is similar to the ARRAY 277 construct, except there is no INDEX clause. 279 5.4. Relationship to SMIv2 281 Whenever possible, existing SMIv2 macros or clauses have been used 282 without modification. Two exceptions are the TEXTUAL-CONVENTION and 283 OBJECT-TYPE macros. In order to reinforce and support a data model more 284 aligned with popular programming concepts and practices, these macros 285 have been replaced by the TYPEDEF and VAR macros (respectively). Strong 286 emphasis is placed on the separation of potentially reusable type 287 definitions and variable declarations. The ASN.1 tabular data model is 288 replaced with a 'hierarchical containment' data model, which is more 289 similar to the 'native' data representation used by the managed device. 291 The type of declarations that can be made in an SMI-DS module do not 292 really change at all, but some constructs have changed. The major 293 differences between an SMIv2 construct and the equivalent SMI-DS 294 construct are listed in the table below: 296 SMIv2 SMI-DS 297 --------------------- --------------------- 298 TEXTUAL-CONVENTION TYPEDEF LEAF 299 scalar OBJECT-TYPE VAR LEAF 300 tabular OBJECT-TYPE VAR ARRAY 301 NOTIFICATION-TYPE NOTIFICATION 303 Notification semantics have not changed at all, although the syntax has 304 changed slightly to make them more consistent with the TYPEDEF and VAR 305 macros. The ASN.1 specific SEQUENCE macro, and the 'FooTable' and 306 'FooEntry' OBJECT-TYPE definitions that start every SMIv2 table are 307 removed. The basic SYNTAX clause has not changed at all, except that a 308 new variant is provided to specify a typed OID pointer (see section 309 5.8). 311 Many constructs do not change at all, such as the IMPORTS, MODULE- 312 IDENTITY, MAX-ACCESS, STATUS, DESCRIPTION, REFERENCE, DEFVAL, OBJECTS, 313 and MODULE-COMPLIANCE macros. 315 5.5. Hierarchical Instance Naming 317 In order to fully utilize the capabilities of arbitrary containment, a 318 new way of naming object instances is needed, which is designed for 319 hierarchical data structures instead of tables, without changing the OID 320 values for any existing SMIv2 objects which are converted to the SMI-DS 321 object naming format. 323 Since it is possible for accessible objects to exist in the same 324 containment structure as non-accessible objects, it is not possible to 325 name SMI-DS objects with a 'flat' model. SMIv2 assumes all accessible 326 objects in the same containment structure have the same number of object 327 identifier components, and the exact same format for all instance 328 identifier components. This assumption cannot be made for SMI-DS object 329 naming. 331 This new naming scheme can help reduce implementation complexity for 332 agent and application developers for SNMP Set operations. Currently, 333 associated attributes can be spread across multiple tables, (possibly 334 sharing major indexes) each with their own RowStatus and set of 'SNMP 335 callback' functions. This design approach can get relatively 336 complicated, especially if 'createAndWait' and 'notInService' RowStatus 337 values are supported. By allowing aggregated containment instead of 338 unfolding data structures into tables, implementation of high-level Set 339 operations can be simplified for both agent and application developers. 341 The basic format of an OID for an SMI-DS data object is not changed from 342 SMIv2. OIDs are constructed left to right. The left fragment contains 343 static OID values which indicate the name of a node in the MIB tree. 344 The right fragment contains potentially dynamic OID values which 345 represent the instance identifier for the node specified by the left 346 fragment. 348 LEAF Data Object Naming 349 ----------------------- 350 A SCALAR variable declaration is named as follows: 352 .0 354 where: 356 is a well-formed OID base fragment. 358 Aggregate Data Object Naming 359 ---------------------------- 361 An Aggregated Data Object variable declaration is named 362 as follows: 364 .. 365 [. ...] [. ...] 367 where: 369 is a well-formed OID base fragment, 370 (also called the left anchor). 372 contains the value 1. 374 is the data object child node identifier, which 375 must be an INTEGER between 1 and 4294967295. (Similar 376 to a column identifier in an SMIv2 table.) 378 is present only if the variable declaration 379 resolves to a type that contains any ARRAY constructs, 380 and MUST be an INTEGER between 0 and 4294967295. 381 (Similar to an instance identifier in an SMIv2 table.) 383 SMI-DS OID Construction 384 ----------------------- 386 OIDs are constructed in an iterative manner, using two conceptual 387 buffers: 389 base buffer 390 used for building the static portion of an OID, left to right. 391 This buffer contains the , , and all 392 identifiers. 394 index buffer 395 used for building a sequence of ARRAY indexes, (left to right), 396 similar to the instance identifier portion of an SMIv2 OID for a 397 tabular object. This buffer contains all the 398 identifiers. 400 The expansion algorithm for is repeated if it represents an 401 aggregated data object. If it represents an ARRAY construct, then all 402 components for this array type are appended to index buffer. 404 The algorithm terminates when a LEAF data object is encountered. The 405 index buffer is then appended to the base buffer, to form the complete 406 instance identifier for a specific variable declaration. 408 5.6. SMI-DS Data Object Usage Examples 410 The following sections introduce some examples of simple data structures 411 that are currently achieved with relatively verbose text in TEXTUAL- 412 CONVENTION and OBJECT-TYPE DESCRIPTION clauses using SMIv2. Refer to 413 Appendix B for an example of a (somewhat) complete SMI-DS module. 415 5.6.1. InetAddress Example 417 The Internet Address textual conventions defined in the "Textual 418 Conventions for Internet Network Addresses" MIB module [RFC2851] defines 419 several variants of an Internet address (InetAddress), and a control 420 object (InetAddressType) to distinguish which variant is actually 421 present in an InetAddress object instance. This construct may be more 422 concisely and properly represented in SMI-DS by a structure containing 423 the control object and a union of all the address variants. 425 -- a union of all the InetAddress types 427 TYPEDEF UNION InetAddressUnion { 428 DESCRIPTION 429 "Internet address in 4 different representations." 431 LEAF ipUnknown { 432 SYNTAX OCTET STRING (SIZE (0..65535)) 433 MAX-ACCESS read-create 434 STATUS current 435 DESCRIPTION 436 "Represents an Internet address using an externally 437 defined format. The associated InetAddressType 438 object value is 'unknown(0)'." 440 } ::= 1 442 LEAF ipv4Addr { 443 SYNTAX InetAddressIPv4 444 MAX-ACCESS read-create 445 STATUS current 446 DESCRIPTION 447 "Represents an IPv4 Internet address. The 448 associated InetAddressType object value 449 is 'ipv4(1)'." 450 } ::= 2 452 LEAF ipv6Addr { 453 SYNTAX InetAddressIPv6 454 MAX-ACCESS read-create 455 STATUS current 456 DESCRIPTION 457 "Represents an IPv6 Internet address. The 458 associated InetAddressType object value 459 is 'ipv6(2)'." 460 } ::= 3 462 LEAF ipDnsAddr { 463 SYNTAX InetAddressDNS 464 MAX-ACCESS read-create 465 STATUS current 466 DESCRIPTION 467 "Represents an DNS domain name. The associated 468 InetAddressType object value is 'dns(16)'." 469 } ::= 4 470 } 472 TYPEDEF STRUCT HostInetAddress { 473 DESCRIPTION 474 "Internet address for an end-station host, adhering 475 to the SMIv2 'associated objects' design approach." 477 LEAF addrType { 478 SYNTAX InetAddressType 479 MAX-ACCESS read-create 480 STATUS current 481 DESCRIPTION 482 "The type of Internet address." 483 } ::= 1 484 UNION addr { 485 SYNTAX InetAddressUnion 486 STATUS current 487 DESCRIPTION 488 "The Internet address." 489 } ::= 2 490 } 492 VAR STRUCT myAddress { 493 SYNTAX HostInetAddress 494 MAX-ACCESS read-only 495 STATUS current 496 DESCRIPTION 497 "Internet address of this host." 498 } ::= { someBase 1 } 500 VAR UNION newAddress { 501 SYNTAX InetAddressUnion 502 MAX-ACCESS read-write 503 STATUS current 504 DESCRIPTION 505 "Example of the new way to represent a union variable, 506 without the use of an associated InetAddressType object." 507 } ::= { someBase 2 } 509 Note 1) The accessible object instances defined within this structure 510 (addrType, ipUnknown, ipv4Addr, ipv6Addr, etc.) have different lengths: 512 myAddress ::= { someBase 1 } 513 myAddress.addrType ::= { myAddress 1 1 } 514 myAddress.addr ::= { myAddress 1 2 } 515 myAddress.addr.ipUnknown ::= { myAddress 1 2 1 } 516 myAddress.addr.ipv4Addr ::= { myAddress 1 2 2 } 517 myAddress.addr.ipv6Addr ::= { myAddress 1 2 3 } 518 myAddress.addr.dnsAddr ::= { myAddress 1 2 4 } 520 newAddress ::= { someBase 2 } 521 newAddress.ipUnknown ::= { newAddress 1 1 } 522 newAddress.ipv4Addr ::= { newAddress 1 2 } 523 newAddress.ipv6Addr ::= { newAddress 1 3 } 524 newAddress.dnsAddr ::= { newAddress 1 4 } 526 Note 2) The mandatory MAX-ACCESS clause within a LEAF construct in a 527 TYPEDEF macro is used to specify the maximum access level that is 528 possible via a management protocol. The optional MAX-ACCESS clause 529 within a VAR macro is used to specify the constrained maximum access 530 level for that specific variable declaration, and must not specify a 531 higher access than declared within a TYPEDEF macro. (E.g., myAddress is 532 a read-only variable even though the LEAF nodes in the HostInetAddress 533 TYPEDEF are read-create. The same LEAF nodes used within the newAddress 534 variable declaration are read-write.) If an overall MAX-ACCESS clause 535 is not present in the VAR macro, then the values specified in the LEAF 536 nodes are used. 538 Note 3) The addrType field is not actually needed for simple variable 539 declarations, because UNION constructs are instantiated with at most one 540 accessible member. In the example above, a GetNext Request for 541 'myAddress.addr' or 'newAddress' will return only one type of 542 InetAddress string from the InetAddressUnion. The associated 543 InetAddressType variable is needed only when used together with the 544 InetAddress (generic string form) as INDEX components in an ARRAY. 546 Note 4) Just like a TEXTUAL-CONVENTION in SMIv2, a TYPEDEF has no 547 instances associated with it and therefore no MIB root assigned. It is 548 only when a a variable of a particular type is declared (and therefore 549 assigned a MIB root) that the full OID for a data object is known. 551 5.6.2. Generic High Capacity Counter Example 553 There are many MIBs that contain up to the three OBJECT-TYPE macro 554 definitions for every high capacity counter, in order to accommodate 555 SNMPv1 implementations without support for Counter64 and 32-bit 556 implementations without any high capacity support at all. 558 A type definition (GenericCounter) for a union that contains an object 559 for each of the three scenarios would better represent the intended 560 semantics of this design, and use less text within data structure 561 definitions than an SMIv2 version. Note that a discriminator object is 562 not needed for a union, because the agent (or management application) 563 will instantiate at most one of the variants. 565 TYPEDEF UNION GenericCounter { 566 DESCRIPTION 567 "Generic counter for all versions of SNMP." 569 LEAF c32 { 570 SYNTAX Counter32 571 MAX-ACCESS read-only 572 STATUS current 573 DESCRIPTION 574 "The Counter32 representation of the counter." 575 } ::= 1 577 LEAF c64 { 578 SYNTAX Counter64 579 MAX-ACCESS read-only 580 STATUS current 581 DESCRIPTION 582 "The Counter64 representation of the counter." 583 } ::= 2 585 STRUCT c32pair { 586 DESCRIPTION 587 "Pair of Counter32 objects to represent a 64-bit 588 counter." 590 LEAF c32low { 591 SYNTAX Counter32 592 MAX-ACCESS read-only 593 STATUS deprecated 594 DESCRIPTION 595 "The lower 32 bits of a 64 bit counter." 596 } ::= 1 598 LEAF c32hi { 599 SYNTAX Counter32 600 MAX-ACCESS read-only 601 STATUS deprecated 602 DESCRIPTION 603 "The upper 32 bits of a 64 bit counter." 604 } ::= 2 605 } ::= 3 606 } 608 VAR UNION myCounter { 609 SYNTAX GenericCounter 610 STATUS current 611 DESCRIPTION 612 "An example generic counter variable." 613 } ::= { someBase 3 } 615 Note 1) Inline vs. external type definition: The 'c32pair' STRUCT could 616 have been defined as a separate type and a STRUCT declared with a SYNTAX 617 clause that referenced that type (e.g., form of 618 the STRUCT declaration). The instance numbering works out the same 619 either way. 621 The following OIDs would be possible for the 'myCounter' variable 622 declaration: 624 myCounter ::= { someBase 3 } 625 myCounter.c32 ::= { myCounter 1 1 } 626 myCounter.c64 ::= { myCounter 1 2 } 627 myCounter.c32pair ::= { myCounter 1 3 } 628 myCounter.c32pair.c32low ::= { myCounter 1 3 1 } 629 myCounter.c32pair.c32hi ::= { myCounter 1 3 2 } 631 Note 2) Even though only one node of a UNION can be instantiated at any 632 given time, a GetNext Request for a UNION which contains other 633 aggregated data objects can cause multiple instances to be returned from 634 that sub-tree, as with the 'c32low' and 'c32hi' LEAF objects in the 635 example above. 637 Note 3) Only the STATUS clauses for LEAF data object definitions are 638 relevant for compliance section usage. However, the above example 639 raises issues regarding an aggregated data object which contains a 640 mixture of current, deprecated, and obsolete LEAF objects. (Is the 641 STATUS of the GenericCounter UNION itself current or deprecated?) 643 5.6.3. Converted SMIv2 TABLE Example 645 The following example shows how two objects from the ifTable [RFC2863] 646 would be defined in SMI-DS syntax. Note that in in this example, the 647 interface table is modeled directly as a variable declaration, without 648 using a TYPEDEF. This practice is discouraged for new MIB definitions. 650 -- this is modeled as an ARRAY variable, rather than 651 -- an ARRAY containing a TYPEDEF'ed structure, to preserve 652 -- compatibility with SMIv2 654 VAR ARRAY ifTable { 656 DESCRIPTION 657 "A list of interface entries. The number of entries 658 is given by the value of ifNumber." 660 INDEX { ifIndex } 662 LEAF ifIndex { 663 SYNTAX InterfaceIndex 664 MAX-ACCESS read-only 665 STATUS current 666 DESCRIPTION 667 "A unique value, greater than zero, for each 668 interface. It is recommended that values are assigned 669 contiguously starting from 1. The value for each 670 interface sub-layer must remain constant at least from 671 one re-initialization of the entity's network 672 management system to the next re-initialization." 673 } ::= 1 675 LEAF ifDescr { 676 SYNTAX DisplayString (SIZE (0..255)) 677 MAX-ACCESS read-only 678 STATUS current 679 DESCRIPTION 680 "A textual string containing information about the 681 interface. This string should include the name of the 682 manufacturer, the product name and the version of the 683 interface hardware/software." 684 } ::= 2 686 LEAF ifType { 687 SYNTAX IANAifType 688 MAX-ACCESS read-only 689 STATUS current 690 DESCRIPTION 691 "The type of interface. Additional values for ifType 692 are assigned by the Internet Assigned Numbers 693 Authority (IANA), through updating the syntax of the 694 IANAifType textual convention." 695 } ::= 3 697 -- rest of ifTable LEAF objects would follow 698 } ::= { interfaces 2 } 700 -- declare the ifEntry descriptor for use in other AUGMENTS 701 ifEntry OBJECT IDENTIFIER ::= { ifTable 1 } 703 Note 1) The object naming and semantics are identical to the SMIv2 704 version. The OIDs for instance number '17' are shown: 706 ifTable ::= { interfaces 2 } 707 ifTable[17] ::= Not Available 708 ifTable[17].ifIndex ::= { ifTable 1 1 17 } 709 ifTable[17].ifDescr ::= { ifTable 1 2 17 } 710 ifTable[17].ifType ::= { ifTable 1 3 17 } 712 5.7. Data Structure Augmentations 714 SMIv2 allows for MIB tables to be conceptually extended over time, 715 without modifying the original MIB table definition, using the AUGMENTS 716 clause. This is usually done to allow vendor extensions to standard 717 MIBs, or to avoid editing a 'stable' RFC. 719 In SMI-DS, the AUGMENTS clause is preserved and adapted for use with 720 aggregated data objects, in order to maintain backward compatibility 721 with SMIv2. Only inline variable declarations for ARRAY data objects 722 can be augmented. 724 In addition to the AUGMENTS clause, which models 1:1 existence 725 relationships between two ARRAY variables, a SPARSE-AUGMENTS clause is 726 provides to model conditional 1:1 existence relationships between the 727 augmenting ARRAY variable and the augmented ARRAY variable. 729 The AUGMENTS construct defines one or more nodes which are conceptually 730 added to the outermost containment layer of the augmented ARRAY 731 variable. The augmenting ARRAY variable inherits all of the index 732 components of that ARRAY (exactly as with SMIv2). 734 A variant of the AUGMENTS construct is provided (called SPARSE-AUGMENTS) 735 for situations in which a static subset of an existing ARRAY is 736 augmented. The DESCRIPTION clause for an ARRAY which is a sparse 737 augmentation MUST explain the relationship between the augmenting and 738 augmented table. 740 The AUGMENTS clause in SMIv2 references the internal table node (e.g., 741 ifEntry, not ifTable), but SMI-DS ARRAY variables do not need or use 742 this internal construct. To remain compatible with SMIv2, an OBJECT 743 IDENTIFIER macro is used to declare an object descriptor which can be 744 used in AUGMENTS and SPARSE-AUGMENTS clauses. 746 AUGMENTS Example 747 ---------------- 749 The following trivial example shows how some high-capacity counters and 750 time-related attributes might be added to an existing array of packet 751 statistics. 753 TYPEDEF ARRAY InetHostStats { 754 DESCRIPTION 755 "Example of a IP host stats table." 757 INDEX { ifIndex, inetAddrType, inetAddr } 759 LEAF inetAddrType { 760 SYNTAX InetAddressType 761 MAX-ACCESS not-accessible 762 STATUS current 763 DESCRIPTION 764 "The IP address type for the array entry. 765 The InetAddressType values 'unknown(1)' and 766 'dns(16)' are not allowed." 767 } ::= 1 769 LEAF inetAddr { 770 SYNTAX InetAddress 771 MAX-ACCESS not-accessible 772 STATUS current 773 DESCRIPTION 774 "The IP address for the array entry." 775 } ::= 2 777 LEAF inPkts { 778 SYNTAX Counter32 779 MAX-ACCESS read-only 780 STATUS current 781 DESCRIPTION 782 "The number of packets received by the specified host 783 on the specified interface." 784 } ::= 3 786 LEAF outPkts { 787 SYNTAX Counter32 788 MAX-ACCESS read-only 789 STATUS current 790 DESCRIPTION 791 "The number of packets transmitted by the specified 792 host on the specified interface." 793 } ::= 4 795 -- Octet counters removed to make example shorter 796 } 797 -- variable declaration for a InetHostStats data collection 799 VAR ARRAY ipStats { 800 SYNTAX InetHostStats 801 STATUS current 802 DESCRIPTION 803 "The IP host statistics for this network device." 804 } ::= { someBase 4 } 806 -- OID declaration to keep AUGMENTS clause consistent 807 ipStatsEntry OBJECT IDENTIFIER ::= { ipStats 1 } 809 -- a struct containing additional information for each 810 -- set of counters 812 TYPEDEF STRUCT HostStatsTimeData { 813 DESCRIPTION 814 "Add some times related objects associated with 815 each set of counters." 817 LEAF createTime { 818 SYNTAX TimeStamp 819 MAX-ACCESS read-only 820 STATUS current 821 DESCRIPTION 822 "The value of sysUpTime at the time this set of 823 counters was created." 824 } ::= 1 826 LEAF updateInterval { 827 SYNTAX Unsigned32 828 UNITS "milliseconds" 829 MAX-ACCESS read-create 830 STATUS current 831 DESCRIPTION 832 "The average amount of time that elapses between 833 internal polling intervals for this counter set. 834 A value of zero indicates that the counter set 835 values are not polled internally." 836 } ::= 2 837 } 839 -- Augment the ipStats variable with the ipXStats variable: 840 -- - 2 HC packet counters 841 -- - a HostStatsTimeData STRUCT 842 -- - an ARRAY of InetPortNumber packet counters 844 VAR ARRAY ipXStats { 845 DESCRIPTION 846 "Adds HC counters and additional information to 847 the ipStats statistics." 849 AUGMENTS { ipStatsEntry } 851 LEAF inHCPkts { 852 SYNTAX Counter64 853 MAX-ACCESS read-only 854 STATUS current 855 DESCRIPTION 856 "The number of packets received by the specified 857 host on the specified interface." 858 } ::= 1 860 LEAF outHCPkts { 861 SYNTAX Counter64 862 MAX-ACCESS read-only 863 STATUS current 864 DESCRIPTION 865 "The number of packets transmitted by the specified 866 host on the specified interface." 867 } ::= 2 869 -- Octet counters removed to make example shorter 871 STRUCT timeData { 872 SYNTAX HostStatsTimeData 873 MAX-ACCESS read-only 874 STATUS current 875 DESCRIPTION 876 "Additional time-related information." 877 } ::= 3 879 ARRAY portStats { 880 DESCRIPTION 881 "Extend the ARRAY with InetPort statistics." 883 INDEX { inetPort } 885 LEAF inetPort { 886 SYNTAX InetPortNumber 887 MAX-ACCESS not-accessible 888 STATUS current 889 DESCRIPTION 890 "The Internet port number for the array entry." 891 } ::= 1 893 UNION uInPkts { 894 SYNTAX GenericCounter 895 MAX-ACCESS read-only 896 STATUS current 897 DESCRIPTION 898 "The number of packets received by the specified 899 host on the specified port." 900 } ::= 2 902 UNION uOutPkts { 903 SYNTAX GenericCounter 904 MAX-ACCESS read-only 905 STATUS current 906 DESCRIPTION 907 "The number of packets transmitted by the specified 908 host on the specified port." 909 } ::= 3 911 -- Octet counters removed to make example shorter 912 } ::= 4 913 } ::= { someBase 5 } 915 ipXStatsEntry OBJECT IDENTIFIER ::= { ipXStats 1 } 917 Note 1) The following example lists the potential OID values for each of 918 the fields in the 'ipStats' and 'ipXStats' variables in the example 919 above. 921 In this example only the instances for interface 17, InetAddressType 922 'ipv4(1)', InetAddress '192.168.0.1', and InetPortNumber '80' are shown. 924 ipStats ::= { someBase 4 } 925 ipStats[17] ::= Not Available 926 ipStats[17][1] ::= Not Available 927 ipStats[17][1][192.168.0.1] ::= Not Available 929 ipStats[17][1][192.168.0.1].inPkts ::= 930 { ipStats 1 3 17 1 4 192 168 0 1 } 932 ipStats[17][1][192.168.0.1].outPkts ::= 933 { ipStats 1 4 17 1 4 192 168 0 1 } 935 ipXStats ::= { someBase 5 } 936 ipXStats[17][1][192.168.0.1].inHCPkts ::= 937 { ipXStats 1 1 17 1 4 192 168 0 1 } 939 ipXStats[17][1][192.168.0.1].outHCPkts ::= 940 { ipXStats 1 2 17 1 4 192 168 0 1 } 942 ipXStats[17][1][192.168.0.1].timeData ::= 943 { ipXStats 1 3 17 1 4 192 168 0 1 } (not-accessible) 945 ipXStats[17][1][192.168.0.1].timeData.createTime ::= 946 { ipXStats 1 3 1 17 1 4 192 168 0 1 } 948 ipXStats[17][1][192.168.0.1].timeData.updateInterval ::= 949 { ipXStats 1 3 2 17 1 4 192 168 0 1 } 951 ipXStats[17][1][192.168.0.1].portStats ::= 952 { ipXStats 1 4 17 1 4 192 168 0 1 } (not-accessible) 954 ipXStats[17][1][192.168.0.1].portStats[80] ::= Not Available 956 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts ::= 957 { ipXStats 1 4 2 17 1 4 192 168 0 1 80 } (not-accessible) 959 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c32 ::= 960 { ipXStats 1 4 2 1 17 1 4 192 168 0 1 80 } 962 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c64 ::= 963 { ipXStats 1 4 2 2 17 1 4 192 168 0 1 80 } 965 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c32pair ::= 966 { ipXStats 1 4 2 3 17 1 4 192 168 0 1 80 } (not-accessible) 968 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c32pair.c32low ::= 969 { ipXStats 1 4 2 3 1 17 1 4 192 168 0 1 80 } 971 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c32pair.c32hi ::= 972 { ipXStats 1 4 2 3 2 17 1 4 192 168 0 1 80 } 974 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts ::= 975 { ipXStats 1 4 3 17 1 4 192 168 0 1 80 } (not-accessible) 977 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c32 ::= 978 { ipXStats 1 4 3 1 17 1 4 192 168 0 1 80 } 980 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c64 ::= 981 { ipXStats 1 4 3 2 17 1 4 192 168 0 1 80 } 983 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c32pair ::= 984 { ipXStats 1 4 3 3 17 1 4 192 168 0 1 80 } (not-accessible) 986 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c32pair.c32low ::= 987 { ipXStats 1 4 3 3 1 17 1 4 192 168 0 1 80 } 989 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c32pair.c32hi ::= 990 { ipXStats 1 4 3 3 2 17 1 4 192 168 0 1 80 } 992 Note 2) Although arbitrary levels of nested containment are 993 theoretically possible, SNMP varbind size limitations and common sense 994 design practices set practical limits on the complexity of data object 995 definitions. 997 Note 3) The SPPI provides an EXTENDS mechanism, which allows new LEAF 998 objects to be defined in a table which conceptually adds INDEX 999 components to an existing table. This mechanism is accomplished by 1000 defining an additional ARRAY (with the new INDEX components and objects) 1001 in an AUGMENTS clause, like the 'portStats' example above. 1003 SPARSE-AUGMENTS Example 1004 ----------------------- 1006 The following example shows how information about physical sensors may 1007 sparsely augment the entPhysicalTable [RFC2737]. 1009 VAR ARRAY entSensorData { 1010 DESCRIPTION 1011 "Adds the ability to read physical sensor values 1012 to the Entity MIB. An entSensorData object exists 1013 for each entPhysicalEntry for which the entPhysicalClass 1014 object value is 'sensor(8)'." 1015 REFERENCE 1016 "RFC 2737, section 3." 1018 SPARSE-AUGMENTS { entPhysicalEntry } 1020 LEAF entSensorType { 1021 SYNTAX EntitySensorDataType 1022 MAX-ACCESS read-only 1023 STATUS current 1024 DESCRIPTION 1025 "The type of data returned by the associated 1026 entSensorValue object. ..." 1027 } ::= 1 1029 LEAF entSensorScale { 1030 SYNTAX EntitySensorDataScale 1031 MAX-ACCESS read-only 1032 STATUS current 1033 DESCRIPTION 1034 "The exponent to apply to values returned by the 1035 associated entSensorValue object. ..." 1036 } ::= 2 1038 -- rest of entSensorEntry objects would follow ... 1040 } ::= { someBase 6 } 1042 Note 1) SMI-DS objects can augment SMIv2 tables, since the SMIv2 <--> 1043 SMI-DS conversion algorithms are transparent. The augmented variable 1044 object descriptor may be any value that would be accepted in an SMIv2 1045 AUGMENTS clause. 1047 Note 2) The following OIDs would be possible for the 'entSensorEntry' 1048 augmentation. The instances for entPhysicalIndex == 17 are shown in this 1049 example: 1051 entSensorData ::= { someBase 6 } 1052 entSensorData[17] ::= Not Available 1053 entSensorData[17].entSensorType ::= { entSensorData 1 1 17 } 1054 entSensorData[17].entSensorScale ::= { entSensorData 1 2 17 } 1056 5.8. SYNTAX POINTER Clause 1058 The 'VariablePointer' and 'RowPointer' TEXTUAL-CONVENTIONs [RFC2579] 1059 provide semantic constraints on the generic OBJECT IDENTIFIER, but they 1060 can only be used to point to a variable or row of any type, not a 1061 specific type. 1063 SMI-DS provides a modified SYNTAX clause for object declarations, in 1064 order to specify an OID that must reference a MIB object (LEAF or 1065 aggregated data object) of a particular type. The value { 0 0 } is also 1066 allowed and is reserved to indicate a NULL pointer. 1068 The form "SYNTAX POINTER " specifies an OID which should 1069 contain only those values that de-reference to the same type as defined 1070 by , or contain the NULL pointer value { 0 0 }. 1072 For example, if the RMON DataSource TC [RFC2021] was written in SMI-DS, 1073 the POINTER construct might be used as follows: 1075 TYPEDEF LEAF DataSource { 1076 SYNTAX POINTER InterfaceIndex 1077 MAX-ACCESS read-create 1078 STATUS current 1079 DESCRIPTION 1080 "Identifies the source of the data that the associated 1081 function is configured to analyze. This source can be any 1082 interface on this device. ... 1083 For example, if an entry were to receive data from 1084 interface #1, this object would be set to ifIndex.1." 1085 } 1087 Refer to section 6.2 for details on the 'SYNTAX POINTER' clause. 1089 6. Definitions 1091 The follow sections specify the SMI Data Structures syntax and 1092 semantics. 1094 [ed. -- this section is intentionally incomplete, because this revision 1095 is meant to introduce the SMI Data Structures concepts, syntax, and 1096 examples. Complete specification to the level of SMIv2 is TBD.] 1098 6.1. Namespaces 1100 The type names and variable names used in SMI Data Structures are 1101 contained is the same namespace, identical to the SMIv2 namespace for 1102 OBJECT-TYPE descriptors, and shared with SMIv2. Reserved keywords in 1103 SMI-DS or SMIv2 MUST NOT be used as type names or object descriptors. 1105 Ideally, every data object containment level would define its own 1106 namespace, in a truly hierarchical fashion. However, this would not be 1107 compatible with existing SMIv2 practices, and would require changes to 1108 the IMPORTS, MODULE-COMPLIANCE and OBJECT-GROUP macros to support. 1110 [ed. - further definition of namespaces TBD] 1112 6.2. Syntax 1114 [ed. - the following ad-hoc syntax definition is a first-pass attempt, 1115 and obviously needs ABNF definition, and a detailed mappings and rules 1116 section for each construct. At this time, any construct which is 1117 equivalent to the SMIv2 version is not fully specified.] 1119 -- top level construction 1121 ::= 1123 "MODULE" "DEFINITIONS" "::=" "BEGIN" 1124 1125 1126 [] 1128 "END" 1130 ::= (same as SMIv2) 1132 ::= (same as SMIv2) 1133 ::= (same as SMIv2) 1135 ::= 1137 ( | | 1138 | | notification-decl> ) 1140 ::= (SMIv2 OBJECT IDENTIFIER clause) 1142 ::= (SMIv2 OBJECT-IDENTITY clause) 1144 ::= 1146 "TYPEDEF" ( | | 1147 | ) 1149 ::= 1151 "VAR" ( | | 1152 | ) 1154 ::= 1156 "LEAF" 1158 ::= 1160 (same rules as for SMIv2 TEXTUAL-CONVENTION descriptors) 1162 ::= 1164 "{" 1165 [] 1166 1167 [] 1168 1169 1170 1171 [] 1172 [] 1173 "}" 1175 ::= (same as SMIv2 DIPLAY-HINT) 1177 ::= 1178 ( | ) 1180 ::= 1182 (same as SMIv2, plus 64-bit numbers and float data types) 1184 ::= 1186 "SYNTAX" "POINTER" 1188 ::= (same as SMIv2) 1190 ::= (same as SMIv2) 1192 ::= (same as SMIv2) 1194 ::= (same as SMIv2) 1196 ::= (same as SMIv2) 1198 ::= (same as SMIv2) 1200 ::= 1202 "LEAF" 1203 "::=" 1205 ::= 1207 (same rules as for SMIv2 OBJECT-TYPE descriptors) 1209 ::= an INTEGER in the range (1..4294967295) 1211 ::= 1213 "LEAF" 1214 "::=" 1216 ::= (same as SMIv2) 1218 ::= 1220 "ARRAY" "{" 1221 1222 [] 1223 1224 [ ...] 1225 "}" 1227 ::= 1229 ( | | 1230 ) 1232 ::= 1234 -- this syntax needs to change to support the optional 1235 -- IMPLIED keyword before the last object-descriptor 1237 "INDEX" "{" 1238 [ "," ...] "}" 1240 ::= 1242 "AUGMENTS" "{" "}" 1244 ::= 1246 "SPARSE-AUGMENTS" "{" "}" 1248 ::= 1250 ( | | 1251 | ) 1253 ::= 1255 ( | ) 1257 ::= 1259 1261 ::= 1263 "ARRAY" "{" 1264 1265 [] 1266 1267 [ ...] 1269 "}" "::=" 1271 ::= 1273 1275 ::= 1277 "ARRAY" "{" 1278 1279 [] 1280 1281 1282 [] 1283 "}" "::=" 1285 ::= 1287 ( | ) 1289 ::= 1291 1293 ::= 1295 1297 ::= 1299 "UNION" "{" 1300 1301 [] 1302 [ ...] 1303 "}" 1305 ::= 1307 ( | ) 1309 ::= 1311 1313 ::= 1314 "UNION" "{" 1315 1316 [] 1317 [ ...] 1318 "}" "::=" 1320 ::= 1322 1324 ::= 1326 "UNION" "{" 1327 1328 [] 1329 1330 1331 [] 1332 "}" "::=" 1334 ::= 1336 ( | ) 1338 ::= 1340 1342 ::= 1344 1346 ::= 1348 "STRUCT" "{" 1349 1350 [] 1351 [ ...] 1352 "}" 1354 ::= 1356 ( | ) 1358 ::= 1359 1361 ::= 1363 "STRUCT" "{" 1364 1365 [] 1366 [ ...] 1367 "}" "::=" 1369 ::= 1371 1373 ::= 1375 "STRUCT" "{" 1376 1377 [] 1378 1379 1380 [] 1381 "}" "::=" 1383 ::= 1385 ( | ) 1387 ::= 1389 1391 ::= 1393 1395 ::= 1397 "NOTIFICATION" "{" 1398 [] 1399 1400 1401 [] 1402 "}" "::=" 1404 ::= 1406 "OBJECTS" "{" 1407 [ "," ...] "}" 1409 ::= 1411 (same as SMIv2, except VAR node descriptors need to 1412 be fully qualified) 1414 -- END 1416 7. Information Modules 1418 TBD - This section (and 7 more) need to be completed by adapting 1419 sections 3 - 10 of SMIv2 [RFC2578]. 1421 8. Appendix A: SMIv2 Compatibility 1423 It is important to advance SMI features in a way that maximizes the 1424 reusability of existing SMIv2-based development work and training. 1425 Several SMI-DS features are intended to provide mechanisms for automatic 1426 (or semi-automatic) translations between SMIv2 and SMI-DS definitions. 1428 8.1. Common Constructs 1430 The following macros, clauses, and keywords are identical in SMIv2 and 1431 SMI-DS, and therefore no translation is required. Clauses listed here 1432 are not mentioned in the sections describing macro conversions that 1433 utilize these clauses. 1435 - BEGIN 1436 - DEFVAL 1437 - DEFINITIONS 1438 - DESCRIPTION 1439 - DISPLAY-HINT 1440 - END 1441 - IMPORTS 1442 - INDEX 1443 - MAX-ACCESS 1444 - MODULE-COMPLIANCE (all clauses) 1445 - MODULE-IDENTITY (all clauses) 1446 - OBJECT-IDENTITY 1447 - OBJECT-IDENTIFIER 1448 - OBJECTS 1449 - REFERENCE 1450 - STATUS 1451 - UNITS 1453 8.2. SMIv2 to SMI-DS Module Conversion 1455 The following SMIv2 macros, clauses and keywords require some 1456 conversion: 1458 - NOTIFICATION-TYPE 1459 - OBJECT-TYPE 1460 - SEQUENCE 1461 - TEXTUAL-CONVENTION 1463 TEXTUAL-CONVENTIONs 1464 ------------------- 1465 The TEXTUAL-CONVENTION macro is replaced by the TYPEDEF macro, which can 1466 be used to define aggregated data types, in addition to the refinement 1467 of base types. The TEXTUAL-CONVENTION macro is replaced with the 1468 TYPEDEF macro as follows: 1470 a) prefix type name with 'TYPEDEF LEAF ' and append it with ' {' 1472 b) remove '::= TEXTUAL-CONVENTION' 1474 c) The SYNTAX clause can be modified to refine another LEAF 1475 TYPEDEF, or an OBJECT IDENTIFIER type can be changed to 1476 a typed OID pointer (e.g., 'SYNTAX POINTER FooType') 1478 d) add a MAX-ACCESS clause specifying the maximum access level 1479 for the data type, as used in any possible situation 1481 e) a UNITS clause may be added if appropriate 1483 f) a DEFVAL clause may be added if appropriate 1485 g) end TYPEDEF macro with a '}' token 1487 e.g: 1489 FooString ::= TEXTUAL-CONVENTION 1490 STATUS current 1491 DESCRIPTION 1492 "This data type is used to model an administratively 1493 controlled textual string." 1494 SYNTAX OCTET STRING (SIZE (0..127)) 1496 is changed to: 1498 TYPEDEF LEAF FooString { 1499 SYNTAX OCTET STRING (SIZE (0..127)) 1500 MAX-ACCESS read-create 1501 STATUS current 1502 DESCRIPTION 1503 "This data type is used to model an administratively 1504 controlled textual string." 1505 } 1507 OBJECT-TYPE Macro 1508 ----------------- 1509 The generic OBJECT-TYPE macro is replaced with the VAR macro. 1511 Scalar Objects 1512 -------------- 1514 The scalar OBJECT-TYPE macro is replaced with the 'VAR LEAF' macro as 1515 follows: 1517 a) prefix scalar name with 'VAR LEAF ' and append it with ' {' 1519 b) remove '::= OBJECT-TYPE' 1521 c) The SYNTAX clause of OBJECT IDENTIFIER can be changed to a 1522 typed OID pointer (e.g., 'SYNTAX POINTER FooType') 1524 d) prefix '::= ' with a '}' token 1526 e.g., 1528 sysUpTime OBJECT-TYPE 1529 SYNTAX TimeTicks 1530 MAX-ACCESS read-only 1531 STATUS current 1532 DESCRIPTION 1533 "The time (in hundredths of a second) since the network 1534 management portion of the system was last re-initialized." 1535 ::= { system 3 } 1537 is replaced with: 1539 VAR LEAF sysUpTime { 1540 SYNTAX TimeTicks 1541 MAX-ACCESS read-only 1542 STATUS current 1543 DESCRIPTION 1544 "The time (in hundredths of a second) since the network 1545 management portion of the system was last re-initialized." 1546 } ::= { system 3 } 1548 Tabular Objects 1549 --------------- 1551 The tabular OBJECT-TYPE macro is replaced with the 'VAR ARRAY' macro as 1552 follows: 1554 a) The contents of the SEQUENCE can be converted in three ways: 1555 1) placed directly in a VAR ARRAY macro 1556 2) placed in a STRUCT TYPEDEF and a data node of that type 1557 declared in the VAR ARRAY macro 1558 3) placed an ARRAY TYPEDEF, including the INDEX, and a 1559 variable of this type declared with the VAR ARRAY macro. 1560 This method must be used to convert tables using the 1561 AUGMENTS clause. 1563 The direct method (1) is shown here. 1565 b) The OBJECT-TYPE macro for the table itself (e.g., fooTable) 1566 is transformed into a VAR ARRAY declaration by extracting 1567 the object descriptor, prefixing it with 'VAR ARRAY ' and 1568 appending it with ' {'. The DESCRIPTION clause should be 1569 transferred and modified as needed. 1571 c) The OBJECT-TYPE macro for the table entry (e.g., fooEntry) is 1572 discarded except for the INDEX clause, and any information 1573 from the DESCRIPTION clause is transferred and modified as 1574 needed. An OBJECT IDENTIFIER macro may be created to 1575 declare the descriptor for the table entry, allowing it 1576 to be used in an AUGMENTS or SPARSE-AUGMENTS clause in 1577 another ARRAY variable declaration. E.g., 1579 fooEntry OBJECT IDENTIFIER ::= { fooTable 1 } 1581 d) For each OBJECT-TYPE macro, an 1582 for a 'LEAF' is created. 1583 - prefix object descriptor with 'VAR LEAF ' and append it 1584 with ' {' 1585 - remove '::= OBJECT-TYPE' 1586 - The SYNTAX clause of OBJECT IDENTIFIER may be changed to a 1587 typed OID pointer (e.g., 'SYNTAX POINTER FooType') 1588 - replace '::= { fooEntry }' with '} ::= ' 1590 e) prefix a '}' token to the node assignment for the table itself 1591 (e.g., 'fooTable'), which becomes the node assignment for the 1592 ARRAY variable declaration. 1594 E.g., (Note: IF-MIB [RFC2863] example DESCRIPTION clauses truncated), 1596 ifStackTable OBJECT-TYPE 1597 SYNTAX SEQUENCE OF IfStackEntry 1598 MAX-ACCESS not-accessible 1599 STATUS current 1600 DESCRIPTION 1601 "The table containing information on the relationships 1602 between the multiple sub-layers of network interfaces..." 1603 ::= { ifMIBObjects 2 } 1605 ifStackEntry OBJECT-TYPE 1606 SYNTAX IfStackEntry 1607 MAX-ACCESS not-accessible 1608 STATUS current 1609 DESCRIPTION 1610 "Information on a particular relationship between two 1611 sub-layers, specifying that one sub-layer runs on 1612 'top' of the other sub-layer. Each sub-layer 1613 corresponds to a conceptual row in the ifTable." 1614 INDEX { ifStackHigherLayer, ifStackLowerLayer } 1615 ::= { ifStackTable 1 } 1617 IfStackEntry ::= 1618 SEQUENCE { 1619 ifStackHigherLayer Integer32, 1620 ifStackLowerLayer Integer32, 1621 ifStackStatus RowStatus 1622 } 1624 ifStackHigherLayer OBJECT-TYPE 1625 SYNTAX Integer32 1626 MAX-ACCESS not-accessible 1627 STATUS current 1628 DESCRIPTION 1629 "The value of ifIndex corresponding to the higher 1630 sub-layer of the relationship, i.e., the sub-layer..." 1631 ::= { ifStackEntry 1 } 1633 ifStackLowerLayer OBJECT-TYPE 1634 SYNTAX Integer32 1635 MAX-ACCESS not-accessible 1636 STATUS current 1637 DESCRIPTION 1638 "The value of ifIndex corresponding to the lower sub- 1639 layer of the relationship, i.e., the sub-layer which ..." 1640 ::= { ifStackEntry 2 } 1642 ifStackStatus OBJECT-TYPE 1643 SYNTAX RowStatus 1644 MAX-ACCESS read-create 1645 STATUS current 1646 DESCRIPTION 1647 "The status of the relationship between two sub- 1648 layers. ..." 1649 ::= { ifStackEntry 3 } 1651 is replaced with: 1653 VAR ARRAY ifStackTable { 1654 DESCRIPTION 1655 "The table containing information on the relationships 1656 between the multiple sub-layers of network interfaces... 1658 Information on a particular relationship between two 1659 sub-layers, specifying that one sub-layer runs on 1660 'top' of the other sub-layer. Each sub-layer 1661 corresponds to a conceptual row in the ifTable." 1663 INDEX { ifStackHigherLayer, ifStackLowerLayer } 1665 LEAF ifStackHigherLayer { 1666 SYNTAX Integer32 1667 MAX-ACCESS not-accessible 1668 STATUS current 1669 DESCRIPTION 1670 "The value of ifIndex corresponding to the 1671 higher sub-layer of the relationship, i.e., 1672 the sub-layer..." 1673 } ::= 1 1675 LEAF ifStackLowerLayer { 1676 SYNTAX Integer32 1677 MAX-ACCESS not-accessible 1678 STATUS current 1679 DESCRIPTION 1680 "The value of ifIndex corresponding to the 1681 lower sub-layer of the relationship, i.e., 1682 the sub-layer which ..." 1683 } ::= 2 1685 LEAF ifStackStatus { 1686 SYNTAX RowStatus 1687 MAX-ACCESS read-create 1688 STATUS current 1689 DESCRIPTION 1690 "The status of the relationship between two sub- 1691 layers. ..." 1692 } ::= 3 1693 ::= { ifMIBObjects 2 } 1695 OBJECT IDENTIFIER ifStackEntry ::= { ifStackTable 1 } 1697 Notifications 1698 ------------- 1700 The SMIv2 NOTIFICATION-TYPE macro is replaced with the NOTIFICATION 1701 macro as follows: 1703 a) prefix notification name with 'NOTIFICATION ' and append 1704 it with ' {' 1706 b) remove '::= NOTIFICATION-TYPE' 1708 c) prefix '::= ' with a '}' token 1710 e.g., 1712 linkUp NOTIFICATION-TYPE 1713 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 1714 STATUS current 1715 DESCRIPTION 1716 "A linkDown trap signifies that the SNMPv2 entity, 1717 acting in an agent role, has detected that the 1718 ifOperStatus object for one of its communication links 1719 left the down state and transitioned into some other 1720 state (but not into the notPresent state). This other 1721 state is indicated by the included value of 1722 ifOperStatus." 1723 ::= { snmpTraps 4 } 1725 is replaced with: 1727 NOTIFICATION linkUp { 1728 OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } 1729 STATUS current 1730 DESCRIPTION 1731 "A linkDown trap signifies that the SNMPv2 entity, 1732 acting in an agent role, has detected that the 1733 ifOperStatus object for one of its communication links 1734 left the down state and transitioned into some other 1735 state (but not into the notPresent state). This other 1736 state is indicated by the included value of 1737 ifOperStatus." 1738 } ::= { snmpTraps 4 } 1740 8.3. SMI-DS to SMIv2 Module Conversion 1742 Just as with the transition from SMIv1 to SMIv2, not all new constructs 1743 can be efficiently mapped backward (from SMI-DS to SMIv2). Since some 1744 new clauses are designed to extract information buried in DESCRIPTION 1745 clauses or comments, it is to be expected that backward conversion 1746 consists of putting this information back where it came from. 1748 [Guidelines for unfolding tables TBD] 1750 8.4. Compatibility Guidelines 1752 The following guidelines are provided to assist MIB writers create SMI- 1753 DS modules that can be properly mapped backward into SMIv2 syntax and 1754 semantics. 1756 ARRAYs 1757 ------ 1759 The IMPLIED keyword SHOULD NOT be used, except to convert an SMIv2 table 1760 which has an IMPLIED INDEX component to SMI-DS. Only one IMPLIED 1761 keyword can be used, and it MUST be in the innermost ARRAY construct, if 1762 nested ARRAYs are defined. The IMPLIED keyword severely limits the 1763 ability to reuse a TYPEDEF containing it, and SHOULD NOT be used in type 1764 definitions. 1766 9. Appendix B: Complete MODULE Example 1768 The following example shows a somewhat complete MIB module, adapted from 1769 the Remote Monitoring Extensions for Differentiated Services document 1770 [DSMON-MIB]. Refer to that document to compare the SMIv2 and SMI-DS 1771 definitions. 1773 This is not a transparent conversion of the SMIv2 version, but rather an 1774 'upgraded' version, in which the containment features (such as STRUCTs 1775 and nested ARRAYs) are utilized. The intent is to demonstrate how a 1776 read-create data structure spread over three tables with SMIv2 can be 1777 defined as a single structure with SMI-DS. 1779 MODULE DSMON-MIB DEFINITIONS ::= BEGIN 1781 -- partial IMPORTS, only for the aggregation control objects 1783 IMPORTS 1784 MODULE-IDENTITY, Integer32, Counter32 1785 FROM SNMPv2-SMI 1786 MODULE-COMPLIANCE, OBJECT-GROUP 1787 FROM SNMPv2-CONF 1788 RowStatus, TimeStamp, TruthValue 1789 FROM SNMPv2-TC 1790 OwnerString, rmon 1791 FROM RMON-MIB 1792 SnmpAdminString 1793 FROM SNMP-FRAMEWORK-MIB 1794 Dscp 1795 FROM DIFFSERV-DSCP-TC; 1797 -- the MODULE-IDENTITY macro is not changed at all 1799 dsmonMIB MODULE-IDENTITY 1800 LAST-UPDATED "200111050000Z" 1801 ORGANIZATION "IETF RMONMIB Working Group" 1802 CONTACT-INFO 1803 "Same as SMIv2" 1804 DESCRIPTION 1805 "Same as SMIv2" 1806 REVISION "200111050000Z" 1807 DESCRIPTION 1808 "Same as SMIv2" 1809 ::= { rmon 26 } 1811 dsmonObjects OBJECT IDENTIFIER ::= { dsmonMIB 1 } 1812 dsmonNotifications OBJECT IDENTIFIER ::= { dsmonMIB 2 } 1813 dsmonConformance OBJECT IDENTIFIER ::= { dsmonMIB 3 } 1815 dsmonAggObjects OBJECT IDENTIFIER ::= { dsmonObjects 1 } 1817 -- the following objects removed from the example 1818 dsmonStatsObjects OBJECT IDENTIFIER ::= { dsmonObjects 2 } 1819 dsmonPdistObjects OBJECT IDENTIFIER ::= { dsmonObjects 3 } 1820 dsmonHostObjects OBJECT IDENTIFIER ::= { dsmonObjects 4 } 1821 dsmonCapsObjects OBJECT IDENTIFIER ::= { dsmonObjects 5 } 1822 dsmonMatrixObjects OBJECT IDENTIFIER ::= { dsmonObjects 6 } 1824 -- converted DsmonCounterAggGroupIndex TC to a TYPEDEF 1826 TYPEDEF LEAF DsmonCounterAggGroupIndex { 1827 SYNTAX Integer32 (0..2147483647) 1828 MAX-ACCESS read-create 1829 STATUS current 1830 DESCRIPTION 1831 "This TC describes a data type which identifies a DSMON 1832 counter aggregation group, ..." 1833 } 1835 -- converted DsmonCounterAggProfileIndex TC to a TYPEDEF 1837 TYPEDEF LEAF DsmonCounterAggProfileIndex { 1838 SYNTAX Integer32 (1..2147483647) 1839 MAX-ACCESS read-create 1840 STATUS current 1841 DESCRIPTION 1842 "This TC describes a data type which identifies a DSMON 1843 counter aggregation profile, ..." 1844 } 1846 -- converted dsmonAggProfileTable 1848 TYPEDEF ARRAY DsmonCounterAggProfile { 1849 DESCRIPTION 1850 "Controls the setup of a single aggregation profile, 1851 for which every DSCP value MUST be configured 1852 into exactly one aggregation group. ..." 1854 INDEX { dsmonAggProfileDSCP } 1855 LEAF dsmonAggProfileDSCP { 1856 SYNTAX Dscp 1857 MAX-ACCESS not-accessible 1858 STATUS curent 1859 DESCRIPTION 1860 "The specific DSCP value which is configured in an 1861 aggregation group by this entry." 1862 } ::= 1 1864 LEAF dsmonAggGroupIndex { 1865 SYNTAX DsmonCounterAggGroupIndex 1866 MAX-ACCESS read-create 1867 STATUS current 1868 DESCRIPTION 1869 "The aggregation group which contains this DSCP 1870 value. ..." 1871 DEFVAL { 0 } 1872 } ::= 2 1873 } 1875 -- converted dsmonAggGroupTable 1877 TYPEDEF ARRAY DsmonCounterAggGroup { 1878 DESCRIPTION 1879 "Controls the setup of a single aggregation profile, 1880 for which every DSCP value MUST be configured 1881 into exactly one aggregation group. ..." 1883 INDEX { dsmonAggGroupIndex } 1885 LEAF dsmonAggGroupIndex { 1886 SYNTAX DsmonCounterAggGroupIndex 1887 MAX-ACCESS not-accessible 1888 STATUS current 1889 DESCRIPTION 1890 "The specific Aggregation Group which is represented 1891 group by each entry." 1892 } ::= 1 1894 LEAF dsmonAggGroupDescr { 1895 SYNTAX SnmpAdminString (SIZE(0..64)) 1896 MAX-ACCESS read-create 1897 STATUS current 1898 DESCRIPTION 1899 "An administratively assigned description of the 1900 aggregation group identified by this entry. ..." 1901 } ::= 2 1902 } 1904 -- converted dsmonAggControlTable 1906 TYPEDEF STRUCT DsmonCounterAggControl { 1907 DESCRIPTION 1908 "Provides an overall description and control 1909 point for a single aggregation control configuration. ..." 1911 LEAF dsmonAggControlDescr { 1912 SYNTAX SnmpAdminString (SIZE(0..64)) 1913 MAX-ACCESS read-create 1914 STATUS current 1915 DESCRIPTION 1916 "An administratively assigned description of the aggregation 1917 profile identified by this entry. ..." 1918 } ::= 1 1920 ARRAY aggProfile { 1921 SYNTAX DsmonCounterAggProfile 1922 STATUS current 1923 DESCRIPTION 1924 "A set of DSCP to Aggregation Group mappings." 1925 } ::= 2 1927 ARRAY aggGroup { 1928 SYNTAX DsmonCounterAggGroup 1929 STATUS current 1930 DESCRIPTION 1931 "A set of Aggregation Group descriptions." 1932 } ::= 3 1934 LEAF dsmonAggControlOwner { 1935 SYNTAX OwnerString 1936 MAX-ACCESS read-create 1937 STATUS current 1938 DESCRIPTION 1939 "The entity that configured this object and is 1940 therefore using the resources assigned to it." 1941 } ::= 4 1943 LEAF dsmonAggControlStatus { 1944 SYNTAX RowStatus 1945 MAX-ACCESS read-create 1946 STATUS current 1947 DESCRIPTION 1948 "The status of this entire aggregation control 1949 object. ..." 1950 } ::= 5 1951 } 1953 -- 1954 -- variable declarations for the 4 scalars in this group 1955 -- 1957 VAR LEAF dsmonMaxAggGroups { 1958 SYNTAX Integer32 (2..64) 1959 MAX-ACCESS read-only 1960 STATUS current 1961 DESCRIPTION 1962 "The maximum number of aggregation groups that this agent 1963 can support. ..." 1964 } ::= { dsmonAggObjects 1 } 1966 VAR LEAF dsmonAggControlLocked { 1967 SYNTAX TruthValue 1968 MAX-ACCESS read-write 1969 STATUS current 1970 DESCRIPTION 1971 "Controls the setup of aggregation groups for this agent. ..." 1972 } ::= { dsmonAggObjects 2 } 1974 VAR LEAF dsmonAggControlChanges { 1975 SYNTAX Counter32 1976 MAX-ACCESS read-only 1977 STATUS current 1978 DESCRIPTION 1979 "This object counts the number of times the value of the 1980 dsmonAggControlLocked object has changed. ..." 1981 } ::= { dsmonAggObjects 3 } 1983 VAR LEAF dsmonAggControlLastChangeTime { 1984 SYNTAX TimeStamp 1985 MAX-ACCESS read-only 1986 STATUS current 1987 DESCRIPTION 1988 "This object identifies the value of sysUpTime at the moment 1989 the dsmonAggControlLocked object was last modified. ..." 1991 } ::= { dsmonAggObjects 4 } 1993 -- finishing the dsmonAggControlTable by allowing multiple 1994 -- instances of an aggregation control block 1996 VAR ARRAY dsmonAggProfiles { 1997 STATUS current 1998 DESCRIPTION 1999 "A collection of DSMON aggregation control profiles. ..." 2001 INDEX { dsmonAggControlIndex } 2003 LEAF dsmonAggControlIndex { 2004 SYNTAX DsmonCounterAggProfileIndex 2005 MAX-ACCESS not-accessible 2006 STATUS current 2007 DESCRIPTION 2008 "The specific Counter Aggregation Profile which is 2009 represented by each entry." 2010 } ::= 1 2012 STRUCT aggControl { 2013 SYNTAX DsmonCounterAggControl 2014 STATUS current 2015 DESCRIPTION 2016 "The DSMON Counter Aggregation Control entry for 2017 each profile." 2018 } ::= 2 2019 } ::= { dsmonAggObjects 5 } 2021 -- No NOTIFICATION-TYPE macros defined in this module 2023 -- Compliance section (currently unchanged from SMIv2) 2025 dsmonCounterAggControlCompliance MODULE-COMPLIANCE 2026 STATUS current 2027 DESCRIPTION 2028 "Example compliance for the aggregation control 2029 portion of the DSMON-MIB module." 2030 MODULE -- this module 2031 MANDATORY-GROUPS { dsmonCounterAggControlGroup } 2033 ::= { dsmonCompliances 1 } 2035 dsmonCounterAggControlGroup OBJECT-GROUP 2036 OBJECTS { 2037 dsmonMaxAggGroups, 2038 dsmonAggControlLocked, 2039 dsmonAggControlChanges, 2040 dsmonAggControlLastChangeTime, 2041 dsmonAggProfiles.aggControl.dsmonAggControlDescr, 2042 dsmonAggProfiles.aggControl.dsmonAggControlOwner, 2043 dsmonAggProfiles.aggControl.dsmonAggControlStatus, 2044 dsmonAggProfiles.aggControl.appProfile.dsmonAggGroupIndex, 2045 dsmonAggProfiles.aggControl.appGroup.dsmonAggGroupDescr 2046 } 2047 STATUS current 2048 DESCRIPTION 2049 "A collection of objects used to configure and manage 2050 aggregation groups for DSMON collection purposes." 2051 ::= { dsmonGroups 1 } 2053 END 2055 Note 1) The following example shows the difference between SMIv2 naming 2056 and SMI-DS naming, for the OBJECT IDENTIFIERS in the DSMON-MIB module 2057 example above. 2059 Object Instance Examples 2060 ------------------------------ 2061 O=Old (SMIv2), N=New (SMI-DS) 2063 dsmonAggGroup scalars: 2064 dsmonMaxAggGroups 2065 O: dsmonAggObjects.1.0 2066 N: dsmonAggObjects.1.0 2067 dsmonAggControlLocked 2068 O: dsmonAggObjects.2.0 2069 N: dsmonAggObjects.2.0 2070 dsmonAggControlChanges 2071 O: dsmonAggObjects.3.0 2072 N: dsmonAggObjects.3.0 2073 dsmonAggControlLastChangeTime 2074 O: dsmonAggObjects.4.0 2075 N: dsmonAggObjects.4.0 2077 dsmonAggControlTable example for row 77: 2078 dsmonAggControlDescr 2079 O: dsmonAggObjects.5.1.2.77 2080 N: dsmonAggObjects.5.1.2.1.77 2082 dsmonAggControlOwner 2083 O: dsmonAggObjects.5.1.3.77 2084 N: dsmonAggObjects.5.1.2.4.77 2085 dsmonAggControlStatus 2086 O: dsmonAggObjects.5.1.3.77 2087 N: dsmonAggObjects.5.1.2.5.77 2089 dsmonAggProfileTable example for row 77.22: 2090 dsmonAggGroupIndex 2091 O: dsmonAggObjects.6.1.2.77.22 2092 N: dsmonAggObjects.5.1.2.2.2.77.22 2094 dsmonAggGroupTable example for row 77.44: 2095 dsmonAggGroupDescr 2096 O: dsmonAggObjects.7.1.1.77.44 2097 N: dsmonAggObjects.5.1.2.3.2.77.44 2098 dsmonAggGroupStatus 2099 O: dsmonAggObjects.7.1.2.77.44 2100 N: not needed because dsmonAggControlStatus 2101 controls an entire dsmonAggControl data object 2103 Note 2) Scalar object naming does not change at all 2105 Note 3) DSMON Counter Aggregation control requires three tables in SMIv2 2106 (dsmonAggObjects.5 - 7) and one in SMI-DS (dsmonAggObjects.5). This 2107 allows the subordinate RowStatus object (dsmonAggGroupStatus) to be 2108 removed. It also allows the agent to identify the complete hierarchical 2109 position of any object instance by inspection. These implementation 2110 benefits (and others) can help significantly to reduce the software 2111 development costs for complex MIBs. 2113 Note 4) Aggregate object descriptors have to be fully qualified, for 2114 each VAR declaration. Need to consider a shorthand notation in next 2115 version of SMI-DS. 2117 10. Appendix C: Open Issues 2119 The following open issues (in no particular order) need to be addressed. 2121 1) SPPI Merge 2123 The biggest issue is SPPI OID naming. Experts in COPS-PR and SPPI 2124 should determine how SPPI naming, tabular data model, and various SPPI 2125 clauses should be integrated into SMI-DS. This should be done in a way 2126 that does not impact the overall complexity or ease of use as an SMIv2 2127 replacement, possibly contained in a separate document. 2129 2) Conformance Granularity 2131 The concept of MIB conformance may need to change to better handle the 2132 complexity created by the type definition and containment features of 2133 SMI-DS. MODULE-COMPLIANCE macros for complex data objects may need to 2134 allow for automatic conformance update mechanisms. The 'copy-by- 2135 reference' property of nested data structures needs to somehow translate 2136 to the conformance section. E.g., if 'fooObject1' is deprecated and 2137 updated with 'fooObject2' in the 'FooStruct', then the update occurs 2138 everywhere a 'FooStruct' is nested. The MODULE-COMPLIANCE needs to be 2139 updated somehow for every VAR declaration that is, or has an embedded 2140 'FooStruct'. 2142 3) Conformance Instance Overlap 2144 Since descriptors can occur in TYPEDEFs, they are not unique for 2145 conformance purposes (as raised by Randy Presuhn in SLC). An efficient 2146 MODULE-COMPLIANCE mechanism is needed to provide conformance info for 2147 each VAR and NOTIFICATION declaration, not for each accessible object 2148 descriptor. This way, object descriptors can have different conformance 2149 requirements at the granularity of the VAR macro. 2151 4) SMIv2 Merge Issues 2153 Sections 3 - 10 of RFC 2578 need to be adapted and added into this 2154 document. The extensive set of implementation rules and guidelines needs 2155 to be updated and clarified. Complete 'ASN.1 free' syntax needs to be 2156 finished, along with the SMIv2 compatibility and transformation 2157 guidelines. 2159 5) Base Data Type Extensions 2161 The data types defined in the 'SMIng Core Modules' document should be 2162 used by this document somehow. 2164 6) SMI Syntax 2166 Although it is tempting to completely change the syntax for the data 2167 definition language to benefit potential 'new users', this would 2168 increase overall complexity for new and old users of the SMI. There are 2169 many more MIB modules now then April 1993, when SMIv2 was first 2170 published as RFC 1442. It took years to convert all the standards track 2171 modules from SMIv1 to SMIv2, and it will probably take years to convert 2172 them all from SMIv2 to SMIv3. During the transition, operators and 2173 developers need to know both syntax variants, and it will help a great 2174 deal if they are similar to each other. 2176 7) STATUS clause for aggregate data objects 2178 It may be useful to have a STATUS clause for an entire aggregate TYPEDEF 2179 or VAR construct, which overrides the status of any of the individual 2180 nodes within that aggregate. This would allow a simpler way to 2181 deprecate the entire object when needed. 2183 11. Appendix D: Discussion of SMIng Objectives 2185 This section lists each accepted design objective described in the SMIng 2186 Objectives document [SMING_OBJ], and explains how SMI-DS addresses the 2187 objective. 2189 4.1.1 The Set of Specification Documents [Yes] 2191 Description 2192 SMIv2 is defined in three documents, based on an obsolete ITU ASN.1 2193 specification. SPPI is defined in one document, based on SMIv2. 2194 The core of SMIng must be defined in one document and must be 2195 independent of external specifications. 2197 Fulfillment 2198 SMI-DS can meet this objective by simply placing as much text as 2199 desired in a single document. 2201 4.1.2 Textual Representation [Yes] 2203 Description 2204 SMIng definitions must be represented in a textual format. 2206 Fulfillment 2207 SMI-DS meets this objective because it is specified using only 2208 textual characters. 2210 4.1.3 Human Readability [Yes] 2212 Description 2213 The syntax must make it easy for humans to directly read and write 2214 SMIng modules. It must be possible for SMIng module authors to 2215 produce SMIng modules with text editing tools. 2217 Fulfillment 2218 The SMI-DS syntax is very close (or identical) to SMIv2 in all 2219 respects, so it will be easy for MIB authors and readers to use. 2221 4.1.4 Rigorously Defined Syntax [Yes - TBD] 2223 Description 2224 There must be a rigorously defined syntax for the SMIng language. 2226 Fulfillment 2227 Once the features (and the syntax for those features) are 2228 finalized, all SMI-DS constructs will be rigorously defined, 2229 including the constructs which do not change from SMIv2. 2231 4.1.5 Accessibility [Yes] 2233 Description 2234 Attribute definitions must indicate whether attributes can be read, 2235 written, created, deleted, and whether they are accessible for 2236 notifications, or are not accessible. Align PIB-ACCESS and MAX- 2237 ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS. 2239 Fulfillment 2240 The MAX-ACCESS clause is retained from SMIv2. PIB versions of these 2241 constructs do not really differ in semantics, just in name. PIBs 2242 and MIBs use the same MAX-ACCESS clause. 2244 4.1.6 Language Extensibility [Maybe] 2246 Description 2247 The language must have characteristics, so that future modules can 2248 contain information of future syntax without breaking original 2249 SMIng parsers. 2251 Fulfillment 2252 Although this objective benefits very few people, it can be 2253 achieved by rigorously defining the SMI-DS syntax so that a parser 2254 can always determine where a construct begins and ends. 2256 4.1.7 Special Characters in Text [No] 2258 Description 2259 Allow an escaping mechanism to encode special characters, e.g., 2260 double quotes and new-line characters, in text such as DESCRIPTIONs 2261 or REFERENCEs. 2263 Fulfillment 2264 Currently there are no mechanisms added to these SMIv2 constructs 2265 used without modification in SMI-DS. It is not clear why forcing 2266 the author to use single quotes is unreasonable. Not sure why this 2267 is a problem. Adding cryptic character sequences conflicts with 2268 objective 4.1.3. 2270 4.1.8 Naming [Yes] 2272 Description 2273 SMIng must provide mechanisms to uniquely identify attributes, 2274 groups of attributes, and events. It is necessary to specify how 2275 name collisions are handled. 2277 Fulfillment 2278 SMI-DS meets all these requirements. Namespaces are handled the 2279 same as in SMIv2. 2281 4.1.9 Namespace Control [Yes] 2283 Description 2284 There must be a hierarchical, centrally-controlled namespace for 2285 standard named items, and a distributed namespace must be supported 2286 to allow vendor-specific naming and to assure unique module names 2287 across vendors and organizations. 2289 Fulfillment 2290 SMI-DS meets this requirement by providing true hierarchical 2291 naming, which is compatible with SMIv2 objects. Enterprise-specific 2292 definitions and augmentations are supported. 2294 4.1.10 Modules [Yes] 2296 Description 2297 SMIng must provide a mechanism for uniquely identifying a module, 2298 and specifying the status, contact person, revision information, 2299 and the purpose of a module. SMIng must provide mechanisms to 2300 group definitions into modules and it must provide rules for 2301 referencing definitions from other modules. 2303 Fulfillment 2304 SMI-DS information modules are conceptually identical to SMIv2 2305 information modules, including the IMPORTS clause. 2307 4.1.11 Module Conformance [Yes] 2309 Description 2310 SMIng must provide mechanisms to detail the minimum requirements 2311 implementers must meet to claim conformance to a standard based on 2312 the module. 2314 Fulfillment 2315 SMI-DS conformance constructs (such as MAX-ACCESS, MODULE- 2316 COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP) are mostly unchanged 2317 from SMIv2. 2319 4.1.12 Arbitrary Unambiguous Identities [Yes] 2321 Description 2322 SMI allows the use of OBJECT-IDENTITIES to define unambiguous 2323 identities without the need of a central registry. SMI uses OIDs 2324 to represent values that represent references to such identities. 2325 SMIng needs a similar mechanism (a statement to register 2326 identities, and a base type to represent values). 2328 Fulfillment 2329 Base type semantics (including OBJECT IDENTIFIER) are unchanged 2330 from SMIv2. 2332 4.1.13 Protocol Independence [Yes - TBD] 2334 Description 2335 SMIng must define data definitions in support of the SNMP and COPS- 2336 PR protocols. SMIng may define data definitions in support of 2337 other protocols. 2339 Fulfillment 2340 SMI-DS is fully compatible with SMIv2 and the SNMP protocol. 2341 Specific mapping algorithms for COPS-PR object naming are TBD. 2343 4.1.14 Protocol Mapping [Yes] 2345 Description 2346 The SMIng working group, in accordance with the working group 2347 charter, will define mappings of protocol independent data 2348 definitions to protocols based upon installed implementations. The 2349 SMIng working group can define mappings to other protocols as long 2350 as this does not impede the progress on other objectives. 2352 Fulfillment 2353 As long as the protocol is actually independent of the data 2354 definition language and its naming scheme (as advertised with 2355 SNMP), accessible data objects (i.e., LEAF objects) can be 2356 manipulated in the same manner as accessible SMIv2 objects. 2358 4.1.15 Translation to Other Data Definition Languages [Yes - TBD] 2360 Description 2361 SMIng language constructs must, wherever possible, be translatable 2362 to SMIv2 and SPPI. At the time of standardization of a SMIng 2363 language, existing SMIv2 MIBs and SPPI PIBs on the standards track 2364 will not be required to be translated to the SMIng language. New 2365 MIBs/PIBs will be defined using the SMIng language. 2367 Fulfillment 2368 Algorithms can be specified to convey each SMI-DS construct to one 2369 or more SMIv2 constructs. Complex nesting must be unfolded into a 2370 set of associated SMIv2 tables, each table corresponding to the 2371 accessible objects at a given nest level of the SMI-DS object. 2372 Existing SMIv2 tables can easily be converted to SMI-DS using the 2373 ARRAY construct. 2375 4.1.16 Base Data Types [Yes] 2377 Description 2378 SMIng must support the base data types Integer32, Unsigned32, 2379 Integer64, Unsigned64, Enumeration, Bits, OctetString, and OID. 2381 Fulfillment 2382 The SMIv2 base data types are unchanged in SMI-DS. The Integer64 2383 and Unsigned64 base data types will also be added. 2385 4.1.17 Enumerations [Yes] 2387 Description 2388 SMIng must provide support for enumerations. Enumerated values 2389 must be a part of the enumeration definition. 2391 Fulfillment 2392 SMI-DS provides enumerated INTEGERs, unchanged from SMIv2. 2394 4.1.18 Discriminated Unions [Yes] 2395 Description 2396 SMIng must support discriminated unions. 2398 Fulfillment 2399 SMI-DS provides the UNION construct to explicitly define (in a 2400 manner that can be machine-parsed) a group of objects with the 2401 characteristics of a discriminated union. A STRUCT can be defined 2402 which includes the discriminator LEAF object and the UNION object, 2403 to further express these semantics. (See HostInetAddress example in 2404 section 5.6.1). 2406 4.1.19 Instance Pointers [Yes] 2408 Description 2409 SMIng must allow specifying pointers to instances (i.e., a pointer 2410 to a particular attribute in a row). 2412 Fulfillment 2413 The concept of a 'row' does not apply to SMI-DS, only to SMIv2, 2414 however OBJECT IDENTIFIER data objects can point to accessible 2415 SMIv2 tabular objects, and object names for SMIv2 tables do not 2416 change when translated to SMI-DS format. 2418 4.1.20 Row Pointers [Yes] 2420 Description 2421 SMIng must allow specifying pointers to rows. 2423 Fulfillment 2424 The concept of a 'row' does not apply to SMI-DS, only to SMIv2, 2425 however OBJECT IDENTIFIER data objects can point to SMIv2 rows, and 2426 object names for SMIv2 tables do not change when translated to SMI- 2427 DS format. 2429 4.1.21 Constraints on Pointers [Yes] 2431 Description 2432 SMIng must allow specifying the types of objects to which a pointer 2433 may point. 2435 Fulfillment 2436 A new variant of the SYNTAX clause is defined which restricts a 2437 particular data type that the OID pointer. E.g., "SYNTAX POINTER 2438 FooObject" or "SYNTAX POINTER InetAddress", would actually define 2439 an OBJECT IDENTIFIER. 2441 4.1.22 Base Type Set [Yes] 2443 Description 2444 SMIng must support a fixed set of base types of fixed size and 2445 precision. The list of base types must not be extensible unless 2446 the SMI itself changes. 2448 Fulfillment 2449 SMI-DS uses a fixed set of base data types. 2451 4.1.23 Extended Data Types [Yes] 2453 Description 2454 SMIng must support a mechanism to derive new types, which provide 2455 additional semantics (e.g., Counters, Gauges, Strings, etc.), from 2456 base types. It may be desirable to also allow the derivation of 2457 new types from derived types. New types must be as restrictive or 2458 more restrictive than the types that they are specializing. 2460 Fulfillment 2461 SMI-DS provides the TYPEDEF construct to specify complex or derived 2462 data types. LEAF definitions can derive attributes from a base type 2463 or another derived type. 2465 4.1.24 Units, Formats, and Default Values of Defined Types and 2466 Attributes [Yes] 2468 Description 2469 In SMIv2 OBJECT-TYPE definitions may contain UNITS and DEFVAL 2470 clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-HINTs. In a 2471 similar fashion units and default values must be applicable to 2472 defined types and format information must be applicable to 2473 attributes. 2475 Fulfillment 2476 SMI-DS retains the UNITS, DEFVAL, and DISPLAY-HINT clauses for all 2477 LEAF data type definitions and variable declarations. 2479 4.1.25 Table Existence Relationships [Yes] 2481 Description 2482 SMIng must support INDEX, AUGMENTS, and EXTENDS in the SNMP/COPS-PR 2483 protocol mappings. 2485 Fulfillment 2486 These concepts have been included in SMI-DS, and AUGMENTS has been 2487 extended to any non-LEAF TYPEDEF. The EXTENDS construct is 2488 achieved by simply augmenting an existing ARRAY with a another 2489 (nested) ARRAY. 2491 4.1.26 Table Existence Relationships [Yes] 2493 Description 2494 SMIng must support EXPANDS and REORDERS relationships in the 2495 SNMP/COPS-PR protocol mappings. 2497 Fulfillment 2498 SMI-DS is not a table-oriented data definition language like SMIv2 2499 or SPPI. Aggregated data objects are defined in a nested manner to 2500 convey a hierarchical relationship. The EXPANDS and REORDERS 2501 clauses are only meaningful in this table-oriented framework. 2502 However, the DESCRIPTION clause is provided to express semantics 2503 such as EXPANDS and REORDERS. 2505 4.1.27 Attribute Groups [Yes] 2507 Description 2508 An attribute group is a named, reusable set of attributes that are 2509 meaningful together. It can be reused as the type of attributes in 2510 other attribute groups (see also Section 4.1.28). This is similar 2511 to `structs' in C. 2513 Fulfillment 2514 SMI-DS provides the STRUCT macro for this purpose. 2516 4.1.28 Containment [Yes] 2518 Description 2519 SMIng must provide support for the creation of new attribute groups 2520 from attributes of more basic types and potentially other attribute 2521 groups. 2523 Fulfillment 2524 SMI-DS allows arbitrary nesting of STRUCT, ARRAY, and UNION type 2525 definitions. 2527 4.1.29 Single Inheritance [Yes] 2528 Description 2529 SMIng must provide support for mechanisms to extend attribute 2530 groups through single inheritance. 2532 Fulfillment 2533 SMI-DS allows new aggregate types to contain other aggregated 2534 types, by reference, i.e., the contained data object inherits all 2535 attributes from the type as defined in another TYPEDEF (and 2536 AUGMENTS, if any). 2538 4.1.30 Reusable vs. Final Attribute Groups [Yes] 2540 Description 2541 SMIng must differentiate between "final" and reusable attribute 2542 groups, where the reuse of attribute groups covers inheritance and 2543 containment. 2545 Fulfillment 2546 SMI-DS provides the TYPEDEF macro to create reusable definitions, 2547 and variable declarations to identify 'final' attribute groups. 2549 4.1.31 Events [Yes] 2551 Description 2552 SMIng must provide mechanisms to define events which identify 2553 significant state changes. 2555 Fulfillment 2556 The NOTIFICATION macro is used (slightly modified NOTIFICATION-TYPE 2557 macro. 2559 4.1.32 Creation/Deletion [Maybe] 2561 Description 2562 SMIng must support a mechanism to define creation/deletion 2563 operations for instances. Specific creation/deletion errors, such 2564 as INSTALL-ERRORS, must be supported. 2566 Fulfillment 2567 A new data objected RowStatus could be defined, or the existing 2568 RowStatus simply used 'as-is' with data objects. This objective is 2569 very 'table-oriented' and protocol-specific. SMI-DS is intended to 2570 be protocol-independent. 2572 4.1.33 Range and Size Constraints [Yes] 2574 Description 2575 SMIng must allow specifying range and size constraints where 2576 applicable. 2578 Fulfillment 2579 The SYNTAX clause is unchanged from SMIv2, which includes a range 2580 construct. 2582 4.1.34 Uniqueness [Maybe] 2584 Description 2585 SMIng must allow the specification of uniqueness constraints on 2586 attributes. SMIng must allow the specification of multiple 2587 independent uniqueness constraints. 2589 Fulfillment 2590 Instance identifiers are of course unique. The DESCRIPTION clause 2591 is available to specify uniqueness characteristics for any LEAF 2592 data type or INDEX component. 2594 4.1.35 Extension Rules [No] 2596 Description 2597 SMIng must provide clear rules how one can extend SMIng modules 2598 without causing interoperability problems "over the wire". 2600 Fulfillment 2601 The final version of SMI-DS will include a rigorous syntax, but 2602 there are no plans for an explicit EXTENSION construct, to allow 2603 SMI-DS to be extended in an distributed and uncontrolled manner. 2604 The SMI should only be changed in very careful and controlled 2605 manner, by an IETF WG (e.g., SMIng). 2607 4.1.36 Deprecate Use of IMPLIED Keyword [Yes] 2609 Description 2610 The SMIng SNMP mapping must deprecate the use of the IMPLIED 2611 indexing schema. 2613 Fulfillment 2614 The IMPLIED keyword is deprecated in the SMI-DS INDEX construct. 2616 4.1.37 No Redundancy [Yes] 2618 Description 2619 The SMIng language must avoid redundancy. 2621 Fulfillment 2622 SMI-DS remove any clause that is always the same value in all 2623 situations (e.g., MAX-ACCESS clause for the fooTable and fooEntry 2624 OBJECT-TYPE macros is always not-accessible, so only LEAF data 2625 objects have a MAX-ACCESS clause). The 'fooEntry' definition is 2626 removed entirely, and since SMI-DS is data object, not table 2627 oriented, there is no need for the ASN.1 'FooEntry SEQUENCE' 2628 construct. Basic containment relationships are implied by the 2629 aggregated data types themselves (nested ARRAY, UNION, STRUCT) 2630 rather than by using lots of verbose OBJECT-TYPE DESCRIPTION 2631 clauses to declare the containment relationships between various 2632 OBJECT-TYPE macros. 2634 4.1.38 Compliance and Conformance [Yes] 2636 Description 2637 SMIng must provide a mechanism for compliance and conformance 2638 specifications for protocol-independent definitions as well as for 2639 protocol mappings. 2641 Fulfillment 2642 The SMI-DS module compliance section is unchanged from SMIv2. Just 2643 like SMIv2, only accessible (LEAF) objects are listed in this 2644 section. 2646 4.1.39 Allow Refinement of All Definitions in Conformance Statements 2647 [Yes - TBD] 2649 Description 2650 SMIv2, RFC 2580, Section 3.1 says: The last sentence 2651 forbids to put a not-accessible INDEX object into an OBJECT-GROUP. 2652 Hence, you can not refine its syntax in a compliance definition. 2653 For more details, see http://www.ibr.cs.tu-bs.de/ietf/smi-errata/. 2655 Fulfillment 2656 The arbitrary rules for SMIv2 can be changed, as they are adapted 2657 to SMI-DS. It is understood that every SMIv2 construct used in SMI- 2658 DS is subject to bugfixes. 2660 4.1.40 Categories [No] 2662 Description 2663 SMIng must provide a mechanism to group definitions into subject 2664 categories. Concrete instances may only exist in the scope of a 2665 given subject category or context. 2667 Fulfillment 2668 SMI-DS currently has no such construct. This would require 2669 management and coordination of the set of categories, and therefore 2670 further thought. Such a construct could be added if required. 2672 4.1.41 Core Language Keywords vs. Defined Identifiers [No - TBD] 2674 Description 2675 In SMI and SPPI modules some language keywords (macros and a number 2676 of basetypes) have to be imported from different SMI language 2677 defining modules, e.g., OBJECT-TYPE, MODULE-IDENTITY, Integer32 2678 must to be imported from SNMPv2-SMI and TEXTUAL- CONVENTION must be 2679 imported from SNMPv2-TC, if used. MIB authors are continuously 2680 confused about these import rules. In SMIng only defined 2681 identifiers must be imported. All SMIng language keywords must be 2682 implicitly known and there must not be a need to import them from 2683 any module. 2685 Fulfillment 2686 Currently, the SMI-DS IMPORTS clause is unchanged from SMIv2. It 2687 would be a mistake to forbid IMPORTS of base data types, since this 2688 is just one more thing for authors to get wrong. The burden of 2689 listing all external definitions, including base types, in the 2690 IMPORTS clause is not a problem worth solving. The SMI-DS rules 2691 could be changed to make IMPORTS of base types forbidden, optional, 2692 or mandatory, whatever is required. 2694 4.1.42 Instance Naming [Maybe - TBD] 2696 Description 2697 Instance naming in SMIv2 and SPPI is different. SMIng must align 2698 the instance naming (either in the protocol neutral model or the 2699 protocol mappings). 2701 Fulfillment 2702 SMI-DS instance naming is compatible with SMIv2. It is not clear 2703 what additions are needed to support SPPI naming as well. 2705 4.1.43 Length of Identifiers [Yes - TBD] 2707 Description 2708 The allowed length of the various kinds of identifiers must be 2709 extended from the current `should not exceed 32' (maybe even from 2710 the `must not exceed 64') rule. 2712 Fulfillment 2713 All the arbitrary SMIv2 rules are subject to removal or repair as 2714 they are transferred to SMI-DS. The maximum descriptor length an 2715 agent must accept will be extended to 64. 2717 4.1.44 Assign OIDs in the Protocol Mappings [No] 2719 Description 2720 SMIng must not assign OIDs to reusable definition of attributes, 2721 attribute groups, events, etc. Instead, SNMP and COPS-PR mappings 2722 must assign OIDs to the mapped items. 2724 Fulfillment 2725 Although TYPEDEF definitions actually meet this requirement because 2726 only variable declarations can have complete OID assignments, it 2727 would be a critical mistake to separate data object naming from the 2728 data definition itself. There is no justification whatsoever for 2729 the management transport protocol to dictate the naming 2730 characteristics of the data definition language. 2732 4.2.1 Methods [No] 2734 Description 2735 SMIng should support a mechanism to define method signatures 2736 (parameters, return values, exception) that are implemented on 2737 agents. 2739 Fulfillment 2740 SMI-DS defines a data definition language with sufficient power to 2741 be used as a platform for object-oriented network management 2742 definitions in the future (ala C --> C++ transition). 2744 4.2.2 Unions [Yes] 2746 Description 2747 Allows an attribute to contain one of many types of values. The 2748 lack of unions has also lead to relatively complex sparse table 2749 work-around in some DISMAN mid-level managers. Despite from 2750 discriminated unions (see Section 4.1.18), this kind of union has 2751 no accompanied explicit discriminator attribute that selects the 2752 union's type of value. 2754 Fulfillment 2755 SMI-DS provides the UNION macro for this purpose. 2757 4.2.3 Float Data Types [Yes] 2759 Description 2760 SMIng should support the base data types Float32, Float64, 2761 Float128. 2763 Fulfillment 2764 SMI-DS will support a Float data type. Is is not clear that 3 2765 variants are needed though. 2767 4.2.4 Comments [Yes] 2769 Description 2770 The syntax of comments should be well defined, unambiguous and 2771 intuitive to most people, e.g., the C++/Java `//' syntax. 2773 Fulfillment 2774 The ASN.1 comment meets these requirements and is used unchanged 2775 from SMIv2. There is no community requirement to use Java style 2776 comments. The use of 2 dashes for a 'start of comment' token is not 2777 any better or worse than 2 slashes. Not a change worth making. 2779 4.2.5 Referencing Tagged Rows [No] 2781 Description 2782 PIB and MIB row attributes reference a group of entries in another 2783 table. SPPI formalizes this by introducing PIB-TAG and PIB- 2784 REFERENCES clauses. This functionality should be retained in 2785 SMIng. 2787 Fulfillment 2788 SMI-DS does not use a table-oriented data model, so these 2789 constructs do not apply. 2791 4.2.6 Arrays [Yes] 2793 Description 2794 SMIng should allow the definition of a SEQUENCE OF attributes or 2795 attribute groups (Section 4.1.27). 2797 Fulfillment 2798 SMI-DS provides the ARRAY macro for this purpose. 2800 4.2.7 Internationalization [No - TBD] 2802 Description 2803 Informational text (DESCRIPTION, REFERENCE, ...) should allow 2804 i18nized encoding, probably UTF-8. 2806 Fulfillment 2807 SMI-DS used the DESCRIPTION and REFERENCE clauses unchanged from 2808 SMIv2. Changes to these clauses could be made if required, but 2809 unless standard (IETF) information modules are written in a 2810 language other than English, this only applies to vendor MIBs. 2812 4.2.8 Separate Data Modelling from Management Protocol Mapping [Yes] 2814 Description 2815 It should be possible to separate the domain specific data 2816 modelling work from the network management protocol specific work. 2818 Fulfillment 2819 The SMI-DS data definitions are protocol independent. Mappings 2820 (where applicable) will be defined for SNMP, because SMIv2 is 2821 intended to function with SNMP, and SMI-DS is intended to replace 2822 SMIv2. Mapping rules for other protocols are certainly possible, 2823 but are not included in this document. 2825 12. Security Considerations 2827 This document defines a structure for management data and therefore does 2828 not expose any management information from a particular device. However, 2829 accessible data objects defined with the mechanisms defined in this 2830 document should be given the same security consideration as objects 2831 specified with SMIv2, when being transferred with SNMP. 2833 SNMPv1 by itself is not a secure environment. Even if the network 2834 itself is secure (for example by using IPSec), even then, there is no 2835 control as to who on the secure network is allowed to access and GET/SET 2836 (read/change/create/delete) the objects in this MIB. 2838 It is recommended that the implementors consider the security features 2839 as provided by the SNMPv3 framework. Specifically, the use of the User- 2840 based Security Model RFC 2574 [RFC2574] and the View-based Access 2841 Control Model RFC 2575 [RFC2575] is recommended. 2843 It is then a customer/user responsibility to ensure that the SNMP entity 2844 giving access to an instance of this MIB, is properly configured to give 2845 access to the objects only to those principals (users) that have 2846 legitimate rights to indeed GET or SET (change/create/delete) them. 2848 13. Intellectual Property 2850 The IETF takes no position regarding the validity or scope of any 2851 intellectual property or other rights that might be claimed to pertain 2852 to the implementation or use of the technology described in this 2853 document or the extent to which any license under such rights might or 2854 might not be available; neither does it represent that it has made any 2855 effort to identify any such rights. Information on the IETF's 2856 procedures with respect to rights in standards-track and standards- 2857 related documentation can be found in BCP-11. Copies of claims of 2858 rights made available for publication and any assurances of licenses to 2859 be made available, or the result of an attempt made to obtain a general 2860 license or permission for the use of such proprietary rights by 2861 implementors or users of this specification can be obtained from the 2862 IETF Secretariat. 2864 The IETF invites any interested party to bring to its attention any 2865 copyrights, patents or patent applications, or other proprietary rights 2866 which may cover technology that may be required to practice this 2867 standard. Please address the information to the IETF Executive 2868 Director. 2870 14. Acknowledgements 2872 This memo is a product of the SMIng Working Group. 2874 Portions of the existing SMI RFCs, SMIng drafts, and the ANSI C 2875 Programming Language inspired many of the concepts discussed in this 2876 memo. 2878 15. Normative References 2880 [RFC1905] 2881 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2882 Waldbusser, "Protocol Operations for Version 2 of the Simple 2883 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 2884 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2885 International Network Services, January 1996. 2887 [RFC1906] 2888 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2889 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 2890 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco 2891 Systems, Inc., Dover Beach Consulting, Inc., International Network 2892 Services, January 1996. 2894 [RFC2026] 2895 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2896 2026, Harvard University, October, 1996. 2898 [RFC2119] 2899 S. Bradner, "Key words for use in RFCs to Indicate Requirement 2900 Levels" RFC 2119, Harvard University, March 1997. 2902 [RFC2571] 2903 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2904 Describing SNMP Management Frameworks", RFC 2571, Cabletron 2905 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 2906 1999. 2908 [RFC2572] 2909 Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 2910 Processing and Dispatching for the Simple Network Management 2911 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, 2912 Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. 2914 [RFC2573] 2915 Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2916 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 2917 Systems, April 1999. 2919 [RFC2574] 2920 Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 2921 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2922 2574, IBM T. J. Watson Research, April 1999. 2924 [RFC2575] 2925 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 2926 Control Model (VACM) for the Simple Network Management Protocol 2927 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., 2928 Cisco Systems, Inc., April 1999. 2930 [RFC2578] 2931 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2932 and S. Waldbusser, "Structure of Management Information Version 2 2933 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 2934 Braunschweig, SNMP Research, First Virtual Holdings, International 2935 Network Services, April 1999. 2937 [RFC2579] 2938 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2939 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 2940 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 2941 Virtual Holdings, International Network Services, April 1999. 2943 [RFC2580] 2944 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2945 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 2946 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 2947 First Virtual Holdings, International Network Services, April 1999. 2949 16. Informative References 2951 [DSMON-MIB] 2952 Bierman, A., "Remote Monitoring MIB Extensions for Differentiated 2953 Services", Work in progress (draft-ietf-rmonmib-dsmon-mib-09.txt), 2954 Cisco Systems, Inc., November 2001. 2956 [RFC1155] 2957 Rose, M., and K. McCloghrie, "Structure and Identification of 2958 Management Information for TCP/IP-based Internets", RFC 1155, 2959 Performance Systems International, Hughes LAN Systems, May 1990. 2961 [RFC1157] 2962 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2963 Management Protocol", RFC 1157, SNMP Research, Performance Systems 2964 International, Performance Systems International, MIT Laboratory 2965 for Computer Science, May 1990. 2967 [RFC1212] 2968 Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 2969 Performance Systems International, Hughes LAN Systems, March 1991. 2971 [RFC1215] 2972 M. Rose, "A Convention for Defining Traps for use with the SNMP", 2973 RFC 1215, Performance Systems International, March 1991. 2975 [RFC1901] 2976 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2977 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 2978 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 2979 Inc., International Network Services, January 1996. 2981 [RFC2021] 2982 S. Waldbusser, "Remote Network Monitoring Management Information 2983 Base Version 2 using SMIv2", RFC 2021, INS, January 1997. 2985 [RFC2570] 2986 Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to 2987 Version 3 of the Internet-standard Network Management Framework", 2988 RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, 2989 Inc., Ericsson, Cisco Systems, April 1999. 2991 [RFC2737] 2992 McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, 2993 Cisco Systems, Inc., December 1999. 2995 [RFC2851] 2996 Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, 2997 "Textual Conventions for Internet Network Addresses", RFC 2851, 2998 Compaq Computer Corporation, Nortel Networks, Wind River Systems, 2999 Inc., TU Braunschweig, June 2000. 3001 [RFC2863] 3002 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC 3003 2863, Cisco Systems, Argon Networks, June, 2000. 3005 [RFC3216] 3006 Elliot, C., Harrington, D., Jason, J., Schoenwaelder, J., Strauss, 3007 F., and W. Weiss, "SMIng Objectives", RFC 3216, Cisco Systems, 3008 Enterasys Networks, Intel Corporation, TU Braunschweig, Ellacoya 3009 Networks, December 2001. 3011 17. Author's Address 3013 Andy Bierman 3014 Cisco Systems, Inc. 3015 170 West Tasman Drive 3016 San Jose, CA USA 95134 3017 Phone: +1 408-527-3711 3018 Email: abierman@cisco.com 3020 18. Full Copyright Statement 3022 Copyright (C) The Internet Society (2002). All Rights Reserved. 3024 This document and translations of it may be copied and furnished to 3025 others, and derivative works that comment on or otherwise explain it or 3026 assist in its implementation may be prepared, copied, published and 3027 distributed, in whole or in part, without restriction of any kind, 3028 provided that the above copyright notice and this paragraph are included 3029 on all such copies and derivative works. However, this document itself 3030 may not be modified in any way, such as by removing the copyright notice 3031 or references to the Internet Society or other Internet organizations, 3032 except as needed for the purpose of developing Internet standards in 3033 which case the procedures for copyrights defined in the Internet 3034 Standards process must be followed, or as required to translate it into 3035 languages other than English. 3037 The limited permissions granted above are perpetual and will not be 3038 revoked by the Internet Society or its successors or assigns. 3040 This document and the information contained herein is provided on an "AS 3041 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 3042 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 3043 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 3044 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3045 FITNESS FOR A PARTICULAR PURPOSE.