Reviewer: Michael Richardson Review result: Ready with Nits Document: draft-ietf-drip-rid-07 Summary: Almost Ready I have done an IoT-Directorate review of draft-ietf-drip-rid-07. I think that I have previously read the document prior to WG adoption. While the core content of the document is all present, and it would appear that code could be written from it, the text in the document is pretty rough shape. The document needs an editorial pass to make the language a bit less abrupt. There is a lot of content in the appendixes (more than 70% or so), and I didn't see a lot of forward references to them. Do we need them all? Nits: I stumbled on the very first sentence: [drip-requirements] describes a UAS ID as a "unique (ID-4), non-spoofable (ID-5), and identify a registry where the ID is listed (ID-2)"; all within ^^^^^^^^^^^^^^^ <- just does not flow with the rest of the sentence. a 20 character Identifier (ID-1). In general, I'd rather that the first word wasn't a reference. Maybe just move that sentence to the end of the Introduction, or at least maybe two or three paragraphs down. s/This is in contrast to general IDs (e.g. a UUID or device serial number) as the subject in an X.509 certificate./ This is in contrast to using general IDs (e.g. a UUID or device serial number) as the subject in an [RFC5280] X.509 certificate./ a) please expand "CA" in the intro on first use. b) please consider if this just belongs in Security Considerations. "In a multi-CA PKI, a subject can occur in multiple CAs, possibly fraudulently. CAs within the PKI would need to implement an approach to enforce assurance of uniqueness." Maybe write: "The use of multiple Certification Authorities (CA), such as used for the public WebPKI comes with the risk of duplicates among the different CAs. These can occur due to fraud or error, and to date the WebPKI has not found a way to prevent this, only to detect the occurance afterwards. [reference to certtrans] } 1.1. Nontransferablity of HHITs } HIs and its HHITs SHOULD NOT be transferable between UA or even between } replacement electronics for a UA. The private key for the HI SHOULD be held } in a cryptographically secure component. I agree that this is true. But, I think that some additional explanation is waranteed. I know that we had the discussion about rebuilding entire air frames, where every single component is changed, and yet, it's the same airframe. } TYPE-3 } A UTM system assigned UUID [RFC4122], which can but need not be dynamic. maybe write: A UTM system assigned UUID [RFC4122]. These can be dynamic, but do not need to be. } 3.1. Hierarchical HITs encoded as CTA-2063-A Serial Numbers please give me an example of a CTA-2063-A serial number, and please give me an example of a HHIT encoded as one.... AHA. Appendix B.4, so a forward reference, please?... ah, but no actual example in B.4. 3.3: } The justification then was attacks against these fields are DoS attacks against protocols using them. Please reword, as this doesn't look like a sentence to me. } The individual HHITs are potentially too numerous (e.g. 60 - 600M) and } dynamic to actually store in a signed, DNS zone. This point has been disputed before. .com is much larger, and we don't have 600M of them on day one. I.e. by the time we really have 600M of them, then there will be a business justification for investing in the required hardware. section 9, please start by explaining what a HHIT hijacking *is*, and what the operational impact of such a thing occuring is.