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

[Adam Peake]

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. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4571 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20150425/30200105/smime.p7s>