* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ntp Status Pages

Network Time Protocol (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2005-Feb-25 —  

IETF-100 ntp minutes

Session 2017-11-13 1330-1530: VIP A - Audio stream - ntp chatroom


minutes-100-ntp-01 minutes

          NTP/TICTOC Joint Meeting
          November 13th, 2017, 13:30-15:30
          NTP WG Chairs: Karen O'Donoghue, Dieter Sibold
          TICTOC WG Chairs: Karen O'Donoghue, Yaakov Stein (absent)
          Note taker: Tal Mizrahi
          Jabber: Kyle Rose
          NTP Session
          CHAIR SLIDES
          Presenter: Karen O'Donoghue
          -   Karen presented the new note well.
          -   Control Messages Protocol for Use with Network Time Protocol Version
          4 draft:
              -   There are open questions how operators are currently using mode 6
              -   Would anyone be willing to help out Brian with the mode 6 draft?
              -   There are question about version numbering
              -   Question about the necessity to add additional commands to the
              mode 6 messages
              -   Robert Nagy: I volunteer.
          -   BCP
              -   is in the shepherding write-up stage
          -   NTP extension field draft:
              -   We will be putting together a consensus call about this issue
              after further discussion with the authors.
              -   Harlan: the authors got together a couple of times.
              -   Karen: the authors still need to agree. There seem to be two
              alternatives, and we want to be able to present the options to the
              working group.
          No slides were presented.
          -   Aanchal: will add the security considerations section in the next
          version of the draft.
          -   Tal: another comment was regarding whether this MAC could be included
          in an extension field.
          -   Aanchal: that was already discussed on the mailing list.
          -   Tal: another issue was there should be a subsection about
          interoperability with previous implementations.
          Presenter: Dieter Sibold
          - Kyle Rose: what is the plan for modes other than client/server?
          - Dieter: In the last interim meeting we talked about moving the other
          modes to another draft in the future.
          - Daniel Franke: I expect to write an experimental draft about these
          other modes.
          - Karen: is there a time frame for moving forward?
          - Dieter: not at this time. If we could have an interim meeting, we can
          talk about a plan in the interim.
          - Karen: it could be great if we could have a hackathon effort around
          NTS in IETF 101 in London.
          Presenter: Anil Kumar (remote)
          - Harlan: I am assuming there should be compatibility between the YANG
          model interface, the mode 6 interface, and the SNMP MIB interface.
          - Greg: why does this need to be compatible?
          - Harlan: functionally equivalent, not necessarily compatible.
          - Robert Nagy: I agree that it needs to be equivalent, but not
          compatible. When can we finally get this released? We don't want to
          continue to update this.
          - Greg: we want to standardize the base, and then we will be able to
          add extensions in the future.
          - Karen: What is your view on the compatibility with mode 6?
          - Anil: we did not try to have compatibility with mode 6. We believe it
          is functionally equivalent to the MIB.
          - Karen: Harlan, do you believe compatibility with mode 6 is really
          required? It seems that it is not a design objective.
          - Harlan: we want to make it easier on the user by having the three
          mechanisms as similar as possible.
          - Karen: it is not reasonable to require these three to be compatible,
          as mode 6 and the MIB go back a long time.
          - Harlan: let’s try to reach functional equivalence.
          - Anil: I will look into it with the other authors.
          Presenter: Tal Mizrahi
          - Greg: I believe this work is valuable. I would like to suggest clear
          terminology that distinguishes resolution from accuracy. Also suggest to
          discuss how to migrate to a higher accuracy. Another aspect that should be
          discussed is how the control plane communicates the timestamp format. In
          future we might need more resolution as provided by the truncated PTP
          timestamps. We might add a foresight discussion how to migrate to higher
          resolution timestamps.
          - Karen: what is the time frame for the next steps?
          - Tal: we hope to complete the open issues by the next IETF meeting and
          be ready for WG last call.
          Presenter: Aanchal Malhotra
          - Greg: when you say “improve the accuracy”, what do you mean?
          - Aanchal: the accuracy of the timestamp captured by the client or
          - Greg: when you timestamp in software, there may be nondeterministic
          error. The further you move from the demon, the less accurate it is.
          - Rich Salz: the time stamping is already in the kernel space. The
          further you move from the demon, the more accurate.
          - Tal: this is very similar to the PTP Follow_up messages. PTP uses
          Sequence ID to match the timestamp and the corresponding event message. Is
          there something similar in the proposed mechanism?
          - Aanchal: yes. The receiver verifies the origin timestamp and the
          transmit timestamp.
          - Tal: from a security perspective, it looks like if a MAC verification
          fails, you should also ignore the previous and next packet, as they are
          bound by the interleaved timestamps. Please consider this and add text
          about it to the draft.
          - Harlan: there was a discussion about where you get the most accurate
          timestamp: closest to the interface, or further from the demon. Both
          are correct, depending on the specific system. There was quite a bit of
          work by Dave Mills about Interleave mode. Regarding the MAC: either the
          MAC works or not, and we drop if it does not work. Interleave mode is
          a wonderful thing.
          - Kristof Teichel: this work is very important. Clarification question:
          does the server have to keep per-client states?
          - Aanchal: yes.
          - Robert: what you did is great. There are security issues that we need
          to think about. If we could avoid adding an additional field for that,
          it would be great.
          - Greg: regarding PTP Follow_up messages: what is the frequency of the
          messages from the client to the server? By delaying the information
          to the next query, we increase the interval. If we had used something
          similar to Follow_up messages, the information would be used immediately.
          - Karen: please summarize this proposal on the mailing list.
          - Aanchal: delay is not an issue here.
          - Harlan: interleave mode is most useful in symmetric mode, and less
          useful in client/server mode.
          Presenter: Aanchal Malhotra
          - Greg: a timestamp is not necessarily based on wall clock time. It can
          be relative, or can be based on any reference.
          - Willem Toorop: a timestamp is a point in time expressed in wall time.
          - Greg: it is important to agree on the dictionary.
          - Harlan: it is unfair to describe some of these issues in the context
          of NTP.
          - Kristof: this work is important. Where can the document be found?
          - Aanchal: it is on the agenda.
          - Kristof: please use the term monotonic more carefully – need to
          define it.
          - Greg: only NTP is used as a reference to this draft.
          - Tal: it is important to clearly define the scope of the document, and
          the target audience. Another issue is that the intended status should
          probably be informational.
          - Karen: the scope is very important.
          - Ethan Grossman: one of the things that was not clear was what the draft
          was focusing on: implementation considerations, or security aspects.
          - Karen: can we have an update to the draft before we start call for
          - Aanchal: we would be happy if people could send their comments on the
          mailing list.
          TICTOC Session
          CHAIR SLIDES
          Presenter: Karen O'Donoghue
          A YANG DATA MODEL FOR IEEE 1588v2
          Presenter: Yuanlong Jiang
          - Karen: one remaining unresolved issue. Once we resolve that issue,
          there is probably no need for another WG last call.
          - Yuanlong: we are looking into it, and I will update the mailing list
          once we resolve it.
          - Suresh Krishnan: has this been reviewed by a YANG expert? Will need
          to be.
          - Karen: there was no official YANG doctor review, but it was reviewed
          by YANG experts. We can do a formal YANG doctor review.
          - Suresh: please do that when the document is ready.
          - Yuanlong: we sent version 05 to the NETMOD working group. We received
          comments on the mailing list. We have not received any formal comments
          from a YANG doctor.

Generated from PyHt script /wg/ntp/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -