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 < [email protected]> wrote: > Hi Greg, > > I am fine with your suggestions. Thank You for addressing my comments. > > Regards, > > Christer > > > -----Original Message----- > > From: Greg Mirsky <[email protected]> > > Sent: Tuesday, 17 February 2026 7.50 > > To: Christer Holmberg <[email protected]> > > Cc: [email protected]; [email protected]; > > [email protected]; [email protected] > > 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 > > <[email protected] <mailto:[email protected]> > 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? >
_______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
