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