1 / 11

Realtime Conference Control Protocol Discussion at IETF 64

Join the discussion on selecting a protocol for conference control at IETF 64 in Vancouver, BC. Review proposed specifications and milestones for future protocol development.

hollisj
Download Presentation

Realtime Conference Control Protocol Discussion at IETF 64

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. XCON IETF 64 November 8th – 9th, 2005 Vancouver, BC, Canada

  2. Note Well • Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an “IETF Contribution”. Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: • the IETF plenary session, • any IETF working group or portion thereof, • the IESG, or any member thereof on behalf of the IESG, • the IAB or any member thereof on behalf of the IAB, • any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, • the RFC Editor or the Internet-Drafts function • All IETF Contributions are subject to the rules of RFC 3978 and RFC 3979. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. • Please consult RFC 3978 for details.

  3. Administrative Tasks • Minute Taker? • XMPP Scribe? • Blue Sheets • New Area by IETF 65: Realtime Applications and Infrastructure (RAI) • Ad-hoc mode: even if you know what you’re doing, check your settings. If you don’t know what you’re doing, remove your wireless card.

  4. Agenda: Tuesday

  5. Agenda: Wednesday

  6. Status • Floor Control Requirements in RFC Editor’s Queue • Conferencing Scenarios in RFC Editor’s Queue • BFCP has gone through IESG review; sent back with some security comments • Framework document has gone through substantial detailed review from dedicated reviewers

  7. Status (Continued) • Still need to nalize framework and data model • Need to complete work around media manipulation (including quite probably media sent to a subset of participants) • Must identify (and maybe dene) protocol for conference state manipulation

  8. Charter Discussion • Milestones need resetting • Original plans included different protocols for media control and membership control • Current thinking seems to be that protocols for performing such manipulations should, in fact, be a single protocol

  9. Proposed Charter Milestones • Jul 06 – Submit Framework and Data Model for publication as PS • Aug 06 – Submit Event Notication Package for publication as PS • Oct 06 – Submit Common Conference Information Denition for publication as PS • Nov 06 – Submit Conference Template Denition for publication as PS • Dec 06 – Submit Conference Control Protocol for publication as PS • Any IM-related work can begin discussion after Conference Control Protocol is in the IESG’s hands (e.g. MSRP conferencing BCP)

  10. XCON: Session 2 IETF 64 November 9th, 2005 Vancouver, BC, Canada

  11. Protocol Selection: Don’t Make Me Stop This Car • CCCP, CPCP, and CSCP have actual proposed specications • Several other ideas have been oated informally, but no one has invested cycles in documenting them in a draft • Some are very general; e.g. proposals to “use SOAP” is about as well-specified as saying “use IP”. • We need to decide on a way forward. • Anyone with a proposal that has not been documented in a draft needs to either produce a draft or stop making proposals. Deadline is December 31st. • Between now and December 31st, interested parties should discuss criteria for evaluating protocols on the mailing list. • We will be taking volunteers to author a document to formally evaluate the proposals against the criteria and make a recommendation before March. • Goal is to have protocol specication in IESG’s hands by end of 2006.

More Related