Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 30 Mar 2015 06:44:26 +0000

Works for me. Summarizing list of changes discussed:

1) There is no use of address family attribute in AAF and I guess it can be removed; Instead of AAF we can probably call if DUAL-STACK-ADDRESS-FAMILY.

2)
a) REFRESH with no attributes refreshes everything, regardless of allocation type.
b) REFRESH with specific RAF refreshes only the specific allocation if it exists, or otherwise fails
c) REFRESH with RAF can be used with our without dual stack allocation and deprecates the behavior in RFC 6156.

3)Change the format of ADDRESS-ERROR-CODE to

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |  Address Family                |  Rsvd  |Class|     Number    |

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      |      Reason Phrase (variable)                                ..

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4)Remove multi-address support to ChannelBind request.

-Tiru

From: Justin Uberti [mailto:[email-masked]]
Sent: Sunday, March 29, 2015 6:17 AM
To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; [email-masked]
Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

We are obsoleting 6156, so we can say whatever we want - especially in the case of dual allocations.

On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

The problem is RFC 6156 says that RAF must not be used in Refresh request, that is one of the reasons for using AAF in Refresh.

-Tiru

From: Justin Uberti [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Friday, March 27, 2015 8:21 PM
To: Tirumaleswar Reddy (tireddy)
Cc: Oleg Moskalenko; [email-masked]<mailto:[email-masked]>

Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01

Agreed, but I think using AAF in Refresh has confusing semantics, since they are different from Allocate. Restating from my previous message:

In ALLOCATE, v4 AAF is forbidden, and v6 AAF means "v4+v6".
In REFRESH, v4 AAF means "v4 only", and v6 AAF means "v6 only".

Compare this to how RAF could be handled:

In ALLOCATE, v4 RAF means "v4 only", and v6 RAF means "v6 only".
In REFRESH, v4 RAF means "v4 only", and v6 RAF means "v6 only".

On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
The client includes AAF in Refresh only if dual allocation is successful which means client when it sends Refresh knows if server supports AAF or not.

-Tiru

> -----Original Message-----
> From: Oleg Moskalenko [mailto:[email-masked]<mailto:[email-masked]>]
> Sent: Friday, March 27, 2015 10:13 AM
> To: Justin Uberti
> Cc: Tirumaleswar Reddy (tireddy); [email-masked]<mailto:[email-masked]>
> Subject: Re: [tram] Comments on draft-ietf-tram-turnbis-01
>
> On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >
> > I think that REFRESH should work as follows:
> > - REFRESH with no attributes refreshes everything, regardless of
> > allocation type
> > - REFRESH with specific RAF refreshes only the specific allocation if
> > it exists, or otherwise fails
> > - REFRESH with any AAF fails because it is not well-defined
>
> this behaviour is not compatible with older (RFC5766-compliant) servers that do
> not understand AAF. They will treat option 1 and option 3 as the same case.

---

From: Oleg Moskalenko <[email-masked]>
Date: Sun, 29 Mar 2015 23:48:07 -0700

Tiru,

please clarify the point 2c, I did not get it.

Thanks
Oleg

On Sun, Mar 29, 2015 at 11:44 PM, Tirumaleswar Reddy (tireddy)
<[email-masked]> wrote:
> 1) There is no use of address family attribute in AAF and I guess it can be
> removed; Instead of AAF we can probably call if DUAL-STACK-ADDRESS-FAMILY.
>
>
>
> 2)
>
> On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy (tireddy)
> <[email-masked]> wrote:
>
> Hi Justin,
>
>
>
> The problem is RFC 6156 says that RAF must not be used in Refresh request,
> that is one of the reasons for using AAF in Refresh.
>
>
>
> -Tiru
>
>
>
> Agreed, but I think using AAF in Refresh has confusing semantics, since they
> are different from Allocate. Restating from my previous message:
>
>
>
> On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy)
> <[email-masked]> wrote:
>
> The client includes AAF in Refresh only if dual allocation is successful
> which means client when it sends Refresh knows if server supports AAF or
> not.
>
> -Tiru
>
>> From: Oleg Moskalenko [mailto:[email-masked]]
>> Cc: Tirumaleswar Reddy (tireddy); [email-masked]
>> On Thu, Mar 26, 2015 at 9:00 PM, Justin Uberti <[email-masked]> wrote:
>> >
>> >

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 30 Mar 2015 06:55:52 +0000

> Sent: Monday, March 30, 2015 12:18 PM
> Cc: Justin Uberti; [email-masked]

I meant if client had sent  AAF in Allocate request and server responds with partial success (allocation successful for only one address family); client can use Refresh + RAF to refresh the specific address family for which the allocation is successful. 
(It changes the behavior discussed in RFC 6156 that client must not send RAF in refresh). 

-Tiru

> > 1) There is no use of address family attribute in AAF and I guess it
> > can be removed; Instead of AAF we can probably call if DUAL-STACK-ADDRESS-
> FAMILY.
> >
> >
> >
> > 2)
> >
> > The problem is RFC 6156 says that RAF must not be used in Refresh
> > request, that is one of the reasons for using AAF in Refresh.
> >
> >
> >
> > -Tiru
> >
> >
> >
> > Agreed, but I think using AAF in Refresh has confusing semantics,
> > since they are different from Allocate. Restating from my previous message:
> >
> >
> >
> > The client includes AAF in Refresh only if dual allocation is
> > successful which means client when it sends Refresh knows if server
> > supports AAF or not.
> >
> > -Tiru
> >
> >> > - REFRESH with specific RAF refreshes only the specific allocation
> >> > if it exists, or otherwise fails
> >> this behaviour is not compatible with older (RFC5766-compliant)
> >> servers that do not understand AAF. They will treat option 1 and
> >> option 3 as the same case.
> >
> >
> >
> >

---

From: Oleg Moskalenko <[email-masked]>
Date: Mon, 30 Mar 2015 00:01:44 -0700

OK, thanks.

Oleg

---

From: Justin Uberti <[email-masked]>
Date: Mon, 30 Mar 2015 08:48:34 -0700

On Sun, Mar 29, 2015 at 11:44 PM, Tirumaleswar Reddy (tireddy) <
[email-masked]> wrote:

> 1) There is no use of address family attribute in AAF and I guess it can
> be removed; Instead of AAF we can probably call if
> DUAL-STACK-ADDRESS-FAMILY.
>

I would keep AAF as currently defined - there may be other places to use it
in the future. However, we can currently return an error if it doesn't
match the expected value (i.e. v6).

> deprecates the behavior in RFC 6156.

Agreed. Clients will probably want to do a) unless they know they are
talking to a turn-bis server.

> 3)Change the format of ADDRESS-ERROR-CODE to

LGTM

>
>
> -Tiru
>
>
>
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Sunday, March 29, 2015 6:17 AM
>
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Oleg Moskalenko; [email-masked]
> *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01
>
>
>
> On Fri, Mar 27, 2015 at 7:08 PM, Tirumaleswar Reddy (tireddy) <
> [email-masked]> wrote:
>
> Hi Justin,
>
>
>
> *From:* Justin Uberti [mailto:[email-masked]]
> *Sent:* Friday, March 27, 2015 8:21 PM
> *To:* Tirumaleswar Reddy (tireddy)
> *Cc:* Oleg Moskalenko; [email-masked]
>
>
> *Subject:* Re: [tram] Comments on draft-ietf-tram-turnbis-01
>
>
>
> Agreed, but I think using AAF in Refresh has confusing semantics, since
> they are different from Allocate. Restating from my previous message:
>
>
>
> On Fri, Mar 27, 2015 at 12:38 AM, Tirumaleswar Reddy (tireddy) <
> [email-masked]> wrote:
>

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Tue, 31 Mar 2015 02:03:51 +0000

Sent: Monday, March 30, 2015 9:19 PM

On Sun, Mar 29, 2015 at 11:44 PM, Tirumaleswar Reddy (tireddy) <[email-masked]<mailto:[email-masked]>> wrote:
Works for me. Summarizing list of changes discussed:

I would keep AAF as currently defined - there may be other places to use it in the future. However, we can currently return an error if it doesn't match the expected value (i.e. v6).

[TR] Okay.

-Tiru

2)

Agreed. Clients will probably want to do a) unless they know they are talking to a turn-bis server.

LGTM

-Tiru

-Tiru

-Tiru