Re: RE : data point - anonymous E.164 number usage
- 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 e164.arpa 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 e164.arpa 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.
Regards
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).
Regards,
-Staffan
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)
countries
>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 e164.arpa 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 e614.arpa 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.
>
>
[cut]
