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

JFC Morfin <> Tue, 27 January 2015 00:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D33831B2B3C for <>; Mon, 26 Jan 2015 16:33:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.631
X-Spam-Level: *
X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iPlaCn0G2JSx for <>; Mon, 26 Jan 2015 16:33:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA1D31B2B2F for <>; Mon, 26 Jan 2015 16:33:54 -0800 (PST)
Received: from ([]:57701 by with esmtpa (Exim 4.84) (envelope-from <>) id 1YFu6L-0000Ze-Ap; Mon, 26 Jan 2015 16:33:53 -0800
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 27 Jan 2015 00:12:25 +0100
To: Andrew Sullivan <>,
From: JFC Morfin <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
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 -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id: user confirmed/virtual account not confirmed
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: Tue, 27 Jan 2015 00:33:56 -0000
Message-ID: <>

At 21:18 25/01/2015, Andrew Sullivan wrote:
>But since both ICANN and the IETF have repeatedly stated their
>comfort with the way things are, and since the way things are just
>includes a bunch of terms that need to move around because of the
>departure of one actor from the scene, it seems to me that we'd have a
>relatively low risk that such terms are not forthcoming.

Dear Andrew,
The IETF has stated

"Our work is not yet complete. There are a number of steps still in 
front of us. They include the following:
    * Both the numbers and names communities need to complete their 
proposals. We at the IETF will continue engage with them with their 
work, just as they assisted us with ours.
    * Later, the IANA Transition Coordination Group 
(<>ICG) will assemble a complete proposal and gather 
community feedback on the result. When ready, they will submit the 
final proposal to the NTIA.
    * The NTIA must then consider and approve the proposal.
    * Finally it must be implemented.
While there will assuredly be some bumps along the road to success, 
the IETF leadership are committed to ensuring a good outcome for the Internet."

"Some bumps" which may not be that confortable.

The IETF does not seem to consider there is yet a departure of one 
actor from the scene when they say the final proposal will have to be 
submited for consideration and approval to the NTIA. The NTIA 
therefore replaces the IAB as the ultimate referent for the 
ICANN/IETF global community making it USG dependent. This 
differentiates the ICANN/IETF global community from the other RFC 
6852 global communities such as the FLOSS or the International communities.

As I have noted it, the IANAPLAN I_D now approved by the IESG 
represents an IETF leadership consensus as per RFC 2026. However it 
also puts the Internet technology in jeopardy because it does not 
includes the necessary watch and technological adjustments and 
liaison cooperation with those among the global communities which may 
not want to become NTIA dependent, and to competitively innovate as a result.