Re: [Ntp] Quick review of WGLC for status change for draft-ietf-ntp-update-registries

[Harlan Stenn <[e-mail]>]

On 8/8/2022 5:39 AM, Miroslav Lichvar wrote:
> On Mon, Aug 08, 2022 at 03:35:40AM -0700, Harlan Stenn wrote:
>> While re-reading to find my answer, I note 4.3 says that Field Types from
>> 0xF000 through 0XFFFF are reserved for experimentation and development.
>>
>> This makes no sense to me.
>>
>> If this experimental/development work is done "privately" then nobody cares
>> what value is used.
> 
> It avoids conflicts with properly specified extension fields. With an
> experimental extension field the user is responsible to enable it only
> if the server is known to support it.

Sorry, this still makes no sense to me.

Before I go on, what are the "conflicts with properly specified 
extension fields"?

It makes more sense to me to use the existing model.  If somebody wants 
to experiment, assign them the next unused number in the registry, say, 
0x**0A,  That give them plenty of (sub)code bits (up to 6, and to date 
no proposal has used more than 4 bits) for whatever purpose they want.

If they decide to go thru with them, they can either publish the 
specific code(s) (n) and use the existing 0x*n0A numbers in the wild, or 
ask for the next allocation.

>> Next, if this experimental/development work gets turned into a Standard,
>> then implementations will likely need to support both the Standard and the
>> experimental versions.  That's needless code bloat.
> 
> No, if it's documented as an experimental feature, it can be dropped
> or changed at any time.

That's still the case.  But as I said before, once something has been 
used it will live on.  The mess remains.

> One use case is testing of some NTPv5 features. We can't use NTPv5 as
> it doesn't exist yet, but we can use an experimental NTPv4 extension
> field that contain the new NTPv5 fields.

OK, that's fine.  So ask for a Type Field for NTPv5 testing, and use the 
code field to specify them.  How many of these fields do you think 
you'll want?  The existing mechanism will give you 64 fields from a 
single allocation.  If you need more, get a 2nd allocation.

>> I'll also point out that, as noted in draft-stenn-ntp-extension fields, a
>> number of 0xFxFF values are being used for the I-DO extension field
>> proposal, as documented in draft-stenn-ntp-i-do.
> 
> The draft expired long time ago. If you decide to resubmit it, I'm
> sure you can change it to another value.

Karen told me the WG consensus was to drop all my proposals, and further 
informed me that future submissions from me would not be considered.

I have no plans to pursue my proposals via the Standards track of the 
WG, or perhaps thru the WG at all.

> But I don't think the I-DO EF is a good solution to the issue with
> ambiguous parsing. It assumes the server doesn't change since the
> support was negotiated. NTP is (mostly) stateless. The client cannot
> be sure it's talking to the same server from which it received the
> last response. A server can be changed, upgraded, or redirected in
> network.

What is this "ambiguous parsing" you describe?

How is this relevant to draft-ietf-ntp-update-registries?

I understand your concerns, and in the general case I don't see it as a 
problem.  I also see easy ways for a server that understands I-DO to 
tell a client to renegotiate.

>> Also, as I'm more carefully reading the proposal, I find it curious that you
>> are are not objecting to its citing of 5906. I recall that you have
>> explicitly ignored that document when writing chrony, at least around the
>> numeric range of keyIDs, because 5906 was "informational" and not listed as
>> an optional Standard.
> 
> chrony does not support Autokey. It doesn't care that keys with some
> specific IDs are generated automatically. It cannot authenticate as an
> Autokey server and will not accept a response from an Autokey server.

Sure.  And if chrony tries to use a KeyID that is "out of range" with 
ntpd, what happens?  My point is that you chose to ignore some of the 
behavioral restrictions of 5906 because (as I recall) late in that 
process, it changed from Standards track to informational, and arguably, 
some 2nd (or 3rd) order effects of that change were not ... appreciated.

>>> The Checksum Complement EF (0x2005) is present in the table 1, but it
>>> is incorrectly described as "Reserved for historic reasons". That
>>> should be changed to refer to RFC 7821. Only the Autokey-related
>>> entries should be "Reserved for historic reasons".
>>
>> I do not believe there is *any* reason that the V1 EF format values
>> (assuming that is what the "Reserved for historic reasons" is referring to)
>> cannot be used by the current/V2 handlers.
> 
> V1 and V2 is specific to Autokey. There is a specification which
> nobody follows. There is an implementation that uses unspecified
> values. The table is trying to cover all values. I don't think it
> matters which one is marked as "reserved for historic reasons". What
> is important is that nothing else will be using them. We already had a
> collision with one of the NTS extension fields. That must be
> prevented.

That's your opinion.  The spec has been there.  The spec was clearly 
followed for checksup complement and for NTS.  Therefore, it's arguable 
that your opinion is demonstrably incorrect.

There is NO REASON the "reserved for historic reasons" items cannot be 
used in the V2 packet format, as I have already said.

I'm curious about the collision with an NTS extension field.  I suspect 
that was simply a result of poor programming on the implementor's side, 
but I could be wrong.

Earlier you wrote:

 > With an
 > experimental extension field the user is responsible to enable it only
 > if the server is known to support it.

If that statement from you is correct, then was the collision with an 
NTS EF the result of responsible or irresponsible user behavior?

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