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

[Jim Reid <jim at rfc1035.com>]

Richard, *please* fix your mail software. It is very annoying to get
needless base-64 encodings of UTF-8 that's actually just ASCII text.
Even more irritating is finding a mail tool to translate that encoding
back to ASCII so that your words of wisdom can be read. Grrr!

> I thought one big advantage of ENUM was that I save a lot of
> OPEX not having to manage weird routing tables.

So every operator having their own funky domain name populated with
stuff is somehow going to reduce costs? I don't think so. All that's
going to do is replace one set of weird routing tables with another. It
will also make it harder to merge or migrate those tables whenever
there's any sort of industry consolidation. Merging name spaces when
everyone's got their own ad-hoc ideas about naming conventions is just
awful. Try it. I have and still have the scars from that torture. That
pain will be zillions of times worse if/when these name spaces have
deployed DNSSEC.

> What you are trying to set up with your private e164.arpa tree
> is an adminstrative nightmare.

Oh give me a break! First of all, I just posted something off the top
of my head as a hypothetical example of how call routing could be
done. This isn't a blueprint for how it would be done. It's just one
of a number of possibilities.

As for administrative nightmares, your idea of each operator having
their own silver tree is far, far worse. For starters, it will mean
every bit of ENUM-aware software in the operator world is going to
have to have a table so it knows what domain name(s) to use for the
network the software is running on today. Please think about this.
Nothing that uses the DNS today does anything remotely so stupid.
And as for maintaining & distributing these tables.... What were you
saying about reducing operational expense?

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