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

From: Tim Wicinski <[email-masked]>
Date: Wed, 20 May 2015 13:12:01 -0400

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

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 20 May 2015 13:55:11 -0400

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

> 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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 May 2015 18:05:54 -0400

On Wed, May 20, 2015 at 1:12 PM, Tim Wicinski <[email-masked]> 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.
>

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
> [email-masked]
> 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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 20 May 2015 19:27:05 -0400

On Wed, May 20, 2015 at 1:55 PM, Joe Abley <[email-masked]> wrote:
> 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.
>
> 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..." :-)

> 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...

---

From: "John Levine" <[email-masked]>
Date: 21 May 2015 03:41:35 -0000

>>> 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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 May 2015 12:11:42 -0400

> https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 - Section 4

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.

---

From: Tom Ritter <[email-masked]>
Date: Thu, 21 May 2015 11:16:51 -0500

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

-tom

---

From: "John Levine" <[email-masked]>
Date: 21 May 2015 16:31:38 -0000

>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

---

From: Bob Harold <[email-masked]>
Date: Thu, 21 May 2015 12:55:20 -0400

On Wed, May 20, 2015 at 1:55 PM, Joe Abley <[email-masked]> wrote:

> ...
> 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

---

From: "Joe Abley" <[email-masked]>
Date: Thu, 21 May 2015 13:15:08 -0400

Hi Bob,

> 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

---

From: Francisco Obispo <[email-masked]>
Date: Thu, 21 May 2015 10:35:31 -0700

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 <[email-masked]> wrote:
> 
> On Wed, May 20, 2015 at 1:55 PM, Joe Abley <[email-masked] <mailto:[email-masked]>> wrote:
> See https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 <https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06>  -
>> if the Tor project had used "onion.eff.org <http://onion.eff.org/>" instead of "onion", we would not
> https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06 <https://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-06> - Section 4
> - Advice to developers.
> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
> 
> 
> 
> --
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
Francisco Obispo
CTO - Registry Operations
____________________________

 <http://www.uniregistry.com/>
2161 San Joaquin Hills Road
Newport Beach, CA 92660

Office +1 949 706 2300 x4202
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 May 2015 13:46:13 -0400

On May 21, 2015, at 1:15 PM, Joe Abley <[email-masked]> 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.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 May 2015 13:48:41 -0400

> 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 wher…

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.

---

From: "John Levine" <[email-masked]>
Date: 21 May 2015 18:06:08 -0000

>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

---

From: Alec Muffett <[email-masked]>
Date: Thu, 21 May 2015 19:10:13 +0000

> On May 21, 2015, at 4:41 AM, John Levine <[email-masked]> wrote:
> 
> 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/ <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

---

From: "John R Levine" <[email-masked]>
Date: 21 May 2015 15:20:24 -0400

> 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, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 21 May 2015 15:21:13 -0400

> 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.

---

From: hellekin <[email-masked]>
Date: Thu, 21 May 2015 16:31:56 -0300

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 21 May 2015 12:59:42 -0700

On May 21, 2015, at 12:10 PM, Alec Muffett <[email-masked]> wrote:
> https://cabforum.org/2015/02/18/ballot-144-validation-rules-dot-onion-names/
> 

They can say whatever they want, and they can change their mind whenever they want. They can also ask us (for many different values of "us") before they make rules that require us to do something that affects their members.

--Paul Hoffman

---

From: str4d <[email-masked]>
Date: Thu, 21 May 2015 21:08:25 +0000 (UTC)

Bob Harold 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 
> [email-masked] https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Richard Barnes <[email-masked]>
Date: Sat, 23 May 2015 09:55:06 -0400

> 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

---

From: Richard Barnes <[email-masked]>
Date: Sat, 23 May 2015 10:35:43 -0400

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 <[email-masked]> wrote:

> 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
> Please review the draft and offer relevant comments. In particular, we’ve
> expected “special” treatment of .onion names in the field. So if people
> feel strongly about possible changes, we need to know.
>