[tram] Ben Campbell's No Objection on draft-ietf-tram-stunbis-16: (with COMMENT)

Ben Campbell <ben@nostrum.com> Tue, 17 April 2018 02:11 UTC

Return-Path: <ben@nostrum.com>
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 399651270AC; Mon, 16 Apr 2018 19:11:03 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Ben Campbell <ben@nostrum.com>
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: <152393106321.26096.12146305230255636553.idtracker@ietfa.amsl.com>
Date: Mon, 16 Apr 2018 19:11:03 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/eeZZzW3R7Zz1hgmolRD7b6it4aI>
Subject: [tram] Ben Campbell's No Objection 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: Tue, 17 Apr 2018 02:11:03 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-tram-stunbis-16: 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:


Hi, thanks for this work. For the record, I have mainly reviewed the diff.

General: I think Peter's ART-ART review has some points worth addressing.

§1, last paragraph: This seems out of place. Also, I wonder if it should be
stated more strongly, perhaps with a SHOULD or even MUST.

§3: RFC 8174 offers it's own recommended boilerplate; is there a reason not to
use it?

§6.2.1, third paragraph: " The value SHOULD be considered stale and discarded
   10 minutes without any transactions to the same server. "
This is a bit ambiguous. I think it means the value is stale if no transactions
have occurred in the last 10 minutes, But I think it could be read to say that
there should be no transactions to the same server once one considers the value
as stale.

§9.1.4: Does it make sense to signal that "an attack took place" rather than
signaling "integrity protection was violated" and let the human operators
decide if that implies an attack?

§14.3: "A compliant implementation MUST
   be able to parse UTF-8 encoded sequence of less than 763."

763 whats?

§15.3, 2nd bullet: I'm not sure I understand what is meant by "get an updated
external mechanism"