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

JFC Morfin <jefsey@jefsey.com> Fri, 19 December 2014 11:04 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 7A6A41A9081; Fri, 19 Dec 2014 03:04:27 -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 fkt2-7EkPfld; Fri, 19 Dec 2014 03:04:26 -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 8587A1A9069; Fri, 19 Dec 2014 03:04:26 -0800 (PST)
Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:61447 helo=MORFIN-PC.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from <jefsey@jefsey.com>) id 1Y1vM8-00036z-M4; Fri, 19 Dec 2014 03:04:25 -0800
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 19 Dec 2014 12:04:22 +0100
To: Jari Arkko <jari.arkko@piuha.net>, "Ianaplan@Ietf. Org" <ianaplan@ietf.org>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net>
References: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net>
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: intl+dot.dj/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: http://mailarchive.ietf.org/arch/msg/ianaplan/d4C-1RXYaR64aBRbTADGuIYcUYM
Cc: gene@iuwg.net, draft-ietf-ianaplan-icg-response.all@tools.ietf.org, iucg@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: Fri, 19 Dec 2014 11:04:27 -0000
X-Message-ID:
Message-ID: <20141219110432.32087.25768.ARCHIVE@ietfa.amsl.com>

At 19:53 18/12/2014, Jari Arkko wrote:
>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."

Dear Jari,

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.

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."

>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; 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.

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).

This would be (1) the end of the "status quo" strategy and (2) the 
affirmation of the "permissionless innovation" paradigm, without any 
proposition regarding:

- the replacement and an extension of the former IAB guidance role in 
the resulting multitechnology competitive environment on an 
economical, and probably political, basis.
- The way the IETF should adapt its mission of influencing peer SDOs 
and global communities in such a way as to make the Internet work better.

The two mails of Andrew Sullivan and the comment of Pete Resnick show 
that this new context and its resulting Tao is not familiar yet among 
every IETF leaders. 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 coordination effort 
that we could adhere to. OpenStand is only a set of principles, not 
an active "concertance" as in a concerted everystakeholder 
governance. Otherwise, it is likely that the technical referent 
structure will temporarily be ICANN and will end up as being the ITU-I.

A twenty years long process to accept the inevitable: in our world 
only sovereignty or concertance (see above) can last.
Best
jfc