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

From: Magnus Westerlund <[email-masked]>
Date: Thu, 15 Aug 2013 09:46:44 +0200

WG,

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.

https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Colin Perkins <[email-masked]>
Date: Mon, 26 Aug 2013 13:57:12 +0100

> https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second

Section 5 says that: "No special treatment with respect to RTP timestamps is required in the presence of a negative leap second". This might be clearer written "No special treatment is needed to avoid ambiguity with respect to RTP timestamps in the presence of a negative leap second". I think some special treatment is needed, as noted in Section 5.2, to avoid jumps in the playout time. 

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? 

Typos:
- Section 3, 1st paragraph: "synchronized with with the rotation"
- Section 6, 2nd paragraph: "leap-seocnd-bearing"

Cheers,
Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: Kevin Gross <[email-masked]>
Date: Mon, 26 Aug 2013 10:23:12 -0600

Thanks for the review. See responses below.

Kevin Gross

On Mon, Aug 26, 2013 at 6:57 AM, Colin Perkins <[email-masked]> wrote:

> Section 5 says that: "No special treatment with respect to RTP timestamps
> is required in the presence of a negative leap second". This might be
> clearer written "No special treatment is needed to avoid ambiguity with
> respect to RTP timestamps in the presence of a negative leap second". I
> think some special treatment is needed, as noted in Section 5.2, to avoid
> jumps in the playout time.
>

That looks like a good improvement.

>
> 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.

> - Section 6, 2nd paragraph: "leap-seocnd-bearing"

Thanks. I will fix these.

>
>
> Cheers,
> Colin
>
>
>
> --
> Colin Perkins
> http://csperkins.org/
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> [email-masked]
> https://www.ietf.org/mailman/listinfo/avt
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 26 Aug 2013 21:46:13 +0100

> Thanks for the review. See responses below.
...
> > https://datatracker.ietf.org/doc/draft-ietf-avtcore-leap-second
...
> 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
http://csperkins.org/