[Qirg] Re: Internet draft: Clock Sync is not a valid Quantum-Internet Application

[Melchior Aelmans <[e-mail]>]

Hi Oskar,

Although I am a co-author of RFC 9583, I would like to offer some generic
observations on how to "update" an RFC, speaking here without my co-author
hat on.

In practice, there are two main ways to address issues or new insights
related to an RFC:

   1.

   *Submit an erratum.*
   As described in the IESG statement on errata processing, "Errata are
   items that were errors at the time the document was published — things that
   were missed during the last call, approval, and publication process."
   Conversely, "If new information, new capabilities, or new thinking has
   come up since publication, or if you disagree with the content of the RFC,
   that is not material for an errata report. Such items are better brought to
   relevant working groups, technical area discussions, or the IESG."

   See also:
   -
      https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
      - https://datatracker.ietf.org/doc/draft-rpc-errata-process/
   2.

   *Write a new document that updates or obsoletes the RFC.*
   When the issue is not a clear publication/textual error but rather new
   scientific insight, new capabilities, or a substantial change in
   understanding, the usual path is to write a new Internet-Draft intended to
   update (or possibly obsolete) the existing RFC. The general process is
   briefly described at:
   - https://www.ietf.org/process/rfcs/#obsoleting-and-updating

   In this context, when someone fundamentally disagrees with the content
   or conclusions of an RFC, the route is typically to:
   - develop a new draft that carefully lays out the updated analysis or
      evidence, and
      - explicitly indicate in that draft that it updates (or, in more
      extreme cases, obsoletes) the existing RFC.

   RFC 8067 ("Tags for the Identifying RFCs that Update or Obsolete Other
   RFCs") may also be useful background for thinking about how to structure
   such work and how to describe its relationship to existing RFCs:
   - https://datatracker.ietf.org/doc/html/rfc8067

In general, the IETF and IRTF processes work best when substantive
technical disagreements with an RFC are handled through new Internet-Drafts
and WG discussions, rather than through the errata mechanism.

Of course, the easiest way to avoid these situations is to provide input
while a document is still an Internet-Draft under active discussion in a
WG/RG. However, I fully recognize that people may not have been following
the work at that time or may have only become involved in the group after
publication.

I am happy to discuss this further, both as a co-author of RFC 9583 and as
an IETF/IRTF participant interested in the process.

Best,

Melchior


On Fri, Jan 30, 2026 at 5:26 PM Deventer, M.O. (Oskar) van
<oskar.vandeventer=[e-mail]> wrote:

> Dear Wojtek,
>
>
>
> Thank you for your advice, which we have incorporated into the uploaded
> version (
> ietf.org/archive/id/draft-vandeventer-qirg-rfc9583-qcs-internet-00.txt
> <https://www.ietf.org/archive/id/draft-vandeventer-qirg-rfc9583-qcs-internet-00.txt>)
> as follows.
>
>    - Add “RFC9583” to the title of our internet draft.
>    - Clarify that the scope is limited to “quantum clock synchronisation”
>    as defined/referenced by RFC9583.
>    - Add clarifying NOTE (copied below) on the term “quantum clock
>    synchronisation”, to reduce the semantic confusion on that term.
>    - Improve a sentence on TRL, in line with you suggestion.
>
>
>
> As mentioned before, both RFC 9583 and the cited [Jozsa2000] are
> frozen-in-time publications. Updated scientific insights do not challenge
> the quality of their creation process, but their conclusions. The question
> is how QIRG wants to give visibility to updated insights, and what further
> analysis would be needed.
>
>
>
>    - Further analysis of the use case is welcome to correct and improve
>    our state of knowledge and if you would like to pursue that at the QIRG
>    that would be welcome especially since I do think this is a very
>    interesting use case.
>
> My team at TNO would welcome further analysis, both on “clock
> synchronisation” and “synthonization” (as defined below), and their
> relationships with “quantum internet”. So, anyone, please contact us if you
> are interested too.
>
>
>
> Best regards,
>
>
>
> Oskar
>
>
>
> ---
>
> NOTE:
>
> The term "synchronisation" has multiple meanings in scientific literature.
>
> Meaning 1 ("clock synchronization"): adjustment of a clock or watch to
> show the same time as another.
>
> Meaning 2 ("synthonization"): the process of setting two or more
> oscillators to the same frequency.
>
> This internet draft is only about the first meaning, as QIRG via
>  [RFC9583] addresses only that meaning.
>
> Examples of the second  meaning are methods that use entangled photon
> pairs from physical  processes (e.g. spontaneous parametric down
> conversion), or that use quantum interference of photons (Hong–Ou–Mandel
> effect). The second meaning is out of scope of this internet draft.
>
> ---
>
>
>
>
>
> *From:* Wojciech Kozlowski <[e-mail]>
> *Sent:* donderdag 29 januari 2026 13:01
> *To:* Deventer, M.O. (Oskar) van <[e-mail]>
> *Cc:* IRTF-QIRG <[e-mail]>
> *Subject:* RE: [Qirg] Re: Internet draft: Clock Sync is not a valid
> Quantum-Internet Application
>
>
>
> Hi Oskar,
>
>
>
> I think the way, given the discussions that happened on the mailing list,
> is to clarify the scope of your conclusions, whether it is time sync in
> general or just on particular academic work, as a next step. Changing the
> title would also be a good step if you do not plan to tackle the entirety
> of clock synchronisation as a use case.  Then it will be your task to reach
> some level of consensus with the QIRG if you wish to publish it through
> this channel.
>
>
>
> My personal recommendation would also be to drop the focus on RFC9583
> though. I think it is counterproductive especially since your focus is on a
> cited work. It also broadens the scope of the discussion. I think it would
> be far more valuable to publish a more complete discussion on time
> synchronisation which, amongst others, tackles your objection to RFC9583,
> than it is to do work specifically to fix one citation in RFC9583.
> Especially since the general statement to which you object might be fixed
> by citing different work instead.
>
>
>
> We don’t think that this is our burden of proof. We have not conclusively
> demonstrated the absence of unicorns on Mars either. Again, RFC9583 does
> not address “*time synchronisation, in general*”, but only [Jozsa2000].
>
>    - However, with this, I disagree. If you want to go ahead with a
>    document titled  “Clock Sync is not a valid Quantum-Internet Application”
>    you will need strong evidence and backing arguments given that this is an
>    active area of research and academic publications. Regardless of the scope
>    of your document, the title is making an incredibly strong statement.
>
>
>
> Many thanks,
>
> Wojtek
>
>
>
> *From:* Deventer, M.O. (Oskar) van <[e-mail]>
> *Sent:* Thursday, 29 January 2026 11:54
> *To:* Wojciech Kozlowski <[e-mail]>
> *Cc:* IRTF-QIRG <[e-mail]>
> *Subject:* RE: [Qirg] Re: Internet draft: Clock Sync is not a valid
> Quantum-Internet Application
>
>
>
> Hi Wojtek,
>
>
>
> Thank you for your considerations, as well as your suggested way forward.
>
>
>
>    - It seems to me that you are targeting a specific publication
>    [Jozsa2000] cited by RFC9583
>
> That is correct. RFC9583 points *only* to [Jozsa2000] (both directly and
> indirectly) for “*quantum clock sync*”. And both QIRG and our internet
> draft point to RFC9583 for that term.
>
>
>
>    - You have not conclusively demonstrated that time synchronisation, in
>    general, is an invalid application of the quantum internet.
>
> We don’t think that this is our burden of proof. We have not conclusively
> demonstrated the absence of unicorns on Mars either. Again, RFC9583 does
> not address “*time synchronisation, in general*”, but only [Jozsa2000].
>
>
>
>    - The citation was peer-reviewed and as far as the authors could tell
>    good enough.
>
> Both [Jozsa2000] and RFC 9583 are frozen-in-time publications. Updated
> scientific insights do not challenge the quality of their creation process,
> but their conclusions. The question is how QIRG wants to give visibility to
> updated insights, and what further analysis would be needed.
>
>
>
> Thanks,
>
>
>
> Oskar
>
>
>
>
>
> *From:* Wojciech Kozlowski <[e-mail]>
> *Sent:* donderdag 29 januari 2026 11:12
> *To:* Deventer, M.O. (Oskar) van <[e-mail]>
> *Cc:* IRTF-QIRG <[e-mail]>
> *Subject:* RE: [Qirg] Re: Internet draft: Clock Sync is not a valid
> Quantum-Internet Application
>
>
>
> Hi Oskar,
>
>
>
> It seems to me that you are targeting a specific publication [Jozsa2000]
> cited by RFC9583 while most others (including me) took the subject matter
> at a much broader scope. If this is the line of reasoning you want to
> pursue you may want to make the language in your draft much more specific.
> Alternatively, you can broaden the scope of the draft and include all the
> other discussions.
>
>
>
> Regarding any sort of action on RFC 9583, I am unable to follow your
> reasoning for why anything needs to be done. You have not conclusively
> demonstrated that time synchronisation, in general, is an invalid
> application of the quantum internet. You have only questioned the value of
> a specific citation as a source for that information. I am still of the
> opinion that this does not warrant any action. The citation was
> peer-reviewed and as far as the authors could tell good enough.
>
>
>
> Further analysis of the use case is welcome to correct and improve our
> state of knowledge and if you would like to pursue that at the QIRG that
> would be welcome especially since I do think this is a very interesting use
> case.
>
>
>
> But I remain unconvinced that any action on RFC 9583 is productive.
>
>
>
> Many thanks,
>
> Wojtek
>
>
>
> *From:* Deventer, M.O. (Oskar) van <[e-mail]>
> *Sent:* Thursday, 29 January 2026 09:59
> *To:* Wojciech Kozlowski <[e-mail]>
> *Cc:* IRTF-QIRG <[e-mail]>
> *Subject:* RE: [Qirg] Re: Internet draft: Clock Sync is not a valid
> Quantum-Internet Application
>
>
>
> Hi Wojtek, all,
>
>
>
> Thank you for your feedback. Let us make a clear separation between two
> aspects.
>
>    - The use of language, which is obviously perceived as too
>    provocative, and that needs to be corrected.
>    - The issue at hand, that one of the RFC-9583-cited applications has a
>    serious issue.
>
>
>
>    - It does not appear that your statement applies to the more
>    substantial portions of RFC 9583.
>
> That is a point for discussion. Of all application scenarios in RFC 9583,
> the quantum clock sync application stands out, as it is the easiest
> explainable to a layperson (e.g. an investor), and it is the most “quantum
> magical”. So I disagree with the qualification of quantum clock sync as
> “less substantial”.
>
>
>
> Oskar
>
>
>
>
>
> *From:* Wojciech Kozlowski <wojciech.kozlowski=[e-mail]>
> *Sent:* donderdag 29 januari 2026 09:28
> *To:* Deventer, M.O. (Oskar) van <[e-mail]>; Eubanks,
> Marshall <[e-mail]>
> *Cc:* IRTF-QIRG <[e-mail]>
> *Subject:* RE: [Qirg] Re: Internet draft: Clock Sync is not a valid
> Quantum-Internet Application
>
>
>
> Hi Oskar,
>
>
>
> I do disagree strongly with calling RFC 9583 flawed per your reasoning.
> Citing accepted academic literature that represent the current state of
> knowledge, even if later proven wrong/incorrect/incomplete (of which in
> this case I am not sufficiently convinced), is not a flaw but an aspect of
> ongoing research and ongoing knowledge development.
>
>
>
> I do not think any action is warranted re: RFC 9583 that applies only to a
> statement built upon citations from academic literature. It does not appear
> that your statement applies to the more substantial portions of RFC 9583.
>
>
>
> Many thanks,
>
> Wojtek
>
>
>
> *From:* Deventer, M.O. (Oskar) van <
> oskar.vandeventer=[e-mail]>
> *Sent:* Thursday, 29 January 2026 09:18
> *To:* Eubanks, Marshall <[e-mail]>
> *Cc:* IRTF-QIRG <[e-mail]>
> *Subject:* [Qirg] Re: Internet draft: Clock Sync is not a valid
> Quantum-Internet Application
>
>
>
> RFC 9583 points to a year-2000 paper, and to other papers that point to
> that year-2000 paper. This paper is fundamentally incorrect because of its
> circular reasoning.
>
> RFC 9583 does not analyse to this new Chinese 2025 paper, which may or may
> not have the same circular reasoning, and which may or may not use “quantum
> internet”.
>
> RFC 9583 does not analyse to any other “quantum clock synchronisation”
> methods. E.g. the use photon pairs emerging from SPDC sources, or HOM
> interference of identical photons. None of those methods achieve the
> “absolute” time synchronisation claimed by the RFC-9583-cited paper.
>
>
>
> I believe all the above are arguments justifying a proper analysis of
> “quantum clock synchronisation” in the context of QIRG and the flawed RFC
> 9583.
>
>
>
> As RFCs are final documents, the flaw cannot be corrected in RFC 9583
> itself.
>
>    - One option would be to issue a new RFC that deprecates RFC 9583.
>    - Another option would be a separate RFC that warns people about the
>    flaw in RFC 9583.
>
>
>
> Best regards,
>
>
>
> Oskar
>
>
>
>
>
> *From:* Marshall Eubanks <[e-mail]>
> *Sent:* donderdag 29 januari 2026 05:31
> *To:* Thom van der Steenhoven <
> T.J.W.vanderSteenhoven=[e-mail]>
> *Cc:* IRTF-QIRG <[e-mail]>
> *Subject:* [Qirg] Re: Internet draft: Clock Sync is not a valid
> Quantum-Internet Application
>
>
>
> I think that this draft is too dismissive and should  not be adopted in
> its current form. One important reason to do quantum time synchronization,
> like any quantum metrology, is to do better than the 1/sqrt(N) improvement
> with number of measurements typical with classical systems (e.g., with
> photon shot noise) and approach the 1/N Heisenberg scaling.
>
>
>
> This is not mentioned in this draft, but this recent review paper (in
> Chinese) it is a key point.
>
> https://www.researching.cn/articles/OJ3a1a8508508a44db
>
>
>
> Quantum clock synchronization has emerged as a groundbreaking solution to
> overcome the fundamental limitations inherent in classical synchronization
> methods, which remain constrained by the shot noise limit. By exploiting
> quantum entanglement’s unique properties, quantum clock synchronization
> achieves unprecedented precision, theoretically approaching the Heisenberg
> limit, while providing inherent physical-layer security against signal
> spoofing through quantum no-cloning principles.
>
>
>
> I think this technology will prove important for the free space
> communications networks such as are dealt with by the tiptop IETF WG.
>
>
>
> Regards
>
> Marshall Eubanks
>
>
>
>
>
>
>
> On Wed, Jan 28, 2026 at 7:58 AM Thom van der Steenhoven
> <T.J.W.vanderSteenhoven=[e-mail]> wrote:
>
> Dear Oskar,
>
> While I think the problem you and your colleagues have pointed out is a
> valid one, I wonder if a bootstrapping problem should really be considered
> a disqualifying problem for an application.
> QKD, for instance, has similar bootstrapping problems but we generally
> think of that as being one of the most robust use-cases for the quantum
> internet.
>
> I'd imagine there are situations where one would use a classical method to
> achieve clock synchronization which is then used to bootstrap quantum clock
> synchronization, from thereon relying on whatever advantage the quantum
> synchronization can bring.
>
> Regardless, I think it is good that we are looking more critically at the
> presumed benefits of this technology, especially considering the amount of
> investment happening in this space.
>
> Kind regards,
> Thom
> ------------------------------
>
> *From:* Deventer, M.O. (Oskar) van <oskar.vandeventer=
> [e-mail]>
> *Sent:* Wednesday, January 28, 2026 12:29
> *To:* IRTF-QIRG <[e-mail]>
> *Subject:* [Qirg] Internet draft: Clock Sync is not a valid
> Quantum-Internet Application
>
>
>
> You don't often get email from oskar.vandeventer=[e-mail]. Learn
> why this is important <https://aka.ms/LearnAboutSenderIdentification>
>
> Dear IRTF-QIRG members,
>
>
>
> What are your thoughts on the attached internet draft “Clock Sync is not a
> valid Quantum-Internet Application”?
>
>
>
> The title is also the main message of the document. RFC 9583
> <https://datatracker.ietf.org/doc/rfc9583/> provides application
> scenarios that are used to justify investment in quantum internet. One of
> those is network clock synchronization. RFC 9583 refers to [Jozsa2000],
> [Komar] and [Guo] for this. We studied these papers. We discovered that
> they contain a fatal flaw. They start from the presumption of shared prior
> entanglement between the two synchronizing parties. The fatal flaw is that
> this presumption can only be achieved by also presuming presence of
> perfectly synchronised clocks. This defies the whole purpose of the
> application scenario.
>
>
>
> As RFCs are final documents, the flaw cannot be corrected in RFC 9583
> itself.
>
>    - One option would be to issue a new RFC that deprecates RFC 9583.
>    - Another option would be a separate RFC that warns people about the
>    flaw in RFC 9583.
>
>
>
> Please let me know your thoughts.
>
>
>
> Thank you,
>
>
>
> Oskar
>
>
>
> P.S.
>
> Who can help making the internet draft uploadable to the IETF servers?
>
> I have spent four frustrating hours with https://author-tools.ietf.org/
> -> Validate. I keep getting these error messages.
>
>   ** The document seems to lack a License Notice according IETF Trust
>
>      Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009
>
>      Section 6.b -- however, there's a paragraph with a matching beginning.
>
>      Boilerplate error?
>
>   ** There are 69 instances of too long lines in the document, the longest
>
>      one being 3 characters in excess of 72.
>
> The first error is incorrect, as the copyright notice is in the document,
> exactly as it should be.
>
> The second error is incorrect, as all the lines have exactly the correct
> length.
>
>
>
>
>
>
>
> Dr. ir. M.O. van Deventer (Oskar)
> Senior Scientist Self-Sovereign Identity & Quantum Standardisation
> ICT, Strategy & Policy
>
> T: [phone]
> M: [phone]
> E: [e-mail]
>
> Location <https://www.tno.nl/locaties/DHA>
>
>
>
>
>
> <https://www.tno.nl/>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>
>
> _______________________________________________
> Qirg mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> Qirg mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>