I just started to prepare a PR for this, but...
RFC6962 says:
"timestamp" is the current NTP Time [RFC5905], measured since the
epoch (January 1, 1970, 00:00), ignoring leap seconds, in
milliseconds.
6962-bis currently says:
"timestamp" is the current NTP Time [RFC5905], measured in
milliseconds since the epoch (January 1, 1970, 00:00 UTC), ignoring
leap seconds.
RFC5905 section 6 says:
"In the date and timestamp formats, the prime epoch, or base date of
era 0, is 0 h 1 January 1900 UTC, when all bits are zero."
1970 != 1900, and (IINM) NTP time does not ignore leap seconds.
ISTM that what we're actually using is Unix time
(https://en.wikipedia.org/wiki/Unix_time), and so we should say that
we're using Unix time. It makes no sense to claim to be using NTP time
if we're not actually doing that.
Two possible ways forward:
1. Replace the "NTP time" references with "Unix time", and find a
suitable reference (any ideas?) to point to.
2. Switch to actually using the 64-bit NTP timestamp format. This might
confuse implementers that are already familiar with RFC6962 though.
Any preferences? (I favour option 1).
On 28/07/18 23:37, Melinda Shore wrote:
On 7/28/18 7:02 AM, Benjamin Kaduk wrote:
Thanks for pulling up the primary source; I was just going on the chairs'
summary of the issues and apparently only noticed an unrelated potential issue.
Clarifying that the 64-bit timestamp format (with callout to Sectino 6 of
RFC 5905) is the correct one sounds like a fine thing to do.
D'oh! But in fairness the what was under discussion was in
response to the meeting minutes, which do accurately capture
the discussion in Montreal. I'll bug the authors.
Melinda
--
Rob Stradling
Senior Research & Development Scientist
Email: [email protected]
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
