"VALARM" Extensions for iCalendar
draft-ietf-calext-valarm-extensions-07

This document appears to enable (or continue) support for the notion of extension properties prefixed by "X-" (via the "x-prop" ABNF token).  That seems contrary to BCP 178.  I realize this is just continuing in what was done in RFC 5545, but should it be dropped here?

Other than this one concern, this is really well written.  Nice work.

Thank you to Valery Smyslov for the SECDIR review.  Also thanks for responding to it.

Please note: I am not an iCal person (probably as demonstrated by the fact that I call it ical), and parsing an icalendar file fills me with dread -- but even I found this document clear, readable, understandable, and solving a set of problems that I understand. 
Thank you for such a good read.

Thank you for this document, it is easy to read and the "snooze" and "ack" extensions will be indeed useful.

During my IESG review, I found nothing worth mentioning.

Regards

-éric

Section 8.2 uses the term "precision," but precision and uncertainty are not the same thing and should not be confused. See RFC 7459. Please use the term "uncertainty" here instead.

Thanks for responding to my previous question to clarify that the intent
is to provide an equivalent form for the alarm ABNF to what is in RFC
5545.  (I personally am not prepared to assert that it definitely is/was
equivalent, since I only looked closely enough to ascertain that it is
at least very similar.  I would prefer if we had some independent
verification of that, but I don't even know what form that verification
would take, so I can hardly insist upon it.)

That said, in making the changes to adapt to VLOCATION, we had to add
the "alarm-subcomp" production that includes x-comp / iana-comp, and
it's pretty hard for me to claim that with alarm-subcomp in place, the
ABNF remains "equivalent" to the RFC 5545 form.  So maybe we have to
revisit that claim, or leave the initial alarm-subcomp as an empty
production and make some additional explicit extension where we allow
subcomponents, or something.

Section 7

   3.  When the "snooze" alarm is triggered, the client MUST do the
       following:

       A.  Reset the "ACKNOWLEDGED" property on the original related
           alarm.

(nit) I think that "clear" or "remove" would probably be more clear than
"reset".

Section 7.2

Should the DTSTAMP of the VEVENT change when the snooze events occur?

Also, IIUC, the ACKNOWLEDGED time for the primary alarm
(8297C37D-BA2D-4476-91AE-C1EAA364F8E1) should be something after
20210302T152000Z after the second snooze event.  (It currently shows as the
same 20210302T151514Z from after the first snooze.)

It's also a little surprising that the final acknowledgment occurs after the
meeting starts, some 6 minutes after the alarm triggered, but that's not
actually a protocol error, so it's technically okay.

Section 8

      "PROXIMITY" property - indicates that a location based trigger is
      to be used and which direction of motion is used for the trigger

It looks like we got rid of the "direction of motion" reference later on
(where I had actually commented on it), but this one should go as well.

Hi,

I was pleased to see the comments about security/privacy for UUIDs in section 4, but I wonder whether it would be helpful for chapters 9 and/or 10 to have a back reference to the UUID security/privacy considerations.

Thanks,
Rob