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. I think the draft is ready for publication as it is, even if some clarifications would help the reader for a correct use of the proposed solution. The comments listed below should not block the publication process but it would be nice if authors could address them if a new version of the draft is required. Main comments: - The whole solution is introduced as an improvement of the ICE prioritization formula. With the PATH-CHARACTERISTIC attribute, it is understood that there are additional criteria for selecting the most suitable candidate. But finally, it is not clearly said how the loss and RTT info modify/impact/improve the formula recommended in the RFC 5245. If it is left outside the document, please indicate it in the text. - Moreover, the case with stateful agent handling the RespTransCnt field is pretty clear. But I think that more information should be given to the reader about the difference for the client to be able to rely or not on the RespTransCnt field. Other comments: - In section 1. Introduction: The ICE [RFC5245] mechanism uses a prioritization formula to order the candidate pairs and perform connectivity checks, in which the most preferred address pairs are tested first and when a sufficiently good pair is discovered, that pair is used for communications and further connectivity tests are stopped. It is maybe too obvious and not essential for people involved in this work but could help the reader to know that ICE is a technique for NAT traversal and not a general purpose solution. - In section 3. Path characteristics determination mechanism This document defines a new comprehension-optional STUN attribute PATH-CHARACTERISTIC. PATH-CHARACTERISTIC will have a STUN Type TBD- CA. This type is in the comprehension-optional range, which means that STUN agents can safely ignore the attribute if they do not understand it. It is said in another section but could be good to clarify that "safely ignore" means that when the new attribute is not supported by the server, the client naturally fallbacks to existing STUN/ICE procedures. Instead of having a format for the request (section 3.1) and the response (section 3.2) that are the same, it would be clearer to have a section describing the format of the attribute (section 3.1) and addition clarifying the use in the request (section 3.2) and the response (section 3.3). - In section 3.1. The PATH-CHARACTERISTIC attribute in request The PATH-CHARACTERISTIC attribute in a STUN request takes a 4-byte Value. I don't know what is the current IETF policy but I would prefer "32-bit value" instead of "4-byte value". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved, should be 0 | ReTransCnt | RespTransCnt | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: PATH-CHARACTERISTIC attribute in request Why are the two first octects marked as "reserved"? I'm assuming that these bits are present for alignment with a fixed size of STUN attributes but it should be clarified. And if they are "should" should be replaced by "must". I think it would be easier to left "reserved" in the figure and describe its contents in the description given below the figure. - In section 3.2. . The PATH-CHARACTERISTIC attribute in response When a server receives a STUN request that includes a PATH- CHARACTERISTIC attribute, it processes the request as per the STUN protocol [RFC5389] plus the specific rules mentioned here. It is maybe obvious or already described in RFC 5389, but I assume that the server must include the new attribute in the response if not received in the request. o If the server is stateless or does not want to remember the transaction ID then it would populate value 0 for the RespTransCnt field in PATH-CHARACTERISTIC attribute sent in the response. If the server is stateful then it populates RespTransCnt with the number of responses it has sent for the STUN request. Is there any recommendation between "stateless vs stateful" for an optimal support of this new attribute? If it is, we could find something like "SHOULD be stateful but MAYBE stateless"... - In section 3.3. Example Operation It should be clarified that the server is stateful in this example. Otherwise, the RespTransCnt field in PATH-CHARACTERISTIC attribute in the response is of no use. Could be "stateful server" instead of "server" in the description of the example. Moreover, as commented earlier, The case with stateful agent handling the RespTransCnt field is pretty clear. But I think that more information should be given to the reader about the difference for the client to be able to rely or not on the RespTransCnt field. - In section 4. Use cases o When an endpoint has multiple interfaces (for example 3G, 4G, WiFi, VPN, etc.), an ICE agent can choose the interfaces for application data according to the path characteristics. After STUN responses to STUN checks are received, the ICE agent using regular nomination can sort the ICE candidate pairs according to the path characteristics (loss and RTT) discovered using STUN. The controlling agent can then assign the highest priority to candidate pair which best fulfills the desired path characteristics. However, it should be noted that the path capacity or throughput is not determined by these STUN checks. If an endpoint needs to pick paths based on capacity, it would have to send application data on those paths. This text illustrates the main comment given above. It is said: the ICE agent using regular nomination can sort the ICE candidate pairs according to the path characteristics (loss and RTT) discovered using STUN. But there is no clue on how the agent will do. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.