Multipath Time Synchronization
draft-ietf-tictoc-multi-path-synchronization-07

Thanks for addressing my comments. I still think this draft reads a little like a research paper but it improved. I would still recommend to consider informational instead of experimental. If this draft stays experimental, it would actually benefit from an own section that describes what this experiment is about. Which parts should be evaluated and what are the expected outcomes?

I have one remaining comments  on the security section:

"The security aspects of time synchronization protocols are discussed
   in detail in [TICTOCSEC].“

TICTOCSEC is a reference to RFC 7384 on "Security Requirements of Time Protocols in Packet Switched Networks“. As this RFC species requirements, it would be much more useful to document how these requirements have bee addressed by this proposal rather than just referring to it and leave this exercise to the reader.

And some remaining editorial comments:

I would still recommend to further shorten the abstract by removing or moving the first part, potentially into the introduction instead, and only leave this part:

"This document describes a multi-path approach to the Network Time Protocol (NTP) and the
   Precision Time Protocol (PTP) over IP networks, allowing the protocols to run concurrently over
   multiple communication paths between the master and slave clocks. The
   multi-path approach can significantly contribute to clock accuracy,
   security and fault tolerance."

Also section 3 and 4 could be completely removed or shorten to 2-3 paragraph that could also be integarted into the introdcution.

I thought Stewart's "chicken and egg" response to Mirja's Discuss was worth considering as an addition to the document that explains why the document is making this assumption.

Does this increase the DDoS amplification potential of NTP
(and/or PTP)? Seems like it must, to at least some extent.
I'd suggest noting that and warning, in particular dual-ended
masters, to consider that.