FW: E.164 Resolution
Nancy-M.Greene.ngreene at NT.COM
Wed Sep 9 15:15:11 EDT 1998
I like to refer to a contribution - R. Scholl, "RFI: Requirements for Very
Large Scale E.164 -> IP Database", ETSI EP TIPHON 9, Portland, 31 Aug.-03
The findings of this contribution can be interesting to the ITU-T SG16 as
well. For example, "...The name space will eventually be completely flat. ..
A flat name space (or number space) facilitates number portability...This is
contrary to the hierarchical DNS or X.500 name sapce. .. a flat name space
does not necessarily mean a flat database architecture. .."
As we go forward for the H.323 addressing schemes, this paper might also
provide us some help in that direction.
Radhika R. Roy
> From: Pete Cordell[SMTP:pete.cordell at BT-SYS.BT.CO.UK]
> Reply To: Mailing list for parties associated with ITU-T Study Group
> Sent: Friday, September 04, 1998 2:37 PM
> To: ITU-SG16 at MAILBAG.INTEL.COM
> Subject: Re: No root node
> In general, to a first order approximation, I would expect a fully
> meshed arrangement of 'country' border elements. However I would see
> the fine detail of the structure being down to who people have
> arrangements for resolving addresses with. For example, BT might go to
> AT+T to resolve all North and South American numbers, and AT+T might
> come to BT for all European numbers. I could also see that
> opportunistic companies could set up global clearing houses that would
> handle address translation for outfits that haven't been able to
> establish their own knowledge of all the borders such as ISPs, or
> corporates. This would look like a root node to the people that used
> it, but it would be used purely as a commercial expedient and not
> mandated by the way the standard works.
> On the issue of France moving its entry point to Lyon for the week, I
> think we have to allow France to have more than one entry point. After
> all, Paris could all of a sudden slide into the Seine, and the press, if
> nobody else, would still want to make calls into France to find out
> what's going on. By having multiple entry points, the French can turn
> off their Paris BE for a while and switch on their Lyon one, and if the
> data didn't propagate around the system for a while it wouldn't really
> matter too much.
> Pete Cordell
> BT Labs
> E-Mail: pete.cordell at bt-sys.bt.co.uk
> Tel: +44 1473 646436
> Fax: +44 1473 645499
> >From: Santo Wiryaman[SMTP:swiryaman at VIDEOSERVER.COM]
> >Sent: 04 September 1998 17:29
> >To: ITU-SG16 at MAILBAG.INTEL.COM
> >Subject: Re: No root node
> >Hi All,
> >I am not at all opposed to eliminating the root domain. A couple of
> >questions for Pete and the group:
> >1. Are you suggesting that at the national level the border elements
> >are fully meshed together, or alternatively arranged in a big ring as
> >Radhika is suggesting?
> >2. If so, when a new country "goes on-line" endpoints in the new
> >country would not be reachable until the information is propagated in
> >this fully meshed database (or inserted in the ring).
> >3. Same if, say France, had to switch its National H.323 Border
> >from Paris to Lyons for one week.
> >4. Are you open to the idea of a global clearing house to resolve the
> >address of border elements of countries which are currently not listed
> >in the fully-meshed database.
> >Santo Wiryaman
> >From: Pete Cordell [SMTP:pete.cordell at BT-SYS.BT.CO.UK]
> >Sent: Thursday, September 03, 1998 10:20 AM
> >To: ITU-SG16 at mailbag.cps.INTEL.COM
> >Subject: No root node
> >Dear All,
> >Apologies for not being on the last call, but...
> >I feel one really important issue with Santo's contribution is that we
> >must remove the root domain. Having such a concept would give
> >politicians and lawyers far too much work!!! I believe the notes that
> >put forward would allow the root node to be removed, and based on
> >comments I heard from Jim, I believe what he is proposing would allow
> >this too.
> >Pete Cordell
> >BT Labs
> >E-Mail: pete.cordell at bt-sys.bt.co.uk
> >Tel: +44 1473 646436
> >Fax: +44 1473 645499
More information about the sg16-avd