[NCAP-Discuss] [Ext] RE: Top-level Domains for Private Internets IETF draft

Mon Jun 15 19:03:48 UTC 2020

Jeff,

You've stated the issue in terms of top down control.  We don't want total
anarchy, but I think it's useful to understand the dynamics of group 4.  In
a very real sense, they are the ultimate example of bottom up, multi
stakeholder participation.

Steve

On Mon, Jun 15, 2020 at 2:59 PM Jeff Neuman <jeff.neuman at comlaude.com>
wrote:

> Agreed.  But, it would be iCANN that would have to decide not to delegate
> a future TLD that matches a string used by any of the other groups.  This
> is what I brought up during the last call.  If you want to participate in
> the coordination process, then it would be reasonable for ICANN to reserve
> those from delegation as TLDs.  If you work outside the process, then ICANN
> should not be bound to recognize your unauthorized use.
>
>
>
> The group you list as Number 4 (those outside ICANN/IETF) that utilize
> alternate roots like .crypto, Handshake Domains, etc., they have done their
> own “delegations” within their alternate roots.  ICANN, however, has the
> decision of whether they will approve other applications for those
> strings.  So although ICANN has no jurisdiction to control what others use,
> they can effectively wipe it out by delegating that string to someone
> else….even though we know there will be some potential collisions.
>
>
>
> So although it will be nearly impossible to coordinate with your group 4,
> I think there should be collaboration between groups 1, 2 and 3 on the
> delegation of strings for whatever purpose.  And ICANN should not be
> rewarding those groups that work around the coordination by agreeing to
> reserve those strings for fear of potential collisions.
>
>
>
> *Jeff Neuman*
>
> Senior Vice President
>
> *Com Laude | Valideus*
>
> D: +1.703.635.7514
>
> E: *jeff.neuman at comlaude.com <jeff.neuman at comlaude.com>*
>
>
>
> *From:* Steve Crocker <steve at shinkuro.com>
> *Sent:* Monday, June 15, 2020 2:18 PM
> *To:* Jeff Neuman <jeff.neuman at comlaude.com>
> *Cc:* David Conrad <david.conrad at icann.org>; ncap-discuss at icann.org;
> Steve Crocker <steve at shinkuro.com>
> *Subject:* Re: [NCAP-Discuss] [Ext] RE: Top-level Domains for Private
> Internets IETF draft
>
>
>
> Briefly, because I'm in another meeting, the ICANN bylaws govern ICANN.
> They have no de jure authority over groups outside of ICANN.
>
>
>
> Steve
>
>
>
>
>
> On Mon, Jun 15, 2020 at 2:13 PM Jeff Neuman <jeff.neuman at comlaude.com>
> wrote:
>
> 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.
>
>
> 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 *potential* 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.
>
>
>
> 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.
>
>
>
> Section 1.1(a)(i):  ICANN “Coordinates the allocation and assignment of
> names in the root zone of the Domain Name System ("*DNS*")”..
>
> 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.”
>
>
>
> So, why don’t we set that mechanism up for coordination?
>
>
>
> *Jeff Neuman*
>
> Senior Vice President
>
> *Com Laude | Valideus*
>
> D: +1.703.635.7514
>
> E: *jeff.neuman at comlaude.com <jeff.neuman at comlaude.com>*
>
>
>
> *From:* Steve Crocker <steve at shinkuro.com>
> *Sent:* Monday, June 15, 2020 1:59 PM
> *To:* Jeff Neuman <jeff.neuman at comlaude.com>; David Conrad <
> david.conrad at icann.org>
> *Cc:* ncap-discuss at icann.org
> *Subject:* Re: [NCAP-Discuss] [Ext] RE: Top-level Domains for Private
> Internets IETF draft
>
>
>
> Jeff, David, et al,
>
>
>
> 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.
>
>
>
> Jeff, you wrote
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>    - The gTLD community, represented by the GNSO
>    - The ccTLD community, represented by the cCNSO
>    - The IETF technical community
>    - An unaligned group that views itself outside of both the IETF and
>    ICANN.
>
> 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 years.
> (Jaap Akkerhuis is the expert on this and definitely needs to be included
> in creating a document that covers this relationship.)
>
>
>
> 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.
>
>
>
> Steve
>
>
>
>
>
>
>
> On Mon, Jun 15, 2020 at 1:25 PM Jeff Neuman <jeff.neuman at comlaude.com>
> wrote:
>
> 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.
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> *Jeff Neuman*
>
> Senior Vice President
>
> *Com Laude | Valideus*
>
> D: +1.703.635.7514
>
> E: *jeff.neuman at comlaude.com <jeff.neuman at comlaude.com>*
>
>
>
> *From:* David Conrad <david.conrad at icann.org>
> *Sent:* Monday, June 15, 2020 12:09 PM
> *To:* Jeff Neuman <jeff.neuman at comlaude.com>
> *Cc:* Roy Arends <roy.arends at icann.org>; ncap-discuss at icann.org
> *Subject:* Re: [Ext] RE: [NCAP-Discuss] Top-level Domains for Private
> Internets IETF draft
>
>
>
> Jeff,
>
>
>
> On Jun 15, 2020, at 8:02 AM, Jeff Neuman <jeff.neuman at comlaude.com> wrote:
>
> 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.
>
>
>
> 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?
>
>
>
> ISO assigns to character codes, yes.  But ISO does not assign 2 character
> domains?
>
>
>
> 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.
>
>
>
> 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,
>
>
>
> 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.
>
>
>
> but to my knowledge, ICANN has never discussed the ability to use other
> ISO code lists for other purposes.
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> 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?
>
>
>
> Regards,
>
> -drc
>
>
> ------------------------------
>
> 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 www.comlaude.com <https://comlaude.com>
>
> _______________________________________________
> NCAP-Discuss mailing list
> NCAP-Discuss at icann.org
> https://mm.icann.org/mailman/listinfo/ncap-discuss
>
> _______________________________________________
> 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 (https://www.icann.org/privacy/policy) and
> the website Terms of Service (https://www.icann.org/privacy/tos). 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.
>
> ------------------------------
>
> 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 www.comlaude.com <https://comlaude.com>
>
> ------------------------------
> 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 www.comlaude.com <https://comlaude.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ncap-discuss/attachments/20200615/4090eb7d/attachment-0001.html>