idnits 2.17.1 draft-kchapman-perfhist-sup-TC-00.txt: ** The Abstract section seems to be numbered 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. ** 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. ** Bad filename characters: the document name given in the document, 'draft-kchapman-perfhist-sup-TC-00', contains other characters than digits, lowercase letters and dash. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [4], [6], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 143 has weird spacing: '... octet conte...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1998) is 9417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 219, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 228, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 234, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 239, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 244, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1902 (ref. '7') (Obsoleted by RFC 2578) ** Downref: Normative reference to an Historic RFC: RFC 1157 (ref. '9') ** Obsolete normative reference: RFC 1905 (ref. '10') (Obsoleted by RFC 3416) Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Textual Conventions for MIB Modules Using Performance History 2 Based on 24 Hour Intervals 4 July 1998 6 8 Ken Chapman 9 Argon Networks, Inc. 10 25 Porter Road 11 Littleton, MA 01460 13 kchapman@argon.com 15 1. 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 a "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 ftp.ietf.org (US East Coast), nic.nordu.net (Europe), 30 ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). 32 2. Abstract 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 tectual conventions used to 37 define 24 hour inteval counters which supplement the interval counters 38 defined in the 15 Minute Based Performance History TCs MIB [1]. See for example the DS1/E1, DS2/E2, 40 DS3/E3 and SONET/SDH supplemental MIBs [2][3][4]. This MIB is designed 41 to provide support for ASNI T1.231-1997 [6] 1-day registers. 43 This memo does not specify a standard for the Internet community. 45 3. Overview 47 This document supplements . In 48 particular, it provides support for MIB objects that support the 49 previous 1-day register and recent 1-day registers as defined in ASNI 50 T1.231-1997, clause 9.1.2.1. 52 4. Definitions 54 PerfHistSup-TC DEFINITIONS ::= BEGIN 56 IMPORTS 57 MODULE-IDENTITY 58 FROM SNMPv2-SMI 59 mib-2, Unsigned32 60 FROM SNMPv2C-SMI 61 TEXTUAL-CONVENTION 62 FROM SNMPv2-TC; 64 perfHistSupTC MODULE-IDENTITY 65 LAST-UPDATED "9806252237Z" -- 25-Jun-98 6:37 PM EDT 66 ORGANIZATION "Argon Networks, Inc." 67 CONTACT-INFO 68 " Ken Chapman 69 Postal: Argon Networks, Inc. 70 25 Porter Road 71 Littleton, MA 01460 72 USA 73 Phone: +1 978 486 0665 74 Fax: +1 978 486 9379 75 Email: KChapman@Argon.com" 76 DESCRIPTION 77 "This MIB module provides Textual Conventions to be used by 78 systems supporting 1-day (24 hour) based performance history 79 counts." 80 ::= { mib-2 xx } 82 -- ********************************************************************* 83 -- Note to RFC editor: Assign a number for xx from IANA when publishing 84 -- this MIB as an RFC. 86 -- ********************************************************************* 88 -- Use of the Textual Conventions defined in this MIB module assumes the 89 -- following: 90 -- 91 -- * The agent supports 1-day based history counters. 92 -- * The agent is capable of keeping a history of n intervals of 1-day 93 -- performance data. The value of n may be limited by the media- 94 -- specific MIB module but shall be 1 < n =< 32, where n = 1 95 -- represents the current 1-day interval, n = 2 represents the 96 -- previous 1-day interval, n = 3 represents the newest recent 1-day 97 -- interval and n = 32 represents the oldest recent 1-day interval. 98 -- * The agent will keep the following objects per interface: 99 -- 100 -- xyzDayTimeElapsed OBJECT-TYPE 101 -- SYNTAX INTEGER (0..86409) 102 -- MAX-ACCESS read-only 103 -- STATUS current 104 -- DESCRIPTION 105 -- "The number of seconds that have elapsed since the beginning 106 -- of the current 1-day perfromance history interval." 107 -- ::= { xxx } 108 -- 109 -- xyzValidDays OBJECT-TYPE 110 -- SYNTAX INTEGER (0..) 111 -- MAX-ACCESS read-only 112 -- STATUS current 113 -- DESCRIPTION 114 -- "The oldest interval number for which data is available. The 115 -- value will normally be n, where n is the number of 1-day 116 -- intervals supported by the agent. However, some intervals 117 -- will not be available if the interface was brought online 118 -- within the last n days, in which case the value will be the 119 -- number of 1-day intervals since the interface has been online 120 -- (including the current interval). It is also possible that 121 -- some intervals are unavailable in the case where the agent is 122 -- a proxy." 123 -- ::= { xxx } 124 -- 125 -- xyzInvalidDays OBJECT-TYPE 126 -- SYNTAX INTEGER (0..) 127 -- MAX-ACCESS read-only 128 -- STATUS current 129 -- DESCRIPTION 130 -- "The number of intervals supported by the agent for which no 131 -- data is available for the interface." 132 -- ::= { xxx } 133 HourOfDay ::= TEXTUAL-CONVENTION 134 DISPLAY-HINT "1d1a1d:1d" 135 STATUS current 136 DESCRIPTION 137 "A time-of-day specification at an hour boundary. This is used 138 to specify an event that is to occure at precisely the same time 139 each day, on the hour; for example, the time to save an 140 interface's current 1-day counter as the previous 1-day counter 141 and reset the current 1-day counter to zero. 143 octet contents range 144 ----- -------- ----- 145 1 hour 0..23 146 2 direction from UTC '+' | '-' 147 3 hours from UTC 0..11 148 4 minutes from UTC 0..59 150 For example, 1 PM EDT would be displayed as: 152 13-4:0 154 Note that if only local time is known, then timezone information 155 (octes 2-4) is not present." 156 SYNTAX OCTET STRING (SIZE (1 | 4)) 158 PerfDayCount ::= TEXTUAL-CONVENTION 159 STATUS current 160 DESCRIPTION 161 "A counter associated with interface performance measurements in 162 a 1-day (24 hour) measurement interval. This data type can be 163 used for either a current interval or a pervious or recent 1-day 164 interval. 166 For a current interval, the value of this counter starts at zero 167 and is increased when associated events occur, until the end of 168 the 1-day interval. At that time the value of the counter is 169 stored in the first 1-day history interval (if supported), and 170 the current interval counter is restarted at zero. Unlike a 171 counter32, this counter shall not wrap; it shall latch if it 172 reachs its maximum value (4294967295 decimal) and it shall not 173 change until it is reset (e.g. at the beginning of a new 174 interval). 176 In a system supporting a history of n intervals, where 177 DayCount(1) and DayCount(n) contain the most and least recent 178 historic intervals respectively, the following applies at the 179 end of a 24 hour interval: 181 - discard the value of DayCount(n) 182 - the value of DayCount(i) becomes that of 183 DayCount(i-1) for n >= i > 1 184 - the value of DayCount(1) becomes the value of the current 185 interval count 186 - the current interval count is restarted at zero. 188 In the case where the agent has no data available for a 189 particular interval the corresponding object instance is not 190 available and upon a retrieval request a corresponding error 191 message (noSuch*) shall be returned." 192 REFERENCE "ANSI T1.231-1997 clauses 9.1.2.1 and 9.1.2.3." 193 SYNTAX Unsigned32 195 END 197 5. Acknowledgments 199 This document is not a product of an IETF Working Group. 201 6. References 203 [1] Fowler, D., "Definitions of Managed Objects for the DS1, E1, DS2 204 and E2 Interface Types", , 205 Newbridge Networks, Wed Feb 11 19:26:27 EST 1998. 207 [2] Greene, M., "Definitions of Supplemental Managed Objects for the 208 DS1, E1, DS2 and E2 Interface Types", , Ascom Nexion, May 31, 1996. 211 [3] Fowler, D., "Definitions of Managed Objects for the DS3/E3 212 Interface Type", , Newbridge 213 Networks, Tue Feb 24 09:53:17 EST 1998. 215 [4] Gonda, R., "Definitions of Supplemental Managed Objects for the 216 DS3/E3 Interface Type", , 217 Cascade Communication Corporation, Thu Oct 17 14:05:52 EDT 1996. 219 [5] Tesink, K., "Definitions of Managed Objects for the SONET/SDH 220 Interface Type", , Bell 221 Communications Research, August 26, 1996. 223 [6] ANSI Standards Committee T1 - Telecommunications, "American 224 National Standard for Telecommunications -- Digital Hierarchy -- 225 Layer 1 In-Service Digital Transmission Performance Monitoring", 226 ANSI T1.231-1997, October 20, 1997. 228 [7] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 229 S. Waldbusser, "Structure of Management Information for Version 2 230 of the Simple Network Management Protocol (SNMPv2)", RFC1902, SNMP 231 Research,Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 232 International Network Services, January 1996. 234 [8] McCloghrie, K., and M. Rose, Editors, "Management Information Base 235 for Network Management of TCP/IP-based internets: MIB-II", STD 17, 236 RFC 1213, Hughes LAN Systems, Performance Systems International, 237 March 1991. 239 [9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 240 Management Protocol", RFC 1157, SNMP Research, Performance Systems 241 International, Performance Systems International, MIT Laboratory 242 for Computer Science, May 1990. 244 [10] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and 245 S. Waldbusser, "Protocol Operations for Version 2 of the Simple 246 Network Management Protocol (SNMPv2)", RFC1905, SNMP Research,Inc., 247 Cisco Systems, Inc., Dover Beach Consulting, Inc., International 248 Network Services, January 1996. 250 7. Security Considerations 252 Security issues are not discussed in this memo. 254 8. Author's Address 256 Ken Chapman 257 Argon Networks, Inc. 258 25 Porter Road 259 Littleton, MA 01460 260 Phone: (978) 486-0665 x146 261 EMail: kchapman@argon.com 263 Table of Contents 265 1 Status of this Memo ............................................. 1 266 2 Abstract ........................................................ 1 267 3 Overview ........................................................ 2 268 4 Definitions ..................................................... 2 269 5 Acknowledgments ................................................. 5 270 6 References ...................................................... 5 271 7 Security Considerations ......................................... 6 272 8 Author's Address ................................................ 6