Re: [Internetgovtech] Cross community

John Curran <> Mon, 21 July 2014 19:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5EAFB1A03C2 for <>; Mon, 21 Jul 2014 12:48:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VjTJbSCIJs0J for <>; Mon, 21 Jul 2014 12:48:41 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 00FF81A02FA for <>; Mon, 21 Jul 2014 12:48:40 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.72) (envelope-from <>) id 1X9JZg-000Hb7-2L; Mon, 21 Jul 2014 19:48:40 +0000
X-Mail-Handler: Dyn Standard SMTP by Dyn
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX19hM7CMD0+ZpLCDhTP4M8dx
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: John Curran <>
In-Reply-To: <>
Date: Mon, 21 Jul 2014 15:48:38 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Avri Doria <>
X-Mailer: Apple Mail (2.1878.6)
Subject: Re: [Internetgovtech] Cross community
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 21 Jul 2014 19:48:43 -0000

On Jul 21, 2014, at 2:11 PM, Avri Doria <> wrote:
>> Could you elaborate some on the above concepts?  I understand how there is 
>> potential for consultation with such advisory committees if considered 
>> appropriate by the ICANN Board (and as provided for in the ASO Global Policy 
>> Development process), but the more typical method of engagement is directly 
>> in the policy development processes taking place in each RIR region... in 
>> this way, the input is considered closer to those affected by the outcome.  
> The ASO is part of ICANN.  Anything it does, is open to comment by any
> of the Adivisory Committees (AC).

Yes - in accordance with the agreement between ICANN and the NRO including
the Global Policy Development Process contained therein.  I expect that the 
ICANN Board would want to promptly seek such advisory committee comment 
given the timelines involved...

> I understand that the RIRs all have their own regional participants, but
> at the global level, there is very little stakeholder participation,
> with the ICANN Advisory Committees being the only possible venue for
> such concerns.

Given that something does not get to ICANN until it has been fully agreed 
as a result of policy development meetings in all of the regions generally 
over a period of years, it would probably be more productive to engage in 
the regional processes leading to the formation of the global policy (i.e.
rather than at the very end of lengthly consensus building process)  

It might make sense for ICANN to look at that model for its own policy
development efforts; it might help address some of the concerns I heard
expressed at the recent IGF-USA meeting about ICANN advisory committees 
needing to be more involved in the policy development process and hence
more invested in the developed outcomes.

>  doea the NRO provide a multistakeholder venue at the
> global level or is that the task of the ASO?  Because the ASO is part of
> ICANN, the ACs have a voice in their activities and thus have a say in
> the accountability methods for those issues.

The ASO does provide for global policy _coordination_ and participates
in ICANN's accountability review processes.  Note that the ASO does not 
do policy development; that takes place closer to the effected parties 
via meetings in each region.

You probably need to look over the agreements between ICANN and the
RIRs/NRO, as the RIRs are accountable (as actual membership orgs) to
their respective communities via elected leaderships and open policy
development processes. The ICANN Board is accountable per agreement
to the collected addressing community for the timely review and 
ratification of proposed global address policies.

> On a specific example that I pay more attention to than numbers, the
> IETF has recently asserted its ability to take names out of the general
> pool of labels available for TLDs by declaring them to be protocol
> artifacts, i.e. RFC 6761 on Special Use Names.  To assert IETF having
> full control of this interface without any accountability to others is
> problematic.  While this may just be an edge case from the IETF protocol
> perspective, it could could be a huge issue from the ICANN perspective.

Strange... The IETF created the namespace through definition of the DNS
protocol, just as they did with IPv4 and IPv6 number spaces.  If there 
are technical/specialized reservations that they (the IETF) see fit to 
make, then that portion of the identifier space is no longer part of 
the "general purpose" portion of the affected registry.  

We work these issues fairly routinely on the addressing side, and I 
would say have excellent working relationships.  Ultimately, those who
are actually affected (service providers, equipment makers, researchers)
know to show up in appropriate working groups in the IETF to make their
views heard.  I have ample faith in the openness and accountability 
of the IETF processes to the affected community in these matters, but
would be willing to consider bodies such as the RIRs as equally capable
given their membership structure.  Trying to claim accountability absent 
the ingrained institutional record of the IETF or an actual membership
model does seem more difficult.

> And I still don't know who submits proposals on the .arpa, or .int issue
> and the root server issues.

If those are technical reservations from the DNS space, then they are backed
by RFCs and will be followed by ICANN per the existing IETF MOU (RFC 2860).
In the event ICANN adopts a policy that prevents it from complying with such
guidance, things would get interesting real fast (see MOU section 4.3...) 

> In a world where the various tech and the various policy issues are so
> intertwined and interdependent, I think siloing is risky and should be
> avoided.

It's much simpler if you look at things one parameter space at a time: 
who created it, what technical reservations does it have, is there a 
general purpose portion & if so who is the delegated policy authority, 
what entity administers the resulting policy, and what party performs 
registry operations/publication for the entire parameter space?  The 
general purpose DNS and IP registries are only portions are subsets 
of the entire registry spaces; keeping that in mind may help quite a
bit with clarity of roles.


Disclaimer: My views alone.