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 consensus is strong of course taking into consideration the
small size of the NTP working group.
2. Was there controversy about particular points, or were there
decisions where the consensus was particularly rough?
There was no controversy in the final version of the document. Early versions
required coordination with the IEEE 1588 (formally the IEEE IM/ST/PNCS Working
Group) that is responsible for the Precision Time Protocol (PTP).
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.)
There are no threats of appeal or discontent.
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 recommends) or elsewhere (where)?
There is an existing implementation of this standard. See the implementation
notes in the draft.
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 document provides a mechanism to run NTP over PTP thereby allowing NTP to
utilize the hardware timestamping in NICs that support PTP. This document has
been closely coordinated with and reviewed by the IEEE 1588 working group that
is responsible for the PTP standard.
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.
There are no required formal expert reviews required for the document.
7. If the document contains a YANG module, has the final version
of the module been checked with any of the recommended validation
tools 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?
This document does not contain a YANG module.
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.
None of these reviews or automated checks are applicable to this document.
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?
This document is a useful addition to help NTP access more precise timestamping
hardware. Additionally, it is clear, concise, and ready to be reviewed by the
broader IETF for approval.
10. Several IETF Areas have assembled lists of common issues that
their reviewers encounter. For which areas have such issues been
identified and addressed? For which does this still need to happen in
subsequent reviews?
No issues have been identified from this list. The one source of possible
confusion is the use of PTP as a transport for NTP. This was coordinated with
IEEE 1588 and had some individual IETF review as well.
11. What type of RFC publication is being requested on the IETF
stream (Best Current Practice, Proposed Standard, Internet Standard,
Informational, Experimental or Historic)? Why is this the proper type
of RFC? Do all Datatracker state attributes correctly reflect this
intent?
Proposed Standard.
12. Have reasonable efforts been made to remind all authors of the
intellectual property rights (IPR) disclosure obligations described
in BCP 79? 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.
To my knowledge, there are no required disclosures for this document.
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.
There is only one author of this document, and he is clearly willing to be
listed as such.
14. Document any remaining I-D nits in this document. Simply
running the idnits tool is not enough; please review the "Content
Guidelines" on authors.ietf.org. (Also note that the current idnits
tool generates some incorrect warnings; a rewrite is underway.)
In running I-D nits on the -04 version resulting in two comments and no errors,
flaws, or warnings. The two comments are both not real issues. It appears to
comply with all the content guidelines.
15. Should any informative references be normative or vice-versa?
See the IESG Statement on Normative and Informative References.
All references are accurate.
16. List any normative references that are not freely available to
anyone. Did the community have sufficient access to review any such
normative references?
There is a normative reference to IEEE std. 1588-2019, "IEEE Standard for a
Precision Clock Synchronization Protocol for Networked Measurement and Control
Systems, November 2019. This document is not freely available; however, the
IEEE 1588 Working Group gave permission for the chairs to share the document
with anyone who requested it. For the IETF Last Call, this same offer will be
made to reviewers. The IESG can decide whether the request point should be the
NTP WG chairs or the AD (Erik Kline).
17. Are there any normative downward references (see RFC
3967 and BCP 97) that are not already listed in the DOWNREF registry?
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).
This document adds an entry to an existing registry (NTP Extension Field Types
Registry).
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.
This document creates a new registry (IANA PTP TLV Subtypes Registry). The
rules for additions to this registry have not been defined in this document.