[ippm] Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-capacity-metric-method-10: (with COMMENT)

Zaheduzzaman Sarker via Datatracker <noreply@ietf.org> Fri, 28 May 2021 12:58 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 35A4C3A27F7; Fri, 28 May 2021 05:58:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Zaheduzzaman Sarker 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: Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
Message-ID: <162220671966.6728.1925413023818681484@ietfa.amsl.com>
Date: Fri, 28 May 2021 05:58:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/ZcBWfh4RXTwTxfWIH5YVzzquT2k>
Subject: [ippm] Zaheduzzaman Sarker's No Objection on draft-ietf-ippm-capacity-metric-method-10: (with COMMENT)
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: Fri, 28 May 2021 12:58:40 -0000

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-ippm-capacity-metric-method-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 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:
----------------------------------------------------------------------

Thanks for the work on the document. I consider this document to be an
important one when it comes to IP layer capacity for access networks.

After my review and observing the IPPM working group discussions, I consider
the valid discuss points raised by Magnus Westerlund is now addressed in the
-10 version of this document.

please find my comments and observations below -

* Major Issue: I didn't find any restriction imposed by the memo on the number
of allowed concurrent tests between same Source and Destination. My
understanding is this memo should either strictly prohibit the concurrent tests
between same Source and Destination or provide a maximum limit of concurrent
tests where the algorithm has been tested to provide valid results. I am not
going to hold a discuss on this but I would like to be corrected if I am wrong
in the understanding.

* Minor Issues , nits:

   ** I found it a bit odd to not find Magnus Westerlund's name in the
   acknowledgement section as his review and comments has improved the
   algorithms and the document a lot. I would encourage the author's to include
   names of the individuals who has provided any sort of review (including the
   directorate reviews) that improved this document.

   ** Section 2:

      *** I am not getting the context of "local goal", what does it really
      mean?

      *** I kind of feel that the paragraph 2 and 3 should swap their order to
      focus the goal of "defining efficient test procedure" and then
      "harmonizing the metric and method across the industry" becomes "another
      goal". This is based on the current text which makes me feel there are
      number of goals and the ranks (if there is any) of the goals are not
      clear. If there is not rank among the goals then simply putting them in a
      bullet list would help the readability.

   ** Section 8.1:

      *** paragraph 1: s/ agressiveness / aggressiveness .

      *** paragraph 2: It will be helpful if it is mentioned who pre-builts the
      table and  who (and where) it will be used.

   ** Section 10 : I find 4, 5, 6 of the new security considerations introduced
   in this section not entirely security related rather general considerations
   on how to run the tests. I think those mentioned considerations are more
   suitable to put it in section 8 (in section 8.3). I understand the feeling
   the everyone should read the security considerations but there is no
   guarantee that it is the case specially while implementing the tests. Hence,
   putting then in section 8 likely will bring these to attention early.