Re: [Tsv-art] [tram] Tsvart last call review of draft-ietf-tram-turnbis-25

[Joe Touch <[e-mail]>]

Hi, Tiru,

> On Jun 9, 2019, at 11:43 PM, Konda, Tirumaleswar Reddy <[e-mail]> wrote:
> 
>> On Jun 7, 2019, at 4:39 AM, Konda, Tirumaleswar Reddy
>> <[e-mail]> wrote:
>> 
>>>>> The specification has two sections 14 and 15 (IP Header Fields for
>>>>> UDP-to-
>>>> UDP translation and IP Header Fields for TCP-to-UDP translation) to
>>>> discuss direct translations. https://tools.ietf.org/html/rfc5766 only
>>>> covered UDP-to- UDP translation in Section 12.
>>>> 
>>>> Yes, but both sections ignore the impact of transport options - both
>>>> current for TCP and pending for UDP. These are ignored both when
>>>> packets with such transport options are received (the input packet to
>>>> the translation) and whether / how they are used on transmit (the
>>>> output packet)
>>> 
>>> TURN is used to relay real-time data (e.g. audio and video streams)
>>> and the approach taken by VOIP related specifications is to avoid
>>> fragmentation for RTP packets
>> 
>> Sec 2.8 mentions RTP as one use case envisioned (at this point, it’d be fair to
>> ask this revision to clarify whether that turned out to be true). But it isn’t
>> indicated as the only use case.
> 
> The draft says TURN is invented to support multimedia sessions signaled using SIP and is typically used with ICE. TURN is also used with WebRTC, and WebRTC data channels also 
> avoid IP fragmentation (see https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13 <https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13>). 

The application protocols TURN is designed for or typically used for is not relevant to my point above, unless you’re claiming that these uses never use transport options (which is doubtful for TCP, for which some transport options are pervasively used by default).

> 
>> 
>> Regardless, though, this doesn’t impact the concern raised above. RTP could
>> still employ transport options.
> 
> I checked again and don't see any RTP, Back-to-Back User Agents (B2BUAs), SIP proxies and WebRTC gateway specifications discussing transport options for translations.

The fact that others have this gap does not justify continuing to fail to address it in this document. If anything, it makes it that much more important to address.

Joe