Éric Vyncke has entered the following ballot position for draft-ietf-tictoc-ptp-enterprise-profile-26: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tictoc-ptp-enterprise-profile/ ---------------------------------------------------------------------- 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. _______________________________________________ TICTOC mailing list -- [email protected] To unsubscribe send an email to [email protected]
