idnits 2.17.1 draft-bierman-entmib-compid-00.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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (30 July 1997) is 9760 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) ** Obsolete normative reference: RFC 1902 (ref. '1') (Obsoleted by RFC 2578) ** Obsolete normative reference: RFC 1903 (ref. '3') (Obsoleted by RFC 2579) ** Obsolete normative reference: RFC 1905 (ref. '4') (Obsoleted by RFC 3416) ** Obsolete normative reference: RFC 1904 (ref. '5') (Obsoleted by RFC 2580) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '6') ** Obsolete normative reference: RFC 2037 (ref. '7') (Obsoleted by RFC 2737) Summary: 16 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 3 Entity MIB Extensions for Persistent Component Identification 5 30 July 1997 7 Andy Bierman 8 Cisco Systems Inc. 9 abierman@cisco.com 11 Keith McCloghrie 12 Cisco Systems Inc. 13 kzm@cisco.com 15 Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its areas, and 19 its working groups. Note that other groups may also distribute working 20 documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet- Drafts as reference material 25 or to cite them other than as ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 29 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 1. Introduction 34 This memo defines an experimental portion of the Management Information 35 Base (MIB) for use with network management protocols in the Internet 36 community. In particular, it describes managed objects used for 37 managing physical topology identification and discovery. 39 Draft Entity MIB Extensions July 1997 41 2. The SNMP Network Management Framework 43 The SNMP Network Management Framework presently consists of three major 44 components. They are: 46 o the SMI, described in RFC 1902 [1], - the mechanisms used for 47 describing and naming objects for the purpose of management. 49 o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed objects 50 for the Internet suite of protocols. 52 o the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol for 53 accessing managed information. 55 Textual conventions are defined in RFC 1903 [3], and conformance 56 statements are defined in RFC 1904 [5]. 58 The Framework permits new objects to be defined for the purpose of 59 experimentation and evaluation. 61 This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A 62 semantically identical MIB conforming to the SNMPv1 SMI can be produced 63 through the appropriate translation. 65 2.1. Object Definitions 67 Managed objects are accessed via a virtual information store, termed the 68 Management Information Base or MIB. Objects in the MIB are defined 69 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 70 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 71 an administratively assigned name. The object type together with an 72 object instance serves to uniquely identify a specific instantiation of 73 the object. For human convenience, we often use a textual string, 74 termed the descriptor, to refer to the object type. 76 3. Overview 78 There is a need for a standardized way of providing non-volatile, 79 administratively assigned identifiers for physical components 80 represented with the Entity MIB [7]. 82 Draft Entity MIB Extensions July 1997 84 This document defines extensions to the Entity MIB to address this need. 86 4. Entity MIB Extensions 88 4.1. MIB Structure 90 The Entity Extensions MIB contains a single group: 92 - Entity Physical Extensions Group 94 4.1.1. Entity Physical Extensions Group 96 This group contains a single table, called the entPhysicalXTable, which 97 augments the entPhysicalTable. Each entPhysicalXEntry provides a 98 DisplayString which can be used by an NMS as a non-volatile alias string 99 for the physical component. 101 4.2. Definitions 103 ENTITY-EXTENSIONS-MIB DEFINITIONS ::= BEGIN 105 IMPORTS 106 MODULE-IDENTITY, OBJECT-TYPE 107 FROM SNMPv2-SMI 108 DisplayString 109 FROM SNMPv2-TC 110 MODULE-COMPLIANCE, OBJECT-GROUP 111 FROM SNMPv2-CONF 112 entPhysicalEntry, entityMIBObjects, entityCompliances, 113 entityGroups, entityPhysicalGroup 114 FROM ENTITY-MIB; 116 entityXMIB MODULE-IDENTITY 117 LAST-UPDATED "9703170000Z" 118 ORGANIZATION "Cisco Systems, Inc." 119 CONTACT-INFO 120 "Andy Bierman 121 Cisco Systems Inc. 122 170 West Tasman Drive 123 San Jose, CA 95134 124 408-527-3711 125 abierman@cisco.com 127 Draft Entity MIB Extensions July 1997 129 Keith McCloghrie 130 Cisco Systems Inc. 131 170 West Tasman Drive 132 San Jose, CA 95134 133 408-526-5260 134 kzm@cisco.com" 135 DESCRIPTION 136 "The extension MIB module for physical entity information." 137 ::= { experimental xx } 138 -- *********************************************************** 139 -- 140 -- E N T I T Y P H Y S I C A L E X T E N S I O N S 141 -- 142 -- *********************************************************** 144 -- entPhysicalTable extensions 146 entityPhysicalX OBJECT IDENTIFIER ::= { entityMIBObjects 5 } 148 entPhysicalXTable OBJECT-TYPE 149 SYNTAX SEQUENCE OF EntPhysicalXEntry 150 MAX-ACCESS not-accessible 151 STATUS current 152 DESCRIPTION 153 "This table contains one row per physical element 154 represented in the entPhysicalTable." 155 ::= { entityPhysicalX 1 } 157 entPhysicalXEntry OBJECT-TYPE 158 SYNTAX EntPhysicalXEntry 159 MAX-ACCESS not-accessible 160 STATUS current 161 DESCRIPTION 162 "Information about a particular physical entity. 164 Each entry provides an object (entPhysicalAlias) to help an 165 NMS uniquely identify a physical entity with a DisplayString 166 stored in non-volatile and re-created after a reboot." 167 AUGMENTS { entPhysicalEntry } 168 ::= { entPhysicalXTable 1 } 170 EntPhysicalXEntry ::= SEQUENCE { 171 entPhysicalAlias DisplayString 172 } 173 Draft Entity MIB Extensions July 1997 175 entPhysicalAlias OBJECT-TYPE 176 SYNTAX DisplayString (SIZE (0..48)) 177 MAX-ACCESS read-write 178 STATUS current 179 DESCRIPTION 180 "This object is an 'alias' name for the physical entity as 181 specified by a network manager, and provides a non-volatile 182 'handle' for the physical entity. 184 On the first instantiation of an physical entity, the value 185 of entPhysicalAlias associated with that entity is the 186 zero-length string. As and when a value is written into an 187 instance of entPhysicalAlias through a network management 188 set operation, then the agent must retain the supplied value 189 in the entPhysicalAlias instance associated with the same 190 physical entity for as long as that entity remains 191 instantiated, including across all re- 192 initializations/reboots of the network management system, 193 including those which result in a change of the physical 194 entity's entPhysicalIndex value." 195 ::= { entPhysicalXEntry 1 } 197 -- conformance information 198 -- compliance statements 200 entityXCompliance MODULE-COMPLIANCE 201 STATUS current 202 DESCRIPTION 203 "The compliance statement for SNMP entities which implement 204 the entPhysicalXTable Entity MIB extension." 205 MODULE -- this module 206 MANDATORY-GROUPS { 207 entityPhysicalGroup, 208 entityPhysicalXGroup 209 } 210 ::= { entityCompliances 2 } 212 -- MIB groupings 213 entityPhysicalXGroup OBJECT-GROUP 214 OBJECTS { 215 entPhysicalAlias 216 } 217 STATUS current 218 DESCRIPTION 220 Draft Entity MIB Extensions July 1997 222 "The collection of objects which are used to represent 223 extended physical topology information for which a single 224 agent provides management information." 225 ::= { entityGroups 5 } 227 END 228 Draft Entity MIB Extensions July 1997 230 5. References 232 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 233 S. Waldbusser, "Structure of Management Information for version 2 234 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 235 January 1996. 237 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 238 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 239 RFC 1213, Hughes LAN Systems, Performance Systems International, 240 March 1991. 242 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 243 S. Waldbusser, "Textual Conventions for version 2 of the Simple 244 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 246 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 247 S. Waldbusser, "Protocol Operations for version 2 of the Simple 248 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 250 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 251 S. Waldbusser, "Conformance Statements for version 2 of the Simple 252 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 254 [6] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 255 Management Protocol", RFC 1157, SNMP Research, Performance Systems 256 International, MIT Laboratory for Computer Science, May 1990. 258 [7] McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037, 259 Cisco Systems, October 1996. 261 Draft Entity MIB Extensions July 1997 263 6. Security Considerations 265 Security issues are not discussed in this memo. 267 7. Author's Address 269 Andy Bierman 270 Cisco Systems, Inc. 271 170 West Tasman Drive 272 San Jose, CA 95134 273 Phone: 408-527-3711 274 Email: abierman@cisco.com 276 Keith McCloghrie 277 Cisco Systems, Inc. 278 170 West Tasman Drive 279 San Jose, CA 95134 280 Phone: 408-526-5260 281 Email: kzm@cisco.com 283 Draft Entity MIB Extensions July 1997 285 Table of Contents 287 1 Introduction .................................................... 1 288 2 The SNMP Network Management Framework ........................... 2 289 2.1 Object Definitions ............................................ 2 290 3 Overview ........................................................ 2 291 4 Entity MIB Extensions ........................................... 3 292 4.1 MIB Structure ................................................. 3 293 4.1.1 Entity Physical Extensions Group ............................ 3 294 4.2 Definitions ................................................... 3 295 5 References ...................................................... 7 296 6 Security Considerations ......................................... 8 297 7 Author's Address ................................................ 8