Comme annoncé, vous trouverez ci-après, la contribution que j'ai
adressée au groupe de travail IETF sur la transition NTIA/FCC. Elle
consiste en la reprise pratique des positions du SMSI non plus dans
le contexte politico/commercial ICANN/ICA, mais dans ce qu'une vision
LIBRE du Catenet permet de faire concrêtement en réponse à la
relègation structurelle de l'IAB et l'IETF au rang de contributeurs
secondaires de l'économie des noms de domaine.
L'interêt de l'opération est qu'elle ne nécessite ni argent, ni
adhésion importante. Il s'agit simplement d'un mécanisme ouvert et
respecteux de tous pour, selon le processus de la RFC 2026 appliqué à
l'I*Core et à ses concepts, corriger le BUG dont souffre l'internet
de l'ICANN à vouloir to "be unilaterally global".
Ce mécanisme est je pense assez complet qui correspond à leur
cohérence propre :
1. une liste de travail des utilisateurs informés au sein de l'IETF
([email protected]) - J'aurai besoin d'aide pour relancer le wiki du site
(http://iucg.org).
.
2. un groupe de travail créé après que les contributions utilisateurs
aient été refoulées (http://iuwg.org) - le sujet étant en débat par
mon appel en attente vers l'IAB. L'avantage de l'IUWG est qu'il est
hors copyrights de l'IETF Trust - qui vont sans doute jouer un
certain rôle pour vérouiller TCP/IP hors du domaine totalement public.
3. une approche purement défense des intérêts pratiques des
consommateurs : les points de coûts.contraintes inutiles, et les
alternatives innovantes.
4. le "seed" de la "communauté" manquante aux-côtés de celles des
"noms", "adresses", et "paramètres", celle de la documentation de
l'utilisation des resources partagées du catenet entre les
utilisateurs, les opérateurs et les technologies. (les "usedocs").
Elle aura une demande d'utilisation du IANA qui si elle n'est pas
satisfaite réclamera sa duplication étendue autonome qu'ils
craignent. (les référentiels multilinguistiques et multigraphiques
seront le point initial). On parle ici de contenu dupliqué, pas de
coût d'éhebergement. A la portée de très peu de sous.
Cela concerne les ICANN Systers. Pour ce qui concerne la
simplicité/cohérence côté utilisateur : ce sera le ***guichet
unique*** de la CCC SCIC, dont l'interface avec la standardisation,
la documentation, l'adressage et le nommage, dans des conditions
d'exploitation favorisées par le regroupement "de nous" comme les
coexploitants que nous sommes vise à réduire la fracture numérique en
mettant un meilleur écosystème digital à la portée de tous.
L'intérêt de cette approche est qu'elle s'inscrit dans l'architecture
même du catenet (du réseau des resources digitales communes aux
différentes technologies superposées (overlay network)) comme
l'internet, le web, le NDN (netflix/xerox), le SDN (le cloud), les
réseaux maillés locaux ou les réseaux sociaux. Donc au coeur même de
la technologie (c'est en fait le principe de subsidiarité - que j'ai
fait inscrire par l'"affinity group" des pionniers [Cerf, Klensin,
etc.] et que Pete Resnick a documenté dans la RFC 5895, à l'occasion
des IDNs - et qu'appliquent à tour de bras les "edge providers", et
la NSA. Et que notre gouvernement tente de se réserver avec sa loi
sur les "valseuses noires".
A partir de là c'est à nous de nous construire nos "cateboxes"
virtuelles, puis physiques, pour une nouvelle architecture de
sécurité où, par exemple, les clés de la confidentialités seront
maillées chez nous (blocknet.co ?) et non à la disposition de la NSA
dans le Cloud.
Impossible de savoir le temps que cela mettra mais .... On peut réver ....
jfc
----
Dear Folks,
We are supposed to represent the IETF/IANA (Informed) Users
community. The IETF IPRs, the lack of attention that we received and
the hacking of our site has not led us to develop as an IETF body,
while some have initiated the IUWG lists. I think, however, that it
is time for us to try to help the IETF and ourselves in the current
circumstances of the IANA transition process, and to counter the new
evolution of Paul Twomey's "IANA war".
1. A six-body complication
We are confronted with six stakeholders (IETF, RIR, ICANN, IANA, PTI,
NTIA) that only seem to share in common their disdain for our user
community (which pays for them all!). There are two possible POVs:
1.1. Political point of view
Clausewitz teaches that one always must consider the worst that can
result from a given situation. The worst seems simple enough to describe:
- a transfer of the 5,000 billion internet worth (through TMs - the
RFC 6852 "huge bounty") from NTIA/WIPO oversight, to ICANN, under
FCC/Congress legal control
- and extend it to everything digital (i.e. capitalizing on the
internet to oversee the whole multitechnology development, i.e. the
1985 delayed IEN 48 initial project).
The mechanism is simple. The IANA is the unique authoritative
repository. It will be operated by the DNSSEC operator, PTI Inc.,
incorporated in the US as a 100% ICANN affiliate replacement for
Verisign, that should statisfy our new internet masters : ICA
(http://www.internetcommerce.org/). This "simplification" could even
permit ICANN to transfer to Geneva, as the WIPO, ITU, etc. while
everything "commercially real" would stay under US jurisdiction.
Even with the WEF support and commercially led multistakeholderism,
this depends on the lasting multilateral credibility of the US State
"IN" (ICANN/NTIA) CLASS "unique authoritative root" fairy tale that
China politely/politically has respected externally for years. But
for how long now? We know this implies a risk and a cost the common
users cannot accept. This is the reason why we sponsor the "FL"
(Free/Libre) CLASS experimentation project [within the limits of the
ICANN ICP/3 constraints in order to avoid any confusion] and MYCANN
Plugs-in - moreover after
<http://malware.dontneedcoffee.com/2015/05/an-exploit-kit-dedicated-to-csrf.html>http://malware.dontneedcoffee.com/2015/05/an-exploit-kit-dedicated-to-csrf.html.
1.2. normative point of view
The WG/IANAPLAN has permitted to experiment the lack of documentation
that I opposed in RFC 6852 (the NTIA transition process follows +/-
the OpenStand multistakeholderism):
- nothing on how to address a situation where another community
architectonically (i.e. more fundamentally than at its own
architectural level) disagree with another community.
- nothing on how a new "global community" can emerge and be acknowledged.
In this case:
- I fully understand and accept that this WG Draft and debate
represents the rough IETF consensus
- however, as an informed user community member, I oppose this Draft
because it is uncompleted.
My
<http://www.ietf.org/iesg/appeal/morfin-2015-03-11.pdf>http://www.ietf.org/iesg/appeal/morfin-2015-03-11.pdf
appeal and their response shows that the IESG refuses to consider the
pending issues. However, some of these issues are already emerging. I
will, therefore, wait until the mid-June limit to appeal the IAB in
order to see how they are adapting to the reality evolution.
What seems obvious is that the IETF is downgraded from the
"iana.arpa" referent having a right of life and death on ICANN (MOU)
to one of the technical SDOs being using the ICANN coordinated names
and addresses. Protocols pass but names and addresses remain; they
survive technologies. The NTIA transition is the beginning of the
post-TCP/IP era.
Lawrence Strickling words this clearly when he speaks of "ICANN's
three customers". I certainly understand how names and numbers can
foot an ICANN's IANA bill. How will the IETF cope if RFCs and
parameters stay in the public domain: Russ Housley seems to be out of
context...
2. We need an RFC 6852 solution
A structural solution is to be found. It is necessarily part of the
NTIA transition. Otherwise, we users (informed users, end users,
corporate users, governments, providers, cities, etc.) will look
for/build it outside of this process. We need to help the NTIA
clearly understand it: we are neither in a master/slave nor in a
client/server situation. We are in a Masters and Masters relationship.
I certainly accept that the complication of the NTIA legacy is not
easy to revamp into a seamless neutral intergovernance of the world
digital ecosystem, Europe and BRICS can accept in the middle range.
This is why I propose that we proceed:
- (1) step by step.
- (2) from an informed user (IUser) point of view.
- (3) along a simple criteria that supersedes - on the middle/long
global range - every political local arrangement/revolution: the
"bubb" criteria: Biggest User Bang for a Buck.
2.1. Basic note
Please note that I do not oppose any local/political arrangement; I
just want to check that each of them:
- consistently sustains the general use stream (and will, therefore,
stay around being probably more and more reinforced)
- and not oppose or attempt to deflect it (because it would erode,
degrade, and ultimately be replaced).
I do not oppose the idea that something might be replaced or
improved, but I do not know how it will be replaced: I cannot support
something that I don't know. This is also a French constitutional
precautionary duty for the French citizens among us.
Is this sterilizing?
On the contrary. This is because we are in a particular case where:
- our charter pleads for a status quo (what I think leads to
technical jeopardy)
- our AD, also the IETF Chair, explains to us that "we are trying to
bring about a significant transition in the internet ...at the IETF
we are lucky to be on the easier side, but we also want the best for
the whole Internet". If I read this as usual, i.e. the "internet" as
a technology and the "Internet" as the "I*Core" deployed network
system, I am in total agreement.
We are truly establishing:
- new ***initial conditions*** for the internet
- in a new context for the Internet.
What is particular about the initial conditions is that you cannot
change them afterward, only patch them.
This is why I am attentive to the latent embarrassments/extensions of
the propositions that we may discuss. To clearly identify them, I
will call them "bubbles": Biggest User Bang for a Buck Latent
Embarrassment Suspicions or Extension Solutions.
2.2. The bubble list
To be pragmatic:
2.2.1. I suggest that we collect, extend, and maintain a bubbles
list. With only a description of the issue.
2.2.2. so, anyone or global community can use the list and
documentation to explore and document a decision tree
(<http://en.wikipedia.org/wiki/Decision_tree>http://en.wikipedia.org/wiki/Decision_tree)
from the first buck invested/spent by a user to the latest possible
returned bang.
2.2.3. this will, therefore, result into a clear method enabling the
ability to clearly support/follow/document each choice that users are
to make depending on their project and the technologies they may use.
2.2.4. In order to support the corresponding effort for consistent
multiple decision tree multi-consensuses, I suggest a common study
for a "<http://netbubbles.net/>netbubbles.net" tool.
3. The seventh stakeholder
The advantage I am looking for here is to transform,
- what may look like a "users ectoplasm" to the honnest members of
the names, numbers, and protocols communities
- into a seventh stakeholder that they can clearly identify as a
"usedocs" community - documenting how to consistently deal with the
digital ecosystem and multitechnology intricacy. The "usedocs.net"
site could then be created. It could feed the IANA with its own use
oriented references, becoming a fourth ICANN "customer" ?
I understand that at least several decision line families may quickly
emerge with options such as: ICANN, MULTICANN, multistakeholderist,
omnistakeholderist, self-restricted RFC use, permissionless
innovation, LIBRE Relationware, Open Source, proprietary solutions,
etc. without even considering national/continental enhanced
cooperation projects. Having them clearly documented will probably
help many in better understanding the pros and cons of the various
solutions that they are considering, thereby driving sustainable innovation.
Sustainable innovation in turn contributes to the achivement of an
"Inclusive, People Centered, Development Oriented and Knowledgeable
Information Society for All" (Tunis Declaration).
jfc
_______________________________________________
comptoir mailing list
[email protected]
http://cafedu.com/mailman/listinfo/comptoir_cafedu.com
