[tram] Ben Campbell's No Objection on draft-ietf-tram-stun-pmtud-10: (with COMMENT)

Ben Campbell <ben@nostrum.com> Wed, 26 September 2018 19:33 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 7F637128CFD; Wed, 26 Sep 2018 12:33:30 -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-stun-pmtud@ietf.org, Gonzalo Camarillo <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.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153799041044.21545.15688918373860539781.idtracker@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 12:33:30 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/Xx4kXdVaMRQMZP8idgvG7t-2m9A>
Subject: [tram] Ben Campbell's No Objection on draft-ietf-tram-stun-pmtud-10: (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: Wed, 26 Sep 2018 19:33:31 -0000

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


I support Adam's DISCUSS. I will go a bit further to say that, even if a new
IETF LC occurs, I would be skeptical that the dependency on PADDING in a
standards track protocol is appropriate unless people are willing to argue that
RFC 5780 has become mature enough that it could reasonably be promoted to
standards track.

Another alternative might be to re-describe PADDING in this draft, as it is
used in the context of the draft. I don't normally love that sort of
duplication, but it might be appropriate here.

Other comments:

§2: "It is not intended as a replacement for [RFC4821]": I find this comment
confusing. Are other sections in the document intended to replace some or all
of 4821?

§4: "The probing mechanism is used to discover the Path MTU in one direction
only...": Can this mechanism not be used bidirectionally, with reciprocal
client-server roles?

§4.1.2: "The server MUST add the FINGERPRINT attribute...": Is this a new
requirement for PMTUD, or a generic STUN requirement? If the latter, it should
not be stated normatively. (Same comment for §4.2.1)

§4.2.1: "If the authentication mechanism permits it, then the Indication MUST
be authenticated": Is that intended to imply it's okay to use authentication
mechanisms that don't allow this?