Re: [Ntp] Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum

[Harlan Stenn <[e-mail]>]

On 9/5/2022 3:24 PM, Danny Mayer wrote:
> 
> On 9/5/22 5:52 PM, Hal Murray wrote:
>> [e-mail] said:
>>> SNTP is defined in RFC5905 Section 14. You don't need anything more than
>>> that.
>> There is also RFC 4330 and a lot of crappy code out there in firmware 
>> that
>> will never get updated.
> RFC5905 obsoleted RFC4330.
>> RFC 5905 is over 100 pages.  Section 14 is less than a page.  How many of
>> those other pages would somebody have to read and understand in order to
>> implement a SNTP client?
> Read Section 14 to find out.
>> If you were a junior programmer assigned to implement a SNTP client, 
>> would you
>> go throgh RFC 5905 or google around and find some code to copy and 
>> ship it
>> when it worked?
> You don't give this to a junior programmer. RFC's are difficult enough 
> to understand and if you were to do so, you would expect a poor 
> implementation and incorrect code. Don't blame the programmer, blame the 
> person who thought that was a good, or maybe a cheap, idea.

Who cares what is assigned to a junior programmer except the programmer 
and the programmer's management?

The more interesting point could be that the Reference Implementation 
has come with am open-source fully-featured SNTP client for many years' 
time.

There's nothing stopping anybody from cribbing from that code and 
throwing out the bits they don't want.  There are also several other 
(likely much less featured) published implementations out there.

>> I think we should have a separate document for SNTP clients.  So far, I
>> haven't convinced (m)any other people.  There are two goals:
>>
>> One is to have a clear and simple document so we can point people at 
>> it when
>> their current code is sending ancient format packets.  Some of those 
>> ancient
>> packets are not using a format described in any RFC and they worked just
>> because of the undocumented details in the ntpd implementation.
>>
>> Another is to make us think and document a packet format that we will 
>> support for a long time.
>>
>> We should setup servers that don't support old format packets so SNTP 
>> implementors can test their code.
>
> Why bother? Developers of such clients will just use existing servers. 
> You can have newer servers not support such packets.

I believe that creating a separate SNTP spec will just be another source 
of bitrot and confusion.

> However you don't 
> say what those undocumented details are.

Yes,  please support your assertion.

If folks implement their own SNTP client and it doesn't work with some 
class of servers, they can fix their code or not.

There is a well-defined SNTP spec already out there.

If somebody chooses to propagate a poor implementation, that's their 
choice.  If others choose to use that implementation, that's their choice.

> Danny
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
> 

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