Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available

Avri Doria <avri@acm.org> Mon, 21 July 2014 14:52 UTC

Return-Path: <avri@acm.org>
X-Original-To: internetgovtech@ietfa.amsl.com
Delivered-To: internetgovtech@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAD9A1A014B for <internetgovtech@ietfa.amsl.com>; Mon, 21 Jul 2014 07:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.465
X-Spam-Level: *
X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zr68QvePm9kN for <internetgovtech@ietfa.amsl.com>; Mon, 21 Jul 2014 07:52:22 -0700 (PDT)
Received: from atl4mhob12.myregisteredsite.com (atl4mhob12.myregisteredsite.com [209.17.115.50]) by ietfa.amsl.com (Postfix) with ESMTP id E086A1A00B8 for <internetgovtech@iab.org>; Mon, 21 Jul 2014 07:52:21 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.207]) by atl4mhob12.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6LEqKRh004499 for <internetgovtech@iab.org>; Mon, 21 Jul 2014 10:52:20 -0400
Received: (qmail 21531 invoked by uid 0); 21 Jul 2014 14:52:20 -0000
X-TCPREMOTEIP: 68.15.42.104
X-Authenticated-UID: avri@ella.com
Received: from unknown (HELO ?127.0.0.1?) (avri@ella.com@68.15.42.104) by 0 with ESMTPA; 21 Jul 2014 14:52:20 -0000
Message-ID: <53CD291E.1020801@acm.org>
Date: Mon, 21 Jul 2014 10:52:14 -0400
From: Avri Doria <avri@acm.org>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: internetgovtech@iab.org
References: <A193D048-2B67-469A-93BA-C61BB362DA75@vigilsec.com> <53CD1E8A.1060804@acm.org> <FA4238C4-ADDC-435F-9591-E3B074C2F6F6@vigilsec.com> <53CD2300.5050307@acm.org> <20140721143105.GH16966@mx1.yitter.info>
In-Reply-To: <20140721143105.GH16966@mx1.yitter.info>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 140721-0, 07/21/2014), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/tkfC1UCMAGgqvFEmSFTGSR536X8
Subject: Re: [Internetgovtech] Documents from the ICG Meeting Last Week are Available
X-BeenThere: internetgovtech@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <internetgovtech.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/internetgovtech/>
List-Post: <mailto:internetgovtech@iab.org>
List-Help: <mailto:internetgovtech-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jul 2014 14:52:24 -0000

Hi,

I am not necessarily looking for joint efforts - though it might be
nice, just allowing for any of the communities to produce
recommendations on any of the aspects.

There are cross over concerns, for example in ICANN the Advisory
Committees (At Large, Government, Security etc) have purview to advise
on addresses as well as numbers and even parameters when it concerns
tech that will be used to manage those names and numbers.  Why does our
process say that they can't make recommendations on that?

Likewise the IETF has great concerns over the allocations of some names
and may want to make a suggestion of how the allocation of names is done
given the IETF's decision that it is able to assign names for protocol
reasons.  That is a tussle waiting in the wings that needs to come out
into the light for all of this assignment of responsibilities.

Yes, the IETF will naturally choose to mostly produce recommendations on
parameters, but need it be limited to that?  Likewise with the other groups.

I have no problem with the notion of an expectation that mostly
parameters will be covered by IETF and names by GNSO and the ccNSO, and
numbers by the NRO.  What I have problems with is the construction of
silo walls that indicate an expectation that others might not have
standing and ability to contribute to the proposed solutions on
particular subjects.

I do not want there to be a possibility that someone calls an
uncomfortable recommendaton out of scope for the organization making it.

As for this have been handed down, I do not remember there ever being a
community wide discussion on slice and dice, just announcements of this
being the way it would be from various leaders.

avri


On 21-Jul-14 10:31, Andrew Sullivan wrote:
> On Mon, Jul 21, 2014 at 10:26:08AM -0400, Avri Doria wrote:
>> I fund this silo approach very problematic and more likely to produce a
>> disjointed set of solutions 
> 
> Where would be the joint whereof you speak?  To put this another way,
> in my opinion protocol parameters belong squarely in the IETF's
> purview, and nobody else's.  Similarly, given the protocols, names
> fall squarely into ICANN's purview, no?  What is the "joint" that
> wouldn't be better solved (in the case of names) by working within the
> ICANN community?  Similarly for number resources, except a different
> community.
> 
> I don't think there's any handed-down-ness about it.  This is a fully
> community-based approach, I think.
> 
> A
>