Re: [secdir] secdir review of draft-ietf-calext-availability-03

Daniel Migault <> Tue, 12 July 2016 12:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2A5412D82E; Tue, 12 Jul 2016 05:52:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E2v7SaDmWIjE; Tue, 12 Jul 2016 05:52:37 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 721D112D81A; Tue, 12 Jul 2016 05:52:34 -0700 (PDT)
X-AuditID: c6180641-f796f6d000000e1e-b4-5784e7cd0972
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 96.22.03614.EC7E4875; Tue, 12 Jul 2016 14:51:26 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0294.000; Tue, 12 Jul 2016 08:52:33 -0400
From: Daniel Migault <>
To: Dan Harkins <>, "" <>, "" <>, "" <>
Thread-Topic: secdir review of draft-ietf-calext-availability-03
Thread-Index: AQHR28MRmJRM+fg80UybXqXIdH3KlqAUwOCQ
Date: Tue, 12 Jul 2016 12:52:33 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXSPt+655y3hBs+eilgs/feFxeLw+j5G ixl/JjJbfFj4kMWBxWPJkp9MHs92v2QJYIrisklJzcksSy3St0vgyli19gBTwX7Bij2H9jM1 MN7j7WLk5JAQMJGY+fExK4QtJnHh3nq2LkYuDiGBo4wS7768ZgdJCAksZ5R4NNMfxGYTMJJo O9TPDlIkInCOUeLXvo1MIAlhAXuJ9Z+eMYPYIgIOElv/f2eCsI0kJq95AWRzcLAIqEo8/JYA EuYV8JV4c6GPBWK+l8TC7s9grZwC3hJ3DpwFizMCHfT91BqwMcwC4hK3nsxngjhUQGLJnvPM ELaoxMvH/6AeUJTY1z+dHaJeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRl FpKWBYwsqxg5SosLcnLTjQw3MQIj5JgEm+MOxr29nocYBTgYlXh4F9xrDhdiTSwrrsw9xCjB wawkwjsVGF9CvCmJlVWpRfnxRaU5qcWHGKU5WJTEefVfKoYLCaQnlqRmp6YWpBbBZJk4OKUa GLNdOZwiLE+4Rf+/UXk6RSiE/zT/laMVH/c/277Kbl7Z/x/XT8uXBOtOnCYweVKZeiDv7ke+ T/oENl5xCN7+f1b4ktfpEyuPKN8rfvTgM+9NwX0KPXsuZ7GvnNNxju/I3We7bjy9XM1bunf9 uXmrDE5JTDhkpBIWqqvssP3emv0ezSYcbVe/rN+uxFKckWioxVxUnAgAIrmzo4wCAAA=
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-calext-availability-03
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 12 Jul 2016 12:52:39 -0000

Hi Dan, 

Thanks for the review!


-----Original Message-----
From: Dan Harkins [] 
Sent: Monday, July 11, 2016 6:25 PM
Subject: secdir review of draft-ietf-calext-availability-03


  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 draft specifies a way to use iCalendar to publish time periods of a person's availability and unavailability. For the record, I am not knowledgeable of namespace requirements on the components described in this draft so I'm just assuming that stuff is OK.

  I believe this draft is "Ready with issues". Those issues are:

  - the steps to calculate free-busy time (section 5) has a for loop
    that goes from the lowest priority entry to the highest priority
    entry. But the 2nd step says, "Determine if the 'VAVAILABILITY'
    is completely overridden by a higher priority component. If so
    ignore it." How can a higher priority component already hold that
    time if we're looping from lower priority to higher priority?

    This step seems superfluous or there's some assumption on the
    state of the calendar prior to the loop that I'm not getting.
    Please fix this or point me to the text that I missed.

  - I am very happy to see Privacy Considerations because that was the
    thing that jumped out at me when I started reading. But there are
    normative requirements in the Privacy Considerations and I feel
    those would be better placed in the appropriate sections of the
    draft that deal with that behavior. It is my feeling that Privacy
    Considerations (and Security Considerations) should consider the
    effects of the normative action described above them and not
    indicate additional normative requirements.

Other than that, publish away!