[TICTOC] Comments on Architecture doc

 Comments on Architecture for the transmission of Timing over Packet
Networks: draft-stein-tictoc-modules-02.txt

1.	This document should have a section on timescales.

2.	This document sometimes uses server and master interchangeably,
and client and slave interchangeably. Master-slave protocols are
fundamentally different from client-server protocols.

3.	We need a better term for time-of-day than "wall clock". Wall
clock is likely to be mis-interpreted as inaccurate time.

4.	Master clocks do not always employ atomic clocks. A master clock
often has only an OCXO or TCXO.

5.	Section 2.2: Frequency transfer in not always done with a one
way protocol. In constrained networks two way protocols can be used.
Note that to select packets with the lowest delays for the servo loop we
will want a two way protocol.

6.	Section 2.4: PLLs as well as frequency synthesizers are used to
create additional frequencies.

7.	Section 3.1: Another challenge to the use of transparent clocks
is that they modify packets. This is a serious challenge for security.

8.	Section 3.1: Time distribution can in fact be done entirely in
multicast, such as in IEEE1588. However this is limited to networks
which can run multicast. There are also scaling issues with the
proliferation of multicast delay request and delay response messages,
unless the peer delay mechanism used.

9.	Section 3.1: The recent revision of IEEE1588 included many
enhancements and revisions, not all of which were related to the needs
of the telecommunications industry.

10.	Section 3.3: The presentation of time also includes the
generation of timing signals, for example IRIG-B.

11.	Section 4.1: Not all slaves are simple. Security mechanisms
should scale to allow equipment designers to make trade-offs between
computational complexity and security robustness.

//Doug Arnold