[calsify] Mohamed Boucadair's No Objection on draft-ietf-calext-ical-tasks-13: (with COMMENT)

[Mohamed Boucadair via Datatracker <[e-mail]>]

Mohamed Boucadair has entered the following ballot position for
draft-ietf-calext-ical-tasks-13: No Objection

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/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


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



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi Adrian & Michael,

Thanks for the effort put into this specification.

# Beyond calext

As a side note, the base spec (RFC 5545) is being leveraged outside the initial
calext use cases. Specifically, this is being leveraged for network management
scheduling (and then consumed by a bunch of specs out there OPSAWG/TVR). You
may refer to related scheduling work in netmod, in particular. Likewise,
similar approaches can be used for traffic engineering such as in RFC 8413.

# Architectural clarifications

With the previous note in mind, I have the following questions on the base
architecture (Figure 1):

* In reference to process logic box, is task conflict handling part of this
process? Also, does this cover inter-dependency between tasks?

* In reference to the task status, do we distinguish task scheduling status vs.
task (occurrence) execution status?

* Many of the entities discussed in the draft should be generalized to not
infer this is a physical person, but  a logical entity that covers both
person/software entities. You have this right in many places, but a check would
be appreciated. For example, the “creator” can ne also a logical entity, not
only a person.

# ABNF

I guess RFC5234 should be cited for the syntax part. This should be normative,
BTW.

I didn’t check the syntax, but I trust this was done by the WG/Authors.

# Some nits

* Add a statement to the abstract to indicate this document updates RFC5545.

* s/This document specifies extensions to the existing Internet/ This document
specifies extensions to the Internet

* (many occurrences like the following need fixing)

OLD:
   The specification of tasks how a task type is defined and the
      relationships between tasks See Section 4.

NEW:
   The specification of tasks:  how a task type is defined and the
      relationships between tasks. See Section 4.

*

OLD:
   Their planning and scheduling  Improved specification of deadlines
      and estimated time.  See Section 5

NEW:
   Task planning and scheduling:  Improved specification of deadlines
      and estimated time.  See Section 5

Also, can we clarify “estimated tome” of what?

* I don’t part the part with “see Section 8”

CURRENT:
   Task assignment, and status reporting:  The addition of VSTATUS, see
      Section 8 allows for more detailed reports.  See Section 7.

As I’m there, s/Task assignment, and status reporting/ Task assignment and
status reporting

# Section 14

Consider citing RFC9253 as well in:

CURRENT:
   This specification introduces no new security considerations beyond
   those identified in [RFC5545], [RFC5546] and [RFC4791].

Given that we say:

   Additionally, this specification uses definitions from Support for
   iCalendar Relationships [RFC9253].

Thank you.

Cheers,
Med