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
- [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