Thank you for DISCUSSing with the DISCUSSers. They had the same questions I had.

I found this a very clear explanation and, at least, believed I understood it.

Well written, clear, short and looks useful to me. Good job!

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.

Very interesting.  I knew about leap seconds, but not about how time implementations vary in their handling of them.  Thanks for the lesson.

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.