From nobody Tue Dec 2 05:22:15 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 5F6481A1B5A; Tue, 2 Dec 2014 05:22:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.067 X-Spam-Level: X-Spam-Status: No, score=-0.067 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_BODY_HIGH_NO_MID=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_BACKHAIR_35=1, 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 tbbD5Bb2FTtT; Tue, 2 Dec 2014 05:22:08 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B053B1A1A90; Tue, 2 Dec 2014 05:22:08 -0800 (PST) Received: from 54.3.14.81.rev.sfr.net ([81.14.3.54]:2881 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1XvnP4-0004W6-Ep; Tue, 02 Dec 2014 05:22:07 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 02 Dec 2014 14:21:42 +0100 To: John Curran , "Ianaplan@Ietf. Org" From: Jefsey In-Reply-To: <928E5B72-73EC-4A56-8271-EA344E5A89A9@istaff.org> References: <928E5B72-73EC-4A56-8271-EA344E5A89A9@istaff.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_625197594==.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/9dRtb8sJi-hxXCkB582Ie-fPTqQ Cc: "comptoir@cafedu.com" , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] Public Consultation and Webinars Announced: "CWG On Naming Related Functions Public Consultation on Draft Transition Proposal" 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, 02 Dec 2014 13:22:12 -0000 --=====================_625197594==.ALT Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit John, Thank you for this. Nature hates vacuums. Three vacuums are being created. 1. coordination between technologies - TCP/IP and non-TCP/IP 2. removal of NTIA sovereign sponsoring of the unique authoritative root lie. 3. RFC 6852 needed referent about the economic requirements for technologies. ICANN wants to fill them with the WEF sponsoring for the economic issues. jfc At 02:51 02/12/2014, John Curran wrote: >IETF IANAplan folks - > >I note that the CWG On Naming Related Functions has called for >"Public Consultation on >on Draft Transition Proposal” and this contains several questions >that may be relevant to >the IETF community, including - > >>"- Who should have standing with the independent Appeals Panel? >>(section 3.4.3.2 of this document) – The CWG recommends that all >>decisions and actions (including deliberate inaction) of the IANA >>Functions Operator that affect the Root Zone or Root Zone WHOIS >>database be subject to an independent and binding appeals panel. >>The Appeals Mechanism should also cover any policy implementation >>actions that affect the execution of changes to the Root Zone File >>or Root Zone WHOIS and how relevant policies are applied. Where >>disputes arise as to the implementation of "IANArelated policies.” > >This process could end up being proposed the governing alternative >to RFC 2860 MOU >dispute resolution process in circumstances where the application of >"IANArelated policies" >from the IETF, e.g. DNS reserved entries, intersect gTLD policy in >an contested manner. > >>"- Key contracting provisions – the end of Section 3 refers the >>reader to Annex 5, which presents key provisions which would be >>required to be in the first contract between ICANN and the new >>contacting entity "Contract Co.". A number of these provisions come >>from the current NTIA IANA Functions Contract and are proposed to >>be retained in the new contract, either in original or modified >>form. Several of these provisions include options or questions on >>which the CWG would also appreciate receiving input.…β€œ > >Note that these CWG proposed contracting arrangements may include >items outside of the >scope of naming which would require coordination to establish. As >an example, per the CWG >Draft proposal - "Regarding function 9, the Customer Service >Complaint Resolution Process (CSCRP), and the implementation of >performance modifications referred to in function 11, the CWG >anticipates that the NRO/ASO and IETF may also have proposals in >these areas, and the CWG will exchange information, collaborate and >develop joint proposals with them on these issues as appropriate.” > >>"Input on a specific (ICANN) alternative solution >>The CWG is also seeking input on a specific alternative option, >>which has been raised within the CWG, which envisages all NTIA >>responsibilities being transferred to ICANN. This option would >>require an increase in ICANN accountability to its constituent >>communities and require the adoption of binding arbitration >>mechanisms (such recommendations may be beyond the scope of the CWG >>and probably rest with the CCWG on ICANN Accountability or other >>groups). Note that this integrated option would impact the future >>ease or ability to tender for another IANAFunctions Operator (other >>than ICANN). However, to ensure there has been a proper >>consideration of this option, the CWG, would appreciate input from >>the community regarding support, or not, for this concept. " > >Attached is the announcement on the CWG on Naming Related Functions >Public Consultation >on the Draft Transition Proposal, including Webinar arrangements >that they have provided for >in the next 3 days to receive feedback. > >FYI, >/John > >Disclaimer: my views alone. > > >Begin forwarded message: >> >>From: Grace Abuhamad >><grace.abuhamad@icann.org> >>To: "ianatransition@icann.org" >><ianatransition@icann.org> >>Date: December 2, 2014 at 5:07:35 AM GMT+4 >>Subject: [ianatransition] Webinars Announced: CWG On Naming Related >>Functions Public Consultation on Draft Transition Proposal >> >>To view the original post, please see: >>https://www.icann.org/news/announcement-3-2014-12-01-en >> >> >> >>WEBINAR: Cross Community Working Group (CWG) On Naming Related >>Functions Public Consultation on Draft Transition Proposal >> >> >> >>Following the request of the National Telecommunications and >>Information Administration (NTIA) forICANN to "convene a >>multistakeholder process to develop a plan to transition the U.S. >>government stewardship role" with regard to the IANA Functions and >>related root zone management, a Cross Community Working Group (CWG) >>was tasked with developing a consolidated transition proposal for >>the elements of the IANA Functions relating to the Domain Name >>System (DNS). The CWG has now published its draft transition >>proposal for >>public >>comment. Comments can be submitted until 22 December at 23:59 UTC. >> >>In order to brief the community on the contents on this draft >>transition proposal and encourage community feedback, the CWG will >>be organizing three identical webinars at different times to >>facilitate participation across time zones. The webinars will take place on: >> * 3 December from 7:00 – 8:30 UTC (time zone converter >> here) >> >> * 4 December from 12:30 – 14:00 UTC (time zone converter >> here) >> >> * 4 December from 16:00 – 17:30 UTC (time zone converter >> here) >> >> >>---------- >>Webinar Details & How to Attend >> >>The webinars will be run in an >>Adobe Connect room. If you >>are interested in attending the webinar and would like to receive >>dial-in details, please send an email to >>grace.abuhamad@icann.org and >>indicate which day / time you would like to attend the webinar. >>Please note that the webinar will be conducted in English and will >>be recorded and transcribed. Subsequently the transcripts will be >>translated in the 5 UN languages and posted on the CWG Wiki >>here. >> >>---------- >>The Draft Transition Proposal >> >>The CWG structured its draft transition proposal based on the IANA >>Stewardship Transition Coordination Group (ICG) Request for >>Proposals. These are: >>>1 Description of Community's Use of IANA Functions >>>2A Existing, Pre-Transition Arrangements – Policy Sources >>>2B Existing, Pre-Transition Arrangements – Oversight and Accountability >>>3 Proposed Post-Transition Oversight and Accountability Arrangements >>>4 Transition Implications >>>5 NTIA Requirements >>>6 Community Process >> >>Sections 1, 2A and 2B describe the current situation. >> >>Section 3, which is the heart of the transition proposal, is still >>a work in progress as not all details have been ironed out as of >>the publication of this consultation. Although lacking some >>details, the information provided in this section should be >>sufficiently detailed to allow the communities to comment on all >>key components. In summary, section 3 proposes the creation of 4 >>new entities to replace the current NTIAarrangements. These are: >> * Contract Co. – This primary function of this entity (likely a >> non-profit corporation) is to be signatory to the contract with >> the IANA Functions Operator. This entity should be lightweight and >> have little or no staff. >> * Multistakeholder Review Team (MRT) – The MRT would be a >> multi-stakeholder body with formally selected representatives from >> all of the relevant communities (exact composition TBD). The >> operation of the MRT would be based on the concept of maximum >> public transparency. The responsibilities of the MRT will include: >> * Developing the detailed contract terms for the agreement >> between Contract Co. and theIANA Functions Operator, based on the >> key contract terms proposed as part of this proposal and set forth as Annex 3 >> * Making key decisions for Contract Co. (e.g., whether or >> not to enter into a rebidding (RFP) process for the operation of >> the IANA Naming Functions) >> * Conducting the IANA Functions Operator Budget Review >> * Addressing any escalation issues raised by the Customer >> Standing Committee (CSC) including the possibility of engaging in enforcement >> * Performing certain elements of administration (including >> periodic performance reviews) currently set forth in the IANA >> Functions Contract and currently being carried out by theNTIA >> * Managing a re-contracting or rebidding (RFP) process for >> the operation of the IANAFunctions, both as an enforcement option >> and as part of a regular rebidding procedure >> The CWG is in the process of discussing whether there is an >> additional enforcement role for the MRT related to policy >> implementation by the IANA Functions Operator; specifically, >> whether the MRT should be able to commence a proceeding before the >> Independent Appeals Panel. >> * Customer Standing Committee (CSC) – While the exact >> composition is still to be determined, the CSC would primarily be >> made up of a number of representatives of registry operators, >> including ccTLD and gTLD registries. Input from the CSC would feed >> into and inform the work of the MRT. It is possible that the CSC >> would also include additional individuals with relevant expertise >> and/or liaisons (or representatives) from other SO/ACs. The CSC would: >> * Work with the MRT to establish Service Levels and >> Performance Indicators for the performance of the IANA Naming Functions >> * Receive reports from the IANA Functions Operator >> including regular performance reports. >> * Review these reports against established service levels >> and escalate any significant issues to the MRT >> * Independent Appeals Panel (IAP) – The CWG recommends that all >> IANA actions which affect the Root Zone or Root Zone WHOIS >> database be subject to an independent and binding appeals panel. >> The Appeals Mechanism should also cover any policy implementation >> actions that affect the execution of changes to the Root Zone File >> or Root Zone WHOIS and how relevant policies are applied. This >> need not be a permanent body, but rather could be handled the same >> way as commercial disputes are often resolved, through the use of >> a binding arbitration process using an independent arbitration >> organization (e.g., ICDR, ICC, AAA) or a standing list of >> qualified people under rules promulgated by such an organization. >> >>Sections 4, 5 and 6 are currently in development and are directly >>dependent on the final choices that will be made for section 3. >> >>For further details, you are encouraged the review the draft >>transition proposal in its entirety, >>availablehere. >> >>---------- >>Further information >> >>For further information about the CWG's work, please see >>https://community.icann.org/x/37fhAg. >> >>For further information about the ICG and the IANA Stewardship >>Transition, please >>seehttps://www.icann.org/stewardship. >>_______________________________________________ >>ianatransition mailing list >>ianatransition@icann.org >>https://mm.icann.org/mailman/listinfo/ianatransition > >_______________________________________________ >ianaxfer mailing list >ianaxfer@nro.net >https://www.nro.net/mailman/listinfo/ianaxfer >_______________________________________________ >Ianaplan mailing list >Ianaplan@ietf.org >https://www.ietf.org/mailman/listinfo/ianaplan --=====================_625197594==.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: 8bit John,
Thank you for this.
Nature hates vacuums. Three vacuums are being created.

1. coordination between technologies - TCP/IP and non-TCP/IP
2. removal of NTIA sovereign sponsoring of the unique authoritative root lie.
3. RFC 6852 needed referent about the economic requirements for technologies.

ICANN wants to fill them with the WEF sponsoring for the economic issues.
jfc

At 02:51 02/12/2014, John Curran wrote:
IETF IANAplan folks -

I note that the CWG On Naming Related Functions has called for "Public Consultation on 
on Draft Transition Proposal” and this contains several questions that may be relevant to
the IETF community, including - 

"- Who should have standing with the independent Appeals Panel? (section 3.4.3.2 of this document) – The CWG recommends that all decisions and actions (including deliberate inaction) of the IANA Functions Operator that affect the Root Zone or Root Zone WHOIS database be subject to an independent and binding appeals panel. The Appeals Mechanism should also cover any policy implementation actions that affect the execution of changes to the Root Zone File or Root Zone WHOIS and how relevant policies are applied. Where disputes arise as to the implementation of "IANArelated policies.”  

This process could end up being proposed the governing alternative to RFC 2860 MOU
dispute resolution process in circumstances where the application of "IANArelated policies"
from the IETF, e.g. DNS reserved entries, intersect gTLD policy in an contested manner.

"- Key contracting provisions – the end of Section 3 refers the reader to Annex 5, which presents key provisions which would be required to be in the first contract between ICANN and the new contacting entity "Contract Co.". A number of these provisions come from the current NTIA IANA Functions Contract and are proposed to be retained in the new contract, either in original or modified form. Several of these provisions include options or questions on which the CWG would also appreciate receiving input.…β€œ

Note that these CWG proposed contracting arrangements may include items outside of the
scope of naming which would require coordination to establish.  As an example, per the CWG
Draft proposal -  "Regarding function 9, the Customer Service Complaint Resolution Process (CSCRP), and the implementation of performance modifications referred to in function 11, the CWG anticipates that the NRO/ASO and IETF may also have proposals in these areas, and the CWG will exchange information, collaborate and develop joint proposals with them on these issues as appropriate.”

"Input on a specific (ICANN) alternative solution
The CWG is also seeking input on a specific alternative option, which has been raised within the CWG, which envisages all NTIA responsibilities being transferred to ICANN. This option would require an increase in ICANN accountability to its constituent communities and require the adoption of binding arbitration mechanisms (such recommendations may be beyond the scope of the CWG and probably rest with the CCWG on ICANN Accountability or other groups). Note that this integrated option would impact the future ease or ability to tender for another IANAFunctions Operator (other than ICANN). However, to ensure there has been a proper consideration of this option, the CWG, would appreciate input from the community regarding support, or not, for this concept. "

Attached is the announcement on the CWG on Naming Related Functions Public Consultation
on the Draft Transition Proposal, including Webinar arrangements that they have provided for
in the next 3 days to receive feedback.

FYI,
/John

Disclaimer:  my views alone.


Begin forwarded message:

From: Grace Abuhamad <grace.abuhamad@icann.org >
To: " ianatransition@icann.org" <ianatransition@icann.org >
Date: December 2, 2014 at 5:07:35 AM GMT+4
Subject: [ianatransition] Webinars Announced: CWG On Naming Related Functions Public Consultation on Draft Transition Proposal

To view the original post, please see: https://www.icann.org/news/announcement-3-2014-12-01-en


WEBINAR: Cross Community Working Group (CWG) On Naming Related Functions Public Consultation on Draft Transition Proposal



Following the request of the National Telecommunications and Information Administration (NTIA) forICANN to "convene a multistakeholder process to develop a plan to transition the U.S. government stewardship role" with regard to the IANA Functions and related root zone management, a Cross Community Working Group (CWG) was tasked with developing a consolidated transition proposal for the elements of the IANA Functions relating to the Domain Name System (DNS). The CWG has now published its draft transition proposal for public comment. Comments can be submitted until 22 December at 23:59 UTC.

In order to brief the community on the contents on this draft transition proposal and encourage community feedback, the CWG will be organizing three identical webinars at different times to facilitate participation across time zones. The webinars will take place on:
  • 3 December from 7:00 – 8:30 UTC (time zone converter here)
  • 4 December from 12:30 – 14:00 UTC (time zone converter here)
  • 4 December from 16:00 – 17:30 UTC (time zone converter here)
Webinar Details & How to Attend

The webinars will be run in an Adobe Connect room. If you are interested in attending the webinar and would like to receive dial-in details, please send an email to grace.abuhamad@icann.org and indicate which day / time you would like to attend the webinar. Please note that the webinar will be conducted in English and will be recorded and transcribed. Subsequently the transcripts will be translated in the 5 UN languages and posted on the CWG Wiki here.
The Draft Transition Proposal

The CWG structured its draft transition proposal based on the IANA Stewardship Transition Coordination Group (ICG) Request for Proposals. These are:
1 Description of Community's Use of IANA Functions
2A Existing, Pre-Transition Arrangements – Policy Sources
2B Existing, Pre-Transition Arrangements – Oversight and Accountability
3 Proposed Post-Transition Oversight and Accountability Arrangements
4 Transition Implications
5 NTIA Requirements
6 Community Process

Sections 1, 2A and 2B describe the current situation.

Section 3, which is the heart of the transition proposal, is still a work in progress as not all details have been ironed out as of the publication of this consultation. Although lacking some details, the information provided in this section should be sufficiently detailed to allow the communities to comment on all key components. In summary, section 3 proposes the creation of 4 new entities to replace the current NTIAarrangements. These are:
  1. Contract Co. – This primary function of this entity (likely a non-profit corporation) is to be signatory to the contract with the IANA Functions Operator. This entity should be lightweight and have little or no staff.
  2. Multistakeholder Review Team (MRT) – The MRT would be a multi-stakeholder body with formally selected representatives from all of the relevant communities (exact composition TBD). The operation of the MRT would be based on the concept of maximum public transparency. The responsibilities of the MRT will include:
    • Developing the detailed contract terms for the agreement between Contract Co. and theIANA Functions Operator, based on the key contract terms proposed as part of this proposal and set forth as Annex 3
    • Making key decisions for Contract Co. (e.g., whether or not to enter into a rebidding (RFP) process for the operation of the IANA Naming Functions)
    • Conducting the IANA Functions Operator Budget Review
    • Addressing any escalation issues raised by the Customer Standing Committee (CSC) including the possibility of engaging in enforcement
    • Performing certain elements of administration (including periodic performance reviews) currently set forth in the IANA Functions Contract and currently being carried out by theNTIA
    • Managing a re-contracting or rebidding (RFP) process for the operation of the IANAFunctions, both as an enforcement option and as part of a regular rebidding procedure
    The CWG is in the process of discussing whether there is an additional enforcement role for the MRT related to policy implementation by the IANA Functions Operator; specifically, whether the MRT should be able to commence a proceeding before the Independent Appeals Panel.
  3. Customer Standing Committee (CSC) – While the exact composition is still to be determined, the CSC would primarily be made up of a number of representatives of registry operators, including ccTLD and gTLD registries. Input from the CSC would feed into and inform the work of the MRT. It is possible that the CSC would also include additional individuals with relevant expertise and/or liaisons (or representatives) from other SO/ACs. The CSC would:
    • Work with the MRT to establish Service Levels and Performance Indicators for the performance of the IANA Naming Functions
    • Receive reports from the IANA Functions Operator including regular performance reports.
    • Review these reports against established service levels and escalate any significant issues to the MRT
  4. Independent Appeals Panel (IAP) – The CWG recommends that all IANA actions which affect the Root Zone or Root Zone WHOIS database be subject to an independent and binding appeals panel. The Appeals Mechanism should also cover any policy implementation actions that affect the execution of changes to the Root Zone File or Root Zone WHOIS and how relevant policies are applied. This need not be a permanent body, but rather could be handled the same way as commercial disputes are often resolved, through the use of a binding arbitration process using an independent arbitration organization (e.g., ICDR, ICC, AAA) or a standing list of qualified people under rules promulgated by such an organization.
    Sections 4, 5 and 6 are currently in development and are directly dependent on the final choices that will be made for section 3.

    For further details, you are encouraged the review the draft transition proposal in its entirety, availablehere.
    Further information

    For further information about the CWG's work, please see https://community.icann.org/x/37fhAg.

    For further information about the ICG and the IANA Stewardship Transition, please see https://www.icann.org/stewardship.
    _______________________________________________
    ianatransition mailing list
    ianatransition@icann.org
    https://mm.icann.org/mailman/listinfo/ianatransition

_______________________________________________
ianaxfer mailing list
ianaxfer@nro.net
https://www.nro.net/mailman/listinfo/ianaxfer
_______________________________________________
Ianaplan mailing list
Ianaplan@ietf.org
https://www.ietf.org/mailman/listinfo/ianaplan
--=====================_625197594==.ALT-- From nobody Tue Dec 9 16:43:51 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 539771A6EF0 for ; Tue, 9 Dec 2014 16:43:49 -0800 (PST) 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_15=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 8uWjwm_BEAGa for ; Tue, 9 Dec 2014 16:43:45 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C3811A6ED9 for ; Tue, 9 Dec 2014 16:43:45 -0800 (PST) Received: from 54.3.14.81.rev.sfr.net ([81.14.3.54]:57568 helo=MORFIN-PC.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1XyVNX-0003Yo-Ph; Tue, 09 Dec 2014 16:43:44 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Dec 2014 01:43:42 +0100 To: Kathy Brown ,"discuss@1net.org" 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: 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/pWb_28aHm8NZrpaFqeeEP7bViUg Cc: gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [discuss] Update: ISOC NMI 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, 10 Dec 2014 00:43:49 -0000 At 14:21 08/12/2014, Kathy Brown wrote: >I posted an update to the ISOC community last night. I wanted to >share our thinking on the NETmundial Initiative with you. Kathy, a network MUST eventually be either (de)centralized OR distributed. Whatever the details, "bottom-up" and "multistakeholderism" mean up-centralizing through a single consensus. Looking for a single consensus means the intended Governance will be Be Unilaterally Global. This is a BUG as it opposes "permissionless innovations" which require a multi-consensus Governance. i.e. based upon a few common consensuses, including that there each community proceeds by local (possibly concerted) consensuses. 1. There is a unique catenet resulting from the concatenation of all the local networks. For decades there was a "status-quo" imposed consensus (through the "unique DNS root file" fairy tale) it was under the sole TCP/IP technology and for 16 years under the sole ICANN administration placed under the NTIA oversight. 2. ISOC initiated RFC 6852 acknowledges a multitechnology internetting paradigm where the same catenet supports a technology innovatve economic competition among global communities. In RFC 6852, did not dare to clarifiy the resulting inter-technology governance. It seems that IAB trusts ISOC for shaping a new industry oriented I*Group, while the NTIA wishes ICANN to take the strategic lead and make forget the Dubai Governments vote. ICANN respects RFC 6852 in working with the Brazilian Civil Society, and calling on WEF for advising them on the economic requirents of reference for the technology - by IETF, or others. I only note that the IIC was created in march 2014, and the NDN consortium in Sept. Intra-I*group feuds are not the "Internet independant innovative involved IETF, etc users (IUsers) main interest. They know that a spontaneous order will result from their permissionless autonomous innovative use of MYCANN-Plug-ins - within their Governments legally defined accountability framework and economical strategies. JFC Morfin Facilitator IUCG >Kathy Brown > >http://www.internetsociety.org/blog/public-policy/2014/12/update-netmundial-initiative >_______________________________________________ >discuss mailing list >discuss@1net.org >http://1net-mail.1net.org/mailman/listinfo/discuss From nobody Thu Dec 11 01:10: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 C457F1ACD29; Thu, 11 Dec 2014 01:10:28 -0800 (PST) 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 6JFI2Aq8kFpi; Thu, 11 Dec 2014 01:10:24 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3C831ACD20; Thu, 11 Dec 2014 01:10:23 -0800 (PST) Received: from i15-lef01-t2-62-35-238-138.ft.lns.abo.bbox.fr ([62.35.238.138]:5325 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Xyzkz-0000Gg-Cr; Thu, 11 Dec 2014 01:09:57 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Dec 2014 10:09:52 +0100 To: Jari Arkko ,rhill@hill-a.ch From: Jefsey 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/ZdBgsNC6Lg0dW49iXcZnRTu94zI Cc: "iucg@ietf.org" , gene@iuwg.net, ietf@ietf.org, iesg@ietf.org Subject: Re: [iucg] [Ianaplan] Last Call: (Draft Response to the Internet Coordination Group Request for Proposals on the IANA protocol parameters registries) to Informational RFC X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 09:10:29 -0000 At 11:27 10/12/2014, Jari Arkko wrote: >Richard, > > On 27 November, I requested that the co-chairs provide a justification for > > the conclusion that rough consensus has been achieved, see: > > > > http://www.ietf.org/mail-archive/web/ianaplan/current/msg01402.html > > > > The requested justification has not yet been provided. Richard, The justification has not yet been provided, and my intent to appeal any decision based upon a text that does not address the charter, as this is the case, has not been reported. Things settle by sontaneous order or self-organized criticality, depending on the way they have been metaprepared. The only thing which can now be done is to smooth the well engaged criticality in making things clear about permissionless innovation, something BCP 78 opposes and RFC 6852 presupposes. Elements of this criticality are, among others, the NTIA/ISOC opposition (ICANN has been given the lead of what ISOC has prepared), the WEF involvement, IIC http://www.industrialinternetconsortium.org/, the inconsideration of Libre (and of the "MYCANN-plug-ins"), the disregard of the WCIT vote, Rosettanet, the transition from Executive to Legislative and Justice under an unclear virtual territory jurisdiction extending to some kinds of private/personal sovereignties (through multistakeholderism where "everyone is on an equal footing"). In a nutshell the multitechnological use of the common catenet has been blocked for 30 years by the internet status-quo strategy. The infant Governance is only still unprepared to switch to the regular permissionless innovation internet system, jfc From nobody Mon Dec 15 03:45:35 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 5A4E61A1B48; Mon, 15 Dec 2014 03:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MISSING_MID=0.497] 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 Z8dL_WT70QRu; Mon, 15 Dec 2014 03:45:32 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C7111A1B4E; Mon, 15 Dec 2014 03:45:32 -0800 (PST) Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:53149 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y0U5i-0002mQ-0g; Mon, 15 Dec 2014 03:45:30 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 15 Dec 2014 12:45:19 +0100 To: Eliot Lear ,"ianaplan@ietf.org" , iesg@ietf.org From: Jefsey In-Reply-To: <548E9814.1090208@cisco.com> References: <548E9814.1090208@cisco.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_378368163==.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/xA07XBURFzGNtvmX0PaEIZL2y5o Cc: Adrian Farrel , IAB , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [Ianaplan] one final last call comment on draft-ietf-ianaplan-icg-response X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 11:45:34 -0000 --=====================_378368163==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed At 09:13 15/12/2014, Eliot Lear wrote: >Obviously this needs to get filled in. Jari and I are working on >doing just that. This will be documentary in nature, much like the >shepherd write-up. I certainly welcome Adrian Farrel's points as I share his support of RFC 6852 (with the restriction concerning its technical accountability framework). Everything which will make this document clearer and more in line with the currently identified standardization paradigm is extremely welcome. In addition, I already underlined the shepherd write-up is uncomplete, as it does not mention my intent to appeal an IESG approbation of the intended RFC, if it did not include as a clear section of a disclaimer by IESG or/and an IAB, or/and an ISOC A. regarding the ultimate nature of this text I consider as a double IAB abdication (if there is a real IETF consensus about it, people are entitled to see it printed): 1. of its leading role and responsibility in the internet governance cross-accountability framework (the reason of my appeal concering RFC 6852 delayed by the NTIA annoucement) 2. obliging internet users (IUsers) to distrust the NTIA plans and technically migrate to DNS zones outside of the ICANN oversight without the sufficient prelimnary guidance of the IAB they are entitled to. B. regarding its violations of the charter: 1. as a letter to an ICANN group rather than an IETF statement. 2. its lack of consideration of the IUWG contribution at: http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.03.pdf jfc --=====================_378368163==.ALT Content-Type: text/html; charset="us-ascii" At 09:13 15/12/2014, Eliot Lear wrote:
Obviously this needs to get
filled in.  Jari and I are working on
doing just that.  This will be documentary in nature, much like the
shepherd write-up.
I certainly welcome Adrian Farrel's points as I share his support of RFC 6852 (with the restriction concerning its technical accountability framework). Everything which will make this document clearer and more in line with the currently identified standardization paradigm is extremely welcome.

In addition, I already underlined the shepherd write-up is uncomplete, as it does not mention my intent to appeal an IESG approbation of the intended RFC, if it did not include as a clear section of a disclaimer by IESG or/and an IAB, or/and an ISOC

A. regarding the ultimate nature of this text I consider as a double IAB abdication (if there is a real IETF consensus about it, people are entitled to see it printed):

1. of its leading role and responsibility in the internet governance cross-accountability framework (the reason of my appeal concering RFC 6852 delayed by the NTIA annoucement)
2. obliging internet users (IUsers) to distrust the NTIA plans and technically migrate to DNS zones outside of the ICANN oversight without the sufficient prelimnary guidance of the IAB they are entitled to.

B. regarding its violations of the charter:

1. as a letter to an ICANN group rather than an IETF statement.
2. its lack of consideration of the IUWG contribution at: http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.03.pdf

jfc --=====================_378368163==.ALT-- From nobody Mon Dec 15 08:50:43 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 A26191A8545; Mon, 15 Dec 2014 08:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.141 X-Spam-Level: X-Spam-Status: No, score=-0.141 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_INFO=1.448, HOST_MISMATCH_NET=0.311] 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 6sEKp-INMueR; Mon, 15 Dec 2014 08:50:40 -0800 (PST) Received: from mx1.yitter.info (ow5p.x.rootbsd.net [208.79.81.114]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 155B91A6FC4; Mon, 15 Dec 2014 08:50:40 -0800 (PST) Received: from mx1.yitter.info (nat-08-mht.dyndns.com [216.146.45.247]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.yitter.info (Postfix) with ESMTPSA id 482788A035; Mon, 15 Dec 2014 16:50:38 +0000 (UTC) Date: Mon, 15 Dec 2014 11:50:38 -0500 From: Andrew Sullivan To: Jefsey Message-ID: <20141215165037.GH29830@mx1.yitter.info> References: <548E9814.1090208@cisco.com> <20141215114537.3FEAE1A1B5E@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141215114537.3FEAE1A1B5E@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/iucg/Mr-FHqj8p5eKVeDRSg2bpzxSk2k Cc: "ianaplan@ietf.org" , Eliot Lear , IAB , iesg@ietf.org, Adrian Farrel , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [IAB] [Ianaplan] one final last call comment on draft-ietf-ianaplan-icg-response X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 16:50:41 -0000 On Mon, Dec 15, 2014 at 12:45:19PM +0100, Jefsey wrote: > In addition, I already underlined the shepherd write-up is uncomplete, as it > does not mention my intent to appeal an IESG approbation of the intended > RFC, if it did not include as a clear section of a disclaimer by IESG or/and > an IAB, or/and an ISOC That is not incomplete. Stated intentions that have not actually produced any action are not, in fact, evidence that needs to be considered at all. As a general rule, I do not believe that possible future actions by someone constitute evidence about the state of affairs in the present. The shepherd write-up is supposed to reflect the state of the WG's actual consensus, not the state of any WG's consensus in any possible world. > 2. its lack of consideration of the IUWG contribution at: > http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.03.pdf That contribution was considered by the WG, in that some people who are participants in the WG said they read it or tried to. None of the responses on the mailing list suggested it caused any rethinking of the text. Some participants said they didn't understand it. Others said it was irrelevant to the WG's work. The shepherd write-up does not have to mention everything anyone ever said about a document, because if an observation did not produce any appreciable effect on the WG's discussion then it cannot be taken to be a point of serious consideration by the WG. The IESG knows where the WG archives are; if they want a blow-by-blow review of the WG's discussions, they can read those archives. The write-up is instead intended to provide the IESG with the context necessary to understand WG consensus. I do not believe that the contribution you refer to there had any effect whatsoever on WG consensus. Best regards, A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Tue Dec 16 19:13:25 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 528A01A1B17; Tue, 16 Dec 2014 19:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.232 X-Spam-Level: X-Spam-Status: No, score=0.232 tagged_above=-999 required=5 tests=[BAYES_50=0.8, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, LOTS_OF_MONEY=0.001, MISSING_MID=0.497] autolearn=unavailable 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 oyXtkpA392Ef; Tue, 16 Dec 2014 19:13:19 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E077E1A1B0A; Tue, 16 Dec 2014 19:13:16 -0800 (PST) Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:11810 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y1534-0005an-Kg; Tue, 16 Dec 2014 19:13:15 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Dec 2014 04:13:05 +0100 To: Andrew Sullivan From: Jefsey In-Reply-To: <20141215165037.GH29830@mx1.yitter.info> References: <548E9814.1090208@cisco.com> <20141215114537.3FEAE1A1B5E@ietfa.amsl.com> <20141215165037.GH29830@mx1.yitter.info> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: 8bit 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/Lyq5zGe4iWZNvHrXwg4cXR1BP1M Cc: "ianaplan@ietf.org" , Eliot Lear , IAB , iesg@ietf.org, Adrian Farrel , gene@iuwg.net, "iucg@ietf.org" Subject: Re: [iucg] [IAB] [Ianaplan] one final last call comment on draft-ietf-ianaplan-icg-response 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, 17 Dec 2014 03:13:21 -0000 Dear Andrew, I fully understand that you are defending the interests of your fellow employees. You will accept that I am defending the interests of my fellow IUsers. Unfortunately, you accepted to be the shepherd of a document making the IETF decision on a point you disagree we should agree. My remarks are interspersed. At 17:50 15/12/2014, Andrew Sullivan wrote: >On Mon, Dec 15, 2014 at 12:45:19PM +0100, Jefsey wrote: > > In addition, I already underlined the shepherd write-up is > uncomplete, as it > > does not mention my intent to appeal an IESG approbation of the intended > > RFC, if it did not include as a clear section of a disclaimer by > IESG or/and > > an IAB, or/and an ISOC > >That is not incomplete. Stated intentions that have not actually >produced any action are not, in fact, evidence that needs to be >considered at all. As a general rule, I do not believe that possible >future actions by someone constitute evidence about the state of >affairs in the present. The shepherd write-up is supposed to reflect >the state of the WG's actual consensus, not the state of any WG's >consensus in any possible world. This seems to be in contradiction with the RFC 4858 letter and spirit. > > 2. its lack of consideration of the IUWG contribution at: > > http://iuwg.net/images/draft-iuwg-intlnet-sdo-registry-relations.03.pdf > >That contribution was considered by the WG, in that some people who >are participants in the WG said they read it or tried to. None of the >responses on the mailing list suggested it caused any rethinking of >the text. This should be mentioned since it is part of the charter and a Chair's commitment. >Some participants said they didn't understand it. Others >said it was irrelevant to the WG's work. I hope this was intended to purposely hurt Libre's contributors. These co-authors of this effort have actually read this: - as despising - not encouraging an internet user cooperation with the IETF, - as a leading business competitor's fear of their permissionless innovation rights and plans. They thank you for the free market study! I am more reserved: I just do not understand you – except if you consider me and the independent users as your competition? I felt there were plenty of room for all on the internet? After the unfortunate cut-off dates of the WG mishaps, they feel that I did not have to publish our draft as an I_D. Not making it subject to the non-CC BCP-78 proprietary license... We are a small team. I am not going to split from them. >The shepherd write-up does not have to mention everything anyone ever >said about a document, because if an observation did not produce any >appreciable effect on the WG's discussion then it cannot be taken to >be a point of serious consideration by the WG. The IESG knows where >the WG archives are; if they want a blow-by-blow review of the WG's >discussions, they can read those archives. OK. Now you are laughing at IESG. Look, I am not interested in the inter/internal ICANN - IAB - IESG - IETF rifts. As an IUser I am interested in a working Internet we can use. With your wording here I am sorry to say that you have by yourself: - taken the responsibility of the DNS technology and governance fork that I tried to prevent for years. We are just tired of these useless non productive tussles. - definitely sparked yourself an architectural competition to your multimillion dollar DNS corporation. Let's be candid. I am not aware that anyone else formally announced an appeal. So why take the risk of playing it low key? Or, would it be because the Charter's Milestones will require the RFC-Editor accepts to by-pass the rules and publish a document that will be under appeal? Sorry this is not our IETF. Press and historians know where to read about the RFC Editor practice, under Jon Postel, in such cases. Or, would it be because the NTIA only spoke of the DNS and that to protect the "unique authoritative root" golden fairy tale that the ICANN and I*core "communities" complicate the transition issue in discussing it as if the IANA was relinquishing the whole IANA oversight? Since RIRs consider addresses as their monopolistic revenue source, and ICANN and many here are unsure about the CLASS "IN" names monopoly, many would like, for a long, to merge the two monopolies before NDN and ION/IoT take off and the MYCANN and GOVCANN plug-ins interfere with the CORPCANN-add-ons. >The write-up is instead >intended to provide the IESG with the context necessary to understand >WG consensus. I do not believe that the contribution you refer to >there had any effect whatsoever on WG consensus. This is a well stated evaluation of the importance given by an IETF and a business leader pundit to the contribution of FLOSS community members, internet users, and non-I*core stakeholders. This will permit my appeal to raise the additional question of conflict of interests with internet users in the IETF standardization business process, and who are the network stakeholders from an NTIA/ISOC point of view. Two matters which will definitely justify the appeal to be escalated to ISOC. Andrew, I have tried to make everyone cooperating with me respect the IETF Tao, so far. I am sorry that you decided to cross the limits and illustrate the obsolete and unsecure "one single authoritative root" lobby's bias. This definitely shows me that I was wrong all along in trusting IAB: IUsers cannot trust the IAB anymore. We must look elsewhere for a secure, trusted, and reliable use of the global catenet that we pay for. That's too bad. But this is real life. We need a better, cheaper, people mastered, more flexible, more reliable, and cross accountable internet than the one you want to sell us. And I am afraid we will get it. I hoped we would cooperate: I discover that you want to compete, including within the IETF. I am dismayed. However, thank you for clarifying my illusions. jfc >Best regards, > >A > >-- >Andrew Sullivan >ajs@anvilwalrusden.com From nobody Wed Dec 17 03:25:46 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 004B71A88CA; Wed, 17 Dec 2014 03:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.069 X-Spam-Level: X-Spam-Status: No, score=-1.069 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jz0EtRodv_LW; Wed, 17 Dec 2014 03:25:43 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D5611A88C8; Wed, 17 Dec 2014 03:25:43 -0800 (PST) Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:18851 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y1Cje-0007v3-5s; Wed, 17 Dec 2014 03:25:42 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 17 Dec 2014 12:25:31 +0100 To: Andrew Sullivan From: Jefsey 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/T_ZPMxxD9X4D2aaiZoQZ2gfkb4U Cc: "ianaplan@ietf.org" , Eliot Lear , IAB , iesg@ietf.org, Adrian Farrel , gene@iuwg.net, "iucg@ietf.org" Subject: [iucg] Typo in my mail [was: one final last call comment on draft-ietf-ianaplan-icg-response] 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, 17 Dec 2014 11:25:44 -0000 Dear Andrew, I apologize for the typo in my mail. Please read "I hope this was ***NOT*** intended to purposely hurt Libre's contributors" instead of "I hope this was intended to purposely hurt Libre's contributors". I hope the civil nature of my response helped you to correct it. jfc From nobody Fri Dec 19 03:04:33 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 7A6A41A9081; Fri, 19 Dec 2014 03:04:27 -0800 (PST) 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 fkt2-7EkPfld; Fri, 19 Dec 2014 03:04:26 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8587A1A9069; Fri, 19 Dec 2014 03:04:26 -0800 (PST) Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:61447 helo=MORFIN-PC.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y1vM8-00036z-M4; Fri, 19 Dec 2014 03:04:25 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 19 Dec 2014 12:04:22 +0100 To: Jari Arkko , "Ianaplan@Ietf. Org" From: JFC Morfin In-Reply-To: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net> References: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net> 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/z62HlVLjlBR5VXex5KHd9npnCaE Cc: , gene@iuwg.net, draft-ietf-ianaplan-icg-response.all@tools.ietf.org, iucg@ietf.org Subject: Re: [iucg] [Ianaplan] last call and IESG processing summary for draft-ietf-ianaplan-icg-response 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, 19 Dec 2014 11:04:27 -0000 At 19:53 18/12/2014, Jari Arkko wrote: >Jefsey notes "My point will not be to change it, but to make sure >that the IESG, and IAB, and ISOC, fully and publicly declare that >they understand, accept and decide that this is what they mean." Dear Jari, It is difficult to understand this sentence since the "this" is not explained as being that from now on, the IETF will still be working for the future internet ,in its own way and for its own mission but will not be exclusive or responsible for it any more. This responsibility is here understood as per RFC 3935: "when the IETF takes ownership of a protocol or function, it accepts the responsibility for all aspects of the protocol, even though some aspects may rarely or never be seen on the Internet. Conversely, when the IETF is not responsible for a protocol or function, it does not attempt to exert control over it, even though it may at times touch or affect the Internet." >It is not clear that there is anything to do about this at the >moment, particularly when at least the sponsoring AD does not >understand the provided feedback; this is an IETF document that >will, as it gains approval, will have been processed by the IESG and >will explicitly note that the IAB supports the described transition. The IAB still has to commit in this document. However, eventually ISOC will be the one having to decide, since the I_D means that ISOC would not own the internet anymore (in the RFC 3935 meaning hereinabove). This would be (1) the end of the "status quo" strategy and (2) the affirmation of the "permissionless innovation" paradigm, without any proposition regarding: - the replacement and an extension of the former IAB guidance role in the resulting multitechnology competitive environment on an economical, and probably political, basis. - The way the IETF should adapt its mission of influencing peer SDOs and global communities in such a way as to make the Internet work better. The two mails of Andrew Sullivan and the comment of Pete Resnick show that this new context and its resulting Tao is not familiar yet among every IETF leaders. Now, as a non-IETF technically competing WG, I need to have the practicalities of this new situation explained and how IETF stakeholders intend to adapt to the MYCANN/CORPCANN/GOVCANN middlewares and the multitechnology environment that we will face and build together. We need to know if the IAB/IETF, or someone else they would accept, intends to launch a normative multistakeholder coordination effort that we could adhere to. OpenStand is only a set of principles, not an active "concertance" as in a concerted everystakeholder governance. Otherwise, it is likely that the technical referent structure will temporarily be ICANN and will end up as being the ITU-I. A twenty years long process to accept the inevitable: in our world only sovereignty or concertance (see above) can last. Best jfc From nobody Sun Dec 21 10:36:50 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 620281A6EF3; Sun, 21 Dec 2014 10:36:42 -0800 (PST) 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 wWRmazI3lqcG; Sun, 21 Dec 2014 10:36:41 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A341A6EE9; Sun, 21 Dec 2014 10:36:41 -0800 (PST) Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:50261 helo=MORFIN-PC.dot.dj) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y2lMt-0004rn-RR; Sun, 21 Dec 2014 10:36:40 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 21 Dec 2014 19:35:17 +0100 To: IAB Chair From: JFC Morfin In-Reply-To: References: <37B40FAC-C449-4A6F-9E72-0CE416F03191@iab.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.presenceweb.org X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jefsey.com X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: 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/rwlJVgzNbZt2mq4d6b4Fn2ZBMp8 Cc: "Ianaplan@Ietf. Org" , IETF , IAB , "iucg@ietf.org" , gene@iuwg.net, iesg@ietf.org Subject: Re: [iucg] IAB statement on the NETmundial Initiative 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 Dec 2014 18:36:42 -0000 At 17:49 21/12/2014, IAB Chair wrote: >Jari and I were invited to join representatives of the Internet >Society Board and the ICANN Board at a meeting last week. There >were two topics: the IANA Stewardship Transition and the NETmundial >Initiative. After the meeting, Bob Hinden and Steve Crocker >released a statement. Here is a link to their statement: >http://www.internetsociety.org/news/joint-statement-isoc-icann-meeting Dear Russ, these a minima I*core meetings seem to be less and less representative of, and concerned by, the omni-stake-holder global communities' multitechnological catenet stability. May I remind you my main concern which is the compatility between the various AMERICANN, GOVCANNs and CORPCANNs strategies, plug-ins and/or add-ons and new developments like NDN, SDNs, etc. in a permissionless innovation referentless competition context. This can only push us to consider more and more actively our own Libre MYCANN plug-in fail safe plan for our personnal networking. Seasons greetings and concerns. jfc Best wishes for a joy filled holiday season, > Russ Housley > IAB Chair From nobody Sun Dec 21 21:12:00 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 E73E81A00B2; Sun, 21 Dec 2014 21:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.232 X-Spam-Level: ** X-Spam-Status: No, score=2.232 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_44=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 4CioHbMMI6Hg; Sun, 21 Dec 2014 21:11:43 -0800 (PST) Received: from host.presenceweb.org (host.presenceweb.org [67.222.106.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2DB1A00AD; Sun, 21 Dec 2014 21:11:42 -0800 (PST) Received: from 180.102.176.95.rev.sfr.net ([95.176.102.180]:38619 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.84) (envelope-from ) id 1Y2vHQ-0004dj-1R; Sun, 21 Dec 2014 21:11:40 -0800 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 22 Dec 2014 06:11:30 +0100 To: John C Klensin From: JFC Morfin In-Reply-To: <95C4C6D9E29456672DEE6A92@JcK-HP8200.jck.com> References: <21730E2D-5F0B-45AE-A763-6F61F8AF5D1B@piuha.net> <20141219110431.5AE911A9089@ietfa.amsl.com> <95C4C6D9E29456672DEE6A92@JcK-HP8200.jck.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_401132578==.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/EsiuGDK9qKQYHnpyUjgu9NpfgGw Cc: "Ianaplan@Ietf. Org" , gene@iuwg.net, Jari Arkko , "iucg@ietf.org" , draft-ietf-ianaplan-icg-response.all@tools.ietf.org Subject: Re: [iucg] [Ianaplan] last call and IESG processing summary for draft-ietf-ianaplan-icg-response X-BeenThere: iucg@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: internet users contributing group List-Id: internet users contributing group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 05:11:47 -0000 --=====================_401132578==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Dear John, Thank you for your kind, open, and constructive comment. It would help sustain a long discussion. I will try to make a general and "short" response. Your mail actually confirms for me that the IETF fork between the pre-RFC 6852 IETF and the post-RFC 6852 IETF, - which has actually been enacted at the IAB level, - as resulting from a change in the very nature of the catenet/internet relationships, is not yet perceived from within the IETF culture, while it starts being progressively enacted and played on, on the technical (new upper layers technologies), economic (WEP, Google, Dyn, Netflix, Libre, etc.), military, and political (Europe, BRICS) planes. My effort is simply to make ISOC formally endorse the risk that I might be right in considering the Lynn St-Amour/Don Tappscott analysis conducted by GSN for the USG (http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/) as self-contradictory. This was the purpose of my appeal concerning RFC 6852's lack of common referent to replace the IAB that was interrupted by the NTIA. Lynn/Don's analysis could be very briefly described as being - within the RFC 6852 paradigm and the "permissionless innovation" framework - the meme stating that "Multi-stakeholder governance has come of age and is now fully independent from control by any government, or governmental organizations like the UN. It is the very embodiment of the vision of a free enterprise system that is managed by its participants." ... most probably within the ISOC framework, that ICANN seems to alternatively prefer to be the NMI (which I feel is slightly more consistent with RFC 6852). This does not stand. For a simple reason that I know very well: me. Lynn's meme stands on the "multi-stake-holder" concept. I know that the network, the world and, the universe stands on the "omni-stake-holder" reality. Andrew (who I certainly did not insult!) expressed this very well, as you just did it: my inputs have not been considered. For a very simple mathematical reason which is: "omni - multi = Libre + Jefseys". Look, - I am discussing TCP/IP Class IN AMERICANN + MYCANNs + GOVCANNs + CORPCANNs global reality. - you are discussing the "ICANN, IANA(*), IETF, IAOC, IETF Trust, US Law, Jon Postel, etc." local virtuality. This virtuality could only be credible if there was someone at the iana.arpa helm. The purpose of this I_D is to show that there is no one. (*) the NTIA has never talked about transferring all the IANA functions, and the Charter never mentioned the IGC. The publication of the I_D will not create the fork between your BCP 78 IETF and the RFC 6852/3935bis IETF: it was created two years ago by OpenStand. And officialized one year ago by RFC 6852 I will only make it clear that the IETF people have not noticed. They have to notice it; otherwise, the transition will not be seamless and constructive. This is the purpose of my appeal. - either it is accepted, and we know who the proprietor of the technical rights and duties concerning the Internet is: and the IAB will have to help upgrading the IETF culture. - or it is denied and ISOC and (USG) will have made it clear that they wish for the IETF to only remain one of the contributors to the TCP/IP technology middle layers within a multitechnology digital context. My only concern is that the IETF situation resolution does not cause too much hassle to the permissionless innovation contribution/contributors - and that they can positively cooperate to the IETF in being identified for what they do. jfc At 15:53 19/12/2014, John C Klensin wrote: >Jefsey, > >Perhaps because we have corresponded more over the years, unlike >Jari, I understood your comments and the note excerpted below >confirmed my understanding. Part of that understanding is that >the vast majority of your text and comments below are about your >vision for computer-enabled networking going forward and where >you think the IETF and other bodies fit in that model. While >the I-D does contain some description of parts of how the IETF >works and, in particular, how it relates to the IANA function, >it doesn't make normative changes to IETF (or IAB, ISOC, etc.) >relationships to the present or future Internet beyond the very >narrow issues of IANA relationships and oversight. No matter >what you might read into what is said, for it to do so would be >out of scope for the WG and would represent changes to which >some of us would object strenuously, especially if those changes >were hidden in discussions of NTIA-IANA relationships and the >conditions and implications of changes in them. > >Details below. > >--On Friday, December 19, 2014 12:04 +0100 JFC Morfin > wrote: > > >... > > It is difficult to understand this sentence since the "this" > > is not explained as being that from now on, the IETF will > > still be working for the future internet ,in its own way and > > for its own mission but will not be exclusive or responsible > > for it any more. > >The document changes nothing in that area, including any notions >of exclusivity and/or responsibility. I don't know whether we >would agree about how "exclusive or responsible" things are >intended or desired to be today (or how they are practiced), but >I am quite certain that this document changes nothing in those >areas. > > > This responsibility is here understood as per RFC 3935: "when > > the IETF takes ownership of a protocol or function, it accepts > > the responsibility for all aspects of the protocol, even > > though some aspects may rarely or never be seen on the > > Internet. Conversely, when the IETF is not responsible for a > > protocol or function, it does not attempt to exert control > > over it, even though it may at times touch or affect the > > Internet." > >That statement has little or nothing to do with the IANA >function, the IETF-IANA relationship, or IANA oversight. The >present draft does not change anything about it, even to >reaffirm it. > > > The IAB still has to commit in this document. However, > > eventually ISOC will be the one having to decide, since the > > I_D means that ISOC would not own the internet anymore (in the > > RFC 3935 meaning hereinabove). > >I do not believe that any of IETF, the IAB, or ISOC have claimed >at any time to "own the Internet". Even if they had, there is >nothing in this document that would change or ratify that >status. Because the document changes nothing in those areas, >your subsequent assertions about 'the end of the "status quo" >strategy' and 'affirmation' are just simply not relevant. > > >... > > Now, as a non-IETF > > technically competing WG, I need to have the practicalities of > > this new situation explained and how IETF stakeholders intend > > to adapt to the MYCANN/CORPCANN/GOVCANN middlewares and the > > multitechnology environment that we will face and build > > together. > > > > We need to know if the IAB/IETF, or someone else they would > > accept, intends to launch a normative multistakeholder > >... > >Whether you "need" those things or not, and whether you can >demand that the IETF or IAB respond to those needs, they simply >have nothing to do with the substantive subject matter of this >document or the scope of the WG. > >best regards, > john --=====================_401132578==.ALT Content-Type: text/html; charset="us-ascii" Dear John,

Thank you for your kind, open, and constructive comment. It would help sustain a long discussion. I will try to make a general and "short" response.

Your mail actually confirms for me that the IETF fork between the pre-RFC 6852 IETF and the post-RFC 6852 IETF,
- which has actually been enacted at the IAB level,
- as resulting from a change in the very nature of the catenet/internet relationships,
is not yet perceived from within the IETF culture, while it starts being progressively enacted and played on, on the technical (new upper layers technologies), economic (WEP, Google, Dyn, Netflix, Libre, etc.), military, and political (Europe, BRICS) planes.

My effort is simply to make ISOC formally endorse the risk that I might be right in considering the Lynn St-Amour/Don Tappscott analysis conducted by GSN for the USG ( http://gsnetworks.org/blog/governing-the-internet-a-new-era-begins/) as self-contradictory. This was the purpose of my appeal concerning RFC 6852’s lack of common referent to replace the IAB that was interrupted by the NTIA.


Lynn/Don's analysis could be very briefly described as being - within the RFC 6852 paradigm and the "permissionless innovation" framework - the meme stating that "Multi-stakeholder governance has come of age and is now fully independent from control by any government, or governmental organizations like the UN. It is the very embodiment of the vision of a free enterprise system that is managed by its participants." ... most probably within the ISOC framework, that ICANN seems to alternatively prefer to be the NMI (which I feel is slightly more consistent with RFC 6852).

This does not stand. For a simple reason that I know very well: me.

Lynn's meme stands on the "multi-stake-holder" concept. I know that the network, the world and, the universe stands on the "omni-stake-holder" reality.

Andrew (who I certainly did not insult!) expressed this very well, as you just did it: my inputs have not been considered. For a very simple mathematical reason which is:

"omni - multi = Libre +  Jefseys".

Look,
- I am discussing TCP/IP Class IN AMERICANN + MYCANNs + GOVCANNs + CORPCANNs global reality.
- you are discussing the "ICANN, IANA(*), IETF,  IAOC, IETF Trust, US Law, Jon Postel, etc." local virtuality. This virtuality could only be credible if there was someone at the iana.arpa helm. The purpose of this I_D is to show that there is no one.

(*) the NTIA has never talked about transferring all the IANA functions, and the Charter never mentioned the IGC.

The publication of the I_D will not create the fork between your BCP 78 IETF and the RFC 6852/3935bis IETF: it was  created two years ago by OpenStand. And officialized one year ago by RFC 6852  I will only make it clear that the IETF people have not noticed. They have to notice it; otherwise, the transition will not be seamless and constructive. This is the purpose of my appeal.

- either it is accepted, and we know who the proprietor of the technical rights and duties concerning the Internet is: and the IAB will have to help upgrading the IETF culture.
- or it is denied and ISOC and (USG) will have made it clear that they wish for the IETF to only  remain one of the contributors to the TCP/IP technology middle layers within a multitechnology digital context.

My only concern is that the IETF situation resolution does not cause too much hassle to the permissionless innovation contribution/contributors - and that they can positively cooperate to the IETF in being identified for what they do.

jfc

At 15:53 19/12/2014, John C Klensin wrote:
Jefsey,

Perhaps because we have corresponded more over the years, unlike
Jari, I understood your comments and the note excerpted below
confirmed my understanding.  Part of that understanding is that
the vast majority of your text and comments below are about your
vision for computer-enabled networking going forward and where
you think the IETF and other bodies fit in that model.  While
the I-D does contain some description of parts of how the IETF
works and, in particular, how it relates to the IANA function,
it doesn't make normative changes to IETF  (or IAB, ISOC, etc.)
relationships to the present or future Internet beyond the very
narrow issues of IANA relationships and oversight.  No matter
what you might read into what is said, for it to do so would be
out of scope for the WG and would represent changes to which
some of us would object strenuously, especially if those changes
were hidden in discussions of NTIA-IANA relationships and the
conditions and implications of changes in them.

Details below.

--On Friday, December 19, 2014 12:04 +0100 JFC Morfin
<jefsey@jefsey.com> wrote:

>...
> It is difficult to understand this sentence since the "this"
> is not explained as being that from now on, the IETF will
> still be working for the future internet ,in its own way and
> for its own mission but will not be exclusive or responsible
> for it any more.

The document changes nothing in that area, including any notions
of exclusivity and/or responsibility.   I don't know whether we
would agree about how "exclusive or responsible" things are
intended or desired to be today (or how they are practiced), but
I am quite certain that this document changes nothing in those
areas.

> This responsibility is here understood as per RFC 3935: "when
> the IETF takes ownership of a protocol or function, it accepts
> the responsibility for all aspects of the protocol, even
> though some aspects may rarely or never be seen on the
> Internet.  Conversely, when the IETF is not responsible for a
> protocol or function, it does not attempt to exert control
> over it, even though it may at times touch or affect the
> Internet."

That statement has little or nothing to do with the IANA
function, the IETF-IANA relationship, or IANA oversight.  The
present draft does not change anything about it, even to
reaffirm it.

> The IAB still has to commit in this document. However,
> eventually ISOC will be the one having to decide, since the
> I_D means that ISOC would not own the internet anymore (in the
> RFC 3935 meaning hereinabove).

I do not believe that any of IETF, the IAB, or ISOC have claimed
at any time to "own the Internet".   Even if they had, there is
nothing in this document that would change or ratify that
status.   Because the document changes nothing in those areas,
your subsequent assertions about 'the end of the "status quo"
strategy' and 'affirmation' are just simply not relevant.

>...
> Now, as a non-IETF
> technically competing WG, I need to have the practicalities of
> this new situation explained and how IETF stakeholders intend
> to adapt to the MYCANN/CORPCANN/GOVCANN middlewares and the
> multitechnology environment that we will face and build
> together.
>
> We need to know if the IAB/IETF, or someone else they would
> accept, intends to launch a normative multistakeholder
>...

Whether you "need" those things or not, and whether you can
demand that the IETF or IAB respond to those needs, they simply
have nothing to do with the substantive subject matter of this
document or the scope of the WG.

best regards,
    john
--=====================_401132578==.ALT--