Subject: [BEHAVE] Version -11 of TURN posted

From: Philip Matthews <[email-masked]>
Date: Wed, 29 Oct 2008 09:15:28 -0400

I have posted a new version of TURN (draft-ietf-behave-turn-11) to the  
IETF servers. This version addresses a number of issues raised in  
reviews of TURN-10 by various people. Thanks to Dan Wing, Cullen  
Jennings, Magnus Westerlund, and Marc Petit-Huguenin for their  
reviews. The major technical changes in this version have all been  
discussed on the mailing list.

As far as I am aware, there are no outstanding issues with this  
version of TURN.

A complete list of the changes in the document are copied below, and  
can also be found in the document itself.

- Philip

21.1.  Changes from -10 to -11

    o  Clarified that, when the client is redirected to an alternate
       server, the client uses the same transport protocol to the
       alternate server as it did to the original server.

    o  Clarified the information that the server needs to store to
       authenticate requests and to compute the message-integrity on
       responses.  Noted that the server need not store the password
       explicitly, but can instead store the key value, which may be
       desirable for security reasons.

    o  Clarified that TURN runs on the same ports as TURN by default,  
but
       noted that a server can use a different port because TURN has its
       own SRV service names.  Strenghened the language for using the  
SRV
       procedures from "typically" to "SHOULD".  Also added a sentence  
in
       the IANA considerations section requesting that IANA reserve the
       service names for TURN; previously they were described in the  
text
       but not mentioned in the IANA considerations section.

    o  Added a detailed example, complete with attributes and their
       values, of the use of TURN.

    o  Reduced the range of channel numbers.  Channel numbers now range
       from 0x4000 through 0x7FFF.  Values in the range 0x8000 through
       0xFFFF are now reserved.

    o  Rewrote the IAB Considerations section to directly address the
       considerations listed in [RFC3424].

    o  Generalized the 508 error code so it can be used for any sort of
       capacity-related problem.  This error code was previously allowed
       only in Allocate responses, but is now also allowed in
       CreatePermission and ChannelBind responses to indicate that the
       server is unable to carry out the request due to some capacity
       problem.

    o  Changed the syntax of the CreatePermission request to allow
       multiple XOR-PEER-ADDRESS attributes to appear in the message, so
       that multiple permissions can be created or refreshed at the same
       time.

    o  Added the restriction that the server must already have a
       permission installed for the IP address in the XOR-PEER-ADDRESS
       attribute of a Send indication, otherwise the Send indication is
       ignored by the server.

    o  Put back the preferred behaviors into Section 12, reversing the
       change made in version -10.

    o  Explicitly allow the server to restrict the range of IP addresses
       and ports it is willing to relay data too.

_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave