Thanks Russ. I pointed to your review in my No Objection ballot. Alissa > On Jul 27, 2020, at 2:52 PM, Russ Housley via Datatracker <noreply@xxxxxxxx> wrote: > > Reviewer: Russ Housley > Review result: Almost Ready > > 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. > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
