Re: [Ntp] WGLC: draft-ietf-ntp-packet-timestamps

[Tal Mizrahi <[e-mail]>]

Hi Daniel,

Thanks for the feedback.

I suggest to add the following text to the abstract (based on text that is
currently in Section 4):

   The rationale behind defining a relatively small set of recommended
formats
   is that it enables significant reuse; network protocols can typically
reuse
   the timestamp format of the Network Time Protocol (NTP) or the Precision
   Time Protocol (PTP), allowing a straightforward integration with an NTP
or a
   PTP-based timer. Moreover, since accurate timestamping mechanisms are
   often implemented in hardware, a new network protocol that reuses an
existing
   timestamp format can be quickly deployed using existing hardware
   timestamping capabilities.

I hope this addresses your concern. Please let me know if it does not.

Thanks,
Tal.


On Thu, Dec 20, 2018 at 1:27 AM Daniel Franke <[e-mail]> wrote:

> On Wed, Dec 19, 2018 at 3:26 PM Watson Ladd <[e-mail]> wrote:
> > What you want is TAI which is in the spec. Why introduce a new kind of
> time? Why count days and seconds and have a strange multiple representation
> issue?
> >
> > UTC is UTC. It is defined by BIPM. Your timescale is not UTC. It is not
> a different timestamp format but a different timescale. Intercalcary
> nanoseconds need to be added in ways you have not defined. For one thing
> what's a day and when is midnight? Siderial, solar, or mean?
> >
> > If you want every second to be unique use TAI. That's what it is for.
>
> I think you're confused. TAI, as defined by BIPM, is canonically
> expressed as Gregorian date, hours, minutes, and seconds, but since
> every day consists of exactly 86400 SI seconds, it can equivalently be
> expressed as a real number of seconds since some fixed epoch. "What's
> a day?" and "When is midnight?" are questions that BIPM will answer
> for you. UTC is defined by the ITU
> (
> https://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf
> )
> and is also canonically expressed as Gregorian date, hours, minutes,
> and seconds, but days are sometimes 86401 SI seconds long; time time
> half a second before the end of one of these days is 23:59:60.5.
> Because of this variation in day length, you can't unambiguously
> represent UTC as a scalar; you need separate fields for representing
> date and time of day
>
> Your accusation of introducing a new kind of time that is not UTC
> should not be directed at me; it *should* be directed at virtually
> every computer time standard currently out there, except for ISO 8601
> which gets it right.
>