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

Request Review of draft-ietf-core-resource-directory
Requested rev. no specific revision (document currently at 25)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-08-11
Requested 2020-07-23
Authors Zach Shelby, Michael Koster, Carsten Bormann, Peter Van der Stok, Christian Amsüss
Draft last updated 2020-07-27
Completed reviews Secdir Last Call review of -24 by Adam Montville (diff)
Genart Last Call review of -24 by Russ Housley (diff)
Genart Telechat review of -25 by Russ Housley
Assignment Reviewer Russ Housley
State Completed
Review review-ietf-core-resource-directory-25-genart-telechat-housley-2020-07-27
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/0AQyJjWaDRP9yK6PCsvBgTVzdhw
Reviewed rev. 25
Review result Almost Ready
Review completed: 2020-07-27

Review
review-ietf-core-resource-directory-25-genart-telechat-housley-2020-07-27

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.