[Ntp] Re: [EXT] Re: Re: NTP Extension Field additions, and IANA NTP table management process

[Harlan Stenn <[e-mail]>]

Ulrich,

On 2/20/2025 1:21 AM, Windl, Ulrich wrote:
> Harlan,
> 
> "experimental" assignments (outside od IANA scope) are *temporary* as I said; if they become permanent (IANA scope), the experimental value will become free, so there is no duplicate allocation.

In theory, that might work.  But in practice, software has a life of its 
own, and there will be cases where somebody is running software that 
uses experimental values and there will be <reasons> why it can't be 
updated.

In the case where the feature goes from experimental to permanent, what 
benefit is there to rebuilding all of that software and making sure all 
of the expected instances are updated?

> The purpose of the suggested allocation method is to avoid clashes between "new standard" and experimental values.

What clashes?

H

> Kind regards,
> Ulrich Windl
> 
>> -----Original Message-----
>> From: Harlan Stenn <stenn=[e-mail]>
>> Sent: Thursday, February 20, 2025 1:57 AM
>> To: Windl, Ulrich <[e-mail]>
>> Cc: NTP WG <[e-mail]>
>> Subject: [EXT] [Ntp] Re: Re: NTP Extension Field additions, and IANA NTP
>> table management process
>>
>> On 2/19/2025 3:59 AM, Windl, Ulrich wrote:
>>>
>>>> -----Original Message-----
>>>> From: Harlan Stenn <stenn=[e-mail]>
>>>> Sent: Wednesday, February 19, 2025 11:35 AM
>>>> To: Windl, Ulrich <[e-mail]>; [e-mail]; NTP WG
>> <[e-mail]>
>>>> Cc: Richard Hoptroff <[e-mail]>
>>>> Subject: [EXT] [Ntp] Re: NTP Extension Field additions, and IANA NTP
>> table
>>>> management process
>>>>
>>>> Hi Ulrich,
>>>>
>>>> On 2/18/2025 3:29 AM, Windl, Ulrich wrote:
>>>>> Hi!
>>>>>
>>>>> I just wonder about "10 - For Hoptroff NTP": Did they use it before
>> letting
>>>> IANA assign it?
>>>>
>>>> Uh, yes, of course.  Why would you think otherwise?
>>>>
>>>> OK, I don't know if they used it or not.  They asked me for a number and
>>>> I assigned them one from our "list" of allocated EF Types.  I have no
>>>> idea whether or not they are using it.  I don't see it as any of my
>>>> business.
>>>>
>>>> I believe I was told not to request EF types from IANA until the
>>>> registration process was refined by the WG.  I have the clear memory of
>>>> discussing this with Karen (who I gather either doesn't remember or
>>>> remembers differently) that the NTP project would be keeping track of EF
>>>> Type number requests until it was time to submit them to IANA.
>>>>
>>>>> Personally I feel such "vendor extension" should be allocated from the
>>>> other end.
>>>>
>>>> I don't know what you mean.  From the high-end of the table, down?  I've
>>>> previously described why that's a bad idea.  It runs us out of numbers
>>>> twice as fast and makes for a growing mess moving forward, forever.
>>> [Windl, Ulrich]
>>> Why do you run out of numbers twice as fast when allocating them in
>> reverse order?
>>
>> Why are we having this discussion again?
>>
>> Was I incorrect in thinking you were suggesting assigning
>> experimental/development EFs from the top of the range down, and
>> assigning permanent EFs from the bottom of the range up?
>>
>> This burns the namespace twice as fast, because it uses both an
>> experimental number AND a permanent number.
>>
>> When is it safe to re-use an experimental EF number for something else?
>>
>> And if there is a problem reusing an experimental number, that means one
>> must burn a *new* experimental number.
>>
>> How can anybody not see this and understand that it becomes a critical
>> problem down the road?
>>
>>>>> Otherwise today's short-lived IT-cycles might unnecessarily fragment the
>>>> number space for extension fields (IMHO).
>>>>> Should an extension field type be "reserved" (=never used officially) to
>>>> allow companies to experiment locally with their own extension fields
>> prior
>>>> to IANA registration?
>>>>
>>>> I haven't looked at the current state of "Experimental EF Types" in a
>>>> while, but I remember speaking out in strong opposition to what was
>>>> proposed.
>>>>
>>>> And again, how many of these do you think people will actually want?
>>>>
>>>> It may be OK to allocate an extension field type (or few) for "Local
>>>> experimentation", because why would it ever be a good idea to use
>>>> limited-scope experimental EFs on the live internet?
>>>>
>>>> Have you forgotten the other ongoing costs of "experimental" EF types?
>>>> What about how they will look and behave after many years of using
>> them?
>>> [Windl, Ulrich]
>>> Each experiment should be over at some time, and then it should be either
>> be accepted as being useful (and registered under a new official number), or
>> be discarded.
>>> (Assuming any experiment is happy when using just one EF type)
>>
>> How do you decide the time at which the experiment should be over?  What
>> do you build in to the code to say "If it's later than YYYY-MM-DD, do
>> not use the following EF code."
>>
>> Why even bother to do this if there's a simpler and cleaner solution?
>>
>> If somebody wants to experiment, assign a number to them.  If it doesn't
>> pan out, they can reuse the number next time, or tell IANA that they are
>> releasing the number.  If it pans out, the "right" number is already
>> assigned.  Yay.
>>
>> If we want even more flexibility, we can use the EEF (Extended Extension
>> Field) idea to (also) assign experimental numbers, and that's a
>> mechanism that won't run out of EF numbers.
>>
>> H
>>
>>>>> I think we should not encourage bad habits.
>>>>
>>>> I agree, and I'd bet your idea of a bad habit is different from mine.
>>>> I do not mean that in an unkind way.
>>>>
>>>>> Also: While it's specified that NTP has to ignore unknown extension
>> fields,
>>>> shouldn't it specified that no IANA unregistered extension field types
>> should
>>>> be able to "escape" to the public Internet?
>>>>
>>>> I thought it was MAY ignore, not MUST ignore.
>>>>
>>>> And what is the definition of "unknown extension fields"?  Unknown to
>>>> whom?  IANA?  The WG?  The implementation?
>>>>
>>>> H
>>>>
>>>>> Kind regards,
>>>>> Ulrich Windl
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Harlan Stenn <stenn=[e-mail]>
>>>>>> Sent: Tuesday, February 18, 2025 11:58 AM
>>>>>> To: [e-mail]; NTP WG <[e-mail]>
>>>>>> Cc: Richard Hoptroff <[e-mail]>
>>>>>> Subject: [EXT] [Ntp] NTP Extension Field additions, and IANA NTP table
>>>>>> management process
>>>>>>
>>>>>> I am not able to even remotely attend this meeting, because, as is
>>>>>> generally the case, it is occurring at the worst possible time for my
>>>>>> sleep schedule.
>>>>>>
>>>>>> Several years ago I submitted proposals to the NTP WG for new NTP
>>>>>> extension fields and types.
>>>>>>
>>>>>> The NTP WG declined to advance these on the Standards track, and
>> due
>>>> to
>>>>>> how the NTP EF Table maintenance was "managed" at the time, Karen
>>>> asked
>>>>>> me to hold off submitting these new EF Type requests.
>>>>>>
>>>>>> Now that the NTP WG has declared consensus on how IANA should
>>>> handle
>>>>>> the
>>>>>> NTP Extension Field Table and subsidiary tables, it's time for me to
>>>>>> submit the EF Type additions that the NTP Project has been collecting.
>>>>>>
>>>>>> As described by RFC5905, section 7.5, the first 16 bits of an NTP
>>>>>> Extension field is the "field type", with the next 16 bits being the
>>>>>> extension field length.
>>>>>>
>>>>>> Since the late 1990s the NTP Extension Field design and evolution has
>>>>>> been built on the premise that the 16 bit “field type” for the extension
>>>>>> field is comprised of all of the information needed to “use” the
>>>>>> Extension Field.  This information includes the Extension Field Type,
>>>>>> bits for what I’ll call the “sub command identifier”, and perhaps some
>>>>>> flag bits.
>>>>>>
>>>>>> The NTP Project has felt that 8 bits, or 256 values, should be more than
>>>>>> sufficient for specifying NTP v4 Extension Field Types.  We have seen
>> no
>>>>>> evidence that this position is incorrect.
>>>>>>
>>>>>> That leaves 8 bits for things like the subcommand and flag bits.
>>>>>>
>>>>>> There is a significant "difference of opinion" between the NTP Project's
>>>>>> view and the NTP WG consensus proposal
>>>>>> (draft-ietf-ntp-update-registries-17) regarding the format and content
>>>>>> of the 16 bit field type in an NTP Extension Field and how the IANA
>>>>>> tables should be described and formatted, but those differences are
>> not
>>>>>> relevant to this message.
>>>>>>
>>>>>> The NTP Project is aware of the following (decimal) Extension Field
>> Types:
>>>>>>
>>>>>> 0 - reserved
>>>>>> 1 - AutoKey version 1
>>>>>> 2 - AutoKey version 2
>>>>>> 3 - MAC extension field
>>>>>> 4 - NTS
>>>>>> 5 - Checksum Complement
>>>>>>
>>>>>> and the NTP Project had been using and preparing to release code and
>>>>>> specs for:
>>>>>>
>>>>>> 6 - Suggest REFID
>>>>>> 7 - I DO
>>>>>> 8 - Last Extension/Legacy MAC follows
>>>>>> 9 - Extended Information
>>>>>>
>>>>>> Additionally, Hoptroff.com contacted us asking for an Extension Field
>>>>>> for their use, so we put them in our list:
>>>>>>
>>>>>> 10 - For Hoptroff NTP
>>>>>>
>>>>>> I hereby request the above NTP EF types, entries 6-10, be added to the
>>>>>> IANA NTP Extension Field Table.
>>>>>>
>>>>>> I will soon submit RFC drafts for NTP Extension Field Types 5-9. These
>>>>>> will be Information Track, as they will be part of the NTP Reference
>>>>>> Implementation from the NTP Project.  If the IETF NTP WG so chooses,
>> I
>>>>>> will submit these as Standards Track documents.
>>>>>>
>>>>>> I do not speak for Hoptroff, so it's up to them as to what, if any,
>>>>>> additional documentation they provide for their use of the NTP EF 10
>>>>>> "namespace".  It's their choice to leave their ER namespace
>>>>>> undocumented, or documented as Informational, or to see if the WG
>>>> feels
>>>>>> it should be a Standards track proposal.
>>>>>>
>>>>>> Finally, I understand the NTP WG is recommending IANA use a 3
>> member
>>>>>> panel of experts to oversee the management of the NTP Extension
>> Field
>>>>>> Table, and related tables.
>>>>>>
>>>>>> I am most curious to see who these experts are, and how they are
>>>> chosen.
>>>>>>
>>>>>> Until January of 2024, I was aware of two clear experts on NTP
>> Extension
>>>>>> Fields.  With the death of David L. Mills in January of 2024, I am now
>>>>>> aware of only one.
>>>>>>
>>>>>> --
>>>>>> Harlan Stenn <[e-mail]>
>>>>>> NTP Project Lead. The NTP Project is part of
>>>>>> https://www.nwtime.org/ - be a member!
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> ntp mailing list -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> --
>>>> Harlan Stenn <[e-mail]>
>>>> NTP Project Lead.  The NTP Project is part of
>>>> https://www.nwtime.org/ - be a member!
>>>>
>>>> _______________________________________________
>>>> ntp mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>
>> --
>> Harlan Stenn <[e-mail]>
>> NTP Project Lead.  The NTP Project is part of
>> https://www.nwtime.org/ - be a member!
>>
>> _______________________________________________
>> ntp mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> _______________________________________________
> ntp mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
Harlan Stenn <[e-mail]>
https://www.nwtime.org/ - be a member!