Diff: rfc9760.original.xml

	rfc9760.original.xml	rfc9760.xml

	<?xml version='1.0' encoding='utf-8'?>	<?xml version='1.0' encoding='UTF-8'?>

	<!DOCTYPE rfc [	<!DOCTYPE rfc [
	<!ENTITY nbsp " ">	<!ENTITY nbsp " ">
	<!ENTITY zwsp "">	<!ENTITY zwsp "">
	<!ENTITY nbhy "‑">	<!ENTITY nbhy "‑">
	<!ENTITY wj "⁠">	<!ENTITY wj "⁠">
	]>	]>

	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC8174] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	tf-tictoc-ptp-enterprise-profile-28" ipr="trust200902" obsoletes="" updates="" s
	ubmissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true"
	sortRefs="true" version="3">
	<!-- xml2rfc v2v3 conversion 3.12.3 -->
	<!-- category values: std, bcp, info, exp, and historic
	ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
	,
	or pre5378Trust200902
	you can add the attributes updates="NNNN" and obsoletes="NNNN"
	they will automatically be output with "(if approved)" -->


	<!-- *** FRONT MATTER *** -->	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
		tf-tictoc-ptp-enterprise-profile-28"
		number="9760" consensus="true" ipr="trust200902" obsoletes="" updates="" submiss
		ionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortR
		efs="true" version="3">

	<front>	<front>

	<!-- The abbreviated title is used in the page header - it is only necessary	<title abbrev="Enterprise Profile for PTP">Enterprise Profile for the
	if the	Precision Time Protocol with Mixed Multicast and Unicast Messages</title>
	full title is longer than 39 characters -->	<seriesInfo name="RFC" value="9760"/>

	<title abbrev="Enterprise Profile for PTP">Enterprise Profile for the Precisi
	on Time Protocol With Mixed Multicast and Unicast messages</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-tictoc-ptp-enterprise-pr
	ofile-28"/>
	<!-- add 'role="editor"' below for the editors if appropriate -->

	<!-- Another author who claims to be an editor -->


	<author fullname="Doug Arnold" initials="D.A." surname="Arnold">	<author fullname="Doug Arnold" initials="D." surname="Arnold">
	<organization>Meinberg-USA</organization>	<organization>Meinberg-USA</organization>
	<address>	<address>
	<postal>	<postal>
	<street>3 Concord Rd</street>	<street>3 Concord Rd</street>

	<!-- Reorder these if your country does things differently -->	<city>Shrewsbury</city>

	<city>Shrewsbury</city>
	<region>Massachusetts</region>	<region>Massachusetts</region>
	<code>01545</code>	<code>01545</code>

	<country>USA</country>	<country>United States of America</country>
	</postal>	</postal>

	<phone/>
	<email>doug.arnold@meinberg-usa.com</email>	<email>doug.arnold@meinberg-usa.com</email>

	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>

	<author fullname="Heiko Gerstung" initials="H.G." surname="Gerstung">	<author fullname="Heiko Gerstung" initials="H." surname="Gerstung">
	<organization>Meinberg</organization>	<organization>Meinberg</organization>
	<address>	<address>
	<postal>	<postal>
	<street>Lange Wand 9</street>	<street>Lange Wand 9</street>

	<!-- Reorder these if your country does things differently -->	<city>Bad Pyrmont</city>

	<city>Bad Pyrmont</city>
	<region/>
	<code>31812</code>	<code>31812</code>
	<country>Germany</country>	<country>Germany</country>
	</postal>	</postal>

	<phone/>
	<email>heiko.gerstung@meinberg.de</email>	<email>heiko.gerstung@meinberg.de</email>

	<!-- uri and facsimile elements may also be added -->
	</address>	</address>
	</author>	</author>

	<date year="2024"/>
	<!-- If the month and year are both specified and are the current ones, xml2
	rfc will fill
	in the current day for you. If only the current year is specified, xml2r
	fc will fill
	in the current day and month for you. If the year is not the current one
	, it is
	necessary to specify at least a month (xml2rfc assumes day="1" if not sp
	ecified for the
	purpose of calculating the expiry date). With drafts it is normally suf
	ficient to
	specify just the year. -->


	<!-- Meta-data Declarations -->	<!-- [rfced] First-page header: Authors, we have updated both of your names in
		the first-page header to use a single initial rather than two
		initials. Please let us know if you prefer to use two initials. Note that
		Heiko's name was listed with a single initial in the first-page header of
		RFC 5907.

		For more information about author names in the first-page header, please see
		Section 4.1.1 of RFC 7322 ("RFC Style Guide").
		-->

		<date year="2025" month="March"/>

		<area>INT</area>
		<workgroup>tictoc</workgroup>


	<area>General</area>
	<workgroup>TICTOC Working Group</workgroup>
	<keyword>PTP</keyword>	<keyword>PTP</keyword>
	<keyword>Enterprise Profile</keyword>	<keyword>Enterprise Profile</keyword>


		<!-- [rfced] We see the following warning in idnits output:
		"There are 1 instance of lines with multicast IPv4 addresses in the
		document. If these are generic example addresses, they should be changed
		to use the 233.252.0.x range defined in RFC 5771"

		It appears that idnits confused multicast addresses with the PTP
		primary IP address (for IPv4) listed in Section 6, but we want to
		point out the idnits warning all the same. It appears that we don't
		need to make any changes. Please review and confirm.

		Original:
		The PTP primary IP address is
		224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for IPv6, where X can
		be a value between 0x0 and 0xF. -->

	<abstract>	<abstract>
	<t>This document describes a Precision Time Protocol (PTP) Profile	<t>This document describes a Precision Time Protocol (PTP) Profile

	<xref target="IEEE1588" format="default">IEEE 1588-2019</xref>	(IEEE Standard 1588-2019)
	for use in an IPv4 or IPv6 Enterprise information system	for use in an IPv4 or IPv6 Enterprise information system
	environment. The PTP Profile uses the End-to-End delay measurement	environment. The PTP Profile uses the End-to-End delay measurement

	mechanism, allows both multicast and unicast Delay Request and Delay	mechanism, allowing both multicast and unicast Delay Request and Delay
	Response messages.</t>	Response messages.</t>
	</abstract>	</abstract>
	</front>	</front>
	<middle>	<middle>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Introduction</name>	<name>Introduction</name>

	<t>The Precision Time Protocol ("PTP"), standardized in IEEE 1588,	<t>The Precision Time Protocol (PTP), standardized in IEEE 1588, has
	has been designed in its first version (IEEE 1588-2002) with the	been designed in its first version (IEEE 1588-2002) with the goal of
	goal to minimize configuration on the participating nodes. Network	minimizing configuration on the participating nodes. Network communication
	communication was based solely on multicast messages, which unlike	was based solely on multicast messages, which, unlike NTP, did not require
	NTP did not require that a receiving node in	that a receiving node as discussed in <xref target="IEEE1588-2019" format=
	<xref target="IEEE1588" format="default">IEEE 1588-2019</xref> need to know	"default">IEEE 1588-2019</xref> need to know the identities of the
	the identity	time sources in the network. This document describes clock roles and
	of the time sources in the network.	PTP Port states using the optional alternative terms "timeTransmitter"
	This document describes clock roles and PTP Port states using the optional	instead of "master" and "timeReceiver" instead of "slave", as defined in t
	alternative terms timeTransmitter, instead of master,	he
	and timeReceiver, instead of slave, as defined in the <xref target="IEEE158	<xref target="IEEE1588g" format="default">IEEE 1588g amendment</xref> to
	8g" format="default">IEEE 1588g</xref> amendment to <xref target="IEEE1588"	<xref target="IEEE1588-2019" format="default"></xref>.</t>
	format="default">IEEE 1588-2019</xref> . </t>	<t>The "Best TimeTransmitter Clock Algorithm" (<xref target="IEEE1588-2019
	<t>The "Best TimeTransmitter Clock Algorithm" (<xref target="IEEE1588" for	" format="default"></xref>, Subclause 9.3), a mechanism that
	mat="default">IEEE 1588-2019</xref> Subclause 9.3), a	all participating PTP nodes <bcp14>MUST</bcp14> follow, sets up strict rul
	mechanism that all participating PTP nodes MUST follow, set up	es for all
	strict rules for all members of a PTP domain to determine which	members of a PTP domain to determine which node <bcp14>MUST</bcp14> be the
	node MUST be the active reference time source (Grandmaster).	active
	Although the multicast communication model has advantages in	reference time source (Grandmaster). Although the multicast
	smaller networks, it complicated the application of PTP in larger	communication model has advantages in smaller networks, it complicated
	networks, for example in environments like IP based	the application of PTP in larger networks -- for example, in environments
	telecommunication networks or financial data centers. It is	like IP-based telecommunication networks or financial data centers. It
	considered inefficient that, even if the content of a message	is considered inefficient that, even if the content of a message applies
	applies only to one receiver, it is forwarded by the underlying	only to one receiver, the message is forwarded by the underlying network (
	network (IP) to all nodes, requiring them to spend network	IP) to
	bandwidth and other resources, such as CPU cycles, to drop the	all nodes, requiring them to spend network bandwidth and other
	message.</t>	resources, such as CPU cycles, to drop it.</t>
	<t>The third edition of the standard (IEEE 1588-2019) defines	<t>The third edition of the standard (IEEE 1588-2019) defines
	PTPv2.1 and includes the	PTPv2.1 and includes the

	possibility to use unicast communication between the PTP nodes in	possibility of using unicast communication between the PTP nodes in
	order to overcome the limitation of using multicast messages for	order to overcome the limitation of using multicast messages for

	the bi-directional information exchange between PTP nodes. The	the bidirectional information exchange between PTP nodes. The
	unicast approach avoided that. In PTP domains with a lot of nodes,	unicast approach avoided that. In PTP domains with a lot of nodes,
	devices had to throw away most of the received multicast	devices had to throw away most of the received multicast
	messages because they carried information for some other node.	messages because they carried information for some other node.

	The percent of PTP message that are discarded as irrelevant to the receving	The percent of PTP messages that are discarded as irrelevant to the receivi
	node can exceded 99%	ng node can exceed 99%
	(<xref target="Estrela_and_Bonebakker" format="default">Estrela and Bonebak	<xref target="Estrela_and_Bonebakker" format="default"/>.
	ker</xref>).</t>
	<t>PTPv2.1 also includes PTP Profiles (<xref target="IEEE1588" format="def	<!-- [rfced] Section 1: We could not find any instances of "%",
	ault">IEEE 1588-2019</xref> subclause 20.3).	"99", "nine", "percent", "per cent", "per-cent", "cent", "discard",
	This construct allows organizations to specify selections of	"exceed", or "relevant" in [Estrela_and_Bonebakker]. Please confirm
		that the text is correct and will be clear to readers when they
		consult [Estrela_and_Bonebakker].

		Original ("receving" and "exceded" have been corrected):
		The
		percent of PTP message that are discarded as irrelevant to the
		receving node can exceded 99% (Estrela and Bonebakker
		[Estrela_and_Bonebakker]). -->

		</t>
		<t>PTPv2.1 also includes PTP Profiles (<xref target="IEEE1588-2019" format
		="default"></xref>, Subclause 20.3).
		These constructs allow organizations to specify selections of
	attribute values and optional features, simplifying the	attribute values and optional features, simplifying the
	configuration of PTP nodes for a specific application. Instead of	configuration of PTP nodes for a specific application. Instead of
	having to go through all possible parameters and configuration	having to go through all possible parameters and configuration
	options and individually set them up, selecting a PTP Profile on a PTP	options and individually set them up, selecting a PTP Profile on a PTP
	node will set all the parameters that are specified in the PTP Profile	node will set all the parameters that are specified in the PTP Profile
	to a defined value. If a PTP Profile definition allows multiple	to a defined value. If a PTP Profile definition allows multiple
	values for a parameter, selection of the PTP Profile will set the	values for a parameter, selection of the PTP Profile will set the
	profile-specific default value for this parameter. Parameters not	profile-specific default value for this parameter. Parameters not
	allowing multiple values are set to the value defined in the PTP	allowing multiple values are set to the value defined in the PTP
	Profile. Many PTP features and functions are optional, and a	Profile. Many PTP features and functions are optional, and a
	PTP Profile should also define which optional features of PTP are	PTP Profile should also define which optional features of PTP are
	required, permitted, and prohibited. It is possible to extend the	required, permitted, and prohibited. It is possible to extend the
	PTP standard with a PTP Profile by using the TLV mechanism of PTP	PTP standard with a PTP Profile by using the TLV mechanism of PTP

	(see <xref target="IEEE1588" format="default">IEEE 1588-2019</xref> subclau	(see <xref target="IEEE1588-2019" format="default"></xref>, Subclause 13.4)
	se 13.4),	,
	defining an optional Best TimeTransmitter Clock Algorithm and a few other w	defining an optional Best TimeTransmitter Clock Algorithm, and a few other
	ays.	ways.
	PTP has its own management protocol (defined in	PTP has its own management protocol (defined in

	<xref target="IEEE1588" format="default">IEEE 1588-2019</xref> subclause 15	<xref target="IEEE1588-2019" format="default"></xref>, Subclause 15.2) but
	.2) but	allows a PTP Profile to specify an alternative management mechanism --
	allows a PTP Profile to specify an alternative management mechanism,	for example, the Network Configuration Protocol (NETCONF).</t>
	for example NETCONF.</t>	<t> In this document, the term "PTP Port" refers to a logical access point
	<t> In this document the term PTP Port refers to a logical access point of	of a PTP instantiation for PTP communication in a network.
	a PTP instantiation for PTP communincation in a network. </t>
		<!-- [rfced] Section 1: We find "and a few other ways" a bit
		confusing. If the suggested text is not correct, please clarify the
		text.

		Original:
		It is possible to extend
		the PTP standard with a PTP Profile by using the TLV mechanism of PTP
		(see IEEE 1588-2019 [IEEE1588] subclause 13.4), defining an optional
		Best TimeTransmitter Clock Algorithm and a few other ways.

		Suggested:
		It is possible to extend
		the PTP standard with a PTP Profile by using the TLV mechanism of PTP
		(see [IEEE1588-2019], Subclause 13.4) or defining an optional Best
		TimeTransmitter Clock Algorithm, among other techniques (which are
		beyond the scope of this document). -->

		</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Requirements Language</name>	<name>Requirements Language</name>

	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as	"<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
	described in BCP 14 <xref target="RFC2119" format="default">RFC 2119 </xref>	"<bcp14>SHOULD NOT</bcp14>",
	<xref target="RFC8174" format="default">RFC 8174</xref> when, and only when, th	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	ey	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document
	appear in all capitals, as shown here.</t>	are to be interpreted as described in BCP 14
		<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only
		when, they appear in all capitals, as shown here.</t>
	</section>	</section>
	<section anchor="technical_terms" numbered="true" toc="default">	<section anchor="technical_terms" numbered="true" toc="default">
	<name>Technical Terms</name>	<name>Technical Terms</name>

	<ul spacing="normal">	<dl spacing="normal" newline="false">
	<li>Acceptable TimeTransmitter Table: A PTP timeReceiver Clock may maint	<dt>Acceptable TimeTransmitter Table:</dt><dd>A list of timeTransmitters
	ain a list of	that
	timeTransmitters which it is willing to synchronize to.</li>	may be maintained by a PTP timeReceiver Clock. The PTP timeReceiver Clock would
	<li>Alternate timeTransmitter: A PTP timeTransmitter Clock, which is not	be willing to synchronize to timeTransmitters in this list.</dd>
	the Best	<dt>Alternate timeTransmitter:</dt><dd>A PTP timeTransmitter Clock, whic
	timeTransmitter, may act as a timeTransmitter with the Alternate timeT	h is not the Best
	ransmitter flag set on	timeTransmitter, and may act as a timeTransmitter with the Alternate t
	the messages it sends.</li>	imeTransmitter flag set on
	<li>Announce message: Contains the timeTransmitter Clock properties of a	the messages it sends.
	timeTransmitter
	Clock. Used to determine the Best TimeTransmitter.</li>	<!-- [rfced] Section 3: Does this definition indicate that a PTP
	<li>Best timeTransmitter: A clock with a PTP Port in the timeTransmitte	timeTransmitter Clock is never the Best timeTransmitter, or does it
	r state, operating	indicate that some PTP timeTransmitter Clocks might not be the
	as the Grandmaster of a PTP domain.</li>	Best timeTransmitter (in which case "which" should be "that")?
	<li>Best TimeTransmitter Clock Algorithm: A method for determining which
	state	Original:
		* Alternate timeTransmitter: A PTP timeTransmitter Clock, which is
		not the Best timeTransmitter, may act as a timeTransmitter with
		the Alternate timeTransmitter flag set on the messages it sends.

		Possibly (updated to achieve parallelism in the list):
		Alternate timeTransmitter: A PTP timeTransmitter Clock that is not
		the Best timeTransmitter and therefore is used as an alternative
		clock. It may act as a timeTransmitter with the Alternate
		timeTransmitter flag set on the messages it sends. -->

		</dd>
		<dt>Announce message:</dt><dd>Contains the timeTransmitter Clock propert
		ies of a timeTransmitter
		Clock. The information is used to determine the Best TimeTransmitter.

		<!-- [rfced] Section 3: "timeTransmitter Clock properties of a
		timeTransmitter Clock" reads oddly. Should the wording be different?
		If the suggested text is not correct, please clarify.

		Original:
		* Announce message: Contains the timeTransmitter Clock properties of
		a timeTransmitter Clock. Used to determine the Best
		TimeTransmitter.

		Suggested:
		Announce message: Contains the properties of a given
		timeTransmitter Clock. The information is used to determine the
		Best TimeTransmitter. -->

		</dd>
		<dt>Best timeTransmitter:</dt><dd>A clock with a PTP Port in the timeTra
		nsmitter state, operating
		as the Grandmaster of a PTP domain.</dd>
		<dt>Best TimeTransmitter Clock Algorithm:</dt><dd>A method for determini
		ng which state
	a PTP Port of a PTP clock should be in. The state decisions lead to t he formation of a clock spanning tree	a PTP Port of a PTP clock should be in. The state decisions lead to t he formation of a clock spanning tree

	for a PTP domain. </li>	for a PTP domain.</dd>
	<li>Boundary Clock: A device with more than one PTP Port. Generally	<dt>Boundary Clock:</dt><dd>A device with more than one PTP Port. Gener
	Boundary Clocks will have one PTP Port in timeReceiver state to receiv	ally,
	e	Boundary Clocks will have one PTP Port in the timeReceiver state to re
	timing and other PTP Ports in timeTransmitter state to re-distribute t	ceive
	he	timing and other PTP Ports in the timeTransmitter state to redistribut
	timing.</li>	e the
	<li>Clock Identity: In IEEE 1588-2019 this is a 64-bit number	timing.</dd>
	assigned to each PTP clock which MUST be globally unique. Often it is	<dt>Clock Identity:</dt><dd>In <xref target="IEEE1588-2019"/>, a 64-bit
	derived from the Ethernet MAC address.</li>	number
	<li>Domain: Every PTP message contains a domain number. Domains are	assigned to each PTP clock. This number <bcp14>MUST</bcp14> be global
	treated as separate PTP systems in the network. Clocks, however,	ly unique. Often, it is
	can combine the timing information derived from multiple domains.</li>	derived from the Ethernet Media Access Control (MAC) address.</dd>
	<li>End-to-End delay measurement mechanism: A network delay	<dt>Domain:</dt><dd>Treated as a separate PTP system in a network. Every
		PTP message contains a domain number. Clocks, however,
		can combine the timing information derived from multiple domains.</dd>
		<dt>End-to-End delay measurement mechanism:</dt><dd>A network delay
	measurement mechanism in PTP facilitated by an exchange of	measurement mechanism in PTP facilitated by an exchange of
	messages between a timeTransmitter Clock and a timeReceiver Clock.	messages between a timeTransmitter Clock and a timeReceiver Clock.

	These messages might traverse Transparent Clocks and PTP unaware switc	These messages might traverse Transparent Clocks and PTP-unaware switc
	hes.	hes.
	This mechanism might not work properly if the Sync and Delay Request m	This mechanism might not work properly if the Sync and Delay Request m
	essages traverse different network paths.</li>	essages traverse different network paths.</dd>
	<li>Grandmaster: the timeTransmitter Clock that is currently acting as t	<dt>Grandmaster:</dt><dd>The timeTransmitter Clock that is currently act
	he reference time source of the PTP domain</li>	ing as the reference time source of the PTP domain.</dd>
	<li>IEEE 1588: The timing and synchronization standard which defines	<dt>IEEE 1588:</dt><dd>The timing and synchronization standard that defi
	PTP, and describes the node, system, and communication properties	nes
	necessary to support PTP.</li>	PTP and describes the node, system, and communication properties
	<li>TimeTransmitter Clock: a clock with at least one PTP Port in the tim	necessary to support PTP.</dd>
	eTransmitter state.</li>	<dt>NTP:</dt><dd>Network Time Protocol, defined by <xref target="RFC5905
	<li>NTP: Network Time Protocol, defined by RFC 5905, see <xref target="R	" format="default"/>.</dd>
	FC5905" format="default">RFC 5905</xref></li>	<dt>Ordinary Clock:</dt><dd>A clock that has a single
	<li>Ordinary Clock: A clock that has a single Precision Time Protocol
	PTP Port in a domain and maintains the timescale used in the	PTP Port in a domain and maintains the timescale used in the

	domain. It may serve as a timeTransmitter Clock, or be a timeReceiver	domain. It may serve as a timeTransmitter Clock or may be a timeReceiv
	Clock.</li>	er Clock.</dd>
	<li>Peer-to-Peer delay measurement mechanism: A network delay	<dt>Peer-to-Peer delay measurement mechanism:</dt><dd>A network delay
	measurement mechanism in PTP facilitated by an exchange of	measurement mechanism in PTP facilitated by an exchange of
	messages over the link between adjacent devices in a network.	messages over the link between adjacent devices in a network.

	This mechanism might not work properly unless all devices in the netwo	This mechanism might not work properly unless all devices in the netwo
	rk support PTP and the Peer-to-peer measurement mechanism.</li>	rk support PTP and the Peer-to-peer measurement mechanism.</dd>
	<li>Preferred timeTransmitter: A device intended to act primarily as the	<dt>Preferred timeTransmitter:</dt><dd>A device intended to act primaril
	Grandmaster of a PTP system, or as a back up to a Grandmaster.</li>	y as the
	<li>PTP: The Precision Time Protocol: The timing and synchronization	Grandmaster of a PTP system or as a backup to a Grandmaster.</dd>
	protocol defined by IEEE 1588.</li>	<dt>PTP:</dt><dd>The Precision Time Protocol -- the timing and synchroni
	<li>PTP Port: An interface of a PTP clock with the network. Note that	zation
	there may be multiple PTP Ports running on one physical interface,	protocol defined by IEEE 1588.</dd>
	for example, mulitple unicast timeReceivers which talk to several Gran	<dt>PTP Port:</dt><dd>An interface of a PTP clock with the network. Not
	dmaster	e that
	Clocks in different PTP Domains.</li>	there may be multiple PTP Ports running on one physical interface --
	<li>PTP Profile: A set of constraints on the options and features of P	for example, multiple unicast timeReceivers that talk to several Grand
	TP,	master
		Clocks in different PTP Domains.</dd>
		<dt>PTP Profile:</dt><dd>A set of constraints on the options and featu
		res of PTP,
	designed to optimize PTP for a specific use case or industry.	designed to optimize PTP for a specific use case or industry.

	The profile specifies what is required, allowed and forbidden among op	The profile specifies what is required, allowed, and forbidden among o
	tions and attribute values of PTP.</li>	ptions and attribute values of PTP.</dd>
	<li>PTPv2.1: Refers specifically to the version of PTP defined by	<dt>PTPv2.1:</dt><dd>Refers specifically to the version of PTP defined b
	IEEE 1588-2019.</li>	y
	<li>Rogue timeTransmitter: A clock with a PTP Port in the timeTransmitte	<xref target="IEEE1588-2019"/>.</dd>
	r state, even though	<dt>Rogue timeTransmitter:</dt><dd>A clock with a PTP Port in the timeTr
		ansmitter state, even though
	it should not be in the timeTransmitter state according to the Best Ti meTransmitter	it should not be in the timeTransmitter state according to the Best Ti meTransmitter

	Clock Algorithm, and does not set the Alternate timeTransmitter flag.<	Clock Algorithm, and does not set the Alternate timeTransmitter flag.
	/li>
	<li>TimeReceiver Clock: a clock with at least one PTP Port in the timeRe	<!-- [rfced] Section 3: This sentence does not parse. If the
	ceiver state,	suggested text is not correct, please clarify "and does not set".
	and no PTP Ports in the timeTransmitter state.</li>
	<li>TimeReceiver Only clock: An Ordinary Clock which cannot become a tim	Original:
	eTransmitter	* Rogue timeTransmitter: A clock with a PTP Port in the
	Clock.</li>	timeTransmitter state, even though it should not be in the
	<li>TLV: Type Length Value, a mechanism for extending messages in	timeTransmitter state according to the Best TimeTransmitter Clock
	networked communications.</li>	Algorithm, and does not set the Alternate timeTransmitter flag.
	<li>Transparent Clock. A device that measures the time taken for a
		Suggested:
		Rogue timeTransmitter: A clock that has a PTP Port in the
		timeTransmitter state - even though it should not be in the
		timeTransmitter state according to the Best TimeTransmitter Clock
		Algorithm - and that does not set the Alternate timeTransmitter
		flag. -->

		</dd>
		<dt>TimeReceiver Clock:</dt><dd>A clock with at least one PTP Port in th
		e timeReceiver state
		and no PTP Ports in the timeTransmitter state.</dd>
		<dt>TimeReceiver Only clock:</dt><dd>An Ordinary Clock that cannot becom
		e a timeTransmitter
		Clock.</dd>
		<dt>TimeTransmitter Clock:</dt><dd>A clock with at least one PTP Port in
		the timeTransmitter state.</dd>
		<dt>TLV:</dt><dd>Type Length Value -- a mechanism for extending messages
		in
		networked communications.</dd>
		<dt>Transparent Clock:</dt><dd>A device that measures the time taken for
		a
	PTP event message to transit the device and then updates the	PTP event message to transit the device and then updates the

	message with a correction for this transit time.</li>	message with a correction for this transit time.</dd>
	<li>Unicast Discovery: A mechanism for PTP timeReceivers to establish a	<dt>Unicast Discovery:</dt><dd>A mechanism for PTP timeReceivers to esta
		blish a
	unicast communication with PTP timeTransmitters using a configured tab le of	unicast communication with PTP timeTransmitters using a configured tab le of

	timeTransmitter IP addresses and Unicast Message Negotiation.</li>	timeTransmitter IP addresses and Unicast Message Negotiation.</dd>
	<li>Unicast Negotiation: A mechanism in PTP for timeReceiver Clocks to	<dt>Unicast Negotiation:</dt><dd>A mechanism in PTP for timeReceiver Clo
	negotiate unicast Sync, Announce and Delay Request message transmissio	cks to
	n rates	negotiate unicast Sync, Announce, and Delay Request message transmissi
	from timeTransmitters.</li>	on rates
	</ul>	from timeTransmitters.</dd>
		</dl>

		<!-- [rfced] Section 3: Because this list was ordered alphabetically
		except for the "TimeTransmitter Clock:" entry, we moved the
		"TimeTransmitter Clock:" entry so that it appears between
		"TimeReceiver Only clock:" and "TLV:". Please let us know any
		objections.

		Original:
		...
		* IEEE 1588: The timing and synchronization standard which defines
		PTP, and describes the node, system, and communication properties
		necessary to support PTP.

		* TimeTransmitter Clock: a clock with at least one PTP Port in the
		timeTransmitter state.

		* NTP: Network Time Protocol, defined by RFC 5905, see RFC 5905
		[RFC5905]
		...
		* TimeReceiver Only clock: An Ordinary Clock which cannot become a
		timeTransmitter Clock.

		* TLV: Type Length Value, a mechanism for extending messages in
		networked communications.
		...

		Currently:
		...
		IEEE 1588: The timing and synchronization standard that defines PTP
		and describes the node, system, and communication properties
		necessary to support PTP.

		NTP: Network Time Protocol, defined by [RFC5905].
		...
		TimeReceiver Only clock: An Ordinary Clock that cannot become a
		timeTransmitter Clock.

		TimeTransmitter Clock: A clock with at least one PTP Port in the
		timeTransmitter state.

		TLV: Type Length Value. A mechanism for extending messages in
		networked communications.
		... -->

	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Problem Statement</name>	<name>Problem Statement</name>
	<t>This document describes how PTP can be applied to work in large	<t>This document describes how PTP can be applied to work in large

	enterprise networks. See <xref target="RFC2026" format="default">ISPCS</x ref> for information on IETF applicability statements.	enterprise networks. See ISPCS <xref target="RFC2026" format="default"/> for information on IETF applicability statements.
	Such large networks are deployed, for example, in	Such large networks are deployed, for example, in
	financial corporations. It is becoming increasingly common in such	financial corporations. It is becoming increasingly common in such

	networks to perform distributed time tagged measurements, such as	networks to perform distributed time-tagged measurements, such as
	one-way packet latencies and cumulative delays on software	one-way packet latencies and cumulative delays on software
	systems spread across multiple computers. Furthermore, there is	systems spread across multiple computers. Furthermore, there is

	often a desire to check the age of information time tagged by a	often a desire to check the age of information time-tagged by a
	different machine. To perform these measurements, it is necessary	different machine. To perform these measurements, it is necessary
	to deliver a common precise time to multiple devices on a network.	to deliver a common precise time to multiple devices on a network.

	Accuracy currently required in the Financial Industry range from	Accuracy currently required in the financial industry ranges from
	100 microseconds to 1 nanoseconds to the Grandmaster. This	100 microseconds to 1 nanosecond to the Grandmaster. This
	PTP Profile does not specify timing performance requirements, but such	PTP Profile does not specify timing performance requirements, but such

	requirements explain why the needs cannot always be met by NTP, as	requirements explain why the needs cannot always be met by NTP as
	commonly implemented. Such accuracy cannot usually be achieved with	commonly implemented. Such accuracy cannot usually be achieved with
	a traditional time transfer such as NTP, without adding	a traditional time transfer such as NTP, without adding
	non-standard customizations such as on-path support, similar to what is do ne in PTP with Transparent Clocks and Boundary Clocks.	non-standard customizations such as on-path support, similar to what is do ne in PTP with Transparent Clocks and Boundary Clocks.
	Such PTP support is commonly available in switches and routers, and many s uch devices have already been deployed in networks.	Such PTP support is commonly available in switches and routers, and many s uch devices have already been deployed in networks.
	Because PTP has a complex range of features and	Because PTP has a complex range of features and

	options it is necessary to create a PTP Profile for enterprise	options, it is necessary to create a PTP Profile for enterprise
	networks to achieve interoperability between equipment	networks to achieve interoperability among equipment
	manufactured by different vendors.</t>	manufactured by different vendors.

		<!-- [rfced] Section 4: "ISPCS" (International Symposium on
		Precision Clock Synchronization) does not appear to be relevant to
		RFC 2026. May we remove the abbreviation from this sentence, or are
		some words or an additional citation missing?

		Original:
		See ISPCS [RFC2026] for information on IETF
		applicability statements. -->

		</t>
	<t>Although enterprise networks can be large, it is becoming	<t>Although enterprise networks can be large, it is becoming
	increasingly common to deploy multicast protocols, even across	increasingly common to deploy multicast protocols, even across

	multiple subnets. For this reason, it is desired to make use of	multiple subnets. For this reason, it is desirable to make use of
	multicast whenever the information going to many destinations is	multicast whenever the information going to many destinations is

	the same. It is also advantageous to send information which is	the same. It is also advantageous to send information that is
	only relevant to one device as a unicast message. The latter can be	only relevant to one device as a unicast message. The latter can be
	essential as the number of PTP timeReceivers becomes hundreds or	essential as the number of PTP timeReceivers becomes hundreds or
	thousands.</t>	thousands.</t>
	<t>PTP devices operating in these networks need to be robust. This	<t>PTP devices operating in these networks need to be robust. This

	includes the ability to ignore PTP messages which can be	includes the ability to ignore PTP messages that can be
	identified as improper, and to have redundant sources of time.</t>	identified as improper and to have redundant sources of time.</t>
	<t>Interoperability among independent implementations of this PTP	<t>Interoperability among independent implementations of this PTP

	Profile has been demonstrated at the ISPCS Plugfest <xref target="ISPCS" f ormat="default">ISPCS</xref>.</t>	Profile has been demonstrated at the <xref target="ISPCS" format="default" >International Symposium on Precision Clock Synchronization (ISPCS) Plugfest</xr ef>.</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Network Technology</name>	<name>Network Technology</name>

	<t>This PTP Profile MUST operate only in networks characterized by	<t>This PTP Profile <bcp14>MUST</bcp14> operate only in networks character
	UDP <xref target="RFC0768" format="default">RFC 768</xref> over either IPv	ized by
	4	UDP <xref target="RFC0768" format="default"></xref> over either IPv4
	<xref target="RFC0791" format="default">RFC 791</xref> or IPv6 <xref targe	<xref target="RFC0791" format="default"></xref> or IPv6 <xref target="RFC8
	t="RFC8200" format="default">RFC 8200</xref>,	200" format="default"></xref>,
	as described by Annexes C and D in <xref target="IEEE1588" format="default	as described by Annexes C and D of <xref target="IEEE1588-2019" format="de
	">IEEE 1588</xref> respectively.	fault"></xref>, respectively.
	A network node MAY include multiple PTP instances running simultaneously.	A network node <bcp14>MAY</bcp14> include multiple PTP instances running s
	IPv4 and IPv6 instances in the same network node MUST operate in different	imultaneously.
	PTP Domains.	IPv4 and IPv6 instances in the same network node <bcp14>MUST</bcp14> opera
	PTP Clocks which communicate using IPv4	te in different PTP Domains.
	can transfer time to PTP Clocks using IPv6, or the reverse, if and only if	PTP Clocks that communicate using IPv4
	, there is a network node	can transfer time to PTP Clocks using IPv6, or the reverse, if and only if
	which simultaneously communicates with both PTP domains in the different I	there is a network node
	P versions.</t>	that simultaneously communicates with both PTP domains in the different IP
	<t> The PTP system MAY include switches and routers.	versions.
	These devices MAY be Transparent Clocks, Boundary Clocks, or
	neither, in any combination. PTP Clocks MAY be Preferred timeTransmitters	<!-- [rfced] Sections 5, 6, 8, 9, 12, and 14: Because it appears
	,	that, per citations in Sections 1 and 17, the instances of
		"IEEE 1588 [IEEE1588]" also refer to IEEE 1588-2019, we updated these
		sentences accordingly and also changed the citation string from
		"[IEEE1588]" to "[IEEE1588-2019]".

		Side topic: Please note that because IEEE 1588-2019 is behind a
		paywall or login setup, we cannot verify the specified annexes or
		subclauses. Please review our citation-string updates carefully, and
		let us know if anything is incorrect.

		Original:
		This PTP Profile MUST operate only in networks characterized by UDP
		RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200
		[RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588]
		respectively.
		...
		The different IPv6 address options
		are explained in IEEE 1588 IEEE 1588 [IEEE1588] Annex D, Section D.3.
		...
		TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter
		Clock Algorithm from IEEE 1588 [IEEE1588].
		...
		See IEEE 1588
		[IEEE1588], subClause 11.2.
		...
		Management messages intended
		for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute
		targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent
		as a unicast message.
		...
		Clocks operating in the Enterprise Profile will interoperate with
		clocks operating in the Default Profile described in IEEE 1588
		[IEEE1588] Annex I.3.

		Currently:
		This PTP Profile MUST operate only in networks characterized by UDP
		[RFC0768] over either IPv4 [RFC0791] or IPv6 [RFC8200], as described
		by Annexes C and D of [IEEE1588-2019], respectively.
		...
		The different IPv6 address options
		are explained in [IEEE1588-2019], Annex D, Section D.3.
		...
		TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter
		Clock Algorithm as defined in [IEEE1588-2019].
		...
		See [IEEE1588-2019],
		Subclause 11.2.
		...
		Management messages intended
		for a specific clock, i.e., where the
		targetPortIdentity.clockIdentity attribute (defined in
		[IEEE1588-2019]) is not set to All 1s, MUST be sent as a unicast
		message.
		...
		Clocks operating in the Enterprise Profile will interoperate with
		clocks operating in the Default Profile described in [IEEE1588-2019],
		Annex I.3. -->

		</t>
		<t> The PTP system <bcp14>MAY</bcp14> include switches and routers.
		These devices <bcp14>MAY</bcp14> be Transparent Clocks, Boundary Clocks, o
		r
		neither, in any combination. PTP Clocks <bcp14>MAY</bcp14> be Preferred t
		imeTransmitters,
	Ordinary Clocks, or Boundary Clocks. The Ordinary Clocks may be	Ordinary Clocks, or Boundary Clocks. The Ordinary Clocks may be

	TimeReceiver Only Clocks, or be timeTransmitter capable.</t>	TimeReceiver Only Clocks or may be timeTransmitter capable.</t>
	<t>Note that PTP Ports will need to keep tack of the Clock ID of received	<t>Note that PTP Ports will need to keep track of the Clock ID of received
	messages and	messages and
	not just the IP or Layer 2 addresses in any network that includes Transpar	not just the IP or Layer 2 addresses in any network that includes Transpar
	ent Clocks, or might include them in the future.	ent Clocks or that might include them in the future.
	This is important	This is important,
	since Transparent Clocks might treat PTP messages that are altered at the PTP application layer	since Transparent Clocks might treat PTP messages that are altered at the PTP application layer

	as new IP packets and new Layer 2 frames when the PTP messages are retranm	as new IP packets and new Layer 2 frames when the PTP messages are retrans
	itted.	mitted.
	In IPv4 networks some clocks	In IPv4 networks, some clocks
	might be hidden behind a NAT, which hides their IP addresses from	might be hidden behind a NAT, which hides their IP addresses from
	the rest of the network. Note also that the use of NATs may place	the rest of the network. Note also that the use of NATs may place
	limitations on the topology of PTP networks, depending on the port	limitations on the topology of PTP networks, depending on the port
	forwarding scheme employed. Details of implementing PTP with NATs	forwarding scheme employed. Details of implementing PTP with NATs

	are out of scope of this document.</t>	are out of scope for this document.</t>
	<t>PTP, similar to NTP, assumes that the one-way network delay for Sync	<t>PTP, similar to NTP, assumes that the one-way network delay for Sync

	messages and Delay Response messages are the same. When this is	messages and Delay Response messages is the same. When this is
	not true it can cause errors in the transfer of time from the	not true, it can cause errors in the transfer of time from the
	timeTransmitter to the timeReceiver. It is up to the system integrator to design	timeTransmitter to the timeReceiver. It is up to the system integrator to design
	the network so that such effects do not prevent the PTP system	the network so that such effects do not prevent the PTP system
	from meeting the timing requirements. The details of network asymmetry	from meeting the timing requirements. The details of network asymmetry

	are outside the scope of this document. See for	are outside the scope of this document. See, for
	example, <xref target="G8271" format="default">ITU-T G.8271</xref>.</t>	example, <xref target="G8271" format="default">ITU-T G.8271</xref>.

		<!-- [rfced] Section 5: We found this "for example" sentence a bit
		misleading in the context of network asymmetry being outside the
		scope of this document. May we clarify by updating as suggested?

		Original (the previous sentence is included for context):
		The details of
		network asymmetry are outside the scope of this document. See for
		example, ITU-T G.8271 [G8271].

		Suggested:
		See ITU-T G.8271 [G8271] for details regarding network asymmetry. -->

		</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Time Transfer and Delay Measurement</name>	<name>Time Transfer and Delay Measurement</name>

	<t>TimeTransmitter Clocks, Transparent Clocks and Boundary Clocks MAY be	<t>TimeTransmitter Clocks, Transparent Clocks, and Boundary Clocks <bcp14>
	either one-step clocks or two-step clocks. TimeReceiver Clocks MUST	MAY</bcp14> be
		either one-step clocks or two-step clocks. TimeReceiver Clocks <bcp14>MUST<
		/bcp14>
	support both behaviors. The End-to-End Delay measurement method	support both behaviors. The End-to-End Delay measurement method

	MUST be used.</t>	<bcp14>MUST</bcp14> be used.</t>
	<t>Note that, in IP networks, Sync messages and Delay Request	<t>Note that, in IP networks, Sync messages and Delay Request
	messages exchanged between a timeTransmitter and timeReceiver do not necessa rily	messages exchanged between a timeTransmitter and timeReceiver do not necessa rily
	traverse the same physical path. Thus, wherever possible, the	traverse the same physical path. Thus, wherever possible, the

	network SHOULD be engineered so that the forward and	network <bcp14>SHOULD</bcp14> be engineered so that the forward and
	reverse routes traverse the same physical path. Traffic	reverse routes traverse the same physical path. Traffic

	engineering techniques for path consistency are out of scope of	engineering techniques for path consistency are out of scope for
	this document.</t>	this document.</t>

	<t>Sync messages MUST be sent as PTP event multicast messages (UDP	<t>Sync messages <bcp14>MUST</bcp14> be sent as PTP event multicast messag
	port 319) to the PTP primary IP address. Two step clocks MUST	es (UDP
		port 319) to the PTP primary IP address. Two-step clocks <bcp14>MUST</bcp1
		4>
	send Follow-up messages as PTP general multicast messages (UDP port 320).	send Follow-up messages as PTP general multicast messages (UDP port 320).

	Announce messages MUST be sent as multicast messages (UDP port 320)	Announce messages <bcp14>MUST</bcp14> be sent as multicast messages (UDP por t 320)
	to the PTP primary address. The PTP primary IP address is	to the PTP primary address. The PTP primary IP address is

	224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for IPv6, where X can	224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for IPv6, where "X" can
	be a value between 0x0 and 0xF. The different IPv6 address options are expla	be a value between 0x0 and 0xF. The different IPv6 address options are expla
	ined in IEEE 1588	ined in
	<xref target="IEEE1588" format="default">IEEE 1588</xref> Annex D, Section D	<xref target="IEEE1588-2019" format="default"></xref>, Annex D, Section D.3.
	.3.	These addresses are allotted by IANA; see the <xref target="IPv6Registry" fo
	These addresses are aloted by IANA, see the <xref target="IPv6Registry" form	rmat="default">"IPv6 Multicast Address Space Registry"</xref>.
	at="default">Ipv6 Multicast Address Space Registry</xref></t>
	<t>Delay Request messages MAY be sent as either multicast or unicast	<!-- [rfced] Section 6: Because this sentence indicates a
	PTP event messages. TimeTransmitter Clocks MUST respond to multicast Delay	requirement and we see that PTP messages can be either event
		multicast messages or general multicast messages, would you like to
		be more specific and confirm that "UDP port 320" is correct here?

		Original:
		Announce messages MUST be sent as multicast messages (UDP port 320)
		to the PTP primary address.

		Suggested:
		Announce messages MUST also be sent as PTP general multicast
		messages (UDP port 320) to the PTP primary address. -->

		</t>
		<t>Delay Request messages <bcp14>MAY</bcp14> be sent as either multicast o
		r unicast
		PTP event messages. TimeTransmitter Clocks <bcp14>MUST</bcp14> respond to mu
		lticast Delay
	Request messages with multicast Delay Response PTP general	Request messages with multicast Delay Response PTP general

	messages. TimeTransmitter Clocks MUST respond to unicast Delay Request PTP	messages. TimeTransmitter Clocks <bcp14>MUST</bcp14> respond to unicast Dela y Request PTP
	event messages with unicast Delay Response PTP general messages.	event messages with unicast Delay Response PTP general messages.

	This allows for the use of Ordinary Clocks which do not support the	This allows for the use of Ordinary Clocks that do not support the
	Enterprise Profile, if they are timeReceiver Only Clocks.</t>	Enterprise Profile, if they are timeReceiver Only Clocks.</t>

	<t>Clocks SHOULD include support for multiple domains. The purpose is	<t>Clocks <bcp14>SHOULD</bcp14> include support for multiple domains. The purpose is
	to support multiple simultaneous timeTransmitters for redundancy. Leaf	to support multiple simultaneous timeTransmitters for redundancy. Leaf
	devices (non-forwarding devices) can use timing information from	devices (non-forwarding devices) can use timing information from
	multiple timeTransmitters by combining information from multiple	multiple timeTransmitters by combining information from multiple
	instantiations of a PTP stack, each operating in a different	instantiations of a PTP stack, each operating in a different

	PTP Domain. Redundant sources of timing can be ensembled, and/or	PTP Domain. Redundant sources of timing can be ensembled and/or
	compared to check for faulty timeTransmitter Clocks. The use of multiple	compared to check for faulty timeTransmitter Clocks. The use of multiple
	simultaneous timeTransmitters will help mitigate faulty timeTransmitters rep orting as	simultaneous timeTransmitters will help mitigate faulty timeTransmitters rep orting as
	healthy, network delay asymmetry, and security problems. Security	healthy, network delay asymmetry, and security problems. Security
	problems include on-path attacks such as delay attacks,	problems include on-path attacks such as delay attacks,

	packet interception / manipulation attacks. Assuming the path to	packet interception/manipulation attacks. Assuming that the path to
	each timeTransmitter is different, failures malicious or otherwise would	each timeTransmitter is different, failures -- malicious or otherwise -- wou
		ld
	have to happen at more than one path simultaneously. Whenever	have to happen at more than one path simultaneously. Whenever

	feasible, the underlying network transport technology SHOULD be	feasible, the underlying network transport technology <bcp14>SHOULD</bcp14> be
	configured so that timing messages in different domains traverse	configured so that timing messages in different domains traverse

	different network paths.</t>	different network paths.

		<!-- [rfced] Section 6: We could not find a dictionary definition of
		"ensemble(d)" used as a verb. If the suggested text is not correct,
		please clarify.

		Original:
		Redundant sources of timing can be ensembled, and/or
		compared to check for faulty timeTransmitter Clocks.

		Suggested:
		To check for faulty timeTransmitter Clocks, redundant sources of
		timing can be evaluated as an ensemble and/or compared individually. -->

		<!-- [rfced] Section 6: Does "such as delay attacks, packet
		interception / manipulation attacks" mean "such as delay attacks,
		packet interception attacks, and packet manipulation attacks" or
		something else? Please clarify the text.

		Original:
		Security problems include on-path attacks such as
		delay attacks, packet interception / manipulation attacks. -->

		</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Default Message Rates</name>	<name>Default Message Rates</name>

	<t>The Sync, Announce, and Delay Request default message rates MUST	<t>The Sync, Announce, and Delay Request default message rates <bcp14>MUST </bcp14>
	each be once per second. The Sync and Delay Request message rates	each be once per second. The Sync and Delay Request message rates

	MAY be set to other values, but not less than once every 128	<bcp14>MAY</bcp14> be set to other values, but not less than once every 128
	seconds, and not more than 128 messages per second. The Announce	seconds and not more than 128 messages per second. The Announce
	message rate MUST NOT be changed from the default value. The	message rate <bcp14>MUST NOT</bcp14> be changed from the default value. The
	Announce Receipt Timeout Interval MUST be three Announce	Announce Receipt Timeout Interval <bcp14>MUST</bcp14> be three Announce
	Intervals for Preferred TimeTransmitters, and four Announce Intervals for	Intervals for Preferred TimeTransmitters and four Announce Intervals for
	all other timeTransmitters.</t>	all other timeTransmitters.</t>
	<t>The logMessageInterval carried in the unicast Delay Response	<t>The logMessageInterval carried in the unicast Delay Response

	message MAY be set to correspond to the timeTransmitter ports preferred	message <bcp14>MAY</bcp14> be set to correspond to the timeTransmitter ports
	message period, rather than 7F, which indicates message periods	preferred
		message period, rather than 7F, which indicates that message periods
	are to be negotiated. Note that negotiated message periods are not	are to be negotiated. Note that negotiated message periods are not

	allowed, see <xref target="forbidden_ptp_options" format="default">forbidden	allowed; see <xref target="forbidden_ptp_options"/> ("<xref target="forbidde
	PTP	n_ptp_options" format="title"/>").
	options</xref>.</t>
		<!-- [rfced] Section 7: Does "the timeTransmitter ports preferred
		message period" mean "the timeTransmitter ports' preferred message
		period", "the preferred message period for timeTransmitter ports",
		or something else? Please clarify.

		Original:
		The logMessageInterval carried in the unicast Delay Response message
		MAY be set to correspond to the timeTransmitter ports preferred
		message period, rather than 7F, which indicates message periods are
		to be negotiated. -->

		</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Requirements for TimeTransmitter Clocks</name>	<name>Requirements for TimeTransmitter Clocks</name>

	<t>TimeTransmitter Clocks MUST obey the standard Best TimeTransmitter Cloc	<t>TimeTransmitter Clocks <bcp14>MUST</bcp14> obey the standard Best TimeT
	k Algorithm	ransmitter Clock Algorithm
	from <xref target="IEEE1588" format="default">IEEE 1588</xref>. PTP systems	as defined in <xref target="IEEE1588-2019" format="default"></xref>. PTP sy
	using this PTP Profile MAY support	stems using this PTP Profile <bcp14>MAY</bcp14> support
	multiple simultaneous Grandmasters if each active Grandmaster is	multiple simultaneous Grandmasters if each active Grandmaster is
	operating in a different PTP domain.</t>	operating in a different PTP domain.</t>

	<t>A PTP Port of a clock MUST NOT be in the timeTransmitter state unless t he	<t>A PTP Port of a clock <bcp14>MUST NOT</bcp14> be in the timeTransmitter state unless the
	clock has a current value for the number of UTC leap	clock has a current value for the number of UTC leap
	seconds.</t>	seconds.</t>

	<t>If a unicast negotiation signaling message is received it MUST	<t>If a unicast negotiation signaling message is received, it <bcp14>MUST< /bcp14>
	be ignored.</t>	be ignored.</t>

	<t>In PTP Networks that contain Transparent Clocks, timeTransmitters might r eceive Delay Request messages that no longer contains the IP Addresses of the ti meReceivers.	<t>In PTP Networks that contain Transparent Clocks, timeTransmitters might r eceive Delay Request messages that no longer contain the IP addresses of the tim eReceivers.
	This is because Transparent Clocks might replace the IP address of Delay Req uests	This is because Transparent Clocks might replace the IP address of Delay Req uests

	with their own IP address after updating the Correction Fields. For this de ployment scenario timeTransmitters will need to have configured tables of timeRe ceivers' IP addresses	with their own IP address after updating the Correction Fields. For this de ployment scenario, timeTransmitters will need to have configured tables of timeR eceivers' IP addresses
	and associated Clock Identities in order to send Delay Responses to the corr ect PTP Nodes.</t>	and associated Clock Identities in order to send Delay Responses to the corr ect PTP Nodes.</t>
	</section>	</section>

	<section numbered="true" toc="default">	<section numbered="true" toc="default" anchor="req-timereceiver-clocks">
	<name>Requirements for TimeReceiver Clocks</name>	<name>Requirements for TimeReceiver Clocks</name>

	<t>In a network which contains multiple timeTransmitters in multiple domains	<t>In a network that contains multiple timeTransmitters in multiple domains,
	,	TimeReceivers <bcp14>SHOULD</bcp14> make use of information from all the tim
	TimeReceivers SHOULD make use of information from all the timeTransmitters i	eTransmitters in their clock control subsystems.
	n their clock control subsystems.	TimeReceiver Clocks <bcp14>MUST</bcp14> be able to function in such networks
	TimeReceiver Clocks MUST be able to function in such networks even if they u	even if they use time from only one of the domains.
	se time from only one of the domains.	TimeReceiver Clocks <bcp14>MUST</bcp14> be able to operate properly in the
	TimeReceiver Clocks MUST be able to operate properly in the	presence of a rogue timeTransmitter. TimeReceivers <bcp14>SHOULD NOT</bcp14>
	presence of a rogue timeTransmitter. TimeReceivers SHOULD NOT Synchronize to	synchronize to a
	a	timeTransmitter that is not the Best TimeTransmitter in its domain. TimeRece
	timeTransmitter which is not the Best TimeTransmitter in its domain. TimeRec	ivers will
	eivers will
	continue to recognize a Best TimeTransmitter for the duration of the	continue to recognize a Best TimeTransmitter for the duration of the

	Announce Time Out Interval. TimeReceivers MAY use an Acceptable TimeTransmit ter	Announce Time Out Interval. TimeReceivers <bcp14>MAY</bcp14> use an Acceptab le TimeTransmitter
	Table. If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver	Table. If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver

	MUST NOT synchronize to it. Note that IEEE 1588-2019 requires	<bcp14>MUST NOT</bcp14> synchronize to it. Note that IEEE 1588-2019 requires
	timeReceiver Clocks to support both two-step or one-step timeTransmitter Clo	timeReceiver Clocks to support both two-step and one-step timeTransmitter Cl
	cks.	ocks.
	See <xref target="IEEE1588" format="default">IEEE 1588</xref>, subClause 11.	See <xref target="IEEE1588-2019" format="default"></xref>, Subclause 11.2.
	2.</t>
	<t>Since Announce messages are sent as multicast messages timeReceivers ca	<!-- [rfced] Section 9: Please confirm that "Announce Time Out
	n	Interval" is correct and is distinct from "Announce Receipt Timeout
		Interval" as mentioned in Section 7.

		Original:
		TimeReceivers will
		continue to recognize a Best TimeTransmitter for the duration of the
		Announce Time Out Interval. -->

		</t>
		<t>Since Announce messages are sent as multicast messages, timeReceivers c
		an
	obtain the IP addresses of a timeTransmitter from the Announce messages.	obtain the IP addresses of a timeTransmitter from the Announce messages.
	Note that the IP source addresses of Sync and Follow-up messages	Note that the IP source addresses of Sync and Follow-up messages
	might have been replaced by the source addresses of a Transparent	might have been replaced by the source addresses of a Transparent

	Clock, so, timeReceivers MUST send Delay Request messages to the IP	Clock; therefore, timeReceivers <bcp14>MUST</bcp14> send Delay Request messa ges to the IP
	address in the Announce message. Sync and Follow-up messages can	address in the Announce message. Sync and Follow-up messages can
	be correlated with the Announce message using the Clock ID, which	be correlated with the Announce message using the Clock ID, which
	is never altered by Transparent Clocks in this PTP Profile.</t>	is never altered by Transparent Clocks in this PTP Profile.</t>
	</section>	</section>

	<section numbered="true" toc="default">	<section numbered="true" toc="default" anchor="req-transparent-clocks">
	<name>Requirements for Transparent Clocks</name>	<name>Requirements for Transparent Clocks</name>

	<t>Transparent Clocks MUST NOT change the transmission mode of an	<t>Transparent Clocks <bcp14>MUST NOT</bcp14> change the transmission mode of an
	Enterprise Profile PTP message. For example, a Transparent Clock	Enterprise Profile PTP message. For example, a Transparent Clock

	MUST NOT change a unicast message to a multicast message.	<bcp14>MUST NOT</bcp14> change a unicast message to a multicast message.
	Transparent Clocks which syntonize to the timeTransmitter Clock might need t	Transparent Clocks that syntonize to the timeTransmitter Clock might need to
	o maintain	maintain
	separate clock rate offsets for each of the supported domains.</t>	separate clock rate offsets for each of the supported domains.

		<!-- [rfced] Section 10: Please confirm that "syntonize to" and not
		"synchronize to" is correct here. Does it mean "to put in resonance"
		or "tune" per <https://www.merriam-webster.com/dictionary/syntonize>?
		We ask because we see "synchronize to" used elsewhere in this
		document.

		Original:
		Transparent Clocks which syntonize to the timeTransmitter Clock might
		need to maintain separate clock rate offsets for each of the
		supported domains. -->

		</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Requirements for Boundary Clocks</name>	<name>Requirements for Boundary Clocks</name>

	<t>Boundary Clocks SHOULD support multiple simultaneous PTP domains.	<t>Boundary Clocks <bcp14>SHOULD</bcp14> support multiple simultaneous PTP domains.
	This will require them to maintain separate clocks for each of the	This will require them to maintain separate clocks for each of the

	domains supported, at least in software. Boundary Clocks MUST NOT	domains supported, at least in software. Boundary Clocks <bcp14>MUST NOT</b cp14>
	combine timing information from different domains.</t>	combine timing information from different domains.</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Management and Signaling Messages</name>	<name>Management and Signaling Messages</name>

	<t>PTP Management messages MAY be used. Management	<t>PTP Management messages <bcp14>MAY</bcp14> be used. Management
	messages intended for a specific clock, i.e. the <xref target="IEEE1588" for	messages intended for a specific clock, i.e., where the targetPortIdentity.c
	mat="default">IEEE 1588</xref> defined	lockIdentity attribute (defined in <xref target="IEEE1588-2019" format="default"
	attribute targetPortIdentity.clockIdentity is not set to All 1s,	></xref>) is not set to All 1s,
	MUST be sent as a unicast message. Similarly, if any signaling	<bcp14>MUST</bcp14> be sent as a unicast message. Similarly, if any signali
	messages are used they MUST also be sent as unicast messages	ng
	whenever the message is intended soley for a specific PTP Node.</t>	messages are used, they <bcp14>MUST</bcp14> also be sent as unicast messages
		whenever the message is intended solely for a specific PTP Node.

		<!-- [rfced] Section 12: Is "All 1s" an alphanumeric setting (i.e.,
		"targetPortIdentity.clockIdentity = All 1s") or some other format
		(perhaps a broadcast address)? If it is some other format, would it
		be helpful to update the text to something along the lines of our
		"Possibly" example below?

		Original:
		Management messages intended
		for a specific clock, i.e. the IEEE 1588 [IEEE1588] defined attribute
		targetPortIdentity.clockIdentity is not set to All 1s, MUST be sent
		as a unicast message.

		Possibly (using the all-1s MAC-address format mentioned in the
		definition of "Clock Identity" in Section 3):
		Management messages intended
		for a specific clock, i.e., where the
		targetPortIdentity.clockIdentity attribute (defined in
		[IEEE1588-2019]) is not set to all 1s (e.g., FF-FF-FF-FF-FF-FF),
		MUST be sent as a unicast message. -->

		</t>
	</section>	</section>
	<section anchor="forbidden_ptp_options" numbered="true" toc="default">	<section anchor="forbidden_ptp_options" numbered="true" toc="default">
	<name>Forbidden PTP Options</name>	<name>Forbidden PTP Options</name>

	<t>Clocks operating in the Enterprise Profile MUST NOT use:	<t>Clocks operating in the Enterprise Profile <bcp14>MUST NOT</bcp14> use
	Peer-to-Peer timing for delay measurement, Grandmaster Clusters, The Alterna	the following:</t>
	te TimeTransmitter option, Alternate Timescales.	<ul spacing="normal">
	Unicast discovery, or unicast negotiation.	<li>Peer-to-Peer timing for delay measurement</li>
	Clocks operating in the Enterprise Profile MUST avoid any optional feature t	<li>Grandmaster Clusters</li>
	hat requires Announce messages to be altered by Transparent Clocks,	<li>The Alternate TimeTransmitter option</li>
		<li>Alternate Timescales</li>
		<li>Unicast discovery</li>
		<li>Unicast negotiation</li>
		</ul>

		<!-- [rfced] Section 13: As originally written, it was not clear
		which options must not be used. We updated the text to use a list.
		Please review, and let us know if anything is incorrect. For
		example, if "Unicast discovery, or unicast negotiation" does not
		belong in the list, please provide the missing words for the
		incomplete sentence.

		Original:
		Clocks operating in the Enterprise Profile MUST NOT use: Peer-to-Peer
		timing for delay measurement, Grandmaster Clusters, The Alternate
		TimeTransmitter option, Alternate Timescales. Unicast discovery, or
		unicast negotiation.

		Currently:
		Clocks operating in the Enterprise Profile MUST NOT use the
		following:

		* Peer-to-Peer timing for delay measurement

		* Grandmaster Clusters

		* The Alternate TimeTransmitter option

		* Alternate Timescales

		* Unicast discovery

		* Unicast negotiation -->

		<t>Clocks operating in the Enterprise Profile <bcp14>MUST</bcp14> avoid any
		optional feature that requires Announce messages to be altered by Transparent Cl
		ocks,
	as this would require the Transparent Clock to change the source address and prevent the timeReceiver nodes	as this would require the Transparent Clock to change the source address and prevent the timeReceiver nodes
	from discovering the protocol address of the timeTransmitter.</t>	from discovering the protocol address of the timeTransmitter.</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Interoperation with IEEE 1588 Default Profile</name>	<name>Interoperation with IEEE 1588 Default Profile</name>
	<t>Clocks operating in the Enterprise Profile will interoperate with	<t>Clocks operating in the Enterprise Profile will interoperate with

	clocks operating in the Default Profile described in <xref target="IEEE1588" format="default">IEEE 1588</xref>	clocks operating in the Default Profile described in <xref target="IEEE1588- 2019" format="default"></xref>,
	Annex I.3. This variant of the Default Profile uses the End-to-End	Annex I.3. This variant of the Default Profile uses the End-to-End
	delay measurement mechanism. In addition, the Default Profile	delay measurement mechanism. In addition, the Default Profile

	would have to operate over IPv4 or IPv6 networks, and use	would have to operate over IPv4 or IPv6 networks and use
	management messages in unicast when those messages are directed at	management messages in unicast when those messages are directed at

	a specific clock. If either of these requirements are not met than	a specific clock. If neither of these requirements is met, then
	Enterprise Profile clocks will not interoperate with Annex I.3	Enterprise Profile clocks will not interoperate with
	Default Profile Clocks. The Enterprise Profile will not	Default Profile Clocks as defined in <xref target="IEEE1588-2019" format="de
	interoperate with the Annex I.4 variant of the Default Profile	fault"></xref>, Annex I.3. The Enterprise Profile will not
	which requires use of the Peer-to-Peer delay measurement mechanism.</t>	interoperate with the variant of the Default Profile defined in
		<xref target="IEEE1588-2019" format="default"></xref>, Annex I.4,
		which requires the use of the Peer-to-Peer delay measurement mechanism.</t>
	<t>Enterprise Profile Clocks will interoperate with clocks operating	<t>Enterprise Profile Clocks will interoperate with clocks operating
	in other PTP Profiles if the clocks in the other PTP Profiles obey the	in other PTP Profiles if the clocks in the other PTP Profiles obey the

	rules of the Enterprise Profile. These rules MUST NOT be changed	rules of the Enterprise Profile. These rules <bcp14>MUST NOT</bcp14> be cha nged
	to achieve interoperability with other PTP Profiles.</t>	to achieve interoperability with other PTP Profiles.</t>
	</section>	</section>
	<section numbered="true" toc="default">	<section numbered="true" toc="default">
	<name>Profile Identification</name>	<name>Profile Identification</name>

	<t keepWithNext="true">The IEEE 1588 standard requires that all PTP Profil es provide the	<t>The IEEE 1588 standard requires that all PTP Profiles provide the
	following identifying information.</t>	following identifying information.</t>

	<artwork name="" type="" align="left" alt=""><![CDATA[
	PTP Profile:
	Enterprise Profile
	Profile number: 1
	Version: 1.0
	Profile identifier: 00-00-5E-01-01-00


	This PTP Profile was specified by the IETF	<dl newline="false" spacing="compact">
		<dt>PTP Profile:</dt><dd>Enterprise Profile</dd>
		<dt>Profile number:</dt><dd>1</dd>
		<dt>Version:</dt><dd>1.0</dd>
		<dt>Profile identifier:</dt><dd>00-00-5E-01-01-00</dd>
		</dl>
		<t>This PTP Profile was specified by the IETF.</t>

		<t>A copy may be obtained at
		<eref target="https://datatracker.ietf.org/wg/tictoc/documents" brackets
		="angle"/>.

		<!-- [rfced] Section 15: The indented text below was originally tagged as
		<artwork>; we updated to use <dl> for the first four lines and <t> for
		the last two sentences. Note that this text is no longer indented.

		Is this text a direct quote from IEEE 1588? If so, we will add
		<blockquote>. We are not able to access IEEE 1588 to check this.

		Also, we see this note on
		<https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/write
		up/>:

		"This is the final document output from TICTOC. After this, I
		expect to close the working group. NTP has been rechartered to
		encompass work on several time sync protocols, and future work
		can be brought there (or dispatched therefrom)."

		Please confirm that <https://datatracker.ietf.org/wg/tictoc/documents> is the
		best URL to be used in the text below since it is specific to the TICTOC
		Working Group, which is closing. Would it be helpful to mention the URL for
		the NTP Working Group (https://datatracker.ietf.org/wg/ntp/documents/)?
		Please review and let us know if any updates are needed.

		Original:
		The IEEE 1588 standard requires that all PTP Profiles provide the
		following identifying information.

		PTP Profile:
		Enterprise Profile
		Profile number: 1
		Version: 1.0
		Profile identifier: 00-00-5E-01-01-00

		This PTP Profile was specified by the IETF

		A copy may be obtained at
		https://datatracker.ietf.org/wg/tictoc/documents

		Currently:
		The IEEE 1588 standard requires that all PTP Profiles provide the
		following identifying information.

		PTP Profile: Enterprise Profile
		Profile number: 1
		Version: 1.0
		Profile identifier: 00-00-5E-01-01-00

		This PTP Profile was specified by the IETF.

		A copy may be obtained at <https://datatracker.ietf.org/wg/tictoc/
		documents>.
		-->

		</t>


	A copy may be obtained at
	https://datatracker.ietf.org/wg/tictoc/documents
	]]></artwork>
	</section>
	<section anchor="Acknowledgements" numbered="true" toc="default">
	<name>Acknowledgements</name>
	<t>The authors would like to thank Richard Cochran, Kevin Gross, John Flet
	cher, Laurent Montini
	and many other members of IETF for reviewing and providing feedback on thi
	s draft.</t>
	<t>This document was initially prepared using 2-Word-v2.0.template.dot
	and has later been converted manually into xml format using an xml2rfc
	template.</t>
	</section>	</section>
	<section anchor="IANA" numbered="true" toc="default">	<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>	<name>IANA Considerations</name>

	<t>There are no IANA requirements in this specification.</t>	<t>This document has no IANA actions.</t>
	</section>	</section>
	<section anchor="Security" numbered="true" toc="default">	<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>	<name>Security Considerations</name>

	<t>Protocols used to transfer time, such as PTP and NTP can be	<t>Protocols used to transfer time, such as PTP and NTP, can be
	important to security mechanisms which use time windows for keys	important to security mechanisms that use time windows for keys
	and authorization. Passing time through the networks poses a	and authorization. Passing time through the networks poses a

	security risk since time can potentially be manipulated.	security risk, since time can potentially be manipulated.
	The use of multiple simultaneous timeTransmitters, using multiple PTP	The use of multiple simultaneous timeTransmitters, using multiple PTP

	domains can mitigate problems from rogue timeTransmitters and	domains, can mitigate problems from rogue timeTransmitters and
	on-path attacks. Note that Transparent Clocks alter PTP content on-path,	on-path attacks. Note that Transparent Clocks alter PTP content on-path,
	but in a manner specified in <xref target="IEEE1588" format="default">IEEE 1588	but in a manner specified in <xref target="IEEE1588-2019" format="default"></xr
	-2019</xref>	ef>
	that helps with time transfer accuracy. See sections 9 and 10. Additional	that helps with time transfer accuracy. See Sections <xref target="req-ti
		mereceiver-clocks" format="counter"/> and <xref target="req-transparent-clocks"
		format="counter"/>. Additional
	security mechanisms are outside the scope of this document.</t>	security mechanisms are outside the scope of this document.</t>

	<t>PTP native management messages SHOULD NOT be used, due to the lack	<t>PTP native management messages <bcp14>SHOULD NOT</bcp14> be used, due t o the lack
	of a security mechanism for this option. Secure management can be	of a security mechanism for this option. Secure management can be

	obtained using standard management mechanisms which include	obtained using standard management mechanisms that include
	security, for example NETCONF <xref target="RFC6241" format="default">NET	security -- for example, <xref target="RFC6241" format="default">NETCONF<
	CONF</xref>.</t>	/xref>.</t>
	<t>General security considerations of time protocols are discussed in	<t>General security considerations related to time protocols are discussed
	<xref target="RFC7384" format="default">RFC 7384</xref>.</t>	in
		<xref target="RFC7384" format="default"></xref>.</t>
	</section>	</section>
	</middle>	</middle>

	<!-- ***BACK MATTER *** -->

	<back>	<back>

	<!-- References split into informative and normative -->

	<!-- There are 2 ways to insert reference entries from the citation libraries
	:
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (
	as shown)
	2. simply use a PI "less than character"?rfc include="reference.RFC.8174.xml
	"?> here
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
	ml")

	Both are cited textually in the same manner: by using xref elements.
	If you use the PI option, xml2rfc will, by default, try to find included fil
	es in the same
	directory as the including file. You can also define the XML_LIBRARY environ
	ment variable
	with a value containing a set of directories to search. These can be either
	in the local
	filing system or remote ones accessed by http (http://domain/dir/... ).-->

	<references>	<references>
	<name>References</name>	<name>References</name>
	<references>	<references>
	<name>Normative References</name>	<name>Normative References</name>

	<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RF
	C.8174.xml"?-->

	<reference anchor="IEEE1588" target="https://www.ieee.org">
	<!-- the following is the minimum to make xml2rfc happy -->


		<reference anchor="IEEE1588-2019" target="https://ieeexplore.ieee.org/docum ent/9120376">
	<front>	<front>

	<title>IEEE std. 1588-2019, "IEEE Standard for a	<title>IEEE Standard for a
	Precision Clock Synchronization for Networked	Precision Clock Synchronization for Networked

	Measurement and Control Systems."</title>	Measurement and Control Systems</title>
	<author>	<author>

	<organization>Institute of Electrical and Electronics Engineers</o rganization>	<organization>IEEE</organization>
	</author>	</author>

	<date month="11" year="2019"/>	<date month="June" year="2020"/>
	</front>	</front>

		<seriesInfo name="IEEE Std" value="1588-2019"/>
		<seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9120376"/>
		</reference>


	</reference>	<!-- [rfced] [IEEE1588]: We updated the URL for this reference to
	<reference anchor="IEEE1588g" target="https://www.ieee.org">	point to the IEEExplore page for this standard. Please let us know
	<!-- the following is the minimum to make xml2rfc happy -->	any objections.


	<front>	Original:
	<title>IEEE std. 1588g-2022, "IEEE Standard for a Precision Clock Sy	[IEEE1588] Institute of Electrical and Electronics Engineers, "IEEE
	nchronization Protocol for Networked Measurement and Control Systems Amendment 2	std. 1588-2019, "IEEE Standard for a Precision Clock
	: Master-Slave Optional Alternative Terminology"</title>	Synchronization for Networked Measurement and Control
		Systems."", November 2019, <https://www.ieee.org>.

		Currently:
		[IEEE1588-2019]
		IEEE, "IEEE Standard for a Precision Clock Synchronization
		for Networked Measurement and Control Systems", IEEE
		Std 1588-2019, DOI 10.1109/IEEESTD.2020.9120376, June
		2020, <https://ieeexplore.ieee.org/document/9120376>. -->

		<reference anchor="IEEE1588g" target="https://ieeexplore.ieee.org/documen
		t/10070440">
		<front>
		<title>IEEE Standard for a Precision Clock Synchronization Protocol
		for Networked Measurement and Control Systems Amendment 2: Master-Slave Optional
		Alternative Terminology</title>
	<author>	<author>

	<organization>Institute of Electrical and Electronics Engineers</o	<organization>IEEE</organization>
	rganization>
	</author>
	<date month="12" year="2022"/>
	</front>
	</reference>
	<reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc7
	68" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.076
	8.xml">
	<front>
	<title>User Datagram Protocol</title>
	<author initials="J." surname="Postel" fullname="J. Postel">
	<organization/>
	</author>
	<date year="1980" month="August"/>
	</front>
	<seriesInfo name="STD" value="6"/>
	<seriesInfo name="RFC" value="768"/>
	<seriesInfo name="DOI" value="10.17487/RFC0768"/>
	</reference>
	<reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc7
	91" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.079
	1.xml">
	<front>
	<title>Internet Protocol</title>
	<author initials="J." surname="Postel" fullname="J. Postel">
	<organization/>
	</author>
	<date year="1981" month="September"/>
	</front>
	<seriesInfo name="STD" value="5"/>
	<seriesInfo name="RFC" value="791"/>
	<seriesInfo name="DOI" value="10.17487/RFC0791"/>
	</reference>
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.21
	19.xml">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<author initials="S." surname="Bradner" fullname="S. Bradner">
	<organization/>
	</author>
	<date year="1997" month="March"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF document
	s. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.81
	74.xml">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<author initials="B." surname="Leiba" fullname="B. Leiba">
	<organization/>
	</author>
	<date year="2017" month="May"/>
	<abstract>
	<t> RFC 2119 specifies common key words that may be used in prot
	ocol specifications. This document aims to reduce the ambiguity by clarifying t
	hat only UPPERCASE usage of the key words have the defined special meanings..</t
	>
	</abstract>
	</front>
	<seriesInfo name="BCP" value="14"/>
	<seriesInfo name="RFC" value="2119"/>
	<seriesInfo name="DOI" value="10.17487/RFC2119"/>
	</reference>
	<reference anchor="RFC8200" target="https://www.rfc-editor.org/info/rfc8
	200" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.82
	00.xml">
	<front>
	<title>Internet Protocol, Version 6 (IPv6) Specification</title>
	<author initials="S." surname="Deering" fullname="S. Deering">
	<organization/>
	</author>
	<author initials="R." surname="Hinden" fullname="R. Hinden">
	<organization/>
	</author>	</author>

	<date year="2017" month="July"/>	<date month="March" year="2023"/>
	<abstract>
	<t>This document specifies version 6 of the Internet Protocol (IPv
	6). It obsoletes RFC 2460.</t>
	</abstract>
	</front>	</front>

	<seriesInfo name="STD" value="86"/>	<seriesInfo name="IEEE Std" value="1588g-2022"/>
	<seriesInfo name="RFC" value="8200"/>	<seriesInfo name="DOI" value="10.1109/IEEESTD.2023.10070440"/>
	<seriesInfo name="DOI" value="10.17487/RFC8200"/>
	</reference>	</reference>


		<!-- [rfced] [IEEE1588g]: We updated the URL for this reference to
		point to the IEEExplore page for this standard. Please let us know
		any objections.

		Original:
		[IEEE1588g]
		Institute of Electrical and Electronics Engineers, "IEEE
		std. 1588g-2022, "IEEE Standard for a Precision Clock
		Synchronization Protocol for Networked Measurement and
		Control Systems Amendment 2: Master-Slave Optional
		Alternative Terminology"", December 2022,
		<https://www.ieee.org>.

		Currently:
		[IEEE1588g]
		IEEE, "IEEE Standard for a Precision Clock Synchronization
		Protocol for Networked Measurement and Control Systems
		Amendment 2: Master-Slave Optional Alternative
		Terminology", IEEE Std 1588g-2022,
		DOI 10.1109/IEEESTD.2023.10070440, March 2023,
		<https://ieeexplore.ieee.org/document/10070440>. -->

		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
		768.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0
		791.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
		119.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		174.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
		200.xml"/>
	</references>	</references>
	<references>	<references>
	<name>Informative References</name>	<name>Informative References</name>

	<reference anchor="G8271" target="https://www.itu.int">	<reference anchor="G8271" target="https://www.itu.int/rec/T-REC-G.8271-2 02003-I/en">
	<front>	<front>

	<title>ITU-T G.8271/Y.1366, "Time and Phase Synchronization Aspects of Packet Networks"</title>	<title>Time and phase synchronization aspects of telecommunication n etworks</title>
	<author>	<author>

	<organization>International Telecommunication Union</organization>	<organization>ITU-T</organization>
	</author>	</author>

	<date month="3" year="2020"/>	<date month="March" year="2020"/>
	</front>	</front>

		<seriesInfo name="ITU-T Recommendation" value="G.8271/Y.1366"/>
	</reference>	</reference>


		<!-- [rfced] [G8271]: Because the original listed date for this
		reference is March 2020, we updated the title to match the 2020
		version, which is listed as "In force" on
		<https://www.itu.int/rec/t-rec-g.8271/en>. We also updated the URL
		accordingly. Please let us know any objections.

		Original:
		[G8271] International Telecommunication Union, "ITU-T G.8271/
		Y.1366, "Time and Phase Synchronization Aspects of Packet
		Networks"", March 2020, <https://www.itu.int>.

		Currently:
		[G8271] ITU-T, "Time and phase synchronization aspects of
		telecommunication networks", ITU-T
		Recommendation G.8271/Y.1366, March 2020,
		<https://www.itu.int/rec/T-REC-G.8271-202003-I/en>. -->

	<reference anchor="ISPCS" target="https://www.ispcs.org">	<reference anchor="ISPCS" target="https://www.ispcs.org">
	<front>	<front>
	<title>Plugfest Report</title>	<title>Plugfest Report</title>
	<author surname="Arnold" initials="D.">	<author surname="Arnold" initials="D.">
	<organization>International Symposium on Precision Clock	<organization>International Symposium on Precision Clock
	Synchronization for Measurement, Control and Communications</ organization>	Synchronization for Measurement, Control and Communications</ organization>
	</author>	</author>

	<date month="10" year="2017"/>	<date month="October" year="2017"/>
	</front>
	</reference>
	<reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6
	241" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.62
	41.xml">
	<front>
	<title>Network Configuration Protocol (NETCONF)</title>
	<author initials="R." surname="Enns" fullname="R. Enns" role="editor
	">
	<organization/>
	</author>
	<author initials="M." surname="Bjorklund" fullname="M. Bjorklund" ro
	le="editor">
	<organization/>
	</author>
	<author initials="J." surname="Schoenwaelder" fullname="J. Schoenwae
	lder" role="editor">
	<organization/>
	</author>
	<author initials="A." surname="Bierman" fullname="A. Bierman" role="
	editor">
	<organization/>
	</author>
	<date year="2011" month="June"/>
	<abstract>
	<t>The Network Configuration Protocol (NETCONF) defined in this do
	cument provides mechanisms to install, manipulate, and delete the configuration
	of network devices. It uses an Extensible Markup Language (XML)-based data enco
	ding for the configuration data as well as the protocol messages. The NETCONF p
	rotocol operations are realized as remote procedure calls (RPCs). This document
	obsoletes RFC 4741. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="6241"/>
	<seriesInfo name="DOI" value="10.17487/RFC6241"/>
	</reference>
	<reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5
	905" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.59
	05.xml">
	<front>
	<title>Network Time Protocol Version 4: Protocol and Algorithms Spec
	ification</title>
	<author initials="D." surname="Mills" fullname="D. Mills">
	<organization/>
	</author>
	<author initials="J." surname="Martin" fullname="J. Martin" role="ed
	itor">
	<organization/>
	</author>
	<author initials="J." surname="Burbank" fullname="J. Burbank">
	<organization/>
	</author>
	<author initials="W." surname="Kasch" fullname="W. Kasch">
	<organization/>
	</author>
	<date year="2010" month="June"/>
	<abstract>
	<t>The Network Time Protocol (NTP) is widely used to synchronize c
	omputer clocks in the Internet. This document describes NTP version 4 (NTPv4),
	which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305,
	as well as previous versions of the protocol. NTPv4 includes a modified protoco
	l header to accommodate the Internet Protocol version 6 address family. NTPv4 i
	ncludes fundamental improvements in the mitigation and discipline algorithms tha
	t extend the potential accuracy to the tens of microseconds with modern workstat
	ions and fast LANs. It includes a dynamic server discovery scheme, so that in m
	any cases, specific server configuration is not required. It corrects certain e
	rrors in the NTPv3 design and implementation and includes an optional extension
	mechanism. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="5905"/>
	<seriesInfo name="DOI" value="10.17487/RFC5905"/>
	</reference>
	<reference anchor="RFC2026" target="https://www.rfc-editor.org/info/rfc2026" xml
	:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml">
	<front>
	<title>The Internet Standards Process -- Revision 3</title>
	<author initials="S." surname="Bradner" fullname="Scott O. Bradner">
	<organization/>
	</author>
	<date year="1996" month="October"/>
	<abstract>
	<t>This memo documents the process used by the Internet community
	for
	the standardization of protocols and procedures. It defines the
	stages in the standardization process, the requirements for moving a
	document between stages and the types of documents used during this
	process. It also addresses the intellectual property rights and
	copyright issues associated with the standards process.</t>
	</abstract>
	</front>
	<seriesInfo name="RFC" value="2026"/>
	<seriesInfo name="DOI" value="10.17487/RFC2026"/>
	</reference>
	<reference anchor="RFC7384" target="https://www.rfc-editor.org/info/rfc7
	384" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.73
	84.xml">
	<front>
	<title>Security Requirements of Time Protocols in Packet Switched Ne
	tworks</title>
	<author initials="T." surname="Mizrahi" fullname="T. Mizrahi">
	<organization/>
	</author>
	<date year="2014" month="October"/>
	<abstract>
	<t>As time and frequency distribution protocols are becoming incre
	asingly common and widely deployed, concern about their exposure to various secu
	rity threats is increasing. This document defines a set of security requirement
	s for time protocols, focusing on the Precision Time Protocol (PTP) and the Netw
	ork Time Protocol (NTP). This document also discusses the security impacts of ti
	me protocol practices, the performance implications of external security practic
	es on time protocols, and the dependencies between other security services and t
	ime synchronization.</t>
	</abstract>
	</front>	</front>

	<seriesInfo name="RFC" value="7384"/>
	<seriesInfo name="DOI" value="10.17487/RFC7384"/>
	</reference>	</reference>

	<reference anchor="IPv6Registry" target="https://iana.org/assignments/ip
	v6-multicast-addresses/ipv6-multicast-addresses.xhtml">	<!-- [rfced] [ISPCS]: The provided URL steers to the page for
		ISPCS 2024. May we update this listing to reflect the 2017
		conference?

		Original:
		[ISPCS] Arnold, D., "Plugfest Report", October 2017,
		<https://www.ispcs.org>.

		Suggested:
		[ISPCS] Arnold, D. and K. Harris, "Plugfest", Proceedings of the
		IEEE International Symposium on Precision Clock
		Synchronization for Measurement, Control, and
		Communication (ISPCS), August 2017,
		<https://2017.ispcs.org/plugfest>.

		Alternatively (if "2017" is no longer correct or applicable):
		[ISPCS] Arnold, D., "Plugfest", Proceedings of the IEEE
		International Symposium on Precision Clock
		Synchronization for Measurement, Control, &
		Communication (ISPCS), October 2024,
		<https://www.ispcs.org>. -->

		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
		241.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5
		905.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.20
		26.xml"/>
		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
		384.xml"/>
		<reference anchor="IPv6Registry" target="https://iana.org/assignments/ip
		v6-multicast-addresses">
	<front>	<front>
	<title>IPv6 Multicast Address Space Registry</title>	<title>IPv6 Multicast Address Space Registry</title>

	<author initials="S." surname="Venaas" fullname="Stig Venaas">	<author>
	<organization>Internet Assigned Numbers Authority</organization>	<organization>IANA</organization>
	</author>	</author>

	<date year="2024" month="February"/>
	</front>	</front>
	</reference>	</reference>
	<reference anchor="Estrela_and_Bonebakker" target="https://www.researchgat e.net/publication/260742322_Challenges_deploying_PTPv2_in_a_global_financial_com pany">	<reference anchor="Estrela_and_Bonebakker" target="https://www.researchgat e.net/publication/260742322_Challenges_deploying_PTPv2_in_a_global_financial_com pany">

	<!-- the following is the minimum to make xml2rfc happy -->

	<front>	<front>

	<title>Estrela and Bonebakker, "Challenges deploying PTPv2 in a globa	<title>Challenges deploying PTPv2 in a global financial company</titl
	l financial company"</title>	e>
	<author initials="P." surname="Estrela" fullname="P. V. Estrela">	<author initials="P." surname="Estrela" fullname="P. V. Estrela"/>
	<organization>IEEE International Symposium on Precision Clock Sy	<author initials="L." surname="Bonebakker" fullname="L. Bonebakker
	nchronization for Measurement, Control and Communication Proceedings	"/>
	</organization>	<date month="September" year="2012"/>
	</author>
	<author initials="L." surname="Bonebakker" fullname="L. Bonebakker
	">
	<organization>IEEE International Symposium on Precision Clock Sy
	nchronization for Measurement, Control and Communication Proceedings
	</organization>
	</author>
	<date year="2012"/>
	</front>	</front>

		<refcontent>Proceedings of the IEEE International Symposium on Precis ion Clock Synchronization for Measurement, Control and Communication, pp. 1-6</r efcontent>
	<seriesInfo name="DOI" value="10.1109/ISPCS.2012.6336634"/>	<seriesInfo name="DOI" value="10.1109/ISPCS.2012.6336634"/>
	</reference>	</reference>
	</references>	</references>
	</references>	</references>

		<section anchor="Acknowledgements" numbered="false" toc="default">
		<name>Acknowledgements</name>
		<t>The authors would like to thank <contact fullname="Richard
		Cochran"/>, <contact fullname="Kevin Gross"/>, <contact fullname="John
		Fletcher"/>, <contact fullname="Laurent Montini"/>, and many other
		members of the IETF for reviewing and providing feedback on this document.
		</t>
		</section>
	</back>	</back>


		<!-- [rfced] Please review the "Inclusive Language" portion of the
		online Style Guide at
		<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>,
		and let us know if any changes are needed. Updates of this nature
		typically result in more precise language, which is helpful for
		readers.

		We appreciate your efforts to use alternatives to "master" and
		"slave" as noted in Section 1.

		Please consider whether the following should be updated:

		"native" ("PTP native management messages")
		Perhaps "PTP innate management messages"

		"traditional" ("... a traditional time transfer such as NTP") *
		Perhaps "a long-established time transfer such as NTP"

		* Please consider whether "tradition" could be updated for clarity.
		While the NIST website (https://www.nist.gov/nist-research-library/
		nist-technical-series-publications-author-instructions#table1)
		indicates that this term is potentially biased, it is also ambiguous.
		"Tradition" is a subjective term, as it is not the same for everyone. -->

		<!-- [rfced] The following terms appear to be used inconsistently in
		this document. Please let us know which form is preferred.

		Alternate timeTransmitter (3 instances /
		Alternate TimeTransmitter (1 instance)
		("Alternate timeTransmitter flag", "Alternate TimeTransmitter
		option")

		Best timeTransmitter (2 instances) /
		Best TimeTransmitter (3 instances)
		(used generally, e.g., "the Best timeTransmitter, ...", "the Best
		TimeTransmitter. ...")

		End-to-End Delay measurement (1 instance) /
		End-to-End delay measurement (3 instances)

		Enterprise (1 instance) / enterprise (3 instances)
		(used generally, e.g., "Enterprise
		information system environment", "enterprise networks")

		Enterprise Profile Clock (1 instance) /
		Enterprise Profile clock (1 instance)

		Peer-to-Peer delay measurement mechanism (2 instances) /
		Peer-to-peer measurement mechanism (1 instance)

		Preferred TimeTransmitter (1 instance) /
		Preferred timeTransmitter (2 instances)

		PTP Clock (3 instances) / PTP clock (3 instances)*

		PTP Domain (3 instances) / PTP domain (9 instances)*

		PTP Management messages (1 instance) /
		management messages (1 instance) /
		PTP native management messages (1 instance)

		PTP Networks (1 instance) / PTP networks (1 instance)*

		PTP Node (2 instances) / PTP node (5 instances)*

		* We see that "PTP Port" is used consistently.

		TimeReceiver (4 instances) / timeReceiver (approx. 14 instances)
		(used generally, e.g., "domains, TimeReceivers SHOULD",
		"then the timeReceiver MUST NOT"; please review, and let us know
		if any changes are needed)

		TimeReceiver Only clock (1 instance) /
		TimeReceiver Only Clock (1 instance) /
		timeReceiver Only Clock (1 instance)

		Unicast Message Negotiation / unicast negotiation (in text) -->

	</rfc>	</rfc>

End of changes. 131 change blocks.
	670 lines changed or deleted	1001 lines changed or added
This html diff was produced by rfcdiff 1.48.