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

From: [email-masked]
Date: Tue, 24 Jun 2008 09:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Behavior Engineering for Hindrance Avoidance Working Group of the IETF.

	Title           : Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)
	Author(s)       : J. Rosenberg, et al.
	Filename        : draft-ietf-behave-turn-08.txt
	Pages           : 51
	Date            : 2008-06-24

If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts
(peers) located behind other NATs.  In these situations, it is
necessary for the host to use the services of an intermediate node
that acts as a communication relay.  This specification defines a
protocol, called TURN (Traversal Using Relays around NAT), that
allows the host to control the operation of the relay and to exchange
packets with its peers using the relay.
The TURN protocol can be used in isolation, but is more properly used
as part of the ICE (Interactive Connectivity Establishment) approach
to NAT traversal.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-behave-turn-08.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Behave mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/behave

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Sat, 28 Jun 2008 14:35:55 -0700

I finished updating my TURN server code, so here's a partial review of
turn-08:

- Section 4, paragraph 3:  "The server's administrator MAY choose..."

I am not sure to understand why this sentence is here.  Should be
removed or moved in a non-normative section.

- Section 4, paragraph 12:  "Subsequent requests on an allocation use
the same username and password..."

They use the same username but can use a different password.

- Section 6.2, bullet 4:

There is no way for a client to know which bit in the REQUESTED-PROPS
triggered the 508 response.  I suggest to send back the REQUESTED-PROPS
attribute with the bits set for properties that the server understand.
This way the client can retry an allocation by clearing some of the bits.

- Section 6.2, bullet 5:

This contradicts paragraph 14 of section 6.1.  I suggest to use the text
in section 6.1, because some future properties can be meaningful with a
RESERVATION-TOKEN (and it's perhaps the case for the Preserving bit).

- Section 6.2, paragraph 13:

I still think that the right thing to do is using turn-ipv6 (i.e.
explicitly ask for an IPv6 allocation).

- Section 6.2, paragraph 15:

I think that this paragraph should say something about
draft-ietf-tsvwg-port-randomization.

- Section 6.2, paragraph 18:

Should the server reject an Allocate with a RESERVATION-TOKEN that was
reserved from a different protocol (i.e. if the first port is allocated
from a UDP connection, should the server reject the RESERVATION-TOKEN
allocate if it is on a TCP connection?)

- Section 8, paragraph 5:  "The default permission lifetime MUST be 300
seconds"

Either "default" or "MUST" is redundant.

- Section 10.4, paragraph 4:

If the length is equal to 0, should an empty packet be sent (like when
Send contains an empty DATA attribute) or does it just refresh the
permission?

- Section 10.7, paragraph 7:

This paragraph is nearly identical to section 9.3.  I suggest to add
another section between 10 and 11 that merge the two texts.

- Section 13:

As I said in a previous email, the codepoint and definition for the ICMP
attribute are missing.

Some nits:

- Section 2.5, paragraph 3:  "... from the peer DOES NOT refresh ..."

"DOES NOT" is not defined by RFC 2119.  Besides this section is
non-normative.

- Section 5, paragraph 11:  "... EXCEPT an Allocate request..."

"EXCEPT" is not defined by RFC 2119.

- Section 6.1, paragraph 5:  "...note that this is NOT the..."

"NOT" is not defined by RFC 2119.

- Section 6.1, paragraph 6:  "...the field to less tha the default value."

s/tha/than/

- Section 7.2, paragraph 2:  "...but the allocation is NOT deleted..."

"NOT" is not defined by RFC 2119.

- Section 11.2, paragraph 13:  "...SHOULD relay as all ICMP..."

s/as all/all/

- Section 11.2, paragraph 13:  "...and MUST relay at at least..."

s/at at/at/

- Section 13.7, paragraph 3:  "...and MUST be ignores on receiption."

s/receiption/reception/

-- 
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: Eilon Yardeni <[email-masked]>
Date: Mon, 30 Jun 2008 09:29:47 -0700 (PDT)

- Section 9.4.  Receiving a Data Indication

This section should mention the ICMP attribute that can be included in
the Data Indication. If it is included, the client shouldn't just
deliver the DATA attribute content to the application.

-- 
View this message in context: http://www.nabble.com/I-D-Action%3Adraft-ietf-behave-turn-08.txt-tp18094194p18199325.html
Sent from the IETF - Behave mailing list archive at Nabble.com.