[secdir] secdir review of draft-ietf-jcardcal-jcal-09

"Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> Tue, 25 February 2014 14:37 UTC

Return-Path: <kwiereng@cisco.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id EA2591A0758; Tue, 25 Feb 2014 06:37:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.048
X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id DAsRhT4mPvvH; Tue, 25 Feb 2014 06:37:06 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com []) by ietfa.amsl.com (Postfix) with ESMTP id EAAC71A075B; Tue, 25 Feb 2014 06:37:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1289; q=dns/txt; s=iport; t=1393339024; x=1394548624; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=vvn6VmqBsbaBkyB5IVlXKXTEaxdfsYJ6YelXQRG4vjE=; b=PrtykBQYasBMbGitVDnhHnzmiKK9lurNECRCMPI/fWATHm6mez/miA6Q hwTYjGIIaG+EmPJUcDlX1MRVXDzZuc8V+zD33sK5EdQNxca0HTmd1tEu2 TJro0FKhtgCZsTXOlAUrVV3c6y7LprkcDmAuvZdkHaSh7Uz6hVj1I2yqp c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av8EAGCqDFOtJXG+/2dsb2JhbABZgwaBEsJoFnSCLIELAYEAJwQBiBfHAheSD4EUBJg0kieDLYIq
X-IronPort-AV: E=Sophos;i="4.97,540,1389744000"; d="scan'208";a="306184612"
Received: from rcdn-core2-3.cisco.com ([]) by rcdn-iport-1.cisco.com with ESMTP; 25 Feb 2014 14:36:59 +0000
Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com []) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1PEaws6002579 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 14:36:58 GMT
Received: from xmb-aln-x12.cisco.com ([]) by xhc-rcd-x09.cisco.com ([]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 08:36:58 -0600
From: "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com>
To: "iesg@ietf.org" <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-jcardcal-jcal.all@tools.ietf.org" <draft-ietf-jcardcal-jcal.all@tools.ietf.org>
Thread-Topic: secdir review of draft-ietf-jcardcal-jcal-09
Thread-Index: AQHPMjcJwgX+osJyDEaPL10iZVgG5Q==
Date: Tue, 25 Feb 2014 14:36:58 +0000
Message-ID: <894C08E3-0017-4830-9C8F-930CCEB5B2E2@cisco.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <B8AD1D6A016C3F48AA4A1679203F88D6@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/zxSw-sAKhfIk5Y4IIFkF3jgfJhE
Subject: [secdir] secdir review of draft-ietf-jcardcal-jcal-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Feb 2014 14:37:08 -0000


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?