Subject: Re: [drinks] Use cases doc and notes from the F2F

From: "Cartwright, Kenneth" <[email-masked]>
Date: Thu, 13 May 2010 10:04:34 -0400

-----Original Message-----
From: Cartwright, Kenneth
Sent: Wednesday, May 12, 2010 9:52 AM
To: 'Sumanth Channabasappa'; 'Alexander Mayrhofer'; David Schwartz; Jean-Francois Mule; Maharishi, Manjul; Syed Ali
Cc: [email-masked]
Subject: RE: Use cases doc and notes from the F2F

Hi Sumanth,

Here are the two use cases that I offered to re-write/clarify.

Ken

Change this...

Coexistent SED Exchange and Discovery Models: When establishing peering relationships some SSPs have the need to support all three SED Exchange and Discovery Models concurrently, for the same set of public identities.  Provisioning activities are required to facilitate this process of supporting all three models concurrently, and allowing SSPs to distinguish and choose the model(s) they wish to utilize for a given set of public identities.

To This...

Coexistent SED Exchange and Discovery Models: When supporting multiple peering relationships some SSPs have the need to concurrently support all three of the SED Exchange and Discovery Models described above, for the same set of lookup keys.  For the same set of lookup keys, SSPs provision SED that supports peers that need a unified LUF/LRF lookup, a LUF only 3263 Domain Name lookup, and a LUF only administrative domain identifier lookup.  Provisioning activities are required to facilitate this process of supporting all three models concurrently for the same or different set of lookup keys, and allowing peers to distinguish and choose the model(s) they wish to utilize for their lookups.

Change this...

   UC ID #5  Peering offer/acceptance: An SSP offers to allow
             terminations from another SSP by adding that SSP to a Data
             Recipient Group it controls.  This causes notification of
             the offered SSP.  An SSP receiving a peering offer should
             be able to accept or decline the offer.  If the offer is
             rejected the registry should not provision corresponding
             SED to the rejecting SSP.  It is expected that this
             capability will apply mainly in the transit case where non-
             authoritative parties (in the sense of not being the
             terminating SSP for an identity) wish to offer the ability
             to reach the identity and originating SSPs may wish to
             restrict the routes that are provisioned to their local
             data repositories.

To this...

Data Recipient Offer and Accept:  When establishing and breaking a peering relationship SSPs coordinate the access to and usage of points of ingress and other SED for a given set of lookup keys.  Only once a peer is ready to use those points of ingress and other SED for a given set of lookup keys do they wish to have those points of ingress and other SED returned in response to resolving on of those lookup keys.  Provisioning activities are required to support these activities that involve the SSP that owns a Routing Group offering a peer (aka a Data Recipient) access to a Routing Group, and then that peer accepting that offer.  Only after that offer is accepted will the peer begin to see that SED returned in resolution responses for the lookup keys associated with that Routing Group.  An auto-accept feature can also be envisioned, such that a given peer is configured to automatically accept any Route Group visibility offer from one or more SSPs.

Ken

-----Original Message-----
From: Sumanth Channabasappa [mailto:[email-masked]]
Sent: Wednesday, May 12, 2010 1:36 AM
To: 'Alexander Mayrhofer'; David Schwartz; Jean-Francois Mule; Cartwright, Kenneth; Maharishi, Manjul; Syed Ali
Cc: [email-masked]; Sumanth Channabasappa
Subject: Use cases doc and notes from the F2F

Folks,

I am enclosing a dirty update to the -02 draft, based on our discussions at the F2F last week. I shared this earlier with Syed, so that he can start the mapping of use cases to the protocol documents. I was hoping to refine it further (e.g., comments from Ken on the introductory sections have not yet been incorporated), but haven't had the chance yet.

This is mostly an FYI for now. Once I have an update, I will post an update and send it to the DRINKS list. I am enclosing three docs:

- the MS Word version that we edited (the base was Ken's comments on the -02 version);
- the updated I-D
- diff from -02

Thanks!
- S

This e-mail message is for the sole use of the intended recipient(s)and may
contain confidential and privileged information of Transaction Network Services.
Any unauthorised review, use, disclosure or distribution is prohibited. If you
are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message.