Should we just remove the broadcast option?
Eric S. Raymond
esr at thyrsus.com
Wed Feb 21 01:14:43 UTC 2018
Mark! Heads up...exernal/marketing issue incoming.
Hal Murray via devel <devel at ntpsec.org>:
> Is anybody using/testing it?
Not as far as I know
> We don't support receiving broadcast.
No, I removed that after Daniel explained that it's unsecurable.
> It used to support a ttl option. That got broken/dropped somewhere
> along the way. Should I restore that? Or maybe document that it is
> missing? ...
I believe I already performed that documentationectomy. If there are
remnants, of course we need to fix them in one direction or the other
depending about the high-level decision aout supporting brodast mode.
> Context is that I'm cleaning up the mode/ttl mess. The mode for
> refclocks used to live in the ttl slot. Since the ttl slot isn't
> used any more, I'm fixing up all the names.
About the major issue:
I believe we retained bradcast mode thinking of a scenario where a bunch
of Windows machines on a lan are being fed time information from NTPsec.
You're our NTP operations old hand. Do you think this is common?
The big question is whetger this is an important scenario for us to cover.
In view of who we have an eye on as a target market, I'm inclined to
doubt it...but this kind of thing in Mark's bailiwick.
I of course, would be happy to remove it to reduce complexity and
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
More information about the devel