Re: [ippm] Benjamin Kaduk's No Objection on draft-ietf-ippm-stamp-09: (with COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Benjamin,
thank you for the comments. We'll continue working with the RFC Editor to
improve the text.
To address two other comments we propose updates as below in-line under the
tag GIM>>.
Also, attached are the working new version with the updates and the diff to
-09 version.
Please let us know if these updates are acceptable and address your
comments.

Regards,
Greg

On Wed, Oct 23, 2019 at 10:38 AM Benjamin Kaduk via Datatracker <
[e-mail]> wrote:

> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-ippm-stamp-09: 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 IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for addressing my Discuss points!
>
> A few final comments on the -09, though I don't think any response is
> needed
> for any of them:
>
> There's still some editing for grammar to do, but I will trust in the RFC
> Editor
> for that.
>
> Section 4.2's use of RFC 6038 as a reference for "the symmetrical size of
> test packets"
> with no section reference is a bit surprising, though perhaps not
> objectionable.
>
GIM>> Formats of TWAMP symmetrical packet and STAMP base packet have minor
differences. Thus we add a reference to Section 3 of RFC 6038 where the
Symmetrical Size capability is defined.

>
> Section 4.6 has changed the discussion of reflected packet size in
> STAMP/TWAMP
> interop scenarios, from "STAMP Session-Reflector will use a symmetric size"
> to "STAMP Session-Reflector will always transmit the base packet (i.e.,
> not a
> symmetric size)".  I will trust you that this is accurate, since I cannot
> confirm it myself.
>
GIM>> Propose the following update to the last paragraph in Section 4.6:
OLD TEXT:
   A STAMP Session-Reflector that supports this specification would
   transmit the base packet (Figure 5) regardless of the size of the
   Padding field in the packet received from TWAMP Session-Sender.
   Also, STAMP does not support the Reflect Octets capability defined in
   [RFC6038].  If the Server Octets field is present in the TWAMP
   Session-Sender packet, STAMP Session-Reflector will not copy the
   content starting from the Server Octets field and will transmit the
   reflected packet, as displayed in Figure 5.
NEW TEXT:
   A STAMP Session-Reflector that supports this specification will
   transmit the base packet (Figure 5) if it receives a packet smaller
   than the STAMP base packet.  If the packet received from TWAMP
   Session-Sender is larger than the STAMP base packet, the STAMP
   Session-Reflector that supports this specification will copy the
   content of the remainder of the received packet to transmit reflected
   packet of symmetrical size.