Skip to main content

Last Call Review of draft-ietf-avtcore-leap-second-06
review-ietf-avtcore-leap-second-06-opsdir-lc-kuarsingh-2013-12-05-00

Request Review of draft-ietf-avtcore-leap-second
Requested revision No specific revision (document currently at 08)
Type IETF Last Call Review
Team Ops Directorate (opsdir)
Deadline 2013-12-09
Requested 2013-11-28
Authors Kevin Gross , Ray van Brandenburg
I-D last updated 2015-10-14 (Latest revision 2014-01-12)
Completed reviews Genart IETF Last Call review of -06 by Ben Campbell (diff)
Genart Telechat review of -07 by Ben Campbell (diff)
Opsdir IETF Last Call review of -06 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Request IETF Last Call review on draft-ietf-avtcore-leap-second by Ops Directorate Assigned
Reviewed revision 06 (document currently at 08)
Result Has nits
Completed 2013-12-05
review-ietf-avtcore-leap-second-06-opsdir-lc-kuarsingh-2013-12-05-00
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.

Example

-------------------------------------------------------------------------------------------------------------------------------

| Source Class                  |     Source Example         |   Recommendation
                   |

--------------------------------------------------------------------------------------------------------------------------------

| non wall-clock                |     self clocking               |    No
Accommodation needed     |

-------------------------------------------------------------------------------------------------------------------------------

| non-leap-second-bearing |     1588, GPS, TAI          |   No Accommodation
needed      |

--------------------------------------------------------------------------------------------------------------------------------

| leap-second-bearing       |     NTP                           |
 Accommodation Recommended |

--------------------------------------------------------------------------------------------------------------------------------

regards,

Victor Kuarsingh