Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04

Simon Perreault <simon.perreault@viagenie.ca> Fri, 07 August 2009 20:18 UTC

Return-Path: <simon.perreault@viagenie.ca>
X-Original-To: behave@core3.amsl.com
Delivered-To: behave@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0EFC33A6D73 for <behave@core3.amsl.com>; Fri, 7 Aug 2009 13:18:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eS7+OPxJB8UY for <behave@core3.amsl.com>; Fri, 7 Aug 2009 13:18:13 -0700 (PDT)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id EBF203A68C5 for <behave@ietf.org>; Fri, 7 Aug 2009 13:18:10 -0700 (PDT)
Received: by jazz.viagenie.ca (Postfix, from userid 8) id 61A1D29E15E8; Fri, 7 Aug 2009 16:18:10 -0400 (EDT)
Message-ID: <4A7C8BF3.3040809@viagenie.ca>
Date: Fri, 07 Aug 2009 16:17:55 -0400
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
MIME-Version: 1.0
To: "Alfred E. Heggestad" <aeh@db.org>
References: <0a9901ca10f2$93cdab60$5f7d150a@cisco.com> <4A7C5D98.6090503@db.org>
In-Reply-To: <4A7C5D98.6090503@db.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-behave-turn-tcp@tools.ietf.org, behave@ietf.org, 'Behave Chairs' <behave-chairs@tools.ietf.org>
Subject: Re: [BEHAVE] WGLC: draft-ietf-behave-turn-tcp-04
X-BeenThere: behave@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: mailing list of BEHAVE IETF WG <behave.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/behave>
List-Post: <mailto:behave@ietf.org>
List-Help: <mailto:behave-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/behave>, <mailto:behave-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Aug 2009 20:18:14 -0000

Le 2009-08-07 13:00, Alfred E. Heggestad a écrit :
> 5.2. Receiving a Connect Request
>
> "Otherwise, the server MUST initiate an outgoing TCP connection. The
> local endpoint is the relayed transport address associated with the
> allocation. ..."
>
> ---> why does the local endpoint have to be the relayed transport address?
> is this a technical requirement to make the TURN/TCP protocol work?
> Normally an outgoing TCP connection using BSD sockets will use a
> random port as local endpoint. It is possible to use the same port
> as the TCP socket is listening on, but will require that things are
> initialized in the correct order. You should check that this does
> cause problems for implementors (ref: ICE tcp-SO discussion)

Here's one case where this is needed: when two TURN servers are talking 
to each other, the client needs to install a permission on each server 
for the remote socket. So each client needs to be know in advance where 
the connection is going to come from.

> 5.4. Receiving a ConnectionBind Request
>
> ---> 5th paragraph: "...Connect or Listen request..."
>
> I think the "Listen" request is not defined anymore ...

Right. Will be removed.

> - some of the text in the abstract is bold in the HTML version

Yes, this is because the HTML version is generated from the text version 
by heuristics. It got this part wrong.

> last line: "STUN Server" --> "TURN Server"

Right. Strange how this was never noticed before...

> 1. Introduction:
>
> "It also allows the client to initiate connections from that allocation
> to peers"
>
> would like to suggest instead:
>
> "It also allows the client to initiate outgoing TCP connections from
> that allocation to peers"

> ", and accept connection requests from peers made towards that allocation"
>
> would like to suggest instead:
>
> ", and accept incoming TCP connections from peers made towards that
> allocation"

Sure, why not.

Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org