[Ntp] Re: [IANA #1443105] Request for Assignment (nts)

[Daniel Franke <[e-mail]>]

Hi, checking in on the status of this request and how people would like to
proceed. I see that the working group has now reached consensus to adopt
the draft and that it will proceed with no major technical changes,
documenting the experiment as it exists rather than altering it. With my
Designated Expert hat on, it remains my position that although I disagree
with some design choices, none of my disagreements are any cause for
rejecting the assignment request under the Specification Required policy
and I'm happy to let it proceed. I defer to WG consensus as to whether and
when the assignments should be made.

On Thu, Feb 26, 2026 at 12:58 PM Daniel Franke <[e-mail]> wrote:

> Yes — I wrote yesterday to NTPWG elaborating on my thoughts:
> https://mailarchive.ietf.org/arch/msg/ntp/-3LOoruv4F3zDtL0EO5BbyMlZoA/
>
> Today David wrote
> https://mailarchive.ietf.org/arch/msg/ntp/DZfoszWPH4A0Whoe7lql8WE_JMo/ in
> reply, and it sounds like he's withdrawing the draft as a CfA at least for
> now. If the authors intend to pursue this design independently of the IETF,
> then my objection that these allocations are premature no longer applies. I
> would still strongly urge David to consider my recommendation to run the
> pool<->time source portion of the exchange as a non-NTS-KE protocol
> multiplexed on the same port via ALPN, and also to use TLS's existing PSK
> facilities in place of the authentication token of section 6.7. However,
> whether he takes my advice or not, I see no further basis for refusing this
> request for assignment.
>
> On Thu, Feb 26, 2026 at 12:43 PM David Dong via RT <
> [e-mail]> wrote:
>
>> Hi Daniel,
>>
>> Following up on this; have you had a chance to further review this
>> request?
>>
>> Thank you.
>>
>> Best regards,
>>
>> David Dong
>> IANA Services Sr. Specialist
>>
>> On Sun Feb 15 16:37:11 2026, [e-mail] wrote:
>> > Apologies that I'm traveling this week and won't be back at a proper
>> > keyboard until after the response deadline so these comments will be
>> > brief
>> > for now. On further review, I continue to agree with Miroslav that
>> > this
>> > request is premature and that early allocation should wait until after
>> > WG
>> > adoption and further discussion. Furthermore, though, I think this
>> > protocol
>> > strains the semantics of NTS-KE more than I'm comfortable with and is
>> > going
>> > to create a high risk of vulnerabilities through implementation errors
>> > in
>> > the treatment of requests that mix pool-related records with ordinary
>> > records. My recommendation would be to turn this into an entirely
>> > separate
>> > protocol which multiplexes on the NTS-KE port by way of ALPN.
>> >
>> > On Thu, Feb 5, 2026, 09:17 Daniel Franke <[e-mail]> wrote:
>> >
>> > > ACK on the review request, but I'll need a bit of time on this one.
>> > > My
>> > > quick first impression is that I agree with Miroslav that the
>> > > allocation is
>> > > a bit premature, but I might change my mind on further review.
>> > >
>> > > On Tue, Feb 3, 2026, 02:31 David Dong via RT <
>> > > [e-mail]> wrote:
>> > >
>> > >> Dear Miroslav Lichvar, Daniel Franke
>> > >> As the designated experts for the Network Time Security Key
>> > >> Establishment
>> > >> Record Types registry, can you review the registration proposal
>> > >> below? If
>> > >> it's OK, we'll make the assignment at:
>> > >>
>> > >> https://www.iana.org/assignments/nts/
>> > >>
>> > >> Specification: https://trifectatech.org/specifications/nts-kelb-
>> > >> pool.html
>> > >>
>> > >> Unless you ask us to wait for the other reviewer, we’ll act two days
>> > >> after the first response we receive.
>> > >>
>> > >> The IESG has asked us to request that reviews be returned within two
>> > >> weeks, which in this case would make the due date February 17th.
>> > >>
>> > >> With thanks,
>> > >>
>> > >> David Dong
>> > >> IANA Services Sr. Specialist
>> > >>
>> > >> On Mon Feb 02 08:04:39 2026, [e-mail] wrote:
>> > >> >
>> > >> > Contact Name:
>> > >> > David Venhoek
>> > >> >
>> > >> > Contact Email:
>> > >> > [e-mail]
>> > >> >
>> > >> > Type of Assignment:
>> > >> > Requesting 7 specification required assignments in the Network
>> > >> > Time
>> > >> > Security Key Establishment Record types registry for extension
>> > >> > fields
>> > >> > with the following purposes:
>> > >> > - Keep Alive
>> > >> > - Supported Next Protocol List
>> > >> > - Supported Algorithm List
>> > >> > - List Server Names
>> > >> > - Fixed Key Request
>> > >> > - NTP Server Deny
>> > >> > - Authentication Token
>> > >> > Details for the registration are given in section 8 of the
>> > >> > specification provided below. The specification also provides
>> > >> > detailed
>> > >> > descriptions of the functionality of the record types requested.
>> > >> >
>> > >> > Registry:
>> > >> > Network Time Security Key Establishment Record Types
>> > >> >
>> > >> > Description:
>> > >> > This assignment is requested to enable us to transition to a more
>> > >> > permanent setup for an NTS pool, which, assuming sufficient
>> > >> > funding
>> > >> > towards the future, will be able to be run indefinitely.
>> > >> >
>> > >> > Additional Info:
>> > >> > The specification is at
>> > >> > https://trifectatech.org/specifications/nts-
>> > >> > kelb-pool.html, and will be hosted there permanently. After
>> > >> > assignment, section 8 will be rewritten to reflect what is
>> > >> > assigned,
>> > >> > and all references to to-be-allocated numbers will be updated,
>> > >> > with
>> > >> > draft implementation numbers removed.
>> > >>
>> > >>
>>
>>