XCON Day 1 11/8/04 1930 Lincoln East Eric Burger, Scribe Chairs ====== Will WGLC Conference Scenarios Framework Document: First Draft Media Policy underway Conference Policy WGLC closed; ready for IESG Notification Event Package: not started yet Floor Control WGLC closed; ready for IESG CCCP document Need call flows Sidebars will end up incorporated in various documents Conferencing Framework Document (Mary Barnes) ============================================= Should it reference SDP-NEW? Cullen: Confused SDPng with SDP-NEW (RFC2327bis). Recognized the error of his ways. SDP-NEW is OK. Would it be helpful to talk about the insides of the bridge (physical implementations)? Maybe. Referencing Data Model Slide: Roni: Is this the real data model? Having trouble understanding whether data lives in Focus, Conference Policy, or Conference State elements. Clients only see view from Focus. Thought is that only conference-aware participants care about distributed data elements, and they are aware of the different data elements, thus it might work as is. More discussion when we get to CCCP (or, "Back to the USSR"). Hisham: Are we defining red data interfaces (on Basic Data model slide)? A: No. Only shown on slide to show relationships. Will not be doing protocols for exchange here. JDR: Does this deprecate SIPPING Conferencing Framework? A: Not intent JDR: But this does everything the SIPPING Conferencing Framework document does, including the stuff taken out to defer to XCON. Compares the concept to ICE: when we say X, which is Y in SIP. However, cannot see difference between SIPPING and XCON Conferencing Framework. Even the titles are confusing. Rohan: no problem having two WGs doing similar documents; different communities of interest Keith: not waiting on this document in 3GPP Mary: Goal is to have document that developers don't need to read SIPPING document JDR: vehemently disagrees Keith: sees split in the other direction: SIPPING document should reference XCON document Keith: charter isn't all conferencing; framework is only to develop those protocols that are necessary Orit: framework does not define protocols; SIPPING Conference Framework works for SIPPING conferencing framework Chairs: Do we need an XCON Framework Document? Consensus is we do. Resistance left room, so everything is OK :) Conferencing Data Model (Orit Levin) ==================================== Entertaining animations of data flow :) Separating Policy from Actions Markus, Hisham, Aki, Henning: looks like good separation; better model: more control, better semantics Henning: 2 problems to address: description of a conference (may be partially filled-in) and templates; thinks of it as a master document that gets modified JDR: State gets manipulated via SIP, et al. However, Policy can also manipulate state. Moreover, changing Policy can trigger changes in state. JDR: Policy is something independent of State. E.g., Membership is state: if you apply Membership to a new clone, members are not members. E.g., Dial-out list is Policy; if you apply list to a new clone, need to dial-out. "Only Henning completely understands what he means by Policy" -- Orit Aki: likes to use terminology from virtual machines & operating systems. Adam says, "Send text to Orit." Things like Booting a member from a conference becomes easier. Right now, all we get is "Boot Member"; Cullen points out that could be "Boot Temporarily", "Boot from this conference", "Boot from all conferences", "Keep out forever". Current documents don't help here. This is a good approach. Henning: Concepts are good, but need better words to describe them. Chairs Discussion on Framework Changes ====================================== 1. Conference Policy has Two Parts: Split (Templates & Rules? Whatever we want to call them) Cullen: are we talking something new, or just "getting our act together"? JDR: This is the kind of stuff we need in framework document. How to carve up policy in a sane way. What gets modified by CPCP, mumble, and fratz. That belongs there. Orit: Chair slide looks a bit misleading (Change #1); concepts good. Hisham: Not really splitting Policy, but splitting stuff inside into two groups. A: Correct; just working on terminology. A: Do we agree on terminology? No real consensus yes or no. Cullen: Does this mean we would have to change all the existing documents? A: Yes Henning can take the terminology to the list. Aki, too. 2. Media isn't a separate thing from State and Policy. Conference Policy is not separate from Media Policy. Weak consensus taken 3. Conference State Manipulated Directly, not via Policy JDR: We should figure out what we want to accomplish before working on the solution. Markus: OK, so it is all document manipulation. Are we doing anything worthwhile, or are we just creating yet another way of doing state manipulation? A: Some semantics associated with states. Hisham & JDR: Need use cases. E.g., how do I get Focus to INVITE me, instead of me INVITING the conference? Take out "by manipulating Conference Package stuff" from proposal JDR: don't want to confuse commands with document editing. E.g., "Kick everyone out" is when executed. Document editing (kick out current participants) enables new participants to join, still. Orit: agrees Aki: Really want protocol with explicit actions. Henning: Need to be able to monitor entire state of conference. Every command has to make a visible change into the conference state representation. Consensus to go into this direction. Conference Policy (Hisham Khartabil) ==================================== Postponed because out of time.