Re: [drinks] Recap on Proposed change to Framework intro

["Cartwright, Ken" <[e-mail]>]

Hi Dean,

1) Can you please identify the diffs.  Thanks.
2) From a general perspective, the framework supports what it supports.  So adding in text to somehow further bound or expand on that seems un-necessary.  It is certainly true that neither the Use Case document nor the resulting framework or protocol documents have attempted to include or support all types of use cases that can be involved on route generation and selection (e.g. Time Based Route Selection, Dial Plans, etc, etc).  Early on, the scope was deemed to be more limited than that, because that broader scope would have been too large, and moving, and varying.  If we wish to expand the scope covered by the Use Case document and/or the framework then that is a different matter.  But adding in vague language here that seems to sort-of apologize for the scope seems a little odd to me.
3) Introduction of the word "targeting" cries out for a definition.  Afaik, this is a term that has not been defined here or in another document.  But if that definition does exist then can you point us at it.  Thanks.  I don't think we can get away with just "slipping it in" here.  It's just too noticeable when used in this context.
4) The phrase "commercial peering "clearinghouse" operation" could probably be either removed or altered.  For example, whether the implementing registry is "commercial" or not is not relevant, and whether the implementing registry considers itself a "clearinghouse" is not relevant.

Thanks for considering these points.
Ken

________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Dean Willis
Sent: Wednesday, April 11, 2012 10:38 AM
To: [e-mail]
Subject: [drinks] Recap on Proposed change to Framework intro

Recapping from the discussion we had on the list. I believe the following might suffice for getting the concerns raised by David about the scope of "peering" into the document.

I'm personally still vague on the difference between routing and targeting, but I don't think that matters much for this text.


1.  Introduction

Service providers and enterprises use registries to make session routing/targeting decisions for Voice over IP, SMS and MMS traffic exchanges. This document is narrowly focused on the provisioning framework for these registries.  In other words, the goal is to allow users to put session establishment data (SED) into a registry, to share that SED selectively with other users of that registry, and to allow those other users to further select a subset of that SED for use in their own applications.  The requirements and use cases driving this framework have been documented in [RFC 6461], and the reader is expected to be familiar with the terminology defined therein.

The SED described in this framework is limited to simple routing/targeting data. Although the terms "peer" and "peering" are used, these refer only to the sharing of basic call routing/targeting information between users of the registry, and do not address the broad range of policy factors that might be used in a commercial peering "clearinghouse" operation. In short "peering organizations" are other users of the same registry, and "peers" are users of that registry to whom the offer of sharing specific SED has been extended, and who have accepted that offer.

Three types of data flows are described in [RFC 6471]: client to/from registry, registry to local data repository and registry to registry, as shown here:



    *--------*               *------------*               *------------*
    |        | (1). Client   |            | (3).Registry  |            |
    | Client | <-----------> |  Registry  |<------------->|  Registry  |
    |        |   to Registry |            |  to Registry  |            |
    *--------*               *------------*               *------------*
                                  /  \                          \
                                 /    \                          \
                                /      \                          \
                               /        \                          v
                              /          \                         ...
                             /            \
                            / (2). Distrib \
                           / Registry data  \
                          /  to local data   \
                         V      store         V
                    +----------+         +----------+
                    |Local Data|         |Local Data|
                    |Repository|         |Repository|
                    +----------+         +----------+

                     Three Registry Provisioning Flows


This document addresses only the (1) Client to Registry aspect.  This document defines an abstract framework for the interaction of registry clients with registries, referred to as the Session Peering Provisioning Framework (SPPF).  This abstract framework is to be mapped into specific protocol bindings in other documents, initially to SOAP in [draft-ietf-drinks-spp-soap].

The data provisioned for session establishment is typically used by various downstream SIP signaling systems to route a call to the next hop associated with the called domain.  These systems typically use a local data store ("Local Data Repository") as their source of session routing information.  More specifically, the SED data is the set of parameters that the outgoing signaling path border elements (SBEs) need to initiate the session.  See [RFC5486] for more details.

A "terminating" SIP Service Provider (SSP) provisions SED into the registry to be selectively shared with other SSPs. Subsequently, a registry may distribute the provisioned data into local data repositories used for look-up queries (identifier -> URI) or for lookup and location resolution (identifier -> URI -> ingress SBE of terminating SSP).  In some cases, the registry may additionally offer a central query resolution service (not shown in the above figure). Typically, this query resolution service will be something like an ENUM [RFC 3761] server or a SIP [RFC 3261] proxy or redirect server.

The roles of  "client" and "server" are abstract and only apply to the requesting and responding roles in given transactions and are not related in any way to the type of entity participating in a protocol exchange.  For example, a registry might also include a "client" when such a registry initiates a connection (for example, for data distribution to an SSP).

... continue with existing text from "A key requirement..."

________________________________
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.