Liaison statement
Re: Letter from Mr. Marby Re: Clarifying domain namespace responsibilities

Dear Göran,

Thank you for your note on the Security and Stability Advisory Committee (SSAC)
recently published SAC113, “SSAC Advisory on Private-Use TLDs” and for your
views on the background to both its publication and the general topic of
strings reserved from delegation in the DNS.

First, we wish to reaffirm our commitment both to the existing memorandum of
understanding (RFC 2860) and to the general principle that the IETF and ICANN
work cooperatively in matters relating to the global namespace of domain names.
 We anticipate that any change to existing practice would require direct mutual
consultation, and we appreciate your correspondence as a demonstration that
ICANN is similarly committed.

Second, we note that a number of the questions that you raise are also
discussed in RFC 8244.  In its taxonomy, for example, we find:

  o  Names reserved by the IETF for technical purposes

  o  Names assigned by ICANN to the public DNS root; some names
     reserved by the IETF for technical purposes may appear in the
     global DNS root for reasons pertaining to the operation of the DNS

  o  ICANN Reserved Names; names that may not be applied for as TLDs
     (see "Reserved Names" and "Treatment of Country or Territory
     Names" (Sections 2.2.1.2.1 and 2.2.1.4.1, respectively) of
     [SDO-ICANN-DAG]).

We understand SAC113 to be a proposal for the ICANN board to allocate an ICANN
Reserved Name, and we believe that it being reserved by ICANN would necessarily
require that the chosen string also be removed from consideration for any
technical use specified by the IETF.  In keeping with our commitment to a
single, global namespace (RFC 2826), such a reservation would ensure that the
IETF would not consider any special-use name with the same string. 
Procedurally, if the ICANN board chooses to reserve a string following the
advice of SAC113, we would expect the string to be reserved within the
IANA-managed reserved domain registry (https://www.iana.org/domains/reserved
<https://www.iana.org/domains/reserved>) rather than the special-use domain
names registry (https://www.iana.org/assignments/special-use-domain-names/
<https://www.iana.org/assignments/special-use-domain-names/>).

We also call your attention to the IAB statement on the registration of special
use names in .ARPA
(https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/
<https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-the-registration-of-special-use-names-in-the-arpa-domain/>).
 As it notes:

All names registered in the Special-Use Domain Names registry that are intended
for use via the DNS protocol are found beneath the ARPA top-level domain. 
Other names in the Special-Use Domain Names registry are intended for exclusion
from DNS resolution. An entry in the Special-Use Domain Names Registry that
does not require DNS resolution does not require the registrant to control the
relevant name in the DNS. In the view of the IAB, when placing any name in the
Special-Use Domain Names registry with the intention that it be used with the
DNS protocol, such an entry must be within a domain under the control of the
body making the registration. For the IETF, an appropriate domain for such
names would be ARPA, as long as those names meet the conditions in RFC 3172.

In general, the IAB does not see the need for special-use names intended to be
resolved by the global DNS to be placed in the root of the namespace, although
we join the SSAC in a desire to avoid squatting.  Similar recent requests in
the IETF have, however, used .ARPA (e.g. RFC 8375).  We believe that technical
uses requiring standard DNS delegations should occur only under extraordinary
circumstances, when other options have been exhausted. Since the technical
requirements that might drive such a need are not known to us, however, we
cannot entirely rule it out.

We think it would be useful to engage IETF and ICANN experts in a dialogue on
this topic and we’ll follow up to try to get that arranged.

Regards,
Alissa Cooper on behalf of the Internet Engineering Steering Group
Mirja Kühlewind on behalf of the Internet Architecture Board