Hi Benson, thanks for your review and sorry for the delayed response. Please find remarks of the authors marked [Authors] below. I'll try to post a version -15 later today addressing changes on the registry and some of Benson's comments. Please note, 1. May is a bank holiday over here and I'll be off on Friday. I'll pick up work Monday again. Regards, Ruediger -----Ursprüngliche Nachricht----- Von: Benson Muite via Datatracker <noreply@xxxxxxxx> Gesendet: Montag, 21. April 2025 19:38 An: int-dir@xxxxxxxx Cc: draft-ietf-ippm-capacity-protocol.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx Betreff: Intdir ietf last call review of draft-ietf-ippm-capacity-protocol-14 < snip > 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. [RG] I failed to ask Len for consent and I don't want to cause further delays. My suggestion If a server instance is identified with a host name that resolves to both IPv4/IPv6 addresses, it is recommended to use the first address returned in the name resolution response - regardless, whether it's IPv4 or IPv6. ADD: Thus the decision on the preferred IP address family is left to the DNS operator. Support for separate IPv4 and IPv6 measurements or an IPv4 and IPv6 multi connection setup are left for future improvement. --------------- 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. [Authors]: Section 3, last para before list: The protocol uses UDP transport [RFC0768] with two connection phases (Control and Data). The exchanges 1 and 2 (see below) constitute the Control phase, while exchanges 3 and 4 constitute the Data phase. ADD: In this document, the term message and the term Protocol Data Unit, or PDU ([RFC 5044]) are used exchangeable. -------------- On Pg 20, please add units to: #define CHSR_CRSP_NOMAXBW 9 // Max bandwidth required [Authors]: This is an error indication (No Maximum test Bit rate specified) and uint16_t maxBandwidth; // Required bandwidth [Authors]: Thanks, NEW: uint16_t maxBandwidth; // Required bandwidth in Mbps -------------- 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. [Authors]: Done (but other way around): This document specifies the UDP Speed Test Protocol (UDPSTP) enabling the measurement of Network Capacity metrics as defined by [RFC9097] 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. [Authors]: Is the above statement ... enabling the measurement of Network Capacity metrics as defined by [RFC9097]... not clear enough? Or do you propose something like ... Network Capacity metrics (commonly called bandwidth)..? Should be terminology which isn't raising new comments for being unprecise. ------------- 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. [Authors]: Section 4.2, last para, ADD :... PDU sender and receiver can be re-used and referred to by other sections within this document. Each successive mode increases security, but comes with additional performance impacts and complexity. The protocol is used with unsubstantial payload and it may operate on very low-end devices. Offering the flexibility of various security operation modes allows for adoption of available end-device resources. In general, an active measurement technique as the one defined by this document is better suited to protect the privacy of those involved in measurement [RFC7594]. -------------- 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? [Authors]: Multi-connection tests are simply multi-flow tests where the additional flow are intended to exercise additional queues and/or perhaps additional links in a LAG. A user can always run a single flow test followed by a multi-flow test. -------------- 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. [Authors]: NEW "The lifetime of the long-lived keys deployed is expected be on the order of double digit seconds to avoid pending congestion of the measured bottleneck. Key rotation and related management specifics are beyond the scope of this document." --------------- In section 5.1 pg 14, what does AB stand for in "big-endian AB"? [Authors]: NEW big-endian AB (most significant to least significant byte) ---------------- In Figure 2, why choose the names reserved1, reserved2 and reserved1a? [Authors]: Some name was required for the fields needed to maintain proper alignment of 16 and 32 bit fields (to prevent them from starting on an odd memory boundary). The name "reserved1a" was specifically used because it resides in the authentication section which is identical in each PDU (and we didn't want it called different names depending on how many reserved fields existed before it in the unique portion of the PDU). ----------------- On pg 22, any suggestions for typical watchdog timer lifetime? Measurements that limit server availability maybe a concern. [Authors]: 5. Test Setup Request and Response, third para: The watchdog timeout is configured as a 1 second... -------------- In section 4.2 perhaps "two authenticated modes and a forth adding encryption." should be "two authenticated modes and a fourth adding encryption." [Authors]: Thanks, done -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
