[bmwg] Genart last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-06

Robert Sparks <rjsparks@nostrum.com> Wed, 26 April 2017 16:05 UTC

Return-Path: <rjsparks@nostrum.com>
X-Original-To: bmwg@ietf.org
Delivered-To: bmwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 960B11300E8; Wed, 26 Apr 2017 09:05:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Sparks <rjsparks@nostrum.com>
To: <gen-art@ietf.org>
Cc: draft-ietf-bmwg-ipv6-tran-tech-benchmarking.all@ietf.org, ietf@ietf.org, bmwg@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <149322271242.5954.6564310624067283031@ietfa.amsl.com>
Date: Wed, 26 Apr 2017 09:05:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/NUBEEN2tkGx_1G1qcgT81RRHlO0>
Subject: [bmwg] Genart last call review of draft-ietf-bmwg-ipv6-tran-tech-benchmarking-06
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Apr 2017 16:05:22 -0000

Reviewer: Robert Sparks
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at


Document: draft-ietf-bmwg-ipv6-tran-tech-benchmarking-06
Reviewer: Robert Sparks
Review Date: 2017-04-26
IETF LC End Date: 2017-05-02
IESG Telechat date: Not scheduled for a telechat

Summary: Essentially Ready for publication as an Informational RFC,
but with some minor issues to address before publication

This document is (with exceptions noted below) straightforward and
easy to follow

Minor Issues:

Section 8 is very confusing - I suspect it has been made so by
removing things that were in it earlier. Right now it claims to
provide additional tests, but the only content is about testing things
with firewalls, along with a statement that this document is only
targeting network devices that do not have a firewall function. I
think you can keep most of the text here (except the statement that
you aren't talking about things with firewalls) and remove the
confusion by changing the section heading to something like "Tests in
the presence of a firewall function".

It's unclear how to apply the formula in Section 10.2.1 to the results
that come out of, say, Section 7.3.2, where you are reporting a
(minimum, median, maximum) tuple. Some discussion about the
applicability of the tests where you recommend against reporting a
single number to the methods in this section would help. It would also
help to point out that the Xpd result can be go negative (it will go
negative for things that become smaller as the number of flows
increase, and positive for things that get bigger). If I read this
correctly, if throughput (for example) goes to 0 as n increases, Xpd
will go to -100%. Similary if latency doubles as n increases, Xpd will
go to +100% (and will go to +200% if latency triples).


There are several places where you point to Section 6 where I think
you meant to point to Section 7. See the Procedure: line in 10.2.1 for
an example. Also make sure 9 is correct where you say "Sections 6
through 9" in section 12.

Please double-check that you meant "larger MTU" in the last paragraph
of 5.1. It might be correct, but I find the paragraph confusing.

In 8.1 you meant to point to 5.2, not 5.3

Please try to simplify this sentence: 
  "The duration of each trial SHOULD be at least 60 seconds to reduce
the potential gain of a DNS64 server, which is able to exhibit higher
performance by storing the requests and thus utilizing also the
timeout time for answering them."

(Style comment - please feel free to ignore): Consider deleting "as
well" everywhere it occurs in the document - most of the places it is
used, the sentence works just as well, and sometimes better, without

end of section 5.1.1: Appendix A1 should be Appendix A
please remove the comma in the first sentence of the second paragraph
of section 5.2