Document: draft-ietf-ippm-capacity-protocol Title: Test Protocol for One-way IP Capacity Measurement Reviewer: Benson Muite Review result: Ready with Issues I am an assigned INT directorate reviewer for draft-ietf-ippm-capacity-protocol. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>. The draft explains how to measure "internet speed" in both laboratory and real world settings. Such measurements are useful for internet service provider quality of service guarantees as well as for end users to be able to determine what activities they can connect to without difficulty. Figure 1 is particularly clear on what the measurment entails. Based on my review, if I was on the IESG I would ballot this document as DISCUSS. I have the following DISCUSS/ABSTAIN level issues: The draft is useful, however the internet directorate is concerned with the expected depletion of IPv4 addresses. As such taking measurements only with the first returned IP address whether it is IPv4 or IPv6 is not helpful to end users. Ideally both would be reported if both are available as they may not be the same. The following are other issues I found with this document that SHOULD be corrected before publication: PDU is first used on pg. 5, but the acronym is not expanded. May be helpful to expand it on its first use, perhaps even give a reference. From rfc5044, rfc5041, rfc4712, rfc1905, draft-ietf-sidrops-8210bis-13 assume this acronym is Protocol Data Unit. Note that Expired draft-ietf-dmm-5g-uplane-analysis-04 indicates that Protocol Data Units may incorporate slightly different fields in 3GPP as compared to the IETF. On Pg 20, please add units to: #define CHSR_CRSP_NOMAXBW 9 // Max bandwidth required and uint16_t maxBandwidth; // Required bandwidth The following are minor issues (typos, misspelling, minor text improvements) with the document: UDPSTP (UDP Speed Test Protocol) - acronym should be introduced the first time the phrase is used in the introduction. While speed test is in common use, being more precise and calling it a bandwidth/capacity test maybe useful. Many users now also care about latency due to video conferencing applications and online gaming applications and may want quality of service guarantees for these in addition to being able to download data. Motivation for the optional modes in sections 4.2.3 and 4.2.4 is unclear. Why are they specified? Why not make 4.2.3 part of the default specified in 4.2.2? Referring to RFC7594 when introducing the encrypted mode maybe helpful, rather than only in the security considerations section. When there are multiple connections, should tests be done on each connection alone and then on all of them at once or on some combination of them depending on end user needs? Section 4.3 has: "While key rotation and related management specifics are regarded as important, these features are beyond the scope of this document." This does not seem accurate. Key lifetimes should be short enough that rotation is not required. In section 5.1 pg 14, what does AB stand for in "big-endian AB"? In Figure 2, why choose the names reserved1, reserved2 and reserved1a? On pg 22, any suggestions for typical watchdog timer lifetime? Measurements that limit server availability maybe a concern. In section 4.2 perhaps "two authenticated modes and a forth adding encryption." should be "two authenticated modes and a fourth adding encryption." -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
