[Last-Call] Tsvart telechat review of draft-ietf-6man-mtu-option-13

Olivier Bonaventure via Datatracker <noreply@ietf.org> Mon, 11 April 2022 07:37 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: last-call@ietf.org
Delivered-To: last-call@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 468D13A1D8C; Mon, 11 Apr 2022 00:37:49 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Olivier Bonaventure via Datatracker <noreply@ietf.org>
To: <tsv-art@ietf.org>
Cc: draft-ietf-6man-mtu-option.all@ietf.org, ipv6@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.46.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <164966266918.19188.13337084939125855095@ietfa.amsl.com>
Reply-To: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Date: Mon, 11 Apr 2022 00:37:49 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/lF0lCdl-536ilHombZUnjzMYfHY>
Subject: [Last-Call] Tsvart telechat review of draft-ietf-6man-mtu-option-13
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Apr 2022 07:37:50 -0000

Reviewer: Olivier Bonaventure
Review result: Not Ready

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

The authors addressed some of the comments raised in the previous review, but
section 6.3 remains very vague on what transport layer protocols could do using
this option. I would expect a more precise description of how some transport
layer protocols (ICMPv6 could be the first protocol discussed in this section)
would use the proposed extension.

The following comments raised for version 12 have not been adequately addressed
:

Then the document can discuss in details the format of the proposed option.
Section 6 should be split in two parts: - a section that discusses the behavior
of routers based on the provided text - a section that discusses the behavior
of different transport layer protocols that could adopt the proposed solution.
It is fine if some transport are not discussed and only a subset of the
possible protocols are discussed, but for each discussed protocol, the
presentation should make it clear how the proposed option would be used by the
protocol. I would suggest to start with ping ICMP because this could be a good
approach to experiment with the proposed option and collect information from
experiments. DNS could also be a possibility since DNSSec responses could
benefit from this solution.