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

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

(David Harrington) Yes

(Jari Arkko) No Objection

Comment (2010-07-01 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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

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"?

(Ron Bonica) No Objection

(Stewart Bryant) No Objection

(Ralph Droms) (was Discuss) No Objection

Comment (2010-08-09)
No email
send info
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.

(Lars Eggert) No Objection

Comment (2010-06-30 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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."

(Adrian Farrel) No Objection

(Russ Housley) No Objection

(Alexey Melnikov) No Objection

(Dan Romascanu) No Objection

(Peter Saint-Andre) No Objection

(Robert Sparks) (was Discuss) No Objection

(Sean Turner) (was Discuss) No Objection

(Gonzalo Camarillo) Recuse

(Tim Polk) No Record

Comment (2010-06-25 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
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.