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 rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2013-12-09
Requested 2013-11-28
Draft last updated 2013-12-05
Completed reviews Genart Last Call review of -06 by Ben Campbell (diff)
Genart Telechat review of -07 by Ben Campbell (diff)
Opsdir Last Call review of -06 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Review review-ietf-avtcore-leap-second-06-opsdir-lc-kuarsingh-2013-12-05
Reviewed rev. 06 (document currently at 08)
Review result Has Nits
Review completed: 2013-12-05

Review
review-ietf-avtcore-leap-second-06-opsdir-lc-kuarsingh-2013-12-05

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