RFC editor,
Thanks for finding lots of nits. Here are answers from the authors to your
questions,
1) single initial is fine for us
2) confirm that we do not need to change the document
3) The relevant part in [Estrela_and_Bonebakker] is this:
" Unfortunately, this option is not scalable, because all clients from all
clusters will be continuously receiving foreign packets at user space, only to
be silently discarded. "
So we agree that there is no number / specific value mentioned. The >99% have
been chosen to express that the overwhelming majority of all received packets
are affected. We would keep it this way.
4) We agree with the suggested change
5) We agree with the proposed change, an alternate timeTransmitter can become
the best TimeTransmitter at any time, so „that“ is more accurate than „which“.
6) We agree with the suggested change
7) We agree with the suggested change
8) No objections
9) We believe the link to the reference is wrong. You are correct, there is no
relationship to RFC2026, the link should have pointed to the [ISPCS] reference
(which is listed right above the RFC2026 reference in the Informative
References section.
10) All references are valid for IEEE 1588-2019.
11) We believe the intention was to avoid the impression that the ITU-T
reference is the one and only document that explains network asymmetry. That is
why the „for example“ has been chosen. As this topic is out of scope, we did
not want to research and provide an extensive list of documents and just wanted
to give an example. I would be OK with removing this reference, if the „for
example“ is not acceptable.
12) We agree with the suggested change
13) We agree with the suggested change
14) We agree with the proposed text ("such as delay attacks, packet
interception attacks, and packet manipulation attacks“)
15) We agree with the proposed text ("the timeTransmitter ports' preferred
message period")
16) We believe it must be changed to „Announce Receipt Timeout Interval“
17) "Syntonize" i.e., frequency synchronization is used purposely to
distinguish it from time synchronization, which we often shorten to simply
synchronization.
18) We suggest changing "is not set to All 1s" to "does not have all bits set
to 1".
19) We agree with the proposed change, i.e., to make it a list
20) This is not a direct quote from IEEE 1588. We agree with the rearranged
format.
21) We agree with the change
22) We agree with the change
23) We agree with the change
24) We agree with the change and prefer the "suggested" change rather than the
"alternatively" change
25) Native management is the term used informally in the PTP community, but the
term does appear in IEEE 1588-2019 or IEEE 1588-2008. Both versions of IEEE
1588 refer to it as "PTP manange messages", so the word native should be
removed from our draft. Also "a traditional time tranfer such as NTP" should
be changed to simply "NTP".
26) We prefer the following:
"Alternate timeTransmitter"
"Best timeTransmitter" except when used in the term "Best TimeTransmitter Clock
Algorithm
"End-to-End delay measurement"
"enterprise" used generally, i.e. not referring to the "Enterprise Profile"
"Enterprise Profile clock"
"Peer-to-Peer delay measurement mechanism"
"Preferred timeTransmitter"
"PTP clock"
"PTP domain"
"PTP management messages"
"PTP Networks"
"PTP Node"
"PTP Port" is correct
"timeReceiver" unless it is the beginning of a sentence.
"timeReceiver only clock". Change all three instances to this.
"unicast message negotiation"
Let me know if you have further questions.
Regards,
Doug
________________________________
From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>
Sent: Monday, March 24, 2025 5:11 PM
To: Doug Arnold <doug.arn...@meinberg-usa.com>; heiko.gerst...@meinberg.de
<heiko.gerst...@meinberg.de>
Cc: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org>; tictoc-...@ietf.org
<tictoc-...@ietf.org>; tictoc-cha...@ietf.org <tictoc-cha...@ietf.org>;
ek.i...@gmail.com <ek.i...@gmail.com>; ek.i...@gmail.com <ek.i...@gmail.com>;
auth48archive@rfc-editor.org <auth48archive@rfc-editor.org>
Subject: Re: AUTH48: RFC-to-be 9760
<draft-ietf-tictoc-ptp-enterprise-profile-28> for your review
Authors,
While reviewing this document during AUTH48, please resolve (as necessary) the
following questions, which are also in the XML file.
1) <!-- [rfced] First-page header: Authors, we have updated both of your names
in
the first-page header to use a single initial rather than two
initials. Please let us know if you prefer to use two initials. Note that
Heiko's name was listed with a single initial in the first-page header of
RFC 5907.
For more information about author names in the first-page header, please see
Section 4.1.1 of RFC 7322 ("RFC Style Guide").
-->
2) <!-- [rfced] We see the following warning in idnits output:
"There are 1 instance of lines with multicast IPv4 addresses in the
document. If these are generic example addresses, they should be changed
to use the 233.252.0.x range defined in RFC 5771"
It appears that idnits confused multicast addresses with the PTP
primary IP address (for IPv4) listed in Section 6, but we want to
point out the idnits warning all the same. It appears that we don't
need to make any changes. Please review and confirm.
Original:
The PTP primary IP address is
224.0.1.129 for IPv4 and FF0X:0:0:0:0:0:0:181 for IPv6, where X can
be a value between 0x0 and 0xF. -->
3) <!-- [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% (Estrela and Bonebakker
[Estrela_and_Bonebakker]). -->
4) <!-- [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). -->
5) <!-- [rfced] Section 3: Does this definition indicate that a PTP
timeTransmitter Clock is 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.
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. -->
6) <!-- [rfced] Section 3: "timeTransmitter Clock properties of a
timeTransmitter Clock" reads oddly. Should the wording be different?
If the suggested text is not correct, please clarify.
Original:
* Announce message: Contains the timeTransmitter Clock properties of
a timeTransmitter Clock. Used to determine the Best
TimeTransmitter.
Suggested:
Announce message: Contains the properties of a given
timeTransmitter Clock. The information is used to determine the
Best TimeTransmitter. -->
7) <!-- [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.
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. -->
8) <!-- [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.
... -->
9) <!-- [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. -->
10) <!-- [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. -->
11) <!-- [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. -->
12) <!-- [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. -->
13) <!-- [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. -->
14) <!-- [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. -->
15) <!-- [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. -->
16) <!-- [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. -->
17) <!-- [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. -->
18) <!-- [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. -->
19) <!-- [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 -->
20) <!-- [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
Currently:
The IEEE 1588 standard requires that all PTP Profiles provide the
following identifying information.
PTP Profile: Enterprise Profile
Profile number: 1
Version: 1.0
Profile identifier: 00-00-5E-01-01-00
This PTP Profile was specified by the IETF.
A copy may be obtained at <https://datatracker.ietf.org/wg/tictoc/
documents>.
-->
21) <!-- [rfced] [IEEE1588]: We updated the URL for this reference to
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>. -->
22) <!-- [rfced] [IEEE1588g]: We updated the URL for this reference to
point to the IEEExplore page for this standard. Please let us know
any objections.
Original:
[IEEE1588g]
Institute of Electrical and Electronics Engineers, "IEEE
std. 1588g-2022, "IEEE Standard for a Precision Clock
Synchronization Protocol for Networked Measurement and
Control Systems Amendment 2: Master-Slave Optional
Alternative Terminology"", December 2022,
<https://www.ieee.org>.
Currently:
[IEEE1588g]
IEEE, "IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems
Amendment 2: Master-Slave Optional Alternative
Terminology", IEEE Std 1588g-2022,
DOI 10.1109/IEEESTD.2023.10070440, March 2023,
<https://ieeexplore.ieee.org/document/10070440>. -->
23) <!-- [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>. -->
24) <!-- [rfced] [ISPCS]: The provided URL steers to the page for
ISPCS 2024. May we update this listing to reflect the 2017
conference?
Original:
[ISPCS] Arnold, D., "Plugfest Report", October 2017,
<https://www.ispcs.org>.
Suggested:
[ISPCS] Arnold, D. and K. Harris, "Plugfest", Proceedings of the
IEEE International Symposium on Precision Clock
Synchronization for Measurement, Control, and
Communication (ISPCS), August 2017,
<https://2017.ispcs.org/plugfest>.
Alternatively (if "2017" is no longer correct or applicable):
[ISPCS] Arnold, D., "Plugfest", Proceedings of the IEEE
International Symposium on Precision Clock
Synchronization for Measurement, Control, &
Communication (ISPCS), October 2024,
<https://www.ispcs.org>. -->
25) <!-- [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. -->
26) <!-- [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) -->
Thank you.
RFC Editor/lb/rv
On Mar 24, 2025, at 2:08 PM, rfc-edi...@rfc-editor.org wrote:
*****IMPORTANT*****
Updated 2025/03/24
RFC Author(s):
--------------
Instructions for Completing AUTH48
Your document has now entered AUTH48. Once it has been reviewed and
approved by you and all coauthors, it will be published as an RFC.
If an author is no longer available, there are several remedies
available as listed in the FAQ (https://www.rfc-editor.org/faq/).
You and you coauthors are responsible for engaging other parties
(e.g., Contributors or Working Group) as necessary before providing
your approval.
Planning your review
---------------------
Please review the following aspects of your document:
* RFC Editor questions
Please review and resolve any questions raised by the RFC Editor
that have been included in the XML file as comments marked as
follows:
<!-- [rfced] ... -->
These questions will also be sent in a subsequent email.
* Changes submitted by coauthors
Please ensure that you review any changes submitted by your
coauthors. We assume that if you do not speak up that you
agree to changes submitted by your coauthors.
* Content
Please review the full content of the document, as this cannot
change once the RFC is published. Please pay particular attention to:
- IANA considerations updates (if applicable)
- contact information
- references
* Copyright notices and legends
Please review the copyright notice and legends as defined in
RFC 5378 and the Trust Legal Provisions
(TLP – https://trustee.ietf.org/license-info).
* Semantic markup
Please review the markup in the XML file to ensure that elements of
content are correctly tagged. For example, ensure that <sourcecode>
and <artwork> are set correctly. See details at
<https://authors.ietf.org/rfcxml-vocabulary>.
* Formatted output
Please review the PDF, HTML, and TXT files to ensure that the
formatted output, as generated from the markup in the XML file, is
reasonable. Please note that the TXT will have formatting
limitations compared to the PDF and HTML.
Submitting changes
------------------
To submit changes, please reply to this email using ‘REPLY ALL’ as all
the parties CCed on this message need to see your changes. The parties
include:
* your coauthors
* rfc-edi...@rfc-editor.org (the RPC team)
* other document participants, depending on the stream (e.g.,
IETF Stream participants are your working group chairs, the
responsible ADs, and the document shepherd).
* auth48archive@rfc-editor.org, which is a new archival mailing list
to preserve AUTH48 conversations; it is not an active discussion
list:
* More info:
https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
* The archive itself:
https://mailarchive.ietf.org/arch/browse/auth48archive/
* Note: If only absolutely necessary, you may temporarily opt out
of the archiving of messages (e.g., to discuss a sensitive matter).
If needed, please add a note at the top of the message that you
have dropped the address. When the discussion is concluded,
auth48archive@rfc-editor.org will be re-added to the CC list and
its addition will be noted at the top of the message.
You may submit your changes in one of two ways:
An update to the provided XML file
— OR —
An explicit list of changes in this format
Section # (or indicate Global)
OLD:
old text
NEW:
new text
You do not need to reply with both an updated XML file and an explicit
list of changes, as either form is sufficient.
We will ask a stream manager to review and approve any changes that seem
beyond editorial in nature, e.g., addition of new text, deletion of text,
and technical changes. Information about stream managers can be found in
the FAQ. Editorial changes do not require approval from a stream manager.
Approving for publication
--------------------------
To approve your RFC for publication, please reply to this email stating
that you approve this RFC for publication. Please use ‘REPLY ALL’,
as all the parties CCed on this message need to see your approval.
Files
-----
The files are available here:
https://www.rfc-editor.org/authors/rfc9760.xml
https://www.rfc-editor.org/authors/rfc9760.html
https://www.rfc-editor.org/authors/rfc9760.pdf
https://www.rfc-editor.org/authors/rfc9760.txt
Diff file of the text:
https://www.rfc-editor.org/authors/rfc9760-diff.html
https://www.rfc-editor.org/authors/rfc9760-rfcdiff.html (side by side)
Diff of the XML:
https://www.rfc-editor.org/authors/rfc9760-xmldiff1.html
Tracking progress
-----------------
The details of the AUTH48 status of your document are here:
https://www.rfc-editor.org/auth48/rfc9760
Please let us know if you have any questions.
Thank you for your cooperation,
RFC Editor
--------------------------------------
RFC9760 (draft-ietf-tictoc-ptp-enterprise-profile-28)
Title : Enterprise Profile for the Precision Time Protocol With
Mixed Multicast and Unicast messages
Author(s) : D. Arnold, H. Gerstung
WG Chair(s) : Yaakov (J) Stein, Karen O'Donoghue
Area Director(s) : Erik Kline, Éric Vyncke
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
