Re: [Ntp] NTP Extensions (was Re: Last Call: <draft-ietf-ntp-using-nts-for-ntp-22.txt> (Network Time Security for the Network Time Protocol) to Proposed Standard)

[Harlan Stenn <[e-mail]>]

On 2/19/2020 1:59 PM, Watson Ladd wrote:
> On Wed, Feb 19, 2020 at 1:33 PM Harlan Stenn <[e-mail]> wrote:
>>
>> Except that we did discuss this, years ago, and there was a meeting with
>> me and Karen and I forget who else where we specifically said that
>> 0xnn04 was already allocated for NTS.  I've long been saying we need a
>> way to make progress with EF proposals that does not cause collisions
>> between inplementations and avoids flag days.  Furthermore, I told Karen
>> that the NTP Project was using 0xNN0[5-9] for other proposals and that
>> with no progress on changing the way the NTP Extension Field IANA
>> registry was being managed, that 1) the NTP Project has a chalkboard
>> that we're using for this purpose, and 2) if anybody wants to work on an
>> EF they should just let me know.
> 
> The way to achieve this is to make an experimental/private use range
> for the registry. The registry is currently IETF review, which is
> annoying: it's big enough to be Specification Required unless
> proposals take large chunks of the range. It's not impossible to
> change this with WG consensus.

Sorry, no.  There are 8 bits available for this.  If you would have
followed the design that was put in place 20 years ago you'd know this.

That so many folks want to ignore this and learn painful lessons all
over again is their choice.

H
--
> As for avoiding flag days, early drafts are going to evolve, breaking
> backwards compatibility anyway. I've always emphasized that we are
> going to have breaking changes in our NTP service until the draft
> stabilizes, I don't see how we can get any sort of experimental
> deployment unless we're willing to break the toys. (And no, they don't
> get to keep the pieces). One solution, copying from the TLS WG, is to
> have draft version numbers in the ordinary version negotiation
> mechanism, but that's not as suitable for an extension field.
> 
> We discussed a potential early allocation request at the virtual
> interim that would give us plenty of time to have implementations
> ready before RFC. There is no reason we can't all have implementations
> and deployments supporting the final RFC version and numbers when they
> come out.
> 
> Sincerely,
> Watson
> 

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