1 DRINKS Requirements Design Team Debrief IETF#73, Minneapolis, MN. (Sumanth Channabasappa, on behalf of the design team.)

2 Introduction DRINKS requirements design team was formed at the last IETF – Currently active participants: Deborah Guyton, Gregory Schumacher, Jean- Francois Mule, Ken Cartwright, Manjul Maharishi, Penn Pfautz, Ray Bellis, Sumanth Channabasappa, WG Chairs (Richard Shockey, Alex Mayrhofer) The goal for this team is to specify the provisioning interface requirements to implement a registry for inter-Service Provider (SP) routing – The requirements will not preclude intra-SP routing The design team started with use case proposals that identify the features and functionality for the provisioning interface – The provisioning interface requirements will be distilled from the use cases

3 Status So far we have identified a “bunch” of candidate use cases We are in the process of finalizing the use cases; for instance, we are aggregating and categorizing the use cases A snapshot of what we have is presented in requirements-01 requirements-01 This document is a work-in-progress; we will normalize the terms (e.g., with SPEERMINT) and the content (e.g., use case descriptions) in future revisions

4 Overview Registry is the authoritative source for provisioned session establishment data (SED) and related information Local Data Repository is the data store component of an addressing server that provides resolution responses Registry is responsible for distributing SED and related information to the Local Data Repositories Registry Local Data Repository 1. Provision SED 2. Distribute SED Local Data Repository

5 Existing Use Case Categories Provisioning data into a Registry Distribution of data into local data repositories Peering Relationships (Labeled “LUF and LRF”) SIP Service Provider Miscellaneous (i.e., use cases that are not categorized yet) Note: We are in the process of re-categorizing as we finalize the use cases

6 Terminology (1/2) Public Identity – A generic term that refers to a telephone number (TN), a range of TNs, an address, or other identities as deemed appropriate, such as a globally routable URI of a user address (e.g., Destination Group – A set of global telephone numbers, TN ranges, dial codes, or other public identifiers that are grouped together to facilitate session setup and routing

7 Terminology (2/2) Data Recipient – SP or SSP participating in the peering community for the purpose of provisioning or consuming SED related information. Data Recipient Group – A group of Data Recipients that receive the same set (or subset) of SED related information. Routing Group – A logical grouping of Resource Records; A Destination Group may be associated with one or more Routing Groups based on its association with the Data Recipient Group.

8 Use Cases Provisioning Data into a Registry and Local Data Repositories Provision public identities, destination groups, data recipient groups, and routing groups Specify an effective date & time during the provisioning process Take a public identity out of service Assign a set of public identities to a different Destination Group, thereby changing their routing Move a Service Provider from one data recipient group to another

9 Use Cases Peering (LUF and LRF) and SSP Direct and Indirect Peering Small and Large SSPs

10 Use Cases Miscellaneous Massive Sunrise Provisioning Direct and Selective Peering Indirect Peering to Selected Destinations Peering Relationship Management Points of Egress Non-blocking transactions

11 Next Steps Finalize use cases - Dec/Jan Draft interface requirements - Jan/Feb Draft interface specification - IETF#74