[ntpwg] draft minutes from Vancouver NTP WG meeting

[Danny Mayer]

Odonoghue, Karen F CIV NSWCDD, W13 wrote:
> Folks,
> 
> Below are draft minutes from our recent meeting. If you have any comments
> or corrections, feel free to send them on. Thank you to Malcolm for
> drafting
> them and any errors are the result of my edits...
> 
> Karen
> 
> Draft (13 Dec 2007)
> NTP WG Meeting Minutes
> 1740 – 1950, Monday, December 3, 2007
> 
> The meeting was chaired by Karen O'Donoghue and Brian
> Haberman. Malcolm Airst took the minutes and Yaakov Stein
> acted as Jabber scribe.
>
> NTP server option for DHCPv6 (Benoit Lourdelet, Richard
> Gayraud)
> Document: draft-gayraud-dhcpv6-ntp-opt-00.txt.
> Slides:
> *       Network operators prefer to centrally configure IP services
> through DHCP. DHCPv6 options are added to offer NTPv4
> client configuration. Two new options were added to DHCPv6: 
> 1) Advertise NTP server locations and 
> 2) Address public internet and private network requirements
> *       Network operators would prefer to configure NTP parameters
> to fine tune NTP traffic vs. clock accuracy. Another concern is
> that a small NTP server become overloaded, causing the risk of
> a catastrophic NTP event. Existing DHCPv4 only uses the NTP
> server address. Additional configuration options are defined in
> the new draft. Suggestions for additional parameters are
> welcome.
> *       Brian Haberman suggested that first, DHCPv6 should emulate
> DHCPv4 capability. A later revision of the document could
> then cover additional capabilities. There was a detailed
> discussion on which NTP parameters to use and if SNTP
> should also be used.

I'm not sure that I agree with this. I would prefer that we figure out
*first* what should be done and then write the document. It's too late
if you allow something initially and later want to restrict it. You
won't be able to go back.

> *       Should the parameters be reworked? Should Autokey be
> included via reference to ID?  Brian Haberman’s suggestion is
> to review comments for impact and then publish a revised
> document. The authors agreed.
> 

That was one of my recommendations. One of the other ones was to include
an NTP timestamp in the initial DHCP response (BOOTP?) so that a client
without a TOY can get at least an approximately idea of the current time
which would later be adjusted with NTP.

> TICTOC/Future Efforts (Karen O'Donoghue)
> Karen felt that an open discussion in the NTP WG was needed in
> preparation for the TICTOC BOF planned for the next morning.
> There were some basic questions that should be addressed
> including: 
> 1) Is there more work that needs to be done with NTP; 
> 2) What is the best way to accomplish this work; and 
> 3) Can the IETF sustain two timing related working groups in the
> IETF.
> 
> There does appear to be more work that could and should be done
> standardizing NTP. However, there are not any clear compelling
> proposals on the table yet. Additionally, the NTP working group
> has struggled with finishing work based partly on a lack of
> resources and issues around clear design authority. The original
> charter covered NTPv4 and eventual work on NTPv5. Almost
> three years later we’re still trying to get NTPv4 completed. NTPv4
> is a moving target since most implementations are based on a
> changing code base.
> 

While the code base is changing it's to improve the algorithms and ways
of handling different configurations. It really is not a protocol issue
and should not affect the NTP v4 spec in any way. The reference
implementation is just that, a reference implementation and changes
being made are to support more and varied configurations and
circumstances. Other implementations should feel free to not try to
follow this and the spec should not require it. The NTPv4 draft is about
how to get an implementation to interoperate with other servers,
correctly interpret the other's packets and make calculations to correct
and discipline the system clock. Some implementations will do this
better than others.

> Karen stated that perhaps the next generation timing work does not
> belong in the NTP WG given the issues to date. In this case,
> however, where should any NTP follow on work (NTPv5?) reside?
> Greg suggested that the NTP charter should be updated when
> NTPv4 is completed. Many current NTP issues are not actual
> timing related, but rather NTP control issues. The initial focus of
> TICTOC would be on timing. Yaakov stated that IETF
> Management is concerned that there is not enough critical mass to
> support two WGs covering timing issues. On the positive side, if
> there’s a single WG with two tracks, there would be synergy and
> collaborative review between the subgroups. Yaakov is concerned
> about NTP’s future, specifically for TICTOC Use Case 2. Karen
> stated that in a perfect scenario NTP would be the timing protocol
> and all IETF efforts would focus on advancing that protocol;
> however, that is not the current reality in the IETF. No clear
> consensus was reached beyond the fact that the working group
> really needs to complete its current charter items and that there is
> concern in the IETF about the resources associated with two time
> related working groups.

Personally, I don't care what the WG is called, though TICTOC is still a
BOF rather than a WG. There are different issues being addressed in the
two groups and if that means two subgroups under an umbrella group,
that's fine. The current TICTOC seems to be concerned about IEEE1588v2
and support for it. I'm sure there's more than that but it didn't come
through very well. From NTP's point of your that's something several
levels below the one that NTP operates on and therefore by it's very
nature will have a more restricted applicability. I suspect that NTP
would probably implement 1588 as a refclock.

Outside of IEEE1588v2 what does TICTOC want to get done? The same
question about NTPv4, autokey and MIB needs to be asked of the NTP WG. I
do know of one authentication proposal that has been raised but it needs
to be drafted.

Danny