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
(Tim Polk)
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.