XCON, Thursday, March 10 BFCP (Gonzalo Camarillo) Additions to -03: - Grouped attributes => dramatic simplification of messages - Hashing algorithms negotiation: allows alternatives to SHA-1 - UserInfoWanted and UserInfo primitives: provides access to user information independent of floor information - Extensibility, per discussion with area directors - Editorial fixes Plea for review; only one person has made a thorough review thus far. Objection from the floor to need for standards track RFC any time we want to add primitives or attributes. Too action to amend. Open issues: - Server authentication in peer-to-peer scenarios: - Example: whiteboarding with one of the peers acting as a floor control server - But peers will not typically have server certificates - Possibility: employ Diffie-Hellman, shared secrets and DIGEST - The above led to a discussion of how this would work for cascaded conferences. Adam and Roni both suggested that this wouldn't cause additional problems IF cascading was based on the traditional master-slave model, where all cascaded MCUs are slaves to a single master MCU. FLOOR CONTROL SIP EVENT PACKAGE (Gonzalo Camarillo) draft-ekim-sipping-conf-floor-package-01.txt - BFCP allows requesting floors chair operations getting floor status info - Proposal: Use SUBSCRIBE/NOTIFY to get floor status info and ... ! - Use cases - #1: UAs don't use BFCP; they're just listening. - #2: BFCP provides a simple mechanism to be informed about the status of the floor. Up to the server to generate notifications and which information to include. The event package would make it possible to use throttles, partial notifications, filters, etc. Subsequent discussion indicated a lack of appreciation for use case #1. If it the UAs aren't using BFCP, what's the point of addressing them in a floor control event package? Henning offered a counter-example: Monitoring applications (that just listen). But what does that have to do with FLOOR CONTROL? Adam then objected to use case #2: First, he doesn't see SIP events as a viable mechanism for bandwidth management. Second, I think he posited that the comparative paucity and brevity of floor control events would be interpreted by the system as a dead connection ... but I didn't get it. ;-) XCON DATA MODELING - NETCONF, RDF, ET AL. (Henning Schulzrinne) Motivation: Avoid reinventing yet more things. Excusable a decade ago; recipe for delay (or failure) now. Goals: - Provide both "semantic" and ... - Use XForms where user interface is needed - Consider NETCONF for object content manipulation & state retrieval Possible models: - Document model: structured docs - RPC model: set/get variables - Data modesl: RDF, NETCONF, user-interface oriented "Semantic" considerations: - Tightly described set of properties - No expectation that the UI would directly correspond to each element. - No internationalization issues - Several possible options follow ... RDF (Resource Description Framework): - W3C - Describes resources in terms of property-value pairs - Used in RSS as well as CC/PP - See slides for good/bad eval! NETCONF: - draft-ietf-netconf-prot-05.txt - Can run over anything - Four layers: content, operations, RPC, application protocol - Data = writable configuration data readable state data - Leaves privacy and authentication to transport layer - Supports Xpath and subtree filtering - Supports multiple "data stores" - Simple set of primitives: get, get-config, edit-conf, copy-config, delete-config, lock, unlock, close-session, kill - Can advertise capabilities - Allows incremental configuration + commit Floor discussion: Unidentified speaker: NETCONF doesn't accommodate user data. Henning: not true; see the latest draft. Alan: NETCONF chairs see no issues. NETCONF co-chair present in the room: True, even though NETCONF was NOT expressly designed for applications other than management apps. Cullen: Does it allow simultaneous access by multiple clients? Henning: Don't know. User interface-oriented considerations: - Describe suggested rendering on controlling clients without the client knowing meaning of controls - Element names are just labels - E.g. - ... ... - Clients do not need to understand meaning of terms, just variables and prompts. - Existing work: XForms - Allows use of CSS to render on variety of devices - Allows use of JavaScript for client-side verification - ... - Provides what we need! No time for further discussion, other than: Eric: What are we going to do with all this information? Adam: Use it in the context of determining the state manipulation protocols. CCCP (Orit Levin) draft-levin-xcon-cccp-02.txt - Nice slide showing mapping to NETCONF. Primary difference is at the "operations level": NETCONF supports only get-config and edit-config. Henning: Again, this difference is nearly irrelevant. All the CCCP primitives could be represented "one layer down" in the NETCONF model. Example of different approaches to defining primitives: Mute a particular media stream 1. muteVoice (conf-id, user-id, media-id) 2. modifyMediaStatus (conf-id, user-id, media-id, media-status) 3. modifyMedia (conf, user, media-id, media-info) 4. setXLMNode (XPATH, value) Example of template handling: 1. Use data manipulation primitives: setXLMNode (XPATH, value) 2. Define "form" conventions: setTemplate (template-id, field-category, field-id, field-value) There was an ensuing floor discussion that I failed to capture. CSCP (Cullen Jennings) draft-jennings-xcon-cscp-00.txt - Premises: - There is a bunch of state that has to do with how things get mixed. - This is different for different conferencing systems. - We need a common way to change it. - New systems will define new state, and old clients need to be able to manipulate that state too. No disagreement with the above from the floor. - Needed semantics: - read/write/add/elete - add/delete require some understanding of what the objects are - read/write will have better GUI if one understands, but usable with no understanding - NOT needed: transactions - 2-phase commits are hard - the "pipeline" approach significantly speeds up bulk changes without adding much complexity - Why leverage BFCP? - < 100ms round-trip response - Small footprint - Small messages - We already have it - Manipulating conference state is VERY similar to manipulating a floor. If we don't think what BFCP does is good for conference state, then we should reconsider it for manipulating floors! Henning somehow segued into a suggestion we might use SNMPv3. Rohan objected on the grounds that (a) SNMPv3 is quite difficult to implement and (b) the choice of SNMPv3 for midcom is a key reason that group's efforts have not been realized. Cullen countered that we were to use SNMP, nothing but v3 would be acceptable, due to its security enhancements. MEDIA CONFERENCE SERVER CONTROL (Cullen Jennings) draft-jennings-xcon-media-control-02.txt Note well (!): This is more generally referred to as the "template draft". It is completely orthogonal to CCCP or CSCP. It was acknowledge as badly titled. Significant changes from -01, due to new conference framework, etc. Core elements: - physical streams - controls - roles, each of which defines controls and streams available to it - logical streams, corresponding to streams that the mixer produces - floors - control arrays -- when you want one instance of a control for every stream in the conference - layout control for media layout, typically video There followed an extended example of how some simple templates could be constructed and a conference object instantiated. FRAMEWORK, PART II (Mary Barnes) Open issues: - Need to align Section 6.4 with BFCP. - Complete detail in Section 7, including sidebars, private messages, etc.; additional scenarios/flows to highlight how the XCON elements work together - Add some full physical realization examples Plan: Submit doc as WG document, plan at least one review cycle prior to Paris. Many items identified as requiring further specification IN OTHER DOCUMENTS Floor discussion: Unidentified speaker: Too many protocols. Would prefer just one. Meeting ended abruptly, having run out of time.