[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