Re: [Internetgovtech] draft-iab-iana-framework-02 (was Re: IANA changes

Jefsey <jefsey@jefsey.com> Fri, 04 April 2014 15:55 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: internetgovtech@ietfa.amsl.com
Delivered-To: internetgovtech@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4F51A01F1 for <internetgovtech@ietfa.amsl.com>; Fri, 4 Apr 2014 08:55:38 -0700 (PDT)
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_42=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 CcOfAj1yUBkg for <internetgovtech@ietfa.amsl.com>; Fri, 4 Apr 2014 08:55:34 -0700 (PDT)
Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) by ietfa.amsl.com (Postfix) with ESMTP id 94C2F1A01F3 for <internetgovtech@iab.org>; Fri, 4 Apr 2014 08:55:34 -0700 (PDT)
Received: from [85.159.233.116] (port=3632 helo=MORFIN-PC.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from <jefsey@jefsey.com>) id 1WW6Sm-0006cQ-F2; Fri, 04 Apr 2014 08:55:29 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 04 Apr 2014 17:55:16 +0200
To: Olaf Kolkman <olaf@NLnetLabs.nl>
From: Jefsey <jefsey@jefsey.com>
In-Reply-To: <14E0C774-0FE8-4E5A-B1AA-AC6701963E67@NLnetLabs.nl>
References: <CADnDZ88-MdhnP0cithbGCdNjE-NGz43GgyBksRxtRBJv-a+vPA@mail.gmail.com> <427FB5CE-1782-4652-B51C-1BE059509820@NLnetLabs.nl> <201404021838.s32Ic6Mi058069@open.nlnetlabs.nl> <14E0C774-0FE8-4E5A-B1AA-AC6701963E67@NLnetLabs.nl>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_1028281276==.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 - iab.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/internetgovtech/1K3xiqM2aH5otDnGNC-cEsnSdJU
Cc: "internetgovtech@iab.org" <internetgovtech@iab.org>
Subject: Re: [Internetgovtech] draft-iab-iana-framework-02 (was Re: IANA changes
X-BeenThere: internetgovtech@iab.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Internet Governance and IETF technical work <internetgovtech.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=unsubscribe>
List-Archive: <http://www.iab.org/mail-archive/web/internetgovtech/>
List-Post: <mailto:internetgovtech@iab.org>
List-Help: <mailto:internetgovtech-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/internetgovtech>, <mailto:internetgovtech-request@iab.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Apr 2014 15:55:38 -0000
X-Message-ID:
Message-ID: <20140418044908.2560.39115.ARCHIVE@ietfa.amsl.com>

Olaf,

I sent the attached mail on the discuss list. It documents the 
alternative of IANA outcomes as I see them:
- either a solidified IANA/ICANN every internet thing can trust and 
build upon,
- or/and a multitechnology DNSA including the IANA information as an 
ubiquist content.

I have no idea of the final choice, or if both will stay together. My 
contribution is only to trigger a multitude's open DNSA operational 
(http://dnsa.org), and see what the multitude will do with it. 
Addressing Milton's requirements as do the Wikipedians.

My positions are definitly attached to the concepts of the ACT 
(advanced communication technology) I joined Tymnet for in 1978 (see 
the link I provided yesterday) and the way we made it support every 
technology, including TCP/IP in1984. This is something that RFC 5895 
demonstrated me that TCP/IP could also do. However, what is 
interesting now are the steps further which are permitted, if you 
blend this with the progresses made since then and the traffic/use evolution.

I will not detail all this but what interests me is an ASAP approach, 
as I call it: applications as a protocol. Network applications needs 
to be ubiqist to support active content. This is a whole area to be 
worked on - at the fringe to fringe layers, that we identified as 
being outside of the IETF but needing extremely stable and clearly 
documented IETF layers.

When I read your draft I think the IANA is the link. Its purpose is 
to document the IETF layers' stability and the way they are organized.

- This is critical to those who actually are the internet 
"taskholders", those who have an identified task of common interest 
for all. They need a rock solid IANA database.

- this also is a necessity, among others, for the real 
"stakeholders", i.e. the intelligent (multitechnology) users who need 
to have an ubiquist/real time access to the "stuff" of the systems 
(among them the internet background) they use. These people need that 
nformation through a IANA protocol consistent with their other 
technology "meteorological" protocols

I will take an example I made quite debated at the IETF. On my mobile 
I receive a mail in a language and script I ignore. The only way I 
have to know what they are is in using the langtag database. The only 
way to know the updated langtag is to dump the entire IANA big 
langtag database. If I receive a few mails like this, I will DoS the 
internet and the IANA. I was banned when I asked we discuss a DNS 
like system to resolve langtags (I will now implement on the DNSA as 
part of the MDRS - MedatData Multilinguistic Distributed Referential 
Registry System - or may be others will come with something better?).

There are two solutions:

1. either the IETF documents a IANA lookup protocol including axfr 
that named content networking can use.
2. or I keep dumping the IANA site and track changes without knowing 
if they correctly reflect the RFCs (in case of conflit what is 
"correct": the RFC or the IANA?) or the IANA manager intent, as I 
start doing again with the "IN root".

Please note that this is not exactly the same case as for the DNS 
since the domain name RRs are limited, but this also is for the users 
a multiclass system one of the classes being the IETF, another being 
ICANN for Class IN DNs, another being NRO for IP/ASs.

Now, what is the basic work to achieve?

IMHO only to be precise about the indications being given (a IANA 
precise framework and taxonomy). JSON with a polynymy (a multilingual 
taxonomy) would probably be a simple way to proceed.

1. you write "At the time of writing, the Internet Assigned Numbers 
Authority (IANA) maintains over one thousand protocol parameter 
registries." There is only the need to add "the list of which is 
maintained by BCP NNNN from the RFCs IANA consideration section.

2. you write "Internet registries hold identifiers consisting of 
constants and other well-known values  used by Internet protocols." 
These are the internet metadata of which the documented list is 
provided in BCP NNNN.

3. You write "This description of responsibilities, entities, and 
functions within the scope of IANA serves as an aid for a structured 
approach to the potential evolution of the Internet Registries model. 
". You just add "and extension as a protocol".

Once this is considered there might some extensions to be considered 
to get multitude's feed-backs and intertechnology consolidations.

jfc



>Alejandro,
>
>1. I agree that Milton's approach (not the solution) is the only one 
>we can currently work on since George  said he is to revamp his position.
>
>2. from your questions, you want to see real actions to be 
>tested/discussed rather than putative thoughts to be "blah blah blah"ed.
>
>These two points seem to be enough in order to address the issue in 
>the way the NTIA wishes it.
>
>1. there are three possibilities because in real life you do not 
>change things, you build aside things, so:
>
>1.0. either the internet is closed and something else is to replace it.
>1.1. either the current system is continued; this is George's line 
>as far as I understand it.
>1.2. or a new system is built and tested in parallel.
>
>            - This is where Milton's line should lead us if he was 
> not actually trying to reform the current system with new ideas.
>            - This is what I have triggered and reported, based upon 
> Milton's initial logic.
>
>2. If you consider only the 1.1. and 1.2. options, there are only 
>two possible known stable systems: top-down or bottom-up. A hybrid 
>proposition cannot be expected to build-up easily and auto-maintain 
>stably. The current system is top-down due to the claimed legitimacy 
>from building the internet is from the leading world power. The NTIA 
>removal has only two possible results:
>
>2.1. either it reinforces the leading power's influence on stability 
>in bringing the stability of the leading power's law as a referent 
>instead of its political executive. This is the NTIA MSist 
>hypothesis. It calls for an adaptation of the US law (by Congress) 
>before the 9/9/19 date, as assigned by the NTIA (cf. L. Strickling), 
>if we allow three weeks for a pre-crash emergency agreement.
>
>2.2. or it switches to the other stable system: bottom-up and proves 
>that it has fully assumed the transition before 9/9/19.
>
>This means that it is ICANN vs. DNSA.
>
>In order to clarify the debate, I suggest that
>-         the "discuss" and "IANAtransition" keep discussing the 
>2.1. George/Milton solution (i.e. ICANN plus possible DNSA),
>-        and "agora" is the list to debate the 2.2. solution at 
><http://dnsa.org/mailman/listinfo/agora_dnsa.org>http://dnsa.org/mailman/listinfo/agora_dnsa.org. 
>(i.e. DNSA including ICANN as a leading stakeholder).
>
>Both solutions obviously share the same "MSism" intent that in 
>European English is called "concertation".
>
>- In the 2.1. approach, the stakeholders (or partners) are chosen by 
>the top and have to be clearly defined by the law for the system to 
>be resilient. The need is to determine the law and to get it 
>implemented and accepted.
>
>- in the 2.2. approach, the partners (or stakeholders) are the 
>multitude, i.e. everyone who "wishes to be" a participant, like at 
>the IETF and Wikipedia. There is no leadership, but a steering 
>secretariat can be forked at any time, making it accountable to the 
>network itself. By the multitude for the multitude: the DNSes' Wikipedia.
>
>The origin of the whole issue is, therefore, that our known 
>governance systems do not scale to the globally "catenet"ed human 
>society. We have to invent one that will be adapted to the new scale 
>of the computer assisted human gathering and decision processes, 
>beginning with the governance of that very system.
>
>- There are those who want to enhance the existing governance to 
>make it more "democratic".
>- There are those who want to carefully (ICANN/ICP-3 gives good 
>guidelines) test (a) new system(s), so that evidence will show on 
>9/9/19which is the one to retain (or if they can cooperate). This is 
>what the NTIA is calling for.
>
>This does not prevent those who think that the proper global 
>granularity is neither with the doers nor with the users but with 
>the rulers to pursue an ITU based proposition. IMHO, but this is 
>only on my opinion, the three systems apply, each at its own stratum 
>in the network pile. This is why they do not oppose but complete. We 
>have 5.5 years to observe, learn, and agree how.
>
>This being said, I triggered the DNSA for it to belong to everyone 
>and its own technical target is to be its own "named data system", 
>so that the leadership issue is fully diluted in our polycratic 
>networked society. This is algorithmic governance, it should 
>therefore be algorithmically governed by public protocol.
>
>jfc