I think this document is almost ready except for some specifications regarding the DNS.

In section 3.1.1., 
"An Observer SHOULD query DNS for the UA's HI. If not available it may have been revoked. Note that accurate revocation status is a DIME inquiry; DNS non-response is a hint that a DET is expired or revoked. It MAY be retrieved from a local cache, if present. The local cache is typically populated by DNS lookups and/or by received Broadcast Endorsements (Section 3.1.2)."

By comprehending RFC9374 and RFC9434, I think it would bring about new operational considerations to leverage current DNS to meet the need of naming in the context of UAS, especially due to DET the new DNS RR proposed by draft-ietf-drip-registries-14. It is therein inevitable to handle some anomalies of DNS queries triggered by DRIP-based Authentication. The current text here is not adequate for the consistency among different implementations. If the authors consider this issue could be left to private implementation, it should be explicitly stated here. Otherwise，I suggest authors consider adding extra content regarding DNS rcode extension. 

On the whole, I think authors should refer to which kind of DNS specification/RFCs normatively used by DRIP since the DNS is key to the DRIP architecture, given that DNS is evolving to DoH and DSO and so on.