Skip to main content

A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos
draft-ietf-ntp-chronos-25

Revision differences

Document history

Date Rev. By Action
2024-02-21
(System)
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-ntp-chronos and RFC 9523, changed IESG state to RFC …
Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-ntp-chronos and RFC 9523, changed IESG state to RFC Published)
2024-02-20
25 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2024-01-03
25 (System) RFC Editor state changed to AUTH48
2023-10-27
25 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2023-10-06
25 (System) IANA Action state changed to No IANA Actions from In Progress
2023-09-08
25 (System) RFC Editor state changed to EDIT
2023-09-08
25 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2023-09-08
25 (System) Announcement was received by RFC Editor
2023-09-08
25 (System) IANA Action state changed to In Progress
2023-09-08
25 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2023-09-08
25 Cindy Morgan IESG has approved the document
2023-09-08
25 Cindy Morgan Closed "Approve" ballot
2023-09-08
25 Cindy Morgan Ballot approval text was generated
2023-09-08
25 (System) Removed all action holders (IESG state changed)
2023-09-08
25 Erik Kline IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2023-08-30
25 Paul Wouters [Ballot comment]
Thanks for addressing the concerns raised by me and other ADs. I have updated my ballot to No Objection.
2023-08-30
25 Paul Wouters [Ballot Position Update] Position for Paul Wouters has been changed to No Objection from Discuss
2023-08-29
25 Neta Schiff New version available: draft-ietf-ntp-chronos-25.txt
2023-08-29
25 Neta Schiff New version accepted (logged-in submitter: Neta Schiff)
2023-08-29
25 Neta Schiff Uploaded new revision
2023-08-20
24 Neta Schiff New version available: draft-ietf-ntp-chronos-24.txt
2023-08-20
24 (System) New version approved
2023-08-20
24 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-08-20
24 Neta Schiff Uploaded new revision
2023-08-19
23 Barry Leiba Closed request for Last Call review by ARTART with state 'Overtaken by Events'
2023-08-19
23 Barry Leiba Assignment of request for Last Call review by ARTART to Claudio Allocchio was marked no-response
2023-07-27
23 Neta Schiff New version available: draft-ietf-ntp-chronos-23.txt
2023-07-27
23 (System) New version approved
2023-07-27
23 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-07-27
23 Neta Schiff Uploaded new revision
2023-07-26
22 Neta Schiff New version available: draft-ietf-ntp-chronos-22.txt
2023-07-26
22 (System) New version approved
2023-07-26
22 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-07-26
22 Neta Schiff Uploaded new revision
2023-07-23
21 (System) Changed action holders to Erik Kline (IESG state changed)
2023-07-23
21 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-07-23
21 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2023-07-23
21 Neta Schiff New version available: draft-ietf-ntp-chronos-21.txt
2023-07-23
21 (System) New version approved
2023-07-23
21 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-07-23
21 Neta Schiff Uploaded new revision
2023-07-18
20 Karen O'Donoghue Added to session: IETF-117: ntp  Fri-1900
2023-07-13
20 (System) Changed action holders to Erik Kline, Neta Schiff, Danny Dolev, Tal Mizrahi, Michael Schapira (IESG state changed)
2023-07-13
20 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2023-07-13
20 Robert Wilton
[Ballot comment]
Hi,

Thanks for this document.

I support Paul's discuss.

Minor level comments:

(1) p 0, sec

  Since it does not affect the …
[Ballot comment]
Hi,

Thanks for this document.

I support Paul's discuss.

Minor level comments:

(1) p 0, sec

  Since it does not affect the wire protocol, the Khronos mechanism is
  applicable to current and future time protocols.

Saying it is applicable to future time protocols seems to be quite a strong assertion to make.  E.g., would it still be applicable if future time protocols had a very different protocol structure?


(2) p 3, sec 1.  Introduction

  Khronos introduces a watchdog mechanism that maintains a time offset
  value that is used as a reference for detecting attacks.  The time
  offset value computation differs from the current NTPv4 in two key
  aspects.  First, Khronos periodically communicates, in each Khronos
  poll interval, with only a few (tens) randomly selected servers out
  of a pool consisting of a large number (e.g., hundreds) of NTP
  servers, thereby providing high security while minimizing the load on
  the NTP servers.  Second, Khronos computes "Khronos time offset"
  based on an approximate agreement technique to remove outliers, thus
  limiting the attacker's ability to contaminate the "time samples"
  (offsets) derived from the queried NTP servers.  These two elements
  of Khronos's design provide provable security guarantees against both
  man-in-the-middle attackers and attackers capable of compromising a
  large number of NTP servers.

Bits of the introduction text feel a bit repetitive.


(3) p 9, sec 4.3.  Security Analysis Overview

  In the second scenario, where the attacker controls more than 2/3 of
  the queried servers, the worst possibility for the client is that all
  remaining samples are malicious (i.e., more than w away from UTC).
  However, as proved in [Khronos_paper], the probability of this
  scenario is extremely low even if the attacker controls a large
  fraction (e.g., 1/4) of the n servers in the local Khronos pool.
  Therefore, the probability that the attacker repeatedly reaches this
  scenario decreases exponentially, rendering the probability of a
  significant time shift negligible.  We can express the improvement
  ratio of Khronos over NTPv4 by the ratios of their single shift
  probabilities.  Such ratios are provided in Table Table 2, where
  higher values indicate higher improvement of Khronos over NTPv4 and
  are also proportional to the expected time till a time shift attack
  succeeds once.

I'm not an NTP or security expert, but if the NTP clients were attached to a stub network (e.g., perhaps connected to Wi-Fi in a coffee shop), then is it plausible that an on-path attacker (e.g., that had control of the Wi-Fi gateway router) would be able to delay all downstream NTP packets towards the client, perhaps randomly by 30-45 seconds?  Would this allow a single compromise in the network to bypass the protection that Khronos is offering?


(4) p 12, sec 9.2.  Informative References

  [Khronos_paper]
              Deutsch, O., Schiff, N.R., Dolev, D., and M. Schapira,
              "Preventing (Network) Time Travel with Chronos", 2018,
              .

This has been listed as informative, but if you are leaning on it for your security considerations at all, it might be better being normative.



Nit level comments:

(5) p 8, sec 4.1.  Threat Model

  Moreover, Khronos uses randomness to independently select the queried
  servers in each poll interval, making it imune to attackers that
  aware of its implementation and past communications.

imune -> immune.  The end of the sentence also doesn't scan.

Regards,
Rob
2023-07-13
20 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2023-07-13
20 Zaheduzzaman Sarker [Ballot comment]
Thanks for working on this specification. Thanks to Tommy for his TSVART review.

I have not find TSV related issues in my review.
2023-07-13
20 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2023-07-13
20 Murray Kucherawy [Ballot comment]
I support Paul's DISCUSS position.
2023-07-13
20 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2023-07-13
20 Andrew Alston [Ballot Position Update] New position, No Objection, has been recorded for Andrew Alston
2023-07-12
20 Roman Danyliw
[Ballot comment]
Thank you to Benjamin M. Schwartz’s SECDIR review.

I support Paul Wouter’s DISCUSS position.

** Per the document status, was there WG discussion …
[Ballot comment]
Thank you to Benjamin M. Schwartz’s SECDIR review.

I support Paul Wouter’s DISCUSS position.

** Per the document status, was there WG discussion on making this document experimental status instead of informational? I don’t have a sense of how much field validation there is of this approach.

** IDnits reported:
  == Unused Reference: 'RFC2119' is defined on line 560, but no explicit
    reference was found in the text

** I don’t fully understand what a “watchdog” is.  It would be helpful to clarify what is being described and the notional implementation mechanism.

-- is “Khronos” an algorithm and this is guidance to NTP client implementers?  Is there a “Khronos application” and an unmodified “NTP application”?

-- Is there any interoperability being described here?

-- Per Warren’s ballot, when “Khronos” detects malfeasance, how does it interact with OS or what new behavior does it introduce to a NTP client?

** Section 3.
  Based on
  empirical analyses, to minimize the load on NTP servers while
  providing high security, the Khronos poll interval should be around
  10 times the NTPv4 poll interval

Since the guidance is “should be around 10 times”, when would you deviate from “10 times”?

** Section 3.1
  Calibration is performed at the first time the Khronos is executed,
  and also periodically, once in a long time (e.g., every few weeks/
  months).

“Every few weeks” to “months” seems like a large spread of time.  What guides the calibration window?

** Section 3.2.
  Note that the randomness of the
  server selection is crucial for the security of the scheme and
  therefore any Khronos implementation should use secure randomness
  implementation such as used for encryption key generation.

If “randomness of the server selection is crucial”, why isn’t it mandatory for Khronos implementations to use a secure randomness implementation?  Specification s/implementations should use/implementations must use/
2023-07-12
20 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2023-07-12
20 Warren Kumari
[Ballot comment]
Thank you for this document. While I agree with Paul Wouters that it does read somewhat like a whitepaper / research paper, I'll …
[Ballot comment]
Thank you for this document. While I agree with Paul Wouters that it does read somewhat like a whitepaper / research paper, I'll also note that it is an Informational RFC, "published for the general information of the Internet community".

I *do* however agree that the pseudo-code / actual description of how to run this should come before the Security Considerations section. I also think that there should be more text about what happens when an attack is detected -- "Under attack, Khronos takes control over the clients clock in order to prevent its shift." - I'd **assume** that this is more "take control over the clients clock to prevent its shift **and also spews scary warnings all over the logs and sets the alarm bells ringing and calls in the black helicopters**" (or something along those lines).

I'd also like to thank Geoff Huston for his helpful DNSDIR review - like others have noted, it does seem like this should have some discussions around NTS -- at the moment all it says is: "However, adding an authentication layer (e.g., NTS [RFC8915]) to Khronos will enhance its security guarantees and enable the detection of various spoofing and modification attacks.". While true, it does feel like there should be some more discussion around the interaction between these.

I'd also like to thank Tianran for the helpful OpsDir review, and suggest that the authors review his comments.
2023-07-12
20 Warren Kumari Ballot comment text updated for Warren Kumari
2023-07-12
20 Warren Kumari
[Ballot comment]
Thank you for this document. While I agree with Paul Wouters that it does read somewhat like a whitepaper / research paper, I'll …
[Ballot comment]
Thank you for this document. While I agree with Paul Wouters that it does read somewhat like a whitepaper / research paper, I'll also note that it is an Informational RFC, "published for the general information of the Internet community".

I *do* however agree that the pseudo-code / actual description of how to run this should come before the Security Considerations section. I also think that there should be more text about what happens when an attack is detected -- "Under attack, Khronos takes control over the clients clock in order to prevent its shift." - I'd **assume** that this is more "take control over the clients clock to prevent its shift **and also spews scary warnings all over the logs and sets the alarm bells ringing and calls in the black helicopters**" (or something along those lines).

I'd also like to thank Geoff Huston for his helpful DNSDIR review - like others have noted, it does seem like this should have some discussions around NTS -- at the moment all it says is: "However, adding an authentication layer (e.g., NTS [RFC8915]) to Khronos will enhance its security guarantees and enable the detection of various spoofing and modification attacks.". While true, it does feel like there should be some more discussion around the interaction between these.
2023-07-12
20 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2023-07-12
20 Martin Duke
[Ballot comment]
Thanks for this document, and to Tommy Pauly for the TSVART review.

From the Introduction:
"Khronos can be integrated into NTPv4-compatible servers as …
[Ballot comment]
Thanks for this document, and to Tommy Pauly for the TSVART review.

From the Introduction:
"Khronos can be integrated into NTPv4-compatible servers as an NTPv4 client's "watchdog" against time shifting attacks."

From reading the rest of this document, I don't understand how any part of this spec affects servers at all.
2023-07-12
20 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2023-07-11
20 John Scudder
[Ballot comment]
- I support Paul Wouters' DISCUSS.

- I agree with Éric Vyncke's comments and in particular the one about "specifies".

- Note that …
[Ballot comment]
- I support Paul Wouters' DISCUSS.

- I agree with Éric Vyncke's comments and in particular the one about "specifies".

- Note that the term "man-in-the-middle" is somewhat dated, perhaps consider something like "on-path attacker"? [1]

- Although you provide a reference to the security properties analyzed for Khronos, you don't mention to what, if any, extent Khronos might be expected to produce false positives, and what deleterious effect this might have on expected time synchronization accuracy. Have you analyzed this? Section 6 gives the superficial appearance of speaking to this question, but doesn't really answer it as far as I can tell.

- I don't follow the pseudocode idiom you're using. You use a Pascal-like assignment operator of := on most lines, but in the second and third lines you use the = operator. I guess that's not assignment. It's not a test. So what is it?

[1] https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/
2023-07-11
20 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2023-07-11
20 Paul Wouters
[Ballot discuss]
This document reads more like a white paper or research paper than an RFC. I also find naming this protocol (Chronos or Khronos?) …
[Ballot discuss]
This document reads more like a white paper or research paper than an RFC. I also find naming this protocol (Chronos or Khronos?) a bit strange, as it is not really a new protocol but more a configuration suggestion of existing NTPv4 parameters.

If I try to reduce the text to that was it really required for implementers, it would be something like:
- Instead of 2 or 3 system configured NTP servers (eg obtained via DHCP options or hardcoded configuration), use a dozen from a well known pool (eg pool.ntp.org) of a few hundred.
- Throw away the top 1/3 and bottom 1/3. Average the remainder. If too far from current time, get fresh samples. (note this isn't a recursive process, so I'm not sure what to do when the fresh samples have the same issues as the original samples)
- Repeat after X time.

It would be good to have a straightforward short section with an concise specification. The pseudo code section is sort of that, but doesn't say anything about timings and when to get how many samples. This section should appear before the Security Considerations section, or else the security section is read without the reader having a proper context.

The document declares out of scope attackers that can delay (practically) all NTP answers, but that is exactly what you would encounter at like a coffee shop or hotel wifi, or being on mobile data with a malicious/compromised telco.

If this protocol is more suited towards datacentre (DC) deployments and not mobile endusers, than another issue comes up. In DCs specifically, one tends to rely on the local NTP servers and for security reasons often won't allow connections to NTP servers outside of the DC. Those local NTP servers could even have their own atomic clock or other hardware to make them specifically much more reliable than random NTP servers on the net that have all sync'ed to/from each other in a large pool.

How does this document solve a problem that NTS does not solve? I assume one use case is if the few target NTS servers configured would be compromised? But is that an issue that current NTP clients are being attacked with?  What would the harm be for most clients to have their time off by say 30 seconds ? That is, who should implement and run this ?

Perhaps an Operational Considerations Section could explain this? Who should run this where and when? Where should one not run this?
2023-07-11
20 Paul Wouters [Ballot Position Update] New position, Discuss, has been recorded for Paul Wouters
2023-07-11
20 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2023-07-11
20 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ntp-chronos-20

Thank you for the work put into this document.

Please find below some non-blocking COMMENT …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-ntp-chronos-20

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Dieter Sibold for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status.

Other thanks to Geoff Huston, the DNS directorate reviewer, please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-ntp-chronos-14-dnsdir-lc-huston-2023-06-08/(and I have read Neta's reply)

Other thanks to Tim Chown, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-ntp-chronos-17-intdir-telechat-chown-2023-07-03/ (and I have read the exchange between Tim and the authors)

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS

## Chronos or Khronos

Just curious about the use of Khronos in the text and Chronos in the filename and in the academic paper ;-)

## Unused reference

Please remove RFC 2119 from the normative references list as it is not used.

## Intended status

I would have assumed that this I-D would have been experimental rather than informational. *NO* justification/explanation is given in the shepherd write-up :-(

## Abstract

s/This document specifies an extension to the NTPv4 client/This document describes a companion application to the NTPv4 client/. Being informative, it cannot really 'specify' and 'extension' could be understood as protocol update. Let's be clear ;-)

As a side note, is the code for this Khronos 'extension' public and available somewhere ? This could be useful.

## Section 3.1

I have in mind that pool.ntp.org authoritative DNS servers answers are influenced by the IP address of the resolver. If this is the case, then isn't the 'Khronos pool' a little bias to a region?

## Section 4.1

`However, adding an authentication layer (e.g., NTS [RFC8915]) to Khronos will enhance its security guarantees` While probably true, I wonder whether a future-looking statement like this one has a place in the security considerations.

I also wonder about the attack (2) as an ISP could easily intercept all UDP/123 packets and delay them. In this case, Khronos would not help too much.
2023-07-11
20 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2023-07-10
20 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even. Review has been revised by Roni Even.
2023-07-10
20 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2023-07-07
20 Neta Schiff New version available: draft-ietf-ntp-chronos-20.txt
2023-07-07
20 (System) New version approved
2023-07-07
20 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-07-07
20 Neta Schiff Uploaded new revision
2023-07-06
19 Neta Schiff New version available: draft-ietf-ntp-chronos-19.txt
2023-07-06
19 (System) New version approved
2023-07-06
19 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-07-06
19 Neta Schiff Uploaded new revision
2023-07-04
18 Neta Schiff New version available: draft-ietf-ntp-chronos-18.txt
2023-07-04
18 (System) New version approved
2023-07-04
18 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-07-04
18 Neta Schiff Uploaded new revision
2023-07-03
17 Tim Chown Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Tim Chown. Sent review to list.
2023-07-02
17 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2023-07-02
17 Neta Schiff New version available: draft-ietf-ntp-chronos-17.txt
2023-07-02
17 (System) New version approved
2023-07-02
17 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-07-02
17 Neta Schiff Uploaded new revision
2023-06-26
16 Amy Vezza Telechat date has been changed to 2023-07-13 from 2023-07-06
2023-06-25
16 Tianran Zhou Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Tianran Zhou. Sent review to list.
2023-06-24
16 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Tim Chown
2023-06-23
16 Éric Vyncke Requested Telechat review by INTDIR
2023-06-23
16 Amy Vezza Placed on agenda for telechat - 2023-07-06
2023-06-22
16 Benjamin Schwartz Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Benjamin Schwartz. Sent review to list. Submission of review completed at an earlier date.
2023-06-22
16 Benjamin Schwartz Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Benjamin Schwartz.
2023-06-22
16 Erik Kline Ballot has been issued
2023-06-22
16 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2023-06-22
16 Erik Kline Created "Approve" ballot
2023-06-22
16 Erik Kline IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2023-06-22
16 Erik Kline Ballot writeup was changed
2023-06-22
16 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2023-06-20
16 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2023-06-20
16 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ntp-chronos-16, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-ntp-chronos-16, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Specialist
2023-06-19
16 Tommy Pauly
Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Tommy Pauly. Sent review to list. Submission of review completed at an earlier …
Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Tommy Pauly. Sent review to list. Submission of review completed at an earlier date.
2023-06-19
16 Tommy Pauly Request for Last Call review by TSVART Completed: Ready with Nits. Reviewer: Tommy Pauly.
2023-06-15
16 Neta Schiff New version available: draft-ietf-ntp-chronos-16.txt
2023-06-15
16 (System) New version approved
2023-06-15
16 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-06-15
16 Neta Schiff Uploaded new revision
2023-06-15
15 Neta Schiff New version available: draft-ietf-ntp-chronos-15.txt
2023-06-15
15 (System) New version approved
2023-06-15
15 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-06-15
15 Neta Schiff Uploaded new revision
2023-06-15
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Benjamin Schwartz
2023-06-15
14 Magnus Westerlund Request for Last Call review by TSVART is assigned to Tommy Pauly
2023-06-12
14 Roni Even Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Roni Even. Sent review to list.
2023-06-12
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tianran Zhou
2023-06-09
14 Barry Leiba Request for Last Call review by ARTART is assigned to Claudio Allocchio
2023-06-08
14 Geoff Huston Request for Last Call review by DNSDIR Completed: Ready. Reviewer: Geoff Huston. Sent review to list.
2023-06-08
14 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2023-06-08
14 Jim Reid Request for Last Call review by DNSDIR is assigned to Geoff Huston
2023-06-08
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2023-06-08
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2023-06-22):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ntp-chronos@ietf.org, dsibold.ietf@gmail.com, ek.ietf@gmail.com, ntp-chairs@ietf.org, ntp@ietf.org …
The following Last Call announcement was sent out (ends 2023-06-22):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ntp-chronos@ietf.org, dsibold.ietf@gmail.com, ek.ietf@gmail.com, ntp-chairs@ietf.org, ntp@ietf.org, odonoghue@isoc.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Secure Selection and Filtering Mechanism for the Network Time Protocol with Khronos) to Informational RFC


The IESG has received a request from the Network Time Protocols WG (ntp) to
consider the following document: - 'A Secure Selection and Filtering
Mechanism for the Network Time
  Protocol with Khronos'
  as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2023-06-22. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The Network Time Protocol version 4 (NTPv4), as defined in RFC 5905,
  is the mechanism used by NTP clients to synchronize with NTP servers
  across the Internet.  This document specifies an extension to the
  NTPv4 client, named Khronos, which is used as a "watchdog" alongside
  NTPv4, and provides improved security against time shifting attacks.
  Khronos involves changes to the NTP client's system process only.
  Since it does not affect the wire protocol, the Khronos mechanism is
  applicable to any current or future time protocol.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-ntp-chronos/



No IPR declarations have been submitted directly on this I-D.




2023-06-08
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2023-06-08
14 Cindy Morgan Last call announcement was generated
2023-06-07
14 Erik Kline Last call was requested
2023-06-07
14 Erik Kline Last call announcement was generated
2023-06-07
14 Erik Kline Ballot approval text was generated
2023-06-07
14 Erik Kline Ballot writeup was generated
2023-06-07
14 Erik Kline IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2023-06-07
14 (System) Changed action holders to Erik Kline (IESG state changed)
2023-06-07
14 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2023-06-07
14 Neta Schiff New version available: draft-ietf-ntp-chronos-14.txt
2023-06-07
14 (System) New version approved
2023-06-07
14 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-06-07
14 Neta Schiff Uploaded new revision
2023-06-05
13 Erik Kline
# Internet AD comments for draft-ietf-ntp-chronos-13
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* Just a few easy-to-address points, I think, and then we …
# Internet AD comments for draft-ietf-ntp-chronos-13
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* Just a few easy-to-address points, I think, and then we can advance a
  revised I-D to IETF Last Call.  Thanks!

## Discuss

### S3.1

* I think some comment about respecting DNS TLLs is probably warranted here.
  Storing and using IP addresses for hostnames beyond their TTL expiration is
  not in keeping with recommended uses of the DNS.

## Comments

### S1

* The phrase "man-in-the-middle (MitM)" will likely be highlighted during
  someone's terminology review.  Perhaps "malefactor-in-the-middle", which
  allows for the MitM initialism to remain unchanged.

  This change should be considered for throughout the document.

### S2.1

* As this is Informational, should (SHOULD) we remove this section?

### S3.3

* "we recommend to use" -> "it is recommended to use"

## Nits

### S1

* s/interfering the communication/interfering with the communication/

* s/Khorons/Khronos/

* "this security analyses"

  -> "this security analysis"
  or "these security analyses"

* "by a man-in-the-middle, attacker" -> "by an attacker,"

### S3

* "is referred as" -> "is referred to as"
2023-06-05
13 (System) Changed action holders to Danny Dolev, Erik Kline, Tal Mizrahi, Michael Schapira, Neta Schiff (IESG state changed)
2023-06-05
13 Erik Kline IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2023-03-29
13 (System) Changed action holders to Erik Kline (IESG state changed)
2023-03-29
13 Erik Kline IESG state changed to AD Evaluation from Publication Requested
2023-03-20
13 Karen O'Donoghue


# Document Shepherd Write-Up for Group Documents #

*Version of the template: 4 July 2022.*

1. Does the working group (WG) consensus represent the strong …


# Document Shepherd Write-Up for Group Documents #

*Version of the template: 4 July 2022.*

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? 
 
The document has working groups consensus for publication. One person expressed opposition. Others either have added supportive comments or have been silent.

1. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? 
 
There has been no controversy about particular points.

1. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 
 
Nobody threatened an appeal or otherwise indicated extrem discontent. 


1. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942](https://datatracker.ietf.org/doc/rfc7942/) recommends) or elsewhere (where)? 
 
The authors have two PoC implementations: one in python the other in C. In addition one ntpd project has setup a project to implement Khronos in the NTPd code base.

1. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. 
 
The document does not contain content that would benefit from additional review of other IETF working groups or external organizations.

1. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 
 
The document does not need expert review from the MIB Doctor, YANG Doctor, media type, and URI type reviews.

1. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools](https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342](https://datatracker.ietf.org/doc/rfc8342/)? 
 
The document does not contain a YANG module.

1. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. 
 
The document does not contain section which are written in a formal language.

1. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? 
 
The document is clearly written, complete und correctly designed. Therefore, it is considered ready to be handed off the responsible AD. 

1. Several IETF Areas have assembled [lists of common issues that their reviewers encounter](https://trac.ietf.org/trac/iesg/wiki/ExpertTopics). For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? 
 
The common issues as compiled in the list mentioned above are not applicable to the document considered.

1. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? 
 
The intended status of this document is informational. The datatracker reflects the correct intended RFC status.

1. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79](https://datatracker.ietf.org/doc/bcp79/)? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. 
 
There are no IPR filings on this document. The document shepherd has received confirmation from the authors that they are not aware of any IPR around this  document.

1. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. 
 
The document shepherd has received confirmation from the authors that they are willing to be listed as authors of this document.

1. Document any remaining I-D nits in this document. Simply running the [idnits tool](https://www.ietf.org/tools/idnits/) is not enough; please review the ["Content Guidelines" on authors.ietf.org](https://authors.ietf.org/en/content-guidelines-overview) (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) 
 
The idnits tool compiles following issues:

    * Error: There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72.
    * Two warnings:
        1. One instance of line with non-RFC2606-compliant FQDNs: [0.pool.ntp.org](http://0.pool.ntp.org) and [1.pool.ntp.org](http://1.pool.ntp.org). These are well-known FQDNs which compiles large number of public available NTP-Servers. The use of these FQDNs supports the purpose of this document.
        2. The document does not use RFC 2119 keywords. The document describes a client algorithm that does not affect NTP servers or non-Khronos clients. The NTP on-wire protocol is not changed and it does not intend to update RFC 5905. The intended status of the document is informational. For these reasons the abstain from RFC 2119 keywords is appropriate.


1. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References](https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/). 
 
The classification of the references is done correctly. There is no need for change.

1. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? 
 
All normative references are freely available. The community did have sufficient access to review these references.

1. Are there any normative downward references (see [RFC 3967](https://datatracker.ietf.org/doc/rfc3967/) and [BCP 97](https://www.rfc-editor.org/info/bcp97)) that are not already listed in the [DOWNREF registry](https://datatracker.ietf.org/doc/downref/)? If so, list them. 
 
There are no normative downward references.

1. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? 
 
All normative references are completed.

1. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. 
 
This document will not change the status of any existing RFC.

1. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126](https://datatracker.ietf.org/doc/rfc8126/)). 
 
The document does not define any request to IANA.

1. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. 
 
The document does not define any request to IANA.
2023-03-20
13 Karen O'Donoghue Responsible AD changed to Erik Kline
2023-03-20
13 Karen O'Donoghue IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2023-03-20
13 Karen O'Donoghue IESG state changed to Publication Requested from I-D Exists
2023-03-20
13 Karen O'Donoghue Document is now in IESG state Publication Requested
2023-03-15
13 Dieter Sibold


# Document Shepherd Write-Up for Group Documents #

*Version of the template: 4 July 2022.*

1. Does the working group (WG) consensus represent the strong …


# Document Shepherd Write-Up for Group Documents #

*Version of the template: 4 July 2022.*

1. Does the working group (WG) consensus represent the strong concurrence of a few individuals, with others being silent, or did it reach broad agreement? 
 
The document has working groups consensus for publication. One person expressed opposition. Others either have added supportive comments or have been silent.

1. Was there controversy about particular points, or were there decisions where the consensus was particularly rough? 
 
There has been no controversy about particular points.

1. Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) 
 
Nobody threatened an appeal or otherwise indicated extrem discontent. 


1. For protocol documents, are there existing implementations of the contents of the document? Have a significant number of potential implementers indicated plans to implement? Are any existing implementations reported somewhere, either in the document itself (as [RFC 7942](https://datatracker.ietf.org/doc/rfc7942/) recommends) or elsewhere (where)? 
 
The authors have two PoC implementations: one in python the other in C. In addition one ntpd project has setup a project to implement Khronos in the NTPd code base.

1. Do the contents of this document closely interact with technologies in other IETF working groups or external organizations, and would it therefore benefit from their review? Have those reviews occurred? If yes, describe which reviews took place. 
 
The document does not contain content that would benefit from additional review of other IETF working groups or external organizations.

1. Describe how the document meets any required formal expert review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews. 
 
The document does not need expert review from the MIB Doctor, YANG Doctor, media type, and URI type reviews.

1. If the document contains a YANG module, has the final version of the module been checked with any of the [recommended validation tools](https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in [RFC 8342](https://datatracker.ietf.org/doc/rfc8342/)? 
 
The document does not contain a YANG module.

1. Describe reviews and automated checks performed to validate sections of the final version of the document written in a formal language, such as XML code, BNF rules, MIB definitions, CBOR's CDDL, etc. 
 
The document does not contain section which are written in a formal language.

1. Based on the shepherd's review of the document, is it their opinion that this document is needed, clearly written, complete, correctly designed, and ready to be handed off to the responsible Area Director? 
 
The document is clearly written, complete und correctly designed. Therefore, it is considered ready to be handed off the responsible AD. 

1. Several IETF Areas have assembled [lists of common issues that their reviewers encounter](https://trac.ietf.org/trac/iesg/wiki/ExpertTopics). For which areas have such issues been identified and addressed? For which does this still need to happen in subsequent reviews? 
 
The common issues as compiled in the list mentioned above are not applicable to the document considered.

1. What type of RFC publication is being requested on the IETF stream (Best Current Practice, Proposed Standard, Internet Standard, Informational, Experimental or Historic)? Why is this the proper type of RFC? Do all Datatracker state attributes correctly reflect this intent? 
 
The intended status of this document is informational. The datatracker reflects the correct intended RFC status.

1. Have reasonable efforts been made to remind all authors of the intellectual property rights (IPR) disclosure obligations described in [BCP 79](https://datatracker.ietf.org/doc/bcp79/)? To the best of your knowledge, have all required disclosures been filed? If not, explain why. If yes, summarize any relevant discussion, including links to publicly-available messages when applicable. 
 
There are no IPR filings on this document. The document shepherd has received confirmation from the authors that they are not aware of any IPR around this  document.

1. Has each author, editor, and contributor shown their willingness to be listed as such? If the total number of authors and editors on the front page is greater than five, please provide a justification. 
 
The document shepherd has received confirmation from the authors that they are willing to be listed as authors of this document.

1. Document any remaining I-D nits in this document. Simply running the [idnits tool](https://www.ietf.org/tools/idnits/) is not enough; please review the ["Content Guidelines" on authors.ietf.org](https://authors.ietf.org/en/content-guidelines-overview) (Also note that the current idnits tool generates some incorrect warnings; a rewrite is underway.) 
 
The idnits tool compiles following issues:

    * Error: There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72.
    * Two warnings:
        1. One instance of line with non-RFC2606-compliant FQDNs: [0.pool.ntp.org](http://0.pool.ntp.org) and [1.pool.ntp.org](http://1.pool.ntp.org). These are well-known FQDNs which compiles large number of public available NTP-Servers. The use of these FQDNs supports the purpose of this document.
        2. The document does not use RFC 2119 keywords. The document describes a client algorithm that does not affect NTP servers or non-Khronos clients. The NTP on-wire protocol is not changed and it does not intend to update RFC 5905. The intended status of the document is informational. For these reasons the abstain from RFC 2119 keywords is appropriate.


1. Should any informative references be normative or vice-versa? See the [IESG Statement on Normative and Informative References](https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/). 
 
The classification of the references is done correctly. There is no need for change.

1. List any normative references that are not freely available to anyone. Did the community have sufficient access to review any such normative references? 
 
All normative references are freely available. The community did have sufficient access to review these references.

1. Are there any normative downward references (see [RFC 3967](https://datatracker.ietf.org/doc/rfc3967/) and [BCP 97](https://www.rfc-editor.org/info/bcp97)) that are not already listed in the [DOWNREF registry](https://datatracker.ietf.org/doc/downref/)? If so, list them. 
 
There are no normative downward references.

1. Are there normative references to documents that are not ready to be submitted to the IESG for publication or are otherwise in an unclear state? If so, what is the plan for their completion? 
 
All normative references are completed.

1. Will publication of this document change the status of any existing RFCs? If so, does the Datatracker metadata correctly reflect this and are those RFCs listed on the title page, in the abstract, and discussed in the introduction? If not, explain why and point to the part of the document where the relationship of this document to these other RFCs is discussed. 
 
This document will not change the status of any existing RFC.

1. Describe the document shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all aspects of the document requiring IANA assignments are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that each newly created IANA registry specifies its initial contents, allocations procedures, and a reasonable name (see [RFC 8126](https://datatracker.ietf.org/doc/rfc8126/)). 
 
The document does not define any request to IANA.

1. List any new IANA registries that require Designated Expert Review for future allocations. Are the instructions to the Designated Expert clear? Please include suggestions of designated experts, if appropriate. 
 
The document does not define any request to IANA.
2023-02-07
13 Neta Schiff New version available: draft-ietf-ntp-chronos-13.txt
2023-02-07
13 (System) New version approved
2023-02-07
13 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2023-02-07
13 Neta Schiff Uploaded new revision
2022-11-07
12 Neta Schiff New version available: draft-ietf-ntp-chronos-12.txt
2022-11-07
12 Neta Schiff New version accepted (logged-in submitter: Neta Schiff)
2022-11-07
12 Neta Schiff Uploaded new revision
2022-11-07
11 Neta Schiff New version available: draft-ietf-ntp-chronos-11.txt
2022-11-07
11 Neta Schiff New version accepted (logged-in submitter: Neta Schiff)
2022-11-07
11 Neta Schiff Uploaded new revision
2022-11-07
10 Dieter Sibold Added to session: IETF-115: ntp  Fri-1200
2022-11-07
10 Karen O'Donoghue Changed consensus to Yes from Unknown
2022-11-07
10 Karen O'Donoghue Notification list changed to dsibold.ietf@gmail.com, odonoghue@isoc.org from dsibold.ietf@gmail.com
2022-11-07
10 Karen O'Donoghue Notification list changed to dsibold.ietf@gmail.com because the document shepherd was set
2022-11-07
10 Karen O'Donoghue Document shepherd changed to Dieter Sibold
2022-10-22
10 Neta Schiff New version available: draft-ietf-ntp-chronos-10.txt
2022-10-22
10 Neta Schiff New version accepted (logged-in submitter: Neta Schiff)
2022-10-22
10 Neta Schiff Uploaded new revision
2022-09-27
09 Neta Schiff New version available: draft-ietf-ntp-chronos-09.txt
2022-09-27
09 Neta Schiff New version accepted (logged-in submitter: Neta Schiff)
2022-09-27
09 Neta Schiff Uploaded new revision
2022-09-27
08 Neta Schiff New version available: draft-ietf-ntp-chronos-08.txt
2022-09-27
08 Neta Schiff New version accepted (logged-in submitter: Neta Schiff)
2022-09-27
08 Neta Schiff Uploaded new revision
2022-08-24
07 Neta Schiff New version available: draft-ietf-ntp-chronos-07.txt
2022-08-24
07 (System) New version approved
2022-08-24
07 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2022-08-24
07 Neta Schiff Uploaded new revision
2022-08-24
06 Neta Schiff New version available: draft-ietf-ntp-chronos-06.txt
2022-08-24
06 (System) New version approved
2022-08-24
06 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2022-08-24
06 Neta Schiff Uploaded new revision
2022-07-25
05 Karen O'Donoghue Intended Status changed to Informational from None
2022-07-25
05 Karen O'Donoghue This is an experimental draft that has been stable for some time.
2022-07-25
05 Karen O'Donoghue IETF WG state changed to In WG Last Call from WG Document
2022-07-09
05 Neta Schiff New version available: draft-ietf-ntp-chronos-05.txt
2022-07-09
05 (System) New version approved
2022-07-09
05 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2022-07-09
05 Neta Schiff Uploaded new revision
2022-06-07
04 Dieter Sibold Added to session: interim-2022-ntp-02
2022-01-11
04 (System) This document now replaces draft-schiff-ntp-chronos instead of draft-schiff-ntp-chronos
2022-01-11
04 Neta Schiff New version available: draft-ietf-ntp-chronos-04.txt
2022-01-11
04 (System) New version approved
2022-01-11
04 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2022-01-11
04 Neta Schiff Uploaded new revision
2021-08-21
03 Neta Schiff New version available: draft-ietf-ntp-chronos-03.txt
2021-08-21
03 (System) New version approved
2021-08-21
03 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2021-08-21
03 Neta Schiff Uploaded new revision
2021-03-08
02 Karen O'Donoghue Added to session: IETF-110: ntp  Tue-1700
2021-02-21
02 Neta Schiff New version available: draft-ietf-ntp-chronos-02.txt
2021-02-21
02 (System) New version approved
2021-02-21
02 (System) Request for posting confirmation emailed to previous authors: Danny Dolev , Michael Schapira , Neta Schiff , Tal Mizrahi
2021-02-21
02 Neta Schiff Uploaded new revision
2020-09-03
01 (System) This document now replaces draft-schiff-ntp-chronos instead of draft-schiff-ntp-chronos
2020-09-03
01 Neta Schiff New version available: draft-ietf-ntp-chronos-01.txt
2020-09-03
01 (System) New version approved
2020-09-03
01 (System) Request for posting confirmation emailed to previous authors: Michael Schapira , Neta Schiff , Tal Mizrahi , Danny Dolev
2020-09-03
01 Neta Schiff Uploaded new revision
2020-07-21
00 Karen O'Donoghue Added to session: IETF-108: ntp  Fri-1100
2020-03-04
00 Karen O'Donoghue This document now replaces draft-schiff-ntp-chronos instead of None
2020-03-04
00 Neta Schiff New version available: draft-ietf-ntp-chronos-00.txt
2020-03-04
00 (System) WG -00 approved
2020-03-04
00 Neta Schiff Set submitter to "Neta Rozen-Schiff ", replaces to draft-schiff-ntp-chronos and sent approval email to group chairs: ntp-chairs@ietf.org
2020-03-04
00 Neta Schiff Uploaded new revision