1. Page 1 IETF Speermint Working Group Speermint draft-ietf-speermint-requirements-04 IETF 71 - Wednesday March 12, 2008 Jean-François Mulé - jfm@cablelabs.com

2. Page 2 IETF Speermint Working Group Agenda Changes in draft-04 Open Issues

3. Page 3 IETF Speermint Working Group Changes in draft-04 Since draft-03, scope is to produce informational document defining requirements that enable use cases http://tools.ietf.org/html/draft-ietf-speermint-requirements-04 Started to remove unnecessary verbose text Addressed some terminology issues but missed a couple Split requirements for advertising Signaling path Border Elements into 2 (one for ingress, one for egress) Removed Section 4 entirely –Signaling and Media Guidelines for Session Peering are out of scope Updated IM and Presence requirements to align them with I-D.ietf-speermint-consolidated-presence-im-usecases Reworked Security text to focus on LUF and LRF requirements

4. Page 4 IETF Speermint Working Group Open Issue #1 - Egress SBEs Requirement #2: Protocol mechanisms should exist for a SIP Service Provider (SSP) to communicate the egress SBEs of its service domain. Motivations for this requirement –Capacity planning, traffic engineering, call admission control. –Example 1: »2 SSPs agree to do L5 peering in multiple locations, including NYC and Paris. »SSPa does not want to carry the cost of transporting media from Paris to NYC for SSPb and requires that calls from subscribers of SSPb originated in Paris to subscribers of SSPa in NYC be carried on SSPb’s network all the way to NYC and then be egressed in NYC to SSPa »SSPa requires a list of SBEs from SSPb at the various POPs to restrict CAC based on originating or egress SBE –Example 2: »SSPs may maintain strict ACLs with the list of peers’ egress SBEs Open Issue: is this requirement needed? Should protocol mechanisms exist to “communicate” egress SBE?

5. Page 5 IETF Speermint Working Group Open Issue #2 - Data path Border Elements Requirement #3: Protocol mechanisms should be available to allow a SIP Service Provider to communicate its DBEs to its peers. Motivations for this requirement –Same as previous slide: Capacity planning, traffic engineering, call admission control. –Diffserv policing between SSPs for media exchanges (see RFC 4594 Configuration Guidelines for DiffServ Service Classes) Considerations –SDP does this essentially meet this advertisement on a call by call basis Open Issue: is this requirement needed?

6. Page 6 IETF Speermint Working Group Open Issue #3 - peer and media variability Requirement #4 The mechanisms recommended for the declaration or advertisement of SBE and DBE entities must allow for peer and media variability. Motivations for this requirement –Specify different border elements for different peers –Specify different border elements for different media types Open Issue –OK to say “allow for peer, media or service-type variability”? –Comments received questioning this requirement, some in favor

7. Page 7 IETF Speermint Working Group Open Issue #4 - Security considerations Draft-04 updated section 5 –New structure around LUF and LRF requirements –Integrated input received from Saverio Niccolini at IETF#70 Requirement #15: The protocols selected for the LUF and LRF must allow the look-up and response data to be exchanged securely (authentication and encryption services should be provided). –Open Issue: Comment received to put this to should or must? –Recommend to keep must (usage may vary but we must have means to secure these protocols) Left Section 5.3 on Hop-by-hop Security for SIP Signaling and TLS Considerations –Folks had request more details than ‘use TLS’ –Yet this is mostly informative due to scope and the fact that it has to do with how SSPs MAY use existing SIP mechanisms –Open Issue »Do we want to keep section 5.3?

8. Page 8 IETF Speermint Working Group Thanks. Other Feedback? mailto:speermint@ietf.org