On Aug 10, 2015, at 3:54 PM, Darcy Kevin (FCA) kevin.da...@fcagroup.com
wrote:
In retrospect, the definition of the “http” and “https” schemes (i.e. RFC
7230) should have probably enumerated clearly which name registries were
acceptable for those schemes,
I generally try to avoid
Darcy == Darcy Kevin (FCA) kevin.da...@fcagroup.com writes:
DarcyIn retrospect, the definition of the
Darcy http and
Darcy https schemes (i.e. RFC 7230) should
Darcy have probably enumerated clearly which name registries were
Darcy acceptable for those schemes,
On Mon, Aug 10, 2015 at 07:25:23PM +, Alec Muffett wrote:
Some Googling suggests that the http:// scheme is defined in RFC 2616, which
- to summarise - again does not mandate DNS.
I'm by no means an expert on the scheme, but I think following the
references means that 2616 does in fact
Hi Alec,
You wrote:
To address Edward’s implicit request for information - rather than to
address his request for document pointers - I’d like to share that I
sketched how onion addressing works in previous discussion at:
https://www.ietf.org/mail-archive/web/dnsop/current/msg13758.html
Hi Alec,
On Mon, Aug 10, 2015 at 11:04 AM, Alec Muffett al...@fb.com wrote:
Hi Ted, thanks for the feedback.
I don’t see any question in the above which impinges upon the draft so
much as being related to internal operations of IETF and/or DNSOP, but I’d
like to reinforce that CA/B-Forum
On Aug 10, 2015, at 9:50 AM, Ted Hardie ted.i...@gmail.com wrote:
I believe that the registry we have currently defined doesn't do a great job
of capturing the actual needs here. It doesn't define what the larger
namespace encompassing the DNS is or could be well, and it doesn't provide a
On 08/10/2015 01:50 PM, Ted Hardie wrote:
It does a fine job with .example since that's fundamentally
just a reservation, but .onion is showing its warts.
Hi Ted,
I fully agree with Alec, and do not understand how .onion would differ
from .example in that case, especially since as we're
On 10 Aug 2015, at 13:25, Alec Muffett wrote:
So, by this analysis I think Onions in http (and by extension https)
are fine.
Not to mention, appropriate. :-)
If the smiley means they're already deployed, so we don't get to talk
about whether they're appropriate, then fine, but that's why a
Five years is not enough. Think in terms of 20 to 50 years.
Oh, of course. I was thinking of five years as the review cycle for
names that people might want to reconsider.
Mark wrote:
If .BELKIN is reserved then it is not available to *anyone* including
Belkin. The simplist fix for
On Aug 10, 2015, at 1:25 PM, Joe Hildebrand hil...@cursive.net wrote:
If the smiley means they're already deployed, so we don't get to talk about
whether they're appropriate, then fine, but that's why a bunch of people are
complaining about the precedent this sets. If the smiley means
Barnes; dnsop@ietf.org;
Mark Nottingham
Subject: Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion
Special-Use Domain Name) to Proposed Standard
On Aug 10, 2015, at 1:25 PM, Joe Hildebrand
hil...@cursive.netmailto:hil...@cursive.net wrote:
If the smiley means they're already
Kevin,
On 11 Aug 2015, at 6:54 am, Darcy Kevin (FCA) kevin.da...@fcagroup.com wrote:
In retrospect, the definition of the “http” and “https” schemes (i.e. RFC
7230) should have probably enumerated clearly which name registries were
acceptable for those schemes, so that the following
I believe that the registry we have currently defined doesn't do a great job
of capturing the actual needs here.
Agreed. It seems to me that there are two somewhat separate things going on
here.
One is the .ONION issue. It's a domain name string that has a
coordinated use that is
Hi again, Ted!
On Aug 10, 2015, at 11:42 AM, Ted Hardie ted.i...@gmail.com wrote:
[…]
I think the Internet community needs to understand that a reservation in the
encompassing name space means that no gTLD with the same string will be
permitted in the DNS and understand who has the right
Five years is not enough. Think in terms of 20 to 50 years.
On Aug 10, 2015, at 3:10 PM, John Levine jo...@taugh.com wrote:
I believe that the registry we have currently defined doesn't do a great
job of capturing the actual needs here.
Agreed. It seems to me that there are two somewhat
In message 20150810191030.13804.qm...@ary.lan, John Levine writes:
I believe that the registry we have currently defined doesn't do a great j
ob of capturing the actual needs here.
Agreed. It seems to me that there are two somewhat separate things going on
here.
One is the .ONION
Kevin,
On Aug 10, 2015, at 3:54 PM, Darcy Kevin (FCA) kevin.da...@fcagroup.com
wrote:
In retrospect, the definition of the “http” and “https” schemes (i.e. RFC
7230) should have probably enumerated clearly which name registries were
acceptable for those schemes, so that the following
On Aug 7, 2015, at 4:26 PM, Edward Lewis edward.le...@icann.org wrote:
… the documents I have access to do not give me a deep enough sense
of, well, why the names are different from DNS domain names. I presume
they are from the email discussion, but what I am reading in the documents
- and
(The last call is still on...)
I am trying to write another document and wanted to include descriptions
of .onion names.
I'm seeking authoritative references but am having some trouble doing so.
This isn't meant to be a replay of my previous comment that the draft
under discussion is poorly
why the names are different from DNS domain names.
I think this is where Andrew's distinction between the DNS and a larger
concept of name space is needed. Onion names are different in that they are
names for a different resolution process which uses a distributed hash
table operated by the
Thanks. That is indeed what I'm working on. And yes, that description is
clear and helpful and deprecates (in my mind) the notion that the names
were too long for the DNS.
(Just wish it was that clear in a Tor document. ;) ...said for the purposes
of the last call.)
On 8/7/15, 11:38, Chris
On 8/7/15, 10:29, DNSOP on behalf of Wendy Seltzer
dnsop-boun...@ietf.org on behalf of wselt...@w3.org wrote:
You might find https://spec.torproject.org/ helpful as a listing of
various tor specs and design documents, if you prefer that to a git
repository.
That's the site I've been using.
On 8/7/15, Edward Lewis edward.le...@icann.org wrote:
On 8/7/15, 10:29, DNSOP on behalf of Wendy Seltzer
dnsop-boun...@ietf.org on behalf of wselt...@w3.org wrote:
You might find https://spec.torproject.org/ helpful as a listing of
various tor specs and design documents, if you prefer that to a
In message 5d60ceeb-a781-4db4-aad6-9ef57a482...@difference.com.au, David Cake
writes:
On 16 Jul 2015, at 4:11 am, Francisco Obispo fobi...@uniregistry.com
wrote:
This was proposed in the working group. It obviously doesn't work,
first because TOR can't come up with that kind of
On 16 Jul 2015, at 4:11 am, Francisco Obispo fobi...@uniregistry.com wrote:
This was proposed in the working group. It obviously doesn't work, first
because TOR can't come up with that kind of money, but second because TOR
doesn't want a TLD (hellekin's erroneous statements
--On Monday, July 20, 2015 13:50 -0400 Bob Harold
rharo...@umich.edu wrote:
This thread has taught me more about the .onion names - thanks
for that. But I would have to agree with those that think this
bit of explanation is unnecessary to the RFC and should be
excluded, rather than
Hi,
While I guess most of you are in Prague having discussions about these things,
I hope you won’t mind someone who is unable to attend but who follows your work
on the mailing lists from expressing an opinion...
On 17 Jul 2015, at 08:39, Paul Vixie p...@redbarn.org wrote:
we only need
Hi David,
On 7/20/15 6:06 AM, David Cake wrote:
As someone with moderate experience in both DNS and web server
configuration, FWIW I found the meaning relatively obvious. The notion
that HTTP Host headers might be used to change web server response
independent of name resolution (e.g. that
David,
On Jul 20, 2015, at 5:53 AM, David Cake d...@difference.com.au wrote:
Of course, ICANN has already determined that .corp does pose a security issue
of sufficient significance that .corp will not be delegated.
For clarity, I believe ICANN has placed the delegation of .CORP on hold
Yes, there is an HTTP Host header. Yes, responses vary by the *value* but
not by the *structure*. As far as Apache is concerned, for instance, I would
imagine it's doing a string compare without counting or considering dots. By
discussing an arbitrary number of components, that
On 20 Jul 2015, at 10:22, David Conrad wrote:
On Jul 20, 2015, at 5:53 AM, David Cake d...@difference.com.au wrote:
Of course, ICANN has already determined that .corp does pose a security
issue of sufficient significance that .corp will not be delegated.
For clarity, I believe ICANN has
For clarity, I believe ICANN has placed the delegation of .CORP on hold
indefinitely.
I do not believe ICANN has stated that .CORP will not be delegated. Part of
the
reason for this discussion is due to this fact.
Since the new gTLD program still has five active applications for
.CORP, each of
On 07/20/2015 10:34 AM, Eliot Lear wrote:
So... Alec and I did a bit of wordsmithing and what I propose is a
slight clarification on the existing text, based on this exchange, and
here it is:
Like Top-Level Domain Names, .onion addresses can have an arbitrary
number of subdomain
* Stephane Bortzmeyer:
On Wed, Jul 15, 2015 at 02:22:58PM -0700,
Francisco Obispo fobi...@uniregistry.com wrote
a message of 48 lines which said:
Well, even worse, what happens if name-your-next-OS-vendor decides
to create a new dns-like protocol that uses .foo, does that mean
that we
On 16 Jul 2015, at 3:35 am, Francisco Obispo fobi...@uniregistry.com wrote:
+1.
I don’t think IETF should be chasing around widely used TLDs and trying to
block them, it will be a never ending chase.
We are trying to mitigate against unknowns and perhaps the best solution is
to have
On 15 Jul 2015, at 8:42 pm, Edward Lewis edward.le...@icann.org wrote:
4. Caching DNS Servers and
5. Authoritative DNS Servers
I really believe that for DNS elements, there should be no change. By
intent, the onion names are not to be presented to the DNS by what's in
category 2 and 3
There are plausible, if unlikely, circumstances in which a fork, not just of
the Tor project software itself, but of the entire project including the
specific URL, might happen. While this argument is an attempt at a reductio ab
absurdum, I do not think it is - the circumstance described is
On 17 Jul 2015, at 10:52 pm, hellekin helle...@gnu.org wrote:
On 07/17/2015 11:32 AM, David Conrad wrote:
No. .LOCAL was not already in the root zone. .FOO is.
*** Therefore the .FOO label is not available for Special-Use anymore,
end of story. A Special-Use name cannot be an already
As someone with moderate experience in both DNS and web server configuration,
FWIW I found the meaning relatively obvious. The notion that HTTP Host headers
might be used to change web server response independent of name resolution
(e.g. that two names that return identical responses to every
On Fri, Jul 17, 2015 at 07:35:47AM +0200,
David Conrad d...@virtualized.org wrote
a message of 73 lines which said:
It assumes folks who are developing these non-DNS protocols
know/care about what the IETF thinks.
It is reasonable to assume that many of them do not even know that the
IETF
Hugo,
On Jul 17, 2015, at 4:03 PM, Hugo Maxwell Connery h...@env.dtu.dk wrote:
The goal here from the non-DNS people seems to be to have DNS type labels
(thus URI's)
which are known to the recursive and authoritative resolvers to be outside of
DNS.
That appears to be the goal of some
Stephane,
On Jul 17, 2015, at 4:17 PM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
Well, even worse, what happens if name-your-next-OS-vendor decides
to create a new dns-like protocol that uses .foo, does that mean
that we should automatically block it?
No need to speculate about what
On Fri, Jul 17, 2015 at 4:20 PM, Eliot Lear l...@cisco.com wrote:
I have no particular objection to the concept here, but I do have a
question about one sentence in the draft. Section 1 states:
Like Top-Level Domain Names, .onion addresses can have an arbitrary
number of subdomain
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/17/2015 11:20 AM, Eliot Lear wrote:
I have no particular objection to the concept here, but I do have a
question about one sentence in the draft. Section 1 states:
Like Top-Level Domain Names, .onion addresses can have an
arbitrary
Maxwell Connery
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion
Special-Use Domain Name) to Proposed Standard
Hugo,
On Jul 17, 2015, at 4:03 PM, Hugo Maxwell Connery h...@env.dtu.dk wrote:
The goal here from the non-DNS people seems to be to have DNS
On 07/17/2015 11:32 AM, David Conrad wrote:
No. .LOCAL was not already in the root zone. .FOO is.
*** Therefore the .FOO label is not available for Special-Use anymore,
end of story. A Special-Use name cannot be an already registered name in
the root zone.
If you referring to e.g., .corp
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/17/2015 07:07 AM, Andrew Sullivan wrote:
On Thu, Jul 16, 2015 at 11:39:24PM -0700, Paul Vixie wrote:
we only need one cutout, something like .external, with an
IANA-maintained registry of non-dns uses, each pointing to an RFC
that
+1 on support
On Thu, Jul 16, 2015 at 9:57 AM, Tom Ritter t...@ritter.vg wrote:
On 16 July 2015 at 00:44, Joe Hildebrand hil...@cursive.net wrote:
I don't see any mention of the CAB Forum stuff in the draft. Has anyone
done the analysis to see if CAB Forum members really will issue certs to
Paul,
On Jul 17, 2015, at 9:51 AM, Paul Vixie p...@redbarn.org wrote:
yes, but not with .ALT, which is a politically desirable gTLD name, and
which allows the connotation of alternate DNS. i suggested .EXTERNAL
because nobody will ever want it as a gTLD and because its connotation
is
...@ietf.org] on behalf of David Conrad
[d...@virtualized.org]
Sent: Friday, 17 July 2015 13:30
To: Paul Vixie
Cc: dnsop
Subject: Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion
Special-Use Domain Name) to Proposed Standard
Paul,
On Jul 17, 2015, at 9:51 AM, Paul Vixie p
On Wed, Jul 15, 2015 at 12:35:12PM -0700,
Francisco Obispo fobi...@uniregistry.com wrote
a message of 207 lines which said:
We are trying to mitigate against unknowns and perhaps the best
solution is to have the TOR folks apply for .ONION on the next round
of TLD application and get a fully
On Wed, Jul 15, 2015 at 02:22:58PM -0700,
Francisco Obispo fobi...@uniregistry.com wrote
a message of 48 lines which said:
Well, even worse, what happens if name-your-next-OS-vendor decides
to create a new dns-like protocol that uses .foo, does that mean
that we should automatically block
I have no particular objection to the concept here, but I do have a
question about one sentence in the draft. Section 1 states:
Like Top-Level Domain Names, .onion addresses can have an arbitrary
number of subdomain components. This information is not meaningful
to the Tor protocol,
Hi Richard,
Thanks for the explanation. Please see below.
On 7/17/15 4:38 PM, Richard Barnes wrote:
On Fri, Jul 17, 2015 at 4:20 PM, Eliot Lear l...@cisco.com wrote:
I have no particular objection to the concept here, but I do have a
question about one sentence in the draft. Section 1
David Conrad wrote:
Well, even worse, what happens if name-your-next-OS-vendor decides to
create a new dns-like protocol that uses .foo, does that mean that we
should automatically block it?
No. We can add it to the special-use domain name registry if the IETF has
consensus to do so,
Paul,
On Jul 17, 2015, at 8:39 AM, Paul Vixie p...@redbarn.org wrote:
we only need one cutout, something like .external, with an
IANA-maintained registry of non-dns uses, each pointing to an RFC that
describes as much as is possible to describe about that use.
You mean like
David Conrad wrote:
Paul,
On Jul 17, 2015, at 8:39 AM, Paul Vixie p...@redbarn.org wrote:
we only need one cutout, something like .external, with an
IANA-maintained registry of non-dns uses, each pointing to an RFC that
describes as much as is possible to describe about that use.
You
From my high tech gadget
On Jul 17, 2015, at 09:04, David Conrad d...@virtualized.org wrote:
Paul,
On Jul 17, 2015, at 8:39 AM, Paul Vixie p...@redbarn.org wrote:
we only need one cutout, something like .external, with an
IANA-maintained registry of non-dns uses, each pointing to an
On Fri, Jul 17, 2015 at 12:51:05AM -0700, Paul Vixie wrote:
yes, but not with .ALT, which is a politically desirable gTLD name, and
which allows the connotation of alternate DNS. i suggested .EXTERNAL
because nobody will ever want it as a gTLD and because its connotation
is unambiguously not
On Thu, Jul 16, 2015 at 11:39:24PM -0700, Paul Vixie wrote:
we only need one cutout, something like .external, with an
IANA-maintained registry of non-dns uses, each pointing to an RFC that
describes as much as is possible to describe about that use.
Why is an IANA-maintained registry a good
On 7/16/15 8:20 AM, Ted Lemon wrote:
On 07/15/2015 02:45 PM, Francisco Obispo wrote:
It doesn’t feel right to me rewarding bad behavior.
I don't think it's fair to characterize this as bad behavior. It is
completely unsurprising behaviour, as I explained in some detail in a
previous
On 07/17/2015 12:17 PM, Eliot Lear wrote:
On Fri, Jul 17, 2015 at 4:20 PM, Eliot Lear l...@cisco.com wrote:
I have no particular objection to the concept here, but I do have a
question about one sentence in the draft. Section 1 states:
Like Top-Level Domain Names, .onion addresses can have
On 07/17/2015 02:57 PM, Paul Vixie wrote:
i would argue, by the way, that onion is a kind of technology, onion
routing, of which Tor is the first and best-known but not the last. so,
i'll prefer .tor.external over .onion.external.
[snip]
compared to alt, yes. note that .external is long
hellekin wrote:
On 07/17/2015 02:57 PM, Paul Vixie wrote:
i would argue, by the way, that onion is a kind of technology, onion
routing, of which Tor is the first and best-known but not the last. so,
i'll prefer .tor.external over .onion.external.
[snip]
compared to alt, yes. note that
+1
The issue not being with ONION per se, but with the .CARROTs and the
.FOOs of the future, having a reserved TLD/namespace with a registry
along with a well defined process on how to do reserve names should be
the way to go.
We also need to close the doors to those who decide to ignore
i think that deep discussion over whether .external is the right exit
gateway from dns naming is premature, and that we should first decide
whether a single exit gateway is preferred, and whether IANA should
craft a registry of external-to-the-dns uses of the internet name space.
i am in favour of
hellekin wrote:
On 07/17/2015 07:07 AM, Andrew Sullivan wrote:
On Thu, Jul 16, 2015 at 11:39:24PM -0700, Paul Vixie wrote:
we only need one cutout, something like .external, with an
IANA-maintained registry of non-dns uses, each pointing to an RFC
that describes as much as is possible
More seriously, does that mean you're opposing the .onion draft, or are
you simply drifting away to the later work on RFC6761bis? I'm asking
because the authors requested .onion, not .tor, nor .tor.alt, nor
.tor.external.
by 6761, .ONION is a valid request and your papers are in order. i
On 07/17/2015 03:10 PM, Paul Vixie wrote:
i apologize for the lack of a pre-existing syntactic framework into
which tor's names could have been encapsulated from the outset. i
apologize even more for the fact that tor's perfectly reasonable request
for .onion is now causing this working
On 7/18/15 12:16 AM, Ted Lemon wrote:
On 07/17/2015 01:35 AM, David Conrad wrote:
To be honest, I doubt this. It assumes folks who are developing
these non-DNS protocols know/care about what the IETF thinks.
I suspect that more do than you think. However, what they think
about the IETF is
On 07/17/2015 10:41 PM, John Levine wrote:
A mechanical criterion might be observable traffic from at least
100,000 different IP addresses every day for at least 30 days.
That'd be a horrible criterion, not least because it's easy
for a modestly well funded adversary to fake.
*** Also, if
With all due respect, this is a classic mistake that geeks make: thinking
that there can be some objective criterion or
set of criteria that would make decisions simple. ...
As I've said several times, I believe there are objective criteria that would
cover the majority of cases. ...
Perhaps
Em 17/07/2015, à(s) 17:08:000, Ted Lemon ted.le...@nominum.com escreveu:
On 07/17/2015 12:40 PM, Rubens Kuhl wrote:
- Deprecating that part of RFC6761 that allowed the .ONION request, shutting
this door;
This would likely result in Warren's draft never getting consensus, so be
careful
On 07/17/2015 01:35 AM, David Conrad wrote:
To be honest, I doubt this. It assumes folks who are developing these non-DNS
protocols know/care about what the IETF thinks.
I suspect that more do than you think. However, what they think about
the IETF is that we have a very heavyweight process,
Ted,
On Jul 18, 2015, at 12:16 AM, Ted Lemon ted.le...@nominum.com wrote:
With all due respect, this is a classic mistake that geeks make: thinking
that there can be some objective criterion or set of criteria that would make
decisions simple. The reality is that to make criteria of this
On 07/17/2015 12:40 PM, Rubens Kuhl wrote:
- Deprecating that part of RFC6761 that allowed the .ONION request, shutting
this door;
This would likely result in Warren's draft never getting consensus, so
be careful what you ask for. If you want to make this change, it would
be better to do it
On 07/17/2015 01:17 PM, Rubens Kuhl wrote:
I personally have no position whether we shut the door before or after .ONION;
there is already a number of names in this category so if .onion was the first
I would strongly oppose its adoption, but since it's not, it doesn't care for
the scale
On 07/17/2015 07:10 PM, David Conrad wrote:
Oh, and what non-objective criteria would those be?
The ones in the special-names RFC, which the author and the working
group apparently considered sufficient. Which, I am afraid, contradicts
the point you were making about how we can have
: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The .onion
Special-Use Domain Name) to Proposed Standard
[snip]
I try to be pragmatic. Given I do not believe that refusing to put ONION in the
special names registry will stop the use of .ONION, the size of the installed
base of TOR
On 16 July 2015 at 00:44, Joe Hildebrand hil...@cursive.net wrote:
I don't see any mention of the CAB Forum stuff in the draft. Has anyone
done the analysis to see if CAB Forum members really will issue certs to
.onion addresses if we do this? Do they issue certs for .example or .local
On 07/15/2015 02:45 PM, Francisco Obispo wrote:
It doesn’t feel right to me rewarding bad behavior.
I don't think it's fair to characterize this as bad behavior. It is
completely unsurprising behaviour, as I explained in some detail in a
previous message:
On Thu, Jul 16, 2015 at 12:44 AM, Joe Hildebrand hil...@cursive.net wrote:
On 15 Jul 2015, at 5:37, David Conrad wrote:
I try to be pragmatic. Given I do not believe that refusing to put ONION
in the special names registry will stop the use of .ONION, the size of the
installed base of TOR
On 7/16/15, 9:57, DNSOP on behalf of Tom Ritter dnsop-boun...@ietf.org
on behalf of t...@ritter.vg wrote:
On 16 July 2015 at 00:44, Joe Hildebrand hil...@cursive.net wrote:
I don't see any mention of the CAB Forum stuff in the draft. Has anyone
done the analysis to see if CAB Forum members
Well, even worse, what happens if name-your-next-OS-vendor decides to
create a new dns-like protocol that uses .foo, does that mean that we should
automatically block it?
No. We can add it to the special-use domain name registry if the IETF has
consensus to do so, but there's nothing
Ted,
To expand on this ever so slightly, the reason why things like this happen is
because the process for approving special-use allocations is perceived as too
heavyweight, so people don't bother to do it in anticipation of an experiment.
To be honest, I doubt this. It assumes folks who
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/15/2015 03:55 PM, David Conrad wrote:
I'm intrigued how you derived an insult from my statement
that it was squatting.
I guess that's the proximity of blunt and squatting that gave me
this impression.
You're wrong.
I stand
On 14 Jul 2015, at 22:16, Ted Hardie wrote:
Further, I believe this stretches the special handling requirement of RFC
6761 to the breaking point. This does not describe special handling _within
the DNS_, but instead removes a portion of the global namespace from the DNS
at all. To me, at
July 2015 17:02
To: dnsop@ietf.org
Subject: Re: [DNSOP] Last Call: draft-ietf-dnsop-onion-tld-00.txt (The
.onion Special-Use Domain Name) to Proposed Standard
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 07/14/2015 11:37 PM, David Conrad wrote:
To put it bluntly, from a certain
If we want to avoid future instances of squatting, it behooves us to
avoid applying too much process friction onto documents of this type.
Well, there's the problem. Personally, I entirely agree with you, and
I would prefer we err on the side of caution to prevent collsions
between special
On 07/15/2015 08:02 AM, hellekin wrote:
This is blunt in more than one aspect. That you consider squatting as a
negative is insulting for those people who actually need to rely on
squatting not to be excluded from society.
To expand on this ever so slightly, the reason why things like this
On 7/15/15, 14:12, Ted Lemon ted.le...@nominum.com wrote:
On 07/15/2015 11:04 AM, Edward Lewis wrote:
Keep in mind - I'm saying the document, the internet-draft, doesn't
contain all that it could or should to be a convincing use case.
Perhaps
it ticked off all the check boxes of RFC 6761, but I
On 07/15/2015 05:42 AM, Edward Lewis wrote:
As David says, .onion-names use is independent (to some extent) on whether
onion is registered in the Special Use Domain Names registry. What I am
writing here isn't a statement about whether onion is to registered, but
about the document applying for
On 07/15/2015 11:04 AM, Edward Lewis wrote:
That Ted.
Yup, Ted pointed that out to me privately--sorry. :)
Keep in mind - I'm saying the document, the internet-draft, doesn't
contain all that it could or should to be a convincing use case. Perhaps
it ticked off all the check boxes of RFC
On 7/14/15, 15:24:
The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document:
- 'The .onion Special-Use Domain Name'
draft-ietf-dnsop-onion-tld-00.txt as Proposed Standard
Having read the document plus Ted Hardie's and David Conrad's
+1.
I don’t think IETF should be chasing around widely used TLDs and
trying to block them, it will be a never ending chase.
We are trying to mitigate against unknowns and perhaps the best solution
is to have the TOR folks apply for .ONION on the next round of TLD
application and get a fully
This was proposed in the working group. It obviously doesn't work,
first because TOR can't come up with that kind of money, but second
because TOR doesn't want a TLD (hellekin's erroneous statements
notwithstanding). What they want is a special-use name. A domain
name does not
Hellekin,
On Jul 15, 2015, at 8:02 AM, hellekin helle...@gnu.org wrote:
To put it bluntly, from a certain perspective, 6762 and
dnsop-onion are essentially about the same thing: they are
formalizing squatting on namespace (by Apple in the first
instance and by TOR in the second).
On 07/15/2015 03:46 PM, Edward Lewis wrote:
What if I copied the onion draft, changed all of the uses of onion to
carrot, and then threw in some supporting documents to describe some
other system that used carrot as it's base identifier? On the heels
of onion's admission to the Special Use
Em 15/07/2015, à(s) 16:21:000, hellekin helle...@gnu.org escreveu:
On 07/15/2015 03:46 PM, Edward Lewis wrote:
What if I copied the onion draft, changed all of the uses of onion to
carrot, and then threw in some supporting documents to describe some
other system that used carrot as it's
On 07/15/2015 11:46 AM, Edward Lewis wrote:
What if I copied the onion draft, changed all of the uses of onion to
carrot, and then threw in some supporting documents to describe some other
system that used carrot as it's base identifier? On the heels of onion's
admission to the Special Use
1 - 100 of 116 matches
Mail list logo
