Re: [Ntp] Registries document

[Harlan Stenn <[e-mail]>]

Since my meeting registration hasn't gone thru yet, I'll reply here.

On 7/27/2023 2:09 PM, Salz, Rich wrote:
>> The document still contains far too much materially incorrect information.
> 
> Let's go through this email message point-by-point, then. I do not want to do this and I apologize for the length of this note. I tried to keep it short, and I shortened, perhaps too much, the context of the original message. For those who have a hard problem maintaining the context, please see Harlan's full message at https://mailarchive.ietf.org/arch/msg/ntp/6Wc2wJQpLZYRcyqR9GzKNPufJ7I/
> 
> If you don't want to read all of this text, here is a summary of my responses:
> 1. I suggest one editorial wording change to address one point
> 2. There are many opinions expressed that are "in the rough" in terms of IETF consensus
> 3. There currently-open issues are also mentioned
> 4. There are some questions along the lines of "why did you do this"
> 
>> 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.
> 
> Okay, so this is not (yet?) materially incorrect.

 From my POV, at the end of my message I have shown that the original 
document has no wrong values.  For those who agree with me, that would 
show the assertion was not validly supported.

>> 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.
> 
> I just re-read Section 10 of RFC 5906.  It talks only about the four subfields in the context of "Autokey protocol messages."  In fact, that's the title of the section. Are there other RFCs related to this?  To the best of my recollection there are/were some extension field *drafts* that were not adopted by the WG. I do not disagree that they were a day-one feature, since 5906 closely followed 5905 :).

So what?

That the EFs were only described in 5906 is a red-herring, at least to 
those of us who have been involved with the reference implementation and 
the RFC process over the long haul.

When was the first public release of ntp-4.0, code that contained 
Autokey, the first (and for a long time, the only) use of EFs?

When was draft-00 of the Autokey document?

When was RFC 5906 published?

When was any (significant?) code that was not based on the reference 
implementation released that actually used EFs?

The EF Field Types used by NTS follow the format described in 5906.

Why in this context is it significant that the WG did not adopt the 
proposals I submitted?  That code is still there, and will be released soon.

> Does this wording address your issue?
> 	"into four subfields, originally defined for use by Autokey, but since adopted by other implementations"

Absolutely not.

Those subfields are part of the core EF format and structure, and are 
not specific to Autokey.

>> 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.
> 
> There seemed to be strong consensus to call the V1 values "wrong". In fact, saying "that is V1 and the RFCs document V2" seems revisionist. Addressing WG consensus point, the wording was contributed by Dieter and see the on-list discussions from around February 2022.

So what?

I invite you to consider that the revisionist approach here is to 
disagree with the reality based on 24+ years of reality.

Dave Mills and I were in fairly constant communication about this and 
other NTP-related discussions since the mid-90s, about 30 years' ago.

I don't recall seeing Dieter participate in any of the discussions 
around EF formats back then, at least as far as the codebase is concerned.

Who in the group of "strong consensus" holders says they were actually 
active participants in the codebase maintenance and development?

>> 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".
> 
> Yes, NTS would not have used a value if the authors saw it was already in a registry. The authors have said this. Therefore, it was a mistake.

Your opinion.  You have restated your claim that that it is a mistake, 
but you have not refuted any of the evidence I have given that there is 
no collision with what was (correctly) in the registry.

If I am given public assurance that you and those who stand with you 
will not again torpedo drafts from me that will address this, I will 
resubmit for Standards track.

Otherwise, I will likely submit informational drafts to the same effect.

>> "Every registry reserves a partition for Private or Experimental Use."
> Why
> 
> Because in my experience this is a current best practice for IANA registries. This is a difference of opinion, not materially incorrect information.

That it is often useful does not mean it is useful here.

I have repeatedly emailed about why an experimental block is 
counter-productive.  I have never said private use is a bad thing, but 
it appears to be at best a poor choice when considering how one would 
use it in the real world.

You have never *shown* how reserving a block will actually be useful. 
Unless I'm missing something,  you have only said that it works well for 
other situations.

The fact that you have asked for 0xF000 thru 0XFFFF is another example 
of "materially incorrect", and tells *me* that you do not 
understand/accept how EFs work.  Yes, you can be revisionist and say "if 
we accept that the four subfields do not apply beyond Autokey and we 
ignore the same for 7821 and NTS and the proposals that got implemented 
but the WG dropped at the meeting Harlan wasn't able to attend" then 
sure, you can say the ship should be sailing in a different direction.

If, instead, you had asked for 0x..0F thru 0x..FF then that would have 
been fine with me.

>> "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.
> 
> This is being revisited at tomorrow's NTP session.

That's nice, and it goes to my pointing out that there are clearly (what 
I, at least, consider to be) defects in the document as presented.

>> 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,
> 
> RFC 8720 and RFC 8126 are good starting points.  This point does not identify materially incorrect information.

Thanks, and true.  And it *might* be better that what we had before. 
But the change is still very troubling to me, in that a simple majority 
of what I will call inadequately aware DEs can trivially cause Big Problems.

Kinda like when focusing on consensus instead of actual (high) quality.

>> 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).
> 
> Yes, already planned to discuss at this IETF meeting.
> 
>> 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.
> 
> It does not perpetuate any such thing. It merely partitions the registration space.

I believe I have clearly demonstrated otherwise.  You have not refuted 
my evidence.

Your "partitioning" is revisionist and breaks established practice.

See my comment above about the experimentat/private range.

> [ much elided ]
> 
>> 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.
> 
> This is re-raising the extension field format issue already discussed above.

Toward what end?

> The first public mention of NTP extension fields is in the autokey specification.  Is there any IETF document that defines the so-called "V1 extension field" format?  I was unable to find one in my searching through the RFCs.

Maybe in the early drafts of 5906.

But who cares, and why?  It is historical.

And as I wrote above, if I am shown public assurance that proposals that 
address the overall EF format (including the historical V1 format and 
table) will not be torpedoed (note I am not asking they be supported), I 
will provide them.

>> Earlier in the document are references to "Designated Experts", in both
> singular and plural forms.
> 
> Minor typo's, fixed in my editor's copy.

Thanks.

>> 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?
> 
> This is standard practice for registries; optimize for human lookup.

Except it's not really optimized for human lookup.

Please compare the tables sorted both ways.

Anybody who knows about the subfields will instantly understand and get 
a sorted lookup.

Anybody who *doesn't* know about the subfields will look at the table 
and, I submit, very quickly see that the table is sorted by the 
low-order byte.

I'm very curious to learn who, after seeing both tables, thinks the way 
the proposal sorts the table is overall the way it should be presented.

> [ much elided ]
> 
>> 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.
> 
> A new registry table can be added by getting an RFC published with WG consensus.
> The WG did not seem interested in doing Version 1 extension fields.

There you go.  Then stop complaining there is no V1 table and stop using 
that as a basis for revisionism.

I still do not see that you have refuted any of my claims that, overall, 
the proposed document contains significant materially incorrect information.

-- 
Harlan Stenn <[e-mail]>, part of
http://networktimefoundation.org - be a member!