Re: [ippm] WGLC for draft-ietf-ippm-encrypted-pdmv2-05

Dhruv,
Thanks for the thoughtful comments.  Let us go over them thoroughly and we will come back with comments.

Nalini Elkins
CEO and Founder
Inside Products, Inc.
https://www.insidethestack.com
PresidentIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Saturday, January 27, 2024 at 01:53:25 AM PST, Dhruv Dhody <dhruv.ietf@gmail.com> wrote:  

 Hi, 
I support this work, but here are a few comments that should be handled before sending the I-D to our AD. 
## Suggestions/Query
* I am assuming that the procedures specified in RFC 8250 continue to apply. That should be stated explicitly. 
* Section 3, Is it correct to say the difference between a client and server is that it is the client that initiates the session? Maybe just state that and other properties are for any endpoint node. 
* Shouldn't there be some backward compatibility text to explain cases like -- what happens when a node does not understand PDMv2 and thus expected a length of 10 as per RFC 8250 but finds a different length. Also I wonder how one decides if a client should use PDM, unencrypted PDMv2 or encrypted PDMv2. There should be specific text that says that the server MUST respond with the same mechanism. Are all mechanisms mandatory to implement? Basically we need more text...

## Minor
*  Section 1, Consider changing Man-In-The-Middle to Machine-In-The-Middle as per https://www.ietf.org/about/groups/iesg/statements/on-inclusive-language/
- Section 1, it would be good to introduce what PDMv2 is before stating "PDMv2 adds...".
- Section 3, mentions terms pkX and skX but never use it, is there a reason they are defined? 
- Section 9, you are reusing the option type 0x0F defined in RFC 8250, you don't need to ask IANA to assign one! 
- Section A.1, is there a reference to the primary-secondary architecture mentioned? 

## Nits
* Section 1, s/current PDM/PDM [RFC8250]/
* Section 4.1, expand HPKE, KEM, KDF (you do that later on in section 5.4, but it should be done here). Also PSN. 
* Don't capitalize "CAN" as it is not a BCP14 keyword. Maybe use MAY?
* Section 6.3, the formatting for field descriptions is hard to follow. 
* s/Reserved Bits/Reserved/ - add it MUST be set to zero on transmission and ignored on receipt. 
* s/RFC3552/[RFC3552]/
* Remove appendix B and C as they are empty

Thanks! Dhruv
On Tue, Jan 9, 2024 at 10:56 PM Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org> wrote:

Hello IPPM, This email starts a Working Group Last Call for "IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option”, draft-ietf-ippm-encrypted-pdmv2-05. https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/https://datatracker.ietf.org/doc/html/draft-ietf-ippm-encrypted-pdmv2-05 Please review the document and send your comments in response to this email, along with whether you think the document is ready to progress.
This last call will be three weeks long, and end on Tuesday, January 30. In parallel, we have requested another SECDIR review. Best,Tommy & Marcus_______________________________________________
ippm mailing list
ippm@ietf.org
https://www.ietf.org/mailman/listinfo/ippm