Re: [Internetgovtech] Cross community

Avri Doria <avri@acm.org> Wed, 23 July 2014 22:16 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 20B3B1B27D3 for <internetgovtech@ietfa.amsl.com>; Wed, 23 Jul 2014 15:16:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 APN17cagMidj for <internetgovtech@ietfa.amsl.com>; Wed, 23 Jul 2014 15:16:08 -0700 (PDT)
Received: from atl4mhob17.myregisteredsite.com (atl4mhob17.myregisteredsite.com [209.17.115.110]) by ietfa.amsl.com (Postfix) with ESMTP id 1CBBE1B27B2 for <internetgovtech@iab.org>; Wed, 23 Jul 2014 15:16:08 -0700 (PDT)
Received: from mailpod.hostingplatform.com ([10.30.71.210]) by atl4mhob17.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id s6NMG7aR022456 for <internetgovtech@iab.org>; Wed, 23 Jul 2014 18:16:07 -0400
Received: (qmail 7268 invoked by uid 0); 23 Jul 2014 22:16:07 -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; 23 Jul 2014 22:16:06 -0000
Message-ID: <53D03426.6030400@acm.org>
Date: Wed, 23 Jul 2014 18:16:06 -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> <53CD291E.1020801@acm.org> <9045EC0A-E123-4CDC-B87F-5BC32C644C85@istaff.org> <53CD57E8.4000909@acm.org> <B7163126-31B6-4CC6-A711-F225051C294A@istaff.org> <53CD8F41.9060909@gih.com> <53CD939D.5020001@cisco.com> <9DE8F705-9748-407D-8E77-7B787ACD9873@gmail.com> <53CE4B39.1090202@acm.org> <53D016B6.2020000@gih.com> <53D01E6B.8020606@gmail.com> <53D025F3.5050708@acm.org> <53D02EF2.7030703@cisco.com>
In-Reply-To: <53D02EF2.7030703@cisco.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-Antivirus: avast! (VPS 140722-1, 07/22/2014), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/82Q_CKdzOF5AlfTaaKqLNbr_6ro
Subject: Re: [Internetgovtech] Cross community
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: Wed, 23 Jul 2014 22:16:09 -0000

Hi,

(Please remember I am only discussing this issue as an example)

Yes, there are internal IETF mechanisms.

And no I did not object, though I do remember thinking it was an
entertaining work around to ICANN processes, but that is not the point.
 I happen to be nerdy enough to participate in both organizations and
track the things I am interested in in both of them, more or less.  That
is a rare affliction.  And counting on such individuals is not really an
optimum cross-function accountability mechanism.

Perhaps this was brought to the ICANN Board by the then Liaison as an
issue, though i do not remember it being communicated to the GNSO at the
time.  If it was that is a good thing, but is that is a defined cross
function accountability function.  And even if it so defined, is it
sufficient?

And what about a year later when we all of a sudden notice that you have
reserved a bunch of names for technical reasons we just don't see -
remember, we do not universal agreement on the technical risks of things
like collision (not to start that discussion here - just an example). So
to whom is IANA accountable in terms of placing and removing such names
from various lists?

At this point, we could go running to NTIA and complain.  What would
come out it, who knows, but we could.  And that is the point:  they
represent a common point of accountability for the IANA function.


avri


On 23-Jul-14 17:53, Eliot Lear wrote:
> Hi Avri,
> 
> On 7/23/14, 5:15 PM, Avri Doria wrote:
>> Hi,
>>
>> On 23-Jul-14 16:43, Brian E Carpenter wrote:
>>> It would be absurd to define new mechanisms if the existing ones are
>>> fully satisfactory.
>> ah the old 'if it ain't broke' conundrum.
>>
>> Thing is, while it is not broken for some, it is broken for others.
>>
>> For me, as an example at this point, I see breakage on things like the
>> self established ability of the IETF to unilaterally decide that a
>> protocol mandates removing labels from the list of available TLD labels.
> 
> "Unilaterally" implies that somehow the community isn't involved in the
> decision.
>>
>> As a long time participant in the IETF, I see how natural this decision
>> is for the the IETF and a part of me cheers at the simplicity of this
>> solution for any number of issues.
>>
>> As a member of the ICANN GNSO Council I am outraged at the idea because
>> it is a policy decision that the technical arm of the enterprise has no
>> business making.
>>
>> To whom is the IETF accountable in making this decision?  Just itself?
> 
> The community and through its leadership through the NOMCOM process,
> which also takes into account community views.  But to be specific, when
> the IETF steps in and reserves a name, it should do so only to avoid
> technical breakage.  Can you provide an example where the IETF got
> involved where that wasn't the case?  Also, did you appeal any decision
> the IESG took in this regard?
> 
>>
>> This is breakage.
> 
> 
> What would be breakage would be if the IETF entered such a debate
> without technical ground or if the IETF *didn't* enter the debate when
> there was technical breakage at risk.
> 
> But even if the example you cited was broken, we have an appropriate
> means to fix it, complete with accountability.
> Eliot
> 
> 
>