idnits 2.17.1 draft-labarre-internetmib-iso-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 69 longer pages, the longest (page 0) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1.2 OVERVIEW OF IIMC' ) ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 131 instances of too long lines in the document, the longest one being 12 characters in excess of 72. ** The abstract seems to contain references ([2], [15], [20], [3], [21], [4], [IMPLIED], [ISO10165-4], [RFC1442], [22], [17], [18], [23], [5], [6], [24], [19], [7,8,9], [7], [RFC1212], [25], [8], [26], [ADD-REMOVE], [RFC1242], [9], [27], [10], [11], [IIMCOMIBTRANS], [12], [0], [13], [IIMCIMIBTRANS], [1], [14], [ISO10165-1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 3142: '... OPTIONAL,...' RFC 2119 keyword, line 3143: '... objectInstanceList [2] ObjectInstanceList OPTIONAL,...' RFC 2119 keyword, line 3144: '...BindList UnknownVarBindList OPTIONAL,...' RFC 2119 keyword, line 3145: '... internetTrapInfo [5] InternetTrapInfo OPTIONAL,...' RFC 2119 keyword, line 3146: '... perceivedSeverity [6] PerceivedSeverity OPTIONAL,...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3012 has weird spacing: '...nceList objec...' == Line 3013 has weird spacing: '...indList unkno...' == Line 3014 has weird spacing: '...rapInfo int...' == Line 3027 has weird spacing: '...Address tra...' == Line 3028 has weird spacing: '...rolInfo acce...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'IIMCOMIBTRANS' on line 308 looks like a reference -- Missing reference section? 'IIMCMIB-II' on line 24 looks like a reference -- Missing reference section? 'IIMCPROXY' on line 25 looks like a reference -- Missing reference section? 'IIMCSEC' on line 25 looks like a reference -- Missing reference section? '5' on line 3145 looks like a reference -- Missing reference section? '7' on line 3147 looks like a reference -- Missing reference section? '8' on line 3149 looks like a reference -- Missing reference section? '9' on line 3151 looks like a reference -- Missing reference section? '12' on line 3154 looks like a reference -- Missing reference section? '19' on line 1668 looks like a reference -- Missing reference section? '11' on line 3153 looks like a reference -- Missing reference section? '17' on line 2661 looks like a reference -- Missing reference section? '27' on line 230 looks like a reference -- Missing reference section? '25' on line 3075 looks like a reference -- Missing reference section? '22' on line 3052 looks like a reference -- Missing reference section? '23' on line 3072 looks like a reference -- Missing reference section? '24' on line 3072 looks like a reference -- Missing reference section? '26' on line 279 looks like a reference -- Missing reference section? 'RFC1212' on line 307 looks like a reference -- Missing reference section? 'IIMCIMIBTRANS' on line 307 looks like a reference -- Missing reference section? 'ISO10165-1' on line 307 looks like a reference -- Missing reference section? 'RFC1442' on line 308 looks like a reference -- Missing reference section? 'ISO10165-4' on line 308 looks like a reference -- Missing reference section? '14' on line 1798 looks like a reference -- Missing reference section? '20' on line 796 looks like a reference -- Missing reference section? '21' on line 1769 looks like a reference -- Missing reference section? 'RFC1242' on line 1049 looks like a reference -- Missing reference section? 'IMPLIED' on line 2051 looks like a reference -- Missing reference section? '18' on line 2850 looks like a reference -- Missing reference section? '13' on line 1763 looks like a reference -- Missing reference section? '15' on line 1766 looks like a reference -- Missing reference section? '10' on line 3152 looks like a reference -- Missing reference section? 'ADD-REMOVE' on line 2309 looks like a reference -- Missing reference section? '3' on line 3179 looks like a reference -- Missing reference section? '6' on line 3146 looks like a reference -- Missing reference section? '0' on line 3123 looks like a reference -- Missing reference section? '1' on line 3141 looks like a reference -- Missing reference section? '2' on line 3143 looks like a reference -- Missing reference section? '4' on line 3180 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 7 warnings (==), 41 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFTExpires August, 1994 3 ISO/CCITT and Internet Management Coexistence (IIMC): 5 Translation of Internet MIBs to ISO/CCITT GDMO MIBs 7 (IIMCIMIBTRANS) 9 February, 1994 11 Lee LaBarre (Editor) 13 The MITRE Corporation 14 Burlington Road 15 Bedford, MA 01730 16 cel@mbunix.mitre.org 18 Status of this Memo 20 This document provides information to the network and 21 systems management community. This document is intended as 22 a contribution to ongoing work in the area of multi-protocol 23 management coexistence and interworking. This document is 24 part of a package; see also [IIMCOMIBTRANS] [IIMCMIB-II] 25 [IIMCPROXY] and [IIMCSEC]. Distribution of this document is 26 unlimited. Comments should be sent to the Network Management 27 Forum IIMC working group (iimc@thumper.bellcore.com). 29 This document is an Internet Draft. Internet Drafts are 30 working documents of the Internet Engineering Task Force 31 (IETF), its Areas, and its Working Groups. Note that other 32 groups may also distribute working documents as Internet 33 Drafts. 35 Internet Drafts are draft documents valid for a maximum of 36 six months. Internet Drafts may be updated, replaced, or 37 obsoleted by other documents at any time. It is not 38 appropriate to use Internet Drafts as reference material or 39 to cite them other than as a "working draft" or "work in 40 progress." 42 Please check the 1id-abstracts.txt listing contained in the 43 internet-drafts Shadow Directories on ds.internic.net, 44 nic.nordu.net, ftp.nisc.sri.com, munnari.oz.au to learn the 45 current status of any Internet Draft. 47 DRAFT February, 1994 49 Abstract 51 This document is intended to facilitate the multi-protocol 52 management coexistence and interworking for networks that 53 are managed using the ISO/CCITT Common Management 54 Information Protocol (CMIP) and networks that are managed 55 using the Internet Simple Network Management Protocol 56 (SNMP). This document contains translation and registration 57 procedures that are applicable to translation of Internet 58 MIBs, defined according to the Internet Structure of 59 Management Information (SMI), into ISO/CCITT SMI-defined 60 MIBs. This document also defines and registers generic 61 management information that may be used with the translation 62 procedures to facilitate interoperability. 64 Table of Contents 66 1. INTRODUCTION ..........................................1 68 1.1 PROBLEM STATEMENT.................................1 70 1.2 OVERVIEW OF IIMC..................................2 72 1.3 MIB TRANSLATION PROCEDURES........................3 74 1.4 NATIVE MANAGEMENT MODEL...........................3 76 1.5 PROXY MANAGEMENT MODEL............................5 78 1.6 SCOPE OF THIS DOCUMENT............................6 80 1.7 TERMS AND CONVENTIONS.............................7 82 2. REGISTRATION AND NAMING PROCEDURES ....................8 84 2.1 REGISTRATION PROCEDURES............................8 85 2.1.1 Automated Registration Procedures ............8 86 2.1.1.1 Translated Object Classes and 87 Attributes Registration .............9 88 2.1.1.2 Translated NAME BINDINGs 89 Registration ........................10 90 2.1.1.3 Translated ASN.1 Modules and 91 Documents Registration ..............10 92 2.1.1.4 Naming Attribute Registration........12 93 2.1.2 IIMC Explicit Registration Procedures ........12 94 2.1.2.1 Explicit ASN.1 Modules and 95 Documents Registration ..............13 96 2.1.2.2 Explicit Trap/Notification 97 Registration ........................13 99 2.2 NAMING PROCEDURES..................................14 100 2.2.1 Naming Attributes ............................14 101 2.2.2 ISO/CCITT-Internet Naming Tree ...............15 102 DRAFT February, 1994 104 2.2.3 Distinguished Names ..........................16 106 2.3 OID TRANSLATION....................................16 107 2.3.1 OID/Name Translation ISO/CCITT to Internet ...16 108 2.3.2 OID/Name Translation Internet to ISO/CCITT ...19 110 2.4 INHERITANCE FOR OBJECT CLASSES.....................20 112 2.5 REFERENCE LABELS FOR DERIVED ENTITIES..............21 114 3. INTERNET TO ISO/CCITT MIB TRANSLATION PROCEDURES ......22 116 3.1 PRE-TRANSLATION PROCEDURES.........................22 118 3.2 GDMO TRANSLATION PROCEDURES........................25 119 3.2.1 Translation of Groups ........................25 120 3.2.2 Translation of Table Entry Objects ...........27 121 3.2.3 Translation of Other OBJECT-TYPES ............29 122 3.2.4 Translation of Notifications .................32 123 3.2.5 Log Record for Internet Alarm ................33 124 3.2.6 Translation of Internet Attribute Types ......33 126 3.3 POST-TRANSLATION PROCEDURES........................36 127 3.3.1 Post-translation of BEHAVIOUR Cause ..........36 128 3.3.2 Creation of NAME BINDING Templates ...........36 129 3.3.3 Attribute Property-label Changes .............41 130 3.3.4 Post-processing of ASN.1 Module ..............41 131 3.3.5 Templates for Naming Attributes ..............42 132 3.3.6 Generation of MOCS ...........................43 134 4. IIMCIMIBTRANS MIB .....................................44 136 -- 4.1 IMIBTRANS MIB GDMO TEMPLATES....................44 137 -- 4.1.1 IMIBTRANS Managed Object Classes ..........44 138 -- 4.1.2 IMIBTRANS Attribute Types .................46 139 -- 4.1.3 IMIBTRANS Attributes ......................54 140 -- 4.1.4 IMIBTRANS Notifications ...................55 142 -- 4.2 IMIBTRANS ASN.1 MODULES.........................57 144 5. COMPLIANCE AND CONFORMANCE ............................61 146 5.1 COMPLIANCE.........................................61 148 5.2 CONFORMANCE........................................61 150 ANNEX A (NORMATIVE): MANAGED OBJECT CONFORMANCE 151 STATEMENTS (MOCS)......................................A-1 153 ANNEX B: GLOSSARY ........................................B-1 155 ANNEX C: REFERENCES ......................................C-1 156 DRAFT February, 1994 158 List of Figures 160 FIGURE 1. MIB TRANSLATION ................................3 162 FIGURE 2. NATIVE MANAGEMENT ..............................4 164 FIGURE 3. PROXY MANAGEMENT ...............................5 166 List of Tables 168 TABLE 1. MAPPING THE GROUP ACCESS CLAUSE .................27 170 TABLE 2. MAPPING THE TABLE ENTRY OBJECT ACCESS CLAUSE ....28 172 TABLE 3. MAPPING TO MATCHING RULES .......................30 174 TABLE 4. COMMON ATTRIBUTE TYPES ..........................31 176 REVISION HISTORY 178 Issue 1.0, October 1993 180 This is the first issue of this document. The internet draft 181 , dated February, 1994, is 182 identical in content to Issue 1.0, October 1993. It has been 183 reformatted for posting as an internet draft. 185 DRAFT February, 1994 187 1. INTRODUCTION 189 This section provides an overview of ISO/CCITT and Internet 190 Management Coexistence (IIMC) activities, insight into the 191 problem being addressed by IIMC, and a brief introduction to 192 the strategy adopted by IIMC: use of translated MIBs in 193 either a proxy or native implementation. The section 194 concludes by describing the scope of this document, and 195 terms and conventions used by this document. 197 1.1 PROBLEM STATEMENT 199 The need for enterprise network management has been 200 addressed by development of network management standards 201 within various communities, most notably the ISO/CCITT and 202 Internet communities. 204 * The ISO/CCITT community developed the Common Management 205 Information Protocol (CMIP) [5], and related SMI 206 documents [7,8,9]. 208 * The Internet community developed the Simple Network 209 Management Protocol (SNMP) [12], and its successor, 210 SNMPv2 [19]. The Internet SMI is defined in [11] and 211 [17]. 213 These standards share a nearly common management model, but 214 diverge due to differing management philosophies. Although 215 functionally similar, the Internet and ISO/CCITT protocols 216 and SMIs differ in terms of their complexity and specific 217 operations. Business requirements for end-to-end enterprise 218 management include the need to integrate the management of 219 many different devices, potentially owned or administered by 220 many independent organizations. This requires components to 221 be accessed by ISO/CCITT management, Internet management, 222 and proprietary management mechanisms in a manner which 223 presents a unified view of the network, despite protocol and 224 SMI differences. 226 For example, many telecommunications and computer vendors, 227 represented by organizations such as the Network Management 228 Forum (NMF), and the U.S. government, as specified in the 229 Government Network Management Profile (GNMP) Version 1.0 230 [27], have based their enterprise management model on the 231 ISO/CCITT management model. These organizations are 232 particularly interested in integrated management of devices 233 that use the Internet management. This interest is primarily 234 due to the widespread commercial implementation and use of 235 DRAFT February, 1994 237 such devices, especially devices that use the Internet 238 TCP/IP protocol suite. 240 1.2 OVERVIEW OF IIMC 242 The ISO/CCITT and Internet Management Coexistence (IIMC) 243 package includes the following documents. 245 IIMCIMIBTRANS Translation of Internet MIBs to ISO/CCITT 246 GDMO MIBs 248 IIMCOMIBTRANS Translation of ISO/CCITT GDMO MIBs to 249 Internet MIBs [25] 251 IIMCMIB-II Translation of Internet MIB-II (RFC 1213) to 252 ISO/CCITT GDMO MIB [22] 254 IIMCPROXY ISO/CCITT to Internet Management Proxy [23] 256 IIMCSEC ISO/CCITT to Internet Management Security[24] 258 These documents together comprise a package aimed at 259 integrating ISO/CCITT-based and Internet-based management 260 systems. 262 IIMC specifications address the problem that end-to-end 263 management requires an integrated, unified view of the 264 managed network, despite differences in management protocol 265 and information structure. Integrated management can be 266 facilitated by the development of "proxy" mechanisms which 267 translate between functionally equivalent service, protocol, 268 and SMI differences to create this unified view. MIB 269 translation procedures can be used to support proxy 270 management, as well as to take advantage of existing MIB 271 definition and avoid duplication of effort. In this way, 272 commercial investment in both ISO/CCITT and Internet-based 273 management technologies can be preserved through deployment 274 of common methods and tools which support integration. 276 This overall strategy was outlined in a joint publication 277 developed by the NM Forum and X/Open entitled "ISO/CCITT and 278 Internet Management: Coexistence and Interworking Strategy" 279 [26]. The documents included in the IIMC package are the 280 next level of detailed specifications which implement 281 several of the methodologies identified in the strategy. 282 Additional specifications may be defined in the future. 284 DRAFT February, 1994 286 1.3 MIB TRANSLATION PROCEDURES 288 The foundation of IIMC is provided by a pair of Management 289 Information Base (MIB) translation procedures. 291 * IIMCIMIBTRANS (this document) specifies translation 292 procedures for converting MIBs from Internet MIB macro 293 format into ISO/CCITT GDMO template format. 295 * IIMCOMIBTRANS [25] specifies translation procedures for 296 converting MIBs from ISO/CCITT GDMO template format into 297 Internet MIB macro format. 299 The IIMC approach is to specify direct translation 300 procedures which yield a pair of functionally-equivalent 301 MIBs, as shown in Figure 1. 303 +----------------+ +--------------------+ +----------------+ 304 | Internet MIB | | MIB Translation | | GDMO MIB | 305 | | | Procedures | | | 306 | Format = | | Specified By | | Format = | 307 | [RFC1212] & |---->| [IIMCIMIBTRANS] or |---->| [ISO10165-1] & | 308 | [RFC1442] |<----| [IIMCOMIBTRANS] |<----| [ISO10165-4] | 309 +----------------+ +--------------------+ +----------------+ 311 Figure 1. MIB translation. 313 MIBs translated by these procedures may be used to take 314 advantage of existing MIB definitions when business needs 315 require deployment in a different management environment. 316 Translated MIBs may also be used to provide uniformity when 317 multiple management environments are supported by a single 318 system (e.g., dual stack managers). Finally, IIMC MIB 319 translation procedures may be used to support service 320 emulation by a proxy. 322 1.4 NATIVE MANAGEMENT MODEL 324 The basic model for ISO/CCITT and Internet management is 325 illustrated in the following diagram. 327 DRAFT February, 1994 329 Manager Agent 330 +-----------------------+ +----------------------+ 331 |+---------------------+| |+-------------------+ | 332 || Management || || Managed | | 333 || Applications || || Resources | | 334 |+---------------------+| |+-------------------+ | 335 | | | | | | 336 | | | | | | 337 |+-----------+---------+| |+----------+---------+| 338 || Manager | MIB || || Agent | MIB || 339 |+-----------+---------+| |+----------+---------+| 340 | | | | | | 341 | | Management | | | Management | 342 | | Services | | | Services | 343 +-----------------------+ +----------------------+ 344 | Management Protocol | | Management Protocol | 345 +-----------------------+ +----------------------+ 346 ^ ^ 347 | | 348 +------------------------------------+ 349 Protocol Messages 351 Figure 2. Native management. 353 Within IIMC documents, this model is referred to as the 354 "native" management model. MIBs translated using IIMC 355 procedures can be used by "native" agent implementations. 356 For example, an ISO/CCITT agent can make visible TCP/IP 357 managed resources using the translated GDMO version of the 358 Internet MIB-II [14] specified by [22]. Dual-stack managers 359 or agents may also be implemented which support both the 360 original MIB and the translated MIB generated using IIMC- 361 specified procedures. 363 DRAFT February, 1994 365 1.5 PROXY MANAGEMENT MODEL 367 The basic model for ISO/CCITT to Internet proxy management 368 is illustrated in the following diagram. This proxy is 369 specified by [23]. A similar approach could also be taken to 370 specify an Internet to ISO/CCITT proxy, although no such 371 IIMC document is currently specified. 373 Manager Proxy Agent 374 +-----------------------+ +---------------------+ +------------------ 375 |+---------------------+| |+------+ +----------+| |+----------------- 376 || Management || || GDMO | | Internet || || Managed 377 || Applications || || MIB | | MIB || || Resources 378 |+---------------------+| |+------+ +----------+| |+----------------- 379 | | | |+-------------------+| | | 380 | | | || Service || | | 381 | | | || Emulation || | | 382 | | | ||(scoping) || | | 383 | | | || (filtering) || | | 384 |+-----------+---------+| || (operations) || |+----------+------ 385 || ISO/CCITT | GDMO || || (message || || Internet | Inter 386 || Manager | MIB || || transformation)|| || Agent | MIB 387 |+-----------+---------+| |+-------------------+| |+----------+------ 388 | | | | |CMIS | | | | 389 | | CMIS Services | | |Services | | | | SNMP "Servic 390 | | | | | | | | | 391 | | | | | SNMP| | | | 392 | | | | | "Services"| | | | 393 +-----------------------+ +---------------------+ +------------------ 394 | CMIP | | CMIP | SNMP | | SNMP 395 +-----------------------+ +---------------------+ +------------------ 396 ^ ^ ^ ^ 397 | | | | 398 +---------------------+ +-------------------+ 399 CMIP Messages SNMP Messages 401 Figure 3. Proxy management. 403 This ISO/CCITT to Internet proxy provides emulation of CMIS 404 services by mapping to the corresponding SNMP message(s) 405 necessary to carry out the service request. The service 406 emulation allows management of Internet objects by an 407 ISO/CCITT manager. The left hand side of the proxy behaves 408 like an ISO/CCITT agent, communicating with the ISO/CCITT 409 manager using CMIP protocols. The right hand side of the 410 proxy behaves like an Internet manager, communicating with 411 the Internet agent using SNMP protocols. 413 The proxy relies on the existence of a pair of directly- 414 related MIB definitions, where the Internet MIB has been 415 translated into ISO/CCITT GDMO using the procedures 416 specified in IIMCIMIBTRANS. The proxy uses these MIB 417 definitions and rules to provide run-time translation of 418 DRAFT February, 1994 420 management information carried in service requests and 421 responses. 423 The proxy is designed with a specified interface between the 424 proxy and the underlying protocol stacks, and so deals 425 primarily in terms of CMIS services and SNMP "services". The 426 proxy emulates services such as CMIS scoping and filtering, 427 processing of CMIP operations, and forwarding/logging of 428 CMIS notifications by performing a mapping process which 429 must be tailored for each protocol (for example, SNMPv1 and 430 SNMPv2 are variants of the same protocol mapping process). 432 1.6 SCOPE OF THIS DOCUMENT 434 A major reason for the rapid commercialization of devices 435 manageable via the Internet management protocol is due to 436 the speed with which the vendors in the Internet community 437 have been able to develop MIBs based on the Internet SMI. To 438 capitalize on this continuing Internet MIB development and 439 their deployment in commercial devices, communities 440 interested in integrated management via ISO/CCITT-Internet 441 proxies require that procedures be defined for translation 442 of Internet MIBs into ISO/CCITT GDMO MIBs, i.e., MIBs 443 defined according to the ISO/CCITT SMI Guidelines for 444 Definition of Managed Objects [9]. Communities interested in 445 using ISO/CCITT management protocols to directly manage 446 resources using the Internet defined MIB elements are also 447 interested in MIB translation procedures. Such MIB 448 translations may also minimize the independent development 449 of ISO/CCITT GDMO MIBs for the same resources and thereby 450 reduce the incompatibilities with the Internet MIBs. 452 Translation procedures which may be automated to a high 453 degree, and include unambiguous automated registration 454 procedures, are of particular interest to the communities 455 interested in using GDMO translations of Internet MIBs. This 456 document (IIMCIMIBTRANS) defines such procedures. 458 This document also defines generic SNMP trap to CMIS 459 notification mappings, common naming conventions, and ASN.1 460 modules applicable to translated Internet MIBs. 462 Many of the procedures defined in this document may be 463 subject to automation. Comments are provided concerning 464 possible aids to automation; however, it is not the intent 465 of this document to provide fully automated translation 466 algorithms. 468 DRAFT February, 1994 470 1.7 TERMS AND CONVENTIONS 472 This document assumes that the reader is familiar with the 473 ISO/CCITT SMI and Internet SMI, and the terminology of each. 474 The term SNMP will be used throughout the document to 475 indicate either SNMPv1 or SNMPv2, unless a distinction needs 476 to be made. 478 Other conventions used during the translation process are 479 described in Section 3.2. 481 DRAFT February, 1994 483 2. REGISTRATION AND NAMING PROCEDURES 485 Registration and naming procedures are crucial to the unique 486 identification of management information. Registration 487 assures the uniqueness of management information element 488 types, while naming provides a way of distinguishing 489 instances of a type and locating them within the MIB. 491 2.1 REGISTRATION PROCEDURES 493 The registration authority for management definitions 494 produced during the translation process shall be the Network 495 Management Forum. 497 WARNING: Object Identifiers produced during the 498 translation process are only provisionally assigned. 499 The object identifiers are not registered until 500 approved by the registration authority. In cases of 501 conflict with existing registered object identifiers, 502 the registration authority will manually assign 503 object identifiers. 505 Registration procedures specify that changes in the syntax 506 or semantics of registered entities require them to be 507 registered as new entities. The process of converting 508 Internet MIBs into the ISO/CCITT GDMO MIBs inevitably 509 introduces subtle semantic changes in how data can be 510 operated on, and changes in the content of the MIB element. 511 For example, ISO/CCITT attributes that are converted from 512 Internet Object Types acquire matching rules for use in 513 filtering operations. ISO/CCITT object classes that are 514 created from Internet groups acquire semantics related to 515 their inheritance of new attributes from the "top" managed 516 object class. The end result is that all the new ISO/CCITT 517 object classes, attributes, and notifications created during 518 the translation process must be registered. In addition, 519 name bindings for inserting object instances into the naming 520 hierarchy must be registered. 522 2.1.1 Automated Registration Procedures 524 Registration procedures are critical to the goals of 525 automating the translation of Internet MIBs to ISO/CCITT 526 GDMO format, and the efficient implementation of ISO/CCITT- 527 Internet proxies. Registration involves assignment of an 528 ASN.1 Object Identifier (OID) to the entity. Management 529 entities defined according to the principles of the Internet 530 SMI may be registered under the IAB's "internet" arc, or 531 DRAFT February, 1994 533 registered under an arc in another organization's 534 proprietary registration subtree. 536 Since OIDs can be guaranteed to be unique across 537 organizations only within the context of the uppermost 538 registration hierarchy, this document uses the entire OID to 539 prevent ambiguity. The effect of the registration procedure 540 specified in this document is to graft the entire OID to 541 another part of the registration tree, without changing the 542 OID structure. 544 This document allocates an arc in the registration hierarchy 545 for use in automated registration of management elements 546 defined according to IIMC procedures defined in this 547 document. The arc is named "iimcAutoTrans", and is 548 registered in section 4.2. 550 The following paragraphs describe IIMC registration 551 procedures to facilitate automated translation and assure 552 uniqueness of registered ASN.1 object identifiers for 553 ISO/CCITT object classes and attributes derived from 554 internet entities; and a registration procedure for their 555 name bindings, document identifiers, and ASN.1 modules. 557 2.1.1.1 Translated Object Classes and Attributes 558 Registration 560 Follow the procedure below for OIDs associated with Internet 561 groups, conceptual tables, conceptual table entries, and 562 objects. 564 a) Determine the sequence of sub-identifiers of the OID 565 assigned to the internet management entity, beginning at the 566 root of the registration tree, and identify that sequence as 567 , 569 Note: Remember, the first part of the ASN.1 BER encoded 570 OID must be translated into two sub-identifiers. 572 b) Determine the translated OID {} as: 574 {} = { 575 } 577 where is the OID dedicated for 578 ISO/CCITT-Internet automated registration of translated 579 object classes and attributes. 581 This procedure preserves the unique identification of the 582 entities within the Internet subtree, and entities 583 identified by OIDs that are registered by other 584 organizations. 586 DRAFT February, 1994 588 2.1.1.2 Translated NAME BINDINGs Registration 590 As described in section 2.2.2 , the ISO/CCITT SMI requires 591 that managed object instances be bound into a naming 592 hierarchy, or tree, for purposes of naming. ISO/CCITT NAME 593 BINDING templates are used to register the manner in which 594 such instances may be bound. These name bindings shall be 595 registered. 597 The Internet SMI does not include the concept of a naming 598 tree and name binding. Thus, there exists no registered 599 internet entity from which an OID for the ISO/CCITT NAME 600 BINDING template can be derived. One solution is to use the 601 object class OID to register name bindings under a special 602 registration arc {iimcAutoNameBinding}. The following 603 procedure shall be followed for registration of a single 604 name binding for an object class to be inserted into the 605 naming hierarchy, i.e., the subordinate object class. 607 * Assign each new name binding an OID, using the following 608 rules. Start with the OID for the subordinate object 609 class, derived using the procedures in section 2.1.1.1. 610 Within the class OID, extract the (c) 611 portion of the OID. Prepend {iimcAutoNameBinding} to the 612 (c) so that the OID for the name 613 binding is of the form: 615 {iimcAutoNameBinding (c)} 617 WARNING: Object Identifiers for name bindings produced 618 during the translation process are only provisionally 619 assigned. The object identifiers are not registered 620 until approved by the registration authority. In 621 cases of conflict with existing registered name 622 bindings that have different creation or deletion 623 semantics, or behaviour characteristics, the 624 registration authority will manually assign object 625 identifiers to the name binding. 627 Note: In general multiple name bindings may be defined for 628 an ISO/CCITT object class. However the automated 629 registration procedures defined in this document only 630 provide for a single name binding. This facilitates 631 the proxy translation process, especially for 632 received traps/notifications and informRequests. 634 2.1.1.3 Translated ASN.1 Modules and Documents Registration 636 Translated MIBs may contain definitions that can be 637 referenced by other documents, e.g., attribute types defined 638 in this document. An identifier and registered OID shall be 639 given to each such document so that management elements 640 defined therein may be referenced. Documents that contain 641 translated MIBs derived from RFCs, unless manually assigned, 642 DRAFT February, 1994 644 shall be automatically assigned short document identifiers, 645 i.e., a document alias, of the form: 647 "iimcRFC" || [|| ]*, 649 where is the internet number assigned to the 650 RFC. If multiple RFCs are included in the translation, then 651 the RFC numbers shall be concatenated in ascending sequence. 652 Document aliases may be manually assigned by the 653 registration authority. 655 Note: Multiple RFCs are included in the same translated 656 MIB in exceptional cases, not as a general rule. 658 Documents derived from MIBs defined in Internet RFCs are 659 registered under the {iimcAutoDocument} arc by concatenating 660 the RFC number onto that arc. If multiple RFCs are included 661 in the translation, then the RFC numbers shall be 662 concatenated to iimcAutoDocument in ascending sequence. 663 Explicit registration of other IIMC documents shall be under 664 the iimcDocument arc. 666 Documents that define translated MIBs contain syntax in 667 ASN.1 modules that can be referenced by other documents. An 668 identifier and registered OID shall be given to each such 669 ASN.1 module so that syntax defined therein may be 670 referenced. ASN.1 modules in documents that contain 671 translated MIBs derived from RFCs, unless manually assigned, 672 shall be automatically assigned short module identifiers, 673 i.e., a module alias, of the form: 675 "IIMCRFC" || [|| ]* || 676 "ASN1", 678 where is the internet number assigned to the 679 RFC. If multiple RFCs are included in the translation, then 680 the RFC numbers shall be concatenated in ascending sequence. 681 Module aliases may be manually assigned by the registration 682 authority. 684 Modules derived for MIBs defined in Internet RFCs are 685 registered under the {iimcAutoModule} arc by concatenating 686 the RFC number onto that arc. If multiple RFCs are included 687 in the translation, then the RFC numbers shall be 688 concatenated to iimcAutoModule in ascending sequence. 689 Explicit registration of other IIMC ASN.1 modules shall be 690 under the iimcModule arc. 692 Translated MIBs defined according to the procedures 693 described in this document shall be documented in the 694 following format. 696 * The OID of the document shall be specified first as 697 DRAFT February, 1994 699 OBJECT IDENTIFIER ::= {} 702 where is the short document identifier 703 derived as described previously, e.g., iimcRFC12131354, 704 and is the OID assigned to the document 705 using the procedures described in this clause, e.g., 706 {iimcAutoDocument 1213 1354}. 708 * The order in which definitions shall appear is: 709 * managed object classes, 710 * attribute types, 711 * attributes, and 712 * ASN.1 Modules. 714 All text that is not part of the GDMO template, or ASN.1 715 definitions shall be preceded by "--" to indicate that 716 they are comments. This includes clause headers. 718 2.1.1.4 Naming Attribute Registration 720 As described in 2.2.1, the conversion of Internet MIBs to 721 ISO/CCITT MIBs requires that naming attributes be defined 722 and registered for each ISO/CCITT object class derived from 723 Internet management entities. Naming attributes shall be 724 registered as 726 {iimcAutoName (c)}, 728 where (c) is the OID assigned to the 729 Internet entity from which the associated ISO/CCITT object 730 class is derived. 732 2.1.2 IIMC Explicit Registration Procedures 734 Automated registration procedures alone are not sufficient 735 to support the translation process. ISO/CCITT management 736 entities other than translated objects, attributes, modules, 737 and documents need to be explicitly registered. These 738 entities include: 740 * common ASN.1 modules that may be referenced for inclusion 741 in other ASN.1 modules of other documents, 743 * IIMC documents to enable MIB elements and attribute types 744 defined in these documents to be referenced within other 745 documents, and 747 * IIMC defined management elements, such as the generic 748 notification defined in this document, the IIMC Proxy MIB 749 defined in [23], the IIMC ACL MIB defined in [24], and 750 the omibtransSpt MIB defined in [25]. 752 DRAFT February, 1994 754 This document allocates an arc in the registration hierarchy 755 for explicitly registering IIMC management entities. The arc 756 is named "iimcManual". This document assigns sub-arcs under 757 the "iimcManual" arc in the ASN.1 module in section 4.2. 759 2.1.2.1 Explicit ASN.1 Modules and Documents Registration 761 Explicit registration of IIMC documents shall be under the 762 iimcDocument arc, as specified in section 4.2. For example, 763 this document iimcIIMCIMIBTRANS is registered as 764 {iimcDocument 1}. 766 Explicit registration of IIMC ASN.1 modules shall be under 767 the iimcModule arc, as specified in section 4.2. For 768 example, the IimcAssignedOIDs module specified in section 769 4.2 of this document is registered as {iimcModule 1}. 771 2.1.2.2 Explicit Trap/Notification Registration 773 Internet traps/notifications and informRequests are not 774 considered by the Internet SMI to be associated with any one 775 object or group. The ISO/CCITT SMI, however, requires that a 776 notification be emitted by a specific object instance. 777 Therefore, determining which ISO/CCITT managed object class 778 should emit specific internet traps/notifications is 779 problematic. 781 This document defines a generic IIMC notification, 782 internetAlarm (see 3.2.4 and 4.1.4) that is used to carry 783 all Internet traps/notifications and informRequests. This 784 notification is to be emitted according to the conditions 785 described in section 3.2.4 either by the 786 {iimcRFC12131354}:internetSystem managed object defined in 787 [22] and derived from the internet system group defined in 788 [14], or by the {iimcIIMCProxy}:cmipsnmpProxyAgent managed 789 object defined in [23]. However, each Internet defined 790 trap/notification and informRequest must be registered such 791 that they may be differentiated within the IIMC generic 792 notification. 794 Internet traps/notifications are registered using the OID 795 corresponding to the value of the Internet snmpTrapOID 796 object defined in [20]. 798 For SNMPv1 trap PDUs, the snmpTrapOID is derived as stated 799 in the SNMPv1/SNMPv2 Coexistence document [21] 3.1.2(2). 800 That definition is repeated below: 802 "... if the value of the generic-trap field is 803 'enterpriseSpecific' then the value used is the 804 concatenation of the enterprise field from the trap 805 PDU with two additional sub-identifiers, '0', and the 806 value of the specific-trap field." 807 DRAFT February, 1994 809 For notifications, informRequests, defined according to the 810 SNMPv2 SMI, the registered OID is the value of the 811 snmpTrapOID. 813 The registered OID for the Internet trap/notification is 814 then used as the value for the probableCause field of the 815 IIMC generic notification, internetAlarm, as defined in 816 section 3.2.4 and 4.1.4. 818 2.2 NAMING PROCEDURES 820 ISO/CCITT objects are identified by specifying read-only 821 attributes within the object class as naming attributes. The 822 naming attribute is used to form the relative distinguished 823 name of the object instance. The sequence of relative 824 distinguished names that trace the path in the naming 825 hierarchy from the root to the object forms a distinguished 826 name that uniquely identifies the object instance. 828 2.2.1 Naming Attributes 830 The conversion of Internet MIBs into ISO/CCITT GDMO MIBs 831 requires that naming attributes be defined and registered 832 for each ISO/CCITT object class derived from Internet 833 management entities. 835 This paper specifies conventions for naming attributes: 836 their labeling, registration, and value definition, to 837 facilitate automated generation of naming attributes for 838 object classes derived from Internet MIBs. 840 The convention for assigning labels to naming attributes 841 shall be to append "Id" to the label of the object class 842 with which they are associated. 844 The convention for assigning registration OIDs to naming 845 attributes is described in 2.1.1.4. 847 The convention for assigning syntaxes to naming attributes 848 for instance identification shall be as follows. 850 The naming attribute value syntax shall be either an ASN.1 851 NULL syntax or an ASN.1 SEQUENCE identifying the Internet 852 INDEX objects used to name the object class and their 853 syntax. 855 Managed objects for which only a single instance resides in 856 the managed system, e.g., {iimcRFC12131354}:tcp, shall use 857 the ASN.1 NULL for their syntax. Managed object classes that 858 may have multiple instances, e.g., table entries, shall use 859 as their syntax an ASN.1 SEQUENCE that contains syntaxes of 860 DRAFT February, 1994 862 the internet objects identified in the INDEX (or AUGMENTS) 863 clause of the Internet Macro from which the object class is 864 derived, as defined in [11] or [17]. The values of the 865 indexing attributes shall be transferred using the ASN.1 866 syntax specified for the Internet objects. 868 Syntax specifications for single instance naming attributes 869 shall be of the form: 871 || "IdValue" ::= NULL. 873 Syntax specifications for multiple instance naming 874 attributes shall be of the form: 876 || "IdValue" ::= SEQUENCE 877 { 878 879 [, ]*i } 881 where the following definitions apply. 883 -- The label of the naming 884 attribute which is derived by appending "Id" to the label of 885 the object class for which the naming attribute is being 886 defined. 888 -- The label of an Internet object which is 889 listed in the INDEX clause of the Internet entity from which 890 the ISO/CCITT object class is derived. 892 -- The syntax associated with the Internet 893 object having the associated . 895 The values of INDEX variables used in the naming attribute 896 structure shall NOT follow the IMPLIED semantics defined in 897 SNMPv2. 899 -- For multiple instance object classes, the index 900 variables shall be listed, and tagged, within the SEQUENCE 901 in the order of their appearance in the INDEX clause of the 902 associated OBJECT-TYPE macro from which the ISO/CCITT object 903 class is derived. Each ASN.1 tag has the syntax "[i]", where 904 i = 1 to the number of index variables. 906 2.2.2 ISO/CCITT-Internet Naming Tree 908 The ISO/CCITT SMI requires that managed object instances 909 (conventionally just called managed objects) be bound into a 910 naming hierarchy, or tree, for purposes of naming. This 911 hierarchy is often called the containment hierarchy. The 912 binding must specify for each managed object class: the 913 object class which is superior to it in the containment 914 hierarchy; and a naming attribute in the object class that 915 DRAFT February, 1994 917 is used to distinguish instances of the object class at a 918 given level in the hierarchy. The name binding is specified 919 after the object class has been defined. 921 2.2.3 Distinguished Names 923 The distinguished name (DN) of a managed object consists of 924 a sequence of relative distinguished names (RDN), one for 925 each managed object on the naming path from the root to the 926 managed object. Each relative distinguished name contains 927 exactly one attribute, the "naming" attribute for the 928 corresponding class, as specified by a NAME BINDING 929 template. This DN is used as the CMIP ManagedObjectInstance 930 or BaseObjectInstance parameter for identifying managed 931 objects. 933 For example, a distinguished name designating a particular 934 routing table entry (of class ipRouteEntry) might be: 936 { 937 {"Rec. X.721 | ISO/IEC 10165-2 : 1992":systemTitle = 938 "troi.mitre.org"} 939 {{iimcRFC12131354}:ipId = NULL } 940 {{iimcRFC12131354}:ipRouteEntryId = SEQUENCE 941 { 942 ipRouteDest {129.83.2.17} 943 } 944 } 946 with appropriate ASN.1 tags, etc., included. 948 Note: The beginning of the above example distinguished name 949 is implementation dependent. For example, the naming 950 attribute for the system object could have been 951 chosen to be the systemId attribute instead of the 952 systemTitle attribute, and the system object could 953 have been bound to object classes other than root. 955 2.3 OID TRANSLATION 957 The procedures required to translate between Internet 958 registered OIDs and names, and ISO/CCITT registered 959 attribute and class OIDs are described in this section. 961 2.3.1 OID/Name Translation ISO/CCITT to Internet 963 The general procedure for deriving ISO/CCITT registered OIDs 964 from Internet OIDs was explained in section 2.1, and the 965 structure of the naming attribute value was explained in 966 section 2.2. This paragraph explains how the information 967 DRAFT February, 1994 969 used in an ISO/CCITT case OID, attribute OID, and the naming 970 attribute value may be used to create the identifier for 971 naming Internet objects. 973 The following definitions apply: ((c) and (a) refer to class 974 and attribute, respectively) 976 From 2.1, 978 {classOID} ::= {iimcAutoObjAndAttr 979 (c)} 981 and 983 {attributeOID} ::= {iimcAutoObjAndAttr 984 (a)} 986 For example, examine the {iimcRFC12131354}:ipRouteEntry 987 object class OID: 989 {iimcRFC12131354}:ipRouteEntry ::= {iimcAutoObjAndAttr 990 1 3 6 1 2 1 4 21 1} 991 where (c) ::= 1 3 6 1 2 1 4 21 1, 993 and an attribute that belongs ipRouteEntry, 994 {iimcRFC12131354}:ipRouteNextHop: 996 {iimcRFC12131354}:ipRouteNextHop ::= 997 {iimcAutoObjAndAttr 1 3 6 1 2 1 4 21 1 7} 998 where (a) ::= 1 3 6 1 2 1 4 21 1 7. 1000 Note that the attribute (a) for 1001 ipRouteNextHop is equal to (c) for its 1002 associated object class, ipRouteEntry, with the sub- 1003 identifier (7) appended to it. Most of the time the 1004 relationship: 1006 (a) ::= (c) 1009 is true for translated MIB attributes. This property is 1010 useful for determining the object class and object instance 1011 with which an attribute may be associated during run-time 1012 translation of Internet object instances contained in SNMP 1013 response PDUs and traps/notifications. 1015 Note: When attributes that were not a part of the original 1016 Internet group, or table entry, are included in a 1017 translated object class, then this relationship is 1018 not valid. For example, derived attributes assigned 1019 to an object class because their inclusion was 1020 indicated by an SNMPv2 AUGMENTS clause, as discussed 1021 in section 3.1. 1023 DRAFT February, 1994 1025 From 2.2, the ISO/CCITT naming attribute value contains 1026 either an ASN.1 NULL value, or a list of index variables in 1027 an ASN.1 SEQUENCE with their values represented in their 1028 appropriate syntax (where the "( )" indicates "contents 1029 of"): 1031 (naming attribute) ::= 1033 where the is an ASN.1 NULL, or a 1034 SEQUENCE identifying the INDEX attributes used to name the 1035 object class, and their syntax. Managed objects for which 1036 only a single instance resides in the managed system, e.g., 1037 {iimcRFC12131354}:tcp and {iimcRFC12131354}:ip, shall use 1038 the ASN.1 NULL for their value. Managed object classes that 1039 may have multiple instances, e.g., table entries, shall use 1040 as their value an ASN.1 SEQUENCE that contains values of the 1041 attributes derived from internet objects identified in the 1042 INDEX (or AUGMENTS) clause of the Internet Macro from which 1043 the object class is derived, as defined in [11] or [17]. 1045 For example, the ISO/CCITT naming attribute value for the 1046 instance of {iimcRFC12131354}:ipRouteEntry specific to IP 1047 address "129.83.2.17" contains the ipDestination index 1048 variable as an IP address represented in an ASN.1 OCTET 1049 STRING of size 4 as specified in [RFC1242]. 1051 The Internet uses the following convention to uniquely 1052 identify an Internet object instance: 1054 {internet object name}::= {(a) 1055 } 1057 For example, the internet object name for ipRouteNextHop 1058 corresponding to IP address 129 83 2 17 is {1 3 6 1 2 1 4 21 1059 1 7 129 83 2 17}, where (a) ::= 1 3 6 1 2 1060 1 4 21 1 7, ::=129 83 2 17. 1062 Therefore, given the contents of the naming attribute for 1063 the ISO/CCITT object instance being accessed, the is extracted. Given the attributeOID for the 1065 attribute being operated upon, the (a) is 1066 extracted. The {internet object name} is then formed from 1067 the results, taking into account appropriate conversions 1068 from their ASN.1 representation. 1070 For example, assume that a CMIS request is issued specifying 1071 a distinguished name for an {iimcRFC12131354}:ipRouteEntry 1072 managed object as illustrated in section 2.2.3; and an 1073 attribute for ipRouteEntry, say 1074 {iimcRFC12131354}:ipRouteNextHop. The ipRouteNextHop 1075 attribute has been assigned the identifier 1076 {iimcAutoObjAndAttr 1 3 6 1 2 1 4 21 1 7} in the MIB defined 1077 in [22]. Therefore, the ipRouteNextHop attribute identifier 1078 would first have to be translated into the corresponding 1079 DRAFT February, 1994 1081 Internet identifier {1 3 6 1 2 1 4 21 1 7} by stripping off 1082 the iimcAutoObjAndAttr portion of the OID. Then, from the 1083 RDN value for the ipRouteEntry extract the value for the 1084 , i.e., the value for the ipRouteDest 1085 index "129 83 2 17". Finally the Internet identification for 1086 this piece of management information would be constructed 1087 according to [14] as {ipRouteNextHop 129 83 2 17}, or 1088 equivalently, {1 3 6 1 2 1 4 21 1 7 129 83 2 17}. The agent 1089 with which this information resides is identified (see 1090 2.2.3), by the RDN for the system managed object naming 1091 attribute, e.g., the "systemTitle", as "troi.mitre.org." 1093 2.3.2 OID/Name Translation Internet to ISO/CCITT 1095 Internet to ISO/CCITT OID/name translation is only necessary 1096 when used during run-time proxy translation. At run-time 1097 internet identifiers are provided as internet object names 1098 in SNMP responses and traps/notifications. The internet 1099 object names are of the form described in section 2.3.1. 1100 Although actual translation is required only during run-time 1101 in proxy implementations, the translation properties, and 1102 information that may be obtained, must be understood in 1103 order to properly define the structure of the IIMC generic 1104 notification, internetAlarm, defined in section 3.2.4. 1106 Given the definitions shown in section 2.3.1, and knowledge 1107 of the IIMC naming hierarchy (name bindings), the ISO/CCITT 1108 {classOID},{attributeOID}, and distinguished name can be 1109 derived from Internet names and the Internet agent address. 1111 * The iimcAutoObjAndAttr OID is known. 1113 * Using knowledge of the internet name structure as 1114 described in section 2.3.1, and knowledge of valid 1115 (a) values known to the proxy, the 1116 (a) and may be 1117 extracted from the internet name. 1119 Note: The extraction process is not possible if the valid 1120 (a) value is not known to the 1121 proxy. The translation process cannot be performed. 1123 * The ISO/CCITT attribute OID is formed as: 1125 {iimcAutoObjAndAttr (a)} 1127 * The ISO/CCITT class OID may be determined in one of two 1128 ways: 1130 i) assume that the (a) contains the 1131 object class OID, (c), with which 1132 the attribute may be associated, as discussed in 1133 section 2.3.1. Then stripping off the final component 1134 DRAFT February, 1994 1136 of the OID will yield the (c). The 1137 object class OID is then formed as {iimcAutoObjAndAttr 1138 (c)}. However, see the note in 1139 section 2.3.1. 1141 ii) use a safer approach, and determine the class OID 1142 by looking up the ISO/CCITT object class OID to which 1143 the attribute identified as {iimcAutoObjAndAttr 1144 (a)} belongs. 1146 * The naming attribute OID may be derived by extracting the 1147 from the class OID derived 1148 previously, and prepending it with the OID for 1149 {iimcAutoName} as described in 2.1.1.4. 1151 * The managed object instance value, the object's DN, may 1152 be determined as follows: 1154 a) the value of the naming attribute associated with 1155 the object class may be formed as: 1157 . 1159 b) the naming attribute value, and the naming 1160 attribute OID defined in section 2.2.1, are used to 1161 form the final RDN for the object's DN. The sequence 1162 of other RDNs for the DN are determined from knowledge 1163 of the naming hierarchy defined for proxy [23], i.e., 1164 the IIMC proxy name bindings, and the Internet agent's 1165 address. 1167 Note: If the Internet agent's address cannot be determined, 1168 then it may not be possible to associate a 1169 notification with a specific agent. This may be a 1170 problem if multiple Internet agents are associated 1171 with the same network address. 1173 2.4 INHERITANCE FOR OBJECT CLASSES 1175 The "Rec. X.721 | ISO/IEC 10165-2 : 1992":top class defined 1176 by [8] is the ultimate superior in the ISO/CCITT inheritance 1177 hierarchy. The class "top" contains attributes which are 1178 inherited by all managed object classes that are defined 1179 using the ISO/CCITT SMI and GDMO templates. 1181 Not all attributes of "top" need to be instantiated in any 1182 single managed object. All objects shall instantiate the 1183 mandatory "objectClass", and "nameBindings" attributes. If 1184 conditional packages may apply, an object shall instantiate 1185 the "packages" attribute. 1187 DRAFT February, 1994 1189 2.5 REFERENCE LABELS FOR DERIVED ENTITIES 1191 The labels used to reference Internet entities (groups, 1192 objects, traps) shall be used to reference the corresponding 1193 templates for the derived ISO/CCITT entity (object class, 1194 attribute, notification). 1196 DRAFT February, 1994 1198 3. INTERNET TO ISO/CCITT MIB TRANSLATION PROCEDURES 1200 The procedures for translating Internet SMI MIBs into 1201 ISO/CCITT SMI MIBs consist of pre-translation procedures, 1202 GDMO template translation procedures, and post-translation 1203 procedures. Many of the procedures are subject to 1204 automation; some are not. Comments are provided concerning 1205 possible aids to automation; however, it is not the intent 1206 of this document to provide fully automated translation 1207 algorithms. 1209 3.1 PRE-TRANSLATION PROCEDURES 1211 Pre-translation procedures are outlined below. The rationale 1212 for steps (a)-(d) is that the ISO/CCITT object classes and 1213 associated attributes must be identified. The rationale for 1214 steps (e)-(f) is that all ASN.1 syntax references in 1215 templates must be an ASN.1 External type reference or 1216 External value reference, i.e., must reference a label that 1217 appears on the left side of an ASN.1 construct within some 1218 ASN.1 module that appears in the document that defines the 1219 derived MIB. Internet MIBs often reference basic ASN.1 1220 constructs, such as INTEGER and OCTET STRING, which must be 1221 converted into an External type reference. Default values 1222 must reference an External value reference. 1224 (a) Identify Internet groups and OBJECT-TYPEs associated 1225 with each group. For SNMPv2 defined MIBs, the OBJECT-GROUP 1226 macro includes this information. For SNMPv1 defined MIBs, 1227 the group may be identified manually and then the members 1228 of the group identified by the fact that their OIDs 1229 contain the group object identifier. For SNMPv1 defined 1230 MIBs, procedure (c) must be followed. 1232 (b) Identify conceptual table OBJECT-TYPEs, conceptual table 1233 entry (row) OBJECT-TYPEs associated with each table, and 1234 columnar OBJECT-TYPEs associated with each conceptual 1235 table entry. 1237 For SNMPv2 defined MIBs, the MAX-ACCESS clause of the 1238 conceptual table and entry OBJECT-TYPES macro will have a 1239 value of 'not-accessible', and the convention often used 1240 is to include the word "Table" or "Entry" in the macro 1241 label. Once a conceptual table has been identified, the 1242 corresponding conceptual entry OBJECT-TYPE macro can be 1243 identified via its registered object identifier through 1244 the convention of appending a 1 to the table object 1245 identifier. Alternatively, the conceptual table's SYNTAX 1246 clause may be examined to determine the label of the 1247 DRAFT February, 1994 1249 corresponding conceptual entry Macro. SNMPv1 defined MIBs 1250 are not so consistent in their use of "not-accessible"; 1251 however, the other conventions apply. 1253 For SNMPv2 defined MIBs, tables may be defined with table 1254 entries that augment (SNMPv2 AUGMENT clause) entries for 1255 an existing table. The table entry object class for the 1256 augmented table will be bound to the table entry object 1257 class that corresponds to the reference in the AUGMENTS 1258 clause. 1260 (c) For each group, the OBJECT-TYPEs not identified in 1261 procedure (b), and not having an ACCESS or MAX-ACCESS 1262 clause value of "not-accessible", are identified for 1263 translation into attributes of an ISO/CCITT object class 1264 associated with the group. The OBJECT-TYPEs that have an 1265 ACCESS or MAX-ACCESS clause of 'not-accessible', i.e. 1266 conceptual table and conceptual table entry objects, are 1267 not translated. 1268 Note: Some groups may not have any OBJECT-TYPEs to 1269 translate into attributes. 1271 (d) For each conceptual table entry OBJECT-TYPE, the set 1272 (set1) of columnar OBJECT-TYPEs associated with the table 1273 entry are identified for translation into ISO/CCITT 1274 attributes of an ISO/CCITT object class associated with 1275 the entry. Another set (set2) of OBJECT-TYPES identified 1276 in the INDEX clause of the conceptual table entry OBJECT- 1277 TYPE are also identified for inclusion in the class. If 1278 the AUGMENTS clause is present, then the INDEX clause of 1279 the conceptual table entry OBJECT-TYPE pointed to by the 1280 AUGMENTS clause identifies the elements of (set2). The 1281 union of these two sets constitutes the set of ISO/CCITT 1282 attributes associated with the table entry object class. 1283 All OBJECT-TYPEs are translated, excluding those that have 1284 an ACCESS or MAX-ACCESS clause of 'not-accessible'. 1286 Note: The set of columnar OBJECT-TYPES associated with a 1287 table entry can be identified by the SYNTAX clause 1288 for the OBJECT-TYPE for the conceptual table entry. 1289 The SYNTAX clause is of the form: 1290 SEQUENCE OF 1291 where includes the label of an OBJECT-TYPE 1292 included in the conceptual table entry. 1294 (e) Create an ASN.1 module for use in the GDMO template 1295 translations. Create an IMPORTS clause for the module and 1296 include in it the syntax to be imported from other 1297 modules. This may be done by including the parameters for 1298 the IMPORTS clause encountered in the Internet module. (An 1299 alternative is to import the syntax for attribute types 1300 defined in this document from the IimcCommonDef module. 1301 However, not all of the syntax may be needed, and some 1302 DRAFT February, 1994 1304 necessary syntax may be omitted for attribute types 1305 defined in other MIBs.) 1307 When any Internet TEXTUAL-CONVENTIONS macros that may be 1308 present in the Internet module are translated according to 1309 the procedures of 3.2.6, the resulting ASN.1 syntax shall 1310 be included in the new ASN.1 module. TEXTUAL-CONVENTIONS 1311 macros shall be translated first so that these ASN.1 1312 constructs may be used during the translation of OBJECT- 1313 TYPE macros. 1315 For each OBJECT-TYPE that is to be translated into an 1316 ISO/CCITT attribute, check the value of the SYNTAX clause, 1317 and if it is not a syntax included in the IMPORTS clause 1318 of the new ASN.1 module, or defined using an SNMPv2 1319 TEXTUAL-CONVENTION macro, then do one of the following: 1321 i) If the value is not an External type reference: 1322 create an External type reference for the value in the 1323 SYNTAX clause and put it into the ASN.1 module. The 1324 label for the External type reference shall be the 1325 attribute label with the first letter capitalized. 1327 ii) If the value is an External type reference put the 1328 External type reference syntax into the ASN.1 module. 1330 (f) If a DEFVAL clause is present, create an External value 1331 reference which has the type indicated by the OBJECT-TYPE 1332 SYNTAX clause and is assigned the value of the DEFVAL 1333 clause. The label for the External value reference shall 1334 be the attribute label preceded by "c-" (lower case letter 1335 "c"). Place the External value reference into the ASN.1 1336 module created in e). For example, the following would be 1337 a valid value references (assuming StorageType was 1338 declared in, or imported to, the same ASN.1 module): 1340 c-contextStorageType StorageType ::= nonVolatile 1341 c-xyz INTEGER ::= 100. 1343 (g) If the ASN.1 module for the Internet MIB definition 1344 contains ASN.1 value assignments, then the syntax for 1345 those value assignments pertinent to the translation shall 1346 either be placed in the ASN.1 module created in (e) or 1347 imported into the module using an External value 1348 reference. 1350 Note: It is recommended that a syntax that is used more 1351 than once in the MIB to be translated be defined just 1352 once in the new ASN.1 module created in (e) and 1353 referenced repeatedly. Examples of such commonly 1354 referenced types are INTEGER, OCTET STRING, and 1355 OBJECT IDENTIFIER. 1357 DRAFT February, 1994 1359 3.2 GDMO TRANSLATION PROCEDURES 1361 Readers of this document are assumed to have familiarity 1362 with the GDMO templates and their format. The templates 1363 structures presented here should be considered definitive 1364 for MIBs defined according to the translation procedures 1365 defined in this document. 1367 The GDMO templates in this paragraph contain elements 1368 indicated by "< x >", where "x" is to be interpreted and the 1369 result substituted into the template. 1371 The "||" symbol indicates concatenation of elements. 1373 Adjacent elements that are not concatenated shall be 1374 separated by at least one space. 1376 The "[ ]" symbols surrounding a construct indicate that it 1377 maybe present or absent in any particular instance of the 1378 template. 1380 The "[ ]*" symbols surrounding a construct indicate that it 1381 may be present or absent in any particular instance of the 1382 template an undefined number of times. 1384 An "|" symbol is used to indicate that a choice must be made 1385 between alternate constructs. 1387 The "!" symbol is used to delimit text strings in the 1388 templates. Other delimiters may be used, as specified by the 1389 GDMO. The delimiter may not be used in the text string 1390 unless it is "doubled", e.g.,"!!". 1392 Elements that are defined in one template are not repeated 1393 for other templates unless its interpretation has changed. 1395 The Internet SNMPv2 SMI also includes macros for specifying 1396 compliance with the MIBs. These macros are similar to 1397 ISO/CCITT managed object conformance statements (MOCS), and 1398 are not addressed here. 1400 3.2.1 Translation of Groups 1402 Internet groups may be translated to ISO/CCITT managed 1403 object classes by filling in the following GDMO template: 1405 MANAGED OBJECT CLASS 1406 DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 :1992" :top; 1407 CHARACTERIZED BY 1408 || "Pkg" PACKAGE 1409 [BEHAVIOUR 1410 || "PkgBehaviour" BEHAVIOUR 1411 DEFINED AS !!;;] 1412 DRAFT February, 1994 1414 ATTRIBUTES 1415 || "Id" GET 1416 ["," 1417 [DEFAULT VALUE ] 1418 [PERMITTED VALUES ] 1420 ]*;;; 1422 REGISTERED AS { iimcAutoObjAndAttr (c) }; 1424 where the following definitions apply. 1426 -- The label associated with the Internet 1427 group. 1429 -- Any textual description 1430 that is applicable to the resource modeled by this group, 1431 and the resource's management behaviour. Text in the SNMPv2 1432 DESCRIPTION clause of the OBJECT-GROUP macro may be used. To 1433 facilitate parsing of BEHAVIOUR clauses for classes derived 1434 from groups, the following scannable structure shall be used 1435 (the [] indicate optional constructs, keywords must be in 1436 caps, keywords shall be excluded from the descriptive text, 1437 keywords shall appear in the order illustrated below): 1439 [BEGINPARSE 1440 [REFERENCE !! 1441 !!;] 1444 [DESCRIPTION !! 1445 !!;] 1447 ENDPARSE] 1449 The scannable structure shall be the first text in the 1450 BEHAVIOUR clause. 1452 -- The label of an Internet OBJECT- 1453 TYPE which is included in the group and does not represent a 1454 conceptual table, a conceptual table entry, or an OBJECT- 1455 TYPE included in a conceptual table entry. These become 1456 attributes of the object class. 1458 -- The constraints on 1459 the attribute values expressed as an ASN.1 subtype that is 1460 valid for the attribute's syntax. This clause is present 1461 only when constraints are specified by the source MIB ASN.1 1462 syntax, but are not specified in the syntax associated with 1463 the corresponding translated attribute. 1465 -- The 1466 mapping of the ACCESS (or SNMPv2 MAX-ACCESS) clause value as 1467 DRAFT February, 1994 1469 defined below (multi-valued attributes are not permitted in 1470 the Internet SMI): 1472 OBJECT-TYPE ACCESS Clause ISO/CCITT 1473 Value 1474 read-only GET 1475 read-write GET-REPLACE 1476 write-only REPLACE 1477 read-create not applicable 1478 not-accessible not translated 1479 Table 1. Mapping the Group ACCESS clause. 1481 -- The value of the DEFVAL 1482 clause in the form of an External value reference, i.e., 1483 ., where the module-name is the 1484 name of an ASN.1 module within the document in which this 1485 object class is defined, and the value-name is the label 1486 assigned to the ASN.1 value definition contained in the 1487 DEFVAL clause. Where it is necessary to refer to the label 1488 of a definition contained in another document, this may be 1489 achieved by means of a local ASN.1 module which makes use of 1490 the ASN.1 IMPORTS mechanism to import the appropriate value 1491 definition. 1493 3.2.2 Translation of Table Entry Objects 1495 Internet conceptual table entry objects may be translated to 1496 ISO/CCITT managed object classes by filling in the following 1497 GDMO template: 1499 MANAGED OBJECT CLASS 1500 DERIVED FROM "Rec. X.721 | ISO/IEC 10165-2 : 1992":top; 1501 CHARACTERIZED BY || "Pkg" PACKAGE 1502 BEHAVIOUR 1503 || "PkgBehaviour" BEHAVIOUR 1504 DEFINED AS 1505 !!;; 1506 ATTRIBUTES 1507 || "Id" GET 1508 ["," 1509 [DEFAULT VALUE ] 1510 [PERMITTED VALUES ] 1512 ]*;;; 1514 REGISTERED AS {iimcAutoObjAndAttr (c) }; 1516 where the following definitions apply. 1518 -- The label of an Internet OBJECT-TYPE 1519 which represents a conceptual table entry. 1521 DRAFT February, 1994 1523 -- The label of an Internet OBJECT- 1524 TYPE which represents an OBJECT-TYPE included in a 1525 conceptual table entry. These become attributes of the table 1526 entry managed object. 1528 -- The 1529 mapping of the ACCESS (or SNMPv2 MAX-ACCESS) clause value as 1530 defined below (multi-valued attributes are not permitted in 1531 the Internet SMI): 1533 OBJECT-TYPE ACCESS Clause ISO/CCITT 1534 Value 1535 read-only GET 1536 read-write* GET-REPLACE 1537 write-only REPLACE 1538 read-create* GET-REPLACE 1539 not-accessible not-translated 1540 Table 2. Mapping the Table Entry Object ACCESS clause. 1542 * Some attributes that were derived from OBJECT-TYPEs with a 1543 read-create or read-write access clause will be changed to 1544 GET during post-translation processing of INDEX type 1545 attributes. See section 3.3.3. 1547 -- To facilitate 1548 parsing of BEHAVIOUR clauses for classes derived from table 1549 entries, the following scannable structure shall be used 1550 (the [] indicate optional constructs, keywords must be in 1551 caps, keywords shall be excluded from the descriptive text, 1552 keywords shall appear in the order illustrated below): 1554 [BEGINPARSE 1555 [REFERENCE !! 1556 !!;] 1559 [DESCRIPTION !! 1560 !!;] 1562 INDEX 1563 [IMPLIED] || "." 1564 || 1565 [,[IMPLIED] 1566 || "." || ]*; 1567 [AUGMENTS ;] 1569 ENDPARSE] 1571 where the following definitions apply. 1573 IMPLIED -- The key word as encountered in the INDEX clause 1574 of SNMPv2 MIBs. The SNMPv2 semantics of IMPLIED are to be 1575 applied to the index variable that it precedes when 1576 translating from OSI names into Internet names. The values 1577 DRAFT February, 1994 1579 of INDEX variables, when used in the naming attribute 1580 structure, shall NOT follow the IMPLIED semantics defined in 1581 SNMPv2. 1583 -- The label for the ASN.1 1584 module that contains the Internet MIB definitions, 1586 -- The Internet label assigned to the 1587 object that appears in the Internet macro INDEX clause for a 1588 table entry. 1590 The scannable structure shall be the first text in the 1591 BEHAVIOUR clause. 1593 3.2.3 Translation of Other OBJECT-TYPES 1595 Other Internet OBJECT-TYPEs are translated into ISO/CCITT 1596 attributes by filling in the following GDMO template: 1598 ATTRIBUTE 1599 [WITH ATTRIBUTE SYNTAX 1600 || "." || ;] 1602 | [DERIVED FROM ;] 1603 [MATCHES FOR ;] 1604 [BEHAVIOUR 1605 || "Behaviour" BEHAVIOUR 1606 DEFINED AS 1607 !!;;] 1608 REGISTERED AS {iimcAutoObjAndAttr (a)}; 1610 where the following definition applies. 1612 -- The label of the ASN.1 module 1613 that contains the ASN.1 syntax being referenced. The module 1614 must appear in the document that defines the translated MIB. 1616 ISO/CCITT have the concept of a generic "attribute type", 1617 which is a defined type that can be used in the definition 1618 of specific attributes. Attribute types have a defined 1619 syntax, generic semantics, and matching rules. For example, 1620 counter and gauge are attribute types. 1622 The SNMPv2 SMI has a similar concept embodied in the 1623 TEXTUAL-CONVENTIONS macro, which allows the definition of 1624 "Internet attribute types" with associated syntax and 1625 semantics. See section 3.2.6 for translation procedures 1626 associated with the TEXTUAL CONVENTIONS macro. 1628 Attributes of the defined SNMP types (e.g., Counter, 1629 IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32, 1630 Counter64, NsapAddress) shall inherit the semantics 1631 associated with the type -- not just the syntax. As such, 1632 DRAFT February, 1994 1634 they could have been defined as Internet attribute types 1635 using a TEXTUAL CONVENTIONS macro. See 4.1.4 for the 1636 conversion of these types into ISO/CCITT attribute types. In 1637 addition, 4.1.4 contains ISO/CCITT attribute type 1638 definitions derived from [18]. 1640 Attribute templates derived from OBJECT-TYPE macros that 1641 specify these Internet attribute types in their SYNTAX 1642 clause shall contain the DERIVED FROM clause. Attribute 1643 templates derived from other ASN.1 types shall contain the 1644 WITH SYNTAX clause. 1646 -- Translation of the SYNTAX 1647 clause into a valid type reference name using the ASN.1 1648 External type reference notation as GDMO requires. 1650 -- The matching rules 1651 for use in CMIS filtering operations. 1653 These rules also apply to External type references that 1654 reference the syntax type. These matching rules may be 1655 applied by automated mechanisms and then examined in the 1656 post-translation phase. 1658 Syntax Type Matching Rules 1659 INTEGER, ENUMERATED EQUALITY, ORDERING 1660 OCTET STRING EQUALITY, ORDERING, 1661 SUBSTRINGS 1662 BIT STRING EQUALITY 1663 OBJECT IDENTIFIER* EQUALITY, ORDERING 1664 NULL EQUALITY 1665 Table 3. Mapping to matching rules. 1667 * ORDERING, when applied to OBJECT IDENTIFIER, refers to the 1668 lexicographical ordering of the OIDs as used in [12] [19]. 1670 See 4.1.2 for the matching rules that are inherited from 1671 some ISO/CCITT attribute types derived from Internet 1672 attribute types. 1674 -- Attributes of the defined 1675 SNMP/SNMPv2 types (e.g., Counter, IpAddress, Gauge, 1676 TimeTicks, Opaque, Counter32, Gauge32, Counter64, 1677 NsapAddress), and Internet attribute types defined using the 1678 SNMPv2 TEXTUAL CONVENTIONS macro, shall be treated as 1679 ISO/CCITT attribute types. Specific attributes are derived 1680 from these types. 1682 The following table indicates the translations required for 1683 Internet attribute types as defined either in this document 1684 or Internet documents. ISO/CCITT attribute types 1685 corresponding to the following Internet attribute types are 1686 defined in 4.1.2. 1688 DRAFT February, 1994 1690 Syntax Type Substituted Value 1691 AutonomousType {iimcIIMCIMIBTRANS} 1692 :autonomousType 1693 Counter {iimcIIMCIMIBTRANS} 1694 :counter32 1695 Counter32 {iimcIIMCIMIBTRANS} 1696 :counter32 1697 Counter64 {iimcIIMCIMIBTRANS} 1698 :counter64 1699 DisplayString {iimcIIMCIMIBTRANS} 1700 :displayString 1701 Gauge {iimcIIMCIMIBTRANS} :gauge32 1702 Gauge32 {iimcIIMCIMIBTRANS} :gauge32 1703 InstancePointer {iimcIIMCIMIBTRANS} 1704 :instancePointer 1705 IpAddress {iimcIIMCIMIBTRANS} 1706 :ipAddress 1707 MacAddress {iimcIIMCIMIBTRANS} 1708 :macAddress 1709 NetworkAddress {iimcIIMCIMIBTRANS} 1710 :ipAddress 1711 NsapAddress {iimcIIMCIMIBTRANS} 1712 :nsapAddress 1713 Opaque {iimcIIMCIMIBTRANS} :opaque 1714 PhysAddress {iimcIIMCIMIBTRANS} 1715 :physAddress 1716 RowStatus {iimcIIMCIMIBTRANS} 1717 :rowStatus 1718 TestAndIncrement {iimcIIMCIMIBTRANS} 1719 :testAndIncrement 1720 TimeInterval {iimcIIMCIMIBTRANS} 1721 :timeInterval 1722 TimeStamp {iimcIIMCIMIBTRANS} 1723 :timeStamp 1724 TimeTicks {iimcIIMCIMIBTRANS} 1725 :timeTicks 1726 TruthValue {iimcIIMCIMIBTRANS} 1727 :truthValue 1728 UInteger32 {iimcIIMCIMIBTRANS} 1729 :uInteger32 1730 Table 4. Common attribute types. 1732 -- To facilitate 1733 parsing of BEHAVIOUR clauses for attributes derived from 1734 Internet objects, the following scannable structure shall be 1735 used (the [] indicate optional constructs, keywords must be 1736 in caps, keywords shall be excluded from the descriptive 1737 text, keywords shall appear in the order illustrated below): 1739 [BEGINPARSE 1740 [REFERENCE !! 1741 !!;] 1743 [DESCRIPTION !! 1744 DRAFT February, 1994 1746 !!;] 1748 [UNITS !! 1749 !!;] 1752 [DEFVAL 1753 ;] 1756 ENDPARSE] 1758 The scannable structure shall be the first text in the 1759 BEHAVIOUR clause. 1761 3.2.4 Translation of Notifications 1763 The Concise MIB Definitions [13] for SNMPv1 does not contain 1764 a macro for representing traps since, in SNMPv1, traps were 1765 considered part of the protocol and not part of the MIB. A 1766 subsequent attempt was made to correct this problem in [15] 1767 by defining a TRAP-TYPE macro. The SNMPv2 SMI [17] defines a 1768 NOTIFICATION macro and its mapping onto an SNMPv2 PDU. The 1769 document on SNMPv1/SNMPv2 Coexistence [21] defines a mapping 1770 between SNMPv1 trap PDUs and SNMPv2 notifications. 1771 Therefore, by inference, there exists a mapping of SNMP trap 1772 PDUs into an SNMPv2 NOTIFICATION macro. 1774 The ISO/CCITT SMI models notifications as being emitted by 1775 specific managed objects. As a consequence, notifications 1776 must be assigned to appropriate object classes at the time 1777 the object class is defined. New notifications cannot be 1778 added to an object class without changing the class's 1779 registration. 1781 The Internet SMI has no explicit concept of traps being 1782 associated with an object. Consequently, determining the 1783 IIMC derived managed object which is the source of a 1784 notification is not always possible. Therefore, this 1785 document defines a generic notification into which all 1786 Internet traps/notifications may be mapped. 1788 Internet Traps/Notifications may contain information related 1789 to multiple internet objects. Consequently, the generic 1790 notification may contain variables not affiliated with the 1791 same derived ISO/CCITT object class. This document requires 1792 that variables be placed into the generic notification even 1793 if they are not attributes of the object class from which 1794 the notification is emitted. 1796 The generic notification, "internetAlarm", shall be emitted 1797 by the internetSystem managed object as defined in [22] and 1798 derived from the internet system group defined in [14]. The 1799 DRAFT February, 1994 1801 notification shall be sent in the unconfirmed mode in the 1802 context that an Internet trap/notification would be sent, 1803 and in the confirmed mode in the context that an SNMPv2 1804 InformRequest PDU would be sent. 1806 When generated within a proxy, the events that shall trigger 1807 the notification to be emitted are the receipt of an 1808 Internet trap/notification, or an SNMPv2 InformRequest PDU. 1810 In accordance with [7] the decision whether to send a 1811 notification in the confirmed or unconfirmed mode is a 1812 matter for the agent to determine based on the policies 1813 associated with the manager. 1815 The SNMPv2 InformRequest PDU shall cause the notification to 1816 be sent in the confirmed mode, with the response containing 1817 no reply information, i.e., the CMIS service shall omit the 1818 event reply parameter. 1820 All SNMP traps/notifications shall cause the generic 1821 notification to be sent in the unconfirmed mode. 1823 In the case of proxy, an Internet trap/notification and 1824 SNMPv2 InformRequest PDU for which the agent address cannot 1825 be determined by the proxy shall cause the generic 1826 notification to be emitted by a different object than the 1827 internetSystem object, as defined in [23]. 1829 The internetAlarm notification is defined in section 4.1.4. 1831 3.2.5 Log Record for Internet Alarm 1833 If internetAlarm notifications and event reports are to be 1834 logged, then a corresponding log record object class must be 1835 defined. The internetAlarmRecord managed object class is 1836 defined in section 4.1.1. 1838 3.2.6 Translation of Internet Attribute Types 1840 ISO/CCITT has the concept of a generic "attribute type", 1841 which is a defined type that can be used in the definition 1842 of specific attributes. Attribute types have a defined 1843 syntax, generic semantics, and matching rules. For example, 1844 counter and gauge are attribute types. 1846 The SNMPv2 SMI has a similar concept embodied in the 1847 TEXTUAL-CONVENTION macro, which allows the definition of 1848 "Internet attribute types" with associated syntax and 1849 semantics. 1851 Attributes of the defined SNMP types (e.g., Counter, 1852 IpAddress, Gauge, TimeTicks, Opaque, Counter32, Gauge32, 1853 DRAFT February, 1994 1855 Counter64, NsapAddress) should inherit the semantics 1856 associated with the type -- not just the syntax. As such, 1857 they could have been defined as Internet attribute types 1858 using a TEXTUAL-CONVENTION macro. 1860 ISO/CCITT attribute types are defined using the ATTRIBUTE 1861 template, without the REGISTERED AS clause. 1863 ATTRIBUTE 1864 [[WITH ATTRIBUTE SYNTAX 1865 || "." ||;] 1867 | [DERIVED FROM ;]] 1868 [MATCHES FOR ;] 1869 [BEHAVIOUR 1870 || "Behaviour" 1871 BEHAVIOUR 1872 DEFINED AS 1873 !!;;] 1875 where the following definitions apply. 1877 -- The label associated with 1878 the TEXTUAL-CONVENTION macro, or with the generic type that 1879 could have been defined using that macro. 1881 -- To facilitate 1882 parsing of BEHAVIOUR clauses for attributes derived from 1883 internet objects, the following scannable structure shall be 1884 used (the [] indicate optional constructs, keywords must be 1885 in caps, keywords shall be excluded from the descriptive 1886 text, keywords shall appear in the order illustrated below): 1888 [BEGINPARSE 1889 [REFERENCE !! 1890 !!;] 1892 [DESCRIPTION !! 1893 !!;] 1895 [UNITS !! 1896 !!;] 1899 [DISPLAY-HINT !! 1900 !!; 1904 ENDPARSE] 1906 The scannable structure shall be the first text in the 1907 BEHAVIOUR clause. 1909 DRAFT February, 1994 1911 Attribute templates derived from OBJECT-TYPE macros that 1912 specify Internet attribute types in their SYNTAX clause 1913 shall specify the corresponding ISO/CCITT attribute types in 1914 their DERIVED FROM clause. 1916 In many cases, an SNMP SMI MIB will define a new ASN.1 type 1917 which is repeatedly referenced by a large number of OBJECT- 1918 TYPE macros. In this case, it would be useful to define a 1919 new generic attribute type once and then use DERIVED FROM 1920 wherever the type is used. Furthermore, if the new ASN.1 1921 type is actually a refinement of one of the defined SNMP 1922 types (for example, a refinement of DisplayString), it is 1923 desirable that the behaviour associated with the defined 1924 SNMP type gets carried over into the translated MIB. To 1925 accomplish this, such cases could use the DERIVED FROM 1926 clause when defining new generic attribute types. For 1927 example, the ASN.1 syntax: 1929 DateAndTime ::= DisplayString (SIZE (14)) 1930 -- comments provide additional semantics 1932 could be represented as a new generic attribute type: 1934 dateAndTime ATTRIBUTE 1935 DERIVED FROM {iimcIIMCIMIBTRANS}:displayString; 1936 BEHAVIOUR dateAndTimeBehaviour BEHAVIOUR 1937 DEFINED AS !!;; 1939 Constraints on the attribute value range, e.g., (SIZE(14)) 1940 from the example, may either be included in the syntax 1941 definition, if one is specified, or textually in the 1942 descriptive text. This avoids the problem of always having 1943 to specify a PERMITTED VALUES clause in the class template 1944 to constrain the values, or value range, of an attribute 1945 derived from a generic attribute type. The latter use of 1946 PERMITTED VALUES is recommended only for special cases where 1947 additional special constraints are to be applied. 1949 3.3 POST-TRANSLATION PROCEDURES 1951 Post-translation procedures generally include manual 1952 checking of the BEHAVIOUR clause text for proper behaviour 1953 definitions, the addition of information concerning 1954 variables for creation and deletion in the case of NAME 1955 BINDING templates, and the creation of name bindings for 1956 placing the derived ISO/CCITT objects into the containment 1957 hierarchy. Also, ATTRIBUTE templates must be created for the 1958 naming attributes assigned to the derived ISO/CCITT object 1959 classes. 1961 DRAFT February, 1994 1963 Post-translation of the property-label is required for 1964 attributes derived from Internet objects used in conceptual 1965 table entry creation and deletion. 1967 Post-translation may also be required for the ASN.1 module 1968 created during the translation process. 1970 3.3.1 Post-translation of BEHAVIOUR Cause 1972 The SNMP and SNMPv2 text descriptions often contain 1973 SNMP/SNMPv2 protocol, or SMI, relevant information that is 1974 inappropriate for an ISO/CCITT object class or attribute; 1975 such text shall be removed or properly modified. 1977 For BEHAVIOUR clauses in NAME BINDING templates, the 1978 behaviour of the object relative to creation and deletion, 1979 and any constraints that pertain, shall be explained, 1980 especially if the action causes an effect on the resource, 1981 e.g., deletion of a transport connection object may cause 1982 the transport connection to be terminated. 1984 The scannable structures within the BEHAVIOUR shall be 1985 checked for completeness and missing fields filled in. 1987 3.3.2 Creation of NAME BINDING Templates 1989 The ISO/CCITT name bindings for object classes to be bound 1990 into the naming hierarchy described in section 2.2.2 are 1991 created by filling in the GDMO template defined below. 1993 ||"NB" NAME BINDING 1994 SUBORDINATE OBJECT CLASS 1995 AND SUBCLASSES; 1996 NAMED BY SUPERIOR OBJECT CLASS 1997 AND SUBCLASSES; 1998 WITH ATTRIBUTE 1999 || "Id"; 2000 BEHAVIOUR 2001 || "Behaviour" 2002 BEHAVIOUR 2003 DEFINED AS !!;; 2004 [CREATE WITH-AUTOMATIC-INSTANCE-NAMING, WITH-REFERENCE- 2005 OBJECT;] 2006 [DELETE DELETES-CONTAINED-OBJECTS;] 2007 REGISTERED AS { }; 2009 -- The combination of the 2010 subordinate and superior managed object class reference 2011 labels separated by a hyphen. An example of the resulting 2012 label is: ip-systemNB. 2014 DRAFT February, 1994 2016 -- The reference label of the 2017 superior object class in the naming hierarchy. 2019 Table entry object classes, derived from conceptual table 2020 entries, have the object class derived from the group in 2021 which they are contained as their superior. One way to 2022 determine the group is to use the structure of the OID for 2023 the table entry object class, i.e., it contains the internet 2024 specific portion of the OID for the group. However, table 2025 entry object classes derived from OBJECT-TYPES that contain 2026 an AUGMENTS clause have the table entry object class derived 2027 from the OBJECT-TYPE referenced in the AUGMENTS clause as 2028 their superior. 2030 -- If required, the behaviour clause shall 2031 describe any conditions, beyond the superior versus 2032 subordinate relationship, concerning the creation or 2033 deletion of the object relative to the existence of other 2034 objects, or attribute values in other objects. 2036 To facilitate parsing of BEHAVIOUR clauses for name 2037 bindings, the following scannable structure shall be used 2038 (the [] indicate optional constructs, keywords must be in 2039 caps, keywords shall be excluded from the descriptive text, 2040 keywords shall appear in the order illustrated below): 2042 [BEGINPARSE 2043 [REFERENCE !! 2044 !!;] 2047 [DESCRIPTION !! 2048 !!;] 2050 [INDEX 2051 [IMPLIED] || "." 2052 || 2053 [,[IMPLIED] || 2054 "." || ]*;] 2055 [AUGMENTS 2056 ;] 2057 [DELETEATT 2058