I am an assigned INT directorate reviewer for draft-ietf-drip-arch-24. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ . Overall I found the document very well-written. I have the following comments/questions for the authors/WG that I feel SHOULD be addressed: 1. I found the discussion of time to be a bit lacking and would like to see it clarified. Specifically, section 3.2 talks about attestation including a timestamp, though it is unclear to me what requirements this places on the UA for having a trusted source of time, such as a local clock. Section 8.2 says "UAs and Broadcast Remote ID communications are so constrained that current post quantum computing cryptography is not applicable" so if UAs are that constrained, can you really rely on them having a trusted source of time? For example, I know in many TEEs, a trusted source of relative time (e.g., monotonic counter) is not even available, and I could imagine that there are many uses (e.g., defense) whereby a UA might want/need a TEE for attestation. The level of trust in time gets to the issue about how robust the architecture is against replay attacks. 2. Somewhat related to the above, Section 5 talks about DRIP Wrapper Authentication messages that sign over dynamically changing data "such as UA location data". I observe that time is not mentioned in this example, and further observe that I don't see how UA location data alone can be robust against replay attacks, e.g., an attacker might attempt to replay the fact that a different UA was where real-time evidence just detects a UA of some sort currently present. I would like to see the replay attack prevention elaborated on here, especially since section 8.3 says "this whole architecture is put forth to make ... replay attacks very hard". 3. In my reading [I-D.ietf-drip-auth] and [I-D.ietf-drip-registries] are used normatively in sections 5 and 8 since they are used by way of limitation to those references, rather than by way of example where alternatives may be applied. But they are listed as informative, not normative references. I think both should be moved to be normative unless the WG changes language like "as described in" to "such as described in" or similar, to make them exemplary. In addition, a number of nits (typos, misspellings, etc.) are called out in the marked up PDF at https://1drv.ms/b/s!Aqj-Bj9PNivcn5QXjfM63l-gFYIJhg?e=9hyYBP Dave