[tram] Mirja Kühlewind's Yes on draft-ietf-tram-stunbis-16: (with COMMENT)

Mirja Kühlewind <ietf@kuehlewind.net> Mon, 16 April 2018 19:29 UTC

Return-Path: <ietf@kuehlewind.net>
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 07C82120725; Mon, 16 Apr 2018 12:29:18 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Mirja Kühlewind <ietf@kuehlewind.net>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-tram-stunbis@ietf.org, Gonzalo.Camarillo@ericsson.com, Tolga Asveren <tasveren@rbbn.com>, tram-chairs@ietf.org, tasveren@rbbn.com, tram@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.78.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <152390695800.19624.250040937113641569.idtracker@ietfa.amsl.com>
Date: Mon, 16 Apr 2018 12:29:18 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/uM6QEb4C-zUQpOpzAIedSAo4SIE>
Subject: [tram] Mirja Kühlewind's Yes on draft-ietf-tram-stunbis-16: (with COMMENT)
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 16 Apr 2018 19:29:18 -0000

Mirja Kühlewind has entered the following ballot position for
draft-ietf-tram-stunbis-16: Yes

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:


1) Maybe it would make sense to refer informationally to
draft-ietf-tram-stun-pmtud in section 6.1?

2)  sec 6.2.2: This sentence seems to assume that only one request is sent per
TCP connection/each request sends out after a new SYN: "However, for a
request/response transaction, if the client has not
   received a response by Ti seconds after it sent the SYN to establish
   the connection, it considers the transaction to have timed out.“
i don’t think that assumption would be correct. Maybe rephrase this sentence…?

3) Also section 6.2.2: Should the client send keep-alives if a connection is
hold open but currently not used? If not, I guess further recommendation is
needed to address the case where a transmission fails because an existing idle
TCP connection was used that doesn’t work anymore. In this case, I'd say the
recommendation would be to send a RST and try to open a new TCP connection.

4) Should section 9.2 maybe provide further guidance on the lifetime of the
(server-selected) nonce?

5) I'm sure, I just missed something but how does a server know if a first
request intends to use the Long-Term Credential Mechanism or not (see
and 9.2.4 I guess). Or is this pre-configured?

6) Section 6.3 says that this doc only specifies the procedures for the new
spec in this document and subsequently says: "It checks [...] that the magic
cookie field has the correct value..." However, given this spec obsoletes
RFC5389, I think that section 11 should provide more guidance on how to handle
"old" STUN messages. Or is the intention that an upgraded STUN server does not
handle old requests anymore? If so that should be spelled out as well.

7) sec 14.5: "The value of the MESSAGE-INTEGRITY attribute is set to a dummy
value." Should the dummy value be further specified? Also it looks like there
was a compile problem on page 39. Is there text missing?

8) sec 17.6: Isn't "stuns  5349/upd" used for DTLS? If so, it should be