Subject: RE: [Enum] New DNS record class values?

From: Sören Nyckelgård <[email-masked]>
Date: Thu, 20 Jan 2000 02:51:08 +0100

> >The ENUM requirement draft says that "The system MUST 
> support existing local
> >number portability mechanisms" and should not "impede future 
> global number
> >portability" So, does the solution above support number portability?
> >
> >Well, the NAPTR record can rewrite a dialed number and, for 
> instance, add a
> >routing prefix. However, global routing prefixes are seldom 
> appreciated by
> >SCN operators since they often interfear with local number 
> plans and local
> >routing prefix schemes. It's probably better to specify the 
> terminating SCN
> >operator explicitly and let the operator map it to locally 
> significant
> >routing information. The NAPTR record might then look 
> something like this:
> >
> >   SC NAPTR 102 10 u potscall+N2R "" [email-masked].
> 
> Now this is also very interesting. In private conversations 
> I've heard talk 
> about the possibility of the DNS record actually carrying the LRN [ 
> Location Routing Number ] for the terminating switch or 
> somehow creating a 
> pointer to a database [LDAP?] for retrieving that data.
> 
> In your opinion what might be the best approach to this?

I don't think one approach excludes the other. It's rather a matter 
of optimization: 

a) We might impose too much delay in the call setup process if we 
first use the DNS to locate an LDAP server, which we then query for 
the termination point information (LRN in America). Users seem to 
accept more or less delay depending on which kind of network they are 
connected to. GSM and IP-telephony users are fairly tolerant whereas 
PSTN and ISDN users are not.

b) If an E.164 number identifies a terminal such as a phone or a fax, 
then the termination point information is fairly static and could be 
carried by the DNS record (record format TBD). If instead the E.164 
number identifies a user that might move between different terminals, 
then the DNS record preferably should point to an address data 
repository that can be dynamically updated. 

My oppinion is hence that the DNS should support both alternatives. 
The usage of the number determines if the DNS record shall carry the 
termination point information itself or reference a service like LDAP.

I noted that you put a question mark after LDAP in your question above. 
A press release from last year signed Telia and Nortel mentions both
"Number Portability" and "SIP". I can't yet reveal any details but
you are of cause free to use your imagination :-) 

---

Sören Nyckelgård, Telia Research

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 20 Jan 2000 06:54:20 +0100

--On 2000-01-20 02.51 +0100, Sören Nyckelgård <[email-masked]>
wrote:

> If instead the E.164 

Or, we update the DNS to hold the correct record. I.e. it all depends on
what timeframes you talk about. DNS refresh values which are minutes is no
problem at all. Seconds are a problem because of cacheing. I.e. having
inconsitencies over a few minutes is not (today) so strange.

But, when I leave the office and redirect my phone to the phone switch, it
still takes me a few minutes to grab all my stuff and actually leave the
building, so a few minutes delay is no problem for me.

That said, DNS will NOT be able to be updated atomically, but neither will
a distributed/replicated LDAP solution. Forcing always a query to the
authoritative source will be costly, regardless of protocol (but of course
more problematic in DNS because of client-side cacheing).

So, as long as one _know_ what delays the protocol inject in the resolution
process, it is possible to build services which match those services.

    Patrik