Subject: Re: [Ntp] WG LC for draft-ietf-ntp-packet-timestamps

From: Tal Mizrahi <[email-masked]>
Date: Wed, 9 Jan 2019 08:39:25 +0200

Hi Greg,

Many thanks for the comments.
We will address these comments in the next version of the draft.
More detailed responses below.

On Wed, Jan 9, 2019 at 5:53 AM Greg Mirsky <[email-masked]> wrote:

> Dear Authors, et al.,
> happy New Year!
> Apologies for the belated response.
> Firstly, I support the publication of this document and thank the authors
> for their work.
> Secondly, I have several comments to share, all are non-blocking and would
> appreciate you consider them as WG LC comments:
>
>    - "binary-encoded timestamp format" as the alternative to the clear
>    text format may be better than "packet timestamp" term to characterize the
>    subject of the document;
>
> We will clarify this point in the document.

>
>    - discussion of decisions, design choices that affect timestamp
>    accuracy and timestamp precision is very important but I don't see it in
>    the document. Perhaps, at this stage, references to the accuracy and the
>    resolution can be removed from the text to be discussed in another document
>    in the future;
>
> These aspects are mentioned in two places in the document: Section 5
(Synchronization Aspects) and Section 7 (Control Field).
Your point is well taken, and I will add more explicit language about the
fact that these aspects are expected to be discussed in future documents.

>
>    - regarding the number of timestamp formats supported by the new
>    protocol. I agree with your view that usually one format should be used.
>    But there could be scenarios that systems have different wall clocks, i.e.,
>    their native time format. In such cases, it is advantageous to enable
>    collection of the timestamp in the native format, NTP or PTP. I think that
>    the document should mention that multiple binary-encoded timestamp formats
>    may be used;
>
> Agreed.

>
>    - the table in section 6 presents RFC 8186 as supporting only PTP
>    Truncated format for timestamps in TWAMP Test packet. Actually, with the
>    RFC 8186 TWAMP Session-Sender and Session-Reflector may use either NTP
>    64-bit or PTP (capability advertisement and negotiation in TWAMP-Control).
>
> Right. Will update the document.

> Regards,
> Greg

Regards,
Tal.

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 8 Jan 2019 19:52:51 -0800

Dear Authors, et al.,
happy New Year!

   - "binary-encoded timestamp format" as the alternative to the clear text
   format may be better than "packet timestamp" term to characterize the
   subject of the document;
   - discussion of decisions, design choices that affect timestamp accuracy
   and timestamp precision is very important but I don't see it in the
   document. Perhaps, at this stage, references to the accuracy and the
   resolution can be removed from the text to be discussed in another document
   in the future;
   - regarding the number of timestamp formats supported by the new
   protocol. I agree with your view that usually one format should be used.
   But there could be scenarios that systems have different wall clocks, i.e.,
   their native time format. In such cases, it is advantageous to enable
   collection of the timestamp in the native format, NTP or PTP. I think that
   the document should mention that multiple binary-encoded timestamp formats
   may be used;
   - the table in section 6 presents RFC 8186 as supporting only PTP
   Truncated format for timestamps in TWAMP Test packet. Actually, with the
   RFC 8186 TWAMP Session-Sender and Session-Reflector may use either NTP
   64-bit or PTP (capability advertisement and negotiation in TWAMP-Control).

Regards,
Greg