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
send info
Thank you for adding the clarification
(Brian Haberman) (was Discuss) Yes
Comment (2014-01-09 for -07)
No email
send info
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
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
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
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
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 +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.
Barry Leiba No Objection
Comment (2013-12-30 for -07)
No email
send info
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
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.