[calsify] Murray Kucherawy's No Objection on draft-ietf-calext-eventpub-extensions-17: (with COMMENT)

[Murray Kucherawy via Datatracker <[e-mail]>]

Murray Kucherawy has entered the following ballot position for
draft-ietf-calext-eventpub-extensions-17: 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/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-eventpub-extensions/



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

Section 1.2 says "For example, we may want to record who is participating in a
public event", but the Privacy Considerations section doesn't say anything
about the fact that this could collect data about people who are interested in
the event, even if they don't go (though the location issue is mentioned). 
Also, especially since 2020, the public event could be a purely online event,
where location data isn't part of the issue.  (Alternatively, if this is meant
to address in-person events only, that would be useful to say up front.)

Section 6.2 (and other sections, but I noticed it here): ABNF literal strings
are case-insensitive.  That means, for example, that the ABNF here would allow
"ACTIVE" for a "partvalue", but would also allow "active", "AcTiVe", etc.  Is
that acceptable?  (This probably applies to lots of prior CALEXT documents -- I
admittedly didn't check -- so it may not be worth fixing here.)

Section 6.4:

   Property Parameters:  IANA, or non-standard property parameters can
      be specified on this property.

I think that should be "IANA-registered"?  Same issue in Sections 6.5 and 6.6.

Section 7: I believe the ABNF here needs a once-over.

Section 9.2: For the threat described in the first paragraph, are there any
possible mitigations to suggest?

Section 10.2: In "without that participants express permission", that should be
"participant's".  There's also a period missing at the end of the second last
paragraph, though as it reads, it's possible there's even some intended text
missing.

Section 11.2: The rules for making registrations into both the existing
registries and these new ones are striking.  RFC 8126 doesn't even create a
category that is a combination of Expert Review and Standards Action, but
that's what this spells out.  And I wonder what would happen if we were to
publish a Standards Track RFC (which has IETF consensus) with which the
Designated Expert disagreed.  I'm not asking for anything to change here given
that consistency with the existing registries is probably desirable, but it
does set an unusually high bar for registrations.