AW: ENUM Privacy (was RE: [Enum] User ENUM vs Operator ENUM)

["Stastny Richard" <Richard.Stastny at oefeg.at>]

Jeff Williams writes:
>And this to a very great degree is what is wrong with the standards
>track with ENUM.  Both opt-in and Opt-out should be incorporated.

They did. The ENUM protocol as defined in IETF can be implemented
in both ways, athough NOT in the same tree, because the both options
are mutually exclusive.

Let me explain: Opt-in means that at the beginning nobody is in and the
end-user decides if he wants to be in to get this service. This is the case
with User ENUM, which is an add-on service. The underlying service
is his phone service and this phone service is working regadless if
he is in ENUM or not (with the exception of ENUM-enable numbers,
which are operating only if you are in User ENUM, but nobody is
forced to use these numbers)

The end-user has the additional choice how much information he
discloses: the minimum requirement is the number itself and the
operator, if he puts in e.g. sip:+43xxx at provider.net. Additional
information between caller and callee may be exchanges via
negotiation between servers (as in SIP) or Personal User Agents
as proposed in UCI. The end-user may also decide on his discretion
to put in more information as he likes, especially a company.

Opt-out would mean that everybody is in and the end-user decides not
to be in. If a provider decides to implement the basic communication service
based on ENUM, he MUST put all users using this service in ENUM.

Using ENUM for a service is currently also opt-in, but for the provider as
a whole with all of his numbers. There is no opt-out for the individual
end-user.  This is called Infrastructure ENUM. It uses ENUM technology,
but in separate tree. It is opt-in currently because there is still the PSTN around
to reach providers not in Infrastructure ENUM by default. If the PSTN ceases 
to exists at some point of time, another default method need to be defined if
E.164 numbering is still around. This may be ENUM or maybe not.

Up to this point of time, different trees may be used by different groups
of service providers (confederation), this is already happening. A service 
provider may even participate in different trees at the same time.

 These trees may either be trees only accessible by participants of the 
confederation (either in extranets or with access control), but not
on the public Internet, or if accessible by the public, the information
is either not accessible, encrypted or useless for the normal end-user.

There is also a difference between the information contained in
the trees. 

In User ENUM the information points to end-points,
giving one ore more URIs where the end-user has his services.
Different NAPTRs may point to different service providers.
The domain name holder is the end-user.

In Infrastructure ENUM the entry points in principle to
the destination network providing the service for this number.
The domain name holder is the service provider.

All this together precludes User ENUM and Infrastructure
ENUM to be in the same tree (even the delegation structure
may be differnent).

Of course User ENUM and Infrastructure ENUM may co-exist,
any user listed in one or more Infrastructure trees may also
request an entry in User ENUM. The provider may also offer
to the calling customer a service in such a way that first User 
ENUM queried and then Infrastructure ENUM. This is already
implemented in some SIP servers and works. (Note: why should
the provider do this? Because the user may do this by himself also.
It is kinda carrier selection ;-)

ETSI is currently drafting a TS 102 055 on Infrastructure ENUM
explaining all these issues.

BTW: there is one complication emerging at the moment:
Confederations also want Infrastructure ENUM to be used
for routing of transit calls, e.g. an provider is publishing number
ranges in a confederation tree he is serving on the PSTN with his
gateways. This is in principle feasable, but will cause serious problems
in the future, especially if two confederations decide to merge there
trees. If one numbers are entered by providers which are assigned
to them, no conflicts could arise if trees are merged.

If numbers are entered by providers not assigned to them, this
will cause policy problems and conflicts. These conflicts cannot
be resolved in ENUM, because it is not designed for it. Other
protocols like TRIP or OSP should be used for this.

Richard:
To Jeff: You know what my problem with all privacy advocates is?

They are trespassing my privacy by trying to limit my freedom of decision,
including my human right to make idiotic decisions ;-)




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