idnits 2.17.1 draft-presuhn-referent-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (27 October 2002) is 7849 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) == Missing Reference: 'RFC2571' is mentioned on line 68, but not defined ** Obsolete undefined reference: RFC 2571 (Obsoleted by RFC 3411) == Missing Reference: 'RFC2573' is mentioned on line 119, but not defined ** Obsolete undefined reference: RFC 2573 (Obsoleted by RFC 3413) == Missing Reference: 'VACM' is mentioned on line 153, but not defined == Unused Reference: 'RFC1155' is defined on line 163, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 167, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 170, but no explicit reference was found in the text == Unused Reference: 'RFC2578' is defined on line 173, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 178, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 182, but no explicit reference was found in the text == Unused Reference: 'OpsReq' is defined on line 186, but no explicit reference was found in the text == Unused Reference: 'ConfBcp' is defined on line 190, but no explicit reference was found in the text == Unused Reference: 'RFC2575' is defined on line 194, but no explicit reference was found in the text == Unused Reference: 'RFC2574' is defined on line 198, but no explicit reference was found in the text == Unused Reference: 'RFC3231' is defined on line 206, but no explicit reference was found in the text == Unused Reference: 'RFC3014' is defined on line 210, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-snmpconf-bcp-07 -- Obsolete informational reference (is this intentional?): RFC 2575 (Obsoleted by RFC 3415) -- Obsolete informational reference (is this intentional?): RFC 2574 (Obsoleted by RFC 3414) Summary: 5 errors (**), 0 flaws (~~), 18 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Presuhn 3 Internet Draft BMC Software, Inc. 4 Expires: April 27 October 2002 6 Referential Integrity Considerations 7 in Management Information Base (MIB) Design 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 Copyright Notice 31 Copyright (C) The Internet Society (2002). All Rights Reserved. 33 Abstract 35 This memo identifies some of referential integrity considerations of 36 which management information base (MIB) designers should be aware. 37 It is intended to promote discussion and the identification of 38 additional related issues. 40 Comments are welcomed, from the Operations and Management Area in 41 general, from MIB writers, and from participants in the sming and eos 42 working groups and the xmlconf BOF in particular. Please send 43 comments to the mibs@ops.ietf.org mailing list. 45 Table of Contents 47 1. Introduction ................................................ 3 48 2. Notice on Intellectual Property ............................. 4 49 3. Security Considerations ..................................... 5 50 4. References .................................................. 5 51 4.1. Informative References .................................... 5 52 4.2. Normative References ...................................... 6 53 5. Author's Address ............................................ 6 54 6. Full Copyright Statement .................................... 6 56 1. Introduction 58 This memo identifies some of referential integrity considerations of 59 which management information base (MIB) deisgners should be aware. 60 It is intended to promote discussion and the identification of 61 additional related issues. 63 This initial draft is just a strawman, so we'll have something to 64 discuss. 66 Referential integrity, a concept from the world of relational 67 databases, is useful in the design and use of MIBs as well. In 68 [RFC2571] how instances of management information are named is 69 spelled out in detail. When we look at how MIBs and management 70 applications handle references, we see several potential sources of 71 problems: 73 - In some MIBs, only the human-readable decription reveals that 74 two tables share a common index; 76 - When two tables share one or more common indexes, the nature of 77 the relationship between them, if it is spelled out at all, is 78 not machine-readable; 80 - When RowPointers and related textual conventions are used, they 81 are frequently used without an associated ContextName object, 82 limiting the scope of the relationship; 84 - In a few notorious cases, such as ifIndex, instance names are 85 not guaranteed to be stable across reboots. 87 The lack of specification (or, in some cases, the over-specification) 88 of inter-table relationships causes much consternation during the 89 processes of row creation and deletion. 91 However, instance name instability causes the most grief when it 92 interacts with other objects which have a requirement for persistance 93 of some kind, whether within the managed deviced or across the larger 94 systems which is the network. It impacts not only MIBs with shared 95 indexes or row pointers, but also things like disman script / 96 expression MIBs, configuration file formats, and system configuration 97 version management. 99 A family of problems that has surfaced in several MIBs arises from 100 the need to ensure that the references (e.g., RowPointers and 101 indexes) to persistent data remain consistent across reboots. An 102 example of where things become problematic is the use of ifIndex, 103 which is not guaranteed to keep its value across reboots. In 104 addition to keeping direct references consistent, there are also 105 cases where keeping references stable across reboots is a 106 requirement. For example, a VACM access control policy could be 107 subverted if the indexes don't remain the same. 109 A similar problem results in MIBs that use "profiles" to reduce the 110 amount of configuration data. The ADSL extension MIB encountered 111 this problem. The solution adopted there, to require implementations 112 to adjust their indexes to match whatever happened to ifIndex, is not 113 terribly satisfying. First, it interacts badly with VACM. Secondly, 114 it requires configuration management applications to somehow be able 115 to figure out whether two or more configurations, in which the 116 indexes may have all been renumbered, are equivalent. (This can be 117 done, but it's not cheap.) 119 The problem only gets worse with things like scripts, the [RFC2573] 120 notification filtering mechanism, thresholds, alarms, and common log 121 management use cases, 123 Consequently, this memo recommends that objects like ifIndex be 124 implemented so that their values do not change across reboots, and 125 that in future MIB design the needs of configuration management 126 systems, scripts, and so on be taken into account. 128 2. Notice on Intellectual Property 130 The IETF takes no position regarding the validity or scope of any 131 intellectual property or other rights that might be claimed to 132 pertain to the implementation or use of the technology described in 133 this document or the extent to which any license under such rights 134 might or might not be available; neither does it represent that it 135 has made any effort to identify any such rights. Information on the 136 IETF's procedures with respect to rights in standards-track and 137 standards-related documentation can be found in BCP-11. Copies of 138 claims of rights made available for publication and any assurances of 139 licenses to be made available, or the result of an attempt made to 140 obtain a general license or permission for the use of such 141 proprietary rights by implementors or users of this specification can 142 be obtained from the IETF Secretariat. 144 The IETF invites any interested party to bring to its attention any 145 copyrights, patents or patent applications, or other proprietary 146 rights which may cover technology that may be required to practice 147 this standard. Please address the information to the IETF Executive 148 Director. 150 3. Security Considerations 152 Needless to say, there are lots of security considerations here. The 153 index structure of the view-based access control model [VACM] 154 reflects the naming of the resources to which access is being 155 controlled. Consequently, if resource names change across reboots, 156 the semantics of a stored access control configuration would not be 157 preserved. 159 4. References 161 4.1. Informative References 163 [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification 164 of Management Information for TCP/IP-based Internets", STD 165 16, RFC 1155, May 1990. 167 [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple 168 Network Management Protocol", STD 15, RFC 1157, May 1990. 170 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 171 16, RFC 1212, March 1991. 173 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 174 Rose, M., and S. Waldbusser, "Structure of Management 175 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 176 1999. 178 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 179 Rose, M., and S. Waldbusser, "Textual Conventions for 180 SMIv2", STD 58, RFC 2579, April 1999. 182 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 183 Rose, M., and S. Waldbusser, "Conformance Statements for 184 SMIv2", STD 58, RFC 2580, April 1999. 186 [OpsReq] Woodcock, B., "Operator Requirements of Infrastructure 187 Management Methods", draft-ops-operator-req-mgmt-02.txt, 188 February 2002. 190 [ConfBcp] MacFaden, M., Saperia, J. and W. Tackabury, "Configuring 191 Networks and Devices With SNMP", draft-ietf-snmpconf- 192 bcp-07.txt, November 2001. 194 [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based 195 Access Control Model (VACM) for the Simple Network 196 Management Protocol (SNMP)", RFC 2575, April 1999. 198 [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model 199 (USM) for version 3 of the Simple Network Management 200 Protocol (SNMPv3)", RFC 2574, April 1999. 202 [RFC3231] Levi, D. and J. Schoenwaelder, "Definitions of Managed 203 Objects for Scheduling Management Operations", RFC 3231, 204 January 2002. 206 [RFC3231] Levi, D. and J. Schoenwaelder, "Definitions of Managed 207 Objects for Scheduling Management Operations", RFC 3231, 208 January 2002. 210 [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, November 211 2000. 213 4.2. Normative References 215 5. Author's Address 217 Randy Presuhn 218 BMC Software, Inc. 219 2141 North First Street 220 San Jose, CA 95131 221 USA 223 Phone: +1 408 546 1006 224 EMail: randy_presuhn@bmc.com 226 6. Full Copyright Statement 228 Copyright (C) The Internet Society (2002). All Rights Reserved. 230 This document and translations of it may be copied and furnished to 231 others, and derivative works that comment on or otherwise explain it 232 or assist in its implementation may be prepared, copied, published 233 and distributed, in whole or in part, without restriction of any 234 kind, provided that the above copyright notice and this paragraph are 235 included on all such copies and derivative works. However, this 236 document itself may not be modified in any way, such as by removing 237 the copyright notice or references to the Internet Society or other 238 Internet organizations, except as needed for the purpose of 239 developing Internet standards in which case the procedures for 240 copyrights defined in the Internet Standards process must be 241 followed, or as required to translate it into languages other than 242 English. 244 The limited permissions granted above are perpetual and will not be 245 revoked by the Internet Society or its successors or assigns. 247 This document and the information contained herein is provided on an 248 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 249 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 250 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 251 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 252 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.