[DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Tim Wicinski]

Greetings,

From the outcome of the Interim meeting, and discussion on the list, 
this draft appears to both have strong support and address the problem 
space of RFC 6761.  The authors have requested a Call for Adoption. The 
chairs want to move forward with this draft if it has consensus support.


It also seems that the document is relatively mature in terms of what 
people need to know in order to decide whether to support advancing it. 
As we have done with other drafts where a lengthy revision process 
didn’t seem necessary to reach a draft we could advance further, and in 
consideration of the timeliness constraint raised by the authors, the 
chairs are going to combine the adopting of the document with the 
Working Group Last Call.


The draft can be found here:

https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/

https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01

Please review the draft and offer relevant comments. In particular, 
we’ve heard reservations expressed about the precedent that might be set 
by advancing this document, and about the level of specification of the 
TOR protocols that we might like to see included in the descriptions of 
the expected “special” treatment of .onion names in the field. So if 
people feel strongly about possible changes, we need to know.


Because of the compression of adoption and WGLC, we're making this a 
three week window.  The working group last call will end on Wednesday 
June 10th, 2015.


thanks
tim

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Joe Abley]

On 20 May 2015, at 13:12, Tim Wicinski wrote:


The draft can be found here:

https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/

https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01

Please review the draft and offer relevant comments.


I have read this document. I support it's adoption by the working group. 
I am willing to review future revisions of the draft, and to contribute 
text if that seems useful.


The document uses the phrase "top-level domain" all over the place to 
describe .onion. That phrase to me seems indelibly linked to its meaning 
in the context of the DNS; in the case of Tor, however, we're not 
talking about the DNS at all, but rather the use of a completely 
separate namespace that just happens to be syntactically equivalent to 
DNS names.


The purpose of the document should not be to create a top-level domain 
in the usual/DNS sense; rather it's to prevent such a top-level domain 
(i.e. a delegation from the root zone for the owner name "onion") from 
ever existing, since that would make things confusing for applications.


I support the idea that the running code evident in the tor network 
should properly trump any process or policy that would otherwise make it 
difficult to make the DNS-specific recommendations on resolvers and the 
root zone encapsulated here. I just think the different contexts should 
be more clearly delineated.


I would also support (as I have heard others say before, and as I think 
I have also said) a separate document that provides advice to anybody 
else planning to deploy code that uses a DNS-like namespace that is not 
the DNS. Such people should either make their names unambiguously 
different from those used in the DNS, or should anchor them somewhere 
else in the namespace where defensive registrations in the DNS are less 
contentious. For example, if the Tor project had used "onion.eff.org" 
instead of "onion", we would not be having this conversation. Making 
such guidance available would make it far easier to deal with the future 
possibility that a decision with "onion" would set an unfortunate 
precedent.


Note that I am definitively not criticising the Tor project for their 
choices back at a time when there was no such guidance available. I 
think they are all to be congratulated for causing us this headache, 
since at its core that headache is a symptom of their success of 
enhancing the privacy and freedom of everybody who uses their software.



Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Warren Kumari]

On Wed, May 20, 2015 at 1:12 PM, Tim Wicinski  wrote:
>
> Greetings,
>
> From the outcome of the Interim meeting, and discussion on the list, this
> draft appears to both have strong support and address the problem space of
> RFC 6761.  The authors have requested a Call for Adoption. The chairs want
> to move forward with this draft if it has consensus support.
>
> It also seems that the document is relatively mature in terms of what people
> need to know in order to decide whether to support advancing it. As we have
> done with other drafts where a lengthy revision process didn’t seem
> necessary to reach a draft we could advance further, and in consideration of
> the timeliness constraint raised by the authors, the chairs are going to
> combine the adopting of the document with the Working Group Last Call.
>
> The draft can be found here:
>
> https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/
>
> https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01
>
> Please review the draft and offer relevant comments.

I have read the document (and provided comments to the author / list).

I support adoption and believe it is almost ready for WGLC (when I
read it last time I was only thinking of adoption, not WGLC. I'll
reread with a stricter eye).

W

>  In particular, we’ve
> heard reservations expressed about the precedent that might be set by
> advancing this document, and about the level of specification of the TOR
> protocols that we might like to see included in the descriptions of the
> expected “special” treatment of .onion names in the field. So if people feel
> strongly about possible changes, we need to know.
>
> Because of the compression of adoption and WGLC, we're making this a three
> week window.  The working group last call will end on Wednesday June 10th,
> 2015.
>
> thanks
> tim
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Warren Kumari]

On Wed, May 20, 2015 at 1:55 PM, Joe Abley  wrote:
> On 20 May 2015, at 13:12, Tim Wicinski wrote:
>
>> The draft can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/
>>
>> https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01
>>
>> Please review the draft and offer relevant comments.
>
>
> I have read this document. I support it's adoption by the working group. I
> am willing to review future revisions of the draft, and to contribute text
> if that seems useful.
>
> The document uses the phrase "top-level domain" all over the place to
> describe .onion. That phrase to me seems indelibly linked to its meaning in
> the context of the DNS; in the case of Tor, however, we're not talking about
> the DNS at all, but rather the use of a completely separate namespace that
> just happens to be syntactically equivalent to DNS names.
>
> The purpose of the document should not be to create a top-level domain in
> the usual/DNS sense; rather it's to prevent such a top-level domain (i.e. a
> delegation from the root zone for the owner name "onion") from ever
> existing, since that would make things confusing for applications.
>
> I support the idea that the running code evident in the tor network should
> properly trump any process or policy that would otherwise make it difficult
> to make the DNS-specific recommendations on resolvers and the root zone
> encapsulated here. I just think the different contexts should be more
> clearly delineated.
>
> I would also support (as I have heard others say before, and as I think I
> have also said) a separate document that provides advice to anybody else
> planning to deploy code that uses a DNS-like namespace that is not the DNS.

[ Warning! Sales pitch below :-) ]

See https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06  -
Section 4 - Advice to developers.

> Such people should either make their names unambiguously different from
> those used in the DNS, or should anchor them somewhere else in the namespace
> where defensive registrations in the DNS are less contentious. For example,
> if the Tor project had used "onion.eff.org" instead of "onion", we would not
> be having this conversation.

This is also in
https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 - Section 4
- Advice to developers.

>  Making such guidance available would make it
> far easier to deal with the future possibility that a decision with "onion"
> would set an unfortunate precedent.

Yup, .onion could be seen as a precedent -- but, if we have .alt we
can say "Now there is a known place to do these sorts of things (there
wasn't when .onion started), you should have used that..." :-)

>
> Note that I am definitively not criticising the Tor project for their
> choices back at a time when there was no such guidance available.

Me neither -- I think .onion is a no brainer. It meets all the
requirements, and is widely used but, providing guidance and a
safe place to experiment in the future seems very valuable.

> I think
> they are all to be congratulated for causing us this headache, since at its
> core that headache is a symptom of their success of enhancing the privacy
> and freedom of everybody who uses their software.

Yah. I'm not sure I'd congratulate them for causing a headache, but
definitely congratulations and thanks for a valuable product...

>
>
> Joe
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[John Levine]

In article  
you write:
>On Wed, May 20, 2015 at 1:55 PM, Joe Abley  wrote:
>> On 20 May 2015, at 13:12, Tim Wicinski wrote:
>>
>>> The draft can be found here:
>>>
>>> https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/
>>>
>>> https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01
>>>
>>> Please review the draft and offer relevant comments.

I've reread it and still think we should adopt it.

I share the concerns about calling .onion a TLD, but I think that's
easily fixable by calling it something like a special purpose
namespace, then going through the document and changing it where
appropriate.  When it's talking about stuff that happens through Tor,
it's a special purpose namespace, when about mitigating problems due
to leakage of queries into ordinary DNS software, that's where we say
there won't be a TLD with that name.

Yeah, in a world where everyone was prescient it'd be .onion.alt or
something like that, but we're the Internet Engineering Task Force,
not the Internet Theology Task Force.  Part of engineering is knowing
when to prefer a kludge that works over a beautiful design that won't.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Ted Lemon]

On May 20, 2015, at 7:27 PM, Warren Kumari  wrote:
>> Such people should either make their names unambiguously different from
>> those used in the DNS, or should anchor them somewhere else in the namespace
>> where defensive registrations in the DNS are less contentious. For example,
>> if the Tor project had used "onion.eff.org" instead of "onion", we would not
>> be having this conversation.
> 
> This is also in
> https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 - Section 4
> - Advice to developers.

Unfortunately, I do not think this is good advice.   Domain registrations have 
to be renewed, and while I hope the EFF lasts for a long time, there is no 
reason to think it will outlive the .onion domain, and even if it does, that it 
will not be rebranded at some point in the future.   Special-use domains that 
have actual protocol uses should not be hung off of domains that are subject to 
renewal.   So while I think .ALT would work for this use case (issues of 
brevity aside), I think eff.org will not.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Tom Ritter]

I've read, I support, I will continue to read and contribute.

-tom

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[John Levine]

>Unfortunately, I do not think this is good advice.   Domain registrations have 
>to
>be renewed, ...

There are domain registrations that don't have to be renewed, but I
still agree with your advice.  We don't want to tell people to balance 
a long term design on a short term foundation.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Bob Harold]

On Wed, May 20, 2015 at 1:55 PM, Joe Abley  wrote:

> ...
> I would also support (as I have heard others say before, and as I think I
> have also said) a separate document that provides advice to anybody else
> planning to deploy code that uses a DNS-like namespace that is not the DNS.
> Such people should either make their names unambiguously different from
> those used in the DNS, or should anchor them somewhere else in the
> namespace where defensive registrations in the DNS are less contentious.
> For example, if the Tor project had used "onion.eff.org" instead of
> "onion", we would not be having this conversation. Making such guidance
> available would make it far easier to deal with the future possibility that
> a decision with "onion" would set an unfortunate precedent.
>
...
The "onion.eff.org" idea only solves half of the problems - it would
prevent others from using the domain for something else, but it fails to
provide the required privacy - part of the requirement is that the onion
names NOT be sent to DNS servers at all, for privacy.

 --
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Joe Abley]

Hi Bob,

On 21 May 2015, at 12:55, Bob Harold wrote:


The "onion.eff.org" idea only solves half of the problems - it would
prevent others from using the domain for something else, but it fails 
to
provide the required privacy - part of the requirement is that the 
onion

names NOT be sent to DNS servers at all, for privacy.


Ted's comment about the mutability of a domain that might expire vs. the 
requirements of a protocol registration resonated strongly with me. I 
agree with him; I think my "onion.eff.org" thinking was inadequate.


To your point though, I don't think we can ever practically prevent a 
query being sent to the DNS. There are no controls available to us that 
would allow us to do that.



Joe

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Francisco Obispo]

Hi Warren,

Just finished reading the draft (for ALT), but still think this is not going to 
help.

The statement:

They SHOULD choose a label that they expect to be unique and, ideally, 
descriptive.

Is something that in reality won’t happen, and we will be back to square one. 
“foo.ALT” is going to be very popular and without a registry to control the 
namespace you’ll end up in a situation where more than one application will 
attempt to connect to the wrong server (names collision problem).

Nowadays there are a lot of options for registering a domain name, in my 
opinion the best practice should be to register a domain name and build on top 
of it. The concept of an application that does not need to be connected to the 
Internet is going to be hard to maintain, specially in a world where we have 
IPv6 and other P2P technologies.

Applications MUST NOT rely on DNS names to authenticate themselves, that is, 
must never send credentials to a server without validating its identity. I 
think that’s where the effort should go, DNSSEC, DANE, etc. not on trying to 
prevent people from doing stupid things, it’s not going to work and it’s going 
to move us away from the real goal, creating an illusion that we’ve solved a 
problem.

Regards,


> On May 20, 2015, at 4:27 PM, Warren Kumari  wrote:
> 
> On Wed, May 20, 2015 at 1:55 PM, Joe Abley  > wrote:
>> On 20 May 2015, at 13:12, Tim Wicinski wrote:
>> 
>>> The draft can be found here:
>>> 
>>> https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/
>>> 
>>> https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01
>>> 
>>> Please review the draft and offer relevant comments.
>> 
>> 
>> I have read this document. I support it's adoption by the working group. I
>> am willing to review future revisions of the draft, and to contribute text
>> if that seems useful.
>> 
>> The document uses the phrase "top-level domain" all over the place to
>> describe .onion. That phrase to me seems indelibly linked to its meaning in
>> the context of the DNS; in the case of Tor, however, we're not talking about
>> the DNS at all, but rather the use of a completely separate namespace that
>> just happens to be syntactically equivalent to DNS names.
>> 
>> The purpose of the document should not be to create a top-level domain in
>> the usual/DNS sense; rather it's to prevent such a top-level domain (i.e. a
>> delegation from the root zone for the owner name "onion") from ever
>> existing, since that would make things confusing for applications.
>> 
>> I support the idea that the running code evident in the tor network should
>> properly trump any process or policy that would otherwise make it difficult
>> to make the DNS-specific recommendations on resolvers and the root zone
>> encapsulated here. I just think the different contexts should be more
>> clearly delineated.
>> 
>> I would also support (as I have heard others say before, and as I think I
>> have also said) a separate document that provides advice to anybody else
>> planning to deploy code that uses a DNS-like namespace that is not the DNS.
> 
> [ Warning! Sales pitch below :-) ]
> 
> See https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 
>   -
> Section 4 - Advice to developers.
> 
>> Such people should either make their names unambiguously different from
>> those used in the DNS, or should anchor them somewhere else in the namespace
>> where defensive registrations in the DNS are less contentious. For example,
>> if the Tor project had used "onion.eff.org " instead 
>> of "onion", we would not
>> be having this conversation.
> 
> This is also in
> https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 
>  - Section 4
> - Advice to developers.
> 
>> Making such guidance available would make it
>> far easier to deal with the future possibility that a decision with "onion"
>> would set an unfortunate precedent.
> 
> Yup, .onion could be seen as a precedent -- but, if we have .alt we
> can say "Now there is a known place to do these sorts of things (there
> wasn't when .onion started), you should have used that..." :-)
> 
>> 
>> Note that I am definitively not criticising the Tor project for their
>> choices back at a time when there was no such guidance available.
> 
> Me neither -- I think .onion is a no brainer. It meets all the
> requirements, and is widely used but, providing guidance and a
> safe place to experiment in the future seems very valuable.
> 
>> I think
>> they are all to be congratulated for causing us this headache, since at its
>> core that headache is a symptom of their success of enhancing the privacy
>> and freedom of everybody who uses their software.
> 
> Yah. I'm not sure I'd congratulate them for causing a headache, but
> definitely congratulations and thanks for a valuable product...
> 
>> 
>> 
>

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Ted Lemon]

On May 21, 2015, at 1:15 PM, Joe Abley  wrote:
> To your point though, I don't think we can ever practically prevent a query 
> being sent to the DNS. There are no controls available to us that would allow 
> us to do that.

This is unfortunately true.   However, there are varying degrees of control we 
could have over these.   It would make sense for at least open source resolvers 
and probably for other resolvers to add .onion to the switch that already 
handles .local, and to ensure therefore that .onion queries that hit the 
resolver either are resolved using the correct protocol, or that no attempt is 
made to resolve them.

This would be much more difficult to do with .onion.eff.org.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Ted Lemon]

On May 21, 2015, at 1:35 PM, Francisco Obispo  wrote:
> Is something that in reality won’t happen, and we will be back to square one. 
> “foo.ALT” is going to be very popular and without a registry to control the 
> namespace you’ll end up in a situation where more than one application will 
> attempt to connect to the wrong server (names collision problem).

This is a really good point.   I think there does need to be a .ALT registry in 
order for .ALT to be able to address anything other than experimental uses.   
And I think this would actually be a good thing.   Experimental uses could 
either come under .EXP (I will probably get flamed for that, but please don't 
take it too seriously) or .EXP.ALT.

Of course, if we had a registry for .ALT, I suppose there would be a land rush 
on it, but if we don't have one I think that will be even worse.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[John Levine]

>They SHOULD choose a label that they expect to be unique and, ideally, 
>descriptive.
>
>Is something that in reality won't happen, ...

Sure it will, for the same reason that the alt.* newsgroups worked and
continue to work.

Remember, this isn't the DNS.  The way you stake a claim to alt.foo is
to write software that implements whatever alt.foo is supposed to do
and get people to use it.  If two different people went to that effort
and found that they collided, that would be a huge pain for both, so
it's worth some effort to avoid that pain.  The idea of parking or
squatting on an alt.* name makes no sense.

To help avoid the pain, I think it would be swell to have informal
lists of the alt.* names, just as there are usenet servers with
informal lists of the alt.* newsgroups.  I would be happy to run such
a list with the clear understanding that the only rule for
registration is that you have to put something comprehensible in each
field of the form, and that multiple entries for the same name are
cheerfully accepted.  Maybe I would weed out the ones for projects
that appear to be dead, maybe not.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Alec Muffett]

> On May 21, 2015, at 4:41 AM, John Levine  wrote:
> 
> I share the concerns about calling .onion a TLD, but I think that's
> easily fixable by calling it something like a special purpose
> namespace, then going through the document and changing it where
> appropriate.

Not to complicate matters, but CA/B-Forum are saying the following:

https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/ 


> 5. CAs MUST NOT issue a Certificate that includes a Domain Name where .onion 
> is in the right-most label of the Domain Name with a validity period longer 
> than 15 months. Despite Section 9.2.1 of the Baseline Requirements 
> deprecating the use of Internal Names, a CA MAY issue a Certificate 
> containing an .onion name with an expiration date later than 1 November 2015 
> after (and only if) .onion is officially recognized by the IESG as a reserved 
> TLD.

- my emphasis.

It would be a shame for them to nitpick the rules because "special purpose 
namespace" != "TLD"?

- Alec



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[John R Levine]

It would be a shame for them to nitpick the rules because "special purpose namespace" != 
"TLD"?


Is the CAB really likely to waste its time on that?  I don't know them, I 
have no idea.  I'd hope they had better things to worry about if it's 
abundantly clear whether we've declared .onion to be special.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Ted Lemon]

On May 21, 2015, at 3:10 PM, Alec Muffett  wrote:
> It would be a shame for them to nitpick the rules because "special purpose 
> namespace" != "TLD"?

It would make sense to call it a reserved special-use top-level domain name.   
It's not a top-level domain in the DNS, though.   I think that's the 
distinction to make.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[hellekin]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 05/21/2015 04:21 PM, Ted Lemon wrote:
> 
> It would make sense to call it a reserved special-use top-level domain
 name.
> It's not a top-level domain in the DNS, though.
> I think that's the distinction to make.
> 
*** A distinction that the P2PNames draft made:

   The abbreviation "pTLD" is used in this document to mean a pseudo
   Top-Level Domain, i.e., a Special-Use Domain Name per [RFC6761]
   reserved to P2P Systems in this document.  A pTLD is mentioned in
   capitals, and within double quotes to mark the difference with a
   regular DNS gTLD.

In the introduction, we specify the shared characteristics of pTLDs:

The set of Special-Use Domain Names for Peer-to-Peer Systems (pTLDs)
   reserved by this document meet this requirement, as they share the
   following specificities:

   o  pTLDs are not manageable by some designated administration.
  Instead, they are managed according to various alternate
  strategies or combinations thereof, introduced in this document,
  and their respective protocol specifications: automated
  cryptographic assignment (".onion", ".zkey"), user-controled
  assignment in a private scope (".gnu", ".i2p"), or in a global
  public ledger (".bit"), or used as a source-routing mechanism to
  delegate DNS resolution to a remote peer (".exit").

   o  pTLDs do not depend on the DNS context for their resolution: GNS
  and Namecoin domains MAY use the DNS servers infrastructure, as
  they return DNS-compatible results; and all pTLDs use specific P2P
  protocols for regular name resolution, covered by their respective
  protocol specifications.

   o  When a pTLD protocol has been implemented, the implementation MUST
  intercept queries for the pTLD to ensure P2P names cannot leak
  into the DNS.

   o  The appropriate pTLD protocols can be implemented in existing
  software libraries and APIs to extend regular DNS operation and
  enable P2P name resolution.  However, the default hierarchical DNS
  response to any request to any pTLD MUST be NXDOMAIN.

   o  Finally, in order for pTLDs to realize a censorship-resistant,
  fully-decentralized name system, and provide security and privacy
  features matching user expectations, this document specifies
  changes required in existing DNS software and DNS operations.

==
hk
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQJ8BAEBCgBmBQJVXjKhXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQ0IyNkIyRTNDNzEyMTc2OUEzNEM4ODU0
ODA2QzM2M0ZDMTg5ODNEAAoJEEgGw2P8GJg9sR0P/RdE7DV7G8tmeJ75tAAS3lmC
Au1SiOjeCdB1kN5ztifd6AvffeOqxueIUisvw7P1Tefow94kLOqR01gcfNd3q5kq
nj52NmAya6dvnG3pCiyzclQviaZ3FxPOy5Bc1a8nwgCf+Km5Ze0AAjPmev7Y7QUD
yrTaw7GpOdn6Q63VgFcekMbN7hEXpV2wY7U0dLEXvn0IKbggVFTjMf2T81FBNrlv
6shf9iqgso4ocUHz7CjZo3oyc+7uZcIZxJkBoi6a4AYO/s8nDWCv/cJF4Vx69Eej
FRhBdqcngZtlDuUAcSTX6tCfYL8OAu2Lr3qKfL5seYxyluoghaRZ2RxR0kJbPgPa
xI58qJZ44R5mNHfQ9JYJzo6Y4RU9XaK7/Wf7GanwnImYw0S/XbokwsJjf45rqhVj
HYee6KuKNMj6Q46bIclBa/tmyVmWkRVoTnjr2dWf9L9+HzK4MfmRnzFim+9+jnYb
8ultuqWsmh7s5NnTaUlincGO1m9tXoqxSmAy9y6IG2LnkvDUOUelQAhtkFOEy4iB
6vnWv25V9vBewX9akqdCTZL53TAp3hFzcr+ku1j5qNjrkbTrUVHqENbf0fUUp7Rj
U+wIky95YOrHDECiPDvPzAJw6dLQI+3TuytFChTFBV53yOH4bRCoiLUOcISJ5ULS
ELRKa+P9ejBy73uJJVr7
=bz5s
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[str4d]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bob Harold wrote:
> On Wed, May 20, 2015 at 1:55 PM, Joe Abley 
> wrote:
> 
>> ... I would also support (as I have heard others say before, and
>> as I think I have also said) a separate document that provides
>> advice to anybody else planning to deploy code that uses a
>> DNS-like namespace that is not the DNS. Such people should either
>> make their names unambiguously different from those used in the
>> DNS, or should anchor them somewhere else in the namespace where
>> defensive registrations in the DNS are less contentious. For
>> example, if the Tor project had used "onion.eff.org" instead of 
>> "onion", we would not be having this conversation. Making such
>> guidance available would make it far easier to deal with the
>> future possibility that a decision with "onion" would set an
>> unfortunate precedent.
>> 
> ... The "onion.eff.org" idea only solves half of the problems - it
> would prevent others from using the domain for something else, but
> it fails to provide the required privacy - part of the requirement
> is that the onion names NOT be sent to DNS servers at all, for
> privacy.

The other reason this fails (partly linked to the privacy issue above)
is because it puts the entire .onion domain in control of a single
zone file. Even if the organization controlling that zone file is
trustworthy, it only takes a single compromise (and who hasn't heard
of DNS zones being hijacked?) for someone to add "legitimate" records
for e.g. facebookcorewwwi.onion.eff.org pointing to malicious servers
on the clearnet. This is not a privacy issue, it is a direct and
abject compromise of the security properties expected of a .onion addres
s.

For apps that already have a centralized model, the suggestion is not
as bad. But for .onion (and the .TLDs in the P2PNames draft),
centralized control is exactly what the technical protocols are
avoiding, and it is irresponsible to provide a "golden key" that could
be used to subvert them.

str4d

> 
> -- Bob Harold
> 
> 
> 
> ___ DNSOP mailing list 
> DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
> 
-BEGIN PGP SIGNATURE-

iQIcBAEBCgAGBQJVXkk+AAoJEBO17ljAn7Pgm8MP/iIh8IOPTIKiUd2Ka59P8iEg
D+YJkMWD3IAuOER8cnGs2Nz7I5JGxxQdc5AUTUKmwnCHp9M7N2RQIuXWOczZ7izE
/XzY9ZojgVb/CvDqPG5qTR8kAo+Q3NHX3r5Dj+dJJUmVpP3i5toHpekXSHtwBUm4
pieRpL/3x9GQHTqg2GAwsqEFHMK7821Wy4QBslt7Q8zb7CqS+0yLHyWYs1cYNXQp
vKP92yR2UGiW+iwvQAAWlXnfFgzS4Rjrnkz8oMBuLa9zEa5r5puFAMoqSTmu8IcT
i345lUQ7ZsQ3OzfILGsvisGhJ4cyGVFvm0qvbGZNC3FPReAyge3EoQUDrgme+Fsc
hNRKwMjWL5NIHG8iPxs6Wu+u7QebYA/jBUQPNi1WgEpPeU5SRRStu45jOHtH/V8U
t6+8tzu4pyqPEHoemfuSdxE3FvFTSaknba3iYhEXZIDAzF6FNTMuUUJqLekH6zCy
+KA4K9f/NR/jOrUDkgV8f/x5HFApoZOnutOL4m/k7aNbK6gCIs/Lz/2NGD5MtZ6b
5GrQQixDrbarw7OpNeVv9v2bT4JP33vxf5ZexFUJg+jyyM0kzxaWMvmOANRAaDHf
vorzDKCmMRDx6f4OxwWXfVe1nM7+DTzd2WS6YCoPSOf6cJBRKcuYj5sNk+Lp+XvD
GX8ByEF3laN93RaLKDkA
=hfI/
-END PGP SIGNATURE-

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Richard Barnes]

On Thu, May 21, 2015 at 3:20 PM, John R Levine  wrote:

> It would be a shame for them to nitpick the rules because "special purpose
>> namespace" != "TLD"?
>>
>
> Is the CAB really likely to waste its time on that?  I don't know them, I
> have no idea.  I'd hope they had better things to worry about if it's
> abundantly clear whether we've declared .onion to be special.
>

Speaking with my "CAB Forum member" hat on, I would be happy to make the
argument there that they should allow CAs to issue for special purpose
names, as long as they follow validation procedures appropriate to each
special-purpose namespace.  (Though clearly, I can't guarantee an outcome.)

The critical thing is having a clear designation, rather than the ambiguity
we have now.

--Richard


>
> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
>
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Richard Barnes]

tl;dr: Ship it.

On adoption: I agree that we should adopt this document.

On WGLC: I have reviewed this document, and I think it's generally in fine
shape to send to the IESG.  I have included a few comments below, but
they're mostly editorial.  The only issue of any substance is that I would
prefer some of the SHOULDs be MUSTs, for extra clarity.

Thanks to the WG for the good discussion, and to the chairs for acting with
lightning speed in IETF terms.

--Richard


"""
   This information is not meaningful to the Tor
   protocol, but can be used in application protocols like HTTP
   [RFC7230].
"""

It took me a second to process what this meant.  Would the following
phrasing be correct?

"""
   Labels beyond the first label under ".onion" are not used by
   the Tor routing, so for example, "foo.example.onion" will route
   to (and authenticate) the same Tor service as "example.onion".
   However, additional labels might be used by application services
   to distinguish different sub-services accessible via the same Tor
   service.  In the case of HTTP, for example, the full name, with
   all labels, will be included in the Host header, and can be used
   to identify HTTP virual hosts on a common server.
"""

Might not be necessary to clarify this much, but like I said, it wasn't
obvious to me what the sub-label handling would be.


--


"Note that this draft was preceded by
[I-D.grothoff-iesg-special-use-p2p-names] ..."

This paragraph can probably be deleted in the final version.


--


"The ".onion" Special-Use TLD" -> "The ".onion" Special-Use Domain Name"

(For consistency with RFC 6761)


--


"""
   ... or using a proxy (e.g., SOCKS [RFC1928])
   to do so.  Applications that do not implement the Tor protocol
   SHOULD generate an error upon the use of .onion, and SHOULD NOT
   perform a DNS lookup.
"""

It might be worth noting that in the scope of the last sentence,
"Applications" includes proxies.  That is, your proxy should n't generate a
DNS request if it gets a .onion request either.  I would just add
"(including proxies)" between "protocol" and "SHOULD".


--


"""
   3.  Name Resolution APIs and Libraries: Resolvers that implement the
   Tor protocol MUST either respond to requests for .onion names by
   resolving them (see [tor-rendezvous]) or by responding with
   NXDOMAIN.  Other resolvers SHOULD respond with NXDOMAIN.
"""

This seems a little backward.  It seems like the general requirement is
that resolvers MUST either resolve over Tor or return NXDOMAIN.  If you
don't support Tor, you just fall in the latter bucket.  Don't be afraid to
MUST DNS servers, here or in the subsequent points.


--



On Wed, May 20, 2015 at 1:12 PM, Tim Wicinski  wrote:

>
> Greetings,
>
> From the outcome of the Interim meeting, and discussion on the list, this
> draft appears to both have strong support and address the problem space of
> RFC 6761.  The authors have requested a Call for Adoption. The chairs want
> to move forward with this draft if it has consensus support.
>
> It also seems that the document is relatively mature in terms of what
> people need to know in order to decide whether to support advancing it. As
> we have done with other drafts where a lengthy revision process didn’t seem
> necessary to reach a draft we could advance further, and in consideration
> of the timeliness constraint raised by the authors, the chairs are going to
> combine the adopting of the document with the Working Group Last Call.
>
> The draft can be found here:
>
> https://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/
>
> https://tools.ietf.org/html/draft-appelbaum-dnsop-onion-tld-01
>
> Please review the draft and offer relevant comments. In particular, we’ve
> heard reservations expressed about the precedent that might be set by
> advancing this document, and about the level of specification of the TOR
> protocols that we might like to see included in the descriptions of the
> expected “special” treatment of .onion names in the field. So if people
> feel strongly about possible changes, we need to know.
>
> Because of the compression of adoption and WGLC, we're making this a three
> week window.  The working group last call will end on Wednesday June 10th,
> 2015.
>
> thanks
> tim
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
>
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Andrew Sullivan]

On Thu, May 21, 2015 at 01:48:41PM -0400, Ted Lemon wrote:
> 
> This is a really good point.   I think there does need to be a .ALT registry 
> in order for .ALT to be able to address anything other than experimental uses.
And I think this would actually be a good thing.

If we created a registry for alt, how would alt not be just another
TLD with exactly the same status as any other domain name registry?
You can already register a name in the DNS registries and not turn it
on in the DNS.

What you're suggesting is that the IETF run a parallel registry for
people who don't want to pay registrars and registries.  I think it
would be unwise for the IETF to get into that business.

Best regards,

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Bob Harold]

On Thu, Jun 4, 2015 at 11:59 AM, Andrew Sullivan 
wrote:

> On Thu, May 21, 2015 at 01:48:41PM -0400, Ted Lemon wrote:
> >
> > This is a really good point.   I think there does need to be a .ALT
> registry in order for .ALT to be able to address anything other than
> experimental uses.
> And I think this would actually be a good thing.
>
> If we created a registry for alt, how would alt not be just another
> TLD with exactly the same status as any other domain name registry?
> You can already register a name in the DNS registries and not turn it
> on in the DNS.
>
> What you're suggesting is that the IETF run a parallel registry for
> people who don't want to pay registrars and registries.  I think it
> would be unwise for the IETF to get into that business.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> a...@anvilwalrusden.com


I think the difference is that ".alt" names should not be leaked into DNS,
but should be kept private.  I assume that DNS registrations have a cost
partly because of the infrastructure required if one chooses to publish
them in DNS.  Registrations under ".alt" would not have this overhead -
they should never reach DNS.  The whole purpose of a registry for ".alt"
sub-domains is simply to avoid name collisions.

-- 
Bob Harold
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[John Levine]

>> This is a really good point.   I think there does need to be a .ALT registry 
>> in order for .ALT to be able to
>address anything other than experimental uses.
>And I think this would actually be a good thing.
>
>If we created a registry for alt, how would alt not be just another
>TLD with exactly the same status as any other domain name registry?
>You can already register a name in the DNS registries and not turn it
>on in the DNS.

I think the key difference would be that it would accept any number of
entries for the same string, and would have a pointer to the place
where you can download the code that implements it.  If you use
foo.alt and I use foo.alt, well, that's our problem.  There is also no
reason to have only one such registry, or why any organization with a
name starting with "I" would run any of them.

As I mentioned before, given that the whole point of .alt is that
people are implementing things that look like DNS names but are
resolved in some other way, the winner of any such conflict is the one
with widely used running code.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Andrew Sullivan]

On Thu, Jun 04, 2015 at 07:53:02PM -, John Levine wrote:
> I think the key difference would be that it would accept any number of
> entries for the same string

I thought that Ted's idea was uniqueness.  (Otherwise there wouldn't
be a landrush.)

I agree that if you had a registry that had no unique entry, there'd
be no problem.  But if you have to be prepared for identifier
collisions anyway, what use is the registry?

A


-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Andrew Sullivan]

On Thu, Jun 04, 2015 at 12:16:05PM -0400, Bob Harold wrote:
> 
> I think the difference is that ".alt" names should not be leaked into DNS,
> but should be kept private.

But there will be such leaks, so that's no defence.  And for local
use, a DNS leak wouldn't be an issue either, some would argue, and
then alt turns into RFC 1918 for DNS.  (Although arguably we have that
with local anyway.)

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[John Levine]

>I agree that if you had a registry that had no unique entry, there'd
>be no problem.  But if you have to be prepared for identifier
>collisions anyway, what use is the registry?

It tells you where to find out about foo.alt if you want to use that
particular un-DNS hack.  Other than that, not much.  

Given the experience with usenet alt.*, it appears that in the absence
of a daddy to declare a winner when names collide, name collision
problems go away because it is much easier to avoid them than to
argue.  People used to the ICANN environment may find this a
conceptual challenge, but that's their problem.

R's,
John

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Warren Kumari]

On Thu, Jun 4, 2015 at 3:53 PM, John Levine  wrote:
>>> This is a really good point.   I think there does need to be a .ALT 
>>> registry in order for .ALT to be able to
>>address anything other than experimental uses.
>>And I think this would actually be a good thing.
>>
>>If we created a registry for alt, how would alt not be just another
>>TLD with exactly the same status as any other domain name registry?
>>You can already register a name in the DNS registries and not turn it
>>on in the DNS.
>
> I think the key difference would be that it would accept any number of
> entries for the same string, and would have a pointer to the place
> where you can download the code that implements it.  If you use
> foo.alt and I use foo.alt, well, that's our problem.  There is also no
> reason to have only one such registry, or why any organization with a
> name starting with "I" would run any of them.

I think that such a list / resource would be a fine idea, but I think that:
A: it would be good to avoid calling it a "registry" (that term has
specific meaning within the DNS world), and
B: it would also be good if someone (or someones) other than the IETF
ran them. This could be a person, like John for exmaple[0], or just
something like a wikipedia page Some of my reason for writing the
.alt draft was because I get more than enough ICANN politics at ICANN
meetings -- I *so* don't want special use names to become an
attractive niusence and have legal / trademark fights when someone
launches an alternate name resolution system for finding drugs and
calls it 'coke.alt'.

Having a place where I could go figure out what piece of software I
need to install to resolve http://0xdeadbeef.kitten.alt would be
really useful (even if the resource said that this could be any of 3
different alternate resolution methods - if it looks like a bunch of
hex is is probably KittenNet (install KittenRes0.23.tgz), if the
string is mainly badly spelt "words" it's likely LoLCat, try install
ICanHazNames from http://example.net :-)).


>
> As I mentioned before, given that the whole point of .alt is that
> people are implementing things that look like DNS names but are
> resolved in some other way, the winner of any such conflict is the one
> with widely used running code.

Yah. If I'm launching a new namespace that resolves based upon
, I have an incentive to choose a string that isn't already
being used by some other large, well known project, in the same way
that it would be silly for me to write a new UNIX program that does
something like cowsay (but with kittens) and call it 'cat'.

W



>
> R's,
> John
>
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[John R Levine]

As I mentioned before, given that the whole point of .alt is that
people are implementing things that look like DNS names but are
resolved in some other way, the winner of any such conflict is the one
with widely used running code.


Yah. If I'm launching a new namespace that resolves based upon
, I have an incentive to choose a string that isn't already
being used by some other large, well known project, in the same way
that it would be silly for me to write a new UNIX program that does
something like cowsay (but with kittens) and call it 'cat'.


Exactly.  The ICANN approach is what I might call the gold rush model -- 
people dash out to grab likely looking territory and squat on it before 
anyone else does.  This is more like homesteading -- there's a practically 
unlimited amount of territory, anyone can get some, but it you want to 
keep it, you have to live on it and improve it.


Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Edward Lewis]

On 6/5/15, 21:16, "Warren Kumari"  wrote:

>I think that such a list / resource would be a fine idea, but I think
>that:
>A: it would be good to avoid calling it a "registry" (that term has
>specific meaning within the DNS world), and

Not just in the DNS world.

To research this response, I looked up the definition or registry (place
that keeps a register) and register.  There are other meanings - including
a vocal register - but the central theme is a public record or an official
list, etc.  In many uses it is the official/public relationship of what
I've mentioned before.

>B: it would also be good if someone (or someones) other than the IETF
>ran them.

If for no other reason that the IETF isn't prone to operating services.

>This could be a person, like John for exmaple[0], or just
>something like a wikipedia page Some of my reason for writing the
>.alt draft was because I get more than enough ICANN politics at ICANN
>meetings -- I *so* don't want special use names to become an
>attractive niusence and have legal / trademark fights when someone
>launches an alternate name resolution system for finding drugs and
>calls it 'coke.alt'.

Sounds like you are trying to solve legal issues with engineering.

>Having a place where I could go figure out what piece of software I
>need to install to resolve http://0xdeadbeef.kitten.alt would be
>really useful (even if the resource said that this could be any of 3
>different alternate resolution methods - if it looks like a bunch of
>hex is is probably KittenNet (install KittenRes0.23.tgz), if the
>string is mainly badly spelt "words" it's likely LoLCat, try install
>ICanHazNames from http://example.net :-)).

The fact that the current Special-Use Domain Names doesn't do this
specifically is what makes me wonder what the benefit that registry offers.

>Yah. If I'm launching a new namespace that resolves based upon
>, I have an incentive to choose a string that isn't already
>being used by some other large, well known project, in the same way
>that it would be silly for me to write a new UNIX program that does
>something like cowsay (but with kittens) and call it 'cat'.

After reading this I'm less sure I understand what the solvable problem
is.  Collisions in identifiers have existed before the Internet and
continue external to the Internet.  Prevention of external events is
impossible, you can only hope to deal with them.

In a side conversation about "preventing" badness it was suggested to turn
the conversation towards "accommodating correct behavior."  What would it
take for someone to pick an identifier space and get it acknowledged?
Answering that may be more beneficial than figuring where in the DNS to
stick all these ad hoc naming schemes.  (After all, [in my opinion] the
DNS is not the root of all identifiers.)


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] Adoption and Working Group Last Call for draft-appelbaum-dnsop-onion-tld

[Tom Ritter]

On 23 May 2015 at 09:35, Richard Barnes  wrote:
> tl;dr: Ship it.

++

Nits:
 - Noted for the first time that the IETF boilerplate uses the oxford
comma. (I like the Oxford comma, but it seems most don't.)
 - "visually or apparently semantically similar to the desired
service" - not sure what "or apparently semantically" adds to this,
seems to be a repeat of "visually"

-tom

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop