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
tsv-art@ietf.org if you reply to or forward this review.

I questions why this document is published as informational status. It appears to at least define a format with a well known URI. I would think a standards track would be a more approrpiate status. 

Section 3:

"if the reverse DNS record for 2001:db8::dead exists"

What should one do if there are multiple PTR records for a given address? This I would expect to be fairly likely in some multi-tennant systems.

Section 4:

• for a [RFC4443] ICMPv6 echo request: in the optional data (see section 4.1 of [RFC4443]);
• for a [RFC792] ICMPv4 echo request: in the optional data;


First of all there are no "optional data" there is a "data" field. I think the reference to which field should be clearer, i.e. "in the data field". 

"for a [RFC768] UDP datagram: in the data part. Note that if the probe is destined to a listened-to/well-known UDP port, the inclusion of the probe description URI may produce undefined results;"

I think this is really understating the issue. If the probe is done using a protocol that has any fields in the UDP payload it is unlikely that the placement of the URI first will work at all, unless the measurement protocol is updated. I would think an placement in the end would be more likely to function, unless the UDP payload has no other than random data. However, in some case it will simply not work without updating the probe protocol.

For the future including the attribution URI in an UDP options would be a potential solution that can be looked into. https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/

"for a [RFC9293] TCP packet with the SYN flag: data is allowed in TCP packets with the SYN flag per section 3.4 of [RFC9293] (2nd paragraph). However, it may change the way the packet is processed, i.e., SYN packets containing data might be discarded;"

So from an TCP using protocol, there are little difference in sending the data in syn, or sending it in the first packets after established state. The data will reach the application layer, this does not bypass the issue of the data ending up in the upper layer application. So why are there specific discussion of the data in TCP syn. 

Also, I think the reference to Section 3.4 of RFC9293 is pointing to the wrong section. Because that paragraph discusses sequence number space wrapping which appear not that relevant here. 

So in general I think the attempt to apply in-band URI to UDP and TCP are likely problematic and may have to be dialed back into being recommended to be included in protocol fields that otherwise would include random data. Have it been considered to define a magical word that would prefix the URI so that it might be easier to look for potential matches in the payloads? It makes sense to volunteerily include this URI in probe packets for measurements that can do that without making there packets unusable for their main purpose. 

Section 8.

I noted that you expect permanent status. 

Reading RFC 8615 I noticed this paragraph:

Values defined by Standards Track RFCs and other open standards (in
   the sense of [RFC2026], Section 7.1.1) have a status of "permanent".
   Other values can also be registered as permanent, if the experts find
   that they are in use, in consultation with the community.  Other
   values should be registered as "provisional".

This document is targeting informational status. Which I personally questions. However, I do see the point of having this format have a well-known URI that are permanent, but according to instruction this ends up in a grey zone. It might be that the expert want to waive this. I do also note that RFC 9116 did get permanent. 


Another aspect that I find worrying.

This draft appear to never to have been even mentioned in the IPPM group. Being a WG that define active measurements it should have been done, and consideration of how to include the attribution in the IPPM protocols should have taken place. Although IPPM targets measurements between collaborating nodes, it appears some of the concerns from on path nodes about measurement could still be relevant. So I would recommend that this work is at least brought up in IPPM to discuss if there are need to extend.