[CCWG-ACCT] Notes and action items CCWG ACCT Day 2 Session 3

[Dr Eberhard W Lisse]

With regards to the first Action Item, Becky is appointed by the gNSO, and there are 5 appointed members of the ccNSO, leaving the Co-Chair and me out(as I would not do it anyway :-)-O) there are three ccNSO appointed members left, one of whom should do this.

I do also not see anything in the Charter permitting this, and object for good measure, and the record.

THERE ARE NO REDELEGATION AND REVOCATION ISSUES!!!! 

When will we start even using the correct terminology? Not because of the terminology, but so that we talk about the same things. 

For the umpteenth time, there are (initial) delegation, and retirement, both of which are not an issue. Then there is what was formerly known as "redelegation", which is a revocation and transfer. 

A transfer is (almost) identical to an initial delegation with the exception that the (initial) work necessitated to establish it (allocation of ISO Code, and entering that into the root) is not required.


To reduce the FoI principles to an Appeal mechanism defies comprehension.


There is no Policy Development, no Issue Request has been circulated to the lists.


And, what on earth does the GAC have to with any of this? (In addition, there are no GAC Principles from 2006, they are from 2005)

Or the CWG, which under the CCWG Charter is responsible of accountability of IANA operational issues, just assumed all is hunky dory and moved on, requesting the CCWG should also do nothing. 

The notes at the same time acknowledge that some ccTLDs are not subject to any of this as pre-existing but nevertheless considers IRP in this context. Interesting...

el
-- 
Sent from Dr Lisse's iPad mini

> On Apr 25, 2015, at 02:24, Adam Peake <adam.peake at icann.org> wrote:
> 
> 
> Notes and action items for CCWG ACCT  Day 2 Session 3 ­ 24 April 2015
> 
> Also posted on the wiki
> https://community.icann.org/pages/editpage.action?pageId=52897583
> 
> Action items
> 
> Action: Becky to confirm with ccNSO if this non-inclusion in the IRP, is
> acceptable.
> Action: update text redelegation and revocation issues should not be
> subject to the IRP, pending ccNSO policy. And considering GAC
> contributions.
> Action: to ensure the IRP txt is aligned as above.
> Action: Chairs will review the transcript and put a proposal to the group,
> and double check with the lawyers.
> Action: Alan to provide a sentence about the reviewing past reviews (WHOIS
> etc)
> Action: Should take on the action item that CWG will
> Action: Staff+ Steve Del Bianco to make sure the text in the reviews
> tables lines up
> 
> 
> 
> CCWG ACCT  Day 2 Session 3 ­ 24 April 2015
> 
> This call is being recorded.
> 
> LINKS
> Intensive Meeting Program:
> https://community.icann.org/pages/viewpage.action?pageId=52897568
> 
> Draft Report Dedicated Webpage:
> https://community.icann.org/display/acctcrosscomm/Draft+Report
> 
> Working Methods: 
> https://community.icann.org/download/attachments/52897394/CCWG%20Intense%20
> work%20days%20work%20methods%20-.pdf?version=1&modificationDate=14295697203
> 31&api=v2 
> 
> Day 2  Session 3 archives will be available at:
> https://community.icann.org/display/acctcrosscomm/Day+2+-+Session+3
> 
> Please note that chat sessions are being archived and follow the ICANN
> Expected Standards of Behavior:
> http://www.icann.org/en/news/in-focus/accountability/expected-standards
> 
> AGENDA:
>  1) Recap of session 2
>  2)  Outstanding stress tests - Stress tests where the contingency does
> not appear to be fully mitigated
>       a)  Including stress test 21: Government official demands rescind
> of a ccTLD
>  3)  Second reading of outstanding issues for public comment report
>  4)  Next Steps ­ Work Plan
> 
> 
> NOTES & ACTION ITEMS:
> These high-level notes are designed to help you navigate through content
> of the call and do not substitute in any way the transcript.
> 
> 
> Rollcall:
> N/A
> 
> Session 2 recap.  Preserving ICANN commitment from the AoC and through the
> AoC reviews, but not covered the bylaws changes suggested by the stress
> tests. 
> 
> 2)  Outstanding stress tests - Stress tests where the contingency does not
> appear to be fully mitigated
> 
> Stress test 21.  Govt official demands a reassignment of a ccTLD.
> Currently no mitigation on this test.
> 
> No answer, but to see if a revocation of a reassignment that did not
> follow procedure: RFC, FOI and GAC principles were considered.  CWG has
> suggest that ccNSO will soon be working on policy.  The test articulates
> the issues, but no solution/bylaws proposal or mechanism emerging.
> 
> CWG request that CCWG should note define mechanisms, ccNSO addressing
> this.  Unless perhaps out appeals mechanisms apply.
> 
> ccNSO has been working with GAC on transfer and revocation, a framework of
> interpretation (FOI) worked on.  The FOI references an appeals mechanism,
> but the ccNSO is still working on the appeals mechanisms, and as ongoing
> work the ccNSO is not will to sign up for any particular appeals process.
> And not all ccTLD managers are subject to 1591 as their TLD assigned
> before it was issues and before the GAC principles of 2006.
> 
> Could the local parties use the IRP mechanisms?  Or in line with the CWG
> input should we say this should not happen in the IRP.
> The view of the ccNSO is until ccNSO policy is developed on this the IRP
> is not applicable to the relegation process.
> 
> Suggestion that we include language to say these issues should not be
> subject to the IRP, pending ccNSO policy.
> 
> Action: Becky to confirm with ccNSO if this non-inclusion in the IRP, is
> acceptable.
> 
> Keep current text, this mechanism could be available if compatible with
> the Policy development process of the ccNSO
> 
> This section was frozen before the CWG request, we will be updating this
> in the next few days.  CWG explicit not to address pending ccNSO policy.
> 
> Action:  update text redelegation and revocation issues should not be
> subject to the IRP, pending ccNSO policy. And considering GAC
> contributions. 
> 
> Action to ensure the IRP txt is aligned as above.
> 
> 
> 3)  Second reading of outstanding issues for public comment report
> 
> NomCom to recall board members or a new committee and community.
> 
> Don¹t believe NomCom will be interested in or able to remove people
> appointed by a previous NomCom.  And don¹s want to put a NomCom in the
> position of taking instruction from the SO/AC ash this affects the
> independence of the NomCom.
> 
> pre-sign an letter to resign under certain conditions, and conditions
> might be a super-majority of the SO/AC to express dissatisfaction with
> their service.  This could remove one or more.
> 
> Suggestion for the recall NomCom be created.
> 
> This NomCom takes the SO/AC appeal and no complication over the person¹s
> appointment.  The only issue is the complaint.  A simple matter
> 
> Disagree that the pre-signed letter is enough to remove a director, as
> opposed to being used to initiate a process.  It may tend to be a reaction
> to a situation going on and does not involve  a check and balance.
> 
> Comment: use the current NomCom, does not see the difference in the board
> process. 
> 
> Comment: Removal for cause may cause appeals and other processes.  A group
> formed ad Hoc may be hard to fit in the member/designator models.
> 
> (legal)  The resignation letter.  Not meant to usurp and checks and
> balance.  It's the end of the process in an entire board recall situation.
> A contractual obligation for the director to step down from the board if
> the sending organization requested.
> 
> Current NomCom can be used.  The SO/AC may also have a changing
> membership.  This is the same for the NomCom
> 
> In favor of Avri¹s proposal to create a new structure of a recall NomCom
> as in the draft proposal.
> 
> Many seem in favor of not putting the current NomCom on the spot.  And
> this suggests the recall NomCom mechanisms should be favored. The
> conditional pre-signed resignation, also useful as the NomCom would not
> have a voting right in the community mechanism.
> 
> The recall NomCom originally written for individual director recall.  But
> not the whole board, and that the NomCom appointees to the board could
> stand or fall with the rest of the board by whatever mechanism is adopted
> for that.
> 
> If the recall NomCom constituted separately from the NomCom then lawyers
> have suggested this may not be possible as they are not the appointing
> body.  
> [Possible Action for legal sub-team to consult with the lawyers TBC]
> 
> Seem that the recall mechanism would be outside the community.  Have often
> spoken as the threat of removal as a means of influence what a Board
> member might do.  
> 
> Comment.  Discomfort with the notion of removing a Board member.  They are
> there for 3 years, community does not see al their work.
> 
> On the table: 
> Let the community do it, with some push.
> The recall NomCom, which can only take place with a trigger from the SO/AC
> community.  
> Would be under the NomCom bylaws, and if a member model the NomCom would
> be an unincorporated association. and the recall NomCom would come under
> the NomCom¹s procedures.
> Or use the existing NomCom, but hopefully keeping the petitioning
> mechanisms. 
> 
> (legal) The power to remove is a reason for having a member of designator
> model, with reason or no reason.  And hearing it would be difficult for
> the NomCom to do this is problematic.  But the proposal is viable.  Could
> have two committee under the unincorporated association entity and one of
> those could appoint and one recall.  For individual directors.  And these
> directors could still file a pre-resignation letter for their removal, or
> absolutely needed for the removal of the whole Board.
> 
> Is the Avri option what Josh described?  It is his the model could be
> implemented if we go with a member designator model and the NomCom becomes
> a unincorporated association.
> 
> Going forward if the NomCom is to put someone on the board it does need to
> be at least a designator, an unincorporated association.  And that entity
> can have two committees.  The process from the view of counsel is as
> described. 
> 
> A problem is that the new committee is constituted in the same numbers as
> the NomCom, so very different from the community mechanism. If constituted
> same as the community mechanism could go along with this.
> 
> Note, the process is to decide which option we put to the community.
> 
> Some do not have enough information to make the decision now, and
> objection to the use of a poll.
> 
> Would be advisable to have the same organization principles for the group
> that recalls as the one that appoints.
> 
> If member or designators, then the groups appointing to the board must be
> unincorporated association.  The NomCom would need to take on the required
> structure. Then the question is should the same group of people who
> appoint be different from those who remove.
> 
> Then SO/AC community reps would bring in their input in the petition.
> 
> Suggestion for a legal paper to explain the options.
> 
> Action.  Chairs will review the transcript and put a proposal to the
> group, and double check with the lawyers.
> 
> Board recall powers
> Reference proposal.  5 for SO and AC of ALAC and GAC, and 2 for RSAC and
> SSAC brings a total of 29 people.  75% is 22 of 29.  80% 4/5, is 24 votes
> of 29.  85% is 25 votes of 29.
> 
> Petition is 3 SO/AC.
> 
> If we want to block a single group from blocking a proposal then a 85%
> trigger is not workable.  Assuming that the will be able to split vote,
> then 80% is appropriate, 75% if a block vote.  The dynamics of the ICANN
> community will make reaching such a high threshold as 75% will be
> difficult.  
> 
> The group is leaning to individual vote. Removal of the whole board, and
> need stability.  
> 80% means if a single group blocks then requires unanimity from the rest
> and that is too high. Abstention are not counting.
> 
> The options are 75% and 80% with 75% preferred as the reference option.
> 
> The removal NomCom would have a different structure.
> 
> The pre-resignation letter essential, to ensure the recall process has
> effect. If the 75% threshold is met then expectation is that all directors
> would resign.
> 
> Diversity (participation and inclusion) as an issue for WS2.
> This proposal is consistent with Jan Scholte¹s advice received before the
> meetings. 
> Is included in the core values work?
> 
> Seeking what does it mean to be transparent by default?  How do we record
> what is classified and be aware of when something is classified.  And as
> has come up in ATRT, just because something has classified at the time,
> does it mean to be so in 5 years. It is almost default that every inquiry
> requires a DIDP
> 
> Not seen any objection to these two items
> 
> Also suggest looking at ICANN¹s whistleblower program in WS2.
> 
> In WS1 the 4 AoC reviews we are suggesting bringing over they will have
> better access than before to information needed to use during a review.
> 
> A package of three items to be added to WS2
> 
> Diversity
> Transparency and 
> Whistleblower policy
> 
> Noting we will ask the community for any additional issues during public
> comment
> 
> Package accepted.
> 
> AoC Section 8 
> 
> Identified that 8b is already reflected in the ICANN bylaws through
> article 18 offices.  And members and designators could block any changes.
> 
> Question is whether we want to move article 18 to fundamental.
> 
> Comment: to reflect that here are 2 opinions in the group that it should
> either be kept in the bylaws or as fundamental.
> 
> Does it cause concern for anyone to replace principles by headquarters.
> 
> Suggestion to seek advice from the lawyers on actual language.
> 
> The bylaws are more specific in CA/Los Angeles, and bylaws only refer to
> the United States.  Registered offices are often in different states from
> headquarters. The articles capture that it is a CA corporation, so the
> package captures the whole.
> 
> Pedro: The CCWG is considering whether bylaws Article 18 Section 1 should
> keep its current status or be among the bylaws sections listed as
> ³Fundamental Bylaws². In the latter case, any changes to it  would require
> positive approval by Members/Designators.
> 
> Suggestion that to allow flexibility and a lower threshold, if it is to be
> a fundamental bylaw or traditional.
> 
> Both options will be in there.
> 
> Reviews in the bylaws and AoC
> 
> Highlight difference of today and being proposed.
> 
> proposed: assessing the role and effectiveness of the GAC in its
> interaction with the board.
> 
> in the AoC, item f.  Implementation of recommendation. The review team may
> terminate reviews and create new reviews.
> 
> Timing.  ART is every 3 years.  Suggest no less frequently than every 5
> years, which would allow us to do this more frequently.
> 
> 5 years:  The current implementation is from the receipt of report, so
> adding an additional year.
> 
> The itemized points are all mandatory, and believed others out of scope.
> Need to take care to allow flexibility.
> 
> Review other review teams.  Clear in ATRT2, first to review other review
> teams, 1 lack expertise, 2.  exponentially increasing work. suggested the
> review be done by the successor review.
> 
> 'timing".  to make a point about the time the board received it.
> unclear on itemized issues
> (f) May be repeated in each review or in the chapeau
> 
> Each ATRT must review the previous ATRT.
> 
> Action Alan to provide a sentence about the reviewing past reviews (WHOIS
> etc)
> 
> comment:  the general principles of what we are trying to archive is
> actually captured in section of 11 of the ATRT2 report.
> 
> If there is a pressing need for a more frequent review then the proposal
> gives that flexibility.
> 
> Review effectiveness of WHOIS (directory services ‹ is included)
> Privacy concerns added with the OECD principles, and this is new
> AoC every three years, and left at three years (expecting change wrt
> directory services)
> 
> Evaluation of the new gTLD.  Change of languages as written pre new gTLD
> program. Competition and consumer trust and choice are reflected in the
> core values.
> 
> Subsequent rounds should not be opened until the review of previous review
> implemented. 
> 
> Action: Should take on the action item that CWG will recommend an IANA
> performance review will be conducted as CWG requirements, as a
> placeholder.  
> 
> Proceed with language as suggested?
> 
> Action: Staff+ Steve Del Bianco to make sure the text in the reviews
> tables lines up
> 
> Fulfilling CWG requirements
> 
> Ability of community to veto the budget.  Feasible, but more enforceable
> under the member model.
> 
> Ability to set up an IANA function review.  And that is be submitted as a
> fundamental bylaw
> 
> Suggested that the CWG would be placed in the same section as the other
> reviews.  Currently reviews are not Fundamental Bylaws.
> 
> The ability to trigger ad hoc [special] reviews.
> 
> The power to convene a review is driven by the community. And there is
> room for this special out of cycle review.
> 
> ccTLD revocation issue covered.
> 
> The IANA functions review in the CWG only covers naming functions, but it
> might evolve within the ICG.
> 
> Next Steps
> 
> Document update with the feedback received.  Update by the rapporteurs,
> staff and co-chairs.
> 
> Final document for review and approval by the CCWG
> 
> Final document May 1st, for final adjustments by the group, with a goal to
> publish on May 4th.  And public comment for 30 days, comment period agreed
> by the group.  The final review should not be for substantial change:
> editorial and inconsistencies.
> 
> First check of the document on Tuesday's regular call, (April 28) and if
> needed hold an additional call on Thursday (April 30).
> 
> Is this acceptable?
> 
> Will affect the CCWG timeline. The public comment start was April 28,
> moving to May 4.  
> 
> Public comment moved by a few days.  Staff complies a review tool for the
> community to review.
> 
> Public comment 30 or 28 days?
> 30 days, green tick please
> Objections to keeping to 30 days red cross
> Agreement to open public comment for 30days.
> 
> The advisors will also be given opportunity to review the document.
> 
> We will review the CWG stress test.
> 
> Kavouss: profound thanks to the co-chairs, the rapporteurs, working group
> chairs. 
> 
> Thanks to colleagues for you participation and support, I have learnt a
> lot.  Thanks staff.  And congratulations to ICANN.  Thank you to you all.
> 
> co-chairs:  Thanks to staff, rapporteurs, lawyers and thanks to the whole
> group. 
> 
> Adjourn. 
>