Last Call Review of draft-ietf-ace-usecases-09
review-ietf-ace-usecases-09-secdir-lc-montville-2015-10-15-00
Request | Review of | draft-ietf-ace-usecases |
---|---|---|
Requested revision | No specific revision (document currently at 10) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2015-10-20 | |
Requested | 2015-10-08 | |
Authors | Ludwig Seitz , Stefanie Gerdes , Göran Selander , Mehdi Mani , Sandeep Kumar | |
I-D last updated | 2015-10-15 | |
Completed reviews |
Genart Last Call review of -09
by Joel M. Halpern
(diff)
Secdir Last Call review of -09 by Adam W. Montville (diff) Opsdir Last Call review of -09 by Mahesh Jethanandani (diff) |
|
Assignment | Reviewer | Adam W. Montville |
State | Completed | |
Request | Last Call review on draft-ietf-ace-usecases by Security Area Directorate Assigned | |
Reviewed revision | 09 (document currently at 10) | |
Result | Has issues | |
Completed | 2015-10-15 |
review-ietf-ace-usecases-09-secdir-lc-montville-2015-10-15-00
Hi. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Draft is Ready with nits and one possible issue. This draft seems to provide a good set of use cases collectively representing the lifecycle of constrained devices up to and including decommissioning. While the draft does mention “configuration”, the context is more about ensuring flexibility of expressing access permissions. I’m not sure if this draft requires something like the following, but it would be beneficial for downstream operational processes to explicitly support endpoint posture assessment. This could be done by providing an explicit posture-related interface. Such a requirement could be alluded to in the Security Considerations section. On the other hand, this may be something addressed by CoAP and other drafts. Nits (against -09): Second paragraph of 3.1: You might consider adding a sentence indicating whether developers are expected to do anything after becoming familiar with RFC7258. Third paragraph of 3.1: Formatting issue after first sentence - second sentence is on a new line, or the second sentence was intended to start a new paragraph. Third paragraph of 3.1: s/attacks/attack/ Fifth paragraph of 3.1: Formatting issue after second sentence - third sentence is on a new line, or the third sentence was intended to start a new paragraph. Kind regards, Adam