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

Andrew Sullivan <ajs@anvilwalrusden.com> Tue, 15 July 2014 19:31 UTC

Return-Path: <ajs@anvilwalrusden.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 AE5911A004D for <internetgovtech@ietfa.amsl.com>; Tue, 15 Jul 2014 12:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.141
X-Spam-Level:
X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 7F10yvdmt_5g for <internetgovtech@ietfa.amsl.com>; Tue, 15 Jul 2014 12:31:21 -0700 (PDT)
Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41B9F1A0039 for <internetgovtech@iab.org>; Tue, 15 Jul 2014 12:31:21 -0700 (PDT)
Received: from mx1.yitter.info (69-165-131-253.dsl.teksavvy.com [69.165.131.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id DE1A58A031 for <internetgovtech@iab.org>; Tue, 15 Jul 2014 19:31:19 +0000 (UTC)
Date: Tue, 15 Jul 2014 15:31:18 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: internetgovtech@iab.org
Message-ID: <20140715193118.GQ8847@mx1.yitter.info>
References: <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> <20140715142048.GE8847@mx1.yitter.info> <6.2.5.6.2.20140715100237.08757120@resistor.net> <133C8BA9-EEC5-48A2-941D-61E9E6371BD3@virtualized.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <133C8BA9-EEC5-48A2-941D-61E9E6371BD3@virtualized.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/internetgovtech/YgOTTHsN6coMgYpDmlKXKcpGdzE
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: Tue, 15 Jul 2014 19:31:22 -0000

On Tue, Jul 15, 2014 at 11:01:25AM -0700, David Conrad wrote:
> 
> Given the various references (some hardwired?) to IANA.ORG, that might get a bit confusing. 

If we split the different IANA functions apart (as the idea of the
IETF going elsewhere with its protocol parameters implies), the name
"IANA" would presumably be wrong, so maybe we couldn't stick with
iana.org anyway.  Anyway, whatever happens it'd be part of the cost of
"changing providers".

Just to be clear, in my opinion the idea of splitting the IANA
function is in general a bad one.  In some important senses, IP
addresses and domain names are just different parameters of protocols
anyway.  They each happen to have detailed policy implications that
gives good reason to split the policy functions for them away from
other protocol parameters.  There's also the fact of close
co-ordination needed when special-purpose registries get updated
(particularly when they're overlapping, like parts of the IP space and
some TLDs); it's much easier to ensure that co-ordination with smaller
numbers of people needing to be involved.  Therefore, I believe that
any possible advantage would have to be pretty huge in order to cause
us to split off -- something along the lines of dealing with willful
divergence that couldn't be remedied.  For example, suppose IANA added
something to a registry in express contradiction to the IETF's
instructions.  Note that this might not be an IANA choice.  Given
ICANN's numerous office presences, I can certainly imagine a
circumstance where some court with jurisdiction over ICANN but not the
IETF ordered the "wrong" outcome.

So, I think we need to have a good idea of what we'd have to do, what
it'd cost us, and so on.  That's just responsible contingency
planning.  But we should not be supposing that the effort would be
cheap or easy or in any way a happy outcome.  

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com