[tsvwg] Martin Duke's Yes on draft-ietf-tsvwg-datagram-plpmtud-17: (with COMMENT)

Martin Duke via Datatracker <noreply@ietf.org> Tue, 31 March 2020 01:56 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: tsvwg@ietf.org
Delivered-To: tsvwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 85D383A17BE; Mon, 30 Mar 2020 18:56:19 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Martin Duke via Datatracker <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-tsvwg-datagram-plpmtud@ietf.org, tsvwg-chairs@ietf.org, tsvwg@ietf.org, Wesley Eddy <wes@mti-systems.com>, wes@mti-systems.com
X-Test-IDTracker: no
X-IETF-IDTracker: 6.123.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Martin Duke <martin.h.duke@gmail.com>
Message-ID: <158561977952.11604.17536804469227337572@ietfa.amsl.com>
Date: Mon, 30 Mar 2020 18:56:19 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/fMph-vMbZrT6XUZRQoMr1sAt8eg>
Subject: [tsvwg] Martin Duke's Yes on draft-ietf-tsvwg-datagram-plpmtud-17: (with COMMENT)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 31 Mar 2020 01:56:20 -0000

Martin Duke has entered the following ballot position for
draft-ietf-tsvwg-datagram-plpmtud-17: 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:


I'm excited for this to go to RFC once the QUIC reference clears.

Normative issue:

Sec 3, item #9 "An update to the PLPMTU (or MPS) MUST NOT modify the congestion
window". Would it not be OK to round down the congestion window to remain a
multiple of the MPS? Probably not a big issue in practice, but I would hate to
constrain an implementer in this way. I would suggest "MUST NOT increase".


Sec 2. In the definition for EMTU_R, put "the largest datagram size that can be
reassembled" in quotes, and delete "by EMTU_R (Effective MTU to receive)"

Sec 4.1. delete word in brackets:  "A PL that uses a probe packet carrying [an]
application data..."

Sec 4.6.2 I think this list of inequalities would be easier to read if it was
ranked in order of increasing PL_PTB_SIZE.

5.1.1. s/up to data/up to date