Subject: Re: progress on wcard draft

From: Paul Vixie <[email-masked]>
Date: Wed, 06 Oct 2004 17:28:42 +0000

> > If the intent is -- do we have rough WG consensus on this? -- to
> > exclude wildcard NSes from functioning as delegations,
> 
> We don't.
> 
> Iff the scripture can be interpreted unambiguosly we do not have to
> get consensus on this.  We just need consensus on the fact that
> everybody reads the same. You just argued that there are multiple
> interpretations possible.

i do not agree with kevin's multiple-interpretation assertion.  the
document is unambiguous as written, and the best we can do is clarify
that wildcard NS's are not supported by the present specifications.

> If there is consensus that the text can be interpreted in two ways
> than we have to make the choice on what the sensible thing is. (One of
> the options is to clarify that both interpretations are possible and
> that therefore interoperabillity cannot be expected.)

ouch.  i hope not.

--
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: Paul Vixie <[email-masked]>
Date: Thu, 28 Oct 2004 14:05:15 +0000

> ...
> == Should the DNSEXT WG do this work
> ...
>  In order to pursue this work as a working group item we will _not_
>  ask the question 
> 
>  "Does the group want to see this as a working group item" 
> 
>  but will ask:
> 
>  1) Who will commit to producing specifications for a denial of existence
>     method that does not allow for zone enumeration;
>  ...
>  2) Who will commit on writing an implementation
>  ...
>  3) Who will commit on reviewing the material
>  ...
>   The intend of this exercise is to see if there is sufficient
>   critical mass for this work to go forward. Please let us know if you
>   can commit to 1,2 and/or 3.

isc has been asked for a proposal covering the above items, and so, you
can count isc as having committed to all three.

side note: i don't agree with alex that any of this touches on opt-in.
while i was a strong proponent of opt-in, it's only a performance problem
not a data visibility problem.  i don't see any groundswell of support
around the idea that operators of large zones shouldn't have to buy faster
computers to sign their zones, and larger computers to serve those zones;
only that changing the visibility of subdomain data was an unintended
consequence of dnssec-bis that should now be undone somehow.