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

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 5 Dec 2018 16:47:01 +0100

On Tue, Nov 06, 2018 at 07:52:59AM +0000, Karen O'Donoghue wrote:
> Folks,
> 
> This message initiates a three plus week working group last call for:
> 
> Guidelines for Defining Packet Timestamps
> https://datatracker.ietf.org/doc/html/draft-ietf-ntp-packet-timestamps
> 
> Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed..

I had few comments for this draft before, which are not addressed
in the current version (-04) of the document yet, but Tal has proposed
some changes and I'm happy with them. As soon as they are in, I
support advancing this document.

-- 
Miroslav Lichvar

---

From: Denis Reilly <[email-masked]>
Date: Thu, 6 Dec 2018 16:13:15 +0000

Hello!

I have read the NTP Packet timestamps draft and believe it is ready for submission, subject to my one minor nit, below:

In Section 6.1 and 6.2, the draft references an earlier version of itself (draft-ietf-ntp-packet-timestamps-03) as an informative reference. Shouldn’t it just refer directly to itself as a section link?

In particular, Section 2 reads:
      The timestamp format used in this specification is the PTP
      [IEEE1588] Truncated format, as specified in Section 4.2.3 of
      [I-D.ietf-ntp-packet-timestamps].

However, Section 4.2.3 doesn’t exist, either in this draft or in the referenced -03 draft. This reference should be corrected.

Best Regards,

--
Denis Reilly  |  Technical Lead  |  [email-masked]<mailto:[email-masked]>  (585)321-5837<tel:(585)%20321-5837>

From: ntp <[email-masked]> On Behalf Of Karen O'Donoghue
Sent: Friday, November 30, 2018 3:38 PM
To: [email-masked]
Subject: Re: [Ntp] WGLC: draft-ietf-ntp-packet-timestamps

Folks,

After receiving a few requests, I am going to extend this WGLC for one week. Please submit comments by COB on Friday 7 December. Even if you don’t have any comments, please indicate to the mailing list that you have read the draft and you believe it is ready for submission to the IESG. This is critical to helping the chairs determine working group consensus on this document.

Regards,
Karen

On Nov 6, 2018, at 2:52 AM, Karen O'Donoghue <[email-masked]<mailto:[email-masked]>> wrote:

Folks,

Please review the referenced document and send any comments to the mailing list including your assessment of whether this document is mature enough to proceed to the IESG. Please note that these messages of support for progression to the mailing list will be used to determine WG consensus to proceed.

Please send all comments in by COB on Friday 30 November. I realize this is a bit longer than normal but we are coming out of an IETF week and heading into the Thanksgiving holiday in the US.

Thanks!
Karen and Dieter

ATTENTION: This email came from an external source.
Do not open attachments or click on links from unknown senders or unexpected emails.

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 9 Dec 2018 10:30:21 +0200

Hi Denis,

Many thanks for your comments.

Good catch - will fix the broken xref.
Regarding the reference that points to the previous version of the draft -
this is an issue we are aware of, and we will work it out with the RFC
editor before publication, so that the xref will point to the RFC number of
the current document.

Cheers,
Tal.

On Thu, Dec 6, 2018 at 6:13 PM Denis Reilly <[email-masked]> wrote:

> Hello!
>
>
>
> I have read the NTP Packet timestamps draft and believe it is ready for
> submission, subject to my one minor nit, below:
>
>
>
> In Section 6.1 and 6.2, the draft references an earlier version of itself
> (draft-ietf-ntp-packet-timestamps-03) as an informative reference.
> Shouldn’t it just refer directly to itself as a section link?
>
>
>
> However, Section 4.2.3 doesn’t exist, either in this draft or in the
> referenced -03 draft. This reference should be corrected.
>
>
>
> Best Regards,
>
>
>
> --
>
> Denis Reilly  |  Technical Lead  |  [email-masked]  (585)321-5837
> <(585)%20321-5837>
>
>
>
> *From:* ntp <[email-masked]> *On Behalf Of * Karen O'Donoghue
> *Sent:* Friday, November 30, 2018 3:38 PM
> *To:* [email-masked]
> *Subject:* Re: [Ntp] WGLC: draft-ietf-ntp-packet-timestamps
>
>
>
> Folks,
>
>
>
> After receiving a few requests, I am going to extend this WGLC for one
> week. Please submit comments by COB on Friday 7 December. Even if you don’t
> have any comments, please indicate to the mailing list that you have read
> the draft and you believe it is ready for submission to the IESG. This is
> critical to helping the chairs determine working group consensus on this
> document.
>
>
>
> Regards,
>
> Karen
>
>
>
> On Nov 6, 2018, at 2:52 AM, Karen O'Donoghue <[email-masked]> wrote:
>
>
>
> Folks,
>
>
>
> Please review the referenced document and send any comments to the mailing
> list including your assessment of whether this document is mature enough
> to proceed to the IESG. Please note that these messages of support for
> progression to the mailing list will be used to determine WG consensus to
> proceed.
>
> Please send all comments in by COB on Friday 30 November. I realize this
> is a bit longer than normal but we are coming out of an IETF week and
> heading into the Thanksgiving holiday in the US.
>
>
>
> Thanks!
>
> Karen and Dieter
>
>
>
>
>
>
> *ATTENTION: This email came from an external source. Do not open
> attachments or click on links from unknown senders or unexpected emails. *
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Tal Mizrahi <[email-masked]>
Date: Sun, 9 Dec 2018 10:37:55 +0200

Hi,

As WGLC has completed, we have uploaded an updated version of the draft:
https://tools.ietf.org/html/draft-ietf-ntp-packet-timestamps-05

We believe this version addresses all the comments we received, including
the latest comments from Miroslav, Warner, and Denis.
Specifically, the authors had some offline correspondence with Miroslav and
Warner regarding the leap second description and the NTP timestamp epoch
description. After a few iterations we believe we have reached a
satisfactory version of the relevant text. The changes compared to draft 04
can be viewed in the diff version (
https://tools.ietf.org/rfcdiff?url2=draft-ietf-ntp-packet-timestamps-05.txt
).

Cheers,
Tal, Joachim, and Al.

---

From: Warner Losh <[email-masked]>
Date: Wed, 19 Dec 2018 11:12:54 -0700

Hi,

Version 5 has addressed my concerns in prior drafts. Re-reading it now I
have no further issues and believe it's ready for publication.

Warner

On Sun, Dec 9, 2018 at 1:38 AM Tal Mizrahi <[email-masked]>
wrote:

> Specifically, the authors had some offline correspondence with Miroslav
> and Warner regarding the leap second description and the NTP timestamp
> epoch description. After a few iterations we believe we have reached a
>> Please review the referenced document and send any comments to the
>> mailing list including your assessment of whether this document is mature
>> enough to proceed to the IESG. Please note that these messages of support
>> for progression to the mailing list will be used to determine WG consensus
>> to proceed.
>>

---

From: Daniel Franke <[email-masked]>
Date: Wed, 19 Dec 2018 13:40:52 -0500

I have no objection to advancing this document. I wish the
introductory text would be clearer on who the document's intended
audience is, and the scope within which its recommendations are
intended to be applicable. If the reader misinterprets this document
as giving recommendations for the right way to represent time in an
entirely green-field project that doesn't have to interoperate with
anything else, then the recommendations are frankly terrible. The only
good reason for using a UTC timestamp that counts only non-leap
seconds and is ambiguous while leap seconds are in progress is that so
many existing systems are built this way (as I've said before, the
*sensible* way to express UTC in binary protocols is with two fields:
days since some epoch, and (nano|nibi)seconds since midnight).
Likewise, in a vacuum, the document's recommendations regarding
particularly choices of epoch or nibiseconds-vs-nanoseconds would be
unmotivated; they are the way they are purely because of existing
systems that already work that way. If the reader goes through the
document from start to finish, it eventually becomes clear that its
recommendations are centered around interoperation with existing NTP
or PTP systems. However, a reader who has only gotten through the
title, abstract, and introduction is likely to have incorrect
expectations about what follows.

On Sun, Dec 9, 2018 at 3:38 AM Tal Mizrahi <[email-masked]> wrote:
> We believe this version addresses all the comments we received, including the latest comments from Miroslav, Warner, and Denis.
> Specifically, the authors had some offline correspondence with Miroslav and Warner regarding the leap second description and the NTP timestamp epoch description. After a few iterations we believe we have reached a satisfactory version of the relevant text. The changes compared to draft 04 can be viewed in the diff version (https://tools.ietf.org/rfcdiff?url2=draft-ietf-ntp-packet-timestamps-05.txt).
>
> Cheers,
> Tal, Joachim, and Al.
>
>
>
> On Fri, Nov 30, 2018 at 10:37 PM Karen O'Donoghue <[email-masked]> wrote:
>>
>> Folks,
>>

---

From: Watson Ladd <[email-masked]>
Date: Wed, 19 Dec 2018 12:26:36 -0800

> expectations about what follows.

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.

> > We believe this version addresses all the comments we received,
> including the latest comments from Miroslav, Warner, and Denis.
> >> Please send all comments in by COB on Friday 30 November. I realize
> this is a bit longer than normal but we are coming out of an IETF week and

---

From: Daniel Franke <[email-masked]>
Date: Wed, 19 Dec 2018 18:27:38 -0500

On Wed, Dec 19, 2018 at 3:26 PM Watson Ladd <[email-masked]> 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?
>

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.

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 20 Dec 2018 12:57:32 +0200

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 <[email-masked]> wrote:

> > 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
> (
> https://www.itu.int/dms_pubrec/itu-r/rec/tf/R-REC-TF.460-6-200202-I!!PDF-E.pdf
> )

---

From: Tal Mizrahi <[email-masked]>
Date: Thu, 20 Dec 2018 13:02:50 +0200

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.

---

From: Daniel Franke <[email-masked]>
Date: Thu, 20 Dec 2018 12:34:50 -0500

That works.

On Thu, Dec 20, 2018 at 5:57 AM Tal Mizrahi <[email-masked]> 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
>    Time Protocol (PTP), allowing a straightforward integration with an NTP or a
>    often implemented in hardware, a new network protocol that reuses an existing