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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Hi Joseph,

Thanks for the review, Please see inline

> -----Original Message-----
> From: tram <[e-mail]> On Behalf Of Joseph Touch via
> Datatracker
> Sent: Wednesday, June 5, 2019 11:34 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: [tram] Tsvart last call review of draft-ietf-tram-turnbis-25
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
> 
> Reviewer: Joseph Touch
> Review result: Ready with Issues
> 
> This document has been reviewed as part of the transport area review
> team's ongoing effort to review key IETF documents. These comments were
> written primarily for the transport area directors, but are copied to the
> document's authors and WG to allow them to address any issues raised and
> also to the IETF discussion list for information.
> 
> When done at the time of IETF Last Call, the authors should consider this
> review as part of the last-call comments they receive. Please always CC tsv-
> [e-mail] if you reply to or forward this review.
> 
> As a preface, this review is performed focusing on the changes since RFC
> 5766, as this document appears to be a fairly direct update of that content.

Yes.

> 
> Transport issues:
> 
> Although this document has substantial implications for transport protocols,
> it does not significantly alter the content of RFC5766 in this regard. However,
> there is a significant gap as follows:
> 
> - The direct translation of TCP into UDP or UDP into TCP is arguably a host
> endpoint emulation function, which strongly suggests that this document
> needs to explicitly address both receiving and transmitting transport options.
> Even if all received options are ignored and no options are used on
> transmission, that should be more directly stated – as well as the impact of
> that decision, both on functionality and security.

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. 

> 
> Sec 2.7 might also note that the support for UDP fragmentation and
> reassembly could be of benefit here in avoiding IP fragmentation, but that
> would be contingent on the previous note – i.e., being able to use and react
> to UDP options in the translation process.

I don't get the comment, what specific change are you looking in the document ?

> 
> Non-transport issues:
> 
> Like RFC 5766, this doc continues to cite I-D.rosenberg-mmusic-ice-nonsip as
> guidance, even using a gentle version of “must”, but this no longer seems
> appropriate because that document has expired over a decade ago. Either
> the guidance should be summarized in this document or the
> recommendation should be removed.

Good point, Revised ICE specification (https://tools.ietf.org/html/rfc8445) has been updated to make the procedures independent of the signaling protocol by removing the SIP and SDP procedures.

I have updated the text as follows:

   For example, if TURN and ICE are used as part of a multimedia
   solution using SIP [RFC3261], then SIP serves the role of the
   rendezvous protocol, carrying the ICE candidate information inside
   the body of SIP messages [I-D.ietf-mmusic-ice-sip-sdp].  If TURN and
   ICE are used with some other rendezvous protocol, then ICE provides
   guidance on the services the rendezvous protocol must perform.

> 
> Section 2.7 is incorrect in its claim of 576 for IPv4; it confuses the receiver
> reassembly minimum (EMTU_R, 576) for the link MTU (EMTU_S, 68). See
> draft-ietf-tunnels for details. If 576 is the focus, at best it could be claimed
> that 576 is the “de-facto” EMTU_S for IPv4. Other nits:

Section 2.7 says IPv4 host must be capable of receiving a packet whose length is equal to 576 bytes (EMTU_R, 576).  
Why do you say the text is incorrect ?

> 
> Sec 23 indicates the changes since RFC5766; a similar section addressing
> changes since RFC6156 would be useful to add.

Okay, added another Section (updates to RFC6156).

Cheers,
-Tiru

> 
> 
> _______________________________________________
> tram mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tram