Subject: Re: [Ntp] New Version Notification for draft-rsalz-update-registries-00.txt

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 4 Jan 2021 15:47:35 +0100

On Tue, Dec 22, 2020 at 08:25:49PM +0000, Salz, Rich wrote:
> This is the promise draft to update all NTP/NTS registries.  Contributions, pull requests, etc., encouraged.  Discuss on this list, or at https://github.com/richsalz/draft-rsalz-update-registries

Is it ok to refer to RFC 5906 for the swapped values, when it's only
used by the (one existing) implementation and not the specification?

I liked the Daniel's idea to keep them both, the original values
unchanged and then mark the swapped set as reserved, occupied, or
similar.

I'm ok with the the proposed range 0xD000-0xFFFF for experimenal
extension fields, but others here probably will not like it as it will
randomly set the "response" and "error" flags in their interpretation
of the value.

Thanks,

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 4 Jan 2021 14:59:21 +0000

I think so, but

If we're listing them as reserved, we should put them in the RFC.  I'll do that today or tomorrow.

Is there a better way to word this (at least in the text, not necessarily in the registry) so that the response and error flags are maintained?  "PR's welcome" :)

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jan 2021 15:42:19 +0000

>    If we're listing them as reserved, we should put them in the RFC.  I'll do that today or tomorrow.

New commit pushed to the repo, https://github.com/richsalz/draft-rsalz-update-registries/commit/2eecd8c308ade0a9f8dce6231f3cc8fcbc5e06bc

So the registry contains more than just the extension field type, it contains the length and those flag bits.  The following diff tries to capture that, is it correct?

And also where are the response and error flags defined?  A quick search in RFC 5905 didn't find anything obvious.
diff --git a/draft-rsalz-update-registries.md b/draft-rsalz-update-registries.md
index 7d62fdd..575d101 100644
--- a/draft-rsalz-update-registries.md
+++ b/draft-rsalz-update-registries.md
@@ -86,8 +86,12 @@ around the interaction with the Message Authentication Code (MAC) field.
 The following problems exists with the current registry:
 
 - Many of the entries in the Extension Field Types registry have
-swapped nibbles (half of a byte).
+swapped some of the bytes; 1234 is listed as 1432 for example.
 This document marks the erroneous values as reserved.
+- The field type registry includes the Field Type, as defined in Figure
+14 of {{!RFC5905}}, but also the length. This is arguably an error, but
+one we will preserve as existing software might depend on the length values
+being fixed.
 - Some values were mistakenly re-used.
 
 ## Network Time Security Registries
@@ -174,7 +178,7 @@ possible, replace the existing 5905 with 5906.
 
 The following Note is added:
 
-- Field Types in the range 0xD000 throught 0xFFFF, inclusive, are reserved
+- Field Types in the range 0xD000 through 0xFF00, inclusive, are reserved
 for experimentation and development. IANA cannot assign them.
 Both NTS Cookie and Autokey Message Request have the same Field Type;
 in practice this is not a problem as the field semantics will be
@@ -182,7 +186,8 @@ determined by other parts of the message.
 
 The columns are defined as follows:
 
-- Field Type (required): A two-byte value in hexadecimal.
+- Field Type (required): A four-byte value in hexadecimal, that includes
+the type as the top two bytes and the length as the bottom two.
 
 - Meaning (required): A brief text description of the field type.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 6 Jan 2021 11:02:38 -0500

On Wed, Jan 6, 2021 at 10:42 AM Salz, Rich <rsalz=
[email-masked]> wrote:

> And also where are the response and error flags defined?  A quick search
> in RFC 5905 didn't find anything obvious.
>
> They're only defined within the context of Autokey. RFC 5906 describes
them, but fails to reserve the registry space that it would need to use
them correctly.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 6 Jan 2021 19:51:58 +0000

On Wed, Jan 6, 2021 at 10:42 AM Salz, Rich <rsalz=[email-masked]<mailto:[email-masked]>> wrote:
And also where are the response and error flags defined?  A quick search in RFC 5905 didn't find anything obvious.

  *   They're only defined within the context of Autokey. RFC 5906 describes them, but fails to reserve the registry space that it would need to use them correctly.

Thanks for the pointer.  Reading Section 10 of RFC 5906 closely, it looks like the partitioning of the field type into R/E/Code/Field parts is limited purely to autokey, and not intended to apply to extensions overall.

I added some text to make things more clear: https://github.com/richsalz/draft-rsalz-update-registries/commit/fa99c0aefc1a7c5071b5a70f69d70d5b7737a8bb

---

From: Miroslav Lichvar <[email-masked]>
Date: Thu, 7 Jan 2021 11:48:46 +0100

> +one we will preserve as existing software might depend on the length values

That doesn't seem right to me. The field type registry doesn't include
the length. All values there are 16-bit. The length is in the other 16
bits of the 32-bit EF header.

> +- Field Types in the range 0xD000 through 0xFF00, inclusive, are reserved

If we wanted to avoid non-zero values in the Autokey error and
response flags, the range would be 0x3000 through 0x3FFF. 

> +the type as the top two bytes and the length as the bottom two.

Just 16 bits for the type, no length. (bytes are arch-specific.)

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jan 2021 13:50:18 +0000

Miroslav,

Thanks very much for the corrections.

Somehow my eyes got crossed and I was confusing nibble and byte, so I thought of 0x1234 as a 32-bit value, not a 16-bit one.  Ugh.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 7 Jan 2021 14:24:21 +0000

Do we want to do this?  The WG can decide when/if this is adopted I guess.

(I changed the range to be 0xF000 through 0xFFFF which seems plenty.)

---

From: Danny Mayer <[email-masked]>
Date: Sun, 17 Jan 2021 22:35:29 -0500

On 1/6/21 2:51 PM, Salz, Rich wrote:
>
> On Wed, Jan 6, 2021 at 10:42 AM Salz, Rich 
> <rsalz=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     And also where are the response and error flags defined?  A quick
>     search in RFC 5905 didn't find anything obvious.
>
>   * They're only defined within the context of Autokey. RFC 5906
>     describes them, but fails to reserve the registry space that it
>     would need to use them correctly.
>
> Thanks for the pointer.  Reading Section 10 of RFC 5906 closely, it 
> looks like the partitioning of the field type into R/E/Code/Field 
> parts is limited purely to autokey, and not intended to apply to 
> extensions overall.
>
That was the intent  of the registry entries and it may have been 
incorrectly set up. It was a bad idea to put these bits into the 
extension id field in the first place so this was the best way to 
reserve the fields so that the rest of the ID's were available without 
totally destroying the way extension fields were meant to be.

It took a while to get this set up but at least it allowed autokey 
(RFC5906) to move forward.

Danny

---

From: Harlan Stenn <[email-masked]>
Date: Sun, 17 Jan 2021 21:29:11 -0800

Danny,

> totally destroying the way extension fields were meant to be.

Are you talking about the top few bits of the EF?  If so, I'd agree with
you if you were right.

There's clear implementation benefit to having at least the
Query/Response bit visible very early.  I've written about this many
times.  Dave has said this, too.

It is a clear feature, not a bug.

> (RFC5906) to move forward.

Huh?

> Danny
> 
> 
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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

---

From: Danny Mayer <[email-masked]>
Date: Mon, 18 Jan 2021 20:24:05 -0500

> times.  Dave has said this, too.
I don't disagree that having the Query/Response/Error bits visible very 
early. The disagreement is where they should go. They belong in the body 
of the extension field and not in the extension field ID. The bits are 
private to the extension field. Nothing else needs to know about them.
> It is a clear feature, not a bug.
It's a misimplemented feature.  I'm not calling it a bug.
>> (RFC5906) to move forward.
I spent 3 months working on this with Dave to get this RFC draft into a 
form acceptable to the IETF because of this issue.

Danny

---

From: "Ulrich Windl" <[email-masked]>
Date: Tue, 19 Jan 2021 08:45:26 +0100

>>> Danny Mayer <[email-masked]> schrieb am 19.01.2021 um 02:24 in

> private to the extension field. Nothing else needs to know about them.

I fully agree.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 19 Jan 2021 13:49:09 +0000

>    I fully agree.

I agree.  We're not changing existing definitions/values, but we probably don't want to promulgate that going forward.  Section 10 of RFC 5906 divides the field into four parts, but only for autokey.  I don't know that the draft needs any wording changes (since I just quoted it :) but am happy to take feedback.