<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
/* List Definitions */
@list l0
        {mso-list-id:1497064146;
        mso-list-template-ids:-1459080084;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:1.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:"Courier New";
        mso-bidi-font-family:"Times New Roman";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:1.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:2.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:3.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.0in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:;
        mso-level-tab-stop:4.5in;
        mso-level-number-position:left;
        text-indent:-.25in;
        mso-ansi-font-size:10.0pt;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Thanks Steve, you are correct, I used gTLDs instead of all TLDs, recognizing that some TLDs are under the auspices of the ccNSO, some are controlled by the US Government (.mil, .gov, .edu), some are under the control of ICANN (.int and
 .arpa (I think)).  However, SubPro did discuss a number of issues around the reservation of strings for other purposes.<o:p></o:p></p>
<p class="MsoNormal"><br>
For example, there is nothing in anyone of those 4 groups that requires the reservation of 3 character codes that match the ISO codes.  Nor is there anything in any one of those groups that states that we should reserve ALL 2 characters even those that do not
 correspond currently to country codes.  Yet despite that, the GNSO has decided to (a) not allocate any two character letter letter string because of the
<i>potential</i> that there may be a country in the future that needs its code and we would not want it to be delegated to another party; and (b) The GNSO has also proposed that 3 character ISO codes that correspond to countries should also be reserved.  We
 could have decided the other way and allow those 3 characters to be used as gTLDs.  But we coordinated with the ccNSO and the GAC to hash that out in a collaborative way and I think ended up in the right place.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I will just again state the ultimate conclusion which is that we need coordination between whatever groups exist that believe they have the authority to delegate strings that appear as TLDs.  And at this point in time ICANN is the only
 organization where coordinating the allocation of names and numbers is in its bylaws.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt">Section 1.1(a)(i):  ICANN “<span style="color:#333333;background:white">Coordinates the allocation and assignment of names in the root zone of the </span>Domain Name<span style="color:#333333;background:white"> System
 ("<strong><span style="font-family:"Calibri",sans-serif">DNS</span></strong>")”..<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;color:#333333;background:white">Section 1.1(a)(iv):  ICANN “Collaborates with other bodies as appropriate to provide registries needed for the functioning of the Internet as specified by Internet protocol standards
 development organizations.” </span><span style="font-size:10.0pt"><o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">So, why don’t we set that mechanism up for coordination?<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Jeff Neuman</span></b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Senior Vice President <o:p></o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Com Laude | Valideus</span></b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">D: +1.703.635.7514<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">E:
</span><u><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0563C1"><a href="mailto:jeff.neuman@comlaude.com">jeff.neuman@comlaude.com</a><o:p></o:p></span></u></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Steve Crocker <steve@shinkuro.com> <br>
<b>Sent:</b> Monday, June 15, 2020 1:59 PM<br>
<b>To:</b> Jeff Neuman <jeff.neuman@comlaude.com>; David Conrad <david.conrad@icann.org><br>
<b>Cc:</b> ncap-discuss@icann.org<br>
<b>Subject:</b> Re: [NCAP-Discuss] [Ext] RE: Top-level Domains for Private Internets IETF draft<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">Jeff, David, et al,<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">There are at least four distinct groups that have a perspective on how top level names are assigned and used.  It would be useful all around if we could assemble their perspectives and also document the decisions and allocation of authorities.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Jeff, you wrote<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<blockquote style="margin-left:30.0pt;margin-right:0in">
<div>
<p class="MsoNormal">The GNSO is responsible for setting all policy with respect to the gTLD namespace.  This issue is no different that the GNSO Subsequent Procedures group looking at the policy behind reserving 2 characters for the ccTLDs which it did in
 2008 and again is in the process of reviewing.  It is the GNSO (and the ICANN community) that decided to reserve the 2 characters for the use of the ccTLDs using the ISO3166 list.   It is the GNSO community that will be affirming that in SubPro.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<p class="MsoNormal">I note that your first sentence says the GNSO is responsible for setting all policy with respect to the gTLD namespace.  You did not say the TLD namespace.  Further, it seems odd on its face for the GNSO to be responsible for reserving
 2 characters for the ccTLDs.  As David points out, the allocation of two character codes for the ccTLDs predates the creation of ICANN.  Perhaps you meant the GNSO acknowledged the use of two character codes for ccTLDs and wisely built into its policy that
 it would not assign two character codes.<o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I said there were at least four distinct groups.  I have in mind these four.  You might choose to divide these further or add others.<o:p></o:p></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
The gTLD community, represented by the GNSO<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
The ccTLD community, represented by the cCNSO<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
The IETF technical community<o:p></o:p></li><li class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1">
An unaligned group that views itself outside of both the IETF and ICANN.<o:p></o:p></li></ul>
<div>
<p class="MsoNormal">Another key group, of course, is the ISO 3166 Maintenance Agency.  We're dependent on them, and they're actually fairly respectful of us.  In particular, after the trouble following the reassignment of CS, they changed their holding period
 from five years to (I think) fifty<span style="font-family:"Arial",sans-serif"> years.  (Jaap Akkerhuis is the expert on this and definitely needs to be included in creating a document that covers this relationship.)</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">With respect to SubPro, I can easily imagine reactions from outside the GNSO, i.e. elsewhere in ICANN as well as outside ICANN, that it's fine for SubPro to set rules for delegating additional
 gTLDs but that doesn't apply to other uses of TLDs.  If you want to encompass *all* allocations of top level names, it seems to me additional work is needed.  ICANN does have operational control of what strings are delegated in the root zone, but it doesn't
 have the same sort of control over what strings are put into use in other arenas, and that's what causes a certain number of collsions.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif">Steve</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, Jun 15, 2020 at 1:25 PM Jeff Neuman <<a href="mailto:jeff.neuman@comlaude.com" target="_blank">jeff.neuman@comlaude.com</a>> wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thanks David.  I have already forwarded this to the Subsequent Procedures Policy Development Process working group as we are talking about the issue of “Special Use” domains and
 ensuring that we have a process to (a) ensure no collisions with those names and (b) ensure there is a dialogue between the ICANN Community and the IETF on future Special Use domains.  Many in the ICANN Community were not happy with the way that .onion came
 about without any discussion within the ICANN community.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Further, I assume in sending this to the NCAP group, it was the intention of at least one of the authors’ to ensure that there were no future collisions with this name space (e.g.,
 that ICANN not allow the delegation of any string reserved for private use). <o:p>
</o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Although you are correct that pre-ICANN this stuff was not in the hands of any formal domain name authority, since ICANN’s formations, many discussions have been held within the
 GNSO (formerly DNSO) and ICANN in general about what to do with the reservation of strings at the top level.  And you are correct that 2 character codes that correspond to existing countries have always been enshrined into our policies to reserve for those
 countries and for potential new countries.  But that was always done with the assumption that they would be used by the corresponding countries in connection with serving their local Internet community.<o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">So if we were talking about a new country coming into existence, like most recently .ss, we would not have to discuss that because of the agreements within the community to allow
 2 characters to be used in connection with that new country (or at least under the supervision of that country).  However, when we start talking about a different use of a 2 character code other than as a ccTLD, such as for private use (or any other use for
 that matter), that should bring this into the ICANN policy realm.  <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Jeff Neuman</span></b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Senior Vice President </span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">Com Laude | Valideus</span></b><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">D: +1.703.635.7514</span><o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:black">E:
</span><u><span lang="EN-GB" style="font-size:9.0pt;font-family:"Arial",sans-serif;color:#0563C1"><a href="mailto:jeff.neuman@comlaude.com" target="_blank">jeff.neuman@comlaude.com</a></span></u><o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> David Conrad <<a href="mailto:david.conrad@icann.org" target="_blank">david.conrad@icann.org</a>>
<br>
<b>Sent:</b> Monday, June 15, 2020 12:09 PM<br>
<b>To:</b> Jeff Neuman <<a href="mailto:jeff.neuman@comlaude.com" target="_blank">jeff.neuman@comlaude.com</a>><br>
<b>Cc:</b> Roy Arends <<a href="mailto:roy.arends@icann.org" target="_blank">roy.arends@icann.org</a>>;
<a href="mailto:ncap-discuss@icann.org" target="_blank">ncap-discuss@icann.org</a><br>
<b>Subject:</b> Re: [Ext] RE: [NCAP-Discuss] Top-level Domains for Private Internets IETF draft<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Jeff,<o:p></o:p></p>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt">On Jun 15, 2020, at 8:02 AM, Jeff Neuman <<a href="mailto:jeff.neuman@comlaude.com" target="_blank">jeff.neuman@comlaude.com</a>> wrote:<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">ICANN, as far as I can tell, does not have a consensus policy that states that once ISO-3166 codes are created anyone can use it for any purpose. If there is such a policy, I would
 love to see it.  <o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Traditionally  (as long as I’ve been doing DNS stuff, i.e., 1984-ish), 2-letter ISO-3166 codes have been the domain (pun intended) of ISO-3166/MA and the entities to which ISO-3166/MA
 assigns control. I am unaware that such control is a subject of ICANN consensus policy, and in the lack of such a policy, my understanding has been that previous usage applied. I gather your view is different?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">ISO assigns to character codes, yes.  But ISO does not assign 2 character domains? 
<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">No, but as you know, since around 1984, a 2-letter code cannot be delegated unless it is assigned by ISO-3166/MA. ISO-3166/MA has assigned a set of codes to be “user defined” codes,
 which means they can’t be delegated by ICANN as there is (by definition) no single entity that has been assigned control, thus it would seem to make sense (IMHO) to use them for private namespaces if you want to avoid potential collision. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">That is within ICANN’s purview. Yes, we through the ICANN processes have acknowledged the right of ccTLDs to use their assigned codes as ccTLDs,
<o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">An interesting perspective.  To be honest, I’m not sure that is a right ICANN has the ability to give or take away, but that’s a probably a different discussion.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">but to my knowledge, ICANN has never discussed the ability to use other ISO code lists for other purposes.<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">OK, but (a) we’re talking about private namespaces which, by definition, ICANN has no control over and (b) Roy/Ed are not speaking for ICANN in any way.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;margin-bottom:12.0pt"><o:p> </o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Why should anyone be averse to having this discussion within the ICANN community and why did Roy and Ed decide that the right venue to discuss this issue was the IETF.  To me this
 is policy issue and not a technical issue?<o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Not to speak for Roy/Ed (I haven’t spoken to them about this), my guess is that they used the technical forum they were most familiar with.  It might also be that they view publishing
 via the IETF as being more likely to result in the document being read by the folks who would be considering squatting on an “unused” string.  I wouldn’t imagine they’d be against publishing the document elsewhere, after all, the intent of Internet Drafts
 is to facilitate discussion, regardless of venue.  However, where/how would you propose they publish?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Regards,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">-drc<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
</div>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<p class="MsoNormal">The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error,
 please return it to the sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan
 or otherwise check this email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited
 t/a Com Laude, a company registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and
 registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc.
 dba Com Laude USA and Valideus USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan.
 For further information see <a href="https://comlaude.com" target="_blank">www.comlaude.com</a>
<o:p></o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
NCAP-Discuss mailing list<br>
<a href="mailto:NCAP-Discuss@icann.org" target="_blank">NCAP-Discuss@icann.org</a><br>
<a href="https://mm.icann.org/mailman/listinfo/ncap-discuss" target="_blank">https://mm.icann.org/mailman/listinfo/ncap-discuss</a><br>
<br>
_______________________________________________<br>
By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (<a href="https://www.icann.org/privacy/policy" target="_blank">https://www.icann.org/privacy/policy</a>)
 and the website Terms of Service (<a href="https://www.icann.org/privacy/tos" target="_blank">https://www.icann.org/privacy/tos</a>). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style
 delivery or disabling delivery altogether (e.g., for a vacation), and so on.<o:p></o:p></p>
</blockquote>
</div>
</div>
<hr>
The contents of this email and any attachments are confidential to the intended recipient. They may not be disclosed, used by or copied in any way by anyone other than the intended recipient. If you have received this message in error, please return it to the
 sender (deleting the body of the email and attachments in your reply) and immediately and permanently delete it. Please note that the Com Laude Group does not accept any responsibility for viruses and it is your responsibility to scan or otherwise check this
 email and any attachments. The Com Laude Group does not accept liability for statements which are clearly the sender's own and not made on behalf of the group or one of its member entities. The Com Laude Group includes Nom-IQ Limited t/a Com Laude, a company
 registered in England and Wales with company number 5047655 and registered office at 28-30 Little Russell Street, London, WC1A 2HN England; Valideus Limited, a company registered in England and Wales with company number 06181291 and registered office at 28-30
 Little Russell Street, London, WC1A 2HN England; Demys Limited, a company registered in Scotland with company number SC197176, having its registered office at 33 Melville Street, Edinburgh, Lothian, EH3 7JF Scotland; Consonum, Inc. dba Com Laude USA and Valideus
 USA, headquartered at 1751 Pinnacle Drive, Suite 600, McLean, VA 22102, USA; Com Laude (Japan) Corporation, a company registered in Japan having its registered office at Suite 319,1-3-21 Shinkawa, Chuo-ku, Tokyo, 104-0033, Japan. For further information see
<a href="https://comlaude.com" target="_blank">www.comlaude.com</a>
</body>
</html>