Replying to a bygone thread, but here it goes:

Out of your four points only the last one is valid. Your document reference is old, and does not take into account the IEEE1588v2 standard released in 2008. PTPv2 can indeed reach good accuracies over WAN, can be used in unicast mode, can form clock hierarchies with multiple atomic (or equivalent) clocks and has security extensions.

For further info you could read the IEEE 1588-2008 standard, it's relatively readable as far as standards go.

In addition to NTP, there's also IEEE 1588. All of these "clock synch over packet switched network" mechanisms are pretty similar, the differences are mainly in the timestamp filtering and processing. NTP details the algorithms, IEEE 1588 leaves them open to implementation and RADClock has its own algorithms (details unknown at least to me).

This story is also a bit dupeish, as RADClock has been recently featured here. Thus I'll copypaste the relevant parts from my previous reply:
--
(disclaimer: just finished my Master's thesis on a related subject) About the 1588 in general: its main selling point is the ability to do hardware timestamping (when using hardware with support!) of the two-way timing messages between master and slave. This eliminates the very significant timing jitter that happens in the software stack before the messages are timestamped. For reference, commercially available master-slave implementations using IEEE 1588 achieve synchronisation within tens of nanoseconds within LAN, and microseconds to tens of microseconds within WAN, depending on network conditions.

So overall I think that while RADclock might be ok as an alternative between NTP and IEEE 1588, it doesn't really bring anything new to the table. Some of the stuff in the Rideaux/Veitch paper has also been used with IEEE 1588 for quite some time, for instance the filtering for fast timing packets is a necessity for accurate synchronisation with IEEE 1588.
--

Like the sibling post says, there's no need to have very high quality oscillators anywhere in the system. A GPS-synched grandmaster with an OCXO should have pretty good holdover properties in case it loses the GPS signal for some time (hours-days).

The slaves can also have OCXOs to enable long time periods for filtering and whatever clever averaging algorithms the slave happens to use to recover the clock after it has been degraded in transit. It's interesting to note that contrary to NTP, IEEE 1588 does not define the clock recovery algorithms, so they are typically proprietary in commercial products.

(disclaimer: just finished my Master's thesis on a related subject) PTPd is ok, but not in itself up-to-date at the moment. It doesn't implement the most recent IEEE 1588-2008 standard, which has significant improvements compared to the 1588-2002. About the 1588 in general: its main selling point is the ability to do hardware timestamping (when using hardware with support!) of the two-way timing messages between master and slave. This eliminates the very significant timing jitter that happens in the software stack before the messages are timestamped. For reference, commercially available master-slave implementations using IEEE 1588 achieve synchronisation within tens of nanoseconds within LAN, and microseconds to tens of microseconds within WAN, depending on network conditions. So overall I think that while RADclock might be ok as an alternative between NTP and IEEE 1588, it doesn't really bring anything new to the table. Some of the stuff in the Rideaux/Veitch paper has also been used with IEEE 1588 for quite some time, for instance the filtering for fast timing packets is a necessity for accurate synchronisation with IEEE 1588.