[drinks] Recap on Proposed change to Framework intro

[Dean Willis <[e-mail]>]

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