Subject: [Enum] Re: Human readable Route descriptors

From: "Matt Squire" <[email-masked]>
Date: Wed, 10 Nov 1999 12:28:43 -0500

One problem that arises when you think about putting this type of
information into TRIP is that TRIP is **not** global.  What I mean is that
the TRIP framework specifically indicates that TRIP is used within
confederations, and that not all confederations are interconnected.  

What you seem to need is a global directory that is shared among all
providers - this is not TRIP. It would definitely be useful, but I don't
think it fits here.

- Matt

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 11 Nov 1999 12:12:48 -0500

An interesting issue is that there is a proposal in enum to turn
+1 603 884 2235 to a DNS entry that looks something like:
5.3.2.2.4.8.8.3.0.6.1.enum.int

Observe that if I reserve the block +1 603 884 2000-2500,
that a query of any number in the block using the above 
scheme will work.

However, what if I query:
2.4.8.8.3.0.6.1.enum.int

What do I get?  Foo owns +1 603 884-2000, but does not own
+1 603 884-2667.  The problem is that dns is heirarchical,
but using a subdomain per digit doesn't capture what happens.

Brian  

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Wednesday, November 10, 1999 10:17 AM
> To: Jon Steer
> Cc: [email-masked]; [email-masked]
> Subject: Re: Human readable Route descriptors
> 
> 
> 
> 
> Jon Steer wrote:
> > 
> > At 11:55 PM 11/9/99 -0500, Jonathan Rosenberg wrote:
> > 
> > > This function is useful, but I'm not sure it needs to be in TRIP.
> > > The
> > > mapping from +1 603 to a name for that area code is not 
> dynamic, nor
> > > different from provider to provider.
> > 
> > But what is dynamic is an enterprise phone destination
> > for example when a company buys a large block of 1603884
> 
> Perhaps dynamic is not the right word. I agree something like 
> that needs
> to be covered. The difference is that if company foo buys 
> 1603884, this
> number is mapped to foo for everyone that asks. TRIP is great at
> distributing information with parameters that are different for
> different peers. What you want to do can be done using a global (with
> updates) directory service, which is exactly what enum is.
> 
> 
> 
> > 
> > > One could actually have a global
> > > database, where you look up a phone prefix, and get out a textual
> > > name.
> > 
> > Those exist already, however, they cannot be dynamically added to
> > when new blocks of numbers are allocated (i.e. new area codes or
> > new large enterprise blocks of numbers).
> 
> Whilst the enum group won't address how updates take place, certainly
> the database itself won't be useful if it can't be updated. DNS can
> certainly be updated; the timescales of the updates we need for this
> service are doable using administrative updates, as opposed 
> to real time
> protocol based updates.
> 
> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com
> 
> ---------
> This message came from the IETF IPTEL Working Group Mailing List.
>

---

From: "Jeff Hinchey" <[email-masked]>
Date: Thu, 11 Nov 1999 15:03:45 -0600

-----Original Message-----
From: Jon Steer [mailto:[email-masked]]
Sent: Wednesday, November 10, 1999 5:11 PM
To: Stephen Sprunk; Jonathan Rosenberg
Cc: iptel; enum
Subject: [Enum] Re: Human readable Route descriptors

[jh] text deleted
 
This presumes that all E.164 addresses that TRIP advertises are RBOC telco
visible and not
a private numbering system perhaps implemented by an ISP.

[jh] For clarification purposes, E.164 defines the global public number
plan. It does not encompass private number plans/numbers. A given number is
unique within E.164 but could also be used in one more private number plans.
If TRIP is to support resolution of private numbers in addition to public
numbers, then the DNS hierarchy must include a top level number plan key.
 
For example:
 
7.0.0.8.3.6.7.3.1.6.1.e164.enum.int
 
7.0.0.8.3.9.3.acme.enum.int

---

From: "Matt Squire" <[email-masked]>
Date: Fri, 12 Nov 1999 13:10:12 -0500

>but using a subdomain per digit doesn't capture what happens.

I'm not sure I understand the problem Brian.   So foo owns/rents
1-603-884-2000 thru 1-603-884-2499.  
  4.2.4.8.8.3.0.6.1.e164.int  => foo.com
  3.2.4.8.8.3.0.6.1.e164.int  => foo.com
  2.2.4.8.8.3.0.6.1.e164.int  => foo.com

If +1-603-884-2 is not allocated by the owner of +1-603-884, then the query
will fail and rightfully so.  If it is allocated, then there should be a
record (to someone other than foo).  I guess I'm just missing your concern.  

The representation is a bit verbose, but I think it works.  By verbose, I
mean that if, say, the US govt allocated numbers in 3 digit chunks (area
codes), it would have to have dummy entries like for the first and second
digits of the chunk, ie
 4.8.8.3.0.6.1.e164.int => someone (legit chunk)
   8.8.3.0.6.1.e164.int => us.gov (dummy)
     8.3.0.6.1.e164.int => us.gov (dummy)

How the owner (in this case us.gov) decided to answer queries about such
'invalid' prefixes would be within its domain.  Is that not ok?

Or are you suggesting something like
 884.603.1.enum.int
where the domain strings represent the current e164 heirarchy (3 digit area
codes in US, etc.)?  This has the effect of placing the burden of knowing
the e164 heirarchy on the user who queries, and that seems undersirable.  

What am I missing?

- Matt

---

From: Richard Shockey <[email-masked]>
Date: Mon, 15 Nov 1999 16:08:59 -0600

>within its domain.  Is that not ok?
>

This is a very difficult problem and I'm not sure I like what this 
statement implies. IMHO any solution should attempt to avoid at all costs 
the necessity that user/client have prior knowledge of the 164 structure. 
Unfortunately the 164 structure has no "global order" to it that permits 
decoding the various elements based solely on the presentation of the digits.

The hope is that a solution is sufficiently simple to permit embedding in 
multiple classes of devices scaling from "Internet Telephone", to PBX 
switch ..ultimately to carrier provided service models.

Richard Shockey
Shockey Consulting LLC
8045 Big Bend Blvd. Suite 110
St. Louis, MO 63119
Voice 314.918.9020
eFAX Fax to EMail 815.333.1237 (Preferred for Fax)
INTERNET Mail & IFAX : [email-masked]
GSTN Fax 314.918.9015
MediaGate iPost VoiceMail and Fax 800.260.4464
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<