[Ianaplan] ***SPAM*** 21.631 (5) Re: last call and IESG processing summary for draft-ietf-ianaplan-icg-response

JFC Morfin <jefsey@jefsey.com> Tue, 06 January 2015 19:33 UTC

Return-Path: <jefsey@jefsey.com>
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 3465B1A1B72; Tue, 6 Jan 2015 11:33:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: YES
X-Spam-Score: 21.631
X-Spam-Level: *********************
X-Spam-Status: Yes, score=21.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497, URIBL_SBL=20] autolearn=spam
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 uirQkiD7xDAf; Tue, 6 Jan 2015 11:33:47 -0800 (PST)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82D661A1B5E; Tue, 6 Jan 2015 11:33:47 -0800 (PST)
Received: from 223.57.14.81.rev.sfr.net ([81.14.57.223]:47826 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from <jefsey@jefsey.com>) id 1Y8Zst-0006Wo-4D; Tue, 06 Jan 2015 11:33:43 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 06 Jan 2015 20:33:35 +0100
To: Jari Arkko <jari.arkko@piuha.net>, "Ianaplan@Ietf. Org" <ianaplan@ietf.org>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <3181B0DB-BBB4-4674-ADF2-3C03B9CDACD4@piuha.net>
References: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net> <3181B0DB-BBB4-4674-ADF2-3C03B9CDACD4@piuha.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.presenceweb.org
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/yDp-oguPbc8YPM_IS-bfUwcPPAA
Cc: draft-ietf-ianaplan-icg-response.all@tools.ietf.org, IETF-Discussion list <ietf@ietf.org>
Subject: [Ianaplan] ***SPAM*** 21.631 (5) Re: last call and IESG processing summary for draft-ietf-ianaplan-icg-response
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: Tue, 06 Jan 2015 19:33:53 -0000
X-Message-ID:
Message-ID: <20150106193357.11440.44992.ARCHIVE@ietfa.amsl.com>

Dear Jari,
Your report creates an appeal procedural problem for me. This 
enlightens the fact of why I believe a final ISOC published position 
is necessary.

At 10:57 06/01/2015, Jari Arkko wrote:
>Whether the document gets published as an RFC or not is somewhat 
>immaterial, because the main purpose of providing an IETF view on 
>the matter is to collect several views together from different 
>organisations to gather a complete transition proposal.

As I read it, this document describes the reality of a fork in the 
IETF mission, responsibilities, and strategies that result from a 
deep change in the technological and political context. That change 
has been partly addressed by the OpenStand principles, individually 
co-signed on August 22, 2012 by the Chairs of IAB and IESG with the 
Chairs of a limited number of SDOs. These OpenStand principles have 
been reported as RFC 6852. This permitted me to appeal the 
incompleteness of these principles along RFC 2026.

However, this appeal necessarily had to be graduated since IESG, IAB, 
and ISOC were involved in different ways and the real issue was with 
ISOC: how do they consider the IAB's role, in the very case of an 
appeal procedure?

However, before I could reach the ISOC layer, on Feb. 21, March 14, 
and March 24 2014, ISOC and the USG confronted the deep change in the 
technological and political context, that I referred to, in their own ways.

* 
http://gsnetworks.org/research_posts/the-remarkable-internet-governance-network-part-i/
* 
http://www.ntia.doc.gov/press-release/2014/ntia-announces-intent-transition-key-internet-domain-name-functions
* http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/

"Moving to the Next Era - US Government to Cede Control of ICANN" , 
meant that IETF as an ISOC affiliate would probably be affected by 
this move in this next area.
1. this necessarily delayed my RFC 6852 appeal at the ISOC level 
since the matter could be better documented by an IETF dedicated WG.
2. this is what rightly happened: the WG/IANAPLAN was asked to 
discuss it - as an option that the NTIA had not announced but ISOC 
seemed to favor (transfer of the IANA instead of the DNS ICANN/NTIA 
Class) and the WG Chairs did not want to accept as anything else than 
a "status quo" in the middle of the change.

This permitted me to better pursue my clarification effort. Through a 
debate and an appeal concerning a regular RFC, produced by a WG, 
along a Charter, approved by an IETF Last-call. It even obliged me to 
crash create a non-IETF/WG to stay aside of the IETF Trust IPs. I 
recall that my objective is to get a formal jurisprudence in the way 
that IESG, IAB, and ISOC consider the IAB area of responsibilities 
along the RFC 6852 principles.

In considering that the IANAPLAN I-D does not need to be published as 
an RFC, you prevent me from appealing the WG/IANAPLAN non-RFC. You 
copnsider it can be purely informational to the IESG, IAB, IAOC, 
ICANN, ISOC, etc. but you do not consider the whole Internet community.

Is there still a pilot in the catenet cockpit? If yes, who are they? 
It seems that stewart ICANN wants to take the con.


>         • Jefsey has noted that he intends to file a future appeal 
> on this topic, around the responsibilities of the IETF and RFC 
> 6852. Jefsey notes "My point will not be to change it, but to make 
> sure that the IESG, and IAB, and ISOC, fully and publicly declare 
> that they understand, accept and decide that this is what they 
> mean." It is not clear that there is anything to do about this at 
> the moment, particularly when at least the sponsoring AD does not 
> understand the provided feedback;

:-) The same as Jefsey "does not understand" how the sponsoring AD 
may co-sign documents with the IAB Chair and others.


>this is an IETF document that will, as it gains approval, will have 
>been processed by the IESG and will explicitly note that the IAB 
>supports the described transition. Response by Andrew Sullivan on 
>December 15 indicates that he does not believe any changes to the 
>document or the summaries produced by the WG officials were necessary.

The reasons why Business, Libre, Political, and Civil people might 
not believe that any change to the document is necessary are 
different, but are certainly supported by the fact that the document 
has certainly met a rough consensus to be (non?)published.


>         • The IAOC has indicated that they are comfortable with the 
> direction the document gives for the IAOC.

It would certainly be surprising if they weren't. The URL would be 
useful for further reference.

The point is not here. The point is that:

* I see this document as an IETF consensual abdication of its de 
facto exclusive ruling of the Catenet. This is certainly "Moving to a 
Next Era" and the world needs it to be clearly formalized by ISOC. We 
need to know if this is good or bad news for the individual users.

* you say that publishing this text as an IETF formal statement of 
reference (RFC) is "somewhat immaterial", introducing the world's 
digisphere in a technical/political gray area that I wish to avoid.

The question is simple, the Catenet not being Internet exclusive 
anymore: will it be "US neutral" (IETF, NDNconsortium, Google, Dyn, 
Netflix, etc.) and/or Libre?

I favor the "and" plus cooperation. You seem to have to fuzzy favor 
the "or". I understand your diplomatic obligations but this has to be 
clarified one way or another.   ISOC & co. cannot avoid it forever.

The ball is still in your court.
jfc