|
Thanks for your thoughtful review, Kyle. My replies to your comments are inline... -----Original Message----- Reviewer: Kyle Rose Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready with nits. I see no issues of interest to the security directorate. I do have three comments, however: * In the security considerations section, a better example might be the potential inappropriateness of using an imprecise mechanism for specifying certificate expiration. I'll plan to add this example when addressing other last call comments. * It's not clear how this is intended to work for dates prior to the start of the Gregorian calendar in 1582. What do negative integer values mean when they imply a date before 15-Oct-1582? Is the Gregorian calendar defined for all time?
In a brief investigation, I've been unable to find the answer to this. See the section in the Introduction on the relationship to the Modified Julian Date value and then see
https://core2.gsfc.nasa.gov/time/ for the relationship of the Modified Julian Date to the Julian Date, a timescale defined by the Smithsonian Astronomical Observatory beginning at noon 1 January 4713 B.C. That
seems to go far back enough for most practical purposes. Interestingly, according to
https://en.wikipedia.org/wiki/Julian_day: “The Modified Julian Date (MJD) was introduced by the Smithsonian Astrophysical Observatory in 1957 to record the orbit of Sputnik via an IBM 704 (36-bit machine) and using only 18 bits
until August 7, 2576. MJD is the epoch of VAX/VMS and its successor OpenVMS, using 63-bit date/time, which allows times to be stored up to July 31, 31086, 02:48:05.47.[18] The MJD has a starting point of midnight on November 17, 1858 and is computed by MJD
= JD - 2400000.5.” * In a very gross sense, this specification *is* actually tied to the prevailing timescale, leap seconds and all: if the whole world were to transition from UTC to TAI and stop adding leap seconds, presumably implementations would continue
to generate dates for this specification by truncating the local timestamp to the date, which would cause it to drift along with TAI away from UTC over time. There wouldn't be a huge practical effect here given how little they are expected to diverge over
the foreseeable future, but it would mean that dates encoded in this format today would not carry enough information to precisely indicate a date in the far future even if the target timescale were understood throughout since the source timescale isn't part
of the encoding. If it’s good enough for the Smithsonian Astronomical Observatory (albeit, utilizing a defined integer offset), it’s good enough for me. ;-) Timekeeping is ultimately a human cultural endeavor and it’s beyond
the scope of this specification to probe its many variations and foibles. The essence of dates is that each time the world goes round, these values increment. That said, if you have specific text you’d like to see added, I’m open to it. Best wishes, -- Mike P.S. I never expected that writing this very simple specification would result in such interesting discussions about timekeeping! |
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
