[CCWG-ACCT] Notes-Recordings-Transcript links for CCWG ACCT Meeting #77 - 14 January

[Brenda Brewer]

Hello all,

 

The notes, recordings and transcripts for CCWG ACCT meeting #77 - 14 January will be available here:
https://community.icann.org/x/HpVlAw

A copy of the notes and action items and notes may be found below.

 

Thank you.

 

Kind regards,

Brenda

 

Action Items

*        ACTION ITEM/Conclusion: Becky and David to work on language for carve-out that will be put
for discussion on list.

*        ACTION ITEM/Conclusion: Board to reach out to ASO and come up with proposal. 

*        ACTION ITEM/Conclusion: Board to reach out to RSSAC and come up with proposal. 

*        ACTION ITEM/Conclusion: Get input from NTIA on whether it was meant to be a chapeau and
share on list. 


Notes


These high-level notes are designed to help you navigate through content of the call and do not
substitute in any way the transcript.

 

Rec 1 Inspection rights - Second reading

Board input: Board agrees with inspection right that are limited to accounting books and can be
invoked by single SO/AC. They 
should be a community right and not be reserved to the Sole Designator. The Sole Designator can
enforce the right. When invoked, 
demand should go to and through ICANN i.e. a community process. Giving the Sole Designator an
inspection right gives the model 
an inappropriate change. Text proposal:

Paragraph 20: "the CCWG-Accountability recommends including in the ICANN Bylaws the right for SOs or
ACs to inspect as 
outlined in California Corporations Code 6333, although this specific article reference would not be
mentioned in the 
Bylaws."  Paragraph 21: "This inspection right is distinct from the Document Information Disclosure
Policy (DIDP). While 
any eligible party can file a request according to the DIDP, Inspection Rights are only accessible
to SOs or ACs. The scopes 
are also different as explained below."  "Unlike the exercise of the other community powers, which
require community 
engagement and escalation before initiating a request for action by the EC, the CCWG-Accountability
recommends that a 
petition for inspection be brought directly by a single SO/AC or by multiple SO/ACs through making a
written 
demand on ICANN for the requested materials. If the Board refused or ignored the request, the
petitioning SO/AC(s) could 
then initiate an escalating community decision-making process to enforce demand on the Board
requiring community consensus. 

On Investigation Rights: The Board agrees with the inclusion of an investigatory right, and notes
that the language proposed in 
redline reflects the Board's comments.

On DIDP: The Board reaffirms its commitment to addressing improvements to the DIDP in WS2, and
thanks the CCWG for the 
clarification in the document on the differences between the inspection right and the DIDP. 

Feedback:

- It is unclear that there will be an expanded process for DIDP. Is that the case? 

--> DIDP is not on agenda of recommendation 1. This discussion will take place on Thursday. 

Conclusion: We will be moving forward with inspection rights section. We will reopen second item -
GAC as decisional participant - once 
we have input from GAC.

----

Rec 2 - Escalation timeline - Second reading

Edits include: timeframe lengthened for SO/ACs to make a decision and conference call step removed.
Once petition is launched, 
it will go to Community Forum. This has an impact on threshold and overall timeframe. Rationale for
giving additional time is to give 
more time for SO/ACs to exchange on why they would want power to be used. Extension is not available
for ICANN or IANA budget.

On timeframe

Feedback:

-  (1) The CF format allows for a "second or third" session if needed - because the CF is the best
chance to amicably resolve an issue that makes sense but  won't these added sessions need an 
extension "as appropriate" as 21 days may be inadequate

---> Community Forum might take 1-2 days. Cannot imagine it would but there could be a Community
Forum where separate sessions to give a global conversation 
(e.g. session at 06:00 UTC - 14:00 UTC etc). We have set deadlines for when Forum should be started
but may want to set tighter limits for duration of Forum. 

 - (2) Suggest step six get 3 days, not 1 - there may be communication issues or human error. 

---> Board will be advised. SO/AC decision will be recording decisions publicly. 

- (3) Could the "days" specified be limited to week days - remember that holidays vary widely across
the globe and August is virtually 
work-free almost everywhere

---> Intention is not that 21 days would be business days. If we want to extend timeframe, we should
have discussion but the days 
in this document are calendar days.

- There is encouragement to socialize other information required before the Community Forum is held.
We cannot be too prescriptive 
on number of days (depending on difficulty of issue). We should allow for flexibility. We should not
be too prescriptive on process - when 
resolution has been found.

Feedback:

- Use calendar days instead of week. 

---> Natural days will be used. 

- Community Forum is opportunity to resolve differences between community and Board. If there is
opportunity for resolution of issues, 
there will need to be multiple sessions. It is inevitable that there will be  multiple sessions. 

- Escalation timeframe has been issue for some GAC members. How many days did the process have
before the changes (at a maximum) 
and how many days will it have when the changes proposed by Jordan will be inserted? We might be
compressing too much. Jumping to 
the Community Forum needs to be considered with care. Sessions does not mean meeting on same days.
We should allow for further 
deliberations. If Board comes up with new solution/reasoning, we need to go back to our SO or AC.
More time is needed for meaningful 
deliberations. By suppressing conference call, we are diminishing elements of deliberation.

---> In the previous process, we were rushing SO/ACs (conference call within 7 days). By deleting
this step, we are saving two decision 
points. We may want to give timeframe for which discussions should happen. On formal structure,
there will be informal discussions 
going on. We need to juggle community need for dialogue with exercise of powers. 

- Our objective is to streamline the process. There are discussion steps before the Community Forum.
Community will be informed for 
Community Forum discussion.

Feedback:

- Unclear that there will be deliberations 

Board input: The Board will support the community in making reasonable adjustments to the escalation
timeframes to support the 
community's ability to take quick action to exercise its powers, while still having the time it
needs to socialize the issues appropriately.   
Where the community believes that some of the tight timeframes might require adjustment by a matter
of days, or have flexibility to 
simplify some of the steps when broad community support is clear, these are all areas that the Board
can support adjusting.    As the CCWG 
works to finalize a revised proposal on this, the Board notes that it would not support an extension
of the initial petition phase beyond 30 days, 
and urges the timelines to be drafted with efficiency and quick action in mind. On thresholds, the
Board supports the CCWG modification 
at Paragraph 62. On Board removal, the Board does not support the change at Paragraph 64.
Demonstration of full community support 
for the exercise of this ultimate power is essential, and the Board does not support a change to
lower this threshold.  The other areas where 
this reduced threshold is proposed (blocking budget, fundamental Bylaws changes) do not raise this
same concern.  A proposed redline of 
Paragraph 64 to address this concern is: The CCWG-Accountability also recommends that in a situation
where use of the community 
powers of either blocking a budget or approving changes to Fundamental Bylaws, where only four
Decisional SOs or ACs participate, 
and the threshold is set at four in support  these two powers will still be validly exercised if
three are in support and no more than 
one objects.  The CCWG-Accountability came to this decision after considering the extended
escalation 
process now proposed prior to the use of Community Powers, and to avoid the risk of powers being
un-useable (especially the risk of making changes to ICANN's Fundamental Bylaws effectively
impossible.

Conclusion: We are trying to have a process that is efficient and flexible. Documentation should be
exchanged prior to 
Community Forum. We will continue collecting ideas and refining on the list. We will conclude this
item next week. 

On thresholds

Feedback:

- If at stage where SO/ACs cannot take action (3 out of 5), we will end up with situation where
organization is frozen and Bylaw cannot 
be changed. If Community Forum is called and no one attends, the Board could act unilaterally past a
defined period of time. There needs 
to be an escape patch. 

---> Let's move this concern and suggestion to the list. If it gets traction, we will move it to the
plenary. 

- Disagree with suggestion above. 

Conclusion: No objection to thresholds proposed in Jordan's revised document. 

 

Rec 4 - Budget (IANA)

Board input: Paragraph 21: Board is very supportive of text - it addresses concerns. We are properly
delivering services. The whole 
caretaker budget should be embedded in Fundamental Bylaws. 1) e. Board Proposal on ICANN Caretaker
Budget. In the event that 
the process for community power to reject the Operating Plan and Budget is invoked, and after the
preceding escalation mechanism 
(as described in Recommendation #2) has failed to resolve an issue, the rejection is triggered.
While the rejection is in effect and 
being resolved, ICANN needs an operating plan and a budget so that it can continue to operate on a
day-to-day basis. The notion 
of a caretaker Operating Plan and Budget has been defined to address this need.  The caretaker
budget is in substance a replacement 
Operating Plan and Budget designed to allow the organization to operate its basic and primary
functions, while avoiding "non-indispensable" 
work during the period of the rejection is in effect.   The conceptual definition of the caretaker
budget has been formulated, but the more 
detailed definition of what is "indispensable" or not now must be further documented.

The Board accepts the above described approach to the veto process and corresponding caretaker
Operating Plan and Budget. The Board 
also recommends that the caretaker budget approach be embedded in the Fundamental Bylaws, including
the responsibility of the CFO to 
establish the caretaker budget in accordance with the defined approach. The Board's acceptance of
this approach is also predicated on the 
consistency of the implemented solution with the conceptual definition described above.

In paragraph between 19 and 20, the caretaker budget would be enacted and details are under
development. We can have it in line with 
paragraph 13. Caretaker budget will be developed in implementation in line with guidelines. 

Feedback:

*        Valid points. In favor of Board suggestions on Caretaker Budget. We want to ensure we have
alignment with budget power. 

*        Agree with Board suggestions

Conclusion: We will be taking Board suggestions on board.

-----

Rec 3 Fundamental Bylaws (first reading)

Overview of comments/discussion items. 

Feedback:

/ 

Conclusion: We will take on these suggestions for second reading.

Rec 4 Scope of community IRP & Separation Power (first reading)

Overview of discussion items. 

On community IRP Thresholds

Board input: Board is concerned that there should be protections built in against ganging up and
recommends higher thresholds.

Feedback:

- Some comments required approval of PDP should not be subject of IRP unless the initiating party of
PDP is part of the process. We 
could leave threshold at 3 SO/ACs and still address Board concern. 

- If appropriate carve-out, this could be acceptable subject to review of text. 

- Carve-out is a sensible approach. 

ACTION ITEM/Conclusion: Becky and David to work on language for carve-out that will be put for
discussion on list.

On Expert Panels 

Do we want IRP to resolve inconsistent outcomes? Decision-making bodies need to contemplate how to
resolve issues and effects 
on community. It should be something that should be addressed in PDP and limited to addressing
failures of Expert Panels outside of in conflict with Mission. 

Board input: IRP should be used for violations of Bylaws or Articles. We do not want people making
decisions over opinion of 
panel. There are procedures to follow.  

Feedback: 

- Concern that practical solution to inconsistent panel decisions.  

On separation process

Feedback:

/ 

Conclusion: We will be moving forward with first reading. Language on carve-out will be sent to the
list. 

Rec 5 - Mission

On Numbers

ICANN Board has proposed alternative formulation for numbers. It has added substantive role of
ratifying policy at global level that are 
reasonably related to IP and AS numbers. It creates a role that cannot be changed. MOU with RIRs
provide alternate mechanism for 
changing this. We get into a disconnect between MOU and Bylaws.

Feedback:

 Online discussions with Bruce. We still feel it is important to keep this reference to ASO MOU
given that we are clearly defining ICANN's role 

based on an agreement between ICANN and RIRs. Board is okay with this. If no further concerns from
Board, our strong preference is to keep 
Third Proposal language. 

Board input: Alternative may be paragraph in ASO MoU. 

ACTION ITEM/Conclusion: Board to reach out to ASO and come up with proposal. 

On Root Servers

RSSAC has proposed that ICANN's role is to facilitate coordination of the operation. ICANN Board
language indicates an operational 
role and considers inputs from the communities dependent on the root server system. 

Board input: Would support text from RSSAC but need to discuss first. 

ACTION ITEM/Conclusion: Board to reach out to RSSAC and come up with proposal. 

On Consumer Trust

Robust discussions on list with respect to language. AOC creates an obligation in context of new
gTLDs expansion. It is being carried over in 
review section of Bylaws. Significant concerns voiced on scope of ICANN's role.  Suggestion that we
put general consumer trust issue in Work 
Stream 2 for further discussion. 

Feedback:

- Disagree with pushing it to WS2. Part of getting AOC in Work Stream 1 is dealing with that issue.
It might be helpful to go back to original source 
to see if we may have any assistance on this.

- Much of what we have in AoC is already in Bylaws. This, however, was not. It is important to look
at the AoC paragraph. Item on Consumer Trust 
is a chapeau leading into the reviews. It is something that is generally applicable, not just new
gTLDs. It is within mission of contractual compliance. 

- We are trying to discuss a broader issue than what was originally in the AOC. AOC review section
is within our report. What is meant by 
market place, consumer trust etc is beyond AOC and should be discussed in WS2. 

- Paragraph 3 is an introductory text. a - b - c -d link to specific commitments in 7 - 8 - 9. It
specifically relates to expansion of TLD space and calls for specific 
review with respect to that. Comment that 3 is only about gTLDs is incorrect. We have transposed the
commitment that is referenced in 3 c and articulated in 9.

- Agree with pushing to WS2. 

- Commitment to consumer trust in DNS market place means in gTLD space. Against pushing to WS2. 

- Paragraph 3 of AOC  is a chapeau to reviews. Inappropriate to read it as brand new. 

- AOC points is for WS1. We are trying to go beyond what is in AOC and there is a lot of concern
about applicability. It would be a game 
change if add components to WS1. This needs more work. 

- Language cannot be in use. We cannot proceed with expansive interpretation

- It is obvious that goes beyond gTLDs but ok to go back to first references.

ACTION item/Conclusion: Get input from NTIA on whether it was meant to be a chapeau and share on
list. 

 Conclusion: Incorporate the AoC as it stands as part of WS1 but continue to review the issue of
extending Consumer Trust as part of WS2

 AOB

/

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160114/4c646617/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5035 bytes
Desc: not available
URL: <http://mm.icann.org/pipermail/accountability-cross-community/attachments/20160114/4c646617/smime-0001.p7s>