From nobody Mon Mar 2 06:35: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 CEBCA1A8784; Mon, 2 Mar 2015 06:35:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 xj6T_vdPcDCS; Mon, 2 Mar 2015 06:35:09 -0800 (PST) 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 452071A8785; Mon, 2 Mar 2015 06:35:09 -0800 (PST) Received: from 114.170.199.77.rev.sfr.net ([77.199.170.114]:64005 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1YSRR5-0000rV-9k; Mon, 02 Mar 2015 06:35:07 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 02 Mar 2015 15:35:07 +0100 To: Andrew Sullivan , Brian E Carpenter From: JFC Morfin In-Reply-To: <20150301020756.GD6345@mx1.yitter.info> References: <1A71F670-BACB-485F-8F06-93720563CB9B@kitterman.com> <5D2D7FD3-B9C6-4BD3-BBEE-B2354EFC9996@nominum.com> <10863B07-6E63-470E-A9D8-67FA37A2097C@standardstrack.com> <287EAD95-42D4-449C-8A7C-E8B3A14C8C21@nominum.com> <378E7F5B-3CFB-4F7D-B174-3D58A6451A15@standardstrack.com> <20150227060834.GI9895@localhost> <54F24BFB.1040101@cis-india.org> <20150301020756.GD6345@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable 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: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Message-Id: <20150302143509.452071A8785@ietfa.amsl.com> Archived-At: Cc: John C Klensin , "diversity@ietf.org" , gene@iuwg.net, "iucg@ietf.org" , Pranesh Prakash Subject: Re: [iucg] [Diversity] 'Paywall, ' IETF self-sufficiency, increasing participation (was Re: Remote participation fees) 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: Mon, 02 Mar 2015 14:35:11 -0000 Dear Andrew and Brian, Thank you for your key inputs. At least in the way I see them. Please consider carefully the RFC 6852 current=20 paradigm. In a nutshell, it is "open=20 permissionless innovation by global community=20 economic coopetition". This is not a bad approach=20 and I understand the IETF, NTIA, ICANN, etc. are=20 progressively adapting to it (IANAPLAN). However,=20 for this to be fully effective, one has to admit that: 1. this coopetition fractally also=20 applies within each global community, etc. down=20 to the corporation, and down to individuals. This=20 is what your employer seems to have understood. This is naturally moderated= by - people's self-restriction in order to not endanger their job; - unselfishness of dedicated independent consultants - and because "as a matter of objective fact,=20 people's participation, their technical=20 perceptions, and their achievements are affected=20 by their employment. It would be delusional to=20 imagine that anything else is possible" (Brian Carpenter). 2. the IETF itself is one of these global=20 communities since there is no documented ultimate=20 technical referent, or economic referent to read=20 and evaluate the market decisions. The ISOC/IETF=20 has chosen the NTIA as its ultimate decision=20 maker (most probably meaning the FCC in the long=20 range), and ICANN seems to adopt the WEF as their=20 economic reader. All of this and many other=20 things makes the IETF system - however imperfect=20 - to be largely able to resist corporate bullying (cf. Brian Carpenter). Such a situation is acceptable in a=20 multistakeholder approach where global=20 communities are identified and mutually agreed on=20 (Edge Providers, States, ICANN, RIRs, USCC). Let=20 us say that the IETF is an RFC 6852 informal=20 default SDO for TCP/IP, mainly for the OECD/US-TPP-TAFTA industrial= community. It is not advisable in the omnistakeholder=20 multitechnology global governance context that I defend. Moreover, this implies an additional=20 problem/clarifying feature: the IETF dedication=20 to end to end TCP/IP issues, i.e. to the covering=20 of only a very large but reducing part of the=20 digital catenet's (global multitech network of=20 networks) intelligent use needs. Therefore, its=20 Internet technology is to be considered increasingly as one of the datacommunications technologies being used on the catenet and/or one of the proposal's source concerning=20 the multi-technologcal common needs. The IETF doesn=92t want to document - at least at=20 this stage - the IEN 48 second motivation's=20 intended master/fundamental catenet protocol set,=20 as we have known/used one with the=20 "NSA-over-compatible" Tymnet Protocol or even=20 with Telenet originated CCITT X.75/25. The real issue is not in practical protocol=20 issues, but rather in the whole digital=20 architectonic and multi-architectural framework,=20 societal understanding, and political governance.=20 The IETF is engaged in a consumerist scheme that=20 is different from the WSIS' =93 people centered, =E0=20 caract=E8re humain, centrada en la persona=94=20 consensus. This means that it can accept every=20 kind of diversity within that framework but it is=20 inadequate to internally discuss an alternate=20 framework. This did belong to IAB: RFC 6852 now=20 assigns the job to the market competition. All of this causes many problems. My feeling is=20 that the solution is not in an ethically divided=20 catch-all organization, but rather in a=20 harmonious sponsored SDOs coopetitive network (cf. RFC 6852 again). Where the IETF is the best, the IETF should be. For what does not belong to that IETF, new=20 structures are to be helped to emerge or=20 adapt, so that incumbents will be able to=20 welcome and help them. IMHO, the experience of=20 the WHATWG is important to consider. I tried some rendezvous between the IETF,=20 lead-users, Libre, as an IETF non-WG mailing list=20 (iucg@ietf.org). This is possibly of interest as=20 a liaison if it was widely publicized/accepted,=20 but it cannot stand alone on its own. What is=20 needed is a Libre's Google like transnational=20 corporation. Because it will be necessary for it=20 to organize an internal omnistakeholderist=20 process that can in turn play its political,=20 normative, and industrial part in the=20 multistakeholderist polylogue. This calls for=20 structure, exposure, money, and (probably=20 disruptive) adequate major industrial innovation. This is the idea behind the Catenet Cooperative=20 Corporation (CCC) project. If it succeeds it will=20 have its own normalization/standardization system=20 that will relate with the IETF within the RFC=20 6852 framework on an equal footing basis. This=20 will be because its solutions will be on an equal=20 technical footing basis via the market, as will=20 be the NDNconsortium, RINA, SDN, etc. name them, in their respective areas. For this to happen and succeed it must start as=20 the IETF did: a small group but of Libre=20 researchers this time, instead of=20 US-government-fundedones. May be some will be from the IETF. If the IETF thinks it needs a "paywall" in=20 addition to its "trollwall" system in order to=20 address its RFC 3774bis remote participation=20 issues, I see no problem with it. We all need the=20 IETF to continue being successful and consistent.=20 RFC 6852 is for everyone to liaise, as IETF does=20 with the ITU, being forced to do it by the market. My only real concerns are: - the way RFCs are presented in that they are not=20 very attractive and transparent for people who=20 did not participate in their writing. - what Brian says "I remind you that this thread=20 started around the question of how can we fund a=20 model with more emphasis on remote participation=20 and less emphasis on face-to-face meetings. It's=20 a sad fact that without money at the level of a=20 few $M per year, we can't fund any model at all".=20 The target for us users is an intelligent use of=20 our digital tools to be documented. This also=20 means a free, smart use: how could it be deemed=20 attractive for the internet to use IETF solutions=20 if using these very tools to document them would cost so much? jfc At 03:07 01/03/2015, Andrew Sullivan wrote: >On Sun, Mar 01, 2015 at 04:45:07AM +0530, Pranesh Prakash wrote:. > > It seems like a fiction because it is a fiction. > > > > Check the IETF main list where there is discussion going on about CFOs > > (Chief Financial Officers) footing the bills for participants. > > > > That doesn't sound like a person=20 > participating in their personal capacity to > > me. > >Quite apart from what John says, I'd like to know what you think >determines when someone is participating in their personal capacity. >You seem to be suggesting that the source of the funding automatically >determines what a participant does or says. > >I can tell you that my employer subsidizes participation of a number >of us in the IETF because my employer thinks the Internet is better if >the IETF is strong and full of independent voices. We do not >co-ordinate our positions. My employer does not have a view (or at >least not one it has expressed) about what I ought to interest myself >in at the IETF. The biggest problem I have ever had is juggling these >obligations (which my employer recognizes and supports) with the rest >of my day job. > >So, if you prefer to say that I'm still not acting "in my personal >capacity", very well; but I'd like to know what the difference is (in >operationalized terms, please). > >Best regards, > >A From nobody Thu Mar 5 11:07:58 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 477961A8726 for ; Thu, 5 Mar 2015 11:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.134 X-Spam-Level: * X-Spam-Status: No, score=1.134 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 ZRS8v6thppBI for ; Thu, 5 Mar 2015 11:07:56 -0800 (PST) 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 9D6DC1A8724 for ; Thu, 5 Mar 2015 11:07:56 -0800 (PST) Received: from 114.170.199.77.rev.sfr.net ([77.199.170.114]:21674 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1YTb7i-0004um-7b; Thu, 05 Mar 2015 11:07:54 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Mar 2015 20:07:46 +0100 To: Paul Hoffman ,Jari Arkko From: Jefsey In-Reply-To: <78A73ED3-BAAB-448F-A550-77F69535422B@vpnc.org> References: <20140520204238.21772.64347.idtracker@ietfa.amsl.com> <500031A0-DF45-409E-AACB-F79C32032E38@viagenie.ca> <94F2C35A-95D1-41CA-9CA5-2F7D59111E0B@vpnc.org> <78A73ED3-BAAB-448F-A550-77F69535422B@vpnc.org> 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: Message-Id: <20150305190756.9D6DC1A8724@ietfa.amsl.com> Archived-At: Cc: IAB , "iucg@ietf.org" Subject: Re: [iucg] [IAB] Last Call: (DNS Root Name Service Protocol and Deployment Requirements) to Best Current Practice 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, 05 Mar 2015 19:07:57 -0000 At 05:42 05/03/2015, Paul Hoffman wrote: >Of the ~100 DNS-related RFCs that Standcore has reviewed in the DNS >conformance testbed, RFC 1912 has the same wording about verifying >UDP checksums without saying what to do if there is a verification >failure, and 1995 has advice of what to do if the checksum is 0. >Other than that, 2870 is the only other RFC that mentions UDP checksums. The real need would be a maintained single Standcore DNS RFC. I would subscribe to it. jfc From nobody Wed Mar 11 11:03:45 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 8F94F1A1B8D; Wed, 11 Mar 2015 11:03:44 -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 dbHXrIey1QsZ; Wed, 11 Mar 2015 11:03:42 -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 2C9CD1A1B8E; Wed, 11 Mar 2015 11:03:42 -0700 (PDT) Received: from 114.170.199.77.rev.sfr.net ([77.199.170.114]:24452 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1YVkyp-00060s-T0; Wed, 11 Mar 2015 11:03:41 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 11 Mar 2015 19:03:34 +0100 To: lstrickling@ntia.doc.gov From: JFC Morfin Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_184952523==.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: <20150311180342.2C9CD1A1B8E@ietfa.amsl.com> Archived-At: Cc: ianaplan@ietf.org, IAB , "iucg@ietf.org" , iesg@ietf.org Subject: [iucg] appeal to the IESG IRT. the IETF response to ICANN concerning the NTIA IANA Transition 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: Wed, 11 Mar 2015 18:03:44 -0000 --=====================_184952523==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit The Honorable Lawrence E. Strickling Assistant Secretary for Communications & Information National Telecommunications & Information Administration United States Department of Commerce 1401 Constitution Ave., N.W. Washington, DC 20230 Saint-Vincent de Barbeyrargues, March 11, 2015 Dear Assistant Secretary Strickling, On March 14, 2014, you asked the Internet Corporation for Assigned Names and Numbers (ICANN) to convene global stakeholders to develop a proposal to transition the current role played by NTIA in the coordination of the Internet's domain name system (DNS). You also have informed ICANN that you expected that in the development of the proposal, ICANN will work collaboratively with the directly affected parties, including the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB), the Internet Society (ISOC), the Regional Internet Registries (RIRs), top level domain name operators, VeriSign, and other interested global stakeholders. Shortly after March 14, 2014, ICANN launched a multistakeholder process and discussion to gather community views and input on the principles and mechanisms for a different issue: the transitioning of NTIA's stewardship of the IANA functions. Following a month-long call for input on the community-driven draft proposal, on June 6, ICANN posted the Process to Develop the Proposal and Next Steps. Then, following a call for names, the IANA Stewardship Transition Coordination Group (ICG) was formed, comprising individuals selected by each represented community. These 30 individuals represent 13 communities of both direct and indirect stakeholders who together will deliver a proposal to the NTIA recommending a transition plan of NTIA's stewardship of IANA functions to the Internet community, consistent with the key principles that you outlined in your March 14 announcement. The ICG coordinates with 13 "communities", which are: * Address Supporting Organization (ASO) * Country Code Names Supporting Organisation (ccNSO and non-ccNSO Country Code Top-Level Domain [ccTLD] operators, as selected by the ccNSO) * Generic Names Supporting Organization (GNSO). GNSO seats from non-Registry representation * Generic Top Level Domain Registries (gTLD Registries) * Governmental Advisory Committee (GAC) * International Chamber of Commerce/ Business Action to Support the Information Society (ICC/BASIS) * Internet Architecture Board (IAB) * Internet Engineering Task Force (IETF) * Internet Society (ISOC) * Number Resource Organization (NRO) * Root Server System Advisory Committee (RSSAC) * Security and Stability Advisory Committee (SSAC) None of them represent the directly affected largest party, i.e. the lead and end users and the civil society organizations. As a part of this large and open community, a pioneer of the international network, and a member of the Libre community, I considered that my best chance to get my position heard would be through the technical community open, collective, and balanced work. Does RFC 3869 of the IAB not state? "The principal thesis of this document is that if commercial funding is the main source of funding for future Internet research, the future of the Internet infrastructure could be in trouble. In addition to issues about which projects are funded, the funding source can also affect the content of the research, for example, towards or against the development of open standards, or taking varying degrees of care about the effect of the developed protocols on the other traffic on the Internet." while the RFC 6852 from the same IAB states: "We embrace a modern paradigm for standards where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status." "In this paradigm standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally. These voluntary standards serve as building blocks for products and services targeted at meeting the needs of the market and consumer, thereby driving innovation. Innovation in turn contributes to the creation of new markets and the growth and expansion of existing markets." The IETF document preparation work has been carried out in three phases: * A "status quo" position decided by the RFC 3774 socalled "IETF affinity group" documented in a WG/IANAPLAN charter. * A work accomplished by that WG/IANAPLAN * A review by the whole IETF mailing list open to everyone but me, (I am the moderator of the iucg@ietf.org non-WG mailing list of the Internet Users Contributing Group) This consensus leads to a technological fork of the internet architecture at a time where the RFC 6852 paradigm opens a permissionless innovation area. To avoid this leading to a technical jeopardy, the IETF position document should address a certain number of questions permitting other SDOs, Libre projects, and other reentrant architectures to transparently use the same basic catenet infrastructure without mutual negative interferences. To that end, the IETF consensus should be enriched by the responses to a certain number of questions because at this stage it is not sufficiently understandable. RFC 2026 defined the internet standardization process that addresses this situation through the appeal process. I am, therefore, appealing to the IESG, with the intent to ensure that the IAB and ISOC also address what belongs to their own areas of responsibility. The text of this appeal is temporarily at the URL: https://www.dropbox.com/s/ckqaaq0ngqed0ie/iesg-appeal-inanaplan.pdf?dl=0 It should soon be listed at http://www.ietf.org/iesg/appeal.html Respectfully yours, Jean-François C. (Jefsey) MORFIN Moderator iucg@ietf.org IETF contributions and appeals are in private capacity. --=====================_184952523==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit
The Honorable Lawrence E. Strickling 
Assistant Secretary for Communications & Information 
National Telecommunications & Information Administration   
United States Department of Commerce 
1401 Constitution Ave., N.W.  
Washington, DC 20230
 
Saint-Vincent de Barbeyrargues, March 11, 2015

Dear Assistant Secretary Strickling,

On March 14, 2014, you asked the Internet Corporation for Assigned Names and Numbers (ICANN) to convene global stakeholders to develop a proposal to transition the current role played by NTIA in the coordination of the Internet’s domain name system (DNS). You also have informed ICANN that you expected that in the development of the proposal, ICANN will work collaboratively with the directly affected parties, including the Internet Engineering Task Force (IETF), the Internet Architecture Board (IAB), the Internet Society (ISOC), the Regional Internet Registries (RIRs), top level domain name operators, VeriSign, and other interested global stakeholders.

Shortly after March 14, 2014, ICANN launched a multistakeholder process and discussion to gather community views and input on the principles and mechanisms for a different issue: the transitioning of NTIA's stewardship of the IANA functions.

Following a month-long call for input on the community-driven draft proposal, on June 6, ICANN posted the Process to Develop the Proposal and Next Steps.

Then, following a call for names, the IANA Stewardship Transition Coordination Group (ICG) was formed, comprising individuals selected by each represented community. These 30 individuals represent 13 communities of both direct and indirect stakeholders who together will deliver a proposal to the NTIA recommending a transition plan of NTIA’s stewardship of IANA functions to the Internet community, consistent with the key principles that you outlined in your March 14 announcement.

The ICG coordinates with 13 “communities”, which are:
  •  Address Supporting Organization (ASO)
  •  Country Code Names Supporting Organisation (ccNSO and non-ccNSO Country Code Top-Level Domain [ccTLD] operators, as selected by the ccNSO)
  •  Generic Names Supporting Organization (GNSO). GNSO seats from non-Registry representation
  •  Generic Top Level Domain Registries (gTLD Registries)
  •  Governmental Advisory Committee (GAC)
  •  International Chamber of Commerce/ Business Action to Support the Information Society (ICC/BASIS)
  •  Internet Architecture Board (IAB)
  •  Internet Engineering Task Force (IETF)
  •  Internet Society (ISOC)
  •  Number Resource Organization (NRO)
  •  Root Server System Advisory Committee (RSSAC)
  •  Security and Stability Advisory Committee (SSAC)
None of them represent the directly affected largest party, i.e. the lead and end users and the civil society organizations. As a part of this large and open community, a pioneer of the international network, and a member of the Libre community, I considered that my best chance to get my position heard would be through the technical community open, collective, and balanced work.
 
Does RFC 3869 of the IAB not state?
“The principal thesis of this document is that if commercial funding is the main source of funding for future Internet research, the future of the Internet infrastructure could be in trouble. In addition to issues about which projects are funded, the funding source can also affect the content of the research, for example, towards or against the development of open standards, or taking varying degrees of care about the effect of the developed protocols on the other traffic on the Internet.”
while the RFC 6852 from the same IAB states:
“We embrace a modern paradigm for standards where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status.”
 
“In this paradigm standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally. These voluntary standards serve as building blocks for products and services targeted at meeting the needs of the market and consumer, thereby driving innovation. Innovation in turn contributes to the creation of new markets and the growth and expansion of existing markets.”
The IETF document preparation work has been carried out in three phases:
  • A “status quo” position decided by the RFC 3774 socalled “IETF affinity group” documented in a WG/IANAPLAN charter.
  • A work accomplished by that WG/IANAPLAN
  • A review by the whole IETF mailing list open to everyone but me, (I am the moderator of the iucg@ietf.org non-WG mailing list of the Internet Users Contributing Group)
This consensus leads to a technological fork of the internet architecture at a time where the RFC 6852 paradigm opens a permissionless innovation area. To avoid this leading to a technical jeopardy, the IETF position document should address a certain number of questions permitting other SDOs, Libre projects, and other reentrant architectures to transparently use the same basic catenet infrastructure without mutual negative interferences. To that end, the IETF consensus should be enriched by the responses to a certain number of questions because at this stage it is not sufficiently understandable.

RFC 2026 defined the internet standardization process that addresses this situation through the appeal process. I am, therefore, appealing to the IESG, with the intent to ensure that the IAB and ISOC also address what belongs to their own areas of responsibility.

The text of this appeal is temporarily at the URL: https://www.dropbox.com/s/ckqaaq0ngqed0ie/iesg-appeal-inanaplan.pdf?dl=0
It should soon be listed at http://www.ietf.org/iesg/appeal.html

Respectfully yours,

Jean-François C. (Jefsey) MORFIN
Moderator iucg@ietf.org
IETF contributions and appeals are in private capacity. --=====================_184952523==.ALT--