Traversal Using Relays around NAT (TURN) Extension for IPv6
Note: This ballot was opened for revision 11 and is now closed.
(David Harrington) Yes
(Jari Arkko) No Objection
Comment (2010-07-01 for -)
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"?
(Ron Bonica) No Objection
(Stewart Bryant) No Objection
(Ralph Droms) (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.
(Lars Eggert) No Objection
Comment (2010-06-30 for -)
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 -)
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.