Re: [Ianaplan] Process concern regarding the IETF proposal development process

Avri Doria <> Sat, 24 January 2015 22:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1B1841A1AF9 for <>; Sat, 24 Jan 2015 14:58:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.234
X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6QIqI4iRyMJ8 for <>; Sat, 24 Jan 2015 14:58:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 681BE1A1AEB for <>; Sat, 24 Jan 2015 14:58:31 -0800 (PST)
Received: from ([]) by (8.14.4/8.14.4) with ESMTP id t0OMwTD6003843 for <>; Sat, 24 Jan 2015 17:58:29 -0500
Received: (qmail 13180 invoked by uid 0); 24 Jan 2015 22:58:29 -0000
Received: from unknown (HELO ? ( by 0 with ESMTPA; 24 Jan 2015 22:58:29 -0000
Message-ID: <>
Date: Sat, 24 Jan 2015 17:58:27 -0500
From: Avri Doria <>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------000509020407030400090707"
X-Antivirus: avast! (VPS 150124-1, 01/24/2015), Outbound message
X-Antivirus-Status: Not-Tested
Archived-At: <>
Subject: Re: [Ianaplan] Process concern regarding the IETF proposal development process
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, 24 Jan 2015 22:58:34 -0000


On 24-Jan-15 17:22, John Curran wrote:
> On Jan 24, 2015, at 12:14 PM, Avri Doria <>; wrote:
>> ...
>> I know that in the Names community work, gaining an understanding of the legal environment and the way of actually dealing with the legal points of appeals and possible future decisions to remove the function from ICANN  before the crisis point, is a gating concern and part of the reason are still working on developing our response - we need legal advice before we can complete our work.  But in that case there is no doubt that the legal aspects are in scope for the Cross community WG.
>> Perhaps once the Names community has completed its work, and I hope it is real soon, there will be some clue that can be used on legal arrangements and appeals mechanisms by the other communities, upon recommendation from the ICG.
> Please explain the above…  it almost appears that you are suggesting 
> that the ICG would make some form of recommendation with respect to 
> various legal implementation aspects (e.g. arbitration rules and location)

Not quite.

What I am saying is that when they look at the proposals, the comments
and what all, they may decide there is a issue that needs to be dealt with.

And if they do, following my understanding of their process, they will
ask questions of the 3 communities.
>> As for whether ICG experts should be expected to understand the intricacies of the arrangements supplied by the 3 communities, I am sure that each group having picked its finest, they are certainly capable of doing so,  And I beleive that as a group coordinating the puzzle of the partial responses from all communities they need to do so to figure out how to fit the 3 answers (once the have the 3) into a consistent response for NTIA.
> The ICG needs to make sure that the integrated proposal meets the NTIA
> criteria.   The ICG charter does not include any form of proposal development 
> work; if there are problems with the component proposals, then the ICG is to 
> communicate that back to the relevant communities so that the communities
> can address the issues.  


> This is particularly important when if comes to contractual matters, since it
> might easily be the case the optimum structure for the IETF/IAB to contract
> for IANA protocol parameter services might truly be different than the optimum 
> structure for the RIR community to contract for IANA services for the various
> central number registries, or the names community to contract, etc.  There is 
> no requirement these contractual structures be the same, only that the specific 
> arrangements do not preclude assembly of a single combined proposal.

Agreed, no requirement.
Perhaps an opportunity.