Document: draft-ietf-ippm-capacity-protocol Title: Test Protocol for One-way IP Capacity Measurement Reviewer: Tianran Zhou Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. 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. 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. 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. 4. In 6.1 Client Generates Test Activation Request It seems some fields are not described, e.g., useOwDelVar，slowAdjThresh. 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. Cheers, Tianran -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
