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

[Karen O'Donoghue <[e-mail]>]

Question for clarification: 

We proposed this draft with a status of "Experimental" with the intention that further analysis and development would be done before proposing any standards track protocol solutions (or an information RFC). Given this metric, I thought it was reasonable for this to seem more like research. Was this taken into account in your analysis of the document? 

Regards,
Karen O’Donoghue (tictoc co-chair)

> On Sep 22, 2016, at 7:52 AM, Mirja Kuehlewind <[e-mail]> wrote:
> 
> 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.
> 
>