From nobody Thu Jul 9 14:32:24 2015 Return-Path: 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 0BAA51A03B3; Thu, 9 Jul 2015 14:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.135 X-Spam-Level: * X-Spam-Status: No, score=1.135 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 WtFWuWAY8si5; Thu, 9 Jul 2015 14:32:16 -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 D420D1A03D5; Thu, 9 Jul 2015 14:32:16 -0700 (PDT) Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:20809 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from ) id 1ZDJQS-00077V-U5; Thu, 09 Jul 2015 14:32:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 09 Jul 2015 23:31:50 +0200 To: IAB From: Jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_862391045==.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 - 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: Message-Id: <20150709213216.D420D1A03D5@ietfa.amsl.com> Archived-At: Cc: WG/IANAPLAN , iesg@ietf.org, "iucg@ietf.org" Subject: [iucg] Response to my IANAPLAN Draft appeal. X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 21:32:19 -0000 --=====================_862391045==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear IAB Members, I have read your response to my appeal. Be sure that I understand the difficulty you faced and I wish to thank Ted Hardy for his work. I will analyze it with great care over next two months, as he expected it. Please note that this is not to waste time. It is actually to save some future time. One has to give time to the stakeholders to stay abreast of the situation as the IETF Chair Jari Arkko's blog has shown yesterday. The IESG/IAB appeal process is now finished. It concludes that the RFC 2026 process has been rigorously respected. It implies that it was able to provoke questions that could and still can be pertinently discussed at the WG/IANAPLAN, but that the IETF process cannot authoritatively address. I, therefore, understand that I must look for authoritative responses to these pertinent and urgent questions: 1) either in understanding and fixing the reasons for this inability - at least for the LIBRE RFC 6852 Global Community I documented in my appeal; 2) and/or, - along RFC 6852, in obtaining them from markets. - along RFC 2026, in trying to ask for them from the ISOC Chair. - along this essential component of the Internet vitality that is responsible experimentation. My intent is to explore these four venues. As explained before, this includes the "FL" (Free/LIBRE) DNS CLASS testing. This will be an RFC 6852 global community experimentation that will adhere to the "Experimentation" section of the ICANN Internet Coordination Policy statement number 3 (quoted below). This is the way I proceeded in 2003/2004 when I conducted the "dot-root" community test-bed. I am certainly willing to coordinate and/or discuss this testing with you and ICANN, as I expect it to provide, potentially everyone, with experience in cooperation/competition operational and normative relations between RFC 6852 Global Communities (such as ICANN and the LIBRE Global Community). Best regards, jfc morfin ICANN ICP/3 Experimentation section the LIBRE GC adheres to. Experimentation has always been an essential component of the Internet's vitality. Working within the system does not preclude experimentation, including experimentation with alternate DNS roots. But these activities must be done responsibly, in a manner that does not disrupt the ongoing activities of others and that is managed according to experimental protocols. DNS experiments should be encouraged. Experiments, however, almost by definition have certain characteristics to avoid harm: (a) they are clearly labeled as experiments, (b) it is well understood that these experiments may end without establishing any prior claims on future directions, (c) they are appropriately coordinated within a community-based framework (such as the IETF), and (d) the experimenters commit to adapt to consensus-based standards when they emerge through the ICANN and other community-based processes. This is very different from launching commercial enterprises that lull users into a sense of permanence without any sense of the foregoing obligations or contingencies. Moreover, it is essential that experimental operations involving alternate DNS roots be conducted in a controlled manner, so that they do not adversely affect those who have not consented to participate in them. Given the design of the DNS, and particularly the intermediate-host and cache poisoning issues described in Section 1 above, special care must be taken to insulate the DNS from the alternate root's effects. For example, alternate roots are commonly operated by large organizations within their private networks without harmful effects, since care is taken to prevent the flow of the alternate resource records onto the public Internet. It should be noted that the original design of the DNS provides a facility for future extensions that accommodates the possibility of safely deploying multiple roots on the public Internet for experimental and other purposes. As noted in RFC 1034, the DNS includes a "class" tag on each resource record, which allows resource records of different classes to be distinguished even though they are commingled on the public Internet. For resource records within the authoritative root-server system, this class tag is set to "IN"; other values have been standardized for particular uses, including 255 possible values designated for "private use" that are particularly suited to experimentation.10 As described in a recent proposal within the IETF,11 this "class" facility allows an alternate DNS namespace to be operated from different root servers in a manner that does not interfere with the stable operation of the existing authoritative root-server system. To take advantage of this facility, it should be noted, requires the use of client or applications software developed for the alternate namespace (presumably deployed after responsible testing), rather than the existing software that has been developed to interoperate with the authoritative root. Those who operate alternate roots for global commercial purposes, however, have not followed this course. In an ever-evolving Internet, ultimately there may be better architectures for getting the job done where the need for a single, authoritative root will not be an issue. But that is not the case today. And the transition to such an architecture, should it emerge, would require community-based approaches. In the interim, responsible experimentation should be encouraged, but it should not be done in a manner that affects those who do not consent after being informed of the character of the experiment. --=====================_862391045==.ALT Content-Type: text/html; charset="us-ascii" Dear IAB Members,

I have read your response to my appeal. Be sure that I understand the difficulty you faced and I wish to thank Ted Hardy for his work. I will analyze it with great care over next two months, as he expected it.

Please note that this is not to waste time. It is actually to save some future time. One has to give time to the stakeholders to stay abreast of the situation as the IETF Chair Jari Arkko's blog has shown yesterday.

The IESG/IAB appeal process is now finished. It concludes that the RFC 2026 process has been rigorously respected. It implies that it was able to provoke questions that could and still can be pertinently discussed at the WG/IANAPLAN, but that the IETF process cannot authoritatively address.

I, therefore, understand that I must look for authoritative responses to these pertinent and urgent questions:

1) either in understanding and fixing the reasons for this inability - at least for the LIBRE RFC 6852 Global Community I documented in my appeal;

2) and/or,

- along RFC 6852, in obtaining them from markets.
- along RFC 2026, in trying to ask for them from the ISOC Chair.
- along this essential component of the Internet vitality that is responsible experimentation.

My intent is to explore these four venues. As explained before, this includes the "FL" (Free/LIBRE) DNS CLASS testing. This will be an RFC 6852 global community experimentation that will adhere to the "Experimentation" section of the ICANN Internet Coordination Policy statement number 3 (quoted below). This is the way I proceeded in 2003/2004 when I conducted the "dot-root" community test-bed.

I am certainly willing to coordinate and/or discuss this testing with you and ICANN, as I expect it to provide, potentially everyone, with experience in cooperation/competition operational and normative relations between RFC 6852 Global Communities (such as ICANN and the LIBRE Global Community).

Best regards,
jfc morfin


<quote>

ICANN ICP/3 Experimentation section the LIBRE GC adheres to.

Experimentation has always been an essential component of the Internet's vitality. Working within the system does not preclude experimentation, including experimentation with alternate DNS roots. But these activities must be done responsibly, in a manner that does not disrupt the ongoing activities of others and that is managed according to experimental protocols.

DNS experiments should be encouraged. Experiments, however, almost by definition have certain characteristics to avoid harm: (a) they are clearly labeled as experiments, (b) it is well understood that these experiments may end without establishing any prior claims on future directions, (c) they are appropriately coordinated within a community-based framework (such as < http://www.ietf.org>the IETF), and (d) the experimenters commit to adapt to consensus-based standards when they emerge through the ICANN and other community-based processes. This is very different from launching commercial enterprises that lull users into a sense of permanence without any sense of the foregoing obligations or contingencies.

Moreover, it is essential that experimental operations involving alternate DNS roots be conducted in a controlled manner, so that they do not adversely affect those who have not consented to participate in them. Given the design of the DNS, and particularly the intermediate-host and cache poisoning issues described in Section 1 above, special care must be taken to insulate the DNS from the alternate root's effects. For example, alternate roots are commonly operated by large organizations within their private networks without harmful effects, since care is taken to prevent the flow of the alternate resource records onto the public Internet.

It should be noted that the original design of the DNS provides a facility for future extensions that accommodates the possibility of safely deploying multiple roots on the public Internet for experimental and other purposes. As noted in < http://www.rfc-editor.org/rfc/rfc1034.txt>RFC 1034, the DNS includes a "class" tag on each resource record, which allows resource records of different classes to be distinguished even though they are commingled on the public Internet. For resource records within the authoritative root-server system, this class tag is set to "IN"; other values have been standardized for particular uses, including 255 possible values designated for "private use" that are particularly suited to experimentation.10

As described in a recent proposal within the IETF,11 this "class" facility allows an alternate DNS namespace to be operated from different root servers in a manner that does not interfere with the stable operation of the existing authoritative root-server system. To take advantage of this facility, it should be noted, requires the use of client or applications software developed for the alternate namespace (presumably deployed after responsible testing), rather than the existing software that has been developed to interoperate with the authoritative root. Those who operate alternate roots for global commercial purposes, however, have not followed this course.

In an ever-evolving Internet, ultimately there may be better architectures for getting the job done where the need for a single, authoritative root will not be an issue. But that is not the case today. And the transition to such an architecture, should it emerge, would require community-based approaches. In the interim, responsible experimentation should be encouraged, but it should not be done in a manner that affects those who do not consent after being informed of the character of the experiment.

<unquote> --=====================_862391045==.ALT-- From nobody Thu Jul 9 15:13:11 2015 Return-Path: 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 97D941A1AE6; Thu, 9 Jul 2015 15:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham 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 Y-burJIwfUXO; Thu, 9 Jul 2015 15:13:06 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id C72BE1A1AB3; Thu, 9 Jul 2015 15:13:06 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 379E910370; Thu, 9 Jul 2015 22:13:05 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LbQ-kT-gzCy; Thu, 9 Jul 2015 22:13:04 +0000 (UTC) Received: from mx2.yitter.info (c-50-169-68-91.hsd1.nh.comcast.net [50.169.68.91]) by mx2.yitter.info (Postfix) with ESMTPSA id 0872910012; Thu, 9 Jul 2015 22:13:03 +0000 (UTC) Date: Thu, 9 Jul 2015 18:13:02 -0400 From: Andrew Sullivan To: Jefsey Message-ID: <20150709221302.GS558@mx2.yitter.info> References: <20150709213216.D420D1A03D5@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20150709213216.D420D1A03D5@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: WG/IANAPLAN , "iucg@ietf.org" Subject: Re: [iucg] Response to my IANAPLAN Draft appeal. X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 22:13:08 -0000 [cc:s trimmed] Hi, Just two things. On Thu, Jul 09, 2015 at 11:31:50PM +0200, Jefsey wrote: > The IESG/IAB appeal process is now finished. It concludes that the RFC 2026 > process has been rigorously respected. […] > - along RFC 2026, in trying to ask for them from the ISOC Chair. I cannot tell whether in the first pair of sentences, the "It concludes" means that the appeals conclude that, but that you don't agree; or whether you mean that the appeal process having gone the way it did, that conclusion shows that the RFC 2026 process has been rigorously respected. If the latter, then you can't ask anything from ISOC, because appeal to the ISOC BoT (not the Chair, note) of an IAB decision is only permitted on procedural grounds. This is the distinction between sections 6.5.1 and 6.5.2, and section 6.5.3, of RFC 2026. I imagine you know that, but I just wanted to remind everyone. > includes the "FL" (Free/LIBRE) DNS CLASS testing. This will be an RFC 6852 > global community experimentation that will adhere to the "Experimentation" > section of the ICANN Internet Coordination Policy statement number 3 (quoted > below). This is the way I proceeded in 2003/2004 when I conducted the > "dot-root" community test-bed. > > I am certainly willing to coordinate and/or discuss this testing with you > and ICANN, as I expect it to provide, potentially everyone, with experience > in cooperation/competition operational and normative relations between RFC > 6852 Global Communities (such as ICANN and the LIBRE Global Community). I note that http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2 includes a range of CLASS values, from 65280-65534, that are reserved for private use. This was defined in RFC 6895. If you perform an experiment, I urge you to use those class values, which will relieve you of the requirement to do any co-ordinating with anyone outside your experiment group. I will also observe that I think DNSOP would very much appreciate data from your experiment regarding how DNAME and CNAME work under it, ideally in a parallel namespace (as is claimed to be expected by STD 13, anyway). Best regards, A PS: not only am I speaking for myself, but I also recused myself from the appeal consideration because of my previous role in handling the document. -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jul 10 08:24:30 2015 Return-Path: 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 A40371AD49D for ; Fri, 10 Jul 2015 08:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.335 X-Spam-Level: ** X-Spam-Status: No, score=2.335 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 3hm9WbUtnTnr for ; Fri, 10 Jul 2015 08:24:26 -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 3E2021A92B7 for ; Fri, 10 Jul 2015 08:24:26 -0700 (PDT) Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:24371 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from ) id 1ZDaA3-0000Tp-IL; Fri, 10 Jul 2015 08:24:24 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 10 Jul 2015 17:24:01 +0200 To: "discuss@0net.org List" From: Jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_926721989==.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 - 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: Message-Id: <20150710152426.3E2021A92B7@ietfa.amsl.com> Archived-At: Cc: "comptoir@cafedu.com" , "iucg@ietf.org" Subject: [iucg] AFFRANCHIS ! pas encore LIBRE mais pas loin X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 15:24:29 -0000 --=====================_926721989==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit L'IAB a répondu de façon très correcte à mon appel. https://www.iab.org/wp-content/IAB-uploads/2015/06/20150622-IANAPLAN-Appeal-IAB.pdf https://www.iab.org/appeals/2015-2/response-draft-ietf-ianaplan-icg-response/ Il est nécessaire de donner un peu de temps de pensée à cette réponse qui marque dans le contexte de l'Internet l'abdication de la souveraineté de la réalité technique face à la souveraineté des économistes commerciaux. Et donc l'affranchissement de ceux qui ne la reconnaissent pas. ---- Je reconnais que c'est compliqué à suivre parce que nous avions à prendre le problème en compte par son milieu : notre point d'entrée était la conduite des intérêts industriels dominants. Lla position prise par l'IAB nous en affranchit. Cela permet de simplifier grandement les choses en raisonnant objectivement, c'est-à-dire de l'extérieur, à partir tout simplement de ce que veut dire ce que disent ceux qui ont autorité. Pour ne pas se planter, il faut toutefois le vérifier avec attention. Je recense trois pôles d'autorité : · Autorité de facto (monopole radical actuel) : ICANN/WEF - sur la prise en main politique de l'Internet (majuscule : réseau de l'I*Core) avec vues cachées sur le Catenet · Autorité de compétence technique : IAB - connaissance de l'architecture internet (minuscule : la technologie) incertaine sur le Catenet · Autorité pratique (mal informée) : chacun de nous, les copropriétaires du Catenet. ---- La transition actuelle consiste à transférer l'autorité exécutive du NTIA /IAB (politico-technique) au tandem ICANN/WEF soutenu par l'IAB (où reste l'autorité de compétence pour l'internet) et les RIR, sans permettre l'émergence d'une autorité d'opportunité, actuellement diffuse, dans l'espace {Catenet – Internet} : ce qui du Catenet n'est pas utilisé par l'Internet – en fort accroissement réel et potentiel. Ceci marque le retour de l'IAB à sa mission première d' « Internet Advisory Board ». Jusqu'à cette clarification de sa propre nature par l'IAB, la compréhension de ce que pouvait être cette nouvelle autorité d'opportunité était en attente. Elle est maintenant possible. Il convient d'en engager l'agorèse, c'est-à-dire la synthèse maillée de ce qu'elle est, doit et peut être.. Pourquoi est-ce que je parle ici encore d'agora ? Parce que c'est très précisément la clé du problème que nous sommes tous en train de discuter, partout. Le remplacement d'un système de décision finalisé par un système de décision émergent : l'agora ne se reconnait plus dans les votes du bouleutêrion, même rebaptisés "consensus approché en multipartieprenance". Que dit exactement l'IAB? L'auteur est Ted Hardie, Directeur exécutif de l'IAB. Il reconnait les principes de la RFC 6852 (OpenStand, le paradigme de standardisation moderne par l'IEEE, IETF, IAB, ISOC, W3C). Il reconnait correctement que mon point (pour l'IETF) est l'inadéquation de son processus de standardisation par rough consensus technique dans un cas concernant la manière d'appliquer ces principes. Sa réponse est que, dans le cadre de son autorité d'appel qui est de savoir si les processus ont été respectés, l'IAB pense le contraire, car il s'agit d'une orientation "informationnelle". Pour bien comprendre ce que Ted entend par là, il faut se souvenir que l'IETF se gère elle-même à travers des RFC de bonnes pratiques communes au statut "informationnel". Ted est donc tout à fait dans son rôle et en tient le discours correct. Nous sommes donc bien dans une impasse loyale. Toutefois, il ajoute "il existe des possibilités de modification de la RFC 2026, si un consensus émergeait pour le faire", et me fait un appel du pied en indiquant que je ne prétends pas qu'il y ait un tel consensus. Ce qui est tout à fait exact : il n'y a pas ce consensus et je n'en évoque pas la possibilité. Mais lui ouvre la porte en le faisant. Nous sommes donc parfaitement d'accord sur la suite. Il s'agit maintenant de rechercher l'existence ou/et l'émergence d'un tel consensus. La suite IETF La suite est engagée de façon apparemment contradictoire par Ted Hardie. 1. dans un mail récent, il avait très bien compris que je jouais à la fois la montée de l'appel vers l'ISOC et la prise de temps maximum pour le faire afin de donner le plus de temps au temps (la date butoir pour que tout soit légalement bouclé est celle du Caucus de l'Iowa, le 20 février : après rien ne passera au Congrès). L'ISOC est en effet l'ultime recours pour ce qui n'est ni décisionnel ni informationnel, c'est à dire structurel. 2. il suggère de continuer à utiliser la procédure informationnelle qui dispose de la plateforme du groupe de travail, bien qu'il ait confirmé les limites. Ce WG peut donc discuter de façon pertinente de sujets que l'IAB ne peut trancher. De façon pratique l'IETF offre donc deux options : · Chercher à susciter l'émergence d'un consensus au sein de l'IETF pour la création d'un chemin ("stream") de RFC concernant ses aspects structurels et, en suite, un WG sur la souveraineté technique ultime de la réalité technique. Selon l'adage de Lessig, « la constitution est dans le Code Source » · Poursuivre mon appel au niveau de l'ISOC. Je vais suivre ces deux pistes pour les apports et liens qu'elles peuvent receler, pour bien asseoir la légitimité et la loyauté de la démarche et les habituer à dialoguer avec ce que j'ai appelé le « LIBRE » c'est-à-dire la strate des relationnels (meshware) libres de toute contrainte, même vis-à-vis du Libre. Toutefois cela a de bonnes chances de ne rien conclure : · je ne suis pas le porteur idéal d'une recherche de consensus IETF : ce que j'ai pu obtenir l'a plus été en les unissant contre ma reprise déguisée de leurs mauvaises demandes) mais je vais essayer. · L'appel à l'ISOC sera surtout pour l'histoire (ce sera le premier) pour voir où veut vraiment aller le Département d'Etat (l'opération est guidée par un cabinet de conseil qu'ils ont adjoint à l'ISOC). La suite externe La suite porteuse sera donc plus, · comme dans le cas de MAAYA (réseau pour la diversité linguistique qui se préoccupe du jeu de protocoles intercérébraux naturels que sont les langues) lui aussi confronté à la convergence cérébrique de la singularité technologique (intégration la couche OSI six « présentation » et de ses possibilités dans l'internet) · comme pour toutes les autres grandes évolutions de l'écosystème digital, d'en ressortir à la catalyse d'un travail d'expérimentation localisé qui sera naturellement globalement filtrée positivement ou négativement par la viralité du réseau. But Le but est alors · une consensualité en omnipartieprenance au sein d'un projet repartant architectoniquement de la base. · Si possible en bonnes relations avec les autres "communautés globales" et leurs leaders (ICANN, BRICS, EU, USCC/NSA, etc.) et pour cela se mettant structurellement à leur diapason - la relation avec la communauté NTIA/IAB était l'IAB, avec le glissement ICANN/WEF on découvrira avec le successeur de Fadi Chehade. C'est le propos de la SCIC. Le catenet avec ses composants de cérébrique naturelle (nos cerveaux) et artificielle (nos machines) sans plus se préoccuper des détails locaux aux uns ou aux autres aussi puissants ou radicalement monopolistiques soient ils. S'applique la métaphore de la petite cuiller qui creuse le barrage et compte sur la force accumulée de la rivière des utilisateurs bloqués. Mise en pratique J'ai pris acte de tout ceci auprès de l'AIB, IESG et du WG, indiquant mon intention de suivre les indications reçues pour obtenir les réponses à mes questions que l'IESG et l'IAB ne pouvaient pas donner et de lancer l'expérimentation que j'avais annoncée d'une CLASS DNS « FL » (Free/LIBRE), dans les conditions d'expérimentation communautaires sur le DNS définies dans le document de politique permanente de l'ICANN. NB. : Dans le cadre de cette expérimentation nous mettrons plus particulièrement les suffixes : · .lib pour les services et solutions libres d'intérêt collectif · .sys pour les solutions systémiques · .acad pour les sources académiques · .lin pour les aspects linguistiques et multilinguistiques Ce banc-test sera mis en place par mon association INTLNET et le projet de SCIC : « Compagnie pour la Cooperance du Catenet Commun (4Cs « the 4Cs be with you ») --=====================_926721989==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit L'IAB a répondu de façon très correcte à mon appel.
https://www.iab.org/wp-content/IAB-uploads/2015/06/20150622-IANAPLAN-Appeal-IAB.pdf
https://www.iab.org/appeals/2015-2/response-draft-ietf-ianaplan-icg-response/

Il est nécessaire de donner un peu de temps de pensée à cette réponse qui marque dans le contexte de l'Internet l'abdication de la souveraineté de la réalité technique face à la souveraineté des économistes commerciaux.
 
Et donc l’affranchissement de ceux qui ne la reconnaissent pas.

----

Je reconnais que c'est compliqué à suivre parce que nous avions à prendre le problème en compte par son  milieu : notre point d’entrée était la conduite des intérêts industriels dominants. Lla position prise par l'IAB nous en affranchit. Cela permet de simplifier grandement les choses en raisonnant objectivement, c'est-à-dire de l'extérieur, à partir tout simplement de ce que veut dire ce que disent ceux qui ont autorité.

Pour ne pas se planter, il faut toutefois le vérifier avec attention.

Je recense trois pôles d'autorité :
 
·       Autorité de facto (monopole radical actuel) : ICANN/WEF - sur la prise en main politique de l'Internet (majuscule : réseau de l'I*Core) avec vues cachées sur le Catenet
 
·       Autorité de compétence technique : IAB - connaissance de l'architecture internet (minuscule : la technologie) incertaine sur le Catenet
 
·       Autorité pratique (mal informée) : chacun de nous, les copropriétaires du Catenet.
 
----

La transition actuelle consiste à transférer l'autorité exécutive du NTIA /IAB (politico-technique) au tandem ICANN/WEF soutenu par l'IAB (où reste l'autorité de compétence pour l'internet) et les RIR, sans permettre l'émergence d'une autorité d'opportunité, actuellement diffuse, dans l'espace {Catenet – Internet} : ce qui du Catenet n’est pas utilisé par l’Internet – en fort accroissement réel et potentiel.
 
Ceci marque le retour de l’IAB à sa mission première d’ « Internet Advisory Board ».

Jusqu'à cette clarification de sa propre nature par l'IAB, la compréhension de ce que pouvait être cette nouvelle autorité d'opportunité était en attente. Elle est maintenant possible. Il convient  d'en engager l'agorèse, c'est-à-dire la synthèse maillée de ce qu’elle est, doit et peut être..

Pourquoi est-ce que je parle ici encore d'agora ? Parce que c'est très précisément la clé du problème que nous sommes tous en train de discuter, partout. Le remplacement d'un système de décision finalisé par un système de décision émergent : l'agora ne se reconnait plus dans les votes du bouleutêrion, même rebaptisés "consensus approché en multipartieprenance".
 

Que dit exactement l'IAB?

L'auteur est Ted Hardie, Directeur exécutif de l'IAB. Il reconnait les principes de la RFC 6852 (OpenStand, le paradigme de standardisation moderne par l’IEEE, IETF, IAB, ISOC, W3C). Il reconnait correctement que mon point (pour l’IETF) est l'inadéquation de son processus de standardisation par rough consensus technique dans un cas concernant la manière d'appliquer ces principes.
 
Sa réponse est que, dans le cadre de son autorité d'appel qui est de savoir si les processus ont été respectés, l'IAB pense le contraire, car il s'agit d'une orientation "informationnelle".

Pour bien comprendre ce que Ted entend par là, il faut se souvenir que l'IETF se gère elle-même à travers des RFC de bonnes pratiques communes au statut "informationnel". Ted est donc tout à fait dans son rôle et en tient le discours correct. Nous sommes donc bien dans une impasse loyale.

Toutefois, il ajoute "il existe des possibilités de modification de la RFC 2026, si un consensus émergeait pour le faire", et me fait un appel du pied en indiquant que je ne prétends pas qu'il y ait un tel consensus. Ce qui est tout à fait exact : il n’y a pas ce consensus et je n’en évoque pas la possibilité. Mais lui ouvre la porte en le faisant.

Nous sommes donc parfaitement d'accord sur la suite. Il s'agit maintenant de rechercher l'existence ou/et l’émergence d'un tel consensus.


La suite IETF

La suite est engagée de façon apparemment contradictoire par Ted Hardie.

1. dans un mail récent, il avait très bien compris que je jouais à la fois la montée de l'appel vers l'ISOC et la prise de temps maximum pour le faire afin de donner le plus de temps au temps (la date butoir pour que tout soit légalement bouclé est celle du Caucus de l'Iowa, le 20 février : après rien ne passera au Congrès). L'ISOC est en effet l'ultime recours pour ce qui n'est ni décisionnel ni informationnel, c'est à dire structurel.

2. il suggère de continuer à utiliser la procédure informationnelle qui dispose de la plateforme du groupe de travail, bien qu’il ait confirmé les limites. Ce WG peut donc discuter de façon pertinente de sujets que l'IAB ne peut trancher.
 
De façon pratique l’IETF offre donc deux options :

·       Chercher à susciter l'émergence d'un consensus au sein de l'IETF pour la création d’un chemin ("stream") de RFC concernant ses aspects structurels et, en suite, un WG sur la souveraineté technique ultime de la réalité technique. Selon l’adage de Lessig, « la constitution est dans le Code Source »
 
·       Poursuivre mon appel au niveau de l'ISOC.

Je vais suivre ces deux pistes pour les apports et liens qu'elles peuvent receler, pour bien asseoir la légitimité et la loyauté de la démarche et les habituer à dialoguer avec ce que j’ai appelé le « LIBRE » c'est-à-dire la strate des relationnels (meshware) libres de toute contrainte, même vis-à-vis du Libre.

Toutefois cela a de bonnes chances de ne rien conclure :
 
·       je ne suis pas le porteur idéal d’une recherche de consensus IETF : ce que j'ai pu obtenir l'a plus été en les unissant contre ma reprise déguisée de leurs mauvaises demandes) mais je vais essayer.
·       L'appel à l'ISOC sera surtout pour l'histoire (ce sera le premier) pour voir où veut vraiment aller le Département d'Etat (l'opération est guidée par un cabinet de conseil qu’ils ont adjoint à l'ISOC).

 
La suite externe

La suite porteuse sera donc plus,
 
·       comme dans le cas de MAAYA (réseau pour la diversité linguistique qui se préoccupe du jeu de protocoles  intercérébraux naturels que sont les langues) lui aussi confronté à la convergence cérébrique de la singularité technologique (intégration la couche OSI six « présentation » et de ses possibilités dans l’internet)
 
·       comme pour toutes les autres grandes évolutions de l'écosystème digital,
 
d'en ressortir à la catalyse d'un travail d'expérimentation localisé qui sera naturellement globalement filtrée positivement ou négativement par la viralité du réseau.

But

Le but est alors
 
·       une consensualité en omnipartieprenance au sein d'un projet repartant architectoniquement de la base.
 
·       Si possible en bonnes relations avec les autres "communautés globales" et leurs leaders (ICANN, BRICS, EU, USCC/NSA, etc.) et pour cela se mettant structurellement à leur diapason - la relation avec la communauté NTIA/IAB était l'IAB, avec le glissement ICANN/WEF on découvrira avec le successeur de Fadi Chehade.
 
C'est le propos de la SCIC. Le catenet avec ses composants de cérébrique naturelle (nos cerveaux) et artificielle (nos machines) sans plus se préoccuper des détails locaux aux uns ou aux autres aussi puissants ou radicalement monopolistiques soient ils. S’applique la métaphore de la petite cuiller qui creuse le barrage et compte sur la force accumulée de la rivière des utilisateurs bloqués.
 
 
Mise en pratique
 
J’ai pris acte de tout ceci auprès de l’AIB, IESG et du WG, indiquant mon intention de suivre les indications reçues pour obtenir les réponses à mes questions que l’IESG et l’IAB ne pouvaient pas donner et de lancer l’expérimentation que j’avais annoncée d’une CLASS DNS « FL » (Free/LIBRE), dans les conditions d’expérimentation communautaires sur le DNS définies dans le document de politique permanente de l’ICANN.
 
 
NB. : Dans le cadre de cette expérimentation nous mettrons plus particulièrement  les suffixes :
 
·       .lib pour les services et solutions libres d’intérêt collectif
·       .sys pour les solutions systémiques
·       .acad pour les sources académiques 
·       .lin pour les aspects linguistiques et multilinguistiques
 
Ce banc-test sera mis en place par mon association INTLNET et le projet de SCIC : « Compagnie pour la Cooperance du Catenet Commun (4Cs « the 4Cs be with you »)
--=====================_926721989==.ALT-- From nobody Fri Jul 17 01:44:12 2015 Return-Path: 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 EF4C11B31B3; Fri, 17 Jul 2015 01:44:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 nzUVpTYFihb6; Fri, 17 Jul 2015 01:44:06 -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 193801B31B2; Fri, 17 Jul 2015 01:44:06 -0700 (PDT) Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:19413 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from ) id 1ZG1FT-0008Mm-Sv; Fri, 17 Jul 2015 01:44:04 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jul 2015 10:43:58 +0200 To: Andrew Sullivan , "Ianaplan@Ietf.org" From: Jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_550851511==.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 - 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: Message-Id: <20150717084406.193801B31B2@ietfa.amsl.com> Archived-At: Cc: gene@wilibre.net, "iucg@ietf.org" Subject: [iucg] response to your questions X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jul 2015 08:44:10 -0000 --=====================_550851511==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit Hi! Andrew, I apologize for the late response. I wanted it to be comprehensive and had a few things to address before. >At 00:13 10/07/2015, Andrew Sullivan wrote: >Hi, >Just two things. > >On Thu, Jul 09, 2015 at 11:31:50PM +0200, Jefsey wrote: > > The IESG/IAB appeal process is now finished. It concludes that the RFC 2026 > > process has been rigorously respected. >[] > > - along RFC 2026, in trying to ask for them from the ISOC Chair. > >I cannot tell whether in the first pair of sentences, the "It >concludes" means that the appeals conclude that, but that you don't >agree; Correct. See below. >or whether you mean that the appeal process having gone the way >it did, that conclusion shows that the RFC 2026 process has been >rigorously respected. The IAB thinks the RFC 2026 process has been respected. I think it did not work: otherwise, the IAB conclusions would have addressed my questions, either in responding to them or in denying their pertinence. The reason why is that you and me do not consider the RFC 2026 process at the same level. 1. IAB looks at the respect of the letter of the RFC 2026 process, I think the RFC 2026 itself is "inadequate or insufficent to the protection of the rights of all parties in a fair and open Internet Standards Process." 2. I have not made up my mind as to why. Is this due to the particular case at hand or is it for new reasons resulting from the new situation in which the IETF now is? >If the latter, then you can't ask anything from >ISOC, because appeal to the ISOC BoT (not the Chair, note) of an IAB >decision is only permitted on procedural grounds. This is the >distinction between sections 6.5.1 and 6.5.2, and section 6.5.3, of >RFC 2026. I imagine you know that, but I just wanted to remind >everyone. It seems that we may not have the same reading of the RFC 2026 sentence that I refer to. Anyway, the point is important because this is a case of conflict between the RFC 6852 principles, the RFC 3935 documented IETF mission and the position irt. NTIA and ICANN accepted by the Draft and now consistently documented by the IETF Chair and by IAB. We are in the case why I objected RFC 6852, the case it has not addressed. How to resolve/clarify an intercommunity technical/political inconsistency. Roughly, there is no longer any moral/political/"formal" (the word is from RFC 6852) authority claim over the use of the catenet by the different technologies designed by the different global communities (that want to use it along the requirements of their markets). We are in the multistakeholder configuration: the evaluation of my RFC 6852 global community differs from your RFC 6852 global community evaluation. This seems to be for three reasons: 1. the IAB has relinquished its authority over ICANN (through the IANA) giving up a historical claim of leadership over the TCP/IP architecture. 2. In addition, the IETF/IAB has limited itself this authority over its technology in accepting to become the ICANN RFC 6852 Global Community architectural/technological pole of expertise – other RFC 6852 Global Communities can compete/coopete/concert with. 3. However, the IETF has helped me identify the wide and widely informal LIBRE RFC 6852 global community through the iucg@ietf.org mailing list. I have not invested enough in the formalization of such a "WI-LIBRE" global community so it might adequately contribute. This is something I should do both politically (hence an appeal at the peer level with ISOC) and technically (hence the analysis, R&D and testing of a catenet partner architecture - that might adequately support and contribute to the different networking architectures a member of the digital ecosystem may have to master). Since (again this was the reason for my appeal last year) RFC 6852 has not foreseen any technical conflict resolution/clarification mechanism between those adhering to its principles, we are left in a limbo situation. My appeal to ISOC should help to understand if (and what) the Internet Community and the State Department have foreseen should the case arise. If ISOC were to decline to answer my appeal, it would only mean that the US has chosen not to politically interfere anymore in my business. This is big news to me after they fired me 30 years ago! > > includes the "FL" (Free/LIBRE) DNS CLASS testing. This will be an RFC 6852 > > global community experimentation that will adhere to the "Experimentation" > > section of the ICANN Internet Coordination Policy statement > number 3 (quoted > > below). This is the way I proceeded in 2003/2004 when I conducted the > > "dot-root" community test-bed. > > > > I am certainly willing to coordinate and/or discuss this testing with you > > and ICANN, as I expect it to provide, potentially everyone, with experience > > in cooperation/competition operational and normative relations between RFC > > 6852 Global Communities (such as ICANN and the LIBRE Global Community). > >I note that >http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2 >includes a range of CLASS values, from 65280-65534, that are reserved >for private use. This was defined in RFC 6895. If you perform an >experiment, I urge you to use those class values, which will relieve >you of the requirement to do any co-ordinating with anyone outside >your experiment group. At this still no-home-root proliferation time, this is certainly my only intent. But this situation will not be sustainable, as a positive outcome will most probably result in three kinds of root files approaches: - the "Global Community" (like the "IN" IcanN) ones. This is something our "WI-LIBRE" (let us call it this for clarity purposes) community will certainly target. - the "VGN" (virtual glocal network) ones, maintained by a VGNIC – sorry, these are WILIBRE basic concepts. - the personal ones: informed users (IUsers) will maintain their own glocal root by themselves with the help of specialized tools. >I will also observe that I think DNSOP would >very much appreciate data from your experiment regarding how DNAME and >CNAME work under it, ideally in a parallel namespace (as is claimed to >be expected by STD 13, anyway). Certainly. The intent is to document it - English speaking manpower permitting - on http://dnsa.org. Unfortunately, the way the IETF did not full-fledge document and maintain its technology (at least for the time being, in only requesting comments on a step by step basis) prevents us from participating in the DNSOP debate, by the lack of a common understanding, however few we are. Our priority is, therefore, to build a comprehensive/consistent documentation (from existing RFCs) we can use. This certainly is documentation that is necessary for the community effort that we will get checked by the DNSOP community, should they want to help. >Best regards, > >A > >PS: not only am I speaking for myself, but I also recused myself from >the appeal consideration because of my previous role in handling the >document. I fully understand and appreciate that. This is unfortunately a possibility I do not share myself for the time being. I think the best is to unravel the complication we reached since things blocked with me over RFC 923. This seems to be possible, in proceeding from the DNS core since the State-Department has also identified it as the apex of the debate (it is also where TMs, languages and people direct use are bound to the technology). It could be technically hacked in a few days. However, what we want to really test is wider: - the ability of average informed users to understand it. - hence the documentation we should produce. - probably the various software tools involved on the user and operator sides. This is much more demanding. Please also note that (in addition to the IUsers) we are to expect at least two kinds of operators: 1. the NIC that produces a root and coordinates with TLD managers. 2. the Ledger operator that will support one or several root registries and, therefore, several public CLASSes. You will, therefore, understand that I will take my time. Moreover, I am currently focusing on the multi/mecalinguistic issues of all this, the local and global catenet oriented citizen use and management as well as the discussion of that "WI-LIBRE" global community and corresponding license (such a community over networking issues must also be free from the Free Software limitations: everyone must be openly interconnectable, supported and protected). My capacity and target is only to spark catalysis. This seems to be feasible because I eventually understood that the whole industry, NSA, I*Core strategy over the last 30 years was based upon the BUG bug (trying to Be Unilaterally Global) transformed into a temporary feature by the NTIA oversight/tutorship replacing the ITU multilateral proposition, itself in parallel with the initial "advanced communication technology" (ACT) (everyone being to be supported) architecture I had access to and deployed. In its own way, the NTIA has also identified this situation. My priority is, therefore, not anymore to try to prevent the IETF from conflicting with future common interests. My simpler target is only to technically, intellectually, legally etc. correct the BUG. If it is correct, at its own pace, my fix will proceed on its own. The only real problem left is that we are in a real-time political, economic context. So, I must take care to not poorly interfer with the evangelization, consolidation, and experimentations I need. This is why I think the ICANN/ICP-3 Experimentation Section makes good guidelines. I would certainly be interested in some improvements: I started working some years ago on an extensions based on a Brian Carpenter's I_D on technical precautions. jfc --=====================_550851511==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Hi! Andrew,
I apologize for the late response. I wanted it to be comprehensive and had a few things to address before.

At 00:13 10/07/2015, Andrew Sullivan wrote:
Hi,
Just two things. 

On Thu, Jul 09, 2015 at 11:31:50PM +0200, Jefsey wrote:
> The IESG/IAB appeal process is now finished. It concludes that the RFC 2026
> process has been rigorously respected.
[]
> - along RFC 2026, in trying to ask for them from the ISOC Chair.

I cannot tell whether in the first pair of sentences, the "It
concludes" means that the appeals conclude that, but that you don't
agree;

Correct. See below.


or whether you mean that the appeal process having gone the way
it did, that conclusion shows that the RFC 2026 process has been
rigorously respected.

The IAB thinks the RFC 2026 process has been respected.

I think it did not work: otherwise, the IAB conclusions would have addressed my questions, either in responding to them or in denying their pertinence. 

The reason why is that you and me do not consider the RFC 2026 process at the same level.
 
1.      IAB looks at the respect of the letter of the RFC 2026 process, I think the RFC 2026 itself is "inadequate or insufficent to the protection of the rights of all parties in a fair and open Internet Standards Process."

2.      I have not made up my mind as to why. Is this due to the particular case at hand or is it for new reasons resulting from the new situation in which the IETF now is?


If the latter, then you can't ask anything from
ISOC, because appeal to the ISOC BoT (not the Chair, note) of an IAB
decision is only permitted on procedural grounds.  This is the
distinction between sections 6.5.1 and 6.5.2, and section 6.5.3, of
RFC 2026.  I imagine you know that, but I just wanted to remind
everyone.

It seems that we may not have the same reading of the RFC 2026 sentence that I refer to.  Anyway, the point is important because this is a case of conflict between the RFC 6852 principles, the RFC 3935 documented IETF mission and the position irt. NTIA and ICANN accepted by the Draft and now consistently documented by the IETF Chair and by IAB. We are in the case why I objected  RFC 6852, the case it has not addressed. How to resolve/clarify an intercommunity technical/political inconsistency. 

Roughly, there is no longer any moral/political/”formal” (the word is from RFC 6852) authority claim over the use of the catenet by the different technologies designed by the different global communities (that want to use it along the requirements of their markets). We are in the multistakeholder configuration: the evaluation of my RFC 6852 global community differs from your RFC 6852 global community evaluation.

This seems to be for three reasons:

1. the IAB has relinquished its authority over ICANN (through the IANA) giving up a historical claim of leadership over the TCP/IP architecture.

2. In addition, the IETF/IAB has limited itself this authority over its technology in accepting to become the ICANN RFC 6852 Global Community architectural/technological pole of expertise – other RFC 6852 Global Communities can compete/coopete/concert with.

3. However, the IETF has helped me identify the wide and widely informal LIBRE RFC 6852 global community through the iucg@ietf.org mailing list. I have not invested enough in the formalization of such a “WI-LIBRE” global community so it might adequately contribute. This is something I should do both politically (hence an appeal at the peer level with ISOC) and technically (hence the analysis, R&D and testing of a catenet partner architecture - that might adequately support and contribute to the different networking architectures a member of the digital ecosystem may have to master). 

Since (again this was the reason for my appeal last year) RFC 6852 has not foreseen any technical conflict resolution/clarification mechanism between those adhering to its principles, we are left in a limbo situation. My appeal to ISOC should help to understand if (and what) the Internet Community and the State Department have foreseen should the case arise.

If ISOC were to decline to answer my appeal, it would only mean that the US has chosen not to politically interfere anymore in my business. This is big news to me after they fired me 30 years ago!


> includes the "FL" (Free/LIBRE) DNS CLASS testing. This will be an RFC 6852
> global community experimentation that will adhere to the "Experimentation"
> section of the ICANN Internet Coordination Policy statement number 3 (quoted
> below). This is the way I proceeded in 2003/2004 when I conducted the
> "dot-root" community test-bed.
>
> I am certainly willing to coordinate and/or discuss this testing with you
> and ICANN, as I expect it to provide, potentially everyone, with experience
> in cooperation/competition operational and normative relations between RFC
> 6852 Global Communities (such as ICANN and the LIBRE Global Community).

I note that
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-2
includes a range of CLASS values, from 65280-65534, that are reserved
for private use.  This was defined in RFC 6895.  If you perform an
experiment, I urge you to use those class values, which will relieve
you of the requirement to do any co-ordinating with anyone outside
your experiment group.

At this still no-home-root proliferation time, this is certainly my only intent. But this situation will not be sustainable, as a positive outcome will most probably result in three kinds of root files approaches:

- the "Global Community" (like the "IN" IcanN) ones. This is something our “WI-LIBRE” (let us call it this for clarity purposes) community will certainly target.
- the "VGN" (virtual glocal network) ones, maintained by a VGNIC – sorry, these are WILIBRE basic concepts.
- the personal ones: informed users (IUsers) will maintain their own glocal root by themselves with the help of specialized tools.


I will also observe that I think DNSOP would
very much appreciate data from your experiment regarding how DNAME and
CNAME work under it, ideally in a parallel namespace (as is claimed to
be expected by STD 13, anyway).

Certainly. The intent is to document it - English speaking manpower permitting - on http://dnsa.org. Unfortunately, the way the IETF did not full-fledge document and maintain its technology (at least for the time being, in only requesting comments on a step by step basis) prevents us from participating in the DNSOP debate, by the lack of a common understanding, however few we are.

Our priority is, therefore, to build a comprehensive/consistent documentation (from existing RFCs) we can use.  This certainly is documentation that is necessary for the community effort that we will get checked by the DNSOP community, should they want to help.


Best regards,

A

PS: not only am I speaking for myself, but I also recused myself from
the appeal consideration because of my previous role in handling the
document.


I fully understand and appreciate that. This is unfortunately a possibility I do not share myself for the time being.

I think the best is to unravel the complication we reached since things blocked with me over RFC 923. This seems to be possible, in proceeding from the DNS core since the State-Department has also identified it as the apex of the debate (it is also where TMs, languages and people direct use are bound to the technology).

It could be technically hacked in a few days. However, what we want to really test is wider:

- the ability of average informed users to understand it.
- hence the documentation we should produce.
- probably the various software tools involved on the user and operator sides.

This is much more demanding.

Please also note that (in addition to the IUsers) we are to expect at least two kinds of operators:

1. the NIC that produces a root and coordinates with TLD managers.
2. the Ledger operator that will support one or several root registries and, therefore, several public CLASSes.

You will, therefore, understand that I will take my time. Moreover, I am currently focusing on the multi/mecalinguistic issues of all this, the local and global catenet oriented citizen use and management as well as the discussion of that “WI-LIBRE” global community and corresponding license (such a community over networking issues must also be free from the Free Software limitations: everyone must be openly interconnectable, supported and protected).

My capacity and target is only to spark catalysis.

This seems to be feasible because I eventually understood that the whole industry, NSA, I*Core strategy over the last 30 years was based upon the BUG bug (trying to Be Unilaterally Global) transformed into a temporary feature by the NTIA oversight/tutorship replacing the ITU multilateral proposition, itself in parallel with the initial “advanced communication technology” (ACT) (everyone being to be supported) architecture I had access to and deployed.

In its own way, the NTIA has also identified this situation. My priority is, therefore, not anymore to try to prevent the IETF from conflicting with  future common interests. My simpler target is only to technically, intellectually, legally etc. correct the BUG. If it is correct, at its own pace, my fix will proceed on its own.

The only real problem left is that we are in a real-time political, economic context. So, I must take care to not poorly interfer with the evangelization, consolidation, and experimentations I need. This is why I think the ICANN/ICP-3 Experimentation Section makes good guidelines. I would certainly be interested in some improvements: I started working some years ago on an extensions based on a Brian Carpenter's I_D on technical precautions.

jfc
--=====================_550851511==.ALT--