1. S. Ali, K. Cartwright, D. Guyton, A. Mayrhofer, J-F. Mulé Data for Reachability of Inter/tra-NetworK SIP (drinks) DRINKS WG draft-mule-drinks-proto-02 77 th IETF – Anaheim March 24, 2010 1

2. Agenda Changes in draft-02 Discussion on open issues & list comments –LUF-only vs. LUF+LRF –Route Object –Target domain –Protocol operations –PSTN related use cases Next Steps 2

3. Scope of protocol document Session Peering Provisioning Protocol (SPPP) *-------------* 1. Provision SED | | -----------------------> | Registry 3. Registry-to-Registry Session Peering | | Data Exchanges Provisioning Protocol *-------------* / \ / 2.Distribute \ / SED \ V “Distribution V Protocols” +----------+ +----------+ |Local Data| |Local Data| |Repository| |Repository| +----------+ +----------+ SED = Session Establishment Data Terminology used in this presentation is from the Speermint WG (LUF, LRF, SF, SED) See RFC 5486

4. Other Changes in draft-02 Added explicit support for LUF-resolution: Target Domain data element Changed Route Group for LRF-resolution to be independent from resolution protocol –URI –DNS RRs TXT, NAPTR, NS Removed NAPTR and NS objects Everything else is pretty much unchanged from draft-01 (see IETF#75 slides for overview) 4

5. LUF vs. LUF+LRF Resolution using data provisioned via SPPP List comments that the protocol must accommodate entities that use these types of Registries for –LUF-only resolution: public identifier -> Target Domain –LUF+LRF resolution: public identifier -> Target Domain and Route Draft-02 provides “simplified views” of the data model for LUF and LUF+LRF Draft-02 introduces a Target Domain 5

6. Target Domain data element What is it? –FQDN that points to the entity that has a Signaling Function (SF) for the public identifier –It is not a Service Provider ID (PSTN SPID) Where should it belong in the data model? –Public Identifier, Destination Group or Route Group? –Current choice is Route Group to accommodate responses that can vary based on who asks (source-based LUF or LUF+LRF resolution) 6

7. Examples LUF <addRteGrpsRqst [… ] id-12317123 20 registrantID123 registrarId0 2010-05-04T18:13:51.0Z route_grp_1 ssp1.example.com true LUF + LRF <addRteGrpsRqst […] [… same as on left side] [… same as on left side] route_grp_1 ssp1.example.com true 10 100 u E2U+sip ^(.*)$ sip:\1;npdi@sbe34- ssp1.example.com; true 7

8. Open Issue: Modify operations Current document has support for add, delete, and get operations Modify operations are done via add commands –Idea: the SPPP client does a get to get operation and then an add with modified values –The server does not have to check if an object instance exists, it overwrites things Comments? 8

9. Open issues Protocol Operations –Do we need to add simple LUF-only provisioning operations? –What other operations (add/get/delete) do we need to add to cover 90% of the needs? What is core protocol vs. features that can be defined later with Schema extensions? –Activation, Deletion dates? –Data Recipient Groups: design team currently reviewing the value of this concept 9

10. Open Issue: PSTN related issues “Carrier-of-record” –Issue: how to represent in the data model the notion of carrier-of-record or who is authoritative for a public identifier? “SPID” or Service Provider ID –Some want the LUF query to return a SPID so that this protocol can be used with their existing systems Local Number Portability Use Cases –A new set of use cases are about to be contributed –Need to address these in the protocol 10

11. Next Steps Stabilize the use cases Get WG feedback on the basic protocol concepts Goal –Have a protocol document that addresses use cases in April before interim meeting –Review protocol @ interim and then get a stable version by mid-June 11