idnits 2.17.1 draft-ietf-sming-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 889 has weird spacing: '...bccddee aa:b...' == Line 1153 has weird spacing: '... status curre...' == Line 1374 has weird spacing: '... status curre...' == Line 1380 has weird spacing: '... status curre...' == Line 1386 has weird spacing: '... status curre...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 20, 2001) is 8308 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) == Unused Reference: '14' is defined on line 1899, but no explicit reference was found in the text -- Possible downref: Normative reference to a draft: ref. '1' -- Possible downref: Normative reference to a draft: ref. '2' -- Possible downref: Normative reference to a draft: ref. '3' ** Downref: Normative reference to an Historic draft: draft-ietf-rap-sppi (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 1215 (ref. '11') ** Obsolete normative reference: RFC 2234 (ref. '12') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '13' ** Obsolete normative reference: RFC 2271 (ref. '14') (Obsoleted by RFC 2571) -- Possible downref: Non-RFC (?) normative reference: ref. '15' ** Obsolete normative reference: RFC 2279 (ref. '16') (Obsoleted by RFC 3629) ** Obsolete normative reference: RFC 2629 (ref. '17') (Obsoleted by RFC 7749) Summary: 10 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Strauss 3 Internet-Draft J. Schoenwaelder 4 Expires: January 18, 2002 TU Braunschweig 5 July 20, 2001 7 SMIng - Next Generation Structure of Management Information 8 draft-ietf-sming-02 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on January 18, 2002. 33 Copyright Notice 35 Copyright (C) The Internet Society (2001). All Rights Reserved. 37 Abstract 39 This memo presents an object-oriented data definition language for 40 the specification of various kinds of management information. It is 41 independent of management protocols and applications. Protocol 42 mappings are defined as extensions to this language in separate 43 memos. The language builds on experiences gained with the SMIv2 and 44 its derivate SPPI. It is expected that the language presented in 45 this memo along with its protocol mappings will replace the SMIv2 and 46 the SPPI in the long term. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 51 2. SMIng Data Modelling . . . . . . . . . . . . . . . . . . . . 5 52 2.1 Identifiers . . . . . . . . . . . . . . . . . . . . . . . . 6 53 3. Base Types and Derived Types . . . . . . . . . . . . . . . . 7 54 3.1 OctetString . . . . . . . . . . . . . . . . . . . . . . . . 7 55 3.2 Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 3.3 Object Identifier . . . . . . . . . . . . . . . . . . . . . 9 57 3.4 Integer32 . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 3.5 Integer64 . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 3.6 Unsigned32 . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 3.7 Unsigned64 . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 3.8 Float32 . . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 3.9 Float64 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 3.10 Float128 . . . . . . . . . . . . . . . . . . . . . . . . . . 15 64 3.11 Enumeration . . . . . . . . . . . . . . . . . . . . . . . . 16 65 3.12 Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 66 3.13 Display Formats . . . . . . . . . . . . . . . . . . . . . . 18 67 4. The SMIng File Structure . . . . . . . . . . . . . . . . . . 20 68 4.1 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 20 69 4.2 Statements and Arguments . . . . . . . . . . . . . . . . . . 20 70 5. The module Statement . . . . . . . . . . . . . . . . . . . . 20 71 5.1 The module's import Statement . . . . . . . . . . . . . . . 21 72 5.2 The module's organization Statement . . . . . . . . . . . . 22 73 5.3 The module's contact Statement . . . . . . . . . . . . . . . 22 74 5.4 The module's description Statement . . . . . . . . . . . . . 22 75 5.5 The module's reference Statement . . . . . . . . . . . . . . 22 76 5.6 The module's revision Statement . . . . . . . . . . . . . . 22 77 5.6.1 The revision's date Statement . . . . . . . . . . . . . . . 22 78 5.6.2 The revision's description Statement . . . . . . . . . . . . 23 79 5.7 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 23 80 6. The extension Statement . . . . . . . . . . . . . . . . . . 24 81 6.1 The extension's status Statement . . . . . . . . . . . . . . 24 82 6.2 The extension's description Statement . . . . . . . . . . . 24 83 6.3 The extension's reference Statement . . . . . . . . . . . . 24 84 6.4 The extension's abnf Statement . . . . . . . . . . . . . . . 25 85 6.5 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 25 86 7. The typedef Statement . . . . . . . . . . . . . . . . . . . 25 87 7.1 The typedef's type Statement . . . . . . . . . . . . . . . . 25 88 7.2 The typedef's default Statement . . . . . . . . . . . . . . 26 89 7.3 The typedef's format Statement . . . . . . . . . . . . . . . 26 90 7.4 The typedef's units Statement . . . . . . . . . . . . . . . 26 91 7.5 The typedef's status Statement . . . . . . . . . . . . . . . 27 92 7.6 The typedef's description Statement . . . . . . . . . . . . 27 93 7.7 The typedef's reference Statement . . . . . . . . . . . . . 27 94 7.8 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 27 95 8. The identity Statement . . . . . . . . . . . . . . . . . . . 28 96 8.1 The identity's status Statement . . . . . . . . . . . . . . 29 97 8.2 The identity' description Statement . . . . . . . . . . . . 29 98 8.3 The identity's reference Statement . . . . . . . . . . . . . 29 99 8.4 Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 30 100 9. The class Statement . . . . . . . . . . . . . . . . . . . . 30 101 9.1 The class' attribute Statement . . . . . . . . . . . . . . . 30 102 9.1.1 The attribute's access Statement . . . . . . . . . . . . . . 31 103 9.1.2 The attribute's default Statement . . . . . . . . . . . . . 31 104 9.1.3 The attribute's format Statement . . . . . . . . . . . . . . 31 105 9.1.4 The attribute's units Statement . . . . . . . . . . . . . . 32 106 9.1.5 The attribute's status Statement . . . . . . . . . . . . . . 32 107 9.1.6 The attribute's description Statement . . . . . . . . . . . 32 108 9.1.7 The attribute's reference Statement . . . . . . . . . . . . 33 109 9.2 The class' unique Statement . . . . . . . . . . . . . . . . 33 110 9.3 The class' event Statement . . . . . . . . . . . . . . . . . 33 111 9.3.1 The event's status Statement . . . . . . . . . . . . . . . . 33 112 9.3.2 The event's description Statement . . . . . . . . . . . . . 34 113 9.3.3 The event's reference Statement . . . . . . . . . . . . . . 34 114 9.4 The class' status Statement . . . . . . . . . . . . . . . . 34 115 9.5 The class' description Statement . . . . . . . . . . . . . . 34 116 9.6 The class's reference Statement . . . . . . . . . . . . . . 35 117 9.7 Usage Example . . . . . . . . . . . . . . . . . . . . . . . 35 118 10. Extending a Module . . . . . . . . . . . . . . . . . . . . . 36 119 11. SMIng Language Extensibility . . . . . . . . . . . . . . . . 37 120 12. Security Considerations . . . . . . . . . . . . . . . . . . 39 121 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39 122 References . . . . . . . . . . . . . . . . . . . . . . . . . 40 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 41 124 A. SMIng ABNF Grammar . . . . . . . . . . . . . . . . . . . . . 41 125 B. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . 51 126 Full Copyright Statement . . . . . . . . . . . . . . . . . . 54 128 1. Introduction 130 In traditional management systems management information is viewed as 131 a collection of managed objects, residing in a virtual information 132 store, termed the Management Information Base (MIB). Collections of 133 related objects are defined in MIB modules. These modules are 134 written conforming to a specification language, the Structure of 135 Management Information (SMI). There are different versions of the 136 SMI. The SMI version 1 (SMIv1) is defined in [9], [10], [11] and the 137 SMI version 2 (SMIv2) in [5], [6], [7]. Both are based on adapted 138 subsets of OSI's Abstract Syntax Notation One, ASN.1 [13]. 140 In a similar fashion policy provisioning information is viewed as a 141 collection of Provisioning Classes (PRCs) and Provisioning Instances 142 (PRIs) residing in a virtual information store, termed the Policy 143 Information Base (PIB). Collections of related Provisioning Classes 144 are defined in PIB modules. PIB modules are written using the 145 Structure of Policy Provisioning Information (SPPI) [8] which is an 146 adapted subset of SMIv2. 148 The SMIv1 and the SMIv2 are bound to the Simple Network Management 149 Protocol (SNMP) while the the SPPI is bound to the Common Open Policy 150 Service Provisioning (COPS-PR) protocol. Even though the languages 151 have common rules, it is hard to use common data definitions with 152 both protocols. It is the purpose of this document to define a 153 common object-oriented data definition language, named SMIng, that 154 allows to formally specify data models independent of specific 155 protocols and applications. Companion documents contain 157 o core modules that supply common SMIng definitions [1][2], 159 o a SMIng language extension to define SNMP specific mappings of 160 SMIng definitions in way compatible to SMIv2 MIBs [3], and 162 o a SMIng language extension to define COPS-PR specific mappings of 163 SMIng definition in a way compatible to SPPI PIBs. 165 Section 2 gives an overview of the basic concepts of data modelling 166 using SMIng while the subsequent sections present the concepts of the 167 SMIng language in detail: the base types, the SMIng file structure, 168 and all SMIng core statements. 170 The remainder of the document describes extensibility features of the 171 language and rules to follow when changes are applied to a module. 172 Appendix A contains the grammar of SMIng in ABNF [12] notation. 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in [4]. 178 2. SMIng Data Modelling 180 SMIng is a language designed to specify management information in a 181 structured way readable to computer programs, e.g. MIB compilers, as 182 well as to human readers. 184 Management information is modeled in classes in an object-oriented 185 manner. Classes can be defined from scratch or by inheritance from a 186 parent class. Multiple inheritence is not possible. The concept of 187 classes is described in Section 9. 189 Each class has a number of attributes. Each attribute represents an 190 atomic piece of information of a base type, a sub-type of a base 191 type, or another class. The concept of attributes is described in 192 Section 9.1. 194 The base types of SMIng include signed and unsigned integers, octet 195 strings, enumeration types, bitset types, and pointers. Pointers are 196 references to class instances, attributes of class instances, or 197 arbitrary identities. The SMIng type system is described in Section 198 3. 200 Related class and type definitions are defined in modules. A module 201 may refer to definitions from other modules by importing identifiers 202 from those modules. Each module may serve one or multiple purposes: 204 o the definition of management classes, 206 o the definition of events, 208 o the definition of derived types, 210 o the definition of arbitrary untyped identities serving as values 211 of pointers, 213 o the definition of SMIng extensions to allow the local module or 214 other modules to specify information beyond the scope of the base 215 SMIng in a machine readable notation. Some extensions for the 216 application of SMIng in the SNMP framework are defined in [3], 218 o the definition of information beyond the scope of the base SMIng 219 statements, based on locally defined or imported SMIng extensions. 221 Each module is identified by an upper-case identifier. The names of 222 all standard modules must be unique (but different versions of the 223 same module should have the same name). Developers of enterprise 224 modules are encouraged to choose names for their modules that will 225 have a low probability of colliding with standard or other enterprise 226 modules, e.g. by using the enterprise or organization name as a 227 prefix. 229 2.1 Identifiers 231 Identifiers are used to identify different kinds of SMIng items by 232 name. Each identifier is valid in a namespace which depends on the 233 type of the SMIng item being defined: 235 o The global namespace contains all module identifiers. 237 o Each module defines a new namespace. A module's namespace may 238 contain definitions of extension identifiers, derived type 239 identifiers, identity identifiers, and class identifiers. 240 Furthermore, a module may import identifiers of these kinds from 241 other modules. All these identifiers are also visible within all 242 inner namespaces of the module. 244 o Each class within a module defines a new namespace. A class' 245 namespace may contain definitions of attribute identifiers and 246 event identifiers. 248 o Each enumeration type and bitset type defines a new namespace of 249 its named numbers. These named numbers are visible in each 250 expression of a corresponding value, e.g., default values and sub- 251 typing restrictions. 253 o Extensions may define additional namespaces and have additional 254 rules of other namespaces' visibilty. 256 Within every namespace each identifier MUST be unique. 258 Each identifier starts with an upper-case or lower-case character, 259 dependent on the kind of SMIng item, followed by zero or more 260 letters, digits and hyphens. 262 All identifiers defined in a namespace MUST be unique and SHOULD NOT 263 only differ in case. Identifiers MUST NOT exceed 64 characters in 264 length. Furthermore, the set of all identifiers defined in all 265 modules of a single standardization body or organization SHOULD be 266 unique and mnemonic. This promotes a common language for humans to 267 use when discussing a module. 269 To reference an item that is defined in the local module, its 270 definition MUST sequentially precede the reference. Thus, there MUST 271 NOT be any forward references. 273 To reference an item, that is defined in an external module it MUST 274 be imported into the local module's namespace (Section 5.1). 275 Identifiers that are neither defined nor imported MUST NOT be visible 276 in the local module. On the other hand, all items defined in a 277 module are implicitly exported. 279 When identifiers from external modules are referenced, there is the 280 possibility of name collisions. As such, if different items with the 281 same identifier are imported or if imported identifiers collide with 282 identifiers of locally defined items, then this ambiguity is resolved 283 by prefixing those identifiers with the names of their modules and 284 the namespace operator `::', i.e. `Module::item'. Of course, this 285 notation can be used to refer to identifiers even when there is no 286 name collision. 288 Note that SMIng core language keywords MUST NOT be imported. See the 289 `...Keyword' rules of the SMIng ABNF grammar in Appendix A for a list 290 of those keywords. 292 3. Base Types and Derived Types 294 SMIng has a minimal but complete set of base types, similar to those 295 of many programming languages, but with some differences due to 296 special requirements from the management information model. 298 Additional types may be defined, derived from those base types or 299 from other derived types. Derived types may use subtyping to 300 formally restrict the set of possible values. An initial set of 301 commonly used derived types is defined in the SMIng standard module 302 IETF-SMING [1]. 304 The different base types and their derived types allow different 305 kinds of subtyping, namely size restrictions and range restrictions. 306 See the following sections on base types (Section 3.1 through Section 307 3.12) for details. 309 3.1 OctetString 311 The OctetString base type represents arbitrary binary or textual 312 data. Although SMIng has a theoretical size limitation of 2^16-1 313 (65535) octets for this base type, module designers should realize 314 that there may be implementation and interoperability limitations for 315 sizes in excess of 255 octets. 317 Values of octet strings may be denoted as textual data enclosed in 318 double quotes or as arbitrary binary data denoted as a `0x'-prefixed 319 hexadecimal value of an even number of at least two hexadecimal 320 digits, where each pair of hexadecimal digits represents a single 321 octet. Letters in hexadecimal values MAY be upper-case but lower- 322 case characters are RECOMMENDED. Textual data may contain any number 323 (possibly zero) of any 7-bit displayable ASCII characters except 324 double quote `"', including tab characters, spaces and line 325 terminator characters (nl or cr & nl). Textual data may span 326 multiple lines, where each subsequent line prefix containing only 327 white space up to the column where the first line's data starts 328 SHOULD be skipped by parsers for a better text formatting. 330 When defining a type derived (directly or indirectly) from the 331 OctetString base type, the size in octets may be restricted by 332 appending a list of size ranges or explicit size values, separated by 333 pipe `|' characters and the whole list enclosed in parenthesis. A 334 size range consists of a lower bound, two consecutive dots `..' and 335 an upper bound. Each value can be given in decimal or `0x'-prefixed 336 hexadecimal notation. Hexadecimal numbers must have an even number 337 of at least two digits. Size restricting values MUST NOT be 338 negative. If multiple values or ranges are given, they all MUST be 339 disjoint and MUST be in ascending order. If a size restriction is 340 applied to an already size restricted octet string the new 341 restriction MUST be equal or more limiting, that is raising the lower 342 bounds, reducing the upper bounds, removing explicit size values or 343 ranges, or splitting ranges into multiple ranges with intermediate 344 gaps. 346 Value Examples: 348 "This is a multiline 349 textual data example." // legal 350 "This is "illegally" quoted." // illegal quotes 351 "But this is 'ok'." // legal apostrophe quoting 352 "" // legal zero length 353 0x123 // illegal odd hex length 354 0x534d496e670a // legal octet string 356 Restriction Examples: 358 OctetString (0 | 4..255) // legal size spec 359 OctetString (4) // legal exact size 360 OctetString (-1 | 1) // illegal negative size 361 OctetString (5 | 0) // illegal ordering 362 OctetString (1 | 1..10) // illegal overlapping 364 3.2 Pointer 366 The Pointer base type represents values that reference class 367 instances, attributes of class instances, or arbitrary identities. 369 The only values of the Pointer type that can be present in a module 370 can refer to identities. They are denoted as identifiers of the 371 concerned identities. 373 When defining a type derived (directly or indirectly) from the 374 Pointer base type, the values may be restricted to a specific class, 375 attribute or identity and all (directly or indirectly) derived items 376 thereof by appending the identifier of the appropriate construct 377 enclosed in parenthesis. 379 Value Examples: 381 null // legal identity name 382 snmpUDPDomain // legal identity name 384 Restriction Examples: 386 Pointer (snmpTransportDomain) // legal restriction 388 3.3 Object Identifier 390 The ObjectIdentifier base type represents administratively assigned 391 names for use with SNMP and COPS-PR. This type SHOULD NOT be used in 392 protocol independant SMIng modules. It is meant to be used in SNMP 393 and COPS-PR mappings of attributes of type Pointer (Section 3.2). 395 Values of this type may be denoted as a sequence of numerical non- 396 negative sub-identifier values which each MUST NOT exceed 2^32-1 397 (4294967295). Sub-identifiers may be denoted decimal or `0x'- 398 prefixed hexadecimal. They are separated by single dots and without 399 any intermediate white space. Alternatively (and preferred in most 400 cases), the first element may be a previously defined or imported 401 lower-case identifier, representing a static object identifier 402 prefix. The total number of sub-identifiers MUST NOT exceed 128 403 including the expanded identifier. 405 Object identifier derived types cannot be restricted in any way. 407 Value Examples: 409 1.3.6.1 // legal numerical oid 410 mib-2.1 // legal oid with identifier prefix 411 internet.4.1.0x0627.0x01 // legal oid with hex subids 412 iso.-1 // illegal negative subid 413 iso.org.6 // illegal non-heading identifier 414 IF-MIB::ifNumber.0 // legel fully quallified instance oid 416 3.4 Integer32 418 The Integer32 base type represents integer values between -2^31 (- 419 2147483648) and 2^31-1 (2147483647). 421 Values of type Integer32 may be denoted as decimal or hexadecimal 422 numbers, where only decimal numbers can be negative. Decimal numbers 423 other than zero MUST NOT have leading zero digits. Hexadecimal 424 numbers are prefixed by `0x' and MUST have an even number of at least 425 two hexadecimal digits, where letters MAY be upper-case but lower- 426 case characters are RECOMMENDED. 428 When defining a type derived (directly or indirectly) from the 429 Integer32 base type, the set of possible values may be restricted by 430 appending a list of ranges or explicit values, separated by pipe `|' 431 characters and the whole list enclosed in parenthesis. A range 432 consists of a lower bound, two consecutive dots `..' and an upper 433 bound. Each value can be given in decimal or `0x'-prefixed 434 hexadecimal notation. Hexadecimal numbers must have an even number 435 of at least two digits. If multiple values or ranges are given they 436 all MUST be disjoint and MUST be in ascending order. If a value 437 restriction is applied to an already restricted type the new 438 restriction MUST be equal or more limiting, that is raising the lower 439 bounds, reducing the upper bounds, removing explicit values or 440 ranges, or splitting ranges into multiple ranges with intermediate 441 gaps. 443 Value Examples: 445 015 // illegal leading zero 446 -123 // legal negative value 447 - 1 // illegal intermediate space 448 0xabc // illegal hexadecimal value length 449 -0xff // illegal sign on hex value 450 0x80000000 // illegal value, too large 451 0xf00f // legal hexadecimal value 453 Restriction Examples: 455 Integer32 (0 | 5..10) // legal range spec 456 Integer32 (5..10 | 2..3) // illegal ordering 457 Integer32 (4..8 | 5..10) // illegal overlapping 459 3.5 Integer64 461 The Integer64 base type represents integer values between -2^63 (- 462 9223372036854775808) and 2^63-1 (9223372036854775807). 464 Values of type Integer64 may be denoted as decimal or hexadecimal 465 numbers, where only decimal numbers can be negative. Decimal numbers 466 other than zero MUST NOT have leading zero digits. Hexadecimal 467 numbers are prefixed by `0x' and MUST have an even number of 468 hexadecimal digits, where letters MAY be upper-case but lower-case 469 characters are RECOMMENDED. 471 When defining a type derived (directly or indirectly) from the 472 Integer64 base type, the set of possible values may be restricted by 473 appending a list of ranges or explicit values, separated by pipe `|' 474 characters and the whole list enclosed in parenthesis. A range 475 consists of a lower bound, two consecutive dots `..' and an upper 476 bound. Each value can be given in decimal or `0x'-prefixed 477 hexadecimal notation. Hexadecimal numbers must have an even number 478 of at least two digits. If multiple values or ranges are given they 479 all MUST be disjoint and MUST be in ascending order. If a value 480 restriction is applied to an already restricted type the new 481 restriction MUST be equal or more limiting, that is raising the lower 482 bounds, reducing the upper bounds, removing explicit values or 483 ranges, or splitting ranges into multiple ranges with intermediate 484 gaps. 486 Value Examples: 488 015 // illegal leading zero 489 -123 // legal negative value 490 - 1 // illegal intermediate space 491 0xabc // illegal hexadecimal value length 492 -0xff // illegal sign on hex value 493 0x80000000 // legal value 495 Restriction Examples: 497 Integer64 (0 | 5..10) // legal range spec 498 Integer64 (5..10 | 2..3) // illegal ordering 499 Integer64 (4..8 | 5..10) // illegal overlapping 501 3.6 Unsigned32 503 The Unsigned32 base type represents positive integer values between 0 504 and 2^32-1 (4294967295). 506 Values of type Unsigned32 may be denoted as decimal or hexadecimal 507 numbers. Decimal numbers other than zero MUST NOT have leading zero 508 digits. Hexadecimal numbers are prefixed by `0x' and MUST have an 509 even number of hexadecimal digits, where letters MAY be upper-case 510 but lower-case characters are RECOMMENDED. 512 When defining a type derived (directly or indirectly) from the 513 Unsigned32 base type, the set of possible values may be restricted by 514 appending a list of ranges or explicit values, separated by pipe `|' 515 characters and the whole list enclosed in parenthesis. A range 516 consists of a lower bound, two consecutive dots `..' and an upper 517 bound. Each value can be given in decimal or `0x'-prefixed 518 hexadecimal notation. Hexadecimal numbers must have an even number 519 of at least two digits. If multiple values or ranges are given they 520 all MUST be disjoint and MUST be in ascending order. If a value 521 restriction is applied to an already restricted type the new 522 restriction MUST be equal or more limiting, that is raising the lower 523 bounds, reducing the upper bounds, removing explicit values or 524 ranges, or splitting ranges into multiple ranges with intermediate 525 gaps. 527 Value Examples: 529 015 // illegal leading zero 530 -123 // illegal negative value 531 0xabc // illegal hexadecimal value length 532 0x80000000 // legal hexadecimal value 533 0x8080000000 // illegal value, too large 535 Restriction Examples: 537 Unsigned32 (0 | 5..10) // legal range spec 538 Unsigned32 (5..10 | 2..3) // illegal ordering 539 Unsigned32 (4..8 | 5..10) // illegal overlapping 541 3.7 Unsigned64 543 The Unsigned64 base type represents positive integer values between 0 544 and 2^64-1 (18446744073709551615). 546 Values of type Unsigned64 may be denoted as decimal or hexadecimal 547 numbers. Decimal numbers other than zero MUST NOT have leading zero 548 digits. Hexadecimal numbers are prefixed by `0x' and MUST have an 549 even number of hexadecimal digits, where letters MAY be upper-case 550 but lower-case characters are RECOMMENDED. 552 When defining a type derived (directly or indirectly) from the 553 Unsigned64 base type, the set of possible values may be restricted by 554 appending a list of ranges or explicit values, separated by pipe `|' 555 characters and the whole list enclosed in parenthesis. A range 556 consists of a lower bound, two consecutive dots `..' and an upper 557 bound. Each value can be given in decimal or `0x'-prefixed 558 hexadecimal notation. Hexadecimal numbers must have an even number 559 of at least two digits. If multiple values or ranges are given they 560 all MUST be disjoint and MUST be in ascending order. If a value 561 restriction is applied to an already restricted type the new 562 restriction MUST be equal or more limiting, that is raising the lower 563 bounds, reducing the upper bounds, removing explicit values or 564 ranges, or splitting ranges into multiple ranges with intermediate 565 gaps. 567 Value Examples: 569 015 // illegal leading zero 570 -123 // illegal negative value 571 0xabc // illegal hexadecimal value length 572 0x8080000000 // legal hexadecimal value 574 Restriction Examples: 576 Unsigned64 (1..10000000000) // legal range spec 577 Unsigned64 (5..10 | 2..3) // illegal ordering 579 3.8 Float32 581 The Float32 base type represents floating point values of single 582 precision as described by [15]. 584 Values of type Float32 may be denoted as a decimal fraction with an 585 optional exponent as known from many programming languages. See the 586 grammar rule `floatValue' of Appendix A for the detailed syntax. 587 Special values are `snan' (signaling Not-a-Number), `qnan' (quiet 588 Not-a-Number), `neginf' (negative infinity), and `posinf' (positive 589 infinity). Note that -0.0 and +0.0 are different floating point 590 values. 0.0 is equal to +0.0. 592 When defining a type derived (directly or indirectly) from the 593 Float32 base type, the set of possible values may be restricted by 594 appending a list of ranges or explicit values, separated by pipe `|' 595 characters and the whole list enclosed in parenthesis. A range 596 consists of a lower bound, two consecutive dots `..' and an upper 597 bound. If multiple values or ranges are given they all MUST be 598 disjoint and MUST be in ascending order. If a value restriction is 599 applied to an already restricted type the new restriction MUST be 600 equal or more limiting, that is raising the lower bounds, reducing 601 the upper bounds, removing explicit values or ranges, or splitting 602 ranges into multiple ranges with intermediate gaps. The special 603 values `snan', `qnan', `neginf', and `posinf' must be explicitly 604 listed in restrictions if they shall be included, where `snan' and 605 `qnan' cannot be used in ranges. 607 Note that encoding is not subject to this specification. It has to 608 be described by protocols that transport objects of type Float32. 609 Note also that most floating point encodings disallow the 610 representation of many values that can be written as decimal 611 fractions as used in SMIng for human readability. Therefore, 612 explicit values in floating point type restrictions should be handled 613 with care. 615 Value Examples: 617 00.1 // illegal leading zero 618 3.1415 // legal value 619 -2.5E+3 // legal negative exponential value 621 Restriction Examples: 623 Float32 (-1.0..1.0) // legal range spec 624 Float32 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 625 Float32 (neginf..-0.0) // legal range spec 626 Float32 (-10.0..10.0 | 0) // illegal overlapping 628 3.9 Float64 630 The Float64 base type represents floating point values of double 631 precision as described by [15]. 633 Values of type Float64 may be denoted as a decimal fraction with an 634 optional exponent as known from many programming languages. See the 635 grammar rule `floatValue' of Appendix A for the detailed syntax. 636 Special values are `snan' (signaling Not-a-Number), `qnan' (quiet 637 Not-a-Number), `neginf' (negative infinity), and `posinf' (positive 638 infinity). Note that -0.0 and +0.0 are different floating point 639 values. 0.0 is equal to +0.0. 641 When defining a type derived (directly or indirectly) from the 642 Float64 base type, the set of possible values may be restricted by 643 appending a list of ranges or explicit values, separated by pipe `|' 644 characters and the whole list enclosed in parenthesis. A range 645 consists of a lower bound, two consecutive dots `..' and an upper 646 bound. If multiple values or ranges are given they all MUST be 647 disjoint and MUST be in ascending order. If a value restriction is 648 applied to an already restricted type the new restriction MUST be 649 equal or more limiting, that is raising the lower bounds, reducing 650 the upper bounds, removing explicit values or ranges, or splitting 651 ranges into multiple ranges with intermediate gaps. The special 652 values `snan', `qnan', `neginf', and `posinf' must be explicitly 653 listed in restrictions if they shall be included, where `snan' and 654 `qnan' cannot be used in ranges. 656 Note that encoding is not subject to this specification. It has to 657 be described by protocols that transport objects of type Float64. 658 Note also that most floating point encodings disallow the 659 representation of many values that can be written as decimal 660 fractions as used in SMIng for human readability. Therefore, 661 explicit values in floating point type restrictions should be handled 662 with care. 664 Value Examples: 666 00.1 // illegal leading zero 667 3.1415 // legal value 668 -2.5E+3 // legal negative exponential value 670 Restriction Examples: 672 Float64 (-1.0..1.0) // legal range spec 673 Float64 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 674 Float64 (neginf..-0.0) // legal range spec 675 Float64 (-10.0..10.0 | 0) // illegal overlapping 677 3.10 Float128 679 The Float128 base type represents floating point values of quadruple 680 precision as described by [15]. 682 Values of type Float128 may be denoted as a decimal fraction with an 683 optional exponent as known from many programming languages. See the 684 grammar rule `floatValue' of Appendix A for the detailed syntax. 685 Special values are `snan' (signaling Not-a-Number), `qnan' (quiet 686 Not-a-Number), `neginf' (negative infinity), and `posinf' (positive 687 infinity). Note that -0.0 and +0.0 are different floating point 688 values. 0.0 is equal to +0.0. 690 When defining a type derived (directly or indirectly) from the 691 Float128 base type, the set of possible values may be restricted by 692 appending a list of ranges or explicit values, separated by pipe `|' 693 characters and the whole list enclosed in parenthesis. A range 694 consists of a lower bound, two consecutive dots `..' and an upper 695 bound. If multiple values or ranges are given they all MUST be 696 disjoint and MUST be in ascending order. If a value restriction is 697 applied to an already restricted type the new restriction MUST be 698 equal or more limiting, that is raising the lower bounds, reducing 699 the upper bounds, removing explicit values or ranges, or splitting 700 ranges into multiple ranges with intermediate gaps. The special 701 values `snan', `qnan', `neginf', and `posinf' must be explicitly 702 listed in restrictions if they shall be included, where `snan' and 703 `qnan' cannot be used in ranges. 705 Note that encoding is not subject to this specification. It has to 706 be described by protocols that transport objects of type Float128. 707 Note also that most floating point encodings disallow the 708 representation of many values that can be written as decimal 709 fractions as used in SMIng for human readability. Therefore, 710 explicit values in floating point type restrictions should be handled 711 with care. 713 Value Examples: 715 00.1 // illegal leading zero 716 3.1415 // legal value 717 -2.5E+3 // legal negative exponential value 719 Restriction Examples: 721 Float128 (-1.0..1.0) // legal range spec 722 Float128 (1 | 3.3 | 5) // legal, probably unrepresentable 3.3 723 Float128 (neginf..-0.0) // legal range spec 724 Float128 (-10.0..10.0 | 0) // illegal overlapping 726 3.11 Enumeration 728 The Enumeration base type represents values from a set of integers in 729 the range between -2^31 (-2147483648) and 2^31-1 (2147483647), where 730 each value has an assigned name. The list of those named numbers has 731 to be comma-separated, enclosed in parenthesis and appended to the 732 `Enumeration' keyword. Each named number is denoted by its lower- 733 case identifier followed by the assigned integer value, denoted as a 734 decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis. 735 Hexadecimal numbers must have an even number of at least two digits. 736 Every name and every number in an enumeration type MUST be unique. 737 It is RECOMMENDED that values are positive and start at 1 and be 738 numbered contiguously. All named numbers MUST be given in ascending 739 order. 741 Values of enumeration types may be denoted as decimal or `0x'- 742 prefixed hexadecimal numbers or preferably as their assigned names. 743 Hexadecimal numbers must have an even number of at least two digits. 745 When defining a type derived (directly or indirectly) from an 746 enumeration type, the set of named numbers may be equal or restricted 747 by removing one or more named numbers. But no named numbers may be 748 added or changed regarding its name, value, or both. 750 Type and Value Examples: 752 Enumeration (up(1), down(2), testing(3)) 753 Enumeration (down(2), up(1)) // illegal order 755 0 // legal (though not recommended) value 756 up // legal value given by name 757 2 // legal value given by number 759 3.12 Bits 761 The Bits base type represents bit sets. That is, a Bits value is a 762 set of flags identified by small integer numbers starting at 0. Each 763 bit number has an assigned name. The list of those named numbers has 764 to be comma-separated, enclosed in parenthesis and appended to the 765 `Bits' keyword. Each named number is denoted by its lower-case 766 identifier followed by the assigned integer value, denoted as a 767 decimal or `0x'-prefixed hexadecimal number, enclosed in parenthesis. 768 Hexadecimal numbers must have an even number of at least two digits. 769 Every name and every number in a bits type MUST be unique. It is 770 RECOMMENDED that numbers start at 0 and be numbered contiguously. 771 Negative numbers are forbidden. All named numbers MUST be given in 772 ascending order. 774 Values of bits types may be denoted as a comma-separated list of 775 decimal or `0x'-prefixed hexadecimal numbers or preferably their 776 assigned names enclosed in parenthesis. Hexadecimal numbers must 777 have an even number of at least two digits. There MUST NOT be any 778 element (by name or number) listed more than once. Elements MUST be 779 listed in ascending order. 781 When defining a type derived (directly or indirectly) from a bits 782 type, the set of named numbers may be restricted by removing one or 783 more named numbers. But no named numbers may be added or changed 784 regarding its name, value, or both. 786 Type and Value Examples: 788 Bits (readable(0), writeable(1), executable(2)) 789 Bits (writeable(1), readable(0) // illegal order 791 () // legal empty value 792 (readable, writeable, 2) // legal value 793 (0, readable, executable) // illegal, readable(0) appears twice 794 (writeable, 4) // illegal, element 4 out of range 796 3.13 Display Formats 798 Attribute definitions and type definitions allow the specification of 799 a format to be used, when a value of that attribute or an attribute 800 of that type is displayed. Format specifications are represented as 801 textual data. 803 When the attribute or type has an underlying base type of Integer32, 804 Integer64, Unsigned32, or Unsigned64, the format consists of an 805 integer-format specification, containing two parts. The first part 806 is a single character suggesting a display format, either: `x' for 807 hexadecimal, or `d' for decimal, or `o' for octal, or `b' for binary. 808 For all types, when rendering the value, leading zeros are omitted, 809 and for negative values, a minus sign is rendered immediately before 810 the digits. The second part is always omitted for `x', `o' and `b', 811 and need not be present for `d'. If present, the second part starts 812 with a hyphen and is followed by a decimal number, which defines the 813 implied decimal point when rendering the value. For example `d-2' 814 suggests that a value of 1234 be rendered as `12.34'. 816 When the attribute or type has an underlying base type of 817 OctetString, the format consists of one or more octet-format 818 specifications. Each specification consists of five parts, with each 819 part using and removing zero or more of the next octets from the 820 value and producing the next zero or more characters to be displayed. 821 The octets within the value are processed in order of significance, 822 most significant first. 824 The five parts of a octet-format specification are: 826 1. the (optional) repeat indicator; if present, this part is a `*', 827 and indicates that the current octet of the value is to be used 828 as the repeat count. The repeat count is an unsigned integer 829 (which may be zero) which specifies how many times the remainder 830 of this octet-format specification should be successively 831 applied. If the repeat indicator is not present, the repeat 832 count is one. 834 2. the octet length: one or more decimal digits specifying the 835 number of octets of the value to be used and formatted by this 836 octet-specification. Note that the octet length can be zero. If 837 less than this number of octets remain in the value, then the 838 lesser number of octets are used. 840 3. the display format, either: `x' for hexadecimal, `d' for decimal, 841 `o' for octal, `a' for ASCII, or `t' for UTF-8 [16]. If the 842 octet length part is greater than one, and the display format 843 part refers to a numeric format, then network byte-ordering (big- 844 endian encoding) is used interpreting the octets in the value. 845 The octets processed by the `t' display format do not necessarily 846 form an integral number of UTF-8 characters. Trailing octets 847 which do not form a valid UTF-8 encoded character are discarded. 849 4. the (optional) display separator character; if present, this part 850 is a single character which is produced for display after each 851 application of this octet-specification; however, this character 852 is not produced for display if it would be immediately followed 853 by the display of the repeat terminator character for this octet 854 specification. This character can be any character other than a 855 decimal digit and a `*'. 857 5. the (optional) repeat terminator character, which can be present 858 only if the display separator character is present and this octet 859 specification begins with a repeat indicator; if present, this 860 part is a single character which is produced after all the zero 861 or more repeated applications (as given by the repeat count) of 862 this octet specification. This character can be any character 863 other than a decimal digit and a `*'. 865 Output of a display separator character or a repeat terminator 866 character is suppressed if it would occur as the last character of 867 the display. 869 If the octets of the value are exhausted before all the octet format 870 specification have been used, then the excess specifications are 871 ignored. If additional octets remain in the value after interpreting 872 all the octet format specifications, then the last octet format 873 specification is re-interpreted to process the additional octets, 874 until no octets remain in the value. 876 Note that for some types no format specifications are defined and 877 SHOULD be omitted. Implementations MUST ignore format specifications 878 they cannot interpret. Also note that the SMIng grammar (Appendix A) 879 does not specify the syntax of format specifications. 881 Display Format Examples: 883 Base Type Format Example Value Rendered Value 884 ----------- ------------------- ---------------- ----------------- 885 OctetString 255a "Hello World." Hello World. 886 OctetString 1x: "Hello!" 48:65:6c:6c:6f:21 887 OctetString 1d:1d:1d.1d,1a1d:1d 0x0d1e0f002d0400 13:30:15.0,-4:0 888 OctetString 1d.1d.1d.1d/2d 0x0a0000010400 10.0.0.1/1024 889 OctetString *1x:/1x: 0x02aabbccddee aa:bb/cc:dd:ee 890 Integer32 d-2 1234 12.34 892 4. The SMIng File Structure 894 The topmost container of SMIng information is a file. An SMIng file 895 may contain zero, one or more modules. It is RECOMMENDED to separate 896 modules into files named by their modules, where possible. Though, 897 for dedicated purposes it may be reasonable to collect several 898 modules in a single file. 900 The top level SMIng construct is the `module' statement (Section 5) 901 that defines a single SMIng module. A module contains a sequence of 902 sections in an obligatory order with different kinds of definitions. 903 Whether these sections contain statements or remain empty mainly 904 depends on the purpose of the module. 906 4.1 Comments 908 Comments can be included at any position in an SMIng file, except in 909 between the characters of a single token like those of a quoted 910 string. However, it is RECOMMENDED that all substantive descriptions 911 be placed within an appropriate description clause, so that the 912 information is available to SMIng parsers. 914 Comments commence with a pair of adjacent slashes `//' and end at the 915 end of the line. 917 4.2 Statements and Arguments 919 SMIng has a very small set of basic grammar rules based on the 920 concept of statements. Each statement starts with a lower-case 921 keyword identifying the statement followed by a number (possibly 922 zero) of arguments. An argument may be quoted text, an identifier, a 923 value of any base type, a list of identifiers enclosed in parenthesis 924 `( )' or a statement block enclosed in curly braces `{ }'. Since 925 statement blocks are valid arguments, it is possible to nest 926 statement sequences. Each statement is terminated by a semicolon 927 `;'. 929 The core set of statements may be extended using the SMIng 930 `extension' statement. See Section 6 and Section 11 for details. 932 At places where a statement is expected, but an unknown lower-case 933 word is read, those statements MUST be skipped up to the proper 934 semicolon, including nested statement blocks. 936 5. The module Statement 938 The `module' statement is used as a container of all definitions of a 939 single SMIng module. It gets two arguments: an upper-case module 940 name and a statement block that contains mandatory and optional 941 statements and sections of statements in an obligatory order: 943 module { 945 946 947 948 949 950 952 954 956 958 }; 960 The optional `import' statements are followed by the mandatory 961 `organization', `contact', and `description' statements and the 962 optional `reference' statement, which in turn are followed by the 963 mandatory `revision' statements. This part defines the module's meta 964 information while the following sections contain its main 965 definitions. 967 See the `moduleStatement' rule of the SMIng grammar (Appendix A) for 968 the formal syntax of the `module' statement. 970 5.1 The module's import Statement 972 The optional module's `import' statement is used to import 973 identifiers from external modules into the local module's namespace. 974 It gets two arguments: the name of the external module and a comma- 975 separated list of one or more identifiers to be imported enclosed in 976 parenthesis. 978 Multiple `import' statements for the same module but with disjoint 979 lists of identifiers are allowed, though NOT RECOMMENDED. Anyhow, 980 the same identifier from the same module MUST NOT be imported 981 multiple times. To import identifiers with the same name from 982 different modules might be necessary and is allowed. To distinguish 983 them in the local module, they have to be referred by qualified 984 names. It is NOT RECOMMENDED to import identifiers not used in the 985 local module. 987 See the `importStatement' rule of the SMIng grammar (Appendix A) for 988 the formal syntax of the `import' statement. 990 5.2 The module's organization Statement 992 The module's `organization' statement, which must be present, gets 993 one argument which is used to specify a textual description of the 994 organization(s) under whose auspices this module was developed. 996 5.3 The module's contact Statement 998 The module's `contact' statement, which must be present, gets one 999 argument which is used to specify the name, postal address, telephone 1000 number, and electronic mail address of the person to whom technical 1001 queries concerning this module should be sent. 1003 5.4 The module's description Statement 1005 The module's `description' statement, which must be present, gets one 1006 argument which is used to specify a high-level textual description of 1007 the contents of this module. 1009 5.5 The module's reference Statement 1011 The module's `reference' statement, which need not be present, gets 1012 one argument which is used to specify a textual cross-reference to 1013 some other document, either another module which defines related 1014 management information, or some other document which provides 1015 additional information relevant to this module. 1017 5.6 The module's revision Statement 1019 The module's `revision' statement is repeatedly used to specify the 1020 editorial revisions of the module, including the initial revision. 1021 It gets one argument which is a statement block that holds detailed 1022 information in an obligatory order. A module MUST have at least one 1023 initial `revision' statement. For every editorial change, a new one 1024 MUST be added in front of the revisions sequence, so that all 1025 revisions are in reverse chronological order. 1027 See the `revisionStatement' rule of the SMIng grammar (Appendix A) 1028 for the formal syntax of the `revision' statement. 1030 5.6.1 The revision's date Statement 1032 The revision's `date' statement, which must be present, gets one 1033 argument which is used to specify the date and time of the revision 1034 in the format `YYYY-MM-DD HH:MM' or `YYYY-MM-DD' which implies the 1035 time `00:00'. The time is always given in UTC. 1037 See the `date' rule of the SMIng grammar (Appendix A) for the formal 1038 syntax of the revision's `date' statement. 1040 5.6.2 The revision's description Statement 1042 The revision's `description' statement, which must be present, gets 1043 one argument which is used to specify a high-level textual 1044 description of the revision. 1046 5.7 Usage Example 1048 Consider how a skeletal module might be constructed: 1050 module FIZBIN { 1052 import IETF-SMING (DisplayString); 1054 organization 1055 "IETF Next Generation Structure of 1056 Management Information Working Group (SMING)"; 1058 contact 1059 "Frank Strauss 1061 TU Braunschweig 1062 Bueltenweg 74/75 1063 38106 Braunschweig 1064 Germany 1066 Phone: +49 531 391-3266 1067 EMail: strauss@ibr.cs.tu-bs.de"; 1069 description 1070 "The module for entities implementing 1071 the xxxx protocol."; 1072 reference 1073 "RFC 2578, Section 5.7."; 1075 revision { 1076 date "2001-03-02"; 1077 description 1078 "Initial revision, published as RFC XXXX."; 1079 }; 1081 // ... further definitions ... 1083 }; // end of module FIZBIN. 1085 6. The extension Statement 1087 The `extension' statement is used to define new statements to be used 1088 in the local module following this extension statement definition or 1089 in external modules that may import this extension statement 1090 definition. The `extension' statement gets two arguments: a lower- 1091 case extension statement identifier and a statement block that holds 1092 detailed extension information in an obligatory order. 1094 Extension statement identifiers SHOULD NOT contain any upper-case 1095 characters. 1097 Note that the SMIng extension feature does not allow to formally 1098 specify the context, argument syntax and semantics of an extension. 1099 Its only purpose is to declare the existence of an extension and to 1100 allow a unique reference to an extension. See Section 11 for 1101 detailed information on extensions and [3] for mappings of SMIng 1102 definitions to SNMP which is formally defined as an extension. 1104 See the `extensionStatement' rule of the SMIng grammar (Appendix A) 1105 for the formal syntax of the `extension' statement. 1107 6.1 The extension's status Statement 1109 The extension's `status' statement, which must be present, gets one 1110 argument which is used to specify whether this extension definition 1111 is current or historic. The value `current' means that the 1112 definition is current and valid. The value `obsolete' means the 1113 definition is obsolete and should not be implemented and/or can be 1114 removed if previously implemented. While the value `deprecated' also 1115 indicates an obsolete definition, it permits new/continued 1116 implementation in order to foster interoperability with 1117 older/existing implementations. 1119 6.2 The extension's description Statement 1121 The extension's `description' statement, which must be present, gets 1122 one argument which is used to specify a high-level textual 1123 description of the extension statement. 1125 It is RECOMMENDED to include information on the extension's context, 1126 its semantics, and implementation conditions. See also Section 11. 1128 6.3 The extension's reference Statement 1130 The extension's `reference' statement, which need not be present, 1131 gets one argument which is used to specify a textual cross-reference 1132 to some other document, either another module which defines related 1133 extension definitions, or some other document which provides 1134 additional information relevant to this extension. 1136 6.4 The extension's abnf Statement 1138 The extension's `abnf' statement, which need not be present, gets one 1139 argument which is used to specify a formal ABNF [12] grammar 1140 definition of the extension. This grammar can reference rule names 1141 from the core SMIng grammar Appendix A. 1143 Note that the `abnf' statement should contain only pure ABNF and no 1144 additional text, though comments prefixed by semicolon are allowed 1145 but should probably be moved to the description statement. Note that 1146 double quotes are not allowed inside textual descriptions which are 1147 itself enclosed in double quotes. So they have to be replaced by 1148 single quotes. 1150 6.5 Usage Example 1152 extension severity { 1153 status current; 1154 description 1155 "The optional severity extension statement can only 1156 be applied to the statement block of an SMIng class' 1157 event definition. If it is present it denotes the 1158 severity level of the event in a range from 0 1159 (emergency) to 7 (debug)."; 1160 abnf 1161 "severityStatement = severityKeyword sep number optsep ';' 1162 severityKeyword = 'severity'"; 1163 }; 1165 7. The typedef Statement 1167 The `typedef' statement is used to define new data types to be used 1168 in the local module or in external modules. It gets two arguments: 1169 an upper-case type identifier and a statement block that holds 1170 detailed type information in an obligatory order. 1172 Type identifiers SHOULD NOT consist of all upper-case characters and 1173 SHOULD NOT contain hyphens. 1175 See the `typedefStatement' rule of the SMIng grammar (Appendix A) for 1176 the formal syntax of the `typedef' statement. 1178 7.1 The typedef's type Statement 1180 The typedef's `type' statement, which must be present, gets one 1181 argument which is used to specify the type from which this type is 1182 derived. Optionally, type restrictions may be applied to the new 1183 type by appending subtyping information according to the rules of the 1184 base type. See Section 3 for SMIng base types and their type 1185 restrictions. 1187 7.2 The typedef's default Statement 1189 The typedef's `default' statement, which need not be present, gets 1190 one argument which is used to specify an acceptable default value for 1191 attributes of this type. A default value may be used when an 1192 attribute instance is created. That is, the value is a "hint" to 1193 implementors. 1195 The value of the `default' statement must, of course, correspond to 1196 the (probably restricted) type specified in the typedef's `type' 1197 statement. 1199 The default value of a type may be overwritten by a default value of 1200 an attribute of this type. 1202 Note that for some types, default values make no sense. 1204 7.3 The typedef's format Statement 1206 The typedef's `format' statement, which need not be present, gets one 1207 argument which is used to give a hint as to how the value of an 1208 instance of an attribute of this type might be displayed. See 1209 Section 3.13 for a description of format specifications. 1211 If no format is specified, it is inherited from the type given in the 1212 `type' statement. On the other hand, the format specification of a 1213 type may be semantically refined by a format specification of an 1214 attribute of this type. 1216 7.4 The typedef's units Statement 1218 The typedef's `units' statement, which need not be present, gets one 1219 argument which is used to specify a textual definition of the units 1220 associated with attributes of this type. 1222 If no units are specified, they are inherited from the type given in 1223 the `type' statement. On the other hand, the units specification of 1224 a type may be semantically refined by a units specification of an 1225 attribute of this type. 1227 The units specification has to be appropriate for values displayed 1228 according to the typedef's format specification, if present. E.g., 1229 if the type defines frequency values of type Unsigned64 measured in 1230 thousands of Hertz, the format specification should be `d-3' and the 1231 units specification should be `Hertz' or `Hz'. If the format 1232 specification would be omitted, the units specification should be 1233 `Milli-Hertz' or `mHz'. Authors of SMIng modules should pay 1234 attention to keep format and units specifications synced. 1235 Application implementors MUST NOT implement units specifications 1236 without implementing format specifications. 1238 7.5 The typedef's status Statement 1240 The typedef's `status' statement, which must be present, gets one 1241 argument which is used to specify whether this type definition is 1242 current or historic. The value `current' means that the definition 1243 is current and valid. The value `obsolete' means the definition is 1244 obsolete and should not be implemented and/or can be removed if 1245 previously implemented. While the value `deprecated' also indicates 1246 an obsolete definition, it permits new/continued implementation in 1247 order to foster interoperability with older/existing implementations. 1249 Derived types SHOULD NOT be defined as `current' if their underlying 1250 type is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be 1251 defined as `deprecated' if their underlying type is `obsolete'. 1252 Nevertheless, subsequent revisions of the underlying type cannot be 1253 avoided, but SHOULD be taken into account in subsequent revisions of 1254 the local module. 1256 7.6 The typedef's description Statement 1258 The typedef's `description' statement, which must be present, gets 1259 one argument which is used to specify a high-level textual 1260 description of the newly defined type. 1262 It is RECOMMENDED to include all semantic definitions necessary for 1263 implementation, and to embody any information which would otherwise 1264 be communicated in any commentary annotations associated with this 1265 type definition. 1267 7.7 The typedef's reference Statement 1269 The typedef's `reference' statement, which need not be present, gets 1270 one argument which is used to specify a textual cross-reference to 1271 some other document, either another module which defines related type 1272 definitions, or some other document which provides additional 1273 information relevant to this type definition. 1275 7.8 Usage Examples 1276 typedef RptrOperStatus { 1277 type Enumeration (other(1), ok(2), rptrFailure(3), 1278 groupFailure(4), portFailure(5), 1279 generalFailure(6)); 1280 default other; // undefined by default. 1281 status deprecated; 1282 description 1283 "A type to indicate the operational state 1284 of a repeater."; 1285 reference 1286 "[IEEE 802.3 Mgt], 30.4.1.1.5, aRepeaterHealthState."; 1287 }; 1289 typedef SnmpTransportDomain { 1290 type Pointer (snmpTransportDomain); 1291 status current; 1292 description 1293 "A pointer to an SNMP transport domain identity."; 1294 }; 1296 typedef DateAndTime { 1297 type OctetString (8 | 11); 1298 format "2d-1d-1d,1d:1d:1d.1d,1a1d:1d"; 1299 status current; 1300 description 1301 "A date-time specification. 1302 ... 1303 Note that if only local time is known, then timezone 1304 information (fields 8-10) is not present."; 1305 reference 1306 "RFC 2579, SNMPv2-TC.DateAndTime."; 1307 }; 1309 typedef Frequency { 1310 type Unsigned64; 1311 format "d-3" 1312 units "Hertz"; 1313 status current; 1314 description 1315 "A wide-range frequency specification measured 1316 in thousands of Hertz."; 1317 }; 1319 8. The identity Statement 1321 The `identity' statement is used to define a new abstract and untyped 1322 identity. Its only purpose is to denote its name, semantics and 1323 existence. An identity can be defined either from scratch or derived 1324 from a parent identity. The `identity' statement gets the following 1325 two or four arguments: The first argument is a lower-case identity 1326 identifier and the last argument is a statement block that holds 1327 detailed identity information in an obligatory order. In case of 1328 derived identities there are two tokens inbetween: a single colon `:' 1329 and the identifier of the parent identity. 1331 See the `identityStatement' rule of the SMIng grammar (Appendix A) 1332 for the formal syntax of the `identity' statement. 1334 8.1 The identity's status Statement 1336 The identity's `status' statement, which must be present, gets one 1337 argument which is used to specify whether this identity definition is 1338 current or historic. The value `current' means that the definition 1339 is current and valid. The value `obsolete' means the definition is 1340 obsolete and should not be implemented and/or can be removed if 1341 previously implemented. While the value `deprecated' also indicates 1342 an obsolete definition, it permits new/continued implementation in 1343 order to foster interoperability with older/existing implementations. 1345 Derived identities SHOULD NOT be defined as `current' if their parent 1346 identity is `deprecated' or `obsolete'. Similarly, they SHOULD NOT 1347 be defined as `deprecated' if their parent identity is `obsolete'. 1348 Nevertheless, subsequent revisions of the parent identity cannot be 1349 avoided, but SHOULD be taken into account in subsequent revisions of 1350 the local module. 1352 8.2 The identity' description Statement 1354 The identity's `description' statement, which must be present, gets 1355 one argument which is used to specify a high-level textual 1356 description of the newly defined identity. 1358 It is RECOMMENDED to include all semantic definitions necessary for 1359 implementation, and to embody any information which would otherwise 1360 be communicated in any commentary annotations associated with this 1361 identity definition. 1363 8.3 The identity's reference Statement 1365 The identity's `reference' statement, which need not be present, gets 1366 one argument which is used to specify a textual cross-reference to 1367 some other document, either another module which defines related 1368 identity definitions, or some other document which provides 1369 additional information relevant to this identity definition. 1371 8.4 Usage Examples 1373 identity null { 1374 status current; 1375 description 1376 "An identity used to represent null pointer values."; 1377 }; 1379 identity snmpTransportDomain { 1380 status current; 1381 description 1382 "A generic SNMP transport domain identity."; 1383 }; 1385 identity snmpUDPDomain : snmpTransportDomain { 1386 status current; 1387 description 1388 "The SNMP over UDP transport domain."; 1389 }; 1391 9. The class Statement 1393 The `class' statement is used to define a new class, that represents 1394 a container of related attributes and events (Section 9.1, Section 1395 9.3) in an object-oriented manner. Thus, a class can be defined 1396 either from scratch or derived from a parent class. A derived class 1397 inherits all attributes and events of the parent class and can be 1398 extended by additional attributes and events. Furthermore, parent 1399 attributes can be refined by new attributes of the same name that are 1400 more specific in their formal type restrictions or their semantics 1401 specified in the attribute description clause. Similarly, parent 1402 events can be refined by new events of the same name that are more 1403 specific in their semantics specified in the event description 1404 clause. 1406 The `class' statement gets the following two or four arguments: The 1407 first argument is an upper-case class identifier and the last 1408 argument is a statement block that holds detailed class information 1409 in an obligatory order. In case of derived classes there are two 1410 tokens inbetween: a single colon `:' and the identifier of the parent 1411 class. 1413 See the `classStatement' rule of the SMIng grammar (Appendix A) for 1414 the formal syntax of the `class' statement. 1416 9.1 The class' attribute Statement 1418 The class' `attribute' statement, which can be present zero, one or 1419 multiple times, gets three arguments: a type or class name, the 1420 attribute name, and a statement block that holds detailed attribute 1421 information in an obligatory order. 1423 9.1.1 The attribute's access Statement 1425 The attribute's `access' statement must be present for attributes 1426 typed by a base type or derived type, and must be absent for 1427 attributes typed by a class. It gets one argument which is used to 1428 specify whether it makes sense to read and/or write an instance of 1429 the attribute, or to include its value in an event. This is the 1430 maximal level of access for the attribute. This maximal level of 1431 access is independent of any administrative authorization policy. 1433 The value `readwrite' indicates that read and write access makes 1434 sense. The value `readonly' indicates that read access makes sense, 1435 but write access is never possible. The value `eventonly' indicates 1436 an object which is accessible only via an event. 1438 These values are ordered, from least to greatest access level: 1439 `eventonly', `readonly', `readwrite'. 1441 9.1.2 The attribute's default Statement 1443 The attribute's `default' statement need not be present for 1444 attributes typed by a base type or derived type, and must be absent 1445 for attributes typed by a class. It gets one argument which is used 1446 to specify an acceptable default value for this attribute. A default 1447 value may be used when an attribute instance is created. That is, 1448 the value is a "hint" to implementors. 1450 The value of the `default' statement must, of course, correspond to 1451 the (probably restricted) type specified in the attribute's `type' 1452 statement. 1454 The attribute's default value overrides the default value of the 1455 underlying type definition if both are present. 1457 9.1.3 The attribute's format Statement 1459 The attribute's `format' statement need not be present for attributes 1460 typed by a base type or derived type, and must be absent for 1461 attributes typed by a class. It gets one argument which is used to 1462 give a hint as to how the value of an instance of this attribute 1463 might be displayed. See Section 3.13 for a description of format 1464 specifications. 1466 The attribute's format specification overrides the format 1467 specification of the underlying type definition if both are present. 1469 9.1.4 The attribute's units Statement 1471 The attribute's `units' statement need not be present for attributes 1472 typed by a base type or derived type, and must be absent for 1473 attributes typed by a class. It gets one argument which is used to 1474 specify a textual definition of the units associated with this 1475 attribute. 1477 The attribute's units specification overrides the units specification 1478 of the underlying type definition if both are present. 1480 The units specification has to be appropriate for values displayed 1481 according to the attribute's format specification if present. E.g., 1482 if the attribute represents a frequency value of type Unsigned64 1483 measured in thousands of Hertz, the format specification should be 1484 `d-3' and the units specification should be `Hertz' or `Hz'. If the 1485 format specification would be omitted the units specification should 1486 be `Milli-Hertz' or `mHz'. Authors of SMIng modules should pay 1487 attention to keep format and units specifications of type and 1488 attribute definitions synced. Application implementors MUST NOT 1489 implement units specifications without implementing format 1490 specifications. 1492 9.1.5 The attribute's status Statement 1494 The attribute's `status' statement must be present for attributes 1495 typed by a base type or derived type, and must be absent for 1496 attributes typed by a class. It gets one argument which is used to 1497 specify whether this attribute definition is current or historic. 1498 The value `current' means that the definition is current and valid. 1499 The value `obsolete' means the definition is obsolete and should not 1500 be implemented and/or can be removed if previously implemented. 1501 While the value `deprecated' also indicates an obsolete definition, 1502 it permits new/continued implementation in order to foster 1503 interoperability with older/existing implementations. 1505 Attributes SHOULD NOT be defined as `current' if their type or their 1506 containing class is `deprecated' or `obsolete'. Similarly, they 1507 SHOULD NOT be defined as `deprecated' if their type or their 1508 containting class is `obsolete'. Nevertheless, subsequent revisions 1509 of used type definition cannot be avoided, but SHOULD be taken into 1510 account in subsequent revisions of the local module. 1512 9.1.6 The attribute's description Statement 1514 The attribute's `description' statement, which must be present, gets 1515 one argument which is used to specify a high-level textual 1516 description of this attribute. 1518 It is RECOMMENDED to include all semantic definitions necessary for 1519 the implementation of this attribute. 1521 9.1.7 The attribute's reference Statement 1523 The attribute's `reference' statement, which need not be present, 1524 gets one argument which is used to specify a textual cross-reference 1525 to some other document, either another module which defines related 1526 attribute definitions, or some other document which provides 1527 additional information relevant to this attribute definition. 1529 9.2 The class' unique Statement 1531 The class' `unique' statement, which need not be present, gets one 1532 argument that specifies a comma-separated list of attributes of this 1533 class, enclosed in parenthesis. If present, this list of attributes 1534 makes up a unique identification of all possible instances of this 1535 class. It can be used as a unique key in underlying protocols. 1537 If the list is empty the class should be regarded as a scalar class 1538 with only a single static instance. 1540 If the `unique' statement is not present the class is not meant to be 1541 instantiated directly, but just to be contained in other classes or 1542 to be the parent class of other refining classes. 1544 If present, the attribute list MUST NOT contain any attribute more 1545 than once and the attributes should be ordered where appropriate so 1546 that the attributes that are most significant in most situations 1547 appear first. 1549 9.3 The class' event Statement 1551 The class' `event' statement is used to define an event related to an 1552 instance of this class that can occur asynchronously. It gets two 1553 arguments: a lower-case event identifier and a statement block that 1554 holds detailed information in an obligatory order. 1556 See the `eventStatement' rule of the SMIng grammar (Appendix A) for 1557 the formal syntax of the `event' statement. 1559 9.3.1 The event's status Statement 1561 The event's `status' statement, which must be present, gets one 1562 argument which is used to specify whether this event definition is 1563 current or historic. The value `current' means that the definition 1564 is current and valid. The value `obsolete' means the definition is 1565 obsolete and should not be implemented and/or can be removed if 1566 previously implemented. While the value `deprecated' also indicates 1567 an obsolete definition, it permits new/continued implementation in 1568 order to foster interoperability with older/existing implementations. 1570 9.3.2 The event's description Statement 1572 The event's `description' statement, which must be present, gets one 1573 argument which is used to specify a high-level textual description of 1574 this event. 1576 It is RECOMMENDED to include all semantic definitions necessary for 1577 the implementation of this event. In particular, it SHOULD be 1578 documented which instance of the class is associated with an event of 1579 this type. 1581 9.3.3 The event's reference Statement 1583 The event's `reference' statement, which need not be present, gets 1584 one argument which is used to specify a textual cross-reference to 1585 some other document, either another module which defines related 1586 event definitions, or some other document which provides additional 1587 information relevant to this event definition. 1589 9.4 The class' status Statement 1591 The class' `status' statement, which must be present, gets one 1592 argument which is used to specify whether this class definition is 1593 current or historic. The value `current' means that the definition 1594 is current and valid. The value `obsolete' means the definition is 1595 obsolete and should not be implemented and/or can be removed if 1596 previously implemented. While the value `deprecated' also indicates 1597 an obsolete definition, it permits new/continued implementation in 1598 order to foster interoperability with older/existing implementations. 1600 Derived classes SHOULD NOT be defined as `current' if their parent 1601 class is `deprecated' or `obsolete'. Similarly, they SHOULD NOT be 1602 defined as `deprecated' if their parent class is `obsolete'. 1603 Nevertheless, subsequent revisions of the parent class cannot be 1604 avoided, but SHOULD be taken into account in subsequent revisions of 1605 the local module. 1607 9.5 The class' description Statement 1609 The class' `description' statement, which must be present, gets one 1610 argument which is used to specify a high-level textual description of 1611 the newly defined class. 1613 It is RECOMMENDED to include all semantic definitions necessary for 1614 implementation, and to embody any information which would otherwise 1615 be communicated in any commentary annotations associated with this 1616 class definition. 1618 9.6 The class's reference Statement 1620 The class's `reference' statement, which need not be present, gets 1621 one argument which is used to specify a textual cross-reference to 1622 some other document, either another module which defines related 1623 class definitions, or some other document which provides additional 1624 information relevant to this class definition. 1626 9.7 Usage Example 1628 Consider how an event might be described that signals a status change 1629 of an interface: 1631 class Interface { 1632 // ... 1633 attribute Gauge32 speed { 1634 access readonly; 1635 units "bps"; 1636 status current; 1637 description 1638 "An estimate of the interface's current bandwidth 1639 in bits per second."; 1640 }; 1641 // ... 1642 attribute AdminStatus adminStatus { 1643 access readwrite; 1644 status current; 1645 description 1646 "The desired state of the interface."; 1647 }; 1648 attribute OperStatus operStatus { 1649 access readonly; 1650 status current; 1651 description 1652 "The current operational state of the interface."; 1653 }; 1655 event linkDown { 1656 status current; 1657 description 1658 "A linkDown event signifies that the ifOperStatus 1659 attribute for this interface instance is about to 1660 enter the down state from some other state (but not 1661 from the notPresent state). This other state is 1662 indicated by the included value of ifOperStatus."; 1663 }; 1665 status current; 1666 description 1667 "A physical or logical network interface."; 1669 }; 1671 10. Extending a Module 1673 As experience is gained with a module, it may be desirable to revise 1674 that module. However, changes are not allowed if they have any 1675 potential to cause interoperability problems between an 1676 implementation using an original specification and an implementation 1677 using an updated specification(s). 1679 For any change, some statements near the top of the module MUST be 1680 updated to include information about the revision: specifically, a 1681 new `revision' statement (Section 5.6) must be included in front of 1682 the `revision' statements. Furthermore, any necessary changes MUST 1683 be applied to other statements, including the `organization' and 1684 `contact' statements (Section 5.2, Section 5.3). 1686 Note that any definition contained in a module is available to be 1687 imported by any other module, and is referenced in an `import' 1688 statement via the module name. Thus, a module name MUST NOT be 1689 changed. Specifically, the module name (e.g., `FIZBIN' in the 1690 example of Section 5.7) MUST NOT be changed when revising a module 1691 (except to correct typographical errors), and definitions MUST NOT be 1692 moved from one module to another. 1694 Also note, that obsolete definitions MUST NOT be removed from modules 1695 since their identifiers may still be referenced by other modules. 1697 A definition may be revised in any of the following ways: 1699 o In `typedef' statement blocks, a `type' statement containing an 1700 `Enumeration' or `Bits' type may have new named numbers added. 1702 o In `typedef' statement blocks, the value of a `type' statement may 1703 be replaced by another type if the new type is derived (directly 1704 or indirectly) from the same base type, has the same set of 1705 values, and has identical semantics. 1707 o In `attribute' statements where the first argument specifies a 1708 class, the class may be replaced by another class if the new class 1709 is inherited (directly or indirectly) from the base class and both 1710 classes have identical semantics. 1712 o In `attribute' statements where the first argument specifies a 1713 type, the type may be replaced by another type if the new type is 1714 derived (directly or indirectly) from the same base type, has the 1715 same set of values, and has identical semantics. 1717 o In any statement block, a `status' statement value of `current' 1718 may be revised as `deprecated' or `obsolete'. Similarly, a 1719 `status' statement value of `deprecated' may be revised as 1720 `obsolete'. When making such a change, the `description' 1721 statement SHOULD be updated to explain the rationale. 1723 o In `typedef' and `attribute' statement blocks, a `default' 1724 statement may be added or updated. 1726 o In `typedef' and `attribute' statement blocks, a `units' statement 1727 may be added. 1729 o A class may be augmented by adding new attributes. 1731 o In any statement block, clarifications and additional information 1732 may be included in the `description' statement. 1734 o In any statement block, a `reference' statement may be added or 1735 updated. 1737 o Entirely new extensions, types, identities, and classes may be 1738 defined, using previously unassigned identifiers. 1740 Otherwise, if the semantics of any previous definition are changed 1741 (i.e., if a non-editorial change is made to any definition other than 1742 those specifically allowed above), then this MUST be achieved by a 1743 new definition with a new identifier. In case of a class where the 1744 semantics of any attributes are changed, the new class can be defined 1745 by inheritence from the old class and refining the changed 1746 attributes. 1748 Note that changing the identifier associated with an existing 1749 definition is considered a semantic change, as these strings may be 1750 used in an `import' statement. 1752 11. SMIng Language Extensibility 1754 While the core SMIng language has a well defined set of statements 1755 (Section 5 through Section 9.3) that are used to specify those 1756 aspects of management information commonly regarded as necessary 1757 without management protocol specific information, there may be 1758 further information, people wish to express. To describe additional 1759 information informally in description statements has the disadvantage 1760 that this information cannot be parsed by any program. 1762 SMIng allows modules to include statements that are unknown to a 1763 parser but fulfill some core grammar rules (Section 4.2). 1764 Furthermore, additional statements may be defined by the `extension' 1765 statement (Section 6). Extensions can be used in the local module or 1766 in other modules, that import the extension. This has some 1767 advantages: 1769 o A parser can differentiate between statements known as extensions 1770 and unknown statements. This enables the parser to complain about 1771 unknown statements, e.g. due to typos. 1773 o If an extension's definition contains a formal ABNF grammar 1774 definition and a parser is able to interpret this ABNF definition, 1775 this enables the parser also to complain about wrong usage of an 1776 extension. 1778 o Since, there might be some common need for extensions, there is a 1779 relatively high probability of extension name collisions 1780 originated by different organizations, as long as there is no 1781 standardized extension for that purpose. The requirement to 1782 explicitly import extension statements allows to distinguish those 1783 extensions. 1785 o The supported extensions of an SMIng implementation, e.g. a SMIng 1786 module compiler, can be clearly expressed. 1788 The only formal effect of an extension statement definition is to 1789 declare its existence and its status, and optionally its ABNF 1790 grammar. All additional aspects SHOULD be described in the 1791 `description' statement: 1793 o The detailed semantics of the new statement SHOULD be described. 1795 o The contexts in which the new statement can be used, SHOULD be 1796 described, e.g., a new statement may be designed to be used only 1797 in the statement block of a module, but not in other nested 1798 statement blocks. Others may be applicable in multiple contexts. 1799 In addition, the point in the sequence of an obligatory order of 1800 other statements, where the new statement may be inserted, might 1801 be prescribed. 1803 o The circumstances that make the new statement mandatory or 1804 optional SHOULD be described. 1806 o The syntax of the new statement SHOULD at least be described 1807 informally, if not supplied formally in an `abnf' statement. 1809 o It might be reasonable to give some suggestions under which 1810 conditions the implementation of the new statement is adequate and 1811 how it could be integrated into existent implementations. 1813 Some possible extension applications are: 1815 o The formal mappings of SMIng definitions into the SNMP ([3]) and 1816 COPS-PR frameworks are defined as SMIng extensions. 1818 o Inlined annotations to definitions. E.g., a vendor may wish to 1819 describe additional information to class and attribute definitions 1820 in private modules. An example are severity levels of events in 1821 the statement block of an `event' statement. 1823 o Arbitrary annotations to external definitions. E.g., a vendor may 1824 wish to describe additional information to definitions in a 1825 "standard" module. This allows a vendor to implement "standard" 1826 modules as well as additional private features, without redundant 1827 module definitions, but on top of "standard" module definitions. 1829 12. Security Considerations 1831 This document defines a language with which to write and read 1832 descriptions of management information. The language itself has no 1833 security impact on the Internet. 1835 13. Acknowledgements 1837 Since SMIng started as a close successor of SMIv2, some paragraphs 1838 and phrases are directly taken from the SMIv2 specifications [5], 1839 [6], [7] written by Jeff Case, Keith McCloghrie, David Perkins, 1840 Marshall T. Rose, Juergen Schoenwaelder, and Steven L. Waldbusser. 1842 The authors would like to thank all participants of the 7th NMRG 1843 meeting held in Schloss Kleinheubach from 6-8 September 2000, which 1844 was a major step towards the current status of this memo, namely 1845 Heiko Dassow, David Durham, and Bert Wijnen. 1847 Marshall T. Rose's work on an XML framework for RFC authors [17] 1848 made the writing of an Internet standards document much more 1849 comfortable. 1851 References 1853 [1] Strauss, F. and J. Schoenwaelder, "SMIng Core Modules", draft- 1854 ietf-sming-modules-02.txt, July 2001. 1856 [2] Strauss, F. and J. Schoenwaelder, "SMIng Internet Protocol Core 1857 Modules", draft-ietf-sming-inet-modules-02.txt, July 2001. 1859 [3] Strauss, F. and J. Schoenwaelder, "SMIng Extension for SNMP 1860 Mappings", draft-ietf-sming-snmp-02.txt, July 2001. 1862 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1863 Levels", RFC 2119, BCP 14, March 1997. 1865 [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 1866 M. and S. Waldbusser, "Structure of Management Information 1867 Version 2 (SMIv2)", RFC 2578, STD 58, April 1999. 1869 [6] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 1870 M. and S. Waldbusser, "Textual Conventions for SMIv2", RFC 1871 2579, STD 59, April 1999. 1873 [7] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, 1874 M. and S. Waldbusser, "Conformance Statements for SMIv2", RFC 1875 2580, STD 60, April 1999. 1877 [8] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S., 1878 Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy 1879 Provisioning Information (SPPI)", draft-ietf-rap-sppi-07.txt, 1880 May 2001. 1882 [9] Rose, M. and K. McCloghrie, "Structure and Identification of 1883 Management Information for TCP/IP-based Internets", RFC 1155, 1884 STD 16, May 1990. 1886 [10] Rose, M. and K. McCloghrie, "Concise MIB Definitions", RFC 1887 1212, STD 16, March 1991. 1889 [11] Rose, M., "A Convention for Defining Traps for use with the 1890 SNMP", RFC 1215, March 1991. 1892 [12] Crocker, D. and P. Overell, "Augmented BNF for Syntax 1893 Specifications: ABNF", RFC 2234, November 1997. 1895 [13] International Organization for Standardization, "Specification 1896 of Abstract Syntax Notation One (ASN.1)", International 1897 Standard 8824, December 1987. 1899 [14] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for 1900 Describing SNMP Management Frameworks", RFC 2271, January 1999. 1902 [15] Institute of Electrical and Electronics Engineers, "IEEE 1903 Standard for Binary Floating-Point Arithmetic", ANSI/IEEE 1904 Standard 754-1985, August 1985. 1906 [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1907 2279, January 1998. 1909 [17] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1910 1999. 1912 Authors' Addresses 1914 Frank Strauss 1915 TU Braunschweig 1916 Bueltenweg 74/75 1917 38106 Braunschweig 1918 Germany 1920 Phone: +49 531 391-3266 1921 EMail: strauss@ibr.cs.tu-bs.de 1922 URI: http://www.ibr.cs.tu-bs.de/ 1924 Juergen Schoenwaelder 1925 TU Braunschweig 1926 Bueltenweg 74/75 1927 38106 Braunschweig 1928 Germany 1930 Phone: +49 531 391-3289 1931 EMail: schoenw@ibr.cs.tu-bs.de 1932 URI: http://www.ibr.cs.tu-bs.de/ 1934 Appendix A. SMIng ABNF Grammar 1936 The SMIng grammar conforms to the Augmented Backus-Naur Form (ABNF) 1937 [12]. 1939 ;; 1940 ;; sming.abnf -- SMIng grammar in ABNF notation (RFC 2234). 1941 ;; 1942 ;; @(#) $Id: sming.abnf,v 1.24 2001/07/20 14:13:10 strauss Exp $ 1943 ;; 1944 ;; Copyright (C) The Internet Society (2001). All Rights Reserved. 1946 ;; 1948 ;; 1949 ;; This file is WORK IN PROGRESS. 1950 ;; 1952 smingFile = optsep *(moduleStatement optsep) 1954 ;; 1955 ;; Statement rules. 1956 ;; 1958 moduleStatement = moduleKeyword sep ucIdentifier optsep 1959 "{" stmtsep 1960 *(importStatement stmtsep) 1961 organizationStatement stmtsep 1962 contactStatement stmtsep 1963 descriptionStatement stmtsep 1964 *1(referenceStatement stmtsep) 1965 1*(revisionStatement stmtsep) 1966 *(extensionStatement stmtsep) 1967 *(typedefStatement stmtsep) 1968 *(identityStatement stmtsep) 1969 *(classStatement stmtsep) 1970 "}" optsep ";" 1972 extensionStatement = extensionKeyword sep lcIdentifier optsep 1973 "{" stmtsep 1974 statusStatement stmtsep 1975 descriptionStatement stmtsep 1976 *1(referenceStatement stmtsep) 1977 *1(abnfStatement stmtsep) 1978 "}" optsep ";" 1980 typedefStatement = typedefKeyword sep ucIdentifier optsep 1981 "{" stmtsep 1982 typedefTypeStatement stmtsep 1983 *1(defaultStatement stmtsep) 1984 *1(formatStatement stmtsep) 1985 *1(unitsStatement stmtsep) 1986 statusStatement stmtsep 1987 descriptionStatement stmtsep 1988 *1(referenceStatement stmtsep) 1989 "}" optsep ";" 1991 identityStatement = identityKeyword sep lcIdentifier optsep 1992 *1(":" optsep qlcIdentifier optsep) 1993 "{" stmtsep 1994 statusStatement stmtsep 1995 descriptionStatement stmtsep 1996 *1(referenceStatement stmtsep) 1997 "}" optsep ";" 1999 classStatement = classKeyword sep ucIdentifier optsep 2000 *1(":" optsep qucIdentifier optsep) 2001 "{" stmtsep 2002 *(attributeStatement stmtsep) 2003 *1(uniqueStatement stmtsep) 2004 *(eventStatement stmtsep) 2005 statusStatement stmtsep 2006 descriptionStatement stmtsep 2007 *1(referenceStatement stmtsep) 2008 "}" optsep ";" 2010 attributeStatement = attributeKeyword sep 2011 qucIdentifier sep 2012 lcIdentifier optsep 2013 "{" stmtsep 2014 *1(accessStatement stmtsep) 2015 *1(defaultStatement stmtsep) 2016 *1(formatStatement stmtsep) 2017 *1(unitsStatement stmtsep) 2018 statusStatement stmtsep 2019 descriptionStatement stmtsep 2020 *1(referenceStatement stmtsep) 2021 "}" optsep ";" 2023 uniqueStatement = uniqueKeyword optsep 2024 "(" optsep qlcIdentifierList 2025 optsep ")" optsep ";" 2027 eventStatement = eventKeyword sep lcIdentifier 2028 optsep "{" stmtsep 2029 statusStatement stmtsep 2030 descriptionStatement stmtsep 2031 *1(referenceStatement stmtsep) 2032 "}" optsep ";" 2034 importStatement = importKeyword sep ucIdentifier optsep 2035 "(" optsep 2036 identifierList optsep 2037 ")" optsep ";" 2039 revisionStatement = revisionKeyword optsep "{" stmtsep 2040 dateStatement stmtsep 2041 descriptionStatement stmtsep 2043 "}" optsep ";" 2045 typedefTypeStatement = typeKeyword sep refinedBaseType optsep ";" 2047 dateStatement = dateKeyword sep date optsep ";" 2049 organizationStatement = organizationKeyword sep text optsep ";" 2051 contactStatement = contactKeyword sep text optsep ";" 2053 formatStatement = formatKeyword sep format optsep ";" 2055 unitsStatement = unitsKeyword sep units optsep ";" 2057 statusStatement = statusKeyword sep status optsep ";" 2059 accessStatement = accessKeyword sep access optsep ";" 2061 defaultStatement = defaultKeyword sep anyValue optsep ";" 2063 descriptionStatement = descriptionKeyword sep text optsep ";" 2065 referenceStatement = referenceKeyword sep text optsep ";" 2067 abnfStatement = abnfKeyword sep text optsep ";" 2069 ;; 2070 ;; 2071 ;; 2073 refinedBaseType = IdentityKeyword / 2074 ObjectIdentifierKeyword / 2075 OctetStringKeyword *1(optsep numberSpec) / 2076 PointerKeyword *1(optsep pointerSpec) / 2077 Integer32Keyword *1(optsep numberSpec) / 2078 Unsigned32Keyword *1(optsep numberSpec) / 2079 Integer64Keyword *1(optsep numberSpec) / 2080 Unsigned64Keyword *1(optsep numberSpec) / 2081 Float32Keyword *1(optsep floatSpec) / 2082 Float64Keyword *1(optsep floatSpec) / 2083 Float128Keyword *1(optsep floatSpec) / 2084 EnumerationKeyword 2085 optsep namedSignedNumberSpec / 2086 BitsKeyword optsep namedNumberSpec 2088 refinedType = qucIdentifier *1(optsep anySpec) 2090 anySpec = pointerSpec / numberSpec / floatSpec 2091 pointerSpec = "(" optsep qlcIdentifier optsep ")" 2093 numberSpec = "(" optsep numberElement 2094 *furtherNumberElement 2095 optsep ")" 2097 furtherNumberElement = optsep "|" optsep numberElement 2099 numberElement = signedNumber *1numberUpperLimit 2101 numberUpperLimit = optsep ".." optsep signedNumber 2103 floatSpec = "(" optsep floatElement 2104 *furtherFloatElement 2105 optsep ")" 2107 furtherFloatElement = optsep "|" optsep floatElement 2109 floatElement = floatValue *1floatUpperLimit 2111 floatUpperLimit = optsep ".." optsep floatValue 2113 namedNumberSpec = "(" optsep namedNumberList optsep ")" 2115 namedNumberList = namedNumberItem 2116 *(optsep "," optsep namedNumberItem) 2117 *1(optsep ",") 2119 namedNumberItem = lcIdentifier optsep "(" optsep number 2120 optsep ")" 2122 namedSignedNumberSpec = "(" optsep namedSignedNumberList optsep ")" 2124 namedSignedNumberList = namedSignedNumberItem 2125 *(optsep "," optsep 2126 namedSignedNumberItem) 2127 *1(optsep ",") 2129 namedSignedNumberItem = lcIdentifier optsep "(" optsep signedNumber 2130 optsep ")" 2132 identifierList = identifier 2133 *(optsep "," optsep identifier) 2134 *1(optsep ",") 2136 qIdentifierList = qIdentifier 2137 *(optsep "," optsep qIdentifier) 2138 *1(optsep ",") 2140 qlcIdentifierList = qlcIdentifier 2141 *(optsep "," optsep qlcIdentifier) 2142 *1(optsep ",") 2144 bitsValue = "(" optsep bitsList optsep ")" 2146 bitsList = *1(lcIdentifier 2147 *(optsep "," optsep lcIdentifier)) 2148 *1(optsep ",") 2150 ;; 2151 ;; Other basic rules. 2152 ;; 2154 identifier = ucIdentifier / lcIdentifier 2156 qIdentifier = qucIdentifier / qlcIdentifier 2158 ucIdentifier = ucAlpha *63(ALPHA / DIGIT / "-") 2160 qucIdentifier = *1(ucIdentifier "::") ucIdentifier 2162 lcIdentifier = lcAlpha *63(ALPHA / DIGIT / "-") 2164 qlcIdentifier = *1(ucIdentifier "::") lcIdentifier 2166 attrIdentifier = lcIdentifier *("." lcIdentifier) 2168 qattrIdentifier = *1(ucIdentifier ".") attrIdentifier 2170 text = textSegment *(optsep textSegment) 2172 textSegment = DQUOTE *textAtom DQUOTE 2174 textAtom = textVChar / HTAB / SP / lineBreak 2176 date = DQUOTE 4DIGIT "-" 2DIGIT "-" 2DIGIT 2177 *1(" " 2DIGIT ":" 2DIGIT) 2178 DQUOTE 2179 ; always in UTC 2181 format = textSegment 2183 units = textSegment 2185 anyValue = bitsValue / 2186 signedNumber / 2187 hexadecimalNumber / 2188 floatValue / 2189 text / 2190 objectIdentifier 2191 ; Note: `objectIdentifier' includes the 2192 ; syntax of enumeration labels and 2193 ; identities. 2194 ; They are not named literally to 2195 ; avoid reduce/reduce conflicts when 2196 ; building LR parsers based on this 2197 ; grammar. 2199 status = currentKeyword / 2200 deprecatedKeyword / 2201 obsoleteKeyword 2203 access = eventonlyKeyword / 2204 readonlyKeyword / 2205 readwriteKeyword 2207 objectIdentifier = (qlcIdentifier / subid "." subid) 2208 *127("." subid) 2210 subid = decimalNumber 2212 number = hexadecimalNumber / decimalNumber 2214 negativeNumber = "-" decimalNumber 2216 signedNumber = number / negativeNumber 2218 decimalNumber = "0" / (nonZeroDigit *DIGIT) 2220 zeroDecimalNumber = 1*DIGIT 2222 hexadecimalNumber = %x30 %x78 ; "0x" with x only lower-case 2223 1*(HEXDIG HEXDIG) 2225 floatValue = neginfKeyword / 2226 posinfKeyword / 2227 snanKeyword / 2228 qnanKeyword / 2229 signedNumber "." zeroDecimalNumber 2230 *1("E" ("+"/"-") zeroDecimalNumber) 2232 ;; 2233 ;; Rules to skip unknown statements 2234 ;; with arbitrary arguments and blocks. 2235 ;; 2236 unknownStatement = unknownKeyword optsep *unknownArgument 2237 optsep ";" 2239 unknownArgument = ("(" optsep unknownList optsep ")") / 2240 ("{" optsep *unknownStatement optsep "}") / 2241 qucIdentifier / 2242 anyValue / 2243 anySpec 2245 unknownList = namedNumberList / 2246 qIdentifierList 2248 unknownKeyword = lcIdentifier 2250 ;; 2251 ;; Keyword rules. 2252 ;; 2253 ;; Typically, keywords are represented by tokens returned from the 2254 ;; lexical analyzer. Note, that the lexer has to be stateful to 2255 ;; distinguish keywords from identifiers depending on the context 2256 ;; position in the input stream. 2257 ;; 2258 ;; Also note, that these keyword definitions are represented in 2259 ;; cleartext for readability, while SMIng keywords are meant to be 2260 ;; case-sensitive, although ABNF makes quoted strings like these to 2261 ;; be case-insensitive. 2262 ;; 2264 ;; Statement keywords. They must be lower-case. 2266 moduleKeyword = %x6D %x6F %x64 %x75 %x6C %x65 2267 importKeyword = %x69 %x6D %x70 %x6F %x72 %x74 2268 revisionKeyword = %x72 %x65 %x76 %x69 %x73 %x69 %x6F %x6E 2269 dateKeyword = %x64 %x61 %x74 %x65 2270 organizationKeyword = %x6F %x72 %x67 %x61 %x6E %x69 %x7A %x61 %x74 2271 %x69 %x6F %x6E 2272 contactKeyword = %x63 %x6F %x6E %x74 %x61 %x63 %x74 2273 descriptionKeyword = %x64 %x65 %x73 %x63 %x72 %x69 %x70 %x74 %x69 2274 %x6F %x6E 2275 referenceKeyword = %x72 %x65 %x66 %x65 %x72 %x65 %x6E %x63 %x65 2276 extensionKeyword = %x65 %x78 %x74 %x65 %x6E %x73 %x69 %x6F %x6E 2277 typedefKeyword = %x74 %x79 %x70 %x65 %x64 %x65 %x66 2278 typeKeyword = %x74 %x79 %x70 %x65 2279 identityKeyword = %x69 %x64 %x65 %x6E %x74 %x69 %x74 %x79 2280 classKeyword = %x63 %x6C %x61 %x73 %x73 2281 attributeKeyword = %x61 %x74 %x74 %x72 %x69 %x62 %x75 %x74 %x65 2282 uniqueKeyword = %x75 %x6E %x69 %x71 %x75 %x65 2283 eventKeyword = %x65 %x76 %x65 %x6E %x74 2284 formatKeyword = %x66 %x6F %x72 %x6D %x61 %x74 2285 unitsKeyword = %x75 %x6E %x69 %x74 %x73 2286 statusKeyword = %x73 %x74 %x61 %x74 %x75 %x73 2287 accessKeyword = %x61 %x63 %x63 %x65 %x73 %x73 2288 defaultKeyword = %x64 %x65 %x66 %x61 %x75 %x6C %x74 2289 abnfKeyword = %x61 %x62 %x6E %x66 2291 ;; Base type keywords. 2293 OctetStringKeyword = %x4F %x63 %x74 %x65 %x74 %x53 %x74 %x72 %x69 2294 %x6E %x67 2295 PointerKeyword = %x50 %x6F %x69 %x6E %x74 %x65 %x72 2296 IdentityKeyword = %x49 %x64 %x65 %x6E %x74 %x69 %x74 %x79 2297 ObjectIdentifierKeyword = %x4F %x62 %x6A %x65 %x63 %x74 %x49 %x64 2298 %x65 %x6E %x74 %x69 %x66 %x69 %x65 %x72 2299 Integer32Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x33 %x32 2300 Unsigned32Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x33 2301 %x32 2302 Integer64Keyword = %x49 %x6E %x74 %x65 %x67 %x65 %x72 %x36 %x34 2303 Unsigned64Keyword = %x55 %x6E %x73 %x69 %x67 %x6E %x65 %x64 %x36 2304 %x34 2305 Float32Keyword = %x46 %x6C %x6F %x61 %x74 %x33 %x32 2306 Float64Keyword = %x46 %x6C %x6F %x61 %x74 %x36 %x34 2307 Float128Keyword = %x46 %x6C %x6F %x61 %x74 %x31 %x32 %x38 2308 BitsKeyword = %x42 %x69 %x74 %x73 2309 EnumerationKeyword = %x45 %x6E %x75 %x6D %x65 %x72 %x61 %x74 %x69 2310 %x6F %x6E 2312 ;; Status keywords. 2314 currentKeyword = %x63 %x75 %x72 %x72 %x65 %x6E %x74 2315 deprecatedKeyword = %x64 %x65 %x70 %x72 %x65 %x63 %x61 %x74 %x65 2316 %x64 2317 obsoleteKeyword = %x6F %x62 %x73 %x6F %x6C %x65 %x74 %x65 2319 ;; Access keywords. 2321 eventonlyKeyword = %x65 %x76 %x65 %x6E %x74 %x6F %x6E %x6C %x79 2322 readonlyKeyword = %x72 %x65 %x61 %x64 %x6F %x6E %x6C %x79 2323 readwriteKeyword = %x72 %x65 %x61 %x64 %x77 %x72 %x69 %x74 %x65 2325 ;; Special floating point values' keywords. 2327 neginfKeyword = %x6E %x65 %x67 %x69 %x6E %x66 2328 posinfKeyword = %x70 %x6F %x73 %x69 %x6E %x66 2329 snanKeyword = %x73 %x6E %x61 %x6E 2330 qnanKeyword = %x71 %x6E %x61 %x6E 2331 ;; 2332 ;; Some low level rules. 2333 ;; These tokens are typically skipped by the lexical analyzer. 2334 ;; 2336 sep = 1*(comment / lineBreak / WSP) 2337 ; unconditional separator 2339 optsep = *(comment / lineBreak / WSP) 2341 stmtsep = *(comment / 2342 lineBreak / 2343 WSP / 2344 unknownStatement) 2346 comment = "//" *(WSP / VCHAR) lineBreak 2348 lineBreak = CRLF / LF 2350 ;; 2351 ;; Encoding specific rules. 2352 ;; 2354 textVChar = %x21 / %x23-7E 2355 ; any VCHAR except DQUOTE 2357 ucAlpha = %x41-5A 2359 lcAlpha = %x61-7A 2361 nonZeroDigit = %x31-39 2363 ;; 2364 ;; RFC 2234 core rules. 2365 ;; 2367 ALPHA = %x41-5A / %x61-7A 2368 ; A-Z / a-z 2370 CR = %x0D 2371 ; carriage return 2373 CRLF = CR LF 2374 ; Internet standard newline 2376 DIGIT = %x30-39 2377 ; 0-9 2379 DQUOTE = %x22 2380 ; " (Double Quote) 2382 HEXDIG = DIGIT / 2383 %x61 / %x62 / %x63 / %x63 / %x65 / %x66 2384 ; only lower-case a..f 2386 HTAB = %x09 2387 ; horizontal tab 2389 LF = %x0A 2390 ; linefeed 2392 SP = %x20 2393 ; space 2395 VCHAR = %x21-7E 2396 ; visible (printing) characters 2398 WSP = SP / HTAB 2399 ; white space 2401 ;; 2402 ;; EOF 2403 ;; 2405 Appendix B. OPEN ISSUES 2407 Set of Documents - What is the expected set of documents specifying 2408 the SMIng? Currently, it looks like we are going to define these: 2410 (a) a core SMIng language specification, 2411 (b) specification of a core SMIng module, 2412 (c) language extensions for SNMP mappings, 2413 (d) language extensions for COPS-PR mappings, 2414 (e) maybe, an SMIng guidelines document, 2415 (f) specification of a basic inet modules, that not 2416 only contain basic definitions but also document 2417 the usage SMIng. 2419 How Generic Shall the Core Language be? - If we focus strictly on 2420 SNMP and COPS-PR, we can build on some common characteristics in 2421 these two related worlds, e.g., the concept and common definitions 2422 of OIDs, and conformance statements. On the other hand, if we 2423 feel closer to OO modeling concepts that should remain applicable 2424 also to other environments (AAA/DIAMETER, XML-style definitions), 2425 more information has to be specified in the mappings to those 2426 environments, while the core language cannot be very expressive. 2428 Floating Point Types - Shall we include Float32/64/128 in the base 2429 type system? Maybe only Float32/64? If we do, shall we disallow 2430 restrictions? See also the requirements document. 2432 Events / NOTIFICATIONs - SMIv2 NOTIFICATIONs contain objects. How 2433 about SMIng? Assume, the clause is named `event'. Shall events 2434 carry a set of attributes? How about those attributes identifying 2435 an instance of a class? Currently, events are assiciated with a 2436 class. What atttributes are carried with an event is subject to 2437 the protocol mapping. 2439 Display Formats - Should display hints be usable in a reversed way? 2440 Check all variants carefully. Is the optional repeat indicator 2441 `*' necessary? Would `u' for unsigned integers be useful? 2443 Discriminated Unions - How to specify unions and their 2444 discriminators? `typemap' statement? What are the specific 2445 requirements? See also the requirements document. 2447 How To Read - Add a section on how to read this set of documents. 2449 Annotations - Make annotations a core feature of SMIng? They are 2450 used to add information to an existent definition in an external 2451 module, e.g., a vendor or user can add specific severity level 2452 information to standard event definitions. 2454 Glossary - Add/Update the glossary of terms. 2456 Module Naming Scheme - Propose well known module name suffixes: `- 2457 MIB' for SNMP mapping modules? `-PIB' for COPS-PR mapping modules? 2458 `-EXT' for modules that define extensions (e.g. snmp)? no 2459 extension for modules that define general classes and types? This 2460 should go to the Guidelines document. 2462 `Extending A Module' - Carefully adjust the rules, e.g., `new named 2463 numbers may be added to enumeration types' is in contradiction 2464 with `attributes may get a new type only if the set of values 2465 remains equal'. 2467 ABNF Statement - Is the `abnf' statement really meaningful? Someone 2468 stated that it could be abused. 2470 7-bit ASCII texts - See requirements. 2472 Module Namespaces - Should we introduce domain-based namespaces for 2473 module names? E.g., DISMAN-SCRIPT-MIB.ietf.org? Mapping to 2474 SMIv2/SPPI module names? Which parts are case-sensitive? Separator 2475 char between module name and domain name (@/.)? Or should we 2476 enforce organization prefixes (also for the IETF), like IETF- 2477 DISMAN-SCRIPT-MIB? 2479 Learn from ODL, XML, ODBMS - Look at the ODL proposal from TINAC. 2480 Look at the XML schema work from W3C. Look at the ODBMS work. 2482 Inheritence - Inheritence is a powerful technique in software 2483 development. But is it really what we want to have in management 2484 data modeling? If it is not easy to find good examples for 2485 inheritence, can we expect that people will know how to use it? Or 2486 would it be more likely that it will be misused? Maybe, 2487 containment/discriminated unions are what we really need. 2489 Examples for Primary goals: MIBs/PIBs - Keep in mind that the 2490 primary goal is to derive modules for use with SNMP and COPS-PR 2491 from common definitions. If we cannot easily give good examples, 2492 we have failed. 2494 Classes or Interfaces - Are classes really classes or are they more 2495 interfaces? 2497 Reusable event definitions - Currently events are defined within a 2498 class. Do we need to be able to reuse event definitions in 2499 multiple classes? This potentially requires to give events their 2500 own names, independent of any class definitions. Or is it 2501 sufficient to use inheritance/containment to handle 99 % of the 2502 cases? 2504 Extensions - Optionally require the understanding of imported 2505 extensions (similar to the marvelous diameter M bit ;-) 2507 Extension Context - Do we need a mechanism to allow an extension to 2508 specify the context in which it can be used (the containing 2509 statement block in the position within this block)? 2511 `Static' Definitions - Is it useful to make specific definitions 2512 non-exported (like `static' in C)? Or would it be useful to make 2513 only those definitions be exported that are explicitly marked 2514 (`public')? 2516 More Formal Restrictions? - Do we need further formal restrictions 2517 on type definitions, e.g. subtyping not allowed on TimeTicks, 2518 max-access read-only on Counters, no default values on Counters? 2520 Full Copyright Statement 2522 Copyright (C) The Internet Society (2001). All Rights Reserved. 2524 This document and translations of it may be copied and furnished to 2525 others, and derivative works that comment on or otherwise explain it 2526 or assist in its implementation may be prepared, copied, published 2527 and distributed, in whole or in part, without restriction of any 2528 kind, provided that the above copyright notice and this paragraph are 2529 included on all such copies and derivative works. However, this 2530 document itself may not be modified in any way, such as by removing 2531 the copyright notice or references to the Internet Society or other 2532 Internet organizations, except as needed for the purpose of 2533 developing Internet standards in which case the procedures for 2534 copyrights defined in the Internet Standards process must be 2535 followed, or as required to translate it into languages other than 2536 English. 2538 The limited permissions granted above are perpetual and will not be 2539 revoked by the Internet Society or its successors or assigns. 2541 This document and the information contained herein is provided on an 2542 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2543 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2544 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2545 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2546 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2548 Acknowledgement 2550 Funding for the RFC Editor function is currently provided by the 2551 Internet Society.