Does this mean:
A: All implementations that conform to this document should prefer the
NTA over the positive anchor in such a case, or
B: This is implementation-dependent, but if an implementation allows
the coexistence of positive and negative anchors, it should prefer
the NTA,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Since Alec Muffett seems to have better things to do, I feel obligated
to do what he should have done before publishing his draft: comparing
the IANA Considerations for .onion in the
draft-grothoff-iesg-special-use-p2p-names-04 (P2PNames) and
Hi there,
On Mon, May 11, 2015 at 06:15:47PM -0300, hellekin wrote:
draft-appelbaum-dnsop-onion-tld-01 came as way to fast-track the
processing of .onion special-use TLD, as the P2PNames draft was
considered too controversial (and maybe too complicated?).
As one of the people who has
On Mon, May 11, 2015 at 7:21 PM, Alec Muffett al...@fb.com wrote:
Hi Hellekin!
Since Alec Muffett seems to have better things to do
I'm sorry if you've been waiting for my input - I am not the primary
author of the document; Jacob Appelbaum's name is in the document's
title for a good
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 05/11/2015 08:21 PM, Alec Muffett wrote:
This might be an issue so long as your threat model includes blindly
unaware users who are typing .onion addresses into non-Tor-capable
browsers in the (presumably first-time) expectation that it will
On Fri, May 08, 2015 at 08:10:41PM -0700, Paul Hoffman wrote:
- Will the IETF require some specific metrics for RFC 6761 reservations?
- If yes, what are those metrics?
- If no, who makes the non-specific decision?
Increasingly it strikes me that RFC 6761 is trying to do too much.
On Mon, May 11, 2015 at 09:29:02PM -0300, hellekin wrote:
*** How can you fail to see that P2PNames says Users can use these
names as they would other domain names, while OnionTLD says they cannot
?
I think people can see that, and they disagree with you.
If you put an onion name into an
Hi Hellekin!
Since Alec Muffett seems to have better things to do
I'm sorry if you've been waiting for my input - I am not the primary
author of the document; Jacob Appelbaum's name is in the document's
title for a good reason, and my involvement has been one of tuning a
few paragraphs,
At Sat, 9 May 2015 15:08:11 +0200,
Warren Kumari war...@kumari.net wrote:
1. In my very original comment on this matter:
www.ietf.org/mail-archive/web/dnsop/current/msg12614.html
I noted one other corner case, which we might also want to clarify:
On a related note, there are
On Mon, May 11, 2015 at 12:10 PM, 神明達哉 jin...@wide.ad.jp wrote:
At Sat, 9 May 2015 18:50:28 +,
Evan Hunt e...@isc.org wrote:
Actually, weirdly enough, after I implemented NTA's in BIND, one of the
very first applications somebody came up with for them was to temporarily
disable
On Mon, May 11, 2015 at 12:19:19PM -0400, Bob Harold wrote:
I am not even sure there is a good reason for a warning.
In BIND, NTA's are set by an rndc command, but in other implementations
they might be set up in a config file. If you have both a TA and an NTA
for the same node in the same
At Sat, 9 May 2015 18:50:28 +,
Evan Hunt e...@isc.org wrote:
Actually, weirdly enough, after I implemented NTA's in BIND, one of the
very first applications somebody came up with for them was to temporarily
disable DNSSEC validation by setting an NTA for .. This was seen as
better than
12 matches
Mail list logo
