[drinks] Diffs on Introduction as requested by Ken

[Dean Willis <[e-mail]>]

I hope this works. It probably won't; IETF mail server seems to hate MHTML.

11 1. Introduction22 3- Service providers and enterprises use4- registries
to make session routing/targeting 3+ Service providers and enterprises use 4+
registries to make session routing 55 decisions for Voice over IP, SMS and
MMS 66 traffic exchanges. This document is narrowly 77 focused on the
provisioning framework for 8- these registries. In other words, the goal9-
is to allow users to put session 10- establishment data (SED) into a
registry, to 11- share that SED selectively with other users 12- of that
registry, and to allow those other 13- users to further select a subset of
that SED 14- for use in their own applications. The 15- requirements and
use cases driving this 16- framework have been documented in [RFC 6461], 17-
and the reader is expected to be familiar 18- with the terminology defined
therein.19- 20- 21- The SED described in this framework is 22- limited to
simple routing/targeting data. 23- Although the terms "peer" and "peering"
are 24- used, these refer only to the sharing of 25- basic call
routing/targeting information 26- between users of the registry, and do not
27- address the broad range of policy factors 28- that might be used in a
commercial peering 29- "clearinghouse" operation. In short "peering 30-
organizations" are other users of the same 31- registry, and "peers" are
users of that 32- registry to whom the offer of sharing 33- specific SED
has been extended, and who have 34- accepted that offer.35- 8+ these
registries. This framework prescribes 9+ a way or an entity to provision
session-10+ related data into a registry. The data 11+ being provisioned
can be optionally shared 12+ with other participating peering entities. 13+
The requirements and use cases driving this 14+ framework have been
documented in [RFC6461]. 15+ The reader is expected to be familiar with 16+
the terminology defined in the previously 17+ mentioned document.3618 37-
Three types of data flows are described in 38- [RFC 6471]: client to/from
registry, registry 39- to local data repository and registry to 40-
registry, as shown here:4119 20+ Three types of provisioning flows have
been 21+ described in the use case document: client 22+ to registry
provisioning, registry to local 23+ data repository and registry to
registry. 24+ This document addresses client to registry 25+ aspect to
fulfill the need to provision 26+ Session Establishment Data (SED). The 27+
framework that supports flow of messages to 28+ facilitate client to
registry provisioning 29+ is referred to as Session Peering 30+
Provisioning Framework (SPPF).4231 32+ Please note that the role of the
"client" 33+ and the "server" only applies to the 34+ connection, and those
roles are not related 35+ in any way to the type of entity that 36+
participates in a protocol exchange. For 37+ example, a registry might also
include a 38+ "client" when such a registry initiates a 39+ connection (for
example, for data 40+ distribution to SSP).4341 4442 4543 *--------*
*------------* *------------*4644 | | (1). Client | | (3).Registry | |47- |
Client | <-----------> | Registry |<------------->| Registry |45+ | Client
| ------------> | Registry |<------------->| Registry |4846 | | to Registry
| | to Registry | |4947 *--------* *------------* *------------*5048 / \ \51
49 / \ \5250 / \ \5351 / \ v5452 / \ ...5553 / \5654 / (2). Distrib \5755 /
Registry data \5856 / to local data \5957 V store V60- +----------+
+----------+61- |Local Data| |Local Data|62- |Repository| |Repository|63-
+----------+ +----------+58+ +----------+ +----------+59+ |Local Data|
|Local Data|60+ |Repository| |Repository|61+ +----------+ +----------+6462
6563 Three Registry Provisioning Flows66- 67- 68- This document addresses
only the (1) Client69- to Registry aspect. This document defines an 70-
abstract framework for the interaction of 71- registry clients with
registries, referred to 72- as the Session Peering Provisioning Framework 73-
(SPPF). This abstract framework is to be 74- mapped into specific protocol
bindings in 75- other documents, initially to SOAP in 76-
[draft-ietf-drinks-spp-soap].7764 65+ Figure 17866 7967 The data
provisioned for session 8068 establishment is typically used by
various 8169downstream SIP signaling systems to route a
8270 call to the next hop associated with the 83- called domain. These
systems typically use a 84- local data store ("Local Data Repository") as 85-
their source of session routing information. 86- More specifically, the SED
data is the set of 87- parameters that the outgoing signaling path 88-
border elements (SBEs) need to initiate the 89- session. See [RFC5486] for
more details.90- 71+ called domain. These systems typically use 72+ a local
data store ("Local Data Repository") 73+ as their source of session routing
74+ information. More specifically, the SED data 75+ is the set of
parameters that the outgoing 76+ signaling path border elements (SBEs) 77+
need to initiate the session. See [RFC5486] 78+ for more details.9179
9280A "terminating" SIP Service Provider (SSP)
9381 provisions SED into the registry to be 94- selectively shared with
other SSPs. 82+ selectively shared with other peer SSPs. 9583 Subsequently,
a registry may distribute the 96- provisioned data into local data
repositories 97- used for look-up queries (identifier -> URI) 98- or for
lookup and location resolution 99- (identifier -> URI -> ingress SBE of 100-
terminating SSP). In some cases, the 101- registry may additionally offer a
central 102- query resolution service (not shown in the 103- above figure).
Typically, this query 104- resolution service will be something like an 105-
ENUM [RFC 3761] server or a SIP [RFC 3261] 106- proxy or redirect server.107-
84+ provisioned data into local data 85+ repositories used for look-up
queries 86+ (identifier -> URI)or for lookup and 87+ location resolution
(identifier -> URI -> 88+ ingress SBE of terminating SSP). In some 89+
cases, the registry may additionally offer a 90+ central query resolution
service (not shown 91+ in the above figure).10892 109- The roles of
"client" and "server" are 110- abstract and only apply to the requesting
and 111- responding roles in given transactions and 112- are not related in
any way to the type of 113- entity participating in a protocol exchange. 114-
For example, a registry might also include a 115- "client" when such a
registry initiates a 116- connection (for example, for data 117-
distribution to an SSP).