[Ntp] Re: [IANA #1413181] NTP Extension Field additions, and IANA NTP table management process (ntp-parameters)

[Miroslav Lichvar <[e-mail]>]

On Wed, Jul 02, 2025 at 06:10:05PM -0700, Harlan Stenn wrote:
> > They don't have to be RFCs. My understanding is that linking to an
> > expired draft on the IETF datatracker is not acceptable. Considering
> > the history of these specifications in the NTP WG, my recommendation
> > to avoid further delays would be to publish it outside of the RFC
> > process, e.g. on the ntp.org domain.
> 
> Then please consider them published via the github account where the drafts
> are still listed:
> 
>  https://github.com/hstenn/ietf-ntp-extended-information-ef
>  https://github.com/hstenn/ietf-ntp-i-do
>  https://github.com/hstenn/ietf-ntp-mac-last-ef
>  https://github.com/ hstenn/ietf-ntp-suggest-refid

I think linking to github is fine, but it should be a link to the
rendered version of the document (not a project page or xml source
code) and it shouldn't look like it came from IETF (assuming you don't
want to go through the RFC process). I hope others will correct me if
I'm wrong.

I agree with what Daniel said about RFC 7822. I understand you would
like to see the original problem with ambiguity solved differently,
but that is what has been accepted and implementations are now
expected to follow. It doesn't make much sense to register a new
extension field that cannot be included in a RFC7822-conforming NTPv4
message, right?

-- 
Miroslav Lichvar