Subject: Re: DNSEXT WGLC: To OPT_IN or not to OPT-IN

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

Paul Vixie writes: 
> 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.

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

--
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: 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
> 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)

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
> (such as a desire to limit the public exposure of complete NXT chains,
> either for business or privacy 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