Last Call Review of draft-ietf-sidr-publication-09
review-ietf-sidr-publication-09-genart-lc-yee-2017-01-06-00
Request | Review of | draft-ietf-sidr-publication |
---|---|---|
Requested revision | No specific revision (document currently at 12) | |
Type | Last Call Review | |
Team | General Area Review Team (Gen-ART) (genart) | |
Deadline | 2017-01-06 | |
Requested | 2016-12-16 | |
Authors | Samuel Weiler , Anuja Sonalker , Rob Austein | |
I-D last updated | 2017-01-06 | |
Completed reviews |
Genart Last Call review of -09
by Peter E. Yee
(diff)
Secdir Last Call review of -09 by Paul Wouters (diff) Opsdir Last Call review of -10 by Ron Bonica (diff) Secdir Telechat review of -10 by Paul Wouters (diff) Genart Telechat review of -10 by Peter E. Yee (diff) |
|
Assignment | Reviewer | Peter E. Yee |
State | Completed | |
Request | Last Call review on draft-ietf-sidr-publication by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 09 (document currently at 12) | |
Result | Ready w/nits | |
Completed | 2017-01-06 |
review-ietf-sidr-publication-09-genart-lc-yee-2017-01-06-00
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 <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. Document: draft-ietf-sidr-publication-09 Reviewer: Peter Yee Review Date: 2017-01-06 IETF LC End Date: 2017-01-06 IESG Telechat date: 2017-01-19 Summary: This specification defines a protocol for handling objects in an RPKI repository. The document seems fairly straightforward and simple to understand. Major issues: Minor issues: Nits/editorial comments: Page 5, Section 2.2, last paragraph, last sentence: perhaps change "are permitted to" to "MAY"? Page 7, Section 2.6, 1st paragraph: change "RelaxNG" to "RELAX NG". (Hey, I had to look it up.) Page 14, Section 4, 1st paragraph after rsync enumation: "safely" is used but no subsequent mention is made of what is unsafe about the non-overlapping rsync directories. Is the reader expected to know something about rsync's safety? Nothing in the Security Considerations deals with this topic. Page 16, Section 6, 3rd paragraph, 2nd sentence: insert "private" before "keys". Insert "to" before "delete". Page 17, Section 7: it might be good to include references to: XML, RelaxNG, and maybe rsync (yeah, I know that one is a little tough).