Telechat Review of draft-ietf-core-resource-directory-25
review-ietf-core-resource-directory-25-genart-telechat-housley-2020-07-27-00

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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.