Subject: [calsify] Kathleen Moriarty's Discuss on draft-ietf-calext-extensions-03: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Tue, 28 Jun 2016 17:45:25 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-calext-extensions-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-calext-extensions/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This should be really easy to clear... 

Thank you for addressing the SecDir reviewers comments.  I'd like to see
the updated text added in the editor's version of the draft that
addresses the secdir review.  In particular, the email thread just says
that text was added to cover possible new threats and I'd like to see
that and the new privacy considerations section.
https://www.ietf.org/mail-archive/web/secdir/current/msg06636.html

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Jun 2016 09:49:59 -0400

Hi Kathleen,

> https://www.ietf.org/mail-archive/web/secdir/current/msg06636.html

I've attached a copy of the draft as it stands after the changes I have 
made. I was going to wait until after IESG review was done before 
publishing it, but I can just do it now if that would help.

-- 
Cyrus Daboo

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Jun 2016 09:56:10 -0400

On Wed, Jun 29, 2016 at 9:49 AM, Cyrus Daboo <[email-masked]> wrote:
> made. I was going to wait until after IESG review was done before publishing
> it, but I can just do it now if that would help.
>

I think it would help to update prior to Stephen's review and Alissa's
if they haven't read it already as they will also want to review the
updated text.

Thanks!

-- 

Best regards,
Kathleen

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 29 Jun 2016 14:58:31 +0100

Hi Cyrus,

On 29/06/2016 14:49, Cyrus Daboo wrote:
> I've attached a copy of the draft as it stands after the changes I 
> have made. I was going to wait until after IESG review was done before 
Please post it now.

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Jun 2016 10:02:52 -0400

Hi Kathleen,

> if they haven't read it already as they will also want to review the

New -04 version of the draft has now been posted.

-- 
Cyrus Daboo

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Jun 2016 10:10:32 -0400

> New -04 version of the draft has now been posted.

Thank you!  I'll look at it in a little while.

-- 

Best regards,
Kathleen

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 29 Jun 2016 12:50:42 -0400

Hi Kathleen,

> Thank you!  I'll look at it in a little while.

Just FYI the -04 privacy section has just had a number of 
additions/revisions in response to Stephen's comments. Here is a complete 
copy of what I currently have:

8.  Privacy Considerations

   Several of the new properties or parameters defined by this
   specification allow reference to "external" URIs.  Access to those
   URIs could be tracked, leading to loss of privacy.  Clients SHOULD
   ensure that suitable permission is granted by calendar users before
   such URIs are dereferenced.  In particular, calendar publishers
   wishing to help protect the privacy of their subscribers MUST use
   HTTP with Transport Layer Security [RFC7230] ("https:" URIs instead
   of "http:" URIs) for access to calendar data or ancillary data such
   as images.

   In general, users have to rely on the privacy policies of any
   conferencing system being accessed via the "CONFERENCE" property, for
   their own privacy protection.  It is entirely possible for such
   systems to uniquely identify and log the activity and participation
   (or not) of calendar users in the conference.  Calendar user agents
   SHOULD track which conferencing systems are used and warn users the
   first time a new one is about to be used.  This is particularly
   important if the client automatically "dials in" to the conference
   when the event start time occurs.

   By giving different calendar users different values for the "REFRESH-
   INTERVAL" property, it is possible for a publisher of calendar data
   to uniquely identify each refresh from each calendar users' clients,
   and thereby track user activity and IP address over time.  To address
   this, clients SHOULD add or subtract some random amount of time from
   the published "REFRESH-INTERVAL" value when doing actual refreshes.

   Privacy considerations in [RFC5545], and [RFC5546] MUST also be
   adhered to.

-- 
Cyrus Daboo

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 29 Jun 2016 13:17:06 -0400

Thank you, Cyrus!

I was following Stephen's discuss and was happy with the text
proposed.  Thanks for being so responsive, it's really helpful!

-- 

Best regards,
Kathleen