Hi Warner, Thanks for the feedback.
>Section 4.1 says "Further considerations may be discussed in >this section, such as required accuracy, or leap second handling." >Yet none of the formats make any allowance for leap seconds. Right. As I pointed out below, we have separated the *formats* from the *synchronization aspects*. The advantage of this approach is that a given timestamp format does not necessarily define the time standard (UTC / TAI), and specifically does not necessarily define the leap second handling. That means that a specification that uses a recommended timestamp format should define the synchronization aspects, including leap second considerations if such exist. See the following text in the draft: A specification that uses one of the recommended timestamp formats should also include a section on Synchronization Aspects... ...such as required accuracy, or leap second handling. With that said, your point is well taken. In the next draft we will add some more text that clarifies this point, including an example in Section 5. Regards, Tal. On Sun, Sep 24, 2017 at 6:06 PM, Warner Losh <[email protected]> wrote: > > > On Sun, Sep 24, 2017 at 7:37 AM, Tal Mizrahi <[email protected]> > wrote: > >> Hi, >> >> We have revised the draft based on the comments received in IETF 99, and >> based on the comments from Yaakov (thanks Yaakov). >> >> https://datatracker.ietf.org/doc/draft-mizrahi-intarea-packet-timestamps/ >> >> The main changes compared to the previous version of the draft: >> - We have extended the discussion about the factors that may affect the >> choice of the timestamp format. >> - A new section has been added, called "Timestamp Use Cases". >> - The sychronization aspects have been separated from the timestamp >> format, allowing the timestamp format to be independent of how time is >> synchronized. >> >> Any further comments are welcome. >> > > Section 4.1 says "Further considerations may be discussed in this > section, such as required accuracy, or leap second handling." Yet none of > the formats make any allowance for leap seconds. In NTP headers, leap > second time stamps are marked with an out-of-band bit. In addition, all NTP > time stamps are adjusted by the cumulative number of leap seconds, yet that > relevant information is not included.PTP timestamps, on the other hand, are > a count of TAI seconds since 1970, which have no adjustments. > > When I was doing time and frequency recovery, these differences weren't > documented and many arguments ensued to get to the understanding of what's > actually on the wire, what the auxiliary bits mean, etc. I'd rather see > this document be explicit about such things rather than some vague hand > wave that will be interpreted in many different ways leading to even more > issues with leap seconds than we already have. > > Warner >
_______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
