Re: [Ntp] Registries document

[Harlan Stenn <[e-mail]>]

The document still contains far too much materially incorrect information.

Items I have repeatedly mentioned before that have not been corrected.

1. Introduction still says "Some registries have wrong values, ..." and 
I will be reading the rest of the document to see if this assertion is 
validly supported or not.

2.2 Extension Field Types.  The claim that "RFC5906 Section 10 splits 
the Field Type into four subfields, only for use within the Autokey 
extension" remains flat out wrong.  The specified subfields have been 
used by other, now formalized EF documents, as well as by a number of 
proposals submitted to the WG by the NTP Project.  They have been a 
day-one foundational design component of extension fields.

The claim that "Many of the entries in the Extension Field ... This 
document marks the erroneous values as reserved, in case there is an 
implementation that uses the registered values instead of what the 
original implementation used."  This is a materially incorrect statement 
and assessment of the situation.  We have repeatedly cited code and 
practice to this effect.  What was implemented and deployed was the V1 
EF format.  RFC 5906 documents the V2 EF format.

Therefore, the claim that these values are "erroneous" is materially 
incorrect.

The NTP Project's Reference Implementation, the basis of ALL of the IETF 
NTP Standards to-date, has clearly demonstrated (with working code) that 
it is very easy to decide if the V1 or V2 EF format should be used, and 
NO interoperability problems have been observed.  From this, it is 
evident that there is no need to "reserve" any values.

Is the claim that "Some values were mistakenly re-used." accurately 
substantiated?  If this claim is in reference to the second sentence of 
the first note in 4.3, the answer is "no".

3. Updated Registries.

"Every registry reserves a partition for Private or Experimental Use."
Why?  There are some registries where this is not needed, and from what 
I can see this document does not specify these "partitions".  For some 
registries this has been shown to be actively counter-productive.  So 
why is this stated as a general guideline to be applied to all 
registries updated in this document?

"Entries with ASCII fields are now limited to uppercase letters;..." 
Why?  There are registries used by NTP, including the Stratum 1 REFID, 
where mixed-case values are in current, active use.

The bit about 3 Designated Experts is particularly troubling to me, 
because I do not see how the IESG is supposed to choose these designated 
experts.  Where can one learn more about this process, and if there is a 
means to appeal the selection of a DE who is considered (by whom?) to be 
unqualified (or worse)?

Even more concerning, *I* don't know 3 experts in this area.

4.1 NTP Reference Identifier Codes.  As I mentioned above, this change 
breaks active current use (NIST's ongoing use of Nut1 for its public UT1 
time servers, for example).

4.3 NTP Extension Field Types.

The first note states Field Types in the range 0xF000 through 0xFFFF, 
inclusive,  are reserved.  This perpetuates the materially incorrect and 
harmful recently-invented position that EF codes have significance 
starting with the highest-order nibble.  This is fundamentally wrong and 
incorrect.

Later in the first note it says "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 determined by other parts of the message." 
This too, is a materially incorrect understanding of how EFs work, and 
is fundamentally wrong.  As I have repeatedly shown in the past, as 
evidenced by the reference implementation, deployed Autokey uses the V1 
EF format, and NTS and other new EFs use the V2 EF format.  While it is 
theoretically POSSIBLE that somebody COULD make an implementation that 
freely intermixes V1 and V2 EF packet formats, can anybody imagine a 
sane reason that would be done?  It is also POSSIBLE to implement 
autokey as specified in RFC 5906, using the V2 EF format.  In this case, 
there is no collision with the NTS Cookie EF is 0x0204 while the Autokey 
Message Request is clearly shown to be 0x0402 in RFC 5906, Section 13.

The second note says: The "Reserved for historic reasons" is for 
differences between the ... and the erroneous values as reserved, in 
case there is an implementation that used the registered values instead 
of what the original implementation used."

That is a materially incorrect and fundamentally flawed interpretation 
of reality.  I wonder who considers it disrespectful.

Earlier in the document are references to "Designated Experts", in both 
singular and plural forms.  Given what I have read in this document so 
far, all I will say is that it seems critically important that a DE 
understands and operates from a thoroughly competent, aware, and 
conscious understanding of these registries and their foundational 
expectations.

The table itself is still, IMO, a mess.  It is sorted "hexanumerically" 
from the most- to least-significant digits.  That might be useful for a 
quick lookup, but since there is so little information given in most of 
the third column (Reference), what is the actual benefit of a slightly 
faster lookup?

Entries in this table should first be sorted by the 2 low-order hex 
digits, then the next higher order digit, and finally by the 
highest-order hex digit.  This follows the 24 year history of the format 
of an extension field that this document apparently seeks to 
ignore/overturn/erase.

Case in point, the first entry in the table is:

  0x0002 | Reserved for historic reasons | This RFC

Why hide so much information?  Anybody who chooses to implement Autokey 
using the V2 EF format, which is exactly what is being described here, 
should see:

  0x0002 | Autokey: No-Operation Request | RFC 5906

followed by:

  0x8002 | Autokey: No-Operation Response | RFC 5906
  0xC002 | Autokey: No-Operation Error Response | RFC 5906
  ...
  0xC902 | Autokey: MV Identity Message Error Response | RFC 5906
  0x0003 | MAC Extension Field | draft-stenn-ntp-mac-last-ef
  0x0103 | MAC Extension Field (1 or more MACs) | 
draft-stenn-ntp-mac-last-ef
  0x0104 | NTS: Unique Identifier | RFC 8915
  0x0204 | NTS Cookie | RFC 8915
  0x0304 | NTS Cookie Placeholder | RFC 8915
  0x0404 | NTS Authenticator and Encrypted Extension Fields | RFC 8915
  0x2005 | Checksum Complement | RFC 7821
  0x0006 | Suggested REFID | draft-stenn-ntp-suggest-refid
  0x0007 | I-DO | draft-stenn-ntp-i-do
  0x8007 | I-DO Response | draft-stenn-ntp-i-do
  0x0008 | Last Extension Field | draft-stenn-ntp-mac-last-ef
  0x0009 | Extended Information | draft-stenn-ntp-extended-information-ef
  0x0109 | Extended Information, Version 1 | 
draft-stenn-ntp-extended-information-ef

Yes, I know I have cited expired drafts above.  But as I informed at 
least Karen, several years' ago, these EF types are the ones we have 
used and deployed, and at the time Karen said we should just pencil them 
in on our "Assigned EF type" list until the IANA registry changes were made.

And if one wants to be thorough, the EF table above can be more 
accurately called the "Version 2 Extension Field Table", and a "Version 
1 Extension Field Table" can also be provided, which lists the Autokey 
values used by the deployed Reference implementation.

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