Mark! Heads up...exernal/marketing issue incoming.
Hal Murray via devel <devel@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.
Good plan.
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
testing scenarios.
--
<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.
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
