Re: [Ianaplan] Time frame inquiry

Jefsey <jefsey@jefsey.com> Fri, 05 June 2015 11:31 UTC

Return-Path: <jefsey@jefsey.com>
X-Original-To: ianaplan@ietfa.amsl.com
Delivered-To: ianaplan@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 518F01B2EE9 for <ianaplan@ietfa.amsl.com>; Fri, 5 Jun 2015 04:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.565
X-Spam-Level:
X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VhCdbglPp6xR for <ianaplan@ietfa.amsl.com>; Fri, 5 Jun 2015 04:31: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 4537F1B2EE8 for <ianaplan@ietf.org>; Fri, 5 Jun 2015 04:31:44 -0700 (PDT)
Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:14257 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from <jefsey@jefsey.com>) id 1Z0pqf-0001KP-T1; Fri, 05 Jun 2015 04:31:42 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 05 Jun 2015 13:31:30 +0200
To: Jari Arkko <jari.arkko@piuha.net>, "Ianaplan@Ietf. Org" <ianaplan@ietf.org>
From: Jefsey <jefsey@jefsey.com>
In-Reply-To: <E7F5E724-D58D-4A8C-90E4-ADB65C8DB819@piuha.net>
References: <D15A3C14-F268-4CF1-B942-BAE57B281C58@cooperw.in> <556D3AAA-1655-4785-9395-8F6CD0B73E44@vigilsec.com> <5F8F0771-C77B-4D90-811B-501A4EC79268@istaff.org> <893FE3E3-A2DD-40D8-B39F-1EB24DFE1806@vigilsec.com> <97267ED7-D8A2-4A64-AB74-07434190DD89@piuha.net> <CA+9kkMBZq_U+CC5Jzv5T3pL7qasUHSfv-Gu8q4P36+phABXxzg@mail.gmail.com> <4AB120DC-AFB1-4915-B6C5-7417FB989878@piuha.net> <55669A78.3020309@cisco.com> <C8B9D0E8-C363-4618-8941-D0027B86EB7A@piuha.net> <6BCB4C30-034A-4D13-AD89-88B0719DB75C@vigilsec.com> <7B6FC84D-CE19-435F-A87A-87AEF3FDB305@thinkingcat.com> <556CBF1F.20503@gmail.com> <CAP4=Vciz9noosd=04mxWineNVYwtESve0991JwGWbmC52OViRA@mail.gmail.com> <556CDDD4.8070507@gmail.com> <E7F5E724-D58D-4A8C-90E4-ADB65C8DB819@piuha.net>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_376704818==.ALT"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - host.presenceweb.org
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jefsey.com
X-Get-Message-Sender-Via: host.presenceweb.org: authenticated_id: jefsey+jefsey.com/only user confirmed/virtual account not confirmed
X-Source:
X-Source-Args:
X-Source-Dir:
Message-Id: <20150605113144.4537F1B2EE8@ietfa.amsl.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/f8nsMV60QVBb50iclCyzf4diymg>
Cc: "Leslie Daigle \(ThinkingCat\)" <ldaigle@thinkingcat.com>
Subject: Re: [Ianaplan] Time frame inquiry
X-BeenThere: ianaplan@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IANA Plan <ianaplan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ianaplan/>
List-Post: <mailto:ianaplan@ietf.org>
List-Help: <mailto:ianaplan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ianaplan>, <mailto:ianaplan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 05 Jun 2015 11:31:47 -0000

Dear Jari,
I will not scream. This was when the IETF still existed as a sovereign entity…

----

Two-days ago, at the French IGF plenary:

1. which congratulated itself over the NTIA ICANN transition process,

2. and consensually felt it was too early to apply the FIFA metaphor to ICANN,

3. I asked about the added value of ICANN:

3.1. brought to the use of the 1974 catenet, pursued by the Internet 
IEN 48 1978 project, status-quoed in 1986 within NSA-compatibility by 
the creation of the IETF and the closing of Tymnet Extended Services 
and its EuroLab,

3.2. now the IAB has lifted the NSA requirement on Nov 14, 2014 
<https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/>https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/, 
leading to a "permissionless innovation" consensual paradigm already 
introduced by the RFC 6852.

3.2.1. I was surprised by the silence, followed by several 
contradictory responses by ICANN BoD level/equivalent leaders.
3.2.2. The consensual echoes that I further received from the 
attendants confirmed that it was acknowledged that ICANN only managed 
an "internet semantic spectrum", which is something partly similar to 
what I call a VGN and RFCs name a CLASS, while the IAB/IETF has never 
considered how a multispectrum internet works.

----

I only note here that the IESG seems to be gone, and you now govern 
intuitu personæ (so there is no more risk of appeals, thank you for that):
- after having enfeoffed  the IETF to the USG 
<http://www.ietf.org/blog/2015/01/taking-a-step-towards-iana-transition/>http://www.ietf.org/blog/2015/01/taking-a-step-towards-iana-transition/
- you do the same, enfeoffing the Internet to the USG through the PTI 
political trick.

This only leads me to extend my question about value-added IAB/IETF 
will now bring to the various internet variants and to the users' catenet.
I, myself, understand that the IETF is now one of the RFC 6852 "ICANN 
global community's" technical contributors.

jfc


At 14:03 04/06/2015, Jari Arkko wrote:
>I wouldn’t worry too much about the signatories that is perhaps 
>more of a practical
>matter than anything else. In general, reducing the reliance on 
>persons in official
>roles and highlighting the role of the community is important in this and many
>other topics.
>
>But being clear about the status of any opinion is important, and we
>didn’t make that yet clear in the previous text.
>
>I plan to send this note to the ICG later today unless someone screams
>otherwise. I also plan to send a copy to the CWG list for information,
>given our reference relating to the PTI arrangements.
>
>—
>This is a response to a query regarding transition finalisation and
>implementation time frames, sent to the IANAPLAN working
>group list by the chairs of the IANA Transition Coordination
>Group (ICG) on May 27th.
>
>While I am carrying this response back to the ICG, the substance
>of this response has been discussed in the IANAPLAN working
>group and the relevant parts of IETF leadership. I believe this
>response represents the (rough) consensus opinion that
>emerged in the discussion, as well as the current state
>of IANA arrangement updates that our leadership bodies
>have been working on.
>
>The IETF is ready today to take the next steps in the
>implementation of the transition of the stewardship.
>In our case, most of the necessary framework is already
>in place and implemented in preceding years.
>
>The remaining step is an updated agreement with
>ICANN which addresses two issues. These issues are
>outlined in Section 2.III in the Internet Draft
>draft-ietf-ianaplan-icg-response-09.txt:
>
>   o  The protocol parameters registries are in the public domain.  It
>      is the preference of the IETF community that all relevant parties
>      acknowledge that fact as part of the transition.
>
>   o  It is possible in the future that the operation of the protocol
>      parameters registries may be transitioned from ICANN to subsequent
>      operator(s).  It is the preference of the IETF community that, as
>      part of the NTIA transition, ICANN acknowledge that it will carry
>      out the obligations established under C.7.3 and I.61 of the
>      current IANA functions contract between ICANN and the NTIA
>      [NTIA-Contract] to achieve a smooth transition to subsequent
>      operator(s), should the need arise.  Furthermore, in the event of
>      a transition it is the expectation of the IETF community that
>      ICANN, the IETF, and subsequent operator(s) will work together to
>      minimize disruption in the use of the protocol parameters registries
>      or other resources currently located at iana.org.
>
>The IETF Administrative Oversight Committee (IAOC) has
>decided to use an update of our yearly IETF-ICANN Service Level
>Agreement (SLA) as the mechanism for this updated
>agreement. They have drafted the update and from our
>perspective it could be immediately executed. Once the updated
>agreement is in place, the transition would be substantially
>complete, with only the NTIA contract lapse or termination
>as a final step.
>
>Of course, we are not alone in this process. Interactions
>with other parts of the process may bring additional
>tasks that need to be executed either before or
>after the transition. First, the ICG, the RIRs,
>and IETF have discussed the possibility of aligning
>the treatment of IANA trademarks and domains. The
>IETF Trust has signalled that it would be willing to do this,
>if asked. We are awaiting coordination on this
>to complete, but see no problem in speedy
>execution once the decision is made. From our
>perspective this is not a prerequisite for the transition,
>however.
>
>In addition, the names community has proposed the
>creation of a 'Post Transition IANA' (PTI).  If the existing
>agreements between the IETF and ICANN remain in place
>and the SLAs discussed above are not affected, the IETF​
>transition would take place as described above.  That is
>our preference.  If the final details of the PTI plan require
>further action from the IETF, more work and community
>agreement would be required.  The timeline for that work
>cannot be set until the scope is known.
>
>Jari Arkko, IETF Chair
>(reporting his summary of the situation)
>
>
>
>_______________________________________________
>Ianaplan mailing list
>Ianaplan@ietf.org
>https://www.ietf.org/mailman/listinfo/ianaplan