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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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 her?

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

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

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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

[Ballot comment]
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

[Ballot comment]
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 mentionning.

Regards

-éric

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-calext-valarm-extensions-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete.

First, in the Properties registry on the iCalendar Element Registries registry page located at:

https://www.iana.org/assignments/icalendar/

two, new properties are to be registered as follows:

Property: ACKNOWLEDGED
Status: Current
Reference: [ RFC-to-be; Section 6.1 ]

Property: PROXIMITY
Status: Current
Reference: [ RFC-to-be; Section 8.1 ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, in the Relationship Types registry also on the iCalendar Element Registries registry page located at:

https://www.iana.org/assignments/icalendar/

a single, new relationship type is to be registered as follows:

Relationship Type: SNOOZE
Status: Current
Reference: [ RFC-to-be; Section 7.1 ]

As this also requests registrations in an Expert Review registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Third, a new registry is to be created called the Proximity Value Registry. The new registry will be located on the

iCalendar Element Registries registry page located at:

https://www.iana.org/assignments/icalendar/

IANA Question --> How is the new registry to be managed? What are the registration rules for the new registry (please see RFC 8126)?

There are four initial values in the new registry as follows:

Value: ARRIVE
Status: Current
Reverence: [ RFC-to-be; Section 8.1 ]

Value: DEPART
Status: Current
Reverence: [ RFC-to-be; Section 8.1 ]

Value: CONNECT
Status: Current
Reverence: [ RFC-to-be; Section 8.1 ]

Value: DISCONNECT
Status: Current
Reverence: [ RFC-to-be; Section 8.1 ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-02-16):

From: The IESG
To: IETF-Announce
CC: Bron Gondwana , Daniel Migault , barryleiba@gmail.com, calext-chairs@ietf.org, calsify@ietf.org, draft-ietf-calext-valarm-extensions@ietf.org, mglt.ietf@gmail.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (VALARM Extensions for iCalendar) to Proposed Standard


The IESG has received a request from the Calendaring Extensions WG (calext)
to consider the following document: - 'VALARM Extensions for iCalendar'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-02-16. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document defines a set of extensions to the iCalendar VALARM
  component to enhance use of alarms and improve interoperability
  between clients and servers.

  This document updates RFC5545.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-calext-valarm-extensions/



No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

the type of RFC is standard track. This is appropriated as it is required for interoperability. Actually the purpose of the document is to improve the interoperability of an existing extension.

This is indicate in the title header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

  This document defines a set of extensions to the iCalendar VALARM
  component to enhance use of alarms and improve interoperability
  between clients and servers.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Nothing to be noted the document got few reviews on the list, but the specification benefits from existing deployments and discussion internal at calconnect as well as during the join ietf/ calconnect meetings.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document came as pretty mature and only minor comments have been provided on the mailing list. The extension seems to benefit from experiences of it being deployed and the authors are well representative of that experience as well as th eability for the extension to provide interoprability.
The extension has also been discussed on joint calconnect/IETF meetings.

I have not special concerns of the document.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel Migault is the document shepherd Barry Leiba is the AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd review carefully the document checked ABNF description with tools. I believe the document is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I have no concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

no concerns were raised.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Authors confirmed there are not aware of any IPR.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Good consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

2119 boiler plate is present in the document

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).

The reference is present in the document

    (Using the creation date from RFC5545, updated by this document, for
    RFC5378 checks: 2008-10-31)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

No text is copied from 5545.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This does not apply here.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

no.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

no.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The document updates 5545. It is mentioned in the header, in the abstract and discussed in the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document adds:
* 2 Calendar properties
* iCalendar relationship type
* iCalendar registry for values of the "PROXIMITY" property:

The addition of a property is described in section 8.2.3 of rfc 5545. The template is are provided in section 6.1 (acknowledged) and 8.1 (proximity).
The IANA registry is describe din section 8.3.2. of rfc 5545 and the IANA section of the current document is in line with that function.

The addition of a type is described in rfc 5545 section 8.3.8. The templates are defined in section 7.1 of the document. The relationship type registry is described in section 8.3.8 of rfc 5545. The IANA section is in line with the description of that registry.

The template for proximity properties is provided in section 8.2.6 of rfc 5545. The template for the proximity values is described in section 8.1. The IANA section has a registry that follows other registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Following the procedure described in rfc 5545 section 8.2.1 the to icalendar@ietf.org and iana@iana.org for an expert review.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

ABNF has been checked though some errors has been raised mostly has some variables  were unknown. In other words the model was not self contained.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

the type of RFC is standard track. This is appropriated as it is required for interoperability. Actually the purpose of the document is to improve the interoperability of an existing extension.

This is indicate in the title header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

  This document defines a set of extensions to the iCalendar VALARM
  component to enhance use of alarms and improve interoperability
  between clients and servers.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Nothing to be noted the document got few reviews on the list, but the specification benefits from existing deployments and discussion internal at calconnect as well as during the join ietf/ calconnect meetings.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document came as pretty mature and only minor comments have been provided on the mailing list. The extension seems to benefit from experiences of it being deployed and the authors are well representative of that experience as well as th eability for the extension to provide interoprability.
The extension has also been discussed on joint calconnect/IETF meetings.

I have not special concerns of the document.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel Migault is the document shepherd Barry Leiba is the AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd review carefully the document checked ABNF description with tools. I believe the document is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I have no concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

no concerns were raised.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Authors confirmed there are not aware of any IPR.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Good consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack the recommended RFC 2119 boilerplate, even if
    it appears to use RFC 2119 keywords -- however, there's a paragraph with
    a matching beginning. Boilerplate error?

2119 boiler plate is present in the document

    (The document does seem to have the reference to RFC 2119 which the
    ID-Checklist requires).

The reference is present in the document

    (Using the creation date from RFC5545, updated by this document, for
    RFC5378 checks: 2008-10-31)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
    have content which was first submitted before 10 November 2008.  If you
    have contacted all the original authors and they are all willing to grant
    the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
    this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
    (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

No text is copied from 5545.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This does not apply here.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

no.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

no.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The document updates 5545. It is mentioned in the header, in the abstract and discussed in the introduction.

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document adds:
* 2 Calendar properties
* iCalendar relationship type
* iCalendar registry for values of the "PROXIMITY" property:

The addition of a property is described in section 8.2.3 of rfc 5545. The template is are provided in section 6.1 (acknowledged) and 8.1 (proximity).
The IANA registry is describe din section 8.3.2. of rfc 5545 and the IANA section of the current document is in line with that function.

The addition of a type is described in rfc 5545 section 8.3.8. The templates are defined in section 7.1 of the document. The relationship type registry is described in section 8.3.8 of rfc 5545. The IANA section is in line with the description of that registry.

The template for proximity properties is provided in section 8.2.6 of rfc 5545. The template for the proximity values is described in section 8.1. The IANA section has a registry that follows other registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Following the procedure described in rfc 5545 section 8.2.1 the to icalendar@ietf.org and iana@iana.org for an expert review.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

ABNF has been checked though some errors has been raised mostly has some variables  were unknown. In other words the model was not self contained.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

the type of RFC is standard track. This is appropriated as it is required for interoperability. Actually the purpose of the document is to improve the interoperability of an existing extension.

This is indicate in the title header.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction.

  This document defines a set of extensions to the iCalendar VALARM
  component to enhance use of alarms and improve interoperability
  between clients and servers.


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

Nothing to be noted the document got few reviews on the list, but the specification benefits from existing deployments and discussion internal at calconnect as well as during the join ietf/ calconnect meetings.

Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, YANG Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted?

The document came as pretty mature and only minor comments have been provided on the mailing list. The extension seems to benefit from experiences of it being deployed and the authors are well representative of that experience as well as th eability for the extension to provide interoprability.
The extension has also been discussed on joint calconnect/IETF meetings.

I have not special concerns of the document.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Daniel MIgault is the document shepherd Barry Leiba is the AD

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

The document shepherd review carefully the document checked ABNF description with tools. I believ the document is ready.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

I have no concerns.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

no.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

no concerns were raised.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

XXXXXX

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

Good consensus.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

no.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.



(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

This does not apply here.

(13) Have all references within this document been identified as either normative or informative?

yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

no.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

no.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

The document updates 5545. XXXX

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

The document adds:
* 2 Calendar properties
* iCalendar relationship type
* iCalendar registry for values of the "PROXIMITY" property:

The addition of a property is described in section 8.2.3 of rfc 5545. The template is are provided in section 6.1 (acknowledged) and 8.1 (proximity).
The IANA registry is describe din section 8.3.2. of rfc 5545 and the IANA section of the current document is in line with that function.

The addition of a type is described in rfc 5545 section 8.3.8. The templates are defined in section 7.1 of the document. The relationship type registry is described in section 8.3.8 of rfc 5545. The IANA section is in line with the description of that registry.

The template for proximity properties is provided in section 8.2.6 of rfc 5545. The template for the proximity values is described in section 8.1. The IANA section has a registry that follows other registries.

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

Following the procedure described in rfc 5545 section 8.2.1 the to icalendar@ietf.org and iana@iana.org for an expert review.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

ABNF has been checked though some errors has been raised mostly has some variables  were unknown. In other words the model was not self contained.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?