ok. I see where you are. I can be there, somewhat. Thats not a bad position
Ted.

So my sense of this is "you were advised not to do this, and you didn't
respect the process" for some value of "you"

What I don't like about that is a schoolmarm/punitive voice. But it has the
qualities. Tragedies of the commons don't just take one form, and having
s/w develop a dependency on name/locator properties with high visibility,
without considering the commons, is (in my opinion) a tragedy.

I'm not inherently arguing for ICANN process, or even the DNS. I think a
mature sense of the locator/id separation qualities of any endeavour, and
the arguments around naming, lead you to caution in seizing names in any
space.

IETF is constantly advised by w3c people (mark nottingham?) to be mindful
of the URI/URL concept, and not to over-egg stipulations on what is
meaningful in that space. And I think by and large, thats right.

So is what the TOR people did usurping .onion respectful of process? What
do you do, when process isn't respected?

-G



On Tue, Feb 4, 2014 at 11:08 AM, Ted Lemon <ted.le...@nominum.com> wrote:

> On Feb 3, 2014, at 6:27 PM, George Michaelson <g...@algebras.org> wrote:
> > .onion is an eminently tractable problem. Arguing otherwise is to argue
> the current .onion codebase dependency cannot move, therefore any future
> CVE against TOR cannot be fixed, therefore further code development on TOR
> is fruitless, therefore lets all stop coding. Breathing even.\
>
> What I'm saying is that it's an obnoxious thing to do, and there's no good
> reason to do it.   We really ought to have a good reason to demand that an
> organization over which we exert no control at all make a significant and
> incompatible change to their deployed code purely on the basis that some of
> us don't like what they did.   We need a better reason than that, and thus
> far none has been stated.
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to