Subject: RE: [Enum] Re. 2916bis

From: "Yu, James" <[email-masked]>
Date: Wed, 20 Feb 2002 15:38:50 -0600

For (iii), one good example is a non-geographical number (e.g., toll free
number) that is mapped to a POTS number (geographical number).  There may be
a "need" to re-submit.

It is possible to retrieve a tel URL with TN#B via ENUM on TN#A.  It
certainly is fine to do ENUM lookup on TN#B.  But this process can go on if
in the worst case a tel URL is the only URL retrieved via ENUM.  The
application should set a limit to such re-submissions.

We need to be careful about putting tel URL in the ENUM NAPTR RRs.   This is
because a U.S. TN being mapped to a Russian TN may cause charging issue
especially when that Russian TN is a PSTN TN (e.g., call must be terminated
via gateway into the PSTN in Russia).  The caller in the U.S. dials a U.S.
TN and expects to pay a domestic long distance (or even local) rate for the
call.  But what if this TN is mapped to a Russian TN via ENUM in the IP
domain?   Must the caller pay an international call rate?  The caller
certainly will argue that he dialed a local/domestic TN.   Someone may argue
that the "called party"  (e.g., ENUM registrant) should pay for the "call
forwarding/delivery."   But the problem is that the one that performs
ENUM/DNS query may not have any relationship with the "called party;"
therefore, it won't be easy to bill that "called party."  

So any valid TN can appear in the tel URL in the NAPTR RR, I see several
possible ways of handling that particular tel URL (TN) if the TN will cause
charging issue (a U.S. TN mapped to a Russian TN)

- If the caller's phone did the ENUM query, it can warn the caller about the
TN change.  If it is a service provider that did the ENUM query and it has
billing relationship with the caller or can bill the caller directly or
indirectly, it can inform the caller about the increase of the call charge
and give the caller the choice to accept/deny the call.  
- Don't route to that TN.  Continue routing using the previous TN.
    
James

> -----Original Message-----
> From: Lawrence Conroy [mailto:[email-masked]]
> Sent: Saturday, February 16, 2002 12:23 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Enum] Re. 2916bis
> 
> 
> At 8:59 pm +0100 15/2/02, Patrik Fältström wrote:
> >I have here compiled a list of things to be changed to RFC 2916 when
> >2916bis is created.
> <snip>
> >(8) Examples must be corrected and made made clear. For 
> example, there
> >should be absolutely no confusion about (?that?) full regular 
> >expressions are used.
> >I.e. any delimiter and any matching mechanism can be used
> 
> To which I reply:
>     I am having major trouble (apart from just reading the 
> DDDS collection :)
> in finding answers to the following questions:
> (i)   Is there ever a need to have anything other than a "complete 
> replacement" as the rule substitution expression when applying an 
> ENUM query to the e164.arpa domain space?
> 
> [Point (8) suggests that there is a need for full regular expressions 
> - I can't think of a case where this is needed.]
> 
> (ii)  Is there ever a need to use a non-terminal NAPTR record when 
> dealing with ENUM (e.164.arpa domain space) records?
> 
> (iii) RFC2916 states that tel: URIs should be re-submitted to the 
> ENUM system, and that the Client is responsible for loop detection.
> 
> Richard has suggested that this is not needed; a tel: URI should NOT 
> be re-submitted. On reflection, I agree with him - I can't think of a 
> particular reason why such a re-submission is needed either - can 
> anyone else think of a case?
> 
> [If not, the required tel: flag document is not too hard, and there 
> may not *be* a problem with loops - it also solves Jon's concerns 
> from the sipping-e164 document, I think :]
> 
> best regards,
>     Lawrence
> -- 
> [email-masked]: +44 1794 833666::<my opinions>:
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

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

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 20 Feb 2002 23:03:14 +0100

--On 2002-02-20 15.38 -0600 "Yu, James" <[email-masked]> wrote:

> possible ways of handling that particular tel URL (TN) if the TN will
> cause charging issue (a U.S. TN mapped to a Russian TN)

You might have the same cost issues when you end up being gatewaying from
one protocol (cheap) to another one (expensive).

So, it is always important when doing gatewaying like this that even if the
NAPTR have a priority that the called party can set, the calling party or
someone which act on behalf of the called party _have_to_ apply a policy
for what he accepts.

In the IETF we say quite often that we have during the years developed
quite a large number of guns, but just because I have one in my hand, I
don't have to shoot myself in my left foot.

Yes, misconfiguration of NAPTR for ENUM might create problems.

Text about these things should go into the security consideration section
of relevant documents. I can add something general in the 2916bis, but you
who work with individual other things also have to think about these things.

  paf

---

From: Jim Reid <[email-masked]>
Date: Wed, 20 Feb 2002 16:26:14 -0800

Forgive me, but could someone please explain why we need to say
anything about NAPTR records in 2916bis? I thought this document
defined a protocol for mapping E.164 numbers into domain names.

---

From: Lawrence Conroy <[email-masked]>
Date: Thu, 21 Feb 2002 04:51:46 +0000

>number) that is mapped to a POTS number (geographical number).  There may be
<snip, answered nicely by Patrik>

To which I reply:
   That was my initial thought, but I have been convinced that CNAMEs work
quite well in most circumstances. If you want to just do a Non-Geo number
translation, I think that you can just put a CNAME to the "real" number.
(Thanks to Richard Stastny & Patrik for that one).

In this case, there is no need to re-submit on receipt of a tel: URL,
as you won't get there until the NS and CNAMEs have been processed,
transparent to DDDS.

If anyone DOESN'T think that CNAMEs can be used, please holler.

best regards,
    Lawrence

---

From: Richard Shockey <[email-masked]>
Date: Thu, 21 Feb 2002 11:23:33 -0500

>If anyone DOESN'T think that CNAMEs can be used, please holler.

Yes but we have previously had discussions (pittsburg i recall) that the 
use of CNAME and DNAME are very dangerous if not configured correctly and 
as we know  the vast majority of DNS errors are in configuration.

Its not that you cant do this ..its just that you have to be very very 
careful and there was consensus before that doing this within the root 
domain e164.arpa is a "bad thing".

I'll let randy comment further if necessary.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Feb 2002 09:30:04 +0100

> as we know  the vast majority of DNS errors are in configuration.

Let me phrase this differently:

ENUM "just" use the DNS for storage of data. Because of this, the resolver
which looks up the NAPTR resource records have to be conformant with
relevant DNS related RFC's -- which might be updated over time.

We already know the DNS people talk about EDNS0, DNSSEC, IPv6 transport,
TKEY, Dynamic Updates, packet size adjustments etc etc.

The whole key of (re-)using DNS is that we in this wg don't have to worry
about it.

That we talked about CNAME and DNAME was just because in informal
communication with DNS people we have understood that _they_ recommend
people _not_ to use DNAME at all, and CNAME only when the "link" crosses
administrative boundaries.

But, once again, this is a DNS issue, and should be discussed in the DNSOP
wg in the IETF.

I.e. if you are interested and maybe even worried about DNS operations, you
should go to _that_ working group.

Here we only use DNS as a storage location and we take for granted that the
DNSOP and DNSEXT working groups will do their job.

     paf