IETF Logo Mail Archive

Re: [TICTOC] TICTOC Security Requirements

Kevin Gross <kevin.gross@avanw.com> Thu, 21 March 2013 15:19 UTC

Return-Path: <kevin.gross@avanw.com>
X-Original-To: tictoc@ietfa.amsl.com
Delivered-To: tictoc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7F3B21F8775 for <tictoc@ietfa.amsl.com>; Thu, 21 Mar 2013 08:19:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.091
X-Spam-Level:
X-Spam-Status: No, score=-0.091 tagged_above=-999 required=5 tests=[AWL=1.885, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tash8ISfzaRO for <tictoc@ietfa.amsl.com>; Thu, 21 Mar 2013 08:19:55 -0700 (PDT)
Received: from oproxy1-pub.bluehost.com (oproxy1-pub.bluehost.com [66.147.249.253]) by ietfa.amsl.com (Postfix) with SMTP id 2417E21F8F75 for <tictoc@ietf.org>; Thu, 21 Mar 2013 08:19:45 -0700 (PDT)
Received: (qmail 8191 invoked by uid 0); 21 Mar 2013 15:17:14 -0000
Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy1.bluehost.com with SMTP; 21 Mar 2013 15:17:14 -0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=i6+2uoYOIdSk7doLzRQhznWcbIe/XIQ80lRVyG78pxE=; b=GNBA9Ivgukuci6XDk0kAQg36v+4ylt1XEYxse09eNzYEmt7PJTvRwru4QR21V3HRlCcKxqRYb9WVJEu4Y/nPXMBwpOCMHvXVc5gNcWgyc4gSH06yTQ83yrIQ1s2TlYYO;
Received: from [209.85.210.174] (port=61507 helo=mail-ia0-f174.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from <kevin.gross@avanw.com>) id 1UIhEw-0006Ou-4F for tictoc@ietf.org; Thu, 21 Mar 2013 09:17:14 -0600
Received: by mail-ia0-f174.google.com with SMTP id b35so2535054iac.5 for <tictoc@ietf.org>; Thu, 21 Mar 2013 08:17:13 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.92.4 with SMTP id ci4mr806152igb.95.1363879033113; Thu, 21 Mar 2013 08:17:13 -0700 (PDT)
Received: by 10.50.183.163 with HTTP; Thu, 21 Mar 2013 08:17:13 -0700 (PDT)
In-Reply-To: <07F7D7DED63154409F13298786A2ADC904CEC680@EXRAD5.ad.rad.co.il>
References: <07F7D7DED63154409F13298786A2ADC904CDF587@EXRAD5.ad.rad.co.il> <CALw1_Q21Z7k3x3u88HEWopTHJvyKatHidFPDdkBxUh9FFdoP1A@mail.gmail.com> <07F7D7DED63154409F13298786A2ADC904CEC680@EXRAD5.ad.rad.co.il>
Date: Thu, 21 Mar 2013 09:17:13 -0600
Message-ID: <CALw1_Q0s5nczi0pZYdtu9uj3HdvN86Z2mxS6_F-CkFa9z-7bZw@mail.gmail.com>
From: Kevin Gross <kevin.gross@avanw.com>
To: Yaakov Stein <yaakov_s@rad.com>
Content-Type: multipart/alternative; boundary="e89a8f3bb24749600904d870d5a2"
X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.174 authed with kevin.gross@avanw.com}
Cc: "tictoc@ietf.org" <tictoc@ietf.org>
Subject: Re: [TICTOC] TICTOC Security Requirements
X-BeenThere: tictoc@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Timing over IP Connection and Transfer of Clock BOF <tictoc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tictoc>, <mailto:tictoc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tictoc>
List-Post: <mailto:tictoc@ietf.org>
List-Help: <mailto:tictoc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tictoc>, <mailto:tictoc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Mar 2013 15:19:56 -0000

In case I was not clear in my previous response, I propose we resolve this
by reusing terminology already used in authoritative documents and
standards, as opposed to what we, as individuals, might argue (at length)
is most correct and proper. If the authors want to go a different
direction, I'm fine with that; it's an editorial issue as far as I'm
concerned.

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Thu, Mar 21, 2013 at 2:41 AM, Yaakov Stein <yaakov_s@rad.com> wrote:

>  Kevin, ****
>
> ** **
>
> I don’t entirely agree.****
>
> ** **
>
> I can use PTP or NTP to distributed frequency without looking at the ToD**
> **
>
> (even if it is correct).****
>
> ** **
>
> So I would claim that they distribute timing, where by “timing” I mean
> time or frequency.****
>
> ** **
>
> What the protocols definitely don’t do is synchronize.****
>
> I guess one could claim that NTP does synchronize, since in addition to a
> protocol it specifies an algorithm for synchronizing a clock.****
>
> But 1588 does not specify the control loop, and thus does no
> synchronization at all!****
>
> ** **
>
> Y(JS****
>
> ** **
>
> *Yaakov (J) Stein***
>
> CTO****
>
> T: +972-3-645-5389, +972-2-588-9159 | F: +972-3-647-5924  | *
> yaakov_s@rad.com* ****
>
> RAD Data Communications Ltd., 24 Raoul Wallenberg St., Tel-Aviv 69719,
> Israel  | www.rad.com | www.raddata.blogspot.com****
>
> ** **
>
> *From:* Kevin Gross [mailto:kevin.gross@avanw.com]
> *Sent:* 18 March, 2013 17:48
> *To:* Yaakov Stein
> *Cc:* tictoc@ietf.org; Tal Mizrahi
> *Subject:* Re: [TICTOC] TICTOC Security Requirements****
>
> ** **
>
> "Timing distribution protocols" is flawed because protocols distribute
> time, not timing. "Time synchronization protocols" is flawed because the
> protocols synchronize clocks; only god synchronizes time. NTP defines
> itself through self-reference. 1588 seems to get it right, "IEEE standard
> for a precision *clock synchronization protocol *for..."****
>
> ** **
>
> On Mon, Mar 18, 2013 at 8:37 AM, Yaakov Stein <yaakov_s@rad.com> wrote:***
> *
>
> General  I personally prefer “timing distribution protocols”  to  “time
> synchronization protocols”,****
>
> as I think the protocol distributes the timing (time and/or frequency)****
>
> while the specific sync algorithm performs the synchronization.****
>
> ** **
>

v2.23.0 | Report a Bug | By Email