The minutes from the NTP/TICTOC session are available under:

Minutes for Joint NTP/TICTOC WG Meeting at IETF 101 - London Chairs:
Karen O'Donoghue, Dieter Sibold (NTP), Yaakov Stein (TICTOC) Minutes by

Karen started the meeting asking for a jabber scribe (Sam Weiler
volunteered) and a minute taker (Yaakov volunteered). She then noted the
new Note Well.


The agenda was slightly modified to enable NTP Yang data model to be
first, due to constraint of the presenter.

NTP Yang data model (draft-ietf-ntp-yang-data-model) ? Ankit (no slides)
A minor update was carried out before this meeting. An IF was added for
optional features, port numbers to be changed, added xml examples. The
draft is stable. More reviews are requested. Karen asked how many have
read - only 1.

Guidelines for Defining Packet Timestamps
(draft-ietf-ntp-packet-timestamps)- Tal (remote)
This audience of this draft is protocol designers. It suggests timestamp
formats and gives guidelines if none of the existing ones suffices. Tal
believes that he has addressed all comments. The draft now separates
syntax from semantics, contains a discussion about leap seconds, and
acquired a control field section. Tal asked whether it is worthwhile to
split into 2 drafts (base and control field) in order to expedite
publishing the base portion. Yaakov recommended that the draft should
clarify the IEEE1588 version if it speaks of PTP timestamps.  Yaakov
stated that he preferred not to split. Suresh asked if Tal is aware of
the work Greg Mirsky is doing in IPPM and MPLS (allowing 1588 or NTP
timestamp formats). Yaakov answered that there are no contradictions.
Yaakov asked if a time difference format is in scope. Tal?s connectivity
dropped. Karen ask Tal to send a note to the mailing list and to first
require additional feedback and secondly to ask if the WG would like to
have this document splitted.

Control Messages Protocol (draft-ietf-ntp-mode-6-cmds) - Brian
The draft is very stable, captures all the commands in RFC 1305 and
several new ones. Additions to the security section are pending. There
was discussion on the mailing list on changing some of the commands.
Brian clarified that the purpose of this draft is to document the
existing commands, not to change them. Brian will upload a new version
next week, and asked for WG LC. Karen agreed to go to WGLC.

Message Authentication Code (draft-ietf-ntp-mac) ? Aanchal (remote)
There are 2 main changes: changing SHOULD to MUST in Replacement
Recommendation section, and text addressing Tal?s comment on
interoperating with old implementations. No further changes are needed.
Karen: will go to WG LC in the next little while.

NTS Hackathon ? Martin 
The goal was to demonstrate interop and to
identify any remaining issues. There are now 3 NTS implementations. 
1. Martin?s (C++14 for Windows/Linux on x86/ARM) 
2. Daniel?s (Python) 
3. Ostfalia students (C++11, but not yet ready for test) 
The hackathon used 3 Raspberry PIs, each with its own IP address,
connecting over the Internet with Daniel?s implementation in Boston.
Test 1: server in London client in Boston - small bugs fixed, NTS worked
but NTP initially failed, but after the bug was fixed  everything
worked. Test 2 on Tuesday: client in London server in Boston. All in all
5 out of 6 tests were successful, 1 outstanding. Code is on GitHub,
Martin?s code is under the Apache license. Yaakov noted that if Martin
has an independent NTP implementation this could be useful in advancing
NTP to full standard. Karen stated that this is not the only independent
implementation, and that NTP will advance to full standard in the not
too distant future. Karen ? thanked participants and wants to repeat the
effort in Montreal with more in-depth testing.

Network Time Security for NTP (draft-ietf-ntp-using-nts-for-ntp) -
First slide showed photo of Big Ben under construction! V11 was
pushed out 1 week before the meeting. It includes 2 new sequence
diagrams, renames section 5.7 to 6, and includes minor editorial
changes. Section 7 has not been changed leaving the suggested cookie
format non-normative (as there were no comments on this issue). Yaakov
asked if this does not affect interoperability and Dieter explained that
the server can choose any format and the client does not need to interpret 
Karen relayed from Brian in the jabber room ?This Hackathon update
deserves an RFC 7942 section being added to the NTS draft.? V12 will be
submitted in a few weeks w/ updates based on hackathon results. After
that WG LC.

NTPv4 Extension Fields (draft-stenn-ntp-extension-fields AKA 7822bis) ?
(remote, audio only, but fully dressed) Document was updated,
joint work with Dave Mills, purely historical material removed. Jared
asked what happens if adding the extensions leads to fragmentation, and
Harlan replied that the ?network superglue document? does not yet exist.
Instead, one must make sure that one doesn?t exceed MTU, but there is no
specific text on what to do if it exceeds. Jared said that we don?t want
an NTP-specific path MTU discovery protocol. Harlan stated that in the
implementation there will be an MTU parameter. Harlan continued that in
the latest version he leaned everything up and changed the IANA tables.
Questions that need to be decided are in square brackets. Karen: this
draft is an individual submission, do we want to adopt? No opposition.
Brian: is this an update to RFC 7822 or a bis version? Karen: will ask
on list. Harlan: there remain open questions. Karen: the idea is that if
we adopt as a WG draft then the WG will decide on all these issues. Sam:
Thanks to Harlan. WG could decide on changes one at a time and create
multiple documents, but if this will be a bis document then it is best
to leave them all in a single draft.

Karen asked Harlan to review the content of the four new extension field
proposals, which will be discussed in a virtual interim. Harlan:
draft-stenn-ntp-extended-information remedies the fact that there are no
spare bits in the NTP format, for information such as TAI-UTC offset
(some people use Autokey just for that!) and interleave mode.
draft-stenn-ntp-mac-last-ef combines two proposals for avoiding
ambiguity as to whether the "next" data is an extension field or a
legacy MAC. draft-stenn-ntp-i-do provides a convenient way to learn if a
remote NTP instance supports an extension fields or not.
draft-stenn-ntp-suggest-refid is a backward-compatible way for a time
source to tell its clients to use a nonce as REFID in order to avoid
loops without divulging the IP address to potential attackers. In
addition there is draft-ietf-ntp-refid-updates which addresses further
shortcomings of the use of REFID, including the lack of a way to offer
leap-smeared time. Karen: these are individual submissions, and we need
comments from WG before moving forward

Karen: there are other drafts that we won?t discuss, including
draft-ietf-ntp-bcp (IESG), draft-ietf-ntp-data-minimization (ready for
LC), draft-mlichvar-ntp-correction-field (blocked on resolving extension
field issue), draft-mlichvar-ntp-interleaved-modes (ready for WG
adoption), draft-aanchal-time-implementation-guidance (hasn?t been

Status: draft-ietf-tictoc-1588v2-yang and
draft-ietf-tictoc-ptp-enterprise-profile are both ready for IESG.
Enterprise profile had interop testing in IEEE.

Synchronizing Internet Clocks (draft-alavarez-hamelin-tictoc-sic) Jose
Alvarez-Hamelin Thanks for ISOC for sponsoring as fellow and to the WG
for allowing to present. There are multiple applications for secure and
accurate time over the Internet, and there are several approaches for
supplying (NTP, PTP, TSC, GPS). From experimentation in Buenos Aires,
minimum gating of RTT does not provide a stable value. The new approach
is client-server, uses 1 packet per second, each packet with a deferred
signature, in order to provide secure sub-1 ppm frequency over the
public Internet. The software is on GitHub. Yaakov asked about goals and
why this is new. Kyle asked for more information on the research behind
this technique. Karen thanked the presenter.

Karen: There will be a virtual interim next month (Karen will poll for
scheduling). There are many open drafts ? please read!

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

TICTOC mailing list

Reply via email to