1. Page 1 IETF DRINKS Working Group Data Model and Protocol Requirements for DRINKS IETF 72 - Thursday July 31 2008 Tom Creighton - tom_creighton@cable.comcast.com Jean-François Mulé - jfm@cablelabs.com

2. Page 2 IETF DRINKS Working Group Agenda Quick Update on espp Requirements Drinks Data Model –Review of Drafts containing input for the “Lookup Function” Data –Discussion on Location Routing Data –Registry-to-registry vs. registry-to-caches Protocol Requirements Next Steps

3. Page 3 IETF DRINKS Working Group Requirements for provisioning LUF/LRF caches Changes in draft-mule-peppermint-espp-requirements-01 Terminology –Used speermint terminology for LUF and LRF –Addressed list comments »LRNs -> RNs, prefixes »Service Areas -> Destination Group Added requirements for Data Model –Data elements required for the SPEERMINT Lookup Function –Allow the Location Routing Function to dynamically determine the target's SIP server outside the provisioning framework. –See more in document The rest of these slides discuss areas where DRINKS Internet-Drafts converge and open some questions for discussion.

4. Page 4 IETF DRINKS Working Group Data Model Requirements from I-Ds (1) Areas where we seem to have some consensus in drafts Classes –Support for wide variety of “destination addresses” »Telephony and non-telephony user addresses »TN Prefixes of variable lengths, routing numbers, number blocks or ranges –Provide means to logically group destination addresses into “Destination Groups” and associate Domains and/or Routes to these groupings Class attributes –Object Identifiers and for some, a Name attribute –Validity attribute for some object (Not-Before, Not-After) –Object ownership –For TNs, Dial Code or TN type –Etc. Telephone Number Ranges/Blocks Destination Group Or Destination Tag FQDN of SIP Service Provider User Addresses (Non-TN) TN Prefix Or Routing Number

5. Page 5 IETF DRINKS Working Group Data Model Requirements from I-Ds (2) Areas where we had more discussions (list, hallway)… Data Model Support for Location Routing data (LRF data) –FQDN of SIP Service Provider -> SIP server location »Next SIP hop(s) in originating domain/terminating domain in the form of full DNS Resource Records or decomposed list of data elements –LRF Data is part of Session Establishment Data and in scope of drinks »2 requirements Internet-Drafts propose to include it in provisioning scope »Applicable to bilateral exchanges in particular »Proposal: Make the LRF data objects optional to support in provisioning protocol(s) => allows other dynamic lookups of SIP server location Destination Group Or Destination Tag FQDN of SIP Service Provider NAPTR RR to terminating SSPHost Addresses, priority, service type, etc. Do not provision LRF data: use other discovery mechanisms a la RFC 3263

6. Page 6 IETF DRINKS Working Group Differences between Registry-to-registry vs. registry-to-caches provisioning Charter has 2 protocols in scope –Registry to Registry –Registry to server caches Some data elements may be applicable to both protocols, some may only be suited for one Examples –Validity of a record »May be more suited for registry »A record pushed to a data cache is just valid and it is removed after the validity period –TN type as proposed by some drafts may be used for TN validation; it may be important for some registries but may not be helpful to propagate down to server caches Questions –How do we want to develop requirements and more importantly, the associated data model(s) and protocol(s)?

7. Page 7 IETF DRINKS Working Group Protocol Requirements Areas where we seem to have no discussions Protocol Operations –Push/Pull support –Add, modify, and delete objects defined in the protocol data model »Some drafts proposed transfer, ported-in, ported-out, and modify operations »Question: are transfer, ported-in/ported-out operations required? »Question: is a modify operation necessary or can we simply use add to update an attribute value? –Query for an instance of each type of object –Multiple clients to provision objects into the same server Connection-Oriented and File-Oriented Operations –Comments? Data Presentation Requirements Other protocol requirements –Security Requirements –Versioning, Capability Exchange, and Extensibility Requirements

8. Page 8 IETF DRINKS Working Group Thank You. Q&A