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

Jari Arkko <jari.arkko@piuha.net> Mon, 26 January 2015 23:15 UTC

Return-Path: <jari.arkko@piuha.net>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 377F41B2AF6 for <ianaplan@ietfa.amsl.com>; Mon, 26 Jan 2015 15:15:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 e7R8qI2h1-BO for <ianaplan@ietfa.amsl.com>; Mon, 26 Jan 2015 15:15:21 -0800 (PST)
Received: from p130.piuha.net (p130.piuha.net [IPv6:2a00:1d50:2::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7553B1A000D for <ianaplan@ietf.org>; Mon, 26 Jan 2015 15:15:13 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id CFBDC2CC61; Tue, 27 Jan 2015 01:15:11 +0200 (EET) (envelope-from jari.arkko@piuha.net)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCmIO88VoENo; Tue, 27 Jan 2015 01:15:11 +0200 (EET)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id 40E452CC4D; Tue, 27 Jan 2015 01:15:11 +0200 (EET) (envelope-from jari.arkko@piuha.net)
Content-Type: multipart/signed; boundary="Apple-Mail=_8BF58F23-7328-4EB8-B1F2-C3CBA332921E"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <54C64467.4020909@meetinghouse.net>
Date: Tue, 27 Jan 2015 01:15:07 +0200
Message-Id: <DCC2E578-906A-4D75-8DB8-DAD19F424391@piuha.net>
References: <1F30A463-76A9-4854-952A-35C54E42D2C6@istaff.org> <CAOW+2dvd1QRC6xbDTZ6ah23HfX=K=SeXDc1kXr2NREAcy37SvQ@mail.gmail.com> <54C13630.3050601@meetinghouse.net> <54C3D305.6030705@acm.org> <20150125201843.GB76865@mx1.yitter.info> <c258dfbdcb3b45f3a5d239fc6c3f0246@EX13-MBX-13.ad.syr.edu> <20150126024813.GB77105@mx1.yitter.info> <54C5ABCB.20000@meetinghouse.net> <20150126030945.GD77105@mx1.yitter.info> <54C5B476.6030900@meetinghouse.net> <20150126034153.GE77105@mx1.yitter.info> <54C64467.4020909@meetinghouse.net>
To: Miles Fidelman <mfidelman@meetinghouse.net>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/nof6dryGqC9Rh7lbMx7Vs3e7XVQ>
Cc: ianaplan@ietf.org
Subject: Re: [Ianaplan] Process concern regarding the IETF proposal development process
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jan 2015 23:15:26 -0000

Miles,

> And this is the big issue that Richard (if I might speak for him), myself, and several others had withe the process - the WG was not representing the IETF "community" in that its charter explicitly excluded policy, legal, contractual, and governance issues from its scope.  So those issues were not addressed by open, transparent, consensus process.

I understand where you are coming from, but I think the above is not a correct characterisation of the situation. The IANAPLAN WG and the IETF community are in charge. They have spoken; they have made their decision on what the transition should be from their perspective. They have made all the top-level decisions necessary to move forward.

This does not mean that we are entirely done. Obviously there are steps beyond this. One, there is an enhancement to make to a contract, and an acknowledgement from various parties to be made about data being in public domain. That is the task for the IAOC, to be done exactly as the IETF commands it to be done. This does not prevent the IAOC for implementing additional enhancements (they got some suggestions from the community), and this is their job, they keep updating all IETF contracts every year or every renewal period. But they shall follow IETF guidance that is clearly described in the IANAPLAN document.

Two, the ICG has work to do. It is conceivable, for instance, that we’ll find incompatibilities that need fixing. We may have to revise the three proposals.

Three, ICANN has some accountability and structural changes to make and some of those may be needed for the names proposal.

Four, NTIA needs to make some evaluations and decisions.

Five, when the full transition goes forward, some contracts will be terminated and perhaps some new ones created.

So I plead that we do not mix clear guidance from the IETF with some of these further steps. They will be done according to what the working group specified. Or else we have to come back here and rethink. And that is always a possibility, e.g., with the incompatibilities, or with NTIA requiring something additional. Or assumed accountability mechanisms or contracts not being possible due to the other parties not being ready or not being willing to do them.   It should be obvious that our community can not, for instance, sign contracts on behalf of ICANN or NTIA. So clearly we have a situation where we need to express our goals and requirements but the actual implementation - be it the negotiation or the signing - necessarily comes later.

In short, to say that the proposal is not complete or is not under the control of an open process is wrong. The direction has been set. There are more steps to go through, and they will happen in time, but they *will* happen under the community direction.

Jari