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

[David Schwartz <[e-mail]>]

Hi Ken

On Apr 11, 2012, at 10:58 PM, Cartwright, Ken wrote:

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.

DS: Unless the additional text neither bounds or expands but merely adds some necessary clarification.

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.

DS: Why do you feel that the new text is apologetic or vague? I would counter that the term peering is way more vague than access control which is precisely what is described in the current docs.

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.

DS: The DRINKS WG is predicated on the SPEERMINT WG and specifically on RFC 5486 defining the very terms we use in our use case document. Section 4.3.3 of 5486 defines LUF (covered as well in section 3.3 of RFC 6461 - the DRINKS use case doc) and in the definition of LUF the term "target" is quite deliberate…"The Look-Up Function (LUF) determines for a given request the target domain to which the request should be routed", hence one could say that "targeting" is the process of determining the target. If the definition of "target" is unclear than that is a problem with 5486 more than it is with any of the DRINKS docs.

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.

DS: It depends in which document. I would agree that in both framework and protocol docs there is no place for either term. I would argue, however, that in a use case document, these terms are very relevant as they provide context to the relevant use cases.

Thanks for considering these points.
Ken

________________________________
From: [e-mail]<mailto:[e-mail]> [mailto:[e-mail]] On Behalf Of Dean Willis
Sent: Wednesday, April 11, 2012 10:38 AM
To: [e-mail]<mailto:[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.

<ATT00001..c>