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

[Barry Leiba <[e-mail]>]

And the -06 version has been posted; Ben, please have a look as soon
as you can, and let us know.

Thanks,
b

On Tue, Mar 2, 2021 at 3:26 PM Ken Murchison <[e-mail]> wrote:
>
> 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
>