[ippm] Éric Vyncke's No Objection on draft-ietf-ippm-capacity-metric-method-11: (with COMMENT)

Éric Vyncke via Datatracker <noreply@ietf.org> Thu, 03 June 2021 11:39 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D555D3A07A2; Thu, 3 Jun 2021 04:39:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: =?utf-8?q?=C3=89ric_Vyncke_via_Datatracker?= <noreply@ietf.org>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-ippm-capacity-metric-method@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, Ian Swett <ianswett@google.com>, tpauly@apple.com, tpauly@apple.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: =?utf-8?q?=C3=89ric_Vyncke?= <evyncke@cisco.com>
Message-ID: <162272035584.18166.1892710574472210395@ietfa.amsl.com>
Date: Thu, 03 Jun 2021 04:39:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/o95uinFh4L1ZmiueXaLhLOObUTE>
Subject: [ippm] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-ippm-capacity-metric-method-11=3A_=28with_COMMENT=29?=
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 11:39:17 -0000

Éric Vyncke has entered the following ballot position for
draft-ietf-ippm-capacity-metric-method-11: 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 DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-ippm-capacity-metric-method/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated).

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==

Generic comment about the 1 Mbps granularity, this may of course be well suited
for many connection but not really for constrained networks where the
measurement techniques of this I-D could be applied.

Should the payload content random content to avoid some compression techniques
on the path ?

-- Section 4 --
s/the address of a host/one of the IP addresses of a host/

Should there be a SHOULD rather than a MAY in "The IPv6 flow label MAY be
included" ?

-- Section 5.3 --
"   o  n0 is the total number of IP-Layer header and payload bits that
      can be transmitted in standard-formed packets [RFC8468] from the
      Src host and correctly received by the Dst host during one
      contiguous sub-interval, dt in length, during the interval [T,
      T+I],"

If we want to split hairs, in the case of IP fragmentation or NAT64, the
received bits will be different than the one sent ;-) I had no time to read RFC
8468 (day job...), but, does the above remark fall in the same category as
"Some compression affects on measurement are discussed in Section 6 of
[RFC8468]."

-- Section 8.3 --
"  The number of concurrent, independent tests between
   the same Source and Destination SHALL be limited to one."

Is it between hosts or between network? I.e.n "same source and destination
networks?"

-- Section 8.4 --
"supports IPv4 and IPv6 address families." does it support a NAT64 function on
the path ?