Conference Event Package Data Format Extension for Centralized Conferencing (XCON)
draft-ietf-xcon-event-package-01

[Ballot comment]
Please consider these comments from the Gen-ART Review by Pete McCann.
  These are not addressed in the current RFC Editor note.

  Section 5.1 says:
  >
  > When the server receives a SUBSCRIBE request (refresh or termination)
  > within the associated subscription, it SHOULD send a NOTIFY request
  > containing the full document using the 'application/
  > xcon-conference-info+xml' content type.
  >
  Do you really want to send the full document upon termination of the
  subscription?

  Section 3:
  s/instance has experimented/instance has experienced/

  Section 5.2:
  s/received in notification/received in the notification/
  s/If subscriber/If the subscriber/

[Ballot comment]
Please consider these comments from the Gen-ART Review by Pete McCann.

  Section 5.1 says:
  >
  > When the server receives a SUBSCRIBE request (refresh or termination)
  > within the associated subscription, it SHOULD send a NOTIFY request
  > containing the full document using the 'application/
  > xcon-conference-info+xml' content type.
  >
  Do you really want to send the full document upon termination of the
  subscription?

  Section 3:
  s/instance has experimented/instance has experienced/

  Section 5.2:
  s/received in notification/received in the notification/
  s/If subscriber/If the subscriber/

IANA Last Call comments:

Action 1:

Upon approval of this document, IANA will make the following
assignmentsin the "Application Media Types" registry at
http://www.iana.org/assignments/media-types/application/

xcon-conference-info+xml [RFC-xcon-event-package-01]
xcon-conference-info-diff+xml [RFC-xcon-event-package-01]


Action 2 (Section 6.3):

Upon approval of this document, IANA will make the following
assignment in the "ns" registry at
http://www.iana.org/assignments/xml-registry/ns.html

ID URI Registration template Reference
------- ------------------ -------------------- ---------
xcon-conference-info-diff urn:ietf:params:xml:ns:xcon-conference-info-diff
xcon-conference-info-diff [RFC-xcon-event-package-01]


Action 3 (Section 6.4):

Upon approval of this document, IANA will make the following
assignment in the "schema" registry at
http://www.iana.org/assignments/xml-registry/schema.html

ID URI Filename Reference
------- ------------------ -------------------- ---------
xcon-conference-info-diff
urn:ietf:params:xml:schema:xcon-conference-info-diff xcon-conference-info-diff
[RFC-xcon-event-package-01]


We understand the above to be the only IANA Actions for this document.

(1.a)  Who is the Document Shepherd for this document?  Has the
      Document Shepherd personally reviewed this version of the
      document and, in particular, does he or she believe this
      version is ready for forwarding to the IESG for publication?

Adam Roach  has personally reviewed this version
of the  document, and beleives it is ready to be forwarded to the
IESG for publication.

(1.b)  Has the document had adequate review both from key WG members
      and from key non-WG members?  Does the Document Shepherd have
      any concerns about the depth or breadth of the reviews that
      have been performed?

As with all current XCON work, the community of commenters has been
relatively small and relatively sedate.

(1.c)  Does the Document Shepherd have concerns that the document
      needs more review from a particular or broader perspective,
      e.g., security, operational complexity, someone familiar with
      AAA, internationalization or XML?

Although heavy in XML, one of the document's authors (Juri Urpalainen)
is highly proficient in XML. Further review is not beleived necessary.

(1.d)  Does the Document Shepherd have any specific concerns or
      issues 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.

The document shepherd has no areas of concern pertaining to the document.

(1.e)  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?

As with all current XCON work, the community of commenters has been
relatively small and relatively sedate. All current key XCON contributors
have read and commented on the current version of the document or
earlier versions with substantially the same technical content.

(1.f)  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
      entered into the ID Tracker.)

No strong discontent has been raised over the content of the document.

(1.g)  Has the Document Shepherd personally verified that the
      document satisfies all ID nits?  (See
      http://www.ietf.org/ID-Checklist.html and
      http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
      not enough; this check needs to be thorough.  Has the document
      met all formal review criteria it needs to, such as the MIB
      Doctor, media type and URI type reviews?

The boilerplate conforms to RFC 3978 instead of RFC 4748. The
shepherd assumes that this issue will be fixed as a matter of course
of the publication process.

Several references need to be updated and/or recharacterized. These are
handled in RFC editors notes, below.

(1.h)  Has the document split its references into normative and
      informative?  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
      strategy for their completion?  Are there normative references
      that are downward references, as described in [RFC3967]?  If
      so, list these downward references to support the Area
      Director in the Last Call procedure for them [RFC3967].

The only less-mature normative reference is to
ietf-xcon-common-data-model. Publication of the Common Data Model
is on hold, pending finalization of the conference control protocol
(on the relatively slim possibility that finishing that work turns
up missing components in the common data model). Publication of the
common data model will be requested once the working group agrees
that the conference control protocol is technically complete.

(1.i)  Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body
      of the document?  If the document specifies protocol
      extensions, are reservations requested in appropriate IANA
      registries?  Are the IANA registries clearly identified?  If
      the document creates a new registry, does it define the
      proposed initial contents of the registry and an allocation
      procedure for future registrations?  Does it suggested a
      reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis].  If the document
      describes an Expert Review process has Shepherd conferred with
      the Responsible Area Director so that the IESG can appoint the
      needed Expert during the IESG Evaluation?

With the exception of a minor issue fixed in the attached RFC
Editors' notes, all IANA actions are clearlly documented, and
match the content of the document.

(1.j)  Has the Document Shepherd verified that sections of the
      document that are written in a formal language, such as XML
      code, BNF rules, MIB definitions, etc., validate correctly in
      an automated checker?

Section 5.4 defines an XML schema which builds on the patch-ops
schema. This schema passes the strict syntax check available via
.

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

Technical Summary
  This document specifies a Session Initiation Protocol (SIP)
  Event Package to provide state to partipants in a Centralized
  Conferencing (XCON)-defined conference, including the specification
  of a mechanism for partial notifications.

Working Group Summary

  This document is a product of the XCON working group.
  Its contents have been uncontroversial in working group
  discussions.

Document Quality

  Adam Roach has reviewed the document for quality.

Personnel

  Adam Roach is the Document Shepherd for this document.
  Cullen Jennings is the responsible Area Director.

RFC Editor Notes

Normative References:
  - Please replace draft-ietf-simple-xml-patch-ops with RFC 5261
  - Please replace draft-ietf-xcon-common-data-model-08
    with the proper RFC number when that document is published.

Please create a "Non-Normative References" section:
  - Move draft-ietf-xcon-framework to it (changing it to
    RFC 5239 at the same time).
  - Move RFC 3688 to the non-normative references section.

Section 6.3:
  - Please replace "consent-status" in the section heading
    with "xcon-conference-info-diff".