--- 1/draft-ietf-2000-issue-04.txt 2007-12-18 18:35:13.000000000 +0100 +++ 2/draft-ietf-2000-issue-05.txt 2007-12-18 18:35:13.000000000 +0100 @@ -1,13 +1,12 @@ - Network Working Group Philip J. Nesser II -draft-ietf-2000-issue-04.txt Nesser & Nesser Consulting +draft-ietf-2000-issue-05.txt Nesser & Nesser Consulting The Internet and the Millennium Problem (Year 2000) Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six @@ -175,22 +174,24 @@ While not a protocol issue, there is a common habit of writing serial numbers for DNS zone files in the form YYXXXXXX. The only real requirement on the serial numbers is that they be increasing (see RFC 1982 for a complete description) and a change from 99XXXXXX to 00XXXXXX cause a failure. See the section on "Name Serving" for a complete description of the issues. 3.5 "Network Management" -Versions 1 & 2 of SNMP specify the use of UTCTime. This could be an -issue depending on implementations. +Version 2 of SNMP's MIB definition language (SMIv2) specifies the +use of UCTTimes for time stamping MIB modules. Even though these +time stamps do not flow in any network protocols, there could be +as issue with management applications, depending on implementations. 3.6 "Network News" There does exist a problem in both NNTP, RFC 977, and the Usenet News Message Format, RFC 10336. They both specify two-digit year format. A working group has been formed to update the network news protocols in general, and addressing this problem is on their list of work items. 3.7 "Real-Time Services" @@ -233,30 +234,21 @@ IDPR suffers from the classic Year 2038 problem, by having a timestamp counter which rolls over at that time. 5. Suggested Solutions The real solution to the problem is to use 4 digit year fields for applications and hardware systems. For counters that key off of a certain time (January 1, 1970 for example) need to either: define a wrapping solution, or to define a larger number space (greater than -32-bits), or to make more efficient use of the 32-bit space. A -trivial example might be to use to lower 12 bits to represent the -number of seconds in a day, and use next upper 19 bits to represent -days since January 1, 1970, and the set the highest bit to 1 so that -it is always larger than the current number of seconds since January -1, 1970. This would provide a unique counter until May 28, 3406. -(There are some drawbacks to this example, the most obvious being -the counter is no longer monotonically increasing. It was only -included as a simple example, not a serious suggestion.) - +32-bits), or to make more efficient use of the 32-bit space. However, it will be impossible to completely replace currently deployed systems, so solutions for handling problems are in order. 5.1 Fixed Solution A number of organizations and groups have suggested a fixed solution to the problem of two digit years. Given a two-digit year YY, if YY is greater than or equal to 50, the year shall be interpreted as 19YY; and where YY is less than 50, the year shall be intrepreted as 20YY. @@ -847,32 +839,31 @@ years). In any case, more work is needed in this area in the not too far distant future. 16 Network Management 16.1 Summary The RFC's which were categorized into this group were the Simple Network Management Protocol (SNMP), a large number of Management Information Bases (MIBs) and the Common Management Information -Protocol (CMIP). +Protocol over TCP/IP (CMOT). Although a few discrepancies have been found and outlined below, none of them should have an impact on interoperability. 16.2 Specifics 16.2.1 Use of GeneralizedTime in CMOT as defined in RFCs 1095 and 1189. -The standards for CMIP over TCP/IP specify an unusual use for the -GeneralizedTime type. (GeneralizedTime has a four-digit -representation of the year.) +The standards for CMOT specify an unusual use for the GeneralizedTime +type. (GeneralizedTime has a four-digit representation of the year.) If the system generating the PDU does not have the current time, yet does have the time since last boot, then GeneralizedTime can be used to encode this information. The time since last boot will be added to the base time "0001 Jan 1 00:00:00.00" using the Gregorian calendar algorithm. This is really a "Year 0" problem rather than a Year 2000 problem, and in any case, CMOT is not currently deployed. @@ -888,30 +879,23 @@ The first usage of UTCTime in the standards for SNMP definitions goes all the way back to RFC 1303. It has persisted unchanged up through the current specifications in RFC 1902. The role of UTCTime in SNMP definitions is to record the history of an SNMP MIB module in the module itself, via two ASN.1 macros: o LAST-UPDATED o REVISION -Applications that store and use MIB modules need to be smart about -interpreting these UTCTimes, but with one exception, the times do not -actually flow in the network. This one exception is the -appnNodeMibVersion object in the APPN MIB (currently -draft-ietf-snanau- appnmib-04.txt, but soon to be published as an -RFC), which returns the value of LAST-UPDATED from the version of the -APPN MIB that an agent has implemented. An application that can -correctly interpret UTCTimes, by prepending a "19" or a "20" as -appropriate, in the MIB modules it has stored locally will be able to -interpret the value of this object correctly as well. +Management applications that store and use MIB modules need to be +smart about interpreting these UTCTimes, by prepending a "19" or a +"20" as appropriate. 16.2.3 Objects in the Printer MIB (RFC 1559) There are two objects in the Printer MIB that allow use of a date as an object value with no explicit guidance for formatting the value. The objects are prtInterpreterLangVersion and prtInterpreterVersion. Both are defined with a syntax of OCTET STRING. The descriptions for the objects allow the object value to contain a date, version code or other product specific information to identify the interpreter or language. The descriptions do not include an explicit statement @@ -3830,70 +3814,85 @@ $OutStuff .= "$Msg found at line $WhereRealLine:\n"; $Start = $Where - 2; $End = $Where + 2; if($Where < 2) { $Start = 0 } if($Where > $LastLine - 2) { $End = $LastLine } for($j = $Start; $j <= $End; $j += 1) { $OutStuff .= "$j: " . @All[$j] } $OutStuff .= "\n"; } Appendix C: Output of the script in Appendix B on all RFC's from 1 - through 2134 + through 2479 + ++=+=+=+=+= File rfc0052.txt +=+=+=+=+= + + 2000 found at line 141: +138: +139: Chuck Rose Case University +140: Jennings Computing Center (216) 368-2000 +141: Case Western Reserve University x2808 +142: 10900 Euclid Avenue + ++=+=+=+=+= File rfc0090.txt +=+=+=+=+= -+=+=+=+=+= File rfc90.txt +=+=+=+=+= 2000 found at line 71: 68: consoles); 69: 70: j) Six data communication ports (3 dial @ 2000 baud, 71: 1 dedicated @ 4800 baud, and 2 dedicated @ 50,000 72: baud) for remote batch entry terminals; -+=+=+=+=+= File rfc230.txt +=+=+=+=+= ++=+=+=+=+= File rfc0230.txt +=+=+=+=+= + 2000 found at line 92: 89: as for conventional synchronous block communication, since start and 90: stop bits for each character would need to be transmitted. This loss 91: is not substantial and does occur now for 2000 bps TIP-terminal 92: communication. 93: 2000 found at line 134: 131: 92 transmitting sites in the U.S. and Canada were used with standard 132: Bell System Dataphone datasets used at both ends. At both 1200 and 133: 2000 bps, approximately 82% of the calls had error rates of 1 error in 134: 10^5 bits or better, assuming an equal number of short, medium, and 135: long hauls. -+=+=+=+=+= File rfc241.txt +=+=+=+=+= ++=+=+=+=+= File rfc0241.txt +=+=+=+=+= + 2000 found at line 32: 29: justifiable on the basis that the IMP and Host computers were 30: expected to be either in the same room (up to 30 feet of cable) or, 31: via the Distant Host option, within 2000 feet on well- controlled, 32: shielded cables. A connection through common carrier facilities is 33: not comparably free of errors. Usage of common- carrier lines for -+=+=+=+=+= File rfc263.txt +=+=+=+=+= ++=+=+=+=+= File rfc0263.txt +=+=+=+=+= + 2000 found at line 22: 19: of the occasional desire to interface a Host to some IMP via a 20: long-distance connection (where long-distance, in this context, 21: is any cable run longer than 2000 feet but may typically be tens 22: of miles) via either a hard-wire or telephone circuit. We believe 23: that any good solution to the general problem of interfacing Hosts -+=+=+=+=+= File rfc662.txt +=+=+=+=+= ++=+=+=+=+= File rfc0662.txt +=+=+=+=+= + 2000 found at line 143: 140: by a rather short cable (approximately 100 feet long.) The CISL Multics is 141: connected to the IMP number 6 (port 0) by an approximately l5OO feet long cable. 142: 8oth IMPs are in close physical proximity (approximately 2000 feet,) and are 143: connected to each other by a 5O kilobits per second line. The results given 144: above show considerable improvement in the performance with the new IMP DIM. -+=+=+=+=+= File rfc713.txt +=+=+=+=+= ++=+=+=+=+= File rfc0713.txt +=+=+=+=+= + 2000 found at line 830: 827: succeeding bytes in the stream used to encode the object. 828: 829: A data object requiring 20000 (47040 octal) bytes would 830: appear in the stream as follows. 831: 2000 found at line 837: 834: 10000010 -- specifying that the next 2 bytes 835: contain the stream length @@ -3901,21 +3900,22 @@ 837: 00100000 -- second byte 838: . 2000 found at line 845: 842: . 843: 844: Interpretation of the contents of the 20000 bytes in 845: the stream can be performed by a module which knows the 846: specific format of the non-atomic type specified by DEFGH in -+=+=+=+=+= File rfc724.txt +=+=+=+=+= ++=+=+=+=+= File rfc0724.txt +=+=+=+=+= + 2-digit found at line 1046: 1043: <4-digit-year> 1044: ::= "/" 1045: "/" <2-digit-year> 1046: ::= 1047: ::= 2-digit found at line 1062: 1059: | "December" | "Dec" 1060: <4-digit-year> ::= @@ -3930,37 +3930,40 @@ 1675: <4-digit-year> ::= 1676: <24-hour-time> ::= 2-digit found at line 1829: 1826: 1827: ::= "/" 1828: "/" <2-digit-year> 1829: ::= 1830: -+=+=+=+=+= File rfc731.txt +=+=+=+=+= ++=+=+=+=+= File rfc0731.txt +=+=+=+=+= + 2000 found at line 1571: 1568: RFC 728, 1977. 1569: 1570: 9. Hazeltine 2000 Desk Top Display Operating Instructions. 1571: Hazeltine IB-1866A, 1870. 1572: -+=+=+=+=+= File rfc732.txt +=+=+=+=+= ++=+=+=+=+= File rfc0732.txt +=+=+=+=+= + 2000 found at line 1681: 1678: 1977. 1679: 1680: 9. Hazeltine 2000 Desk Top Display Operating Instructions. Hazeltine 1681: IB-1866A, 1870. 1682: -+=+=+=+=+= File rfc733.txt +=+=+=+=+= ++=+=+=+=+= File rfc0733.txt +=+=+=+=+= + 2-digit found at line 333: 330: 331: "(element)" is equivalent to "*(element)"; that is, 332: exactly occurrences of (element). Thus 2DIGIT is a 2-digit 333: number, and 3ALPHA is a string of three alphabetic characters. 334: 2digit found at line 333: 330: 331: "(element)" is equivalent to "*(element)"; that is, @@ -3996,21 +3999,22 @@ 1718: date-field = "Date" ":" date-time 1719: date-time = [ day-of-week "," ] date time 2digit found at line 1754: 1751: host-indicator = 1*( ("at" / "@") node ) 1752: host-phrase = phrase host-indicator 1753: hour = 2DIGIT [":"] 2DIGIT [ [":"] 2DIGIT ] 1754: HTAB = 1755: -+=+=+=+=+= File rfc734.txt +=+=+=+=+= ++=+=+=+=+= File rfc0734.txt +=+=+=+=+= + 2000 found at line 184: 181: Bit name Value Meaning 182: 183: %TOALT 200000,,0 characters 175 and 176 are converted to 184: altmode (033) on input. 185: 2000 found at line 264: 261: NORMALLY OFF. 262: @@ -4025,44 +4029,47 @@ 354: 355: %TXSFT 1000 Reserved, must be zero. 2000 found at line 634: 631: Value Key 632: 633: 2000 Reserved 634: 1000 Reserved 635: 0400 -+=+=+=+=+= File rfc738.txt +=+=+=+=+= ++=+=+=+=+= File rfc0738.txt +=+=+=+=+= + 1900 found at line 41: 38: without sending anything. 39: 40: The time is the number of seconds since 0000 (midnight) 1 January 1900 41: GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this 42: base will serve until the year 2036. As a further example, the most 1900 found at line 42: 39: 40: The time is the number of seconds since 0000 (midnight) 1 January 1900 41: GMT, such that the time 1 is 12:00:01 am on 1 January 1900 GMT; this 42: base will serve until the year 2036. As a further example, the most 43: recent leap year as of this writing began from the time 2,398,291,200 -+=+=+=+=+= File rfc745.txt +=+=+=+=+= ++=+=+=+=+= File rfc0745.txt +=+=+=+=+= + 2000 found at line 562: 559: Circuits, EIA standard RS-422," April 1975; Engineering Dept., 560: Electronic Industries Assn., 2001 Eye St., N.W., Washington, D.C., 561: 20006. 562: 563: REA bulletin 345-67, Rural Electrification Admin., U.S. Dept. of -+=+=+=+=+= File rfc746.txt +=+=+=+=+= ++=+=+=+=+= File rfc0746.txt +=+=+=+=+= + 'yy' on a line without 'yyyy' found at line 341: 338: %TDGRF ;Enter graphics. 339: %GOCLR ;Clear the screen. 340: %GOMVA xx yy ;Set cursor. 341: %GODLA xx yy ;Draw line from there. 342: << repeat last two commands for each line >> 'yy' on a line without 'yyyy' found at line 342: 339: %GOCLR ;Clear the screen. 340: %GOMVA xx yy ;Set cursor. @@ -4070,29 +4077,31 @@ 342: << repeat last two commands for each line >> 343: %TDNOP ;Exit graphics. 2000 found at line 859: 856: %TRGIN 0,,400000 terminal can provide graphics input. 857: 858: %TRGHC 0,,200000 terminal has a hard-copy device to which output can 859: be diverted. 860: -+=+=+=+=+= File rfc752.txt +=+=+=+=+= ++=+=+=+=+= File rfc0752.txt +=+=+=+=+= + 'yy' on a line without 'yyyy' found at line 218: 215: word 4 The name of the site in SIXBIT. 216: word 5 The user name who compiled the file, usually in SIXBIT. 217: word 6 Date of compilation as SIXBIT YYMMDD. 218: word 7 Time of compilation as SIXBIT HHMMSS. 219: word 8 Address in file of NAME table. -+=+=+=+=+= File rfc754.txt +=+=+=+=+= ++=+=+=+=+= File rfc0754.txt +=+=+=+=+= + 'yy' on a line without 'yyyy' found at line 76: 73: 74: Messages are transmitted as a character string to an address which is 75: specified "outside" the message. The destination host ("YYY") is 76: specified to the sending (or user) FTP as the argument of the "open 77: connection" command, and the destination user ("XXX") is specified to 'yy' on a line without 'yyyy' found at line 81: 78: the receiving (or server) FTP as the argument of the "MAIL" (or "MLFL") 79: command. In Tenex, when mail is queued this outside information is @@ -4100,21 +4109,22 @@ 81: 82: The proposed solutions are briefly characterized. 'yy' on a line without 'yyyy' found at line 239: 236: 237: 238: "[---].XXX@YYY", not anything from the header. Only the string "XXX" 239: is passed to the FTP server. 240: -+=+=+=+=+= File rfc759.txt +=+=+=+=+= ++=+=+=+=+= File rfc0759.txt +=+=+=+=+= + two-digit found at line 1414: 1411: yyyy-mm-dd-hh:mm:ss,fff+hh:mm 1412: 1413: Where yyyy is the four-digit year, mm is the two-digit month, dd is 1414: the two-digit day, hh is the two-digit hour in 24 hour time, mm is 1415: the two-digit minute, ss is the two-digit second, and fff is the two-digit found at line 1415: 1412: 1413: Where yyyy is the four-digit year, mm is the two-digit month, dd is @@ -4122,21 +4132,22 @@ 1415: the two-digit minute, ss is the two-digit second, and fff is the 1416: decimal fraction of the second. To this basic date and time is two-digit found at line 1416: 1413: Where yyyy is the four-digit year, mm is the two-digit month, dd is 1414: the two-digit day, hh is the two-digit hour in 24 hour time, mm is 1415: the two-digit minute, ss is the two-digit second, and fff is the 1416: decimal fraction of the second. To this basic date and time is 1417: appended the offset from Greenwich as plus or minus hh hours and mm -+=+=+=+=+= File rfc767.txt +=+=+=+=+= ++=+=+=+=+= File rfc0767.txt +=+=+=+=+= + two-digit found at line 710: 707: yyyy-mm-dd-hh:mm:ss,fff+hh:mm 708: 709: Where yyyy is the four-digit year, mm is the two-digit month, dd is 710: the two-digit day, hh is the two-digit hour in 24 hour time, mm is 711: the two-digit minute, ss is the two-digit second, and fff is the two-digit found at line 711: 708: 709: Where yyyy is the four-digit year, mm is the two-digit month, dd is @@ -4144,29 +4155,31 @@ 711: the two-digit minute, ss is the two-digit second, and fff is the 712: decimal fraction of the second. To this basic date and time is two-digit found at line 712: 709: Where yyyy is the four-digit year, mm is the two-digit month, dd is 710: the two-digit day, hh is the two-digit hour in 24 hour time, mm is 711: the two-digit minute, ss is the two-digit second, and fff is the 712: decimal fraction of the second. To this basic date and time is 713: appended the offset from Greenwich as plus or minus hh hours and mm -+=+=+=+=+= File rfc786.txt +=+=+=+=+= ++=+=+=+=+= File rfc0786.txt +=+=+=+=+= + 'yy' on a line without 'yyyy' found at line 71: 68: 69: The date-time will be in the default TOPS20 ODTIM format 70: "dd-mmm-yy hh:mm:ss" (24 hour time). 71: 72: The files will named "arbitrary.NIMAIL.-1", where "arbitrary" will -+=+=+=+=+= File rfc788.txt +=+=+=+=+= ++=+=+=+=+= File rfc0788.txt +=+=+=+=+= + 'yy' on a line without 'yyyy' found at line 1592: 1589: ::= "at"