Re: [iucg] [Ianaplan] teasing the issues apart -- IANA.org, authoritative IETF repository
JFC Morfin <jefsey@jefsey.com> Fri, 10 October 2014 12:14 UTC
Return-Path: <jefsey@jefsey.com>
X-Original-To: iucg@ietfa.amsl.com
Delivered-To: iucg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id CF2EB1A90DA;
Fri, 10 Oct 2014 05:14:44 -0700 (PDT)
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 s3UD7VAGrdzC; Fri, 10 Oct 2014 05:14:44 -0700 (PDT)
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 DABAC1A8BAF;
Fri, 10 Oct 2014 05:14:43 -0700 (PDT)
Received: from 192.102.176.95.rev.sfr.net ([95.176.102.192]:53555
helo=MORFIN-PC.mail.jefsey.com)
by host.presenceweb.org with esmtpa (Exim 4.82)
(envelope-from <jefsey@jefsey.com>)
id 1XcZ5m-00056p-KE; Fri, 10 Oct 2014 05:14:43 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 10 Oct 2014 14:14:35 +0200
To: "Leslie Daigle (TCE)" <ldaigle@thinkingcat.com>,
"ianaplan@ietf.org" <ianaplan@ietf.org>
From: JFC Morfin <jefsey@jefsey.com>
In-Reply-To: <5437031D.9080505@thinkingcat.com>
References: <5437031D.9080505@thinkingcat.com>
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/iucg/Xrt6TAoEznrhgZ1O9tazfiToeY8
Cc: iab@iab.org, vint Cerf <vint@google.com>, iesg@ietf.org,
"iucg@ietf.org" <iucg@ietf.org>
Subject: Re: [iucg] [Ianaplan] teasing the issues apart -- IANA.org,
authoritative IETF repository
X-BeenThere: iucg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: internet users contributing group <iucg@ietf.org>
List-Id: internet users contributing group <iucg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/iucg>,
<mailto:iucg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/iucg/>
List-Post: <mailto:iucg@ietf.org>
List-Help: <mailto:iucg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/iucg>,
<mailto:iucg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2014 12:14:45 -0000
X-Message-ID:
Message-ID: <20141010121450.21562.50969.ARCHIVE@ietfa.amsl.com>
At 23:50 09/10/2014, Leslie Daigle (TCE) wrote: >I feel there is still a discussion to be had here, though I am >sensitive to the fact that we're spelunking in a pretty big rathole >at this time. Trying to tease issues apart to see if it helps the >discussion -- from the couple of days' messages, it seems that: Thank you, this defines the IETF present questions rather well that are to be seen, at this WG/IANAPLAN through Andrew Sullivan's filter: "Our charter tells us to do the minimum possible. We should heed its instructions." However, we have to be careful at not doing less than the minimum required. 1. internet ownership >1/ Some people think the IETF (Trust) is the obvious home of iana.org . Yes. This makes the ISOC/IETF Trust the owner of the Internet technology. From a Libre point of view, RFCs should be subject to a Chinese wall and the internet use to be specified again from a user point of view in order to free the internet system from the IETF Trust. > Others don't believe that and/or think it would be a stretch to > get the rest of the world to agree. Correct. It is unlikely that BRICS, Europe, and Libre will accept the IETF Trust terms at this stage. This may result in some TPP/TAFTA legal actions that will have no impact on the people's intelligent use of the internet. However, might affect IETF and ICANN's image and credibility and the US industry's interests. >But, for now, I would like to suggest we take discussion of "1/" off >the table. This would not make any sense, if (as most probably the rest of the world believes) "1/" is the key to "2/". ==> suggested action: to port the IETF deliverables (RFCs and IANA Tables) under a Creative Common license. From ISOC proprietary to Free. From a GSN pact to people's Libre. 2. tightly bind the future to the past. >2/ The issue that Eliot opened on the document was to address how >best to go about "requiring the current operator make clear upon >termination that their copy is no longer the version that is >maintained on our behalf, where at on[e] point (today and hopefully >long from now) it was. " (Eliot's words). > >I think "2/" has been characterized as rational contractual >behavior, and it seems like a worthwhile problem to address. The >challenge is that the most obvious way to achieve 2 is to bind >iana.org and the registries, tightly, as they are today. This supposes that the real world is not the world described by the RFC 6852 paradigm, i.e. there is still only one global community network managed by ICANN and documented by ISOC. 3. Preventing the fork >Other thoughts? Unless the IESG, IAB, and ISOC say otherwise you are documenting an IETF fork between the past and reality, and between IEN 48 first and second objectives, when it could have been cooperation between robust end to end lower layers and intelligent fringe to fringe higher layers. ==> suggested action: to add to the RFC 3935 missions of the IETF: "to engage in the IEN 48 second objective along its core values, the RFC 6852 paradigm and the consequence of the US/NTIA removal, i.e. to share the global catenet among/with other technologies". This would translate into advocating a WG/RFC3935bis. 4. Conclusion There are only three clarifications needed: 1/ is the NTIA transitioning its DNS or complete IANA oversight? 2/ is RFC 3935 or RFC 6852 the reference for the IETF or a consistent update of RFC 3869, 3935, and 6852 to be done? 3/ is the IETF wishing to constrain innovation to the past, or provide a stable basis to open future innovation? This seems to clearly delineate the purpose of my appeal. Thank you. jfc