> On Jun 6, 2019, at 9:12 AM, Konda, Tirumaleswar Reddy <TirumaleswarReddy_Konda@xxxxxxxxxx> wrote: > > Hi Joseph, > > Thanks for the review, Please see inline > >> -----Original Message----- >> From: tram <tram-bounces@xxxxxxxx> On Behalf Of Joseph Touch via >> Datatracker >> Sent: Wednesday, June 5, 2019 11:34 AM >> To: tsv-art@xxxxxxxx >> Cc: draft-ietf-tram-turnbis.all@xxxxxxxx; ietf@xxxxxxxx; tram@xxxxxxxx >> 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- >> art@xxxxxxxx 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. 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) > >> >> 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 ? The doc currently indicates that UDP relies only on IP fragmentation, but this isn’t the case with UDP options (there is a UDP-level frag and reassembly that preserves port numbers on each fragment and would thus be TURN-compatible). > >> >> 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 ? 576 is the reassembly MTU, but is also referred as the PMTU. The PMTU is EMTU_S and is strictly only 68. >> >> 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 >> tram@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/tram > _______________________________________________ > Tsv-art mailing list > Tsv-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tsv-art
