[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
- [Ianaplan] last call and IESG processing summary … Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Richard Hill
- Re: [Ianaplan] last call and IESG processing summ… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… John C Klensin
- Re: [Ianaplan] last call and IESG processing summ… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Richard Hill
- Re: [Ianaplan] last call and IESG processing summ… Andrew Sullivan
- Re: [Ianaplan] last call and IESG processing summ… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… Abdussalam Baryun
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- [Ianaplan] ***SPAM*** 21.631 (5) Re: last call an… JFC Morfin
- Re: [Ianaplan] last call and IESG processing summ… Milton L Mueller
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Milton L Mueller
- Re: [Ianaplan] last call and IESG processing summ… Brian E Carpenter
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko
- Re: [Ianaplan] last call and IESG processing summ… Seun Ojedeji
- Re: [Ianaplan] last call and IESG processing summ… Milton L Mueller
- Re: [Ianaplan] last call and IESG processing summ… Jari Arkko