Re: [AVTCORE] Working Group Last Call on draft-ietf-avtcore-leap-second-03

Colin Perkins <> Mon, 26 August 2013 20:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B45621F9998 for <>; Mon, 26 Aug 2013 13:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fQzddlm3iJ0K for <>; Mon, 26 Aug 2013 13:46:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4B64821F9EA2 for <>; Mon, 26 Aug 2013 13:46:28 -0700 (PDT)
Received: from [] (port=49062 helo=[]) by with esmtpsa (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from <>) id 1VE3fx-00038U-Fn; Mon, 26 Aug 2013 21:46:16 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_905A0609-9824-4EE7-8F2C-230FCDA8D8DC"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Colin Perkins <>
In-Reply-To: <>
Date: Mon, 26 Aug 2013 21:46:13 +0100
Message-Id: <>
References: <> <> <>
To: Kevin Gross <>
X-Mailer: Apple Mail (2.1508)
X-BlackCat-Spam-Score: -28
X-Mythic-Debug: Threshold = On =
Cc: Magnus Westerlund <>, IETF AVTCore WG <>
Subject: Re: [AVTCORE] Working Group Last Call on draft-ietf-avtcore-leap-second-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Aug 2013 20:46:46 -0000

On 26 Aug 2013, at 17:23, Kevin Gross <> wrote:
> Thanks for the review. See responses below.
> On Mon, Aug 26, 2013 at 6:57 AM, Colin Perkins <> wrote:
> On 15 Aug 2013, at 08:46, Magnus Westerlund <> wrote:
> > This starts the WG last call on RTP and Leap Seconds with the intended
> > status of Proposed Standard. Please provide any comments by 1st of
> > September.
> >
> >
> Section 5 also says NTP includes leap seconds, and that implementations working to a leap-second-bearing reference need "a working communications channel to receive notification of leap-second scheduling". Is having an NTP-synchronised clock a sufficient channel to receive the necessary notification, or is something more needed?
> NTP includes a mechanism for leap-second notification. That's a good start but what we're trying to capture here is the entire communications chain from IERS to the slaved clocks. In addition to these protocol mechanisms for delivering leap-second notifications, master clocks must have access to an up-to-date leap second schedule through some other communications channel (e.g. FTP leap-seconds.list from a NIST server).
> I can revise to emphasize that time protocol notifications are not sufficient but I don't think we want to try and describe the whole communications channel for this information. Or we can leave it as it is. The current text is terse but correct.

I agree that you shouldn't try to describe the whole process of how to do this, but I do think it needs a little more than is in the current draft. In particular, I can imagine someone reading the draft and thinking that because they have NTP, they know everything they need to know about leap seconds, and can just use the NTP timestamps. From my point of view, paraphrasing what you wrote about into the draft would be enough to clarify this.

Colin Perkins