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.