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 <[email protected]> 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. > > _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
