Comments on CWG draft proposal section i and corresponding annex

[Peter Koch <pk@xxxxxxxx>]

-----------------------------------------------------------------------------
Name: Peter Koch
Affiliation: DENIC eG
        {given for disclosure, background and identification,
         submitting as an individual}
Parts covered: section I
-----------------------------------------------------------------------------

Confessing, with regret, that the submitter did not follow in progress the
impressive amount of work the CWG and its members put into the draft proposal, 
I would like to draw the CWG's attention to some pontentially ancillary
statements made in the draft proposal.

Without taking a stand w.r.t. the desirability or necessity of separation,
it should clearly be in everybody's interest to maintain separability.
Separating conjoined triplets is delicate surgery.  That said,
responsibilities and duties in overlapping areas of the three communities
need to be recognized as precisely as possible - well in advance.

The current draft says in section I.D

        I.D Overlap or interdependencies between your IANA requirements and the 
functions required by other customer communities
        The IETF, through its responsibilities for developing the underlying 
DNS protocol and its extensions, could designate parts of the domain name space 
for particular protocol-related purposes that may
        overlap with usages assigned through ICANN policies. It may also 
designate portions of the namespace as invalid, illegal or reserved based on 
evolution of the underlying DNS protocol and its extensions. It may also expand 
the scope of namespace to be managed through such changes. Additional overlap 
and/or interdependencies have been identified for each activity in Annex A.

It can be assumed this is in recognition of RFC 2860 "Memorandum of 
Understanding
Concerning the Technical Work of the Internet Assigned Numbers Authority", 
section
4.3 (with emphasis on clause (a), NB "such as")

   Note that (a) assignments of domain names for technical uses (such as
   domain names for inverse DNS lookup), (b) assignments of specialised
   address blocks (such as multicast or anycast blocks), and (c)
   experimental assignments are not considered to be policy issues, and
   shall remain subject to the provisions of this Section 4.  (For
   purposes of this MOU, the term "assignments" includes allocations.)
   In the event ICANN adopts a policy that prevents it from complying
   with the provisions of this Section 4 with respect to the assignments
   described in (a) - (c) above, ICANN will notify the IETF, which may
   then exercise its ability to cancel this MOU under Section 2 above.

Annex A expands 

        a) Root Zone Change Request Management (NTIA IANA Functions Contract: 
C.2.9.2.a)
        [...]
        # Overlaps or interdependencies: Policy for entries in the root zone 
are determined by the ICANN policy setting mechanisms (e.g. for ccTLDs and 
gTLDs). The IETF standardisation process can create reservations from the 
global name space so that certain names that otherwise would be valid in the 
DNS root are disallowed.

and
        c) Delegation and Redelegation of a Country Code Top Level-Domain 
(ccTLD) (NTIA IANA Functions Contract: C.2.9.2.c)
        [...]
        # Overlaps or interdependencies: Policy for entries in the root zone 
are determined both by the ICANN policy setting mechanisms (e.g. for ccTLDs and 
gTLDs), and by the IETF standardisation process (e.g. for specially reserved 
names)

similar to

        d) Delegation and Redelegation of a Generic Top Level Domain (gTLD) 
(NTIA IANA Functions Contract: C.2.9.2.d)
        [...]
        # Overlaps or interdependencies: Policy for entries in the root zone 
are determined both by the ICANN policy setting mechanisms (e.g. for ccTLDs and 
gTLDs), and by the IETF standardisation process (e.g. for specially reserved 
names)

It is unclear to what extent the CWG recognizes the IETF's competence (as in 
'court')
to reserve or designate TLDs (of any kind).  There is positive precedent for 
such
actions to be well received and widely recognized (dating back to RFC 2606 
"Reserved Top Level DNS Names"),
but recently RFC 6761 "Special-Use Domain Names" has invited a number of 
applications
for the reservation of top level domains that might be perceived as end-run to
established (ICANN) process, independent of the good faith and intentions of 
the respective
applicants.

This issue does not necessarily have to be fully resolved prior transition, but 
needs to
be clearly identified as "open" and ought to be addressed in reasonably short 
time.
Points to address in particular:

  o Which body is responsible for the formal designation of a TLD or 'TLD like 
string'?
  o What role (formal and/or technical) would the IETF special names registry 
have?
  o What is the coordination process between the IETF and ICANN (as a names 
policy
    setting body, not as IFO)?

The technical and operational merits of such registry can remain out of scope.

There might be other areas of overlap between the IETF and the names community, 
details
of which should not clutter the proposal, that would benefit from a separation 
(pun intended)
of duties in addition to the issue identified above.

Kind regards,
   Peter Koch


-- 
Peter Koch              |                           |         pk@xxxxxxxx
DENIC eG                |                           |      +49 69 27235-0
Kaiserstraße 75-77      |                           |
60329 Frankfurt am Main |                           | http://www.DENIC.DE
-------------------------------------------------------------------------
Eingetr. Nr. 770 im Genossenschaftsregister Amtsgericht Frankfurt am Main
Vorstand: Helga Krüger, Andreas Musielak, Carsten Schiefner, Dr. Jörg Schweiger
Vorsitzender des Aufsichtsrats: Thomas Keller