Skip to main content

Traversal Using Relays around NAT (TURN) Extension for IPv6
draft-ietf-behave-turn-ipv6-11

Yes

(David Harrington)

No Objection

(Adrian Farrel)
(Alexey Melnikov)
(Dan Romascanu)
(Peter Saint-Andre)
(Robert Sparks)
(Ron Bonica)
(Russ Housley)
(Sean Turner)
(Stewart Bryant)

Recuse

(Gonzalo Camarillo)

No Record


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

David Harrington Former IESG member
Yes
Yes () Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection () Unknown

                            
Alexey Melnikov Former IESG member
No Objection
No Objection () Unknown

                            
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2010-07-01) Unknown
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"?
Lars Eggert Former IESG member
No Objection
No Objection (2010-06-30) Unknown
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."
Peter Saint-Andre Former IESG member
No Objection
No Objection () Unknown

                            
Ralph Droms Former IESG member
(was Discuss) No Objection
No Objection (2010-08-09) Unknown
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 IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Sean Turner Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Stewart Bryant Former IESG member
No Objection
No Objection () Unknown

                            
Gonzalo Camarillo Former IESG member
Recuse
Recuse () Unknown

                            
Tim Polk Former IESG member
No Record
No Record (2010-06-25) Unknown
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.