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