Updating the NTP Registries
draft-ietf-ntp-update-registries-16

my discuss has been addressed.  I do still agree with Paul's discuss.

There seemed to be a need to update the NTP registries. I trust that the AD and the WG discussed the updates accordingly and that the dust settled properly on any updated values or allocation procedures

The IANA review of this document seems to not have concluded yet.

DOWNREF [RFC5906] from this Proposed Standard to Informational RFC5906. (For
IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and
also seems to not appear in the DOWNREF registry.)

DOWNREF [RFC7821] from this Proposed Standard to Experimental RFC7821. (For
IESG discussion. It seems this DOWNREF was not mentioned in the Last Call and
also seems to not appear in the DOWNREF registry.)

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.2, paragraph 4
> es registry. The following problems exists with the current registry: * Many 
>                                     ^^^^^^
The verb form "exists" does not seem to match the subject "problems".

I support Paul's DISCUSS.

From Section 2.1:

   Entries that start with 0x58, the ASCII letter uppercase X, are reserved for Private or Experimental Use.

This is continued in later sections.  We formally discontinued this practice in BCP 178, at least for header field names, media type registrations, and similar.  Do we need to preserve this for these registries or is it obsolete there too?

In Section 4.2:

   The existing entries are left unchanged. ## NTP Extension Field Types

I think this should've been a section break.

# Orie Steele, ART AD, comments for draft-ietf-ntp-update-registries-13 
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-ntp-update-registries-13.txt&submitcheck=True

## Comments

I support Deb's DISCUSS, and Paul's DISCUSS.


```
158	   *  Many of the entries in the Extension Field Types registry have
159	      swapped some of the nibbles; 0x1234 is listed as 0x1432 for
160	      example.  This was due to documentation errors with the original
161	      implementation of Autokey.  This document marks the erroneous
162	      values as reserved, in case there is an implementation that used
163	      the registered values instead of what the original implementation
164	      used.

166	   *  Some values were mistakenly re-used.
```

^ this section could be improved by listing the entries that were swapped and their corrected values, and identifying the values that were mistakenly reused.

I agree with Paul's comment regarding "NTP Kiss-o'-Death Codes".

Perhaps something like "NTP Rate Limited Error Codes", with a note that these codes are historically referred to as "NTP Kiss-o'-Death Codes".

I support Deb Cooley's DISCUSS position.

** idnits reports the following:
 
 -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
     have content which was first submitted before 10 November 2008.  If you
     have contacted all the original authors and they are all willing to grant
     the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
     this comment.  If not, you may need to add the pre-RFC5378 disclaimer. 
     (See the Legal Provisions document at
     https://trustee.ietf.org/license-info for more information.)

Please update the boilerplate.

I am stealing this from Eric's review: "Thanks for this document, it seems that it was really required."; I'm glad that someone cares enough to do this, and even more glad that it's not me...

I support Paul's DISCUSS, and am assuming that it will be addressed - these seem like needed cleanup.

Thanks for working on this specification. No objection from transport protocol considerations, However, I am supporting Deb and Paul's discuss.

Thanks for this document, it seems that it was really required.

Some non-blocking COMMENTs though.

Outdated shepherd write-ups cannot be DISCUSSed during the ballot but the 2022 write-up would benefit from an update. How can `One person expressed strong opposition` and `There has been no controversy about particular points.` coexist in the write-up ? Later `The summarized list of conflicts shall be send to the responsible AD.` has this been done ?

Why having NTS in the abstract and in the introduction and later in section 2.1 writing `no changes to them are specified in this document.`