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'm not an expert in IPPM nor in security, so I am read this seeking to understand the requirements for the protocol interactions. The method adds meta data to existing packets, as such it does not introduce significant increase in the transmission rate and seems unlikely to contribute new congestion control considerations. I did find places where the mechanism appears to be unclear, and a mention of QoS which seems to require some work. * What is the relationship with other PDM documents? The document makes no mention of the standards status of the existing PDM spec, although I later understand that this is a negoiciated variant and both are expected to co-exist. This ought to be clear: Is this spec an additional format or replacement? Is that spec deprecated? Should this spect obsolete/deprecate RFC 8250? Does this document update any other specification, in which case the boiler plate and the abstract ought to say so? The following specific comments relate to specific sections in this document. Abstract ---- The abstract states: “RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements.“ - I think the normal term is that the EH is “included” rather than “embedded”? - I also wonder if this is being specified for IPv4 (I think not?), if not then I think this document ought to insert “IPv6” before packet in the abstract. --- Is this defined only for unicast addresses, later the document states “Global Unicast addresses.”, in which case, ought the abstract and introduction to define this limited scope - or is this applicable to or extensible to anycast and multicast use? --- “As this data is sent in clear-text, this may create an opportunity for malicious actors” - I think this is /Because/ and I expect that /may create/creates/ is more accurate, the opportunity is created, the effect can be mitigated. /PDMv2 which has/PDMv2, which has/ --- Please expand PDM to Performance and Destinations Metrics in the abstract. --- “Additional performance metrics which may be of use are also defined.” - could perhaps be clearer as: “Additional performance metrics are also defined.”, without speculating on the usefulness? --- 1. Introduction. ---- - The Introduction section needs additional editorial work to produce readable english, and also needs the set of examples and use-cases to be clearly explained. --- I wonder if this phrase makes sense to people: “measure the Quality of Service (QoS)“ - Can someone really measure something that is configured? - I expect you can measure a path that is designed to support a certain QoS. Is there a better wording? --- “and to assist in diagnostics” - This seems like it could be useful, but the current text does not say say anything about what sort of diagnostics or what is the intended use? --- “For example, the operational capabilities of either the client or server end hosts such as processing speed -- that is, if the system in question is very fast system or an older, slower device.” - This and the following examples seem to be rather incomplete: For example, this does not explain the vulnerability or the exploit, please explain. --- 3.2 - Is this only for directly carrying transport protocols? All the examples provided as examples for PROTC seem to be upper-layer transport protocols, is it possible to use this with an encapsulation or other EH? - If so please add some examples here. - What is the format of this header? --- 5.2 “Alternatively, the network administrator might choose to create a policy that prohibits the use of PDM or unencrypted PDMv2 on their network. The implementation SHOULD provide a way for the network administrator to enforce such a policy.” - I can see this is an alternative, but what is the RFC2119 requirement intended to test/require? Is this really a useful requirement, or could this be a case where we do not need RFC 2119 language? ---- “ The server and client implementations SHOULD support PDM, unencrypted PDMv2, and encrypted PDMv2. “ - I think this is not easy to understand. Why is this a SHOULD? If it implements this specification, doesn’t it support some of these. I’m unclear. Sections 5.2.1 and 5.2.2 seem to describe use cases where a server does not understand PDM or PDMv2, and that is also confusing for me. --- “If a client chooses a certain mechanism (e.g., PDM), the server MAY respond with the same mechanism, unless the network administrator has selected a policy that only allows certain mechanisms on their network.” - This seems important, but I do not understand what needs to be implemented and what needs to be configured from this text. --- Section 6.3 “An unauthorized party MUST NOT be able to send PDM data and MUST NOT be able to authorize another entity to do so. Alternatively, if authentication is done via any of the following, this requirement MAY be considered to be met.” - I’m unsure what the RFC2119 requirement is in this case. I think this is not a compliance. --- I think the following applies only to the PDM option data, is that correct (please say): “Confidentiality: Encryption ensures that the actual content of the communication remains confidential. Even if attackers or observers intercept the data packets, they won't be able to decipher the information without the encryption key. In the case of IPv6 Performance and Destination Option (PDM), the still- visible, non-encrypted metadata is still visiblenegligible, and does not poses confidentiality.” ---