Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03

Otmar Lendl <lendl@nic.at> Fri, 05 January 2007 12:29 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oCF-0000YF-OD; Fri, 05 Jan 2007 07:29:19 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1H2oCE-0000YA-EV for enum@ietf.org; Fri, 05 Jan 2007 07:29:18 -0500
Received: from fardach.bofh.priv.at ([88.198.34.164] helo=mail.bofh.priv.at) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1H2oCD-0007vO-5Q for enum@ietf.org; Fri, 05 Jan 2007 07:29:18 -0500
Received: by mail.bofh.priv.at (Postfix, from userid 1000) id 92EE44C3BF; Fri, 5 Jan 2007 13:29:16 +0100 (CET)
Date: Fri, 05 Jan 2007 13:29:16 +0100
From: Otmar Lendl <lendl@nic.at>
To: enum@ietf.org
Subject: Re: [Enum] NITS review of draft-ietf-enum-infrastructure-03
Message-ID: <20070105122912.GA24574@nic.at>
References: <45AEC6EF95942140888406588E1A66028D2215@PACDCEXCMB04.cable.comcast.com> <20070102111424.GI5435@finch-staff-1.thus.net> <785A120B-9D8F-4928-8128-CBDB7EB1DDD4@insensate.co.uk> <20070104164240.GN98464@finch-staff-1.thus.net> <20070105113718.GB24048@enum.at>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20070105113718.GB24048@enum.at>
User-Agent: Mutt/1.5.13 (2006-08-11)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465
X-BeenThere: enum@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Enum Discussion List <enum.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:enum@ietf.org>
List-Help: <mailto:enum-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/enum>, <mailto:enum-request@ietf.org?subject=subscribe>
Errors-To: enum-bounces@ietf.org

On 2007/01/05 12:01, Otmar Lendl <lendl@nic.at> wrote:
> 
> But it's a fact that we run an officially sanctioned I-ENUM trial
> here in an EU member state.

Two more points on this:

* If the mapping "Telephone number" -> "provider" is one you're
  worried about being public, then Austria already has that 
  problem with all mobile numbers:

  The block allocations to carriers are simple, published, and 
  well known to the public. (e.g. +43 664 -> Mobilkom, +43 676
  -> T-Mobile, ...)

  If someone ported a number from one carrier to another
  then an announcement indicating the new carrier is played 
  every time such a number is called.
  
  That announcement was necessary as tariffs depend on the
  destination network, thus with MNP, consumers could
  no longer derive the tariff by simply looking at the
  number.

  The upshot is: it's trivial to find out which mobile
  carrier services a certain number.

* Maybe we need to stress one point from 
  draft-ietf-enum-infrastructure-enum-reqs-03 which
  is not mentioned in draft-ietf-enum-infrastructure-04:

>From "2.2.  Background"

| There is also no guarantee that the originating service provider
| querying infrastructure ENUM is able to access the ingress network
| element of the destination provider's network.  Additional peering and
| accounting agreements requiring authentication may be necessary.

  In other words: the information found in the public I-ENUM
  tree (e.g. +43123456789@sip.example.net) does not enable
  anybody and his dog (and Nigerian spammers) to call that number
  directly from his robo-call Asterisk box using SIP.

  If you're no carrier with an established peering relationship
  with "example.net", then you gain next to nothing by knowing
  the mapping +43123456789 -> +43123456789@sip.example.net.

/ol
-- 
< Otmar Lendl (lendl@nic.at) | nic.at Systems Engineer >

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