Re: [tram] Review of dual allocation in TURNbis-11

[Marc Petit-Huguenin <[e-mail]>]

As suggested by Brandon, I reviewed turnbis-14 for the modifications agreed on below, and found some discrepancies.  See inline.

On 02/09/2018 04:51 AM, Konda, Tirumaleswar Reddy wrote:
>> -----Original Message-----
>> From: Marc Petit-Huguenin [mailto:[e-mail]]
>> Sent: Sunday, October 22, 2017 9:38 PM
>> To: Konda, Tirumaleswar Reddy
>> <[e-mail]>; [e-mail]
>> Subject: Re: [tram] Review of dual allocation in TURNbis-11
>>
>> Inline.
>>
>> On 10/16/2017 07:14 PM, Konda, Tirumaleswar Reddy wrote:
>>> Thanks Marc for the detailed review, Please see inline
>>>
>>>> -----Original Message-----
>>>> From: tram [mailto:[e-mail]] On Behalf Of Marc Petit-
>>>> Huguenin
>>>> Sent: Saturday, October 14, 2017 12:59 AM
>>>> To: [e-mail]
>>>> Subject: [tram] Review of dual allocation in TURNbis-11
>>>>

[snip]

>>>
>>>>
>>>> - Section 6.2
>>>>
>>>> I would suggest to make ADDRESS-ERROR-CODE more generic by
>> renaming
>>>> it as WARNING-CODE and use the same format than for ERROR-CODE.
>> Then
>>>> allocate a new error code for that specific warning.  I would suggest
>>>> to request the 0x8009 codepoint for that attribute.
>>>
>>> I don't understand the need to change ADDRESS-ERROR-CODE !
>>
>> To make it more generic and reusable in future specifications.
> 
> ADDRESS-ERROR-CODE cannot use the same format as ERROR-CODE, ADDRESS-ERROR-CODE signals the IP address family for which the warning is generated + all the fields in the ERROR-CODE. 
> 
>>
>>>
>>>>
>>>> Also I think we needs two different warnings, one that states that
>>>> dual allocation is not available in a TURNbis server, but both
>>>> protocols are available, and another that says that dual allocation
>>>> failed because one of the two protocols is not available.  This is to
>>>> let the client know that it is useless to try another allocation for the
>> missing protocol.
>>>
>>> I don't get the reason for two different warnings.
>>
>> A server may support both IPv6 and IPv4 allocations and not support dual
>> allocation, in which case the client can do a second allocation for the IPv6
>> relayed address.
> 
> If the server does not support dual allocation but supports both IPv6 and IPv4 allocations, it will only allocate the IPv4 relayed address and not will not return ADDRESS-ERROR-CODE in the response, the client will know the server does not understand the ADDITIONAL-ADDRESS-FAMILY attribute (ADDITIONAL-ADDRESS-FAMILY is a comprehension-optional attribute). 
> 
>>
>> Alternatively the server may not support IPv6 at all, in which case the second
>> allocation will fail and was unnecessary.
> 
> ADDRESS-ERROR-CODE signals both unsupported IP address type (0x02 (IPv6 address family)) and the reason for failure (440 (unsupported address family)). 
> 
> Cheers,
> -Tiru
> 
>>
>> Using two different warnings permits to know if the second allocation will
>> succeed or not.
>>
>>>
>>>>
>>>> What is the policy when reserving the next port with the EVEN-PORT
>>>> attribute in a dual allocation, but one of them fails to find a pair
>>>> of subsequent ports available?
>>>
>>> It's discussed in section 6.1
>>>
>>> <snip>
>>>    Clients MUST NOT
>>>    include ADDITIONAL-ADDRESS-FAMILY attribute in a Allocate request
>>>    that contains an EVEN-PORT attribute with the R bit set to 1.
>>> </snip>
>>>
>>>>
>>>> It is not said that the Allocate successful response must contain two
>>>> XRAs after a successful dual allocation.
>>>
>>> Good point, Updated draft.

I cannot find this update in turn-14.

>>>
>>>>
>>>> I would also suggest to add some text that says that when a TURNbis
>>>> server sends an Allocate success response, it must always send the
>>>> XRAs in the same order than the RAFs were sent.  So in case the
>>>> server sends back by mistake two XRAs, the first one matches the one
>> requested by the client.

Did not get answer to that and did not see it in turn-14.

>>>>
>>>> The bullet list at the end needs also to be fixed for dual allocation.
>>>
>>> Agreed, fixed.
>>>
>>>>
>>>> - Section 6.3
>>>>
>>>> Here's too, the text needs to be updated for the dual allocation case.
>>>
>>>
>>> Yup, updated.
>>>

Same, there is no update since -11 in section 7.3 (formerly 6.3)

-- 
Marc Petit-Huguenin
Email: [e-mail]
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug