[ntpwg] draft minutes from Vancouver NTP WG meeting

Thu Dec 13 20:22:40 UTC 2007

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. 

The proposed agenda included:
Administrivia                Chairs
NTPv4 Protocol Specification  Martin
          * draft-ietf-ntp-ntpv4-proto-08.txt
- NTP Autokey Specification     Haberman
          * draft-ietf-ntp-autokey-00.txt
- NTPv4 MIB                     Elliott
          * draft-ietf-ntp-ntpv4-mib-02.txt
- NTP server option for DHCPv6  Lourdelet
          * draft-gayraud-dhcpv6-ntp-opt-00.txt
- TICTOC/Future efforts

NTPv4 Protocol Specification (Jim Martin)
Document: draft-ietf-ntp-ntpv4-proto-08.txt. 
Slides: 
Jim has produced another revision of this document in response to 
Chicago and Prague discussions. The following significant changes 
were made:
*	References to private networks for alternative algorithms were 
removed. 
*	The REFID was placed under IANA management. Verified 
that REFID text does address both v4 and v6. 
*	Text is still lacking that clearly defines which bit in the
packet 
the timestamp represents. The WG needs to decide on the 
precise approach. Three options were discussed:  
a) The timing bit be the first bit of the IP packet or  
b) the timing bit be located at the beginning of NTP payload or  
c) Use the start of the Ethernet frame.  
Discussion: The timestamp should reference the start of the 
NTP header. Yaakov Stein, Stewart Bryant, and Greg Dowd to 
work offline and submit proposed text. 
*	KOD timestamp to be defined in draft-09 using the text 
proposed by Danny Meyer on the mailing list. 
*	The WG should identify remaining issues between the NTP 
and Autokey drafts. Then draft -09 can be published and go 
through another Working Group Last Call. 

NTP Autokey Specification (Brian Haberman)  
Document: draft-ietf-ntp-autokey-00.txt. 
Slides: 
*	WGLC began on 11-02-07
*	Only one set of comments initially received (additional 
comments and suggestions by Greg Dowd and Dave Mills 
were missed in the meeting preparation and are not discussed 
here). 
o	There was a proposal to remove the paragraph 
discussing NATs
o	There was also a comment to remove the sentence 
discussing the use of reverse DNS
o	Other minor comments were discussed and adjudicated
*	Next steps: Revise document based on comments. Further 
discussion needed on the draft. NTPv4 can't proceed without 
the Autokey document. 

NTPv4 MIB (Chris Elliott)
Document: draft-ietf-ntp-ntpv4-mib-02.txt. 
Slides: 
*	Minor updates made to document
o	Added optional statistics objects
o	Remaining work includes verifying compliance with 
latest XML MIB template and incorporating the latest 
comments. 
*	Plan to revise document one final time and issue a working 
group last call. Chris indicated that this could be done within a 
week. 

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. 
*	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. 

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. 

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. 

The meeting was adjourned. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.ntp.org/pipermail/ntpwg/attachments/20071213/57a90fb7/attachment-0001.html 