[ippm] Re: WG Last Call: draft-ietf-ippm-stamp-ext-hdr-08 (Ends 2026-06-25)

[Rakesh Gandhi <[e-mail]>]

Hi Greg,

Thank you for your follow-up comments. One reply below with <RG4>

<snip>








*<RG2> STAMP test packets MUST NOT carry more than one "IPv6 Extension
 Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
 the "Reflected Test Packet Control" TLV in the Session-Sender test
 packet contains more than one "IPv6 Extension Header Control" Sub-   TLV,
the Session-Reflector MUST return the "Reflected Test Packet   Control" TLV
with the U flag (Unrecognized TLV) set to 1 in the Sub-   TLV Flags of all
"IPv6 Extension Header Control" Sub-TLVs, using the   procedure defined in
[RFC8972].*


GIM3>> Could it be that the C flag is more suitable in this case? As I
understand it, the Session-Reflector recognizes the IPv6 Extension Header
Control sub-TLV, but finds that the Reflected Test Packet Control TLV
includes more than one IPv6 Extension Header Control sub-TLV. In other
word, construction of the Reflected Test Packet Control TLV is
non-conformant to this specification. WDYT?

<RG4> Ok, updated to use the C flag for this case in the latest revision.

Thanks,
Rakesh (for authors)






On Fri, Jun 26, 2026 at 11:43 AM Rakesh Gandhi <[e-mail]>
wrote:

> Hi Greg,
>
> Thank you for reviewing the suggested updates.
>
> Please see the replies inline with <RG3>...
>
>
> And I apologize for coming back to my question about the figures that
> display examples of STAMP test packets for Session-Sender and
> Session-Reflector. As defined in RFC 8972, the Extra Padding TLV is used to
> make STAMP packets symmetrical. If that is also the case for the Reflected
> IPv6 Extension Header Data STAMP TLV and the Fixed IPv6 Header Data TLV, it
> seems that the Extra Padding TLV must be reflected in figures. WDYT?
>
>
> <RG2> Both Session-Sender and Session-Reflector test packets carry the
> same number of Reflected IPv6 Extension Header Data STAMP and the Fixed
> IPv6 Header Data TLVs, making them symmetric in size, no?
>
>
> GIM3>> Thank you for confirming that to me. My question was about the use
> of the Extra Padding TLV in the STAMP test packet constructed by the
> Session-Sender. It seems that attribution of Figure 1 to both
> Session-Sender and Session-Reflector hides from a reader that the STAMP
> test packet transmitted by the Session-Sender MUST have Extra Padding TLV
> to make up for the difference in  length between base and reflected packets.
>
> <RG3> I fail to see how extra padding would be applicable to this draft as
> Sender adds new fixed length STAMP TLVs defined in this draft and Reflector
> sends them back with data. So the reflected STAMP packet size does not
> change.
>
> GIM3>> Also, should the document clarify whether the Session-Reflector
> must use information other than the Type field value, in IPv6 Extension
> Header Data or Fixed Header Data TLVs for sanity verification? If nothing
> of the kind, should the document state that all Value fields MUST be zeroed
> on transmission by the Session-Sender and ignored by the Session-Reflector
> on receipt?
>
> <RG3> This is covered in the “Requested IPv6 Extension Header Data” field
> in the draft where additional fields are compared.
>
>
>
> --------------------------------------------------------------------------------
>
>
> GIM3>> Could you please clarify to which STAMP TLV and Sub-TLV this
> applies?
>
> <RG3> Revised the text as follows to add these TLV and Sub-TLV.
>
>   * If the Session-Reflector cannot add a new matching IPv6 extension*
> *   header in the Session-Reflector test packet, the Session-Reflector*
> *   MUST return the "Reflected Test Packet Control" TLV with the C flag*
> *   (Conformance) set to 1 in the Sub-TLV Flags of the "IPv6 Extension*
> *   Header Control" Sub-TLV using the procedure defined in*
> *   [I-D.ietf-ippm-asymmetrical-pkts].  This can occur, for example, when*
> *   the Session-Reflector does not support the IPv6 extension header, or*
> *   when the Session-Reflector cannot access the received IPv6 extension*
> *   headers, etc.*
>
> ---------------------------------------------------------------------------------
>
>
>
> GIM2>> As I understand it (please correct me if I misunderstand it), the
> STAMP test packet transmitted by the Session-Sender includes M Reflected
> Extension Header Data TLVs. If that is the case, I assume that the C flag
> must be set in all Reflected Extension Header Data TLVs in the reflected
> STAMP test packet. Is that correct?
>
>
>
> <RG2> Revised the text as follows.
>
>
>
>
>
>
>
>
>
> *   When the Session-Reflector does not use the received "Reflected IPv6
>  Extension Header Data" TLV for reflecting the IPv6 extension header,   the
> Session-Reflector MUST return the STAMP TLV with the U flag   (Unrecognized
> TLV) set to 1 in the STAMP TLV Flags using the   procedure defined in
> [RFC8972].  This can occur, for example, if   there is a mismatch in the
> length between the received IPv6 extension   headers and the "Reflected
> IPv6 Extension Header Data" TLVs, or when   the Session-Reflector cannot
> access the received IPv6 extension   headers, etc.*
>
>
> GIM3>> I got confused when reading the previous text and the one above. It
> seems to me that the case when the Session-Reflector doesn't have access to
> IPv6 extension headers, the Session-Reflector MUST set both C and U flags
> in the TLV flags field of the IPv6 Extension Header Data TLV in the
> reflected STAMP test packet. Am I missing something here?
>
> <RG3> Revised the text as follows to indicate the TLV type to avoid
> confusion.
>
>    *When the Session-Reflector could not use the received "Reflected IPv6*
> *   Extension Header Data" TLV for reflecting any IPv6 extension header,*
> *   the Session-Reflector MUST return the "Reflected IPv6 Extension*
> *   Header Data" TLV with the U flag (Unrecognized TLV) set to 1 in the*
> *   STAMP TLV Flags using the procedure defined in [RFC8972].  This can*
> *   occur, for example, if there is a mismatch in the length between the*
> *   received IPv6 extension headers and the "Reflected IPv6 Extension*
> *   Header Data" TLVs, or when the Session-Reflector cannot access the*
> *   received IPv6 extension headers, or when the IPv6 extension header*
> *   corresponding to the "Requested IPv6 Extension Header Data" field was*
> *   not found, etc.*
>
>
> ---------------------------------------------------------------------------------
> <snip>
>
>
>
> GIM2>> I returned to the last paragraph of Section 5.3:
>    STAMP test packets MUST NOT carry more than one "IPv6 Extension
>    Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
>    a Session-Sender test packet contains more than one "IPv6 Extension
>    Header Control" Sub-TLV, the Session-Reflector MUST return the STAMP
>    TLV with the U flag (Unrecognized TLV) set to 1 in the STAMP TLV
>    Flags using the procedure defined in [RFC8972].
>
>
> I couldn't figure out in which TLV in the reflected STAMP test packt the U
> flag must be set to 1. Could you please clarify it for me.
>
>
>
> <RG2> Revised the test as follows:
>
>
>
>
>
>
>
>
> *   STAMP test packets MUST NOT carry more than one "IPv6 Extension
>  Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
>  the "Reflected Test Packet Control" TLV in the Session-Sender test
>  packet contains more than one "IPv6 Extension Header Control" Sub-   TLV,
> the Session-Reflector MUST return the "Reflected Test Packet   Control" TLV
> with the U flag (Unrecognized TLV) set to 1 in the Sub-   TLV Flags of all
> "IPv6 Extension Header Control" Sub-TLVs, using the   procedure defined in
> [RFC8972].*
>
>
> GIM3>> Could it be that the C flag is more suitable in this case? As I
> understand it, the Session-Reflector recognizes the IPv6 Extension Header
> Control sub-TLV, but finds that the Reflected Test Packet Control TLV
> includes more than one IPv6 Extension Header Control sub-TLV. In other
> word, construction of the Reflected Test Packet Control TLV is
> non-conformant to this specification. WDYT?
>
> <RG3> C flag is already used for the following case in this Sub-TLV.
> <RG3> U flag in Sub-TLV is used to distinguish the below case with the
> above case case for the multiple Sub-TLVs.
> <RG3> draft-ietf-ippm-asymmetrical-pkts unfortunately does not cover the
> multiple sub-TLVs case for "Reflected Test Packet Control” TLV although it
> defines several sub-TLVs.
> <RG3> I think, the draft-ietf-ippm-asymmetrical-pkts could also
> benefit from above U flag behaviour, since the C flag was already used for
> a different purpose in draft-ietf-ippm-asymmetrical-pkts.
>
> <RG3> Related existing text in the draft.
>
>    *If the Session-Reflector cannot add a new matching IPv6 extension*
> *   header in the Session-Reflector test packet, the Session-Reflector*
> *   MUST return the "Reflected Test Packet Control" TLV with the **C flag*
> *   (Conformance) set to 1 i**n the Sub-TLV Flags of the "IPv6 Extension*
> *   Header Control" Sub-TLV using the procedure defined in*
> *   [I-D.ietf-ippm-asymmetrical-pkts].  This can occur, for example, when*
> *   the Session-Reflector does not support the IPv6 extension header, or*
> *   when the Session-Reflector cannot access the received IPv6 extension*
> *   headers, etc.*
>
>
> Thanks,
> Rakesh (for authors)
>
>
>
>
>
> On Thu, Jun 25, 2026 at 6:53 PM Greg Mirsky <[e-mail]> wrote:
>
>> Hi Rakesh,
>> Thank you for your careful consideration of my notes and thoughtful
>> updates. Please find my additional notes below, tagged GIM3>>.
>>
>> Regards,
>> Greg
>>
>> On Wed, Jun 24, 2026 at 6:33 AM Rakesh Gandhi <[e-mail]>
>> wrote:
>>
>>> Hi Greg,
>>>
>>> Thank you for the further review comments and the discussions.
>>>
>>> Please see replies inline with <RG2>...
>>>
>>> On Tue, Jun 23, 2026 at 6:09 PM Greg Mirsky <[e-mail]>
>>> wrote:
>>>
>>>> Hi Will,
>>>> Thank you for your thoughtful proposal. Please find my notes below,
>>>> tagged GIM2>>.
>>>>
>>>
>>>
>>>> And I apologize for coming back to my question about the figures that
>>>> display examples of STAMP test packets for Session-Sender and
>>>> Session-Reflector. As defined in RFC 8972, the Extra Padding TLV is used to
>>>> make STAMP packets symmetrical. If that is also the case for the Reflected
>>>> IPv6 Extension Header Data STAMP TLV and the Fixed IPv6 Header Data
>>>> TLV, it seems that the Extra Padding TLV must be reflected in figures. WDYT?
>>>>
>>>
>>> <RG2> Both Session-Sender and Session-Reflector test packets carry the
>>> same number of Reflected IPv6 Extension Header Data STAMP and the Fixed
>>> IPv6 Header Data TLVs, making them symmetric in size, no?
>>>
>> GIM3>> Thank you for confirming that to me. My question was about the use
>> of the Extra Padding TLV in the STAMP test packet constructed by the
>> Session-Sender. It seems that attribution of Figure 1 to both
>> Session-Sender and Session-Reflector hides from a reader that the STAMP
>> test packet transmitted by the Session-Sender MUST have Extra Padding TLV
>> to make up for the difference in  length between base and reflected packets.
>> GIM3>> Also, should the document clarify whether the Session-Reflector
>> must use information other than the Type field value, in IPv6 Extension
>> Header Data or Fixed Header Data TLVs for sanity verification? If nothing
>> of the kind, should the document state that all Value fields MUST be zeroed
>> on transmission by the Session-Sender and ignored by the Session-Reflector
>> on receipt?
>>
>>>
>>>
>>>>
>>>> Regards,
>>>> Greg
>>>>
>>>> On Mon, Jun 22, 2026 at 8:04 PM Will Hawkins <[e-mail]> wrote:
>>>>
>>>>> On Mon, Jun 22, 2026 at 9:19 PM Greg Mirsky <[e-mail]>
>>>>> wrote:
>>>>> >
>>>>> > Hi Rakesh,
>>>>> > I misinterpreted the use of the Reflected IPv6 Extension Header Data
>>>>> STAMP TLV, assuming it could carry only the SRH and not any other IPv6
>>>>> Extension Header. Please disregard that question below.
>>>>> >
>>>>> > Regards,
>>>>> > Greg
>>>>> >
>>>>> > On Mon, Jun 22, 2026 at 5:34 PM Greg Mirsky <[e-mail]>
>>>>> wrote:
>>>>> >>
>>>>> >> Hi Rakesh,
>>>>> >> Thank you for your thoughtful consideration of my notes. Please
>>>>> find my follow-up notes below, tagged GIM>>.
>>>>> >>
>>>>> >> Regards,
>>>>> >> Greg
>>>>> >>
>>>>> >> On Wed, Jun 17, 2026 at 11:11 AM Rakesh Gandhi <
>>>>> [e-mail]> wrote:
>>>>> >>>
>>>>> >>> Hi Greg,
>>>>> >>>
>>>>> >>> Thank you for the detailed review of the document.
>>>>> >>>
>>>>> >>> We have addressed your comments in the working copy (rev-09) of
>>>>> the document, as replied below <RG>...
>>>>> >>>
>>>>> >>> On Wed, Jun 10, 2026 at 8:53 PM Greg Mirsky <[e-mail]>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> Dear All,
>>>>> >>>> I read the latest version of draft-ietf-ippm-stamp-ext-hdr. The
>>>>> draft specifies the STAMP extension useful for IPv6 networks. I have
>>>>> several questions, please consider them as WG LC comments:
>>>>> >>>>
>>>>> >>>> A general observation. I feel that the document would be helpful
>>>>> to an implementer if it used the normative language rather than "can",
>>>>> "does", and "does not".
>>>>> >>>
>>>>> >>>
>>>>> >>> <RG> Updated where applicable.
>>>>> >>
>>>>> >> GIM>> Thank you
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>> I got confused by the labeling of the IPv6 extension headers and
>>>>> Reflected IPv6 Extension Header-x Data STAMP TLVs in Figure 2. Could you
>>>>> clarify for me the format of an IPv6 STAMP packet constructed by a
>>>>> Session-Sender and the format of the reflected STAMP test packet?
>>>>> >>>
>>>>> >>> <RG> It should be the same format. Updated the figure as follows
>>>>> to remove outer/inner headers for simplicity.
>>>>> >>>
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     | IPv6 Header
>>>>>  |
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     | IPv6 Extension Header-1 RFC 8200
>>>>>   |
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     ~ ...
>>>>>  ~
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     | IPv6 Extension Header-N RFC 8200
>>>>>   |
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     | UDP Header
>>>>>   |
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     | STAMP Packet RFC 8972
>>>>>  |
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     | Reflected IPv6 Extension Header-1 Data STAMP TLV (TBA1)
>>>>>  |
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     ~ ...
>>>>>  ~
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>     | Reflected IPv6 Extension Header-M Data STAMP TLV (TBA1)
>>>>>  |
>>>>> >>>
>>>>>  +---------------------------------------------------------------+
>>>>> >>>
>>>>> >>>       Note: Value of M <= N
>>>>> >>>
>>>>> >>>         Figure 2: Example Session-Sender and Session-Reflector Test
>>>>> >>>         Packet with Reflected IPv6 Extension Header Data STAMP TLVs
>>>>> >>
>>>>> >> GIM>> Thank you for the figure, but I still wonder if the scenario
>>>>> of multiple SRHs is realistic. AFAIK, operators use a single SRH in the
>>>>> packet. That operational decision was the motivation to work on u-SIDs. Can
>>>>> you help me with a scenario in which a Session-Reflector receives a packet
>>>>> with a single IPv6 header and multiple SRHs.
>>>>>
>>>>
>>>
>>>
>>>> >> GIM>> And an additional question. What are actions of the
>>>>> Session-Reflector that received a STAMP packet with a IPv6 Extension Header
>>>>> Control Sub-TLV, but has no access to the extension headers (similar to
>>>>> Sender's TTL case described in Section 4.2 of RFC 5357)?
>>>>>
>>>>> Hello Greg!!
>>>>>
>>>>> I always love your analysis. I don't want to speak for Rakesh, but I
>>>>> thought perhaps I could help him by answering this question (and, of
>>>>> course, it's possible that I am not giving the right answer -- we'll
>>>>> let him verify!). All that said, I think that
>>>>>
>>>>> "If for any reason, the Session-Reflector cannot add a new matching
>>>>> IPv6 extension header in the Session-Reflector test packet, for
>>>>> example, if the Session-Reflector does not support the IPv6 extension
>>>>> header, the Session-Reflector MUST return the STAMP TLV with the C
>>>>> flag (Conformance) set to 1 in the Sub-TLV Flags of the Sub-TLV using
>>>>> the procedure defined in [I-D.ietf-ippm-asymmetrical-pkts]."
>>>>>
>>>>> would govern the situation you describe. That is taken from -9
>>>>> (
>>>>> https://www.ietf.org/archive/id/draft-ietf-ippm-stamp-ext-hdr-09.html#section-5.3-10
>>>>> ).
>>>>>
>>>>> Let me know if that text is responsive to your question.
>>>>>
>>>>> It seems like the situation you describe (where the Session-Reflector
>>>>> is running at a privilege level that will not allow it to access
>>>>> certain information about the test packet) has come up repeatedly in
>>>>> the design and specification of TLVs. Would it make sense to add it as
>>>>> one of the "for example"s in the text? Maybe something like:
>>>>>
>>>>> "If the Session-Reflector cannot add a new matching IPv6 extension
>>>>> header in the Session-Reflector test packet for any reason (e.g., if
>>>>> the Session-Reflector does not support the IPv6 extension header, or
>>>>> the Session-Reflector is running at a privilege level where headers
>>>>> are inaccessible), the Session-Reflector MUST return the STAMP TLV
>>>>> with the C flag (Conformance) set to 1 in the Sub-TLV Flags of the
>>>>> Sub-TLV using the procedure defined in
>>>>> [I-D.ietf-ippm-asymmetrical-pkts]."
>>>>
>>>>
>>>
>>> <RG2> Revised the text as follows.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *  If the Session-Reflector cannot add a new matching IPv6 extension
>>>  header in the Session-Reflector test packet, the Session-Reflector   MUST
>>> return the STAMP TLV with the C flag (Conformance) set to 1 in   the
>>> Sub-TLV Flags of the Sub-TLV using the procedure defined in
>>>  [I-D.ietf-ippm-asymmetrical-pkts].  This can occur, for example, when
>>>  the Session-Reflector does not support the IPv6 extension header, or
>>>  when the Session-Reflector cannot access the received IPv6 extension
>>>  headers, etc.*
>>>
>>> GIM3>> Could you please clarify to which STAMP TLV and Sub-TLV this
>> applies?
>>
>>>
>>>
>>>> GIM2>> As I understand it (please correct me if I misunderstand it),
>>>> the STAMP test packet transmitted by the Session-Sender includes M
>>>> Reflected Extension Header Data TLVs. If that is the case, I assume that
>>>> the C flag must be set in all Reflected Extension Header Data TLVs in the
>>>> reflected STAMP test packet. Is that correct?
>>>>
>>>
>>>
>>> <RG2> Revised the text as follows.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *   When the Session-Reflector does not use the received "Reflected
>>> IPv6   Extension Header Data" TLV for reflecting the IPv6 extension
>>> header,   the Session-Reflector MUST return the STAMP TLV with the U flag
>>>  (Unrecognized TLV) set to 1 in the STAMP TLV Flags using the   procedure
>>> defined in [RFC8972].  This can occur, for example, if   there is a
>>> mismatch in the length between the received IPv6 extension   headers and
>>> the "Reflected IPv6 Extension Header Data" TLVs, or when   the
>>> Session-Reflector cannot access the received IPv6 extension   headers, etc.*
>>>
>> GIM3>> I got confused when reading the previous text and the one above.
>> It seems to me that the case when the Session-Reflector doesn't have access
>> to IPv6 extension headers, the Session-Reflector MUST set both C and U
>> flags in the TLV flags field of the IPv6 Extension Header Data TLV in the
>> reflected STAMP test packet. Am I missing something here?
>>
>>>
>>>
>>>
>>>> GIM2>> I looked once more at the text in Section 3.3:
>>>>    If not, the Session-Reflector MUST return both STAMP TLVs
>>>>    with the C flag (Conformance) set to 1 in the STAMP TLV Flags using
>>>>    the procedure defined in [I-D.ietf-ippm-asymmetrical-pkts].
>>>> Based on my understanding of Figure 4, Reflected Fixed Header Data
>>>> STAMP TLV already precedes the list of Reflected IPv6 Extension Header Data
>>>> STAMP TLVs in the STAMP test packet transmitted by the Session-Sender. If
>>>> that is the case, which scenario leads to setting C flag to 1? Also, which
>>>> TLVs are included in "both STAMP TLVs"?
>>>>
>>>
>>>
>>> <RG2> Revised the test as follows:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *  The "Reflected Fixed Header Data" TLVs MUST be added before adding
>>>  the "Reflected IPv6 Extension Header Data" TLVs to maintain the same
>>>  order as the IP headers and IPv6 extension headers in the Session-
>>>  Sender test packets.  If the "Reflected Fixed Header Data" TLVs and   the
>>> "Reflected IPv6 Extension Header Data" TLVs are not received in   this
>>> order, the Session-Reflector MUST return these TLVs with the C   flag
>>> (Conformance) set to 1 in the STAMP TLV Flags using the   procedure defined
>>> in [I-D.ietf-ippm-asymmetrical-pkts].*
>>>
>> GIM3>> Thank you.
>>
>>>
>>>
>>>
>>>
>>>
>>>> GIM2>> I returned to the last paragraph of Section 5.3:
>>>>    STAMP test packets MUST NOT carry more than one "IPv6 Extension
>>>>    Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
>>>>    a Session-Sender test packet contains more than one "IPv6 Extension
>>>>    Header Control" Sub-TLV, the Session-Reflector MUST return the STAMP
>>>>    TLV with the U flag (Unrecognized TLV) set to 1 in the STAMP TLV
>>>>    Flags using the procedure defined in [RFC8972].
>>>> I couldn't figure out in which TLV in the reflected STAMP test packt
>>>> the U flag must be set to 1. Could you please clarify it for me.
>>>>
>>>
>>>
>>> <RG2> Revised the test as follows:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> *   STAMP test packets MUST NOT carry more than one "IPv6 Extension
>>>  Header Control" Sub-TLV in a "Reflected Test Packet Control" TLV.  If
>>>  the "Reflected Test Packet Control" TLV in the Session-Sender test
>>>  packet contains more than one "IPv6 Extension Header Control" Sub-   TLV,
>>> the Session-Reflector MUST return the "Reflected Test Packet   Control" TLV
>>> with the U flag (Unrecognized TLV) set to 1 in the Sub-   TLV Flags of all
>>> "IPv6 Extension Header Control" Sub-TLVs, using the   procedure defined in
>>> [RFC8972].*
>>>
>> GIM3>> Could it be that the C flag is more suitable in this case? As I
>> understand it, the Session-Reflector recognizes the IPv6 Extension Header
>> Control sub-TLV, but finds that the Reflected Test Packet Control TLV
>> includes more than one IPv6 Extension Header Control sub-TLV. In other
>> word, construction of the Reflected Test Packet Control TLV is
>> non-conformant to this specification. WDYT?
>>
>>>
>>>
>>> Thanks,
>>> Rakesh (for authors)
>>>
>>>
>>>
>>>
>>>
>>>>
>>>>> As I said, I always enjoy reading your analysis and I hope my response
>>>>> is helpful!
>>>>>
>>>>> Will
>>>>>
>>>>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>> Should the first four octets of the Value field of the "Reflected
>>>>> IPv6 Extension Header Data" STAMP TLV be presented as a separate field for
>>>>> ease of reference and specification of the matching mechanism?
>>>>> >>>
>>>>> >>>
>>>>> >>> <RG> Updated the Figure to show the field separately.
>>>>> >>>
>>>>> >>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>> >>>
>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> >>>     |STAMP TLV Flags|  Type=TBA1    |         Length
>>>>>   |
>>>>> >>>
>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> >>>     |                  Requested IPv6 Extension Header Data
>>>>>  |
>>>>> >>>
>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> >>>     |                  Reflected IPv6 Extension Header Data
>>>>>  |
>>>>> >>>     ~
>>>>>  ~
>>>>> >>>     |
>>>>>  |
>>>>> >>>
>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> >>>
>>>>> >>>              Figure 6: Reflected IPv6 Extension Header Data TLV
>>>>> >>
>>>>> >> GIM>> Thank you
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>> It seems that the following processing option can benefit from
>>>>> the use of the normative language:
>>>>> >>>>
>>>>> >>>>    If necessary, Reflected Data
>>>>> >>>>    STAMP TLVs can be removed to avoid violating the IP MTU limit.
>>>>> >>>>
>>>>> >>>> And I find the suggestion somewhat ambiguous. Should all
>>>>> Reflected IPv6 Extension Header Data STAMP TLVs be removed from the
>>>>> reflected STAMP packet, or only as many as necessary to conform to the IP
>>>>> MTU of the Reflector's egress interface?
>>>>> >>>
>>>>> >>>
>>>>> >>> <RG> Updated to:
>>>>> >>>
>>>>> >>>    The Session-Sender and Session-Reflector MUST ensure that the
>>>>> >>>    resulting test packets do not exceed the IPv6 MTU after adding
>>>>> >>>    "Reflected IPv6 Extension Header Data" STAMP TLVs.  If
>>>>> necessary, one
>>>>> >>>    or more "Reflected IPv6 Extension Header Data" STAMP TLVs MUST
>>>>> be
>>>>> >>>    removed to avoid violating the IPv6 MTU limit.
>>>>> >>
>>>>> >> GIM>> Excellent, thanks!
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>> MUST NOT in the following text seems too restrictive:
>>>>> >>>>
>>>>> >>>>    IOAM Direct Exporting (DEX) [RFC9326] is applicable with STAMP
>>>>> test
>>>>> >>>>    packets for on-path telemetry use cases
>>>>> >>>>    [I-D.ietf-ippm-on-path-active-measurements].  In this case, the
>>>>> >>>>    Session-Reflector does not reflect IOAM data fields since no
>>>>> IOAM
>>>>> >>>>    data is recorded in the STAMP test packets.  Hence, the
>>>>> Session-
>>>>> >>>>    Sender MUST NOT include a corresponding "Reflected IPv6
>>>>> Extension
>>>>> >>>>    Header Data" STAMP TLV in the Session-Sender test packets for
>>>>> the
>>>>> >>>>    IOAM DEX option-type.
>>>>> >>>>
>>>>> >>>> I think there could be other valid motivations to use the
>>>>> "Reflected IPv6 Extension Header Data" STAMP TLV. Perhaps softening to MAY
>>>>> NOT could be applied in this case.
>>>>> >>>
>>>>> >>>
>>>>> >>> <RG> Updated to MAY not.
>>>>> >>
>>>>> >> GIM>> Thank you
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>> Can Reflected IPv6 Extension Header Data STAMP TLVs be used in
>>>>> combination with Reflected Fixed Header Data STAMP TLV? What are the rules
>>>>> that govern such a scenario?
>>>>> >>>
>>>>> >>>
>>>>> >>> <RG> Added following text:
>>>>> >>>
>>>>> >>>    STAMP test packets can be used to reflect both IPv6 extension
>>>>> headers
>>>>> >>>    and IP headers by carrying the corresponding "Reflected IPv6
>>>>> >>>    Extension Header Data" and "Reflected Fixed Header Data" STAMP
>>>>> TLVs
>>>>> >>>    as shown in Figure 4.
>>>>> >>>
>>>>> >>>    The "Reflected Fixed Header Data" STAMP TLV MUST be added before
>>>>> >>>    adding the "Reflected IPv6 Extension Header Data" STAMP TLVs to
>>>>> >>>    maintain the same order as the IP headers and extension headers
>>>>> in
>>>>> >>>    the STAMP test packets.  If not, the Session-Reflector MUST
>>>>> return
>>>>> >>>    both STAMP TLVs with the C flag (Conformance) set to 1 in the
>>>>> STAMP
>>>>> >>>    TLV Flags using the procedure defined in
>>>>> >>>    [I-D.ietf-ippm-asymmetrical-pkts].
>>>>> >>
>>>>> >> GIM>> Thank you
>>>>> >>>
>>>>> >>>
>>>>> >>>> Can you please clarify the format of "IPv6 Extension Header
>>>>> Control" sub-TLV?
>>>>> >>>
>>>>> >>>
>>>>> >>> <RG> Added following Figure:
>>>>> >>>
>>>>> >>>    This document defines the "IPv6 Extension Header Control"
>>>>> Sub-TLV
>>>>> >>>    (Type TBA3) for the "Reflected Test Packet Control" STAMP TLV
>>>>> (Type
>>>>> >>>    12) introduced in [I-D.ietf-ippm-asymmetrical-pkts].  The
>>>>> format of
>>>>> >>>    "IPv6 Extension Header Control" Sub-TLV is shown in Figure 8.
>>>>> >>>
>>>>> >>>     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>>>> >>>
>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> >>>     | Sub-TLV Flags |  Type = TBA3  |         Sub-TLV Length = 0
>>>>>   |
>>>>> >>>
>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>>>> >>>
>>>>> >>>               Figure 8: IPv6 Extension Header Control Sub-TLV
>>>>> >>>
>>>>> >>>    The Sub-TLV fields are defined as follows:
>>>>> >>>
>>>>> >>>    Type: Sub-TLV Type (value TBA3).
>>>>> >>>
>>>>> >>>    Sub-TLV Flags: The Sub-TLV Flags follow the procedure for STAMP
>>>>> TLV
>>>>> >>>    Flags described in [RFC8972].
>>>>> >>>
>>>>> >>>    Sub-TLV Length: A two-octet field equal to the length of the
>>>>> Data in
>>>>> >>>    octets.  It is set to 0.
>>>>> >>>
>>>>> >>>    When a Session-Sender test packet is received with the "IPv6
>>>>> >>>    Extension Header Control" Sub-TLV, the Session-Reflector MUST
>>>>> add
>>>>> >>>    matching IPv6 extension headers in the Session-Reflector STAMP
>>>>> test
>>>>> >>>    packet corresponding to the received IPv6 extension headers
>>>>> (except
>>>>> >>>    the routing extension headers specific to the Session-Sender
>>>>> test
>>>>> >>>    packet).
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>> Nit. A document would benefit from consistent use of STAMP
>>>>> terminology, e.g., Session-Sender vs Sender.
>>>>> >>>
>>>>> >>>
>>>>> >>> <RG> Fixed.
>>>>> >>
>>>>> >> GIM>> Thank you
>>>>> >>>
>>>>> >>>
>>>>> >>> Thanks,
>>>>> >>> Rakesh (for authors)
>>>>> >>>
>>>>> >>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> Regards,
>>>>> >>>> Greg
>>>>> >>>>
>>>>> >>>> On Thu, Jun 4, 2026 at 6:14 AM Marcus Ihlar via Datatracker <
>>>>> [e-mail]> wrote:
>>>>> >>>>>
>>>>> >>>>> This message starts a WG Last Call for:
>>>>> >>>>> draft-ietf-ippm-stamp-ext-hdr-08
>>>>> >>>>>
>>>>> >>>>> This Working Group Last Call ends on 2026-06-25
>>>>> >>>>>
>>>>> >>>>> Abstract:
>>>>> >>>>>    The Simple Two-Way Active Measurement Protocol (STAMP) and its
>>>>> >>>>>    optional extensions can be used for Edge-to-Edge (E2E) active
>>>>> >>>>>    measurement.  In Situ Operations, Administration, and
>>>>> Maintenance
>>>>> >>>>>    (IOAM) data fields can be used for recording and collecting
>>>>> Hop-by-
>>>>> >>>>>    Hop (HBH) and E2E operational and telemetry information.  This
>>>>> >>>>>    document extends STAMP to reflect IP headers as well as IPv6
>>>>> >>>>>    extension headers for HBH and E2E active measurements, for
>>>>> example,
>>>>> >>>>>    using IOAM data fields.
>>>>> >>>>>
>>>>> >>>>> File can be retrieved from:
>>>>> >>>>>
>>>>> >>>>> Please review and indicate your support or objection to proceed
>>>>> with the
>>>>> >>>>> publication of this document by replying to this email keeping
>>>>> [e-mail]
>>>>> >>>>> in copy. Objections should be explained and suggestions to
>>>>> resolve them are
>>>>> >>>>> highly appreciated.
>>>>> >>>>>
>>>>> >>>>> Authors, and WG participants in general, are reminded of the
>>>>> Intellectual
>>>>> >>>>> Property Rights (IPR) disclosure obligations described in BCP 79
>>>>> [1].
>>>>> >>>>> Appropriate IPR disclosures required for full conformance with
>>>>> the provisions
>>>>> >>>>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of
>>>>> any.
>>>>> >>>>> Sanctions available for application to violators of IETF IPR
>>>>> Policy can be
>>>>> >>>>> found at [3].
>>>>> >>>>>
>>>>> >>>>> Thank you.
>>>>> >>>>>
>>>>> >>>>> [1] https://datatracker.ietf.org/doc/bcp78/
>>>>> >>>>> [2] https://datatracker.ietf.org/doc/bcp79/
>>>>> >>>>> [3] https://datatracker.ietf.org/doc/rfc6701/
>>>>> >>>>>
>>>>> >>>>> The IETF datatracker status page for this Internet-Draft is:
>>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-ippm-stamp-ext-hdr/
>>>>> >>>>>
>>>>> >>>>> There is also an HTMLized version available at:
>>>>> >>>>>
>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-ippm-stamp-ext-hdr-08
>>>>> >>>>>
>>>>> >>>>> A diff from the previous version is available at:
>>>>> >>>>>
>>>>> https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-stamp-ext-hdr-08
>>>>> >>>>>
>>>>> >>>>> _______________________________________________
>>>>> >>>>> ippm mailing list -- [e-mail]
>>>>> >>>>> To unsubscribe send an email to [e-mail]
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> ippm mailing list -- [e-mail]
>>>>> >>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>