[TICTOC] Mirja Kühlewind's Discuss on draft-ietf-tictoc-multi-path-synchronization-05: (with DISCUSS and COMMENT)

["Mirja Kuehlewind" <[e-mail]>]

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tictoc-multi-path-synchronization-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tictoc-multi-path-synchronization/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

"Each NTP clock has a set of N IP addresses. The assumption is that
      the server information, including its multiple IP addresses is
      known to the NTP clients."

A protocol specification should not make this assumption but describe a
mechanism how a client gets to know about these IP addresses. However,
this draft does not read like a protocol specification anyway; it rather
reads like an informational document leaveraging existing mechanisms to
use multiples pathes (see further below). 

Further, this draft claims in the abstract that this mechanism could
enhance security which is not further discussed (should be added to the
security considerations section!). However, I would guess that it depends
on the choosen combining algorithm if it enhances security or not (or
even worsens it). If so that really needs to be further discussed!


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This drafts reads rather like a research paper than an RFC. Especailly
saying that "The Multi-Path Precision Time Protocol
   (MPPTP) and Multi-Path Network Time Protocol (MPNTP) define an
   additional layer that extends the existing PTP and NTP without the
   need to modify these protocols. "
is completely overstating. I really don't see that this doc defines new
protocols or a new layer. I would strongly recommend to not give the
describe mechanisms a name (like Multi-Path Precision Time Protocol 
(MPPTP) and Multi-Path Network Time Protocol (MPNTP)) as these are no
protocols. I further recommend to publish this document instead as an
informational RFC that describes how to leverages multiple pathes without
protocol changes. 

Also section 6 that only gives references to other docs would be
acceptable for an informational draft but for a protocol spec. A spec
should provide an implementation recommendation by provding a default
algorithm.

Some editorial commenta:

I would recommend to 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.