Subject: Re: [BEHAVE] I-D Action:draft-ietf-behave-turn-10.txt

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 09 Oct 2008 11:43:12 -0700

Please find below my review of TURN-10.

BTW, I will be in Minneapolis so I will be happy to do some interop with
other implementers of TURN-10.  Send me an email if you are interested.

Also, we have a patch ready for Wireshark and will be submitting it next
week to the Wireshark developers.

-----------------------------------------------------------------------

- Abstract:  "... with other hosts (peers) located behind other NATs."

Communication can be impossible even if the peers are not behind a NAT.
Same thing in Section 1, second paragraph.

- Section 3, definition of 5-tuple:  "...and transport protocol (UDP or
TCP))..."

Can be something else than UDP or TCP.

- Section 14.6:

This attribute is one byte long, which I understand as been padded to 4
bytes by the algorithm described in rfc3489bis.  I think that it is a
good idea to do this, but this is not consistent with CHANNEL-NUMBER and
REQUESTED-TRANSPORT that are both 4 bytes, with RFFU.

NITS
----

- Section 2, paragraph 2:  "On the public Internet..."

Pleonasm.

- Section 3, definition of 5-tuple: "...used to communicate between the
client and the server ."

Remove the space before the stop.

- Section 6.2, bullet #3:  "...contain a REQUESTED-TRANPORT..."

REQUESTED-TRANSPORT

- Section 6.2, bullet #8:  "...as in authenticated error responses.."

Remove redundant stop.

- Section 8, paragraph 7: "...at a different point in time, or vica-versa."

...vice versa.

- Section 9, second paragraph: "...with either the Send mechanismSection
10 or the Channel mechanismSection 11."

...mechanism in Section...

- Section 14:  "0x001a: DONT-FRAGMENT"

0x001A

- Section 14.6:

The unused bits in the ASCII art should be marked RFFU.

- Section 14.6: "...to reserve the next highest port..."

...to reserve the next port...

- Section 16.1.3: "...by sending it a Refresh with an..."

...by sending it a Refresh request with an...

-- 
Marc Petit-Huguenin           [                                 ]
Home: [email-masked] [RFC1855-compliant space for rent ]
Work: [email-masked]            [                                 ]
[                                                               ]
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Philip Matthews <[email-masked]>
Date: Sat, 11 Oct 2008 12:26:53 -0400

Hi Marc:

Thanks for your review!
See inline for some quick responses.

- Philip

> week to the Wireshark developers.

OK. I have deleted the "located behind other NATs".

> Can be something else than UDP or TCP.

Not sure what you are driving at. Protocols like DCCP or SCTP are not  
supported for communication with the TURN server (yet).

> REQUESTED-TRANSPORT that are both 4 bytes, with RFFU.

Yes, there is a small inconsistency. Since EVEN-PORT is only for use  
with older RTP clients, and since we have previously agreed to really  
restrict what can be done here, I didn't see any need for an RFFU  
field. Also, I didn't want to change the format of the other  
attributes unless there was a good reason.

As you noted, the padding rules of rfc3489bis handle one-byte  
attributes.

I'll comment on (and fix) the nits below later.

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 11 Oct 2008 10:21:17 -0700

> On Thu, 9-Oct-08, at 14:43 , Marc Petit-Huguenin wrote:

[...]

> supported for communication with the TURN server (yet).

Yes, but TURN-10 also does not support IPv6, or TCP between the server
and the peer, but still mention the possibility of using them.

---

From: Philip Matthews <[email-masked]>
Date: Thu, 16 Oct 2008 13:12:45 -0400

> and the peer, but still mention the possibility of using them.

My criterion for mentioning a future extension to TURN has been  
whether or not there exists an accepted Working Group document  
specifying it. Both IPv6 and TCP have such WG documents. By contrast,  
preserving allocations, even though they used to be in the base spec  
and have been discussed at two WG meetings, are not, because there is  
not yet a WG document for them.

But how about:
    "... and transport protocol (currently one of UDP, TCP, or TLS))"
which is both more accurate and suggests (with the word "currently")  
that other possibilities might be defined in the future?

- Philip

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 16 Oct 2008 10:32:14 -0700

Philip Matthews wrote:
> My criterion for mentioning a future extension to TURN has been whether
> or not there exists an accepted Working Group document specifying it.
> Both IPv6 and TCP have such WG documents. By contrast, preserving
> allocations, even though they used to be in the base spec and have been
> discussed at two WG meetings, are not, because there is not yet a WG
> document for them.
> 
> 
> But how about:

OK.

Thanks.

---

From: Philip Matthews <[email-masked]>
Date: Sat, 18 Oct 2008 10:05:11 -0400

Responding to your remaining points.

[Snip]

> - Section 2, paragraph 2:  "On the public Internet..."

I suppose that it true. But it is in contrast to the phrase "private  
network" in the previous sentence, and I personally feel it re- 
enforces the difference. I have left the text as is.
> Remove the space before the stop.
Fixed.

> - Section 6.2, bullet #3:  "...contain a REQUESTED-TRANPORT..."

Fixed.

> - Section 6.2, bullet #8:  "...as in authenticated error responses.."

Fixed.

> - Section 8, paragraph 7: "...at a different point in time, or vica- 

Fixed.

> ...mechanism in Section...

Fixed.

> - Section 14:  "0x001a: DONT-FRAGMENT"

Fixed.

> The unused bits in the ASCII art should be marked RFFU.

Fixed.

> ...to reserve the next port...

I changed "highest" to "higher".

> ...by sending it a Refresh request with an...

Fixed.