
User-Agent: Microsoft-MacOutlook/14.3.1.130117
Date: Fri, 31 Oct 2014 11:12:54 -0400
From: Ken Pogran <ken@egh.com>
To: Richard Shockey <richard@shockey.us>, "Holmes, David W [CTO]" <David.Holmes@sprint.com>, Henning Schulzrinne <Henning.Schulzrinne@fcc.gov>, "McGarry, Tom" <Tom.McGarry@neustar.biz>, "modern@ietf.org" <modern@ietf.org>
Message-ID: <D0791E07.7B8B9%ken@egh.com>
Thread-Topic: [Modern] Services
In-Reply-To: <D0747AB5.18045%richard@shockey.us>
Mime-version: 1.0
Content-type: text/plain; charset="EUC-KR"
Content-transfer-encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/modern/uXB-R6OrP3VwzsBwmcz2XIG21Pc
Subject: [Modern] ***SPAM*** 7.215 (5) Re:  Services
Precedence: list

I agree with David Holmes and Rich Shockey that identifying the data
elements and functionality we want to have in our next-generation
telephone number (TN) databases should be the first step. To do this, we
will need to identify what data elements will need to be associated with
each TN.=20

Most of the discussion here so far has focused on data that today is in
the NPAC and LERG. However, call setup in the North American PSTN
typically involves one or more queries to a LIDB (Line Information
Database) and maybe a separate CNAM database as well (and to find out
which LIDB or CNAM DB to query, there may be lookups in the LARG and
CNARG, to boot).  So in addition to carrying over appropriate data
elements from the LERG and NPAC, we will need to pull in some of the data
elements currently in LIDB/CNAM, as well.

PSTN databases like LIDB/CNAM of course contain a lot of "legacy-only"
data elements that we as an industry will be happy to get rid of as we
move to IP telephony ("line-based" Calling Card PINs, anyone?).  But there
are some that are definite "keepers," and others that will need to be
looked at before the transition is done.  EGH did a writeup on LIDB data
elements in 2012, available at
http://apps.fcc.gov/ecfs/document/view?id=3D7022032292, and also commented
(in the FCC's 13-5 proceeding,
http://apps.fcc.gov/ecfs/document/view?id=3D7022117659) on the data elements
EGH thought -- back in 2013 -- would need to be carried over, or at least
considered.

We should also construct some use cases for when, how, and by whom these
databases will be queried as part of the call setup process. Having use
cases in hand will help us to define the overall architecture as well as
the security model: where the database(s) live, and who can access the
data. In addition, they can help us explore cost models for the databases
and database queries.

Once we have identified data elements and functionality, explored use
cases, and determined the overall architecture and security model, we can
proceed to match the functionality and query methodology to appropriate
protocols, both for querying and (separately) for provisioning.

Regards,
  Ken Pogran
  Director of Business Development
  Evans Griffiths & Hart, Inc.
  (781) 861-0670
  www.egh.com
 =20


On 10/27/14 11:28 PM, "Richard Shockey" <richard@shockey.us> wrote:

>
>There is still the first order problem of clearly and succinctly defining
>what is the problem statement. Everything else falls out from that.
>
>The value proposition would run something like this.
>
>How do we construct a set of tools that National Number Administrations
>can use to design systems for which E.164 identifiers can be properly and
>securely managed and authorized entities can create and use metadata
>associated with those E.164 identifiers to enable ubiquitous global
>communications.=20
>
>David ..I can testify that other National Number Administrations are
>struggling with this.
>
>What is the history of the IETF with E.164 identifiers?  Where has there
>been success and failure so far and why is new work needed.
>
>Certainly the history of ENUM is instructive. We all know what the
>successes and failures of that effort were and Tom McGarry correctly laid
>out the pros and cons of using DNS models. As you know Ive been there done
>that. I=A9=F6ll volunteer to write that section. :-)
>
>We have looked at provisioning issues in DRINKS but that had its own
>issues associated with it and I, for one do not believe the existing DNS
>EPP tool kit RFC 4114 is an appropriate starting place for provisioning
>based on what we know of modern carrier systems. I=A9=F6m not sure even the
>Domain Name Registration industry would go down the EPP route if they knew
>what they know now. It wouldn=A9=F6t hurt to ask Scott Hollenbeck since he is
>the institutional memory of all of this. You correctly point out we
>somewhat trapped in legacy models and telephony provisioning systems are
>staggeringly expensive.
>
>I=A9=F6ve argued that EPP is actually a IETF failure since it is not really a
>general purpose provisioning data exchange system it is highly bound to
>the domain name registry industry and as such carries a lot of baggage
>associated with it. Even HTTP/SOAP/XML has now been eclipsed for all sorts
>of reasons but it did work and was clearly more generic than other methods
>that proceeded it.
>
>We certainly know what people use in North America use SOA/LSMS interfaces
>for the NPAC and BIRDDS for the LERG etc and there is a lot of open
>documentation on all of those what the required fields are etc.
>
>We=A9=F6d need to see every darn field currently in use and then see if it
>could have some mapping to some new system and certainly we have more
>modern Query Response mechanisms.  Brian Rosen pointed out REST/JSON
>certainly comes to mind and I would certainly agree. There is the
>globalization problem. E.164 is a big name space but I reject the notion
>that the solution has to be globally applicable from day one.  That is way
>too much of a stretch. Visions of global roots come into mind and my head
>wants to explode.=20
>
>My basic suspicion is if we all sat down in a room for a day or two (with
>beer) a white board we could roughly outline the basics including one or
>more models of how registries would operate and I commend to your
>attention the work of IETF PAWS and the FCC White Spaces initiative on how
>a new federated registry model might actually work.
>
>Needless to say there is some level of Layer 9 here (politics) due to the
>nature of control of the namespace itself.  This is <cough> telephony not
>the Internet.
>
>=8B=20
>Richard Shockey
>Shockey Consulting LLC
>Chairman of the Board SIP Forum
>www.shockey.us
>Www.sipforum.org
>richard<at>shockey.us
>Skype-Linkedin-Facebook rshockey101
>PSTN +1 703-593-2683
>
>
>
>
>
>On 10/27/14, 7:18 PM, "Holmes, David W [CTO]" <David.Holmes@sprint.com>
>wrote:
>
>>This is a great discussion & continues to follow the common IETF
>>principles of proposing a solution & then finding what patches it needs
>>to meet some implicit requirement(s).
>>
>>However, in this case, given the huge legacy coming in from both the IP &
>>PSTN worlds, I suspect that perhaps we should consider modifying the
>>process somewhat, & first generate some kind of statement of requirements
>>/ problem statement.  A large amount of the required information has
>>already been aired, as we see below, so potentially this could be done
>>without the expenditure of much effort.
>>
>>Maybe what we need to start the process is an informational RFC that list
>>out all the identifiers in common use in this field, & how they are used,
>>translated for routing, etc.?  Based on that it should be easy to
>>rationally derive a set of requirements & (hopefully) figure which
>>identifier(s) & supporting mechanisms can be minimally modified to
>>produce a reasonable solution.
>>
>>David Holmes
>>Sprint