RTP and Leap Seconds
draft-ietf-avtcore-leap-second-08
Yes
(Richard Barnes)
(Sean Turner)
No Objection
(Benoît Claise)
(Gonzalo Camarillo)
(Jari Arkko)
(Martin Stiemerling)
(Ted Lemon)
Note: This ballot was opened for revision 07 and is now closed.
Brian Haberman Former IESG member
(was Discuss)
Yes
Yes
(2014-01-09 for -07)
Unknown
Thanks for addressing my DISCUSS point.
Richard Barnes Former IESG member
Yes
Yes
(for -07)
Unknown
Sean Turner Former IESG member
Yes
Yes
(for -07)
Unknown
Stewart Bryant Former IESG member
(was Discuss)
Yes
Yes
(2014-01-13)
Unknown
Thank you for adding the clarification
Adrian Farrel Former IESG member
No Objection
No Objection
(2014-01-01 for -07)
Unknown
I found this a very clear explanation and, at least, believed I understood it.
Barry Leiba Former IESG member
No Objection
No Objection
(2013-12-30 for -07)
Unknown
Very interesting. I knew about leap seconds, but not about how time implementations vary in their handling of them. Thanks for the lesson.
Benoît Claise Former IESG member
No Objection
No Objection
(for -07)
Unknown
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -07)
Unknown
Jari Arkko Former IESG member
No Objection
No Objection
(for -07)
Unknown
Joel Jaeggli Former IESG member
No Objection
No Objection
(2014-01-08 for -07)
Unknown
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 +1-303-447-0517 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.
Martin Stiemerling Former IESG member
No Objection
No Objection
(for -07)
Unknown
Pete Resnick Former IESG member
No Objection
No Objection
(2014-01-07 for -07)
Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection
(2014-01-08 for -07)
Unknown
Thank you for DISCUSSing with the DISCUSSers. They had the same questions I had.
Stephen Farrell Former IESG member
No Objection
No Objection
(2014-01-05 for -07)
Unknown
Well written, clear, short and looks useful to me. Good job!
Ted Lemon Former IESG member
No Objection
No Objection
(for -07)
Unknown