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

[Tal Mizrahi <[e-mail]>]

Clarification: the text edit I suggested below is in response to Daniel's
comment:

https://www.ietf.org/mail-archive/web/ntp/current/msg03012.html

Apologies for responding to the wrong email on the thread. :)

Cheers,
Tal.


On Thu, Dec 20, 2018 at 12:57 PM 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.
>>
>