Comment Close Date | Statement Name | Status | Assignee(s) | Call for Comments Open | Call for Comments Close | Vote Open | Vote Close | Date of Submission | Staff Contact and Email | Statement Number |
---|---|---|---|---|---|---|---|---|---|---|
IANA Stewardship Transition Proposal | ADOPTED 11Y, 0N, 0A | Olivier Crepin-Leblond | 23:59 UTC | public-comments@ianacg.org | AL-ALAC-ST-0915-03-00-EN |
FINAL VERSION TO BE SUBMITTED IF RATIFIED
Please click here to download the document below.
FINAL DRAFT VERSION TO BE VOTED UPON BY THE ALAC
Click here to download the Word document
Click here to download the PDF document
FIRST DRAFT SUBMITTED
--- start of initial text section ---
A split resulting in IANA Functions being undertaken by more than one IANA Functions Operator would be likely to introduce instability. The ALAC therefore recommends that although no measures were introduced by the IANA Coordination Group to increase direct operational coordination between the Operational Communities, this should be promoted at Implementation Phase, with the aim to reduce the likelihood of a split in IANA Functions Operators. This direct operational coordination should take place as enhanced communication and continuous dialogue.
In the event of an Operational Community reaching the decision to replace the IANA Functions Operator, they should discuss their decision with other Operational Communities prior to proceeding forward, seeking all ways to keep all of the IANA functions undertaken by a single IANA Functions Operator.
--- end of initial text section ---
This text section now forms a sub-part of the ALAC's Statement which will take the form of a set of responses to a Public Input Template.
Please look at the Public Input Template Provided by the ICG and which we have filled with the above text (plus other points) including feedback from the IANA Issues WG calls on 26 & 27 Aug 2015:
Working Document in Word Format Version 3
Below: document in PDF format Version 3
It is expected that the ALAC input in the consultation will take the full form using the Template Provided. Please comment below on the template's contents or use the working group mailing list (if you are a member of the ALAC IANA Issues & ICANN Accountability Working group) using "track changes")
7 Comments
Olivier Crepin-Leblond
Note the full presentation slide deck of the ICG can be accessed on: https://www.ianacg.org/icg-files/documents/XPL-ICAN_1510_ICG_Report_Visual_Summary_08.pdf
Also, recordings/transcripts of the ICG presentation can be found on: https://www.ianacg.org/coordination-group/icg-archives/
Olivier Crepin-Leblond
The ALAC IANA Issues & ICANN Accountability working group has discussed the issue of Intellectual Property Issues namely the ownership of the IANA Trademark as well as IANA.ORG Domain name in several conference calls.
The choice was between:
IANA.ORG & any IPRs are transferred to IETF Trust
IANA.ORG & any IPRs are transferred to a new Trust created for this purpose
Another solution (please specify)
The majority of persons attending the calls expressed a clear preference for IANA.ORG & any related IPRs to remain with ICANN but also mentioned that a transfer or IANA.ORG & any IPRs to the IETF Trust (under certain conditions) or to a new Trust created for the purpose of holding the IPRs (under certain conditions) would be acceptable.
The recent Statement from the ICANN Board might make the issue irrelevant for inclusion in a comment?
Olivier Crepin-Leblond
The Chair of the ICANN Board has published his response about the matter on https://community.icann.org/download/attachments/54690758/ICANN%20Statement%20IPR.pdf?version=1&modificationDate=1440098917000&api=v2
The paragraph addressing this question reads:
During the transition, ICANN is prepared to transfer full ownership of the IANA-related trademarks to a
neutral third party mutually agreed among the operational communities with the understanding that
ICANN, as the current IANA Functions Operator, will be granted license to those trademarks and ICANN
will maintain operational control of the IANA.ORG domain for as long as ICANN remains
the IANAFunctions Operator.
Based on discussion in the IANA Issues & ICANN Accountability Working Group during its recent conference calls, whilst members & participants preferred the option where ICANN retained all rights, there was no opposition to accepting that the Rights listed above be transferred as per the text.
I therefore suggest that the ALAC does NOT include a comment on this issue in its Statement.
Tijani Ben Jemaa
The ICG proposal is an assemblage of the 3 proposals received from the 3 operational communities rather than a compilation of 3 harmonized proposals in a single well structured one.
We can notice that the CRISP (Numbering Function) as well as the IANAPLAN WG (Protocol Parameters Function) have clearly expressed their total satisfaction of the performance of ICANN as the operator of their respective IANA Functions. Their submissions proposed that they will continue dealing with ICANN in the post transition phase (SLE with ICANN / MoU with ICANN). On the other hand, the CWG (Naming Function) proposed to form an affiliate to ICANN called PTI (with a legal separation from ICANN) to operate the IANA naming function, with a possible structural (full) separation. We find all those details in the ICG proposal.
We can notice that the CSC is for the naming function only, and so is the IFR. If the CSC is not happy with PTI, they, together with the IFR, may ask for its complete separation from ICANN. Means that we may end up with the PTI owned by a company X to operate the 3 functions because the naming function people decided it. In this case, shall the RIR and IETF accept it? If they don’t, and they very likely don’t, shall they look for other companies to operate their respective functions? Or shall they create a new PTI (affiliated to ICANN or part of it) without the naming function?
I’m really worried about the internet stability and resiliency under such situation. I think the ICG didn’t do its work, but assembled the received proposals. This solution is not sustainable and needs more negotiation with the 3 communities to come up with a structured single proposal.
Olivier Crepin-Leblond
Dear Tijani,
you say:
I’m really worried about the internet stability and resiliency under such situation. I think the ICG didn’t do its work, but assembled the received proposals. This solution is not sustainable and needs more negotiation with the 3 communities to come up with a structured single proposal.
Isn't this what the 3 operational communities asked of the ICG? Cut/Paste & let the operational communities know of any discrepancy for them to work out themselves?
Avri Doria
In response to Tijani.
While I agree it would have been better for the ICG to have given us an integrated proposal, I do not think the threat to stabilty is as great as all that. I also don't think there is a prayer of getting them to do something other than what they have done.
Through the IFR and resulting Separation process, the naming community can only decide to move Names to another iana function provider other than PTI. Removing the PTI itself from ICANN would be a harder task and would take cooperation with the other Operational Communities. I think that if any of the OC get to the point of discussing removal, all 3 OCs will start discussing what to do. That is part of the reason for including the other COs as liaison in any separation process.
Theoretically though, it is possible that names could move to another IFO while Numbers and Protocols remain with ICANN and the PTI.
This would not be a good thing. I am among those who thinks that splitting the IANA, the real root of the Internet, is a bad idea. My warmest hope is that after the PTI becomes 'working code' the other OC will join in its oversight. For now they have chosen stability, just as we have chosen stability+the ability they have to terminate with ICANN as IFO.
I believe that the solution is sustainable even if a bit awkward under the worst case..
One thing that the IPR issue has shown us is that when there is a tough issue among the 3 OC, we will figure out a way to work it out together. Working in the PTI together would make that easier, but we have shown already that we will cooperate. I think it is important to trust that. There is no way we can come up with a proposal that takes care of all eventualities. Enough of us, though are participants of multiple OC, to make sure that we do not let it fall apart.
Olivier Crepin-Leblond
Proposed Text to reconcile Tijani's & Avri's points:
In the event of an Operational Community reaching the decision to replace the IANA Functions Operator, they should discuss their decision with other Operational Communities prior to proceeding forward, seeking all ways to keep all of the IANA functions undertaken by a single IANA Functions Operator.
A split resulting in IANA Functions being undertaken by more than one IANA Functions Operator would be likely to introduce instability. The ALAC therefore recommends that although no measures were introduced by the IANA Coordination Group to increase direct operational coordination between the Operational Communities, this should be promoted at Implementation Phase, with the aim to reduce the likelihood of a split in IANA Functions Operators. This direct operational coordination should take place as enhanced communication and continuous dialogue.