You are here: Home > Participate > Join a Discussion > Mailman Archives
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: ETSI on Minimum Requirements for European ENUM Trials

  • To: David Conrad < >
    Jim Reid < >
    Stastny Richard < >
  • From: Richard Shockey < >
  • Date: Thu, 24 Oct 2002 10:46:40 -0400

At 06:59 PM 10/23/2002 -0700, David Conrad wrote:
Richard,

On 10/23/02 12:20 PM, "Richard Shockey" richard@localhost wrote:
> So why isnt .COM .NET and .ORG signed?  .UK .DE .US ???

"Signing large zones is painful" is the usual answer.  "Business reasons"
(in particular, the lack of increased revenue justifying the additional
cost) and "because no one is asking for it" are also common responses.
I know .. and IPv6 requirements IDN , the list is rather large .... there is a lot on the plate of TLD operators generic and CC ..as you well know my employer runs two of them.

I would say that given the current climate DNSSEC and IPv6 certainly top the list.


Neither of these need apply in the case of ENUM trials.

I do not believe it would be prudent to give people the impression that
DNSSEC is optional for actual ENUM deployment.
I do not want to give that impression either ..but that said. I"m hoping we can maintain focus and "eyes on the prize" in which is a new generation of telecommunications services globally deployed.

I worry that some will use the DNSSEC issue to delay or stall ENUM deployments by arguing .."Well if you cant deploy DNSSEC..you cant deploy ENUM" and I do not believe that is true. I dont like the two issues so closely linked.


> NO ... its probably talking out of class for here but IMHO it is WAY WAY to
> early to even suggest DNSSEC as part of any TRIAL... where are the client
> support ...in MS?

Client support is in validating caching servers, e.g. BINDv9 or other
servers.  BINDv9 runs on Win32.

> and grossly complicate the basic ENUM services trial itself IMHO.

Compared to the complexity of NAPTR record parsing (or even reading the
RFCs), DNSSEC is easy... :-).
Mike Mealling is going to get you for that one .. :-) touche'


More seriously, the point (IMHO) of operational trials is to get an idea of
the operational issues people will face with deployment of technology.  As
dealing with DNSSEC is an operational issue, it would seem to me to be
important to include this in any trial.
ACK ... but thats not my point. Its the linkage issue ... its as much a political problem as a technical one. I much more interested at this point with beginning to see how cross-domain call setups will operate w/ SIP and H.323 and the metrics associated with them. What kinds of cacheing ENUM data do we need to look at and root e164.arpa data etc. I'm my mind the DNSSEC issue is putting the cart before the horse.


> Who says any one will "have" to use it in a production service.

Err.  So, you are suggesting that telephone numbers be susceptible to
spoofing?  I don't think this is a good idea.  I don't think numbering plan
managers or telcos will either.  I always assumed that DNSSEC would be
part-and-parcel of ENUM deployment.

> Yes .. I still agree that using BIND 9+ is a good requirement.

<commercial plug, apologies in advance>
There is at least one commercial DNS caching server that can out perform
BINDv9 by a factor of 5 and also do DNSSEC validation.
</commercial plug>
and commercial plug is graciously accepted... we all have to eat ...


I wouldn't make using any version of BIND a requirement.  Make the
functionality desired a requirement and let people pick and choose what
servers they want to meet those requirements.
I completely agree and stand properly corrected.


Rgds,
-drc

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<
> or <
> <http://www.neustar.biz> ; <http://www.enum.org> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>