idnits 2.17.1 draft-schoenw-snmpv2-mib-ext-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-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 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 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.) ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 November 1998) is 9291 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) No issues found here. Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Juergen Schoenwaelder 3 Internet-Draft TU Braunschweig 4 Expires May 1999 18 November 1998 6 DateAndTime Extension for the MIB-2 system Group 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. Please send comments to 29 the SNMP Version 3 Working Group, . 31 Abstract 33 This memo defines an extension of the Management Information Base 34 (MIB) for Version 2 of the Simple Network Management Protocol 35 (SNMPv2) as published in RFC 1907. In particular, it defines an 36 object which allows to read and modify the notion of wall clock time 37 accessible by an SNMP agent. The addition of this object allows to 38 use the DateAndTime textual convention as defined in RFC 1903 even on 39 devices that do not have a real-time clock. 41 Table of Contents 43 1 Introduction ................................................. 2 44 2 Problem ...................................................... 2 45 3 Solution ..................................................... 3 46 4 Definitions .................................................. 4 47 5 Acknowledgments .............................................. 4 48 6 Authors' Address ............................................. 5 50 1. Introduction 52 This memo defines an extension of the Management Information Base 53 (MIB) for Version 2 of the Simple Network Management Protocol 54 (SNMPv2) as published in RFC 1907. In particular, it defines an 55 object which allows to read and modify the notion of wall clock time 56 accessible by an SNMP agent. The addition of this object allows to 57 use the DateAndTime textual convention as defined in RFC 1903 even on 58 devices that do not have a real-time clock. 60 2. Problem 62 Many MIBs require to time-stamp events. This is usually accomplished 63 by using either the TimeStamp or the DateAndTime textual convention 64 defined in RFC 1903. Both approaches have strength and weaknesses: 66 TimeStamp: 68 + One advantage of a TimeStamp is that sysUpTime is always locally 69 available, even on devices that have no notion of wall clock 70 time. 72 + Further, sysUpTime is supported by the AgentX sub-agent protocol 73 defined in RFC 2257 since it is exchanged in master/sub-agent 74 message exchanges. 76 - A TimeStamp time-stamp is based on sysUpTime and becomes 77 ambiguous after some time. 79 - A TimeStamp has itself no meaning - a manager must also retrieve 80 the current value of sysUpTime and do calculations against its 81 local notion of date and time in order to calculate when an 82 event happened. 84 - A TimeStamp can not be used to time-stamp events that have 85 occurred prior to the initialization of the network management 86 of the system was last re-initialized. 88 - TimeStamps reported by sub-agents can be ambiguous if the master 89 agent has been restarted. Resetting or recalculating time stamps 90 on such an event can be expensive. 92 DateAndTime: 94 + DateAndTime time-stamps report the time an event occurred in the 95 local notion of date and time. A DateAndTime time-stamp is 96 therefore self-contained. 98 + DateAndTime time-stamps are globally unambiguous if they contain 99 the offset from UTC. DateAndTime time-stamps are still locally 100 unambiguous if they miss the offset from UTC. 102 + DateAndTime time-stamps can describe events that have occurred 103 prior to the initialization of the network management subsystem. 105 + DateAndTime time-stamps do not require any special attention in 106 a sub-agent environment when the master agent restarts. 108 - A DateAndTime time-stamp is slightly longer than a TimeStamp 109 time-stamp. 111 - DateAndTime time-stamps requires that the agent has a notion of 112 wall clock time. This is generally not supported on devices 113 without a battery powered clock or devices that do not support 114 time protocols such as NTP. A MIB which records a time-stamp as 115 a DateAndTime value can thus not me implemented on such a 116 device. 118 - The AgentX sub-agent protocol does not allow to share the notion 119 of DateAndTime between sub-agents. The notion of DateAndTime 120 must therefore be exchanged with other local mechanisms. (This 121 is typically a service of the underlying operating system). 123 3. Solution 125 The sysDateAndTime object defined below solves the main problem with 126 DateAndTime time-stamps by providing a mechanism which allows to 127 configure the date and time with an SNMP set operations. This enables 128 devices without a battery powered clock and without time protocols to 129 have a notion of wall clock time. 131 In addition, the sysDateAndTime object allows a manager to read the 132 remote notion of the current date and time in order to detect clock 133 screw or mis-configurations. This can be of great help when 134 interpreting DateAndTime time-stamp values from devices that have 135 mis-configured clocks. 137 Objects that record a time-stamp can now be written similar to the 138 following example: 140 smRunStartTime OBJECT-TYPE 141 SYNTAX DateAndTime 142 MAX-ACCESS read-only 143 STATUS current 144 DESCRIPTION 145 "The date and time when the execution started. The value 146 '0000000000000000'H is returned if the script has not 147 started yet or if the current date and time is not (yet) 148 known by the agent." 149 DEFVAL { '0000000000000000'H } 150 ::= { smRunEntry 3 } 152 4. Definitions 154 SNMPv2-MIB-EXT-01 DEFINITIONS ::= BEGIN 156 IMPORTS 157 MODULE-IDENTITY, OBJECT-TYPE, 158 FROM SNMPv2-SMI 159 system 160 FROM SNMPv2-MIB; 162 -- This module is not valid SMIv2. The author left out all the 163 -- administrative stuff in order to keep it small. 165 sysDateAndTime OBJECT-TYPE 166 SYNTAX DateAndTime 167 MAX-ACCESS read-write 168 STATUS current 169 DESCRIPTION 170 "The locally known date and time. The value '0000000000000000'H 171 is returned on systems without a local clock until the local 172 date and time is learned, either from a network time protocol 173 such as NTP or a management set operations on this object." 174 ::= { system 9 } 176 END 178 5. Acknowledgments 180 The definition of the sysDateAndTime object was inspired by a remark 181 Eamonn McManus about implementing 182 DateAndTime objects of the Script MIB in an embedded system without a 183 hardware clock. 185 The comparison of the advantages and disadvantages of the frequently 186 used TimeStamp mechanisms was inspired by discussions about the 187 TimeStamp textual convention in the SMI design team and on the SNMPv3 188 mailing list. 190 6. Authors' Address 192 Juergen Schoenwaelder Email: schoenw@ibr.cs.tu-bs.de 193 TU Braunschweig Tel: +49 531 391-3283 194 Bueltenweg 74/75 195 38106 Braunschweig 196 Germany