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

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.