Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web)

JFC Morfin <jefsey@jefsey.com> Mon, 14 July 2014 22:24 UTC

Return-Path: <jefsey@jefsey.com>
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 590571A0158 for <internetgovtech@ietfa.amsl.com>; Mon, 14 Jul 2014 15:24:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.83
X-Spam-Level:
X-Spam-Status: No, score=0.83 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] 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 97UfKYk59rbG for <internetgovtech@ietfa.amsl.com>; Mon, 14 Jul 2014 15:24:49 -0700 (PDT)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D139A1A0154 for <internetgovtech@iab.org>; Mon, 14 Jul 2014 15:24:49 -0700 (PDT)
Received: from 254.74.14.81.rev.sfr.net ([81.14.74.254]:57935 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from <jefsey@jefsey.com>) id 1X6ofw-00027O-CF; Mon, 14 Jul 2014 15:24:48 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 15 Jul 2014 00:21:48 +0200
To: Miles Fidelman <mfidelman@meetinghouse.net>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <53C42C31.4060002@meetinghouse.net>
References: <6.2.5.6.2.20140708142055.0d5fbb78@elandnews.com> <20140709161653.GM59034@mx1.yitter.info> <9B506E73B33873103AE5EC52@JcK-HP8200.jck.com> <20140709171401.GB2935@mx1.yitter.info> <53BD843F.1070304@cs.tcd.ie> <53BD84BB.7000002@meetinghouse.net> <53BDA867.7090701@gmail.com> <53BE602F.7020108@firsthand.net> <53BE6384.5030504@cs.tcd.ie> <53BE69D2.9070509@firsthand.net> <6.2.5.6.2.20140711000259.0cc016e8@resistor.net> <53BFD828.3070007@firsthand.net> <53C06E7C.4010903@gmail.com> <CAD_dc6ihUvV8SDkmoc3fGHWoOoR6nFhRz-=tgCjKnuNvRO2JXw@mail.gmail.com> <53C0F1D9.3090400@cisco.com> <53C17B5C.4090600@abenaki.wabanaki.net> <C5750A628D4D973F3C44F6DC@JcK-HP8200.jck.com> <53C1B2C6.40501@meetinghouse.net> <72F8472D-2913-4BEC-9260-6DAC7791BBF8@virtualized.org> <53C1DD6C.8030501@gmail.com> <43DD1894-54A8-44D0-AE58-6F3D395F43DD@ericsson.com> <53C4000C.4030401@dcrocker.net> <53C41C78.1090006@abenaki.wabanaki.net> <CAD_dc6gsrgZdr0v+Uxapyiaaqq6OijLZrDAWA87ECuc5=wjXQQ@mail.gmail.com> <53C42C31.4060002@meetinghouse.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.presenceweb.org
X-AntiAbuse: Original Domain - iab.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/wQRfsHEBoRcNoxikFQmRm5riX18
Cc: internetgovtech@iab.org
Subject: Re: [Internetgovtech] Contracts, what problems we are solving (Was: Re: Transition to the web)
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, 14 Jul 2014 22:24:51 -0000
X-Message-ID:
Message-ID: <20140714222453.28138.18117.ARCHIVE@ietfa.amsl.com>

At 21:14 14/07/2014, Miles Fidelman wrote:
>Is not the threat of non-renewal the single oversight mechanism 
>currently in place for ICANN?  And is not the central question of 
>the transition, what should replace it?

IMHO, the IANA contract should simply be replaced by a IANA protocol. 
This way every technology parameter provider and multi-registry 
ledger administrator could pass information in a consistant and 
responsible manner to every would be/VGN repository. Would a 
repository not be maintained properly users could switch to a more serious one.

What you call a "societal contract" is a multitude emergence: people 
just agree to do it for their convenience. If there is a better one 
(or less bad on - depends on politicals events, e.g. an ICANN 
Snowdenia) they may change their mind.

For example, let imagine that at some stage people start being fed-up 
working for Google for free and in addition paying their taxes: this 
may unballance the equilibrium. Why would people continue to pay for 
the ICANN DNS when some can organize naming in a better, cheaper and 
more reliable way? All these things are subject to competition: why 
to create IANA monopolies?

IETF is the source provider for protocol parameters.
ICANN is the source for DNS Class IN names.
NRO is the source for one IPv4 and 2 IPv6 numbering plans.

Probably large alliances (EU, China, ITU, Libre) will also claim for 
IPv6 numbering plans.
Every other network technology and namespaces will have their own 
parameters and names.
This way ISO will be able to directly maintain ISO 3166, 639, 15924, 10646.

The question only is: who takes the lead in normalizing the IANA 
protocol: the providers or the users side? RFC 6852 has left us in 
the middle of nowhere: there are global communities with their own 
formal or not standards, the only operational global communities are 
US, Chinese, Google, Apple, Windows, sometimes EU? and probably at 
some stage Libre and/or IUse ones.This leaves the internet as 
fragmented in many areas. The IANA should be another fragmentation 
occasion in having several pseudo-dominant or national or 
edge-provider repositories, but a single protocol for all.

I can only say that as a registered non-profit local public operator 
I will not trust any commercialized name/parameter system.
I am aware and sure that I am not alone. This is why we started the 
http://fsp4.net (fail safe plan for the net) alliance and confirmed 
its creation during the https://2014.rmll.info/?lang=en meeting last week.

Best
jfc




>Personally, I have seen very few cases of self-oversight - and none 
>come immediately to mind.
>
>Miles Fidelman
>
>Seun Ojedeji wrote:
>>Hello Eric,
>>
>>Pardon me if i may have missed something, this discussion seem to 
>>be going in the line of maintaining the IANA contract regime. If 
>>yes, then who will be the awarder and in whose capacity/authority 
>>will the awarder be doing that?
>>
>>While i also agree that there is really noting much about IP and 
>>Protocol (although IP process to me may need some re-dress), i am 
>>not sure the way to handle the names is by continuing the 
>>contracting approach. There is absolutely no need to create another 
>>layer of lobbying politics; ICANN should be self healing and IMO, 
>>review of the role of the AC/SO backed up with an external process 
>>to resolve conflict may be helpful.
>>
>>Regards
>>
>>
>>On Mon, Jul 14, 2014 at 7:07 PM, Eric Brunner-Williams 
>><ebw@abenaki.wabanaki.net <mailto:ebw@abenaki.wabanaki.net>> wrote:
>>
>>     On 7/14/14 9:06 AM, Dave Crocker wrote:
>>
>>         An essential point to a legitimate contract is providing for the
>>         possibility of switching to someone else.
>>
>>
>>     The 2011 NTIA NOI and follow-on RFP proposed the IANA Functions
>>     contract to be awarded through a competitive bid process, and for
>>     a finite term.
>>
>>     The subsequent contract was awarded to the sole bidder, upon
>>     re-tender, the incumbent contractor, for a term of three (3)
>>     years, extensible to five (5) years.
>>
>>     Removing either the finiteness of the term, or the competitive
>>     process of bidding, really should be explained by their respective
>>     advocates, if any.
>>
>>     Eric
>>
>>
>>     _______________________________________________
>>     Internetgovtech mailing list
>>     Internetgovtech@iab.org <mailto:Internetgovtech@iab.org>
>>     https://www.iab.org/mailman/listinfo/internetgovtech
>>
>>
>>
>>
>>--
>>------------------------------------------------------------------------
>>
>>     /Seun Ojedeji,
>>     Federal University Oye-Ekiti
>>     web: http://www.fuoye.edu.ng
>>     Mobile: +2348035233535
>>     //alt email:<http://goog_1872880453>seun.ojedeji@fuoye.edu.ng
>>     <mailto:seun.ojedeji@fuoye.edu.ng>/
>>
>>         The key to understanding is humility - my view !
>>
>>
>>
>>
>>_______________________________________________
>>Internetgovtech mailing list
>>Internetgovtech@iab.org
>>https://www.iab.org/mailman/listinfo/internetgovtech
>
>
>--
>In theory, there is no difference between theory and practice.
>In practice, there is.   .... Yogi Berra
>
>_______________________________________________
>Internetgovtech mailing list
>Internetgovtech@iab.org
>https://www.iab.org/mailman/listinfo/internetgovtech