RTP and Leap Seconds
RFC 7164

Note: This ballot was opened for revision 07 and is now closed.

(Richard Barnes) Yes

(Stewart Bryant) (was Discuss) Yes

Comment (2014-01-13)
No email
send info
Thank you for adding the clarification

(Brian Haberman) (was Discuss) Yes

Comment (2014-01-09 for -07)
No email
send info
Thanks for addressing my DISCUSS point.

(Sean Turner) Yes

(Jari Arkko) No Objection

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

Comment (2014-01-08 for -07)
No email
send info
Thank you for DISCUSSing with the DISCUSSers. They had the same questions I had.

(Adrian Farrel) No Objection

Comment (2014-01-01 for -07)
No email
send info
I found this a very clear explanation and, at least, believed I understood it.

(Stephen Farrell) No Objection

Comment (2014-01-05 for -07)
No email
send info
Well written, clear, short and looks useful to me. Good job!

(Joel Jaeggli) No Objection

Comment (2014-01-08 for -07)
No email
send info
from the response to the opsdir review.

Thanks Victor.

I appreciate your suggestion and considered addressing it by adding an
introductory paragraph to section 5 which would identify the single case
where accommodation is recommended. I think, however, your proposed table
brings together some other useful information and will help people skimming
the document quickly ascertain its applicability.

I propose to add the table between second and third paragraphs in section 5
and caption it "Table 2: Leap second accommodation recommendations". I
think this positioning makes referencing it in the text unnecessary.

Kevin Gross
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>

On Tue, Dec 3, 2013 at 9:14 AM, Victor Kuarsingh <victor@jvknet.com> wrote:

> IESG, OPS-DIR and Authors,
> I reviewed "RTP and Leap Seconds"  (draft-ietf-avtcore-leap-second-06) for
> operational impact.
> Intended Status: Standards TrackCurrent Draft Status: IESG - Special
> Request Review
> Summary:  This document specifies recommended behaviours for RTP senders
> and receivers with reference to leap seconds adjustments to clock reference
> sources.  The document outlines the problem statement, rationale for update
> and provides recommendations for implementations.
> This document is intended to update RFC3550.
> I do not see any negative operational impact with publication based on
> what is currently specified in this draft.  The document specifics
> behaviours which are intended to help alleviate existing operational issues
> with RTP senders/receivers which are unable to make adjustments for changes
> on sources with respect to leap second adjustments.
> The changes proposed in this document should be beneficial operationally.
> Summary Feedback Points:
> (1) The document provides a clear summary of the problem (Section 1)
> (2) The document provides background on the issue and contextual
> information (Section 3 - 4)
> (3) The document clarifies which clock sources cause the issue (i.e. NTP)
> versus non-impacted sources (i.e. IEEE 1588, GPS, TAI).
> (4) The document outlines recommendations for RTP implementations which
> use “leap-second-bearing” clock sources to avoid operation impact (Section
> 5)
> Document Recommendation (trivial):
> The only recommendation I would make - which is not material to the
> content - is an added reference/text piece in section 5 on the RTP source
> clock deployment models/recommendations. I note this since not all readers
> may be RTP implementers, but may be operators who will use this document
> for reference.  It would be nice if such a reader class could quickly
> identify if their deployment requires the RTP implementation updates as
> specified in document.
> I was thinking of a list or table which outlines the three source classes
> (non wall-clock, non-leap-second-bearing source, leap-second-bearing
> source) with a statement if adjustments are required.

(Barry Leiba) No Objection

Comment (2013-12-30 for -07)
No email
send info
Very interesting.  I knew about leap seconds, but not about how time implementations vary in their handling of them.  Thanks for the lesson.

(Ted Lemon) No Objection

(Pete Resnick) No Objection

Comment (2014-01-07 for -07)
No email
send info
I have no particular problem with this document going forward, but I am left to wonder whether this is solving a *real* problem. The document doesn't really explain. Have we actually seen implementations in the field that do bad things, like  crash or produce lousy output? I would like to see a paragraph added between the first and second paragraphs of the introduction that says something like, "In the field, implementations have been observed that blah blah blah stutter and drop-outs blah blah blah divide by zero blah blah blah piss off the users..." If this is addressing a real problem, this document is fine. Otherwise, I fear it "fills a well-needed gap", as the saying goes.

(Martin Stiemerling) No Objection