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

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?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-ietf-tictoc-ptp-enterprise-profile-28"
number="9760" consensus="true" ipr="trust200902" obsoletes="" updates="" submissionType="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 ***** -->

 <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the
        full title is longer than 39 characters -->
   <title abbrev="Enterprise Profile for PTP">Enterprise Profile for the
   Precision Time Protocol With with Mixed Multicast and Unicast messages</title> Messages</title>
   <seriesInfo name="Internet-Draft" value="draft-ietf-tictoc-ptp-enterprise-profile-28"/>
    <!-- add 'role="editor"' below for the editors if appropriate -->

   <!-- Another author who claims to be an editor --> name="RFC" value="9760"/>

   <author fullname="Doug Arnold" initials="D.A." initials="D." surname="Arnold">
      <organization>Meinberg-USA</organization>
      <address>
        <postal>
          <street>3 Concord Rd</street>
          <!-- Reorder these if your country does things differently -->
          <city>Shrewsbury</city>
          <region>Massachusetts</region>
          <code>01545</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone/>
        <email>doug.arnold@meinberg-usa.com</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <author fullname="Heiko Gerstung" initials="H.G." initials="H." surname="Gerstung">
      <organization>Meinberg</organization>
      <address>
        <postal>
          <street>Lange Wand 9</street>
          <!-- Reorder these if your country does things differently -->
          <city>Bad Pyrmont</city>
          <region/>
          <code>31812</code>
          <country>Germany</country>
        </postal>
        <phone/>
        <email>heiko.gerstung@meinberg.de</email>
        <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
    <date year="2024"/>

<!-- If the month and year are [rfced] First-page header: Authors, we have updated both specified and are of your names in
the current ones, xml2rfc will fill 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 current day for you. If only first-page header of
RFC 5907.

For more information about author names in the current year is specified, xml2rfc will fill 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>

    <keyword>PTP</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 current day and month for you.
document.  If these are generic example addresses, they should be changed
to use the year is not 233.252.0.x range defined in RFC 5771"

It appears that idnits confused multicast addresses with the current one, it is
	 necessary PTP
primary IP address (for IPv4) listed in Section 6, but we want to specify at least a month (xml2rfc assumes day="1" if not specified for
point out the
	 purpose of calculating idnits warning all the expiry date).  With drafts it is normally sufficient same.  It appears that we don't
need to
	 specify just the year. -->

   <!-- Meta-data Declarations 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. -->

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

    <abstract>
      <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
    environment.  The PTP Profile uses the End-to-End delay measurement
    mechanism, allows allowing both multicast and unicast Delay Request and Delay
    Response messages.</t>
    </abstract>
  </front>
  <middle>
    <section numbered="true" toc="default">
      <name>Introduction</name>
      <t>The Precision Time Protocol ("PTP"), (PTP), standardized in IEEE 1588, has
      been designed in its first version (IEEE 1588-2002) with the goal to minimize of
      minimizing configuration on the participating nodes. Network communication
      was based solely on multicast messages, which which, unlike
     NTP NTP, did not require
      that a receiving node as discussed in <xref target="IEEE1588" format="default">IEEE 1588-2019</xref> target="IEEE1588-2019" format="default">IEEE 1588-2019</xref> need to know the identity identities of the
      time sources in the network.  This document describes clock roles and
      PTP Port states using the optional alternative terms timeTransmitter, "timeTransmitter"
      instead of master, "master" and timeReceiver, "timeReceiver" instead of slave, "slave", as defined in the
      <xref target="IEEE1588g" format="default">IEEE 1588g</xref> amendment 1588g amendment</xref> to
      <xref target="IEEE1588"      format="default">IEEE 1588-2019</xref> .  </t> target="IEEE1588-2019" format="default"></xref>.</t>
      <t>The "Best TimeTransmitter Clock Algorithm" (<xref target="IEEE1588" format="default">IEEE 1588-2019</xref> target="IEEE1588-2019" format="default"></xref>, Subclause 9.3), a mechanism that
      all participating PTP nodes MUST <bcp14>MUST</bcp14> follow, set sets up strict rules for all
      members of a PTP domain to determine which node MUST <bcp14>MUST</bcp14> be the active
      reference time source (Grandmaster).  Although the multicast
      communication model has advantages in smaller networks, it complicated
      the application of PTP in larger
     networks, networks -- for example example, in environments
      like IP based IP-based telecommunication networks or financial data centers. It
      is considered inefficient that, even if the content of a message applies
      only to one receiver, it the message is forwarded by the underlying network (IP) to
      all nodes, requiring them to spend network bandwidth and other
      resources, such as CPU cycles, to drop the
     message.</t> it.</t>
      <t>The third edition of the standard (IEEE 1588-2019) defines
     PTPv2.1 and includes the
     possibility to use of using unicast communication between the PTP nodes in
     order to overcome the limitation of using multicast messages for
     the bi-directional bidirectional information exchange between PTP nodes. The
     unicast approach avoided that. In PTP domains with a lot of nodes,
     devices had to throw away most of the received multicast
     messages because they carried information for some other node.
     The percent of PTP messages that are discarded as irrelevant to the receiving node can exceed 99%
     <xref target="Estrela_and_Bonebakker" format="default"/>.

<!-- [rfced] Section 1:  We could not find any instances of "%",
"99", "nine", "percent", "per cent", "per-cent", "cent", "discard",
"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%
     (<xref target="Estrela_and_Bonebakker" format="default">Estrela (Estrela and Bonebakker</xref>).</t> Bonebakker
 [Estrela_and_Bonebakker]). -->

</t>
      <t>PTPv2.1 also includes PTP Profiles (<xref target="IEEE1588" format="default">IEEE 1588-2019</xref> subclause target="IEEE1588-2019" format="default"></xref>, Subclause 20.3).
     This construct allows
     These constructs allow organizations to specify selections of
     attribute values and optional features, simplifying the
     configuration of PTP nodes for a specific application. Instead of
     having to go through all possible parameters and configuration
     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
     to a defined value. If a PTP Profile definition allows multiple
     values for a parameter, selection of the PTP Profile will set the
     profile-specific default value for this parameter. Parameters not
     allowing multiple values are set to the value defined in the PTP
     Profile. Many PTP features and functions are optional, and a
     PTP Profile should also define which optional features of PTP are
     required, permitted, and prohibited. It is possible to extend the
     PTP standard with a PTP Profile by using the TLV mechanism of PTP
     (see <xref target="IEEE1588" format="default">IEEE 1588-2019</xref> subclause target="IEEE1588-2019" format="default"></xref>, Subclause 13.4),
     defining an optional Best TimeTransmitter Clock Algorithm Algorithm, and a few other ways.
     PTP has its own management protocol (defined in
     <xref target="IEEE1588" format="default">IEEE 1588-2019</xref> subclause target="IEEE1588-2019" format="default"></xref>, Subclause 15.2) but
     allows a PTP Profile to specify an alternative management mechanism, mechanism --
     for example NETCONF.</t> example, the Network Configuration Protocol (NETCONF).</t>
     <t> In this document document, the term PTP Port "PTP Port" refers to a logical access point of a PTP instantiation for PTP communincation communication in a network.

<!-- [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 numbered="true" toc="default">
      <name>Requirements Language</name>
       <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
    NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
    "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
       "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
       "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
       "<bcp14>SHOULD NOT</bcp14>",
       "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
       "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document
       are to be interpreted as described in BCP 14 BCP&nbsp;14
       <xref target="RFC2119" format="default">RFC 2119 </xref> target="RFC2119"/> <xref target="RFC8174" format="default">RFC 8174</xref> target="RFC8174"/> when, and only
       when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="technical_terms" numbered="true" toc="default">
      <name>Technical Terms</name>
      <ul spacing="normal">
        <li>Acceptable
      <dl spacing="normal" newline="false">
        <dt>Acceptable TimeTransmitter Table: A Table:</dt><dd>A list of timeTransmitters that
may be maintained by a PTP timeReceiver Clock.  The PTP timeReceiver Clock may maintain a list of would be willing to synchronize to timeTransmitters in this list.</dd>
        <dt>Alternate timeTransmitter:</dt><dd>A PTP timeTransmitter Clock, which is not the Best
          timeTransmitter, and may act as a timeTransmitter with the Alternate timeTransmitter flag set on
          the messages it sends.

<!-- [rfced] Section 3:  Does this definition indicate that a PTP
timeTransmitter Clock is willing to synchronize to.</li>
        <li>Alternate never the Best timeTransmitter, or does it
indicate that some PTP timeTransmitter Clocks might not be the
Best timeTransmitter (in which case "which" should be "that")?

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.</li>
        <li>Announce 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 properties 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.</li>
        <li>Best timeTransmitter:  A
    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 timeTransmitter state, operating
          as the Grandmaster of a PTP domain.</li>
        <li>Best domain.</dd>
        <dt>Best TimeTransmitter Clock Algorithm: A Algorithm:</dt><dd>A method for determining which state
          a PTP Port of a PTP clock should be in.  The state decisions lead to the formation of a clock spanning tree
          for a PTP domain. </li>
        <li>Boundary Clock: A domain.</dd>
        <dt>Boundary Clock:</dt><dd>A device with more than one PTP Port.  Generally  Generally,
          Boundary Clocks will have one PTP Port in the timeReceiver state to receive
          timing and other PTP Ports in the timeTransmitter state to re-distribute redistribute the
          timing.</li>
        <li>Clock Identity: In IEEE 1588-2019 this is
          timing.</dd>
        <dt>Clock Identity:</dt><dd>In <xref target="IEEE1588-2019"/>, a 64-bit number
          assigned to each PTP clock which MUST clock.  This number <bcp14>MUST</bcp14> be globally unique. Often Often, it is
          derived from the Ethernet MAC address.</li>
        <li>Domain: Media Access Control (MAC) address.</dd>
        <dt>Domain:</dt><dd>Treated as a separate PTP system in a network. Every PTP message contains a domain number.  Domains are
          treated as separate PTP systems in the network. Clocks, however,
          can combine the timing information derived from multiple domains.</li>
        <li>End-to-End domains.</dd>
        <dt>End-to-End delay measurement mechanism: A mechanism:</dt><dd>A network delay
          measurement mechanism in PTP facilitated by an exchange of
          messages between a timeTransmitter Clock and a timeReceiver  Clock.
          These messages might traverse Transparent Clocks and PTP unaware PTP-unaware switches.
          This mechanism might not work properly if the Sync and Delay Request messages traverse different network paths.</li>
        <li>Grandmaster: the paths.</dd>
        <dt>Grandmaster:</dt><dd>The timeTransmitter Clock that is currently acting as the reference time source of the PTP domain</li>
        <li>IEEE 1588: The domain.</dd>
        <dt>IEEE 1588:</dt><dd>The timing and synchronization standard which that defines
          PTP,
          PTP and describes the node, system, and communication properties
          necessary to support PTP.</li>
        <li>TimeTransmitter Clock: a clock with at least one PTP Port in the timeTransmitter state.</li>
        <li>NTP: Network PTP.</dd>
        <dt>NTP:</dt><dd>Network Time Protocol, defined by RFC 5905, see <xref target="RFC5905" format="default">RFC 5905</xref></li>
        <li>Ordinary Clock: A format="default"/>.</dd>
        <dt>Ordinary Clock:</dt><dd>A clock that has a single Precision Time Protocol
          PTP Port in a domain and maintains the timescale used in the
          domain. It may serve as a timeTransmitter Clock, Clock or may be a timeReceiver Clock.</li>
        <li>Peer-to-Peer Clock.</dd>
        <dt>Peer-to-Peer delay measurement mechanism: A mechanism:</dt><dd>A network delay
          measurement mechanism in PTP facilitated by an exchange of
          messages over the link between adjacent devices in a network.
          This mechanism might not work properly unless all devices in the network support PTP and the Peer-to-peer measurement mechanism.</li>
        <li>Preferred timeTransmitter: A mechanism.</dd>
        <dt>Preferred timeTransmitter:</dt><dd>A device intended to act primarily as the
          Grandmaster of a PTP system, system or as a back up backup to a Grandmaster.</li>
        <li>PTP: The Grandmaster.</dd>
        <dt>PTP:</dt><dd>The Precision Time Protocol: The Protocol -- the timing and synchronization
          protocol defined by IEEE 1588.</li>
        <li>PTP Port: An 1588.</dd>
        <dt>PTP Port:</dt><dd>An interface of a PTP clock with the network.  Note that
          there may be multiple PTP Ports running on one physical interface, interface --
          for example, mulitple multiple unicast timeReceivers which that talk to several Grandmaster
          Clocks in different PTP Domains.</li>
          <li>PTP Profile: A Domains.</dd>
          <dt>PTP Profile:</dt><dd>A set of constraints on the options and features of PTP,
          designed to optimize PTP for a specific use case or industry.
          The profile specifies what is required, allowed allowed, and forbidden among options and attribute values of PTP.</li>
        <li>PTPv2.1: Refers PTP.</dd>
        <dt>PTPv2.1:</dt><dd>Refers specifically to the version of PTP defined by
          IEEE 1588-2019.</li>
        <li>Rogue
          <xref target="IEEE1588-2019"/>.</dd>
        <dt>Rogue timeTransmitter:</dt><dd>A clock with 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 does not set the Alternate timeTransmitter flag.

<!-- [rfced] Section 3:  This sentence does not parse.  If the
suggested text is not correct, please clarify "and does not set".

Original:
 *  Rogue timeTransmitter: A clock with 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 does not set the Alternate timeTransmitter flag.</li>
        <li>TimeReceiver Clock: flag.

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 the timeReceiver state, state
          and no PTP Ports in the timeTransmitter state.</li>
        <li>TimeReceiver state.</dd>
        <dt>TimeReceiver Only clock: An clock:</dt><dd>An Ordinary Clock which that cannot become a timeTransmitter
          Clock.</li>
        <li>TLV: Type
          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, Value -- a mechanism for extending messages in
          networked communications.</li>
        <li>Transparent Clock.  A 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
          message with a correction for this transit time.</li>
        <li>Unicast Discovery: A time.</dd>
        <dt>Unicast Discovery:</dt><dd>A mechanism for PTP timeReceivers to establish a
          unicast communication with PTP timeTransmitters using a configured table of
          timeTransmitter IP addresses and Unicast Message Negotiation.</li>
        <li>Unicast Negotiation: A Negotiation.</dd>
        <dt>Unicast Negotiation:</dt><dd>A mechanism in PTP for timeReceiver Clocks to
          negotiate unicast Sync, Announce Announce, and Delay Request message transmission rates
          from timeTransmitters.</li>
      </ul> 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 numbered="true" toc="default">
      <name>Problem Statement</name>
      <t>This document describes how PTP can be applied to work in large
      enterprise networks.  See ISPCS <xref target="RFC2026" format="default">ISPCS</xref> format="default"/> for information on IETF applicability statements.
      Such large networks are deployed, for example, in
      financial corporations.  It is becoming increasingly common in such
      networks to perform distributed time tagged time-tagged measurements, such as
      one-way packet latencies and cumulative delays on software
      systems spread across multiple computers. Furthermore, there is
      often a desire to check the age of information time tagged time-tagged by a
      different machine.  To perform these measurements, it is necessary
      to deliver a common precise time to multiple devices on a network.
      Accuracy currently required in the Financial Industry range financial industry ranges from
      100 microseconds to 1 nanoseconds nanosecond to the Grandmaster.  This
      PTP Profile does not specify timing performance requirements, but such
      requirements explain why the needs cannot always be met by NTP, NTP as
      commonly implemented. Such accuracy cannot usually be achieved with
      a traditional time transfer such as NTP, without adding
      non-standard customizations such as on-path support, similar to what is done in PTP with Transparent Clocks and Boundary Clocks.
      Such PTP support is commonly available in switches and routers, and many such devices have already been deployed in networks.
      Because PTP has a complex range of features and
      options
      options, it is necessary to create a PTP Profile for enterprise
      networks to achieve interoperability between among equipment
      manufactured by different vendors.</t> 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
      increasingly common to deploy multicast protocols, even across
      multiple subnets. For this reason, it is desired desirable to make use of
      multicast whenever the information going to many destinations is
      the same.  It is also advantageous to send information which that is
      only relevant to one device as a unicast message.  The latter can be
      essential as the number of PTP timeReceivers becomes hundreds or
      thousands.</t>
      <t>PTP devices operating in these networks need to be robust.  This
      includes the ability to ignore PTP messages which that can be
      identified as improper, improper and to have redundant sources of time.</t>
      <t>Interoperability among independent implementations of this PTP
      Profile has been demonstrated at the ISPCS Plugfest <xref target="ISPCS" format="default">ISPCS</xref>.</t> format="default">International Symposium on Precision Clock Synchronization (ISPCS) Plugfest</xref>.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Network Technology</name>
      <t>This PTP Profile MUST <bcp14>MUST</bcp14> operate only in networks characterized by
      UDP <xref target="RFC0768" format="default">RFC 768</xref> format="default"></xref> over either IPv4
      <xref target="RFC0791" format="default">RFC 791</xref> format="default"></xref> or IPv6 <xref target="RFC8200" format="default">RFC 8200</xref>, format="default"></xref>,
      as described by Annexes C and D in of <xref target="IEEE1588" format="default">IEEE 1588</xref> target="IEEE1588-2019" format="default"></xref>, respectively.
      A network node MAY <bcp14>MAY</bcp14> include multiple PTP instances running simultaneously.
      IPv4 and IPv6 instances in the same network node MUST <bcp14>MUST</bcp14> operate in different PTP Domains.
      PTP Clocks which that communicate using IPv4
      can transfer time to PTP Clocks using IPv6, or the reverse, if and only if, if there is a network node
      which
      that simultaneously communicates with both PTP domains in the different IP versions.</t> versions.

<!-- [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 MAY <bcp14>MAY</bcp14> include switches and routers.
      These devices MAY <bcp14>MAY</bcp14> be Transparent Clocks, Boundary Clocks, or
      neither, in any combination.  PTP Clocks MAY <bcp14>MAY</bcp14> be Preferred timeTransmitters,
      Ordinary Clocks, or Boundary Clocks.  The Ordinary Clocks may be
      TimeReceiver Only Clocks, Clocks or may be timeTransmitter capable.</t>
      <t>Note that PTP Ports will need to keep tack track of the Clock ID of received messages and
      not just the IP or Layer 2 addresses in any network that includes Transparent Clocks, Clocks or that might include them in the future.
      This is important important,
      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 retranmitted. retransmitted.
      In IPv4 networks networks, some clocks
      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
      limitations on the topology of PTP networks, depending on the port
      forwarding scheme employed.  Details of implementing PTP with NATs
      are out of scope of for this document.</t>
      <t>PTP, similar to NTP, assumes that the one-way network delay for Sync
      messages and Delay Response messages are is the same. When this is
      not true 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
      the network so that such effects do not prevent the PTP system
      from meeting the timing requirements. The details of network asymmetry
      are outside the scope of this document.  See  See, for
      example, <xref target="G8271" format="default">ITU-T G.8271</xref>.</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 numbered="true" toc="default">
      <name>Time Transfer and Delay Measurement</name>
      <t>TimeTransmitter Clocks, Transparent Clocks Clocks, and Boundary Clocks MAY <bcp14>MAY</bcp14> be
    either one-step clocks or two-step clocks.  TimeReceiver Clocks MUST <bcp14>MUST</bcp14>
    support both behaviors. The End-to-End Delay measurement method
    MUST
    <bcp14>MUST</bcp14> be used.</t>
      <t>Note that, in IP networks, Sync messages and Delay Request
    messages exchanged between a timeTransmitter and timeReceiver do not necessarily
    traverse the same physical path. Thus, wherever possible, the
    network SHOULD <bcp14>SHOULD</bcp14> be engineered so that the forward and
    reverse routes traverse the same physical path.  Traffic
    engineering techniques for path consistency are out of scope of for
    this document.</t>
      <t>Sync messages MUST <bcp14>MUST</bcp14> be sent as PTP event multicast messages (UDP
    port 319) to the PTP primary IP address.   Two step   Two-step clocks MUST <bcp14>MUST</bcp14>
    send Follow-up messages as PTP general multicast messages (UDP port 320).
    Announce messages MUST <bcp14>MUST</bcp14> be sent as multicast messages (UDP port 320)
    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 "X" can
    be a value between 0x0 and 0xF. The different IPv6 address options are explained in IEEE 1588
    <xref target="IEEE1588" format="default">IEEE 1588</xref> target="IEEE1588-2019" format="default"></xref>, Annex D, Section D.3.
    These addresses are aloted allotted by IANA, IANA; see the <xref target="IPv6Registry" format="default">Ipv6 format="default">"IPv6 Multicast Address Space Registry</xref></t> Registry"</xref>.

<!-- [rfced] Section 6:  Because this sentence indicates a
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 MAY <bcp14>MAY</bcp14> be sent as either multicast or unicast
    PTP event messages. TimeTransmitter Clocks MUST <bcp14>MUST</bcp14> respond to multicast Delay
    Request messages with multicast Delay Response PTP general
    messages. TimeTransmitter Clocks MUST <bcp14>MUST</bcp14> respond to unicast Delay Request PTP
    event messages with unicast Delay Response PTP general messages.
    This allows for the use of Ordinary Clocks which that do not support the
    Enterprise Profile, if they are timeReceiver Only Clocks.</t>
      <t>Clocks SHOULD <bcp14>SHOULD</bcp14> include support for multiple domains.  The purpose is
    to support multiple simultaneous timeTransmitters for redundancy. Leaf
    devices (non-forwarding devices) can use timing information from
    multiple timeTransmitters by combining information from multiple
    instantiations of a PTP stack, each operating in a different
    PTP Domain. Redundant sources of timing can be ensembled, ensembled and/or
    compared to check for faulty timeTransmitter Clocks. The use of multiple
    simultaneous timeTransmitters will help mitigate faulty timeTransmitters reporting as
    healthy, network delay asymmetry, and security problems.  Security
    problems include on-path attacks such as delay attacks,
    packet interception / manipulation interception/manipulation attacks. Assuming that the path to
    each timeTransmitter is different, failures -- malicious or otherwise -- would
    have to happen at more than one path simultaneously. Whenever
    feasible, the underlying network transport technology SHOULD <bcp14>SHOULD</bcp14> be
    configured so that timing messages in different domains traverse
    different network paths.</t> 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 numbered="true" toc="default">
      <name>Default Message Rates</name>
      <t>The Sync, Announce, and Delay Request default message rates MUST <bcp14>MUST</bcp14>
    each be once per second.  The Sync and Delay Request message rates
    MAY
    <bcp14>MAY</bcp14> be set to other values, but not less than once every 128
    seconds,
    seconds and not more than 128 messages per second.  The Announce
    message rate MUST NOT <bcp14>MUST NOT</bcp14> be changed from the default value.  The
    Announce Receipt Timeout Interval MUST <bcp14>MUST</bcp14> be three Announce
    Intervals for Preferred TimeTransmitters, TimeTransmitters and four Announce Intervals for
    all other timeTransmitters.</t>
      <t>The logMessageInterval carried in the unicast Delay Response
    message MAY <bcp14>MAY</bcp14> be set to correspond to the timeTransmitter ports preferred
    message period, rather than 7F, which indicates that message periods
    are to be negotiated.  Note that negotiated message periods are not
    allowed,
    allowed; see <xref target="forbidden_ptp_options"/> ("<xref target="forbidden_ptp_options" format="default">forbidden PTP
    options</xref>.</t> format="title"/>").

<!-- [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 numbered="true" toc="default">
      <name>Requirements for TimeTransmitter Clocks</name>
      <t>TimeTransmitter Clocks MUST <bcp14>MUST</bcp14> obey the standard Best TimeTransmitter Clock Algorithm
    from
    as defined in <xref target="IEEE1588" format="default">IEEE 1588</xref>. target="IEEE1588-2019" format="default"></xref>.  PTP systems using this PTP Profile MAY <bcp14>MAY</bcp14> support
    multiple simultaneous Grandmasters if each active Grandmaster is
    operating in a different PTP domain.</t>
      <t>A PTP Port of a clock MUST NOT <bcp14>MUST NOT</bcp14> be in the timeTransmitter state unless the
    clock has a current value for the number of UTC leap
    seconds.</t>
      <t>If a unicast negotiation signaling message is received received, it MUST <bcp14>MUST</bcp14>
    be ignored.</t>
    <t>In PTP Networks that contain Transparent Clocks, timeTransmitters might receive Delay Request messages that no longer contains contain the IP Addresses addresses of the timeReceivers.
    This is because Transparent Clocks might replace the IP address of Delay Requests
    with their own IP address after updating the Correction Fields.  For this deployment scenario scenario, timeTransmitters will need to have configured tables of timeReceivers' IP addresses
    and associated Clock Identities in order to send Delay Responses to the correct PTP Nodes.</t>
    </section>
    <section numbered="true" toc="default"> toc="default" anchor="req-timereceiver-clocks">
      <name>Requirements for TimeReceiver Clocks</name>
    <t>In a network which that contains multiple timeTransmitters in multiple domains,
    TimeReceivers SHOULD <bcp14>SHOULD</bcp14> make use of information from all the timeTransmitters in their clock control subsystems.
    TimeReceiver Clocks MUST <bcp14>MUST</bcp14> be able to function in such networks even if they use time from only one of the domains.
    TimeReceiver Clocks MUST <bcp14>MUST</bcp14> be able to operate properly in the
    presence of a rogue timeTransmitter. TimeReceivers SHOULD NOT Synchronize <bcp14>SHOULD NOT</bcp14> synchronize to a
    timeTransmitter which that is not the Best TimeTransmitter in its domain. TimeReceivers will
    continue to recognize a Best TimeTransmitter for the duration of the
    Announce Time Out Interval. TimeReceivers MAY <bcp14>MAY</bcp14> use an Acceptable TimeTransmitter
    Table.  If a timeTransmitter is not an Acceptable timeTransmitter, then the timeReceiver
    MUST NOT
    <bcp14>MUST NOT</bcp14> synchronize to it. Note that IEEE 1588-2019 requires
    timeReceiver Clocks to support both two-step or and one-step timeTransmitter Clocks.
    See <xref target="IEEE1588" format="default">IEEE 1588</xref>, subClause 11.2.</t> target="IEEE1588-2019" format="default"></xref>, Subclause 11.2.

<!-- [rfced] Section 9:  Please confirm that "Announce Time Out
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 messages, timeReceivers can
    obtain the IP addresses of a timeTransmitter from the Announce messages.
    Note that the IP source addresses of Sync and Follow-up messages
    might have been replaced by the source addresses of a Transparent
    Clock, so,
    Clock; therefore, timeReceivers MUST <bcp14>MUST</bcp14> send Delay Request messages to the IP
    address in the Announce message.  Sync and Follow-up messages can
    be correlated with the Announce message using the Clock ID, which
    is never altered by Transparent Clocks in this PTP Profile.</t>
    </section>
    <section numbered="true" toc="default"> toc="default" anchor="req-transparent-clocks">
      <name>Requirements for Transparent Clocks</name>
      <t>Transparent Clocks MUST NOT <bcp14>MUST NOT</bcp14> change the transmission mode of an
    Enterprise Profile PTP message.  For example, a Transparent Clock
    MUST NOT
    <bcp14>MUST NOT</bcp14> change a unicast message to a multicast message.
    Transparent Clocks that syntonize to the timeTransmitter Clock might need to maintain
    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> domains. -->

</t>
    </section>
    <section numbered="true" toc="default">
      <name>Requirements for Boundary Clocks</name>
      <t>Boundary Clocks SHOULD <bcp14>SHOULD</bcp14> support multiple simultaneous PTP domains.
    This will require them to maintain separate clocks for each of the
    domains supported, at least in software.  Boundary Clocks MUST NOT <bcp14>MUST NOT</bcp14>
    combine timing information from different domains.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Management and Signaling Messages</name>
      <t>PTP Management messages MAY <bcp14>MAY</bcp14> be used.  Management
    messages intended for a specific clock, i.e. i.e., where the <xref target="IEEE1588" format="default">IEEE 1588</xref> defined
    attribute targetPortIdentity.clockIdentity attribute (defined in <xref target="IEEE1588-2019" format="default"></xref>) is not set to All 1s,
    MUST
    <bcp14>MUST</bcp14> be sent as a unicast message.  Similarly, if any signaling
    messages are used used, they MUST <bcp14>MUST</bcp14> also be sent as unicast messages
    whenever the message is intended soley solely for a specific PTP Node.</t> 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 anchor="forbidden_ptp_options" numbered="true" toc="default">
      <name>Forbidden PTP Options</name>
      <t>Clocks operating in the Enterprise Profile <bcp14>MUST NOT</bcp14> use the following:</t>
  <ul spacing="normal">
   <li>Peer-to-Peer timing for delay measurement</li>
   <li>Grandmaster Clusters</li>
   <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 Clocks,
    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>
    </section>
    <section numbered="true" toc="default">
      <name>Interoperation with IEEE 1588 Default Profile</name>
      <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> target="IEEE1588-2019" format="default"></xref>,
    Annex I.3.  This variant of the Default Profile uses the End-to-End
    delay measurement mechanism.  In addition, the Default Profile
    would have to operate over IPv4 or IPv6 networks, networks and use
    management messages in unicast when those messages are directed at
    a specific clock. If either neither of these requirements are not met than is met, then
    Enterprise Profile clocks will not interoperate with Annex I.3
    Default Profile Clocks. Clocks as defined in <xref target="IEEE1588-2019" format="default"></xref>, Annex I.3.  The Enterprise Profile will not
    interoperate with the Annex I.4 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
    in other PTP Profiles if the clocks in the other PTP Profiles obey the
    rules of the Enterprise Profile.  These rules MUST NOT <bcp14>MUST NOT</bcp14> be changed
    to achieve interoperability with other PTP Profiles.</t>
    </section>
    <section numbered="true" toc="default">
      <name>Profile Identification</name>
      <t keepWithNext="true">The
      <t>The IEEE 1588 standard requires that all PTP Profiles provide the
        following identifying information.</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[

	<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/writeup/>:

"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
        ]]></artwork>
    </section>
    <section anchor="Acknowledgements" numbered="true" toc="default">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Richard Cochran, Kevin Gross, John Fletcher, Laurent Montini
      and many other members of IETF for reviewing and providing feedback on this draft.</t>
      <t>This document

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 initially prepared using 2-Word-v2.0.template.dot
         and has later been converted manually into xml format using an xml2rfc template.</t> specified by the IETF.

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

</t>

    </section>
    <section anchor="IANA" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>There are
      <t>This document has no IANA requirements in this specification.</t> actions.</t>
    </section>
    <section anchor="Security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Protocols used to transfer time, such as PTP and NTP NTP, can be
       important to security mechanisms which that use time windows for keys
       and authorization. Passing time through the networks poses a
       security risk risk, since time can potentially be manipulated.
       The use of multiple simultaneous timeTransmitters, using multiple PTP
       domains
       domains, can mitigate problems from rogue timeTransmitters and
       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-2019</xref> target="IEEE1588-2019" format="default"></xref>
       that helps with time transfer accuracy. See sections 9 Sections <xref target="req-timereceiver-clocks" format="counter"/> and 10. <xref target="req-transparent-clocks" format="counter"/>. Additional
       security mechanisms are outside the scope of this document.</t>
      <t>PTP native management messages SHOULD NOT <bcp14>SHOULD NOT</bcp14> be used, due to the lack
       of a security mechanism for this option. Secure management can be
       obtained using standard management mechanisms which that include
       security,
       security -- for example NETCONF example, <xref target="RFC6241" format="default">NETCONF</xref>.</t>
      <t>General security considerations of related to time protocols are discussed in
       <xref target="RFC7384" format="default">RFC 7384</xref>.</t> format="default"></xref>.</t>
    </section>
  </middle>
  <!--  *****BACK MATTER ***** -->

<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.xml")

    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 files in the same
    directory as the including file. You can also define the XML_LIBRARY environment 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>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"?-->

     <reference anchor="IEEE1588" target="https://www.ieee.org">
          <!-- the following is the minimum to make xml2rfc happy --> anchor="IEEE1588-2019" target="https://ieeexplore.ieee.org/document/9120376">
       <front>
            <title>IEEE std. 1588-2019, "IEEE Standard for a
                Precision Clock Synchronization for Networked
                Measurement and Control Systems."</title> Systems</title>
            <author>
              <organization>Institute of Electrical and Electronics Engineers</organization>
              <organization>IEEE</organization>
            </author>
            <date month="11" year="2019"/> month="June" year="2020"/>
          </front>
	  <seriesInfo name="IEEE Std" value="1588-2019"/>
	  <seriesInfo name="DOI" value="10.1109/IEEESTD.2020.9120376"/>
       </reference>
             <reference anchor="IEEE1588g" target="https://www.ieee.org">

<!-- [rfced] [IEEE1588]:  We updated the following is the minimum URL for this reference to make xml2rfc happy
point to the IEEExplore page for this standard.  Please let us know
any objections.

Original:
 [IEEE1588] Institute of Electrical and Electronics Engineers, "IEEE
            std. 1588-2019, "IEEE Standard for a Precision Clock
            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/document/10070440">
         <front>
            <title>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"</title> Terminology</title>
            <author>
              <organization>Institute of Electrical and Electronics Engineers</organization>
              <organization>IEEE</organization>
            </author>
            <date month="12" year="2022"/>
          </front>
        </reference>
        <reference anchor="RFC0768" target="https://www.rfc-editor.org/info/rfc768" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0768.xml">
          <front>
            <title>User Datagram Protocol</title>
            <author initials="J." surname="Postel" fullname="J. Postel">
              <organization/>
            </author>
            <date year="1980" month="August"/> month="March" year="2023"/>
          </front>
	  <seriesInfo name="STD" value="6"/>
          <seriesInfo name="RFC" value="768"/> name="IEEE Std" value="1588g-2022"/>
	  <seriesInfo name="DOI" value="10.17487/RFC0768"/> value="10.1109/IEEESTD.2023.10070440"/>
        </reference>
        <reference anchor="RFC0791" target="https://www.rfc-editor.org/info/rfc791" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.0791.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/rfc2119" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words

<!-- [rfced] [IEEE1588g]:  We updated the URL for use in RFCs this reference to Indicate Requirement Levels</title>
            <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
point to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices IEEExplore page for the Internet Community, this standard.  Please let us know
any objections.

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

Currently:
 [IEEE1588g]
            IEEE, "IEEE Standard 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/rfc8174" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <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 protocol specifications.  This document aims to reduce the ambiguity by clarifying that 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/rfc8200" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.8200.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>
            <date year="2017" month="July"/>
            <abstract>
              <t>This document specifies version 6 of the Internet a Precision Clock Synchronization
            Protocol (IPv6). It obsoletes RFC 2460.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="86"/>
          <seriesInfo name="RFC" value="8200"/>
          <seriesInfo name="DOI" value="10.17487/RFC8200"/>
        </reference> 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.0768.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.0791.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8200.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="G8271" target="https://www.itu.int"> target="https://www.itu.int/rec/T-REC-G.8271-202003-I/en">
          <front>
            <title>ITU-T G.8271/Y.1366, "Time
            <title>Time and Phase Synchronization Aspects phase synchronization aspects of Packet Networks"</title> telecommunication networks</title>
            <author>
              <organization>International Telecommunication Union</organization>
              <organization>ITU-T</organization>
            </author>
            <date month="3" month="March" year="2020"/>
          </front>
	  <seriesInfo name="ITU-T Recommendation" value="G.8271/Y.1366"/>
        </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">
          <front>
            <title>Plugfest Report</title>
            <author surname="Arnold" initials="D.">
              <organization>International Symposium on Precision Clock
                   Synchronization for Measurement, Control and Communications</organization>
            </author>
            <date month="10" month="October" year="2017"/>
          </front>
        </reference>
        <reference anchor="RFC6241" target="https://www.rfc-editor.org/info/rfc6241" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6241.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" role="editor">
              <organization/>
            </author>
            <author initials="J." surname="Schoenwaelder" fullname="J. Schoenwaelder" 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 document provides mechanisms to install, manipulate, and delete the configuration of network devices.  It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages.

<!-- [rfced] [ISPCS]:  The NETCONF protocol 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/rfc5905" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author initials="D." surname="Mills" fullname="D. Mills">
              <organization/>
            </author>
            <author initials="J." surname="Martin" fullname="J. Martin" role="editor">
              <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 computer 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 protocol header provided URL steers to accommodate the Internet Protocol version 6 address family.  NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs.  It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required.  It corrects certain errors 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 page for moving a
   document between stages and the types of documents used during
ISPCS 2024.  May we update 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/rfc7384" xml:base="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml">
          <front>
            <title>Security Requirements of Time Protocols in Packet Switched Networks</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 increasingly common and widely deployed, concern about their exposure listing to various security threats is increasing.  This document defines a set 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 security requirements for time protocols, focusing on the
            IEEE International Symposium on Precision Time Protocol (PTP) Clock
            Synchronization for Measurement, Control, and the Network Time Protocol (NTP). This document also discusses the security impacts
            Communication (ISPCS), August 2017,
            <https://2017.ispcs.org/plugfest>.

Alternatively (if "2017" is no longer correct or applicable):
 [ISPCS]    Arnold, D., "Plugfest", Proceedings of time protocol practices, the performance implications of external security practices IEEE
            International Symposium on time protocols, and the dependencies between other security services and time synchronization.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7384"/>
          <seriesInfo name="DOI" value="10.17487/RFC7384"/>
        </reference> 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.6241.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5905.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2026.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7384.xml"/>
        <reference anchor="IPv6Registry" target="https://iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml"> target="https://iana.org/assignments/ipv6-multicast-addresses">
          <front>
            <title>IPv6 Multicast Address Space Registry</title>
            <author initials="S." surname="Venaas" fullname="Stig Venaas">
              <organization>Internet Assigned Numbers Authority</organization>
	    <author>
              <organization>IANA</organization>
            </author>
            <date year="2024" month="February"/>
          </front>
        </reference>
      <reference anchor="Estrela_and_Bonebakker" target="https://www.researchgate.net/publication/260742322_Challenges_deploying_PTPv2_in_a_global_financial_company">
          <!-- the following is the minimum to make xml2rfc happy -->
        <front>
           <title>Estrela and Bonebakker, "Challenges
           <title>Challenges deploying PTPv2 in a global financial company"</title> company</title>
              <author initials="P." surname="Estrela" fullname="P. V. Estrela">
                <organization>IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication Proceedings
                </organization>
              </author> Estrela"/>
              <author initials="L." surname="Bonebakker" fullname="L. Bonebakker">
                <organization>IEEE Bonebakker"/>
              <date month="September" year="2012"/>
            </front>
	    <refcontent>Proceedings of the IEEE International Symposium on Precision Clock Synchronization for Measurement, Control and Communication Proceedings
                </organization>
              </author>
              <date year="2012"/>
            </front> Communication, pp. 1-6</refcontent>
          <seriesInfo name="DOI" value="10.1109/ISPCS.2012.6336634"/>
          </reference>
       </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>

<!-- [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>