Skip to main content

Last Call Review of draft-ietf-ippm-encrypted-pdmv2-08
review-ietf-ippm-encrypted-pdmv2-08-artart-lc-blanchet-2024-10-04-00

Request Review of draft-ietf-ippm-encrypted-pdmv2
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team ART Area Review Team (artart)
Deadline 2024-10-15
Requested 2024-10-01
Authors Nalini Elkins , michael ackermann , Ameya Deshpande , Tommaso Pecorella , Adnan Rashid
I-D last updated 2024-10-04
Completed reviews Secdir Early review of -04 by Chris M. Lonvick (diff)
Secdir Last Call review of -05 by Chris M. Lonvick (diff)
Secdir Early review of -01 by Adam W. Montville (diff)
Genart Last Call review of -09 by Peter E. Yee
Artart Last Call review of -08 by Marc Blanchet (diff)
Tsvart Last Call review of -09 by Gorry Fairhurst
Intdir Telechat review of -09 by Carlos J. Bernardos
Assignment Reviewer Marc Blanchet
State Completed
Request Last Call review on draft-ietf-ippm-encrypted-pdmv2 by ART Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/art/nZ5fjpnpEfGFNUJWI117WlzR5CQ
Reviewed revision 08 (document currently at 09)
Result Ready
Completed 2024-10-04
review-ietf-ippm-encrypted-pdmv2-08-artart-lc-blanchet-2024-10-04-00
I've reviewed this document as an assigned ART reviewer. I'm not an expert in
IPPM nor in security. I haven't seen any issue from the perspective of ART or
i18n. However, I was struggling trying to understand the mapping
between/implementation of appendix A.2 and the wire format described in section
3.3. For example, I'm not sure where and how security algorithms are
negotiated. Maybe it is just me not understanding well the document. And I was
wondering, maybe incorrectly, why there is yet another key exchange and
algorithm negotiation mechanism, instead of maybe reusing one we already have.
However, all these comments are related to security and I let the security
reviewers and ADs to properly handle that perspective.