I am an assigned INT directorate reviewer for this draft. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherds should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details of the INT directorate, see < http://www.ietf.org/iesg/directorate.html >. Summary This document is clearly-written and informative. I identified a couple of areas where some additional discussion might be useful, but no glaring ommission or other problem that would be a reason not to publish as-is, if the authors prefer. Suggestions for Section 5 The document says, reasonably, that "the set of IP addresses for each clock should be chosen in a way that enables the establishment of paths that are the most different." This is sensible advice, and I understand the generality of the recommendation since it is difficult to provide detailed advice for the many component networks of the Internet, many of which are presumably operated differently from each other in this regard. However, I think it might be worth giving an easy example derived from global routing operations with BGP. For example, choosing multiple addresses for a clock that are covered by the same prefix exported from the local autonomous system (AS) is likely to yield fewer candidate return paths than choosing addresses covered by different exported prefixes, since the former can only provide a single exit for all addresses from a remote AS while the latter potentially can provide more. Other examples are no doubt possible. I think it would be useful to include at least one example, however, since the advice might otherwise be overlooked. Suggestions for Section 5.3 1. Header parameters used for flow hashing in traceroute vs. clock protocol It was observed earlier in the document that in some networks flow buckets are associated with a tuple of packet headers that includes transport protocol identifiers (e.g. UDP) and transport layer addresses (e.g. UDP port numbers). A traceroute implementation that wants to identify the path used by the timing protocol would need to take care to use the same values in the headers of its probe packets as is used by the network timing protocol, to the extent that routers in the intermediate networks between master and slave use those values to identify individual packets that will be forwarded along congruent paths. However, some or even most implementations (e.g. the original Van Jacobsen traceroute that continues to ship with BSD variants) vary some of these parameters in order to support concurrent operation by multiple users of the same system, or to allow multiple probe packets to be in flight simultaneously to speed up the process of mapping a path. VJ traceroute varies the destination UDP port number, for example. I think it is worth noting in this section that if the particular algorithm employed for traceroute is not identical to the clock protocol being used, as seen by the network, it is entirely possible that the paths taken by traceroute probe packets and packets associated with the clock protocol will be different. The extent to which traceroute will be useful in the identification of identical paths for the clock protocol will vary in practice, and in applications where the possibility of path diversity is more important than the cost of identical paths is high it might be better to forego identical path identification and instead acknowledge that some work will likely be wasted. 2. Temporal stability of paths Some networks might re-route individual flows over time. The path (A, B) and the path (C, D) might be different at time T0, but the same at T1, then different again at T2, as individual routers in the path experience topology changes (e.g. interfaces come up and down, or a routing protocol reacts to an LSA received from a neighbour). I think it is worth mentioning that if paths are to be compared to assess whether they are identical, that assessment needs to be repeated regularly in order to be useful over the lifetime of an association between a clock master and slave, which is presumed to be long compared to the expected stability of an arbitrary path over the Internet.