[Last-Call] Genart last call review of draft-ietf-core-resource-directory-24

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux