Subject: [Ietf-behave] Comments on draft-ietf-behave-turn-01.txt

From: "Neil Deason" <[email-masked]>
Date: Wed, 28 Jun 2006 21:38:04 -0700 (PDT)

Hello folks.
 
- The intended usage of LIFETIME
 
In the previous draft this attribute was referred to as "the duration that a mapping is valid". Now it is referred to as "the duration for which the server will maintain an allocation in the absence of data traffic either from or to the client". 

These two definitions appear to be different. The first being the total duration timeout for a session and the second an idle timeout for a session. Perhaps actually having both would be useful?

Either way the intended usage of LIFETIME needs to be clarified and consistent. (In the new draft section 
9.1.2.2 still refers to this being refreshed by an Allocate request, which is more inline with the previous draft's definition.)
 
- Length and padding of attributes
 
This came up previously in relation to changes in the STUN bis03 draft. (
http://list.sipfoundry.org/archive/ietf-behave/msg01206.html)
 
Unfortunately TURN inherits the same issue and has the added problem that padding to a 4 byte boundary can mess up the data relayed to a remote address via a Send Indication.

Is the intention to still fix this by encoding actual attribute lengths, but padding out to multiple of 4 bytes if the length of the attribute is not 0 or already a multiple of 4 bytes? That makes sense, but if so when/where ;) 

Cheers,
Neil.

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 29 Jun 2006 14:04:34 -0700 (PDT)

Hi Neil,

Comments inline..

On 6/28/06, Neil Deason <neildeason@xxxxxxxxx> wrote:
- The intended usage of LIFETIME

In the previous draft this attribute was referred to as "the duration that a
mapping is valid". Now it is referred to as "the duration for which the
server will maintain an allocation in the absence of data traffic either
from or to the client".
These two definitions appear to be different. The first being the total
duration timeout for a session and the second an idle timeout for a session.
Perhaps actually having both would be useful?
Either way the intended usage of LIFETIME needs to be clarified and
consistent. (In the new draft section 9.1.2.2 still refers to this being
refreshed by an Allocate request, which is more inline with the previous
draft's definition.)
Agreed this needs to be clarified.  Do you have a preference?

This came up previously in relation to changes in the STUN bis03 draft. (
http://list.sipfoundry.org/archive/ietf-behave/msg01206.html)
Unfortunately TURN inherits the same issue and has the added problem that
padding to a 4 byte boundary can mess up the data relayed to a remote
address via a Send Indication.
Is the intention to still fix this by encoding actual attribute lengths, but
padding out to multiple of 4 bytes if the length of the attribute is not 0
or already a multiple of 4 bytes? That makes sense, but if so when/where ;)
Yes, Send and Data indications will be consistent with padding rules
in 3489bis.  I can restate this explicitly.  Also, I need to
explicitly state this for the lightweight TCP framing.  This was an
oversight on my part.
thanks,
-rohan

---

From: "Neil Deason" <[email-masked]>
Date: Thu, 29 Jun 2006 16:37:38 -0700 (PDT)

Hi Rohan.
 
Regarding the semantics of LIFETIME I actually see value in having 2 defined values: One for total permitted duration of a session and one for idle timeout. That would be my preferred choice.
 
If we really can only have one then making LIFETIME the total duration of the session is probably the way to go as then a Server has the option of making this relatively short to enforce Allocate request refreshes as a form of keep alives to timeout idle connections as well as ultimately refusing the refresh request if the session has exceeded max permitted duration.

- Neil. 
On 6/29/06, Rohan Mahy <rohan.mahy@xxxxxxxxx
> wrote: 
Hi Neil,Comments inline..On 6/28/06, Neil Deason <
 neildeason@xxxxxxxxx> wrote:> - The intended usage of LIFETIME>> In the previous draft this attribute was referred to as "the duration that a> mapping is valid". Now it is referred to as "the duration for which the 
> server will maintain an allocation in the absence of data traffic either> from or to the client".>> These two definitions appear to be different. The first being the total> duration timeout for a session and the second an idle timeout for a session. 
> Perhaps actually having both would be useful?>> Either way the intended usage of LIFETIME needs to be clarified and> consistent. (In the new draft section 
9.1.2.2 still refers to this being> refreshed by an Allocate request, which is more inline with the previous> draft's definition.)Agreed this needs to be clarified.  Do you have a preference?
> - Length and padding of attributes >> This came up previously in relation to changes in the STUN bis03 draft. (> 
http://list.sipfoundry.org/archive/ietf-behave/msg01206.html )>> Unfortunately TURN inherits the same issue and has the added problem that> padding to a 4 byte boundary can mess up the data relayed to a remote
> address via a Send Indication.>> Is the intention to still fix this by encoding actual attribute lengths, but> padding out to multiple of 4 bytes if the length of the attribute is not 0> or already a multiple of 4 bytes? That makes sense, but if so when/where ;) 
Yes, Send and Data indications will be consistent with padding rulesin 3489bis.  I can restate this explicitly.  Also, I need toexplicitly state this for the lightweight TCP framing.  This was anoversight on my part. 
thanks,-rohan