[ippm] Re: Mike Bishop's No Objection on draft-ietf-ippm-asymmetrical-pkts-11: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Mike,
Thank you for your thorough review and helpful suggestions. Please find my
notes below, tagged GIM>> below. I attached the TXT version of the working
document and the diff, highlighting all updates applied, addressing all
DISCUSSes and COMMENTS from the IESG reviewers.

Regards,
Greg

On Mon, Mar 2, 2026 at 8:58 AM Mike Bishop via Datatracker <[e-mail]>
wrote:

> Mike Bishop has entered the following ballot position for
> draft-ietf-ippm-asymmetrical-pkts-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/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # IESG review of draft-ietf-ippm-asymmetrical-pkts-11
>
> CC @MikeBishop
>
> ## Nits
>
> All comments below are about very minor potential issues that you may
> choose to
> address in some way - or ignore - as you see fit. Some were flagged by
> automated tools (via https://github.com/larseggert/ietf-reviewtool) so
> there
> will likely be some false positives. There is no need to let me know what
> you
> did with these suggestions.
>
> ### Typos
>
> ### Paragraph 0
> ```
>   Network Working Group                                          G. Mirsky
> ```
> Shouldn't this be IPPM?
>
GIM>> Thank you for catching it.

>
> ### Grammar/style
>
> #### Asymmetrical vs. Asymmetric
>
> A quick search suggests these are equivalent words. Unless you have a
> precise rule
> for when you're using one versus the other, consider picking one and using
> it
> consistently. (I think "asymmetric" sounds better in context, FWIW.)
>
> Also, an "asymmetrical packet" sounds like the packet itself is lopsided;
> consider
> using this term primarily to describe the traffic pattern, since the
> effect you're
> describing is that there's more traffic from one party than the other.
>
GIM>> We updated the texts as follows:
In Terminology:
   In this document, "asymmetrical packets" has two meanings, depending
   on the context.  The first aspect is asymmetry in packet size between
   a packet sent by a Session-Reflector and the packet it received from
   the Session-Sender.  The second aspect is asymmetry in the number of
   packets the Session-Reflector transmits in response to receiving a
   single STAMP test packet.
In Introduction:
   By default, a STAMP Session-Sender and a Session-Reflector exchange
   packets symmetrically: the number of packets sent by the Session-
   Reflector and the Session-Sender are the same and the length of the
   packets sent by the Session-Reflector and the Session-Sender are the
   same.  However, in some scenarios, e.g., rate measurements discussed
   in [RFC7497], it would be beneficial for a Session-Reflector to
   respond with asymmetrical test packets: packets whose length is not
   symmetrical to the test packet sent by the Session-Sender and/or
   packets that are not sent in direct response to a packet received
   from a Session-Sender.  The optional extension defined in this
   document gives operators the tools to create such asymmetrical
   packets between a Session-Sender and a Session-Reflector.

Do you find these updates helpful, making the document more clear?

>
> #### Section 2, paragraph 18
> ```
> ]) is set to No Reply Requested. If this the intended behavior, use of the
> Re
>                                     ^^^^
> ```
> A verb may be missing.
>
GIM>> This is reference to RFC 9503
<http://atatracker.ietf.org/doc/rfc9503/>:
   Control Code Flags (32 bits):  Reply Request Flag at bit 31 (least
      significant bit) is defined as follows.

      0x0:  No Reply Requested

      0x1:  Reply Requested on the Same Link