[calsify] Benjamin Kaduk's Discuss on draft-ietf-calext-valarm-extensions-05: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-calext-valarm-extensions-05: 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-valarm-extensions/



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

Please update to reflect the changes made in draft-ietf-calext-eventpub-extensions-17
(e.g., there is no longer STRUCTURED-LOCATION and VLOCATION plays a similar
role).


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

[edited to add a comment section, now that I finished my way through
the document]

A lot of these improvements look familiar from
draft-ietf-calext-jscalendar :)

Please note the question about interactions between "geo:" URIs and
(presumed mobile) vehicles, in Section 8; that was almost a Discuss.

Section 3

Is the new syntax for VALARM claimed to be exactly equivalent or just
"basically the same" as the RFC 5545 definition?

Section 6.1

   Description:  This property is used to specify when an alarm was last
      sent or acknowledged.  This allows clients to determine when a

(editorial) the "last sent" part only becomes clear in the second
paragraph; perhaps "when an alarm was last acknowledge (or sent, if
acknowledgment is not possible)" would help clarify (and would also do
better to set up the rest of this paragraph that mostly assumes the
"acknowledged" case).

Section 7

   To "snooze" an alarm, clients create a new "VALARM" component within
   the parent component of the "VALARM" that was triggered and is being
   "snoozed" (i.e., as a "sibling" component of the "VALARM" being
   snoozed).  [...]

The way this is written seems to imply something that does not seem
correct.  That is, the "i.e., as a 'sibling'" seems to imply that VALARM
will always exist in a parent/child relationship, with only "child"
instances ever actually triggering.  Since we only just in this document
allow VALARM to have the RELATED-TO property, I don't see how that could
be the case.  Perhaps it is enough to just say "e.g., as a "sibling"
component of the "VALARM" being snoozed", since "e.g." does not imply
that the statement applies for all cases, but I would expect some more
substantial discussion of the procedures involved when there is just a
single alarm being snoozed, and how the first child is created, what
needs to be done (if anything else) to create the overarching "parent",
etc.  The only text I see right now that covers this case is the
addition of "UID" if not already present (and UID has to be present if
there's a parent/child relationship), but that's not really the same
thing.

   Alternatively, if the "snooze" alarm is itself "snoozed", the client
   MUST remove the original "snooze" alarm and create a new one, with
   the appropriate trigger time and relationship set.

(This part seems a bit at odds with the "as a 'sibling' text above that
I complained about -- if the alarm being triggered is getting removed,
it seems hard for it to be a sibling of anything.)

Section 7.1

   This specification adds the "SNOOZE" relationship type for use with
   the "RELTYPE" property defined in Section 3.2.15 of [RFC5545].  This
   is used when relating a "snoozed" "VALARM" component to the original
   alarm that the "snooze" was generated for.

Is this going to be the "parent" or the "sibling" (or potentially
either)?  Note my previous comment about "sibling"s getting removed...

Section 8

      "STRUCTURED-LOCATION" [I-D.ietf-calext-eventpub-extensions] - used
      to indicate the actual location to trigger off, specified using a
      geo: URI [RFC5870] which allows for two or three coordinate values
      with an optional uncertainty

(nit?) maybe "trigger off of"?

      "STRUCTURED-LOCATION" [I-D.ietf-calext-eventpub-extensions] - used
      to indicate the actual location to trigger off, specified using a
      geo: URI [RFC5870] which allows for two or three coordinate values
      with an optional uncertainty

How do I use a geo: URI to indicate the vehicle to which I (dis)connect
via Bluetooth with?

Section 8.1

(side note) is there work underway to define proximity triggers for
JSCalendar?

   Description:  This property is used to indicate that an alarm has a
      location-based trigger.  Its value identifies the direction of
      motion used to trigger the alarm.  One or more location values
      MUST be set using "STRUCTURED-LOCATION" properties.

(editorial) I don't see how we get "direction of motion" from the rest
of the description.  What I see described is just, well, a
proximity-based trigger, without sensitivity to in what direction the
proximity is attained.  There are triggers based on whether the distance
metric crosses a threshold in one direction or the other, but that's
still not directional in a typical 3-dimentional vector sense.

Section 8.2

Is there a reason for the "TRIGGER" line to appear twice in the example?

Section 9

I think there is also potential for abuse in causing embarassing or
otherwise undesired alerts (especially audio ones) when a victim is in a
particular location.  (But the mitigation is basically the same as for
the already-indicated threats.)

Section 13

It's not entirely clear to me that RFC 4791 needs to be classified as
normative.