Re: [Ntp] Experimental/Private EF area: was Re: Registries document

[Harlan Stenn <[e-mail]>]

On 8/3/2023 12:39 AM, Miroslav Lichvar wrote:
> On Tue, Aug 01, 2023 at 10:55:03PM -0700, Harlan Stenn wrote:
>> On 8/1/2023 5:10 AM, Miroslav Lichvar wrote:
>>> No, you don't have to do that. You can keep using the "V1 EF format"
>>> as you have been for 20+ years. The document discussed in this thread
>>> is fixing RFC5906 and the registry to match the ntpd values. Your code
>>> will then conform to RFC5906 and everyone is happy. If you just wait
>>> a bit, your problem will fix itself on its own.
>>
>> No, thank you.
> 
> Ok. It seems you are not going back from the path you have chosen.
> 
> How about the following?
> 
> - Values reserved for experimental use are changed from the nice
>    continuous 0xF000-0xFFFF range to the 4096 scattered values ending
>    with E (why not F?) as you suggested.

Did you not see how I answered this in my response to Rich?

As I said, the I-DO proposal is counting down from 0xFFFF for its work. 
I-DO exchanges information about both EFs and "capabilities".  An I-DO 
value of 0x0004 means "I-DO NTS", while 0x0005 means "I-DO Checksum 
Complement".  0xFFFF is "I-DO IPv6 REFID hashes" and 0xFFFE is "I-DO 
Leap Smear REFIDs".

This was all described in draft-stenn-ntp-i-do.

If y'all disagree with me that a reserved block for experimental and/or 
private use is an unnecessary and excessively restricted approach (what 
I have called a bad idea), then I-DO will be one way for cooperating NTP 
instances to exchange information about which of the 
experimental/private use EFs they support.

And the reason for not using 0xF000-0xFFFF (even if it was 
0xE000-9xEFFF) is that it breaks 25 years of design and established 
coding, and stomps all over the ability to more cleanly code for a 
growing number of EFs.

The EF Field Type is the BOTTOM octet.  The "suggested" proposal not 
only completely ignores this, including the existing usage for Autokey 
(let's ignore our disagreements about the Autokey numbering for now), 
NTS, Checksum Complement, and all of the proposals and work the NTP 
Project has done on new EFs.

> - RFC5906 is not marked as "updated" by the document.
> 
> - The "reserved for historic reason" and RFC 5906 descriptions in the
>    table are swapped (except for 0x0202, 0x8202, 0xC202 which map to
>    themselves).

I don't fully understand this yet - I think I know the general direction 
  you are describing, but I don't yet know if we're on the same page 
regarding what it means.

> - A short explanation is provided on why RFC5906 and the
>    implementation it was supposed to be based on didn't match for 20+
>    years. Can you write that?

Sure.

But I have already invested a HUGE amount of time and effort in this 
sort of work in the past, and after writing these proposals, combining 
them at the request of the Chair, then separating some of them, etc. for 
multiple cycles, the WG dropped them from consideration.

I am not interested in wasting my time like that again.  As you have 
pointed out yourself, I am resource-limited and want to devote my 
efforts to things I believe are useful.

-- 
Harlan Stenn <[e-mail]>, part of
http://networktimefoundation.org - be a member!