Last Call Review of draft-ietf-tram-stun-path-data-03
review-ietf-tram-stun-path-data-03-opsdir-lc-morand-2016-04-23-00

Request Review of draft-ietf-tram-stun-path-data
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-04-19
Requested 2016-02-03
Draft last updated 2016-04-23
Completed reviews Genart Last Call review of -03 by Wassim Haddad (diff)
Secdir Last Call review of -03 by Watson Ladd (diff)
Opsdir Last Call review of -03 by Lionel Morand (diff)
Assignment Reviewer Lionel Morand
State Completed
Review review-ietf-tram-stun-path-data-03-opsdir-lc-morand-2016-04-23
Reviewed rev. 03 (document currently at 05)
Review result Has Nits
Review completed: 2016-04-23

Review
review-ietf-tram-stun-path-data-03-opsdir-lc-morand-2016-04-23

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.