You are here: Home > Participate > Join a Discussion > Mailman Archives
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: RE : data point - anonymous E.164 number usage

  • From: "Pat Walsh" < >
  • Date: Wed, 3 Mar 2004 14:57:12 -0000

I think the combination of Richard's excellent explanation of the
numbering requirements and Staffan's subsequent conclusion says it all.
Identification and validation are basic requirements but need not be
made into huge hurdles - while the specific number range(s) selected
(geographic, mobile, personal, special new range ...) may well influence
the level of complexity. Validation/identification via a SIM card and
PIN may well be all that is needed. 

The ENUM domain has a direct dependency on the E.164 number
and the regulatory rights and obligations for the former would be seen
by a Regulator as essentially the same as for the latter. Not to put too
fine a point on it, the user-specific digits in the domain are
no more than a manipulation of the E.164 number, the rights of use of
which are assigned to some (and necessarily the same)specific person. 

Concerning a proposal in an earlier message that appeared to suggest
carte blanche to be possible with E.164 numbers, I believe this is
wishful thinking. The E.164 resource works effectively and regulators,
while wanting to minimise bureacracy and facilitate new developments,
are unlikely to simply allocate numbers from this resource without
conditions being attached to the rights of use. 


Pat Walsh - ComReg

Message: 1
Date: Sun, 29 Feb 2004 18:03:53 +0100
From: Staffan Hagnell shl@localhost
To: Stastny Richard <Richard.Stastny@localhost
Cc: Olivier.Girard@localhost, jim@localhost,
	ag@localhost, jseng@localhost, enum-l@localhost,
	enum-trials@localhost, enum-trial@localhost
Subject: Re: RE : data point - anonymous E.164 number usage

Could a conclusion be that -
1. Identification and validation of an E.164 Subscribers is not handled 
uniform, but rather different for different types of services in 
different countries.
2. The requirement on identification and validation of an ENUM 
Subscriber is not supposed to be less then the identification and 
validation made for the corresponding E.164 Subscribers (doing the same 
type of transaction, e.g. registration)
--> the same type of identification and validation could be considered
sufficient for administer an ENUM Subscriber as is used when administer 
the corresponding E.164 Subscriber.
E.g. if showing a SIM card is considered to a proper requirement for 
identification and validation of an E.164 Subscriber, it could also be 
considered a sufficient requirement for identification and validation of

an ENUM Subscriber!
Of course, it would be nice to have a single solution for identification

and validation of all ENUM Subscribers (but I am skeptical to the 
possibilities that there will be such one in the short run).


Stastny Richard wrote:

>I fully agree with Olivier:
>We have here two complete separate problems:
>1. Identification required to get an E.164 number.
>This is a problem that has nothing to do with ENUM and should be kept
>completely separate. That prepaid cards are given out in some (most)
>without proper id is NOT an ENUM problem.
>If some legal entity wants to get the identification of a person or 
>entity assigned an E.164 number, it should use the existing 
>infrastructure. This is also holds if they want to know the identity 
>holding an domain related to this number if no contact 
>information is available.
>ENUM is not here to solve OPPs (Other People Problems)
>2. The only thing that ENUM needs to provide is consistency in the 
>E.164 name space, that is: a domain shall only be delegated 
>if and only for the period of time the associated E.164 number is 
>assigned to a person or entity and it shall be delegated to the SAME 
>person or entity.
>As Olivier shows this does not necessarily require to reveal the entity

>of the person,
>especially not on mobile phone if you use the access to the
identification token
>(e.g a SIM-card), but there ara also possibilities for fixed lines.
>For regulators, they should only state the requirement and not the 
>procedure how to do this, because you can do this in many different 
>ways. They will of course have the right to check a given procedure if 
>it complies to the requirement given.

  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>