[tram] Éric Vyncke's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Sun, 07 July 2019 08:18 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: tram@ietf.org
Delivered-To: tram@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A4612002E; Sun, 7 Jul 2019 01:18:44 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tram-turnbis@ietf.org, Brandon Williams <brandon.williams@akamai.com>, tram-chairs@ietf.org, brandon.williams@akamai.com, tram@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.98.2
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <156248752430.14312.15895119889558390147.idtracker@ietfa.amsl.com>
Date: Sun, 07 Jul 2019 01:18:44 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/gXZ957FF7vHHsjFmasAIuyAtQpo>
Subject: [tram] Éric Vyncke's No Objection on draft-ietf-tram-turnbis-27: (with COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Jul 2019 08:18:44 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-tram-turnbis-27: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you all for the work put into this clear and well-written document. I also appreciate the fact that TURN server can be used to proxy between IPv4 and IPv6; on this topic, this specific use case could probably be described early in the document rather then in section 5 (e.g. when discussing the transport protocol between client and server or even earlier). For my own curiosity, isn't TURN scope broader than plain NAT: can it also be useful in the absence of NAT if inbound 'connection' are blocked by security policy ? == COMMENTS == -- Section 2 -- Please use the new boilerplate RFC 8174 ;-) -- Section 3.1 -- Is there any reason why MPTCP is not specified for the communication between TURN client and TURN server? There is a very short explanation in section 15 "TCP multi-path is not used by both SIP and WebRTC protocols [RFC7478] for media and non-media data" but it does not address the use of MPTCP between TURN client/server. -- Section 3.7 -- The 500 bytes guideline to avoid fragmentation, is there any data backing the sentence "...will generally avoid IP fragmentation." ? In the same section, the text about 'DF bit' should be clear that it is obviously for IPv4 (it is indicated 2 paragraphs below). -- Section 3.9 -- The TCP/UDP/DTLS discussion of 'happy eyeball' is confusing between "use the first TCP connection that is established" and "if connections are established on both IP address families..." Which sentence should be used? Why plain RFC 8305 is not enough? -- Section 7.2 -- What is the expected server behavior when receiving a DONT-FRAGMENT when the REQUESTED-ADDRESS-FAMILY is IPv6 ? The STUN document appears to use DONT-FRAGMENT only when receiving traffic from the peers. -- Section 9 -- About the permission based on the peer IP address, the text is about UDP, but what about ICMP messages? (obvioulsy their source could be any router on the path) The text should refer to section 11.5
- [tram] Éric Vyncke's No Objection on draft-ietf-t… Éric Vyncke via Datatracker
- Re: [tram] Éric Vyncke's No Objection on draft-ie… Konda, Tirumaleswar Reddy
- Re: [tram] Éric Vyncke's No Objection on draft-ie… Eric Vyncke (evyncke)
- Re: [tram] Éric Vyncke's No Objection on draft-ie… Magnus Westerlund
- Re: [tram] Éric Vyncke's No Objection on draft-ie… Konda, Tirumaleswar Reddy
- Re: [tram] Éric Vyncke's No Objection on draft-ie… Konda, Tirumaleswar Reddy
- Re: [tram] Éric Vyncke's No Objection on draft-ie… Eric Vyncke (evyncke)
- Re: [tram] Éric Vyncke's No Objection on draft-ie… Konda, Tirumaleswar Reddy