Looks like you cleared up the issue raised in Erratum 1709.
(http://www.rfc-editor.org/errata_search.php?eid=1709)
You might ask your AD to close the Erratum record.

  The Gen-ART Review by Vijay K. Gurbani posted on 16-Sep-2009 points
  out two nits:

  1) S6.1.4 is about eavesdropping and not data integrity, right?
  But the misuse suffered by a cleartext iCalendar object is given
  both treatments: lack of privacy and loss of data integrity.  A
  simple suggestion would be to remove "and/or changed" from S6.1.4,
  and have a new paragraph as follows:

    Data Integrity

    The iCalendar object is constructed with human-readable
    clear text.  Any information contained in an iCalendar object
    may be changed by unauthorized persons while the object is
    in transit.

  2) Acknowledgments: s/S.Silverberg/S. Silverberg/

3.2.2.3.  Delegating an Event to another CU

   In response to the request, the "Delegate" MUST send a "REPLY" method
   to the "Organizer" and optionally, to the "Delegator".  The "REPLY"
   method SHOULD include the "ATTENDEE" property with the "DELEGATED-
   FROM" parameter value

The SHOULD sounds a bit too weak here.

   of the "Delegator's" calendar address.

5.1.1.  Event-Related Fallbacks

   +----------------+--------------------------------------------------+
   | Method         | Fallback                                         |
   +----------------+--------------------------------------------------+
   | PUBLISH        | Required                                         |
   | REQUEST        | PUBLISH                                          |
   | REPLY          | Required                                         |
   | ADD            | Required if recurrences supported, otherwise     |
   |                | reply with a REQUEST-STATUS "2.8;Success,        |
   |                | repeating event ignored.  Scheduled as a single  |
   |                | component." and schedule as a single component.  |
   | CANCEL         | Required                                         |
   | REFRESH        | Required                                         |
   | COUNTER        | Reply with "Not Supported"                       |
   | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs,  |
   |                | otherwise reply with "Not Supported"             |
   +----------------+--------------------------------------------------+

This table is not very clear which requirements apply to Organizer and
which requirements apply to Attendees.
(Similar comment about other tables)

The OPS-DIR review by Menachem Dodge brought up the following issues and nits: 

1. This document obsoletes RFC 2446. The modifications are listed in Appendix A – "Differences from RFC 2446". It would be useful to have text that discusses any possible interworking issues that may occur between implementations of this document and implementations of RFC 2446.

2. It would be helpful to have an abbreviations section to refer to as needed, or to exapnd acronyms at first occurence.

Example: 

CS   -   Calendar Service
CU -    Calendar User

3.       A few minor corrections:

a.       Page 9: Section 1.4 Methods

Within the table for the method COUNTER. 

"objecy"

OLD ->  COUNTER         |   The Counter method is used by an "Attendee" to   negotiate a change in an iCalendar objecy.

SUGGESTED -> COUNTER |   The Counter method is used by an "Attendee" to   negotiate a change in an iCalendar object.

b.      Page 53

OLD -> The "Organizer" is MUST send a "CANCEL"

SUGGESTED -> The "Organizer" MUST send a "CANCEL

Section 5.2.1 recommends holding onto CANCEL messages that can't be correlated to a REQUEST when they arrive (because of reordering on store-and-forward transports perhaps). The security considerations section should discuss when to stop doing this (bad-guys can make up a lot of CANCELs). Something similar to the flood mitigation discussed in 6.2.2 paragraph 2 would work.

The first paragraph of 6.2.2 recommends that CUs be given the choice to honor an Organizer change. I think it would be useful guidance to implementers to point out here that if individual CUs in that set make different choices, future changes by _either_ of the resulting Organizers will not be accepted by all of the CUs. The protocol will not malfunction (as far as I can tell), but the original set of CUs may end up attending two different meetings. (Implementers could, in turn, provide guidance to users making that choice or to let Organizers know that their attempt to make a change was not wholly accepted).