Subject: comments on ds-13

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Mar 2003 17:57:46 +0000

olafur, you wrote (in draft-ietf-dnsext-delegation-signer-13.txt),

>> DS RRsets MUST NOT appear at non-delegation points or at a zone's apex.

why not?  i think you can say they are irrelevant elsewhere, but i don't
think there's a way to show that they are in any way harmful elsewhere.

as a simple document quality issue, there is no way to enforce this
requirement and no reliable way to even know when it has been violated.
so at best it would be a SHOULD not a MUST.

however, even as a SHOULD, it overreaches.  the proper attitude of a
document toward its protocol is to specify things which, if left
unspecified, will lead to loss of interoperability or functionality.
there is no such argument to be made for restricting the placement of
DS RRs (or for restricting the use of KEYs for that matter.)

paul

--
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: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 11 Mar 2003 15:04:38 -0500

>think there's a way to show that they are in any way harmful elsewhere.

Well the record is called "Delegation Signer".
IMHO this is a record for DNS consumption, and only for DNS, it
makes limited sense to have DS record at non delegation points
within the context of current DNSSEC specification.
In addition there are DS rules specify that it resides on
the upper side of delegation.
Does allowing DS to reside at normal node require more special cases?

If someone figures out other uses for the DS concept that is not
related to standard DNSSEC, lets define a new record for that.
If the new usage is to somehow improve/add on DNSSEC then the
use of DS should be considered.

>so at best it would be a SHOULD not a MUST.

This is a real good argument, and I would be happy to make the change
base on this, if the working group says so.

>DS RRs (or for restricting the use of KEYs for that matter.)

Remember the name and purpose of the record.
Key on the other hand can be assigned to hosts for dynamic update purposes
thus KEY is not restricted to APEX only.
IFF KEY was restricted to DNSSEC zone signing only then restricting it
to the apex would make sense.

         Olafur

---

From: Paul Vixie <[email-masked]>
Date: Tue, 11 Mar 2003 21:15:06 +0000

> Well the record is called "Delegation Signer".  IMHO this is a record
> for DNS consumption, and only for DNS, it makes limited sense to have
> DS record at non delegation points within the context of current
> DNSSEC specification.

that's all true but does not mention the harm in allowing them to
exist at other than zone boundaries.  

> In addition there are DS rules specify that it resides on the upper
> side of delegation.  Does allowing DS to reside at normal node require
> more special cases?

nope.  it's just data unless the delegation logic is being invoked.

> related to standard DNSSEC, lets define a new record for that.  If the
> new usage is to somehow improve/add on DNSSEC then the use of DS
> should be considered.

you have not yet shown any possible harm in letting DS RR's exist at
places other than zone boundaries.

> base on this, if the working group says so.

i hope it's the default unless the working group decides to make a change
like "it's ok to specify nonenforceable requirements in a standards doc."

---

From: Michael Richardson <[email-masked]>
Date: Tue, 11 Mar 2003 16:48:20 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "mundsson" == mundsson  <lafur> writes:
    mundsson> delegation.  Does allowing DS to reside at normal node require
    mundsson> more special cases?

  No. 
  If there is any issue, you have to code for that case anyway, since you can
rely upon the network or software to behave properly.
 
    >> requirement and no reliable way to even know when it has been
    >> violated.  so at best it would be a SHOULD not a MUST.

    mundsson> This is a real good argument, and I would be happy to make the
    mundsson> change base on this, if the working group says so.

  I'd agree with Paul.

]       ON HUMILITY: to err is human. To moo, bovine.           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: Randy Bush <[email-masked]>
Date: Tue, 11 Mar 2003 23:19:11 -0500

> places other than zone boundaries.

and no one has shown the benefit.  so why add bangles to an already
complex world for unknown uses?  simplicity, please.

randy

---

From: Rob Austein <[email-masked]>
Date: Wed, 12 Mar 2003 13:50:16 -0500

The robustness principal probably applies here.  DS is a DNS
infrastructure RR type, we know of no useful purpose that DS RRs
anywhere other than at delegation points would serve, and at least
some of us think that reusing existing RR types for fundamentally
different purposes is a risky thing to do, therefore:

a) Zones either SHOULD NOT or MUST NOT include DS RRs anywhere but at
   delegation points;

b) Software MUST cope if a zone violates (a).

I tend to think that (a) should be MUST NOT, on the grounds that it
probably simplifies the implementation of (b) slightly (software must
not fall on its face, full stop, but don't expect an implementation to
do anything useful with a non-delegation DS RR).

---

From: Paul Vixie <[email-masked]>
Date: Wed, 12 Mar 2003 19:37:46 +0000

> The robustness principal probably applies here.

i'm sure it does but i think i interpret it in the opposite way.

> DS is a DNS infrastructure RR type, we know of no useful purpose that
> DS RRs anywhere other than at delegation points would serve, and at
> least some of us think that reusing existing RR types for
> fundamentally different purposes is a risky thing to do

others of us think that putting in feel-good restrictions whose implementation
status is unlikely to be rigourously tested (either for operability reasons or
interoperability reasons) ultimately does no good (ever) and some harm (often).

> ... therefore:

i humbly disagree.  we should define what we mean and say that other uses are
undefined.  if we some day think of a reason to use these at non-delegation
points, it'll be wonderful to know that authority servers (both master and
slave) and caching forwarders are willing to pass the data through even though
they have reason to believe that it wasn't at a delegation point.

---

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Wed, 12 Mar 2003 23:01:05 -0500

This starts a two week working group last call,
concluding on March 28'th 2003.

Q: Is there consensus by the WG, to allow Opt-in zones?

The document to base this discussion on is
     http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dnssec-opt-in-05.txt

Please send explicit statements of support or disagreement.

Note this is not a last call on the technical issues in the document,
if any such issues exist they should be assumed to be fixable and not
affect the judgment on the question above.

The document is on the standards track. If this document is advanced by
the working group, it will be integrated into the DNSSECbis documents.

Silence during this working group last call will be taken as support
for opt-in based on comments made during the technical last call on
OPT-IN.

	Olafur

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2003 06:09:49 +0000

> Please send explicit statements of support or disagreement.

as an individual, i support this.

if organizational support matters, isc supports this too.

---

From: Roy Arends <[email-masked]>
Date: Thu, 13 Mar 2003 12:11:38 +0100 (CET)

> Please send explicit statements of support or disagreement.

I support opt-in.

Roy

---

From: Matt Larson <[email-masked]>
Date: Thu, 13 Mar 2003 07:52:03 -0500

> Please send explicit statements of support or disagreement.

I support Opt-In.

Matt

---

From: Olaf Kolkman <[email-masked]>
Date: Thu, 13 Mar 2003 15:09:14 +0100

* Q: Is there consensus by the WG, to allow Opt-in zones?

Although I would advise against its use in all other cases but the huge
zones out there, I do support the draft.

--Olaf

---

From: Mark Kosters <[email-masked]>
Date: Thu, 13 Mar 2003 10:07:33 -0500

I support opt-in.

Mark

-- 

Mark Kosters            [email-masked]       Verisign Applied Research

---

From: "Scott Rose" <[email-masked]>
Date: Thu, 13 Mar 2003 10:47:08 -0500

As per Olaf's comment - I support the draft with the last round of comments.
And wish there was a good way of recommending OPT-IN for "huge zones" only.
However, I know what makes a zone "huge" would be a rathole debate.

Scott

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Mar 2003 08:54:01 -0800 (PST)

I oppose OPT-IN going forward as a proposed standard.  

It is very clear that there are some engineering trade-offs
here, and I'm very glad that we've taken the time to explore
them.  In this case, I would summarize a bunch of trade offs
by saying "ease of zone management for large zones" vs.
"complexity (both of code path, and, more generally,
the understanding of the states DNSSEC will imply)".
In a case where there are trade-offs of this type, I
think it is important to look both at where we are today
and where we are likely to be later.  My take is that
the deployment of DS for large zones today _is_ a
problem, but a tractable one given today's hardware and software
either present or far along the pipeline; more importantly,
I believe it will only get easier as the maturity of
those products increase.  The "complexity" side of the equation
doesn't seem to me to get much better as time goes on.

Based on that, I believe we would be making the wrong choice
to advance OPT-IN; if we allow it, it will be part of
the standard for a very long time, and we will be living
with its complexity well past the time horizon that the problems
it addresses have ceased to be an issue.

				regards,
					Ted Hardie

---

From: Daniel Massey <[email-masked]>
Date: Thu, 13 Mar 2003 12:18:04 -0500

> However, I know what makes a zone "huge" would be a rathole debate.

same as above.  support for the draft with the last round of comments.

Dan

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Mar 2003 13:09:17 -0500

> if organizational support matters

<chair>

in the ietf it doesn't.  sorry to do this publicly, but we need
to be very clear on this.  such assertions are inappropriate and
damage one's position.

randy

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Mar 2003 12:45:33 -0600

I support opt-in.   We've been playing around with DNSSEC for a long 
time, and we will still be playing with it (or have abandoned it) ten 
years from now if we don't adopt opt-in.

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Mar 2003 10:56:58 -0800

Sigh.  I've said I don't care what decision is made as long as a 
decision is made and I still feel that way, however this is a bit over 
the top.

So, let me get this straight:

> same as above.  support for the draft with the last round of comments.

You all appear to be arguing that we should yet again modify DNSSEC, 
increasing complexity and changing the security model, to include 
functionality to address a temporary transition issue that only a 
handful of folks will ever need and that many who have looked at the 
problem believe is solvable in other arguably better ways?

If you want to support pushing opt-in forward, I believe it should be 
done so with the belief that it is necessary, generally useful, and 
improves the protocol, not a hack for a small set of outliers or "well, 
it doesn't look like it will do any harm".

Rgds,
-drc

---

From: Brian Wellington <[email-masked]>
Date: Thu, 13 Mar 2003 11:18:03 -0800 (PST)

> problem believe is solvable in other arguably better ways?

I completely agree.

Furthermore, the main argument for opt-in has historically been that full 
DNSSEC would require too many resources.  Since this argument was 
originally used, probably 2 years ago, every conceivable resource has 
become both cheaper and faster, and the size of excessively large zones 
has more or less stayed the same.  This means that even if it had been a 
good argument in the past, it's days are over.

> it doesn't look like it will do any harm".

Exactly.

Brian

---

From: Mark Kosters <[email-masked]>
Date: Thu, 13 Mar 2003 14:58:22 -0500

I would prefer to see some hard numbers before I would agree with
this conjecture.

There is at least one recursive implementation of opt-in that has been 
completed.  And we have had some experience that it interoperates
correctly with at least two authoritative opt-in servers. So with this
knowledge of actual running code, perhaps we should ask ISC and/or Nominum to 
comment on how much more "complex" it is to add opt-in support.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2003 21:22:17 +0000

> It is very clear that there are some engineering trade-offs here, ...

that's not as clear to me as it seems to be to you.  opt-in adds another
knob for zone managers, some of whom will twist it for engineering reasons
(such as difficulty in signing and publishing large zones with current
technology) but some of whom will twist it for non-engineering reasons
(such as a desire to limit the public exposure of complete NXT chains,
either for business or privacy reasons.)

> Based on that, I believe we would be making the wrong choice to
> advance OPT-IN; if we allow it, it will be part of the standard for a
> very long time, and we will be living with its complexity well past
> the time horizon that the problems it addresses have ceased to be an
> issue.

because there are reasons for the knob which existing zone managers
consider valid, some of which are engineering related and of those some
appear to be temporary, but others of which are not engineering related,
i believe that the tradeoff is between complexity and autonomy, and that
autonomy has to win since the complexity has already been shown to be
quite manageable (witness various recent workshops and bind9 snapshots.)

it is not up to us as protocol developers to tell zone managers how they
ought to "run their businesses."  that would be paternalism at its offensive
worst, worse even than the "restrict key" silliness.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 13 Mar 2003 21:31:12 +0000

> knowledge of actual running code, perhaps we should ask ISC and/or
> Nominum to comment on how much more "complex" it is to add opt-in
> support.
> 
> Mark

the complexity arguments are a tempest in a teapot, as silly as verisign's
whining about memory footprints and bandwidth requirements.  any argument
based on either basis is just pure FUD.

this is a tradeoff between complexity and autonomy.  the complexity part
has been shown to be manageable; opt-in validators exist and have been
tested by people other than their authors.

let's move on.

---

From: Daniel Massey <[email-masked]>
Date: Thu, 13 Mar 2003 17:04:35 -0500

On Thursday, March 13, 2003, at 01:56  PM, David Conrad wrote:

> decision is made and I still feel that way,

yes, there are no new technical issues being raised.    we need to make 
a decision.

> however this is a bit over the top.
>

No, to me it reflects that is trade-off rather than a clearly right or 
clearly wrong issue.  we are long past the time we should have decided 
on this trade-off.

as you suggest below, there may be "other arguably better ways" to 
address this "temporary transition issue".   But a decade from now, 
there will still be "other arguably better ways" that are better in 
some ways and worse in others.   I'm also not sure what is really 
"temporary", but in any event, this is a permanent change to the 
protocol.  It adds some complexity and that is bad, but the draft 
authors have convinced me much of the complexity I initially attributed 
to opt-in is actually inherent in DNSSEC.    I don't see anything more 
that authors could present and I think all the issues are on the table. 
   At some point, it has to come down to a decision.

my decision is I support the draft.   I can live with whatever the 
working group decides as long it decides.

Dan

> improves the protocol, not a hack for a small set of outliers or 
> "well, it doesn't look like it will do any harm".
>
> Rgds,
> -drc

---

From: Randy Bush <[email-masked]>
Date: Thu, 13 Mar 2003 17:29:24 -0500

> I would prefer to see some hard numbers before I would agree with

just a sec.  years ago, we asked you for hard numbers on the problem
of large zones.  what you provided did not make your point.  you are
asking for a change to acommodate your needs.  the onus is on you to
justify that need, not vice versa.

randy

---

From: Mark Kosters <[email-masked]>
Date: Thu, 13 Mar 2003 18:19:21 -0500

> based on either basis is just pure FUD.

I agree that the complexity args on one side and additional operational 
requirements on the other can be colored by the type of glasses worn.

> tested by people other than their authors.

Is this a reasonable answer for Ted?

Mark

--

---

From: Bob Halley <[email-masked]>
Date: 13 Mar 2003 15:48:09 -0800

> based on either basis is just pure FUD.

I don't see how either can be written of as "pure FUD".  The OPT-IN
draft describes itself as a way to make a cost-benefit adjustment for
certain classes of zones.  It does not justify itself on the grounds
of zone administrators needing more knobs.  If the resource and
operational issues are significant, then they are fair game and not
FUD.  If they are not, then why do we have OPT-IN at all?

Likewise, complexity is a fair argument that isn't just FUD.  Just
because implementations can, and have, been made does not mean that we
should impose the complexity of OPT-IN on every subsequent
implementation, or on the system as a whole.  We also had multiple
implementations that did A6 records and bitstring labels, yet that
technology is no longer progressing (and rightfully so!).  Also,
because this is an area involving security, any increases in
complexity of validation must be taken seriously.  Complexity is often
the enemy of good security, making implementation errors more likely,
and more difficult to find.

/Bob

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Mar 2003 17:37:37 -0800 (PST)

> worst, worse even than the "restrict key" silliness.

This point of view, that the OPT-IN mechanism is there primarily to
provide a knob for zone managers to use in running their businesses,
does not seem to me well laid out in the draft.  If the justification
is based on this, then I would say making clear which new knobs
are needed to do what would be a very useful thing.  

This is not "paternalism", but a way of making clear to everyone what
the benefit of a change is going to be.  It's important for all of
us to remember that zone managers are not the only ones concerned
in the operation of the DNS; those who run recursive resolvers and
manage applications relying on data stored in the DNS are concerned 
as well.  This mechanism has implications for them, and considering
those implications in the protocol design is appropriate.
				regards,
					Ted Hardie

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Mar 2003 17:44:59 -0800 (PST)

> Is this a reasonable answer for Ted?

I was afraid when I tried to boil down two sets of trade-offs to a simple
statement that I would boil it down too far.  It seems I have, and I'm
sorry.  No, the existence proof of the code is not sufficient to prove
that complexity isn't an issue.  If the draft couldn't be implemented,
we would have a different discussion.  

I have elsewhere answered Paul's comment on autonomy,
					regards,
						Ted

---

From: Paul Vixie <[email-masked]>
Date: Fri, 14 Mar 2003 03:00:35 +0000

i don't think i said "primarily".  here, let's look:

> > it is not up to us as protocol developers to tell zone managers how
> > they ought to "run their businesses."  that would be paternalism at
> > its offensive worst, worse even than the "restrict key" silliness.

it's an aspect of what ought not be done, that's all.

> is based on this, then I would say making clear which new knobs are
> needed to do what would be a very useful thing.

the justification is not based on this.  however, some zone managers
have said that they want this and have put the onus on the standards
community to say why they can't have it.  i don't think there's a
reasonable basis for denying the request for this feature.  dnssec is
such a step upward in complexity and brittleness from basic dns, that
the incremental complexity from opt-in is pretty much lost in the noise.

> the benefit of a change is going to be.  It's important for all of us
> to remember that zone managers are not the only ones concerned in the
> operation of the DNS; those who run recursive resolvers and manage
> applications relying on data stored in the DNS are concerned as well.
> This mechanism has implications for them, and considering those
> implications in the protocol design is appropriate.

i believe i have, since opt-in vs. not has been shown to be an early
deployment issue, and early deployment is going to affect the quality
of the "protocol experience" by recursive server operators and application
managers more than either elegance or any real or imagined incremental
difference in complexity.  it is in other words far more likely that a
given application manager or recursive server operator will avoid dnssec
altogether than that they will face any noticable complexity penalty due
to opt-in.

---

From: Ted Hardie <[email-masked]>
Date: Thu, 13 Mar 2003 21:48:52 -0800 (PST)

> > > its offensive worst, worse even than the "restrict key" silliness.

Point taken; you did not say "primarily". 

> the justification is not based on this.  

And we seem to agree that the draft does not make this argument.

> however, some zone managers

We disagree.  You believe that the trade-off in value for this
feature is worth the incremental complexity.  I do not.

The primary point made in favor of this approach has been that
it will be easier to deploy for very large, flat zones.  I
do not disagree that it is problem.   I believe, however, that 
the barriers that they face are smaller now and continue
to recede.  The complexity will not recede.

You have made a second point that this provides a knob for
zone managers.  I believe that if that is even part of the reason for
this approach, a clear statement of its value belongs in the draft,
so that the community can better understand who this benefits (and
what the knob will be turned for).  As other messages in this thread
have made clear, there are real costs to this approach.

>  it is in other words far more likely that a

It is moderately obvious that you and I see the protocol from different
points of view, and I suppose that it is not surprising that we see
the likely deployment curve differently as well.  Rather than the
debate the merits of either of our conjectures, let us leave it that deployment
must be taken into account with the other factors, and let others
put the emphasis on it that they think appropriate.  
					regards,
						Ted Hardie

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Mar 2003 22:16:44 -0800

Mark,

On Thursday, March 13, 2003, at 11:58  AM, Mark Kosters wrote:
> completed.

I know of one implementation of a recursive server that does 
_delegation only_ opt-in.  I would, of course, be interested in hearing 
of another.

> And we have had some experience that it interoperates
> Nominum to

I'm told that
- implementation of the validator turns out to be easy
- implementation of the authoritative side is harder
- figuring out what needs to be cached is the hard bit

Different server architectures make coming up with a consistent answer 
regarding complexity difficult.

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Mar 2003 22:28:12 -0800

Paul,

On Thursday, March 13, 2003, at 01:22  PM, Paul Vixie wrote:
> opt-in adds another
> technology)

As has been pointed out, there is some argument whether this difficulty 
is an engineering issue.

> but some of whom will twist it for non-engineering reasons

I (still) don't buy this.  This says you have a choice: either names 
that can be (arguably) hidden OR the data fetched from the names can be 
can be verified, but NOT both.  We have already shot down a proposal to 
address the zone traversal via NXT chain issue.  Using opt-in as a hack 
to partially get the same thing is silly.  If it is an issue, lets 
resurrect NO (which I'm not actually advocating this as you know -- if 
people want to hide DNS data, they should use "views" (or equivalent) 
and get over it) instead of pretending a side effect is a solution.

> i believe that the tradeoff is between complexity and autonomy,

Huh?

Rgds,
-drc

---

From: David Conrad <[email-masked]>
Date: Thu, 13 Mar 2003 23:10:06 -0800

Dan,

> clearly wrong issue.  we are long past the time we should have decided 

Agreed on both counts.

What I was complaining about was that the arguments raised by Olaf and 
Scott to which you were agreeing were adding the proviso that opt-in 
should only be used for "huge" zones.  This is, I believe, not an 
appropriate constraint to add.  There aren't a whole lot of "huge" 
zones (and it has often been argued that given their size, they should 
have sufficient resources to deal with this issue without spreading the 
cost over every secure DNS server implementation) and opt-in _only_ has 
value if you assume only a portion of the full zone is signed (thus my 
'temporary transition issue' statement).  If the protocol modification 
is not generally useful but instead is intended to address 
non-technical requirements for a limited set of users, then I 
personally do not believe it should be added.

Rgds,
-drc

---

From: Greg Hudson <[email-masked]>
Date: 14 Mar 2003 11:37:36 -0500

On Fri, 2003-03-14 at 02:10, David Conrad wrote:
> If the protocol modification 

I'm not sure what "non-technical" requirements you believe opt-in
addresses.  If Verisign wants to charge extra for a secure delegation,
they can do that without opt-in.

As to the "limited set of users" argument: almost every DNSSEC user is
expected to make use of opt-in from the client side.  It's important to
distinguish asymmetric features like this--used by only a few people on
the server side, but still affecting lots of users--from features which
will impact almost nobody.

---

From: David Conrad <[email-masked]>
Date: Fri, 14 Mar 2003 11:52:21 -0800

Greg,

On Friday, March 14, 2003, at 08:37  AM, Greg Hudson wrote:
> addresses.

To be explicit, this isn't a Verisign-only issue. In today's Internet, 
you typically need a business case to justify doing something new to 
pretty much any infrastructure.  Given the vast majority of zone owners 
won't be interested in DNSSEC when it is first (finally) released, it 
is unlikely they'd be happy about paying more to get what DNSSEC 
provides.  Given it is unlikely people will want to pay more, it is 
hard to come up with a business case that would justify the additional 
costs necessary to deploy the DNSSEC infrastructure if those costs are 
significant which was thought to be the case for very large zones.  
Opt-in addresses this problem by allowing only those interested in 
DNSSEC to choose (and pay) to have their zones and delegations secured. 
  This is not a technical requirement, it is a means by which a business 
case can be made.

However, others have pointed out that Moore's law has caught up and 
passed this problem.  Signing a huge zone (say 33 million delegations, 
for example) has been demonstrated to take less than 2 hours on a $10K 
box (or rather, $10K a year and a half ago) and could be done faster.  
Propagation and loading the data is indeed an issue, but this issue is 
addressable in a variety of fashions (e.g., only propagate/load 
changes) using existing technology, albeit perhaps with changes to 
existing business processes.

My point was that opt-in should be included or not based on its general 
applicability, not because a small number of zones have decided for 
non-technical reasons to not fully sign the zone (and hence opt-in 
should be limited to those zones).   As Paul V. states, there may be 
intrinsic benefits that opt-in provides that justify its inclusion and 
the decision should be made by analyzing the costs of those benefits.

> expected to make use of opt-in from the client side.

I am unsure whether the vast majority of zone owners will bother with 
not signing their entire zones.  I guess it depends on the signing 
tools.

Rgds,
-drc

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 19 Mar 2003 22:48:23 -0300

> Please send explicit statements of support or disagreement.

We strongly support OPT-IN. Today as the "standard" is we can't deploy
DNSSEC without OPT-IN.

Fred

---

From: David Blacka <[email-masked]>
Date: Thu, 27 Mar 2003 18:44:23 -0500

I apologize for not catching this earlier...

> - implementation of the validator turns out to be easy

Yay!

> - implementation of the authoritative side is harder

Ok, I think I understand that, at least in the context of how I think BIND 
9 works.

> - figuring out what needs to be cached is the hard bit

Somebody absolutely needs to explain this, as Opt-In does not envision any 
new caching requirements.  Well, the draft does talk about needing to 
fetch NXT records from the cache in an additional case, but that doesn't 
cover this statement.

-- 
David Blacka    <[email-masked]> 
Sr. Engineer    Verisign Applied Research