Minutes of the DISPATCH WG Session at IETF 76 ============================================= Meeting chaired by: Mary Barnes and Gonzalo Camarillo Minutes produced by Gonzalo Camarillo based on detailed notes by John Elwell and James McEachern. In addition to the minutes of the main DISPATCH session, the minutes of the DISPATCH Adhoc meetings on identity, domain registrations in SIP, and SIP-XMPP minutes are included below. Jabber: http://jabber.ietf.org/logs/dispatch/ Slides presented included in the proceedings. Main DISPTACH session: Tuesday, November 10th, 2009 ============================ Topic: Agenda Bash Discussions led by: Chairs Audio: http://www.softarmor.com/dispatch/IETF76/audio/agenda.mp3 The chairs presented the current status of the WG. Topic: Session Recording Discussion led by: Andrew Hutton and Leon Portman Relevant documents: draft-rehor-dispatch-session-recording-req-00.txt Audio: http://www.softarmor.com/dispatch/IETF76/audio/session-recording.mp3 The slides were presented. Privacy concerns need to be addressed explicitly since they are very important in this area. The chairs took a hum: should we form a working group for session recording? Consensus that we should form WG. No hums against. The presenters were asked to revise the charter in accordance with comments soon after meeting. Topic: Disaggregrated Media Discussion led by: Salvatore Loreto Relevant documents: draft-loreto-dispatch-disaggregated-media-00.txt Audio: http://www.softarmor.com/dispatch/IETF76/audio/disaggregated-media.mp3 The slides were presented. This is a considerable amount of work but there were enough people willing to work on it. Two people in the room, more people on the mailing list, and Simon Pietros' team are committed to put considerable efforts on this. The chairs took a hum: is there interest in chartering a WG for Disagregated Media, subject to getting enough interest on the mailing list. Result: Solid support for chartering. Topic: Alert Info URNs Discussion led by: Laura Liess Relevant documents: draft-liess-dispatch-alert-info-urns-00.txt Audio: http://www.softarmor.com/dispatch/IETF76/audio/alert-info.mp3 It is not clear if the decision about whether or not to use semantic URNs needs to be made before or after chartering this work. The chairs took a hum: Assuming that we resolve the issue of semantic representation on the list, is there interest in chartering a WG on Alert Info URNs. Result: Solid consensus. Interest in writing drafts= 6 people Interest in participating and reviewing = 10 to 15 people Topic: Reason in responses Discussion led by: Roland Jesske Relevant documents: draft-jesske-dispatch-reason-in-responses-00.txt Audio: http://www.softarmor.com/dispatch/IETF76/audio/reason.mp3 It was not clear why using encapsulation or translation are not considered in the solution space. More discussions needed on the list. Ad-hoc Meeting on Identity: Monday, November 9th, 2009 ========================== Topic: SIP Identity Discussion led by: John Elwell Relevant documents: draft-elwell-dispatch-identity-reqs-01.txt John Elwell presented the slides, which summarized the history of this activity and where we are at present, and then asked the question where should we go from here. There were different views as to how well the requirements draft captures the requirements, and in particular whether it should or should not refer explicitly to B2BUAs and their functions. The moving target nature of trying to cater for B2BUA behavior was also a concern. Also there was an opinion that the a solution might be embedded within the requirements. There was consensus that we have a problem. There was also consensus that we should not try to map solutions onto requirements until we have better agreement on the requirements. Several people indicated willingness to be involved in the ongoing discussion. John will work with those concerned to refine the requirements. Ad-hoc Meeting on Domain Registrations in SIP (DREGS) Thursday, November 12th, 2009 ============================= Meeting chaired by Mary Barnes and Eric Burger Minutes edited by: Spencer Dawkins Notes from: Jim McEachern and Shida Schubert John Elwell presented a proposed charter (slides at http://www.ietf.org/proceedings/09nov/slides/dispatch-6.ppt) Jon Peterson reacted to John's statement that "decided we needed a new WG" and said that he had suggested this work might be DISPATCHed to DRINKS. Was concerned about the presumption of what needs to be done to address the open issue. Mary explained that AD insisted that it is to be discussed in DISPATCH. Cullen: the purpose of DISPATCH is to recommend what should be done. So we could recommend it go to DRINKS or wherever. Let's see what we recommend. The proposal was that this should be looked at, not that a WG was needed. The purpose of DREGS was to standardize a uniform way for PBXs to dynamically register a domain. Today everyone does it their own way, and they are all very similar, but they aren't the same. DREGS is proposing to use REGISTER with an added option tag and header field to request domain registration. John is proposing this approach because it builds on what is already widely deployed. Eric Burger explained why REGISTER is proposed here. Alan Johnston explained that if some other mechanism is used then this will break a lot of the deployments. Adam Roach: Are we really proposing to write the use of REGISTER in the charter? Answer: Yes. Ben Campbell also questioned the inclusion of REGISTER in the charter. Adam stated that he was not prepared to have that discussion today because he thought it would be discussed in the WG. This feels like "let's ratify this draft" rather than "let's work on this problem". Spencer Dawkins: the intent is not to ratify existing draft. Eric: the subject of whether or not REGISTER should be included in the charter has been discussed on the list, but there is not consensus Jon: don't think REGISTER is the right approach, want to see a discussion of why we don't use PUBLISH, for example. Someone stated that REGISTER was proposed because "that is what is implemented" and we need to align with those implementations to be relevant. Jon Peterson countered that earlier it had been stated that the entire reason for this is that there are multiple ways this is implemented and that we need a standard to get interoperability. So if it is being done multiple ways today, the argument that REGISTER needs to be in the charter to align with deployed equipment, simply does not fly. Cable Labs supported the use of REGISTER because that is what they use in their specifications, and they believe it will best align with IMS networks. Jim McEachern & Adam Roach both pointed out that even if you remove the word REGISTER from the charter that does not mean that the eventual solution will not have REGISTER. The bulk of the objections are because the solution (REGISTER) is being specified in the charter, when the charter should be simply defining the problem we are trying to solve. Anwar? Asked about the definition of small - medium businesses with SIP-PBXes that would use this mechanism. John answered that DREGS was targeting SIP-PBXes with up to a few hundred endpoints. Eric argued that a larger enterprise would use RFC3263 and that DREGS is indeed for small to medium company. This is for cookie-cutter installations. Markus Isomaki, Nokia: What does this imply about the addresses of the terminals behind the PBX? John Elwell/Eric Burger: UA registers with the PBX, but that's local policy. DREGS deals with the PBX registering with the SP. It is designed to help the SP work out where to send requests to "example.com". Jon Peterson: Charter scope question. We had a larger discussion about option tags - this is suggesting one alternative. Is the Is the charter focused on the specific problem on the slide, or the more general problem? Answer: The more general one. No feedback at all on charter text received after posting to the mailing list. Jon Peterson: The only way this charter will get approved is by taking REGISTER out of the draft. Lots of nods to that. Spencer: If this looks like tweaking existing implementations, it will get more interest from implementers than if it looks like support for a new method. Preference is to be up front about this. Jon re-emphasized that all he is asking is to remove the text on use of REGISTER from the charter which doesn't preclude the use of REGISTER as a solution. Spencer shows concern that leaving out the text on REGISTER or not deciding the technology used today will delay the overall process and potentially make the work irrelevant. The concern is that we'll still be talking about whether to use REGISTER in six months. Cullen: when are we going to have the conversation with the people who are objecting, many of whom are not here? Cullen (channeling Hadriel): If Hadriel were here he would insist it must be REGISTER or it will never be deployed. Cullen: would the possible solution space now include dynamic DNS? "For carriers that are incapable..." Cullen expects that we would remove "without DNS" from the charter. Eric re-emphasized that if some other approach is taken no one will accept the IETF solution. John Elwell said that if non REGISTER approach is adopted it will not be implemented and deployed. Chris Stanley: CableLabs needs to deploy this for businesses and needs to move quickly. (And REGISTER is the mechanism we use.) Spencer explains that it may not be the right mechanism but it's what's going to be used in the field with more likelihood. Adam Roach: how far are we going to go down this path of specifying the answer in the charter? If we allow it for REGISTER for this WG, what other things are we going to do it for? Alan Johnston wanted to have the discussion on the use of REGISTER. What we do must be deployable and not just a theoretical exercise. Jim explained that some of what's being debated here, such as "the solution needs to be something that will be deployed" can be included in the charter. Cullen as AD: He was the one who earlier encouraged them to be very specific to see if they could get consensus on the approach to shorten the process, even though he suspected the proposal would get the reaction that it is currently getting. However, if the group cannot get consensus to specify the solution in the charter, then the only approach is to remove it. This is clearly the case. Hum: Should we leave the charter exactly as it is? Result: Moderate hum "yes" Hum: Should we leave the charter largely as is, but remove the solution (REGISTER) from the charter. Result: Strong hum "yes". We discussed a hum on "Is there a critical mass in the IETF to work on this problem?", but instead decided to reverse the wording after the following exchange: Eric asserted that IETF and SIPForum participants are the same, and indeed critical mass is in the room. Robert disagrees that many of the SIPForum participants aren't here and that doesn't understand the culture of IETF. Hum: Does anyone think that we don't have the critical mass and the expertise to tackle this. Result: no one objected. So consensus in the room for this. Hum: is the IETF the place to work on this? Answer: yes Meeting officially closed. Note: The following happened after the meeting had officially closed, but is included here because it pointed toward a possible way forward. Since we had time, we had an open discussion of how to make progress... Discussion of what would be realistic dates for this? Jim thinks may be to have a charter by January is the likely outcome. John expresses that SIPForum needs a realistic date. SIP Forum participants were expecting a commitment for quick turnaround. Bernard thinks realistic schedule is 12-18 months for an RFC. Jim suggests March for WG or charter to be formed/finalized and June for the deliverable to be sent to the IESG. Cullen Jennings: Recognize that we do need to find ways to work faster. "If you send me a charter by midnight tonight, I will have it on the agenda for the next IESG meeting" Robert Sparks: Recipe for success in SDOs cooperating is having a significant overlap of common participants working on the problem. He is concerned that the overlap is not enough. Spencer Dawkins: Last SIP Forum meeting had 12 people and 7 of them were also IETF people. Is that enough? Robert Sparks: Nope, not enough. Jon Peterson: Concerned about the precedent-setting risks of just adopting an existing solution. Why not adopt proxy BYE? It's widely deployed, too. Unifying the nasty market might be helpful. Think of this as a telephone number problem, rather than a domain problem. If the only thing the SIP Forum cares about is telephone numbers, that's much easier to solve. Telling a domain to act like another domain will make IESG member heads explode. Alan Johnston: The entire SIP Forum discussion is in fact about telephone numbers, so restricting it to telephone numbers would be acceptable. Ad-hoc Meeting on SIP-XMPP Friday, November 13th, 2009 =========================== Meeting chaired by: Gonzalo Camarillo and Simo Veikkolainen Minutes produced by Simo Veikkolainen based on detailed notes by Spencer Dawkins and Shida Schubert. Topic: Agenda Bashing Jon Peterson requested to present slides on voice-presence interaction. It was agreed to take the presentation as the last agenda item. Topic: SIP-XMPP Combined Use Motivation and Use Cases Markus Isomäki presented the slides covering the motivation, assumed architecture, use cases and requirements. Adam Roach and Roni Even expressed their concern that the requirements already address the solution. The requirements should state that the initial use cases only need support in the endpoints, so that deployment would not require upgrades in the existing SIP or XMPP servers. Robert Sparks commented that it should also be clearly stated that interworking between SIP-only endpoint and XMPP-only endpoint is out of scope. Emil Ivov would like to see some text on how to handle overlapping information (e.g. presence). B2BUA concerns were also discussed. It was noted that we cannot prevent B2BUA's from modifying/stripping any header they like, but at least we should avoid relying on those headers which B2BUA's are known to modify (like Call-ID). Topic: Technical overview on SIP-XMPP co-existence Simo Veikkolainen presented the slides covering the technical approach to SIP-XMPP co-existence as described in drat-veikkolainen-sip-voip-xmpp-im. The goal is to offer the user a seamless user experience as if only one protocol is used, even though actually two protocols are used to provide the voice and IM/presence components. About seven people had read the draft (out of the 20 or so in the room). Main topics in the discussion that followed were: - we need to check that the proposed solution does not break anything in the way SIP and XMPP are used today (for example, SIP supplementary services), - we need GRUU and JID Resource to be able to point to a specific user agent/endpoint instance. The Resource in particular can be dynamic in nature, which needs to be taken into account. - the effects of B2BUAs was also discussed. Adam Roach proposed that the correlation related information could be carried in the SDP, which would be safer from B2BUA point of view. - scoping: Robert Sparks reconfirmed that the scope is only about integrated endpoint, and that SIP-XMPP interworking is out of scope. A hum was taken to see whether the IETF should be working on the problem space, and there was full consensus for doing so. There was also strong consensus with little opposition to take the proposed charter text as a starting point. It was agreed to modify the charter to clearly state that the focus is only on the integrated endpoint. When asked who are willing to contribute to the work, about five people expressed their interest. Charter will be scoped/revised according to the debate and will be sent for AD for further treatment. Topic: Presence-based session advertisement Jon Peterson and Cullen Jennings presented their proposal on using presence to advertise session information. The goal is to replace SDP Offer-Answer with a different model - advertisement and proposal. Technical topics that were brought up during the discussion included: - how are connectivity checks used, - advertising codec support, - support of early media. After a lively discussion, the AD encouraged the authors to submit a new version of the draft if they want to continue the discussion.