Minutes of SIP WG meeting at IETF 73 Edited by Dean Willis based on notes by: Vijay Gurbani Scott Lawrence Paul Kyzivat Alan Johnston Session 1, Monday November 17, 2008, 1740-1930, Salon D Topic: Agenda and Status Led by Chairs Slides presented Agenda accepted as presented. Issue: Interim in Jan 2009. Proposed interim in Malta during January 2009 discussed. Note: This interiom was cancelled later in the week. Issue: SIP Location Conveyance Ted Hardie and James Polk reported on status in GEOPRIV. They disagree on how far from a consensus we are. Issue: Dotson's Mutual Authentication draft WG has consensus on pursuing, but ADs and Security Area adviser are opposed to this work. Therefore, we will continue to ignore it until further notice. Topic: URI and Parameter Delivery Led by Jonaathan Rosenberg Slides presented http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt Issue: Free Phone Numbers. Agreed that there is no differentiation required here, they may be treated as targets. Issue: What is a "retarget" operation? This Following discussion, Jonathan agreed to add a definition and discussion of this to the draft. Issue: Normative behavior update for RFC 4244 Consensus noted to revise RFC 4244, and fix some other known problems with it at teh same time. MAry Barnes volunteered to edit the document. Issue: Reference to URNS. Ted Hardie prposed removing teh reference to URNs, as incorrect and confusing. Issue: Discussion of P-Celled-Party-ID Agreed that this needs furtehr work. Christer Holmberg will send text. Issue: Parameter name conflict ("target") with RFC 4458. Editor will change the name of the parameter. Poll: Shall WG adopt this draft towards our charter deliverable on the topic? Chairs reported a strong consensus to do so. Topic: INFO Packages Led by Eric Burger Slides presented http://tools.ietf.org/id/draft-ietf-sip-info-events-01.txt Issue: The "send-info" set Discussion focues on use cases, with DTMF being proposed and found inadequate. Agreed to deprecate this from draft; each side to only declare receive capabilities. Issue: Info in SUBSCRIBE dialogs Can INFO be used only in INVITE dialogs, or also in SUBSCRIBE dialogs? Consensus on use only in INVITE dialogs. Robert Sparks is to send text on topic to Eric. Issue: To allow or not allow Contact header field in INFO Agreed that we can use the existing rule for target-refresh requests. Further text is to be solicited on-list. Issue: Case sensitivity in INFO pakcage names Noted that package identifiers are in the grammr as octets, therefore case sensitive per RFC 3265. Agreed that registry definition shall include text prohibiting registration of names that differ only in case. Issue: Specification Strength Alternatives including "Specification Required", "No Registration Required", "FCFS", were discussed. No consensus detected. Topic: Early Dialog Termination with 199 Led by Christer Holmberg Slides presented http://tools.ietf.org/id/draft-ietf-sip-199-02.txt Issue: Is there a constituency for this work? Noted by chairs that we had previously taken a poll on the topic, but that very few people seem engaged in the work. Chairs took a poll on interest levels, and "don't care" was observed as the loudest of the results. Noted that 3GPP has adopted the approach. Noted that AT&T expects to be requiring this optimization from vendors. Noted that the draft is less interetsing if it does not solve HERFP. There had been agreement in SIPPING not to work on a general solution for HERFP. Therefore, the scope of this work was reduced to exclude HERFP. Discussion about the benefits of the optimization provided by the draft ensued. These discussions were inconclusive. Interested parties are asked to discuss constituency on-list. Session 2, Thursday, November 21, 1300-1500 Salon D Topic: Agenda and Announcements Led by Chairs Slides presented (one deck, same as Session 1) Issue: SIP Location Conveyance A revised draft was submitted Nov. 19. The WG is asked to review it. Issue: draft-ua-sip-privacy, BCP or Info. Concerned parties are asked to discuss on list, with the "default" option being Info. Topic: SIP Draft Stadnards Work Led by Robert Sparks No slides http://tools.ietf.org/id/draft-sparks-sip-steps-to-draft-00.txt Issue: Should we go for draft? Extensive discussion ensued, with many opinions offered. There seems to be a general cosnensus that some part of the work, perhaps SDP and Offer-Answr, or perhaps the grammar, can be carved off and worked on independently. However, there is no conclusion on the larger question. Robert proposed that we concentrate in the near term on collecting interoperability statements and essential corrections. We shall also continue to discuss revisable sections of work. Robert will act as a facilitator for this effort. Topic: Keepalive Without Outbound Led by Christer Holmberg Slides presented http://tools.ietf.org/id/draft-holmberg-sip-keep-02.txt Christer reviewed problem statement and scope of work, including a presentation of use cases. Four requirements are presented in the slides. Issue: Requirements We seem to have general consensus on Req 1-3, but not 4. Hadriel also thinks there is a missing requirement on negotiating the frequency of refresh. Issue: Can we add this back to outbound? Noted that this approach was rejected earlier in the outbound work. However, the most recent Outbound editor (Francois Audet) claims that Outbound has left a hook for thsi approach, and supports it going forward as a separate document. Also noted that some participants don't care about Outbound, but do need keepalive negotiation. Poll: How many people have ready the draft? Chair noted the result as a "fair number", indicating more than expected. Poll: Are there questions in the draft that we should solve? Chair noted the result as "rough consensus". Poll; Do we have consensus on the proposed mecahnism: Answer "No". Topic: Return Routability Check Using RFC 4235, aka DERIVE Led by Victor Pascual Ávila Slides Presented http://tools.ietf.org/id/draft-kuthan-sip-derive-00.txt Issue: Does sending a DERIVE check tell the caller he isn't trusted? Discussion conoted that if one is sending a DERIVE check to every caller that doesn't use RFC 4474, this isn't a statement of distrust. Issue: E.164 numbers Since we are unlikely to have return-routability to a phone number, this mechanism doesn't seem to work there. Or at least it proves nothing about the identity of the caller, although it might (with a GRUU) get us a UA-liveness check. Issue: B2BUA/SBCs Will B2BUAs respond on behalf of the calling party? If they do, is the result useful? Opinions expressed on both sides, with the usefulness dependent on which SBC responds. If it is the caller's SBC, the result might be useful. If it is the called SBC, the result probably isn't useful. And we have no way for the UAS to determine which case occurred, short of an RFC 4474 signature on the response, which would have made the whole thing moot anyhow. No consensus noted on resolving this issue. (Editor note: this is isomorphic to the E.164 identity problem, good luck on solving it!). Noted that Security Considerations section needs work. Issue: Requirements EKR proposed that we are thrashing in the solution space with adequate requirements here. What exactly are we trying to solve? Discussion ensued, with a wide range of positions noted. Noted that return rouatbility checks have proven useful in other spaces. Noted that if this works with off-the-sehf UAs, then the incentive structure is right: the party doing the added work (called) is the one that gets the benefit from it. This is the inverse of the RFC 4474. No final consensus noted. Topic: Path forward on Identity Issues Led by Jon Peterson Slides Presented No draft Issue: Desirable Properties Desirable properties: - Generality ? one universal mechanism is a good thing. - Avoids bid-downs. - Authentication - enables media security - useful to decide whether or not to accept a request Hadriel noted that these are all good, but we can't have them. What are we willing to settle for tha twe can actually deliver? Several others voiced similar positions on the "noble but futile" theme. Issue: Configurability Proposed that some level of flexibility on what headers get signed might be acceptable. Hadriel suggested that we come up with a set of rules that intermediaries could comply with. Sam Hartman suggested that we further need a compromise about what we need to sign to get secure media that shows up as secure on the other end, with a spec that provides it. If we can't get it in this working group, we may need work that spans the entire IETF to get it. Further discussion ensued. No conclusions were noted.