Re: [Ianaplan] last call and IESG processing summary for draft-ietf-ianaplan-icg-response
JFC Morfin <jefsey@jefsey.com> Tue, 30 December 2014 12:47 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 61BC81A0099;
Tue, 30 Dec 2014 04:47:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([4.31.198.44])
by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 17K7Yv5VpcVQ; Tue, 30 Dec 2014 04:47:52 -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 9957E1A0097;
Tue, 30 Dec 2014 04:47:52 -0800 (PST)
Received: from 223.57.14.81.rev.sfr.net ([81.14.57.223]:49368
helo=MORFIN-PC.mail.jefsey.com)
by host.presenceweb.org with esmtpa (Exim 4.84)
(envelope-from <jefsey@jefsey.com>)
id 1Y5wDF-0003nJ-GI; Tue, 30 Dec 2014 04:47:50 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Tue, 30 Dec 2014 13:47:42 +0100
To: Andrew Sullivan <ajs@anvilwalrusden.com>,Richard Hill <rhill@hill-a.ch>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <20141228204645.GB51125@mx1.yitter.info>
References: <62731176-0029-4CD6-B24B-6250F527FCB5@piuha.net>
<GLEAIDJPBJDOLEICCGMNEEICCPAA.rhill@hill-a.ch>
<20141228204645.GB51125@mx1.yitter.info>
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 - 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/lQLj6L3C22NVrAYcRdd_jCxNMsI
Cc: "Ianaplan@Ietf. Org" <ianaplan@ietf.org>, gene@iuwg.net,
IETF-Discussion list <ietf@ietf.org>
Subject: Re: [Ianaplan] 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, 30 Dec 2014 12:47:54 -0000
X-Message-ID:
Message-ID: <20141230124800.32469.90739.ARCHIVE@ietfa.amsl.com>
At 21:46 28/12/2014, Andrew Sullivan wrote: >On Sat, Dec 27, 2014 at 10:19:52AM +0100, Richard Hill wrote: > > And please note that the changes I requested to the sheperd write-up with > > respect to my statements have not been made (see below), so that write-up > > does not correctly reflect what I said during the disussions. At 21:46 28/12/2014, Andrew Sullivan wrote: On Sat, Dec 27, 2014 at 10:19:52AM +0100, Richard Hill wrote: > And please note that the changes I requested to the shepherd write-up with > respect to my statements have not been made (see below), so that write-up > does not correctly reflect what I said during the discussions. Richard, This already created an unintended controversy between Andrew and me. Andrew is correct when he says: >The shepherd's write up is how the shepherd communicates to the IESG, >and is not a consensus document or a product of the WG. It is instead >a process document. The shepherd's role seems, therefore, to be an informant for the IESG whose mission is to control that the Chairs respect the charter. > My understanding of the point of this document >(especially using the new-form template, which is the one I used) is >that it is to inform the IESG about the state of the WG's consensus, i.e. not about the dissensus arguments. >and in particular to alert them to any areas of particular controversy >and difficulty. only about the dissensus areas and risks of appeal (that last reporting would be left to the Chairs?) - If they want more: the records are available. Every AD can state a "DISCUSS" position. However, this is their personal decision, not one you can request or demand. This is a multilayer process. >If the IESG is concerned, they generally follow up >with the shepherd to learn more. Please remember that the concern is only about an existing dissensus, not about its reasons. If the dissensus does not lead to the risk of appeal, or was not considered as sufficient to impeach a rough consensus, it is of no further interest. One cannot constantly repeat the defeated objections. >While it is important that the write-up not misrepresent the state of >consensus, it need not provide a lot of detail about what the >objections of individuals are. What the "IETF born" leaders tried to tell you is that what counts is only the rough consensus. Like 51% in a democratic vote. In our case, the rough consensus was actually pre-decided by the Charter (status quo). This reflects a ***new*** IETF environment. This pre-decided rough consensus seems, therefore, to be the IETFcore's reading of what RFC 6852 OpenStand principles call a "broad consensus". This is why I say that this is an IETF fork. This ***new IETF*** branch has its own different governance rules. The only possibility left is to make the coup leaders to acknowledge their coup. This is difficult, as usually a coup is to take control, assume responsibilities, get power. In this case, it is the contrary, an abdication. For two reasons: * a good one - technology developments leads the internet to share the catenet with other technologies; IETF cannot claim monoresponsibility. * a bad one - the IETF does not want to be responsible for accommodating these new technologies to the existing practices, solutions, standards, and systems. One fully understands why: they do not want to be accountable for an ICANN economy. They are manufacturer/industry oriented. Up to RFC 6852 ICANN was accountable to IETF and still is to IAB - but they do not want that responsibility alone. Before being a decentralized toy for a sovereign financial entity - it is a distributed open network with cross-accountability mechanisms and real time operations. Up to the politicians to address the issue. Any solution to this situation calls for a clean sheet status report. This means 1. to make IESG, IAB, and ISOC to publicly commit on what they are, their mission is, the responsibilities they assume or not. 2. As a consequence to get the other stakeholders (in an omnistakeholder approach) state in the same manner who they are, what they need, what they want to achieve and how. This can only be obtained through an appeal process, technically documenting why the WG/IANAPLAN, which was pre-decided rough consensus by a virtual charter, puts the IETF technology in jeopardy and transfers the Internet technology governance to the WEF. In calling for press attention through the introduced delay. * Either ISOC will have to say "yes", and things will be clear. There will be a wefnet and an interplus competing over the ITU catenet. * Or ISOC will say "no", and the OpenStand principles will have to be completed and co-signed by the ITU and the IUse community. * Or ISOC will not respond and lose legitimacy - at least as far as IUse/Libre communities will be concerned. >In this particular case, since during >IETF LC you raised your concerns with the way the write-up expressed >your objections, your concerns are on the record anyway. Richard, Andrew is rightfully only concerned by the rough consensus decision legitimacy along with the IETF rules. Your objections are on the records not as objections (for their value) but to prove that you were able to express them and that the rough consensus process was respected. The IESG does not discuss objections. The IESG is told that there is a rough consensus and verifies that there is no conflict with other IETF efforts. This is a perfectly balanced process, because if ***you*** think that the matter of your objections has not been considered enough you can call on the IESG/IAB to discuss these objections through an appeal process. Either you agree with the Chairs' rough consensus declaration, or you appeal. This is now your decision. You can appeal either (1) against the Chairs' declaration or (2) against the produced document or (3) both. 1) I understand that in your opinion you oppose the Chairs' rough consensus declaration as being premature and not fully justified. It does not have to be documented by Andrew, but you can document it to the AD, the IESG, etc. 2) I do not oppose the Chairs' declaration of rough consensus myself, because as soon as they refused to ask for IAB guidance over the Charter virtual parts, the pre-decided rough consensus was shared by most of the members of this WG. I oppose the produced document, not for what it says, but for what it does not say. I oppose its incompleteness as being the result of a tacit anti-ITU/IUsers I*core/NTIA pre-consensus strategy. This strategy has now itself forked (between ISOC and NMI). Andrew has nothing to do with this. He loyally tries not to choose among not yet fully documented sides. There were several initial network projects in the 1960s. Three propositions came to gather them together. Multitechnology Tymnet, concatenation Catenet, TCP/IP Internet. Counter-strategically, TCP/IP prevailed through the "status quo" and forked through the IETF in abandoning the multitechnology ambition. In front of the multitechnology come-back, ISOC took IETF over but must technically fork again (this I_D) and accept "permissionless innovation" while its political support is economically forking (WEF). I do not particularly wish to know who wishes to follow which fork. I am only interested in the multitechnological intelligent use of the catenet which is public, common, and private omistakeholder property. >Best regards and many happy returns for 2015, Ditto to everyone. Jfc >A > >-- >Andrew Sullivan >ajs@anvilwalrusden.com > >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan
- [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