idnits 2.17.1 draft-bierman-entmib-compid-01.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-26) 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 (18 September 1997) is 9717 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) ** Obsolete normative reference: RFC 1573 (ref. '8') (Obsoleted by RFC 2233) == Outdated reference: A later version (-06) exists of draft-ietf-snmpv3-next-gen-arch-04 Summary: 17 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Draft Entity MIB Extensions September 1997 4 5 Entity MIB Extensions for Persistent Component Identification 7 18 September 1997 9 Andy Bierman 10 Cisco Systems Inc. 11 abierman@cisco.com 13 Keith McCloghrie 14 Cisco Systems Inc. 15 kzm@cisco.com 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 22 documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference material 27 or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 31 Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), 32 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 34 1. Introduction 36 This memo defines an experimental portion of the Management Information 37 Base (MIB) for use with network management protocols in the Internet 38 community. In particular, it describes managed objects used for 39 managing physical topology identification and discovery. 41 Draft Entity MIB Extensions September 1997 43 2. The SNMP Network Management Framework 45 The SNMP Network Management Framework presently consists of three major 46 components. They are: 48 o the SMI, described in RFC 1902 [1], - the mechanisms used for 49 describing and naming objects for the purpose of management. 51 o the MIB-II, STD 17, RFC 1213 [2], - the core set of managed objects 52 for the Internet suite of protocols. 54 o the protocol, RFC 1157 [6] and/or RFC 1905 [4], - the protocol for 55 accessing managed information. 57 Textual conventions are defined in RFC 1903 [3], and conformance 58 statements are defined in RFC 1904 [5]. 60 The Framework permits new objects to be defined for the purpose of 61 experimentation and evaluation. 63 This memo specifies a MIB module that is compliant to the SNMPv2 SMI. A 64 semantically identical MIB conforming to the SNMPv1 SMI can be produced 65 through the appropriate translation. 67 2.1. Object Definitions 69 Managed objects are accessed via a virtual information store, termed the 70 Management Information Base or MIB. Objects in the MIB are defined 71 using the subset of Abstract Syntax Notation One (ASN.1) defined in the 72 SMI. In particular, each object type is named by an OBJECT IDENTIFIER, 73 an administratively assigned name. The object type together with an 74 object instance serves to uniquely identify a specific instantiation of 75 the object. For human convenience, we often use a textual string, 76 termed the descriptor, to refer to the object type. 78 3. Overview 80 There is a need for a standardized way of providing non-volatile, 81 administratively assigned identifiers for physical components 82 represented with the Entity MIB [7]. 84 This document defines extensions to the Entity MIB to address this need. 86 Draft Entity MIB Extensions September 1997 88 4. Entity MIB Extensions 90 4.1. MIB Structure 92 The Entity Extensions MIB contains a single group: 94 - Entity Physical Extensions Group 96 4.1.1. Entity Physical Extensions Group 98 This group contains a single table, called the entPhysicalXTable, which 99 augments the entPhysicalTable. Each entPhysicalXEntry provides a 100 writable string object, 'entPhysicalAlias', which can be used by an NMS 101 as a non-volatile 'alias' (or label) for the physical component. 103 The entPhysicalAlias object is different from the ifAlias version in 104 several ways: 106 - SnmpAdminString SYNTAX 107 The Interfaces MIB [8] version is defined as a DisplayString [3]. 108 The Entity MIB [7] version is defined as an SnmpAdminString [9]. 110 - SIZE (0..32) 111 The maximum length of the entPhysicalAlias string is half that of 112 the ifAlias object. 114 - MIN-ACCESS 115 Maintaining a non-volatile string for every physical component 116 represented in the entPhysicalTable can be costly and unnecessary. 117 An agent may choose to algorithmically generate entPhysicalAlias 118 strings for particular entries (based on the entPhysicalClass 119 value). 121 4.2. Definitions 123 ENTITY-EXTENSIONS-MIB DEFINITIONS ::= BEGIN 125 IMPORTS 126 MODULE-IDENTITY, OBJECT-TYPE 127 FROM SNMPv2-SMI 128 MODULE-COMPLIANCE, OBJECT-GROUP 129 FROM SNMPv2-CONF 130 SnmpAdminString 132 Draft Entity MIB Extensions September 1997 134 FROM SNMP-FRAMEWORK-MIB 135 entPhysicalEntry, entityMIBObjects, entityCompliances, 136 entityGroups, entityPhysicalGroup 137 FROM ENTITY-MIB; 139 entityXMIB MODULE-IDENTITY 140 LAST-UPDATED "9709150000Z" 141 ORGANIZATION "IETF Entity MIB Working Group" 142 CONTACT-INFO 143 "Andy Bierman 144 Cisco Systems Inc. 145 170 West Tasman Drive 146 San Jose, CA 95134 147 408-527-3711 148 abierman@cisco.com 150 Keith McCloghrie 151 Cisco Systems Inc. 152 170 West Tasman Drive 153 San Jose, CA 95134 154 408-526-5260 155 kzm@cisco.com" 156 DESCRIPTION 157 "The extension MIB module for physical entity information." 158 ::= { experimental xx } 160 -- *********************************************************** 161 -- 162 -- E N T I T Y P H Y S I C A L E X T E N S I O N S 163 -- 164 -- *********************************************************** 166 -- entPhysicalTable extensions 168 entityPhysicalX OBJECT IDENTIFIER ::= { entityMIBObjects 5 } 170 entPhysicalXTable OBJECT-TYPE 171 SYNTAX SEQUENCE OF EntPhysicalXEntry 172 MAX-ACCESS not-accessible 173 STATUS current 174 DESCRIPTION 175 "This table contains one row per physical element 176 represented in the entPhysicalTable." 177 ::= { entityPhysicalX 1 } 179 Draft Entity MIB Extensions September 1997 181 entPhysicalXEntry OBJECT-TYPE 182 SYNTAX EntPhysicalXEntry 183 MAX-ACCESS not-accessible 184 STATUS current 185 DESCRIPTION 186 "Information about a particular physical entity." 187 AUGMENTS { entPhysicalEntry } 188 ::= { entPhysicalXTable 1 } 190 EntPhysicalXEntry ::= SEQUENCE { 191 entPhysicalAlias SnmpAdminString 192 } 194 entPhysicalAlias OBJECT-TYPE 195 SYNTAX SnmpAdminString (SIZE (0..32)) 196 MAX-ACCESS read-write 197 STATUS current 198 DESCRIPTION 199 "This object is an 'alias' name for the physical entity as 200 specified by a network manager, and provides a non-volatile 201 'handle' for the physical entity. 203 On the first instantiation of an physical entity, the value 204 of entPhysicalAlias associated with that entity is set to 205 the zero-length string. An agent may instead choose to set 206 the value to a locally unique default value instead of a 207 zero-length string. 209 If write access is implemented for an instance of 210 entPhysicalAlias, and a value is written into the instance, 211 the agent must retain the supplied value in the 212 entPhysicalAlias instance associated with the same physical 213 entity for as long as that entity remains instantiated, 214 including across all re-initializations/reboots of the 215 network management system, including those which result in a 216 change of the physical entity's entPhysicalIndex value." 217 ::= { entPhysicalXEntry 1 } 219 -- conformance information 220 -- compliance statements 222 entityXCompliance MODULE-COMPLIANCE 223 STATUS current 224 DESCRIPTION 225 "The compliance statement for SNMP entities which implement 227 Draft Entity MIB Extensions September 1997 229 the entPhysicalXTable Entity MIB extension." 230 MODULE -- this module 231 MANDATORY-GROUPS { 232 entityPhysicalGroup, 233 entityPhysicalXGroup 234 } 236 OBJECT entPhysicalAlias 237 MIN-ACCESS read-only 238 DESCRIPTION 239 "Write access is required if the associated 240 entPhysicalClass value is equal to 'chassis(3)'. 241 Otherwise, write access is not required." 242 ::= { entityCompliances 2 } 244 -- MIB groupings 245 entityPhysicalXGroup OBJECT-GROUP 246 OBJECTS { 247 entPhysicalAlias 248 } 249 STATUS current 250 DESCRIPTION 251 "The collection of objects which are used to represent 252 extended physical component information for which a single 253 agent provides management information." 254 ::= { entityGroups 5 } 256 END 257 Draft Entity MIB Extensions September 1997 259 5. References 261 [1] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 262 S. Waldbusser, "Structure of Management Information for version 2 263 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, 264 January 1996. 266 [2] McCloghrie, K., and M. Rose, Editors, "Management Information Base 267 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 268 RFC 1213, Hughes LAN Systems, Performance Systems International, 269 March 1991. 271 [3] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 272 S. Waldbusser, "Textual Conventions for version 2 of the Simple 273 Network Management Protocol (SNMPv2)", RFC 1903, January 1996. 275 [4] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 276 S. Waldbusser, "Protocol Operations for version 2 of the Simple 277 Network Management Protocol (SNMPv2)", RFC 1905, January 1996. 279 [5] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 280 S. Waldbusser, "Conformance Statements for version 2 of the Simple 281 Network Management Protocol (SNMPv2)", RFC 1904, January 1996. 283 [6] Case, J., M. Fedor, M. Schoffstall, J. Davin, "Simple Network 284 Management Protocol", RFC 1157, SNMP Research, Performance Systems 285 International, MIT Laboratory for Computer Science, May 1990. 287 [7] McCloghrie, K., Bierman, A., "Entity MIB using SMIv2", RFC 2037, 288 Cisco Systems, October 1996. 290 [8] McCloghrie, K., and Kastenholtz, F., "Interfaces Group Evolution", 291 RFC 1573, Hughes LAN Systems, FTP Software, January 1994. 293 [9] Harrington D., Wijnen, A., "An Architecture for Describing SNMP 294 Management Frameworks", draft-ietf-snmpv3-next-gen-arch-04.txt, 295 Cabletron Systems, IBM T.J. Watson Research, August 1997. 297 Draft Entity MIB Extensions September 1997 299 6. Security Considerations 301 No additional security concerns are introduced due to implementation of 302 this MIB module. Refer to RFC 2037 [7] for information on any security 303 issues related to the Entity MIB. 305 7. Author's Address 307 Andy Bierman 308 Cisco Systems, Inc. 309 170 West Tasman Drive 310 San Jose, CA 95134 311 Phone: 408-527-3711 312 Email: abierman@cisco.com 314 Keith McCloghrie 315 Cisco Systems, Inc. 316 170 West Tasman Drive 317 San Jose, CA 95134 318 Phone: 408-526-5260 319 Email: kzm@cisco.com 321 Draft Entity MIB Extensions September 1997 323 Table of Contents 325 1 Introduction .................................................... 1 326 2 The SNMP Network Management Framework ........................... 2 327 2.1 Object Definitions ............................................ 2 328 3 Overview ........................................................ 2 329 4 Entity MIB Extensions ........................................... 3 330 4.1 MIB Structure ................................................. 3 331 4.1.1 Entity Physical Extensions Group ............................ 3 332 4.2 Definitions ................................................... 3 333 5 References ...................................................... 7 334 6 Security Considerations ......................................... 8 335 7 Author's Address ................................................ 8