Last Modified: 2005-09-27
Done | NTP BOF at IETF 61 | |
Done | NTP WG Charter Approved | |
Mar 2005 | Draft of Scope and Requirements Document | |
Mar 2005 | Draft of NTP Protocol Specification | |
May 2005 | Draft of MIB Specification | |
Jul 2005 | Draft of NTP Algorithms Specification | |
Sep 2005 | WG Last Call Scope and Requirements Document | |
Nov 2005 | WG Last Call NTP Protocol Specification | |
Mar 2006 | WG Last Call NTP MIB Specification | |
May 2006 | WG Last Call NTP Algorithms Specification |
Dave Plonka - Requirements Draft Differences between -00 and -01: Extended broadcast term to mean IPv6 multicast too. Added jitter and wander defs. Remove reference to master/slave. Algorithm Requirements: Removed MAXSTRAT, MAXSKEW, etc. due to them being only implementation details Introduced MAXPOLL which has clear requirements Mentioned that SNTP clients are divorced from many of the algorithm requirements for "full" implementations. Accuracy: noted that ntp is best effort, but noted service expectations. Configs: 4 servers should be configurable New "Leap Seconds" Section Implementations should signal pending leap-seconds Reconfiguration Added test re:reconfiguration when servers are unreachable. New "Management Information Requirements" Section Security removed references to th autokey protocol in favor of "IETF standard method" for server verfification and key distribution. Identity verification of servers and the like is included in that. AutoKey is NTP-specific, and perhaps this should be replaced with some other protocol. Previous Open issues: draft has a dedicated sntp sectioni: There has been discussion in splitting the sntp protocol out into a separate draft. operational requiremetns section remains temporarily to collect these items. Leap Seconds: Is this issue sufficiently addressed in the new Leap Seconds sub-section? Is distribution of the leap-seconds table important? This was apparently a function of the non-standard AutoKey protocol. Terminology There is a ntp community terms doc somewhere Other NTP WG drafts/rfcs become the authorative source fo defs of these terms, at least the terms used in the protocol spec. What is iburst? used in ntpd initialization. how does this affect poolling interval requirements? There are still holes that need to be filled, planned for the next draft, please contribute!! Yakov Stein: defs of time, jitter and wander, ref to ITU-T G.810. Editorial comments. section 8, specially crafted ntp public key crypto method should be crafted. -- is there a good reason we cannot use an existing pki method?? Brian Haberman: Originally said had to use AutoKey, this new text is trying to get away from specifying autokey in the requirements doc. Yakov: We should try to use a standard method, should change the text to make it clear. Brian: I agree, makes sense, send text. Other point: Pat Cain did an assesssment of the autokey method itself. Should put this assessment out on the mailing list, since that will give us a baseline. Operational guidelines should be in other specs and not in requirements doc. Jim Martin: As we go through the protocol, we may discover that there are things defined in the current spec, that if we document is precisely, may not make it through the rfc process (see existing issue on autokey). Do we rev the version? What do we do if the spec diverges from the application? Yakov: If we assume that we're just doing an implementation documentation, why are we doing a requirements doc? Brian: We are trying to do both, the requirements doc is an attempt to look at the delta between the existing implementation and things that we may need for ntpv5. James Rafferty: Former chair of FAX, similar problems in that wg. Different communities differ in how they opearte, we need to keep lines of communication open so we don't break things. Jack Burbank: If this doc is attempting to address requirements for both v4 and v5, we might want to reconsider the title. Tony Hain: Perhaps we should split this into 2 docs, v4 and v5. Also put things that are likely to change into an v5 requirements doc. So the v4 doc says that this is a minimum set that is not likely to change. Dave: Easy to say, but the existing problem is that the current implemenation as done cannot pass ietf (e.g. autokey). Karen: Working on getting more closely hooked into the ntp community. NTPv4 is in flux, we need to try to coordinate this. One thing that was missing from the open issues, are tim frost's requirements from the pseudowire group. Mark Townsley: If ntpv4 is not done, then this is fine, and does the group plan to do some work on v4, then break and do v5. Karen: Yes. Mark: How do we split that? Karen: In working with the community, the changes that are immedietely pending in the developer community will go into v4, others will go to v5. Mark: If you go to IESG with a doc that exists vs. saying that this is the doc, and that this is what we merge to. These are different things. Dave: Inclined to the latter. Mark: Still unclear as to what we're targeting for what docs and processes. Dave: We're trying to write ietf-standard specs, that document what exists. Jim: It is possible that by the time we publish, things will be in sync. Worried that the developer community and the ietf community will diverge with regard to ntpv4. If developers and ietf are all on board, we converge to what ntpv4 should be. If that doesn't happen, maybe we need to do ntpv5. Mark: Now we get into the normal developer<>protocol designer conflicts. We need to get the developer community onboard. To reiterate: would be nice to have a clear def as to where the "should be" stops and when work on v5 starts. Tony: Affinity with the v4 label. Maybe we should be less concerned with the v4 label. ======== Jim Martin Presenting on NTPv4 Protocol draft -01. Work in progress, drawn on sntp draft. reorged the sections. clarified "manycast" mechanism. pulled in the control protocol that existed in the v3 spec. defined the modes of operation for ntp vs sntp. broke ptocol ops into client, server, and symmetric peer (to be done). manycast: removed all refs to anycast added a setion clearly definding the dynamic discovery mechanism. manycast is a dynamic discovery mechanism using an expanding-ring ttl/hop-count based multicast discovery mechanism. The expanding-ring expands until it gets max hop count or you reach the required server count. Pulled into a separate mechanism, removed refs to anycast. Control protocol: imported out of ntpv3 minor updates for v4, still need to go through the source and see if there are any changes. To do: document v4 options document symmetric peer ops document existing autokey so we can make a decision. determine what elements shoul dbe iana managed vet docs for sntp specific refs. copyedit (rev -03+). Once -02 and/or -03 are out, plan to circulate through the community to fix errors and the like. Targeting at least one rev, and preferably both before the next meeting (65, Dallas) ========== Bill Kasch presenting on -00 rev on algorithm draft. created to capture the algorithm info. based entirely on david mills draft book. 6 algorithms clock filter, clock selection, clustering, clock combining, polling, clock discipline Issues: nomenclature. incomplete polling info state machine shortcomings Need to get input from implementors. =========== Karen O'Donoghue presenting on Leap Second discussion background: IETF position on leap seconds, there is an ITU effort ITU-R 236/7. Dates back to 1999 to look at the future of UTC timescales. The ITU would like data on how leap seconds impact applicaitons and protocols. Karen posted ITU questions on slides. Ronald Beard is the ITU liason. IETF is responsible for a leap seconds position to send to ITU. No consensus yet: two positions - IETF shouldn't care - Don't do away with them (but need data on this). Peter Lothberg: Since we live on a planet that is slowing down, the clocks run consistently, but the earth does not. Need to sync up clocks with earth time. Committee for earth rotation speed sees we've slowed down more than 0.9 seconds we'll add or delete a second to sync up. A letter goes to vimp which gets published. You can add a leap second at the end of every month. Earlier we said that we were going to ignore this, but if we delete leap seconds then we cannot keep up with the time. We should factor this in so that regardless the internet can keep up. Tim Shepard: Worked for astronomers for 2 months years ago. And what I find astonishing is that the ITU has authority to decide what UTC means. Hesitant to suggest that the IETF should make any statement that agrees with ITU having authority to define this. Since this is well defined in the astronomy community, that I still keep up with. There is a volume of information on what UTC means that go backs to the 1970's and goes forward for a long time as well, so that in the 30th century they have a consistent time reference. TAI and UTC and leap seconds relationship is not something that the ITU should play with. Peter: ITU specifies UTC, full stop. UT-1 is specified by the astronomical community. Karen: Not having an opinion on this is fine, if that is the consensus. The issue with talking to the ITU folks, is what is the impact of UTC with leap seconds. Having leap seconds is something that causes problems, so ITU wants to know if the impact of removing it will be worse. Dave Plonka: Should leave it in. But a difference between the time distribution protocol and what the applicaiton does with it. Karen: Dave Mills agrees with that. Peter: If we are the time experts in the IETF, then our stand should be that our protocols should be able to correctly implement leap seconds, but if the user doesn't want to use them, that is fine. Karen: A profileration of timescales (UTC, GPS, etc.) are out there, one of the ITU concerns are that this causes confustion. Tim: Would have been nice is when ntp was deployed, you could also distrubute TAI which is a timescale that does not use leap seconds. Dave Mills 15 years ago, said he did not have an accurate timesource for TAI time. The only atomic-grade time source was UTC. Pehaps we should add a UTC-TAI offset information to NTPv5. Peter: The GPS navigation timescale is a snapshot of UTC when it was launched in the mid 1980's. Suggestion that Gallieo should be launched with TAI. Glonaz runs with UTC including leap seconds. Greg Dowd: As a manufactuer of time gear, this is just time shifting. NTP is just a dist protocol, the bits are not going away, leave 'em alone, unless you want to get into the os specs business. I believe the apps don't have any more trouble dealing with this than with daylight savings time. Brian: What we do owe the ITU is a document that at least states how leap seconds relates to the ntp protocol. Implementors: PLEASE HELP, so we can get the doc done. Karen: We have more time, we don't have to make a decision this week. Brian: Can we try to get this doc done by the end of the year. Mark: Perhaps we don't need a full doc, unless we need to give details. Brian: ITU is not asking us for an opinion, they are asking for data on how ntp deals with leap seconds. Mark: So long as something gets done, it doesn't have to be a doc. James: I have lots of ITU experience, ITU loves docs. ITU will want a doc, and ideally, send a person at the same meeting, to explain the doc, that is what will open communication lines. Mark Andrews: Disagee that this is the only group that deals with time. DNS deals with time as well. We had to make a decision, although I don't remember the decision. We should also look at these protocols. Karen: Good point, glad you made it, we shoud look at these, can you provide more info? Yakov: How to talk to ITU - need a liason statement, ITU processing is at least 3 weeks. Steve Cassner: Datapoint on RTP's use of NTP-format time. In RTP we pretend that leap seconds don't exist, since we're interested in keeping track of time intervals, not absolute time. So if you have 2 implementations one which include leap-seconds and one that does not, this could cause a problem. Doesn't happen very often. So this is not a strong datapoint to say that this has to be removed. Peter: We'll need to add complexity to the protocols to specify the timescales, because in 50 years, they'll be 30 seconds off. Karen: Yes, however today people are using GPS-feeds for ntp clock source. Which does not do leap seconds. Mark: What for ntpv4 Karen: We'll be UTC for ntpv4. Tim: Perhaps add something to ntpv5 that indicates timescale in the packet. Greg: NTP extensions format is open, but it is not defined that you can extend the format to include what you want. Has that been considered? Karen: No Greg: Good to have values which can be registered an extended. That way you can have time-related data be distributed. You could, for example, transmit the offset between two timescales. Yakov: ICMP has a timestamp. If some people are doing leap seconds and some are not, we'll have return times off. To circuit-em applications it might cause a failure. ============= Karen speaking on IEEE 1588 update. Work is progressing in the 1588 committees. There is a fair amount of overlap, and we have an ongoing discussion to coordinate the work between the two groups. |
None received.