Subject: Re: [BEHAVE] Comments on draft-ietf-behave-turn-ipv6-04

From: "Oscar Novo" <[email-masked]>
Date: Fri, 2 May 2008 12:05:14 +0200

Simon,

Thanks for your comments. We'll include them in the next version. 
Regarding your comment 4.2, the draft already defined a 420 (unknown
attribute) for a wrong family.

Cheers,

Oscar

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: 29. huhtikuuta 2008 16:12
To: Gonzalo Camarillo; Oscar Novo
Cc: [email-masked]
Subject: Comments on draft-ietf-behave-turn-ipv6-04

Hello,

I had a first reading of draft-ietf-behave-turn-ipv6-04. Here are a few
comments.

1. Last paragraph of section 4.1:

   The REQUEST-ADDRESS-TYPE attribute MAY only be present in Allocate
   Requests.

This is in contradiction with section 4.2 which describes the usage of
REQUESTED-ADDRESS-TYPE in the Refresh request.

Also, s/REQUEST/REQUESTED/.

2. In section 4.2, there is confusing talk about bindings. Please
s/binding/allocation/ because you do not want to confuse the reader with
STUN bindings when you're really talking about TURN allocations.

3. In section 4.2:

   If the Allocate Response contains the same transport address as
   previously obtained, the binding has been refreshed.

There's an "else" missing. I suggest that server refresh the allocation
if the REQUESTED-ADDRESS-TYPE attribute is missing or of the same type
as previously allocated. If it is present but of the wrong family, reply
with a 400 Bad Request.

4. The last paragraph of section 5.1:

   If the REQUESTED-ADDRESS-TYPE attribute is absent, the server MUST
   allocate a IPv4 transport address to the TURN client.

This is incompatible with the current TURN draft, which says that the
relayed address must be of the same family as the mapped address, which
may be IPv6.

Otherwise, this draft is very straightforward and easy to understand.

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

---

From: "Oscar Novo" <[email-masked]>
Date: Fri, 2 May 2008 13:32:18 +0200

Buenas,

Aquí te envio la nueva versión del draft con los comentarios del tio (abajo).

Oscar

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: 29. huhtikuuta 2008 16:12
To: Gonzalo Camarillo; Oscar Novo
Cc: [email-masked]
Subject: Comments on draft-ietf-behave-turn-ipv6-04

Hello,

I had a first reading of draft-ietf-behave-turn-ipv6-04. Here are a few comments.

This is in contradiction with section 4.2 which describes the usage of REQUESTED-ADDRESS-TYPE in the Refresh request.

2. In section 4.2, there is confusing talk about bindings. Please s/binding/allocation/ because you do not want to confuse the reader with STUN bindings when you're really talking about TURN allocations.

3. In section 4.2:

There's an "else" missing. I suggest that server refresh the allocation if the REQUESTED-ADDRESS-TYPE attribute is missing or of the same type as previously allocated. If it is present but of the wrong family, reply with a 400 Bad Request.

This is incompatible with the current TURN draft, which says that the relayed address must be of the same family as the mapped address, which may be IPv6.

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 2 May 2008 08:22:30 -0400

> attribute) for a wrong family.

That's not what I was talking about. By "wrong family" I meant "of a different 
(but known) family than the one previously allocated." This only makes sense 
in the context of refreshing an existing allocation.

---

From: "Oscar Novo" <[email-masked]>
Date: Fri, 2 May 2008 15:13:07 +0200

OK, now I understand your point. We could add this in the next version
as well.

Thanks,

Oscar 

-----Original Message-----
From: Simon Perreault [mailto:[email-masked]] 
Sent: 2. toukokuuta 2008 15:23
To: Oscar Novo
Cc: Gonzalo Camarillo; [email-masked]
Subject: Re: Comments on draft-ietf-behave-turn-ipv6-04

> attribute) for a wrong family.

That's not what I was talking about. By "wrong family" I meant "of a
different (but known) family than the one previously allocated." This
only makes sense in the context of refreshing an existing allocation.

> There's an "else" missing. I suggest that server refresh the 
> allocation if the REQUESTED-ADDRESS-TYPE attribute is missing or of 
> the same type as previously allocated. If it is present but of the 
> wrong family, reply with a 400 Bad Request.