[Internal-cg] PTI related issues slide 5

Martin Boyle Martin.Boyle at nominet.org.uk
Wed Sep 23 15:57:27 UTC 2015


Milton, Paul, Jari,
All,

(No consultation on any of this yet:  other sub-team members might have views divergent from mine, but given time constraints, I am copying this to the whole ICG list.)

I've now gone through slide 5 (much easier than slide 4 :) ):  I do not think we need to ask for CWG any further action on any of the points.  I leave it to others to decide whether we draw the OCs' attention to D3 to assure that ICANN's Continuity and Contingency Plan is updated in the contract between ICANN and PTI.

D2

*         INTA (110):  "INTA recommends a separation process that does not require final approval by the ICANN Board."

While the CWG separation process does require approval by the ICANN Board, the ICG proposal paragraph 1399 specifies, "The selection of a new operator to perform the IANA Naming Functions ...  will be subject to approval by the ICANN Board, and a community mechanism derived from the CCWG-Accountability process.  A determination by the ICANN Board to not approve a recommendation by the SCWG ... will need to follow the same supermajority thresholds and consultation procedures ...."  Hence the responsibility for dealing with the Board overriding a recommendation by the separation process is within the ICANN enhanced accountability processes.

No further action is required.

D3

*         R Dara (23):  "[The] "Continuity and Contingency Plan" developed by ICANN under clause C.7.3 of the present IANA Functions Contract ... operationalises separability and outlines how continuity will be ensured...  The plan needs to be revised for how continuity will be ensured if IANA were to be split into three parts and only one community decides to move IANA.

This should be picked up in the ICANN-PTI contract.  Given that the numbers & protocol parameters communities have their own relationship with ICANN, I do not think anything needs to be done here, although I would expect that ICANN would want to cover a split in the IANA functions operation as part of its contingency plan.

Further action:  none necessary (it is an ICANN implementation issue), although we could say, "One comment notes that the current Continuity and Contingency Plan developed under the current IANA functions contract will need to be updated as part of the new contractual relationship between ICANN and the PTI.  We would expect this to be dealt with under the contracting process, but we would welcome confirmation that this will be the case."

D4:         Covered under 1.c.

D.5.

*         A Doria (104):  "I do not support the possible separation of ... the IANA function, into separate ... subfunctions. I consider that a possible risk to the stability and security of the Internet.  I see IANA, not any single directory, as the actual root of the Internet and am concerned about possible inconsistencies that might develop were IANA to be split..."

The consensus proposal does not share the opinion that splitting the IANA functions by OC is a serious risk (although we have recognised the risk of inconsistencies with our response on 1.c. requesting the OCs to commit to coordinating and cooperating as necessary when changing operator

No further action is required.

D.6.

*         Centre for Internet and Society  (126):  Recommends splitting the three IANA functions ("allows for technical specialisation leading to greater efficiency; allows for more direct accountability, and no concentration of power;  and allows for ease of shifting of the ... IANA functions operator without affecting the legal structure of any of the other IANA function operators.")

The proposal has been developed based on the requirements of the three OCs.  It is based on a general consensus in each community process.  While this might be a possible solution, it was not adopted.  (It is likely it would have been opposed without a clear need, given the significant changes that this would introduce.)

No further action is required.

E.

*         GNSO IPC (125):  "in one very important aspect, the IPC believes that the proposal does not support and certainly does not enhance the multistakeholder model. In the bodies created by the CWG ... representation from the GNSO stakeholder communities is set at the stakeholder group level. ... the IPC will, more likely than not, fail to be directly represented on those bodies."

Representation on different bodies has to be a compromise that balances representation against the manageable size of different groups.  Representation from the GNSO (in comparison with other communities) was discussed at length in the CWG for the SCWG and gTLD interests have a significantly larger representation than any other community (six seats on the SCWG and five on the IANA Function Review Teams, compared with three ccTLDs and one from other communities).  Given the delicate balance in these structures, and a general consensus, it would be inappropriate to ask the CWG to re-open this discussion.

No further action required.

Happy to discuss in the next 30 minutes!


Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://ianacg.org/pipermail/internal-cg_ianacg.org/attachments/20150923/7d013b4b/attachment.html>


More information about the Internal-cg mailing list