[要約] RFC 7164は、RTP（Real-time Transport Protocol）と閏秒の関係について説明しており、RTPの実装における閏秒の取り扱いに関するガイドラインを提供しています。このRFCの目的は、RTPの利用者や開発者が閏秒の問題を理解し、適切な対策を講じるための情報を提供することです。
Internet Engineering Task Force (IETF) K. Gross
Request for Comments: 7164 AVA Networks
Updates: 3550 R. van Brandenburg
Category: Standards Track TNO
ISSN: 2070-1721 March 2014
RTP and Leap Seconds
RTPとうるう秒
Abstract
概要
This document discusses issues that arise when RTP sessions span Coordinated Universal Time (UTC) leap seconds. It updates RFC 3550 by describing how RTP senders and receivers should behave in the presence of leap seconds.
このドキュメントでは、RTPセッションが協定世界時（UTC）のうるう秒にまたがるときに発生する問題について説明します。これは、うるう秒が存在する場合のRTP送信者と受信者の動作を記述することにより、RFC 3550を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7164.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7164で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Leap Seconds . . . . . . . . . . . . . . . . . . . . . . . . 2
3.1. UTC Behavior during a Positive Leap Second . . . . . . . 3
3.2. NTP Behavior during a Positive Leap Second . . . . . . . 3
3.3. POSIX Behavior during a Positive Leap Second . . . . . . 3
3.4. Example of Leap-Second Behaviors . . . . . . . . . . . . 4
4. Receiver Behavior during a Leap Second . . . . . . . . . . . 5
5. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Sender Reports . . . . . . . . . . . . . . . . . . . . . 6
5.2. RTP Packet Playout . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . 8
In some media networking applications, RTP streams are referenced to a wall-clock time (absolute date and time). This is accomplished through use of the NTP timestamp field in the sender report (SR) to create a mapping between RTP timestamps and the wall clock. When a wall-clock reference is used, the playout time for RTP packets is referenced to the wall clock. Smooth and continuous media playout requires a smooth and continuous time base. The time base used by the wall clock may include leap seconds that are not rendered smoothly.
一部のメディアネットワーキングアプリケーションでは、RTPストリームは実時間（絶対日時）を参照します。これは、送信者レポート（SR）のNTPタイムスタンプフィールドを使用して、RTPタイムスタンプとウォールクロックの間のマッピングを作成することで実現されます。壁時計基準が使用される場合、RTPパケットのプレイアウト時間は壁時計を基準とします。スムーズで継続的なメディアの再生には、スムーズで継続的なタイムベースが必要です。ウォールクロックで使用されるタイムベースには、スムーズにレンダリングされないうるう秒が含まれる場合があります。
This document updates RFC 3550 [1] by providing recommendations for smoothly rendering streamed media referenced to common wall clocks that do not have smooth or continuous behavior in the presence of leap seconds.
このドキュメントは、うるう秒の存在下でスムーズまたは連続的な動作を行わない一般的なウォールクロックを参照するストリーミングメディアをスムーズにレンダリングするための推奨事項を提供することにより、RFC 3550 [1]を更新します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for compliant implementations.
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [2]で説明されているように解釈され、準拠した実装の要件レベルを示します。
The world's scientific time standard is International Atomic Time (TAI), which is based on vibrations of cesium atoms in an atomic clock. The world's civil time is based on the rotation of the Earth.
世界の科学的な時間標準は、原子時計のセシウム原子の振動に基づく国際原子時間（TAI）です。世界の市民の時間は地球の自転に基づいています。
In 1972, the civil time standard, Coordinated Universal Time (UTC), was redefined in terms of TAI and the concept of leap seconds was introduced to allow UTC to remain synchronized with the rotation of the Earth.
1972年に、常用時標準である協定世界時（UTC）がTAIの観点から再定義され、うるう秒の概念が導入され、UTCが地球の回転と同期を維持できるようになりました。
Leap seconds are scheduled by the International Earth Rotation and Reference Systems Service. Leap seconds may be scheduled at the last day of any month but are preferentially scheduled for December and June and secondarily March and September [6]. Because Earth's rotation is unpredictable, leap seconds are typically not scheduled more than six months in advance.
うるう秒は、国際地球回転および参照システムサービスによってスケジュールされています。うるう秒は任意の月の最終日にスケジュールできますが、12月と6月に優先的にスケジュールされ、2番目に3月と9月にスケジュールされます[6]。地球の回転は予測できないため、うるう秒は通常、6か月以上前にスケジュールされていません。
Leap seconds do not respect local time and always occur at the end of the UTC day. Leap seconds can be scheduled to either add or remove a second from the day. A leap second that adds an extra second is known as a positive leap second. A leap second that skips a second is known as a negative leap second.
うるう秒は現地時間を考慮せず、常にUTCの日の終わりに発生します。うるう秒は、その日の秒を追加または削除するようにスケジュールできます。秒を追加するうるう秒は、正のうるう秒と呼ばれます。 1秒をスキップするうるう秒は、負のうるう秒と呼ばれます。
Since their introduction in 1972, all leap seconds have been scheduled in June or December, and they have all been positive.
1972年の導入以来、すべてのうるう秒は6月または12月に予定されており、それらはすべて前向きです。
NOTE: The ITU is studying a proposal that could eventually eliminate leap seconds from UTC. As of January 2012, this proposal is expected to be decided no earlier than 2015 [7].
注：ITUは、UTCからうるう秒を最終的に取り除くことができる提案を検討しています。 2012年1月現在、この提案は2015年までに決定される予定です[7]。
UTC clocks feature a 61st second at the end of the day when a positive leap second is scheduled. The leap second is designated "23h 59m 60s".
UTCクロックは、正のうるう秒がスケジュールされている日の終わりに61秒を備えています。うるう秒は「23h 59m 60s」と指定されています。
Under NTP [8], a leap second is inserted at the beginning of the last second of the day. This results in the clock freezing or slowing for one second immediately prior to the last second of the affected day. This results in the last second of the day having a real-time duration of two seconds. Timestamp accuracy is compromised during this period because the clock's rate is not well defined.
NTP [8]の下では、うるう秒がその日の最後の秒の初めに挿入されます。これにより、影響を受ける日の最後の1秒の直前に、時計が1秒間フリーズまたはスローダウンします。その結果、1日の最後の秒は2秒のリアルタイム期間になります。クロックのレートが明確に定義されていないため、この期間中はタイムスタンプの精度が低下します。
The POSIX (Portable Operating System Interface) standard [3] requires that leap seconds be omitted from reported time. All days are defined as having 86,400 seconds, but the timebase is defined to be UTC, a leap-second-bearing reference. Implementors of POSIX systems are offered considerable latitude by the standard as to how to map POSIX time to UTC.
POSIX（Portable Operating System Interface）標準[3]では、報告される時間からうるう秒を省略することが要求されています。すべての日は86,400秒と定義されていますが、タイムベースはうるう秒を表す参照であるUTCとして定義されています。 POSIXシステムの実装者は、POSIX時間をUTCにマップする方法に関して、標準によってかなりの自由度を提供されています。
In many systems, leap seconds are accommodated by repeating the last second of the day. A timestamp within the last second of the day is therefore ambiguous in that it can refer to a moment in time in either of the last two seconds of a day containing a leap second.
多くのシステムでは、うるう秒はその日の最後の秒を繰り返すことで調整されます。したがって、1日の最後の秒内のタイムスタンプは、うるう秒を含む1日の最後の2秒のいずれかの瞬間を参照できるため、あいまいです。
Other systems use the same technique used by NTP, freezing or slowing for one second immediately prior to the last second of the affected day.
他のシステムは、NTPで使用されるのと同じ手法を使用して、影響を受ける日の最後の1秒の直前に1秒間フリーズまたはスローダウンします。
In some cases, leap seconds are accommodated by warping time [5] [4]; that is, the length of the second in the vicinity of a leap second is slightly altered.
場合によっては、うるう秒はワープ時間[5] [4]によって調整されます。つまり、うるう秒付近の秒の長さがわずかに変更されます。
Table 1 illustrates the positive leap second that occurred June 30, 2012 when the offset between TAI and UTC changed from 34 to 35 seconds. The first column shows RTP timestamps for an 8 kHz audio stream. The second column shows the TAI reference. The following columns show behavior for the leap-second-bearing wall clocks described above. Time values are shown at half-second intervals.
表1は、TAIとUTC間のオフセットが34秒から35秒に変更された2012年6月30日の正のうるう秒を示しています。最初の列は、8 kHzオーディオストリームのRTPタイムスタンプを示しています。 2番目の列は、TAI参照を示しています。次の列は、上記のうるう秒を設定したウォールクロックの動作を示しています。時間の値は0.5秒間隔で表示されます。
+-------+--------------+--------------+--------------+--------------+
| RTP | TAI | UTC | POSIX | NTP |
+-------+--------------+--------------+--------------+--------------+
| 8000 | 00:00:32.500 | 23:59:58.500 | 23:59:58.500 | 23:59:58.500 |
| 12000 | 00:00:33.000 | 23:59:59.000 | 23:59:59.000 | 23:59:59.000 |
| 16000 | 00:00:33.500 | 23:59:59.500 | 23:59:59.500 | 23:59:59.500 |
| 20000 | 00:00:34.000 | 23:59:60.000 | 23:59:59.000 | 00:00:00.000 |
| 24000 | 00:00:34.500 | 23:59:60.500 | 23:59:59.500 | 00:00:00.000 |
| 28000 | 00:00:35.000 | 00:00:00.000 | 00:00:00.000 | 00:00:00.000 |
| 32000 | 00:00:35.500 | 00:00:00.500 | 00:00:00.500 | 00:00:00.500 |
+-------+--------------+--------------+--------------+--------------+
Table 1: Positive Leap-Second Behavior
表1：正のうるう秒の動作
NOTE: Some NTP implementations do not entirely freeze the clock while the leap second is inserted. Successive calls to retrieve system time return infinitesimally larger (e.g., 1 microsecond or 1 nanosecond larger) time values. This behavior is designed to satisfy assumptions applications may make that time increases monotonically. This behavior occurs in the least-significant bits of the time value and so is not typically visible in the human-readable format shown in the table.
注：一部のNTP実装は、うるう秒が挿入されている間、完全にクロックを凍結しません。システム時間を取得するための連続した呼び出しは、無限に大きい（たとえば、1マイクロ秒または1ナノ秒大きい）時間値を返します。この動作は、アプリケーションがその時間を単調に増加させるという仮定を満たすように設計されています。この動作は時間値の最下位ビットで発生するため、通常、表に示されている人間が読める形式では表示されません。
NOTE: POSIX implementations vary. The implementation shown here repeats the last second of the affected day. Other implementations mirror NTP behavior or alter the length of a second in the vicinity of the leap second.
注：POSIX実装は異なります。ここに示す実装は、影響を受ける日の最後の1秒間を繰り返します。他の実装では、NTPの動作をミラーリングするか、うるう秒の近くで秒の長さを変更します。
Timestamps generated during a leap second may be ambiguous or interpreted differently by a sender and receiver or interpreted differently by different receivers.
うるう秒の間に生成されたタイムスタンプは、あいまいであるか、送信側と受信側で異なって解釈されるか、受信側で異なって解釈される可能性があります。
Without prior knowledge of the leap-second schedule, NTP servers and clients may become offset by exactly one second with respect to their UTC reference. This potential discrepancy begins when a leap second occurs and ends when all participants receive a time update from a server or peer. Depending on the system implementation, the offset can last anywhere from a few seconds to a few days. A long-lived discrepancy can be particularly disruptive to operation of NTP-referenced RTP streams.
うるう秒のスケジュールを事前に把握していないと、NTPサーバーとクライアントは、UTC参照に対して正確に1秒ずれることがあります。この潜在的な不一致は、うるう秒が発生したときに始まり、すべての参加者がサーバーまたはピアから時刻の更新を受信したときに終了します。システムの実装に応じて、オフセットは数秒から数日まで続きます。長期にわたる不一致は、NTP参照のRTPストリームの動作を特に破壊する可能性があります。
These discrepancies, depending on direction, may cause receivers to think they are receiving RTP packets after they should be played or to attempt to buffer received data an additional second before playing it. Either situation can cause an interruption in playback. Some receivers may automatically recognize an unexpected offset and resynchronize to the stream to accommodate it. Once the offset is resolved, such receivers may need to resynchronize again.
これらの不一致は、方向に応じて、再生する必要がある後にRTPパケットを受信していると考えるか、受信したデータを再生する前にさらに1秒間バッファリングしようとする可能性があります。どちらの場合も、再生が中断する可能性があります。一部のレシーバーは、予期しないオフセットを自動的に認識し、ストリームに再同期してそれに対応する場合があります。オフセットが解決されると、そのようなレシーバーは再度同期する必要がある場合があります。
Senders and receivers that are not referenced to a wall clock are not affected by issues associated with leap seconds, and no special accommodation is required.
ウォールクロックを参照していない送信者と受信者は、うるう秒に関連する問題の影響を受けず、特別な調整は必要ありません。
RTP implementation using a wall-clock reference is simplified by using a clock with a timescale that does not include leap seconds. IEEE 1588 [9], GPS [10], and other systems that use a TAI [11] reference do not include leap seconds. NTP time, operating system clocks, and other systems using a UTC reference include leap seconds.
壁時計基準を使用したRTP実装は、うるう秒を含まないタイムスケールの時計を使用することで簡素化されます。 IEEE 1588 [9]、GPS [10]、およびTAI [11]リファレンスを使用するその他のシステムには、うるう秒は含まれていません。 NTP時間、オペレーティングシステムクロック、およびUTCリファレンスを使用するその他のシステムには、うるう秒が含まれます。
Note that some TAI-based systems such as IEEE 1588 and GPS, in addition to the TAI reference clock, deliver TAI to UTC mapping information. By combining the delivered TAI reference clock and the mapping information, some receivers of these systems are able to synthesize a leap-second-bearing UTC reference clock. For the purposes of this document, it is important to recognize that it is the timescale used, not the delivery mechanism that determines whether a reference clock is leap-second bearing.
IEEE 1588やGPSなどの一部のTAIベースのシステムは、TAI基準クロックに加えて、TAIからUTCへのマッピング情報を提供することに注意してください。配信されたTAI基準クロックとマッピング情報を組み合わせることにより、これらのシステムの一部の受信機は、うるう秒を伴うUTC基準クロックを合成できます。このドキュメントの目的のために、参照クロックがうるう秒に対応しているかどうかを決定する配信メカニズムではなく、使用されるタイムスケールであることを認識することが重要です。
+-------------------------+---------------------+---------------+
| Reference clock type | Examples | Accommodation |
+-------------------------+---------------------+---------------+
| None | Self clocking | None needed |
| Non-leap-second-bearing | IEEE 1588, GPS, TAI | None needed |
| Leap-second-bearing | NTP | Recommended |
+-------------------------+---------------------+---------------+
Table 2: Recommendations Summary
表2：推奨事項の要約
All participants generating or consuming timestamps associated with a leap-second-bearing reference MUST recognize leap seconds and SHOULD have a working communications channel to receive notifications of leap-second scheduling. A working communication channel includes a protocol means of notifying clocks of an impending leap second such as the Leap Indicator in the NTP header [8] and also a means for top-tier clocks to receive leap-second schedule information published by the International Earth Rotation and Reference Systems Service [12].
うるう秒を伴う参照に関連付けられたタイムスタンプを生成または使用するすべての参加者は、うるう秒を認識しなければならず、うるう秒スケジューリングの通知を受信するための有効な通信チャネルが必要です。有効な通信チャネルには、NTPヘッダーのうるうインジケータなどのうるう秒の差し迫ったクロックを通知するプロトコル手段[8]と、国際地球回転によって公開されたうるう秒スケジュール情報を受信する最上位のクロックの手段も含まれます。および参照システムサービス[12]。
Such a communications channel may not be available on all networks. For security or other reasons, leap-second schedules may be configured manually for some networks or clocks. When a device does not reliably receive leap-second scheduling information, failures as described in Section 4 may occur.
このような通信チャネルは、すべてのネットワークで利用できるとは限りません。セキュリティまたはその他の理由により、一部のネットワークまたはクロックでは、うるう秒のスケジュールを手動で構成できます。デバイスがうるう秒のスケジューリング情報を確実に受信しない場合、セクション4で説明されているような障害が発生する可能性があります。
Because of the timestamp ambiguity that positive leap seconds can introduce and the inconsistent manner in which different systems accommodate positive leap seconds, generating or using NTP timestamps during the entire last second of a day on which a positive leap second has been scheduled SHOULD be avoided. Note that the period to be avoided has a real-time duration of two seconds. In the Table 1 example, the region to be avoided is indicated by RTP timestamps 12000 through 28000
正のうるう秒がもたらす可能性のあるタイムスタンプのあいまいさ、および異なるシステムが正のうるう秒に対応する一貫性のない方法のため、正のうるう秒がスケジュールされている日の最後の秒全体でNTPタイムスタンプを生成または使用することは避けてください。回避する期間は、2秒のリアルタイム期間であることに注意してください。表1の例では、回避する領域は、RTPタイムスタンプ12000から28000で示されています。
Negative leap seconds do not introduce timestamp ambiguity or other complications. No special treatment is needed to avoid ambiguity with respect to RTP timestamps in the presence of a negative leap second.
負のうるう秒は、タイムスタンプのあいまいさやその他の複雑さをもたらしません。負のうるう秒が存在する場合に、RTPタイムスタンプに関するあいまいさを回避するために特別な処理は必要ありません。
POSIX clocks that use a warping technique to accommodate leap seconds (e.g., [4] [5]) are not a good choice for an interoperable timestamp reference and SHOULD not be used to timestamp RTP streams.
うるう秒に対応するためにワーピング手法を使用するPOSIXクロック（[4] [5]など）は、相互運用可能なタイムスタンプ参照には適しておらず、RTPストリームのタイムスタンプに使用すべきではありません（SHOULD）。
In order to avoid generating or using NTP timestamps during positive leap seconds, RTP senders and receivers need to avoid sending or using sender reports to synchronize their clocks in the vicinity of a leap second and instead rely on their internal clocks to maintain synchronization until the leap second has passed.
正のうるう秒の間にNTPタイムスタンプを生成または使用しないようにするため、RTP送信者と受信者は送信者レポートの送信または使用を避けて、うるう秒の近くでクロックを同期し、代わりにうるうまで同期を維持するために内部クロックに依存する必要があります。秒が過ぎました。
RTP Senders using a leap-second-bearing reference for timestamps SHOULD NOT generate sender reports containing an originating NTP timestamp in the vicinity of a positive leap second. To maintain a consistent RTCP schedule and avoid the risk of unintentional timeouts, such senders MAY send receiver reports in place of sender reports in the vicinity of the leap second.
タイムスタンプにうるう秒を伴う参照を使用するRTP送信者は、正のうるう秒の近くに元のNTPタイムスタンプを含む送信者レポートを生成してはなりません（SHOULD NOT）。一貫したRTCPスケジュールを維持し、意図しないタイムアウトのリスクを回避するために、そのような送信者は、うるう秒の近くで送信者レポートの代わりに受信者レポートを送信できます（MAY）。
For the purpose of suspending sender reports in the vicinity of a leap second, senders MAY assume that a positive leap second occurs at the end of the last day of every month.
うるう秒の近くで送信者レポートを一時停止する目的で、送信者は正のうるう秒が毎月の最終日の終わりに発生すると想定してもよい（MAY）。
Receivers consuming leap-second-bearing timestamps SHOULD ignore timestamps in any sender reports generated in the vicinity of a positive leap second.
うるう秒を含むタイムスタンプを使用する受信者は、正のうるう秒の近くで生成された送信者レポートのタイムスタンプを無視する必要があります。
For the purpose of ignoring sender reports in the vicinity of a leap second, receivers MAY assume that a positive leap second occurs at the end of the last day of every month.
うるう秒付近の送信者レポートを無視する目的で、受信者は正のうるう秒が毎月の最終日の終わりに発生すると想定してもよい（MAY）。
Receivers consuming leap-second-bearing timestamps SHOULD take both positive and negative leap seconds in the reference into account to determine the playout time based on RTP timestamps for data in RTP packets.
うるう秒を含むタイムスタンプを消費する受信者は、RTPパケット内のデータのRTPタイムスタンプに基づいてプレイアウト時間を決定するために、参照の正と負の両方のうるう秒を考慮に入れるべきです（SHOULD）。
RTP streams using a wall-clock reference as discussed here present an additional attack vector compared to self-clocking streams. Manipulation of the wall clock at either the sender or receiver can potentially disrupt streaming.
ここで説明するウォールクロックリファレンスを使用したRTPストリームは、セルフクロッキングストリームと比較して、追加の攻撃ベクトルを示します。送信側または受信側のいずれかでウォールクロックを操作すると、ストリーミングが中断される可能性があります。
For an RTP stream operating to a leap-second-bearing reference to operate reliably across a leap second, the sender and receiver must both be aware of the leap second. It is possible to disrupt a stream by blocking or delaying leap second notification to one of the participants. Streaming can be similarly affected if one of the participants can be tricked into believing a leap second has been scheduled where there is not one. These vulnerabilities are present in RFC 3550 [1] and these new recommendations neither heighten nor diminish them. Integrity of the leap-second schedule is the responsibility of the operating system and time distribution mechanism, both of which are outside the scope of RFC 3550 [1] and these recommendations.
うるう秒を伴う参照で動作するRTPストリームがうるう秒全体で確実に動作するには、送信側と受信側の両方がうるう秒を認識している必要があります。参加者の1人へのうるう秒通知をブロックまたは遅延することにより、ストリームを中断することができます。参加者の1人が、うるう秒が存在しない場所でうるう秒がスケジュールされていると信じ込まされた場合、ストリーミングは同様に影響を受ける可能性があります。これらの脆弱性はRFC 3550 [1]に存在し、これらの新しい推奨事項は脆弱性を高めたり、弱めたりしません。うるう秒のスケジュールの整合性は、オペレーティングシステムと時間配信メカニズムの責任であり、どちらもRFC 3550 [1]およびこれらの推奨事項の範囲外です。
The authors would like to thank Steve Allen for his valuable comments that helped to improve this document.
著者は、このドキュメントの改善に役立つ貴重なコメントを提供してくれたSteve Allenに感謝します。
[1] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.
[1] Schulzrinne、H.、Casner、S.、Frederick、R。、およびV. Jacobson、「RTP：A Transport Protocol for Real-Time Applications」、STD 64、RFC 3550、2003年7月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] IEEE, "Portable Operating System Interface (POSIX)", IEEE Standard 1003.1-2008, December 2008, <http://standards.ieee.org/findstds/standard/1003.1-2008.html>.
[3] IEEE、「Portable Operating System Interface（POSIX）」、IEEE Standard 1003.1-2008、2008年12月、<http://standards.ieee.org/findstds/standard/1003.1-2008.html>。
[4] Google, Inc., "Time, technology and leaping seconds", September 2011, <http://googleblog.blogspot.com/2011/09/ time-technology-and-leaping-seconds.html>.
[4] Google、Inc。、「Time、technology and leaping seconds」、2011年9月、<http://googleblog.blogspot.com/2011/09/ time-technology-and-leaping-seconds.html>。
[5] Kuhn, M., "Coordinated Universal Time with Smoothed Leap Seconds (UTC-SLS)", Work in Progress, January 2006.
[5] クーンM.、「平滑化うるう秒を使用した協定世界時（UTC-SLS）」、進行中の作業、2006年1月。
[6] ITU, "Standard-frequency and time-signal emissions", ITU-R TF.460-6, February 2002, <http://www.itu.int/rec/R-REC-TF.460/>.
[6] ITU、「標準周波数および時間信号エミッション」、ITU-R TF.460-6、2002年2月、<http://www.itu.int/rec/R-REC-TF.460/>。
[7] ITU, "The future of the UTC time scale", Question ITU-R 236/7, February 2012, <http://www.itu.int/pub/R-QUE-SG07.236-2001>.
[7] ITU、「UTC時間スケールの未来」、質問ITU-R 236 / 7、2012年2月、<http://www.itu.int/pub/R-QUE-SG07.236-2001>。
[8] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, June 2010.
[8] Mills、D.、Martin、J.、Burbank、J。、およびW. Kasch、「Network Time Protocol Version 4：Protocol and Algorithms Specification」、RFC 5905、2010年6月。
[9] IEEE, "IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE Standard 1588-2008, July 2008, <http://standards.ieee.org/findstds/standard/1588-2008.html>.
[9] IEEE、「ネットワーク化された測定および制御システムの高精度クロック同期プロトコルのIEEE標準」、IEEE標準1588-2008、2008年7月、<http://standards.ieee.org/findstds/standard/1588-2008.html>。
[10] Global Positioning Systems Directorate, "Systems Engineering & Integration Interface Specification", September 2011, <http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>.
[10] Global Positioning Systems Directorate、「Systems Engineering＆Integration Interface Specification」、2011年9月、<http://www.navcen.uscg.gov/pdf/IS-GPS-200F.pdf>。
[11] Bureau International des Poids et Mesures, "International Atomic Time", Navstar GPS Space Segment/Navigation User Segment Interfaces IS-GPS-200, <http://www.bipm.org/en/scientific/tai/tai.html>.
[11] 国際ウェイトおよびメジャーの局、「国際原子時間」、Navstar GPSスペースセグメント/ナビゲーションユーザーセグメントインターフェースIS-GPS-200、<http://www.bipm.org/en/scientific/tai/tai.html>。
[12] IERS Earth Orientation Centre, "Bulletin C - Product metadata", <http://datacenter.iers.org/web/guest/eop/-/somos/5Rgv/ product/16>.
[12] IERS Earth Orientation Centre、「Bulletin C-Product metadata」、<http://datacenter.iers.org/web/guest/eop/-/somos/5Rgv/ product / 16>。
Authors' Addresses
著者のアドレス
Kevin Gross AVA Networks Boulder, CO US
ケビングロスAVAネットワークボルダー、CO US
EMail: kevin.gross@avanw.com
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT the Netherlands
レイヴァンブランデンブルクTNOブラッサースプレイン2デルフト2612CTオランダ
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl