[art] Artart last call review of draft-ietf-ippm-encrypted-pdmv2-08

Marc Blanchet via Datatracker <noreply@ietf.org> Fri, 04 October 2024 17:09 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Marc Blanchet via Datatracker <noreply@ietf.org>
To: art@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <172806177552.112908.15111308185284431976@dt-datatracker-cb674fff7-jr9km>
Date: Fri, 04 Oct 2024 10:09:35 -0700
Message-ID-Hash: Q4XIYWI5XA6SPCT4IYGJV6YD743AYT5H
CC: draft-ietf-ippm-encrypted-pdmv2.all@ietf.org, ippm@ietf.org, last-call@ietf.org
Reply-To: Marc Blanchet <marc.blanchet@viagenie.ca>
Subject: [art] Artart last call review of draft-ietf-ippm-encrypted-pdmv2-08
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/nZ5fjpnpEfGFNUJWI117WlzR5CQ>

Reviewer: Marc Blanchet
Review result: Ready

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.

[art] Artart last call review of draft-ietf-ippm-… Marc Blanchet via Datatracker
[art] Re: [ippm] Artart last call review of draft… nalini.elkins@insidethestack.com