Skip to main content

Telechat Review of draft-ietf-core-resource-directory-25

Request Review of draft-ietf-core-resource-directory
Requested revision No specific revision (document currently at 28)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2020-08-11
Requested 2020-07-23
Authors Christian Amsüss , Zach Shelby , Michael Koster , Carsten Bormann , Peter Van der Stok
Draft last updated 2020-07-27
Completed reviews Secdir Last Call review of -24 by Adam W. Montville (diff)
Genart Last Call review of -24 by Russ Housley (diff)
Genart Telechat review of -25 by Russ Housley (diff)
Secdir Telechat review of -25 by Valery Smyslov (diff)
Assignment Reviewer Russ Housley
State Completed
Review review-ietf-core-resource-directory-25-genart-telechat-housley-2020-07-27
Posted at
Reviewed revision 25 (document currently at 28)
Result Almost Ready
Completed 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

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:


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.


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

 == 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.