idnits 2.17.00 (12 Aug 2021) /tmp/idnits2251/draft-bierman-sming-ds-03.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. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 (14 May 2002) is 7311 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 1058 -- Looks like a reference, but probably isn't: '1' on line 994 -- Looks like a reference, but probably isn't: '80' on line 994 == 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) == Outdated reference: draft-ietf-rmonmib-dsmon-mib has been published as RFC 3287 -- 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: 14 errors (**), 0 flaws (~~), 7 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 14 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. To avoid confusion, the term appears 180 in capital letters when referring to any data object definition 181 which represents a base type. 183 SMI Data Structure (SMI-DS) 184 This term refers to the concepts and definitions defined in this 185 document. 187 5.2. Design Objectives 189 The working group objectives for this work are detailed in the SMIng 190 Objectives document [RFC3216]. (Refer to Appendix D for a detailed 191 discussion of each accepted objective.) 193 The primary high-level design goals of this work are: 195 - Significantly enhance the usefulness of the SMI as a network 196 management data definition language, by creating a modern 197 programming language like data model supporting aggregated 198 containment. 200 - Enhance SMI object instance naming to support aggregated 201 hierarchical data structures, while remaining backwardly-compatible 202 with SMIv2 naming. 204 - Improve readability by enhancing reusability and removing as much 205 redundant text as possible. The SMI should be as easy to use as 206 possible, for the largest number of people. Therefore, a priority 207 hierarchy can be established, starting with MIB readers, then MIB 208 writers, management software developers, and MIB compiler writers. 210 - Maintain 100% forward and backward translation compatibility with 211 SMIv2. It must be possible to convert all valid SMIv2 constructs 212 to SMI-DS constructs without loss of semantics (i.e., forward 213 compatibility). It should also be possible to translate any SMI-DS 214 construct to one or more SMIv2 constructs, if the associated 215 feature(s) exist in SMIv2. Refer to Appendix A for details on 216 SMIv2 <--> SMI-DS translations. 218 - Preserve as many of the SMIv2 mechanisms and 'installed knowledge- 219 base' as possible. There will a transition period lasting several 220 years, in which SMIv2 MIBs will be converted to SMIv3 format. It 221 is important that MIB readers and writers be able to understand 222 both SMI syntaxes during this period, and so it will be beneficial 223 to keep them as close as possible. Clauses that have not changed 224 at all in semantics between SMI versions should maintain the same 225 syntax. 227 - Make sure accessible data objects (i.e., LEAF objects) can be used 228 with existing versions of SNMP. 230 There are some relevant topics which not design objectives addressed by 231 this draft: 233 - Compatibility with any version of ASN.1. 235 - Equally weighted importance for support of COPS-PR and SNMP. There 236 is a huge disparity in deployment of applications utilizing these 237 protocols. The solution space is biased in favor of SNMP because 238 that will benefit the largest number of people. 240 - Idiot proof MIB design. Data structures can help better organize 241 the information found in a MIB, but they cannot prevent bad design 242 choices or badly written DESCRIPTION clauses. 244 5.3. Data Structure Constructs 246 There are four basic constructs available in the SMI-DS language for the 247 definition of data objects. 249 LEAF This construct is conceptually equivalent to an OBJECT-TYPE macro 250 definition for an accessible MIB object in SMIv2, except a LEAF can 251 be defined at any level of containment. A LEAF type definition or 252 variable declaration resolves to any SMIng base type. In SMI-DS, 253 all other constructs must eventually resolve to some number of 254 these objects, and only LEAF data objects are actually accessible 255 via SNMP. 257 ARRAY 258 This construct provides a multi-dimensional array structure, 259 similar to the SEQUENCE construct in SMIv2. However, instead of 260 one flat 'row' consisting of only accessible base-type MIB objects, 261 an ARRAY can consist of an arbitrary mix of any of the four types 262 of data object constructs. Only base type data objects can be used 263 in an ARRAY INDEX clause (the same ones as in SMIv2), and the rules 264 for encoding INDEX clause base types in OIDs are the same as for 265 SMIv2. 267 UNION 268 This construct provides a mechanism to conceptually allow a single 269 object definition to contain one of potentially several different 270 construct definitions. Only one of these constructs is actually 271 instantiated at any time by the agent. Unlike a union in the C 272 language, the unused union members cannot be accessed at all (no 273 'cast' operator in SMI). 275 STRUCT 276 This construct provides a mechanism to group an arbitrary number of 277 data constructs (of any type), allowing a theoretically unlimited 278 number of data containment layers. It is similar to the ARRAY 279 construct, except there is no INDEX clause. 281 5.4. Relationship to SMIv2 283 Whenever possible, existing SMIv2 macros or clauses have been used 284 without modification. Two exceptions are the TEXTUAL-CONVENTION and 285 OBJECT-TYPE macros. In order to reinforce and support a data model more 286 aligned with popular programming concepts and practices, these macros 287 have been replaced by the TYPEDEF and VAR macros (respectively). Strong 288 emphasis is placed on the separation of potentially reusable type 289 definitions and variable declarations. The ASN.1 tabular data model is 290 replaced with a 'hierarchical containment' data model, which is more 291 similar to the 'native' data representation used by the managed device. 293 The type of declarations that can be made in an SMI-DS module do not 294 really change at all, but some constructs have changed. The major 295 differences between an SMIv2 construct and the equivalent SMI-DS 296 construct are listed in the table below: 298 SMIv2 SMI-DS 299 --------------------- --------------------- 300 TEXTUAL-CONVENTION TYPEDEF LEAF 301 scalar OBJECT-TYPE VAR LEAF 302 tabular OBJECT-TYPE VAR ARRAY 303 NOTIFICATION-TYPE NOTIFICATION 305 Notification semantics have not changed at all, although the syntax has 306 changed slightly to make them more consistent with the TYPEDEF and VAR 307 macros. The ASN.1 specific SEQUENCE macro, and the 'FooTable' and 308 'FooEntry' OBJECT-TYPE definitions that start every SMIv2 table are 309 removed. The basic SYNTAX clause has not changed at all, except that a 310 new variant is provided to specify a typed OID pointer (see section 311 5.8). 313 Many constructs do not change at all, such as the IMPORTS, MODULE- 314 IDENTITY, MAX-ACCESS, STATUS, DESCRIPTION, REFERENCE, DEFVAL, OBJECTS, 315 and MODULE-COMPLIANCE macros. 317 5.5. Hierarchical Instance Naming 319 In order to fully utilize the capabilities of arbitrary containment, a 320 new way of naming object instances is needed, which is designed for 321 hierarchical data structures instead of tables, without changing the OID 322 values for any existing SMIv2 objects which are converted to the SMI-DS 323 object naming format. 325 Since it is possible for accessible objects to exist in the same 326 containment structure as non-accessible objects, it is not possible to 327 name SMI-DS objects with a 'flat' model. SMIv2 assumes all accessible 328 objects in the same containment structure have the same number of object 329 identifier components, and the exact same format for all instance 330 identifier components. This assumption cannot be made for SMI-DS object 331 naming. 333 This new naming scheme can help reduce implementation complexity for 334 agent and application developers for SNMP Set operations. Currently, 335 associated attributes can be spread across multiple tables, (possibly 336 sharing major indexes) each with their own RowStatus and set of 'SNMP 337 callback' functions. This design approach can get relatively 338 complicated, especially if 'createAndWait' and 'notInService' RowStatus 339 values are supported. By allowing aggregated containment instead of 340 unfolding data structures into tables, implementation of high-level Set 341 operations can be simplified for both agent and application developers. 343 The basic format of an OID for an SMI-DS data object is not changed from 344 SMIv2. OIDs are constructed left to right. The left fragment contains 345 static OID values which indicate the name of a node in the MIB tree. 346 The right fragment contains potentially dynamic OID values which 347 represent the instance identifier for the node specified by the left 348 fragment. 350 LEAF Data Object Naming 351 ----------------------- 353 A SCALAR variable declaration is named as follows: 355 .0 357 where: 359 is a well-formed OID base fragment. 361 Aggregate Data Object Naming 362 ---------------------------- 364 An Aggregated Data Object variable declaration is named 365 as follows: 367 .. 368 [. ...] [. ...] 370 where: 372 is a well-formed OID base fragment, 373 (also called the left anchor). 375 contains the value 1. 377 is the data object child node identifier, which 378 must be an INTEGER between 1 and 4294967295. (Similar 379 to a column identifier in an SMIv2 table.) 381 is present only if the variable declaration 382 resolves to a type that contains any ARRAY constructs, 383 and MUST be an INTEGER between 0 and 4294967295. 384 (Similar to an instance identifier in an SMIv2 table.) 386 SMI-DS OID Construction 387 ----------------------- 389 OIDs are constructed in an iterative manner, using two conceptual 390 buffers: 392 base buffer 393 used for building the static portion of an OID, left to right. 395 This buffer contains the , , and all 396 identifiers. 398 index buffer 399 used for building a sequence of ARRAY indexes, (left to right), 400 similar to the instance identifier portion of an SMIv2 OID for a 401 tabular object. This buffer contains all the 402 identifiers. 404 The expansion algorithm for is repeated if it represents an 405 aggregated data object. If it represents an ARRAY construct, then all 406 components for this array type are appended to index buffer. 408 The algorithm terminates when a LEAF data object is encountered. The 409 index buffer is then appended to the base buffer, to form the complete 410 instance identifier for a specific variable declaration. 412 5.6. SMI-DS Data Object Usage Examples 414 The following sections introduce some examples of simple data structures 415 that are currently achieved with relatively verbose text in TEXTUAL- 416 CONVENTION and OBJECT-TYPE DESCRIPTION clauses using SMIv2. Refer to 417 Appendix B for an example of a (somewhat) complete SMI-DS module. 419 5.6.1. InetAddress Example 421 The Internet Address textual conventions defined in the "Textual 422 Conventions for Internet Network Addresses" MIB module [RFC2851] defines 423 several variants of an Internet address (InetAddress), and a control 424 object (InetAddressType) to distinguish which variant is actually 425 present in an InetAddress object instance. This construct may be more 426 concisely and properly represented in SMI-DS by a structure containing 427 the control object and a union of all the address variants. 429 -- a union of all the InetAddress types 431 TYPEDEF UNION InetAddressUnion { 432 DESCRIPTION 433 "Internet address in 4 different representations." 435 LEAF ipUnknown { 436 SYNTAX OCTET STRING (SIZE (0..65535)) 437 MAX-ACCESS read-create 438 STATUS current 439 DESCRIPTION 440 "Represents an Internet address using an externally 441 defined format. The associated InetAddressType 442 object value is 'unknown(0)'." 443 } ::= 1 445 LEAF ipv4Addr { 446 SYNTAX InetAddressIPv4 447 MAX-ACCESS read-create 448 STATUS current 449 DESCRIPTION 450 "Represents an IPv4 Internet address. The 451 associated InetAddressType object value 452 is 'ipv4(1)'." 453 } ::= 2 455 LEAF ipv6Addr { 456 SYNTAX InetAddressIPv6 457 MAX-ACCESS read-create 458 STATUS current 459 DESCRIPTION 460 "Represents an IPv6 Internet address. The 461 associated InetAddressType object value 462 is 'ipv6(2)'." 463 } ::= 3 465 LEAF ipDnsAddr { 466 SYNTAX InetAddressDNS 467 MAX-ACCESS read-create 468 STATUS current 469 DESCRIPTION 470 "Represents an DNS domain name. The associated 471 InetAddressType object value is 'dns(16)'." 472 } ::= 4 473 } 475 TYPEDEF STRUCT HostInetAddress { 476 DESCRIPTION 477 "Internet address for an end-station host, adhering 478 to the SMIv2 'associated objects' design approach." 480 LEAF addrType { 481 SYNTAX InetAddressType 482 MAX-ACCESS read-create 483 STATUS current 484 DESCRIPTION 485 "The type of Internet address." 486 } ::= 1 488 UNION addr { 489 SYNTAX InetAddressUnion 490 STATUS current 491 DESCRIPTION 492 "The Internet address." 493 } ::= 2 494 } 496 VAR STRUCT myAddress { 497 SYNTAX HostInetAddress 498 MAX-ACCESS read-only 499 STATUS current 500 DESCRIPTION 501 "Internet address of this host." 502 } ::= { someBase 1 } 504 VAR UNION newAddress { 505 SYNTAX InetAddressUnion 506 MAX-ACCESS read-write 507 STATUS current 508 DESCRIPTION 509 "Example of the new way to represent a union variable, 510 without the use of an associated InetAddressType object." 511 } ::= { someBase 2 } 513 Note 1) The accessible object instances defined within this structure 514 (addrType, ipUnknown, ipv4Addr, ipv6Addr, etc.) have different lengths: 516 myAddress ::= { someBase 1 } 517 myAddress.addrType ::= { myAddress 1 1 } 518 myAddress.addr ::= { myAddress 1 2 } 519 myAddress.addr.ipUnknown ::= { myAddress 1 2 1 } 520 myAddress.addr.ipv4Addr ::= { myAddress 1 2 2 } 521 myAddress.addr.ipv6Addr ::= { myAddress 1 2 3 } 522 myAddress.addr.dnsAddr ::= { myAddress 1 2 4 } 524 newAddress ::= { someBase 2 } 525 newAddress.ipUnknown ::= { newAddress 1 1 } 526 newAddress.ipv4Addr ::= { newAddress 1 2 } 527 newAddress.ipv6Addr ::= { newAddress 1 3 } 528 newAddress.dnsAddr ::= { newAddress 1 4 } 530 Note 2) The mandatory MAX-ACCESS clause within a LEAF construct in a 531 TYPEDEF macro is used to specify the maximum access level that is 532 possible via a management protocol. The optional MAX-ACCESS clause 533 within a VAR macro is used to specify the constrained maximum access 534 level for that specific variable declaration, and must not specify a 535 higher access than declared within a TYPEDEF macro. (E.g., myAddress is 536 a read-only variable even though the LEAF nodes in the HostInetAddress 537 TYPEDEF are read-create. The same LEAF nodes used within the newAddress 538 variable declaration are read-write.) If an overall MAX-ACCESS clause 539 is not present in the VAR macro, then the values specified in the LEAF 540 nodes are used. 542 Note 3) The addrType field is not actually needed for simple variable 543 declarations, because UNION constructs are instantiated with at most one 544 accessible member. In the example above, a GetNext Request for 545 'myAddress.addr' or 'newAddress' will return only one type of 546 InetAddress string from the InetAddressUnion. The associated 547 InetAddressType variable is needed only when used together with the 548 InetAddress (generic string form) as INDEX components in an ARRAY. 550 Note 4) Just like a TEXTUAL-CONVENTION in SMIv2, a TYPEDEF has no 551 instances associated with it and therefore no MIB root assigned. It is 552 only when a a variable of a particular type is declared (and therefore 553 assigned a MIB root) that the full OID for a data object is known. 555 5.6.2. Generic High Capacity Counter Example 557 There are many MIBs that contain up to the three OBJECT-TYPE macro 558 definitions for every high capacity counter, in order to accommodate 559 SNMPv1 implementations without support for Counter64 and 32-bit 560 implementations without any high capacity support at all. 562 A type definition (GenericCounter) for a union that contains an object 563 for each of the three scenarios would better represent the intended 564 semantics of this design, and use less text within data structure 565 definitions than an SMIv2 version. Note that a discriminator object is 566 not needed for a union, because the agent (or management application) 567 will instantiate at most one of the variants. 569 TYPEDEF UNION GenericCounter { 570 DESCRIPTION 571 "Generic counter for all versions of SNMP." 573 LEAF c32 { 574 SYNTAX Counter32 575 MAX-ACCESS read-only 576 STATUS current 577 DESCRIPTION 578 "The Counter32 representation of the counter." 579 } ::= 1 581 LEAF c64 { 582 SYNTAX Counter64 583 MAX-ACCESS read-only 584 STATUS current 585 DESCRIPTION 586 "The Counter64 representation of the counter." 587 } ::= 2 589 STRUCT c32pair { 590 DESCRIPTION 591 "Pair of Counter32 objects to represent a 64-bit 592 counter." 594 LEAF c32low { 595 SYNTAX Counter32 596 MAX-ACCESS read-only 597 STATUS deprecated 598 DESCRIPTION 599 "The lower 32 bits of a 64 bit counter." 600 } ::= 1 602 LEAF c32hi { 603 SYNTAX Counter32 604 MAX-ACCESS read-only 605 STATUS deprecated 606 DESCRIPTION 607 "The upper 32 bits of a 64 bit counter." 608 } ::= 2 609 } ::= 3 610 } 612 VAR UNION myCounter { 613 SYNTAX GenericCounter 614 STATUS current 615 DESCRIPTION 616 "An example generic counter variable." 617 } ::= { someBase 3 } 619 Note 1) Inline vs. external type definition: The 'c32pair' STRUCT could 620 have been defined as a separate type and a STRUCT declared with a SYNTAX 621 clause that referenced that type (e.g., form of 622 the STRUCT declaration). The instance numbering works out the same 623 either way. 625 The following OIDs would be possible for the 'myCounter' variable 626 declaration: 628 myCounter ::= { someBase 3 } 629 myCounter.c32 ::= { myCounter 1 1 } 630 myCounter.c64 ::= { myCounter 1 2 } 631 myCounter.c32pair ::= { myCounter 1 3 } 632 myCounter.c32pair.c32low ::= { myCounter 1 3 1 } 633 myCounter.c32pair.c32hi ::= { myCounter 1 3 2 } 635 Note 2) Even though only one node of a UNION can be instantiated at any 636 given time, a GetNext Request for a UNION which contains other 637 aggregated data objects can cause multiple instances to be returned from 638 that sub-tree, as with the 'c32low' and 'c32hi' LEAF objects in the 639 example above. 641 Note 3) Only the STATUS clauses for LEAF data object definitions are 642 relevant for compliance section usage. However, the above example 643 raises issues regarding an aggregated data object which contains a 644 mixture of current, deprecated, and obsolete LEAF objects. (Is the 645 STATUS of the GenericCounter UNION itself current or deprecated?) 647 5.6.3. Converted SMIv2 TABLE Example 649 The following example shows how two objects from the ifTable [RFC2863] 650 would be defined in SMI-DS syntax. Note that in in this example, the 651 interface table is modeled directly as a variable declaration, without 652 using a TYPEDEF. This practice is discouraged for new MIB definitions. 654 -- this is modeled as an ARRAY variable, rather than 655 -- an ARRAY containing a TYPEDEF'ed structure, to preserve 656 -- compatibility with SMIv2 658 VAR ARRAY ifTable { 660 DESCRIPTION 661 "A list of interface entries. The number of entries 662 is given by the value of ifNumber." 664 INDEX { ifIndex } 665 LEAF ifIndex { 666 SYNTAX InterfaceIndex 667 MAX-ACCESS read-only 668 STATUS current 669 DESCRIPTION 670 "A unique value, greater than zero, for each 671 interface. It is recommended that values are assigned 672 contiguously starting from 1. The value for each 673 interface sub-layer must remain constant at least from 674 one re-initialization of the entity's network 675 management system to the next re-initialization." 676 } ::= 1 678 LEAF ifDescr { 679 SYNTAX DisplayString (SIZE (0..255)) 680 MAX-ACCESS read-only 681 STATUS current 682 DESCRIPTION 683 "A textual string containing information about the 684 interface. This string should include the name of the 685 manufacturer, the product name and the version of the 686 interface hardware/software." 687 } ::= 2 689 LEAF ifType { 690 SYNTAX IANAifType 691 MAX-ACCESS read-only 692 STATUS current 693 DESCRIPTION 694 "The type of interface. Additional values for ifType 695 are assigned by the Internet Assigned Numbers 696 Authority (IANA), through updating the syntax of the 697 IANAifType textual convention." 698 } ::= 3 700 -- rest of ifTable LEAF objects would follow 701 } ::= { interfaces 2 } 703 -- declare the ifEntry descriptor for use in other AUGMENTS 704 ifEntry OBJECT IDENTIFIER ::= { ifTable 1 } 706 Note 1) The object naming and semantics are identical to the SMIv2 707 version. The OIDs for instance number '17' are shown: 709 ifTable ::= { interfaces 2 } 710 ifTable[17] ::= Not Available 711 ifTable[17].ifIndex ::= { ifTable 1 1 17 } 712 ifTable[17].ifDescr ::= { ifTable 1 2 17 } 713 ifTable[17].ifType ::= { ifTable 1 3 17 } 715 5.7. Data Structure Augmentations 717 SMIv2 allows for MIB tables to be conceptually extended over time, 718 without modifying the original MIB table definition, using the AUGMENTS 719 clause. This is usually done to allow vendor extensions to standard 720 MIBs, or to avoid editing a 'stable' RFC. 722 In SMI-DS, the AUGMENTS clause is preserved and adapted for use with 723 aggregated data objects, in order to maintain backward compatibility 724 with SMIv2. Only inline variable declarations for ARRAY data objects 725 can be augmented. 727 In addition to the AUGMENTS clause, which models 1:1 existence 728 relationships between two ARRAY variables, a SPARSE-AUGMENTS clause is 729 provides to model conditional 1:1 existence relationships between the 730 augmenting ARRAY variable and the augmented ARRAY variable. 732 The AUGMENTS construct defines one or more nodes which are conceptually 733 added to the outermost containment layer of the augmented ARRAY 734 variable. The augmenting ARRAY variable inherits all of the index 735 components of that ARRAY (exactly as with SMIv2). 737 A variant of the AUGMENTS construct is provided (called SPARSE-AUGMENTS) 738 for situations in which a static subset of an existing ARRAY is 739 augmented. The DESCRIPTION clause for an ARRAY which is a sparse 740 augmentation MUST explain the relationship between the augmenting and 741 augmented table. 743 The AUGMENTS clause in SMIv2 references the internal table node (e.g., 744 ifEntry, not ifTable), but SMI-DS ARRAY variables do not need or use 745 this internal construct. To remain compatible with SMIv2, an OBJECT 746 IDENTIFIER macro is used to declare an object descriptor which can be 747 used in AUGMENTS and SPARSE-AUGMENTS clauses. 749 AUGMENTS Example 750 ---------------- 752 The following trivial example shows how some high-capacity counters and 753 time-related attributes might be added to an existing array of packet 754 statistics. 756 TYPEDEF ARRAY InetHostStats { 757 DESCRIPTION 758 "Example of a IP host stats table." 760 INDEX { ifIndex, inetAddrType, inetAddr } 762 LEAF inetAddrType { 763 SYNTAX InetAddressType 764 MAX-ACCESS not-accessible 765 STATUS current 766 DESCRIPTION 767 "The IP address type for the array entry. 768 The InetAddressType values 'unknown(1)' and 769 'dns(16)' are not allowed." 770 } ::= 1 772 LEAF inetAddr { 773 SYNTAX InetAddress 774 MAX-ACCESS not-accessible 775 STATUS current 776 DESCRIPTION 777 "The IP address for the array entry." 778 } ::= 2 780 LEAF inPkts { 781 SYNTAX Counter32 782 MAX-ACCESS read-only 783 STATUS current 784 DESCRIPTION 785 "The number of packets received by the specified host 786 on the specified interface." 787 } ::= 3 789 LEAF outPkts { 790 SYNTAX Counter32 791 MAX-ACCESS read-only 792 STATUS current 793 DESCRIPTION 794 "The number of packets transmitted by the specified 795 host on the specified interface." 796 } ::= 4 798 -- Octet counters removed to make example shorter 800 } 802 -- variable declaration for a InetHostStats data collection 804 VAR ARRAY ipStats { 805 SYNTAX InetHostStats 806 STATUS current 807 DESCRIPTION 808 "The IP host statistics for this network device." 809 } ::= { someBase 4 } 811 -- OID declaration to keep AUGMENTS clause consistent 812 ipStatsEntry OBJECT IDENTIFIER ::= { ipStats 1 } 814 -- a struct containing additional information for each 815 -- set of counters 817 TYPEDEF STRUCT HostStatsTimeData { 818 DESCRIPTION 819 "Add some times related objects associated with 820 each set of counters." 822 LEAF createTime { 823 SYNTAX TimeStamp 824 MAX-ACCESS read-only 825 STATUS current 826 DESCRIPTION 827 "The value of sysUpTime at the time this set of 828 counters was created." 829 } ::= 1 831 LEAF updateInterval { 832 SYNTAX Unsigned32 833 UNITS "milliseconds" 834 MAX-ACCESS read-create 835 STATUS current 836 DESCRIPTION 837 "The average amount of time that elapses between 838 internal polling intervals for this counter set. 839 A value of zero indicates that the counter set 840 values are not polled internally." 841 } ::= 2 842 } 844 -- Augment the ipStats variable with the ipXStats variable: 846 -- - 2 HC packet counters 847 -- - a HostStatsTimeData STRUCT 848 -- - an ARRAY of InetPortNumber packet counters 850 VAR ARRAY ipXStats { 851 DESCRIPTION 852 "Adds HC counters and additional information to 853 the ipStats statistics." 855 AUGMENTS { ipStatsEntry } 857 LEAF inHCPkts { 858 SYNTAX Counter64 859 MAX-ACCESS read-only 860 STATUS current 861 DESCRIPTION 862 "The number of packets received by the specified 863 host on the specified interface." 864 } ::= 1 866 LEAF outHCPkts { 867 SYNTAX Counter64 868 MAX-ACCESS read-only 869 STATUS current 870 DESCRIPTION 871 "The number of packets transmitted by the specified 872 host on the specified interface." 873 } ::= 2 875 -- Octet counters removed to make example shorter 877 STRUCT timeData { 878 SYNTAX HostStatsTimeData 879 MAX-ACCESS read-only 880 STATUS current 881 DESCRIPTION 882 "Additional time-related information." 883 } ::= 3 885 ARRAY portStats { 886 DESCRIPTION 887 "Extend the ARRAY with InetPort statistics." 889 INDEX { inetPort } 890 LEAF inetPort { 891 SYNTAX InetPortNumber 892 MAX-ACCESS not-accessible 893 STATUS current 894 DESCRIPTION 895 "The Internet port number for the array entry." 896 } ::= 1 898 UNION uInPkts { 899 SYNTAX GenericCounter 900 MAX-ACCESS read-only 901 STATUS current 902 DESCRIPTION 903 "The number of packets received by the specified 904 host on the specified port." 905 } ::= 2 907 UNION uOutPkts { 908 SYNTAX GenericCounter 909 MAX-ACCESS read-only 910 STATUS current 911 DESCRIPTION 912 "The number of packets transmitted by the specified 913 host on the specified port." 914 } ::= 3 916 -- Octet counters removed to make example shorter 917 } ::= 4 918 } ::= { someBase 5 } 920 ipXStatsEntry OBJECT IDENTIFIER ::= { ipXStats 1 } 922 Note 1) The following example lists the potential OID values for each of 923 the fields in the 'ipStats' and 'ipXStats' variables in the example 924 above. 926 In this example only the instances for interface 17, InetAddressType 927 'ipv4(1)', InetAddress '192.168.0.1', and InetPortNumber '80' are shown. 929 ipStats ::= { someBase 4 } 930 ipStats[17] ::= Not Available 931 ipStats[17][1] ::= Not Available 932 ipStats[17][1][192.168.0.1] ::= Not Available 934 ipStats[17][1][192.168.0.1].inPkts ::= 935 { ipStats 1 3 17 1 4 192 168 0 1 } 937 ipStats[17][1][192.168.0.1].outPkts ::= 938 { ipStats 1 4 17 1 4 192 168 0 1 } 940 ipXStats ::= { someBase 5 } 941 ipXStats[17][1][192.168.0.1].inHCPkts ::= 942 { ipXStats 1 1 17 1 4 192 168 0 1 } 944 ipXStats[17][1][192.168.0.1].outHCPkts ::= 945 { ipXStats 1 2 17 1 4 192 168 0 1 } 947 ipXStats[17][1][192.168.0.1].timeData ::= 948 { ipXStats 1 3 17 1 4 192 168 0 1 } (not-accessible) 950 ipXStats[17][1][192.168.0.1].timeData.createTime ::= 951 { ipXStats 1 3 1 17 1 4 192 168 0 1 } 953 ipXStats[17][1][192.168.0.1].timeData.updateInterval ::= 954 { ipXStats 1 3 2 17 1 4 192 168 0 1 } 956 ipXStats[17][1][192.168.0.1].portStats ::= 957 { ipXStats 1 4 17 1 4 192 168 0 1 } (not-accessible) 959 ipXStats[17][1][192.168.0.1].portStats[80] ::= Not Available 961 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts ::= 962 { ipXStats 1 4 2 17 1 4 192 168 0 1 80 } (not-accessible) 964 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c32 ::= 965 { ipXStats 1 4 2 1 17 1 4 192 168 0 1 80 } 967 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c64 ::= 968 { ipXStats 1 4 2 2 17 1 4 192 168 0 1 80 } 970 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c32pair ::= 971 { ipXStats 1 4 2 3 17 1 4 192 168 0 1 80 } (not-accessible) 973 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c32pair.c32low ::= 974 { ipXStats 1 4 2 3 1 17 1 4 192 168 0 1 80 } 976 ipXStats[17][1][192.168.0.1].portStats[80].uInPkts.c32pair.c32hi ::= 977 { ipXStats 1 4 2 3 2 17 1 4 192 168 0 1 80 } 979 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts ::= 980 { ipXStats 1 4 3 17 1 4 192 168 0 1 80 } (not-accessible) 982 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c32 ::= 983 { ipXStats 1 4 3 1 17 1 4 192 168 0 1 80 } 985 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c64 ::= 986 { ipXStats 1 4 3 2 17 1 4 192 168 0 1 80 } 988 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c32pair ::= 989 { ipXStats 1 4 3 3 17 1 4 192 168 0 1 80 } (not-accessible) 991 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c32pair.c32low ::= 992 { ipXStats 1 4 3 3 1 17 1 4 192 168 0 1 80 } 994 ipXStats[17][1][192.168.0.1].portStats[80].uOutPkts.c32pair.c32hi ::= 995 { ipXStats 1 4 3 3 2 17 1 4 192 168 0 1 80 } 997 Note 2) Although arbitrary levels of nested containment are 998 theoretically possible, SNMP varbind size limitations and common sense 999 design practices set practical limits on the complexity of data object 1000 definitions. 1002 Note 3) The SPPI provides an EXTENDS mechanism, which allows new LEAF 1003 objects to be defined in a table which conceptually adds INDEX 1004 components to an existing table. This mechanism is accomplished by 1005 defining an additional ARRAY (with the new INDEX components and objects) 1006 in an AUGMENTS clause, like the 'portStats' example above. 1008 SPARSE-AUGMENTS Example 1009 ----------------------- 1011 The following example shows how information about physical sensors may 1012 sparsely augment the entPhysicalTable [RFC2737]. 1014 VAR ARRAY entSensorData { 1015 DESCRIPTION 1016 "Adds the ability to read physical sensor values 1017 to the Entity MIB. An entSensorData object exists 1018 for each entPhysicalEntry for which the entPhysicalClass 1019 object value is 'sensor(8)'." 1020 REFERENCE 1021 "RFC 2737, section 3." 1023 SPARSE-AUGMENTS { entPhysicalEntry } 1024 LEAF entSensorType { 1025 SYNTAX EntitySensorDataType 1026 MAX-ACCESS read-only 1027 STATUS current 1028 DESCRIPTION 1029 "The type of data returned by the associated 1030 entSensorValue object. ..." 1031 } ::= 1 1033 LEAF entSensorScale { 1034 SYNTAX EntitySensorDataScale 1035 MAX-ACCESS read-only 1036 STATUS current 1037 DESCRIPTION 1038 "The exponent to apply to values returned by the 1039 associated entSensorValue object. ..." 1040 } ::= 2 1042 -- rest of entSensorEntry objects would follow ... 1044 } ::= { someBase 6 } 1046 Note 1) SMI-DS objects can augment SMIv2 tables, since the SMIv2 <--> 1047 SMI-DS conversion algorithms are transparent. The augmented variable 1048 object descriptor may be any value that would be accepted in an SMIv2 1049 AUGMENTS clause. 1051 Note 2) The following OIDs would be possible for the 'entSensorEntry' 1052 augmentation. The instances for entPhysicalIndex == 17 are shown in this 1053 example: 1055 entSensorData ::= { someBase 6 } 1056 entSensorData[17] ::= Not Available 1057 entSensorData[17].entSensorType ::= { entSensorData 1 1 17 } 1058 entSensorData[17].entSensorScale ::= { entSensorData 1 2 17 } 1060 5.8. SYNTAX POINTER Clause 1062 The 'VariablePointer' and 'RowPointer' TEXTUAL-CONVENTIONs [RFC2579] 1063 provide semantic constraints on the generic OBJECT IDENTIFIER, but they 1064 can only be used to point to a variable or row of any type, not a 1065 specific type. 1067 SMI-DS provides a modified SYNTAX clause for object declarations, in 1068 order to specify an OID that must reference a MIB object (LEAF or 1069 aggregated data object) of a particular type. The value { 0 0 } is also 1070 allowed and is reserved to indicate a NULL pointer. 1072 The form "SYNTAX POINTER " specifies an OID which should 1073 contain only those values that de-reference to the same type as defined 1074 by , or contain the NULL pointer value { 0 0 }. 1076 For example, if the RMON DataSource TC [RFC2021] was written in SMI-DS, 1077 the POINTER construct might be used as follows: 1079 TYPEDEF LEAF DataSource { 1080 SYNTAX POINTER InterfaceIndex 1081 MAX-ACCESS read-create 1082 STATUS current 1083 DESCRIPTION 1084 "Identifies the source of the data that the associated 1085 function is configured to analyze. This source can be any 1086 interface on this device. ... 1087 For example, if an entry were to receive data from 1088 interface #1, this object would be set to ifIndex.1." 1089 } 1091 Refer to section 6.2 for details on the 'SYNTAX POINTER' clause. 1093 6. Definitions 1095 The follow sections specify the SMI Data Structures syntax and 1096 semantics. 1098 [ed. -- this section is intentionally incomplete, because this revision 1099 is meant to introduce the SMI Data Structures concepts, syntax, and 1100 examples. Complete specification to the level of SMIv2 is TBD.] 1102 6.1. Namespaces 1104 The type names and variable names used in SMI Data Structures are 1105 contained is the same namespace, identical to the SMIv2 namespace for 1106 OBJECT-TYPE descriptors, and shared with SMIv2. Reserved keywords in 1107 SMI-DS or SMIv2 MUST NOT be used as type names or object descriptors. 1109 Ideally, every data object containment level would define its own 1110 namespace, in a truly hierarchical fashion. However, this would not be 1111 compatible with existing SMIv2 practices, and would require changes to 1112 the IMPORTS, MODULE-COMPLIANCE and OBJECT-GROUP macros to support. 1114 [ed. - further definition of namespaces TBD] 1116 6.2. Syntax 1118 [ed. - the following ad-hoc syntax definition is a first-pass attempt, 1119 and obviously needs ABNF definition, and a detailed mappings and rules 1120 section for each construct. At this time, any construct which is 1121 equivalent to the SMIv2 version is not fully specified.] 1123 -- top level construction 1125 ::= 1127 "MODULE" "DEFINITIONS" "::=" "BEGIN" 1128 1129 1130 [] 1132 "END" 1134 ::= (same as SMIv2) 1136 ::= (same as SMIv2) 1137 ::= (same as SMIv2) 1139 ::= 1141 ( | | 1142 | | notification-decl> ) 1144 ::= (SMIv2 OBJECT IDENTIFIER clause) 1146 ::= (SMIv2 OBJECT-IDENTITY clause) 1148 ::= 1150 "TYPEDEF" ( | | 1151 | ) 1153 ::= 1155 "VAR" ( | | 1156 | ) 1158 ::= 1160 "LEAF" 1162 ::= 1164 (same rules as for SMIv2 TEXTUAL-CONVENTION descriptors) 1166 ::= 1168 "{" 1169 [] 1170 1171 [] 1172 1173 1174 1175 [] 1176 [] 1177 "}" 1179 ::= (same as SMIv2 DIPLAY-HINT) 1181 ::= 1182 ( | ) 1184 ::= 1186 (same as SMIv2, plus 64-bit numbers and float data types) 1188 ::= 1190 "SYNTAX" "POINTER" 1192 ::= (same as SMIv2) 1194 ::= (same as SMIv2) 1196 ::= (same as SMIv2) 1198 ::= (same as SMIv2) 1200 ::= (same as SMIv2) 1202 ::= (same as SMIv2) 1204 ::= 1206 "LEAF" 1207 "::=" 1209 ::= 1211 (same rules as for SMIv2 OBJECT-TYPE descriptors) 1213 ::= an INTEGER in the range (1..4294967295) 1215 ::= 1217 "LEAF" 1218 "::=" 1220 ::= (same as SMIv2) 1222 ::= 1224 "ARRAY" "{" 1225 1226 [] 1227 1228 [ ...] 1229 "}" 1231 ::= 1233 ( | | 1234 ) 1236 ::= 1238 "INDEX" "{" 1239 [ "," ...] "}" 1241 ::= 1243 "AUGMENTS" "{" "}" 1245 ::= 1247 "SPARSE-AUGMENTS" "{" "}" 1249 ::= 1251 ( | | 1252 | ) 1254 ::= 1256 ( | ) 1258 ::= 1260 1262 ::= 1264 "ARRAY" "{" 1265 1266 [] 1267 1268 [ ...] 1269 "}" "::=" 1271 ::= 1272 1274 ::= 1276 "ARRAY" "{" 1277 1278 [] 1279 1280 1281 [] 1282 "}" "::=" 1284 ::= 1286 ( | ) 1288 ::= 1290 1292 ::= 1294 1296 ::= 1298 "UNION" "{" 1299 1300 [] 1301 [ ...] 1302 "}" 1304 ::= 1306 ( | ) 1308 ::= 1310 1312 ::= 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 ::= 1360 1362 ::= 1364 "STRUCT" "{" 1365 1366 [] 1367 [ ...] 1368 "}" "::=" 1370 ::= 1372 1374 ::= 1376 "STRUCT" "{" 1377 1378 [] 1379 1380 1381 [] 1382 "}" "::=" 1384 ::= 1386 ( | ) 1388 ::= 1390 1392 ::= 1394 1396 ::= 1398 "NOTIFICATION" "{" 1399 [] 1400 1401 1402 [] 1403 "}" "::=" 1405 ::= 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 Portions of the existing SMI RFCs, SMIng drafts, and the ANSI C 2873 Programming Language inspired many of the concepts discussed in this 2874 memo. 2876 15. Normative References 2878 [RFC1905] 2879 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2880 Waldbusser, "Protocol Operations for Version 2 of the Simple 2881 Network Management Protocol (SNMPv2)", RFC 1905, SNMP Research, 2882 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 2883 International Network Services, January 1996. 2885 [RFC1906] 2886 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2887 Waldbusser, "Transport Mappings for Version 2 of the Simple Network 2888 Management Protocol (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco 2889 Systems, Inc., Dover Beach Consulting, Inc., International Network 2890 Services, January 1996. 2892 [RFC2026] 2893 Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2894 2026, Harvard University, October, 1996. 2896 [RFC2119] 2897 S. Bradner, "Key words for use in RFCs to Indicate Requirement 2898 Levels" RFC 2119, Harvard University, March 1997. 2900 [RFC2571] 2901 Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 2902 Describing SNMP Management Frameworks", RFC 2571, Cabletron 2903 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, April 2904 1999. 2906 [RFC2572] 2907 Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 2908 Processing and Dispatching for the Simple Network Management 2909 Protocol (SNMP)", RFC 2572, SNMP Research, Inc., Cabletron Systems, 2910 Inc., BMC Software, Inc., IBM T. J. Watson Research, April 1999. 2912 [RFC2573] 2913 Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 2914 2573, SNMP Research, Inc., Secure Computing Corporation, Cisco 2915 Systems, April 1999. 2917 [RFC2574] 2918 Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 2919 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2920 2574, IBM T. J. Watson Research, April 1999. 2922 [RFC2575] 2923 Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 2924 Control Model (VACM) for the Simple Network Management Protocol 2925 (SNMP)", RFC 2575, IBM T. J. Watson Research, BMC Software, Inc., 2926 Cisco Systems, Inc., April 1999. 2928 [RFC2578] 2929 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2930 and S. Waldbusser, "Structure of Management Information Version 2 2931 (SMIv2)", RFC 2578, STD 58, Cisco Systems, SNMPinfo, TU 2932 Braunschweig, SNMP Research, First Virtual Holdings, International 2933 Network Services, April 1999. 2935 [RFC2579] 2936 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2937 and S. Waldbusser, "Textual Conventions for SMIv2", RFC 2579, STD 2938 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, First 2939 Virtual Holdings, International Network Services, April 1999. 2941 [RFC2580] 2942 McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M., 2943 and S. Waldbusser, "Conformance Statements for SMIv2", RFC 2580, 2944 STD 58, Cisco Systems, SNMPinfo, TU Braunschweig, SNMP Research, 2945 First Virtual Holdings, International Network Services, April 1999. 2947 16. Informative References 2949 [DSMON-MIB] 2950 Bierman, A., "Remote Monitoring MIB Extensions for Differentiated 2951 Services", Work in progress (draft-ietf-rmonmib-dsmon-mib-09.txt), 2952 Cisco Systems, Inc., November 2001. 2954 [RFC1155] 2955 Rose, M., and K. McCloghrie, "Structure and Identification of 2956 Management Information for TCP/IP-based Internets", RFC 1155, 2957 Performance Systems International, Hughes LAN Systems, May 1990. 2959 [RFC1157] 2960 Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 2961 Management Protocol", RFC 1157, SNMP Research, Performance Systems 2962 International, Performance Systems International, MIT Laboratory 2963 for Computer Science, May 1990. 2965 [RFC1212] 2966 Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 2967 Performance Systems International, Hughes LAN Systems, March 1991. 2969 [RFC1215] 2970 M. Rose, "A Convention for Defining Traps for use with the SNMP", 2971 RFC 1215, Performance Systems International, March 1991. 2973 [RFC1901] 2974 SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and S. 2975 Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, 2976 SNMP Research, Inc., Cisco Systems, Inc., Dover Beach Consulting, 2977 Inc., International Network Services, January 1996. 2979 [RFC2021] 2980 S. Waldbusser, "Remote Network Monitoring Management Information 2981 Base Version 2 using SMIv2", RFC 2021, INS, January 1997. 2983 [RFC2570] 2984 Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction to 2985 Version 3 of the Internet-standard Network Management Framework", 2986 RFC 2570, SNMP Research, Inc., TIS Labs at Network Associates, 2987 Inc., Ericsson, Cisco Systems, April 1999. 2989 [RFC2737] 2990 McCloghrie, K., and A. Bierman, "Entity MIB (Version 2)", RFC 2737, 2991 Cisco Systems, Inc., December 1999. 2993 [RFC2851] 2994 Daniele, M., Haberman, B., Routhier, S., and J. Schoenwaelder, 2995 "Textual Conventions for Internet Network Addresses", RFC 2851, 2996 Compaq Computer Corporation, Nortel Networks, Wind River Systems, 2997 Inc., TU Braunschweig, June 2000. 2999 [RFC2863] 3000 McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB", RFC 3001 2863, Cisco Systems, Argon Networks, June, 2000. 3003 [RFC3216] 3004 Elliot, C., Harrington, D., Jason, J., Schoenwaelder, J., Strauss, 3005 F., and W. Weiss, "SMIng Objectives", RFC 3216, Cisco Systems, 3006 Enterasys Networks, Intel Corporation, TU Braunschweig, Ellacoya 3007 Networks, December 2001. 3009 17. Author's Address 3011 Andy Bierman 3012 Cisco Systems, Inc. 3013 170 West Tasman Drive 3014 San Jose, CA USA 95134 3015 Phone: +1 408-527-3711 3016 Email: abierman@cisco.com 3018 18. Full Copyright Statement 3020 Copyright (C) The Internet Society (2002). All Rights Reserved. 3022 This document and translations of it may be copied and furnished to 3023 others, and derivative works that comment on or otherwise explain it or 3024 assist in its implementation may be prepared, copied, published and 3025 distributed, in whole or in part, without restriction of any kind, 3026 provided that the above copyright notice and this paragraph are included 3027 on all such copies and derivative works. However, this document itself 3028 may not be modified in any way, such as by removing the copyright notice 3029 or references to the Internet Society or other Internet organizations, 3030 except as needed for the purpose of developing Internet standards in 3031 which case the procedures for copyrights defined in the Internet 3032 Standards process must be followed, or as required to translate it into 3033 languages other than English. 3035 The limited permissions granted above are perpetual and will not be 3036 revoked by the Internet Society or its successors or assigns. 3038 This document and the information contained herein is provided on an "AS 3039 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 3040 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 3041 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 3042 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 3043 FITNESS FOR A PARTICULAR PURPOSE.