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

[Jeff Williams <jwkckid1 at ix.netcom.com>]

Jim and all,

Jim Reid wrote:

> >>>>> "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.

  Good point here Jim, and of course your right IMHO.  Oh and I prefer the

Miss Nude World contest of which I have again been ask to be a judge.  >:)

But I am sure you would not qualify for that contest either, or at least I
hope
you wouldn't!  >:)

> 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.

  I don't see a chance of this happening either..

> 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.

  Very well stated points here Jim!  Well done.  And this in part was
my and our members concerns with publicly viewable or available
Assigned ENUM's to users.

>
>
>     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.

  Yes this was discussed some time ago, and also remained relatively
unsolved, so that subject line was dropped...  Glad you brought it
back up though here.

>
>
> 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.

  Do you mean an agreed upon TLD for ENUM here?

> 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 need
> 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

Regards,

--
Jeffrey A. Williams
Spokesman for INEGroup LLA. - (Over 134k members/stakeholders strong!)
"Be precise in the use of words and expect precision from others" -
    Pierre Abelard

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security
IDNS. div. of Information Network Eng.  INEG. INC.
E-Mail jwkckid1 at ix.netcom.com
 Registered Email addr with the USPS
Contact Number: 214-244-4827



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