[ippm] Re: draft-ietf-ippm-asymmetrical-pkts-10 ietf last call Genart review

[Greg Mirsky <[e-mail]>]

Thank you, Christer, for your kind consideration of the proposed update.
We'll upload the new version before the submission deadline for IETF-125.

Regards,
Greg

On Tue, Feb 17, 2026 at 12:12 AM Christer Holmberg <
[e-mail]> wrote:

> Hi Greg,
>
> I am fine with your suggestions. Thank You for addressing my comments.
>
> Regards,
>
> Christer
>
> > -----Original Message-----
> > From: Greg Mirsky <[e-mail]>
> > Sent: Tuesday, 17 February 2026 7.50
> > To: Christer Holmberg <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; [e-mail]
> > Subject: Re: draft-ietf-ippm-asymmetrical-pkts-10 ietf last call Genart
> review
> >
> > Hi Christer,
> > thank you for your kind consideration of our work and the helpful
> > suggestions. Please find my notes below tagged GIM>>.
> >
> > Regards,
> > Greg
> >
> > On Wed, Feb 11, 2026 at 3:09 AM Christer Holmberg via Datatracker
> > <[e-mail] <mailto:[e-mail]> > wrote:
> >
> >
> >       Document: draft-ietf-ippm-asymmetrical-pkts
> >       Title: Performance Measurement with Asymmetrical Traffic Using
> > Simple Two-Way
> >       Active Measurement Protocol (STAMP) Reviewer: Christer Holmberg
> > Review result:
> >       Ready with Nits
> >
> >       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
> >
> >       <https://wiki.ietf.org/en/group/gen/GenArtFAQ
> > <https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.
> > ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=05%7C02%7Cchrister.
> > holmberg%40ericsson.com%7C6bec1ce3ca9346fbdb9608de6de86fff%7C92
> > e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639069042237916777
> > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
> > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> > %7C%7C&sdata=11Cc5nJRzgGBU5TujBupGNMAmAfXZgLouYEnkpKUPtA%3D
> > &reserved=0> >.
> >
> >       Document: draft-ietf-ippm-asymmetrical-pkts-10
> >       Reviewer: Christer Holmberg
> >       Review Date: 2026-02-11
> >       IETF LC End Date: 2026-02-18
> >       IESG Telechat date: Not scheduled for a telechat
> >
> >       Summary: The document is well written, and easy to understand. I
> > only have a
> >       couple of editorial comments that I would like the authors to
> address.
> >
> >       Major issues: N/A
> >
> >       Minor issues: N/A
> >
> >       Nits/editorial comments:
> >
> >       Q1:
> >
> >       The Abstract is far too long. I think it would be enough with
> something
> > like:
> >
> >       "This document specifies an optional extension to the Simple Two-
> > way
> >       Active Measurement Protocol (STAMP) to control the length and/or
> >       number of packets sent by a Session-Reflector in response to a
> single
> >       test packet from the Session-Sender during a STAMP test session.
> >       This supports cases where a Session-Reflector responding with
> >       Asymmetrical Packets would ensure a closer approximation between
> >       active performance measurements and the conditions experienced by
> >       monitored application."
> >
> >
> > GIM>> Indeed, the Abstract is better when it is not too wordly. At the
> same
> > time, it would be helpful to a reader if terms used in the Abstract are
> well-
> > known. "Asymmetrical packets", in fact, is the term introduced in this
> > document. Perhaps is slightly different version of the Abstract would be
> > acceptable:
> > NEW TEXT:
> >    This document defines an optional STAMP extension that allows a
> >    Session-Reflector to send packets whose length or quantity differs
> >    from those sent by the Session-Sender.  While standard STAMP
> >    exchanges packets symmetrically, some measurement scenarios benefit
> >    from asymmetric response packets to better reflect real application
> >    conditions.  This extension enables the Session-Reflector to send
> >    packets of different sizes and/or additional packets not tied one-
> >    for-one to incoming test packets.  The document also analyzes
> >    challenges in multicast performance monitoring and specifies STAMP
> >    procedures to improve measurement efficiency and reduce network
> >
> >    impact.
> >
> >
> >       Q2:
> >
> >       In the Introduction, I suggest to put the current 1st chapter to
> the
> > end. First
> >       describe what the draft does, and then how it does it.
> >
> >
> > GIM>> The first paragraph references RFC 7497, the Rate Measurement Test
> > Protocol Problem Statement and Requirements, in which the case for
> > asymmetrical performance measurement is formulated. The second paragraph
> > of the Introduction introduces "asymmetrical packets". Third paragraph -
> > refers to specific challenges of performance measurement, including rate
> > measurement, in a multicast environment. Considering that, would
> > maintaining the existing sequence of paragraphs be acceptable?
>