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. > > 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 > tram@xxxxxxxx > https://www.ietf.org/mailman/listinfo/tram
