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

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Karen,

not sure what you mean by „seem more like research“, however, both Standards track documents and experimental documents are protocol specifications (or defining other kinds of normative information; but in this case we seem to speak about a protocol spec). The difference between experimental and standards track is that there is less deployment (potentially none) and therefore there are open questions that might influence the protocol design. These open questions should be mentioned at best in an own section. If the experiment is successful, one could either adapt the specification based on the achieved results or even move the document forward to standards track without any modification if the experiment showed no problems that need to be fixed. As I said, both types should be written as specs, just the level of maturity might be different. ‚Just‘ putting a research paper into a draft is usually not sufficient as research papers are written with a different target and different target audience.

There is no transition from experimental to informational. If a doc is only informational, in the sense that it does not specify a protocol or defines any other normative information, it should be informational from the beginning.

Does that help to clarify things?

Mirja


 
> Am 22.09.2016 um 14:13 schrieb 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.
>> 
>> 
>