Last Call Review of draft-ietf-calext-availability-03
review-ietf-calext-availability-03-secdir-lc-harkins-2016-07-14-00
Request | Review of | draft-ietf-calext-availability |
---|---|---|
Requested revision | No specific revision (document currently at 04) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2016-07-05 | |
Requested | 2016-06-23 | |
Authors | Cyrus Daboo , Michael Douglass | |
I-D last updated | 2016-07-14 | |
Completed reviews |
Genart Last Call review of -04
by Christer Holmberg
Secdir Last Call review of -03 by Dan Harkins (diff) Opsdir Last Call review of -01 by Qin Wu (diff) |
|
Assignment | Reviewer | Dan Harkins |
State | Completed | |
Request | Last Call review on draft-ietf-calext-availability by Security Area Directorate Assigned | |
Reviewed revision | 03 (document currently at 04) | |
Result | Has issues | |
Completed | 2016-07-14 |
review-ietf-calext-availability-03-secdir-lc-harkins-2016-07-14-00
Greetings, 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! regards, Dan.