Re: [Ianaplan] A draft for your review

Brian E Carpenter <> Sat, 30 August 2014 20:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EE5E21A0AE5 for <>; Sat, 30 Aug 2014 13:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ojAheCUZ6fh0 for <>; Sat, 30 Aug 2014 13:30:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c02::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A2AA1A0AE3 for <>; Sat, 30 Aug 2014 13:30:14 -0700 (PDT)
Received: by with SMTP id ft15so2926221pdb.34 for <>; Sat, 30 Aug 2014 13:30:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G3ngzKEyGtaMKHhT0IoHjLrbQFH2RgjJxkT1IFQ8vkM=; b=WeMRHXwS+mHpZCufRPVToaPuq3Xf6kdqFLcDzBHahIAgXmGhHDNrgZqwQITjF8hMVJ xMpLa2kab4IRZNbnYcqdtfjVqvAQDH7LvhfBqcujE3vS/B8bJbcQLx09lj5rLbxoKYgD GXeytNXNUUku1P8fVsXx6zeW+71z0DHQCtKsxcxMiYl8/9DqLdyKUQArVHQMMeE0mO+O LuDaYYVZP0FUttdjjR5i/dETcCJ4r+rYkXb4xigfJSKxYA+EoK9+IVZVdqqlRSvpyZyK EeIWwlNqZn2pLzMqxuuvcwuQm2PoT14Tdm8A4bfizPtlt04IAoPTi0ISLDDO32zzOryi 5uyA==
X-Received: by with SMTP id lo3mr26323029pab.7.1409430613915; Sat, 30 Aug 2014 13:30:13 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id st7sm12279902pab.7.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 30 Aug 2014 13:30:13 -0700 (PDT)
Message-ID: <>
Date: Sun, 31 Aug 2014 08:30:24 +1200
From: Brian E Carpenter <>
Organization: University of Auckland
User-Agent: Thunderbird (Windows/20070728)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc:, Russ Housley <>, Eliot Lear <>
Subject: Re: [Ianaplan] A draft for your review
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 30 Aug 2014 20:30:16 -0000


I will review the draft carefully in due course, but I want to react
briefly to a couple of Richard's comments:

On 31/08/2014 01:29, Richard Hill wrote:

> 4) Related to the above, should consideration be given to adding a proper dispute resolution clause, that is, including choice of law and venue, to the agreement?

I believe that we should explicitly not mention a legal venue. We should simply
stick to the IAB being in charge and the IESG being the technical decision
taker in case of doubt. We never, ever want to suggest that a court has
authority. (And if we did, we would definitely not want it to be a national
court anyway.)


> "And item 4 of RFC 2860 should be modified to read as follows:
> "4. Agreed technical work items.  ICANN agrees, notwithstanding any provisions in its Bylaws or other corporate documents that might be construed differently, that during the term of this MOU it shall cause IANA to comply ..."
> For reference, item 4 of RFC 2860 currently reads "4. Agreed technical work items. ICANN agrees that during the term of this MOU it shall cause IANA to comply ..."

IANAL, but that "notwithstanding" clause seems logically redundant. The existing
text (which was ratified by the ICANN Board in 2000) leaves no loophole. Personally
I think the risks in changing even one word in the existing MoU are too great.

> 7) There was extensive discussion (but no agreement) on the IANA Transition mailing list regarding whether or not the fact that a US court could, in theory, order ICANN/IANA to do something contrary to agreed community policies is an issue and, if so, whether anything should be proposed to deal with that issue, such as proposing that the entity that performs the IANA function should have immunity of jurisdiction, or that the entity should have redundant sites in more than one jurisdiction.
> If there is support for dealing with that issue, then some text could be added.

While I'd love to see it happen, I think it's a separable issue so
should be left out of scope for now.