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

[Daniel Franke <[e-mail]>]

That works.

On Thu, Dec 20, 2018 at 5:57 AM Tal Mizrahi <[e-mail]> wrote:
>
> 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.