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

[David Venhoek <[e-mail]>]

Below my view on the topics of discussion, in the hope that we can at
some point get to some form of rough consensus:

Having gone over both documents again, it is not at all apparent that
RFC5906 modifies the extension field format defined in RFC5905. As
such, in my view, the ship for standardizing a split type field has
long since sailed. Especially since even the reference implementation
of autokey doesn't use this split as specified there. As such, I see
little problem with taking the range 0xF000-0xFFFF.

Also, given modern processor architectures, the impact of having to do
a 16 vs 8 bit choice on extension fields is going to be negligible.
The fact that extension field parsing produces unpredictable branch
points is going to be far more significant. In any case, the
experiments we have done on the ntpd-rs implementation suggest that on
a gigabit ethernet network connection and a reasonably modern
processor (~5 years old) the network connection is easily the limiting
factor in terms of handling NTP traffic.

However, if we do want to respect that design space I do have a strong
preference to use the end of the code space and reserving all 0x???F
codes. I do not see a not yet standardized spec's use of these as
reason to deviate (rather the opposite, as that spec should be one of
the prime users of this range whilst not yet standardized).

I strongly think we should have experimental ranges. Reserving codes
for any experiment before even starting the standardization process is
not a good option. So long as it is not standardized, interop is also
a non issue so I'm fine with considering overlap in this range as risk
of the user.

To the contrary, if we don't introduce such a range, people will start
using random codes at some point for their experiments, and then that
could collide even with implementations that don't intend to support
any experimental/private use stuff.

On the subject of the collision between NTS cookie and autokey message
request extension field identifiers, this is there (unless I am really
misunderstanding the reference implementation code, best I can tell
they both put 0x0204 in the type field), and I consider the current
text sufficient in indicating that this has indeed happened and that
we are aware of it. It also already clearly states that it is not a
problem in practice which should answer most questions. Not mentioning
it and just having double entries on the other hand would be very
confusing.

On Thu, Aug 3, 2023 at 11:01 AM Miroslav Lichvar <[e-mail]> wrote:
>
> On Thu, Aug 03, 2023 at 01:19:14AM -0700, Harlan Stenn wrote:
> > 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.
>
> draft-stenn-ntp-i-do is nowhere close to publication. It can be easily
> updated to use other values if necessary. I'm not sure why the
> REFID-related capabilities should be tied to the EF numbering anyway.
> They should have their own space.
>
> > 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.
>
> 25 years of design that nobody implemented yet. It might help if you
> could show an example of what you see as the issue with flat 16-bit
> types causing unclean code.
>
> > 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.
>
> You are not the only one here with limited time to work on things.
>
> --
> Miroslav Lichvar
>
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp