1 Use Cases & Requirements IETF#77, Anaheim, CA.

2 Introduction The latest I-D revision can be found at: – The design team has since discussed additional use cases, and changes to existing use cases (in -01) – This slide deck presents the existing set of use cases, some of the proposed changes, and a couple of new use cases – Additional use cases will be presented by other participants

3 Recap 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

4 Use Cases in -01 (1 of 2) Process – Near-real-time provisioning – Deferred provisioning – Offline (batch) provisioning Routing – Intra-network SED – Inter-network SED (direct and selective peering) – Support for aggregations (i.e., destination groups) – Indirect (transit) peering – Provisioning an authoritative name server – LUF-only provisioning – LUF + LRF provisioning

5 Use Cases in -01 (2 of 2) Identity – Public Identity operations – TN range operations Administration – Peering Offer/Acceptance – Moving SSP from one destination group to another Number Portability – Need clarity around use cases

6 Comments & Questions (1 of 2) A couple of use cases have been questioned since they introduce protocol complexity without illustrated benefits #1: Aggregation of Data Recipients into a Data Recipient Group, for selective peering – This is only required when you want to modify a set of record routes that are shared by a large number of SSPs; do we expect this? #2: Provisioning using effective date and time – This introduces complexities when a real-time operation changes the state that was prevalent when the deferred operation was requested

7 Comments & Questions (2 of 2) A few new use cases have been proposed; only a couple are presented here #1: Source based LUF response – SSP may wish to present a different target domain, based on the querying entity; for instance, different target domains for international and domestic querying entities #2: Multiple target domains within a LUF-only response – e.g., Authoritative and non-authoritative target domains

(Proposed) Data Model 8

9 Next Steps Discuss and accept/reject the proposed use cases ? Re-check the requirements list? Create a cross-reference of requirements against the protocol documents?