1. A Framework for Session Initiation Protocol User Agent Profile Delivery (draft-ietf-sipping-config-framework-11) SIPPING – IETF 68 Mar 19, 2007 Sumanth Channabasappa sumanth@cablelabs.com (On behalf of the design team)

2. 2 Why this presentation? Based on the breakout session discussions at IETF#67, the chairs recommended the formation of a design team to review and revise sipping-config-framework-09 –Design team volunteers (in no particular order): Dan Petrie, Peter Blatherwick, Josh Littlefield, Cullen Jennings, Martin Dolly, Francois Audet, Mary Barnes, Gonzalo Camarillo, Jason Fischl, Alvin Jiang, Sumanth Channabasappa Design team planned and presented two revisions –draft-10 (Jan, 2007) –draft-11 (Mar, 2007) Revisions incorporate WG comments and resolutions that are briefly highlighted in the following slides –Comments received post -11 are also presented for feedback

3. 3 What is being presented? “Long, long ago, a great chef traveled far to start a restaurant in the planet of opportunity – Sip. He had heard right, it offered the best ingredients in the universe. But there was one peculiarity…each family (a.k.a. sipuas) established unique and adamant rules for serving cuisines…thus, for each dish on the menu, the chef needed to learn, and remember 3261 (and increasing) ways to serve it…!” Reproduced in part, without permission, from the extended version of ‘The Hitchhiker’s guide to SIP’ The SIP configuration framework aims to solve this problem –It is a proposal that specifies a single way to serve any dish to any SIP UA (dishes themselves are out of scope) SIP UA Profile Delivery Server

4. 4 Technical please… What does “draft-ietf-sipping-config-framework” do? –It proposes a framework for propagating profile data to SIP UAs How does it accomplish it? –By specifying a new Event Package based on the SUBSCRIBE/NOTIFY mechanism (RFC3265) Does it specify anything else (at a high level)? –It specifies a profile life cycle describing how: a device requests profile data using the new event package (enrollment) a device retrieves profiles via content indirection (content retrieval) a device is notified of profile changes (change notification) –It specifies three types of profiles, each of which use the profile life cycle local-network, device and user What does it not do? – It does not specify any data models

5. 5 So, what did we say in IETF#68? Consider suggestions to simplify the structure and technical proposal in draft-09 –Structural changes Keith Drage recommended a new structure (via email, Nov/09/’06) leading to brief comments on the WG mailing list and detailed discussions in the design team –Simplify, or justify, the various profile types? –Simplify, if possible, the profile discovery mechanisms? Address review comments presented in the WG –Fix the usage of ‘network-user’ parameter –Revise the overview section to better articulate the use cases

6. 6 What was done in draft-10? The document layout was revised based on the initial recommendation and subsequent design team discussions –Introduction, Terminology and Overview sections were revised –Requirements detailing the proposal were specified in a single section (Profile Delivery Framework, section 5) –Use cases were made high-level to better reflect the requirements for the framework –Examples were expanded to provide more clarity Please refer to draft-10 for a complete list of changes Draft-09 was presented to the WG for further comments –Thanks to the WG participants who provided expert review comments –An attempt was made to address all the comments in draft-11 (based on design team consensus)

7. 7 What was done in draft-11? Major changes include –The Profile Life Cycle process was further simplified –Made changes to the local network profile to include the user’s AOR in the ‘From’ field –Added a ‘device-id’ field for the local-network profile to include the device identifier –Security section was revised –Fixed terminology and editorials based on the comments in the WG Please refer to draft-11 for a complete list of changes Draft-11 was presented to the WG for further comments –Once again, thanks to the WG participants who provided expert review comments –These comments have not been incorporated as yet

8. 8 Questions to the WG

9. 9 Layout? Does the layout reflect expectations? –Too much information (if so, what would you want to remove)? –Too little (if so, what should we consider adding)? Any specific recommendations? –For example, there has been a suggestion to include the security requirements in the respective sections

10. 10 To _ or not to _? There is an ongoing discussion in the mailing list regarding the use of _(underscore) for the specified DNS A record: sipuaconfig. within the local profile type –DNS experts have been contacted to resolve this –Any expert thoughts in the group? Options: A)Sipuaconfig. B)_supuaconfig. C) Others?

11. 11 Do we need the ‘device-id’? The ‘device-id’ parameter can be provided as part of the local-profile request to identify the originating device –This is required since the From field is either the user’s AOR or ‘anonymous’ –IP addresses are transient and a device may have multiple IP addresses However, it has been indicated that we can rely on the contact header alone? Thoughts? Options: A)Continue the use of ‘device-id’ parameter B)Remove ‘device-id’, rely on contact header

12. 12 Fallback to HTTP? The I-D allows fallback to a HTTP based device profile retrieval mechanism if all the specified profile enrollment methods fail –However, this has been questioned Options A)Continue using the fallback mechanism B)Eliminate the fallback mechanism

13. 13 Other comments Do we need the local network profile?

14. 14 Additional information Latest I-D: –http://www.ietf.org/internet-drafts/draft-ietf- sipping-config-framework-11.txthttp://www.ietf.org/internet-drafts/draft-ietf- sipping-config-framework-11.txt