Roughtime
draft-ietf-ntp-roughtime-15

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-ntp-roughtime-15. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, IANA will assign a port number for [ Roughtime ]:

https://www.iana.org/assignments/service-names-port-numbers/

An expert review has been requested for the port request. The IANA state for the document will be set to "IANA NOT OK" until the port review is completed and approved.

Second, a new registry will be created called the Roughtime Version registry.

IANA QUESTION -> Where should this new registry be located? Is this to be a new registry group or is it under an existing registry group?

The registration rule for the new registry is IETF Review as defined by [RFC8126] except for the range 0x80000000-0xffffffff which is reserved for private or experimental use. Each registration in the registry has a version ID, a version name and a reference. There are initial registrations in the new registry as follows:

Version ID Version Name Reference
----------+-------------+-------------
0x0 Reserved [ RFC-to-be ]
0x1 Roughtime version 1 [ RFC-to-be ]
0x2-0x7fffffff Unassigned
0x80000000- Reserved for Private [ RFC-to-be ]
0xffffffff or Experimental use

Third, a new registry is to be created called the Roughtime Tage registry.

IANA QUESTION -> Where should this new registry be located? Is it a néw registry on the IANA Matrix or is it a sub-registry of an existing registry? If it is a sub-registry of an existing registry, in which registry will it be contained?

The registration rule for the new registry is Specification Required as defined by [RFC8126]. There are initial registrations in the new registry as follows:

Tag ASCII Representation Reference
---+---------------------+-------------
0x00474953 SIG [ RFC-to-be ]
0x00524556 VER [ RFC-to-be ]
0x00565253 SRV [ RFC-to-be ]
0x434e4f4e NONC [ RFC-to-be ]
0x454c4544 DELE [ RFC-to-be ]
0x45505954 TYPE [ RFC-to-be ]
0x48544150 PATH [ RFC-to-be ]
0x49444152 RADI [ RFC-to-be ]
0x4b425550 PUBK [ RFC-to-be ]
0x5044494d MIDP [ RFC-to-be ]
0x50455253 SREP [ RFC-to-be ]
0x53524556 VERS [ RFC-to-be ]
0x544e494d MINT [ RFC-to-be ]
0x544f4f52 ROOT [ RFC-to-be ]
0x54524543 CERT [ RFC-to-be ]
0x5458414d MAXT [ RFC-to-be ]
0x58444e49 INDX [ RFC-to-be ]
0x5a5a5a5a ZZZZ [ RFC-to-be ]

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

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

Thank you,

David Dong
IANA Services Sr. Specialist

Request for IETF Last Call review by HTTPDIR Completed: Ready with Issues. Reviewer: Mark Nottingham. Sent review to list. Submission of review completed at an earlier date.

The following Last Call announcement was sent out (ends 2026-01-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-ntp-roughtime@ietf.org, ek.ietf@gmail.com, kodonog@pobox.com, ntp-chairs@ietf.org, ntp@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Roughtime) to Experimental RFC


The IESG has received a request from the Network Time Protocols WG (ntp) to
consider the following document: - 'Roughtime'
  as Experimental 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 2026-01-07. 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


  This document describes Roughtime—a protocol that aims to achieve two
  things: secure rough time synchronization even for clients without
  any idea of what time it is, and giving clients a format by which to
  report any inconsistencies they observe between time servers.  This
  document specifies the on-wire protocol required for these goals, and
  discusses aspects of the ecosystem needed for it to work.




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



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

# Internet AD comments for draft-ietf-ntp-roughtime-14
CC @ekline

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

## Comments

### S1

* I think the document should probably mention something about Roughtime's
  objectives relative to RFC 9523, as that document did try to help deal
  with detecting malfeasance and so forth (as I understand it).

### S4.1.3

* To be clear, the "VER" tag would be serialized as

      (u8){0x56, 0x45, 0x52, 0x00}

  is that correct?

### S8.3

* I think we have to say that an IPv6 address in the Server List "addresses"
  section of a server object MUST be encapsulated within []s, a la
  RFC 3986 S3.2.2 style.

  Otherwise, an address in RFC 5952 format using RFC 5952 S2.2 zero
  compression may not easily have the :port portion readily identifiable.

### S12.3

* If this registry is going to be Specification Required then the document
  will want to include a brief "Guidance to Designated Experts" section.

## Nits

### idnits

* Check the idnits page:

  https://author-tools.ietf.org/idnits3/results?url=https://www.ietf.org/archive/id/draft-ietf-ntp-roughtime-14.txt

  It has some term spelling style comments ("INCORRECT_TERM_SPELLING") and
  found some updated RFCs to reference ("OBSOLETE_DOCUMENT").

### S11

* Just to link back for a casual reader, the document might note something
  like "Additional operational considerations for clients are discussed
  in [Section 8]."