Last Call Review of draft-ietf-jcardcal-jcal-09

Request Review of draft-ietf-jcardcal-jcal
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-03-12
Requested 2014-02-20
Authors Philipp Kewisch, Cyrus Daboo, Mike Douglass
Draft last updated 2014-02-27
Completed reviews Genart Last Call review of -09 by Robert Sparks (diff)
Genart Last Call review of -09 by Robert Sparks (diff)
Secdir Last Call review of -09 by Klaas Wierenga (diff)
Assignment Reviewer Klaas Wierenga 
State Completed
Review review-ietf-jcardcal-jcal-09-secdir-lc-wierenga-2014-02-27
Reviewed rev. 09 (document currently at 10)
Review result Has Nits
Review completed: 2014-02-27



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.

This document specifies jCal, a JSON format for iCalendar data as well as semantically lossless conversion between iCalendar and jCal and vv.

I believe the document is well written and ready for publication with a few small nits:

- Paragraph 3 (converting from iCal to jCal):

The  text looks very much like production rules, why not give ABNF? (Ah wait, now that I have read the full document I see that that appears in Appendix B, I think you should at least point to Appendix B here)

- Paragraph 3.4 and onwards

It is unclear to me when you write for example "Each individual iCalendar property is represented in jCal by …" whether you really mean to write: "Each individual iCalendar property MUST be represented in jCal by…." 
I assume you want to be normative in specifying the format?

- Paragraph 9.2 should RFC4627 not be a normative rather than informative reference?