Network Time Protocol WG Meeting Minutes
Tuesday, August 2 at 1630-1800
==============================
CHAIRS: Brian Haberman, brian@innovationslab.net
Karen O'Donoghue, karen.odonoghue@navy.mil
o Administrivia (Chairs)
Mailing list, blue sheets, scribes, agenda bashing
There was no jabber scribe available.
o SNTP Draft Status (Karen)
The SNTP draft is now final; it is to be an Informational RFC that is
now pending in the RFC Editor's Queue. While this work pre-dates this
WG, it will be under WG once it is released. The new documents, that this
Working Group is developing, will supersede this RFC.
o NTPv4 Requirements
draft-ietf-ntp-reqs-00 (Dave Plonka)
This effort is developing a requirements document for a protocol that is
already in use. This document is also to be a collection place for
future requirements. Dave provided an overview of the current draft.
Areas that he is soliciting information are marked with a "FIXME".
Dave asked for help in the Algorithm Requirements in particular.
A number of issues were discussed:
*(Dave P.) How can we best address SNTP? Currently it has its own section but
it is interleaved throughout as well.
*(Dave P.) Should operational requirements be included? Usually only a BCP
covers operational issues but NTP's public server infrastructure is a special
case. Brian said that Operational considerations should be in a BCP, not
in a Requirements document. Karen asked that we collect the operational
considerations here for now and break them out later.
*(Peter L.) Should the working group be concerned only with UTC or with any
time source? Direction was to work with any time source but NTP's public
server infrastructure is a special case that needs emphasis.
*(Peter L.) Need to explain the algorithm so that someone can build from
scratch, this will affect many documents.
*(Dave P.) How should we handle autokey? Brian indicated that he talked to
an AD who indicated that we may need a way to distribute keys using IETF IPSEC
key distribution protocols. The requirement is to distribute keys, not
to describe a particular protocol.
*(Bill) Manual key configuration will result in replay attacks related to
restarting the sequence number at the same value and thus an automated
key management capability is needed.
*(Sharon C.) Need to provide useful reporting of management information (e.g.
via the MIB), do not make it an operational issue. For example, continue
requiring that stratum 1 servers have an outside source of time versus
making this an operational issue.
*(Peter L.) - Need to document a requirement to identify the type of time
that is being transferred. For example any of the eighty UTC clocks is
identified by a four-character name, this could be placed into the protocol
header sent by a stratum 1 server. Currently, the protocol has a means
identifying the dissemination method versus identifying the source of the
time information. Someway of authenticating such information would also
be needed. This topic is to be put into the bin of future requirements.
draft-frost-pwe3-timing-pw-reqs-00 (Tim Frost)
Tim provided an overview of his draft, explaining pseudo wire's need
for time synchronization. There was a lot of discussion trying to align
the time needs of pseudo wire (Used in carrier packet nets) with NTP (usually
used in LAN or Internet environments) capabilities. Tim was interested in
seeing whether NTP might be a protocol suitable for conveying timing and
synchronization for a pseudo wire infrastructure. NTP is concerned with wall
clock or absolute time while carrier packet nets are concerned with frequency
and phase as well as absolute time. Performance aspirations may differ.
The basic question discussed was whether NTP could be used for timing pseudo
wires. Pseudo wire time capabilities are needed for the infrastructure and
not providing time info directly to users.
A number of issues were discussed:
(From the floor) Why could not NTP be used as is since pseudo wire is
is used where you don't have IP ( e.g. an L2 link like ATM)?
(From the floor) Can we use NTP to distribute clock within a Telco? There
were a number of people who thought it could. Use NTP packets to pass
phase and frequency.
(Stewart B.) Wants to understand the requirement and come up with a viable
solution. Recommended that the discussion be moved to the list.
(Karen) Asked that the focus be the articulation of the problem so that
all can agree on the problem and the associated performance numbers.
o NTPv4 Protocol Specification
draft-ietf-ntp-ntpv4-proto-00 (Jack Burbank)
Jack provided an overview of the draft which Jim Martin, Dave Mills and he
are writing. This draft is to document the protocol on the wire. The goal is to
have a draft ready for Working Group last call by the next meeting. As with the
NTP Requirements draft, he felt that SNTP probably deserves its own section in
the protocol draft.
The three step process for developing this draft is (currently in step 2):
1. Compile material "as-is" from existing NTP material putting it into the proper format.
2. Add any additional material that is required. Here the comments from the
IESG on the informational SNTP draft can be addressed.
3. Clean up.
Issues that were discussed:
(From the floor) Anycast terminology needs to be cleaned up. There was consensus
that this is a goal for this draft.
(Jack) The advancement of the Protocol document requires multiple independent
implementations. Most current implementations come from the reference
implementation.
o IEEE 1588 Update (Karen)
IEEE1588-2002 is a standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems. The IEEE 1588 community is interested
in using the NTP security approach. Karen wants to keep the two communities
tied together.
Issues that were discussed:
(Sharon C.) Asked whether IEEE 1588 and NTP could be merged. Karen indicated that
there are quite a bit of difference since IEEE 1588 can require dedicated hardware
and only uses Ethernet transfer. Stewart said that we can perhaps a common upper
layer for both 1588 and NTP.
(From the floor) Is the NTP security solution in need of fixing? If there
are known problems these need to be communicated to the IEEE 1588 group. The
discussion that followed indicates that there are no known problems with the
NTP security solution but at this point it is not known whether the NTP
security solution would be good for IEEE 1588.
|