1 / 9

Use Cases & Requirements

Use Cases & Requirements. IETF#77, Anaheim, CA. Introduction. The latest I-D revision can be found at: http://tools.ietf.org/search/draft-ietf-drinks-usecases-requirements-01 The design team has since discussed additional use cases, and changes to existing use cases (in -01)

matthewllewis
Download Presentation

Use Cases & Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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-01 • 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 1. Provision SED 2. Distribute SED Local Data Repository 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

  8. (Proposed) Data Model ROUTING GROUP SED Record DATA RECIPIENT DESTINATION GROUP Public Identity TN Range RN

  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?

More Related