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

[Jim Reid <jim at rfc1035.com>]

>>>>> "Richard" == Stastny Richard <Richard.Stastny at oefeg.at> writes:

    Richard> Sofar the story of public "User" ENUM in e164.arpa. The
    Richard> major problem of e164.arpa is that it is simply not
    Richard> available, so one may get the idea to set up the same
    Richard> principle just in another tree (temporarily?) (silver
    Richard> tree), so every operator may join with his number ranges.

Sorry Richard, this is too simplistic. Your so-called silver tree
could only work if all the operators reached a consensus on the domain
name of that tree and who got to operate and populate it. There's
probably about as much chance of that happening as I have of winning
Miss World. A unique and consistent naming scheme needs to be deployed
in order to avoid all sorts of confusion and bad practices that will
deter users and cripple the uptake of ENUM-based services. And as soon
as anyone starts talking about entering E.164 numbers into the DNS,
the usual government and regulatory issues raise their head. For
instance I cannot imagine the Chinese government agreeing to +86 going
under a registry operated in Austria. Or vice versa.

Maybe your silver tree could fly if all the VoIP providers and their
fellow travellers co-operated on setting this up. But so far all I see
are competing, mutually exclusive naming schemes which seem to be
about protecting market share or locking service providers and end
users into a vendor-specific solution. Getting co-operation seems
unlikely, even if there was agreement on who did what and how costs
were recovered. On top of that I can't see how VoIP provider A would
be comfortable exposing their customer's "phone numbers" in some
private, shared tree to VoIP provider B.

    Richard> I currently do not see a possibility to get all
    Richard> requirements for all 4 options workable in one tree.

Indeed. User and Infrastucture ENUM (to use those weasel terms) are
different things and cannot possibly exist in the same tree. They can
of course use the same domain name, but with different sets of name
servers providing different data to different constituencies: one for
the public internet and one for private telco-like usage. Since the
same sorts of applications are likely to live in both places -- ie
VoIP to SIP servers -- it would be sensible to use the same domain
name. That would avoid the messy complexity of applications having to
figure out where they are today to decide what domain name they should
lookup.

    Richard> There is no problem having two trees in parallel, a
    Richard> provider (or even the user himself) may query public User
    Richard> ENUM first and public or private Infrastructure ENUM
    Richard> afterwards.

I don't understand this. An end user should never, ever see a private
ENUM tree. Even if querying both trees was possible, how is the user
or application supposed to know which one holds the data it's supposed
to use? If my phone number is in both places each with 1 NAPTR record
pointing at different SIP servers, which one does the application
connect to? Now suppose one of those SIP servers lives deep in some
telco's net and is unreachable from another operator's net. Or the
internet. Or vice versa.

    Richard> Talking about two trees, of course there will be more
    Richard> trees at the beginning, but if every operator gets
    Richard> delegated only the numbers he is hosting, any two trees
    Richard> may be merged without any problem (if no transit routes
    Richard> are in).

This can never work. Number portability means block delegations to
operators will become increasingly fragmented over time. Delegations
will probably have to be made for individual numbers (or perhaps an
organisation's DDI block). If not, providers could use their control
over the end user's DNS content for all sorts of anti-competitive
practices. Like making it difficult to change the customer's
delegation to another provider.

FYI merging DNS trees is far from the simple exercise you seem to
think it is. Read on...

    Richard> This leaves the question of e164.arpa itself. For
    Richard> Infrastructure ENUM there is no need to go into e164.arpa
    Richard> and wait until hell freezes over until all countries have
    Richard> decided eventually to opt-in.

Wrong. Operators can (and probably should) use a private version of
e164.arpa today. This doesn't need any involvement in the Tier-0 and
Tier-1 stuff or ITU's interim procedures. e164.arpa is the IETF/IAB
agreed domain name for ENUM. It's neutral and not controlled by any
commercial interest or nation. So it's the obvious choice for the
unique and consistent naming scheme that Infrastructure ENUM
needs. There is no viable alternative. [BTW don't confuse the domain
name e164.arpa with its public expression on the internet today.] This
would also make it easier for operators to interwork and perhaps link
their private trees: ie nobody has to figure out the DNS gunk needed
to merge say enum.pulver.com with e164.at or enum.bt.intra.

    Richard> Sorry to say, but the same is valid for "User" ENUM. The
    Richard> proposal here is to set up a silver tree immediately by
    Richard> all interested parties, which may or may not be folded
    Richard> back to e164.arpa if it gets useful.  Countries already
    Richard> having e164.arpa implemented may be copied over to the
    Richard> silver tree in the meantime.

Richard, you should not be making statements like this. Merging trees
and migrating domain names is a very, very painful process. [I know
because I've done it. Have you?] Even for the most trivial of cases in
controlled environments, this exercise is difficult, time-consuming
and all too easy to get wrong. In an ENUM world with as little as a
few hundred individually managed zones, migrating or merging them will
be effectively impossible. Now scale this to say a few million
delegations... For bonus points, deal with zones that have NAPTR
records pointing at URIs inside the tree that's being merged.

Please remember that once a domain name is registered and gets used,
it lives forever in things like application software, configuration
files, address books, search engine databases, web links, documents &
stationery, web browser bookmarks, etc, etc. Once someone starts
populating phone numbers or whatever under RichardsSilverTree.at,
they're going to be pretty much stuck with that until long after hell
freezes over. I sometimes still get email sent to an address I stopped
using 10+ years and 5 jobs ago.

This is one reason why there needs to be considerably more thought
about the choice of domain name for Infrastructure ENUM. You seem to
be saying that any old name can be used and moved elsewhere at some
point in future with a wave of a magic wand. It's not going to be that
simple. It can't be. Trust me on this. I've done fairly big domain
name migrations/mergers and know just how hard this is to do. It's
even harder when trying to maintain continuity of service. And harder
still when you've no idea what applications are out there and what
they look up or how they'll break if their favourite domain names get
changed. 

I think we agree there must be a single, consistent name space for
Infrastructure ENUM. The question then becomes one of implementation:
what domain name is used and how it gets realised. This is orthogonal
to what happens with the public e164.arpa name space. Please don't
confuse these two things even if the same domain name happens to apply
to both.

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