< draft-ietf-ntp-packet-timestamps-01.txt		draft-ietf-ntp-packet-timestamps-02.txt >
	Network Working Group T. Mizrahi		NTP Working Group T. Mizrahi
	Internet-Draft Marvell		Internet-Draft Marvell
	Intended status: Informational J. Fabini		Intended status: Informational J. Fabini
	Expires: September 6, 2018 Vienna University of Technology		Expires: December 26, 2018 TU Wien
	A. Morton		A. Morton
	AT&T Labs		AT&T Labs
	March 5, 2018		June 24, 2018
	Guidelines for Defining Packet Timestamps		Guidelines for Defining Packet Timestamps
	draft-ietf-ntp-packet-timestamps-01		draft-ietf-ntp-packet-timestamps-02
	Abstract		Abstract
	This document specifies guidelines for defining binary packet		This document specifies guidelines for defining binary packet
	timestamp formats in networking protocols at various layers. It also		timestamp formats in networking protocols at various layers. It also
	presents three recommended timestamp formats. The target audience of		presents three recommended timestamp formats. The target audience of
	this memo includes network protocol designers. It is expected that a		this memo includes network protocol designers. It is expected that a
	new network protocol that requires a packet timestamp will, in most		new network protocol that requires a packet timestamp will, in most
	cases, use one of the recommended timestamp formats. If none of the		cases, use one of the recommended timestamp formats. If none of the
	recommended formats fits the protocol requirements, the new protocol		recommended formats fits the protocol requirements, the new protocol
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 6, 2018.		This Internet-Draft will expire on December 26, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2018 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3		2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3
	2.3. Terms used in this Document . . . . . . . . . . . . . . . 4		2.3. Terms used in this Document . . . . . . . . . . . . . . . 3
	3. Packet Timestamp Specification Template . . . . . . . . . . . 4		3. Packet Timestamp Specification Template . . . . . . . . . . . 4
	4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5		4. Recommended Timestamp Formats . . . . . . . . . . . . . . . . 5
	4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6		4.1. Using a Recommended Timestamp Format . . . . . . . . . . 6
	4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6		4.2. NTP Timestamp Formats . . . . . . . . . . . . . . . . . . 6
	4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6		4.2.1. NTP 64-bit Timestamp Format . . . . . . . . . . . . . 6
	4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 8		4.2.2. NTP 32-bit Timestamp Format . . . . . . . . . . . . . 7
	4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 9		4.3. The PTP Truncated Timestamp Format . . . . . . . . . . . 8
	5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 10		5. Synchronization Aspects . . . . . . . . . . . . . . . . . . . 10
	6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 11		6. Timestamp Use Cases . . . . . . . . . . . . . . . . . . . . . 10
	6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 12		6.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 12		6.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . . . 12
	7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 12		7. Packet Timestamp Control Field . . . . . . . . . . . . . . . 12
	7.1. High-level Control Field Requirements . . . . . . . . . . 13		7.1. High-level Control Field Requirements . . . . . . . . . . 12
	7.2. Control Field Categories . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7.3. Control Field Features and Elements . . . . . . . . . . . 15		9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7.3.1. Timestamp Format . . . . . . . . . . . . . . . . . . 16		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	7.3.2. Timestamp Format Specification . . . . . . . . . . . 16		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.3.3. Timestamp Precision . . . . . . . . . . . . . . . . . 17		11.1. Normative References . . . . . . . . . . . . . . . . . . 15
	7.3.4. Timestamp Timescale . . . . . . . . . . . . . . . . . 17		11.2. Informative References . . . . . . . . . . . . . . . . . 15
	7.3.5. Timestamp Leap Second . . . . . . . . . . . . . . . . 17		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
	7.3.6. Reference Clock . . . . . . . . . . . . . . . . . . . 18
	7.3.7. Provable Signature . . . . . . . . . . . . . . . . . 18
	7.3.8. Custom Extension . . . . . . . . . . . . . . . . . . 18
	7.4. Control Field Payload Definition . . . . . . . . . . . . 19
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	11.1. Normative References . . . . . . . . . . . . . . . . . . 20
	11.2. Informative References . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Timestamps are widely used in network protocols for various purposes,		Timestamps are widely used in network protocols for various purposes,
	including delay measurement, clock synchronization, and logging or		including delay measurement, clock synchronization, and logging or
	reporting the time of an event.		reporting the time of an event.
	Timestamps are represented in the RFC series in one of two forms:		Timestamps are represented in the RFC series in one of two forms:
	text-based timestamps, and packet timestamps. Text-based timestamps		text-based timestamps, and packet timestamps. Text-based timestamps
	[RFC3339] are represented as user-friendly strings, and are widely		[RFC3339] are represented as user-friendly strings, and are widely
	skipping to change at page 9, line 23 ¶		skipping to change at page 8, line 50 ¶
	4.3. The PTP Truncated Timestamp Format		4.3. The PTP Truncated Timestamp Format
	The Precision Time Protocol (PTP) [IEEE1588] uses an 80-bit timestamp		The Precision Time Protocol (PTP) [IEEE1588] uses an 80-bit timestamp
	format. The truncated timestamp format is a 64-bit field, which is		format. The truncated timestamp format is a 64-bit field, which is
	the 64 least significant bits of the 80-bit PTP timestamp. Since		the 64 least significant bits of the 80-bit PTP timestamp. Since
	this timestamp format is similar to the one used in PTP, this		this timestamp format is similar to the one used in PTP, this
	timestamp format should be preferred in network protocols that are		timestamp format should be preferred in network protocols that are
	typically deployed in PTP-capable devices.		typically deployed in PTP-capable devices.
	The PTP truncated timestamp format is used in several protocols, such		The PTP truncated timestamp format was defined in [IEEE1588v1] and is
	as [RFC6374], [RFC7456], [RFC8186] and [ITU-T-Y.1731].		used in several protocols, such as [RFC6374], [RFC7456], [RFC8186]
			and [ITU-T-Y.1731].
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Seconds |		| Seconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Nanoseconds |		| Nanoseconds |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 3: PTP [IEEE1588] Truncated Timestamp Format		Figure 3: PTP [IEEE1588] Truncated Timestamp Format
	skipping to change at page 12, line 45 ¶		skipping to change at page 12, line 27 ¶
	It is assumed that nodes that run this protocol are synchronized		It is assumed that nodes that run this protocol are synchronized
	among themselves. Nodes may be synchronized to a global reference		among themselves. Nodes may be synchronized to a global reference
	time. Note that if PTP [IEEE1588] is used for synchronization,		time. Note that if PTP [IEEE1588] is used for synchronization,
	the timestamp may be derived from the PTP-synchronized clock,		the timestamp may be derived from the PTP-synchronized clock,
	allowing the timestamp to be measured with respect to the clock of		allowing the timestamp to be measured with respect to the clock of
	an PTP Grandmaster clock.		an PTP Grandmaster clock.
	7. Packet Timestamp Control Field		7. Packet Timestamp Control Field
	In some cases it is desirable to have a control field that includes		In some cases it is desirable to have a control field that describes
	information about the timestamp format. Control information about		structure, format, content, and properties of timestamps. Control
	the timestamp format can be conveyed in some protocols using a		information about the timestamp format can be conveyed in some
	dedicated control plane protocol, or may be made available at the		protocols using a dedicated control plane protocol, or may be made
	management plane, for example using a YANG data model. The optional		available at the management plane, for example using a YANG data
	control field that is defined in this section allows some of the		model. An optional control field allows some of the control
	control information to be attached to the timestamp. This section		information to be attached to the timestamp.
	defines requirements and a recommended format of a timestamp-related
	control field that is intended for network protocols that can benefit		An example of a packet timestamp control field is the Error Estimate
	from such timestamp-related control information.		field, defined by Section 4.1.2 in [RFC4656], which is used in OWAMP
			[RFC4656] and TWAMP [RFC5357].
			This section defines high-level guidelines for defining packet
			timestamp control fields in network protocols that can benefit from
			such timestamp-related control information. The word 'requirements'
			is used in its informal context in this section.
	7.1. High-level Control Field Requirements		7.1. High-level Control Field Requirements
	A control field for packet timestamps must offer an adequate feature		A control field for packet timestamps must offer an adequate feature
	set and fulfill a series of requirements to be usable and accepted.		set and fulfill a series of requirements to be usable and accepted.
	The following list captures the main high-level requirements for		The following list captures the main high-level requirements for
	timestamp fields.		timestamp fields.
	1. Extensible Feature Set: protocols and applications depend on		1. Extensible Feature Set: protocols and applications depend on
	various timestamp characteristics. A timestamp control field		various timestamp characteristics. A timestamp control field
	must support a variable number of elements (components) that		must support a variable number of elements (components) that
	either describe or quantify timestamp-specific characteristics or		either describe or quantify timestamp-specific characteristics or
	parameters. Examples of potential elements include timestamp		parameters. Examples of potential elements include timestamp
	accuracy, leap seconds, reference clock identifiers, etc.		size, encoding, accuracy, leap seconds, reference clock
			identifiers, etc.
	2. Size: Essential for an efficient use of timestamp control fields		2. Size: Essential for an efficient use of timestamp control fields
	is the trade-off between supported features and control field		is the trade-off between supported features and control field
	size. Protocols and applications may select the specific control		size. Protocols and applications may select the specific control
	field elements that are needed for their operation from the set		field elements that are needed for their operation from the set
	of available elements.		of available elements.
	3. Composition: Applications may depend on specific control field		3. Composition: Applications may depend on specific control field
	elements being present in messages. The status of these elements		elements being present in messages. The status of these elements
	may be either mandatory, conditional mandatory, or optional,		may be either mandatory, conditional mandatory, or optional,
	depending on the specific application and context. This memo		depending on the specific application and context. A control
	must support applications in conveying or negotiating (a) the set		field specification must support applications in conveying or
	of control field elements along with (b) the status of any		negotiating (a) the set of control field elements along with (b)
	element (i.e., mandatory, conditional mandatory, or optional) by		the status of any element (i.e., mandatory, conditional
	defining appropriate data structures and identity codes.		mandatory, or optional) by defining appropriate data structures
			and identity codes.
	4. Category: Control field elements can characterize either static		4. Category: Control field elements can characterize either static
	timestamp information (like, e.g., timestamp size in bytes and		timestamp information (like, e.g., timestamp size in bytes and
	timestamp semantics: NTP 64 bit format) or runtime timestamp		timestamp semantics: NTP 64 bit format) or runtime timestamp
	information (like, e.g., estimated timestamp accuracy at the time		information (like, e.g., estimated timestamp accuracy at the time
	of sampling: 20 microseconds to UTC). For efficiency reason it		of sampling: 20 microseconds to UTC). For efficiency reason it
	is meaningful to support separation of these two concepts: while		may be meaningful to support separation of these two concepts:
	the former (static) information is typically valid throughout a		while the former (static) information is typically valid
	protocol session and may be conveyed only once, at session		throughout a protocol session and may be conveyed only once, at
	establishment time, the latter (runtime) information augments any		session establishment time, the latter (runtime) information
	timestamp instance and may cause substantial overhead for high-		augments any timestamp instance and may cause substantial
	traffic protocols.		overhead for high-traffic protocols.
	7.2. Control Field Categories
	Depending on their characteristics, the elements or components of a
	timestamp control field can be assigned to one of two categories:
	Structure (static) or Instance (runtime). Aim of this categorization
	is to support minimum overhead of timestamp control fields in
	practice. Protocols may use structural elements once, at connection
	setup time to define or negotiate the timestamp structure and instace
	elements (repeatedly) to identify the quality of timestamp instances
	at runtime.
	1. <Structure>: static timestamp control field. The static control
	field identifies information like timestamp structure, type,
	size, or features, that characterize and are common to a set of
	related timestamps. Typical use of such a control field is at
	connection establishment time when protocols negotiate available
	and preferred timestamp types and features to be used for the
	lifetime of an association. For instance endpoints can specify
	the type, structure and size of the timestamp representation
	within protocol messages that will be exchanged as part of a
	following protocol session. These can be either standard
	timestamp formats like NTP 64 bit as specified by this memo or
	specific vendor-defined timestamp formats.
	2. <Instance>: runtime timestamp control field. Besides static
	information, dynamic (runtime) timestamp information is commonly
	available at the sender when sampling a specific timestamp
	instance. Typical examples include the ID of a clock that
	originated a specific timestamp, the estimated time
	synchronization accuracy of the local reference clock when
	sampling a specific timestamp, or the correction to apply due to
	an ongoing leap smear for a leap second. Moreover, with today's
	critical infrastructures depending increasingly on accurate time,
	provable signatures may become an essential runtime parameter to
	protect the integrity of timestamp and control field values. The
	accurate and reliable operation of timestamp receivers can
	benefit from this detailed runtime control field information that
	augments any single timestamp.
	Drawing analogies to programming languages, the static timestamp
	control field maps best to concepts like "type", "structure", or
	"template", whereas the runtime timestamp control field corresponds
	to "variables", i.e., runtime-instantiations of types. Main
	consequence is that static timestamp control fields may be exchanged
	only once during an ongoing association, saving substantial link
	capacity, whereas a runtime timestamp control field accompanies any
	single message or timestamp instance. Still, some protocols may
	prefer to augment any single timestamp instance with both, a static
	and a runtime control field. Example use cases for the latter
	variant include potential support for heterogeneity in terms of
	timestamps - various clients can decide dynamically which timestamp
	format they send as part of the protocol - or to include a maximum of
	timestamp context for receivers in the case of sporadic messages.
	7.3. Control Field Features and Elements
	The timestamp control field is composed of elements that can be
	selected from the following set:
	o Timestamp format
	o Timestamp format specification
	o Precision
	o Timescale
	o Leap second
	o Reference clock(s)
	o Probable signature
	o Custom extension
	o ... (tbd)
	The following subsections detail on the role of the elements, their
	structure and related constraints. Any element is characterized by
	the following parameters:
	o ID: <IANA identifier for this element>
	o Type: Either <structure>: element defines static timestamp
	structure that can subsequently be used to describe several
	instances of timestamps - typically used once during connection
	setup, or <instance>: parameter characteristic to a specific
	timestamp instance.
	o Status: <mandatory>, <conditional mandatory>, or <optional>.
	Note: interpretation of the status field depends on the value of
	the type field. If type is <structure>, then status <mandatory>
	means that this element must be part of any <structure>-type
	timestamp control field. However, it may be part of <instance>-
	type timestamp control field, too.
	o Size: <the size of this element, including all elements>
	o Value: the value or subfields of this element
	o Comments: Additions and considerations for this element
	7.3.1. Timestamp Format
	The timestamp format field defines the size and semantics of the
	timestamp that follows this timestamp control field by referencing
	appropriate IANA IDs.
	o ID: tbd
	o Type: <structure>
	o Status: <mandatory>
	o Size: tbd
	o Value: IANA identifier, referencing either a standard format
	defined by this memo or an alternate timestamp format (e.g.
	vendor-specific extension). In the latter case, a Timestamp
	Format Specification field is conditional mandatory.
	o Comments:
	7.3.2. Timestamp Format Specification
	The timestamp format specification field defines the structure and
	size of custom timestamps and is needed whenever the use of standard
	timestamp formats is inappropriate.
	o ID: tbd
	o Type: <structure>
	o Status: <conditional mandatory>. This field must be included
	whenever the "timestamp format" element references non-standard
	timestamp formats and must not be included into the control field
	otherwise.
	o Size: tbd
	o Value: Subfields: 1. Timestamp size; 2. User- or vendor-specific
	id and 3. Sub-id that allow to uniquely identify this timestamp
	type;
	o Comments:
	7.3.3. Timestamp Precision
	The precision field value stores the precision of the clock that
	originated the timestamp at the time when the timestamp was sampled
	along with attributes that characterize the timestamp quality (like
	absolute or relative synchronization, reference clock identifiers,
	etc.)
	o ID: tbd
	o Type: <instance> (optionally: <structure> when the clock
	originating the timestamps has maximum limits for precision)?
	o Status: <optional>. The local system may or may not know the
	precision (or accuracy) of its clock and sampled timestamps.
	o Size: tbd
	o Value: Subfields: 1. Estimated Precision (in terms of 10^(-x)),
	2. Maximum Error, 3. Reference (Absolute: UTC, TAI ...,
	Relative: to specific clock, needs reference to clock ID)
	o Comments: NTF calls this "error".
	7.3.4. Timestamp Timescale
	The timescale field denotes Epoch and Era of the timestamp
	o ID: tbd
	o Type: <instance>
	o Status: <optional>
	o Size: tbd
	o Value: Subfields: 1. epoch 2. era
	o Comments:
	7.3.5. Timestamp Leap Second
	o ID: tbd
	o Type: <instance>
	o Status: <optional>
	o Size: tbd
	o Value: Subfields: 1. Leap second ongoing 2. Considered leap
	second fraction (during leap smear)
	o Comments:
	7.3.6. Reference Clock
	o ID: tbd
	o Type: <instance> (perhaps <structure>, too)
	o Status: <optional>
	o Size: tbd
	o Value: Subfields: 1. Reference clock type 2. Unique reference
	clock ID
	o Comments:
	7.3.7. Provable Signature
	o ID: tbd
	o Type: <instance>
	o Status: <optional>
	o Size: tbd
	o Value: Signature covering the entire timstamp control field and
	the timestamp field, masking out the provable signature field with
	0.
	o Comments:
	7.3.8. Custom Extension
	o ID: tbd
	o Type: <structure> or <instance>
	o Status: <optional>
	o Size: tbd
	o Value: tbd
	o Comments: For future extensions
	7.4. Control Field Payload Definition
	This section defines the binding format of timestamp control		Proposals for timestamp control fields will be defined in separate
	(sub)fields to be used by protocols. (tbd)		documents and are out of scope of this memo.
	8. IANA Considerations		8. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Security Considerations		9. Security Considerations
	A network protocol that uses a packet timestamp MUST specify the		A network protocol that uses a packet timestamp MUST specify the
	security considerations that result from using the timestamp. This		security considerations that result from using the timestamp. This
	section provides an overview of some of the common security		section provides an overview of some of the common security
	skipping to change at page 20, line 16 ¶		skipping to change at page 14, line 44 ¶
	In many cases timestamping relies on an underlying synchronization		In many cases timestamping relies on an underlying synchronization
	mechanism. Thus, any attack that compromises the synchronization		mechanism. Thus, any attack that compromises the synchronization
	mechanism can also compromise protocols that use timestamping.		mechanism can also compromise protocols that use timestamping.
	Attacks on time protocols are discussed in detail in [RFC7384].		Attacks on time protocols are discussed in detail in [RFC7384].
	10. Acknowledgments		10. Acknowledgments
	The authors thank Yaakov Stein, Greg Mirsky, Warner Losh, Rodney		The authors thank Yaakov Stein, Greg Mirsky, Warner Losh, Rodney
	Cummings and other members of the NTP working group for many helpful		Cummings and other members of the NTP working group for many helpful
	comments. The authors gratefully acknowlege Harlan Stenn and the		comments. The authors gratefully acknowledge Harlan Stenn and the
	people from the Network Time Foundation for sharing their thoughts		people from the Network Time Foundation for sharing their thoughts
	and ideas.		and ideas.
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	skipping to change at page 20, line 39 ¶		skipping to change at page 15, line 24 ¶
	11.2. Informative References		11.2. Informative References
	[I-D.ietf-ippm-initial-registry]		[I-D.ietf-ippm-initial-registry]
	Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,		Morton, A., Bagnulo, M., Eardley, P., and K. D'Souza,
	"Initial Performance Metric Registry Entries", draft-ietf-		"Initial Performance Metric Registry Entries", draft-ietf-
	ippm-initial-registry-06 (work in progress), March 2018.		ippm-initial-registry-06 (work in progress), March 2018.
	[I-D.ietf-ntp-packet-timestamps]		[I-D.ietf-ntp-packet-timestamps]
	Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for		Mizrahi, T., Fabini, J., and A. Morton, "Guidelines for
	Defining Packet Timestamps", draft-ietf-ntp-packet-		Defining Packet Timestamps", draft-ietf-ntp-packet-
	timestamps-00 (work in progress), October 2017.		timestamps-01 (work in progress), March 2018.
	[IEEE1588]		[IEEE1588]
	IEEE, "IEEE 1588 Standard for a Precision Clock		IEEE, "IEEE 1588 Standard for a Precision Clock
	Synchronization Protocol for Networked Measurement and		Synchronization Protocol for Networked Measurement and
	Control Systems Version 2", 2008.		Control Systems Version 2", 2008.
			[IEEE1588v1]
			IEEE, "IEEE 1588 Standard for a Precision Clock
			Synchronization Protocol for Networked Measurement and
			Control Systems", 2002.
	[ITU-T-Y.1731]		[ITU-T-Y.1731]
	ITU-T, "OAM functions and mechanisms for Ethernet based		ITU-T, "OAM functions and mechanisms for Ethernet based
	Networks", 2013.		Networks", 2013.
	[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions		[RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions
	for High Performance", RFC 1323, DOI 10.17487/RFC1323, May		for High Performance", RFC 1323, DOI 10.17487/RFC1323, May
	1992, <https://www.rfc-editor.org/info/rfc1323>.		1992, <https://www.rfc-editor.org/info/rfc1323>.
	[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:		[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
	Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,		Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
	skipping to change at page 22, line 31 ¶		skipping to change at page 17, line 16 ¶
	Tal Mizrahi		Tal Mizrahi
	Marvell		Marvell
	6 Hamada st.		6 Hamada st.
	Yokneam		Yokneam
	Israel		Israel
	Email: talmi@marvell.com		Email: talmi@marvell.com
	Joachim Fabini		Joachim Fabini
	Vienna University of Technology		TU Wien
	Gusshausstrasse 25/E389		Gusshausstrasse 25/E389
	Vienna 1040		Vienna 1040
	Austria		Austria
	Phone: +43 1 58801 38813		Phone: +43 1 58801 38813
	Fax: +43 1 58801 38898		Fax: +43 1 58801 38898
	Email: Joachim.Fabini@tuwien.ac.at		Email: Joachim.Fabini@tuwien.ac.at
	URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/		URI: http://www.tc.tuwien.ac.at/about-us/staff/joachim-fabini/
	Al Morton		Al Morton
End of changes. 20 change blocks.
	305 lines changed or deleted		62 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/