Network Time Protocol Suggested REFID Extension Field
draft-stenn-ntp-suggest-refid-05
| Document | Type |
Expired Internet-Draft
(candidate for ntp WG)
Expired & archived
|
|
|---|---|---|---|
| Author | Harlan Stenn | ||
| Last updated | 2019-09-26 (Latest revision 2019-03-25) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Call For Adoption By WG Issued | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
NTP's Reference ID, or REFID, identifies the source of time in a timestamp or time packet. In NTP packets sent over the network the REFID is used to identify the "system peer", and in the long-term general case its fundamental purpose is to prevent a one-degree timing loop. Each instance of NTP decides for itself what REFID it will put in its outgoing packets, and there is currently no way for an external time source to tell or recommend this value in the case where that external time source is selected as the "system peer." The SUGGESTED-REFID NTP Extension Field proposal is a backward- compatible way for a time source to tell its peers or clients "If you use me as your system peer, use this nonce as your REFID."
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)