Back to SIP Notes and Minutes IETF 71
Notes on SIP at IETF 71 Reported by Bruce Lowekamp Agenda and status no comments draft-dotson-sip-mutual-auth-01 cablelabs and maybe 3gpp interested in this, there is a need for a technical liason action draft needs to account for difference between how authentication is handled in http vs sip, and also know that this header is not terribly well exercised by http deployments, so can't start with the assumption that this works in http. draft-ietf-sip-session-policy-framework-02 presented an open issue. not enough participation in the room. needs more discussion on the list to see if this needs revision before processing. draft-ietf-sip-outbound-12 need feedback on consensus agreement on keep-alive. no objections in the room. poll of the room, one person appears to care about flow-timer, and wants it in. Clearly no consensus to want it in. draft-kaplan-sip-info-events-01 larger preference in casual poll for info-events than for banning info, but no clear consensus. We don't have time to address this during the current meeting. Angst was expressed at not having the time to discuss this during 71 and will try to arrange telecon or other time to address this in the near future. draft-sparks-sip-invfix-01 preference between complete rewriting of fixes to earlier draft or whether should have only low-level technical diffs. Should maintain both in drafts? Conclusion is that overall is useful, but precise list of sentence-by-sentence diffs is essential. There needs to be a summary of all corrections maintained to put all of these together. Dan Wing: SIP Media Security Requirements discussion on "Comment: "re-instate R15"" interesting solution in new zrtp draft. people happy with re-instating R15 to deal with RTP->SRTP conversion. Moving Forward: Choices 1) publish requirements from 3/07 RTPSEC bof? 2) define requirements based on today's requirements? strong consensus: move forward with current draft as a good place to start. future requirements and new solutions can be done as extensions/new features, but this is needed now. 3gpp has not to this point contributed feedback on it, but is discussing. new rev of document will be wglc'd and if new requirements arrive from any source, new document will be started to reflect those. Mayumi Munakata: draft-ietf-sip-ua-privacy-01 open issue: what should the URI in the From header of an anonymous message be? anonymous@anonymous.invalid prevents identity from working. anonymous@domain allows identity to work. temp-gruu allows possible encoding of useful information for later traceback or persistent pseudo-anonymity (if it's not really temp). Any is possible depending on the requirements of the particular application. Should document all three. Domain hiding isn't supported by any of these and requires a fourth option of an anonymizing intermediary. question as to whether temp-gruu in from conveys more useful behavior than using temp-gruu in Contact? poll: document all 3 vs narrowing down, result is 50/50 split proposal to have use cases for all three being documented and determine if there are use cases that require 3 and not met by 2 new proposal to drop 3 because it is better replaced by third party anonymizer. no objections to this approach. Vijay Gurbani: domain-certs and sip-eku Discussion over whether this is BCP, essential correction, or standards-track. Comment that the drafts being split makes language and implementation hard. Discussion over MUST language requiring SIP certificates to have a subject-alt-name, which no commercial CAs will currently issue. AD reports has attempted to get commercial CAs to support these certificates, and CAs say market does not justify new cert format. ekr to deliver language to move issue to parallel 4474 resolution. need to resolve conflict between security area feedback on banning wildcard certificates and belief that these are being widely proposed for other problem spaces Christer Holmberg: target-uri-delivery-01 Discussion of whether there is a need for more URIs that are trying to indicate where this message is actually going. Numerous people asserting that History -Info handles the practical implications of Target: , but loose-routing requires provisioning to be useful. Now need to evaluate whether we know what the requirements are we're trying to solve here and whether we can address this and maintain backwards compatibility. ADs and chairs to determine the next step. John Elwell: SIP-Identity issues summary: if you want to assert something about a tel number, use a p-a-id (which asserts that a pstn gateway received that caller-id). Sip can only assert things about sip uris question is whether <e.164-addr>@domain can be asserted by that domain as being a valid identity for a user without confusion that it actually came from a pstn-gateway discussion of what identity can mean, and discussion that a domain can never assert anything outside the context of its domain, unless you have outside knowledge of what that domain does.