Re: [Ntp] Antw: Re: Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

[Harlan Stenn <[e-mail]>]

On 9/2/2019 3:52 AM, Ulrich Windl wrote:
>>>> Harlan Stenn <[e-mail]> schrieb am 02.09.2019 um 12:21 in
> Nachricht
> <[e-mail]>:
>> The refid has meaning on the system that issues it.
>>
>> The refid is a nonce to any system that receives it.
>>
>> Any meaning of the refid outside of the issuing system relies on
>> higher‑level knowledge that is not part of the protocol.
> 
> Actually this description holds for NTPv4. For NTPv3 the formal description
> also is like that, but the specificvation of the clock update procedure (page
> 27 in the PDF version of RFC 1303) says:

You mean 1305.

> sys.refid ˿ peer.peeraddr
> 
> Also on page 37:
> peer.refid = peer.hostaddr

It doesn't hold when IPv6 enters the mix.

And while NTPv3/RFC1305  is interesting it was published in March of
1992 and the last change to the NTPv3 code was in October of 1996, and
the first development code for what would become NTPv4 was released in
September of 1997.

The first *draft* of NTPv4 happened in July of 2005, after we had put *9
years work* into the development and testing of the NTPv4 protocol,
algorithms, and codebase.  RFC5905 was published 5 years after that, at
which point we had 14 years of demonstrably working protocol,
algorithms, and code.  For those keeping count, that was 9 years ago.

Yes, we can and should make conscious, well reasoned and tested changes
in NTPv5 and beyond.

> And, maybe most important, what's missing in RFC 5905 is a section "Chages
> from the previous version": I guess many implementations just continued to
> treat the REFID as some network address...

How many implementations are we talking about?  How many of these
implementations are "significant", and what's your definition of
"significant"?

H

>> On 9/2/2019 1:00 AM, Heiko Gerstung wrote:
>>> Hi Ulrich,
>>>
>>> good point. That is why NTP would use that "ID" instead of the IP address
> to 
>> identify itself. That means ntpd could find out timing loops even if they
> are 
>> caused by a routing loop.
>>>
>>> Regards,
>>>    Heiko
>>>
>>>
>>
>> ‑‑ 
>> Harlan Stenn, Network Time Foundation
>> http://nwtime.org ‑ be a Member!
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail] 
>> https://www.ietf.org/mailman/listinfo/ntp 
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!