[Tsv-art] draft-ietf-ippm-encrypted-pdmv2-14 early Tsvart review

[Yoshifumi Nishida via Datatracker <[e-mail]>]

Document: draft-ietf-ippm-encrypted-pdmv2
Title: IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option
Reviewer: Yoshifumi Nishida
Review result: On the Right Track

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

when done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

Summary: This document is On the Right Track as a standard track document,
however, I think the following points need to be addressed.

1. Section 7: Option type '0x0F'
   I believe this means this document reuses the option value used for RFC8250
   as it mentions "adopted from RFC 8250".
   However, the document also requests a new option type to use different value.
   This point should be clarified.

2. Section 7. Option length '0x22'
   This indicates option length is 34 bytes, however, actual length of the
   header format looks 22 bytes.

3. Section 7.
   It looks a bit strange to me to have the same length for Unencrypted PDM
   and Encrypted PDM. Is this correct?

   "PDMv2 uses a single header format. Whether metric contents are protected
   or unprotected is determined by local policy and registration context."
   Does this mean there is no inbound mechanism for receiver to know whether
   this is Encrypted PDM or not? Is this design intentional ?

4. Section 7.
   "Epoch field is used to indicate the valid SessionTemporaryKey."

   I think we need to add an explanation for SessionTemporaryKey, such as
   how this key is derived.

5. Section 7.
   Both PSNTP and PSNLR have dependency on 5-tuple. However, I'm not sure
   how we can apply this to ICMP.
   The draft mentions "PDMv2 operates entirely at the IPv6 layer and
   applies uniformly to TCP, UDP, ICMP, QUIC" in Section 1.

6. Section 7.
   "This field is initialized at a random number and is incremented sequentially
   for each packet of the 5-tuple."
   When TCP retransmits packets, should we increase PSNTP or not?
   Please clarify this point.

7. Can this approach work with TSO/GSO? When a packet is split into multiple packets,
   multiple packets would have the same PSNTP.  Is this acceptable?

8. Appendix A
   "This appendix illustrates one possible registration mechanism that satisfies
   the requirements defined in Section 4."

   I think Section 4 doesn't define requirements. I thought you mean Section 5.1
   ('Registration Objectives'). however, 5.1's bullets are high-level enough that
   it's unclear what 'satisfies' means in the sentence.