Minutes SIPPING WG at IETF 66 Minutes edited by Gonzalo Camarillo and Mary Barnes Based on notes by Spencer Dawkins and Dean Willis Meeting chaired by Mary Barnes and Gonzalo Camarillo Slides presented included in the proceedings First Session TUESDAY, July 11, 2006, 0900-1130 Topic: Agenda Bash Discussions led by: Chairs The chairs presented the current status of the WG. The chairs noted that as soon as some of the current WG items are finished there will be a charter update to add a few new milestones the WG agreed to work on in the past, namely the Session Border Controllers requirements work, the race condition examples, the overload requirements, offer/answer examples, and IPv6 torture tests. There was a brief discussion of the new process for tracking document reviews, WGLCs, etc at the end of the session. It was suggested that a reminder or warning of deadlines would be useful (i.e., in the body of an email, rather than requiring folks open the spreadsheet). It was also suggested that the WG consider an issue tracker. Topic: Configuration Framework Discussion led by: Dan Petrie Relevant documents: draft-ietf-sipping-config-framework-08.txt draft-ietf-sipping-xcap-config-00.txt Primary issue from IETF-65 had been around support for optionality of XCAP. Issue around HTTP header is okay, per offline discussions. This will need to be documented in IANA section. The concern about the use of 489 was discussed, as the proposed use does not seem consistent with the usual usage. It was suggested that perhaps 2 different event packages should be defined. Others proposed the definition of a new error response code is needed. This introduces a somewhat new problem in terms of negotiating the fields in an event package. On the issue of multicast discovery as proposed on the list, there was general agreement that resolution of this issue could be deferred. On the issue of the SHOULDs versus MUSTs for network-user and SUBSCRIBE text, it was agreed to make those MUSTS. This was accomponied along with a general discussion that SHOULDs are not good for interop with a suggestion that SHOULDs can be written as two MUSTS instead. On the issue of whether a new mechanism is need to confirm if the new profile is received, it was suggested that this could be deferred to later. Poll: Would anybody feel unhappy about just fixing the 489 and the MUST/SHOULD question as noted earlier, then proceeding with WGLC? There seems to be a consensus on this approach. Conclusion: Dan will update the doc ASAP and make it available for WGLC. Volunteers will be recruited. Topic: Consent Framework Discussion led by: Gonzalo Camarillo Relevant documents: draft-ietf-sipping-consent-framework-05.txt draft-camarillo-sipping-consent-format-01.txt draft-camarillo-sipping-pending-additions-00.txt Gonzalo summarized the changes: removing the complex REFER by restricting to one URI at a time, adding optional event package for permissions and now using MESSAGE instead of CONSENT request with two parts - XML and human-readable. The framework is simpler than last time and the call flow is much simpler. Gonzalo also clarified that the use of MESSAGE, which had been restricted to usages which are rendered to an end user, is commented in the draft. It was highlighted that this use of MESSAGE has two parts: one human-readable, other is permission document that automata could process. Open issues and proposed solutions were discussed including "Pending additions" URI, use of 409 and whether a Permission Server is needed. There was some concern that the document in the body of the 409 is an extension of the SIMPLE framework that's already been defined. However, it was agreed that the issue did not require discussion in the SIMPLE WG. Poll: How many read the draft? A fairly large number. Poll: Do these changes make the document simple enough to deal with? Seem to have strong consensus that the current level of simplification is adequate. Open issue: From which WG do we advance this? By RFC 3427, the framework probably goes through SIP, with the other 2 documents going through SIPPING. Conclusion: SIPPING chairs will talk to ADs and SIP chairs. Topic: Session Policies Discussion led by: Volker Hilt Relevant documents: draft-ietf-sipping-session-policy-framework-01.txt Volker reviewed the changes since last meeting, including mandating support for the media policy dataset. The only open issue discussed was whether to use body of SUBSCRIBE or something else (e.g., PUBLISH). There was some discussion that this leads us down a slipper slope. However, this change was made based on consensus during the last meeting. Since all open issues are believed to be closed. Additional WG review is requested. Poll: How many people have read this document? Only 4 or 5. Can't really take a vote with so few folks having read the document. Conclusions: - Chairs will request reviewers to assess whether the document is ready to progress. Also, will request that companion documents be reviewed to assure alignment and consistency. - It was noted that RFC 3427 appears to require this document advance through SIP, with this being confirmed by the AD(s). Changes to the following draft was also briefly reviewed: draft-ietf-sipping-policy-package-01.txt The only change to this draft was submitting as a SIPPING WG document: draft-ietf-sipping-media-policy-dataset-01.txt Topic: Multiple Dialog Usages in SIP Discussion led by: Robert Sparks Relevant documents: draft-ietf-sipping-dialogusage-02.txt Robert highlighted that this document is getting significant comment on the list and is pretty much done. One open issue on the reliable 183 was discussed. In the end, it was suggested to remove that issue out of this draft and resolve in SIP. However, the importance of documenting all the issues was highlighted to ensure that they are eventually addressed in SIP. Conclusion (for SIPPING): this document should be complete after the next revision. Chairs will assign reviewers and announce WGLC once updated doc is available. Next step (for SIP): build a list of normative changes needed, and work on executing them. Proposal that this be a single document (or whatever process SIP comes up with). Topic: Potential Future BoF on Call Usage in SIP Discussion led by: Martin Dolly Martin highlighted that the goal of the proposed BoF/WG is to ensure service interoperability across heterogenous networks. Changes to core SIP would go to SIP/SIPPING, "Core SIP" based on the Hitchhiker's Guide. There was strong consensus that folks don't want this proposed group to have a license to publish P-headers. Martin thinks that the general direction would be towards BCPs, perhaps Event packages, P-headers only as a last resort. It was agreed that the latter two would progress through the SIPPING WG (i.e. this work would all be done in the context of the SIP Change process). Conclusion: A BoF is planned for San Diego for this topic, with the group name under discussion. It was highlighted that deadlines for BoFs have been moved forward a week or two to allow for better IESG/IAB interaction on BoFs. Second Session THURSDAY, July 13, 2006, 0900-1130, Room 520ABC At the start of the session, the chairs thanked all the folks that have volunteered as reviewers since Tuesday - that's great! Also, even folks that don't feel they can commit the time are encouraged to read and comment on the documents as their time allows. Topic: Communication Service Identifiers Discussion led by: Salvatore Loreto Relevant documents: draft-loreto-sipping-3gpp-ics-requirements-00.txt It was highlighted that this document reflects 3GPP requirements and that this is a good opportunity for the SIPPING WG to influence 3GPP. The objective of these requirements was to allow groupings of media to be visible to proxies, etc and it was highlighted that a particular media (or set of media) does not uniquely identify a service. Some of the discussion points involved the suggestion that multiple applications are multiple things and that RFC 3458 addresses this. Others felt that the current document does not adequately describe assumptions or architectures which are the basis of the requirements. The importance of doing this work in IETF was highlighted to ensure general applicability and more importantly interoperability. Poll: How many people feel that the they understood the requirements? Only 4 or 5 hands were raised. Conclusion: the document requires more use cases and examples. Topic: Early Media Authorization Discussion led by: Richard Ejzak Relevant documents: draft-ejzak-sipping-p-em-auth-01.txt Gonzalo highlighted that this discussion is centered on the expert review of a P-header that might or might not be changing fundamental behavior, as discussed on mailing list. Richard summarized the basic problem that some RFCs say early media can flow immediately on signaling SDP, others say it won't be rendered, thus there's conflicting views on handling early media. This particular document is focused on a narrow problem with a transitive trust model. However, concerns were raised that if the p-header is defined it will be used in cases that are inappropriate and that it might be interpreted to be a general solution to early media, which it is NOT. Others suggested that the problem should be fixed in base SIP, rather than defining a p-header. However, there was also WG members that felt that if the document is appropriately scoped, then it should be progressed, particularly given that no alternative proposal exists. Poll: How many would support progressing this document defining a p-header if it were appropriately scoped? (this is aside from the issue of whether the SIP/SIPPING WGs decide to address the more general problem) 30-40 folks supported this draft progressing. Fewer (around 8) were not comfortable with this p-header draft progressing. Conclusion: Chairs will discuss the very rough consensus with ADs to determine how to progress. Topic: Overload Requirements Discussion led by: Jonathan Rosenberg Relevant documents: draft-rosenberg-sipping-overload-reqs-01.txt draft-hilt-sipping-hopbyhop-overload-00.txt draft-malas-sipping-congestion-header-01.txt The requirements document has been updated based upon positive support for the work at the Dallas IETF. The requirements document is believed to be complete and the discussion focused on the solution design trying to scope the overall design space. Issues such interactions with QoS, routing problems, oscillation and simulation were discussed. The need for experts in other areas, such as TSVWG, to review and provide input to this work early on was emphasized. Two key points were raised about whether the traffic can be categorized as multicast and re-emphasizing the need to show the overload data to people that have the background for analyzing algorithms. It was highlighted that there has been simulation work in this domain submitted to other SDOs that might be applicable (although it does not address multicast). And finally, the importance of considering interactions with TCP mechanisms was emphasized. Conclusion: Solution documents should be combined. Chairs will assign reviewers for requirements document and add the doc to the WG charter once the WG completes other work and the AD approves. Topic: SIP Performance Metrics Discussion led by: Daryl Malas Relevant documents: draft-malas-performance-metrics-03.txt Daryl introduced the general problem in that there are no standard terms, metrics or methods for performance measurement in current SIP deployments. Thus, the industry is currently relying on PSTN metrics. This work does overlap with work in the Benchmarking WG in IETF, as well as other SDOs/consortiums, thus it is important to scope the role of the work within SIPPING. Discussion centered around the difficulty in agreeing a common set of metrics as the requirements of the communities of interest vary. It was suggested that defining requirements first might aid in ensuring appropriate metrics are defined. The BMWG chair highlighted that there are difficulties in scoping this work and that the scope itself is the biggest challenge. Poll: Hum vote on interest in working on measuring performance related issues? Conclusion: General working group support for continued work on this problem. Topic: Call Completion Service in TISPAN Discussion led by: Martin Huelsemann Relevant documents: draft-poetzl-sipping-call-completion-00.txt Martin introduced the basic ETSI-TISPAN CCBS ("busy subscriber") and CCNR ("no reply") services, with these call completion calls being queued and having higher priority than normal calls. The objective is for the solution to be based on existing SIP means, yet still provide interoperability with PSTN based call completion solutions. Some concern was raised over the use of SUBSCRIBE/NOTIFY for the proposed solution. It was highlighted that the solution is not so much a FIFO based queue, but rather the call completion calls are reordered based on an unknown/undefined algorithm. It was suggested that this problem could be more generic and that a solution might also be applicable to call/contact center applications. Conclusion: The document needs updating based on WG feedback to include more explanatory/background text and signalling flow. Additional comments should be sent to the authors and the SIPPING WG mailing list. Ad-hoc Meeting on Peer-to-peer SIP FRIDAY, July 14, 2006, 1230-1500, Room 519A Topic: Agenda Bash Discussions led by: Chairs The chairs highlighted that this was an official SIPPING WG adhoc meeting, thus the Note Well statement does apply. The objective of the session is to get agreement on the basic concepts and terminology and ensure that the problem to be solved in the proposed BoF/WG is well scoped. The current plan is to have a BoF in San Diego (IETF-67) with the intention of forming a new RAI WG. Topic: Concepts and Terminology Discussion led by: Dean Willis Relevant documents: draft-willis-p2psip-concepts-00.txt Dean presented a basic overview of the model proposed for P2P SIP. Clarifications of some key terms was provided such as the difference between a P2P client and Peers, as well the difference between Enrollment and Insertion. It was clarified that the "Network" should be removed from the document. Topic: Charter Discussions Discussion led by: David Bryan David presented 4 key decision points for the group in terms of scoping the work. 1. What gets standardized? The proposal was for 2wo protocols - an overlay client protocol and an overlay peer protocol. Could be the same protocol, but don't know that yet. At least one could be vanilla SIP, but don't know that yet, either. Poll: Do folks agree with the proposal? Lots of hands are OK, 80 percent. Disagree? none in this room. 2. Are topologies with NATs in scope? This question was divided into 3 subquestions: Do NATs need to be addressed at all? Is locating media relays for NAT traversal required ? If so, should existing IETF work be reused? Proposal was "Yes" for all the subquestions. Poll: "yes" before we asked the question - provided there's wording in the charter on reusing ICE, etc. Almost unanimous agreement on the chart. Disagree? No one spoke up. 3. Can we limit the scope to name lookups? Proposed answer: Yes. Very analogous to SIP registrar functionality. Poll: All yeses for limiting scope to name lookup. 4. Anonymization service? Poll: Interested at all in solving this problem? 15 against, 30 for. Poll: Should this be excluded completely? 8 for. Poll - Dean's compromise: This is very important, but delivery could be handled separately - "nothing that precludes" would be sufficient. Thus, proposing to not put in initial charter. 40 support this compromise proposal. Poll: Include in charter? None for. With some final comments made that the anonymization is fundamentally bound up in SIP, and you can't fix it without changing SIP. Gonzalo emphasized that any SIP changes required for this work will go through SIP change process. The importance of starting the chartered work with a small number of milestones was emphasized, with a threat analysis document being suggested as one of the initial documents, which lead to a discussion of the fundamental security requirements for this work. The suggestion was made to charter with explicit security tradeoffs, but without requiring extensions to the state of the art. A suggestion was made since there was time left after David's presentation to work through the detailed charter changes. However, the majority believed that could be resolved outside the meeting based on the feedback received. Conclusion: Proposed charter needs updating to reflect the tentative consensus, with discussion to continue on the mailing list.