Re: [Ianaplan] last call and IESG processing summary for draft-ietf-ianaplan-icg-response

JFC Morfin <jefsey@jefsey.com> Mon, 22 December 2014 05:11 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 E73E81A00B2; Sun, 21 Dec 2014 21:11:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.232
X-Spam-Level: **
X-Spam-Status: No, score=2.232 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=0.6, 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 4CioHbMMI6Hg; Sun, 21 Dec 2014 21:11:43 -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 EE2DB1A00AD; Sun, 21 Dec 2014 21:11:42 -0800 (PST)
Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:38619 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from <jefsey@jefsey.com>) id 1Y2vHQ-0004dj-1R; Sun, 21 Dec 2014 21:11:40 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 22 Dec 2014 06:11:30 +0100
To: John C Klensin <john-ietf@jck.com>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <95C4C6D9E29456672DEE6A92@JcK-HP8200.jck.com>
References: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net> <20141219110431.5AE911A9089@ietfa.amsl.com> <95C4C6D9E29456672DEE6A92@JcK-HP8200.jck.com>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_401132578==.ALT"
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/ARR9F971BJ-g1aBo_IUeMMBD4SQ
Cc: "Ianaplan@Ietf. Org" <ianaplan@ietf.org>, gene@iuwg.net, Jari Arkko <jari.arkko@piuha.net>, "iucg@ietf.org" <iucg@ietf.org>, draft-ietf-ianaplan-icg-response.all@tools.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: Mon, 22 Dec 2014 05:11:47 -0000
X-Message-ID:
Message-ID: <20141222051156.24165.65901.ARCHIVE@ietfa.amsl.com>

Dear John,

Thank you for your kind, open, and constructive comment. It would 
help sustain a long discussion. I will try to make a general and 
"short" response.

Your mail actually confirms for me that the IETF fork between the 
pre-RFC 6852 IETF and the post-RFC 6852 IETF,
- which has actually been enacted at the IAB level,
- as resulting from a change in the very nature of the 
catenet/internet relationships,
is not yet perceived from within the IETF culture, while it starts 
being progressively enacted and played on, on the technical (new 
upper layers technologies), economic (WEP, Google, Dyn, Netflix, 
Libre, etc.), military, and political (Europe, BRICS) planes.

My effort is simply to make ISOC formally endorse the risk that I 
might be right in considering the Lynn St-Amour/Don Tappscott 
analysis conducted by GSN for the USG 
(<http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/>http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/) 
as self-contradictory. This was the purpose of my appeal concerning 
RFC 6852's lack of common referent to replace the IAB that was 
interrupted by the NTIA.


Lynn/Don's analysis could be very briefly described as being - within 
the RFC 6852 paradigm and the "permissionless innovation" framework - 
the meme stating that "Multi-stakeholder governance has come of age 
and is now fully independent from control by any government, or 
governmental organizations like the UN. It is the very embodiment of 
the vision of a free enterprise system that is managed by its 
participants." ... most probably within the ISOC framework, that 
ICANN seems to alternatively prefer to be the NMI (which I feel is 
slightly more consistent with RFC 6852).

This does not stand. For a simple reason that I know very well: me.

Lynn's meme stands on the "multi-stake-holder" concept. I know that 
the network, the world and, the universe stands on the 
"omni-stake-holder" reality.

Andrew (who I certainly did not insult!) expressed this very well, as 
you just did it: my inputs have not been considered. For a very 
simple mathematical reason which is:

"omni - multi = Libre +  Jefseys".

Look,
- I am discussing TCP/IP Class IN AMERICANN + MYCANNs + GOVCANNs + 
CORPCANNs global reality.
- you are discussing the "ICANN, IANA(*), IETF,  IAOC, IETF Trust, US 
Law, Jon Postel, etc." local virtuality. This virtuality could only 
be credible if there was someone at the iana.arpa helm. The purpose 
of this I_D is to show that there is no one.

(*) the NTIA has never talked about transferring all the IANA 
functions, and the Charter never mentioned the IGC.

The publication of the I_D will not create the fork between your BCP 
78 IETF and the RFC 6852/3935bis IETF: it was  created two years ago 
by OpenStand. And officialized one year ago by RFC 6852  I will only 
make it clear that the IETF people have not noticed. They have to 
notice it; otherwise, the transition will not be seamless and 
constructive. This is the purpose of my appeal.

- either it is accepted, and we know who the proprietor of the 
technical rights and duties concerning the Internet is: and the IAB 
will have to help upgrading the IETF culture.
- or it is denied and ISOC and (USG) will have made it clear that 
they wish for the IETF to only  remain one of the contributors to the 
TCP/IP technology middle layers within a multitechnology digital context.

My only concern is that the IETF situation resolution does not cause 
too much hassle to the permissionless innovation 
contribution/contributors - and that they can positively cooperate to 
the IETF in being identified for what they do.

jfc

At 15:53 19/12/2014, John C Klensin wrote:
>Jefsey,
>
>Perhaps because we have corresponded more over the years, unlike
>Jari, I understood your comments and the note excerpted below
>confirmed my understanding.  Part of that understanding is that
>the vast majority of your text and comments below are about your
>vision for computer-enabled networking going forward and where
>you think the IETF and other bodies fit in that model.  While
>the I-D does contain some description of parts of how the IETF
>works and, in particular, how it relates to the IANA function,
>it doesn't make normative changes to IETF  (or IAB, ISOC, etc.)
>relationships to the present or future Internet beyond the very
>narrow issues of IANA relationships and oversight.  No matter
>what you might read into what is said, for it to do so would be
>out of scope for the WG and would represent changes to which
>some of us would object strenuously, especially if those changes
>were hidden in discussions of NTIA-IANA relationships and the
>conditions and implications of changes in them.
>
>Details below.
>
>--On Friday, December 19, 2014 12:04 +0100 JFC Morfin
><jefsey@jefsey.com> wrote:
>
> >...
> > It is difficult to understand this sentence since the "this"
> > is not explained as being that from now on, the IETF will
> > still be working for the future internet ,in its own way and
> > for its own mission but will not be exclusive or responsible
> > for it any more.
>
>The document changes nothing in that area, including any notions
>of exclusivity and/or responsibility.   I don't know whether we
>would agree about how "exclusive or responsible" things are
>intended or desired to be today (or how they are practiced), but
>I am quite certain that this document changes nothing in those
>areas.
>
> > This responsibility is here understood as per RFC 3935: "when
> > the IETF takes ownership of a protocol or function, it accepts
> > the responsibility for all aspects of the protocol, even
> > though some aspects may rarely or never be seen on the
> > Internet.  Conversely, when the IETF is not responsible for a
> > protocol or function, it does not attempt to exert control
> > over it, even though it may at times touch or affect the
> > Internet."
>
>That statement has little or nothing to do with the IANA
>function, the IETF-IANA relationship, or IANA oversight.  The
>present draft does not change anything about it, even to
>reaffirm it.
>
> > The IAB still has to commit in this document. However,
> > eventually ISOC will be the one having to decide, since the
> > I_D means that ISOC would not own the internet anymore (in the
> > RFC 3935 meaning hereinabove).
>
>I do not believe that any of IETF, the IAB, or ISOC have claimed
>at any time to "own the Internet".   Even if they had, there is
>nothing in this document that would change or ratify that
>status.   Because the document changes nothing in those areas,
>your subsequent assertions about 'the end of the "status quo"
>strategy' and 'affirmation' are just simply not relevant.
>
> >...
> > Now, as a non-IETF
> > technically competing WG, I need to have the practicalities of
> > this new situation explained and how IETF stakeholders intend
> > to adapt to the MYCANN/CORPCANN/GOVCANN middlewares and the
> > multitechnology environment that we will face and build
> > together.
> >
> > We need to know if the IAB/IETF, or someone else they would
> > accept, intends to launch a normative multistakeholder
> >...
>
>Whether you "need" those things or not, and whether you can
>demand that the IETF or IAB respond to those needs, they simply
>have nothing to do with the substantive subject matter of this
>document or the scope of the WG.
>
>best regards,
>     john