Re: [Ianaplan] CWG draft and its impact on the IETF

Jefsey <jefsey@jefsey.com> Mon, 18 May 2015 13:44 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 054BB1A8996 for <ianaplan@ietfa.amsl.com>; Mon, 18 May 2015 06:44:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.735
X-Spam-Level: *
X-Spam-Status: No, score=1.735 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_19=0.6] 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 NdUbw_1oXSi9 for <ianaplan@ietfa.amsl.com>; Mon, 18 May 2015 06:44:37 -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 318AB1A8955 for <ianaplan@ietf.org>; Mon, 18 May 2015 06:44:31 -0700 (PDT)
Received: from 251.47.14.81.rev.sfr.net ([81.14.47.251]:5685 helo=MORFIN-PC.mail.jefsey.com) by host.presenceweb.org with esmtpa (Exim 4.85) (envelope-from <jefsey@jefsey.com>) id 1YuLLF-0006dv-Jz; Mon, 18 May 2015 06:44:29 -0700
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 18 May 2015 15:44:07 +0200
To: Olaf Kolkman <kolkman@isoc.org>, John C Klensin <klensin@jck.com>, Seun Ojedeji <seun.ojedeji@gmail.com>, John Curran <jcurran@istaff.org>
From: Jefsey <jefsey@jefsey.com>
In-Reply-To: <44A0F230-A98C-4060-88E2-B20FE1DE1FC5@isoc.org> <CAD_dc6hN58zCt1sd0NNQ5M0jbZaz-vo=R0n2z=-=_9NkS0UZGg@mail.gmail.com> <C9EB9657-5B66-4FDD-8CF2-B54897A4595D@istaff.org>
References: <5550F809.80200@cisco.com> <55511064.2000300@gmail.com> <CAOW+2dvBb4n4W=q7NoO_V1X+JoqvO1TWYBqPAEseY9T7vybj9Q@mail.gmail.com> <CAKFn1SEkBSfk5H5ZjOqfiyaxPak_62cNcRR-SDFH2JJ2HxQumA@mail.gmail.c om> <59edd953c1d349cfa377bcd72b514b7f@EX13-MBX-13.ad.syr.edu> <C3D17473E06220755959AB78@JcK-HP8200.jck.com> <27ed27614a6b47729043610f09ac197f@EX13-MBX-13.ad.syr.edu> <88F741BF3D4C2A597622A70C@JcK-HP8200.jck.com> <44A0F230-A98C-4060-88E2-B20FE1DE1FC5@isoc.org> <5550F809.80200@cisco.com> <55511064.2000300@gmail.com> <CAOW+2dvBb4n4W=q7NoO_V1X+JoqvO1TWYBqPAEseY9T7vybj9Q@mail.gmail.com> <59edd953c1d349cfa377bcd72b514b7f@EX13-MBX-13.ad.syr.edu> <C3D17473E06220755959AB78@JcK-HP8200.jck.com> <27ed27614a6b47729043610f09ac197f@EX13-MBX-13.ad.syr.edu> <88F741BF3D4C2A597622A70C@JcK-HP8200.jck.com> <44A0F230-A98C-4060-88E2-B20FE1DE1FC5@isoc.org> <CAD_dc6hN58zCt1sd0NNQ5M0jbZaz-vo=R0n2z=-=_9NkS0UZGg@mail.gmail.com> <5550F809.80200@cisco.com> <55511064.2000300@gmail.com> <CAOW+2dvBb4n4W=q7NoO_V1X+JoqvO1TWYBqPAEseY9T7vybj9Q@mail.gmail.com> <CAKFn1SEkBSfk5H5ZjOqfiyaxPak_62cNcRR-SDFH2JJ2HxQumA@mail.gmail.c> <om@mac.com> <59edd953c1d349cfa377bcd72b514b7f@EX13-MBX-13.ad.syr.edu> <C3D17473E06220755959AB78@JcK-HP8200.jck.com> <27ed27614a6b47729043610f09ac197f@EX13-MBX-13.ad.syr.edu> <88F741BF3D4C2A597622A70C@JcK-HP8200.jck.com> <44A0F230-A98C-4060-88E2-B20FE1DE1FC5@isoc.org> <C9EB9657-5B66-4FDD-8CF2-B54897A4595D@istaff.org>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_1021983048==.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: <20150518134431.318AB1A8955@ietfa.amsl.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/ianaplan/CQTsqcvwoF77xc6rdIsJYwf9TYg>
Cc: Milton L Mueller <mueller@syr.edu>, "ianaplan@ietf.org" <ianaplan@ietf.org>
Subject: Re: [Ianaplan] CWG draft and its impact on the IETF
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: Mon, 18 May 2015 13:44:41 -0000

Dear John, Olaf, Seun, and John,

Thank you for this clear summary of the I*Community's internal positions.

1. Two "inside" things must be added:

a) Jari Arkko's
<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/ 
: "The NTIA must then consider and approve the proposal. Finally, it 
must be implemented." This means that the future of the IETF is not 
to result from an IETF consensus but rather from an NTIA decision.

b) The NTIA/White House/Congress/FCC convoluted political decision 
mechanism and respective responsibilities will be based upon the 
information available to them. This information is:
<<http://www.fas.org/sgp/crs/misc/R44022.pdf>http://www.fas.org/sgp/crs/misc/R44022.pdf>

2. The "outside" thing that must be added is simple: no outside 
aspect is being considered.

3. As a non-US citizen who is not particularly interested in the 
NTIA/White House/Congress/FCC/ICANN deliberations, and as a Libre 
lead user interested in my internet and non-internet protocol 
consistent relations with other local members of the global catenet, 
I am also interested, under the auspices of RFC 6852:

a) in the way the IETF will ensure that its global community's 
technology will stay compatible with other communities' technologies 
and/or practices and/or demands regardless of the number of competing 
"ICANN"s on the global market.

b) to know if the IAB and/or IESG is/are going to sponsor a BoF, 
introduce a charter, create a WG/MULTICANN on the way to use, 
operate, and manage a multi-Overlay Networked Edge Systems (ONES) environment.

c) or if I should request Andrew Sullivan or Jari Arkko  (I am not 
sure about the stream and the responsible AD in that case) to create 
a multicann@ietf.org permanent non-WG mailing list to that end?

4. This results from my observation that:

a) the IETF does not seem to be interested in keeping the catenet's 
internet oriented technologies consistent along with a single IANA 
for all of their RFC 6852 global communities' flavors, enhancements, 
permissionless innovation, national sovereignty protections, and precautions.

b) the IESG has prefered not to consider the questions raised but not 
addressed by the IETF IANAPLAN consensus, I therefore have now to 
bring in the most adquate manner in front of the IAB before mid-June.

jfc

At 10:04 18/05/2015, Olaf Kolkman wrote:

>On 15 May 2015, at 18:54, John C Klensin wrote:
>
>First of all and as far as I can tell, if we ended up with the
>IETF and/or RIRs/NRO having agreements about relevant IANA
>functions with ICANN and the names community having an agreement
>with a PTI for IANA functions that are relevant to them, either
>we end up splitting IANA into two (or three) separate
>organizations or we end up with a picture that looks like:
>
>IETF -> ICANN -> IANA Department
>NRO -> ICANN -> IANA Department
>Names Community -> PTI -> ICANN -> IANA Department
>
>Working from the thesis that what is confusing to me might be 
>confusing to others. I am going to ask for clarification.
>
>My mental model of the setup that is being discussed here (that is, 
>if I were to determine the current consensus):
>
>Mental model 1
>
>IETF -> ICANN [-> IANA blackbox ]
>NRO  -> ICANN [—> IANA blackbox ]
>
>Names Community -> PTI
>Where the IANA blackbox and PTI deliver the registry publication and 
>maintenance functions. The reason why I picture an IANA blackbox is 
>because the SLA is with ICANN and how the service is being 
>subcontracted is a detail that the IETF and NRO would not 
>particularly care about as long as the SLA is honored.
>
>Depending on how ICANN sub contracts the IANA services the IANA 
>Blackbox could look in fact be the PTI, with the IANA department 
>being a one-to-one mapping to the PTI. And the then looks like:
>
>Mental Model 1 - implementation
>
>IETF -> ICANN [-> PTI ]
>NRO  -> ICANN [—> PTI ]
>
>Names Community -> PTI
>Where PTI == the IANA department.
>
>The Names Community is organized within ICANN and there is a funding 
>stream from ICANN to the PTI.
>
>If I understand Milton correctly then he favors:
>
>Mental model 2
>
>IETF -> PTI
>NRO -> PTI
>Names Community -> PTI
>The picture is a bit more complicated since the Names Community is 
>part of 'ICANN' and the funding of the PTI comes through 'ICANN'.
>
>So here is my clarification question: Am I correct in my 
>understanding that my mental model 1 aligns with where most people 
>on this list are going, and Milton, is my mental model 2 a 
>reasonable representation of your thoughts?
>
>—Olaf
>
>----------

At 10:27 18/05/2015, Seun Ojedeji wrote:

>For RIR and names, model 1 seem to be the case. However from my 
>observation of current IETF discussion, it seem there is a "but" in 
>their preferred version of model 1 as thus:
>
>IETF -> ICANN [-> IANA Department ]Where oversight(administrative) 
>of IETF related function is not done by PTI
>
>Regards

At 13:32 18/05/2015, John Curran wrote:
>Olaf -
>
>     I do not know what is current consensus, but the current proposals
>     (IANAPlan, CRISP, CWG) reflect the following relations, as best I
>     can determine -
>
>- IANAplan (Protocol parameter registries)
>
>     The protocol parameter community is represented by the IETF.
>
>     The IETF (via its various structures incl. IAB and IAOC) continues
>     its present relationship with ICANN for ICANN to provide IANA
>     protocol parameter registry services.   Assignment by ICANN to
>     another entity (such as a new PTI affiliate) would require IETF
>     approval.
>
>
>- CRISP (Internet number registries)
>
>     The Internet numbers community is represented by the RIRs.
>
>     The RIRs (via NRO coordination) enters into a service level
>     agreement (SLA) with ICANN ICANN to provide IANA number
>     registry services. Assignment by ICANN to another entity (such
>     as a new PTI affiliate) is not provided for in the present SLA draft.
>
>
>- CWG  (Internet domain name registry)
>
>     The Internet DNS community is represented by the ICANN
>     (as guided by its constituent parts, and with strengthened
>      accountability to same as a result of the CCWG changes
>      to make ICANN into a formal membership organization)
>
>     ICANN enters into a service level agreement with PTI (a new
>     wholly-owned affiliate) to provide IANA DNS registry services.
>
>FYI,
>/John