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-dice-profile-14.txt Reviewer: Brian Carpenter Review Date: 2015-09-02 IETF LC End Date: 2015-09-04 IESG Telechat date: Summary: Ready with issues -------- Comment: -------- This is complicated and I'm not an expert. I went through the whole document but have to take most of the details on trust. Major Issues: ------------- One thing puzzles me. Unless I have missed it, the profile is neutral on the choice described in Section 6 (Credential Types): pre-shared secrets, raw public keys, or certificates. How does this work to help interoperability in multivendor environments? Wouldn't it be better to RECOMMEND one? ((The answer to this interests me in the Anima context too.)) Would it be possible to add a summary table of the MUST, SHOULD, MAY and MUST NOT items in the profile? At the moment there is a lot of prose and nothing that can be used as an implementer's check list. Minor Issues: ------------- " Figure 7 shows an example interaction... The IPv6 multicast address used for site-local discovery is FF02::FD." Where does ff02::fd come from? Is it just used as an example? That isn't clear in the text. (IANA lists it as "variable scope allocation".) ((Incidentally, this is a side track, but note that a command such as GET coap://[FF02::FD]/.well-known/core is problematic in a device with more than one interface, unless you support RFC6874.)) "6.4.2. Certificates used by Clients For client certificates the identifier used in the SubjectAltName or in the leftmost CN component of subject name MUST be an EUI-64, as mandated in Section 9.1.3.3 of [RFC7252]." Actually it is not mandated there, it is only suggested: " The subject in the certificate would be built out of a long-term unique identifier for the device such as the EUI-64 [EUI64]." You can certainly choose to mandate it here, but s/mandated/described/ in the text. However, I am confused by this MUST in 6.4.2, and other normative keywords in Section 6. Are we now in the specification of the DICE profile, or are we still in the descriptive text? I would expect a very clear break in the text when we move from description to specification. Looking at the table of contents, I can't figure out where that point is. OK, now I found a sentence at the beginning: "If you are familiar with (D)TLS, then skip ahead to Section 6." But please reflect this in the arrangement of the sections. I would suggest nesting sections 3,4, and 5 within a single "Overview" section, and put something at start of section 6 to make it clear that is where the profile starts. Or nest sections 6 etc. inside a single "Profile" section. Nits: ----- The RFC2119 boilerplate is messed up. == Outdated reference: draft-ietf-tls-sslv3-diediedie has been published as RFC 7568 The downref to RFC7251 was not mentioned in the last call and that RFC isn't in the downref registry. ((Yes, I've been in the IESG and I know how annoying this can be, but it's a process glitch.)) _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
