RE: [Enum] Re. 2916bis

Patrik Fältström <paf@cisco.com> Wed, 20 February 2002 22:27 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22331 for <enum-archive@odin.ietf.org>; Wed, 20 Feb 2002 17:27:42 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA25647 for enum-archive@odin.ietf.org; Wed, 20 Feb 2002 17:27:46 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25080; Wed, 20 Feb 2002 17:18:42 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA25050 for <enum@optimus.ietf.org>; Wed, 20 Feb 2002 17:18:40 -0500 (EST)
Received: from cisco.com (nordic.cisco.com [64.103.48.45]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22109 for <enum@ietf.org>; Wed, 20 Feb 2002 17:18:35 -0500 (EST)
Received: from [0.0.0.0] (ssh-ams-1.cisco.com [144.254.74.55]) by cisco.com (8.8.8+Sun/8.8.8) with ESMTP id XAA20620; Wed, 20 Feb 2002 23:17:59 +0100 (MET)
Date: Wed, 20 Feb 2002 23:03:14 +0100
From: Patrik Fältström <paf@cisco.com>
To: "Yu, James" <james.yu@neustar.biz>, 'Lawrence Conroy' <lwc@roke.co.uk>
cc: enum@ietf.org
Subject: RE: [Enum] Re. 2916bis
Message-ID: <2852914.1014246194@localhost>
In-Reply-To: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com>
References: <23309E398D84D5119D0F00306E075139ECEC5C@dc02.npac.com>
X-Mailer: Mulberry/2.1.2 (Mac OS X)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
Sender: enum-admin@ietf.org
Errors-To: enum-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Enum Discussion List <enum.ietf.org>
X-BeenThere: enum@ietf.org
Content-Transfer-Encoding: 7bit

--On 2002-02-20 15.38 -0600 "Yu, James" <james.yu@neustar.biz> wrote:

> 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)

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


_______________________________________________
enum mailing list
enum@ietf.org
https://www1.ietf.org/mailman/listinfo/enum