On Feb 12, 2014, at 6:38 PM, George Michaelson <[email protected]> wrote:
> The previous draft (at least for some of the TLDs) was anchored in the 
> reality that changing the name already in use was not practical, e.g. there's 
> a sufficient deployed base that uses DNS-like names ending in ONION that 
> proposals to use things like ONION.ARPA were non-starters.
> 
> I dissent from this view. I strongly disagree with any characterisation of 
> the problem of code replacement in service being intractable, and I think it 
> is a false premise.

+1 

> I realize I am probably a lone voice on this, but at *no* time have I felt 
> the "there are too many already" argument has merit, and it has materially 
> impeded several outcomes we now face, because of failure to accept the 
> necessary transition pain. The future is always bigger. 

I once heard a story about the author of make(1) realizing that perhaps having 
the tab character be significant in makefiles might not have been the best 
choice, but deciding against fixing it because the installed base of systems 
using make(1) at the time -- all 200 of them -- was too large.

> 
> I think therefore that the ALT draft addresses quite a different problem: the 
> choice of DNS-like (but not DNS) name structure for new applications that we 
> don't know about yet.
> 
> And as a consequence I disagree with this too. An orderly migration from 
> .ONION to another namespace is both feasible and capable of being planned for.

While I agree, pragmatically, I'm unsure there is incentive for the maintainers 
to move (which I think where Joe was going). As such, we're in the increasingly 
common quandary of figuring out how to document reality despite violation of 
policy or ignoring reality to ensure purity of policy.

Has anyone asked the folks coding .ONION (or others) if they're willing to 
migrate, pointing out the downsides if they choose not to? 

Regards,
-drc

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to