Reviewer: Reese Enghardt Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-calext-ical-tasks-12 Reviewer: Reese Enghardt Review Date: 2025-03-10 IETF LC End Date: 2025-03-11 IESG Telechat date: Not scheduled for a telechat Summary: The document is ready for publication, and I have a few minor suggestions to improve clarity on the motivation and diff to the previous spec. Major issues: None. Minor issues: Abstract: "The Internet Calendaring and Scheduling Core Object Specification (iCalendar) (RFC5545) VTODO calendar component has been seen as the poor relation of VEVENT - useful only for personal reminders and to-do lists." While I agree that it's helpful to lay out the motivation for this work, please consider rephrasing this part to be more neutral in tone and/or a bit more specific. Maybe something like "has seen limited adoption and use"? I am not sure what "a poor relation" means in a technical context. Section 1, Introduction: I am curious about the specific extensions and improvements to VTODO that this specification adds. For example, was VTODO already capable to be used in an automated way? Is the task architecture new or was it already used in RFC 5545? Please consider laying out the improvements that this specification adds explicitly. Considering the motivation of this work, are there any specific improvements that are believed to make VTODO "more useful", and why? I can see that sections 6 and 7 lay out some of these changes, but I think it'll be helpful to already mention the potential improvements in the Introduction. Section 5, Task Extensions: "In order to support the task architecture described in Section 2, this document defines a number of extensions to the current iCalendar standards in the areas of: Task Specification improved ability to specify domain specific tasks Task Deadlines, Milestones and Time Planning clarification of deadlines and extension for task duration to support task time planning Task Scheduling and Assignment ensure support for common patterns of scheduling and assigning tasks Task Status Tracking improved granularity in status tracking information and alerting task actors of pending or actual task status changes" I suggest being more specific here, for example, saying that the document extends a specific specification with an RFC number by adding fields to specific components. I think highlighting that these added fields are expected to make VTODO more useful will be good content for the Introduction section. Section 16, "Security Considerations": If this specification is expected to improve the ways in which VTODO can be automated, rather than being mostly used manually by individual users, are there potential new risks? Nits/editorial comments: None. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
