Hi Tianran, thanks for your review and suggestions. The comments of Len and me are marked [Authors] in line below. The issue "explaining text for the pdu fields" is dealt with separately, as improvement takes some more time. I'm publishing suggested changes based on feedback received from Magnus, Brian and you by draft -16. This is of course an intermediate step only. Regards, Ruediger -----Ursprüngliche Nachricht----- Von: Tianran Zhou via Datatracker <noreply@xxxxxxxx> Gesendet: Dienstag, 6. Mai 2025 06:05 An: ops-dir@xxxxxxxx Cc: draft-ietf-ippm-capacity-protocol.all@xxxxxxxx; ippm@xxxxxxxx; last-call@xxxxxxxx Betreff: draft-ietf-ippm-capacity-protocol-14 ietf last call Opsdir review <snip> In general, this document is clear to me. I did not see any special operational or network management related issue. But there are several minor issues, for the authors consideration. minor issues： 1. In section 5.1 "testPort: The UDP ephemeral port number on the server that the client has to use for the Test Activation Request and subsequent Load or Status PDUs." Accorrding to 5.2.2, server will be assigned an UDP port after receiving a request. Why the request carries the server test port? Do you mean the client assigns the server test prot? But I am not sure if it's a safe mechanism. [Authors]: CHANGE: testPort: Set to zero in the Test Setup Request and populated by the server in the Test Setup Response. It contains the UDP ephemeral port number on the server that the client has to use for the Test Activation Request and subsequent Load or Status PDUs. Section 5.2.2, CHANGE: ... (with the port number communicated back to the client in testPort field of the Test Setup Response). -------------- 2. In section 5.1 "maxBandwith: When this field is non-zero, it is a specification of the maximum bit rate the client expects to send or receive during the requested test. The server compares this value to its currently available configured limit for test admission control. This field MAY be used for rate-limiting the maximum rate the server should attempt. The maxBandwidth field's most significant bit, the CHSR_USDIR_BIT, is set to 0 by default to indicate comment："downstream" and has to be set to 1 to indicate "upstream"." What's the unit of the maxBandwith, bps, Bps, or Kbps or Mbps? I see you mentioned "bit rate". Do you indicate the bps? I would suggest you to make it explicitly. [Authors]: ADD/CHANGE: maxBandwith: When this field is non-zero, it is a specification of the maximum bit rate the client expects to send or receive during the requested test in Mbps. -------------- 3. In section 5.1 "checkSum: An optional checksum of the entire PDU. The calculation is done with the fields checksum, authMode and those following after authMode set to zero." It seems the checkSum is optional. But I think it's mondatory if auth/encryption is not on, in order to find out bit error. [Authors]: Section 4.5, last sentence is covering the requirement (indirectly, though): However, because authentication is not applicable to the Load PDU, the checkSum field SHALL be utilized by the sender whenever UDP data integrity may be uncertain (as outlined above). Section 4.5, 1st sentence CHANGE: ... header checksum that covers the various fields in the UDPST PDU (excluding the Payload Content of the Load PDU and, to be clear, also the IP- and UDP-header). All instances of checkSum, CHANGE: checkSum: An optional checksum of the entire PDU (see Section 4.5 for guidance).... --------------- 4. In 6.1 Client Generates Test Activation Request It seems some fields are not described, e.g., useOwDelVar，slowAdjThresh. [Authors]: To make progress and save some time, we'd like to discuss this separately. -------------- 5. In 7.1 Test Packet PDU and Roles I would suggest a dedicated section to describe the rate adjust algorithm. And you can describe the state machine and para config, so as to better understand the algorithm. [Authors]: We'd suggest to add a reference, as algo B operation is standardised and published: Section 7.1, 7th paragraph CHANGE: The default algorithm (B, see [Y.1540]).... Cheers, Tianran -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
