Traversal Using Relays around NAT (TURN) Extension for IPv6
RFC 6156

Note: This ballot was opened for revision 11 and is now closed.

Lars Eggert No Objection

Section 8., paragraph 4:
>    The descriptions below have two parts: a preferred behavior and an
>    alternate behavior.  The server SHOULD implement the preferred
>    behavior.  However, if that is not possible for a particular field,
>    then the server SHOULD implement the alternative behavior.

  This would be better phrased as "SHOULD do preferred, MUST do
  alternative otherwise, MUST NOT do anything else."

(David Harrington; former steering group member) Yes

(Adrian Farrel; former steering group member) No Objection

(Alexey Melnikov; former steering group member) No Objection

(Dan Romascanu; former steering group member) No Objection

(Jari Arkko; former steering group member) No Objection

From Ari Keranen's review:

1. Introduction

    symmetric NATs that wish to be on the receiving end of a connection
    to a single peer.

Would help to have a reference to definition of symmetric NATs and 
perhaps rather use the more up-to-date terminology of RFC4787 (endpoint 
dependent filtering/mapping).


3. Overview of Operation

    Assuming the request is authenticated, the TURN server allocates a
    transport address of the type indicated in the REQUESTED-ADDRESS-
    FAMILY attribute.  This address is called the allocated transport
    address.

Could make sense to use the same terminology as TURN RFC: "Relayed 
Transport Address" instead of "allocated transport address". Same issue 
throughout the draft.


4.2. Receiving an Allocate Request

    If the server can successfully process the request, it allocates a
    transport address to the TURN client, called the allocated transport
    address, and returns it in the response to the Allocate Request.

s/to the TURN client/for the TURN client/ ?
(same issue a bit later in the section)


    As specified in [I-D.ietf-behave-turn], the Allocate Response
    contains the same transaction ID contained in the Allocate Request
    and the XOR-RELAYED-ADDRESS attribute that sets it to the allocated
    transport address.

The part "that sets it to the [...]" sounds a bit strange. Is there a 
word missing?


5.1. Sending a Refresh Request

    To perform a binding refresh, the client generates a Refresh Request
    as described in Section 7.1 of [I-D.ietf-behave-turn].

Should this say "allocation refresh" instead of "binding refresh"?

(Peter Saint-Andre; former steering group member) No Objection

(Ralph Droms; former steering group member) (was Discuss) No Objection

My earlier COMMENT had a typo - for correctness (although my on-line dictionary says "alternate" is usable as well as "alternative" in American usage in this case), s/Alternate behavior:/Alternative behavior/ throughout.

(Robert Sparks; former steering group member) (was Discuss) No Objection

(Ron Bonica; former steering group member) No Objection

(Russ Housley; former steering group member) No Objection

(Sean Turner; former steering group member) (was Discuss) No Objection

(Stewart Bryant; former steering group member) No Objection

(Gonzalo Camarillo; former steering group member) Recuse

(Tim Polk; former steering group member) No Record

Based on earlier email between the secdir reviewer and one of the authors, I was expecting to
see a new version addressing the following agreed issues (lines beginning with ">" are the
reviewer, other text is the author's)

 S.3, Paragraph "Assuming the request..."
> The server doesn't "assume" that the request is authenticated.  Suggest
> rephrasing as "After the request has been successfully authenticated, ..."

Agreed, fixed.

> S4.2, First paragraph
> As above, suggest rephrasing as "Once a server has verified that the
> request is authenticated and has not been tampered with, ..."

Agreed, fixed.

> S4.3
> Why is this a SHOULD NOT and not a MUST NOT?  What's the exceptional case?

I have no idea. I'll change it to a MUST NOT unless I receive more info
from my co-authors.