From nobody Sun Sep 21 15:13:10 2014 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 BA6E91A0376; Sun, 21 Sep 2014 15:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.832 X-Spam-Level: ** X-Spam-Status: No, score=2.832 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdCKv9bCWGUP; Sun, 21 Sep 2014 15:13:03 -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 568EE1A0372; Sun, 21 Sep 2014 15:13:03 -0700 (PDT) Received: from 65.104.14.81.rev.sfr.net ([81.14.104.65]:30918 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XVpNM-0000qq-Rc; Sun, 21 Sep 2014 15:13:01 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Sep 2014 00:12:53 +0200 To: S Moonesamy , Brian E Carpenter From: JFC Morfin In-Reply-To: <6.2.5.6.2.20140920163627.0d561560@elandnews.com> References: <6.2.5.6.2.20140919225748.0b95fee0@elandnews.com> <541DD8B0.3070104@gmail.com> <6.2.5.6.2.20140920163627.0d561560@elandnews.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_106943505==.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: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/6vcS7ldLeA8GSvaPScI7RpPMPlk Cc: ianaplan@ietf.org, Jari Arkko , "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Disclosure of conflicts of interest 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: Sun, 21 Sep 2014 22:13:04 -0000 --=====================_106943505==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 06:59 21/09/2014, S Moonesamy wrote: >Hi Brian, >At 12:42 20-09-2014, Brian E Carpenter wrote: >>Could you define "conflict of interest" please? It is a phrase with >>a very wide range of interpretations. > >I agree that the phrase has a very wide range of interpretations. I >posted a message at >http://www.ietf.org/mail-archive/web/ianaplan/current/msg00309.html >I wasn't sure what information to provide. I left out some >information as I thought that it is obvious from the message >itself. The better path, in my opinion, is to leave the matter to >individual appreciation. Seun, Definitely every one of us is a stakeholder (even if many political/practical reasons oppose our full mutual recognition). This means that we all have some stakes of various kinds in the stability, reliability, and availability of the internet, for some directly (being paid for our acts/posts), and for most of us indirectly through various business/relational interests or rewards and/or revenues. The level and nature of these returns are of no real interest as they may vary with the considered terms (traveling is a short-term interest, protecting a job is a middle-term interest, architecturing the network is a long-term interest that may be worth oblivion or billions). The real point for everyone is to assess if each other individual is clever or free-minded enough to understand his/her own, his/her employer's or country's best interests in a complex political, economic, technical, etc. system and what is their nature (short-, middle-, or long-term, professional, financial, political, fame, military, etc.). In meshed interests networking, developments do not obey cybernetics or logic but rather agorics (i.e. not mono/dialectics but polylectics inferences and influences). In such a situation, the "average", the probable "emergence", and the "attraction" is what you feel (or simulate) as being the best leading common interest. The difficulty is that the best leading common interest depends on the terms, communities, market variations, etc. and ultimately on the common interaction of them (networking). Therefore, you do not think in terms of what people say and do, of who is paying them, etc. but rather by metaduction, i.e. what should be their best metainterests and how long will they take to understand it. This means that if someone does not understand his/her or others best interests he/she is creating a dumbness black-hole where any clever move and smart proposition will be absorbed and blocked or buried. Currently, while the "status quo" strategic black hole seems to dissolve, the most common black hole results from intellectual hysteresis: a determined attitude to act, think, and talk as if the situation was far from any singularity. This attitude might be a wider black hole. A black hole is a definitive conflict of intelligence with the whole community's common set of interests. - It may dissolve with time as the status quo seems to be doing, after the RFC 6852 identification of the global communities and the results of their divergences of interests (normative fragmentation leading to competitive innovation). - It may also enter a "self-organized criticality" phase (http://en.wikipedia.org/wiki/Self-organized_criticality) that can certainly be exacerbated by the kind of conflicts of interest you discuss. Those who sponsor them certainly play sorcerers' apprentices. jfc --=====================_106943505==.ALT Content-Type: text/html; charset="us-ascii" At 06:59 21/09/2014, S Moonesamy wrote:
Hi Brian,
At 12:42 20-09-2014, Brian E Carpenter wrote:
Could you define "conflict of interest" please? It is a phrase with
a very wide range of interpretations.

I agree that the phrase has a very wide range of interpretations.  I posted a message at http://www.ietf.org/mail-archive/web/ianaplan/current/msg00309.html I wasn't sure what information to provide.  I left out some information as I thought that it is obvious from the message itself.  The better path, in my opinion, is to leave the matter to individual appreciation.

Seun,

Definitely every one of us is a stakeholder (even if many political/practical reasons oppose our full mutual recognition). This means that we all have some stakes of various kinds in the stability, reliability, and availability of the internet, for some directly (being paid for our acts/posts), and for most of us indirectly through various business/relational interests or rewards and/or revenues.

The level and nature of these returns are of no real interest as they may vary with the considered terms (traveling is a short-term interest, protecting a job is a middle-term interest, architecturing the network is a long-term interest that may be worth oblivion or billions).

The real point for everyone is to assess if each other individual is clever or free-minded enough to understand his/her own, his/her employer’s or country's best interests in a complex political, economic, technical, etc. system and what is their nature (short-, middle-, or long-term, professional, financial, political, fame, military, etc.). In meshed interests networking, developments do not obey cybernetics or logic but rather agorics (i.e. not mono/dialectics but polylectics inferences and influences).

In such a situation, the "average", the probable "emergence", and the "attraction" is what you feel (or simulate) as being the best leading common interest. The difficulty is that the best leading common interest depends on the terms, communities, market variations, etc. and ultimately on the common interaction of them (networking). Therefore, you do not think in terms of what people say and do, of who is paying them, etc. but rather by metaduction, i.e. what should be their best metainterests and how long will they take to understand it.

This means that if someone does not understand his/her or others best interests he/she is creating a dumbness black-hole where any clever move and smart proposition will be absorbed and blocked or buried.

Currently, while the “status quo” strategic black hole seems to dissolve, the most common black hole results from intellectual hysteresis: a determined attitude to act, think, and talk as if the situation was far from any singularity. This attitude might be a wider black hole.

A black hole is a definitive conflict of intelligence with the whole community's common set of interests.

- It may dissolve with time as the status quo seems to be doing, after the RFC 6852 identification of the global communities and the results of their divergences of interests (normative fragmentation leading to competitive innovation).
- It may also enter a “self-organized criticality” phase ( http://en.wikipedia.org/wiki/Self-organized_criticality) that can certainly be exacerbated by the kind of conflicts of interest you discuss. Those who sponsor them certainly play sorcerers’ apprentices.

jfc --=====================_106943505==.ALT-- From nobody Mon Sep 22 17:07:58 2014 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 D41A51A6F63; Mon, 22 Sep 2014 17:07:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gj0lK-oM3K2z; Mon, 22 Sep 2014 17:07:49 -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 6B3FB1A6F71; Mon, 22 Sep 2014 17:07:48 -0700 (PDT) Received: from 65.104.14.81.rev.sfr.net ([81.14.104.65]:59832 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XWDdy-0007sX-FM; Mon, 22 Sep 2014 17:07:46 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Sep 2014 02:07:37 +0200 To: Marc Blanchet , "Leslie Daigle (TCE)" From: JFC Morfin In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/mQuKthwUFngD2QYlA36B40KOf2M Cc: "ianaplan-chairs@tools.ietf.org" , iab@iab.org, iesg@ietf.org, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] IANAPLAN virtual meeting 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: Tue, 23 Sep 2014 00:07:50 -0000 At 15:46 22/09/2014, Marc Blanchet wrote: >The IANAPLAN WG will hold a 2 hour interim virtual meeting October >6th, 10h00am Eastern. The main agenda item is the first deliverable >of the working group, where an individual draft will be discussed >and reviewed to be adopted by the working group. Marc and Leslie, Prior to this virtual global meeting, I would like to request an IANAPLAN IETF/WG charter update in two directions. A. This charter states both: 1. "The IANAPLAN working group is chartered to produce an IETF consensus document that describes the expected interaction between the IETF and the operator of IETF protocol parameters registries." This implies (as the context clearly shows it) that a single operator is to be considered. 2. The working group will assume that the following documents will continue to be in effect: ... RFC 6220 - Defining the Role and Function of IETF Protocol Parameter Registry Operators. Point 1 considers a single operator, something that point 2 formally contradicts in considering and pertinently documenting the need for multiple operators. This calls for a clarification, not only due to the demanded contradiction, but because I am most probably not alone among Libre and States R&D organizations (RDOs) in planning: a. to draft within the coming months the description of a general internet model, - addressing the second motivation of the IEN 48, 1978 Vint Cerf's ARPANET internetworking project (better known as the internet project embodied by the IETF) - that would be compliant with the RFC 6220 text and rationale in extending its MDRS (metadata registry system) support of the IEN 48 first motivation documentation (IANA) - to every "new networking technology to be introduced into the existing catenet while remaining functionally compatible with existing systems" in order to "allow[] for the phased introduction of new and obsolescence of old networks without requiring a global simultaneous change". b. to develop, test, and deploy MDRS tools in order, - to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the IEN 48 "loose sense" of the local meaning "peculiar to the particular network" rather than "a network of limited geographic extent.") - to operate their own Information Centers (VGNICs) for the Administration of their Names and Numbers (the MYCANN project in my case), - at least - outside of any other consideration - in order to have available a failsafe plan for their net in case of ICANN failure, unaccountable divergence or incapacity to keep coordinated the RFC 6852 multi-global community landscape. B. Since 1977, the US (FCC and then NTIA) as a single point of network failure was a reliable enough situation that RFC 6852 is dissolving and the NTIA is going to terminate on Sept. 30, 2015. The mission of the IETF is to make sure that the end to end datagram exchanges can continue to perform in a the new context "where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status" so its "standards support interoperability [and] foster global competition", even in the case they "are [only partly] voluntarily adopted globally". I do not think this is possible if the Milestones are not reviewed in order to permit a seamless transition by Sept. 30, 2015. To that end, the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This implies an IETF general final call by April 30, 2015 and WG final call by March 31, 2015. The charter must not appear as an incitement to the status quo while criticality is a possibility, and this way to legitimate self-organization that is not concerted. jfc . From nobody Tue Sep 23 09:20:30 2014 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 1FDE51A8734; Tue, 23 Sep 2014 09:20:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.632 X-Spam-Level: * X-Spam-Status: No, score=1.632 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuSo0uzPyKBm; Tue, 23 Sep 2014 09:20:09 -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 22D9A1A8730; Tue, 23 Sep 2014 09:20:09 -0700 (PDT) Received: from 65.104.14.81.rev.sfr.net ([81.14.104.65]:13634 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XWSox-0003IF-1L; Tue, 23 Sep 2014 09:20:07 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Sep 2014 18:19:56 +0200 To: "Leslie Daigle (TCE)" , Marc Blanchet From: Jefsey In-Reply-To: <5420D3C0.7000206@thinkingcat.com> References: <20140923004910.C34E1A0647@zoidberg.ecotroph.net> <5420D3C0.7000206@thinkingcat.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_258566680==.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: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/zvpQXKNw1skjkq5eWToq5RsKIb4 Cc: "ianaplan-chairs@tools.ietf.org" , iab@iab.org, iesg@ietf.org, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] IANAPLAN virtual meeting 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: Tue, 23 Sep 2014 16:20:12 -0000 --=====================_258566680==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 03:58 23/09/2014, Leslie Daigle (TCE) wrote: >M. Morfin, >The appropriate time for such substantive suggestions for charter >changes would have been during the initial WG chartering process. >At this time, the status quo is in fact what the WG is chartered to >ensure, and what the WG chairs will be pursuing unless or until the >IESG directs us otherwise. >Leslie. Dear Leslie, One of my premises is that, at this time, the status quo's political/economic/technical strategy deployed by the US industry since 1983 is dissolving. I am, therefore, not suggesting substantive changes to an inadequate charter, but rather demanding the urgent resolution of two double constraints in its text, of which some deem the aporia to be a pro-status-quo strategic bias that you seem to confirm. Several consider this bias to be of such a magnitude that its resolution could only lie in an IETF fork. Before triggering such a risk in refusing to review the Charter, it would seem reasonable for the co-Chairs and the AD, who is also the IETF Chair, to consider my request carefully. This request follows the RFC 2026 procedure: 1. It is based upon my belief that, in not calling for the clarification of internal and contextual contradictions in our charter, the AD and the co-Chairs would make "an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy". 2. as such I "first discuss the matter with the Working Group's chair(s)" and "involve other members of the Working Group (or the Working Group as a whole) in the discussion." 3. due to the time constraints imposed on this question that you refer to, I "bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered." in the hope that "The Area Director(s) shall attempt to resolve the dispute." For the information of the non-IETF parties: 1 I quote the RFC 2026: "If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the IESG as a whole. The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing. If the disagreement is not resolved to the satisfaction of the parties at the IESG level, any of the parties involved may appeal the decision to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed and with respect to all questions of technical merit." 2. Due to the political nature of the disagreement, you have clearly identified: "the status quo [political strategy] is in fact what the WG is chartered to ensure, and what the WG chairs will be pursuing unless or until the IESG directs us otherwise [whatever the WG members may contribute]", 3. If the IESG and IAB are unable to reach a compromise that is acceptable to the whole Internet community, such a compromise will have to be found through an appeal to ISOC. This results from RFC 2026, which states: "Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute." 4. If ISOC is then unable to work out an acceptable compromise to the world, the RFC 6852 (Affirmation of the Modern Paradigm for Standards) would provide the framework to find a way to avoid an international sovereign involvement in devising the appeal procedure that I called for in my appeal to IESG and IAB reaching the ISOC level, concerning the RFC 6852 incompleteness on this very point. That procedure was interrupted by the NTIA strategic move that was called for by the Dubai vote, Snowden saga, RFC 6852, Montevideo Statement, and NETmundial and Geneva meetings in that it: - (1) made the status quo strategy obsolete that you want to slowly follow in spite of the NTIA imposed fast calendar; -.(2) is based upon a quid-pro-quo that is organized by ICANN, that many consider to be a self-protection move, confusing the NTIA request concerning the punctual transition of the ICANN/NTIA "IN" DNS Class registry function with the ICANN management of the whole set of IANA functions; - (3) prompted the need for this WG. The time frame imposed by the NTIA, ITU, R&DO, Governments, and IUser projects is extremely tight and, therefore, I cannot accept to engage in any dilatory skirmishes. I, therefore, urge you, and Jari Arrko, both as the AD and the IETF Chair, to urgently support a WG/IANALAN charter internal and contextual consistency review. The only alternative in order to prevent an IETF horizontal and/or vertical fork, leading to the WCIT already voted on ITU/IGF takeover of the internet affairs and governance, would then be for me to engage anew in a fastidious, cumbersome, and time consuming peace mongering IESG/IAB/ISOC appeal effort. However, due to the tight time frame I doubt that the created incertitude would prevent uncoordinated but legitimate or the legal duty of precaution projects tending to protect many people's interests and harden internet operational security, stability, transparency, neutrality, and reliability. Such projects would most probably durably affect the internet architectonics. It is not up to me to decide if they would "make the Internet work better" (RFC 3539) nor if their possible conflicts would lead to an internet "where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status." (RFC 6852). I am only interested in a "paradigm [where] standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally" (RFC 6852). jfc >On 9/22/14 8:07 PM, JFC Morfin wrote: >>At 15:46 22/09/2014, Marc Blanchet wrote: >>>The IANAPLAN WG will hold a 2 hour interim virtual meeting October >>>6th, 10h00am Eastern. The main agenda item is the first deliverable of >>>the working group, where an individual draft will be discussed and >>>reviewed to be adopted by the working group. >> >>Marc and Leslie, >> >>Prior to this virtual global meeting, I would like to request an >>IANAPLAN IETF/WG charter update in two directions. >> >>A. This charter states both: >> >>1. "The IANAPLAN working group is chartered to produce an IETF consensus >>document that describes the expected interaction between the IETF and >>the operator of IETF protocol parameters registries." This implies (as >>the context clearly shows it) that a single operator is to be considered. >> >>2. The working group will assume that the following documents will >>continue to be in effect: ... RFC 6220 - Defining the Role and Function >>of IETF Protocol Parameter Registry Operators. >> >>Point 1 considers a single operator, something that point 2 formally >>contradicts in considering and pertinently documenting the need for >>multiple operators. This calls for a clarification, not only due to the >>demanded contradiction, but because I am most probably not alone among >>Libre and States R&D organizations (RDOs) in planning: >> >>a. to draft within the coming months the description of a general >>internet model, >>- addressing the second motivation of the IEN 48, 1978 Vint Cerf's >>ARPANET internetworking project (better known as the internet project >>embodied by the IETF) >>- that would be compliant with the RFC 6220 text and rationale in >>extending its MDRS (metadata registry system) support of the IEN 48 >>first motivation documentation (IANA) >>- to every "new networking technology to be introduced into the existing >>catenet while remaining functionally compatible with existing systems" >>in order to "allow[] for the phased introduction of new and obsolescence >>of old networks without requiring a global simultaneous change". >> >>b. to develop, test, and deploy MDRS tools in order, >>- to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the IEN >>48 "loose sense" of the local meaning "peculiar to the particular >>network" rather than "a network of limited geographic extent.") >>- to operate their own Information Centers (VGNICs) for the >>Administration of their Names and Numbers (the MYCANN project in my case), >>- at least - outside of any other consideration - in order to have >>available a failsafe plan for their net in case of ICANN failure, >>unaccountable divergence or incapacity to keep coordinated the RFC 6852 >>multi-global community landscape. >> >>B. Since 1977, the US (FCC and then NTIA) as a single point of network >>failure was a reliable enough situation that RFC 6852 is dissolving and >>the NTIA is going to terminate on Sept. 30, 2015. >> >>The mission of the IETF is to make sure that the end to end datagram >>exchanges can continue to perform in a the new context "where the >>economics of global markets, fueled by technological advancements, drive >>global deployment of standards regardless of their formal status" so its >>"standards support interoperability [and] foster global competition", >>even in the case they "are [only partly] voluntarily adopted globally". >> >>I do not think this is possible if the Milestones are not reviewed in >>order to permit a seamless transition by Sept. 30, 2015. To that end, >>the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This implies >>an IETF general final call by April 30, 2015 and WG final call by March >>31, 2015. >> >>The charter must not appear as an incitement to the status quo while >>criticality is a possibility, and this way to legitimate >>self-organization that is not concerted. >> >>jfc >> >> >>. >> >> >> >> >> >> >> >> >> > >-- > >------------------------------------------------------------------- >Leslie Daigle >Principal, ThinkingCat Enterprises >ldaigle@thinkingcat.com >------------------------------------------------------------------- --=====================_258566680==.ALT Content-Type: text/html; charset="us-ascii" At 03:58 23/09/2014, Leslie Daigle (TCE) wrote:
M. Morfin,
The appropriate time for such substantive suggestions for charter changes would have been during the initial WG chartering process.
At this time, the status quo is in fact what the WG is chartered to ensure, and what the WG chairs will be pursuing unless or until the IESG directs us otherwise.
Leslie.

Dear Leslie,

One of my premises is that, at this time, the status quo’s political/economic/technical strategy deployed by the US industry since 1983 is dissolving. I am, therefore, not suggesting substantive changes to an inadequate charter, but rather demanding the urgent resolution of two double constraints in its text, of which some deem the aporia to be a pro-status-quo strategic bias that you seem to confirm. Several consider this bias to be of such a magnitude that its resolution could only lie in an IETF fork.

Before triggering such a risk in refusing to review the Charter, it would seem reasonable for the co-Chairs and the AD, who is also the IETF Chair, to consider my request carefully. This request follows the RFC 2026 procedure:

1. It is based upon my belief that, in not calling for the clarification of internal and contextual contradictions in our charter, the AD and the co-Chairs would make "an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy".

2. as such I "first discuss the matter with the Working Group's chair(s)" and "involve other members of the Working Group (or the Working Group as a whole) in the discussion."

3. due to the time constraints imposed on this question that you refer to, I "bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered." in the hope that "The Area Director(s) shall attempt to resolve the dispute."

For the information of the non-IETF parties:

1 I quote the RFC 2026:
 
"If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the IESG as a whole.  The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing. If the disagreement is not resolved to the satisfaction of the parties at the IESG level, any of the parties involved may appeal the decision to the IAB.  The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed and with respect to all questions of technical merit."

2. Due to the political nature of the disagreement, you have clearly identified:
 
"the status quo [political strategy] is in fact what the WG is chartered to ensure, and what the WG chairs will be pursuing unless or until the IESG directs us otherwise [whatever the WG members may contribute]",
 
3. If the IESG and IAB are unable to reach a compromise that is acceptable to the whole Internet community, such a compromise will have to be found through an appeal to ISOC. This results from RFC 2026, which states:
 
"Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees.  The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute.”

4. If ISOC is then unable to work out an acceptable compromise to the world, the RFC 6852 (Affirmation of the Modern Paradigm for Standards) would provide the framework to find a way to avoid an international sovereign involvement in devising the appeal procedure that I called for in my appeal to IESG and IAB reaching the ISOC level, concerning the RFC 6852 incompleteness on this very point. That procedure was interrupted by the NTIA strategic move that was called for by the Dubai vote, Snowden saga, RFC 6852, Montevideo Statement, and NETmundial and Geneva meetings in that it:

- (1) made the status quo strategy obsolete that you want to slowly follow in spite of the NTIA imposed fast calendar;
-.(2) is based upon a quid-pro-quo that is organized by ICANN, that many consider to be a self-protection move, confusing the NTIA request concerning the punctual transition of the ICANN/NTIA "IN" DNS Class registry function with the ICANN management of the whole set of IANA functions;
- (3) prompted the need for this WG.

The time frame imposed by the NTIA, ITU, R&DO, Governments, and IUser projects is extremely tight and, therefore, I cannot accept to engage in any dilatory skirmishes. I, therefore, urge you, and Jari Arrko, both as the AD and the IETF Chair, to urgently support a WG/IANALAN charter internal and contextual consistency review.

The only alternative in order to prevent an IETF horizontal and/or vertical fork, leading to the WCIT already voted on ITU/IGF takeover of the internet affairs and governance, would then be for me to engage anew in a fastidious, cumbersome, and time consuming peace mongering IESG/IAB/ISOC appeal effort. However, due to the tight time frame I doubt that the created incertitude would prevent uncoordinated but legitimate or the legal duty of precaution projects tending to protect many people’s interests and harden internet operational security, stability, transparency, neutrality, and reliability.
 
Such projects would most probably durably affect the internet architectonics. It is not up to me to decide if they would “make the Internet work better” (RFC 3539) nor if their possible conflicts would lead to an internet “where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status.” (RFC 6852).
 
I am only interested in a “paradigm [where] standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally” (RFC 6852).

jfc


On 9/22/14 8:07 PM, JFC Morfin wrote:
At 15:46 22/09/2014, Marc Blanchet wrote:
The IANAPLAN WG will hold a 2 hour interim virtual meeting October
6th, 10h00am Eastern. The main agenda item is the first deliverable of
the working group, where an individual draft will be discussed and
reviewed to be adopted by the working group.

Marc and Leslie,

Prior to this virtual global meeting, I would like to request an
IANAPLAN IETF/WG charter update in two directions.

A. This charter states both:

1. "The IANAPLAN working group is chartered to produce an IETF consensus
document that describes the expected interaction between the IETF and
the operator of IETF protocol parameters registries." This implies (as
the context clearly shows it) that a single operator is to be considered.

2. The working group will assume that the following documents will
continue to be in effect: ... RFC 6220 - Defining the Role and Function
of IETF Protocol Parameter Registry Operators.

Point 1 considers a single operator, something that point 2 formally
contradicts in considering and pertinently documenting the need for
multiple operators. This calls for a clarification, not only due to the
demanded contradiction, but because I am most probably not alone among
Libre and States R&D organizations (RDOs) in planning:

a. to draft within the coming months the description of a general
internet model,
- addressing the second motivation of the IEN 48, 1978 Vint Cerf's
ARPANET internetworking project (better known as the internet project
embodied by the IETF)
- that would be compliant with the RFC 6220 text and rationale in
extending its MDRS (metadata registry system) support of the IEN 48
first motivation documentation (IANA)
- to every "new networking technology to be introduced into the existing
catenet while remaining functionally compatible with existing systems"
in order to "allow[] for the phased introduction of new and obsolescence
of old networks without requiring a global simultaneous change".

b. to develop, test, and deploy MDRS tools in order,
- to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the IEN
48 "loose sense" of the local meaning "peculiar to the particular
network" rather than "a network of limited geographic extent.")
- to operate their own Information Centers (VGNICs) for the
Administration of their Names and Numbers (the MYCANN project in my case),
- at least - outside of any other consideration - in order to have
available a failsafe plan for their net in case of ICANN failure,
unaccountable divergence or incapacity to keep coordinated the RFC 6852
multi-global community landscape.

B. Since 1977, the US (FCC and then NTIA) as a single point of network
failure was a reliable enough situation that RFC 6852 is dissolving and
the NTIA is going to terminate on Sept. 30, 2015.

The mission of the IETF is to make sure that the end to end datagram
exchanges can continue to perform in a the new context "where the
economics of global markets, fueled by technological advancements, drive
global deployment of standards regardless of their formal status" so its
"standards support interoperability [and] foster global competition",
even in the case they "are [only partly] voluntarily adopted globally".

I do not think this is possible if the Milestones are not reviewed in
order to permit a seamless transition by Sept. 30, 2015. To that end,
the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This implies
an IETF general final call by April 30, 2015 and WG final call by March
31, 2015.

The charter must not appear as an incitement to the status quo while
criticality is a possibility, and this way to legitimate
self-organization that is not concerted.

jfc


.










--

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------
--=====================_258566680==.ALT-- From nobody Tue Sep 23 09:24:04 2014 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 76BDB1A86ED; Tue, 23 Sep 2014 09:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.632 X-Spam-Level: * X-Spam-Status: No, score=1.632 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSGLMEyQ8NgC; Tue, 23 Sep 2014 09:23:52 -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 2E2EC1A873D; Tue, 23 Sep 2014 09:23:52 -0700 (PDT) Received: from 65.104.14.81.rev.sfr.net ([81.14.104.65]:13684 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XWSsY-0003Y6-Ay; Tue, 23 Sep 2014 09:23:51 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 23 Sep 2014 18:23:39 +0200 To: Jari Arkko From: Jefsey Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_258789762==.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: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/EiVT6ex8rrLLor36wf5PgbSWDSY Cc: "ianaplan-chairs@tools.ietf.org" , "Leslie Daigle \(TCE\)" , Marc Blanchet , iab@iab.org, "iucg@ietf.org" , iesg@ietf.org Subject: Re: [iucg] [Ianaplan] IANAPLAN virtual meeting 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: Tue, 23 Sep 2014 16:23:55 -0000 --=====================_258789762==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear Jari, this is to formally inform you of the mail I sent to the IETF/WG/IANAPLAN co-Chairs concering the urgent need of a double charter clarification prior to the announced virtual meeting if we want it to be of use. Best jfc At 03:58 23/09/2014, Leslie Daigle (TCE) wrote: >M. Morfin, >The appropriate time for such substantive suggestions for charter >changes would have been during the initial WG chartering process. >At this time, the status quo is in fact what the WG is chartered to >ensure, and what the WG chairs will be pursuing unless or until the >IESG directs us otherwise. >Leslie. Dear Leslie, One of my premises is that, at this time, the status quo's political/economic/technical strategy deployed by the US industry since 1983 is dissolving. I am, therefore, not suggesting substantive changes to an inadequate charter, but rather demanding the urgent resolution of two double constraints in its text, of which some deem the aporia to be a pro-status-quo strategic bias that you seem to confirm. Several consider this bias to be of such a magnitude that its resolution could only lie in an IETF fork. Before triggering such a risk in refusing to review the Charter, it would seem reasonable for the co-Chairs and the AD, who is also the IETF Chair, to consider my request carefully. This request follows the RFC 2026 procedure: 1. It is based upon my belief that, in not calling for the clarification of internal and contextual contradictions in our charter, the AD and the co-Chairs would make "an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy". 2. as such I "first discuss the matter with the Working Group's chair(s)" and "involve other members of the Working Group (or the Working Group as a whole) in the discussion." 3. due to the time constraints imposed on this question that you refer to, I "bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered." in the hope that "The Area Director(s) shall attempt to resolve the dispute." For the information of the non-IETF parties: 1 I quote the RFC 2026: "If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the IESG as a whole. The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing. If the disagreement is not resolved to the satisfaction of the parties at the IESG level, any of the parties involved may appeal the decision to the IAB. The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed and with respect to all questions of technical merit." 2. Due to the political nature of the disagreement, you have clearly identified: "the status quo [political strategy] is in fact what the WG is chartered to ensure, and what the WG chairs will be pursuing unless or until the IESG directs us otherwise [whatever the WG members may contribute]", 3. If the IESG and IAB are unable to reach a compromise that is acceptable to the whole Internet community, such a compromise will have to be found through an appeal to ISOC. This results from RFC 2026, which states: "Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees. The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute." 4. If ISOC is then unable to work out an acceptable compromise to the world, the RFC 6852 (Affirmation of the Modern Paradigm for Standards) would provide the framework to find a way to avoid an international sovereign involvement in devising the appeal procedure that I called for in my appeal to IESG and IAB reaching the ISOC level, concerning the RFC 6852 incompleteness on this very point. That procedure was interrupted by the NTIA strategic move that was called for by the Dubai vote, Snowden saga, RFC 6852, Montevideo Statement, and NETmundial and Geneva meetings in that it: - (1) made the status quo strategy obsolete that you want to slowly follow in spite of the NTIA imposed fast calendar; -.(2) is based upon a quid-pro-quo that is organized by ICANN, that many consider to be a self-protection move, confusing the NTIA request concerning the punctual transition of the ICANN/NTIA "IN" DNS Class registry function with the ICANN management of the whole set of IANA functions; - (3) prompted the need for this WG. The time frame imposed by the NTIA, ITU, R&DO, Governments, and IUser projects is extremely tight and, therefore, I cannot accept to engage in any dilatory skirmishes. I, therefore, urge you, and Jari Arrko, both as the AD and the IETF Chair, to urgently support a WG/IANALAN charter internal and contextual consistency review. The only alternative in order to prevent an IETF horizontal and/or vertical fork, leading to the WCIT already voted on ITU/IGF takeover of the internet affairs and governance, would then be for me to engage anew in a fastidious, cumbersome, and time consuming peace mongering IESG/IAB/ISOC appeal effort. However, due to the tight time frame I doubt that the created incertitude would prevent uncoordinated but legitimate or the legal duty of precaution projects tending to protect many people's interests and harden internet operational security, stability, transparency, neutrality, and reliability. Such projects would most probably durably affect the internet architectonics. It is not up to me to decide if they would "make the Internet work better" (RFC 3539) nor if their possible conflicts would lead to an internet "where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status." (RFC 6852). I am only interested in a "paradigm [where] standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally" (RFC 6852). jfc >On 9/22/14 8:07 PM, JFC Morfin wrote: >>At 15:46 22/09/2014, Marc Blanchet wrote: >>>The IANAPLAN WG will hold a 2 hour interim virtual meeting October >>>6th, 10h00am Eastern. The main agenda item is the first deliverable of >>>the working group, where an individual draft will be discussed and >>>reviewed to be adopted by the working group. >> >>Marc and Leslie, >> >>Prior to this virtual global meeting, I would like to request an >>IANAPLAN IETF/WG charter update in two directions. >> >>A. This charter states both: >> >>1. "The IANAPLAN working group is chartered to produce an IETF consensus >>document that describes the expected interaction between the IETF and >>the operator of IETF protocol parameters registries." This implies (as >>the context clearly shows it) that a single operator is to be considered. >> >>2. The working group will assume that the following documents will >>continue to be in effect: ... RFC 6220 - Defining the Role and Function >>of IETF Protocol Parameter Registry Operators. >> >>Point 1 considers a single operator, something that point 2 formally >>contradicts in considering and pertinently documenting the need for >>multiple operators. This calls for a clarification, not only due to the >>demanded contradiction, but because I am most probably not alone among >>Libre and States R&D organizations (RDOs) in planning: >> >>a. to draft within the coming months the description of a general >>internet model, >>- addressing the second motivation of the IEN 48, 1978 Vint Cerf's >>ARPANET internetworking project (better known as the internet project >>embodied by the IETF) >>- that would be compliant with the RFC 6220 text and rationale in >>extending its MDRS (metadata registry system) support of the IEN 48 >>first motivation documentation (IANA) >>- to every "new networking technology to be introduced into the existing >>catenet while remaining functionally compatible with existing systems" >>in order to "allow[] for the phased introduction of new and obsolescence >>of old networks without requiring a global simultaneous change". >> >>b. to develop, test, and deploy MDRS tools in order, >>- to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the IEN >>48 "loose sense" of the local meaning "peculiar to the particular >>network" rather than "a network of limited geographic extent.") >>- to operate their own Information Centers (VGNICs) for the >>Administration of their Names and Numbers (the MYCANN project in my case), >>- at least - outside of any other consideration - in order to have >>available a failsafe plan for their net in case of ICANN failure, >>unaccountable divergence or incapacity to keep coordinated the RFC 6852 >>multi-global community landscape. >> >>B. Since 1977, the US (FCC and then NTIA) as a single point of network >>failure was a reliable enough situation that RFC 6852 is dissolving and >>the NTIA is going to terminate on Sept. 30, 2015. >> >>The mission of the IETF is to make sure that the end to end datagram >>exchanges can continue to perform in a the new context "where the >>economics of global markets, fueled by technological advancements, drive >>global deployment of standards regardless of their formal status" so its >>"standards support interoperability [and] foster global competition", >>even in the case they "are [only partly] voluntarily adopted globally". >> >>I do not think this is possible if the Milestones are not reviewed in >>order to permit a seamless transition by Sept. 30, 2015. To that end, >>the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This implies >>an IETF general final call by April 30, 2015 and WG final call by March >>31, 2015. >> >>The charter must not appear as an incitement to the status quo while >>criticality is a possibility, and this way to legitimate >>self-organization that is not concerted. >> >>jfc >> >> >>. >> >> >> >> >> >> >> >> > >-- > >------------------------------------------------------------------- >Leslie Daigle >Principal, ThinkingCat Enterprises >ldaigle@thinkingcat.com >------------------------------------------------------------------- --=====================_258789762==.ALT Content-Type: text/html; charset="us-ascii" Dear Jari,
this is to formally inform you of the mail I sent to the IETF/WG/IANAPLAN co-Chairs concering the urgent need of a double charter clarification prior to the announced virtual meeting if we want it to be of use.
Best
jfc

At 03:58 23/09/2014, Leslie Daigle (TCE) wrote:
M. Morfin,
The appropriate time for such substantive suggestions for charter changes would have been during the initial WG chartering process.
At this time, the status quo is in fact what the WG is chartered to ensure, and what the WG chairs will be pursuing unless or until the IESG directs us otherwise.
Leslie.

Dear Leslie,

One of my premises is that, at this time, the status quo’s political/economic/technical strategy deployed by the US industry since 1983 is dissolving. I am, therefore, not suggesting substantive changes to an inadequate charter, but rather demanding the urgent resolution of two double constraints in its text, of which some deem the aporia to be a pro-status-quo strategic bias that you seem to confirm. Several consider this bias to be of such a magnitude that its resolution could only lie in an IETF fork.

Before triggering such a risk in refusing to review the Charter, it would seem reasonable for the co-Chairs and the AD, who is also the IETF Chair, to consider my request carefully. This request follows the RFC 2026 procedure:

1. It is based upon my belief that, in not calling for the clarification of internal and contextual contradictions in our charter, the AD and the co-Chairs would make "an incorrect technical choice which places the quality and/or integrity of the Working Group's product(s) in significant jeopardy".

2. as such I "first discuss the matter with the Working Group's chair(s)" and "involve other members of the Working Group (or the Working Group as a whole) in the discussion."

3. due to the time constraints imposed on this question that you refer to, I "bring it to the attention of the Area Director(s) for the area in which the Working Group is chartered." in the hope that "The Area Director(s) shall attempt to resolve the dispute."

For the information of the non-IETF parties:

1 I quote the RFC 2026:
 
"If the disagreement cannot be resolved by the Area Director(s) any of the parties involved may then appeal to the IESG as a whole.  The IESG shall then review the situation and attempt to resolve it in a manner of its own choosing. If the disagreement is not resolved to the satisfaction of the parties at the IESG level, any of the parties involved may appeal the decision to the IAB.  The IAB shall then review the situation and attempt to resolve it in a manner of its own choosing. The IAB decision is final with respect to the question of whether or not the Internet standards procedures have been followed and with respect to all questions of technical merit."

2. Due to the political nature of the disagreement, you have clearly identified:
 
"the status quo [political strategy] is in fact what the WG is chartered to ensure, and what the WG chairs will be pursuing unless or until the IESG directs us otherwise [whatever the WG members may contribute]",
 
3. If the IESG and IAB are unable to reach a compromise that is acceptable to the whole Internet community, such a compromise will have to be found through an appeal to ISOC. This results from RFC 2026, which states:
 
"Further recourse is available only in cases in which the procedures themselves (i.e., the procedures described in this document) are claimed to be inadequate or insufficient to the protection of the rights of all parties in a fair and open Internet Standards Process. Claims on this basis may be made to the Internet Society Board of Trustees.  The President of the Internet Society shall acknowledge such an appeal within two weeks, and shall at the time of acknowledgment advise the petitioner of the expected duration of the Trustees' review of the appeal. The Trustees shall review the situation in a manner of its own choosing and report to the IETF on the outcome of its review. The Trustees' decision upon completion of their review shall be final with respect to all aspects of the dispute.”

4. If ISOC is then unable to work out an acceptable compromise to the world, the RFC 6852 (Affirmation of the Modern Paradigm for Standards) would provide the framework to find a way to avoid an international sovereign involvement in devising the appeal procedure that I called for in my appeal to IESG and IAB reaching the ISOC level, concerning the RFC 6852 incompleteness on this very point. That procedure was interrupted by the NTIA strategic move that was called for by the Dubai vote, Snowden saga, RFC 6852, Montevideo Statement, and NETmundial and Geneva meetings in that it:

- (1) made the status quo strategy obsolete that you want to slowly follow in spite of the NTIA imposed fast calendar;
-.(2) is based upon a quid-pro-quo that is organized by ICANN, that many consider to be a self-protection move, confusing the NTIA request concerning the punctual transition of the ICANN/NTIA "IN" DNS Class registry function with the ICANN management of the whole set of IANA functions;
- (3) prompted the need for this WG.

The time frame imposed by the NTIA, ITU, R&DO, Governments, and IUser projects is extremely tight and, therefore, I cannot accept to engage in any dilatory skirmishes. I, therefore, urge you, and Jari Arrko, both as the AD and the IETF Chair, to urgently support a WG/IANALAN charter internal and contextual consistency review.

The only alternative in order to prevent an IETF horizontal and/or vertical fork, leading to the WCIT already voted on ITU/IGF takeover of the internet affairs and governance, would then be for me to engage anew in a fastidious, cumbersome, and time consuming peace mongering IESG/IAB/ISOC appeal effort. However, due to the tight time frame I doubt that the created incertitude would prevent uncoordinated but legitimate or the legal duty of precaution projects tending to protect many people’s interests and harden internet operational security, stability, transparency, neutrality, and reliability.
 
Such projects would most probably durably affect the internet architectonics. It is not up to me to decide if they would “make the Internet work better” (RFC 3539) nor if their possible conflicts would lead to an internet “where the economics of global markets, fueled by technological advancements, drive global deployment of standards regardless of their formal status.” (RFC 6852).
 
I am only interested in a “paradigm [where] standards support interoperability, foster global competition, are developed through an open participatory process, and are voluntarily adopted globally” (RFC 6852).

jfc


On 9/22/14 8:07 PM, JFC Morfin wrote:
At 15:46 22/09/2014, Marc Blanchet wrote:
The IANAPLAN WG will hold a 2 hour interim virtual meeting October
6th, 10h00am Eastern. The main agenda item is the first deliverable of
the working group, where an individual draft will be discussed and
reviewed to be adopted by the working group.

Marc and Leslie,

Prior to this virtual global meeting, I would like to request an
IANAPLAN IETF/WG charter update in two directions.

A. This charter states both:

1. "The IANAPLAN working group is chartered to produce an IETF consensus
document that describes the expected interaction between the IETF and
the operator of IETF protocol parameters registries." This implies (as
the context clearly shows it) that a single operator is to be considered.

2. The working group will assume that the following documents will
continue to be in effect: ... RFC 6220 - Defining the Role and Function
of IETF Protocol Parameter Registry Operators.

Point 1 considers a single operator, something that point 2 formally
contradicts in considering and pertinently documenting the need for
multiple operators. This calls for a clarification, not only due to the
demanded contradiction, but because I am most probably not alone among
Libre and States R&D organizations (RDOs) in planning:

a. to draft within the coming months the description of a general
internet model,
- addressing the second motivation of the IEN 48, 1978 Vint Cerf's
ARPANET internetworking project (better known as the internet project
embodied by the IETF)
- that would be compliant with the RFC 6220 text and rationale in
extending its MDRS (metadata registry system) support of the IEN 48
first motivation documentation (IANA)
- to every "new networking technology to be introduced into the existing
catenet while remaining functionally compatible with existing systems"
in order to "allow[] for the phased introduction of new and obsolescence
of old networks without requiring a global simultaneous change".

b. to develop, test, and deploy MDRS tools in order,
- to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the IEN
48 "loose sense" of the local meaning "peculiar to the particular
network" rather than "a network of limited geographic extent.")
- to operate their own Information Centers (VGNICs) for the
Administration of their Names and Numbers (the MYCANN project in my case),
- at least - outside of any other consideration - in order to have
available a failsafe plan for their net in case of ICANN failure,
unaccountable divergence or incapacity to keep coordinated the RFC 6852
multi-global community landscape.

B. Since 1977, the US (FCC and then NTIA) as a single point of network
failure was a reliable enough situation that RFC 6852 is dissolving and
the NTIA is going to terminate on Sept. 30, 2015.

The mission of the IETF is to make sure that the end to end datagram
exchanges can continue to perform in a the new context "where the
economics of global markets, fueled by technological advancements, drive
global deployment of standards regardless of their formal status" so its
"standards support interoperability [and] foster global competition",
even in the case they "are [only partly] voluntarily adopted globally".

I do not think this is possible if the Milestones are not reviewed in
order to permit a seamless transition by Sept. 30, 2015. To that end,
the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This implies
an IETF general final call by April 30, 2015 and WG final call by March
31, 2015.

The charter must not appear as an incitement to the status quo while
criticality is a possibility, and this way to legitimate
self-organization that is not concerted.

jfc


.









--

-------------------------------------------------------------------
Leslie Daigle
Principal, ThinkingCat Enterprises
ldaigle@thinkingcat.com
-------------------------------------------------------------------
--=====================_258789762==.ALT-- From nobody Tue Sep 23 12:40:57 2014 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 3B2851A1B3E; Tue, 23 Sep 2014 12:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.787 X-Spam-Level: X-Spam-Status: No, score=-7.787 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] 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 rYCQvy2Wh7QX; Tue, 23 Sep 2014 12:40:51 -0700 (PDT) Received: from sabertooth01.qualcomm.com (sabertooth01.qualcomm.com [65.197.215.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E8BE1A1B38; Tue, 23 Sep 2014 12:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=qti.qualcomm.com; i=@qti.qualcomm.com; q=dns/txt; s=qcdkim; t=1411501251; x=1443037251; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=8hnWhpm+2XryvHLik9iJsZKVB4fvSchBSL09wusVqoM=; b=QVSsMSap4yOZdglbBBkc4v1rzTRyZPQ3NaxG0K3G6rF2m5Ysol6iBUhu vEyUKXj3v+LKBwesIiBWcz3bU2ZnP749ZePHDay9phgFwJbUrPf/1x6I0 23I9DMesfWKWfP/Qv2T1lq6hPhoKbOo0T7t3qKPV0nJ70zrV2YI6AWHiU 8=; X-IronPort-AV: E=McAfee;i="5600,1067,7570"; a="74723283" Received: from ironmsg03-l.qualcomm.com ([172.30.48.18]) by sabertooth01.qualcomm.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Sep 2014 12:40:50 -0700 X-IronPort-AV: E=Sophos;i="5.04,581,1406617200"; d="scan'208";a="741956057" Received: from nasanexhc06.na.qualcomm.com ([172.30.48.21]) by Ironmsg03-L.qualcomm.com with ESMTP/TLS/RC4-SHA; 23 Sep 2014 12:40:40 -0700 Received: from NASANEXM01F.na.qualcomm.com (172.30.48.1) by nasanexhc06.na.qualcomm.com (172.30.48.21) with Microsoft SMTP Server (TLS) id 14.3.181.6; Tue, 23 Sep 2014 12:40:39 -0700 Received: from resnick2.qualcomm.com (10.80.80.8) by NASANEXM01F.na.qualcomm.com (10.46.201.192) with Microsoft SMTP Server (TLS) id 15.0.913.22; Tue, 23 Sep 2014 12:40:25 -0700 Message-ID: <5421CCA6.8000001@qti.qualcomm.com> Date: Tue, 23 Sep 2014 14:40:22 -0500 From: Pete Resnick User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv:1.9.1.9) Gecko/20100630 Eudora/3.0.4 MIME-Version: 1.0 To: JFC Morfin References: <20140923000755.411AC1A6F87@ietfa.amsl.com> In-Reply-To: <20140923000755.411AC1A6F87@ietfa.amsl.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.80.80.8] X-ClientProxiedBy: nasanexm01a.na.qualcomm.com (129.46.53.228) To NASANEXM01F.na.qualcomm.com (10.46.201.192) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/7Hy9nCRbBhv7Z9LRUvNKuuuHOAQ Cc: "ianaplan-chairs@tools.ietf.org" , "Leslie Daigle \(TCE\)" , Marc Blanchet , iab@iab.org, "iucg@ietf.org" , iesg@ietf.org Subject: Re: [iucg] [Ianaplan] IANAPLAN virtual meeting 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: Tue, 23 Sep 2014 19:40:53 -0000 On 9/22/14 7:07 PM, JFC Morfin wrote: > A. This charter states both: > > 1. "The IANAPLAN working group is chartered to produce an IETF > consensus document that describes the expected interaction between the > IETF and the operator of IETF protocol parameters registries." This > implies (as the context clearly shows it) that a single operator is to > be considered. > > 2. The working group will assume that the following documents will > continue to be in effect: ... RFC 6220 - Defining the Role and > Function of IETF Protocol Parameter Registry Operators. > > Point 1 considers a single operator, something that point 2 formally > contradicts in considering and pertinently documenting the need for > multiple operators. This is a mis-reading of the title of RFC 6220. It does not say, "Defining the Role and Function of *the* IETF Protocol Parameter Registry Operators". If you read the document, you will realize that it is referring to the role and function of *present or future* operators, but always takes as given that there will be a single operator at any one time. There is no contradiction or ambiguity here. On this you simply made an error in reading. pr -- Pete Resnick Qualcomm Technologies, Inc. - +1 (858)651-4478 From nobody Tue Sep 23 15:59:41 2014 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 73B2D1A8954; Tue, 23 Sep 2014 15:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YvY9rcah_P1h; Tue, 23 Sep 2014 15:59:38 -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 9272B1A8907; Tue, 23 Sep 2014 15:59:38 -0700 (PDT) Received: from 65.104.14.81.rev.sfr.net ([81.14.104.65]:55211 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XWZ3Y-00013F-KG; Tue, 23 Sep 2014 15:59:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 24 Sep 2014 00:59:35 +0200 To: Pete Resnick ,JFC Morfin From: JFC Morfin In-Reply-To: <5421CCA6.8000001@qti.qualcomm.com> References: <20140923000755.411AC1A6F87@ietfa.amsl.com> <5421CCA6.8000001@qti.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/-cOjnFHXL0ltbEh--Vqp8uTUiV8 Cc: "ianaplan-chairs@tools.ietf.org" , "Leslie Daigle \(TCE\)" , Marc Blanchet , iab@iab.org, "iucg@ietf.org" , iesg@ietf.org Subject: Re: [iucg] [Ianaplan] IANAPLAN virtual meeting 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: Tue, 23 Sep 2014 22:59:39 -0000 At 21:40 23/09/2014, Pete Resnick wrote: >On 9/22/14 7:07 PM, JFC Morfin wrote: >>Point 1 considers a single operator, something that point 2 >>formally contradicts in considering and pertinently documenting the >>need for multiple operators. > >This is a mis-reading of the title of RFC 6220. It does not say, >"Defining the Role and Function of *the* IETF Protocol Parameter >Registry Operators". If you read the document, you will realize that >it is referring to the role and function of *present or future* >operators, but always takes as given that there will be a single >operator at any one time. > >There is no contradiction or ambiguity here. On this you simply made >an error in reading. Dear Pete, I certainly accept your point as a possibility. However my re-reading of RFC 6220 definitely differs from yours. This is the essence of every debate. Yet, in this case I do not think it makes a real difference for two reasons. : 1. The RFC 6229 introduction states: "For each IETF protocol parameter, it is current practice for the IETF to delegate the role of Protocol Parameter Registry Operator to a nominated entity. This document provides a description of, and the requirements for, these delegated functions." The text says "to a nominated entity" not "to the same/a unique nominated entity". When it says "these delegated functions" it does not imply they are delegated to the ***same*** entity (because there would be a good reason for it to be the same). My point is not that there MUST be several operators at the same time, but that there MAY be several operators, and that the RFC 6220 does not want to preclude such a possibility. I therefore credit the IETF for its RFC 6220 to be consistent with the joint OpenStand paradigm (RFC 6852) which does not pay a particular attention to the "formal status" of the global communities standards (what implies several possible parameter tables). Please note that if I was not correct, what could be the case but what I do not genuinely believe,.this would only mean the RFC 6220 is not consistent with the RFC 6852 paradigm for standards. This would only call for an RFC 6220bis to adjust to the RFC 6852 paradigm. I therefore thank you for rising the point. Should I have to appeal the IESG against a Chairs' refusal to work first on the clarification of the Charter, I would have to add this additional consistency preoccupation. 2. The existing situation is that there already are several concurrent Norms, Names and Numbers information centers for IETF and non-IETF protocols used on the Internet by the Internet users (please remember that my lead concern is the Internet use). If RFC 6220 is unable to provide help in this area, this would mean that this WG is the one to provide guidance to the community on the concerned points. In such a case, I wish this WG to ask first IAB guidance on this situation, according to a least confusion precaution. In both cases striving to protect the past status-quo, as Leslie has formally stated it, would IMHO not only be inadequate, put the network in jeopardy, but also oppose the Charter. This is certainly only my opinion; concerning the IETF/WG/IANAPLAN responsibilities and the opinion of those I share the concerns. jfc From nobody Wed Sep 24 15:49:42 2014 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 88EF41A1B8B; Mon, 22 Sep 2014 18:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001] 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 NlqFLpF8UNxA; Mon, 22 Sep 2014 18:58:27 -0700 (PDT) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CE871A03A5; Mon, 22 Sep 2014 18:58:27 -0700 (PDT) Received: from angora-2.local ([::ffff:173.71.212.143]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,128bits,AES128-SHA) by zeke.ecotroph.net with esmtp; Mon, 22 Sep 2014 21:58:24 -0400 id 00060002.5420D3C1.00006939 Message-ID: <5420D3C0.7000206@thinkingcat.com> Date: Mon, 22 Sep 2014 21:58:24 -0400 From: "Leslie Daigle (TCE)" Organization: ThinkingCat Enterprises User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: JFC Morfin , Marc Blanchet References: <20140923004910.C34E1A0647@zoidberg.ecotroph.net> In-Reply-To: <20140923004910.C34E1A0647@zoidberg.ecotroph.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/zrjz9IxHtT0OOCgxijTWDh26ah8 X-Mailman-Approved-At: Wed, 24 Sep 2014 15:49:40 -0700 Cc: "ianaplan-chairs@tools.ietf.org" , iab@iab.org, iesg@ietf.org, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] IANAPLAN virtual meeting 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: Tue, 23 Sep 2014 01:58:29 -0000 M. Morfin, The appropriate time for such substantive suggestions for charter changes would have been during the initial WG chartering process. At this time, the status quo is in fact what the WG is chartered to ensure, and what the WG chairs will be pursuing unless or until the IESG directs us otherwise. Leslie. On 9/22/14 8:07 PM, JFC Morfin wrote: > At 15:46 22/09/2014, Marc Blanchet wrote: >> The IANAPLAN WG will hold a 2 hour interim virtual meeting October >> 6th, 10h00am Eastern. The main agenda item is the first deliverable of >> the working group, where an individual draft will be discussed and >> reviewed to be adopted by the working group. > > Marc and Leslie, > > Prior to this virtual global meeting, I would like to request an > IANAPLAN IETF/WG charter update in two directions. > > A. This charter states both: > > 1. "The IANAPLAN working group is chartered to produce an IETF consensus > document that describes the expected interaction between the IETF and > the operator of IETF protocol parameters registries." This implies (as > the context clearly shows it) that a single operator is to be considered. > > 2. The working group will assume that the following documents will > continue to be in effect: ... RFC 6220 - Defining the Role and Function > of IETF Protocol Parameter Registry Operators. > > Point 1 considers a single operator, something that point 2 formally > contradicts in considering and pertinently documenting the need for > multiple operators. This calls for a clarification, not only due to the > demanded contradiction, but because I am most probably not alone among > Libre and States R&D organizations (RDOs) in planning: > > a. to draft within the coming months the description of a general > internet model, > - addressing the second motivation of the IEN 48, 1978 Vint Cerf's > ARPANET internetworking project (better known as the internet project > embodied by the IETF) > - that would be compliant with the RFC 6220 text and rationale in > extending its MDRS (metadata registry system) support of the IEN 48 > first motivation documentation (IANA) > - to every "new networking technology to be introduced into the existing > catenet while remaining functionally compatible with existing systems" > in order to "allow[] for the phased introduction of new and obsolescence > of old networks without requiring a global simultaneous change". > > b. to develop, test, and deploy MDRS tools in order, > - to permit Virtual Glocal Networks (VGNs) (i.e. conforming to the IEN > 48 "loose sense" of the local meaning "peculiar to the particular > network" rather than "a network of limited geographic extent.") > - to operate their own Information Centers (VGNICs) for the > Administration of their Names and Numbers (the MYCANN project in my case), > - at least - outside of any other consideration - in order to have > available a failsafe plan for their net in case of ICANN failure, > unaccountable divergence or incapacity to keep coordinated the RFC 6852 > multi-global community landscape. > > B. Since 1977, the US (FCC and then NTIA) as a single point of network > failure was a reliable enough situation that RFC 6852 is dissolving and > the NTIA is going to terminate on Sept. 30, 2015. > > The mission of the IETF is to make sure that the end to end datagram > exchanges can continue to perform in a the new context "where the > economics of global markets, fueled by technological advancements, drive > global deployment of standards regardless of their formal status" so its > "standards support interoperability [and] foster global competition", > even in the case they "are [only partly] voluntarily adopted globally". > > I do not think this is possible if the Milestones are not reviewed in > order to permit a seamless transition by Sept. 30, 2015. To that end, > the WG/IANAPLAN RFC(s) should be published by May 31, 2015. This implies > an IETF general final call by April 30, 2015 and WG final call by March > 31, 2015. > > The charter must not appear as an incitement to the status quo while > criticality is a possibility, and this way to legitimate > self-organization that is not concerted. > > jfc > > > . > > > > > > > > > > -- ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises ldaigle@thinkingcat.com ------------------------------------------------------------------- From nobody Wed Sep 24 16:36:57 2014 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 BAE5D1A1B44; Wed, 24 Sep 2014 16:36:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.631 X-Spam-Level: * X-Spam-Status: No, score=1.631 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fs9gaiIURmgf; Wed, 24 Sep 2014 16:36:55 -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 C48A81A1A69; Wed, 24 Sep 2014 16:36:55 -0700 (PDT) Received: from 65.104.14.81.rev.sfr.net ([81.14.104.65]:53447 helo=GHM-SAM.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XWw7C-0000jN-BE; Wed, 24 Sep 2014 16:36:54 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 25 Sep 2014 01:36:58 +0200 To: S Moonesamy ,Jefsey , ianaplan@ietf.org From: JFC Morfin In-Reply-To: <6.2.5.6.2.20140924101409.0b1efd88@elandnews.com> References: <541868C8.4090301@thinkingcat.com> <5421DAB8.1090604@thinkingcat.com> <6.2.5.6.2.20140923141757.0b337680@resistor.net> <201409241612.s8OGC7Zd014807@mx.elandsys.com> <6.2.5.6.2.20140924101409.0b1efd88@elandnews.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: intl+dot.dj/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/598WGRqnE-yF6bZzMKU6hfTIQUA Cc: "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Summary/refinement of scenarios discussed so far (was Constructive redirect -- focusing discussions) 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, 24 Sep 2014 23:36:56 -0000 At 19:58 24/09/2014, S Moonesamy wrote: >At 09:11 24-09-2014, Jefsey wrote: >>This calls for two remarks : >> >>1. To my knowledge the charter does not specify two communities. > >Strictly speaking , the above is correct. > >>I want to make clear that I belong the Internet Users Community and >>I speak as one of its member, i.e. as an "IETF Customer" as we are >>sometimes inadequately qualified in some texts. The interests of my >>community were traditionnally supposed to be conveniently >>represented by the US procurement process and the quality of its >>obtained deliveries guaranteed by the expertise of its Contracting Officers. > >Ok. > >>2. The Chair states that "there is no such proposal yet. When they >>will be ready, we will review them". >> >>This is an important change from the Charter and only says that the >>WG may review and comment them. > >The WG Charter is at >https://datatracker.ietf.org/wg/ianaplan/charter/ I do not view >that sentence from the WG Chair as a change. As explained I used your mail because it listed the pending points. My evaluations are mine. They do not claim to be yours. The charter says "may", the chair says "will". The charter says "communities", it is now agreed there are not only two communities. It therefore means that a I_D presented by the IUse community will be discussed. This is a step in the good direction. >>This "status-quo" position is clearly stated by the chairs. It >>opposes every possibility of innovation or the discussion of >>special cases resulting from IUse, Name and Numbers communities >>where names, numbers and parameters could be entangled. > >My view is that the WG Chair clarified what the discussion was about >in response to what I asked. I did not ask about "status-quo". Again my evaluations are mine and do not claim to be yours. I did ask a review of the charter. The co-chair responded the WG would follow a "status-quo" line unless directed otherwise by the IESG. Members of my community therefore call for this WG to discuss a Charter review with the IESG in order to make it consistent with the context of our reality, as we believe it differs from the ICANN virtuality. This is an effort toward a concerted dialog and in order to avoid the complication of an appeal against a far too restrcitive Charter, in the post WCIT international political context and the observed insidious NTIA question creep from DNS class "IN" root file oversight to IANA functions. jfc >Regards, >S. Moonesamy From nobody Fri Sep 26 08:20:59 2014 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 94FF01A896C; Fri, 26 Sep 2014 08:20:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.231 X-Spam-Level: ** X-Spam-Status: No, score=2.231 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, MISSING_MID=0.497] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-fQpunnoxy9; Fri, 26 Sep 2014 08:20:44 -0700 (PDT) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1947B1A897C; Fri, 26 Sep 2014 08:20:44 -0700 (PDT) Received: from 65.104.14.81.rev.sfr.net ([81.14.104.65]:6480 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.82) (envelope-from ) id 1XXXK6-0004Z1-Ui; Fri, 26 Sep 2014 08:20:43 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 26 Sep 2014 17:20:31 +0200 To: "ianaplan@ietf.org" From: JFC Morfin Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/fl8M7RhBoSxaCCbTDpmYLoxS1hw Cc: iab@iab.org, "iucg@ietf.org" , iesg@ietf.org Subject: [iucg] The RFC 6852 paradigm. 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, 26 Sep 2014 15:20:45 -0000 Dear all, It seems that we have reached the crux of the whole problem: the lack of an ultimate technical referent in RFC 6852 to decide from its reading of the global communities' market economic consensual requirement(s). The paradigm is not a paradigm because it is divisive rather than consensual. We, therefore, meet four positions: - There is a paradigm. - There is not a paradigm. - There was a paradigm. - What is the paradigm? - I have my reading of the paradigm. - Who is reponsible ? - What next? 1. There is a paradigm. =============== At 21:40 23-09-2014, Eliot Lear wrote: We do not single out the IANA registry. Rather ALL of our decisions should follow that framework. See RFC 6852 that the IAB released in January of 2013, as mentioned in our current draft. 2. There is not a paradigm. ================= At 09:11 25/09/2014, S Moonesamy wrote: I do not think that the reference is appropriamte as the document has not been subject to IETF review and approval. 3. There was a paradigm. ================ At 02:06 25/09/2014, Brian E Carpenter wrote: Now that's a good question. I'm thinking that if a parameter space was created by IETF action (or by the IETF's predecessors, since there are things here that date back before 1986) then logically the IETF should contract for the *existence* of the whole registry, even if some parts of the registry are no longer populated under IETF technical direction. But I don't think the IETF should be held responsible for the *contents* of those parts of the registry. (IANAL, so I will not attempt to discuss how this should be expressed in formal language.) Brian, I certainly agree with this, but what if: the IETF modifies a registry framework. Or, worse, what if the IETF adapts to a foreign registry? Then what if the SDO defining this foreign registry modifies its framework? The whole issue, IMHO, is that we do not have to adapt the past ("status quo") but rather to adapt to the (1) ***possible*** what is quite complex, starting with the (2) ***probable*** I am a part of who is willing to cooperate. 4. What is the paradigm? ================ Up to now, I only could appeal against RFC 6852, and it was easy for IESG and IAB to oppose my appeals forcing me to escalate to ISOC. The NTIA did it its own way faster than me. Now, the co-chairs have given me a double opportunity to make the IETF decide if the RFC 3539 is subject to RFC 6852, and how, or not. In, 1. as suggested by the first co-Chair, appealing to the IESG against the Charter itself on the ground that, as she reads it, it would be pro-ante-RFC 6852 status quo oriented. 2. to introduce an IUse (RFC 6852 global) community draft for this WG, that the second co-chair promised this WG will discuss. 5. Note on my reading of RFC 6852 ======================== For everything to be clear: - I approve the pragmatic diagnosis of RFC 6852. - I am concerned by its lack of definition of a "global community" vs. a "local network" as defined by IEN 48. - I disapprove of its lack of solution, i.e. a conflict resolution strategy. My pre-IEN 48 position has not changed for 37 years: an aggregate of relational spaces VGNs by the users for the users. I am pretty confident that this is the solution that will emerge from all this because: - I directed it from 1984 to 1986 and I, therefore, saw it work. - it was - only financially/politically but not architecturally - "attenuated" along the, now removing itself (cf. OpenStand, Dubai, Snowden, Montevideo, NTIA, Sao Paulo, Geneva), "Being Unilaterally Global" "status quo" strategy. - this removal may be enticed by technology, or the technology is freed by this removal, I do not know. However, as a small local digital services provider my need is for an SDN technology mix that I need to be compatibly designed, documented, and supported. I am certainly looking for an NDN oriented IANA service architecture and protocol for my intelligent village's VGN. I hope we can document this in coming months. [SDN]: Software Designed Network [NDN]: Named-Data.Network [VGN]: Virtual Glocal Network, as in US VGN (I*core governed Internet). 6. The IETF responsibility ================= From a local IUser point of view, the IETF is not the single technology source in town. It is not even the main one. Most people do not give a damn about ICANN. However, the whole multitude has been used to entrust its QA to the US procurement process. This has led to the confusion of the IUse, unstructured by nature, community and NTIA. The current process is not to transfer anything from NTIA to ICANN. It is to transfer from the IUse NTIA responsibility to the IUse community. The emergence of which has to be far better helped. All I am trying to do is to clumsily obtain and gather that help, and to help protect the IUse community from the deepest mistakes I may spot. A purely precautionary attempt. The I*core and USG adaptation to the current political, financial, and technological reality through RFC 6852 and the March 14 announcement are pragmatic enough to be of use. However, the digital IUse community still has to find a replacement for the NTIA other than the suggested US jurisdiction (due to the US localization of the internet de facto governance bodies). I only wish that a few American IUsers more would better understand the real stakes. Their best interest, just as is everyone else's best interest, must be kept neutral to an autonomous ICANN vote to transfer anywhere outside of the US and adopt a BoD and staff continent, nationality, and language democratic numerus clausus. Mr. Lawrence E. Strickling is trying to best protect the US digital interests in transferring the IANA/DNS oversight from the US Executive Branch to the US Legislative branch. This is not adequate, however, because no national bias will be able to architecturally resist his unleashing of the IUse multitude. We all know it very well from the NAT experience. Therefore, it is up to us to help the multitude to adequately organize the criticality that he has triggered. Otherwise, Mr. Lawrence E. Strickling will be the one who killed the TCP/IP internet. Perhaps this is a carefully planned disruptive innovation move. Maybe it isn't. However, this will be this WG's decision. 7. Follow-up ======= Anyway, my recent mails have built-up the content of an appeal to the IESG/IAB guidance and, maybe, to a community decision, IRT. - the consistency of the RFC 6852 paradigm with the IETF RFC 3935 mission statement, - its practical and precautionary articulation, on a multistakeholder basis involving all the global communities, including the post-NTIA IUse community. - the ultimate technological referent, - the common technological and operational use documentation of reference for network engineers, software designers, and lawmakers. There is no mystery. The World Digital Ecosystem has a need. NTIA states that such a need cannot be addressed by Governments alone. If engineers cannot address it alone either, it becomes a common citizen cause to be addressed by our multitude and the necessary steps must be discussed, concerted, and engaged. jfc