Reviewer: Russ Housley Review result: Not 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-24 Reviewer: Russ Housley Review Date: 2020-03-14 IETF LC End Date: 2020-03-31 IESG Telechat date: Unknown Summary: Not Ready Major Concerns: Section 7.3 says: ... the certificate is uniquely identified by the CN field and the serial number (see [RFC5280] Section 4.1.2.2). This is _not_ correct! RFC 5280 says that the issuer name (not the CN) and serial number uniquely identify a certificate! The issuer name is made up of may naming attributes, and the CN is one that MAY be present. The list of naming attributes is given in Section 4.1.2.4 of RFC 5280. Note: Even if the conventions required by IEEE 802.1AR are followed, the sentence is not correct. The paragraph goes on to say: The RD can assign a unique endpoint name by using the certificate identifier as endpoint name. I believe that this is correct, but it is not the common name (CN) that makes it correct. I think that some guidance ia needed here. Section 7.3 says: Proof of possession of the endpoint name by the registering endpoint is checked by encrypting the certificate identifier with the private key of the registering endpoint, which the RD can decrypt with the public key stored in the certificate. This only works if the certificate contains an RSA public key. There are algorithm independent ways to achieve this outcome. With the push for elliptic curve cryptography and post-quantum cryptography it is important that this be reworded in an algorithm independent manner. Section 7.3 says: Even simpler, the authorized registering endpoint can generate a random number (or string) that identifies the endpoint. The RD can check for the improbable replication of the random value. The RD MUST check that registering endpoint uses only one random value for each authorized endpoint. Yes, but only if the random number is large enough. Please offer some guidance about the size. Minor Concerns: General: The document uses "Resource Directory", "resource directory", and "RD" interchangeably. I thin it would help the reader if just one spelling was used throughout. Section 2: Please update the first paragraph to reference RFC 8174 in addition to RFC 2119, as follows: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Also, please put this sentence in a separate paragraph: The term "byte" is used in its now customary sense as a synonym for "octet". Further, the definition in Section 2 does not align with the document Introduction, which says that an RD is used to register, maintain, lookup and remove information on resources. I think these should match. Section 9.5 says: IPv4 - "all CoRE resource directories" address MCD2 (suggestion: 224.0.1.189), from the "IPv4 Multicast Address Space Registry". As the address is used for discovery that may span beyond a single network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771). I believe you want to make RFC 5771 a reference here. I suggest: ... from the Internetwork Control Block (224.0.1.x) [RFC 5771]. In Figures 5 and 6, I am surprised to see the response end in a comma. Looking at the examples in RFC 6690 and Section 10 of this document none of them end in a comma. Please make sure that these figures are correct. Appendix A: Can the IPv6 addresses in this appendix be replaced with ines from RFC 3849 or RFC 4193? Nits: General: IDnits reports three instances of too long lines. General: These two phrases are used: - Resource Directory implementations using this specification ... - Resource Directories implementing this specification ... - An implementation of this resource directory specification ... Please pick one, or (my preference): - RD implementations of this specification ... Abstract: Some places Resource Directory is spelled out. Other places RD is used. Either spell it out just once or every time. The captions for Figure 2 and Figure 3 include "E-R", but the text about the figures uses "ER". Please choose one spelling. Section 3.5 includes " (machines -- endpoints) ". The meaning of double hypen is unclear to me. Please use words. Section 4 includes " (registrant-EPs / CTs, lookup clients, ...". I do not know the difference in meaning between the slash and the comma. Section 8.1 has a typo: "... the et of endpoints ..." -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
