(This is one of the point-to-point follow-up mails on the RD -25 reviews; for the preface, please see the preceding mail on "The various positions on draft-ietf-core-resource-directory-25" at <https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>). > 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? response: See GENERIC-SUBJECT. > 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. response: With growing numbers of participants, the chances some collision happening stays at a constant level even with the 2n length due to the birthday paradox, which is why the collision on the initial attempt is highlighted. A bit of clarifying information was added in https://github.com/core-wg/resource-directory/pull/248, without attempting to verbosely lay out the whole background. > Nits: [...] resonse: All addressed in https://github.com/core-wg/resource-directory/pull/246 > IDnits reports: > > == There are 3 instances of lines with non-ascii characters in the > document. response: Two of them are in an author's name, the third is in an example and relevant there (as it talks about variations of a representation containing non-ascii charactes). > == 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 response: That instance is a suggestion to IANA, it will be replaced with the actually assigned address. > == There are 3 instances of lines with non-RFC3849-compliant IPv6 > addresses in the document. If these are example addresses, they > should be changed. response: see GENERIC-FFxxDB
Attachment:
signature.asc
Description: PGP signature
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
