Subject: [Ntp] WGLC: draft-ietf-ntp-update-registries

From: Dieter Sibold <[email-masked]>
Date: Thu, 20 Jan 2022 17:57:58 +0100

Dear all,

this email starts a two week working group last call (WGLC) on:
https://datatracker.ietf.org/doc/draft-ietf-ntp-update-registries/

Please respond on the mailing list (keeping the subject line intact) with any comments you have on this document. Please also indicate your opinion on whether or not this document is sufficiently mature to advance to publication.

Sincerely
Karen and Dieter

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 20 Jan 2022 17:08:48 +0000

I'm the author, so I'm biased, but I think this is ready to advance.

---

From: Miroslav Lichvar <[email-masked]>
Date: Mon, 24 Jan 2022 08:51:31 +0100

> Please respond on the mailing list (keeping the subject line intact) with any comments you have on this document. Please also indicate your opinion on whether or not this document is sufficiently m…

I think it would be good to add some explanation for the "Many of the
entries in the Extension Field Types registry have swapped some of the
nibbles". The issue is that in ntpd - the original (and only
existing?) implementation of Autokey the values are swapped and this
update reflects that.

Other than that, I think it's ready to be advanced.

Thanks,

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jan 2022 14:56:47 +0000

Is this diff accurate and sufficient? If so, I will leave this as an edit after AD and IESG review.  If not, PELASE suggest better wordig.

diff --git a/draft-ietf-ntp-update-registries.md b/draft-ietf-ntp-update-registries.md
index e19a09c..fe49d8d 100644
--- a/draft-ietf-ntp-update-registries.md
+++ b/draft-ietf-ntp-update-registries.md
@@ -104,6 +104,8 @@ The following problems exists with the current registry:
 
 - Many of the entries in the Extension Field Types registry have
 swapped some of the nibbles; 0x1234 is listed as 0x1432 for example.
+This was due to documentation errors with the original NTP implementation
+of Autokey.
 This document marks the erroneous values as reserved.
 - Some values were mistakenly re-used.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 24 Jan 2022 14:04:30 -0800

> +This was due to documentation errors with the original NTP implementation

Why do you believe/maintain "This was due to documentation errors with 
the original NTP implementation of Autokey".

I do not believe that is the case.

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 24 Jan 2022 22:42:06 +0000

I assume this question is address to Miroslav, since I just quoted him in the doc.

>    I do not believe that is the case.

Do you have a suggestion for what I should write, instead?  Or should I make no change?

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 24 Jan 2022 14:53:12 -0800

> Do you have a suggestion for what I should write, instead?  Or should I make no change?

I'm working on a complete response to the draft.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 25 Jan 2022 09:12:19 +0100

> I assume this question is address to Miroslav, since I just quoted him in the doc.

I don't remember writing that sentence.

As I understand it, it was just a mistake in the Autokey draft in the
description of how the field type was encoded in ntpd. It seems the
code always had the "code" subfield in the lower bits of the 16-bit
field type, even when it was still Autokey version 0 and 1.

The R and E bits are described in the document as bit 0 and 1, but
those should be the highest bits, so it might just be a disagreement
in the bit numbering convention (left to right, or right to left?).

-- 
Miroslav Lichvar

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Jan 2022 15:46:24 +0000

>    I'm working on a complete response to the draft.

Nothing for me to do then.  Look forward to seeing your complete response, hopefully before the WGLC is done.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 25 Jan 2022 16:02:59 +0000

On 1/25/22, 3:12 AM, "Miroslav Lichvar" <[email-masked]> wrote:

>    I don't remember writing that sentence.

You didn't.  Sorry, I should have said "paraphrased"

So my wording above is accurate, although perhaps you think more elaboration is needed?
Maybe a link to the original draft if you have one?

Probably; figure 7 in RFC 5906 shows R E Code ... as the first three fields of the packet.

But I don't think it matters for this document.

---

From: Harlan Stenn <[email-masked]>
Date: Tue, 25 Jan 2022 18:05:15 -0800

> Maybe a link to the original draft if you have one?

Your wording is incorrect.

I am working on a complete response to the draft.

> But I don't think it matters for this document.

I think that is a big mistake.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 26 Jan 2022 14:44:03 +0000

I still see nothing for me to do until you finish your complete response, just claims that "this is wrong" etc.

I hope your response gets posted before WGLC ends.

---

From: Harlan Stenn <[email-masked]>
Date: Mon, 31 Jan 2022 14:44:38 -0800

Something has come up and I am requesting a 2 week postponement for the 
closing date of the last call.

The document is not ready for last call.  I will provide a detailed list 
as soon as I can.  I am Busy for the next 2 weeks.