Subject: RE: [Enum] ENUM interworking

From: "Pfautz, Penn L, NNAD" <[email-masked]>
Date: Wed, 31 Oct 2001 11:27:38 -0500

See PLP: below

Penn Pfautz

-----Original Message-----
From: David R. Conrad [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 11:11 AM
To: Kevin McCandless; [email-masked]'
Cc: [email-masked]'; Bob Wienski
Subject: Re: [Enum] ENUM interworking

Kevin,

At 07:30 AM 10/31/2001 -0800, Kevin McCandless wrote:
>After having my ENUM in box full of religious debate I began to wonder if 
>this is the technical department?

Clearly not, but we can try...

>The ENUM Forum that just recently met in Kansas discussed this issue.  We 
>first discussed the use of CNAME records at Tier 1 under 
>RFC2916.  Representatives from both VeriSign and Registrar.com said that 
>this is very burdensome on a database because it would require a double 
>look up every time.

I'm not clear on how CNAME records would be used in this context.  Can you 
explain in more detail?  I'd agree, however, that the use of CNAME could 
result in double lookups (when there are cache misses of course).

PLP: The idea seemed to be that the e164.arpa Tier 1 would have a standard
NS record pointing to the alternate
registry. This would cause the query to be made to that registry  with an
e164.arpa domain, i.e. <phone_number_backwards_with_dots>.e164.arpa. Since
the presumption is that the alternate registry stores its NAPTR under a
proprietary domain, e.g. joesenum.com, there would be a CNAME record in
the alternate registry that would cause a new query to be done on
<phone_number_backwards_with_dots>.joesenum.com.

>The easiest approach would be to have a resolver for the client.  This 
>resolver would be capable of searching multiple domains for the E.164 
>number.  If one is merely trying to obtain NAPTR records for anything but 
>call setup the resolver approach should work fine.

Unless the same E.164 number is registered in multiple domains in which 
case the resolver will need some heuristics to try to guess which response 
is correct.

>An issue we should be aware of is if ENUM is used for call setup and the 
>resolution of multiple domains takes a large amount of time then this 
>would not be an acceptable delay for the call completion.

This makes the assumption that it is only call setup that is time 
constrained which I'm not sure is a safe assumption.

There are two ways to handle the multiple domain queries, either serially 
or in parallel.  If you make the assumption that the first (positive) 
answer you get back is acceptable, then the parallel approach will not 
differ significantly in time than the lookup in a single domain.

>Circuit switched calls are considered toll grade if they are set up under 
>250ms.  That is a target we should keep in mind if we expect ENUM to be an 
>enabler of call setup and be rooted in multiple domains.

Or in single domains...

Rgds,
-drc

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

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