Subject: [Ntp] Experimental extension fields

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 15 Dec 2020 13:32:52 +0100

I'd like to start experimenting with some of the new features proposed
for NTPv5, in a form of an NTPv4 extension field.

What is the recommended range for experimental EF types? IIRC there
was a discussion about this (on a WG meeting?) when experimental
implementations of NTS were starting, but I don't remember the
conclusion.

Would it be ok if I picked a random number from the 0x..FF range?

-- 
Miroslav Lichvar

---

From: Danny Mayer <[email-masked]>
Date: Tue, 15 Dec 2020 12:11:22 -0500

> Would it be ok if I picked a random number from the 0x..FF range?
I would recommend using the high numbers. I generally see other 
protocols doing this when conducting experiments and when something is 
approved it gets a new value in the low range.

Danny

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Dec 2020 17:20:14 +0000

Looking at the IANA registry, https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml ...

Wow.  That is really outdated with respect to current practice.  We should block off a range for experimentation, and change things to be "designated expert"  Anyone want to help write a draft that makes those changes?

---

From: James <[email-masked]>
Date: Tue, 15 Dec 2020 18:26:27 +0100

I'd be happy to help out with writing the draft, however not trying to
conflate matters wonder if we should leave it for NTPv5, or apply it to the
existing registry for v4?

- J

On Tue, 15 Dec 2020 at 18:20, Salz, Rich <rsalz=[email-masked]>
wrote:

> Looking at the IANA registry,
> https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml ...
>
> Wow.  That is really outdated with respect to current practice.  We should
> block off a range for experimentation, and change things to be "designated
> expert"  Anyone want to help write a draft that makes those changes?
>
>
>
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
>

---

From: Danny Mayer <[email-masked]>
Date: Tue, 15 Dec 2020 13:20:17 -0500

> Wow.  That is really outdated with respect to current practice.  We should block off a range for experimentation, and change things to be "designated expert"  Anyone want to help write a draft that…

They're not really outdated. I was responsible for all of those RFC5906 
ID's after 3 months of working with Dave Mills on it so that the draft 
could be completed. They are all autokey ones. It was the design of 
Autokey that resulted in that long list. Autokey is almost obsolete but 
NTS doesn't replace it in all of the modes.

I'd be happy to work on an extension field update draft.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Tue, 15 Dec 2020 13:21:09 -0500

I don't think it matters if it is V4 or V5, they should be compatible.

On 12/15/20 12:26 PM, James wrote:
> conflate matters wonder if we should leave it for NTPv5, or apply it 
> to the existing registry for v4?
>
> - J
>
>
> On Tue, 15 Dec 2020 at 18:20, Salz, Rich 
> <rsalz=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml
>     <https://www.iana.org/assignments/ntp-parameters/ntp-parameters.xhtml>
>     ...
>
>     Wow.  That is really outdated with respect to current practice. 
>     We should block off a range for experimentation, and change things
>     to be "designated expert"  Anyone want to help write a draft that
>     makes those changes?
>
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ntp>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 15 Dec 2020 19:49:49 +0000

*   I'd be happy to help out with writing the draft, however not trying to conflate matters wonder if we should leave it for NTPv5, or apply it to the existing registry for v4?

I think we should change the current registries to be designed-expert and then if NTPv5 adds more registries they just follow the newly-installed pattern.

Designated experts are usually picked by the AD and formally set up by the IESG. If there’s more than one, a majority approval is needed.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 16 Dec 2020 09:59:35 +0100

On Tue, Dec 15, 2020 at 12:11:22PM -0500, Danny Mayer wrote:
> I would recommend using the high numbers. I generally see other protocols
> doing this when conducting experiments and when something is approved it
> gets a new value in the low range.

That would be my first pick, but I thought that doesn't work well with
the ntp.org implementation, which interprets some high-order bits, and
is the reason why even the non-Autokey types were assigned in the
low-order scheme?

There is also the issue that the one known Autokey implementation is
using different types than what is in the registry and RFC.

If this can be addressed in a draft, that would be great.

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 16 Dec 2020 04:00:22 -0800

> If this can be addressed in a draft, that would be great.

I think I'll just enjoy my popcorn.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Dec 2020 14:51:23 +0000

Can you post the assigned and used numbers?  Thanks.

My goal is to have a skeleton and GitHub repo up today or tomorrow.

---

From: Miroslav Lichvar <[email-masked]>
Date: Wed, 16 Dec 2020 16:27:24 +0100

> Can you post the assigned and used numbers?  Thanks.

0x0002 0x0200 No-Operation Request
0x8002 0x8200 No-Operation Response
0xC002 0xC200 No-Operation Error Response
0x0102 0x0201 Association Message Request
0x8102 0x8201 Association Message Response
0xC102 0xC201 Association Message Error Response
0x0202 0x0202 Certificate Message Request
0x8202 0x8202 Certificate Message Response
0xC202 0xC202 Certificate Message Error Response
0x0302 0x0203 Cookie Message Request
0x8302 0x8203 Cookie Message Response
0xC302 0xC203 Cookie Message Error Response
0x0402 0x0204 Autokey Message Request
0x8402 0x8204 Autokey Message Response
0xC402 0xC204 Autokey Message Error Response
0x0502 0x0205 Leapseconds Message Request
0x8502 0x8205 Leapseconds Message Response
0xC502 0xC205 Leapseconds Message Error Response
0x0602 0x0206 Sign Message Request
0x8602 0x8206 Sign Message Response
0xC602 0xC206 Sign Message Error Response
0x0702 0x0207 IFF Identity Message Request
0x8702 0x8207 IFF Identity Message Response
0xC702 0xC207 IFF Identity Message Error Response
0x0802 0x0208 GQ Identity Message Request
0x8802 0x8208 GQ Identity Message Response
0xC802 0xC208 GQ Identity Message Error Response
0x0902 0x0209 MV Identity Message Request
0x8902 0x8209 MV Identity Message Response
0xC902 0xC209 MV Identity Message Error Response

Only the three Certificate Message types are used as assigned.

The used Autokey Message Request (0x0204) conflicts with the NTS
Cookie. That's unfortunate.

> My goal is to have a skeleton and GitHub repo up today or tomorrow.

Great. Thanks!

-- 
Miroslav Lichvar

---

From: Harlan Stenn <[email-masked]>
Date: Wed, 16 Dec 2020 12:10:47 -0800

> 0xC902 0xC209 MV Identity Message Error Response

There should be no conflict in practice.  The legacy autokey
implementation does not do any other EF types.

> Cookie. That's unfortunate.

I don't think it will be a problem in practice.

No legacy autokey is expected to be using the V2 EF bit layouts.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 16 Dec 2020 15:20:06 -0500

I think the right way to handle the Autokey numbers is to keep the existing
registrations in place, and mark the ones in use by the ntp.org
implementation as Reserved to keep IANA from assigning them
to something else by accident. Whatever we use for P&E range, avoid having
it overlap with those numbers. Is that roughly your plan?

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Dec 2020 22:42:59 +0000

Yes.

From: Daniel Franke <[email-masked]>
Date: Wednesday, December 16, 2020 at 3:20 PM
To: "Salz, Rich" <rsalz=[email-masked]>
Cc: Miroslav Lichvar <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [Ntp] Experimental extension fields

I think the right way to handle the Autokey numbers is to keep the existing registrations in place, and mark the ones in use by the ntp.org<https://urldefense.com/v3/__http:/ntp.org__;!!GjvTz_vk!EvpxDHy6Tec3oRUTwbunID4wPOqEsgW_Hsa_fcxuD8mRU1_-8ul5WRWzE5Xs$> implementation as Reserved to keep IANA from assigning them to something else by accident. Whatever we use for P&E range, avoid having it overlap with those numbers. Is that roughly your plan?

On Wed, Dec 16, 2020 at 9:51 AM Salz, Rich <rsalz=[email-masked]<mailto:[email-masked]>> wrote:
    There is also the issue that the one known Autokey implementation is
    using different types than what is in the registry and RFC.

_______________________________________________
ntp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ntp<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ntp__;!!GjvTz_vk!EvpxDHy6Tec3oRUTwbunID4wPOqEsgW_Hsa_fcxuD8mRU1_-8ul5Wd7-UJ0p$>

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 17 Dec 2020 07:56:15 +0100

>>> Miroslav Lichvar <[email-masked]> schrieb am 16.12.2020 um 16:27 in
Nachricht <20201216152724.GI2567995@localhost>:
> 0x0002 0x0200 No‑Operation Request
> 0x8002 0x8200 No‑Operation Response
> 0xC002 0xC200 No‑Operation Error Response

Hi!

I'd still wish the specific request/response/error bits had not been part of
the extension field number, but instead would be bits inside the extension
field.
Then the number sopece would be less fragmented. What if some sub-protocol
needs more bits that those two (response, error)? Allocate even more extension
field numbers?
Also should extension field number 0x4902 (just one example) be assignable?
Per list it's available?

Regards,
Ulrich

> ‑‑

---

From: Danny Mayer <[email-masked]>
Date: Thu, 17 Dec 2020 09:13:16 -0500

> Also should extension field number 0x4902 (just one example) be assignable?

That was the problem. It shouldn't put what are really status bits in 
the extension field ID. They belong in the body of the extension field. 
That's why you see the mess above and took months to sort out. If the 
list is actually incorrect then that should be corrected.

Danny