Subject: RE: wildcards, dnssec, and opt-in

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Sep 2002 14:33:32 -0700

> > I find it bizare that we are talking about hypothetical applications
> > of enum in Andora when it has already been established that without
> > a change to the processing of NXT, the DNSSEC protocol is 
> undeployable
> > for the vast majority of current users.
> 
> The vast majority of current users don't have zones the size 
> of .com, so 
> this is irrelevant.

The vast majority of users have zones that are IN .com so for them the
issue is pretty damn important.

The .com hardware supports 7 billion transactions per day. There is 
simply no way that anyone is going to allow deployment of any protocol
modification that does not take account of the fact that DNS is a 
critical infrastructure for the Internet and take every step possible
to minimize impact on those systems.

Call these issues 'irrelevant' if you like, but in every successful
standards group I have been involved in the group has taken great
pains to gain the active endorsement of the principal stakeholders
rather than dismissing their needs as 'irrelevant'. 

Since I first attended a DNSEXT meeting in San Diego I have started 
two open standards groups, one of which has its specs in final vote 
and the other is just about to go to last call. Both specifications
have a very broad base of support amongst industry and developers.

I don't expect anyone to use XKMS or SAML or even WS-Security because
they are told to by a standards body, I expect them to use the 
specifications because they meet their needs. If a working group goes 
out of its way to tell a group that their requirements are considered 
'irrelevant' they are effectively saying that they do not intend to
service that groups needs and consequently cannot expect that group
to adopt any resulting proposal.

Standards groups are a two way street, don't tell me my requirements
are irrelevant one day and then go and complain later if I do something
you don't like.

		Phill

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Brian Wellington <[email-masked]>
Date: Tue, 17 Sep 2002 14:51:15 -0700 (PDT)

> issue is pretty damn important.

It's important for you, not for them.  Do you really think the users care 
how long it takes to sign .com?

> to minimize impact on those systems.

7 billion transactions?  Presumably you're referring to queries, and 
opt-in doesn't make query responses any shorter.

> rather than dismissing their needs as 'irrelevant'. 

They're irrelevant to most users, and important to large registries.  You 
work at a large registry.  Of course you think it's important.  You 
should.

> are irrelevant one day and then go and complain later if I do something

This seems pretty off-topic.  I didn't intend to dismiss your claims;
merely that they don't apply to most users.

Brian

---

From: Jim Reid <[email-masked]>
Date: Wed, 18 Sep 2002 02:22:25 -0700

>>>>> "Brian" == Brian Wellington <[email-masked]> writes:

    Brian> It's important for you, not for them.  Do you really think
    Brian> the users care how long it takes to sign .com?

Of course not. Though they will care if the signing time has an impact
on how quickly new delegations get published.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 18 Sep 2002 07:55:20 -0400

Before we get too far into this rat hole, the DNSSEC performance 
issue behind opt-in isn't signing time.  That's been discussed 
before.  The issue is the memory required to hold the zone in a 
server (whether primary or secondary storage) and the cpu needed to 
search through the data.

I claim that signing a zone of any size is an easy proposition.  My 
first signer could handle (late-90s) com. from scratch - then at 700K 
delegations - on a mid-90's Pentium in 40 hours.  My second signer 
(the one distrubuted with BIND 8.2) couldn't sign com. because I 
didn't include my "memory tricks" simply because it didn't seem 
important to to do so in experimental code.  Signing is the easy part.

The "response time" for adding a new signed delegation is more a 
function of institutional practices than computing power.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer