Subject: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM?

From: "Stastny Richard" <[email-masked]>
Date: Mon, 6 Feb 2006 19:32:32 +0100

> (i) Requirements first - that should be fun. What's the schedule 
>for ITU SG2
>       meetings after January 2007?

good question
 
BTW, talking about doing requirements first:

I just got asked here at the ETSI TISPAN meeting, why then the 
enumservice pstn is closing WGLC already, because this is
definitely for Infrastructure ENUM.
 
There was also a mumbling about "quod licet jovi, not licet bovi"
 
Just asking ;-)
 
Richard

________________________________

Von: lconroy [mailto:[email-masked]]
Gesendet: Mo 06.02.2006 19:26
An: Richard Shockey
Cc: Stastny Richard; [email-masked]
Betreff: Re: [Enum] Why not re-use interim procedures for infrastructure ENUM?

Hi Richards, folks,
   (i) Requirements first - that should be fun. What's the schedule 
for ITU SG2
       meetings after January 2007?
  (ii) People keep talking about rfc3761bis, but I think we're 
talking about
       different things - some folks seem to be talking about a 
"traditional"
       rfc3761bis (i.e. obsoleting the current RFC 3761); others seem 
more
       interested in an RFC3761-doppelganger (i.e. in parallel with 
RFC 3761).

So... are we to work on a replacement doc or one to run in parallel?

I'm assuming that the Pfautz/Linn draft is the one you take for 
requirements.
That would seem to tie in with the doppelganger approach, as that draft
covers requirements for Infrastructure ENUM only.

all the best,
   Lawrence

On 6 Feb 2006, at 15:19, Richard Shockey wrote:
> Stastny Richard wrote:
>> Richard Shockey wrote:
>>> However the "issue" as you call it Richard IMHO would not lie 
>>> with the
>>> IAB. You should re read the charter of the IAB.
>>> It would lie with the IESG upon creation of the appropriate RFC that
>>> designated an Infrastructure apex. If the RFC is approved there is
>>> little or nothing the IAB can do to impede its deployment.
>> So to get this going, we first need a RFC 3761bis defining the apex
>> If the IESG approves, IAB will start negotiating with RIPE and ITU
>
>
> This is only a personal opinion but I do not believe you need to 
> wait for 3761bis this could be defined in a separate document once 
> there is agreement on the requirements.
>
> As is usual IETF procedure ..requirements _first_ ..then the solution.
>
>> Translated to practical issues this means:
>> 1. we have to move forward with our draft to get a workable 
>> solution for the next 1 or 2 years (option2)
>> 2. we also have to start the procedure by creating draft-enum-
>> rfc3761bis.
>> Since 2 cannot be finished before May 2006, the question is, 
>> should be bother ITU-T already
>> now or wait for January 2007?
>> regards
>> Richard

_______________________________________________
enum mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Mon, 06 Feb 2006 14:03:29 -0500

> definitely for Infrastructure ENUM.

Its actually a valid point and this is the third question I've had on 
that subject this morning since I issued the request for publication.

We had WGLC on this and if anyone had asked a question we certainly 
could have responded with the business case in more detail.

As we pointed out in various fora Enumservice PSTN may or _may not_ 
integrate with Infrastructure ENUM. How it is integrated is a "national 
matter" based on local policy involving LNP and who has access to that 
data under the relevant national policy.

The proposed RFC, today, has a great deal to do with the desire of some 
operators _right now_  to query a well known database about LNP data in 
IP friendly ( aka NO TCAP ) query response format.

If the softswitch/proxy can query for LNP data at call origination it 
can then signal the media gateway at the VoIP network edge what is the 
true route path is and thus eliminate an unnecessary and expensive TCAP 
queries and SS7/C7 PRI links.

TCAP - BAD   DNS - GOOD!

I do have hats these days btw.

The "well known database" is presumably "private" as we described in the 
draft however it may be a form of highly localized cached DNS server ( 
the IP-SCP if you want to call it that) inside the service providers 
network as well as a network based server.

Using high performance internal cacheing servers eliminates, in the 
opinion of some, considerable time in call setup operations. Vital 
milliseconds, especially in some IMS operations.

How that "well known database" is provisioned was outside the scope of 
this document.

This proposed RFC solves genuine network problems for VoIP softswitches 
today as well as tomorrow.

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<