I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-core-resource-directory-25 Reviewer: Russ Housley Review Date: 2020-07-27 IETF LC End Date: 2020-03-31 IESG Telechat date: 2020-08-13 I reviewed -24 on 2020-03-14. The Major Concerns raised in that review have been resolved. Some Minor Concerns were introduced as part of the changes. Summary: Almost Ready Major Concerns: None. Minor Concerns: Section 7.1 says: "... can be transported in the subject." I think you should say "subject field" or "subject name". Do you mean to exclude the subject alternative name? Section 7.1.1 says: Registrants that are prepared to pick a different identifier when their initial attempt at registration is unauthorized should pick an identifier at least twice as long as the expected number of registrants; registrants without such a recovery options should pick significantly longer endpoint names (e.g. using UUID URNs [RFC4122]). I think that the reason for the recommendation on length is to reduce the likelihood of name collision. However, it is not clear to me why this is linked in any way to authorization failures on the first attempt to register. Nits: Section 7.1: s/It is immaterial there whether/It is immaterial whether/ Section 8.1: s/address based access/address-based access/ IDnits reports: == There are 3 instances of lines with non-ascii characters in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 3 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed.