Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages
draft-ietf-tictoc-ptp-enterprise-profile-28

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-tictoc-ptp-enterprise-profile and RFC 9760, changed IESG state to RFC Published)

[Ballot comment]
Thank you to Susan Hares for the GENART review.

Thanks for addressing my DISCUSS and COMMENT feedback.

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

Per using “https://datatracker.ietf.org/wg/tictoc/documents “ for “sourceIdentification, the IEEE guidance says: "This attribute shall be a URL, e-mail, or regular mail address to which inquiries concerning the profile or requests for copies may be sent.” Consider using the WG mailing list.  I understand that the WG is being shutdown, but I would imaging the responsible AD will keep the list open.

[Ballot comment]
        This PTP Profile MUST operate only in networks characterized by UDP

What does "networks characterized by UDP" mean? My home network sees a lot
more TCP than UDP. Is it still "characterized by UDP" ?



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

Shouldn't this be pointing to https://datatracker.ietf.org/doc/rfcXXXX/
with a note to the RFC Editor to update XXXX ?


The Acknowledgement Section should move to after the IANA Considerations and
Security Considerations section (although I understand the author's desire to express
their pain using the tools they used)

[Ballot comment]
Thank you very much for writing this document - I found it an interesting read.

Also, much thanks to Tim Chown for their excellent Ops-Dir review (https://datatracker.ietf.org/doc/review-ietf-tictoc-ptp-enterprise-profile-24-opsdir-lc-chown-2024-03-07/), and to the authors for addressing the comments; I think that there is still one remaining unaddressed comment ("In practice, would PTP operate over just one or the other, or might messages be duplicated in each protocol?  How does the profile look for a dual-stack environment?").

[Ballot comment]
This seems like what RFC 2026 defines as an Applicability Statement.  Should it say so explicitly?

NTP in the Abstract could use a reference to its RFC.

The SHOULD in Section 5 is bare.  When might an implementer legitimately decide to deviate from the advice given there?  Or maybe MUST is better?

The first SHOULD in Section 9 seems to me to be redundant to the MUST that precedes it.

Is the SHOULD in Section 10 a restatement of the SHOULD in the last paragraph of Section 6?

[Ballot discuss]
** Section 15.

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

            This PTP Profile was specified by the IETF

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

Per Figure 55 of Section 20.3.3 of [IEEE1588], it appears that a few things are missing:

-- missing a profile number (which is distinct from the profile version, but implicit in the profile identifier)

-- Using “https://datatracker.ietf.org/wg/tictoc/documents “ for “sourceIdentification: This attribute shall be a URL, e-mail, or regular mail address to which inquiries concerning the profile or requests for copies may be sent.” Instead of the specific name.

[Ballot comment]
Thank you to Susan Hares for the GENART review.

** idnits reported the following:

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

** Section 1.  Editorial. s/in stead/instead/

** Section 1.
  In PTP domains with a lot
  of nodes, devices had to throw away more than 99% of the received
  multicast messages because they carried information for some other
  node.

What constitutes “a lot of nodes”?

** Section 5.
The PTP system MAY include switches and routers.

What does this mean?  Aren’t switches and routers just computers?

** Section 6.
  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, see IEEE 1588 [IEEE1588] Annex D,
  Section D.3.

The IPv4 address is in Annex C of [IEEE1558].  Annex D is IPv6 only.

[Ballot comment]
Thanks for working on this specification.

I have following comments which I believe would help improving document when addressed -

# Please define Grandmaster more precisely and consistently. In the introduction is says - Grandmaster = active reference time source and in the terminology section is says Grandmaster =  primary timeTransmitter Clock. lets decide which one it is. I am also wondering why we are using the term "Grandmaster". The term "primary reference timeTransmitter" would it clear about the role, why do we need to hide it? (And while the goal is to use inclusive language - GrandMASTER has a master in it.)

# What are "Grandmaster Clusters" and how do we interpret "NOT ALLOWED"?

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-tictoc-ptp-enterprise-profile-26
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-tictoc-ptp-enterprise-profile-26.txt&submitcheck=True

I agree with the comments from Deb Cooley regarding framing of normative language.

## Comments

### Grandmaster term

```
157   *  Best timeTransmitter: A clock with a PTP Port in the
158       timeTransmitter state, operating as the Grandmaster of a PTP
159       domain.
```

Does IEEE1588g define an alternative term for Grandmaster?

Given the other terminology changes, perhaps `primaryTimeTransmitter`, is a better term to use.

Later, the term `Preferred timeTransmitter` is used, is a "Preferred timeTransmitter" always a "primary timeTransmitter Clock within a domain of a PTP system". It seems odd to have the concept of a "preferred primary..." that is a backup... is the alternate timeTransmitter flag set when the "Preferred timeTransmitter" is a backup?

Consider defining Grandmaster cluster as well, given the term appears later:

```
479   timing for delay measurement.  Grandmaster Clusters are NOT ALLOWED.
```

### How to operate in the presence of a rogue timeTransmitter?

```
429   timeTransmitters in their clock control subsystems.  TimeReceiver
430   Clocks MUST be able to operate properly in the presence of a rogue
431   timeTransmitter.  TimeReceivers SHOULD NOT Synchronize to a
```

Its not clear to me how to comply with this MUST, based on the surrounding context.
Perhaps there is a citation that could be given for to answer the question of "how?".

## Nits

### aloted -> alloted

```
357   Section D.3.  These addresses are aloted by IANA, see the Ipv6
```

### ensembled -> assembled

```
373   Domain.  Redundant sources of timing can be ensembled, and/or
```

ensembled is ok, but a more common word might be easier to comprehend for most readers.

### syntonize -> synchronize

```
456   Clocks which syntonize to the timeTransmitter Clock might need to
```

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-tictoc-ptp-enterprise-profile-26

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Erik Kline (the responsible AD :-O ) for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Tommy Pauly, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-tictoc-ptp-enterprise-profile-26-intdir-telechat-pauly-2024-05-09/ (while the review is recent, I was unable to find a reply)


I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

##

# COMMENTS (non-blocking)

## Intended status

Should the IETF publish a standards track document for a IEEE protocol ?

Moreover (see my comments about section 5), it does not seem to be a profile only as it is more about recommendations; i.e., no need for normative language.

## TICTOC charter

The TICTOC charter has an item about profile but it also states that the profile should include a MIB:
```
To develop an IEEE1588v2 profile as necessary for time and frequency
distribution, with primary focus on (1). This profile will include a MIB
module for IEEE1588v2.
```

## Abstract

Please expand PTP acronym before first use.

## Section 1

```
It is considered inefficient that, even if the content of a message applies only to one receiver, it 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.
```

What is meant here by 'underlying network' ? If it is a multi-link routed IP network, then multicast traffic is either dropped by the first router for forwarded efficiently with the use of PIM. If it is layer-2 network (e.g., Ethernet), then remove "(IP)" and note that many if not all NIC are able to drop unwanted mcast packets without CPU cycles.

```
In PTP domains with a lot of nodes, devices had to throw away more than 99% of the received multicast messages because they carried information for some other node.
```

Is there a reference for the above text ? Else, consider removing it (or at least remove the 99% if unfounded).

## Section 4

```
Accuracy currently required in the Financial Industry range from 100 microseconds to 1 nanoseconds to the Grandmaster.
```

Is there a reference for those numbers ?

```
For this reason, it is desired to make use of multicast whenever the information going to many destinations is the same.
```

I find this text weird as I understood in the previous sections that "multicast is not suitable" ?

## Section 5

Out of curiosity, as PTP seems to be an application layer protocol, why is it that `IPv4 and IPv6 instances in the same network node MUST operate in different PTP Domains.` ? I have a little knowledge of PTP, I am trusting the authors for this statement.

As the document is about a profile (in my mind values for parameters not topology), why using normative language in `The PTP system MAY include switches and routers.`? Same for `Thus, wherever possible, the network SHOULD be engineered so that the forward and reverse routes traverse the same physical path.` in section 6. Suggest changing the title of the document and using "recommendations" rather than "profile".

## Section 15

Suggest adding a note to the RFC editor to replace the datatracker reference with the RFC number.

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Erik Kline (the responsible AD :-O ) for the shepherd's detailed write-up including the WG consensus and the justification of the intended status.

Other thanks to Tommy Pauly, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-tictoc-ptp-enterprise-profile-26-intdir-telechat-pauly-2024-05-09/ (while the review is recent, I was unable to find a reply)


I hope that this review helps to improve the document,

Regards,

-éric


# DISCUSS (blocking)

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics:

##

# COMMENTS (non-blocking)

## Intended status

Should the IETF publish a standards track document for a IEEE protocol ?

Moreover (see my comments about section 5), it does not seem to be a profile only as it is more about recommendations; i.e., no need for normative language.

## TICTOC charter

The TICTOC charter has an item about profile but it also states that the profile should include a MIB:
```
To develop an IEEE1588v2 profile as necessary for time and frequency
distribution, with primary focus on (1). This profile will include a MIB
module for IEEE1588v2.
```

## Abstract

Please expand PTP acronym before first use.

## Section 1

```
It is considered inefficient that, even if the content of a message applies only to one receiver, it 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.
```

What is meant here by 'underlying network' ? If it is a multi-link routed IP network, then multicast traffic is either dropped by the first router for forwarded efficiently with the use of PIM. If it is layer-2 network (e.g., Ethernet), then remove "(IP)" and note that many if not all NIC are able to drop unwanted mcast packets without CPU cycles.

```
In PTP domains with a lot of nodes, devices had to throw away more than 99% of the received multicast messages because they carried information for some other node.
```

Is there a reference for the above text ? Else, consider removing it (or at least remove the 99% if unfounded).

## Section 4

```
Accuracy currently required in the Financial Industry range from 100 microseconds to 1 nanoseconds to the Grandmaster.
```

Is there a reference for those numbers ?

```
For this reason, it is desired to make use of multicast whenever the information going to many destinations is the same.
```

I find this text weird as I understood in the previous sections that "multicast is not suitable" ?

## Section 5

Out of curiosity, as PTP seems to be an application layer protocol, why is it that `IPv4 and IPv6 instances in the same network node MUST operate in different PTP Domains.` ? I have a little knowledge of PTP, I am trusting the authors for this statement.

As the document is about a profile (in my mind values for parameters not topology), why using normative language in `The PTP system MAY include switches and routers.`? Same for `Thus, wherever possible, the network SHOULD be engineered so that the forward and reverse routes traverse the same physical path.` in section 6. Suggest changing the title of the document and using "recommendations" rather than "profile".

## Section 15

Suggest adding a note to the RFC editor to replace the datatracker reference with the RFC number.

[Ballot comment]
This review consists of both COMMENTs and NITs.

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 1, paragraph 4
>    PTPv2.1 also includes PTP Profiles (IEEE 1588-2019 [IEEE1588]
>    subclause 20.3).  This construct allows 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 IEEE 1588-2019 [IEEE1588] subclause 13.4), defining an optional
>    Best TimeTransmitter Clock Algorithm and a few other ways.  PTP has
>    its own management protocol (defined in IEEE 1588-2019 [IEEE1588]
>    subclause 15.2) but allows a PTP Profile to specify an alternative
>    management mechanism, for example NETCONF.

While NETCONF is the management protocol that can carry a PTP profile information, the actual profile needs to be defined as part of a YANG model or an augmentation of the existing PTP YANG model. Specifically, RFC 8575 says:
  -  A profile standard based on IEEE Std 1588-2008 may create a
      dedicated YANG module for its profile.  The profile's YANG module
      SHOULD use YANG "import" to import the IEEE Std 1588-2008 YANG
      module as its foundation.  Then the profile's YANG module SHOULD
      use YANG "augment" to add any profile-specific enhancements.
  -  A product that conforms to a profile standard may also create its
      own YANG module.  The product's YANG module SHOULD "import" the
      profile's module, and then use YANG "augment" to add any product-
      specific enhancements.
Where is the work of defining this new profile being done?

Section 15, paragraph 3
>    The IEEE 1588 standard requires that all PTP Profiles provide the
>    following identifying information.
>
>              PTP Profile:
>              Enterprise Profile
>              Version: 1.0
>              Profile identifier: 00-00-5E-00-01-00
>
>              This PTP Profile was specified by the IETF
>
>              A copy may be obtained at
>              https://datatracker.ietf.org/wg/tictoc/documents

I am not an expert in how different profiles are maintained, but is there a common registry where one can go to look for all profiles defined for PTP? For example, I see ITU has define Telecom Profile G8275.1 and G8275.2, and here we have a Enterprise Profile. Are there other profiles? Does it make sense to define a registry? In IANA?

At the same time, I realize that it is not this documents responsibility to collect all the profiles, but creating a registry might enable profiles to be registered in one location.

Section 18, paragraph 2
>    PTP native management messages SHOULD NOT be used, due to the lack of
>    a security mechanism for this option.  Secure management can be
>    obtained using standard management mechanisms which include security,
>    for example NETCONF NETCONF [RFC6241].
In general, the document should refer to both NETCONF and RESTCONF[RFC8040]; the latter also provides a secure mechanism to distribute management information.

This document uses the RFC2119 keywords "SHALL NOT", "RECOMMENDED", "SHALL",
"MAY", "NOT RECOMMENDED", "SHOULD NOT", "SHOULD", "MUST NOT", "MUST",
"REQUIRED", and "OPTIONAL", but does not contain the recommended RFC8174
boilerplate. (It contains some text with a similar beginning.)

The IANA review of this document seems to not have concluded yet.

Possible DOWNREF from this Standards Track doc to [IEEE1588g]. If so, the IESG
needs to approve it.

Possible DOWNREF from this Standards Track doc to [IEEE1588]. If so, the IESG
needs to approve it.

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

* Term "master"; alternatives might be "active", "central", "initiator",
  "leader", "main", "orchestrator", "parent", "primary", "server"
* Term "slave"; alternatives might be "follower", "peripheral", "replica",
  "responder", "secondary", "standby", "worker"
* Term "traditional"; alternatives might be "classic", "classical", "common",
  "conventional", "customary", "fixed", "habitual", "historic",
  "long-established", "popular", "prescribed", "regular", "rooted",
  "time-honored", "universal", "widely used", "widespread"
* Term "native"; alternatives might be "built-in", "fundamental", "ingrained",
  "intrinsic", "original"

Found IP block or address not inside RFC5737/RFC3849 example ranges:
"224.0.1.129".

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Duplicate normative references to: https://www.ieee.org.

Section 3, paragraph 13
> randmaster of a PTP system, or as a back up to a Grandmaster. * PTP: The Prec
>                                    ^^^^^^^
When "back-up" is used as a noun or modifier, it needs to be hyphenated.

Section 3, paragraph 21
> sm for PTP timeReceivers to establish a unicast communication with PTP timeTr
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 3, paragraph 26
>  range from 100 microseconds to 1 nanoseconds to the Grandmaster. This PTP P
>                                ^^^^^^^^^^^^^
Please verify that the plural noun "nanoseconds" is in agreement with the
quantifier "1". Did you mean to use the singular form?

Section 4, paragraph 1
> ich is only relevant to one device as a unicast message. The latter can be e
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 7, paragraph 1
> r the number of UTC leap seconds. If a unicast negotiation signaling message
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 9, paragraph 1
> , a Transparent Clock MUST NOT change a unicast message to a multicast messa
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 9, paragraph 2
> is not set to All 1s, MUST be sent as a unicast message. Similarly, if any s
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 14, paragraph 1
> or PTP? For example, I see ITU has define Telecom Profile G8275.1 and G8275.
>                                    ^^^^^^
It appears that the past participle should be used here.

Section 14, paragraph 1
> G8275.1 and G8275.2, and here we have a Enterprise Profile. Are there other p
>                                      ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 14, paragraph 1
> s later been converted manually into xml format using an xml2rfc template. 1
>                                      ^^^
File types are normally capitalized.

Section 14, paragraph 1
> verted manually into xml format using an xml2rfc template. 17. IANA Consider
>                                      ^^
Use "a" instead of "an" if the following word doesn't start with a vowel sound,
e.g. "a sentence", "a university".

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-tictoc-ptp-enterprise-profile-26

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.


#HIGH LEVEL COMMENTS
#===================
## Thank you for this write up. The documents reads well for a network generalist as myself.

## One item kept confusing me was about delay. Is this the minimal delay of the link
or some overage? does it include queueing or QoS properties? Maybe some words about these
assuptions would be good to set the stage for the ongoing usage of 'delay'

## on line 258 it is written that this document describes a version of PTP while my
nderstanding was that ptp was an IEE standard. ow can IETF describe a new version of ptp?
I assume my understanding of the wording 'describes a version of PTP' is incorrect. Please confirm

## There is some assumption around line 320 about IPv4 addresses behind a NAT. I was
slightly surprised to not see a discussin around IPv6 and address selection finding
and using an address of the wrong scope. Is this not a consern for ptp in the context of this document?

## some non compliant to RFC2119 normative language is used "NOT ALLOWED ". Is that intentional?


#DETAILED COMMENTS
#=================
##classified as [minor] and [major]

14   This document describes a PTP Profile for the use of the Precision
15   Time Protocol in an IPv4 or IPv6 Enterprise information system
16   environment.  The PTP Profile uses the End-to-End delay measurement

[minor] What about following suggestion for start of abstract?
"This document outlines a PTP Profile for the use of the Precision Time
Protocol within an IPv4 or IPv6 Enterprise Information System environment."

86   master, and timeReceiver, in stead of slave, as defined in the IEEE

[minor] typo
s/in stead/instead/

102   The third edition of the standard (IEEE 1588-2019) defines PTPv2.1

[minor] I am not sure i discovered the 2nd edition of in the earlier
text. I know very little about this technology, so i may have missed the
subtle description.

103   and includes the possibility to use unicast communication between the
104   PTP nodes in order to overcome the limitation of using multicast
105   messages for the bi-directional information exchange between PTP

[minor] disclaimer that my ptp knowledge is not existing. This phrase
seems to indicate that the restriction is that communication
in both directions is muticast. In most tehnologoes the server side sends
mcast to everybody and then the clients pick up the mcast messags and
complete the remainder with unicast packets. Is this not happening
with ptp first and second version?

111   PTPv2.1 also includes PTP Profiles (IEEE 1588-2019 [IEEE1588]
112   subclause 20.3).  This construct allows organizations to specify
113   selections of attribute values and optional features, simplifying the
114   configuration of PTP nodes for a specific application.  Instead of
115   having to go through all possible parameters and configuration
116   options and individually set them up, selecting a PTP Profile on a
117   PTP node will set all the parameters that are specified in the PTP
118   Profile to a defined value.  If a PTP Profile definition allows
119   multiple values for a parameter, selection of the PTP Profile will
120   set the profile-specific default value for this parameter.

[minor] are there any profiles that are industry standard and well known?
or is this all local to the site or the ptp server-client relationship?

143 3.  Technical Terms
145   *  Acceptable TimeTransmitter Table:
149   *  Alternate timeTransmitter:

[minor] This section has terminology that either starts with single capital
and others that have words with more as a single capital. Is this intentional?


204   *  Peer-to-Peer delay measurement mechanism: A network delay
205       measurement mechanism in PTP facilitated by an exchange of
206       messages over the link between adjacent devices in a network.

[minor] does adjacent mean L2 adjacent or L3 session/tunneled adjacent between peers?

210   *  Preferred timeTransmitter: A device intended to act primarily as
211       the Grandmaster of a PTP system, or as a back up to a Grandmaster.

[minor] How is the correlation with the Best timeTransmitter as mentioned above?
The differentiation betweenGrandmaster and Best timeTransmitter confuses me a slightly.

221   *  PTP Profile: A set of constraints on the options and features of
222       PTP, designed to optimize PTP for a specific use case or industry.
223       The profile specifies what is required, allowed and forbidden
224       among options and attribute values of PTP.

[minor] is this Profile a local network construct or something are there profiles
that are well known in the industry?

232       Algorithm, and does not set the Alternate timeTransmitter flag.

[minor] not sure if this should be 'does not' or 'has not'?

258   This document describes a version of PTP intended to work in large
259   enterprise networks.  Such networks are deployed, for example, in

[major] I assumed from earlier text that ptp was an IEEE specification.
How can IETF outline a new version of ptp when it is owned by IEEE?

272   a traditional time transfer such as NTP, without adding non-standard
273   customizations such as on-path support, similar to what is done in
274   PTP with Transparent Clocks and Boundary Clocks.  Such PTP support is

[minor] what does 'on-path' exactly mean support mean in the context of ptp?

281   Although enterprise networks can be large, it is becoming
282   increasingly common to deploy multicast protocols, even across
283   multiple subnets.  For this reason, it is desired to make use of

[minor] 'even across multiple subnets'. This is oddly written.
If there is a single subnet then ther eis no need for multicast protocols
because all is a single flooding domain. The need for multicast protocols
comes when there is need for multicast to sent between L3-subnets. Maybe the
subnets refered to here are not L3-subnets but administrative boundaries or so?

285   same.  It is also advantageous to send information which is only
286   relevant to one device as a unicast message.  The latter can be

[minor] yes, advantageous, assuming hte message is sent to the intended
target device :-)

299   This PTP Profile MUST operate only in networks characterized by UDP
300   RFC 768 [RFC0768] over either IPv4 RFC 791 [RFC0791] or IPv6 RFC 8200
301   [RFC8200], as described by Annexes C and D in IEEE 1588 [IEEE1588]
302   respectively.  A network node MAY include multiple PTP instances

[minor] i am not entirely sure what 'charactarized' means in the above phrase.
Is is intended to say 'operate exclusively' maybe?

What about this proposal:
"This PTP Profile MUST operate exclusively in networks using UDP as defined
in RFC 768 [RFC0768] over either IPv4 [RFC0791] or IPv6 [RFC8200], as
detailed in Annexes C and D of IEEE 1588 [IEEE1588], respectively."

320   PTP messages are retranmitted.  In IPv4 networks some clocks might be
321   hidden behind a NAT, which hides their IP addresses from the rest of
322   the network.

[major] in IPv6 networks the source address selection mechanisms may have
selected an IPv6 address unknown (for example due to different address
scope usage) to the recipient. Is that something to consider
or detail?

332   the PTP system from meeting the timing requirements.  The details of
333   network asymmetry are outside the scope of this document.  See for
334   example, ITU-T G.8271 [G8271].

[minor] what about queing delays when different queue are used for the
traffic due to QoS? I assume this wil be out of scope also. Maybe
worthwile to add that consideration. The delay assumed will be the min delay
of link (not the avg or max or anything else). If for example the link is
a fiber then the delay should be the result of the length of te link and
speed of light through the fiber. Are other delays included in the procedure
proposed with this document?

479   timing for delay measurement.  Grandmaster Clusters are NOT ALLOWED.

[major] the NOT ALLOWED seems not official formal RFC2119 language.

[Ballot comment]

Thank you to Tero Kivinen for his careful review of draft 24.  While some of his of his points were addressed, there are still some that remain in draft 26.  I will only highlight a few of these:
  - The use of MUST NOT in cases where a positive requirement could be used, where a direct requirement of MUST can be used.  Often MUST is clearer to understand.
  - For PTP Management messages, the discrepency of 'MAY' in Section 12 and SHOULD NOT in Section 18 need to be reconciled.  (My recommendation would be to change Section 12 to 'SHOULD NOT')

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-tictoc-ptp-enterprise-profile-24, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-03-05):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tictoc-ptp-enterprise-profile@ietf.org, ek.ietf@gmail.com, tictoc-chairs@ietf.org, tictoc@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Enterprise Profile for the Precision Time Protocol With Mixed Multicast and Unicast messages) to Proposed Standard


The IESG has received a request from the Timing over IP Connection and
Transfer of Clock WG (tictoc) to consider the following document: -
'Enterprise Profile for the Precision Time Protocol With Mixed
  Multicast and Unicast messages'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-03-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document describes a PTP Profile for the use of the Precision
  Time Protocol in an IPv4 or IPv6 Enterprise information system
  environment.  The PTP Profile uses the End-to-End delay measurement
  mechanism, allows both multicast and unicast Delay Request and Delay
  Response messages.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/



No IPR declarations have been submitted directly on this I-D.

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  The working group itself is very small.  That said, this document has
  working group consensus.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  No.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Yes; from S4 of the document:

  Interoperability among independent implementations of this PTP Profile has
  been demonstrated at the ISPCS Plugfest.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  This work touches on IEEE PTP work.  Co-ordination was called out in the
  working group charter, and several IEEE participants have participated in
  the drafting and review of this document.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  Not applicable.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  Not applicable.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  Not applicable.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    None; none.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    PS.  This document specifies an enterprise profile and uses requirements
    language for the purpose of implementation conformance evaluation.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    No IPR claims; authors confirmed.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    I-D nits complains about lack of 2119 but 8174 text is used.  Not sure
    what the issue is there.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    The document contains normative references to IEEE 1588 specifications.
    Group members had sufficient access to these (PTP specifications).

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    No IANA considerations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    None.

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Internet AD comments for {draft-ietf-tictoc-ptp-enterprise-profile-22}
CC @ekline

## Comments

### S1

* "PTPv2.1 also includes PTP profiles..."

  I think thing may read better if this marks the start of a new paragraph.

### S2

* Please update to RFC 8174 (8174 S2).

### S3

* The use of the term "port" was pretty confusing until I got down to the
  description of "PTP port".

  This terminology seems sufficiently different from NTP, and multiple
  possible IETF meanings of "port", that it's probably worth adding a short
  explainer paragraph in Section 1 (maybe add on to the end).

* Does "NTP" refer specifically to NTPv4 (i.e. RFC 5905) or can it also
  refer to future versions of NTP (e.g., the v5 work currently underway)?

## Nits

### Abstract

* s/IPV4/IPv4/

### S3

* "configures table" -> "configured table"

* "Sync, announce and Delay Request" -> "Sync, Announce, and Delay Request"

### S6

* "Ipv6" -> "IPv6"

* s/man-in-the-middle attacks/on-path attacks/

### S9

* s/from the all/from all the/

### S10

* s/syntonize/synchronize/

### S18

* s/man-in-the-middle attacks/on-path attacks/

  It might also be fair to note that Transparent Clocks are a form of
  on-path manipulation, but one that aids in achieving the timing objectives.

* s/SHOULD not/SHOULD NOT/

Note: This document has reached working group consensus and passed WGLC. Minor issues raised during the WGLC will be incorporated by the document editors. Upon completion of this update, the document will be ready to send to the IESG.