FRIDAY, November 12, 2004, 0900-1130

0900 - 0940 Floor Control - Gonzalo Camarillo (40 minutes)
draft-ietf-xcon-bfcp-02.txt

    * Need to review and make sure section 3 is consistent with the conferencing framework - Alan will, others are welcome to comment
    * Open issues
          o How to perform authentication - Digest and TLS - what's mandatory? If you do basic, this is MUST use TLS, not may. Adding nonce to SDP is only to save one RTT. This affects IANA and security considerations. Current text is servers MUST implement TLS, clients SHOULD (or something equivalent). This should make the security types happy. Wouldn't the signaling protocol mechanisms suffice? What's the difference between authentication and conference admission? Can't use a shared secret for both, so need two mechanisms.
          o Clients initiate transactions, with no timeouts defined now. Define an application-level error recovery mechanism? Need to make sure we don't cause problems when trying to do more than TCP does - we won't define these mechanisms
          o Clients with several ongoing floor requests at once? We get this for free in the protocol, servers can reject them now if desired. What about requests based on media types?
    * To be done -IANA considerations, security considerations, SDP format for BFCP (in MMUSIC)
    * Need volunteers to review this draft - actually, the next version of the draft
          o Ben Cambell, Dave Morgan, Bob Hughes, Christer, ? 
    * What about multiple floors with one media stream (sidebars, etc).

draft-ekim-spping-conf-floor-package-00

    * From SIPPING, needs to be discussed here.
          o Requirement for "richer information than BFCP" - we need to see use cases
          o Support UAs that don't implement BFCP - will all floor control protocols allow requests for information?
          o Information about the status of a floor - up to the server to decide when to send notifications, decide what information to include, etc. - event package would allow throttling if needed

    * Are these reasons compelling?
          o We just need to see use cases before barreling off.
          o Two mechanisms doesn't simplify things, because you have to implement both
          o Throttling is important - can we do this with floor control policy? Out of band?
          o I already have a SIP UA and know how to do SUBSCRIBE/NOTIFY - this draft adds like, one XML body for these UAs
          o Could probably implement a reference implementation today that meets these requirements using BFCP
    * Conclusion - we just need to see use cases, and will discuss in XCON, not SIPPING
    * We may end up with a parallel SIP-based mechanism anyway - TLS is not a SHOULD for SIP clients, but is for BFCP, and that's a big deal

0940 - 1040 Media Policy - Alan Johnston (60 minutes)
draft-jennings-xcon-media-control-01.txt
draft-boulton-xcon-media-template-00.txt
draft-rosen-xcon-conf-sidebars-01.txt

    * Core draft has not been updated
    * Design team has been working on templates, not yet complete (4 of 10 are started)
    * Want to disband design team and continue discussion on the list
    * Need a good framework and terminology
    * Have a preliminary division of work, but won't make decisions until we look at framework and decide on terminology
    * XCON will likely have an Interim Meeting in January (watch the list for info on this, expect East Coast, 1.5 or 2 days)
          o Don't have AD approval to do a lot of work in an ad hoc and have work go forward without list discussion - process point
          o Not a proposal yet (either the design team proposal or the interim meeting proposal!)
          o Please discuss this on the list, that's the way we do things on the list
          o Allison would prefer that we work out document structure before working on terminology
          o Need a heads-up on the list that this is coming, people are commenting on the current drafts and we're thinking about big changes
          o This doesn't look like huge changes to the existing charter - no change at all, we're changing how we do the work
    * 3GPP is expecting floor control out of us
          o Could we get an e-mail on the list about exactly what they expect from us?
          o Floor control is at least one of the deliverables they need from us
          o Probably send to IESG after volunteer review
          o 3GPP likely to give us a list of document names, we need a list of document contents!
          o We also need to finalize conference event package - not in this working group - what does floor control without an event package mean? At least the event package is in WGLC in SIPPING now, so this should be OK.
          o Can we formulate conference rules quickly and not wait for terminology?
          o 3GPP also needs templates, etc.
          o We'll get clarifications and post them as quickly as possible
          o 3GPP will eventually need everything in the XCON charter, but probably don't need it all now - if we do this in usable stages, that should be good enough for them. Probably can't wait for everything to finish in order to finalize the rules.
          o We've had good experience with 3GPP use of our technology so far, and what they're asking for isn't unreasonable
          o Allison thinks they can give us functionalities again, since we're restructuring all our drafts. Keith and Stephen should be able to discuss this with us. We can have a teleconference (if you want to participate, please contact us and let us know).
          o Believe 3GPP will be flexible - give them the basics, chat and messaging applications would matter. Basic rules would be enough.