1

Use Cases & Requirements

IETF#77, Anaheim, CA.

2

Introduction

• The latest I-D revision can be found at:– http://tools.ietf.org/search/draft-ietf-drinks-usecases-requirements-0

1

• 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?