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

[Ken Murchison <[e-mail]>]

Hi Benjamin,

Thanks for the detailed review.  Responses below, but you'll want to 
look at the new text in -06.


On 2/24/21 8:25 PM, Benjamin Kaduk via Datatracker wrote:
> 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 tohttps://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).


Fixed, with associated extension to the ABNF and corrected example.



> ----------------------------------------------------------------------
> 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?


The new syntax is intended to be equivalent.  I've augmented the text to 
state that.



> 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).


Clarified using your suggested rewording.



> 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...


I think the parent/child/sibling language wasn't quite clear.  I 
reorganized the snooze process as a series of steps and tried to clarify 
the parent/child relationship with an example.


> 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.


Sections 8 and 8.1 have been rewritten in -06 to hopefully be more clear.


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


No reason other than a mistake.  Corrected.


> 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.)


Augmented the text remove the word "spam" and to include embarrassment 
as a possible outcome.


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


Moved to Informational.

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC